Disadvantages of purely functional programming • Hacker News Board

Re: Disadvantages of purely functional programming

#51

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

nv-vn wrote: post #46

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.

Can you give me some pointers to some production quality parsers written with this style? By production quality, I mean "used in practice by a significant number of users".

I've looked at dozens of parsers, both for shells and for other programming languages, and none of them use this technique. I've studied many forms of parsing, and written my own lexing and parsing library/language. This included going on a pretty deep dive into PEGs.

I'm going to be a bit rude and say that parser combinators look appropriate for toy programs only. shell is the opposite of a toy language... it's fairly big, and has a very precise spec with all the hairs and scars of evolution.

Re: Disadvantages of purely functional programming

#52

Post by daxfohl » Sun, Jun 05, 2016, 7:19 PM UTC

striking wrote: post #11

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…

I like Haskell, and I use it once in a while. The thing is, I like knowing what my tools are capable of. That includes wanting to know their limits. This piece, to me, seems well-researched and factual. It's not perfect, but it's good. It has plenty of good citations for areas that aren't simply opinionated. A piece that is honest about the shortcomings of a piece of software can only help that software's community.…

Thing is, Harrop runs a business using F# and is a known troll against anything competing with F#. His MO is to focus on minutiae and make them sound like bigger deals than they actually are. Then when asked about a limitation of F# typically responds "well you'll never need that in the real world anyway". (See his responses to e.g. http://stackoverflow.com/questions/21170493/when-are-higher-..., trolling every single answer, including my own).

So, while potentially everything in the article is true, it's all likely overinflated and/or has workarounds. I'd not put much weight on anything in here.

Re: Disadvantages of purely functional programming

#53

Post by pjmlp » Sun, Jun 05, 2016, 7:33 PM UTC

chubot wrote: post #50

pjmlp wrote: post #45

Earlier quoted context omitted.

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.) Related: https://akabe.github.io/evilml/

Have you ever learned Smalltalk?

Thanks to support for blocks (lambda), Smalltalk collections already had LINQ style programming, aka algorithm.h support, for example.

Nice link.

Re: Disadvantages of purely functional programming

#54

Post by striking » Sun, Jun 05, 2016, 7:37 PM UTC

daxfohl wrote: post #52

striking wrote: post #11

Earlier quoted context omitted.

I like Haskell, and I use it once in a while. The thing is, I like knowing what my tools are capable of. That includes wanting to know their limits. This piece, to me, seems well-researched and factual. It's not perfect, but it's good. It has plenty of good citations for areas that aren't simply opinionated. A piece that is honest about the shortcomings of a piece of software can only help that software's community.…

Thing is, Harrop runs a business using F# and is a known troll against anything competing with F#. His MO is to focus on minutiae and make them sound like bigger deals than they actually are. Then when asked about a limitation of F# typically responds "well you'll never need that in the real world anyway". (See his responses to e.g. http://stackoverflow.com/questions/21170493/when-are-higher-... , trolling every sing…

It'd be nice for him to have disclosed that fact in his article.

It's a shame he'd rather flamewar over "best language" than honestly discussing the issues of both.

Re: Disadvantages of purely functional programming

#55

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

pjmlp wrote: post #53

chubot wrote: post #50

Earlier quoted context omitted.

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.) Related: https://akabe.github.io/evilml/

Have you ever learned Smalltalk? Thanks to support for blocks (lambda), Smalltalk collections already had LINQ style programming, aka algorithm.h support, for example. Nice link.

I actually haven't ever used SmallTalk, although I understand Ruby is considerably influenced by it (blocks, as far as I understand). Any pointers are appreciated though.

I'm more of a Python person, and Python doesn't really use blocks. I like the duality mentioned this post: http://journal.stuffwithstuff.com/2013/01/13/iteration-insid... (In summary it's for item in L: f(item) vs L.each(|item| ...)

I don't really think of C++ algorithm.h as LINQ ? I guess I don't use it that much. To me that is more "functional in the small", e.g. map or filter with lambdas, vs. "functional in the large". But I'd be interested to hear more details on this analogy.

