It may be of interest to know that for a long time Visual Age for Java was itself written in Smalltalk. I think that may have changed by the very last versions, but certainly the earlier ones were.
Ah, how I loved my HP-28S. Unfortunately the cover to the battery compartment gave out (seems like a weak point in the design; I'd imagine others have had the problem).
I never liked the later HP calculators as well because they didn't have the separate alphabetic keyboard, which I found a real convenience.
Actually I think it's considerably less useful to review a bad book. Why? There are many, many times more books written than I will read. Therefore a bad review is most likely to warn me away from a book that I wasn't going to read anyway. And chances are (given the limited number of reviews) that no review will appear of a bad book that I planned to read.
However, a good review may point me to a useful or interesting book that I would have otherwise overlooked.
The obvious exception to this is when one can give a bad review to a book that is expected to have a very wide readership (and thus can warn many people away from a bad book), but how many technical books fall into this category?
Actually, I do read my old code and I do read other's code. And I typically find others' Lisp code easier to read than others' C code. In fact I'd say that while I'd expect the readability of "beginner's" code to vary wildly, I usually find that I can read an experienced Lisp programmer's code fairly easily, whereas the readability (to me) of code of experienced C (for example) programmers still varies quite a bit. So it would appear that we simply have a case of YMMV.
I program Lisp, and I'd say that I can write a line of Lisp code faster than I could a line of C code. Of course, I write a lot more Lisp code than C code. Of course, this works the other way around too. Most of the people we see on Slashdot whining about how hard it is to write Lisp code have written a lot more C (or whatever) than Lisp; well, of course it's harder for them. Spend a significant amount of time writing Lisp and it becomes pretty easy.
And lining up parens? Isn't that why we have editors? Eventually you stop thinking about the parens anyway and start thinking in terms of forms, which is a much more useful viewpoint.
Then you probably want links like
Franz success stories, or perhaps this from
ALU.
Or Digitool.
And of course these are just Common Lisp references; you can surely dig up similar things for other languages as well.
My apologies if you took my statement to imply that you needed static typechecking as a cruch. The fact of the matter is that we all have things that cause us problems and things that don't, and things that emphasize our strengths and things that don't. I personally have an easier time creating robust, useful software quickly in dynamically typed languages like Common Lisp and Smalltalk. Other people can do it better in things like Haskell or ML (which the language of that vein that I am most familiar with). I find that dynamic typing helps me a lot more than static typing. YMMV, and in fact probably will.
It'd probably be more accurate to say that what you want is your static typechecker, not your compiler, given that Smalltalk (and many other
dynamically (yet strongly) typed languages, e.g. Common Lisp) are typically compiled.
Nevertheless, your concern is not without any merit. People who take to dynamically typed languages don't seem to have the problems with type errors that those who do not think they would, but if one has a problem it may well be better to stick to something with static typing. In any case, the whole static/dynamic typing issue does not, IMHO, obviate the usefulness of Smalltalk for getting a handle on OO concepts.
Yet it is so very true that a typical object-oriented language like C++ or Java is much harder to learn than a procedural language like C
One could always learn a different typical object-oriented language (e.g. Smalltalk) that is much easier to learn. About the worst side-effect of that is never wanting to go back to something like C++ or Java.
CLISP is written in C. As far as I know, CMUCL and SBCL are written in Lisp (granted, CMUCL and SBCL are pretty intimately related). So two of the three big free Lisp implementations are not in C. To the best of my knowledge, the big commercial Lisps such as Allegro and Lispworks are also written in Lisp.
I love Common Lisp and do most of my heavy lifting in it, but let's not get _too_ carried away. In Lispworks for Windows 4.2.6, your example (or rather either a tail-recursive version of it that doesn't cause the stack to overflow or a natural direct iterative version such as by using loop) takes about 2.6s to run on my box. An equivalent program in Dolphin Smalltalk takes.629s on the same box, and as you can see, there are no special tricks and the code is as simple.
Integer<<factorialIterative | factorial | factorial:= 1. 2 to: self asInteger do: [:i | factorial:= i * factorial]. ^factorial
While the ANSI Common Lisp standard is comparably sized to the C++ standard, there is one important difference - it's actually really easy to read.:-) I think most Lisp programmers start very early in their development to start referring to and using the standard on a regular basis. I'm less sure about C++ programmers.
Moreover, I don't believe that you're correct. Lisp AFAIK started out as a functional programming language, and Common Lisp added objects much later.
He claimed that Common Lisp specifically (and not Lisp in general) was to provide an OO environment. From the history in the Hyperspec, object-oriented ideas in general were find their way into the Lisp world by the late 70s. While (as far as I can tell; I wasn't really old enough to be around the community at the time) the 1984 definition of Common Lisp didn't include CLOS, clearly people were thinking about it and the problems that had to be solved in getting an object system that would be as compatible as possible with the variety of object systems that had cropped up. (A little more information about this period can be found in Keene's book on CLOS, or in AMOP.) CLOS was officially adopted into Common Lisp in 1988 and appears in the second edition of Steele. It has always been part of the ANSI standard. Since the latter is what people mean when they casually say "Common Lisp" nowadays, I think it's fair to say that having OO facilities was a part of the goal of Common Lisp.
Also, in the history from the Hyperspec we find the following:
In 1986 X3J13 was formed as a technical working group to produce a draft for an ANSI Common Lisp standard. Because of the acceptance of
Common Lisp, the goals of this group differed from those of the original designers. These new goals included stricter standardization for portability, an object-oriented programming system, a condition system, iteration facilities, and a way to handle large character sets. To accommodate those goals,
a new language specification, this document, was developed.
So at very least we have to conclude that by 1986 that this was one of the design goals of Common Lisp
Once the boss see's the solution, he'll probably add another requirement: "no run-time licences" which means that the versions of lisp with the neat GUI are out:/
As the original poster mentioned, Lispworks has this (in fact either CLIM or Lispworks' own CAPI) with no runtime fees for Linux or Windows (these were dropped when version 4.2 came out)
Given that CLOS is part of the ANSI Common Lisp standard, this is hardly surprising; one can't claim to be standards compliant without providing it.:-)
A good source for starting to address all of your garbage collection questions is Jones & Lins' book,
Garbage Collection : Algorithms for Automatic Dynamic Memory Management. Another good source is The Memory Management Reference
Okay, LISP doesn't lack objects, but it does lack (automatic) function dispatching depending on the type of an object. But this could easily be hacked into it, if someone wanted to:)
I'm not sure what you mean by this? What do you think having various methods for a generic function does if not dispatch based on the types of the arguments? Perhaps you ought to make section 7.6 one of the sections of the CLHS that you read.:-)
There's an intriguing book called bject-Oriented Implementation of Numerical Methods: An Introduction with Java & Smalltalk which might give some pointers. I haven't read it (just browsed it in a bookstore), so I can't give a personal recommendation one way or the other. It does seem rather intended to address just your question, though.
Well, then please explain to us very specifically why you think the thread and/or socket interface from a major Common Lisp implementation such as Allegro is bad.
Slashdot Mirror
Sure, that's easy.
:-)
ANSI Common Lisp already satisfies that requirement.
It may be of interest to know that for a long time Visual Age for Java was itself written in Smalltalk. I think that may have changed by the very last versions, but certainly the earlier ones were.
Ah, how I loved my HP-28S. Unfortunately the cover to the battery compartment gave out (seems like a weak point in the design; I'd imagine others have had the problem).
I never liked the later HP calculators as well because they didn't have the separate alphabetic keyboard, which I found a real convenience.
Actually I think it's considerably less useful to review a bad book. Why? There are many, many times more books written than I will read. Therefore a bad review is most likely to warn me away from a book that I wasn't going to read anyway. And chances are (given the limited number of reviews) that no review will appear of a bad book that I planned to read.
However, a good review may point me to a useful or interesting book that I would have otherwise overlooked.
The obvious exception to this is when one can give a bad review to a book that is expected to have a very wide readership (and thus can warn many people away from a bad book), but how many technical books fall into this category?
Well, for starters I'd look here (make sure to look at the links in the navigation bar on the left) and here.
Actually, I do read my old code and I do read other's code. And I typically find others' Lisp code easier to read than others' C code. In fact I'd say that while I'd expect the readability of "beginner's" code to vary wildly, I usually find that I can read an experienced Lisp programmer's code fairly easily, whereas the readability (to me) of code of experienced C (for example) programmers still varies quite a bit. So it would appear that we simply have a case of YMMV.
I program Lisp, and I'd say that I can write a line of Lisp code faster than I could a line of C code. Of course, I write a lot more Lisp code than C code. Of course, this works the other way around too. Most of the people we see on Slashdot whining about how hard it is to write Lisp code have written a lot more C (or whatever) than Lisp; well, of course it's harder for them. Spend a significant amount of time writing Lisp and it becomes pretty easy.
And lining up parens? Isn't that why we have editors? Eventually you stop thinking about the parens anyway and start thinking in terms of forms, which is a much more useful viewpoint.
Sure. A couple of good options are Lispworks and VisualWorks
Then you probably want links like Franz success stories, or perhaps this from ALU. Or Digitool. And of course these are just Common Lisp references; you can surely dig up similar things for other languages as well.
Gee, I hope so. Otherwise a lot of the software I've written for my employer's trading business the past few years isn't real.
My apologies if you took my statement to imply that you needed static typechecking as a cruch. The fact of the matter is that we all have things that cause us problems and things that don't, and things that emphasize our strengths and things that don't. I personally have an easier time creating robust, useful software quickly in dynamically typed languages like Common Lisp and Smalltalk. Other people can do it better in things like Haskell or ML (which the language of that vein that I am most familiar with). I find that dynamic typing helps me a lot more than static typing. YMMV, and in fact probably will.
It'd probably be more accurate to say that what you want is your static typechecker, not your compiler, given that Smalltalk (and many other dynamically (yet strongly) typed languages, e.g. Common Lisp) are typically compiled.
Nevertheless, your concern is not without any merit. People who take to dynamically typed languages don't seem to have the problems with type errors that those who do not think they would, but if one has a problem it may well be better to stick to something with static typing. In any case, the whole static/dynamic typing issue does not, IMHO, obviate the usefulness of Smalltalk for getting a handle on OO concepts.
One could always learn a different typical object-oriented language (e.g. Smalltalk) that is much easier to learn. About the worst side-effect of that is never wanting to go back to something like C++ or Java.
CLISP is written in C. As far as I know, CMUCL and SBCL are written in Lisp (granted, CMUCL and SBCL are pretty intimately related). So two of the three big free Lisp implementations are not in C. To the best of my knowledge, the big commercial Lisps such as Allegro and Lispworks are also written in Lisp.
It's hard to figure Lisp having C/C++ at it's core when it existed long before C was invented.
I love Common Lisp and do most of my heavy lifting in it, but let's not get _too_ carried away. In Lispworks for Windows 4.2.6, your example (or rather either a tail-recursive version of it that doesn't cause the stack to overflow or a natural direct iterative version such as by using loop) takes about 2.6s to run on my box. An equivalent program in Dolphin Smalltalk takes .629s on the same box, and as you can see, there are no special tricks and the code is as simple.
While the ANSI Common Lisp standard is comparably sized to the C++ standard, there is one important difference - it's actually really easy to read. :-) I think most Lisp programmers start very early in their development to start referring to and using the standard on a regular basis. I'm less sure about C++ programmers.
He claimed that Common Lisp specifically (and not Lisp in general) was to provide an OO environment. From the history in the Hyperspec, object-oriented ideas in general were find their way into the Lisp world by the late 70s. While (as far as I can tell; I wasn't really old enough to be around the community at the time) the 1984 definition of Common Lisp didn't include CLOS, clearly people were thinking about it and the problems that had to be solved in getting an object system that would be as compatible as possible with the variety of object systems that had cropped up. (A little more information about this period can be found in Keene's book on CLOS, or in AMOP.) CLOS was officially adopted into Common Lisp in 1988 and appears in the second edition of Steele. It has always been part of the ANSI standard. Since the latter is what people mean when they casually say "Common Lisp" nowadays, I think it's fair to say that having OO facilities was a part of the goal of Common Lisp.
Also, in the history from the Hyperspec we find the following:
So at very least we have to conclude that by 1986 that this was one of the design goals of Common Lisp
As the original poster mentioned, Lispworks has this (in fact either CLIM or Lispworks' own CAPI) with no runtime fees for Linux or Windows (these were dropped when version 4.2 came out)
Given that CLOS is part of the ANSI Common Lisp standard, this is hardly surprising; one can't claim to be standards compliant without providing it. :-)
A good source for starting to address all of your garbage collection questions is Jones & Lins' book, Garbage Collection : Algorithms for Automatic Dynamic Memory Management. Another good source is The Memory Management Reference
Okay, LISP doesn't lack objects, but it does lack (automatic) function dispatching depending on the type of an object. But this could easily be hacked into it, if someone wanted to :)
I'm not sure what you mean by this? What do you think having various methods for a generic function does if not dispatch based on the types of the arguments? Perhaps you ought to make section 7.6 one of the sections of the CLHS that you read. :-)
There's an intriguing book called bject-Oriented Implementation of Numerical Methods: An Introduction with Java & Smalltalk which might give some pointers. I haven't read it (just browsed it in a bookstore), so I can't give a personal recommendation one way or the other. It does seem rather intended to address just your question, though.
Well, then please explain to us very specifically why you think the thread and/or socket interface from a major Common Lisp implementation such as Allegro is bad.
Actually, it'd be a lot more likely to give you an error, since define isn't a standard function in Common Lisp.