Is Haskell the Cure? • Hacker News Board

Re: Is Haskell the Cure?

#51

Post by T_S_ » Mon, Oct 03, 2011, 4:35 PM UTC

The ecosystem for Haskell is improving rapidly. My startup built a computer vision application on top of easyVision and with the intention of rewriting it in ObjC. Instead we are working with the Haskell community to target the mobile platform. A year ago that would have been a dicey bet.

About our Haskell experience: Yes, the learning curve seems steep, but mainly because of the things you have to unlearn (OMG no for-loops!). However, functions are the most modular things ever invented. That translates into an uncanny ability to add features quickly. A sophisticated type system catches many errors at compile time.

Re: Is Haskell the Cure?

#52

Post by anothermachine » Mon, Oct 03, 2011, 4:36 PM UTC

microtonal wrote: post #19

MatthewPhillips wrote: post #14

Earlier quoted context omitted.

Did you perhaps jump into the water too quickly? I'm currently learning a couple of functional languages (including Haskell) and using it in production environments but my current use is restricted to "I have an input that will always produce a certain output. There are no database or environmental dependencies, this is straight computation. I want to never have to worry about this function ever again". And so far, k…

Haskell is beautiful, I love it, but I can easily see his points. There are a few traps one can easily fall in: - Reach a point in a complex application where it becomes hard to reason what laziness will do to performance. - End up in type-hell. E.g. some libraries extensively use existential quantification of type variables. Before you know it, you are chasing "type variable x would escape its scope"-type or error m…

> Artificially pure packages. There are some packages that link to C libraries, but (forcefully) provide a pure interface. (Or in other words: purity is just convention)

Explain? What would the alternative be?

> Using functions with worse time or space complexity, to maintain purity.

This seems like the opposite of your previous complaint.

> For a lot of code you end up using monads plus 'do' notation, making your programs look practically imperative, but an oddball variation of it.

This seems to be a "psychological problem" with Haskell: the idea that because Haskell supports declarative, it's not OK to be imperative. It makes beginners tear their hair out looking for 'do'-free solutions when they could just use 'do'. C.f., "Lambda: the Ultimate Imperative" (and the rest of that series of LtU papers) http://dspace.mit.edu/handle/1721.1/5790

Re: Is Haskell the Cure?

#53

Post by Peaker » Mon, Oct 03, 2011, 4:39 PM UTC

Someone wrote: post #39

Peaker wrote: post #6

It is somewhat of a shame that learning curve plays such a significant role for career programmers. You would expect that people that spend years and years working with their tools would be willing to put a few weeks or months into learning their most important tool: the programming language. It seems most programmers get frustrated and abandon learning of different programming paradigms very quickly.

The problem is not why one "would be willing to put a few weeks or months into learning their most important tool", but why one would be willing to put a few weeks or months into learning the next silver bullet, and repeat that two or three times a year. Experienced developers have learned that, typically, newer languages are better than older ones, but they typically do not get better by leaps and bounds across the…

I don't think anyone has been advocating any programming language as the "next silver bullet".

Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn.

Additionally, Haskell isn't a new little "fad" language. It is a pretty old research effort that accumulated many novel and useful ideas that are worth learning. I understand someone who knows Python and does not think learning Perl/Ruby/Lua will teach him anything substantial/new. But I think even a cursory look at Haskell will remove any doubt about whether it contains novel ideas to learn.

Learning about programming languages enriches you as a programmer, and I can't imagine spending a few weeks learning novel languages and the reward not far-outweighing the costs.

Re: Is Haskell the Cure?

#54

Post by lobster_johnson » Mon, Oct 03, 2011, 4:45 PM UTC

gvb wrote: post #32

Why is a Fibonacci sequence used as a benchmark for an argument for concurrent programming? The Fibonacci sequence is a recursive algorithm that inherently has dependencies on previous calculations that prevent effective concurrent execution. The Fibonacci algorithm executed concurrently is going to spend an inordinate amount of time creating tasks that do a trivial calculation (add two numbers together). If you want…

He was not benchmarking concurrency, he was pointing out that Node is single-threaded system that essentially implements the old-style cooperative multitasking, where a single task will block everything else. He could have used sleep() and it would have illustrated the same point (and more elegantly, since half of the responses miss the point entirely and focus on the Fibonacci part).

Node developers probably don't do a lot of computationally complex stuff, but when they do, they have to think about the concurrency problem. Even something as trivial as sorting a large list or parsing a huge chunk of JSON is going to stop all other requests from executing.

Re: Is Haskell the Cure?

#55

Post by eru » Mon, Oct 03, 2011, 5:00 PM UTC

microtonal wrote: post #35

gregwebs wrote: post #26

Earlier quoted context omitted.

I believe you are attributing a library issue to a language. Before today (and by today I literally mean a month ago when Yesod released a cross-platform development server that automatically re-compiles your web application) there wasn't a productive set of libraries and tools to build a web application with in Haskell. 3 years ago when you started, and even until 1-2 years ago the library situation was absolutely h…

I believe you are attributing a library issue to a language. Reasoning about laziness? Polymorphism that can only be implemented using existential types plus Typable? Even purity is a double-edged sword (some algorithms are inherently mutable)[1]. Some of Haskell's problems in real-life projects can definitely be attributed to the language itself. So the practical reason for using Haskell today is to take advantage o…

If you want a canonical example of an algorithm that's imperative and harder to do in a functional setting, cite union-find (See "A Persistent Union-Find Data Structure"). Searching is optimal in a functional setting, too. Just not the classic quicksort.

