Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Mostly functional” programming does not work

queue.acm.org

Post reply on HN
Print view View original

71–80 of 205 posts

Re: “Mostly functional” programming does not work

#71

Post by coolsunglasses »

metasim wrote: post #61
coolsunglasses wrote: post #19

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…

Is your argument that deep experience in Clojure is sufficient in determining FP/OO hybridization isn't a good idea or can't be done well? I didn't think that was in the sphere of Clojure's goals.

I've used a lot of languages, including Clojure and Scala. I'm saying any time spent learning Clojure when Haskell exists is a waste of time and a half-step.

Everybody who hasn't should be learning Haskell, regardless of background.

Teaching somebody Haskell is faster than explaining why the 1,001 dumb things mainstream languages do are dumb. I don't want to waste my time explaining why null values are dropdead stupid when I can just show them "Maybe".

We can talk about where we're headed after that.

Re: “Mostly functional” programming does not work

#72

Post by coolsunglasses »

dorfsmay wrote: post #57
coolsunglasses wrote: post #19

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…

Have you completely switched to haskell now?

I've written an Elasticsearch client in Haskell just so I can port a project from Clojure.

I'm moving everything over that I can. Some legacy Clojure at work I'll have to leave alone for now, but going forward it's Haskell wherever I can.

Re: “Mostly functional” programming does not work

#73

Post by coldtea »

PaulAJ wrote: post #45
bambax wrote: 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.

Well, most of the software I depend upon everyday, and is almost rock-solid is written in C++.

So not sure where you are getting at.

Re: “Mostly functional” programming does not work

#74

Post by nhaehnle »

lostcolony wrote: post #49
nhaehnle wrote: post #43

From the article: The infix application function (ma>>=\a->f(a)), commonly called bind, executes the computation ma to expose its effects, calling the resulting value a, and passes that to function f. This is the kind of imprecise language that really made life extraordinarily difficult for me when I first learned about monads. I think this is an important point: >>= does not execute ma! If it did execute ma, that wo…

Before learning about monads in Haskell, you probably should learn a bit of Haskell first. Most tutorials assume that. So the fact that function application is lazy is assumed as prior knowledge, since any approach to learning Haskell would cover that before monads.

This has nothing to do with laziness, because laziness does not affect the semantics of a program that has bounded recursion. [0]

The problem is that the quoted part of the article is written as if the >>= operator had side-effects (whether lazy or not), and that's just plain false.

Now I agree that ordinarily, a student of Haskell has learned very early on that There Are No Side-Effects in Haskell, and should therefore not be confused. However, introductions to monads typically start out by stating that monads are how you can get side-effects in Haskell, and so they explicitly "deactivate" the No Side-Effects-assumption that students have. That's what causes the confusion.

(In fact, the moment I finally understood monads was precisely when I realized that a useful way of thinking about it is that Haskell code with monads does not have side-effects after all. This is totally obvious in hindsight, but it seems that the best way to get this point across in teaching material has yet to be found.)

[0] Obviously, this is only true in a side-effect-free language, but we're talking about Haskell here...

Re: “Mostly functional” programming does not work

#75

Post by [deleted] »

yason wrote: post #54

I think that "Mostly functional" is actually the sweet spot. Going to any extreme makes some things horribly difficult and going to another does the same for other things. So, optimally, multiple paradigms coexist in the single codebase, applied where they're most useful. Functional programming with as many immutable bits as possible is definitely a good start. I generally do that for whatever problem I'm solving: I…

[deleted]

Re: “Mostly functional” programming does not work

#76

Post by ozataman »

yason wrote: post #54

I think that "Mostly functional" is actually the sweet spot. Going to any extreme makes some things horribly difficult and going to another does the same for other things. So, optimally, multiple paradigms coexist in the single codebase, applied where they're most useful. Functional programming with as many immutable bits as possible is definitely a good start. I generally do that for whatever problem I'm solving: I…

