Disadvantages of purely functional programming • Hacker News Board

Re: Disadvantages of purely functional programming

#41

Post by cubano » Sun, Jun 05, 2016, 5:41 PM UTC

chubot wrote: post #23

Good points, although I agree that a lot of them boil down to similar statements. I have settled on a style of doing "functional-like" programming in Python and C++. It's more about the high level architecture than low level coding details. It means being very paranoid and rigorous about state -- but still having great tools to express it! For example: Using ZERO mutable globals, and passing state in as a parameter t…

Yes, you are definitely in the right path but don't you sometimes notice that "get-this-stuff-working-by-tomorrow" productivity is dinged by always having to be doing such deep and ordered design, as well as working out all the other typical programming issues?

I went down an almost identical path as you many years ago but found that after a certain point, the maintenance and just being away from the codebase for a couple of months made the time needed to make coherent mods that fit the design quite problematic.

Re: Disadvantages of purely functional programming

#42

Post by tome » Sun, Jun 05, 2016, 5:44 PM UTC

rusabd wrote: post #40

pmarreck wrote: post #29

Earlier quoted context omitted.

Tail-call optimization eliminates those. Assuming your language provides it, and assuming you trigger it correctly. ;) http://stackoverflow.com/questions/32164370/does-elixir-infi...

TCO eliminates some types of recursion. Not all of them.

Eliminates some types of stack usage, not "recursion".

Re: Disadvantages of purely functional programming

#43

Post by marxama » Sun, Jun 05, 2016, 5:54 PM UTC

charlieflowers wrote: post #3

xyzzy4 wrote: post #2

I don't get why people would use functional programming for anything. It's both more difficult and slower.

When it comes to expressing logic in small composable, understandable pieces, nothing else can compete. Unfortunately, it does have the challenges listed in the OP, so it seems to make most sense where either (a) it is ok to leave performance on the table in the interest of clarity or (b) you create a little sandbox in which you use functional programming for clarity, and something outside your sandbox compensates fo…

I think it's also interesting to note that sometimes when choosing immutability as the default, which gives a slight performance penalty for basic operations compared to doing normal mutation, you end up being able to save lots of performance on a larger level. React wrappers in ClojureScript, such as Om, are a good example of this - since data is immutable, shouldComponentUpdate is automatically and trivially implemented for you, leading to oftentimes better performance than straight React. I reckon this would also be the case with the lock-free code you write in Clojure, etc.

Re: Disadvantages of purely functional programming

#44

Post by lispm » Sun, Jun 05, 2016, 5:54 PM UTC

yummyfajitas wrote: post #21

efnx wrote: post #7

Harrop is known in the Haskell community for being a hater. Most of his remarks here are opinion, which is fine. Lots of people don't like Haskell - that's also fine, but pieces like these hurt the community because it will both push away newcomers and make industrial use more difficult. Also, I've never needed an unsorted dictionary, and parallelism is actually great in Haskell. http://chimera.labs.oreilly.com/books…

This is an ad hominem attack, and a fallacy. He may hate Haskell - so what? Are any of his critiques incorrect?

Harrop is a known troll. This is not an attack.

It's a fact.

> Are any of his critiques incorrect?

Probably. That's what makes a real troll effective.

Harrop had a business around OCaml and later F#. He often posted to other FP communities controversial statements, with added links to his offerings. He started not knowing much about those other languages or FP in general, but in later years he learned from people and his attacks got more sophisticated. His controversial marketing did not make him many friends, though.

Going after the real or perceived drawbacks of purely functional programming in Haskell and also its data structures was one of his favorite targets.

Before that he used similar tactics in the Lisp community. For example I remember that he once said that Lisp is not used and this can be seen that there are no Lisp mailing list archived at GMANE. Well, that one was easy. I explained to him that GMANE has a top hierarchy for Lisp, where all the mailing lists are. But that did not stop him, he discovered or made up many more problems with Lisp. ;-)

Re: Disadvantages of purely functional programming

#45

Post by pjmlp » Sun, Jun 05, 2016, 5:58 PM UTC

chubot wrote: post #23

Good points, although I agree that a lot of them boil down to similar statements. I have settled on a style of doing "functional-like" programming in Python and C++. It's more about the high level architecture than low level coding details. It means being very paranoid and rigorous about state -- but still having great tools to express it! For example: Using ZERO mutable globals, and passing state in as a parameter t…

I dabble occasionally in FP languages and I am a bit fan of the ML family.

However I came to the conclusion that the latest improvemetns in C#, Java and C++ are already quite good for doing FP style programming.

Yes, I feel a bit dirty not being able to use more pure FP languages, but I have to work within the context that customers allow us to do.

Although it feels like blasphemy, C++14/7 can be seen almost as an impure Haskell with curly brackets.

Re: Disadvantages of purely functional programming

#46

Post by nv-vn » Sun, Jun 05, 2016, 6:01 PM UTC

chubot wrote: post #23

Good points, although I agree that a lot of them boil down to similar statements. I have settled on a style of doing "functional-like" programming in Python and C++. It's more about the high level architecture than low level coding details. It means being very paranoid and rigorous about state -- but still having great tools to express it! For example: Using ZERO mutable globals, and passing state in as a parameter t…

I suggest giving some form of parser combinators a try for a more functional approach to parsing/lexing.

Re: Disadvantages of purely functional programming

#47

Post by dottedmag » Sun, Jun 05, 2016, 6:27 PM UTC

Roboprog wrote: post #33

