Lisp as an Alternative to Java (2000) [pdf](flownet.com)
flownet.com
Lisp as an Alternative to Java (2000) [pdf]
http://www.flownet.com/gat/papers/lisp-java.pdf
22 comments
https://news.ycombinator.com/item?id=8446368
> Prechelt compared multiple implementations of the same task by multiple programmers in order to control for the effects of differences in programmer skill.
It would be interesting to compare these programmers' salaries as well. I think that a lot of companies would still make a completely rational decision to stick to Java after such an analysis.
It would be interesting to compare these programmers' salaries as well. I think that a lot of companies would still make a completely rational decision to stick to Java after such an analysis.
Rational, yes. Prudent, no. As a corporation, developer salaries is not where you want to be trying to save money in your budget, because having your software produced by low-quality talent is cause you to spend much more money on maintaining poorly designed and poorly tested codebases in the long run. Hence why it's 2015 and we still have people working in COBOL, and writing Java code that interfaces with it.
And several of Paul Graham's essays mention this--using a language other than Java (or C++) can actually be an advantage in hiring because those are languages that many people learn just to get a job, so the quality of the candidate base is lower on average, whereas if you're hiring for a Lisp hacker, you're going to get applicants who are genuinely passionate about programming. Then you also get the benefit of Lisp being a more expressive language that's faster to develop features in.
And several of Paul Graham's essays mention this--using a language other than Java (or C++) can actually be an advantage in hiring because those are languages that many people learn just to get a job, so the quality of the candidate base is lower on average, whereas if you're hiring for a Lisp hacker, you're going to get applicants who are genuinely passionate about programming. Then you also get the benefit of Lisp being a more expressive language that's faster to develop features in.
Doesn't the result of this argument rest on empirical evidence more than anything?
There must be some point at which the salary/talent tradeoff doesn't make sense. Take a team of half a dozen developers each with a million dollar salary. They'd be the best of the best, sure, but it's probably not the best deployment of resources.
Alternatively, consider a team of dozen unpaid interns. They're also probably too expensive.
Figuring out the correct mixture of talent and money is a hard problem, and companies are built on getting that right. And although it might be a good ego-stroke to think "expensive awesome programmers provide a lot more value than cheap competent programmers," it needs evidence, and the evidence for it probably varies in different contexts.
There must be some point at which the salary/talent tradeoff doesn't make sense. Take a team of half a dozen developers each with a million dollar salary. They'd be the best of the best, sure, but it's probably not the best deployment of resources.
Alternatively, consider a team of dozen unpaid interns. They're also probably too expensive.
Figuring out the correct mixture of talent and money is a hard problem, and companies are built on getting that right. And although it might be a good ego-stroke to think "expensive awesome programmers provide a lot more value than cheap competent programmers," it needs evidence, and the evidence for it probably varies in different contexts.
There are plenty of worse things to rest on besides empirical evidence. Indeed, it is a shame that empirical evidence is not more heavily weighed, for some of us.
For sure. The talent/cost relationship is a curve and you want to find an optimum point somewhere in the middle rather than maximize or minimize on one axis only.
Exclusively hiring Java devs at below-market salary, as a lot of Fortune 500 companies do, is equivalent to a strategy of minimizing the salary axis while ignoring the talent axis.
Meanwhile in my day-to-day experience at work I am perfectly comfortable with making the generalization that "expensive, awesome programmers provide a lot more value than cheap, barely-competent programmers," because I personally have to work with the product of cheap, barely-competent programmers five days a week, so I know what an unmaintainable mess it is.
Exclusively hiring Java devs at below-market salary, as a lot of Fortune 500 companies do, is equivalent to a strategy of minimizing the salary axis while ignoring the talent axis.
Meanwhile in my day-to-day experience at work I am perfectly comfortable with making the generalization that "expensive, awesome programmers provide a lot more value than cheap, barely-competent programmers," because I personally have to work with the product of cheap, barely-competent programmers five days a week, so I know what an unmaintainable mess it is.
Isn't these days there's a lot of hype in programming languages (no matter what they are)?
I mean, people hyping Erlang and mentioned WhatsApp a lot but never actually bothered to check that Rick Reed is just plain smart and have strong theoretical knowledge and lots of practical experience in System level work (he did C++, as you mentioned, while working for Yahoo)?
Also, nobody knew how smart and knowledgeable the WhatsApp team w.r.t to full-stack (like literally Full-stack, FreeBSD kernel/driver, Storage knowledge, Networking stack/low-level code, up to Erlang VM tweaks/patches/fixes).
Facebook, on the other hand, had to re-write their Messenger to C++ due to "lack of Erlang expertise". Somehow that recruiting aspect of the argument is lost somewhere in my book...Facebook couldn't possibly failed to attract smart Erlang developers.
Whenever I see people using Ruby or Python writing just CRUD web-apps but getting praised as better programmers than their Java counter-part seems a bit sad/unfortunate to me.
Java does have tons of programmers ranging from incompetent up to very competent (http://martinfowler.com/articles/lmax.html, lots of infrastructure component being written in Java: Hadoop, Cassandra, to name a view, Martin Fowler wrote the seminal Enterprise Application Architecture that most web-apps implement, LinkedIN build lots of infrastructure tools, NetFlix too).
I don't know...
I mean, people hyping Erlang and mentioned WhatsApp a lot but never actually bothered to check that Rick Reed is just plain smart and have strong theoretical knowledge and lots of practical experience in System level work (he did C++, as you mentioned, while working for Yahoo)?
Also, nobody knew how smart and knowledgeable the WhatsApp team w.r.t to full-stack (like literally Full-stack, FreeBSD kernel/driver, Storage knowledge, Networking stack/low-level code, up to Erlang VM tweaks/patches/fixes).
Facebook, on the other hand, had to re-write their Messenger to C++ due to "lack of Erlang expertise". Somehow that recruiting aspect of the argument is lost somewhere in my book...Facebook couldn't possibly failed to attract smart Erlang developers.
Whenever I see people using Ruby or Python writing just CRUD web-apps but getting praised as better programmers than their Java counter-part seems a bit sad/unfortunate to me.
Java does have tons of programmers ranging from incompetent up to very competent (http://martinfowler.com/articles/lmax.html, lots of infrastructure component being written in Java: Hadoop, Cassandra, to name a view, Martin Fowler wrote the seminal Enterprise Application Architecture that most web-apps implement, LinkedIN build lots of infrastructure tools, NetFlix too).
I don't know...
The total number of professional Java developers in the world is estimated at 9-10 million. So if you're a large corp that has a lot of positions to fill you are going to be tempted to hire for Java devs. But unless you're offering a truly amazing opportunity (like a real-time trading app, which a mediocre dev wouldn't be allowed to touch), you are just going to get bombarded with mediocre resumes, and the most competent Java Dev you can hire on your budget is going to build boring CRUD software slowly, with lots of boilerplate and null checks, and overuse of GoF patterns and XML frameworks, because that is just how the Java ecosystem works.
Cranking out RoR apps is nothing special either, and there are plenty of barely-competent Rails devs on the market, but at least Rails actually makes simple CRUD apps simple to build. Why pay someone to fuck around with configuring Hibernate all day when they can get the same job done in a few minutes with ActiveRecord? It only makes sense if you're a megacorp that has a budget for salary but no meaningful way to measure productivity.
Yes, there are good devs and bad devs in any language community, and no developer is successful or fails just because of their language preference. But Java has its reputation as a bureaucracy-oriented programming language for good reason.
Cranking out RoR apps is nothing special either, and there are plenty of barely-competent Rails devs on the market, but at least Rails actually makes simple CRUD apps simple to build. Why pay someone to fuck around with configuring Hibernate all day when they can get the same job done in a few minutes with ActiveRecord? It only makes sense if you're a megacorp that has a budget for salary but no meaningful way to measure productivity.
Yes, there are good devs and bad devs in any language community, and no developer is successful or fails just because of their language preference. But Java has its reputation as a bureaucracy-oriented programming language for good reason.
because companies like to pay higher salaries?
https://gooroo.io/GoorooTHINK/Article/16225/Programming-lang...
If anyone wants to read either of Lutz Prechelt's papers, see the original C/C++/Java [1] and the Perl/Python/.. followup [2]. I wish the program sources were available, if only to see if any of the Perl submissions are as readable as Norvig's lisp [3].
[1] http://www.ebhakt.info/dl/Comparejavaandc_D9F7/compare_java_...
[2] http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf
[3] http://www.norvig.com/java-lisp.html
[1] http://www.ebhakt.info/dl/Comparejavaandc_D9F7/compare_java_...
[2] http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf
[3] http://www.norvig.com/java-lisp.html
How good was Java's JDK 1.2 JIT? Probably not good.
Jit came with 1.3.1 if I recall. Of course the real question is if lisp is that good why aren't more people using it? Including the people who know about lisp and java?
> if lisp is that good why aren't more people using it?
Rewrites being uncommon, companies use the language that they started in. Start-ups use hyped languages that are considered good for the job in the current environment, in order to attract interest and inspire trust in their judgement.
Languages that were frowned upon can go back into favour; JS did. However, it only did so thanks to both the success of the platform it was on and a functional language committee. Lisp has neither, and is therefore unlikely to rise to fame.
If a company made a platform which recommended Lisp, and if a language committee rose to modernize the language and stifle innovation, it would start getting hype. I cannot see the future, but it seems unlikely, regardless of its technical merit.
Rewrites being uncommon, companies use the language that they started in. Start-ups use hyped languages that are considered good for the job in the current environment, in order to attract interest and inspire trust in their judgement.
Languages that were frowned upon can go back into favour; JS did. However, it only did so thanks to both the success of the platform it was on and a functional language committee. Lisp has neither, and is therefore unlikely to rise to fame.
If a company made a platform which recommended Lisp, and if a language committee rose to modernize the language and stifle innovation, it would start getting hype. I cannot see the future, but it seems unlikely, regardless of its technical merit.
I'm trying via Clojure.
In general it seems that Lisp suffered from a closed ecosystem. I know that there are tons of simple Lisp interpreters for free. But there weren't any really good ones for free 10ish years ago with a permissive license. Take the Allegro CL used in the paper. The free version doesn't allow commercial use [1].
Sure, you could do things with LISP as we've seen with PG, but it's not anywhere as practical as Java was near it's inception. Java was free to use for whatever you wanted. It was quickly improving VM. Verbose < money.
[1]http://franz.com/downloads/license.lhtml
In general it seems that Lisp suffered from a closed ecosystem. I know that there are tons of simple Lisp interpreters for free. But there weren't any really good ones for free 10ish years ago with a permissive license. Take the Allegro CL used in the paper. The free version doesn't allow commercial use [1].
Sure, you could do things with LISP as we've seen with PG, but it's not anywhere as practical as Java was near it's inception. Java was free to use for whatever you wanted. It was quickly improving VM. Verbose < money.
[1]http://franz.com/downloads/license.lhtml
In the 15 years since this was published, maybe it's more accurate to talk about the family of languages, rather than just Lisp itself. I imagine that together all of the Lisps represent a lot more of the language popularity long tail then one might think. Of course this is just a hunch and I have no data.
Also, Clojure seems pretty trendy among certain circles these days, which is a Lisp on the JVM (and Python, JS, etc).
Also, Clojure seems pretty trendy among certain circles these days, which is a Lisp on the JVM (and Python, JS, etc).
Some of the memory overhead is intrinsic to the language: every object can be synchronized on.
One word. Clojure.
Two words. Android Runtime.
n*2 words: I don't get it?
Java works on Android Runtime (ART). Clojure barely works on dalvik, let alone ART.
[deleted]
I tried to like LISP many times since the 1980's when I was experimenting with it on the side, it just did not click for me like C/C++/Java/C#.