Lisp as an alternative to Java (2000) [pdf]
flownet.com
flownet.com
Interpreted only ... that's a narrow, 4 year window, the first was developed in 1962.
Probably the key thing in this is that most any good programmer could hack out a Lisp implementation in a week or two. Making one preform as well as contemporary languages, strangely enough, took a similar amount of effort, and most Lisps back then didn't.
I sometimes think that the AI winter really took computing in a weird turn, not just Lisp, but computing in general. It feels like we stopped trying to make computers do all the work for us and decided that humans should be doing the work for the computer. So we ended up heading down the path of manual memory management in the C style languages, verbose constrained programming in Java and static typing instead of the easier dynamic. Whilst I agree that at one point, hardware performance was a serious consideration and we needed to squeeze everything we could out of computers - that is no longer the case. We're overwhelmed by hardware performance in most cases. Perhaps that's why we're seeing a resurgence in Lispy languages nowadays?
In the '80s, a common startup setup that was more powerful than a PC (for a while) and ASCII terminals to a UNIX(TM) box was 3 or so el-cheapo Sun workstations sharing one disk over an Ethernet (or so I've read, I might well prefer the ASCII terminal to a UNIX box, which is what I tended to use).
Although also think about the PC starting with ones using the 386 (true 32 bits, the 286 was misbegotten and all but useless except as a fast 8086): both these configurations were cheap, but not all that capable, memory was at a premium as well as virtual memory in the workstation case.
So using machine but not programmer efficient C and the like was the zeitgeist. Then about or a bit before the time engineering workstations based on more capable microprocessors were also capable of running Lisp quickly, although without hardly as much error checking, the expert system bubble collapsed. And those promoting it had to find something to blame, and Lisp became it. Or so goes one narrative of it.
There was certainly a ... Slough of Despond in programming languages we mortals could use to earn a living about the time you would have started programming seriously (before college, I assume). For Lisper and programming language guy like myself it was very depressing; I think what got us out of that, besides Moore's Law, was the dot com bust, it upset a lot of the conventional wisdom, coupled with a paucity of resources for development. No longer could you, at the extreme, do a wild IPO with an idea and a plan to hire a bunch of blub programmers using a consensus language running on expensive Sun or whatever hardware. You probably get the idea of what lost favor (ask if not).
Also, as Paul Graham pointed out, in essays who's influence I can't judge, the above will at best get you average results, and the average result of a startup is failure. He also noted that technical failure was a frequent cause of corporate failure. To take one stark example, compare Facebook competitor Friendster. Whatever promise it had, that the company's board used to wheel and deal, didn't matter when it was just too slow to use. Of course (if I remember correctly), its technical founder was purged by that board.
Which also leads into issues of control. We technical people don't need so much money, and the all too common downside of losing control is awful for us, the company, and of course the people we hired for it.
So all in all we more tend to call the shots technically, and are able to pull it off. And wild successes like Facebook with PHP and Twitter with Ruby on Rails didn't hurt.
So, how will Lisp compete ?
Maybe if we look at it pragmatically, the solution is not in the performance nor in the time to develop, but in the ease of maintaining the software in the long term. A field where Lisp is not particularly brilliant.
[0]: http://www.randomhacks.net/2005/12/03/why-ruby-is-an-accepta...
Good point about long term maintenance. Ruby and Python aren't that great either, people say static typing is the way to go. Lisps are weird because they allow to hot swap most of the things which makes changing a system easy, but at the same time it leads to spaghetti images.
I often connect to production servers using Slime and fix little things like typos this way - then check the source into Github and have it permanently saved. It removes a lot of the stress of doing a full deployment each time you need to patch something!
Code lives in Git as well via GitFileTree.
Yes, (as tptacek said), just like Esperanto is an acceptable English.
The article's first premise of what are lisp's virtues is dead wrong. First Lisp is NOT a functional language. A functional language is one that maintains referential transparency. i.e. where I can replace the reference/variable with its value its semantics are unchanged. Common Lisp is a multi-paradigm language and pervasively uses the the concept of places to setf state. And in a more general lisp sense, macros are opaque to the run-time and directly opposes referential transparency.
His second statement, Ruby gives you 80% of what you need of macros, implies that we know what macros are for. Macros are not a solved problem, you can see Racket is actively researching macros. For example, how does one do meaningful error reporting in macros? And given that macros, generally, are programming at compile time the statement is as analogous to saying we know what we are programming for, a statement I couldn't disagree more with.
The quid of Lisp I would argue is not specifically macros, but its 'meta-circular semantics', that is to say, the capacity of lisp to speak of itself in a meaningful way[0][1]. For example, in C++ we can speak of C++ but not in C++ but in its template language, that is to say a meta language. Lisp is its own meta language. We could also speak of Python in Python, for example express Python's for loop in python[2], except there is now way to replace python's definition of for with my own.
BTW, that doesn't mean Ruby isn't a good language. Lisp is not an idyllic standard from which to measure how good all other languages are. For example, Smalltalk is far from being a Lisp, that doesn't mean it is not good.
[0]: http://home.pipeline.com/~hbaker1/MetaCircular.html
[2]: https://gist.github.com/PuercoPop/9d192f94f88074d06625
[1]: "Informal "design patterns" are only for inexpressive languages. In Lisp, you can always express the "design pattern" formally, through a function or a macro. (...) No half-assed informal descriptions of repetitive patterns needed; if you can actually identify and express a redundancy using English language, you can also code a formal function or macro to get rid of it" — Fare in http://fare.tunes.org/files/fun/fibonacci.lisp
Common Lisp certainly doesn't have as many libraries as Python or Ruby, but let's not exaggerate. The ecosystem is broad and deep enough for the average programmer -- me, here -- to be perfectly productive.
You can't just take 20 programmers and give them a problem to solve, that's not how surveys works.
I could see something similar happening with dynamic languages. Over the past decade, the things that once irritated me about working in static languages have largely been addressed as features like generics, type inference, and interface polymorphism became more common. But I can't imagine dynamic languages will ever go away, if anything because they're still so successful in the scripting domain.
Where?!?
JavaScript is king for those that need to target the browser, that is for sure.
Now outside the browser? There are lot of languages to choose from.
Python and Ruby are surely not the first to reach if one needs performance.
C (plus is implied)
C++
Java (3rd to rise, with syntax based off C++)
C# (4 pluses joined together to make a sharp sign)
Objective C (5th to rise, tho around for longer)
And it's had that behavior for much longer than C# has; I think since the very first version of the language. Though I suspect that the implementation of late binding has become more efficient since the DLR came along.
That's incorrect. Regardless of the metric (TIOBE, job boards, StackOverflow, ...), you will see that the top five languages are 90% statically typed (usually Java, C, C++, C#).
One of the strengths that Java has over Lisp is that it's statically typed. At the time, the direction of the industry wasn't too clear cut but this is clearly the trend today.
Another example of the bias is that the benchmarks compare development times (and Lisp wins, surprise surprise) but not maintenance time, which is admittedly harder to measure but a big liability that dynamically typed languages have.
Common Lisp has optional static typing. Unlike Java, you have the choice, depending on what you're doing.
http://www.lispforum.com/viewtopic.php?f=2&t=191
TL;DR is that many CL implementations will check types at compile time, but for appropriate speed and safety settings, they will also generate code that checks types at runtime, too.
That depends on what you mean. CL declarations are promises to the compiler. They permit the compiler to make optimizations but does not require it to signal compile-time errors. Specific implementations may give you compile-time errors, but in general you can't count on it the way you can in Java.
With the caveat that Java's type system can be subverted and isn't expressive enough to catch any more than the most trivial kinds of errors a type system can catch.
Because Java is statically typed, it catches a lot more errors at compile time than Lisp can.
Now, whether or not a particular implementation does catch it is an entirely different affair.
The latter sort are, in my experience, the most common form of type error and catching g them is awesome.
Maybe if we all adopted a language for our weekend projects, we'd contribute enough back through blogging and StackOverFlow questions that we'll add enough knowledge, etc to the net, that it'll become increasingly easier for the next person.
Btw, I'm using Go for my weekend web site project: http://thespanishsite.com
Basically it's very nice when a language gets enough traction that the lack of users is no longer a concern for its long term prospects.
http://readwrite.com/2011/06/06/cpp-go-java-scala-performanc...
I'd love to see a few more languages included, Scheme and D being two. Scala had an impressive performance there, creaming Go in particular!
(Wow, it's amazing that paper is already three years old - time flies!)
The JVM has been improving a lot since then.
In order for that content to be taken seriously, the tests should be re-run with modern runtimes for both C/C++, Java and Lisp.
If we consider JavaCard or Java ME a java dialect then yes, it has gotten a lot smaller! I think neither of these where available in 2000.
Running Java also does not need a JVM. There are AOT compilers for JAVA. Like Lisp there are a lot of different implementations with lots of differing trade offs.
In any case a very flawed comparison, like all programming languages comparison of this kind as it is so hard/expensive to do it correct.
But an interesting read anyway.
I think of languages as equivalent (they are all turing complete right) so something buildable in one must be buildable in the other. The question is what tradeoffs do the languages make for the humans in the loop.
Lisp and Java make different tradeoffs there, and C makes yet another set of tradeoffs. And which languages we use is more often dependant on historical accidents than technical excellence (like most human languages) see JS as an example.
I believe dynamic languages are better for small teams and short project life times. I believe automatic memory management by default languages are better for the vast majority of projects than manual memory management options. I think a written language like Traditional Chinese (Java) is better for running an empire than one like Latin (Lisp). But a more modern idea like Hangul (Clojure?) might do even better.
In the end to get the best CPU performance one needs to know the CPU and architecture as well as an ability to think in bits. And like in human language one can write poetry in all of them, its just a bit more difficult than the office memo's we tend to write and read in our jobs ;)