It seems to me that yes, you need an "escape hatch" in an FP language to make your updates. It would be nice if the language required such functions, and the modules in which they reside, to be flagged. (I don't know if Haskell does something like this with mutation, or not) It also seems that an "actor model" would be a good way to encapsulate the updates in an otherwise FP program by having a loop/reduce/fold wrapp…

Flagged like "State T" in function type, which Haskell has had since ~1995?

Re: Disadvantages of purely functional programming

#48

Post by chubot » Sun, Jun 05, 2016, 6:46 PM UTC

Roboprog wrote: post #31

chubot wrote: post #23

Good points, although I agree that a lot of them boil down to similar statements. I have settled on a style of doing "functional-like" programming in Python and C++. It's more about the high level architecture than low level coding details. It means being very paranoid and rigorous about state -- but still having great tools to express it! For example: Using ZERO mutable globals, and passing state in as a parameter t…

Interesting points. As a matter of style, I still prefer using currying over "one trick pony" (single method/function) classes, though. Sometimes this means I have several "layers" of references to the original function, with varying numbers of parameters applied as each layer further specializes (adds configuration). I'm doing most of this type of work in Javascript, though, so YMMV. (PS - also did some work with Li…

If you're using JavaScript, I think that's actually an advantage because your closures can return multiple named methods (in a JS dictionary). To me, closures in Lisp seem a bit impoverished since it's awkward to return more than one method. (Another problem is that I don't like reifying random local variables as program state. State is important; it should be both minimized and made explicit. Classes make it explicit.)

Classes with one method are useful, but so are classes with multiple methods.

I just stumbled across this post again, and HIGHLY agree with it. Yegge is basically outlining why JavaScript is a better language than Emacs Lisp. I had the same experience with hacking on femtolisp and trying to write my shell in it.

http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-int...

OCaml and Lisp both have problems with polymorphic print. There were some recent posts on HN about the expression problem, and the duality between FP and OOP, which I liked. But I have to say that print should be polymorphic, full stop. And if your functional language has problems with that, that's the language's problem and not my problem :)

http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent

Re: Disadvantages of purely functional programming

#49

Post by chubot » Sun, Jun 05, 2016, 7:03 PM UTC

cubano wrote: post #41

chubot wrote: post #23

Good points, although I agree that a lot of them boil down to similar statements. I have settled on a style of doing "functional-like" programming in Python and C++. It's more about the high level architecture than low level coding details. It means being very paranoid and rigorous about state -- but still having great tools to express it! For example: Using ZERO mutable globals, and passing state in as a parameter t…

Yes, you are definitely in the right path but don't you sometimes notice that "get-this-stuff-working-by-tomorrow" productivity is dinged by always having to be doing such deep and ordered design, as well as working out all the other typical programming issues? I went down an almost identical path as you many years ago but found that after a certain point, the maintenance and just being away from the codebase for a c…

Yes, that's definitely an issue in general. But in this case, my shell has some unique properties, which make it both necessary and possible to do a good job of software design:

1. Shell is a fixed problem domain. It's not changing, so you can spend time getting the components and interactions right, and know that the rug won't be pulled out from under you. (Though I am planning significant enhancements; it's not a "nostalgia" project).

2. But it is a complex problem domain. What I'm writing is a superset of full fledged POSIX shell, i.e. not a toy. You really do need to control complexity... or you'll end up with something like bash (at least 175 K LOC)

3. It's "systems code". I find that systems code needs to be more highly reliable than application code (or at least the market tolerates less sloppy systems code than app code). So good software architecture matters.

4. It's not a commercial product. I am doing all the design by myself, for better or worse, and the only deadlines are my own.

I think my main thing now is designing with ZERO mutable globals. I've probably been doing this for about 5 years now. Once you get in the habit, and get a few idioms down, I find it makes things go a lot faster. Things break less.

My main issue now is C++ headers and compile times. I started the current codebase with C++, but then switched over to Python to figure out the design. There were a lot of nontrivial issues to solve. Admittedly, implementing everything twice is pretty extreme! But maybe not -- I can write Python so fast that it saves time overall.

But that issue is entirely orthogonal to FP vs OOP. As far as that is concerned, Python and C++ are identical -- they have an imperative history, with significant OOP additions, and support a functional-in-the-small style (lambdas, list comprehensions, etc.). functional-in-the-large is already covered by classes, as mentioned.

Re: Disadvantages of purely functional programming

#50

Post by chubot » Sun, Jun 05, 2016, 7:06 PM UTC

pjmlp wrote: post #45

chubot wrote: post #23

Good points, although I agree that a lot of them boil down to similar statements. I have settled on a style of doing "functional-like" programming in Python and C++. It's more about the high level architecture than low level coding details. It means being very paranoid and rigorous about state -- but still having great tools to express it! For example: Using ZERO mutable globals, and passing state in as a parameter t…

I dabble occasionally in FP languages and I am a bit fan of the ML family. However I came to the conclusion that the latest improvemetns in C#, Java and C++ are already quite good for doing FP style programming. Yes, I feel a bit dirty not being able to use more pure FP languages, but I have to work within the context that customers allow us to do. Although it feels like blasphemy, C++14/7 can be seen almost as an im…

Yes I agree. It's MUCH easier to do FP in modern OO languages than OOP in functional languages. So with the OO languages, you're simply in a better position to solve real problems.

Learning OCaml really improved my appreciation of C++. C++ code is just all over the place, but you can write it in a pretty clean style (admittedly with considerable effort.)