Lisp has the same facility. You can attach strings as documentation to functions, generic functions, and classes at the very least (possibly to more things, I can't remember offhand) and query them using documentation. E.g.
(defun square (x)
"Return the square of x"
(* x x))
(defclass square (shape)
((side-length:initarg:side-length))
(:documentation "A representation of a box"))
Then
(documentation 'square 'function)
returns "Return the square of x"
(documentation 'square 'type)
returns "A representation of a box"
Why do you think that people so often overlook many of the wonderful things in Common Lisp such as unwind-protect, the whole condition system (which you are of course closely associated with), and so on - things that make it very useful for day-to-day programming, and are there any such things that you'd particularly highlight, or conversely that you wish had become part of the standard but did not.
Incidentally, thank you for all of the insight so generously and regularly poured forth in comp.lang.lisp.
The is no clear separation between the environment and the program.
Okay, one point in favor of Smalltalk, IMHO.:-)
There is no finalaization (destruction)
I can't speak for every Smalltalk, but then what exactly am I telling my objects when I define a #finalize method for them and send them the #beFinalizable message in Dolphin? I'm relatively sure that other Smalltalks implement similar measures.
There is no strong typing.
Kindly review the meanings of strong/weak vs. static/dynamic typing. Smalltalk is strongly and dynamically typed. I don't necessarily disagree that strong typing is a good thing (under its correct definition, of course). The whole dynamic/static argument is considerably less clear, however, IMHO.
The environment is hostile to multi-programmer cooperation.
Please tell us specifically what is wrong with approaches such as StORE for Visual Works, or even less ambitious tools such as David Gorisek's Source Tracking System for Dolphin.
The language design allows incomplete programs to appear to run, encouraging the release of incomplete and buggy programs.
It's unclear that your premise implies your conclusion. It's also unclear exactly what your premise means. As you pointed out above, there is no clear separation between the working programming environment and a developed program. So how is it that an incomplete program is appearing to run? A modification or extension to the existing Smalltalk image actually is running. In contrast to your assertion that this results in buggy code, the typical Smalltalker would observe that this makes it a lot easier to test and correct code incrementally.
Methods (member functions) of subclasses (derived classes) are executed during construction of the superclasses (base
class), invalidating the debugging of the superclass (base class) constructor.
I have an inkling what you mean by this, but I'm not sure. Would you mind posting a snippet of Smalltalk code to clarify it?
It is totally unsuitable for the construction of mission-critical or commercial-grade applications.
I will admit that I only know one massively successful Smalltalk "commercial-grade" application, viz. Visual Age for Java. OTOH, you might want to ask companies such as Sprint, FedEx, and various large banks about the suitability of Smalltalk for mission-critical applications.
If you don't like Smalltalk, that's fine with me (it's not my first choice for most things either, honestly), but please don't spread misinformation about it.
Well, if Graham isn't your cup of tea, you should definitely take a look at Norvig's Paradigms of Artificial Intelligence Programming (which is actually of interest to a much wider audience than just AI people, but I digress). As someone else said, Steele's book Common Lisp: the Language is good, thought it predates the ANSI standard, hence you need to be a little careful. The standard itself (or more likely, the Hyperspec, which you can find online at various places; check for example
Xanalys; there should be a copy around there somewhere. You can certainly download it, if not independently, as part of their personal edition of Lispworks) is very readable and informative. For a starting CLOS reference, try Sonya Keene's book Object-Oriented Programming in Common Lisp.
Of those, I particularly recommend Norvig, and recommend that you get a copy of the Hyperspec, which you will quickly find much more useful than the back of Graham's book. You might also want to describe exactly what Lisp system you are using, as this may possibly help us give further advice.
While I would personally rather implement almost anything in Common Lisp than Perl (the primary exceptions being when Perl's CPAN advantage comes into play), I certainly sympathize with your plight; it's hard to imagine why they oughtn't let you implement your projects however you like.
Plus, if you really want to close this back door, you can start uninterning symbols. I can't think offhand of any way someone could get their hands on something that that's been done to.
When we got VC funding one of the requirements was that we eventually rewrite the whole thing in Java. Not for technical reasons, but because of their fear that we wouldn't be able to find enough good Lisp programmers. Well, we hired a boatload of Java programmers.
Seeing stories like this (and having the relatively sheltered career, such as it is, that I've had), I've often wondered why management worries about finding (insert language) programmers rather than just finding good programmers (with the assumption that a truly good programmer will be able to relatively rapidly acquire whatever skill set is necessary). I don't dispute that one can probably find more Java programmers than Lisp programmers, but can one find significantly more truly good Java programmers than good Lisp programmers?
To the untrained eye (like mine), it's also always mysterious why, when your team was able to build everything necessary with four programmers, a good management would want to a) take on a lot of extra people (and salary, no doubt) and b) take on the risk associated with a transition rather than c) just make sure that you four remained sufficiently well compensated that you'd want to stay on and continue meeting their needs. It'd seem to me that c) would be not only less risky, but less expensive.
The authors got so excited about mathematical research they forgot they were trying to teach a programming language.
You may have missed the point. The authors of SICP aren't trying to teach a programming language. They're trying to teach how to program, and, in the opinion of many (myself included), do a very good job. Scheme is incidental to their actual task (although it does suit it well).
Two good choices are CMUCL and CLisp. Information for both of these may be found at
www.cons.org. (Warning-there have been some problems with the site lately. Be patient or try again if there is a problem.:-)
Emacs Lisp is mostly suited for writing Emacs and extensions thereof; it differs from more modern Lisps in some important ways. Of course, one should still know it to facilitate customization of Emacs.:-)
Agreed that Lisp won't put you close to the hardware (in most cases - there are always the Lisp machines:-). Disagreed that it's hard to do bit twiddling. In fact, there are two different good ways to do bit twiddling: bit-arrays and their associated functions, and ordinary integers together with the logwhatever, dpb, ldb etc. functions.
I can't really address suggestion 1, though I can't ever remember being particularly ill-treated by anyone. As for 2.:
Lispworks is a real development environment too (it's the one I use) which is less expensive than ACL
Corman Lisp is a real development environment too (though I admit to not fancying it that much) which is much less expensive than ACL or even Lispworks
If a truly free solution is desired, what's wrong with CLisp + (X)emacs, which I've also used under Windows?
There is a Free-CLIM project, although I don't know its status
It's unclear, though, how the lack of free CLIM implementations makes any statements about its usefulness. It merely indicates that you are either unable or unwilling to use a commercial implementation, which is fine, but really only makes a very local statement about it's usefulness (viz. that it's not useful to you in particular).
Why is it relevant how readable a program written in some language one doesn't know is? I don't think there's anything wrong with Russian because I can't gain any understanding from looking at a Russian text. I think people who know (i.e. use regularly, not studied for two weeks one semester in school) Lisp find it perfectly readable.
Actually the standard doesn't require Common Lisp to be tail recursive. A decent implementation should be, however, at least at appropriate optimization settings.
Specifically what features do you feel that a Lisp such as Lispworks (as Mark mentioned) or Allegro do you feel are missing that makes building multi-threaded applications a problem? For your reference, the chapter of the Lispworks Reference manual describing the MP package is
here
If you're at all language agnostic, there are good offerings that will work on both Windows and Linux, for example Cincom VisualWorks (Smalltalk) and XAnalys Lispworks (Common Lisp), both of which have fine IDEs.
Re:Mercury (Perl has first-class functions)
on
ICFP 2001 Task
·
· Score: 2
Perl does in fact have proper closures. E.g.
#!/usr/bin/perl -w
use strict;
sub make_adder {
my $addend = shift;
sub {my $x = shift; $x + $addend}}
my $adder = make_adder(3);
print &$adder(2), "\n";
IMHO not as nice as Lisp or ML, but there nonetheless.
If I'm not mistaken, one of my compadres from comp.lang.lisp:-) (ok, I'm really more of a lurker than a contributer). Glad to see you have more concrete information, as much of what I was spouting off about was gleaned from places like comp.lang.lisp.
Have any insight into why your last point is so? Given the productivity boost I've seen by using things like Lisp in my own work, and evidence as you present on another scale, I'd think companies would want to embrace such techology.
Before I say anything else, let me say that it's refreshing to have a reasonable discussion with an AC.:-)
Also let me say that I'm the lone programmer at my company, and do not have first hand experience at "large-scale" Lisp development, so some (though not all) of the things I might relate about that have to be taken in that light. They come mostly from reading others' accounts of the same.
I get the impression that larger Lisp projects will not approach the team size you mention above. Lisp advocates will tell you that this is because not so many are necessary to achieve the same results. I'm inclined to believe this, but keep in mind my caveat above.
Lisp's type system is strong (i.e. things are of definite types and don't automatically and mysteriously switch between them, as in Perl), it's just not static (i.e. variables may contain values of different types, which makes compile time type checking difficult or impossible - although, there are implementations that are able to do it to some extent). I don't know if that makes the distinction clear, but there is a difference between the static/dynamic and weak/strong axes. Lisp would be dynamic/strong. Since dynamic/static types and their advantages/disadvantages are rather religious issues, it's unlikely that any discussion of that would be of benefit. IMHO it's perfectly possible to make robust applications with dynamic typing, but I can also see where the static typing people are coming from, so let's leave it at that. (Incidentally, something like ML or OCaml might be of interest to you if you're committed to static typing. I'd say their type systems are a considerable improvement on C++/Java style. And actually they meet some of your other requirements well too.)
Lisp does have the kinds of features that you need for larger programs. Packages (think namespaces) allow you to keep things hidden and to keep people out of each other's way. CLOS provides an object system which is at least as powerful and is much used in Lisp projects. The condition system is not radically different from the exception systems. Finally, macros, while rather a dirty word in C++ circles, are much more useful and sane in Lisp, and can help tremendously in some of the engineering needs that you mention.
You would be right that Lisp chooses more to give you the ability to use these things properly and usefully rather than forcing such use. Put another way, for best use one must assume that the programmers, designers, etc. are competent. With packages, for example, there is a notion of exported symbols. So if I'm using someone else package, I should only use the exported symbols (which one might think of as the interface to the package). However, if I want to be devious about it (okay, you don't actually have to be that devious), I can get to the internal symbols. (I'm not a C++ expert, but I'd suspect that you can do similar things with respect to private variables, etc. if you know how to fool around with pointers properly, and so on.) A programmer is expected to know that while this is possible, it's not a good idea. And so on. Since IMHO the most important thing one can do to get a robust application is to get good people working on it (and I don't have much sympathy for those who neglect this), this doesn't disturb me that much, but others' requirements may vary.
(And, in case it's not evident, I'm certainly not saying that Lisp is best for every large scale project, just that it is appropriate for many of them.)
What I mean is that Smalltalk would be more widely accepted if there were variants that duplicated the look & feel and object
model of a common C++ toolkit & framework like MFC or KDE. The idea being that developers could work in Smalltalk but
produce applications that seem more native to the end user.
No one can really say if making the GUI aspects of Smalltalks more like a C++ toolkit would make it more popular among (non Smalltalking) programmers. However, it doesn't seem that it would make much sense to do that. The GUI frameworks in Smalltalk are set up to (as you might expect) work logically, consistenty, and robustly with Smalltalk. There's little reason to try to bolt things from a different langauge onto it, and as always, trying to use one language like another instead of using it like itself is not likely to produce good results. As far as producing native-seeming apps for an end user, some Smalltalks take this approach. For example, at work I use Dolphin Smalltalk, whose GUI system is based around native Windows widgets. Build an app and it looks just like it would if you built it with VC++ or VB. It would certainly be possible for a Smalltalk vendor to do this on other platforms (and in fact VW or VA may well work that way; I don't know).
I guess I think Lisp is fun because I spend all day working in
procedural OO languages and get bored. However, it doesn't have blazing speed and low level control of C, the GUI friendliness
of Smalltalk or Obj-C, or the industrial strength of Ada, C++, or Java.
I doubt too many people would argue that with current machines/OSes something like C is better for getting close to the machine. Of course, there are examples like the Symbolics Lisp Machine where everything was in Lisp, so that wasn't true.(As far as speed goes, that's really an implementation rather than language issue. If one knows how to optimize Lisp code properly and has an implementation with a good compiler, one can do pretty well. See, for example,
CMUCL. Or this page for more pointers. I will be honest, however, and admit to sometimes coding small parts of programs in C to improve performance. With the emphasis on small.:-) I do think Smalltalk wins hands down as far as anything I know for GUI, but particular Lisp implementations needn't be all that bad; I use Lispworks, and I don't think I'd say that I think GUI building is any harder in that than in a typical C++ or Java environment. I do think you may underestimate how suitable it is for "industrial strength" applications, though. Hang out in comp.lang.lisp for a while (or better, search the archives) and you will discover those who have built very serious, very large apps in Lisp, in part because of its suitability for such projects.
Smalltalk would be great for building UI intensive applications if only there were more good toolkits for it. If that flavor of OO suits you, you're better off using GNUStep or OS X and coding in Objective-C. Smalltalk still doesn't have the performance or library support to make it a true general purpose language.
Given that Smalltalks, typically, are mostly self-contained enviroments with built in GUI building tools, it seems rather unlikely that there will be a big proliferation of toolkits for them. On the other hand, I doubt most people who use Smalltalk feel that such is necessary, as the ones that exist with the environments are typically well thought out and useful and pretty complete already. I'm not qualified to say very much about performance aspects of Smalltalk, since I don't use it for such tasks (but primarily for building GUIs), but you might possibly be surprised at how well something like VW or VA can do.
And Lisp is a fun language, but I can't really think of anything it particularly excels at.
I use (Common) Lisp as my main general purpose language, and I think it works pretty darn well for most tasks (well enough that I choose it above anything else). I suspect most Lisp programmers would agree with your statement with C++ swapped for Lisp, except few of them would claim that it's fun.:-)
Well, there isn't static typing in Lisp. There is strong typing, but not static. Some implementations (CMUCL, for example) have some ability to make such static checks. But an implementation needn't, and in fact, may not be able to. For example, in your second example, what if we do (bar (read *standard-input*))? There's no way to know at compile time what type of data read is going to return, so reasonable static checking seems somewhat impossible here.
Also, the second example doesn't have to error. If you look here
for example, you will see that if we do something like (bar 0) the spec. declares that the consequences are undefined. If you then check the definitions
here, you'll see that this doesn't necessarily mean that an error is signaled. It may be, but it needn't be.
Slashdot Mirror
So why didn't you just use a Lisp with threads. E.g. almost any (or perhaps even every) major Common Lisp.?
Lisp has the same facility. You can attach strings as documentation to functions, generic functions, and classes at the very least (possibly to more things, I can't remember offhand) and query them using documentation. E.g.
:initarg :side-length))
(defun square (x)
"Return the square of x"
(* x x))
(defclass square (shape)
((side-length
(:documentation "A representation of a box"))
Then
(documentation 'square 'function)
returns "Return the square of x"
(documentation 'square 'type)
returns "A representation of a box"
I use Lisp for something similar in finance. So, yes, it does work for that.
The right link for XAnalys is actually here (no 'i').
Why do you think that people so often overlook many of the wonderful things in Common Lisp such as unwind-protect, the whole condition system (which you are of course closely associated with), and so on - things that make it very useful for day-to-day programming, and are there any such things that you'd particularly highlight, or conversely that you wish had become part of the standard but did not.
Incidentally, thank you for all of the insight so generously and regularly poured forth in comp.lang.lisp.
It's hard even to know where to start with that.
Okay, one point in favor of Smalltalk, IMHO. :-)
I can't speak for every Smalltalk, but then what exactly am I telling my objects when I define a #finalize method for them and send them the #beFinalizable message in Dolphin? I'm relatively sure that other Smalltalks implement similar measures.
Kindly review the meanings of strong/weak vs. static/dynamic typing. Smalltalk is strongly and dynamically typed. I don't necessarily disagree that strong typing is a good thing (under its correct definition, of course). The whole dynamic/static argument is considerably less clear, however, IMHO.
Please tell us specifically what is wrong with approaches such as StORE for Visual Works, or even less ambitious tools such as David Gorisek's Source Tracking System for Dolphin.
It's unclear that your premise implies your conclusion. It's also unclear exactly what your premise means. As you pointed out above, there is no clear separation between the working programming environment and a developed program. So how is it that an incomplete program is appearing to run? A modification or extension to the existing Smalltalk image actually is running. In contrast to your assertion that this results in buggy code, the typical Smalltalker would observe that this makes it a lot easier to test and correct code incrementally.
I have an inkling what you mean by this, but I'm not sure. Would you mind posting a snippet of Smalltalk code to clarify it?
I will admit that I only know one massively successful Smalltalk "commercial-grade" application, viz. Visual Age for Java. OTOH, you might want to ask companies such as Sprint, FedEx, and various large banks about the suitability of Smalltalk for mission-critical applications.
If you don't like Smalltalk, that's fine with me (it's not my first choice for most things either, honestly), but please don't spread misinformation about it.
Well, if Graham isn't your cup of tea, you should definitely take a look at Norvig's Paradigms of Artificial Intelligence Programming (which is actually of interest to a much wider audience than just AI people, but I digress). As someone else said, Steele's book Common Lisp: the Language is good, thought it predates the ANSI standard, hence you need to be a little careful. The standard itself (or more likely, the Hyperspec, which you can find online at various places; check for example Xanalys; there should be a copy around there somewhere. You can certainly download it, if not independently, as part of their personal edition of Lispworks) is very readable and informative. For a starting CLOS reference, try Sonya Keene's book Object-Oriented Programming in Common Lisp.
Of those, I particularly recommend Norvig, and recommend that you get a copy of the Hyperspec, which you will quickly find much more useful than the back of Graham's book. You might also want to describe exactly what Lisp system you are using, as this may possibly help us give further advice.
While I would personally rather implement almost anything in Common Lisp than Perl (the primary exceptions being when Perl's CPAN advantage comes into play), I certainly sympathize with your plight; it's hard to imagine why they oughtn't let you implement your projects however you like.
Plus, if you really want to close this back door, you can start uninterning symbols. I can't think offhand of any way someone could get their hands on something that that's been done to.
Seeing stories like this (and having the relatively sheltered career, such as it is, that I've had), I've often wondered why management worries about finding (insert language) programmers rather than just finding good programmers (with the assumption that a truly good programmer will be able to relatively rapidly acquire whatever skill set is necessary). I don't dispute that one can probably find more Java programmers than Lisp programmers, but can one find significantly more truly good Java programmers than good Lisp programmers?
To the untrained eye (like mine), it's also always mysterious why, when your team was able to build everything necessary with four programmers, a good management would want to a) take on a lot of extra people (and salary, no doubt) and b) take on the risk associated with a transition rather than c) just make sure that you four remained sufficiently well compensated that you'd want to stay on and continue meeting their needs. It'd seem to me that c) would be not only less risky, but less expensive.
You may have missed the point. The authors of SICP aren't trying to teach a programming language. They're trying to teach how to program, and, in the opinion of many (myself included), do a very good job. Scheme is incidental to their actual task (although it does suit it well).
Two good choices are CMUCL and CLisp. Information for both of these may be found at www.cons.org. (Warning-there have been some problems with the site lately. Be patient or try again if there is a problem. :-)
Emacs Lisp is mostly suited for writing Emacs and extensions thereof; it differs from more modern Lisps in some important ways. Of course, one should still know it to facilitate customization of Emacs. :-)
Agreed that Lisp won't put you close to the hardware (in most cases - there are always the Lisp machines :-). Disagreed that it's hard to do bit twiddling. In fact, there are two different good ways to do bit twiddling: bit-arrays and their associated functions, and ordinary integers together with the logwhatever, dpb, ldb etc. functions.
I can't really address suggestion 1, though I can't ever remember being particularly ill-treated by anyone. As for 2.:
There is a Free-CLIM project, although I don't know its status
It's unclear, though, how the lack of free CLIM implementations makes any statements about its usefulness. It merely indicates that you are either unable or unwilling to use a commercial implementation, which is fine, but really only makes a very local statement about it's usefulness (viz. that it's not useful to you in particular).
Why is it relevant how readable a program written in some language one doesn't know is? I don't think there's anything wrong with Russian because I can't gain any understanding from looking at a Russian text. I think people who know (i.e. use regularly, not studied for two weeks one semester in school) Lisp find it perfectly readable.
Actually the standard doesn't require Common Lisp to be tail recursive. A decent implementation should be, however, at least at appropriate optimization settings.
There's always CLIM for such things.
Actually, it turns out to be incredibly useful for reading and writing any sort of data - not just code.
Specifically what features do you feel that a Lisp such as Lispworks (as Mark mentioned) or Allegro do you feel are missing that makes building multi-threaded applications a problem? For your reference, the chapter of the Lispworks Reference manual describing the MP package is here
If you're at all language agnostic, there are good offerings that will work on both Windows and Linux, for example Cincom VisualWorks (Smalltalk) and XAnalys Lispworks (Common Lisp), both of which have fine IDEs.
Perl does in fact have proper closures. E.g.
#!/usr/bin/perl -w
use strict;
sub make_adder {
my $addend = shift;
sub {my $x = shift; $x + $addend}}
my $adder = make_adder(3);
print &$adder(2), "\n";
IMHO not as nice as Lisp or ML, but there nonetheless.
If I'm not mistaken, one of my compadres from comp.lang.lisp :-) (ok, I'm really more of a lurker than a contributer). Glad to see you have more concrete information, as much of what I was spouting off about was gleaned from places like comp.lang.lisp.
Have any insight into why your last point is so? Given the productivity boost I've seen by using things like Lisp in my own work, and evidence as you present on another scale, I'd think companies would want to embrace such techology.
Before I say anything else, let me say that it's refreshing to have a reasonable discussion with an AC. :-)
Also let me say that I'm the lone programmer at my company, and do not have first hand experience at "large-scale" Lisp development, so some (though not all) of the things I might relate about that have to be taken in that light. They come mostly from reading others' accounts of the same.
I get the impression that larger Lisp projects will not approach the team size you mention above. Lisp advocates will tell you that this is because not so many are necessary to achieve the same results. I'm inclined to believe this, but keep in mind my caveat above.
Lisp's type system is strong (i.e. things are of definite types and don't automatically and mysteriously switch between them, as in Perl), it's just not static (i.e. variables may contain values of different types, which makes compile time type checking difficult or impossible - although, there are implementations that are able to do it to some extent). I don't know if that makes the distinction clear, but there is a difference between the static/dynamic and weak/strong axes. Lisp would be dynamic/strong. Since dynamic/static types and their advantages/disadvantages are rather religious issues, it's unlikely that any discussion of that would be of benefit. IMHO it's perfectly possible to make robust applications with dynamic typing, but I can also see where the static typing people are coming from, so let's leave it at that. (Incidentally, something like ML or OCaml might be of interest to you if you're committed to static typing. I'd say their type systems are a considerable improvement on C++/Java style. And actually they meet some of your other requirements well too.)
Lisp does have the kinds of features that you need for larger programs. Packages (think namespaces) allow you to keep things hidden and to keep people out of each other's way. CLOS provides an object system which is at least as powerful and is much used in Lisp projects. The condition system is not radically different from the exception systems. Finally, macros, while rather a dirty word in C++ circles, are much more useful and sane in Lisp, and can help tremendously in some of the engineering needs that you mention.
You would be right that Lisp chooses more to give you the ability to use these things properly and usefully rather than forcing such use. Put another way, for best use one must assume that the programmers, designers, etc. are competent. With packages, for example, there is a notion of exported symbols. So if I'm using someone else package, I should only use the exported symbols (which one might think of as the interface to the package). However, if I want to be devious about it (okay, you don't actually have to be that devious), I can get to the internal symbols. (I'm not a C++ expert, but I'd suspect that you can do similar things with respect to private variables, etc. if you know how to fool around with pointers properly, and so on.) A programmer is expected to know that while this is possible, it's not a good idea. And so on. Since IMHO the most important thing one can do to get a robust application is to get good people working on it (and I don't have much sympathy for those who neglect this), this doesn't disturb me that much, but others' requirements may vary.
(And, in case it's not evident, I'm certainly not saying that Lisp is best for every large scale project, just that it is appropriate for many of them.)
No one can really say if making the GUI aspects of Smalltalks more like a C++ toolkit would make it more popular among (non Smalltalking) programmers. However, it doesn't seem that it would make much sense to do that. The GUI frameworks in Smalltalk are set up to (as you might expect) work logically, consistenty, and robustly with Smalltalk. There's little reason to try to bolt things from a different langauge onto it, and as always, trying to use one language like another instead of using it like itself is not likely to produce good results. As far as producing native-seeming apps for an end user, some Smalltalks take this approach. For example, at work I use Dolphin Smalltalk, whose GUI system is based around native Windows widgets. Build an app and it looks just like it would if you built it with VC++ or VB. It would certainly be possible for a Smalltalk vendor to do this on other platforms (and in fact VW or VA may well work that way; I don't know).
I doubt too many people would argue that with current machines/OSes something like C is better for getting close to the machine. Of course, there are examples like the Symbolics Lisp Machine where everything was in Lisp, so that wasn't true.(As far as speed goes, that's really an implementation rather than language issue. If one knows how to optimize Lisp code properly and has an implementation with a good compiler, one can do pretty well. See, for example, CMUCL. Or this page for more pointers. I will be honest, however, and admit to sometimes coding small parts of programs in C to improve performance. With the emphasis on small. :-) I do think Smalltalk wins hands down as far as anything I know for GUI, but particular Lisp implementations needn't be all that bad; I use Lispworks, and I don't think I'd say that I think GUI building is any harder in that than in a typical C++ or Java environment. I do think you may underestimate how suitable it is for "industrial strength" applications, though. Hang out in comp.lang.lisp for a while (or better, search the archives) and you will discover those who have built very serious, very large apps in Lisp, in part because of its suitability for such projects.
Given that Smalltalks, typically, are mostly self-contained enviroments with built in GUI building tools, it seems rather unlikely that there will be a big proliferation of toolkits for them. On the other hand, I doubt most people who use Smalltalk feel that such is necessary, as the ones that exist with the environments are typically well thought out and useful and pretty complete already. I'm not qualified to say very much about performance aspects of Smalltalk, since I don't use it for such tasks (but primarily for building GUIs), but you might possibly be surprised at how well something like VW or VA can do.
I use (Common) Lisp as my main general purpose language, and I think it works pretty darn well for most tasks (well enough that I choose it above anything else). I suspect most Lisp programmers would agree with your statement with C++ swapped for Lisp, except few of them would claim that it's fun. :-)
Well, there isn't static typing in Lisp. There is strong typing, but not static. Some implementations (CMUCL, for example) have some ability to make such static checks. But an implementation needn't, and in fact, may not be able to. For example, in your second example, what if we do (bar (read *standard-input*))? There's no way to know at compile time what type of data read is going to return, so reasonable static checking seems somewhat impossible here.
Also, the second example doesn't have to error. If you look here for example, you will see that if we do something like (bar 0) the spec. declares that the consequences are undefined. If you then check the definitions here, you'll see that this doesn't necessarily mean that an error is signaled. It may be, but it needn't be.