Haskell 2010 Announced 173
paltemalte writes "Simon Marlow has posted an announcement of Haskell 2010, a new revision of the Haskell purely functional programming language. Good news for everyone interested in SMP and concurrency programming."
Is it just me ? (Score:4, Insightful)
I admit that a function with no side effects can ease making things thread safe, but are recursive style functional programming languages really used that much in "SMP and concurrency programming" nowadays. I wrote some code in that category but I never envisioned a functional programming language would suit the job. Am I the only one ? ;-))
Thanks for your replies,
Re:Is it just me ? (Score:5, Insightful)
Functional languages are enjoying an enormous renaissance in the field of multithread, multicore and/or multiprocessor environments.
There are a few really major obstacles to doing multi-* well. The major theoretical one is Amdahl's Law, which puts some extreme limits on how much multi-* can help you. The major practical one is our current obsession with side-effect languages. We need major theoretical advancements to get past Amdahl's Law (if, in fact, it can be gotten past at all). Functional programming is a great way to get past side-effect-based programming, though.
In a proper functional language, there is no such thing as iteration. There can't be. The instant you say, "each time through the loop, increment the counter, and as soon as it hits this certain value stop," you have stopped programming in a functional style.
As an example of some really cool concurrent languages that emphasize recursion and functional programming, look at Clojure, Scala, Erlang and F#. All of these languages provide iteration and other side effect techniques if you really need them -- but all of these languages emphasize recursion.
Re:But I'm lazy... (Score:5, Insightful)
Re:Concurrency? (Score:5, Insightful)
Well, pure functional languages are (potentially) good for concurrency in general. Because they have no mutable variables in the usual sense, it doesn't actually matter what order functions are evaluated in (other than the fact that callers cannot continue until their callees return). You can't do this in C or Java because it might be necessary for one function to see a variable modified by another. In a functional language, any dependencies are explicit call-return relationships (well, ish, they typically do have some non-functional constructs otherwise it's hard to do IO!), so in principle it's quite easy to split up a program's work across multiple CPUs (or machines) and not worry about whether they need to talk to each other.
Haskell, along with the ML family of languages, also has an amazing type checker that is waaay more sophisticated than most other languages. I think most people who've played around with these languages do start to feel that often "If it compiles, it's bug-free". Obviously that's not something you can rely on, since the compiler can't know what you meant to do. But it is true that the type system is *way* more useful at detecting bugs at compile-time than for any conventional language I've used.
Re:Is it just me ? (Score:3, Insightful)
Except that
1. Slashdot thought you're writing HTML and ate half of your code
2. Put it into a module and load in ghci, then try something like "qsort [1..10000]". Watch the slowness.
3. The efficient implementation in Haskell uses iteration and is 100 times less readable than equivalent code in C.
I really like Haskell, but this is not the best example of its strenghts.
Re:Not to sound like an ass, but... (Score:3, Insightful)
Re:Is it just me ? (Score:3, Insightful)
Amdahl's law is not like Moore's "law". Amdahl's law is an observation of mathematics. You can't ever get around the fact that if you increase the performance of 90% of the instructions in a program, you still have to deal with the other 10%. Even if you increase the performance of 90% of the instructions by 100x or something large, if the other 10% take a long time (like disk access) its going to kill your performance.
It makes the implicit assumption that there is a '10%'. The whole point of some pure functional languages is that essentially all of it can be parallelized, 99% or more in some cases. There are programs where the sequential part is 0.001%, if that.
However, another comeback I've heard is that the "end goal" of parallelization is not necessarily to do the same thing in less time, but to do more in the same time. That is, you increase the "parallelizable" bit while keeping everything else constant. For example, take a look at computer games, where you'd just do "higher resolution", or "bigger textures", or "more complex shaders". You do more, while the sequential stuff stays much the same.
I can't stand it when people trot out Amhdal's law like it's some sort of reason that parallelization is futile or something. It's missing the point completely!