10 ms·

IME Haskell development has a sort of bell-curve to it. Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstracti

IME Haskell development has a sort of bell-curve to it. Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way: you have to declare up-front which functions do I/O, etc. But once the core abstractions are settled, you start to reap its power. The type system catches tons of potential errors. Combinators allow for enormous expressiveness. Here you're rolling: Haskell is in its zone! But then you hit a wall. Laziness makes for brutal debugging. Singly linked lists actually suck. Performance optimization is a black art. You find yourself longing for a language with simple semantics and mechanical sympathy. Now Haskell is bumping up against the real world. Haskell has its sweet spot somewhere between "bang this out by 5pm" and "ship this to a million users". (No surprise it's popular in academia.)

Tehnix 10y ago
>But once the core abstractions are settled, you start to reap its power This is so true. Once you get the types settled for your project, then it becomes a breeze to quickly add things and refactor over and over again, because maybe the spec or idea changed. I've recently experienced this in both a Haskell project (using the Yesod framework) and I'm currently working on an Elm project, where I very much feel this strength also. I'll have to agree with you on the debugging though - it is somewhat of an art, and not one I've completely mastered yet, since I haven't had that much need for it for now (haven't done that many production haskell projects).
vog 10y ago
> But then you hit a wall. Laziness makes for brutal debugging. Singly linked lists actually suck. Performance optimization is a black art To be fair, these issue are more-or-less solved by newer functional languages, such as OCaml or Rust.
- amelius 10y ago
  You mean non-purely functional languages.
  - bjz_ 10y ago
    Purity is orthogonal to laziness. Languages like Idris, Purescript, and Elm are pure but also eagerly evaluated.
    - hikarudo 10y ago
      Except that laziness requires purity.
      - deleted 10y ago
        [deleted]
      - fdej 10y ago
        Only if you insist on determinism :-)
  - vog 10y ago
    I assume you mean strict (the opposite of lazy) instead of non-pure (which means imperative). Well, even then, Rust does not only give you control over execution order, but also tight control over memory management, while keeping it safe. Haskell allows for good reasoning about correctness. In OCaml, you can additionally reason about execution order, but memory management and garbage collector are still somewhat "unpredictable" (i.e. hard to reason about). On top of that, in Rust, you can reason clearly about memory usage and aliasing. These new, modern languages follow a clear path about keeping quality and correctness (hence safety) while having more and more control over performance, without going back to low-level where you would loose clarity about correctness and safety. (Note, however, that the distinction between correctness and performance is over-simplified here, because performance can also be part of correctness, e.g. for real-time systems, or in systems where scalability is an important requirement.)
    - pron 10y ago
      > pure (the opposite of imperative). Pure is not quite the opposite of imperative; declarative is the opposite of imperative, although in practice it is true that pure functional languages tend to be more declarative that imperative functional ones. You can have pure (AKA referentially transparent) imperative languages if they are synchronous[1]. The synchronous style is especially well suited to reactive/interactive applications, and quite popular in hard realtime applications. Also, we don't really have exact definitions to any of these terms (imperative, pure, functional, declarative). Here is my attempt for approximate, problematic definitions: * Functional -- a language that models most/all computations as (possibly partial) mathematical functions, and constructs a program by assembling those functions. * Imperative -- a language that models computation as state transitions, specifying what state should the computation have at each step. * Declarative -- a language that describes what result should the program give (as a function, a relation or a behavior) rather than at each step. * Pure -- a language where the semantic value of the composition of syntactic terms can be determined by the semantic value of each of the component terms and no others. [1]: https://en.wikipedia.org/wiki/Synchronous_programming_language https://en.wikipedia.org/wiki/Synchronous_programming_langua...
- srean 10y ago
  Technically you are correct (the best kind of correct) but from where we sit today in time, Haskell and OCaml appear as are peers. They probably have some 4~5 years between them, and probably less if you consider ML.
- nilkn 10y ago
  Practically speaking, OCaml is not exactly just a drop-in replacement for Haskell. For instance, Haskell has world-class support for STM which makes it arguably one of the best languages out there for single-machine multicore concurrency. Also, OCaml is still two decades old. I find it very bizarre that you attempted to group it in with Rust as a "new" language.
