freenode/#clasp - IRC Chatlog
Search
3:54:02
beach
It is the only documentation I have ever seen of an experiment to compare the productivity of different programming languages.
6:14:35
phoe
Do you mean https://www.cse.iitk.ac.in/users/karkare/courses/2010/cs653/Papers/hudak_haskell_sw_prototype.pdf ?
6:17:44
beach
They basically conclude that Haskell is great and the timing for "relational Lisp" is weird and can't be trusted.
6:19:19
beach
I interpret the result like this: Any project leader who does not take into account the possibility that there might be a huge difference in productivity of different languages (for the project at hand) should be fired. They should especially take into account the savings of a productivity gain vs the cost of training or hiring staff.
8:46:00
phoe
They don't say that Lisp can't be trusted. They simply favor Haskell and say nothing about Lisp other than mentioning that it had 3/8 of Haskell's dev time and performed decently in their benchmarks.
8:48:02
beach
To me that means, "If they had taken time to write documentation, it would not have been this low, so we can't trust this result"
8:49:59
phoe
It's possible to quickly hack something in Lisp that works but is hard to understand afterwards. It takes skill to immediately write Lisp that does not look like a hack.
8:52:29
beach
Look phoe, I already said that I don't interpret the result of this paper as a statement about the productivity of the languages in the test.
8:53:39
beach
I specifically said that I interpret the result as a statement about the potentially huge difference in productivity for different languages RELATIVE TO A PARTICULAR TASK. The order may change when the task changes.
8:54:45
beach
When I present this paper in one of my talks to industry, I just emphasize that you should not choose a language based on whether you already have programmers how know it, because you can then be wrong by an order of magnitude.
8:55:14
beach
Because the paper shows that it takes very little time to learn a new language sufficiently well to be fairly productive.
8:55:48
beach
And it shows that the difference in productivity between a language adapted to the task and one that isn't can be as high as a FACTOR 20.
8:56:39
heisig
The whole paper is extremely questionable. Fun fact: It contains the word 'Lisp' only 5 times, compared to 12 occurrences of 'Ada' and 40 occurrences of 'Haskell'.
8:57:00
beach
Now, even if you don't believe it is that much, even if it is only a factor 1.2 (i.e. 20%, which seems modest in view of the results) then that means that a 5 year project can be done in 4 years, if you change the language, leaving you 1 year to train your staff. And then you have staff that know one more language.
8:58:13
beach
heisig: Also, they fully admit that it is not good enough to provide scientific evidence for a particular language.
8:58:38
heisig
beach: Sure. Just interesting to see how some people completely fail to cloak their bias.
8:59:16
beach
Yeah, well. They are Haskell people after all. That was the point of the paper, i.e. show how good Haskell is.
9:06:13
heisig
jackdaniel: You are right. The paper nevertheless saddens me - how shall we ever reach consensus on programming methodology when no one is willing to question his own position. (Says the hardcore Common Lisp programmer :) )
9:07:52
beach
heisig: It is psychologically extremely difficult to question one's position, when it has taken years or decades to establish.
9:09:20
beach
It has to contain several different types of projects, several different levels of staff training, etc.
9:09:55
beach
The projects have to be non-trivial and must require several developers and several years of development.
9:10:37
beach
Until someone is willing to do that, we won't have any real idea of the difference between languages.
9:12:17
jackdaniel
I think I've read a paper at some point of time, where independent teams were implementing the same specification in parallel
9:14:24
heisig
I had an idea for a comparison technique recently: You always consider two languages A and B. Then you take a small group of experts of A and experts of B. The B experts spend 2-5 years learning and using A and vice versa. In the end both teams have to solve the same complex task. Finally, they discuss their experiences and write them town together.