6 ms·

Haskell, Ada, C++, Awk: An Experiment in Prototyping Productivity (1994) [pdf]

86 points by Akronymus 4y ago

RcouF1uZ4gsC 4y ago
C++ in 1994 was very primitive. It didn’t even have a standard string class. The STL with all the containers and algorithms did not come until the C++ standard in 1998.
- kazinator 4y ago
  Vendors didn't wait until 1998; C++ toolchains touted draft features before then.
- pjmlp 4y ago
  All C++ compiler vendors shipped their own containers. In 1994 Borland had already gone through BIDS, Turbo Vision and OWL. Apple was shipped AppToolbox alongside Metrowerks Powerplant. IBM had CSet++. Microsoft was shipping MFC since 1993. In fact, 30 years later those frameworks still win over many missing features in the standard library, like networking and graphics.
- simne 4y ago
  You are partially right. It is really hard to write portable C++ code of small projects, because strings are different in nearly all major platforms. But if You tied to one platform, platform specific strings, usually, are good enough for heavy usage.
- erik_seaberg 4y ago
  Generics had been defined, but it wasn’t uncommon to see compilers crash(!) when using them seriously. It took a while for them to support all of STL.
kazinator 4y ago
There is no actual code, and even the problem description is omitted, in the most cryptic way. Supposedly, the description is in a referenced paper that readers are encouraged to read. However, the citation itself warns us that the paper which contains it is 400 pages that are "Unpublished". Problem description and code, or it didn't happen.
- thesz 4y ago
  Page 5: "The geo-server specification was by nature ambiguos and imprecise, thus leading to some variation in the functionalities of developed prototypes. (On the other hand, the specification is probably typical of that found in practice, especially during requirement acquisition.)" Nevertheless, at Page 6 starts the chapter 3 which aptly named "Problem description". The Haskell code for a problem solution is at Page 15. It is not complete, but it contains examples of what is called "combinators", from whose it is easy to deduce how authors approached the solution. But, one needs to be aware of the notion of combinators and how they are usually constructed. For that, take a look at [1], a construction of parsing combinators. They start with a simple higher-order functional approach just like the solution exemplified in the paper we all discuss here. [1] https://www.researchgate.net/publication/222837975_Combinator_Parsers_From_Toys_to_Tools https://www.researchgate.net/publication/222837975_Combinato...
mk_stjames 4y ago
In reading, it sounds like some of the code for certain languages wasn't even executed/tested? They just had people take a shot at it and then other people reviewed the code informally? It doesn't sound like there were very stringent test cases written beforehand. Also this paper was published by the people who wrote the Haskel version, and the whole thing, once you see that, reads like these guys did a better job in way less time and maybe understood goals better without having attended the first conference. I wish there was documentation of what the actual program and input data looked like. Something this text based.... it almost sounds like you could give it as an Advent of Code day 23 puzzle and somebody will have a Python solution done for it in 45 minutes.
usgroup 4y ago
This reads bizzarely. Awk for creating a server prototype? Haskell as an easy to learn rapid prototyping language? The lines of documentation column -- what is that even? Apparently the lisp version seems to only require 12 lines of documentation whilst the first Haskell version requires 450+ lines?
- kazinator 4y ago
  If the server can work with just a text input and output stream, and then used as a coprocess, it can be written in anything that has basic I/O facilities. If events have to be multiplexed from multiple sources, that's done outside of the server (and it is clear from the context diagram in the paper). The "Sensors" and "Object Tracking" are outside of the "Geo-Server" block. In the diagram, the Geo-Server takes input from Object Tracking and produces some output as well as a Log. It also takes input from a User Interface, and produces output back to it. Because of that extra multiplexing complexity, a front-end harness layer could be developed: something which interacts with the User Interface, Log, Object Tracking and Deployment, and loads the Geo-Server as basically a plug-in.
