Reflecting on Haskell in 2015 • Hacker News Board

Re: Reflecting on Haskell in 2015

#91

Post by mbrock » Sat, Dec 19, 2015, 12:18 PM UTC

saosebastiao wrote: post #21

onesixtythree wrote: post #4

Earlier quoted context omitted.

I like Haskell but I see no future in terms of widespread adoption for it. The aim isn't necessarily widespread adoption, so much as the ability for people who know it to use professionally. It's way past merely "production ready", but reputation is a lagging indicator and so most programmers are stuck doing Java... Since the goal is to avoid {success at all costs}, getting 25% market share is probably not possible.…

> The problem, economically speaking, is that Haskell and Clojure engineers are massively underpaid, when you consider that an average Haskeller would be Principal+ at any Java shop. That's because the Java and C++ people can create bidding wars every year and spike their salaries, whereas using a better but more niche language makes that career strategy untenable. I haven't found the same to be true for other langua…

I don't know who the average Haskeller is, but your description doesn't fit any of the engineers I worked with at Silk, who were all very pragmatic and got stuff done quickly.

Re: Reflecting on Haskell in 2015

#92

Post by kqr » Sat, Dec 19, 2015, 12:22 PM UTC

jrochkind1 wrote: post #59

> Avoiding success at all costs takes time... Uh?

Originally spoken as "Avoid (success at all costs)", i.e. don't sacrifice your principles just to get your 15 seconds on the stage. Now sometimes used as a joke in the alternate meaning.

Re: Reflecting on Haskell in 2015

#93

Post by cousin_it » Sat, Dec 19, 2015, 1:35 PM UTC

kqr wrote: post #90

cousin_it wrote: post #86

Earlier quoted context omitted.

As a first language, I think Haskell is too safe. It forbids you from doing too many things that the computer can do. I recently talked to someone who was learning Haskell as a first language, and it was a surreal experience. It was obvious that he wasn't having fun in the sandbox, but he couldn't articulate it because he'd never been outside the sandbox. My own first language was QBasic and I'm very happy about it.…

> Haskell is too safe. It forbids you from doing too many things that the computer can do. Computers are to computing science what telescopes are to astronomy, or something. Haskell is a great language for expressing computations, the thing CS is about. It's not meant to flip bits and observe processor states and page faults, if that is your idea of fun. That's more computer engineering stuff. But Haskell is absolute…

> Haskell is a great language for expressing computations, the thing CS is about.

I think Haskell is good at expressing a narrow range of ideas that, honestly, aren't all that fruitful outside the FP field. There are three main reasons why it's not a great language for expressing arbitrary algorithms:

1) It uses the pointer model instead of the integer RAM model. That leads to extra logarithmic factors.

2) Immutability. That's hypothesized to also cause extra logarithmic factors, but AFAIK that's still an open problem.

3) Non-strict evaluation. That wreaks havoc with space complexity, and compositional analysis of performance in general.

Yes, you can add epicycles to remedy these drawbacks (arrays, ST, strictness annotations). But I'd rather use a C-like language in the first place. That's closer to the "core" of CS as I understand it, and that's how most algorithm research is done.

Re: Reflecting on Haskell in 2015

#94

Post by kqr » Sat, Dec 19, 2015, 4:00 PM UTC

jasperry wrote: post #47

chrisseaton wrote: post #35

Earlier quoted context omitted.

For me all the extensions and abstractions induce a kind of choice paralysis, and fear that my program isn't abstracted far enough. I don't feel that when working in C, Java or Ruby.

That captures my feelings really well. And then I think that if I'm going to stick to the "meat and potatoes" of functional programming, I might as well just use a language in the ML family.

Except controlled side effects are a godsend, even for meat and potatoes.

Re: Reflecting on Haskell in 2015

#95

Post by kqr » Sat, Dec 19, 2015, 4:09 PM UTC

cousin_it wrote: post #93

kqr wrote: post #90

Earlier quoted context omitted.

> Haskell is too safe. It forbids you from doing too many things that the computer can do. Computers are to computing science what telescopes are to astronomy, or something. Haskell is a great language for expressing computations, the thing CS is about. It's not meant to flip bits and observe processor states and page faults, if that is your idea of fun. That's more computer engineering stuff. But Haskell is absolute…

> Haskell is a great language for expressing computations, the thing CS is about. I think Haskell is good at expressing a narrow range of ideas that, honestly, aren't all that fruitful outside the FP field. There are three main reasons why it's not a great language for expressing arbitrary algorithms: 1) It uses the pointer model instead of the integer RAM model. That leads to extra logarithmic factors. 2) Immutabili…

All three are problems with performance on a von Neumann machine. So there are three main reasons why Haskell is not a great language for expressing high-performance computation algorithms. Since CS is a branch of maths, performance isn't that big a deal; the important thing is that the result is computable. The performance may be an interesting property, but so is line count and purity and ease of writing proofs and doing analysis on the code!

Speaking more pragmatically, outside of CS study, most of the programs I write do not require me to write high-performance algorithms – they tend to be very I/O bound, and call out to external libraries/services for the data crunching. When I need performance (because of course I do at times), there is an amazing library that lets me write C code in Haskell[1]. The fact that some sections of my program is performance critical doesn't mean I have to write the entire program in C. I can write just the performance critical parts in C.

[1]: https://github.com/fpco/inline-c/blob/master/README.md

Re: Reflecting on Haskell in 2015

#96

Post by incepted » Sat, Dec 19, 2015, 4:18 PM UTC

LukeHoersten wrote: post #3

armitron wrote: post #2

I like Haskell but I see no future in terms of widespread adoption for it. It's simply too alien for your typical CS grad and for some projects one would like to use it for (let's say security critical), laziness (and non-predictable behavior in terms of memory use and performance) is a big problem. We do however see some of its features being slowly introduced to other languages which is nice, I guess.