Re: Is Haskell the Cure?

#56

Post by eru » Mon, Oct 03, 2011, 5:00 PM UTC

microtonal wrote: post #35

gregwebs wrote: post #26

Earlier quoted context omitted.

I believe you are attributing a library issue to a language. Before today (and by today I literally mean a month ago when Yesod released a cross-platform development server that automatically re-compiles your web application) there wasn't a productive set of libraries and tools to build a web application with in Haskell. 3 years ago when you started, and even until 1-2 years ago the library situation was absolutely h…

I believe you are attributing a library issue to a language. Reasoning about laziness? Polymorphism that can only be implemented using existential types plus Typable? Even purity is a double-edged sword (some algorithms are inherently mutable)[1]. Some of Haskell's problems in real-life projects can definitely be attributed to the language itself. So the practical reason for using Haskell today is to take advantage o…

If you want a canonical example of an algorithm that's imperative and harder to do in a functional setting, cite union-find. Searching is optimal in a functional setting, too. Just not the classic quicksort.

Re: Is Haskell the Cure?

#57

Post by jberryman » Mon, Oct 03, 2011, 5:07 PM UTC

the_mat wrote: post #37

Please stop with the toy benchmarks and pretty one-liners that show how awesome Haskell is. There is growing list of smart programmers who get all enchanted with Haskell, jump into it wholeheartedly, and end up frustrated (see bottom of message). GHC makes the typical C++ compiler seem fast. Once code grows past the homework problem size, all hope of understanding memory usage is lost. I don't think people really get…

To be fair, as I understand it the toy benchmark was someone else's and he was offering a haskell implementation.

Re: Is Haskell the Cure?

#58

Post by Homunculiheaded » Mon, Oct 03, 2011, 5:10 PM UTC

bobfunk wrote: post #17

substack wrote: post #10

I gave haskell a shot as some of my earlier github repos indicate: https://github.com/substack . I even wrote my blog in haskell with happstack, since snap hadn't gotten popular yet. Haskell is very hard, but even after 3 years of pretty intensive use, I never really felt productive with haskell in the same way that I've felt in other languages. Anything I did in haskell required a lot of thinking up-front and tinker…

It's pretty much what I mean when calling Haskell hard to learn. For me it's also been a steep learning curve, and my experience hasn't been altogether different than yours. I started out maybe 5 years ago following tutorials, reading up on all the metaphors about Monads and doing project Euler problems. After a while I started to tackle some small web related things with Haskell and had exactly your experience of ru…

I think part of the issue with learning haskell is that it seems to invert the typical learning strategy for programming languages. Usually the best advice is read a little, then write a lot. Typically you can just look and some published code and go "ah yes that's how you do it". But I find, for better or worse, Haskell really requires you to understand before you code. Which in the end means your study to code ratio is very different than almost any other language.

Most languages, even lisps, are somewhat tolerant of 'programming by guessing' for beginners. Usually you write terrible code that works, learn more and see what you did wrong. Haskell is very unforgiving of this, if you don't understand why it works it probably won't

Re: Is Haskell the Cure?

#59

Post by jberryman » Mon, Oct 03, 2011, 5:13 PM UTC

microtonal wrote: post #35

gregwebs wrote: post #26

Earlier quoted context omitted.

I believe you are attributing a library issue to a language. Before today (and by today I literally mean a month ago when Yesod released a cross-platform development server that automatically re-compiles your web application) there wasn't a productive set of libraries and tools to build a web application with in Haskell. 3 years ago when you started, and even until 1-2 years ago the library situation was absolutely h…

I believe you are attributing a library issue to a language. Reasoning about laziness? Polymorphism that can only be implemented using existential types plus Typable? Even purity is a double-edged sword (some algorithms are inherently mutable)[1]. Some of Haskell's problems in real-life projects can definitely be attributed to the language itself. So the practical reason for using Haskell today is to take advantage o…

> Polymorphism that can only be implemented using existential types plus Typable?

I'm curious where you came across this. In an external library you were using, or in the process of trying to implement some kind of dynamic typing in your own code?

Re: Is Haskell the Cure?

#60

Post by eru » Mon, Oct 03, 2011, 5:15 PM UTC

microtonal wrote: post #48

thesz wrote: post #46

Earlier quoted context omitted.

Why use quicksort over arrays when you can do mergesort over lists and get 1) stable behavior and 2) solution to maximum and k-max problems due to laziness? Do you really need arrays? And quicksort for arrays in ST monad wouldn't copy anything unnecessary. Actually, I've seen many claims that some algorithms are inherently mutable. So far none stand close scrutiny. Matrix operations? You better copy intermediate resu…

Why use quicksort over arrays when you can do mergesort over lists Sure, you can do merge sort. Except that the list split step in Haskell is O(n) in time, while it is constant when using arrays. As well as merging lists, since you have to 'reattach' the second list as the tail of the first list. And quicksort for arrays in ST monad wouldn't copy anything unnecessary. You have to copy the data from whatever represent…

I agree with you in most cases.

> Sure, you can do merge sort. Except that the list split step in Haskell is O(n) in time, while it is constant when using arrays. As well as merging lists, since you have to 'reattach' the second list as the tail of the first list.

It's no problem writing a merge-sort in Haskell that uses O(n log n) time. So who cares what the asymptotics of the individual elements of the algorithm are? (You may care about the actual speed of the whole thing and its parts, though.)