tmm84 4y ago
Somethings I like in this paper, 1) the AWK programmer tried to do as many statements as possible in an 80 column row (must have loved one liners in Perl), 2) the Lisp implementation just describes the guy being at the kickoff for 4 hours (doing what?).
Spivasart 4y ago
[dead]
dang 4y ago
Related: Haskell, Ada, C++: An Experiment in Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=19570776 https://news.ycombinator.com/item?id=19570776 - April 2019 (55 comments) Haskell vs. Ada vs. C++ an Experiment in Software Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=14267882 https://news.ycombinator.com/item?id=14267882 - May 2017 (59 comments) Haskell vs. Ada vs. C++ vs. Awk vs (1994) [pdf] - https://news.ycombinator.com/item?id=13275288 https://news.ycombinator.com/item?id=13275288 - Dec 2016 (68 comments) Haskell, Ada, C++, Awk: An Experiment in Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=7050892 https://news.ycombinator.com/item?id=7050892 - Jan 2014 (24 comments) Haskell v Ada v C++ v Awk... An Experiment in Software Prototyping Productivity - https://news.ycombinator.com/item?id=7029783 https://news.ycombinator.com/item?id=7029783 - Jan 2014 (23 comments)
tmtvl 4y ago
I am very impressed that when most languages have a development time in the double digits (including the initial Haskell implementation), the Lisp version was developed in 3 hours. If the codebases are publicly available it would be interesting to see how understandable they are.
- nine_k 4y ago
  When you don't have to prove your code is correct, and just hope it generally is (a well-grounded hope for an experienced developer), highly flexible and dynamic languages like Lisp or Python or Ruby or Smalltalk will shine. Mistakes which an experienced developer makes are usually trivial and surface during interactive testing, and the development happens in a REPL. Also, simple algorithms and data structures suffice for prototyping like this. The larger the code base, and the stricter the correctness and performance requirements, the more you want to use something like Haskell, or F#, or Typescript, which allow you to exactly pin down and statically ensure certain things.
- gleenn 4y ago
  What do you mean by "double digit times"? Your whole statement is almost completely lost because I can't tell if you think Lisp is fast or slow. Generally people say Lisps are good at prototyping and I'd agree, Clojure is super fast.
  - tmtvl 4y ago
    I'm talking about the table which shows development time in hours, as well as lines of code and lines of documentation. Come to think of it, I wonder if they counted docstrings as documentation or code?
    - lispm 4y ago
      I would guess that they used a very declarative style of Lisp programming, where much of the code looks like a specification. Here they used Common Lisp enhanced with a relational programming model, like an in-core database with an embedded query language. The developer(s) were probably quite experienced with it.
atty 4y ago
So if I’m parsing the results correctly they only have a single data point per language? Seems like they are testing individual programmers styles/speed just as much as they are testing the languages.
- AnimalMuppet 4y ago
  And individual familiarity with their language. But if you think you can get better data, we'd all love to see it...
  - kqr 4y ago
    I haven't reviewed the methodology of this first hit in detail, but here's perhaps some: https://www.researchgate.net/profile/Charles-Knutson/publication/4261726_Do_Programming_Languages_Affect_Productivity_A_Case_Study_Using_Data_from_Open_Source_Projects/links/546223460cf2c0c6aec1a663/Do-Programming-Languages-Affect-Productivity-A-Case-Study-Using-Data-from-Open-Source-Projects.pdf https://www.researchgate.net/profile/Charles-Knutson/publica... I don't think it's this one but I do remember reading a very high quality study arriving at the same result as well.
- charcircuit 4y ago
  They have 2 data points for Haskell since the one of the authors wrote a Haskell one which happened to have the fewest lines and highest documentation to code ratio.
  - tmtvl 4y ago
    They do mention that the one you're mentioning was developed in literate programming style, where the program is a LaTeX document. I wonder what kind of an impact literate programming has on maintenance. Can't imagine rewriting 40 lines of commentary to suit a 2 line code change to be particularly enjoyable.
    - ParetoOptimal 4y ago
      > Can't imagine rewriting 40 lines of commentary to suit a 2 line code change to be particularly enjoyable. I have the expectation of a "simple" 2 lime change that took 24 hours to resolve not require more than 4 lines of commentary. However I fully admit it's not rational and try to work to change it. It helps me to remember the end goal isn't just fixing the problem, but also preserving the biggest gotchas, limitations, and most important lessons learned.
