[nbevans]

Every OOP developer is on a journey, they just don't know it. Some of them will never make it. But some will reach a point of realisation where writing well-designed software comes naturally to them because they've inadvertently stumbled upon the core concepts of functional programming. It then requires them to realise that what they've found is just FP and then requires a further minor step to actually learn a more appropriate language. Once this developer makes that jump he reaches a new plain of development happiness and a feeling of power over OOP practicers because his level of productivity has magnified by about 3x. Enabling themselves to allocate brain power to more important issues. That's just called progress though.

Having said that, I dislike articles like this because they shout too loudly. Just use a proper hybrid OO-FP (ala F# / Scala etc) language and be done with it. These languages are designed for business productivity - not academic box ticking. Everybody happy.

[mpweiher]

What arrogant hogwash.

I was exposed to functional programming my first year at university (it was used in the introductory courses) and quickly noticed that contrary to the hype (similar to yours), functional programs tended to be more bloated with trying to work around limitations of the less expressive programming model/language and not particularly more robust.

That doesn't mean certain aspects can't be nice to have ('let' is kinda nice), but even that is mostly for programming-in-the-small.

Your unsubstantiated claim of 3x productivity increase is, er, "interesting".

[chriswarbo]

> was exposed to functional programming my first year at university (it was used in the introductory courses) and quickly noticed that contrary to the hype (similar to yours), functional programs tended to be more bloated with trying to work around limitations of the less expressive programming model/language and not particularly more robust.

In other words, when you first tried a functional programming language you tried to write imperative code in it, and the result ended up bloated and fragile? I'm not surprised.

Guess what, trying to write pure FP in Java by chaining together static methods and "Function<A, B>" objects would end up with bloated and fragile code too; but that's not a valid criticism of OO.

[mpweiher]

> when you first tried a functional programming language you tried to write imperative code in it,

Guess again. Did I mention the arrogance and the unwarranted assumptions?

[denibertovic]

I've learned Haskell at university too. That doesn't prove anything though does it? At the time I've found it useless and plain wrong ... it is much later that I learned to appreciate it and value what it brings to the table...much much later.

[mpweiher]

We didn't have Haskell in 1989. As I wrote, there are things I value in FP languages in general, and more specifically Backus's FP calculus inspired me to come up with Higher Order Messaging[1].

It's nice to have language support for functional style (let, for example) where that is appropriate for the problem at hand, but you can write in that style without the language support easily enough.

On the other hand, when FP style is not appropriate for the problem at hand, it really, really gets in the way, and that's the case a lot of the time. Many if not most problems (outside of writing compilers for FP languages) don't really fit the functional style, and have to be made to fit.

Experienced devs will choose appropriate tools for the problem at hand. Me, I like adaptive tooling that I can bend to fit the problem, which is why I like dynamic OO languages, internal DSLs and Domain Modeling[2] in general.

In fact, I think the current tools are still a little too inflexible for this, which is why I am creating a language to address some of these issues: http://objective.st

FP seems to be more about bending the problem to fit the tooling, which I guess may work for a specific kind of mindset.

[1] http://en.wikipedia.org/wiki/Higher_order_message

[2] http://www.amazon.com/Domain-Driven-Design-Tackling-Complexi...

[nbevans]

Adaptive tooling. You mean like a FP ML then ala OCaml / F#.

I said I like hybrid OO-FP languages for business productivity, rather than concentrating on meaningless software architecture astronautics like that "Blue Book" you linked. I've read it, yes starting from chapter 11, and while I took it on board I find many of its ideas and practices completely toxic now. Just like Gang of Four patterns and the inane amount that OOP inherently relies upon them.

Then you go off on some academic rant about "well in 1989" (no one cares) and HPC computing (no one cares, it's hardly relevant either). FP has progressed a lot since 89 but you're seemingly too old and set in your purely OOP ways to realise it. Carry on. But take a look at a modern OO-FP multi paradigm language and feel enlightened.

If you carry on down the path of ranting about FP because, shock horror, yes it is slower than imperative code then you'll look even sillier. Not that anyone really cares about some randomer making himself look silly by poo-pooing a whole programming language paradigm whilst paradoxically claiming he always likes to choose the right tool for the job. I guess your jobs have just never been varied enough then?

PS: Higher order messaging is just function composition with presumably a dash of actors. Congrats on reinventing a functional programming concept. But it perfectly illustrate the ignorance so prevalent in individuals that only know OOP and will attack anything that isn't OOP.

[mpweiher]

>academic rant about "well in 1989" (no one cares)

Funny, my age seemed to be important when I was "young and inexperienced". Now "no one cares"...and I am "too old and set in my ways". Which is it? Both? Does my age matter or not? Both again?

Hint: if your conclusion remains the same, but your reasons for that conclusion are this inconsistent, then your conclusions is almost certainly not supported by those reasons. In the words of Popper, an "immunized" theory, meaning it is immune to falsification by empirical evidence.

Anyway, as you gain experience, you will probably appreciate the wisdom of domain modeling. Or remain ignorant. Not sure how the GoF Pattern book got into this discussion, but note that it is largely a description of workarounds for non-dynamic OO languages.

The 6x slower performance was relevant for "Data Parallel Haskell", because performance is pretty much the only reason for doing that sort of parallelism in the first place, as I explained. HPC was relevant because they had been doing the thing that was claimed "impossible" by SPJ in languages not like Haskell...in FORTRAN (which I hope we can agree is not all that much like Haskell).

Had you paid attention, you would have noticed that I use functional techniques when appropriate. I just don't buy the inflated claims, which have been consistently inflated and consistently unsupported by evidence for well over 2 decades now ... and object to arrogant ignorance such as that which you have amply displayed and continue to display.

To call HOM derivative is not exactly a deep insight, when I very specifically told you that it was derivative (and the papers are also very clear about that). However, you display fundamental misunderstanding of not just HOM (which could be forgiven), but also OOP and FP: HOM is exactly not "function composition". OOP languages have had higher order functions ("blocks" in Smalltalk) for decades, and these can be and have been composed quite easily. The point of HOM is that the first order mechanism in an OOPL is messaging, so having functions as the higher order mechanism is inconsistent. HOM creates a HO mechanism that is based on messaging instead of functions, hence HOM. Actors are an unrelated concept.

[nbevans]

Cheeky bugger ain't you? "Had you paid attention"? "As I gain experience"? You mean on top of the 20 I already have, and which I clearly used to better effect than yourself as I'm not still rolling around believing the DDD Blue Book is the be-all-end-all silver bullet of software development. I took it on board, and kept some of its ideas in my toolkit, but really it is a book all about over-engineering for those that don't know any better. Domain modelling gives the impression of UML diagrams and all that lark, is that you? It isn't me. My domain models are honed over time as the project evolves. You act like domain models can't be done in FP. My domain models that I write in F# are sodding impressive and they only use a quarter of the lines of code required by Obj-C, Java, C# and similar ilk.

HOM? Don't make me laugh. It's just more shit for the objective world to work around limitations of the languages. A message is just an object that can be and queued somewhere, and potentially serialized. That's not special.

- Loves dynamic languages. Check. - Loves OO. Check. - Loves DDD Blue Book. Check. - Invents "new" programming design patterns all by himself believing he is the sole inventor. Check. - Dabbled with an FP language in '89 and hasn't touched FP ever since. Check. - Created his own shitty programming language to try to improve upon OOPs limitations. Check. - Dares to talk down to anyone more experienced or that disagrees with him. Check.

Yeah, I wouldn't employ you either.

[tome]

I know it's always tempting to argue vagaries with trolls, but if you have the time I would very much appreciate it if you could give a short answer to my good faith question here:

https://news.ycombinator.com/item?id=8339654

[tome]

> Many if not most problems ... don't really fit the functional style, and have to be made to fit

Some examples would be helpful here.

[mpweiher]

Hmm...didn't realize this was (or could be) a serious question.

Anything with state comes to mind. The text field I am typing this into, for example. I type on my keyboard and the state of the text field changes, and after I hit "reply", the state of the page changes with a comment appended. Before/after.

Yes, you can implement this by creating a completely new page containing the concatenation of the old page with the comment, but externally (when you visit the URL), the state of that page has changed. So if you choose to implement the problem in a functional style, you have to bridge that gap somehow between that style and the problem at hand.

Any sort of document processing done on computers in Word, Excel (regarding the document itself, not the one way dataflow constraint program inside), OpenOffice, PowerPoint, Pages, Keynote, Quark XPress, InDesign, Photoshop, Illustrator etc. People use these programs to change the state of documents. That is the purpose of these programs.

Anything that interacts with the world, for example the user interface.

Or Wikipedia. Pages change, sometimes because there is new information, sometimes because something in the world has changed. Or most any other web site.

Really, the world (a) has (a lot of) state and (b) that state is changing incessantly. It is not (a) stateless or (b) immutable.

But don't take it from me: "In the end, any program must manipulate state. If it doesn't, there is no point in running it. You hit go and the box gets hotter" - Simon Peyton-Jones. https://www.youtube.com/watch?v=iSmkqocn0oQ&t=3m20s

[tome]

Thank you for the food for thought.

[nbevans]

Don't worry, you haven't reached the right level of experience yet. You'll get there, though you have some attitude problems to overcome first like most young programmers.

[mpweiher]

LOL! My 1st year university course was 1989. When were you born?

Interestingly, that is exactly what I see in the current generation of FP hypsters. Grandiose claims based on very limited experience. Aka: know so little, assume so much.

But don't worry, it happens to the best. My favorite is still the Simon Peyton-Jones talk on Data Parallel Haskell, where he can't help himself, but just has to make the snide comment "this is only possible in a language like Haskell". Hand raised in the auditorium: The HPC community has been doing this for years. In FORTRAN. But carry on...

(And of course, the results are dismal: 6 cores required to match sequential C! Considering that this sort of concurrency [there are others] is exclusively for better performance, that is a damning result).

Despite these, er, issues, it is an absolutely fascinating talk, and the techniques look quite worthwhile. After all, they've been in use in the HPC community for some time :-)

https://www.youtube.com/watch?v=NWSZ4c9yqW8

[frowaway001]

I wonder why the parent comment is downvoted. He's dead on.

[AnimalMuppet]

nbevans made a post dripping with condescension and arrogance. mpweiher pointed that out. nbevans replied with... more arrogance and condescension. And you wonder why he got downvoted?

He's also (at least partly) wrong, and so are you. FP has it's place. But what people like you and nbevans never seem to realize is that the rest of the programming world is neither stupid nor ignorant. Yes, there are better ways of working than the ways that we work. Yes, we don't know all of those ways, even though some people do. But that's true for you, too. There are people who are ignorant about FP. There are also people who are both smarter than you and more experienced than you, who do not use FP for good reasons. But you and nbevans arrogantly tell us that once we learn enough, we'll see that you're right. Your inexcusable assumption that everyone who disagrees with you has to be both wrong and ignorant is why you're getting downvoted.

[nbevans]

OOP people are too sensitive!

I still use OOP just not as much as I have another tool in the box (FP) that is sometimes (often?) more appropriate.

[tlarkworthy]

I made the switch to FP. I first learnt Basic then Delphi then C then Java then C# then Python then JS and now Scala. Python is my still my favourite and I really like Scala too. Anyway, I could write big stuff in any typed language OO or otherwise. I don't get what the revelation about FP is. If you want bullet proof code, get the model checker out and work in state machines. That is far the biggest revelation I have had in my career. FP doesn't save me much time or much safety . It doesn't solve concurrency. Its usually terser which is nice. That's about it. Python is a massive productivity boost but it doesn't scale. Scala scales but isn't that productive IMHO.

[chas]

I'm not going to claim it solves concurrency, but Haskell's combination of STM, expressive types, and immutable data by default make it the nicest language I have used for concurrency. (I have heard similar praise of Clojure as well, but I don't have any experience with it.)

[frowaway001]

I found Scala to be hugely more productive than Python.

[zak_mc_kracken]

You don't sound arrogant and condescending at all.

Here is the truth: in a few years, you'll realize that OOP is actually vastly superior to FP. It's okay if you don't believe me right now, you haven't progressed enough yet. Maybe you will, maybe you won't. If you succeed, you'll look back on FP and you will wonder how you could ever tolerate such an inferior programming model.

[jl6]

If you think you have found the silver bullet then you are still on the journey too.

[nbevans]

I don't think that. I think I found a big productivity boost and the ability to focus the mind on more important issues than trying to repetitively trick a imperative language design to do what I want.

Always looking for the next step on the journey. (It isn't Go)

[skybrian]

It's also possible that they're on a journey to Go, not FP.