It's Like Déjà Vu All Over Again
"You could probably waste an entire day on the preceding links alone. But why take chances? We also give you Paul Snively..." — John Wiseman, lemonodor
"I saw, pretty much for the first time in my life, people being as productive and more in other languages as I was in Lisp. What's more, once I got knocked off my high horse /.../ and actually bothered to really study some of these other languges I found *myself* suddenly becoming more productive in other languages than I was in Lisp. For example, my language of choice for doing Web development now is Python."
Languages like Python, Ruby, and Perl have improved on Lisp in many ways, mainly by adopting Lisp-like features for scripting environments. They've made these features fit for stand-alone shell scripts and scripts integrated into C and Java-like environments.
I'd also add better support for string handling to the list of things that what most people call "scripting languages" tend to do better than Lisp has historically done, although Paul Graham is attempting to change that.
The Lisp that Erann lost faith in was the CommonLisp environment that attempted to be a world unto itself. Note that the Smalltalk environment which has historically attempted to do the same thing has also fallen by the wayside.
Well, except in certain circles in which you can get away with being a world unto yourself. :-)
Lisp can play the same role as other scripting languages. Guile does. JScheme does. Kawa and Skij, too. If you add them all up, they probably don't approach the popularity of Python or Perl. Probably not even Ruby.
My favorite such system remains DrScheme and family. It's an excellent Scheme environment, and the code you write can be confined to that which can be run by MzScheme, which can be embedded in a C/C++ app as a scripting engine.
I would go farther and say that folks who haven't become fluent in at least one functional language (be it Scheme, Standard ML, Haskell, Objective Caml, Erlang, Concurrent Clean, and/or Oz) don't really know how to program correctly.
Lisp is older than I am. Lisp has contributed as well as incorporated new ideas better than any other language. There is no need to lose faith, as long as you don't get your hopes too high!
I think this last point, which is a commonplace among Lisp programmers, is nevertheless overlooked in the mainstream. My single strongest criticism of the majority of working programmers is that they can only think of one way to solve any given problem (yes, even the Perl programmers). This is the thrust of my claim above. Even object-oriented programmers rapidly become stymied if you put constraints on them like "no pointer assignment in this; it needs to work in the case where there are other dependencies on those pointers" or what have you. A solid background in a functional language helps tremendously with this type of issue.
Lisp, whether Common or Scheme or something derived from them, has a healthy life ahead of it indeed, if we are willing to recognize the values that are inherent in it.
9:14:13 AM
I'm trying to wrap my mind around REST. I'm fully in favor of any technology that tries to simplify the complex. But REST seems to take things a little too far, by limitting the verbs and putting almost all meaning into the URI. My initial gut feeling is that it's just moving the complexity elsewhere, rather than getting rid of it. By recasting RPC as a POST, you are not really getting rid of the RPC, you are just making it look like something other than what it is. I'm not sure if it's going to catch on. It's certainly an interesting thought experiment. [it's getting better]
I had a similar reaction. You can make a good argument that XML-RPC and SOAP should not be using HTTP. The ideal answer would be to go create your own dang protocol. But the fact is that the protocol designers engineered solutions for HTTP that works pretty well. I don't see REST as a practical step, but it's an interesting criticism.
I have to admit that this surprises me. I think REST makes excellent sense for exactly the reasons that Paul Prescod and Mark Baker keep trying to pound into everyone's heads: HTTP already gives you all the operational semantics you need, and if you use it according to REST principles, you get to take advantage of all of the stuff that's been built up around HTTP, e.g. caching proxies and the like.
What's interesting to me about the discussion is that it basically boils down to an imperative view of web services (the RPC bunch) vs. a functional view (the REST bunch). The argument about caching and so forth is really an argument in favor of what we functional types call "referential transparency" (it doesn't matter to the recipient or—importantly—to the resource whether the resource is gotten from its original source or from the cache).
Another interpretation of REST is that it's simply "program to the interface, not the implementation" applied to HTTP. If the interface is consistent and there's a good-enough (MIME-)type system in place, then you can develop tools that can manipulate resources without overcommitting to how that manipulation takes place.
And URI's really are central to the Internet. I remember my initial surprise when I first played a game called "Unreal" on the Internet, and it started to download a map. It did so by accessing a URL of the form <unreal://192.168.x.x/map.unr>. Later, it occurred to me that that was exactly as it should be: we should have a generic URI resolution framework in our code and just plug in a new scheme handler. Done.
If you do take REST seriously, and in particular the notion of typed resources seriously, I would argue that Prescod is correct: it should be used so that all of the emerging technologies such as XSLT, RDF, etc. can be applied to the resources as needed or desired. You can't do that with XML-RPC or SOAP.
Now we just need some nice REST-based frameworks for webapp development. :-) I'm betting that Tyler Close's Cistern framework is one such tool.
8:30:04 AM
