5 ms·

It's old. It's so old, it predates Haskell's monads as an idea, let alone a solution to the IO problem. It was before Higher Kinded Types and GADTs. Linked List

It's old. It's so old, it predates Haskell's monads as an idea, let alone a solution to the IO problem. It was before Higher Kinded Types and GADTs. Linked Lists were still the primary data structure for everything. Haskell was more like Miranda than it was like Haskell today. Not only that, but it excluded some of the more prominent languages for prototyping of the time: Smalltalk, SML, Eiffel, and Objective C. And if you were to do it today, you'd invariably have to include languages that have had 20 years to catch up. Would the same result hold in a world with Scala, Ocaml, F#, Idris, Agda, Swift, and Rust? Let's face it, this study was a victory for higher order functions and ADTs with pattern matching. Let's not pretend it was anything more than that.

the_af 10y ago
> Let's face it, this study was a victory for higher order functions and ADTs with pattern matching. Let's not pretend it was anything more than that. In what sense was this not a victory for Haskell at the time the paper was written? You can always decompose any programming language L into a collection of X, Y, Z features and claim it's really about X, Y, Z instead of L, but is that a meaningful distinction? I love this paper because it explores the idea that functional languages with static typing can actually be very good at rapid prototyping. This goes against some oft-repeated "common sense" notion that "static typing is good for large systems, but for prototyping it's best to use dynamic typing". It's very illuminating that the two Haskell teams were the only ones that delivered [1] working, feature-complete code, and at the same time they had the fewer lines of code. [1] ...which would have mattered more if the examiners had actually looked at working code, the results hadn't been self-reported by each team, and the requirements themselves hadn't been determined more or less by each team. Seriously, if there is ONE complain to make is that the study wasn't rigorous enough. I'd love for this experiment to be conducted again with modern languages and a more rigorous methodology.
- berkut 10y ago
  > "It's very illuminating that the two Haskell teams were the only ones that delivered [1] working, feature-complete code" Where are you seeing that the Haskell code was the only "working, feature-complete" code?
  - the_why_of_y 10y ago
    The paper does not support this statement - section 5 says that there were several submissions that could not be executed at the time because no implementation was available (Ada9X, Rapide, Griffin). The authors say that the Rapide submission "did not address the essential functionality of the geo-server"; I guess it is reasonable to assume that if any of the other submissions had been incomplete, they would have mentioned that too.
  - the_af 10y ago
    Yes, you are right. I misread, that claim is not supported by the paper. Thanks for the correction!
- saosebastiao 10y ago
  > In what sense was this not a victory for Haskell at the time the paper was written? You can always decompose any programming language L into a collection of X, Y, Z features and claim it's really about X, Y, Z instead of L, but is that a meaningful distinction? It was the exclusion of a handful of popular languages that either strongly intersected with Haskell of the era (SML), or had other measurable contributions to make to prototyping capability (smalltalk, erlang, prolog). Including SML at the very least, would have let us know whether Haskell's laziness was a help or a hindrance, and including smalltalk would have helped us to know whether C++'s failings had to do with its reliance on OOP or something else (even in 94, C++ was one of the largest and most complex languages that had ever existed). But they weren't even on the table...a baffling decision given some of the languages that did make it in. It looks like a deliberate bias in language selection, and it makes it look like the conclusion was drawn before the study even began.
  - wyager 10y ago
    > It was the exclusion of a handful of popular languages that either strongly intersected with Haskell of the era (SML) They probably wanted to avoid redundancy. It seems like they picked fairly dissimilar languages all around.
  - jmcphers 10y ago
    > it makes it look like the conclusion was drawn before the study even began. From the paper, page 9: > The Haskell prototype was written by the second author of this paper, with minor help from the first Seems like they definitely had a horse in the race!
    - gilmi 10y ago
      > (10) Intermetrics, independently and without the knowledge of NSWC or Yale University, conducted an experiment of its own: the Haskell Report was given to a newly hired college graduate, who was then given 8 days to learn Haskell. This new hire received no formal training, but was allowed to ask an experienced Haskell programmer questions as issues came up during the self study. After this training period, the new hire was handed the geo-server speciﬁcation and asked to write a prototype in Haskell.
wyager 10y ago
> this study was a victory for higher order functions and ADTs with pattern matching. So, the bread and butter of Haskell? There are few languages that do these two things nearly as well as Haskell. All of them are ML derivatives. Haskell, OCaml, and F# come to mind. Rust has almost-as-good ADTs, but no higher order functions. A number popular of languages support both of these concepts, but not nearly as natively or conveniently.
- riffraff 10y ago
  > Rust has almost-as-good ADTs, but no higher order functions. it seems to me Rust has HOF, do you mean they are not as nice as Haskells' ? Why?
  - wyager 10y ago
    Correct. True functional-style HOFs require passing around arbitrarily-sized heap closures, which doesn't work with rust's memory model. Rust lets you Box closures, but it's very inconvenient compared to treating them as first-class values, so I didn't count it.
