Live data from Hacker News

A Year of Functional Programming

japgolly.blogspot.com.au

51–60 of 172 posts

Re: A Year of Functional Programming

#51

Nice article! I have been using Clojure for years, initially because a repetitive customer mandated its use, later for my own projects because it reduced my development time and is fun to code in. I tried Scala (really liked Martin Odersky's Coursera class!) but it did not stick. That said, Haskell has started to win my mind share. At least for my own projects I have been mostly using Haskell this year, with some bit…

That's a bit of an off-topic but may I ask, why Haskell over Clojure. What are the differences? You partly asked that in the 2nd part, but I would like to know more. I never did any serious FP so would love to know where to start: Scala? Clojure(Script)? Haskell? F#?

Re: A Year of Functional Programming

#52
post #45
post #2

" Recently I looked at some code I wrote 8 months ago and was shocked! I looked at one file written in “good OO-style”, lots of inheritance and code reuse, and just thought “this is just a monoid and a bunch of crap because I didn't realise this is a monoid” so I rewrote the entire thing to about a third of the code size and ended up with double the flexibility. Shortly after I saw another file and this time thought…

If you're interested in examples of useful monoids and similar structures, you may want to have a look at the Algebird[0] project or the recent work on CRDTs[1]. The code savings in these projects comes from being able to write the complex distributed aggregation / conflict resolution / etc. code just once, and reuse it with a menagerie of useful implementations. Personally, I like structuring things using these tool…

What we want is a comparison: what was the OO code, and what did the functional code turn out to be? That way, we can judge for ourselves.

Typically, these examples take low-end crappy OO code and convert it to high-end elegant FP code. But this doesn't really convince anyone.

Re: A Year of Functional Programming

#53
post #51

Nice article! I have been using Clojure for years, initially because a repetitive customer mandated its use, later for my own projects because it reduced my development time and is fun to code in. I tried Scala (really liked Martin Odersky's Coursera class!) but it did not stick. That said, Haskell has started to win my mind share. At least for my own projects I have been mostly using Haskell this year, with some bit…

That's a bit of an off-topic but may I ask, why Haskell over Clojure. What are the differences? You partly asked that in the 2nd part, but I would like to know more. I never did any serious FP so would love to know where to start: Scala? Clojure(Script)? Haskell? F#?

Here's an article that was on the frontpage recently; some reflections from a Clojurist that switched to Haskell:

http://bitemyapp.com/posts/2014-04-29-meditations-on-learnin...

Re: A Year of Functional Programming

#54
post #7

I used to like functional programming. Now I think that it's -- more often than not -- a solution in search of a problem. I can understand some of the things FP gets you (although those come at a cost, which I'll get to later); I'm just not so sure these are the things we need, or that FP is the best solution for them. One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it…

I'm starting to think that different programming styles are more suited to different levels of abstraction - maybe you can program in an OO style at a high level, use functional style code for the low level implementation.

Re: A Year of Functional Programming

#55
post #45

Earlier quoted context omitted.

If you're interested in examples of useful monoids and similar structures, you may want to have a look at the Algebird[0] project or the recent work on CRDTs[1]. The code savings in these projects comes from being able to write the complex distributed aggregation / conflict resolution / etc. code just once, and reuse it with a menagerie of useful implementations. Personally, I like structuring things using these tool…

What we want is a comparison: what was the OO code, and what did the functional code turn out to be? That way, we can judge for ourselves. Typically, these examples take low-end crappy OO code and convert it to high-end elegant FP code. But this doesn't really convince anyone.

I don't know the OP's examples, but I think he is saying something subtly different: that he took (his own) low-end crappy OO code and converted it to high-end elegant OO code, using the insight gained from how he would have written it as FP.

Re: A Year of Functional Programming

#56
post #17

Earlier quoted context omitted.

> Combinator libraries sure are pretty useful, and they're more than small simple loops. Useful -- yes. Useful enough to pay the price -- IMO, no. OO is decent at code reuse, and the most effective, most important code reuse, is that of big libraries with rich functionality, which is done rather well in many programming paradigms (i.e. pure, statically typed FP has little to no advantage here). > Very puzzled how you…

I don't agree with your definition of FP then. Erlang is broadly the same as Clojure: pure in the small but stateful in the large (mailboxes in Erlang store state). Your basic argument seems to come down to Haskell (the only pure statically typed language with any widespread adoption) vs any other language. That's not an argument I'm particularly interested in. As for OO vs FP in combinator libraries -- the same patt…

All Erlang, Clojure, Scheme sport pretty nifty object systems, even if they don't resemble the Java kind. I find it funny when someone espouses the benefits of functional programming with...objects? On the other hand, these languages are quite pragmatic and I believe such blending is the future.

The only language that is purely FP is Haskell. It doesn't have anything that we could mistake for an object system, its functions all the way down!

Fluent interfaces should die a horrible death; it is a confusing style in OOP and quite easy to make lots of errors without the equational reasoning that supports combinators in FP.

Re: A Year of Functional Programming

#57
post #54
post #7

I used to like functional programming. Now I think that it's -- more often than not -- a solution in search of a problem. I can understand some of the things FP gets you (although those come at a cost, which I'll get to later); I'm just not so sure these are the things we need, or that FP is the best solution for them. One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it…

I'm starting to think that different programming styles are more suited to different levels of abstraction - maybe you can program in an OO style at a high level, use functional style code for the low level implementation.

"maybe you can program in an OO style at a high level, use functional style code for the low level implementation."

That's sort of the Erlang approach, right?

Re: A Year of Functional Programming

#58
Suprised that the year ended with one language and not another, particularly given his background.

This could be indicative of a "good enough" FP trend where the net affect of language authors cherry picking FP constructs does not, ironically enough, result in significantly increased adoption rates for those FP languages that are at the forefront of FP R&D.

Case in point: the recently announced Swift appears to have a decent grab bag of FP candy that will immediately appeal to legions of iThing app developers.

In short, it may be that Haskell, and particularly Scala (fending off Java 8, Kotlin, Groovy, and Clojure) will be fighting for scraps until one of them comes up with a killer stack that launches them out of niche status into the mainstream. Could be awhile yet...

Re: A Year of Functional Programming

#59

Earlier quoted context omitted.

What we want is a comparison: what was the OO code, and what did the functional code turn out to be? That way, we can judge for ourselves. Typically, these examples take low-end crappy OO code and convert it to high-end elegant FP code. But this doesn't really convince anyone.

I don't know the OP's examples, but I think he is saying something subtly different: that he took (his own) low-end crappy OO code and converted it to high-end elegant OO code, using the insight gained from how he would have written it as FP.

I didn't get that from the article, but they aren't explicit about it.

Re: A Year of Functional Programming

#60
post #17

Earlier quoted context omitted.

> Combinator libraries sure are pretty useful, and they're more than small simple loops. Useful -- yes. Useful enough to pay the price -- IMO, no. OO is decent at code reuse, and the most effective, most important code reuse, is that of big libraries with rich functionality, which is done rather well in many programming paradigms (i.e. pure, statically typed FP has little to no advantage here). > Very puzzled how you…

I don't agree with your definition of FP then. Erlang is broadly the same as Clojure: pure in the small but stateful in the large (mailboxes in Erlang store state). Your basic argument seems to come down to Haskell (the only pure statically typed language with any widespread adoption) vs any other language. That's not an argument I'm particularly interested in. As for OO vs FP in combinator libraries -- the same patt…

[deleted]
Post reply on HN