5 ms·
I am Ron Garret (f.k.a. Erann Gat), the author of the followup study mentioned in TFA. I am, frankly, amazed that this work is getting the amount of attention
by lisper 5y ago
I am Ron Garret (f.k.a. Erann Gat), the author of the followup study mentioned in TFA. I am, frankly, amazed that this work is getting the amount of attention that it is over 20 years after it was published. I have a couple of comments about this latest critique.
> Given that the participants were recruited from internet groups, I doubt that the subjects were monitored in place, which makes me think that the Development time data collected should be taken with a giant grain of salt.
> Based on a small study like Garret’s, I find that the premise that Lisp is so great is unwarranted.
That's a fair criticism. In my defense I will say that I didn't actually claim that Lisp is great, only that it seems plausible that it might offer the development speed and runtime safety advantages of Java and the execution speed of C, and so it is worth paying some attention to it, and maybe doing further studies. I certainly believed (and continue to believe) that Lisp is great, but I certainly concede that my data didn't (and doesn't) prove it. Renato seems to agree:
> However, the data does suggest that Lisp is about as productive as the scripting languages of the day and has a speed comparable to C and C++, which is indeed a remarkable achievement.
FWIW, my study was a throwaway side-project conducted on the spur of the moment in my spare time. It was intended more to get people's attention and make the case that Lisp ought to be considered alongside Java as an alternative to C than to be a rigorous scientific case for Lisp's superiority over Java. At the time, Lisp was quite a bit more mature than Java, and indeed one could have argued (and indeed could argue today) that Java was an inferior re-invention of many of the ideas that Lisp had pioneered, with automatic memory management being at the top of that list. I was frustrated that Java was getting all the attention because it was the shiny new thing and Lisp was being ignored because at the time Java actually sucked pretty badly. (IMHO it sucks pretty badly today too, but that is now a much harder case to make.)
In any case, what astonishes me most is that AFAICT no one has ever done a follow-up to either of these studies that was better designed and used more rigorous methods. Instead, people just seem to keep citing these papers again and again as if squeezing these turnips harder might yield something worthwhile now that could not be extracted from them when they were first published.
This is a very fertile field for further research. Someone should cultivate it.
- 37ef_ced3 5y agoWhat do you think of Go (particularly as an alternative to C and C++)?
- exdsq 5y agoOn a similar note, what about Rust?
- lisper 5y agoI am not very familiar with either one (I've read about them both but never written any code) so I can't really answer that. Same for C#, F#, Swift, in fact, pretty much anything that has come out in the last 10 years. Old dog, new tricks, something something... I will say, however, that IMHO just about anything is better than C++, including C.
- Gibbon1 5y agoA random anecdote back in the early 90's I worked with a mad lad self taught non-degreed engineer. He did an embedded project where faced with memory constraints based on unit cost. Ported a lisp interpreter to PIC assembly[1] and then write most of the code in lisp. Performance was about 1/2 to 1/5 that of straight C[2]. But the memory footprint was about 50% less. Which meant it fit into flash. He went on to use that for a few other products. [1] Took him three months to port it. [2] A 50% difference in speed usually doen't cause firmware to fail performance metrics.
- jhgb 5y agoSounds like there's a decent chance that one could achieve similar things with something like Modula's M-code. Also compressing a large program into a small computer by having a part of the program written in compact interpreted code dates back at the very least to Apollo's Guidance Computer's INTERPRETER component.
- kragen 5y agoCompressing a large program into a small computer by having part of the program written in compact interpreted code dates back at least to Short Code on the UNIVAC I in 01950, which was "short" because it could fit six instructions per machine word instead of the usual two. Of course Turing's original hypothetical Universal Machine from 01936 is "universal" precisely because it is an interpreter that can emulate any computing machine, most importantly including itself, but you could reasonably object that Turing didn't actually build a working Universal Machine in the 01930s, and at any rate he wasn't concerned with the question of how to fit a lot of functionality into a small amount of RAM. I've seen references to "Turing's 'short code'" and to "ENIAC Short Code" but I am not sure if they are things that really existed or if someone was just getting their references confused.