deleted 10y ago
[deleted]
pka 10y ago
> Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way The opposite is true: here Haskell helps to find the right data structures/abstractions incredibly fast. The ability to quickly construct and reconstruct a high-level skeleton of your program without actually having to implement anything makes prototyping much easier and faster than in comparable dynamic languages. > But then you hit a wall. Laziness makes for brutal debugging. Laziness can sometimes surprise you in bad ways, but it's not like it's impossible to debug. > Singly linked lists actually suck. Just replace them with the right data structure then? Even for big codebases and fundamental program abstractions that's a 15min job, because of types. > Performance optimization is a black art. I agree. But then again - you don't have to write everything in Haskell. Writing the critical 1% in C, testing the shit out of it and calling it from Haskell is absolutely fine.
- jstimpfle 10y ago
  Why, in your opinion, is it faster to construct a "high-level skeleton" than in dynamic languages? > Laziness can sometimes surprise you in bad ways, but it's not like it's impossible to debug. The last message I get was something like "Array.Array: Index out of bounds". Program crashed. No idea where the error originated. The answer I got was "yeah, in GHC 8 there will be some support for stack traces".
  - pka 10y ago
    Because of types, basically. You can construct the core data structures of your program and the types of the functions operating on those data structures without having to actually implement said functions. When the types fit together, i.e. your program is logically consistent, you can start filling in the actual code. This is much faster than writing a large chunk of code, playing around in the REPL thinking everything is ok, only to realize one week later that you didn't think through some core aspect of your design and then having to refactor a sizeable piece of your codebase. > The last message I get was something like "Array.Array: Index out of bounds". Program crashed. No idea where the error originated. It is an unfortunate historical artefact that there are still partial functions (i.e. functions that may crash) in the Haskell base libraries. It is generally advised to avoid such functions, but this is not very clearly communicated to newcomers to Haskell. For example, Elm, a language largely inspired by Haskell, doesn't have partial functions. This is why it prides itself in "not having any runtime errors in production" (excluding things like compiler bugs or unsafe JavaScript libraries, of course).
catnaroek 10y ago
> You find yourself longing for a language with simple semantics and mechanical sympathy. “Simple semantics” as measured how? The only good metric I can think of is the size of a formal specification.
sc4th1s 10y ago
There's a reason Real World Ocaml has a section dedicated to the run-time system and no book on Haskell will ever go near it.
the_af 10y ago
> IME Haskell development has a sort of bell-curve to it. Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way: you have to declare up-front which functions do I/O, etc There's some evidence Haskell is pretty good at rapid prototyping. Are you familiar with this '94 paper on rapid prototyping [ http://www.cs.yale.edu/publications/techreports/tr1049.pdf http://www.cs.yale.edu/publications/techreports/tr1049.pdf ] by Paul Hudak (RIP), sponsored by the Office of Naval Research & ARPA? The paper is a report on an experimental comparison of programmming languages for prototyping, and it's pretty cool because they were asked to implement a portion of a (heavily simplified) AEGIS weapons system! Unfortunately the paper and experiment are dated and have a number of methodological shortcomings (results were self reported; the examining panel didn't look at running code; requirements were very vague and mostly determined by each team, which makes the comparison difficult), but the results are pretty interesting regardless: - Of all the teams, only the two Haskell teams delivered working code (though the examiners didn't look at working programs). This must be stressed: no other team delivered running code at all, much less on time! - One of the Haskell prototypes delivered more features than the initial requirements asked for. - The programmer of one of the Haskell teams had NO experience with Haskell before the experiment. - Both Haskell prototypes were also the shortest in line count. Way shorter than the C++ prototype, which wasn't even finished or working in time! I'd like to see the same experiment repeated under more rigorous conditions and with more modern languages, but the results certainly hint at Haskell being more than adequate at prototyping.
- saosebastiao 10y ago
  1994 was well before the IO monad became the standard IO paradigm for Haskell, and a year before there was even a proposal on the table for monadic IO for Haskell. It makes me wonder what the language was like back then and whether the results would be repeatable with today's language.
  - the_af 10y ago
    Sure! I think Haskell would fare pretty well today, because the essential aspects haven't changed. It's still very suitable for prototyping and exploratory programming. Of course, today it would have to go toe to toe against modern dynamic languages. In this case it'd be essential to demonstrate running code, which is arguably a huge advantage of static typing over dynamic typing; if you're only comparing source code, dynamic languages can get away with being terse and claiming "trust me, it works". I imagine Haskell would still leave modern C++ coughing dust at the start line :)

