“Mostly functional” programming does not work • Hacker News Board

Re: “Mostly functional” programming does not work

#81

Post by metasim » Sun, Apr 27, 2014, 2:28 PM UTC

MichaelGG wrote: post #52

userbinator wrote: post #37

The average programmer would [...] because that's the way the program was written, as evidenced by the semicolon between the two statements. Seriously? I don't even know C# and the "var q0" was enough to suggest the type of whatever Where returns is not an array of int (as opposed to the two functions above, with int and bool types), so why would I expect it to have filtered the array and returned it? Ditto for the 2…

It is possible that Erik has a better (or more cynical) idea of the "average programmer" than you or I might. I'm of the opinion that so long it makes sense and has an elegance to it, then it's fine. If "average" programmers can't handle it, they can use another language or something.

I can't substantiate this, but my sense is that the generation of general-purpose, non-academic programming languages C++ lowered the barrier to writing software in the industrial context (think VB.Net, etc.). This can be seen as a good thing in these business contexts, but for those who are driven to be deeper and more concise in their problem solving, and are interested in solving more challenging problems, are only starting to realize that we've not been expecting enough out of our languages and compilers. Furthermore, the last two decades of software tool development have gained "lowest common denominator" accessibility at the cost of "dumbing down" the ways we generalists think about and solve problems. The first thing that picking up Scala did for me was realize I was expecting way too little from the compilers I use. Why should I be figuring out what the damn type of a value should be (while not throwing out types all together)!?!

Since Meijer is as an employee of Microsoft I'd extrapolate to say he's heavily influenced in his experience of the "average programmer" by the primary clients of his company.

Re: “Mostly functional” programming does not work

#82

Post by Chattered » Sun, Apr 27, 2014, 2:29 PM UTC

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…

Indeed. Consider:

Nothing >>= \a -> f a

Here, there is no "a" and there never will be, and I could even annotate the type of "a" with something which can never be inhabited (such as Void).

Re: “Mostly functional” programming does not work

#83

Post by _halgari » Sun, Apr 27, 2014, 2:32 PM UTC

coolsunglasses wrote: post #71

metasim wrote: post #61

Earlier quoted context omitted.

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

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 saying "You're not doing it right!!!"

Re: “Mostly functional” programming does not work

#84

Post by danenania » Sun, Apr 27, 2014, 2:33 PM UTC

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…

I agree with you in general about 'mostly functional' being a sweet spot, but I think there's also lots of room for pure functions and immutability in ui programming without bending over backward too much.

For example, rather than creating a big oo hierarchy to model a ui, you can describe it declaratively as immutable data, then transform it with chains of pure and semi-pure functions whose only ultimate side effects are updating whatever bits of state absolutely must be held onto (ideally not much) and rendering the ui. I think that qualifies as 'mostly functional' even though it's not totally pure and doesn't use monads or other advanced constructs.

I haven't yet toyed with react.js, but I believe it takes an approach similar to this.

Re: “Mostly functional” programming does not work

#85

Post by leoc » Sun, Apr 27, 2014, 2:34 PM UTC

Kutta wrote: post #35

