Why I'm not using Lisp
dreamersrealm.net
dreamersrealm.net
His #1 need is "Outstanding Unicode support", and he's switching to Python for this. Just today there was a blog post that made the rounds, "The Truth About Unicode In Python" (http://www.cmlenz.net/archives/2008/07/the-truth-about-unico...) that gripes about Unicode in Python!
One of the gripes about Python was that its internal representation is UCS-2 by default. In comparison, SBCL uses 21 bits internally, and his Python example works fine in SBCL (on the Mac, no less):
* (characterp #\MUSICAL_SYMBOL_G_CLEF)
T
* (char-name #\MUSICAL_SYMBOL_G_CLEF)
"MUSICAL_SYMBOL_G_CLEF"
(NB: I am employed by Clozure)
I was in the same situation and I simply ditched OSX: it just can't rival Linux as an ultimate programmers' world exploration vehicle. Ironically, it was Python and some Python libraries that drove me to Linux.
I have a Mac too, of course, as an ultimate Safari+Photoshop machine.
http://lh4.ggpht.com/_gGwo1YUVIQg/RpYpNTwgJUI/AAAAAAAAApM/my...
Therefore the above comment implies that Python should work on Mac OS X.
I seriously doubt he's running Windows on a Mac...
Implemented out of the box, it should get Java's Unicode support for free.
I haven't use CLISP on a Mac... but I'm sure it works fine.
I also think it's interesting that he describes Python as having "outstanding" Unicode support. There's an article on the front page right now about how poor Python's Unicode support is. (There's some support, but it's not outstanding. Merely acceptable.)
"You know, I'm outstandingly attractive when you compare me to nobody at all!"
I'm using SBCL and Slime (aquamacs) on my Macbook right now - or more accurately I would be if I wasn't procrastinating on HN ;)
Most of the popular newer languages have a "benevolent dictator" (or not so benevolent in some cases), which means there's a reference implementation which almost everyone uses. Okay, maybe you lose out a bit on runtime quality, but I think the current trend towards building on top of the JVM, etc. will continue and alleviate that particular problem.
I also tried to use Common Lisp, I really did. I liked the core, but in the end it was the sheer volume of little problems that drove me away. Luckily, I've found a lovely compromise in Clojure.
If only ActiveState made an ActiveLISP...
import email
msg = email.message_from_string(sys.stdin.read())
How easy is that? The subject is msg["Subject"]. Iterating over the MIME parts is 2 lines of code. I could build all the scaffolding very quickly, and concentrate on the problems I needed to solve. Maybe this is just as easy in LISP - if you already know where to get all the bits, and I don't, and I'm not good enough to write a production-grade RFC822 handler in a day.
I like LISP a lot and am trying to use it where I can, but at the end of the day, I have to get stuff out the door as quickly as I can...
That's one of the worst examples, but my overall feeling is that dynamic languages on the JVM aren't worth it. You're probably better off with an independent language environment.
Sometimes it's not clear if that's really the problem, or if it's more the perception (and the fact that the perception gets repeated a lot) that's the problem. Hence my question earlier in the thread.
It's not only fear or laziness; I know two very good programmers who have tried Lisp and don't like it. Interestingly, both are Smalltalkers, though one was of the original generation that migrated to Java.
I wonder if it's that some people like thinking in trees and some don't. Human language has barely any nesting. Putting one parenthetical phrase inside another is already rare and that's just two levels. Parenthetical nesting is so difficult for humans to process that there's even a well-known hypnotic induction based on it (that essentially creates a stack overflow in a person's brain).
One of the guys I'm talking about has a programming style that's markedly linear (though not procedural). He likes chaining expressions together almost like noun phrases in English. For example, where in Lisp you'd write
(min y (max x 0))
x.atLeast(0).atMost(y)
The converse is true, though: all chains of this form could be converted to s-expressions, so it's easy to imagine embedding this style into Lisp with a macro. That's the sort of thing that gets talked about naively, but never catches on. I think it would be a losing proposition. You'd lose Lisp's regularity, which is one of its greatest advantages. And the resulting programs would still have plenty of s-expressions, so you'd end up driving away the same group of people after all.
http://www.cs.brown.edu/~sk/Publications/Talks/SwineBeforePe...
It doesn't address the s-expr situation directly, but Dr. Krishnamurthi plays a devious trick to show you why they aren't scary.
Thus, the lack of a batteries-included Lisp might well be more significant than a fear of s-expressions. Hopefully Arc will one day reach the point where I can sneak it into my workplace as I have done for Python. At that point the fear of s-expressions will hopefully be irrelevant.
Heh, there is no fear or laziness here. I am a 32-year-old who grew up with Pascal, learned FORTRAN in college, wasted a few years working in Java, and have done Python for a few years. All the time I am moving up the scale towards more powerful languages. I started learning LISP this year, and so long as I stay within the LISP runtime I'm a happy bunny. At the boundary between LISP and the outside world, tho', I keep hitting obstacles that Python breezes through without a pause.
The lack of libraries is a significant problem, certainly to anyone who wants to use LISP in an existing environment, no matter how motivated they are to do so, given the constraints that a good-enough language already exists and the expectation that integrating the code with everything else is essentially a solved problem.
Or, just switch to Scheme: http://docs.plt-scheme.org/net/pop3.html http://docs.plt-scheme.org/net/smtp.html
Is Z greater than W, or less than W? That's the critical question for him.
How can he decide which approach is best without estimating the hour values of each variable?
Edit: of course there's some other issues. maybe he'd spend 80 hours on python maintenance vs 100 writing lisp unicode support. the numbers are made up, but the point is that maintenance probably isn't much fun, so one might choose the lisp path even if it takes a bit more time. besides fun, one might learn more that way.
Lisp as a concept is very powerful. The current dialects, their implementations, respective libraries and package management systems on the other hand have often gotten in my way. For example take a look at http://article.gmane.org/gmane.lisp.cclan.general/807
(Plus a few other reasons. See PG's essays, PG's Lisp books, and SICP if you don't know the other reasons.)
If you don't believe this, don't use Lisp. The guy writing the article does seem to believe it. He likes and respects Lisp. So he ought to analyze in the way I said.
Though python is a pretty powerful language in it's own right, it's got a repl console and sweet little list comprehensions and more, so is the difference really that great between python and lisp? Python is not assembler after all. To know that I suppose I should have to learn lisp myself, which I haven't had the time to do yet. Surrounded by java zealots at work as I am though, and that clojure seems to be the best working non-statically typed language on the JVM I just might.
The issue with utf-8 seems to be solved by now from reading the comments around here. But there are always problems working with utf-8 with libraries written by people that have never needed to work on non-ascii text, the code has simply not been tested thoroughly on the problem of working with utf-8 text so while it might be production quality regarding to ASCII there are weird bugs that pop out of the woodwork when working with musical notes.
On a related note: I've written a few programs in ruby where I've really run into trouble not having decent unicode support in the language. With iconv you can easily make it work if you are working with characters that map to an 8-bit character set. But if you are working with characters that map to several european languages at once, and need the euro symbol, you're in the cold. You can have utf-8 strings in ruby yes, but if you pry them apart, or make changes to them, they loose their utf-8:ness and look like shit. This is an issue that should really be solved at language level, if you don't want to have roughly similar the same abstraction level dealing with strings as you have in C. I love ruby, but I hate working with utf-8 strings in it just now.
with lisp, you don't need anything to be built in "at the language level" because you can modify the language much better than with python or ruby. many "built-in" lisp features, that would be language-level in other languages, are just built-in macros, and you could have written them yourself exactly the same. for example, loops are done this way.
i'm not saying you should always use lisp for everything. but for this particular issue lisp has a major advantage.