melling 4y ago
30 years ago Haskell was the winner. Conciseness was a major feature. Has anyone put this to the test on larger projects? 10,000 lines of Haskell have the same functionality as 100,000 lines of C++?
- Ingaz 4y ago
  Hasura (https://github.com/hasura/graphql-engine https://github.com/hasura/graphql-engine) is quite big project. Although it should be less than 100K LOC. It was only once when I saw problem that could be considered a bug.
- nine_k 4y ago
  Haskell was mere 4 years old in 1994.
- simne 4y ago
  Haskell is too special, to be used in typical large project. But in real projects, are in wide use other pure functional langs (trying to write most popular first): - Erlang (telco, finance) - Lisp (finance, CAD) - Scala (basically universal) - Scheme (basically universal) - Elixir (frontend) - Clojure (don't know much, looks like also frontend). But in most cases, they are sort of DSL, because functional paradigm is much better in some niches, but not so good in others.
- amelius 4y ago
  Sounds great except it takes 10x as much time to read/write the Haskell code versus C++.
  - MaxBarraclough 4y ago
    Page 9 shows Haskell scoring very well for development time when compared against Ada. C++ development time was unfortunately not reported.
    - synack 4y ago
      Ada projects tend to start slow, but readability and flexible namespacing make refactoring and maintenance much easier.
charcircuit 4y ago
The small sample size and age of the experiment makes it not very relevant to today.
- nerdponx 4y ago
  It's interesting to think about how this was a selection of the best languages available at the time. Python and Java were brand new!
js8 4y ago
Are there any more recent studies?
Guthur 4y ago
Relation programming is really quite effective for high order problem solving. I've been using prolog recently and found really quite good. I've found myself thinking in terms of ontologies rather than hierarchies, which most over languages encourage. In case it was missed, the lisp in the paper is a rational lisp.
- Guthur 4y ago
  Errata: rational lisp/relation lisp

86 points by Akronymus 4y ago

C++ in 1994 was very primitive. It didn’t even have a standard string class. The STL with all the containers and algorithms did not come until the C++ standard in 1998.

kazinator 4y ago
Vendors didn't wait until 1998; C++ toolchains touted draft features before then.
pjmlp 4y ago
All C++ compiler vendors shipped their own containers. In 1994 Borland had already gone through BIDS, Turbo Vision and OWL. Apple was shipped AppToolbox alongside Metrowerks Powerplant. IBM had CSet++. Microsoft was shipping MFC since 1993. In fact, 30 years later those frameworks still win over many missing features in the standard library, like networking and graphics.
simne 4y ago
You are partially right. It is really hard to write portable C++ code of small projects, because strings are different in nearly all major platforms. But if You tied to one platform, platform specific strings, usually, are good enough for heavy usage.
erik_seaberg 4y ago
Generics had been defined, but it wasn’t uncommon to see compilers crash(!) when using them seriously. It took a while for them to support all of STL.

kazinator 4y ago

There is no actual code, and even the problem description is omitted, in the most cryptic way. Supposedly, the description is in a referenced paper that readers are encouraged to read. However, the citation itself warns us that the paper which contains it is 400 pages that are "Unpublished". Problem description and code, or it didn't happen.

thesz 4y ago
Page 5: "The geo-server specification was by nature ambiguos and imprecise, thus leading to some variation in the functionalities of developed prototypes. (On the other hand, the specification is probably typical of that found in practice, especially during requirement acquisition.)" Nevertheless, at Page 6 starts the chapter 3 which aptly named "Problem description". The Haskell code for a problem solution is at Page 15. It is not complete, but it contains examples of what is called "combinators", from whose it is easy to deduce how authors approached the solution. But, one needs to be aware of the notion of combinators and how they are usually constructed. For that, take a look at [1], a construction of parsing combinators. They start with a simple higher-order functional approach just like the solution exemplified in the paper we all discuss here. [1] https://www.researchgate.net/publication/222837975_Combinator_Parsers_From_Toys_to_Tools https://www.researchgate.net/publication/222837975_Combinato...

mk_stjames 4y ago

In reading, it sounds like some of the code for certain languages wasn't even executed/tested? They just had people take a shot at it and then other people reviewed the code informally? It doesn't sound like there were very stringent test cases written beforehand. Also this paper was published by the people who wrote the Haskel version, and the whole thing, once you see that, reads like these guys did a better job in way less time and maybe understood goals better without having attended the first conference. I wish there was documentation of what the actual program and input data looked like. Something this text based.... it almost sounds like you could give it as an Advent of Code day 23 puzzle and somebody will have a Python solution done for it in 45 minutes.

usgroup 4y ago

This reads bizzarely. Awk for creating a server prototype? Haskell as an easy to learn rapid prototyping language? The lines of documentation column -- what is that even? Apparently the lisp version seems to only require 12 lines of documentation whilst the first Haskell version requires 450+ lines?

kazinator 4y ago
If the server can work with just a text input and output stream, and then used as a coprocess, it can be written in anything that has basic I/O facilities. If events have to be multiplexed from multiple sources, that's done outside of the server (and it is clear from the context diagram in the paper). The "Sensors" and "Object Tracking" are outside of the "Geo-Server" block. In the diagram, the Geo-Server takes input from Object Tracking and produces some output as well as a Log. It also takes input from a User Interface, and produces output back to it. Because of that extra multiplexing complexity, a front-end harness layer could be developed: something which interacts with the User Interface, Log, Object Tracking and Deployment, and loads the Geo-Server as basically a plug-in.

tmm84 4y ago

Somethings I like in this paper, 1) the AWK programmer tried to do as many statements as possible in an 80 column row (must have loved one liners in Perl), 2) the Lisp implementation just describes the guy being at the kickoff for 4 hours (doing what?).

