Is Haskell the Cure? • Hacker News Board

Re: Is Haskell the Cure?

#31

Post by dtbx » Mon, Oct 03, 2011, 1:35 PM UTC

microtonal wrote: post #20

Jach wrote: post #7

Earlier quoted context omitted.

Maybe most programmers who bother to look up different paradigms. My experience is that most programmers overall aren't even aware of different paradigms, let alone that things could be better: they're taught what they're taught in school or at home and don't move beyond. I've heard the phrase "Well if you know C++ you know it all" at least three times.

You must have never done any meta-programming in C++ ;). It's pretty much a functional language. Also, STL provides some infrastructure for FP-like programming (defining functors, argument binding, and providing map/fold-like transformations). But given that C++98 didn't provide lambda functions, it was all a bit too painful.

Yeah, but the syntax and the verbosity hides your aim.

In the obscure years previous to c++11, meta-programming in c++ would have required a language lawyer.

In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way.

Re: Is Haskell the Cure?

#32

Post by gvb » Mon, Oct 03, 2011, 1:37 PM UTC

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 to benchmark concurrency, at least pick an benchmark algorithm that exercises concurrency. The FFT comes to mind, but there are probably lots of better examples (that is a challenge to HNers ;-).

Re: Is Haskell the Cure?

#33

Post by sharmajai » Mon, Oct 03, 2011, 1:40 PM UTC

stonemetal wrote: post #15

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.

Not to be to contrarian but until I see proof to the contrary I think Norvig put said it best: In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages…

the right development process that allows for rapid development, well rapid development is the reason people write webapps in python/ruby/node and not C++. We have to stop pretending that language choice is immaterial, hadn't it for C we would still be typing in our single and double mouse clicks into an OS written in assembly.

Re: Is Haskell the Cure?

#34

Post by shocks » Mon, Oct 03, 2011, 1:48 PM UTC

For every application there is a language best suited... Let's stop trying to force every language to be good at everything and then compare them as though they were all the same, shall we?

Re: Is Haskell the Cure?

#35

Post by microtonal » Mon, Oct 03, 2011, 2:00 PM UTC

gregwebs wrote: post #26

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…

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 of the amazing performance,

My experience with everything from simple checksum functions to parameter estimators (ML) is that Haskell is generally at least 2-10x slower than C (even when introducing strictness where necessary, unboxing constructors, etc.). So, in practice you'll often end up doing heavy lifting in C anyway (whether it is a database server or a classifier that works in the background), and in the end it doesn't matter so much whether you use Haskell or a dynamic language (performance-wise) if a significant amount of time is required processing requests.

where its type system can rule out most common web development bugs

Right, this is where Haskell currently has an edge, because it does not only make it easy to make DSLs (as e.g. Ruby), but typechecks everything as well.

oh, and Yesod is even faster than the mentioned Snap framework which is already much faster than Node

Yes, but the benchmarks you implicitly point to (the pong benchmark) is very synthetic and says fairly little about real-life use. Until we see Snap and Yesod more in production, the jury is still out.

[1] Sure, you can do quicksort in the ST monad, but it will require a lot of unnecessary copying.

Re: Is Haskell the Cure?

#36

Post by microtonal » Mon, Oct 03, 2011, 2:16 PM UTC

dtbx wrote: post #31

microtonal wrote: post #20

Earlier quoted context omitted.

You must have never done any meta-programming in C++ ;). It's pretty much a functional language. Also, STL provides some infrastructure for FP-like programming (defining functors, argument binding, and providing map/fold-like transformations). But given that C++98 didn't provide lambda functions, it was all a bit too painful.

Yeah, but the syntax and the verbosity hides your aim. In the obscure years previous to c++11, meta-programming in c++ would have required a language lawyer. In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way.

In haskell, the syntax is so nice that is easily readable, and it doesn't get in your way.

Unless you want if-then-else in the do notation (yes, I know that there is a GHC extension for this), disagree with its whitespace rules, or like record syntax (which subsequently pollutes your namespace).

Also, point-free style is nice, but it is easily and often abused, leading to unreadable code.

Yeah, but the syntax and the verbosity hides your aim.

Many people would argue the same of Haskell. So much semantics are encoded in the particular operators, monads, functors, monad transformers, arrows being used, that they are hidden from plain sight.

Re: Is Haskell the Cure?

#37

Post by the_mat » Mon, Oct 03, 2011, 2:16 PM UTC

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 how bad that it is. The whole culture of Haskell is based around static checking, yet you have to run a program in order to find out if it blows your memory limit several times over.

Haskell is still a neat language, but we need less advocacy based on toy programs and more honest realism.

(Here's a typical, non-superficial example: http://wagerlabs.com/haskell-vs-erlang-reloaded-0)

Re: Is Haskell the Cure?

#38

Post by Jach » Mon, Oct 03, 2011, 2:25 PM UTC

microtonal wrote: post #20

Jach wrote: post #7

Earlier quoted context omitted.

Maybe most programmers who bother to look up different paradigms. My experience is that most programmers overall aren't even aware of different paradigms, let alone that things could be better: they're taught what they're taught in school or at home and don't move beyond. I've heard the phrase "Well if you know C++ you know it all" at least three times.

You must have never done any meta-programming in C++ ;). It's pretty much a functional language. Also, STL provides some infrastructure for FP-like programming (defining functors, argument binding, and providing map/fold-like transformations). But given that C++98 didn't provide lambda functions, it was all a bit too painful.

> You must have never done any meta-programming in C++ ;). It's pretty much a functional language.

I've done enough to scream in terror and run towards a Lisp should anyone suggest such an awful thing! I think there's a huge, huge gap between your 'pretty much a functional language' and standard 'a functional language' [with proper meta-programming capabilities].

Re: Is Haskell the Cure?

#39

Post by Someone » Mon, Oct 03, 2011, 2:27 PM UTC

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 whole domain. Instead, language evolution typically is a matter of two steps forward, ten sideways, and one step back.

Also, experience tells that new languages often get overhyped as making only forward steps. Given that, it does not make sense to switch horses too often, or one would be forever learning, and never be productive.

Re: Is Haskell the Cure?

#40

Post by numeromancer » Mon, Oct 03, 2011, 2:31 PM UTC

agentultra wrote: post #16

I don't think Haskell itself is really the answer. If I read the article correctly it's simply a matter of concurrency and parallelism that's important. There are a host of languages that do that quite well and Haskell just happens to be one of them.

I don't think Haskell itself is really the answer.

What was the question?