I always think it's interesting that people state this sort of opinion without actually providing any evidence that this kind of move by Google actually reduces creativity. Sure, their model for the way things are produced predicts this, but why is their model valid? What about a model where one posits that having all (or even just more) information freely available for anyone's use actually increases the overall creative output of society because creators have more raw material to work with? Though I present no evidence for this either, it's easy to conceive that this could be valid as well.
Just to amplify the previous poster's message, I must admit that I had programmed in Common Lisp for some time without completely "getting" the condition system (which is still not terrible as one can trivially use it as a "typical" exception system without its the extra power). I think Peter Seibel really gave me the light bulb moment in Practical Common Lisp. Whereas a typical exception mechanism has two points of relevance in the code, the point where the exception is raised and the point where it is caught and handled, the Lisp condition system can be seen as breaking the latter into two parts: a point (or for that matter multiple points) in the code where a potential way of handling a condition is established, and a point (or multiple points) where it is decided which of these ways will actually be used. This is key to the added flexibility of Lisp conditions and to the ability to not unwind the stack all the way to the point where it is decided how to handle the condition.
It's doubtful that you read much on the link for Teach Scheme, or you'd find that not only do students pick up Scheme faster, but that they are able to do real things with it faster and more easily.
And take a gander at the websites of Franz, Lispworks, or Digitool to see exactly what wide variety of real things people do with Lisp.
And regardless, there's little need for Lisp to look nice to anyone except a Lisp programmer, as Lisp tends to be written and read by Lisp programmers. And serious Lisp programmers will tell you that they don't have any problem reading Lisp. I generally find it easier to read Lisp written by other people (who are actually Lisp progammers) than, say, C (written by C programmers). So it's mostly a matter of experience. And people who have _no_ programming experience and then are exposed to Scheme as their first language don't really seem to have too much trouble with it (c.f. The Teach Scheme Project).
I think it's somewhat unfair to characterize de Branges approach to the Bieberbach conjecture to be unnecessarily wacky, and certainly not everyone does. Consider, for example, the following quote from Donald Sarason's book Sub-Hardy Hilbert Spaces in the Unit Disk, p.7 (empahsis mine)
The ideas of contractive containment and complementary space were critical in de Branges's discovery of his proof of the Bieberbach conjecture. Although a proof of the conjecture that expunges these ideas can be given, and such a proof might seem preferable to specialists in geometric function theory, the role of Hilbert space ideas
is really very natural, as is made manifest by the study of V.I. Vasyunin and N.K. Nikolskii, which further develops de Branges's approach.
Now, I do have respect for Sarason and his opinion and, as with just about everything in mathematics, how strange or natural a particular approach to a problem is may depend strongly on one's own background.
Sorry, but you're comparing apples and oranges here. LISP is adheres more to a completely different programming paradigm (functional programming) as opposed to Java/C/C++ and all the other OO languages.
If you actually believe this, you don't know Lisp very well. While Schemers often emphasize the functional use of their language, Common Lispers move about as they wish in the realms of procedural, object-oriented, and functional programming in order to most easily solve their problems.
You might have a look at the Table of Contents of the Hyperspec to have a better idea of the things available in Common Lisp as a language proper, and something like Cliki for links to Lisp libraries and such whose source code will indicate how people actually program in Lisp these days.
Well, a typical generational collector will promote the object to a longer lived generation after touching it a few times without collecting it (perhaps even just once), and many will allow you to simply allocate it into a longer lived (or even permanent) generation to begin with.
A couple of relevant references for garbage collection are the following website (which unfortunately hasn't been updated for a while - still, it's useful):
In Lisp a pretty common way to handle this sort of thing is with a with-some-resource macro (with-open-file is a commonly used built-in). This sort of macro will typically take information for dealing with the resource (e.g. in the file example the pathname of the file, options for opening it, etc.) and the body of code to be executed with the resource; it will then expand to code that acquires the resource and then uses it and releases it (the latter two typically wrapped in unwind-protect to assure the release should there be an exit via a condition or whatnot).
Obviously the poster's point was that there are better garbage collection algorithms that do not generally suffer from the original poster's problems, as there are sorts that generally perform better than bubble sort. It was intended to be a tad sarcastic, I'd think.
If I were typing all the time, I'd agree. However, I don't find that all that much of what I do when developing is typing. Especially when using languages like Lisp and Smalltalk that let me express everything I need more concisely than some more mainstream ones.
As for a smaller user base for Smalltalk and Lisp, true, but so what? It doesn't affect what I do in any way.
Probably because we see no great benefit in that. I however, find Smalltalk a useful language that I would use even more than I do were it not for the existence of Lisp.
that Lisp is case sensitive. It's just that by default the reader upcases the characters in symbols when it reads them. One can either alter the readtable or quote symbols or characters in symbols as desired to avoid that.
from its webpage that DBDesigner4 only supports MySQL, whereas this offers support for more databases. That could be an explanation, as not everyone uses MySQL.
I've gotten the impression from some of Kent Pitman's postings in comp.lang.lisp that really what he felt was the most important factor in leaving out continuations was the desire to have unwind-protect, which doesn't necessarily interact very well with continuations. I'd hate not to have unwind-protect in Common Lisp.
You almost answer your own question. You're plugged into the Perl community, so you know what is the right thing to use. If you were plugged into the Lisp community, you'd either have a decent idea which of these to use and how to use it, or at least how to find out. CPAN is probably the only reason that I continue to use Perl myself, and I agree that it's a good one. I don't necessarily think that it's so easy to know what the good modules are without being connected to the community, nor do I find Perl modules from CPAN necessarily easier to use than libraries I might find from CLiki.
In my case, I originally did as you mentioned - I wrote an interface to MySQL through the Lispworks FFI that wasn't terribly sophisticated, but had the functionality that I needed and mimicked the Perl DBI interface that I was already familiar with. Later I got the better version of Lispworks with their built in (and quite well documented) SQL interface and used that for a while. Now that I'm using PostgreSQL on Linux I use the Pg package and found little problem in getting accustomed to it.
I personally use Pg most of the time now, but I used to use CommonSQL (that comes with Lispworks), on which UncommonSQL is based. That really makes database access dead easy in Lisp.
Slashdot Mirror
I always think it's interesting that people state this sort of opinion without actually providing any evidence that this kind of move by Google actually reduces creativity. Sure, their model for the way things are produced predicts this, but why is their model valid? What about a model where one posits that having all (or even just more) information freely available for anyone's use actually increases the overall creative output of society because creators have more raw material to work with? Though I present no evidence for this either, it's easy to conceive that this could be valid as well.
Just to amplify the previous poster's message, I must admit that I had programmed in Common Lisp for some time without completely "getting" the condition system (which is still not terrible as one can trivially use it as a "typical" exception system without its the extra power). I think Peter Seibel really gave me the light bulb moment in Practical Common Lisp. Whereas a typical exception mechanism has two points of relevance in the code, the point where the exception is raised and the point where it is caught and handled, the Lisp condition system can be seen as breaking the latter into two parts: a point (or for that matter multiple points) in the code where a potential way of handling a condition is established, and a point (or multiple points) where it is decided which of these ways will actually be used. This is key to the added flexibility of Lisp conditions and to the ability to not unwind the stack all the way to the point where it is decided how to handle the condition.
isn't unique to Perl. It exists, for example, in Common Lisp.
It's doubtful that you read much on the link for Teach Scheme, or you'd find that not only do students pick up Scheme faster, but that they are able to do real things with it faster and more easily.
And take a gander at the websites of Franz, Lispworks, or Digitool to see exactly what wide variety of real things people do with Lisp.
Yep, it's pretty much only useful for simple problems like:
. Animation & Graphics
. Artificial Intelligence
. BioInformatics
. B2B & E-Commerce
. Data Integ. & Mining
. EDA
. Expert Systems
. Finance
. Intelligent Agents
. Knowledge Mgmt
. Mechanical CAD
. Modeling & Simulation
. Natural Lang. Proc.
. Optimization
. Research
. Risk Analysis
. Scheduling
. Telecom
. Web Authoring
and the like.
(loop for x from a to b do (print x))
(+ 1 x) isn't RPN, if anything, it's "PN".
And regardless, there's little need for Lisp to look nice to anyone except a Lisp programmer, as Lisp tends to be written and read by Lisp programmers. And serious Lisp programmers will tell you that they don't have any problem reading Lisp. I generally find it easier to read Lisp written by other people (who are actually Lisp progammers) than, say, C (written by C programmers). So it's mostly a matter of experience. And people who have _no_ programming experience and then are exposed to Scheme as their first language don't really seem to have too much trouble with it (c.f. The Teach Scheme Project).
Not so, is it? Scheme has 'do', though hardcore Schemers aren't apt to use it much.
The problem is that if there is already a function of the same name, how does the compiler know what you intend?
let f x = 1
let f x = if x = 0 then 0 else 4 + f (x - 1)
Now, should f 4 be 5 or 16?
That's why there's let rec, and what a previous poster was talking about regarding scoping.
I think it's somewhat unfair to characterize de Branges approach to the Bieberbach conjecture to be unnecessarily wacky, and certainly not everyone does. Consider, for example, the following quote from Donald Sarason's book Sub-Hardy Hilbert Spaces in the Unit Disk, p.7 (empahsis mine)
Now, I do have respect for Sarason and his opinion and, as with just about everything in mathematics, how strange or natural a particular approach to a problem is may depend strongly on one's own background.
If you actually believe this, you don't know Lisp very well. While Schemers often emphasize the functional use of their language, Common Lispers move about as they wish in the realms of procedural, object-oriented, and functional programming in order to most easily solve their problems.
You might have a look at the Table of Contents of the Hyperspec to have a better idea of the things available in Common Lisp as a language proper, and something like Cliki for links to Lisp libraries and such whose source code will indicate how people actually program in Lisp these days.
Well, a typical generational collector will promote the object to a longer lived generation after touching it a few times without collecting it (perhaps even just once), and many will allow you to simply allocate it into a longer lived (or even permanent) generation to begin with.
A couple of relevant references for garbage collection are the following website (which unfortunately hasn't been updated for a while - still, it's useful):
The Memory Management Reference
and of course Jones and Lins book, Garbage Collection: Algorithms for Automatic Dynamic Memory Management
In Lisp a pretty common way to handle this sort of thing is with a with-some-resource macro (with-open-file is a commonly used built-in). This sort of macro will typically take information for dealing with the resource (e.g. in the file example the pathname of the file, options for opening it, etc.) and the body of code to be executed with the resource; it will then expand to code that acquires the resource and then uses it and releases it (the latter two typically wrapped in unwind-protect to assure the release should there be an exit via a condition or whatnot).
Obviously the poster's point was that there are better garbage collection algorithms that do not generally suffer from the original poster's problems, as there are sorts that generally perform better than bubble sort. It was intended to be a tad sarcastic, I'd think.
If I were typing all the time, I'd agree. However, I don't find that all that much of what I do when developing is typing. Especially when using languages like Lisp and Smalltalk that let me express everything I need more concisely than some more mainstream ones.
As for a smaller user base for Smalltalk and Lisp, true, but so what? It doesn't affect what I do in any way.
Probably because we see no great benefit in that. I however, find Smalltalk a useful language that I would use even more than I do were it not for the existence of Lisp.
I suppose the rest of the world can take the five or ten minutes that it takes to understand Smalltalk syntax.
Or you could get the best of both worlds by using a interactive compiled language, e.g. most Common Lisps.
that Lisp is case sensitive. It's just that by default the reader upcases the characters in symbols when it reads them. One can either alter the readtable or quote symbols or characters in symbols as desired to avoid that.
from its webpage that DBDesigner4 only supports MySQL, whereas this offers support for more databases. That could be an explanation, as not everyone uses MySQL.
I've gotten the impression from some of Kent Pitman's postings in comp.lang.lisp that really what he felt was the most important factor in leaving out continuations was the desire to have unwind-protect, which doesn't necessarily interact very well with continuations. I'd hate not to have unwind-protect in Common Lisp.
No, the parentheses and long, hyphenated function names are part of the reason that Lisp is beautiful.
And to amplify, plenty of companies use Lisp internally and don't talk about it too much. The customer lists at:
Franz
and
Digitool
should be ample evidence of that.
You almost answer your own question. You're plugged into the Perl community, so you know what is the right thing to use. If you were plugged into the Lisp community, you'd either have a decent idea which of these to use and how to use it, or at least how to find out. CPAN is probably the only reason that I continue to use Perl myself, and I agree that it's a good one. I don't necessarily think that it's so easy to know what the good modules are without being connected to the community, nor do I find Perl modules from CPAN necessarily easier to use than libraries I might find from CLiki.
In my case, I originally did as you mentioned - I wrote an interface to MySQL through the Lispworks FFI that wasn't terribly sophisticated, but had the functionality that I needed and mimicked the Perl DBI interface that I was already familiar with. Later I got the better version of Lispworks with their built in (and quite well documented) SQL interface and used that for a while. Now that I'm using PostgreSQL on Linux I use the Pg package and found little problem in getting accustomed to it.
For example,
http://www.cliki.net/Database
I personally use Pg most of the time now, but I used to use CommonSQL (that comes with Lispworks), on which UncommonSQL is based. That really makes database access dead easy in Lisp.