6 ms·
Lisp as an Alternative to Java
- jdludlow 15y agothe directions said to code as you would professionally I'm curious to know if anyone wrote test cases for their code. I didn't see any here, but maybe they are in a separate file or weren't allowed to be submitted to the study.
- dextorious 15y agoTest cases were not that fashionable back in the day. Surprisingly, people still got work done.
- mjb 15y ago> Test cases were not that fashionable back in the day. Surprisingly, people still got work done. Reinforced concrete did not exist back in the day. Surprisingly, some people still got work done. It's tempting to be dismissive of modern development practices (TDD, for example) using the argument that a lot of great software was written before it existed. If the icons of the past could write Unix without TDD, why do we need it to build a CRUD app? This is an extremely poor argument against improving development practices. People were getting building done before reinforced concrete, doing particle physics before synchrotrons, and designing mechanical devices before CAD. Since we have had these things, however, each of these fields has advanced significantly due to their use. It would certainly be possible to design the complex solid forms of something like an iPad without CAD, but it would be much more difficult and expensive. It's the same way with development practices. Modern development approaches, in many cases, significantly reduce the cost and risk of software development.
- tomjen3 15y agoDon't confuse writing unit-tests with TDD. TDD requires unit-tests, unit-tests do not require TDD. And unit-tests don't require writing unit-tests for everything.
- Silhouette 15y ago> Modern development approaches, in many cases, significantly reduce the cost and risk of software development. I'm sure some do. For others, a lot of people claim they do, but there is precious little empirical evidence to support the claim. Many practices associated with Agile are poster children for that second group, including TDD.
- dextorious 15y ago"""People were getting building done before reinforced concrete, doing particle physics before synchrotrons, and designing mechanical devices before CAD. Since we have had these things, however, each of these fields has advanced significantly due to their use.""" I actually like the achievements of each of these fields better, way before those technological advances. Reinforced concrete architecture sucks compared to the marvels of times past, particle physics were more interesting back in the day of the Copenhagen boyz, and I like pre-cad mechanical devices, from cars to watches, better than what we get today. But that's just me.
- SomeOtherGuy 15y ago>It's tempting to be dismissive of modern development practices (TDD, for example) using the argument that a lot of great software was written before it existed. It is even more tempting to be dismissive because there is no evidence to support the notion than TDD is in any way helpful, and there is evidence that suggests it does not help at all.
- igouy 15y agoLest we forget - IEEE Standard for Software Unit Testing Approved December 11, 1986
- pearle 15y agoIs this an older article or something recent? A 1999 paper is referenced but the article itself does not seem to have a date.
- geebee 15y agoYeah, and Java is referred to as "3-4 times slower than C++", which makes me think it's probably from the late 90s or early 00s. That said, most of the arguments for Java around improved speed might apply to any language that runs on the JVM, though someone else might want to chime in here (I'm a little out of my depth trying to talk about how Lisp, Ruby, etc are implemented on the JVM).
- dextorious 15y agoActually, for a programming genius, those exact comments in the article seems lazy and ignorant.
- deleted 15y ago[deleted]
- tomjen3 15y agoUnfortunately the JVM is optimized for Java, rather than for computer languages in general. This is a problem because you can't just say execute function 'foo' on object bar, you have to look up the type of bar to find foo and then execute it. Clojure gets around this by having all its functions implement a standard interface, and Java 7 has sorta seen the light (still no closures, but they can kind be emulated). JRuby just suffers.
- mark_l_watson 15y agoThis is an old article but still relevant, especially since Clojure allows co-mingling Java and Clojure (Lisp) code. I find Clojure especially useful on my own projects because there are no problems finding developers or getting customer approval for using a very nice, but niche language. I still like (J)Ruby a lot but the runtime performance of Clojure is better and the two languages seem, to me, to be equally "agile" - both are a pleasure to code in.
- jasonjackson 15y agoYou've found it easy to hire people with existing Clojure experience? That surprises me, great news though.
- dpritchett 15y agoHe is saying that he uses Clojure for personal projects because those are the projects where he doesn't have to recruit for or justify his choice of a niche language.
- mark_l_watson 15y agoThanks, that is exactly what I meant.
- JoeCortopassi 15y agoI'm guessing what he means is that, because Clojure can work so well with Java, he doesn't have to find people with Clojure experience to help on a Clojure project, he can just get Java people (of which there is an abundance).
- rbanffy 15y agoGetting customer approval is often the hardest part. Back in 2002 I started working with Python and Zope. It was easy to hire and train people in Python and Zope (you can pick up Python in an afternoon and work from there), but it was mindbogglingly hard to convince customers the data not being in a relational database was, actually, an advantage.
- aninteger 15y agoIt's 2012. There is an alternative to Java. It's called C#
- tomjen3 15y agoYeah, but it is not really relevant in this context. The distance between C# and Java is much, much smaller than between lisp and any member of the C family (except objective C).
- rbanffy 15y agoC# and Java are very close. I wouldn't be surprised if the numbers - LoC, performance and time-to-develop - were very similar to the Java ones. The article states the Lisp code is significantly smaller and development was much faster. I don't see how C# could approach Lisp even adjusting for the fact it's Peter Norvig writing it.
- scarmig 15y agoWell, "very close" might be an exaggeration. C# has lazy evaluation, generators, LINQ, generics, and functions as first class citizens, while Java has... none of those. Or what amounts to none of those. Overall C# ends up being a much more expressive language. Though obviously C# and Java are closer than C# and Lisp.
- bborud 15y agoI can imagine that Lisp without the shitty attitude would be great. The shitty attitude that elegance and purity is so much more important than actually being able to talk to the environment a program runs in.
- tikhonj 15y agoWhy do you think that Lisp programs can't talk to the environment? Also, even if you couldn't, flippantly dismissing "elegance and purity" as a "shitty attitude" is not very constructive.
- bborud 15y agoHaving a shitty attitude is not constructive. Pointing out the shitty attitude may be rude and unpleasant, but people have to be realistic. The Lisp community, as I have experienced it, has a shitty attitude towards people who might have criticisms or have a more pragmatic approach. (And I am not a Ruby nut. For crying out loud, Ruby is such a sloppy, pointless direction to take things in that we might as well stick to Perl -- which for the most part was at least faster). I made a couple of attempts at getting real work done in Lisp, and Lisp derivatives in the past. What almost always ended up making life miserable for me was that doing IO in Lisp was painful. And when you write networked server software, you do care about IO. Quite a lot actually. There was no way to write performant networked servers in Common Lisp in a way that was portable across implementations. And the amount of abuse I took when I pointed out that this was a fairly severe limitation told me that I was dealing with people whose world view may not be perfectly aligned with what is needed to build a following. For all I know, there may be a perfectly portable way to do highly performant networked IO in Common Lisp today. But that is of no importance. Because what I remember of the Lisp community is that they don't like strangers and they are really big on authority and rank. But the Lisp world isn't just Common Lisp, it is things like Scheme as well. And what a load of nonsense the early Scheme days were. Again, all they cared about was the inner nuts and bolts. Actually caring for the parts of the language that INSPIRES people do use it wasn't even part of the plan. You know what: having a standard library that does useful stuff isn't raving lunacy. it is actually a quite good idea. Java may be just a gradual evolution from the transitional languages of the late 80s and early 90s, but it was the first language to have a fairly decent standard library. Python may have been clumsy and filled with warts, but you could do things with it right away. Ruby may have been a giant step back and an exercise in excessive masturbation over a single idea, but even though it was fairly crap it let people do things. Heck, even a hack like Javascript is doing well. Occasionally Lisp'ers tell me that things have gotten better. That the Lisp community has become more pragmatic. That "we get it now" and that bloated egos might even consider learning something from other communities. Well, then why isn't everyone suddenly rushing to use Lisp? Because, you know what: people are pretty open minded about languages these days. It is like 1968 of programming languages. Everyone is in bed with everyone else. So downvote me all you want. And write bitter articles about how stupid the rest of the world is. Go on, it is a great way to limit your followers to people who are just like you and to keep new ideas out.
- discreteevent 15y agoThe following are taken from: http://news.ycombinator.com/item?id=1803351 http://news.ycombinator.com/item?id=1803351 ----norvig 449 days ago------ Peter Norvig here. [....] In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice. ----edw519 448 days ago---- [....] Someone should write a program that automatically posts this paragraph [Norvig's] at the top of every language war thread. I think they should write that program in php :-) ----poet 449 days ago----- An approximation of some of Norvig's recent thoughts (Feb 2010): "(1) It just turned out that when Google was started, the core programmers were C++ programmers and they were very effective. Part of it is a little bit of culture. (2) Early Lisp programmers (Erann Gat) at Google actually noticed that other programmers were equally or more productive. It has more to do with the programmer; we're getting to the point where language choice is less important (as opposed to 20 years ago). (3) Lisp is optimized for a single programmer or a small group of programmers doing exploratory work... If I want to make a change in a weekend I'd rather do it in Lisp than anything else, but by the time you get up to hundreds of programers making changes are not a language problem but a social one. (4) Libraries." Paraphrased from: http://www.youtube.com/watch?v=hE7k0_9k0VA#t=03m20s http://www.youtube.com/watch?v=hE7k0_9k0VA#t=03m20s.
- raganwald 15y agoYes, but given A = people, B = architecture, and C = language (and ignoring process for brevity’s sake), the two honking giant caveats are these: Just because A > B > C does not mean that C does not contribute to the result and can be dismissed. C may be less important than A, but that doesn’t mean it’s unimportant. Specifically, assuming you have a sane process for hiring people and a sane process for choosing a language (e.g. we are not talking about the gap between “I CAN HAZ CODES” programmers and Norvig, nor are we talking about the gap between Brainfuck and Lisp), the contribution of A to the result is not so many orders of magnitude greater than C that you can ignore C. And: A > B > C. Fine. But are these independent variables? No, we know that the language affects (for better or worse) your ability to attract and retain certain developers. So A and C are not independent. Likewise, certain architectures are just plain hell to implement with certain languages, so B and C are not independent. Solving for the maximal result of A, B, and C does not mean choosing A first, then B, and then C. It means choosing the best combination of all three at once. Update: Nothing I’ve said here disagrees with Norvig, caveats are warnings not to oversimplify, not suggestions the advice is incorrect. Also, http://paulgraham.com/pypar.html http://paulgraham.com/pypar.html
- deleted 15y ago[deleted]