10 ms·
Why Haskell is beyond ready for Prime Time
- thomasmallen 18y agoAdvanced languages like Haskell will never reach Prime Time in the sense of the term because they're too challenging. Similar to the "Python Paradox," except that Python's easy to learn. There's a strange appeal (that we all still can relate to) that's led people to prefer simple junk like ColdFusion to better-designed, more useful languages over the years.
- jimbokun 18y agoObject orientation eventually "won" in the market. Unfortunately, it was adopted by the general programming public in the form of Java, not Smalltalk. It seems like functional programming is similarly "winning" as an idea. Anyone who thinks about programming much agrees that a language where you can't pass a function as a value, or construct functions at runtime, is pretty broken. The question then, is whether Haskell is the new Smalltalk of functional programming, and what language will play the role of the functional programming Java.
- wmf 18y agoIndeed; all functional languages are not alike. Haskell is not just functional, it's also lazy and has "weird" syntax. If functional programming is going to take off, I would expect to see it in the form of an eagerly-evaluated language with C-like syntax.
- eelco 18y agoMaybe I'm getting Haskell-blind, but what's "wierd" about the syntax? If I think about "wierd" syntax, I think about Erlang or Objective-C or Befunge for that matter. However, it seems that once you spent a day or so with a language the syntax wierdness tends to go away. (Still need to test that hypothesis with Erlang, though.)
- lacker 18y agoPattern-matching for control flow rather than if statements is the main weird thing. E.g. sum ys = let sum' [] total = total sum' (x:xs) total = sum' xs (total+x) in sum' ys 0 That looks weird.
- silentbicycle 18y agoUnlike some other features* , pattern matching isn't all that scary, though. "Oh, it's like a switch statement... but it can break things up and check inside... that's pretty cool." You can understand it in terms of other fairly commonplace constructs, and it's relatively clear how useful it is. It could be presented a bit differently, but the underlying idea seems approachable. * I'm thinking of monads, in particular; whether they actually are or whether it's just due to the way they've been presented is another question.
- time_management 18y agoMonads aren't that hard. A monad is just like a burrito! Pattern matching is awesome. It makes code immensely more readable.
- silentbicycle 18y agoI started to understand monads when I compared the Maybe monad to the short-circuiting behavior of the Unix pipe. That doesn't mean my insight will work for anybody else, though. Also, having masses of Haskell blog posts saying, "No, monads are actually not that hard, here's (an explanation that probably won't actually make all that much sense)." probably doesn't help to dispel the myth that Haskell is hard / impractical / whatever.
- time_management 18y agoIn understanding monads, I think Maybe and List are the best places to start, because they're familiar data structures. IO is conceptually familiar, but IO as an immutable value representing a series of actions is not.
- lallysingh 18y agoC++ 0x is providing lambdas and closures. Closures didn't make it into Java, where it may have been relevant.
- andreyf 18y agoThe question then, is [...] what language will play the role of the functional programming Java. JavaScript?
- time_management 18y agoMulti-core concurrency is going to kill OO. FP will resurge in the 2010s among good programmers, spreading out to the "vital 25%" (who are, right now, mostly upper-tier Java developers) rather than being restricted to an elite 3-5%.
- 11ren 18y agoI know this is the conventional wisdom, but can you provide support for your claim that multi-core will help FP? The usual claim is that the immutability of FP will avoid the problems of different processes writing to shared memory, because they only read it. But Erlang is famous for its concurrency, and this is not due to it being a FP; it is due to its shared-nothing pure-message passing (from Smalltalk). It's another solution. If you have multi-cores, the problem is not what you do within one core (we can already manage that); it's that you have many cores. If [1] they have their own local memory, then pure-message passing is the inevitable solution. Anyway, that's my reasoning - I'm interested to hear your reasoning. [1] At the moment, the on-chip memory is (very small) cache, and so shared memory is an option... but I think it's also inevitable that we'll get sufficient local memory for each core to execute code independently.
- cstejerean 18y agoerlang is really good at running distributed programs. that's where the share nothing actor model is necessary and works well. it's actually a kludge to write a simple concurrent application in erlang because the simplest reads requires sending two messages. For writing concurrent applications (single process, multiple threads) I like the Clojure approach much better. I can't explain it length here, but check out http:/clojure.org
- time_management 18y agoI think Clojure is likely to shoot ahead of Erlang as the leading concurrency language. After that will be Concur, an ML/Haskell-inspired statically-typed concurrency language my friend Brian Hurt is designing. One thing I've picked up, looking at Clojure, is that the lack of mutable state allows certain cool optimizations. For example, let's say you have a map A with a million key-value pairs. You want to do something with B = A + (k', v'). In a mutable-state language, you'd physically add (k', v') to the map, which is usually implemented as a hash table. Clojure creates a new map (32-ary tree) for B that shares most of its pointers and structure with A, which allows you to do FP without FP's greatest drawback, which is the copying of large data structures. Since the nodes will never change, this sharing is entirely safe. A remains entirely unchanged, so a thread working with A still has A. Functional programming doesn't actually eliminate side effects and mutability. Haskell has the IO and Array monads. Clojure has refs and agents. FP simply segregates them from the rest of the program so that they exist only when desirable, and can be more easily managed. I don't know the details about cache and local memory. This is a weak area for me.
- 11ren 18y agoI think part of Lisp's success was that academics liked it, so when they did clever stuff, it was related to Lisp. Today, it seems that academics like Haskell (is it true?), and so when they think of clever stuff, it will be related to Haskell. The "Java of FP" could be C# or F# (although Microsoft isn't willing to go multi-platform, so that might stop it becoming "successful", by many definitions). But honestly, I don't think there is a powerful enough vector available to carry FP. C had Unix. Java had the net. A novel way to think about the next "Java of FP" is to think of what vector could matter, and then what FP language is well-placed to be carried by it. Mobile phones are all I can think of at the moment, but no FP has come of it; the netbooks (which are becoming phones) are plain ol' PCs; and the iPhone runs Objective-C (doesn't it?). What's the next IT revolution? Actually, time_management is right: the next IT revolution is clearly multi-core. EDIT: I keep hearing about Intel's CUDA for multicore on GPU's, but it's pretty much the anti-FP, being "recursion free" http://en.wikipedia.org/wiki/CUDA#Limitations http://en.wikipedia.org/wiki/CUDA#Limitations
- ionfish 18y agoThere's a project called GpuGen intended to allow the compilation of Haskell code to CUDA. http://www.galois.com/blog/2008/08/29/gpugen-bringing-the-power-of-gpus-into-the-haskell-world/ http://www.galois.com/blog/2008/08/29/gpugen-bringing-the-po... There's also something similar called Obsidian: http://lambda-the-ultimate.org/node/3016 http://lambda-the-ultimate.org/node/3016
- ionfish 18y agoAnd if you'd prefer to read the original papers, rather than presentation slides... http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf http://www.cse.chalmers.se/~joels/writing/dccpaper_obsidian.pdf http://www.cse.chalmers.se/~joels/writing/dccpaper_obsidian....
- 11ren 18y agoThere's a counter-argument to multi-cores being the next IT revolution: although they seem to be the way to faster performance, faster performance isn't needed. Data point one: the rise of the netbook. They have slower, single-core processors, and are fast enough for most of the mainstream stuff people want to do: web, email, word-processing. Netbooks are getting faster (and this is needed for some webapps e.g. that musical score webapp is a little sluggish on my eee PC). But what is more important in a netbook is weight and battery life - that is what is needed. Performance isn't needed. Data point two: even in video games, the wii console is the most successful of the present batch. It is unusually low powered even for single-core (and in coincidence, one of its competitors, the PS3, is multi-core). Performance isn't needed. Data point three (an exception): some applications do need performance (weather simulation; google server farms), but these are already multi-core, and have been for a long time (the core used to be in separate computers, but the app was multi-core). I'm arguing that most of the mainstream market can't absorb faster performance (and the high-performance market has already solved the problem). Ripe for Disruption?: It's common for whole industries to overshoot what is needed, in terms of the particular metric they have worked at improving for years. Their corporate organization, product development and marketing are based on improving that aspect, and selling that aspect. When the basis of competition shifts, you get a new set of leaders, because the old ones can't adapt.
- 11ren 18y agoI think Haskell is intellectually challenging in a way that isn't needed to get the job done. The one exception is for proving things (which so far is not practical - but it's cool, and might become practically useful, one day). Don't get me wrong: I like the intellectual challenge, and I especially like the Haskell community - they are nice people, excited about what they're doing, very helpful, and just not interested in putting down other languages - and I think there is real beauty in Haskell. It's like a branch of mathematics. Disclosure: I'm terrible at Haskell's intellectual challenge. It makes me feel stupid. I hate that.
- eelco 18y agoWell, I'll be glad as hell if Haskell is as popular in 4.5 years from now as Python is currently (pg's article about the Python Paradox was written August 2004). Hmm, I think I'll even be glad if Haskell will ever be as popular as Python was 4.5 years ago :)
- gaius 18y agoIt won't be "real" until there's a batteries-included, commercially supported ActiveHaskell on activestate.com. OCaml (in the guise of F#) is the most likely mainstream FP language.
- silentbicycle 18y agoI rather like OCaml, but it seems like the community is too quiet / too small, and it's unlikely that it will suddenly explode. It's probably too late. :(
- sctb 18y agoThe author is asserting that Haskell, the language and the tools, is ready for `Prime Time'. There is also a sustainable community of smart and enthusiastic Haskell hackers. The developer mainstream may not be quite ready for Haskell, but Haskell is ready for them. EDIT: Meant to be in reply to thomasmallen: "Advanced language like Haskell..."
- stcredzero 18y agoIs the developer mainstream any better than it used to be?
- bpyne 18y agoI think it is or will be soon enough. The internet made communication between geographically disparate developers so much easier. It's become mature enough that there are sites now where curious developers can congregate and exchange ideas. When I started in the field the internet wasn't on the radar of businesses. Email accounts were uncommon never mind blog sites. Most book stores didn't carry books on academic topics. Besides, the wave of OO was just starting to gather so 9 out of 10 books were on OO or C++ or both. Developers are now exposed to more and can share code and techniques. More complex problems are shared now causing curious developers to stretch their limits. The largest problem I see now with adoption of Haskell is the us/them mentality of field trained developers vs. academically trained ones. I'm in the former group. While not all academically trained developers code/design well, the median one has been exposed to a wider range of coding problems and tools. Our ability to share ideas and problems on the internet levels that playing field if we let it. In short, yes, mainstream developers are ready for Haskell/Lisp/OCaml/etc. We need to get over the "that's just for academics" mentality. They are tools, thought out by people with lots of brains and time on their hands, to solve problems. The only thing holding us back is our mentality.
- smanek 18y agoBeing able to search for functions/libraries by type signatures is very, very useful.
- sctb 18y agoI completely agree, and I believe that this is something unique to Haskell+Hoogle+Hackage.
- silentbicycle 18y agoThough thinking about functions/libraries in terms of their type signatures is, in itself, a pretty new concept to a lot of people.
- time_management 18y agoI remember, about a week into my exposure to Ocaml, asking what a functor was. "It's a function from a module to a module." My response was along the lines of, What? It turns out, though, that Ocaml functors are really cool and can provide some of the functionality of Haskell's type classes.
- andreyf 18y agoEven more useful: searching for functions/libraries with a unit test?
- alexfarran 18y agoKind of like Squeak Smalltalk's method finder http://wiki.squeak.org/squeak/1916 http://wiki.squeak.org/squeak/1916 And a reimplementation in Ruby http://www.nobugs.org/developer/ruby/method_finder.html http://www.nobugs.org/developer/ruby/method_finder.html
- time_management 18y agoIndeed. Type signatures mean that the code is naturally self-documenting. My stance on the static/dynamic controversy is that static typing becomes a win as the amount of time spent reading others' code increases. A single programmer is probably going to be more productive in Lisp than in ML. (I don't know enough about Haskell to speak for it.) On the other hand, if I were choosing a base language for a team of 10 people who would all be editing the same code, I'd most likely choose one that's statically typed. Static typing enforces interfaces and allows the compiler to detect a decent share of bugs as well as most code breaks.
- brl 18y agoRather than writing blog articles touting how great your favorite language is for general purpose programming you should write some code. When you have more non-trivial applications written in Haskell than a Haskell compiler and a DVCS it will be a lot more credible to talk about it being ready for 'Prime Time'.
- sharkbrainguy 18y agoLike a window manager? http://xmonad.org/ http://xmonad.org/
- brl 18y agoI like xmonad, but it's still just a 500 line ultra-minimalist window manager. Students in introductory programming classes write programs longer than that. Get back to me when you've implemented KDE, Aqua, or Aero in Haskell.
- wernerv0nbraun 18y agoyou find me one introductory programming student who can even read the code for xmonad let alone write it xmonad is feature-laden it is a small codebase not because it is trivial, but because the people who wrote it are kick-ass coders
- time_management 18y agoLines of code fails as a measure of code quantity for languages like Lisp and Haskell. 500 lines of Haskell code can accomplish what will take 1500-5000 lines of Java.
- brl 18y agoWhen I'm trying to get stuff done I would rather spend 3x as much time typing in code than waste all week deciphering 'core' and reading heap profiling output to track down a space leak that could never happen in any other language.