Re: Disadvantages of purely functional programming

#56

Post by tome » Sun, Jun 05, 2016, 8:13 PM UTC

dottedmag wrote: post #47

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?

Or IO, or ST, or STM, or any other number of Haskell features that Roboprog has correctly predicted to exist.

Re: Disadvantages of purely functional programming

#57

Post by lispm » Sun, Jun 05, 2016, 9:01 PM UTC

chubot wrote: post #48

Roboprog wrote: post #31

Earlier quoted context omitted.

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 explici…

In Common Lisp it is easy to return multiple closures.

Emacs Lisp now has lexical closures, too.

Common Lisp has no problems with 'polymorphic print'.

Re: Disadvantages of purely functional programming

#58

Post by dllthomas » Sun, Jun 05, 2016, 10:32 PM UTC

dottedmag wrote: post #47

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?

Performance-wise, StateT is not an escape-hatch. It can be great for removing boilerplate, but it's simply another way of writing (s -> (a, s)).

IO, ST, and STM mentioned by tome better match the description of "escape hatch" - though for ST and STM they are very carefully shaped escape hatches.

Re: Disadvantages of purely functional programming

#59

Post by chubot » Sun, Jun 05, 2016, 11:15 PM UTC

lispm wrote: post #57

chubot wrote: post #48

Earlier quoted context omitted.

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 explici…

In Common Lisp it is easy to return multiple closures. Emacs Lisp now has lexical closures, too. Common Lisp has no problems with 'polymorphic print'.

Fair enough, but the appeal of Lisp to me is that it's a small axiomatic core, something that not only fits in your head, but the whole implementation fits in your head too. I wanted to use it to bootstrap languages, with no dependencies.

But it turns out that this axiomatic core is too impoverished for a lot of programming. You DO need something like Common Lisp on top. And I'm not really willing to open that can of worms, both for this specific project, and in general.

I would liken it to the language "Factor", which I've also experimented with... you took a specific and elegant paradigm, and tried to extend it to all paradigms, and ended up with a mess. A square peg in a round hole. Factor is basically Forth with OOP and a whole bunch of other stuff.

The other problem I pointed out is that the first problem you hit when writing a language is writing a lexer. I don't see anything that Lisp offers you in that respect. I looked at how Julia does it:

https://github.com/JuliaLang/julia/blob/master/src/julia-par...

Julia is actually bootstrapped in femtolisp. If you look at the lexer, it just looks like C code written with Scheme syntax. There's nothing helpful about this. It doesn't help you manage state. I might as well just write C.

(And actually I chose the code generator re2c, which is BETTER than C.)

Re: Disadvantages of purely functional programming

#60

Post by Roboprog » Mon, Jun 06, 2016, 4:55 AM UTC

chubot wrote: post #48

Roboprog wrote: post #31

Earlier quoted context omitted.

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 explici…

Back at CSU in the 80s, the Lisp exposure we had was so so. We learned about pure functions and a tiny bit about higher order functions, but that's about it. Nothing much about closures explicitly.

It's funny that one of the other commenters mentioned Smalltalk and blocks. Version 5 of the "Clipper" language I was using at work, which came out around 1990, added (borrowed, stole) blocks to an "XBase" style language. I didn't quite know what to do with them, so I used them to simulate virtual method tables in a non-OOP language :-)

It wasn't until I started tinkering with Ruby around 2006 or so that all the block / closure / lambda stuff REALLY sunk in ("Hmm. I could have been doing this - subroutines as closures, and not just "blank" call-backs - in all the Perl 5 code I've written the last 8 years"), some 20 years or so after I was in college. They did a good job of brainwashing proto-OOP into us back in the mid 80s.

Never used any Lisp macros, but "eval" and dynamic languages sure help shorten many tasks vs static types bondage and discipline. There's another Yegge essay on that sort of thing ("code compression"). The PC "4GL" type languages I used at work in the 80s were dynamic, with runtime types, and quite productive for the jobs they were designed for (pre MS-Windows...). I'm tired of the static type authoritarians punishing us all for the sins of C/C++. (I need to stop before I go into another rant)