Spivasart 4y ago

[dead]

dang 4y ago

Related: Haskell, Ada, C++: An Experiment in Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=19570776 https://news.ycombinator.com/item?id=19570776 - April 2019 (55 comments) Haskell vs. Ada vs. C++ an Experiment in Software Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=14267882 https://news.ycombinator.com/item?id=14267882 - May 2017 (59 comments) Haskell vs. Ada vs. C++ vs. Awk vs (1994) [pdf] - https://news.ycombinator.com/item?id=13275288 https://news.ycombinator.com/item?id=13275288 - Dec 2016 (68 comments) Haskell, Ada, C++, Awk: An Experiment in Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=7050892 https://news.ycombinator.com/item?id=7050892 - Jan 2014 (24 comments) Haskell v Ada v C++ v Awk... An Experiment in Software Prototyping Productivity - https://news.ycombinator.com/item?id=7029783 https://news.ycombinator.com/item?id=7029783 - Jan 2014 (23 comments)

tmtvl 4y ago

I am very impressed that when most languages have a development time in the double digits (including the initial Haskell implementation), the Lisp version was developed in 3 hours. If the codebases are publicly available it would be interesting to see how understandable they are.

nine_k 4y ago
When you don't have to prove your code is correct, and just hope it generally is (a well-grounded hope for an experienced developer), highly flexible and dynamic languages like Lisp or Python or Ruby or Smalltalk will shine. Mistakes which an experienced developer makes are usually trivial and surface during interactive testing, and the development happens in a REPL. Also, simple algorithms and data structures suffice for prototyping like this. The larger the code base, and the stricter the correctness and performance requirements, the more you want to use something like Haskell, or F#, or Typescript, which allow you to exactly pin down and statically ensure certain things.
gleenn 4y ago
What do you mean by "double digit times"? Your whole statement is almost completely lost because I can't tell if you think Lisp is fast or slow. Generally people say Lisps are good at prototyping and I'd agree, Clojure is super fast.
- tmtvl 4y ago
  I'm talking about the table which shows development time in hours, as well as lines of code and lines of documentation. Come to think of it, I wonder if they counted docstrings as documentation or code?
  - lispm 4y ago
    I would guess that they used a very declarative style of Lisp programming, where much of the code looks like a specification. Here they used Common Lisp enhanced with a relational programming model, like an in-core database with an embedded query language. The developer(s) were probably quite experienced with it.