I disagree with some of the sentiment expressed in the article; mostly functional programming works much better than profoundly non-functional code, and more functional programming usually delivers marginal benefits. The fact that effects can be used to simulate other effects does not imply that programmers would typically try doing that. In fact, programming style is more often shaped by trivial inconveniences (ofte…

It's an obviously silly exaggeration: what, did MacLISP, Scheme or Standard ML not exist? It's not as if Erik Meijer has the excuse of never having heard of them...

Re: “Mostly functional” programming does not work

#86

Post by caughtexception » Sun, Apr 27, 2014, 2:34 PM UTC

coolsunglasses wrote: post #19

cynicalkane wrote: post #7

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…

> Learn Haskell properly and then see for yourself why "hybrids" are a waste of time.

/rant

Getting tired of puritans. You people are selling functional programming on the basis of "ideology", not merits.

Can the following be done in Haskell ?

* A Real Operating System.

* GPU programming.

* Embedded programming.

* If you can do all the above, can you replace Verilog ?

* Financial Programming.

  Ocaml is one of the "hybrids". Genetically impure,
  since it has "refs". But they have Jane Street.

* Games worth playing.

  assertion : If all the haskell programmers are put in
  a gulag, they can't come up with a half-decent
  game. 
  
  Nintendo Gameboy Games were written in assembly with 
  goto's. 

  Why don't you guys take a moment and pat yourselves on
  the back ? Hypocrisy-2.0 is probably in the hackage.

Let's say you do all the above, GUI apps, distributed computing, ... without complains and ending up as a half-decent C++ or 1/10th lisp.

Haskell syntax is garbage.

(Common Lisp has a goto, gee what were they thinking ?)

Mathematicians pride themselves in their rich history of syntax.

Haskellers actually type "Arrow".

"I do consider assignment statements and pointer variables to be among computer science's most valuable treasures."

-- Only an Idiot could say that.

Re: “Mostly functional” programming does not work

#87

Post by coolsunglasses » Sun, Apr 27, 2014, 2:37 PM UTC

_halgari wrote: post #83

coolsunglasses wrote: post #71

Earlier quoted context omitted.

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

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 Parsec. Parsec has been preeminent parser-combinator library since forever.

Also: pugs, pandoc, gitit, Darcs, xmonad, Idris (same person that did whitespace, haha)

Recently? Cryptol. That's pretty major.

I'm building stuff in Haskell, right now. Specifically, the easiest to use Elasticsearch client in the world.

One was needed. Badly. The ES API's data structures were never specced out properly, just documented on an ad-hoc basis. The Haskell library I'm working on will, if nothing else, mean that there's a reference for how the JSON is structured.

Anyway, empower thyself, learn some Haskell: https://gist.github.com/bitemyapp/8739525

Edit:

Ah, I thought I knew that username from somewhere. The negative-nancy is Timothy Baldridge, an employee of Rich Hickey's company Cognitect. Cognitect is "the" Clojure company and represents the inner-clique.

Re: “Mostly functional” programming does not work

#88

Post by userbinator » Sun, Apr 27, 2014, 2:37 PM UTC

MichaelGG wrote: post #52

userbinator wrote: post #37

The average programmer would [...] because that's the way the program was written, as evidenced by the semicolon between the two statements. Seriously? I don't even know C# and the "var q0" was enough to suggest the type of whatever Where returns is not an array of int (as opposed to the two functions above, with int and bool types), so why would I expect it to have filtered the array and returned it? Ditto for the 2…

It is possible that Erik has a better (or more cynical) idea of the "average programmer" than you or I might. I'm of the opinion that so long it makes sense and has an elegance to it, then it's fine. If "average" programmers can't handle it, they can use another language or something.

I think his idea of "programmer" is closer to "mathematician" --- and indeed if you think in that manner, functional programming looks perfectly natural and obvious. The problem is how many of the programmers - and by that, I mean anyone who writes instructions for a machine - actually do think like mathematicians; and in my experience, not as many as the ones who can easily grasp the sequential, imperative model of machine execution. Not to say that thinking of computation as a function that takes an input state and produces an output state is conceptually interesting, but I think that's a bit too abstract for a lot of people.

Re: “Mostly functional” programming does not work

#89

Post by eranation » Sun, Apr 27, 2014, 2:39 PM UTC

Just an observation, Erik was one of the lecturers in the coursera course "Introduction to reactive programming" co taught by Martin Odersky, creator of Scala. Erik was teaching reactive extensions to Scala (a port based of his work at Microsoft). Course is highly recommended by the way.

Re: “Mostly functional” programming does not work

#90

Post by rapala » Sun, Apr 27, 2014, 2:42 PM UTC

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.

The semantics of >>= do not depend on the laziness of the language. >>= behaves exactly the same in Scala (although it's called flatMap there) as it does in Haskell. >>= does not execute effects, it only composes them. So to correct the article:

The infix application function (ma>>=\a->f(a)), commonly called bind, composes two computations. When the resulting computation is executed, ma is executed first, f is called with its result and finally the computation returned by f is executed.