- vertex-four 10y ago
  Rust definitely has higher order functions, but it doesn't have higher kinded types required for certain things (like monads). You may have got these confused.
  - wyager 10y ago
    Rust has very limited higher-order functions. True functional-style HOFs require passing around arbitrarily-sized heap closures, which doesn't work with rust's memory model. You cannot, for example, have a vector of functions in rust. You can sort of get it with boxed closures, but it's very inconvenient compared to in any of the languages I mentioned. That's why I didn't include it.
    - vertex-four 10y ago

the_af 10y ago

> Let's face it, this study was a victory for higher order functions and ADTs with pattern matching. Let's not pretend it was anything more than that. In what sense was this not a victory for Haskell at the time the paper was written? You can always decompose any programming language L into a collection of X, Y, Z features and claim it's really about X, Y, Z instead of L, but is that a meaningful distinction? I love this paper because it explores the idea that functional languages with static typing can actually be very good at rapid prototyping. This goes against some oft-repeated "common sense" notion that "static typing is good for large systems, but for prototyping it's best to use dynamic typing". It's very illuminating that the two Haskell teams were the only ones that delivered [1] working, feature-complete code, and at the same time they had the fewer lines of code. [1] ...which would have mattered more if the examiners had actually looked at working code, the results hadn't been self-reported by each team, and the requirements themselves hadn't been determined more or less by each team. Seriously, if there is ONE complain to make is that the study wasn't rigorous enough. I'd love for this experiment to be conducted again with modern languages and a more rigorous methodology.

berkut 10y ago
> "It's very illuminating that the two Haskell teams were the only ones that delivered [1] working, feature-complete code" Where are you seeing that the Haskell code was the only "working, feature-complete" code?
- the_why_of_y 10y ago
  The paper does not support this statement - section 5 says that there were several submissions that could not be executed at the time because no implementation was available (Ada9X, Rapide, Griffin). The authors say that the Rapide submission "did not address the essential functionality of the geo-server"; I guess it is reasonable to assume that if any of the other submissions had been incomplete, they would have mentioned that too.
- the_af 10y ago
  Yes, you are right. I misread, that claim is not supported by the paper. Thanks for the correction!
saosebastiao 10y ago
> In what sense was this not a victory for Haskell at the time the paper was written? You can always decompose any programming language L into a collection of X, Y, Z features and claim it's really about X, Y, Z instead of L, but is that a meaningful distinction? It was the exclusion of a handful of popular languages that either strongly intersected with Haskell of the era (SML), or had other measurable contributions to make to prototyping capability (smalltalk, erlang, prolog). Including SML at the very least, would have let us know whether Haskell's laziness was a help or a hindrance, and including smalltalk would have helped us to know whether C++'s failings had to do with its reliance on OOP or something else (even in 94, C++ was one of the largest and most complex languages that had ever existed). But they weren't even on the table...a baffling decision given some of the languages that did make it in. It looks like a deliberate bias in language selection, and it makes it look like the conclusion was drawn before the study even began.
- wyager 10y ago
  > It was the exclusion of a handful of popular languages that either strongly intersected with Haskell of the era (SML) They probably wanted to avoid redundancy. It seems like they picked fairly dissimilar languages all around.
- jmcphers 10y ago
  > it makes it look like the conclusion was drawn before the study even began. From the paper, page 9: > The Haskell prototype was written by the second author of this paper, with minor help from the first Seems like they definitely had a horse in the race!
  - gilmi 10y ago
    > (10) Intermetrics, independently and without the knowledge of NSWC or Yale University, conducted an experiment of its own: the Haskell Report was given to a newly hired college graduate, who was then given 8 days to learn Haskell. This new hire received no formal training, but was allowed to ask an experienced Haskell programmer questions as issues came up during the self study. After this training period, the new hire was handed the geo-server speciﬁcation and asked to write a prototype in Haskell.

wyager 10y ago

> this study was a victory for higher order functions and ADTs with pattern matching. So, the bread and butter of Haskell? There are few languages that do these two things nearly as well as Haskell. All of them are ML derivatives. Haskell, OCaml, and F# come to mind. Rust has almost-as-good ADTs, but no higher order functions. A number popular of languages support both of these concepts, but not nearly as natively or conveniently.

riffraff 10y ago
> Rust has almost-as-good ADTs, but no higher order functions. it seems to me Rust has HOF, do you mean they are not as nice as Haskells' ? Why?
- wyager 10y ago
  Correct. True functional-style HOFs require passing around arbitrarily-sized heap closures, which doesn't work with rust's memory model. Rust lets you Box closures, but it's very inconvenient compared to treating them as first-class values, so I didn't count it.
vertex-four 10y ago
Rust definitely has higher order functions, but it doesn't have higher kinded types required for certain things (like monads). You may have got these confused.
- wyager 10y ago
  Rust has very limited higher-order functions. True functional-style HOFs require passing around arbitrarily-sized heap closures, which doesn't work with rust's memory model. You cannot, for example, have a vector of functions in rust. You can sort of get it with boxed closures, but it's very inconvenient compared to in any of the languages I mentioned. That's why I didn't include it.
  - vertex-four 10y ago