Live data from Hacker News

“Mostly functional” programming does not work

queue.acm.org

111–120 of 205 posts

Re: “Mostly functional” programming does not work

#111

I would just like to point out that the author seems to be confusing Pure-Functional-Lazy with just Functional. I absolutely agree that if you buy into Lazy programming, you have to buy into entirely Pure Functional as well. However, many languages and frameworks have demonstrated a high degree of success mixing in functional paradigms (mostly centered around collections) I would like to refer people to the concept o…

He isn't confusing the terms, he's just using the correct one.

Functional programming is about programming with functions - "Purely functional" is redundant. It should be obvious that Functional means functions, and "function" has fairly precise meaning which predates computation, and certainly didn't include anything about side-effects. Languages which don't use functions are not functional - they would be best described as psuedo-functional, nearly-functional, or mostly-functional, as he uses in the article title.

The only reason we've had to invent new terms like "purely functional" is because the original term has been abused to mean what it never meant - it was used to describe psuedo-functional languages, so we needed a new term to distinguish the two.

Re: “Mostly functional” programming does not work

#112

Earlier quoted context omitted.

How about Clojure, which is a Lisp-like language with objects? Explicitly, you have protocols and multimethods; implicitly, almost everything under the hood is done with Java interfaces (and you can make new first-class datatypes by implementing the interfaces, though this is mildly discouraged). I cannot recall anyone complaining about the OO clashing with the functional patterns. There's also O'Haskell, and in regu…

I'm an experienced Clojure user with work done on the job and in open source. If you're a Clojure user, it's very likely you've used a library I've worked on or made. Don't bother. Go straight to Haskell and just Haskell. No excuses, no compromises, no mental backflips to justify not learning something new. Learn Haskell properly and then see for yourself why "hybrids" are a waste of time. Hybridized approaches are l…

I spent a couple of years using Haskell, but a few months after I started using Clojure I've switched over to using it pretty much exclusively.

I certainly didn't find Clojure to be a waste of time; to my mind it's a far more practically-minded language. It's philosophy of decoupling components is also interesting. For example, in Haskell, the static type system is coupled to the language; in Clojure, the static type system is an optional library.

Re: “Mostly functional” programming does not work

#113
I think, this is a marketing article (the author is working as a consultant now). With all due respect to Erik Meijer for his contribution to functional programming, this article disseminates FUD that you are using functional features of programming languages incorrectly.

In my experience, using imperative programming with elements of functional, is very productive, and I don't need to introduce monads everywhere to be more productive. Separating side effects, and making code as pure as possible, was a good practice in old style OO programming and will be so in the future, and introducing smart-sounding words for this which most of the readers don't understand (BTW, I do understand what monad is), is just a marketing trick.

Re: “Mostly functional” programming does not work

#114

Earlier quoted context omitted.

I find it funny to hear such grandiose claims about a language that can has yet to create a major killer project. That's why I can never bring myself to write Haskell. Show me the Storm, OTP, Datomic, Netflix, Whatsapp, etc. written in Haskell and perhaps I'll have a reason to change my mind. But until then all I see is C#, Scala, Erlang and Clojure shipping awesome products and the Haskell guys sitting in the corner…

Haskell's community is a bit more thoughtful and less prone to self-promotion. That combined with the fact that you're not a Haskeller, you're not familiar with what they've built. Another issue is that Haskell is somewhat weighted towards finance and they're a bunch that tends to be somewhat proprietary about their IP. Some exceptions (Ermine) exist. Some notable projects that come to mind include git-annex and Pars…

> xmonad is stable.

> haskell + smart programming practices guarantee a crash

> free experience.

Yeah dwm, crashes all the time.

Why don't you try another approach to functional programming, like http://www.shenlanguage.org/ ?

If you think Haskell is The One True Way™, get a new pair of sun glasses.

Re: “Mostly functional” programming does not work

#115
post #5

The software engineering world is in danger of repeating the mistake it made with objects two decades ago. Back then there were legacy "structured" languages like C and Ada, and new exciting "object oriented" languages like Smalltalk and Eiffel. C++ was promoted as a "middle way" that let you "choose the best tool for the job". This made the pure OO languages look extremist. So, it was argued, if you had a problem be…

> And its going to fail for the same reasons that C++ failed C++ "failed"? > the OO and functional features don't interact well How don't they? Before C++ had lambdas, programmers would define a class with overloaded operator() and use that instead, every time. Now the language provides a way to easily generate the class with its members and constructor and operator() automatically - which is basically what functiona…

Just to cite a few quick examples.

If you have a mutable object anywhere in your codebase, the compiler can not reuse calculated values, ignore unneeded code, or map a set of independent output sequences[1] at your source code into highly interleaved single threaded asynchronous output, like Haskell's green threads do.

[1] I'm yet to see an imperative language (and "mostly functional" is imperative) that has the concept of "output sequence", instead of "execution sequence", but I don't know enough to claim it's impossible.

Re: “Mostly functional” programming does not work

#116

Earlier quoted context omitted.

How about Clojure, which is a Lisp-like language with objects? Explicitly, you have protocols and multimethods; implicitly, almost everything under the hood is done with Java interfaces (and you can make new first-class datatypes by implementing the interfaces, though this is mildly discouraged). I cannot recall anyone complaining about the OO clashing with the functional patterns. There's also O'Haskell, and in regu…