Haskell's learning curve is certainly steeper than other popular general programming languages. But my view on that is best explained with an analogy: calculus is certainly harder to learn than arithmetic approximations but once learned, the complexity of calculus is factored out of all the problems suited for solving with it. Haskell is excellently suited for solving extremely complex problems and why it's so desira…

> Haskell is excellently suited for solving extremely complex problems and why it's so desirable for concurrency and parallelism tasks.

As is the JVM (and most languages running on it). Not only that, but the JVM has actually a proven track record of being good and performant at it. And you can solve these problems with pretty much the language of your choice.

What makes you think Haskell is well suited for it? Immutability? This is available in a lot of languages (and for languages where it's not enforced, simple programmer discipline and code reviews address it).

Re: Reflecting on Haskell in 2015

#97

Post by incepted » Sat, Dec 19, 2015, 4:20 PM UTC

thetmkay wrote: post #5

armitron wrote: post #2

I like Haskell but I see no future in terms of widespread adoption for it. It's simply too alien for your typical CS grad and for some projects one would like to use it for (let's say security critical), laziness (and non-predictable behavior in terms of memory use and performance) is a big problem. We do however see some of its features being slowly introduced to other languages which is nice, I guess.

> It's simply too alien for your typical CS grad In my university, Programming 101 (mandatory) was (and is) Haskell. For context, there is typically a mix of experience among the class - some will have programmed seriously before, but others will have only studied math. I had already studied Java, but I found Haskell a delightful re-introduction (it was my first exposure to functional programming) and I see its value…

> In my university, Programming 101 (mandatory) was (and is) Haskell.

I don't think it's a good idea because it might discourage a lot of students from the get go and they might simply drop out.

It's well established today that the language you start with has little impact on your mastery of the field years later (most of us started with BASIC I bet), so you might as well start with an easy language that will get people hooked.

If the students are curious and talented, they will move on to more complex things with time.

Re: Reflecting on Haskell in 2015

#98

Post by progman » Sat, Dec 19, 2015, 4:27 PM UTC

LukeHoersten wrote: post #3

armitron wrote: post #2

I like Haskell but I see no future in terms of widespread adoption for it. It's simply too alien for your typical CS grad and for some projects one would like to use it for (let's say security critical), laziness (and non-predictable behavior in terms of memory use and performance) is a big problem. We do however see some of its features being slowly introduced to other languages which is nice, I guess.

Haskell's learning curve is certainly steeper than other popular general programming languages. But my view on that is best explained with an analogy: calculus is certainly harder to learn than arithmetic approximations but once learned, the complexity of calculus is factored out of all the problems suited for solving with it. Haskell is excellently suited for solving extremely complex problems and why it's so desira…

> Haskell is excellently suited for solving extremely complex problems

I doubt that seriously. Could you write a complete Mars landing project in Haskell for instance? That would impress me. That's the area where Ada excels, or (less impressive) C and FramaC. But Haskell? No way.

AFAIK there is not one serious large project written in Haskell There is not even one sophisticated Haskell IDE for daily use written in Haskell (excuse me Leksah). Tell me if I am wrong, and if there actually are really big Haskell projects. Please don't listen compilers, they are not really complex.

The only advantage which Haskell actually has in comparison to other modern languages is its greatest disadvantage. The overall rock solid type safety of the whole application makes it very difficult to add additional unpredicted functionality which requires a significant change in many modules (where on the other hand the type system helps a lot). I am very impressed by the efforts and the implementations of Haskell but the simple fact that the Cabal hell -- for the simple job of a basic package manager -- lasted for years reveals that Haskell is not that practical after all.

I invested a lot of time to learn Haskell to use it seriously but after I switched to Nim (nim-lang.org) I realized how easy I can get real productivity.

Re: Reflecting on Haskell in 2015

#99

Post by vu3rdd » Sat, Dec 19, 2015, 4:58 PM UTC

kqr wrote: post #94

jasperry wrote: post #47

Earlier quoted context omitted.

That captures my feelings really well. And then I think that if I'm going to stick to the "meat and potatoes" of functional programming, I might as well just use a language in the ML family.

Except controlled side effects are a godsend, even for meat and potatoes.

Yes, indeed. Even with the 101 level haskell I write, it feels so right. I exactly know where the side effects are and the semantics of the program is so clear.

Re: Reflecting on Haskell in 2015

#100

Post by cousin_it » Sat, Dec 19, 2015, 7:25 PM UTC

kqr wrote: post #95

cousin_it wrote: post #93

Earlier quoted context omitted.

> Haskell is a great language for expressing computations, the thing CS is about. I think Haskell is good at expressing a narrow range of ideas that, honestly, aren't all that fruitful outside the FP field. There are three main reasons why it's not a great language for expressing arbitrary algorithms: 1) It uses the pointer model instead of the integer RAM model. That leads to extra logarithmic factors. 2) Immutabili…

All three are problems with performance on a von Neumann machine. So there are three main reasons why Haskell is not a great language for expressing high-performance computation algorithms. Since CS is a branch of maths, performance isn't that big a deal; the important thing is that the result is computable. The performance may be an interesting property, but so is line count and purity and ease of writing proofs and…

Um, CS is totally about performance. Frigging P vs NP is about performance. Sure, there's a part that deals with computability and the halting problem, but I'm not sure Haskell is especially useful for studying that either! It can't even express the notion of "dovetailing over all possible programs" very easily :-)

Out of curiosity, what kind of CS do you mostly work with? If it falls under the umbrella of Curry-Howard, then sure, I agree with you. But CS has tons of other areas like graphics, crypto, AI... The impact of Curry-Howard related ideas on these areas has been disappointingly small, IMO.