Please note that this is pretty much how you model Haskell programs as well: Keep as much of your logic as possible in pure code and interface/drive that with imperatively written stateful code. Purely functional languages (e.g. Haskell) do not remove your ability to code imperatively, they rather augment it so that you can better reason with it while doing it. Things like first class IO actions (that you can pass around) and explicitly marked state (i.e it's clear what you have in context and what you don't) make for some pretty satisfying solutions you wow yourself with.

It is common to hear in the Haskell community remarks like "Haskell is the best imperative language I've used."

Re: “Mostly functional” programming does not work

#77

Post by PaulAJ »

userbinator wrote: post #24
PaulAJ wrote: 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…

For instance, in Haskell a value is a value. If I have a value of type Integer then it definitely exists; if I want to say that it might not exist then I use the type "Maybe Integer", which expresses that idea precisely.

Same goes for a value of type Employee; if I might or might not have an Employee (for instance, if the lookup function doesn't find someone with that employee number) then I have to use Maybe Employee.

Scala has the same concept with (IIRC) the Option type. But Scala also inherits null references from Java. In Java a reference to an Employee might be an optional value (so null is allowed) or it might be a required value (so null is not allowed). Scala has to play well with Java so anything has to be allowed to be a null reference. Except that Integers in Java (and hence Scala) aren't references, so I can't have a null reference to an Integer.

So now my "Option Employee" might wind up being a null reference to the Option, or it might be an Option that is empty, or it might be an Option that contains a null reference to the Employee, or it might actually have an Employee in it.

Gahh.

Re: “Mostly functional” programming does not work

#78

Post by PaulAJ »

overgard wrote: post #69

So many weasel words and strawmen in this article. > Recently, many are touting "nearly functional programming" and "limited side effects" as the perfect weapons against the new elephants in the room: concurrency and parallelism. Who is this "many", and when did they say it was "perfect". I think the premise is silly too. Even if you don't get the full benefit of functional programming without a hardcore functional l…

The problem is that the languages don't limit the side effects; they leave that to the programmer.

Re: “Mostly functional” programming does not work

#79

Post by coldtea »

PaulAJ wrote: post #56
Amadiro wrote: post #18

Earlier quoted context omitted.

And just what makes you think making a purely functional language 'lambdacious' will not a few years later result in a book 'Industrial strength lambdacious'? You're falling for the trap of thinking that pursuing a theoretically pure discipline will result in a language with less flaws; in reality, even theoretically pure concepts have issues and can be superior and inferior to other theoretical concepts/constructs […

Quote: "You call 'Aversion to Extremes' a cognitive bias [... but] the more extreme a language pursues a theoretical concepts, the less used it typically ends up being in practice." Yes, people use languages with solid theoretical foundations less because they perceive them to be extreme. That was my point. Quote: "I can't imagine [... any measure that] makes these 'purity-oriented' languages appear to "work better i…

>Yes, people use languages with solid theoretical foundations less because they perceive them to be extreme. That was my point.

At some point it stops beings the people's problem and its a problem of the language?

Or do we know (by divine intuition?) that those languages are perfect, and we don't need any stinking reality to verify it?

Re: “Mostly functional” programming does not work

#80

Post by pron »

PaulAJ wrote: post #11
_random_ wrote: post #2

I am not sure what I am doing wrong, but using functional techniques improved my C# quite a lot.

Its an example of the "blub paradox": if you haven't used a pure functional language then its hard to see what the problem is. The crucial thing about pure functional languages is that they decouple the logic of the program from the order of the computation. In an imperative language control flow and data flow are explicitly interleaved, with complex dependencies between the two. In many cases a particular bit of cod…

> Its an example of the "blub paradox": if you haven't used a pure functional language then its hard to see what the problem is.

Well, if a problem is so hard to see, maybe the solution to it is not all that important...

Like I said in another comment, I certainly believe that handling shared mutable state is a problem, but I certainly don't think pure functional programming is the only solution (in fact, I don't think it's a solution at all).

Post reply on HN