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.
12:07:28
drmeister
Does anyone know how to write debugging output from slime that doesn't interfere with its regular communication?
12:11:55
drmeister
I'm putting print statements into clasp.lisp and they appear to be messing up slime and causing it to segfault.
12:12:55
drmeister
For instance, I add ... (format *trace-output* "Raw backtrace length: ~a ~%" (length (core:clib-backtrace-as-list))
12:14:37
drmeister
I assume printing to *trace-output* is causing some kind of weird interference with the swank protocol
12:15:58
jackdaniel
you may cause an error in error printer, what leads to new errors, which invoke error printer, what leads to new errors, which invoke error printer, what leads to new…
12:17:57
drmeister
printing to +process-standard-output+ now sends the output to *inferior-lisp* but it still crashes the same way - grrrrrr.
12:20:00
drmeister
Ok - I made a mistake in where I put the statement - I'm debugging not fully awak.
12:24:05
drmeister
jackdaniel: Thank you - I can generate debugging info without interfering with swank - I can debug this now.
12:53:24
drmeister
There aren't any fundamental problems. I think it's that the build system has changed and the demos haven't kept up.
12:53:54
drmeister
I have a site visit from the Department of Defense next Tuesday and so I won't be able to look at it until after that.
12:54:31
drmeister
I would really like to get gsl exposed as well as the Bloomberg graphing widgets within the Jupyter notebook interface that we have developed.
12:55:27
drmeister
I'd like to turn Clasp/Cando into something better than SciPy, NumPy, Matlab - with all of the scientific code exposed but accessible from a fully compiled programming language.
13:03:17
drmeister
Merging info from clib backtrace/backtrace_symbols, a Common Lisp shadow stack and information captured from the JIT engine.
13:25:25
Kevslinger
Kevin has been wanting to create tests to find some sort of objective metric across languages
13:25:49
Kevslinger
That way, by the time he’s ready to retire, he’ll know which programming language he should’ve been learning his whole life :-)
13:30:01
Shinmera
In my opinion helping people in giving up on pointless things, or in the very least helping them turn something pointless into something worthwhile is a good idea.
13:31:44
Kevslinger
Shinmera: I agree completely. I was only kidding (I have very little desire to be the one who coordinates some sort of tests for that) :)