Tehnix 10y ago

>But once the core abstractions are settled, you start to reap its power This is so true. Once you get the types settled for your project, then it becomes a breeze to quickly add things and refactor over and over again, because maybe the spec or idea changed. I've recently experienced this in both a Haskell project (using the Yesod framework) and I'm currently working on an Elm project, where I very much feel this strength also. I'll have to agree with you on the debugging though - it is somewhat of an art, and not one I've completely mastered yet, since I haven't had that much need for it for now (haven't done that many production haskell projects).

vog 10y ago

> But then you hit a wall. Laziness makes for brutal debugging. Singly linked lists actually suck. Performance optimization is a black art To be fair, these issue are more-or-less solved by newer functional languages, such as OCaml or Rust.

amelius 10y ago
You mean non-purely functional languages.
- bjz_ 10y ago
  Purity is orthogonal to laziness. Languages like Idris, Purescript, and Elm are pure but also eagerly evaluated.
  - hikarudo 10y ago
    Except that laziness requires purity.
    - deleted 10y ago
      [deleted]
    - fdej 10y ago
      Only if you insist on determinism :-)
- vog 10y ago
  I assume you mean strict (the opposite of lazy) instead of non-pure (which means imperative). Well, even then, Rust does not only give you control over execution order, but also tight control over memory management, while keeping it safe. Haskell allows for good reasoning about correctness. In OCaml, you can additionally reason about execution order, but memory management and garbage collector are still somewhat "unpredictable" (i.e. hard to reason about). On top of that, in Rust, you can reason clearly about memory usage and aliasing. These new, modern languages follow a clear path about keeping quality and correctness (hence safety) while having more and more control over performance, without going back to low-level where you would loose clarity about correctness and safety. (Note, however, that the distinction between correctness and performance is over-simplified here, because performance can also be part of correctness, e.g. for real-time systems, or in systems where scalability is an important requirement.)
  - pron 10y ago
    > pure (the opposite of imperative). Pure is not quite the opposite of imperative; declarative is the opposite of imperative, although in practice it is true that pure functional languages tend to be more declarative that imperative functional ones. You can have pure (AKA referentially transparent) imperative languages if they are synchronous[1]. The synchronous style is especially well suited to reactive/interactive applications, and quite popular in hard realtime applications. Also, we don't really have exact definitions to any of these terms (imperative, pure, functional, declarative). Here is my attempt for approximate, problematic definitions: * Functional -- a language that models most/all computations as (possibly partial) mathematical functions, and constructs a program by assembling those functions. * Imperative -- a language that models computation as state transitions, specifying what state should the computation have at each step. * Declarative -- a language that describes what result should the program give (as a function, a relation or a behavior) rather than at each step. * Pure -- a language where the semantic value of the composition of syntactic terms can be determined by the semantic value of each of the component terms and no others. [1]: https://en.wikipedia.org/wiki/Synchronous_programming_language https://en.wikipedia.org/wiki/Synchronous_programming_langua...
srean 10y ago
Technically you are correct (the best kind of correct) but from where we sit today in time, Haskell and OCaml appear as are peers. They probably have some 4~5 years between them, and probably less if you consider ML.
nilkn 10y ago
Practically speaking, OCaml is not exactly just a drop-in replacement for Haskell. For instance, Haskell has world-class support for STM which makes it arguably one of the best languages out there for single-machine multicore concurrency. Also, OCaml is still two decades old. I find it very bizarre that you attempted to group it in with Rust as a "new" language.

deleted 10y ago

[deleted]

pka 10y ago

> Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way The opposite is true: here Haskell helps to find the right data structures/abstractions incredibly fast. The ability to quickly construct and reconstruct a high-level skeleton of your program without actually having to implement anything makes prototyping much easier and faster than in comparable dynamic languages. > But then you hit a wall. Laziness makes for brutal debugging. Laziness can sometimes surprise you in bad ways, but it's not like it's impossible to debug. > Singly linked lists actually suck. Just replace them with the right data structure then? Even for big codebases and fundamental program abstractions that's a 15min job, because of types. > Performance optimization is a black art. I agree. But then again - you don't have to write everything in Haskell. Writing the critical 1% in C, testing the shit out of it and calling it from Haskell is absolutely fine.

jstimpfle 10y ago
Why, in your opinion, is it faster to construct a "high-level skeleton" than in dynamic languages? > Laziness can sometimes surprise you in bad ways, but it's not like it's impossible to debug. The last message I get was something like "Array.Array: Index out of bounds". Program crashed. No idea where the error originated. The answer I got was "yeah, in GHC 8 there will be some support for stack traces".
- pka 10y ago
  Because of types, basically. You can construct the core data structures of your program and the types of the functions operating on those data structures without having to actually implement said functions. When the types fit together, i.e. your program is logically consistent, you can start filling in the actual code. This is much faster than writing a large chunk of code, playing around in the REPL thinking everything is ok, only to realize one week later that you didn't think through some core aspect of your design and then having to refactor a sizeable piece of your codebase. > The last message I get was something like "Array.Array: Index out of bounds". Program crashed. No idea where the error originated. It is an unfortunate historical artefact that there are still partial functions (i.e. functions that may crash) in the Haskell base libraries. It is generally advised to avoid such functions, but this is not very clearly communicated to newcomers to Haskell. For example, Elm, a language largely inspired by Haskell, doesn't have partial functions. This is why it prides itself in "not having any runtime errors in production" (excluding things like compiler bugs or unsafe JavaScript libraries, of course).

catnaroek 10y ago

> You find yourself longing for a language with simple semantics and mechanical sympathy. “Simple semantics” as measured how? The only good metric I can think of is the size of a formal specification.

sc4th1s 10y ago

There's a reason Real World Ocaml has a section dedicated to the run-time system and no book on Haskell will ever go near it.

the_af 10y ago

> IME Haskell development has a sort of bell-curve to it. Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way: you have to declare up-front which functions do I/O, etc There's some evidence Haskell is pretty good at rapid prototyping. Are you familiar with this '94 paper on rapid prototyping [ http://www.cs.yale.edu/publications/techreports/tr1049.pdf http://www.cs.yale.edu/publications/techreports/tr1049.pdf ] by Paul Hudak (RIP), sponsored by the Office of Naval Research & ARPA? The paper is a report on an experimental comparison of programmming languages for prototyping, and it's pretty cool because they were asked to implement a portion of a (heavily simplified) AEGIS weapons system! Unfortunately the paper and experiment are dated and have a number of methodological shortcomings (results were self reported; the examining panel didn't look at running code; requirements were very vague and mostly determined by each team, which makes the comparison difficult), but the results are pretty interesting regardless: - Of all the teams, only the two Haskell teams delivered working code (though the examiners didn't look at working programs). This must be stressed: no other team delivered running code at all, much less on time! - One of the Haskell prototypes delivered more features than the initial requirements asked for. - The programmer of one of the Haskell teams had NO experience with Haskell before the experiment. - Both Haskell prototypes were also the shortest in line count. Way shorter than the C++ prototype, which wasn't even finished or working in time! I'd like to see the same experiment repeated under more rigorous conditions and with more modern languages, but the results certainly hint at Haskell being more than adequate at prototyping.

saosebastiao 10y ago
1994 was well before the IO monad became the standard IO paradigm for Haskell, and a year before there was even a proposal on the table for monadic IO for Haskell. It makes me wonder what the language was like back then and whether the results would be repeatable with today's language.
- the_af 10y ago
  Sure! I think Haskell would fare pretty well today, because the essential aspects haven't changed. It's still very suitable for prototyping and exploratory programming. Of course, today it would have to go toe to toe against modern dynamic languages. In this case it'd be essential to demonstrate running code, which is arguably a huge advantage of static typing over dynamic typing; if you're only comparing source code, dynamic languages can get away with being terse and claiming "trust me, it works". I imagine Haskell would still leave modern C++ coughing dust at the start line :)