I'm an experienced Clojure user with work done on the job and in open source. If you're a Clojure user, it's very likely you've used a library I've worked on or made. Don't bother. Go straight to Haskell and just Haskell. No excuses, no compromises, no mental backflips to justify not learning something new. Learn Haskell properly and then see for yourself why "hybrids" are a waste of time. Hybridized approaches are l…

I find your rant slightly insulting, off-topic, and lacks substantial information. "Learn Haskell because I say so." Why? No.

But let me do something you didn't do, which is to actually explain my position. Hybrid languages afford a flexibility and power not available to language puritans. It's very nice to have things first-class DSLs that don't rely on slow monad stacks, heterogeneous lists that don't rely on existential qualification, stateful programming that isn't a type system hack (do I really need to understand existential uninstantiated types to twiddle a bit in a vector?), first-class side-effects without monad stack weirdness (unsafe escapes don't count), Turing-complete macros at load time, inheritance and class qualification that isn't crippling and/or dependent on weird compiler extensions... In the course of learning Haskell I find myself banging my head against a type-system wall to do something that would be trivial in Clojure or Scala.

Now I like Haskell, but Clojure and even Scala offer very flexible and powerful defaults together with programming escape hatches anywhere you want them. This is very powerful. It's not clear how to have a similar in a strongly typed strict language. Monads and weird compiler extensions don't cut it.

Re: “Mostly functional” programming does not work

#117
post #97

I am going to take the apparently unique position here (after 90 comments) that Erik is correct, at least about pure functional programming (the more modern sense of "functional" rather than the older one that is "merely" about first-class function objects). The value of pure functional programming comes from creating programs out of very mathematically-small pieces... a function of Int -> Int can only do so many thi…

Now that I've read your post, I'd say that impurity is much more similar to "goto" than with object orientation.

A language with "goto" is not structured. It does not matter how often it's used, or how similar the rest of the language is to a structured one. The same is true for side effects.

(Funny thing that the most used language has both.)

Re: “Mostly functional” programming does not work

#118
post #45
post #36

Earlier quoted context omitted.

Of course C++ didn't fail in the sense that it would lack popularity; I think the parent meant that C++ is a complex, horrible mess and that it failed in the "beauty contest" sense. It also failed in the sense that it didn't eliminate all competition.

Yes, that is what I meant. Thanks for the clarification, although I think the term "beauty contest" trivialises the issue. Its not about beauty, its about buggy software.

"Its not about beauty, its about buggy software."

In the vast majority of cases, it's about delivering customer value--whether through good, buggy, or nonexistent software.

A buggy language used to make buggy software beats a perfect solution every time if it gets you paid.

EDIT:

Downvote all you'd like; in the vast majority of cases the pain point of a customer getting solved is what matters, not how we solve it.

Re: “Mostly functional” programming does not work

#119

Earlier quoted context omitted.

I'm an experienced Clojure user with work done on the job and in open source. If you're a Clojure user, it's very likely you've used a library I've worked on or made. Don't bother. Go straight to Haskell and just Haskell. No excuses, no compromises, no mental backflips to justify not learning something new. Learn Haskell properly and then see for yourself why "hybrids" are a waste of time. Hybridized approaches are l…

I find your rant slightly insulting, off-topic, and lacks substantial information. "Learn Haskell because I say so." Why? No. But let me do something you didn't do, which is to actually explain my position. Hybrid languages afford a flexibility and power not available to language puritans. It's very nice to have things first-class DSLs that don't rely on slow monad stacks, heterogeneous lists that don't rely on exist…

I am fed up with these "pure" people.

They have hijacked every sane discussion about programming into a condescending -- "Do you have monads and typeclasses ?".

It's absolutely unhealthy.

State is not Evil.

Languages like clojure, scheme take imperative features and give it more beautiful abstractions.

In what profession, do you find people complaining about the very foundations and thinking it's cool ? It's like Musicians saying Rhythm is stupid.

If you haven't written a State Machine with goto's and never marvelled at it's beauty ... please just try it.

Re: “Mostly functional” programming does not work

#120

Earlier quoted context omitted.

I find it funny to hear such grandiose claims about a language that can has yet to create a major killer project. That's why I can never bring myself to write Haskell. Show me the Storm, OTP, Datomic, Netflix, Whatsapp, etc. written in Haskell and perhaps I'll have a reason to change my mind. But until then all I see is C#, Scala, Erlang and Clojure shipping awesome products and the Haskell guys sitting in the corner…

Haskell's community is a bit more thoughtful and less prone to self-promotion. That combined with the fact that you're not a Haskeller, you're not familiar with what they've built. Another issue is that Haskell is somewhat weighted towards finance and they're a bunch that tends to be somewhat proprietary about their IP. Some exceptions (Ermine) exist. Some notable projects that come to mind include git-annex and Pars…

"That combined with the fact that you're not a Haskeller, you're not familiar with what they've built."

On the other hand, I don't have to be a php'r to know facebook was built in that language or a C++ programmer to know what google has done with it.

The negative-nancy is Timothy Baldridge, an employee of Rich Hickey's company Cognitect.

By personally attacking a critic of your claims, you're only making your case weaker.

Post reply on HN