atty 4y ago

So if I’m parsing the results correctly they only have a single data point per language? Seems like they are testing individual programmers styles/speed just as much as they are testing the languages.

AnimalMuppet 4y ago
And individual familiarity with their language. But if you think you can get better data, we'd all love to see it...
- kqr 4y ago
  I haven't reviewed the methodology of this first hit in detail, but here's perhaps some: https://www.researchgate.net/profile/Charles-Knutson/publication/4261726_Do_Programming_Languages_Affect_Productivity_A_Case_Study_Using_Data_from_Open_Source_Projects/links/546223460cf2c0c6aec1a663/Do-Programming-Languages-Affect-Productivity-A-Case-Study-Using-Data-from-Open-Source-Projects.pdf https://www.researchgate.net/profile/Charles-Knutson/publica... I don't think it's this one but I do remember reading a very high quality study arriving at the same result as well.
charcircuit 4y ago
They have 2 data points for Haskell since the one of the authors wrote a Haskell one which happened to have the fewest lines and highest documentation to code ratio.
- tmtvl 4y ago
  They do mention that the one you're mentioning was developed in literate programming style, where the program is a LaTeX document. I wonder what kind of an impact literate programming has on maintenance. Can't imagine rewriting 40 lines of commentary to suit a 2 line code change to be particularly enjoyable.
  - ParetoOptimal 4y ago
    > Can't imagine rewriting 40 lines of commentary to suit a 2 line code change to be particularly enjoyable. I have the expectation of a "simple" 2 lime change that took 24 hours to resolve not require more than 4 lines of commentary. However I fully admit it's not rational and try to work to change it. It helps me to remember the end goal isn't just fixing the problem, but also preserving the biggest gotchas, limitations, and most important lessons learned.

melling 4y ago

30 years ago Haskell was the winner. Conciseness was a major feature. Has anyone put this to the test on larger projects? 10,000 lines of Haskell have the same functionality as 100,000 lines of C++?

Ingaz 4y ago
Hasura (https://github.com/hasura/graphql-engine https://github.com/hasura/graphql-engine) is quite big project. Although it should be less than 100K LOC. It was only once when I saw problem that could be considered a bug.
nine_k 4y ago
Haskell was mere 4 years old in 1994.
simne 4y ago
Haskell is too special, to be used in typical large project. But in real projects, are in wide use other pure functional langs (trying to write most popular first): - Erlang (telco, finance) - Lisp (finance, CAD) - Scala (basically universal) - Scheme (basically universal) - Elixir (frontend) - Clojure (don't know much, looks like also frontend). But in most cases, they are sort of DSL, because functional paradigm is much better in some niches, but not so good in others.
amelius 4y ago
Sounds great except it takes 10x as much time to read/write the Haskell code versus C++.
- MaxBarraclough 4y ago
  Page 9 shows Haskell scoring very well for development time when compared against Ada. C++ development time was unfortunately not reported.
  - synack 4y ago
    Ada projects tend to start slow, but readability and flexible namespacing make refactoring and maintenance much easier.

charcircuit 4y ago

The small sample size and age of the experiment makes it not very relevant to today.

nerdponx 4y ago
It's interesting to think about how this was a selection of the best languages available at the time. Python and Java were brand new!

js8 4y ago

Are there any more recent studies?

Guthur 4y ago

Relation programming is really quite effective for high order problem solving. I've been using prolog recently and found really quite good. I've found myself thinking in terms of ontologies rather than hierarchies, which most over languages encourage. In case it was missed, the lisp in the paper is a rational lisp.

Guthur 4y ago
Errata: rational lisp/relation lisp