Yet another Smalltalk or Lisp discussion (Windows Centric)
in [Lisp]
|
From: sean.mymail on 7 Sep 2006 05:55 Hi, After a fair amount of research I have decided to use the CLISP version of Common Lisp running under Windows XP. I had initially dismissed Smalltalk almost out of hand but think it may be worth another look. More than likely I will end up trying out both languages in the long run, but in the short to medium term I want to start with the language with the easier learning curve, best development environment for Windows XP and least frustrations. Now if I had a UNIX background and development environment the decision would to me almost have been a no-brainer - start with Lisp. However I intend to do all future development under Windows with the option to be able to easily move to Linux at some point in the future. Lisp under Windows is a pain to say the least. I hate Emacs (yes I know it is extremely powerful) and Slime is not a lot better. Almost nothing in Common Lisp for Windows is straight forward to use. The only exception is Dr. Scheme - and that is Scheme not Lisp. Now all these problems are surmountable with some effort and hacking, although I can't seem to be able to drop Emacs from the equation I'm sure I could eventually learn to tolerate it. I do have the option of using commercial stuff for free for non commercial purposes - but both Lispworks and Allegro are crippleware unless paid for. Now it appears to me that Smalltalk is a much better proposition for someone wanting to develop under Windows. I can get VisualWorks free for non commercial use with no features disabled at all. I don't want to lose the flexibilty of Lisp though and it seems to me that Smalltalk pretty much is able to match Lisp in terms of flexibility. Both Lisp and Smalltalk are extensible and hot updates of running programs are easy. Smalltalk code seems to look a lot better to the eye than Lisp - very personal opinion of course. Smalltalk of course forces you to use OO while with Lisp it is optional - but that isn't really an issue to me. The 4 biggest reasons (to me) perhaps to not consider Smalltalk and stay with Lisp as a language are: 1. Lisp is amazing for bottom up development - and this style of development totally suits me. Just get something simple running immediately and keep on adding features. Prototyping is of course very simple under Lisp. I am not sure Smalltalk can compete here. 2. Lisp Macros. Simple to extend the language and create self-modifying systems. Smalltalk has some of this ability but again I am not sure it is easy to create any language from Smalltalk the way one can under Lisp. 3. Codebase and Libraries. I haven't really investigated this in detail for Smalltalk - would appreciate it if people could give me an idea of Smalltalk vs Lisp here. 4. Execution speed - Lisp can be very optimised - how does Smalltalk compare here?
From: Friedrich Dominicus on 7 Sep 2006 06:27 sean.mymail(a)googlemail.com writes: > Now it appears to me that Smalltalk is a much better proposition for > someone wanting to develop under Windows. I can get VisualWorks free > for non commercial use with no features disabled at all. Well I can not see the big difference while using e.g LispWorks. > Smalltalk code seems to look a lot better to the eye than Lisp - very > personal opinion of course. To less braces ? ;-) > > Smalltalk of course forces you to use OO while with Lisp it is optional > - but that isn't really an issue to me. > > The 4 biggest reasons (to me) perhaps to not consider Smalltalk and > stay with Lisp as a language are: > > 1. Lisp is amazing for bottom up development - and this style of > development totally suits me. Just get something simple running > immediately and keep on adding features. Prototyping is of course very > simple under Lisp. I am not sure Smalltalk can compete here. I disagree, Smalltalks is at least as fine in this area. And you usually get the GUI stuff extra, which is not "default" with anything but the commercial Lisps > > 2. Lisp Macros. Simple to extend the language and create self-modifying > systems. Smalltalk has some of this ability but again I am not sure it > is easy to create any language from Smalltalk the way one can under > Lisp. > > 3. Codebase and Libraries. I haven't really investigated this in detail > for Smalltalk - would appreciate it if people could give me an idea of > Smalltalk vs Lisp here. Smalltalks are known for the large libraries, and every Smalltalk ships with thousand of classes, the same is true for commercial Lisp, less so for free lisps, changing from one Smalltalk to another will give you another set of libraries, IMHO the lisp offers are often much more portable between Lisps. > > 4. Execution speed - Lisp can be very optimised - how does Smalltalk > compare here? They always were fast enough for me. However I have one test where the speed difference is magntinute lower with Squeak. Have not tried with other Smalltalks... Regards friedrich -- Please remove just-for-news- to reply via e-mail.
From: Chris Uppal on 7 Sep 2006 07:11 sean.mymail(a)googlemail.com wrote: > 1. Lisp is amazing for bottom up development - and this style of > development totally suits me. Just get something simple running > immediately and keep on adding features. Prototyping is of course very > simple under Lisp. I am not sure Smalltalk can compete here. Funny that, I'd have put it the other way around. Part of the problem for Lisp is the relative feebleness of the development environments (necessarily code-centric rather than object-centric). Of course, this will depend on individual tastes and talents, so either one may suit someone better than the other. For me, I find it easier to train my objects to perform their tricks if I can interact with them directly, instead of having to write an instruction manual for them to read... > 2. Lisp Macros. Simple to extend the language and create self-modifying > systems. Smalltalk has some of this ability but again I am not sure it > is easy to create any language from Smalltalk the way one can under > Lisp. It doesn't, or not to the same extent. But don't confuse yourself about macros. They are /a/ technique for abstraction (and arguably are only needed in Lisp as a performance optimisation and in order to get around some language restrictions (fixed evaluation order) which don't exist in Smalltalk. The key thing here is abstraction, and it's a mistake to think that the tools for abstraction are the same in any two languages -- let alone two as powerful and idiosyncratic as Smalltalk and Lisp. You do abstraction in Smalltalk by building richer ecologies of objects, not by creating interpretive towers. > 3. Codebase and Libraries. I haven't really investigated this in detail > for Smalltalk - would appreciate it if people could give me an idea of > Smalltalk vs Lisp here. As a Lisp outsider it looks to me as if they are about par. There are libraries for both, but nothing like as extensive as what's available for Java or C; both can (and often should) make use of external libraries instead of re-implementing stuff. Note that Smalltalk is weaker than Lisp at sharing code across dialects, so your choice of implementation will have more impact on what's conveniently available than would be the case if you were working in Lisp. > 4. Execution speed - Lisp can be very optimised - how does Smalltalk > compare here? Wrong question. You should be comparing specific implementations, since there is a wide variance in speed between implementations of either language. Also you should consider what you want that speed for -- unless the difference in performance between Smalltalk <A> and Lisp <B> /actually/ matters to your program(s), then it is purely academic which is fastest. FWIW, I think you can probably get significantly better performance at number crunching out of a fast Lisp with an optimising compiler than out of most Smalltalk implementations. But, for most purposes, either language (almost any implementation except toys) will be "fast enough". E.g I use Dolphin Smalltalk (which I recommend you take a look at, BTW) which uses a fast interpreter, unlike VW's JITed compilation; the difference in speed is measurable (about a factor of 3 for one real program of mine), but is hardly ever relevant -- and is certainly nowhere near enough to make me consider switching to VW. -- chris
From: David E. Young on 7 Sep 2006 10:02 Here's an idea. Just ask the Lispworks (or Franz) folks for an evaulation license. Explain to them what you're doing and how long you'll need for your comparison work. I think you'll find either vendor more than happy to accommodate your needs, if you're candid with them from the beginning. It's really that simple. david sean.mymail(a)googlemail.com wrote: > > I do have the option of using commercial stuff for free for non > commercial purposes - but both Lispworks and Allegro are crippleware > unless paid for...
From: Ken Tilton on 7 Sep 2006 11:45
Chris Uppal wrote: > sean.mymail(a)googlemail.com wrote: > > >>1. Lisp is amazing for bottom up development - and this style of >>development totally suits me. Just get something simple running >>immediately and keep on adding features. Prototyping is of course very >>simple under Lisp. I am not sure Smalltalk can compete here. > > > Funny that, I'd have put it the other way around. Part of the problem for Lisp > is the relative feebleness of the development environments Yep. > (necessarily > code-centric rather than object-centric). Not a problem if you are not exclusively using objects. And even then with multi-methods a lot of code still is not centric to any one class. And ST is not just OO-centric, it is OO-obsessive. "All X all the time" has a surface appeal that breaks down in real applications. > > Of course, this will depend on individual tastes and talents, so either one may > suit someone better than the other. For me, I find it easier to train my > objects to perform their tricks if I can interact with them directly, instead > of having to write an instruction manual for them to read... The way I work, I vastly prefer having a page-full of code right in front of me so I can slice and dice left and right. Smalltalk IDEs have a surface appeal and I suppose are great for compulsive types who can work on only one thing at a time, but they just held me back and made /me/ dance to their tune. That is the great thing about Lisp non-IDEs. Any serious developer quickly enough rolls their own IDE that works just the way they like. > > > >>2. Lisp Macros. Simple to extend the language and create self-modifying >>systems. Smalltalk has some of this ability but again I am not sure it >>is easy to create any language from Smalltalk the way one can under >>Lisp. > > > It doesn't, or not to the same extent. But don't confuse yourself about > macros. They are /a/ technique for abstraction (and arguably are only needed > in Lisp as a performance optimisation and in order to get around some language > restrictions (fixed evaluation order) which don't exist in Smalltalk. No, that is wrong. I have never used a macro for either purpose, and I write a /lot/ of macros. Macros simply allow one to condense the code in ways functions cannot, for all the advantages of condensed code: readability/writability, ease of refactoring/maintenance, code reliability from re-use, etc etc. A good programmer develops mini-frameworks within their apps, macros let one automate or at worst hide any/all boilerplate required by these frameworks. > The key > thing here is abstraction, and it's a mistake to think that the tools for > abstraction are the same in any two languages -- let alone two as powerful and > idiosyncratic as Smalltalk and Lisp. You do abstraction in Smalltalk by > building richer ecologies of objects, not by creating interpretive towers. So the macro issue gets swept under the rug with "OO for ST, macros for Lisp"? Nonsense. CL has OO. More powerfully than ST. So the real story is: "CL (a) has a /better/ tool for OO abstraction and (b) ST completely lacks an abstraction tool (macros) CL developers would not want to live without." OO-wise: -- Smalltalk does not allow multiple-inheritance. -- Smalltalk does not support multi-methods. -- CLOS has before/after/around methods, and non-vanilla method combinations. Smalltalk? Other-wise: -- Smalltalk does not have macros. -- Smalltalk forces one to use an object for everything, CL supports multiple paradigms. -- Smalltalk IDEs are more sophisticated out of the box. Finally, the CL community is growing fast. Smalltalk? hth, kenny -- Cells: http://common-lisp.net/project/cells/ "I'll say I'm losing my grip, and it feels terrific." -- Smiling husband to scowling wife, New Yorker cartoon |