6 ms·

Advanced 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 th

Advanced 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 ago
Object 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 ago
  Indeed; 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 ago
    Maybe 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 ago
      Pattern-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 ago
        Unlike 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 ago
        Monads aren't that hard. A monad is just like a burrito! Pattern matching is awesome. It makes code immensely more readable.
        silentbicycle 18y ago
        I 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 ago
        In 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.
    - wmf 18y ago
      Pattern matching, also the lack of syntax for function calls (I realize there's a good reason for it).
      - jimbokun 18y ago
        "lack of syntax for function calls" It recently dawned on me that this is what makes it hard for me to understand snippets of Haskell. Specifically, trying to parse the precedence relations in a sequence of tokens uninterrupted by any kind of punctuation. Say what you will about Lisp, it is always very clear which arguments go to which functions, what the scoping boundaries are, etc.
        eru 18y ago
        In Haskell you can just put your parens like you would in Lisp.
        ighost 18y ago
        But a lot of people use $ syntax.
  - lallysingh 18y ago
    C++ 0x is providing lambdas and closures. Closures didn't make it into Java, where it may have been relevant.
- andreyf 18y ago
  The question then, is [...] what language will play the role of the functional programming Java. JavaScript?
- time_management 18y ago
  Multi-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 ago
    I 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 ago
      erlang 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 ago
      I 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 ago
  I 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 ago
    There'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 ago
      And 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 ago
    There'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 ago
  I 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 ago
Well, 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 ago
  It 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 ago
    I 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. :(

jimbokun 18y ago

Object 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 ago
Indeed; 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 ago
  Maybe 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 ago
    Pattern-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 ago
      Unlike 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 ago
        Monads aren't that hard. A monad is just like a burrito! Pattern matching is awesome. It makes code immensely more readable.
        silentbicycle 18y ago
        I 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 ago
        In 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.
  - wmf 18y ago
    Pattern matching, also the lack of syntax for function calls (I realize there's a good reason for it).
    - jimbokun 18y ago
      "lack of syntax for function calls" It recently dawned on me that this is what makes it hard for me to understand snippets of Haskell. Specifically, trying to parse the precedence relations in a sequence of tokens uninterrupted by any kind of punctuation. Say what you will about Lisp, it is always very clear which arguments go to which functions, what the scoping boundaries are, etc.
      - eru 18y ago
        In Haskell you can just put your parens like you would in Lisp.
        ighost 18y ago
        But a lot of people use $ syntax.
- lallysingh 18y ago
  C++ 0x is providing lambdas and closures. Closures didn't make it into Java, where it may have been relevant.
andreyf 18y ago
The question then, is [...] what language will play the role of the functional programming Java. JavaScript?
time_management 18y ago
Multi-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 ago
  I 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 ago
    erlang 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 ago
    I 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 ago
I 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 ago
  There'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 ago
    And 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 ago
  There'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 ago
I 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 ago

Well, 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 ago
It 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 ago
  I 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. :(