[HN Gopher] Revisiting Prechelt's paper comparing Java, Lisp, C/...
___________________________________________________________________
Revisiting Prechelt's paper comparing Java, Lisp, C/C++ and
scripting languages
Author : mahmoudimus
Score : 63 points
Date : 2021-08-08 18:19 UTC (4 hours ago)
(HTM) web link (renato.athaydes.com)
(TXT) w3m dump (renato.athaydes.com)
| robertwt7 wrote:
| It's interesting that even a system programming language like
| rust is actually not faster than java if not written /
| implemented correctly. People always thought that when they
| needed to go faster they go for c++/rust. I guess advance
| knowledge in one programming language is better than switching to
| another one in the case where you need to make your app faster
|
| Also isn't this similar to this study? https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| lisper wrote:
| 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.
| Gibbon1 wrote:
| A 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 wrote:
| Sounds 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.
| klipt wrote:
| I've heard FORTH is also good for that kind of embedded
| higher level programming. The interpreter is probably simpler
| to implement than lisp.
| zerr wrote:
| > and the execution speed of C
|
| Which implementation of Lisp did you use and how did you
| build/deploy the code? How idiomatic the code was? e.g. was it
| C-like code but in S-expressions? (imperative, for loops, in-
| place modifications, no high level abstractions, etc... but I
| guess this also might count as "idiomatic Lisp" in some
| circumstances)
| lisper wrote:
| Back in the day different submissions used different Lisps.
| Some used CL, some used Scheme. Unfortunately, I don't recall
| the details, and I can't find my records (this was over 20
| years ago). If I do come across them I'll post a followup
| here.
|
| I can tell you this: I currently have a consulting gig where
| I help maintain a tool for designing state-of-the-art ASICS
| which is written in Allegro Common Lisp. It is definitely
| competitive with C in terms of run-time speed.
| [deleted]
| 37ef_ced3 wrote:
| What do you think of Go (particularly as an alternative to C
| and C++)?
| exdsq wrote:
| On a similar note, what about Rust?
| lisper wrote:
| I 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.
| hyperman1 wrote:
| I'd like to hear your opinion about the following vision of
| language comparisons:
|
| Lisp as a language is much more malleable to the problem at
| hand. This will mean it will attract a small group of smarter
| people, but create code which is harder to read and hence
| harder to give to other people. Hence, lisp programs tend be
| smaller, more creative, better quality, faster to create, but
| also to stagnate when their creators leave.
|
| Java, more recently Go, and maybe even Cobol, attract a bigger
| group of more average people. They'll write in a simpler, more
| standardized style. The programs tend to be more bureacratic,
| average, less optimized, but also much more readable. They are
| the better choice when you need maintainability over a long
| time by a varied group of programmers.
|
| I don't remember where this came from, it's certainly not my
| own idea. It doesn't sound completely bollocks, but have no
| idea if its true or not.
| fiddlerwoaroof wrote:
| I'm not the person you're asking, but I've spent a bunch of
| time fixing bugs in other people's lisp libraries and haven't
| found this to be true at all. If anything, because Lisp
| encourages you to adapt the language to the problem domain,
| others people's code tends to be easier to understand because
| the code tends to use names and constructs that makes sense
| to someone that understands the problem domain.
| lisper wrote:
| Yes, I agree with this.
|
| Lisp is tremendously powerful, and like all power, it can
| be abused. But when used properly it can produce some very
| easy-to-read and maintainable code precisely because of its
| malleability.
|
| Take a look at this for example:
|
| https://flownet.com/ron/lisp/djbec.lisp
|
| In that code I used an embedded an infix parser and macros
| to allow me to write modular bignum arithmetic expressions
| as infix. That lets me cut-and-paste the infix versions of
| elliptic curve point addition algorithms and use them
| directly without translating them into s-expressions, which
| eliminates the possibility of transcription errors. The
| resulting code is much easier to read than if I'd had to
| actually translate all the modular math into standard
| Common Lisp.
| ssivark wrote:
| Something I'm struck by in reading such discussions (esp on
| forums) is how often people's choice of programming languages
| (and tools, more generally) is from a defensive stance. I
| understand that when working on problems where better
| technology is unlikely to lead to significant advantages (so
| you'd prefer to cap the potential downsides), but I'm still
| surprised by the sheer paucity of examples where people are
| willing to make aggressive technology choices to get leverage
| on their goals. I wonder whether that's another manifestation
| of the blub paradox.
| fungiblecog wrote:
| The Java program may be more readable in small snippets but a
| large Java program is often completely incomprehensible
| because the overall structure doesn't map well to the problem
| being solved. A lisp program with comparable functionality
| can be much smaller and more comprehensible due to the
| ability to mould the language to the business problem.
| pharmakom wrote:
| Yes!!
|
| Java programs often have so many classes, methods and
| interfaces that it's hard to comprehend the overall flow of
| the application. Terse languages (lisps and MLs come to
| mind) can often solve the same problem in a single page.
| quantified wrote:
| +1. "Let's distribute all our algorithms in tiny chunks
| everywhere" seems to be the goal of some code bases. It's
| unnecessary, you can control data and algorithm
| differently in most cases.
| btilly wrote:
| I remember loving these papers back in the day.
|
| First, I would be far less skeptical than this author is over the
| tradeoffs of scripting languages. Given the tools offered by
| scripting languages, there is one obvious way to do things. The
| overhead of building a fancy "just right" data structure almost
| always makes things perform worse than the straightforward
| solution using dictionaries, arrays and scalars. Given that,
| people go directly to that solution, leading to less variation in
| length of code, time and performance. It is always possible to
| beat a scripting language's performance, but a surprising number
| of programmers won't.
|
| This is a lesson that generation after generation of programmers
| have learned in a variety of scripting languages. With the latest
| winner being Python. But the differences between popular
| scripting languages generally matter a lot less than the
| commonalities. (There are exceptions, specialized languages like
| Lua, R and Julia have very specific strengths and weaknesses
| despite being aimed at scripting.)
|
| Second, there are two basic reasons why Lisp loses.
|
| The first is the disadvantage of being an image based system.
| This has a lot of upsides, but the downside is that people lose
| access to a long toolchain that they are used to for dealing with
| files. Tools including editors, source control, and so on.
| Programming expertise is fragile, and that is a pretty big shock.
|
| The second is that Lisp attracts people who want a perfect
| language. Unfortunately people's ideas of perfection different.
| So we get a large number of related dialects of Lisp, which are
| almost compatible with each other. And fail to get critical mass
| behind any of them.
|
| That said, how big a deal is achieving critical mass? Well
| obviously it matters. If you're using a mainstream language you
| can find packages for things that you need, answers on
| StackOverflow, and so on. But there are diminishing returns. The
| size of CPAN didn't keep Ruby from rising, and JavaScript and
| Python in turn have seen meteoric growth.
|
| But that said, there is a fundamental tradeoff. Working in a
| popular language matters more if you're planning on leveraging
| lots of existing work. The more your project is building on what
| you yourself have built, the less important the easy start of
| external packages is relative to your own development
| familiarity. The more specialized the thing that you're building,
| the more it makes sense to use the perfect language for you/your
| space, rather than going with what's popular.
| pfdietz wrote:
| Common Lisp implementations typically aren't image based
| systems, although one can dump images. Code is in files, which
| are loaded. The typical workflow involves modifying files,
| compiling/loading the changed files and their dependencies
| (using asdf), and running tests. Nothing persistent is in the
| image.
| jeffbee wrote:
| I've been asked to whiteboard this or very similar problems in
| 45-minute job interviews. Based on my experience in those
| interviews I am not surprised to see it typically takes 3-10
| hours to do a proper job of it.
| amusedcyclist wrote:
| I mean of course Java is slower if you're including JVM start up
| time. A more modern version of the problem would ask for a
| service which performs the same function and averages time taken
| over N requests. I suspect modern java would look pretty close to
| C++/rust there
| bluejekyll wrote:
| This is always an interesting question, about including the JVM
| startup time or not. In this context doesn't it seem like the
| JVM startup time should be included?
|
| During JVM startup, one thing it's generally doing is
| allocating space for the heap from the OS. For the C/C++/Rust
| application, this could be implemented either as a large arena
| allocation, or allocations inline during the program. That is a
| programming choice, but the allocation cost is still there. It
| would be unfair to not include that allocation for Java whereas
| always including it (whether inline or upfront) in the native
| C/C++/Rust versions.
|
| For long lived programs, like server-side things, the JVM
| startup time probably isn't relevant, but for short lived
| programs, it seems reasonable to include the startup time as
| that would be part of the time running the program from the
| CLI.
| zmmmmm wrote:
| > for short lived programs, it seems reasonable to include
| the startup time
|
| but then one can say, if the whole problem is so trivial that
| startup time is a significant chunk of the execution then is
| it really a problem worth optimising in the first place? The
| only situation where it would matter is if you are putting
| this in a tight loop on the command line or something like
| that (which is a thing, but its a reasonably small thing).
| bch wrote:
| John Ousterhout (creator of Tcl (mentioned in OP paper)) also
| wrote an interesting paper about the "scripting" vs "system"
| language dichotomy, "Scripting: Higher Level Programming for the
| 21st Century"[0] which some may find interesting.
|
| [0] http://users.ece.utexas.edu/~adnan/top/ousterhout-
| scripting....
___________________________________________________________________
(page generated 2021-08-08 23:00 UTC)