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?
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
···········@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...
···········@googlemail.com wrote:
> Hi,
>
> After a fair amount of research I have decided to use the CLISP version
> of Common Lisp running under Windows XP.
CLisp works fairly well under Windows, ECL does too. The problem with
Windows CL is that things like GUI libs work best on *nix. Ltk works
on Windows though, and I've heard Cells-Gtk does too.
It depends what you want to do. For stuff that doesn't require lots of
system interfacing its OK.
> I had initially dismissed Smalltalk almost out of hand but think it may
> be worth another look.
I don't know about Smalltalk, so I'll only comment on Lisp below.
> Lisp under Windows is a pain to say the least. I hate Emacs (yes I know
> it is extremely powerful)
In the long term it is worth learning. If you learn it then it
eliminates the need for learning a new IDE every time you need to
change language for some reason.
> 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.
Yes. DrScheme is good. If you want an easy platform to learn
programmable programming languages on Windows I would pick DrScheme.
Stepping to CL afterwards would be no big deal.
> 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.
What is the difficulty you have with it?
I'd say all in all it doesn't matter what you first learn with. But
when you transition to making a real app you need to make the decision
again based on the problem.
···········@googlemail.com wrote:
> 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:
>
Do you know either Lisp or Smalltalk?
> 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.
If you know Smalltalk, prototyping is simple with Smalltalk.
>
> 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.
If you know Lisp well enough to write self modifying code, perhaps you
should use Lisp. Not sure exactly what you mean by "create any language
from Smalltalk" - people do write languages in Smalltalk
http://prog.vub.ac.be/research/DMP/soul/soul2.html
>
> 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.
Depends quite a lot on the specific Smalltalk implementation. If you
could be more specific about what you need then people could give
better help - it doesn't really matter how extensive the libraries are,
it really does matter that the libraries you need are available.
>
> 4. Execution speed - Lisp can be very optimised - how does Smalltalk
> compare here?
Again it depends quite a lot on the specific Smalltalk and Lisp
implementations. Good Lisp compilers should result in faster execution
speed than good Smalltalk JIT VMs, good Smalltalk JIT VMs should result
in faster execution speed than good Lisp interpreters, but you knew
that already ;-)
Maybe look at Smalltalk/X
http://www.exept.de/exept//english/Smalltalk/frame_uebersicht.html
···········@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
Chris Uppal wrote:
> ···········@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).
Agreed, and after reading some of the archives of the LispOS threads
over at tunes, it seems that the no-brainer option would have been to
develop a Squeak-like system (that actually is visually attractive) on
top of X and using an existing kernel instead of starting from the
bottom-up and wasting time discussing whether it's pure enough if
you're not writing device drivers in Lisp.
>
> 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.
>
>
I'm not an expert in either language, but I somehow doubt that there's
really a Smalltalk equivalent for the abstractions afforded by macros.
And then there's CLOS and it's multi-dispatch. I think the similarity
of both of them though, is that both have the capabilities of producing
highly-interactive, runtime-modifiable environments. There's just not
current Lisp environments that take advantage of those abilities that
Smalltalk has.
It looks like right now, the best way forward is for SBLC to get the
windows port done, a 1.0 release, a modern, fast crossplatform gui, and
then someone(s) can start developing a modern, highly-interactive,
development environment for it. Of course as long as people think
Emacs is the holy grail...
From: Ken Tilton
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <r8ZLg.21$AY4.1@newsfe08.lga>
············@gmail.com wrote:
>
> It looks like right now, the best way forward is for SBLC to get the
> windows port done, a 1.0 release, a modern, fast crossplatform gui,
LTk, Cells-GTk, or Celtk/Cello.
> and
> then someone(s) can start developing a modern, highly-interactive,
> development environment for it.
I have an object inspector based on Cello (Tk+OpenGL) that could be
revived in a few days.
> Of course as long as people think
> Emacs is the holy grail...
If you add "revive Hemlock" to the above list you get an Emacs-like
editor (I think).
ken
--
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
From: Bill Atkins
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <m2y7svpl7l.fsf@joshu.local>
Ken Tilton <·········@gmail.com> writes:
> ············@gmail.com wrote:
>
>>
>> It looks like right now, the best way forward is for SBLC to get the
>> windows port done, a 1.0 release, a modern, fast crossplatform gui,
>
> LTk, Cells-GTk, or Celtk/Cello.
and CAPI.
From: Ken Tilton
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <IUZLg.31$VC6.3@newsfe09.lga>
Bill Atkins wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>············@gmail.com wrote:
>>
>>
>>>It looks like right now, the best way forward is for SBLC to get the
>>>windows port done, a 1.0 release, a modern, fast crossplatform gui,
>>
>>LTk, Cells-GTk, or Celtk/Cello.
>
>
> and CAPI.
For SBCL? :)
kt
--
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
From: Bill Atkins
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <m2ejunscx4.fsf@joshu.local>
Ken Tilton <·········@gmail.com> writes:
> Bill Atkins wrote:
>> Ken Tilton <·········@gmail.com> writes:
>>
>>
>>>············@gmail.com wrote:
>>>
>>>
>>>>It looks like right now, the best way forward is for SBLC to get the
>>>>windows port done, a 1.0 release, a modern, fast crossplatform gui,
>>>
>>>LTk, Cells-GTk, or Celtk/Cello.
>>
>>
>> and CAPI.
>
> For SBCL? :)
Heh heh heh. Time for me to start reading complete sentences.
············@gmail.com wrote:
> Chris Uppal wrote:
> > ···········@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).
>
> Agreed, and after reading some of the archives of the LispOS threads
> over at tunes, it seems that the no-brainer option would have been to
> develop a Squeak-like system (that actually is visually attractive) on
> top of X and using an existing kernel instead of starting from the
> bottom-up and wasting time discussing whether it's pure enough if
> you're not writing device drivers in Lisp.
FWIW I think quite a few lisp people think that LispOS is rather nuts
too.
············@gmail.com wrote:
> It looks like right now, the best way forward is for SBLC to get the
> windows port done, a 1.0 release, a modern, fast crossplatform gui, and
> then someone(s) can start developing a modern, highly-interactive,
> development environment for it.
I don't want to knock the SBCL people, and I admit that I know very little
about the whole thing, but still I doubt whether that will ever happen. The
principle problem any such effort would face is the fact that it has started in
the wrong place -- on Unix-like systems[*]. I don't see any reason in
principle why the various cross-platform UI toolkits couldn't be used to create
a /good/ environment, but I have never seen anything that even remotely came
close to putting that idea into practice. (I speculate that one reason may be
that many such toolkits -- or rather, the few which are capable of producing
decent results -- have been produced by programmers with a very static
mind-set.)
That's in addition to the observation that many programmers have never /seen/ a
decent interactive environment, and so have no idea what they are missing or
could be building. (I may as well be explicit -- in addition to my early
disclaimer -- that I have no idea whether this observation applies to the SBCL
people.)
And also there's my feeling that Lisp is just not as suitable a target for an
interactive environment as a pure OO language like Smalltalk -- the issue being
that there is nothing sensible to interact /with/ (so you end up with a
tarted-up version of a read-eval-print loop). That problem would not occur if
the environment committed itself fully to the OO approach to Lisp, and
basically said "if you aren't using CLOS for everything then we don't give a
damn about you" -- but I can't imagine that being very popular ;-) (And in
any case, if you want that kind of environment, why not just use Smalltalk ?)
-- chris
[*] I am very fond of Unix, btw, but GUI stuff on Unix is pretty uniformly
terrible -- or if there are any counterexamples, then /I/ haven't seen 'em.
From: Ken Tilton
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <q0fMg.529$AY4.507@newsfe08.lga>
Chris Uppal wrote:
> And also there's my feeling that Lisp is just not as suitable a target for an
> interactive environment as a pure OO language like Smalltalk -- the issue being
> that there is nothing sensible to interact /with/ (so you end up with a
> tarted-up version of a read-eval-print loop).
? One interacts with Lisp. The GUI is just a surface manifestation (I
assume you have heard of MVC). Add Tk or GTk to a Lisp and away you go.
The idea that Lisp applications (and an IDE is just another application)
are limited to the REPL is ridiculous. The AllegroCL IDE includes a REPL
window, I just never use it.
> That problem would not occur if
> the environment committed itself fully to the OO approach to Lisp,...
Talk about a category error. What has OO got to do with it? My only
guess is that you have been doing all-objects-all-the-time too long and
somehow think that that is the only way to program and/or build GUIs
hence IDEs.
You need to get out more. Even commercial Lisp GUIs such as CAPI and
Common Graphics are powerful enough to build an ST IDE. Same with C GUIs
used from Lisp, such as Tk and GTk.
And thanks to all the other power of Lisp, when confonted with
especially dynamic GUI requirements I almost accidentally developed a
dataflow hack (see sig) that makes insanely dynamic and interactive GUIs
a breeze to develop even atop toolkits developed with (yes) a static
mindset. All that macrology I expanded last time was from that library
(Cells).
ST developers have given ST programmers a lot of good stuff for dynamic
GUI development, but only those things the ST environment developers
have seen fit to support. Start hand-rolling a more sophisticated scheme
like Cells and the results are awful because there are no macros with
which to hide the boilerplate.
> and
> basically said "if you aren't using CLOS for everything then we don't give a
> damn about you"
OK, so you /do/ misunderstand OO to be somehow necessary to an IDE. The
AllegroCL IDE also let's me manage symbols, a backtrace, and generic
functions as well as objects. And I almost never use the object browser
because it is much easier to use the "find symbol definition" keychord
to get to the source (and because the information shown in object
browsers other than method source is rarely what I am looking for).
> -- but I can't imagine that being very popular ;-) (And in
> any case, if you want that kind of environment, why not just use Smalltalk ?)
My reasons are: no macros, no multiple-inheritance, and I do not like an
IDE getting between me and editing when i am refactoring and touching
dozens of bits of source at once.
kt
--
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
Ken Tilton wrote:
> Chris Uppal wrote:
>
> > And also there's my feeling that Lisp is just not as suitable a target for an
> > interactive environment as a pure OO language like Smalltalk -- the issue being
> > that there is nothing sensible to interact /with/ (so you end up with a
> > tarted-up version of a read-eval-print loop).
>
> ? One interacts with Lisp. The GUI is just a surface manifestation
> (I assume you have heard of MVC).
I occasionally appreciate sarcasm so that made me smile :-)
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
> Add Tk or GTk to a Lisp and away you go.
> The idea that Lisp applications (and an IDE is just another application)
> are limited to the REPL is ridiculous. The AllegroCL IDE includes a REPL
> window, I just never use it.
>
> > That problem would not occur if
> > the environment committed itself fully to the OO approach to Lisp,...
>
> Talk about a category error. What has OO got to do with it? My only
> guess is that you have been doing all-objects-all-the-time too long and
> somehow think that that is the only way to program and/or build GUIs
> hence IDEs.
>
> You need to get out more. Even commercial Lisp GUIs such as CAPI and
> Common Graphics are powerful enough to build an ST IDE. Same with C GUIs
> used from Lisp, such as Tk and GTk.
>
> And thanks to all the other power of Lisp, when confonted with
> especially dynamic GUI requirements I almost accidentally developed a
> dataflow hack (see sig) that makes insanely dynamic and interactive GUIs
> a breeze to develop even atop toolkits developed with (yes) a static
> mindset. All that macrology I expanded last time was from that library
> (Cells).
>
> ST developers have given ST programmers a lot of good stuff for dynamic
> GUI development, but only those things the ST environment developers
> have seen fit to support. Start hand-rolling a more sophisticated scheme
> like Cells and the results are awful because there are no macros with
> which to hide the boilerplate.
>
> > and
> > basically said "if you aren't using CLOS for everything then we don't give a
> > damn about you"
>
> OK, so you /do/ misunderstand OO to be somehow necessary to an IDE. The
> AllegroCL IDE also let's me manage symbols, a backtrace, and generic
> functions as well as objects. And I almost never use the object browser
> because it is much easier to use the "find symbol definition" keychord
> to get to the source (and because the information shown in object
> browsers other than method source is rarely what I am looking for).
>
> > -- but I can't imagine that being very popular ;-) (And in
> > any case, if you want that kind of environment, why not just use Smalltalk ?)
>
> My reasons are: no macros, no multiple-inheritance, and I do not like an
> IDE getting between me and editing when i am refactoring and touching
> dozens of bits of source at once.
I like the idea of a Smalltalk with Traits, but doubt anyone wants to
face the legacy issue of re-structuring existing class libraries :-(
http://www.iam.unibe.ch/~scg/Research/Traits/
I'm curious about your comment on refactoring - what tool support do
you have for refactoring?
>
> kt
>
> --
> 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
From: Ken Tilton
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <J_hMg.112$VC6.76@newsfe09.lga>
Isaac Gouy wrote:
> Ken Tilton wrote:
>
>>Chris Uppal wrote:
>>
>>
>>>And also there's my feeling that Lisp is just not as suitable a target for an
>>>interactive environment as a pure OO language like Smalltalk -- the issue being
>>>that there is nothing sensible to interact /with/ (so you end up with a
>>>tarted-up version of a read-eval-print loop).
>>
>>? One interacts with Lisp. The GUI is just a surface manifestation
>
>
>> (I assume you have heard of MVC).
>
> I occasionally appreciate sarcasm so that made me smile :-)
> http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
Yes, that was the joke. :)
> I'm curious about your comment on refactoring - what tool support do
> you have for refactoring?
Not sure if you mean automatic refactoring, which I hear the Java folks
have gotten into. If so, none. Otherwise, I happen to use a very nice
IDE from Franz (part of AllegroCL on win32 and (I hear) Linux now). It
lets me find things across a complex project and presents results in
list boxes so I can have at it. One thing they do not have is "find
callers", but MCLs IDE (also strongly graphical) had one, and I believe
I have in the past hacked one for ACL because another "find" tool (their
graphical APROPOS) happened to reveal on unexported function that would
support that. There is an object browser, but I tend not to use it
because the various "find" keychords get me there faster.
Lisp also makes refactoring easier by its very nature, but that is a
longer story.
kt
--
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
Ken Tilton wrote:
> Isaac Gouy wrote:
> > Ken Tilton wrote:
> >
> >>Chris Uppal wrote:
> >>
> >>
> >>>And also there's my feeling that Lisp is just not as suitable a target for an
> >>>interactive environment as a pure OO language like Smalltalk -- the issue being
> >>>that there is nothing sensible to interact /with/ (so you end up with a
> >>>tarted-up version of a read-eval-print loop).
> >>
> >>? One interacts with Lisp. The GUI is just a surface manifestation
> >
> >
> >> (I assume you have heard of MVC).
> >
> > I occasionally appreciate sarcasm so that made me smile :-)
> > http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
>
> Yes, that was the joke. :)
>
> > I'm curious about your comment on refactoring - what tool support do
> > you have for refactoring?
>
> Not sure if you mean automatic refactoring, which I hear the Java folks
> have gotten into. If so, none.
Yes, automatic refactoring.
Guess where the Java folks got that from ;-)
http://wiki.cs.uiuc.edu/RefactoringBrowser/History+of+the+Refactoring+Browser
http://www.refactory.com/RefactoringBrowser/Refactorings.html
> Otherwise, I happen to use a very nice
> IDE from Franz (part of AllegroCL on win32 and (I hear) Linux now). It
> lets me find things across a complex project and presents results in
> list boxes so I can have at it. One thing they do not have is "find
> callers", but MCLs IDE (also strongly graphical) had one, and I believe
> I have in the past hacked one for ACL because another "find" tool (their
> graphical APROPOS) happened to reveal on unexported function that would
> support that. There is an object browser, but I tend not to use it
> because the various "find" keychords get me there faster.
>
> Lisp also makes refactoring easier by its very nature, but that is a
> longer story.
>
> kt
>
>
> --
> 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
Ken Tilton <·········@gmail.com> writes:
> Not sure if you mean automatic refactoring, which I hear the Java
> folks have gotten into. If so, none. Otherwise, I happen to use a very
> nice IDE from Franz (part of AllegroCL on win32 and (I hear) Linux
> now). It lets me find things across a complex project and presents
> results in list boxes so I can have at it. One thing they do not have
> is "find callers", but MCLs IDE (also strongly graphical) had one, and
> I believe I have in the past hacked one for ACL because another "find"
> tool (their graphical APROPOS) happened to reveal on unexported
> function that would support that. There is an object browser, but I
> tend not to use it because the various "find" keychords get me there
> faster.
:who-calls provides already "find callers", right?
Benjamin
--
"Master your instrument, master the music, and then forget all that
bullshit and just play." -- Charlie Parker
From: Ken Tilton
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <frmMg.10951$W72.8643@newsfe10.lga>
Benjamin Tovar wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>Not sure if you mean automatic refactoring, which I hear the Java
>>folks have gotten into. If so, none. Otherwise, I happen to use a very
>>nice IDE from Franz (part of AllegroCL on win32 and (I hear) Linux
>>now). It lets me find things across a complex project and presents
>>results in list boxes so I can have at it. One thing they do not have
>>is "find callers", but MCLs IDE (also strongly graphical) had one, and
>>I believe I have in the past hacked one for ACL because another "find"
>>tool (their graphical APROPOS) happened to reveal on unexported
>>function that would support that. There is an object browser, but I
>>tend not to use it because the various "find" keychords get me there
>>faster.
>
>
> :who-calls provides already "find callers", right?
That's it, and my recollection was faulty, it is exported. I was
remembering that no GUI interface to the function was provided, which
struck me as odd. MCL had a who-calls dialog, and ACL has dialogs for
everything else.
Me, I just search on "(changed-func". :) And, yes, with Celtk it would
take about 30mins to make a "find callers" dialog. Hell, I could even
use CG. Anyway, thx for the reminder.
kt
--
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
From: Pascal Costanza
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <4me404F5ovuiU4@individual.net>
Isaac Gouy wrote:
> I'm curious about your comment on refactoring - what tool support do
> you have for refactoring?
S-expressions. You can get amazingly far by being able to select, copy
and paste them, either via keyboard shortcuts or via the mouse. And you
can work pretty fast this way.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Ken Tilton
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <gdlMg.10947$W72.8175@newsfe10.lga>
Pascal Costanza wrote:
> Isaac Gouy wrote:
>
>> I'm curious about your comment on refactoring - what tool support do
>> you have for refactoring?
>
>
> S-expressions. You can get amazingly far by being able to select, copy
> and paste them, either via keyboard shortcuts or via the mouse. And you
> can work pretty fast this way.
Oh, I wouldn't mind if AllegroCL automated some of the things I do
during refactoring, but some of them I could do myself and have not. And
one thing I have learned from bug reports to Franz is that other
developers do not work the way I do, or work on such big hairy projects,
so it may not be clear exactly what automation to add and how much it
would enhance ACL. Lisp certainly has the reflective capabilities need
for automated refactoring, never mind the fact that the vendor controls
the compiler as well as the IDE and can have the first support the second.
Why haven't I done it? I guess we would have to get specific about the
automated refactoring feature, but I have to wonder how much can be
automated since I have to revisit all affected code anyway to revise it
in light of the refactoring.
kt
--
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
Chris Uppal wrote:
> ············@gmail.com wrote:
>
> > It looks like right now, the best way forward is for SBLC to get the
> > windows port done, a 1.0 release, a modern, fast crossplatform gui, and
> > then someone(s) can start developing a modern, highly-interactive,
> > development environment for it.
>
> I don't want to knock the SBCL people, and I admit that I know very little
> about the whole thing, but still I doubt whether that will ever happen. The
> principle problem any such effort would face is the fact that it has started in
> the wrong place -- on Unix-like systems[*].
It's my understanding that the windows port is getting there. How fast
I don't know. I think they would have to realize the importance of a
windows port by now.
I don't see any reason in
> principle why the various cross-platform UI toolkits couldn't be used to create
> a /good/ environment, but I have never seen anything that even remotely came
> close to putting that idea into practice. (I speculate that one reason may be
> that many such toolkits -- or rather, the few which are capable of producing
> decent results -- have been produced by programmers with a very static
> mind-set.)
I had an idea of taking the native C libraries of SWT and working with
that. At least you have nice looking GUIs on Windows and Unix.
>
> That's in addition to the observation that many programmers have never /seen/ a
> decent interactive environment, and so have no idea what they are missing or
> could be building. (I may as well be explicit -- in addition to my early
> disclaimer -- that I have no idea whether this observation applies to the SBCL
> people.)
>
> And also there's my feeling that Lisp is just not as suitable a target for an
> interactive environment as a pure OO language like Smalltalk -- the issue being
> that there is nothing sensible to interact /with/ (so you end up with a
> tarted-up version of a read-eval-print loop). That problem would not occur if
> the environment committed itself fully to the OO approach to Lisp, and
> basically said "if you aren't using CLOS for everything then we don't give a
> damn about you" -- but I can't imagine that being very popular ;-) (And in
> any case, if you want that kind of environment, why not just use Smalltalk ?)
>
It seems that CLOS would be a natural fit for a development enviornment
(at least the presentation parts). Personally, I have nothing against
Smalltalk. In fact i have this thing called Vista Smalltalk that can
run in a browser up right now, but I'd rather have the full power of CL
along with the environments preferably.
> -- chris
>
> [*] I am very fond of Unix, btw, but GUI stuff on Unix is pretty uniformly
> terrible -- or if there are any counterexamples, then /I/ haven't seen 'em.
From: Ken Tilton
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <q9XLg.36$yD7.9@newsfe11.lga>
Chris Uppal wrote:
> ···········@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
Ken Tilton wrote:
> Chris Uppal wrote:
> > ···········@googlemail.com wrote:
> >>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.
This is a matter of perspective:
* Regarding summarization, some people regard this to be abstraction.
IMO sometimes it is and sometimes it isn't.
* Regarding optimization. This is a POV that comes from other langs
where people do things in strange ways. In some langs you have a
function say weird_interpreter that takes an arglist of any length, you
then call weird_interpreter(something, something_else, ...).
Weird_interpreter then performs the action of a macro. This is nasty,
Turbo Pascal GUIs used to do it. Some people who've seen this think of
macros as embedded DSL interpreters that are accelerated by being
compiled.
Ken Tilton wrote:
>
> Finally, the CL community is growing fast. Smalltalk?
"Fast?" Growing rather than shrinking, sure. But "fast?" What's the
evidence?
Cheers,
Brandon Van Every
Ken Tilton wrote:
> So the macro issue gets swept under the rug with "OO for ST, macros for
> Lisp"?
Up until that point I had imagined that your post was intended to contribute to
a sensible discussion of these options and issues. I see that I was wrong.
-- chris
From: Ken Tilton
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <aRYLg.16$W72.14@newsfe10.lga>
Chris Uppal wrote:
> Ken Tilton wrote:
>
>
>>So the macro issue gets swept under the rug with "OO for ST, macros for
>>Lisp"?
>
>
> Up until that point I had imagined that your post was intended to contribute to
> a sensible discussion of these options and issues. I see that I was wrong.
>
Funny, it was at the same point in your article that i was disappointed
to see the hand-waving in which ST's lack of macros got excused as "hey,
we use OO, they use macros". I appreciated the artfulness of that
dodge, but felt it needed exposing: all that feel-good,
different-strokes stuff distills to: "ST does not have macros".
the "abstraction" fig leaf will not stretch far enough to cover ST's
lack of macros. I happen to be a big a fan of OO as well as macros and
leverage OO all over the place, and OO simply does different things.
Let's look at some code:
(c? (bwhen (mp (mouse-pos .og.)) ;; mouse-pos is a function
(without-c-dependency
(find-ix-under self mp)))) ;; find-ix is a function
Inside out on the macrology:
(c? (bwhen (mp (mouse-pos .og.))
(let (cells::*call-stack*) ;; wo-c-d hid implementation
(find-ix-under self mp))))
Next we look at bwhen, which simply extends CL to include a frequent
pattern in my coding:
(c? (let ((mp (mouse-pos .og.))) ;; BWHEN condenses a bind-test pattern
(when mp
(let (cells::*call-stack*)
(find-ix-under self mp)))))
Oh, hang on, I just noticed .og. That expands to:
(or (clo::ogl-context self)
(setf (clo::ogl-context self) (upper self togl)))
OpenGL contexts are not around during window startup, and my frameworks
do an awful lot during startup (and I try to make coding easier by not
having to worry about order).
Upper? I love that one, use it all the time in GUI hierarchies:
(container-typed self 'togl)
Put it all together and:
(c? (let ((mp (mouse-pos (or (clo::ogl-context self)
(setf (clo::ogl-context self)
(container-typed self 'togl))))))
(when mp
(let (cells::*call-stack*)
(find-ix-under self mp)))))
C? That is the key macro in my Cells framework (see sig). That hides a
/lot/ of implementation boilerplate (two diff things worth hiding):
(cells::make-c-dependent
:value-state :unevaluated
:rule (lambda (cells::slot-c
&aux
(self (cells::c-model cells::slot-c))
(.cache (cells::c-value cells::slot-c)))
(declare (ignorable .cache self))
(let ((mp (mouse-pos .og.))) ;; .og. back in for brevity
(when mp (let (cells::*call-stack*)
(find-ix-under self mp))))))
Instead of:
(c? (bwhen (mp (mouse-pos .og.))
(without-c-dependency
(find-ix-under self mp))))
Since I write a ton of code using these macros, one can see the
advantages in writing, reading, and refactoring. And I subscribe to the
rule "no unecessary macros", so if this kind of thing could be done with
OO or functions or lambdas (blocks) it would have been.
Hope that is "sensible" enough for you. :)
ken
--
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
From: Pascal Costanza
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <4mblviF5fpv7U1@individual.net>
Ken Tilton wrote:
> OO-wise:
> -- Smalltalk does not allow multiple-inheritance.
A seemingly popular recent extensions for Smalltalk are Traits, which
are quite similar to CLOS-style multiple inheritance. If I understand
correctly, this is provided as an extension to some Smalltalk
implementations.
> -- Smalltalk does not support multi-methods.
Brian Foote has described a CLOS-style MOP for Smalltalk with which he
has implemented multi-methods in a neat way that at the same time
actually maintains the idea a method belongs to a class. (In CLOS, this
is actually also the case to a certain extent: There is a defined
argument precedence order for each generic function, and one could argue
that a method "belongs" to the class of the first argument according to
this order.)
> -- CLOS has before/after/around methods, and non-vanilla method
> combinations. Smalltalk?
If I remember correctly, also part of Brian Foote's extension. Described
in a ECOOP 2005 paper. I don't know whether his code is actually
available by now.
> 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.
...and it seems to me that this is the main trade-off. Whenever you
write a tool for Smalltalk, you exactly know all the language features
that you have to take care for, so your tools can actually be complete.
I think this is basically impossible to achieve with Lisp because only
the most trivial tools can deal with all the possible extensions that
may ever come up.
In a sense, the IDE tools play the role that macros play in the Lisp
world: Tools allow you to abstract away from implementation details and
inspect your programs at different levels, and according to different
criteria.
So, I think, this boils down to whether you prefer a more text-based
programming style or a more tool-based / visual programming style.
My reasons for preferring Common Lisp over Smalltalk are Common Lisp's
support for multi-paradigm programming and the fact I am not a visual
thinker but strongly prefer to work with text (or better: symbolic
representations), among others.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Ken Tilton
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <HG1Mg.124$344.111@newsfe12.lga>
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>> OO-wise:
>> -- Smalltalk does not allow multiple-inheritance.
>
>
> A seemingly popular recent extensions for Smalltalk are Traits, which
> are quite similar to CLOS-style multiple inheritance. If I understand
> correctly, this is provided as an extension to some Smalltalk
> implementations.
>
>> -- Smalltalk does not support multi-methods.
>
>
> Brian Foote has described a CLOS-style MOP for Smalltalk with which he
> has implemented multi-methods in a neat way that at the same time
> actually maintains the idea a method belongs to a class. (In CLOS, this
> is actually also the case to a certain extent: There is a defined
> argument precedence order for each generic function, and one could argue
> that a method "belongs" to the class of the first argument according to
> this order.)
>
>> -- CLOS has before/after/around methods, and non-vanilla method
>> combinations. Smalltalk?
>
>
> If I remember correctly, also part of Brian Foote's extension.
"Lisp the Inevitable"?
Forget programming languages, let's talk transportation: how did
McCarthy get here from whatever star system that was?
kt
--
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
From: Pascal Costanza
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <4mbl53F5f8hhU1@individual.net>
Chris Uppal wrote:
>> 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.
The characterization of macros for performance or for getting around
language restriction is definitely wrong. Macros give you syntactic
abstractions, and can be used to abstract over implementation details
that other abstraction facilities cannot abstract away.
A very simple example is a while-loop. With a functional abstraction,
you can basically express this as a higher-order function that accepts
two other functions:
(defun while/function (predicate body)
(when (funcall predicate)
(funcall body)
(while/function predicate body)))
You can call it like this:
(let ((i 0))
(while/function
(lambda () (< i 10))
(lambda ()
(incf i)
(print i))))
This prints all the numbers from 1 to 10.
In Smalltalk, iteration constructs are basically implemented in this
way, except that the block syntax makes lambda expression somewhat nicer
to write down. [1] Here is similar code as above in Smalltalk: [2]
x := 0.
[ (x < 10) ]
whileTrue: [x := x + 1.
Transcript show: (x) printString.
Transcript show: ' '.].
There is a problem with this code, though. The problem is that the
while/function definition leaks an implementation detail, which is the
requirement that client code explicitly uses blocks / lambda expression.
However, as a programmer of client code I am actually not interested in
that detail.
Abstractions are used to hide implementation details. This is especially
interesting when we may want to vary the implementation without changing
the interface. When we define while as a macro, we can do this. Here is
one implementation of the while macro:
(defmacro while (predicate &body body)
`(while/function
(lambda () ,predicate)
(lambda () ,@body)))
We can now express the above client code like this:
(let ((i 0))
(while (< i 10)
(incf i)
(print i)))
This definition of the while macro actually expands into a use of the
while/function - by the way, a pretty common approach in Lisp to
implement the functionality in terms of functions and only provide
macros as a thin syntactic layer on top.
However, we may realize at some stage that our while macro is actually a
hot spot in our program, and that it may make sense to provide a more
efficient implementation. We can do this with a revised macro definition:
(defmacro while (predicate &body body)
(let ((predicate-tag (gensym))
(body-tag (gensym))
(end-tag (gensym)))
`(tagbody
,predicate-tag
(if ,predicate (go ,body-tag) (go ,end-tag))
,body-tag ,@body
(go ,predicate-tag)
,end-tag)))
We have now expressed the while macro in terms of goto statements. This
would not be possible with plain functional abstractions, at least not
in a straightforward, convenient way. (And convenience is the only
reason for programming languages in the first place.)
In this context it is worthwhile to note that a Smalltalk compiler
internally recognizes its implementation-provided iteration constructs
and treats them specially such that the blocks are actually transformed
into "direct" code. However, the Smalltalk compiler doesn't provide an
interface with which you could easily do the same for your own extensions.
Note that, although in this example efficiency is used as a reason for
implementing the while macro differently, there are a lot of other
motivations why you would want to hide implementation details such as
whether lambdas are used internally or not. This example was just for
demonstration.
Pascal
[1] There are also other differences between blocks and lambda
expressions, but that's not relevant here.
[2] Stolen from some webpage - sorry, I am not a Smalltalker. ;)
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> The characterization of macros for performance or for getting around
> language restriction is definitely wrong.
> [...]
> A very simple example is a while-loop. With a functional abstraction,
> you can basically express this as a higher-order function that accepts
> two other functions:
Then why is it that Smalltalk's while loops[*] and other control structures
(including the many user-defined ones) are implemented without macros ?
(I did read the rest of your post, btw, so I know that you know about
Smalltalk's blocks)
Put it like this. If Lisp had (mabe it has, for all I know) a simple and clear
syntax for indicating deferred evaluation, then are there any cases where
macros are used that could not be replaced by an combination of ordinary
functional evaluation (possibly introspective), and the application of that
syntax ? If not, then the only reason for using them (in this hypothetical
near-lisp) would be to optimise runtime computation into compile-time
computation. My personal feeling is that such optimsation should be done by
the compiler (partial evaluation perhaps) not by the programmer.
> There is a problem with this code, though. The problem is that the
> while/function definition leaks an implementation detail, which is the
> requirement that client code explicitly uses blocks / lambda expression.
> However, as a programmer of client code I am actually not interested in
> that detail.
Now this I don't agree with. It is simply not the case that the time when code
is executed is an implementation detail. E.g. in the following code (in C for
neutrality ;-)
if (x == NULL)
kaBoom("!!!!");
it is vital for understanding the code that you can see that kaBoom() is not
executed except under certain circumstances. In C, with its fixed set of
control structures, there is no need for special syntax to communicate that
(either to the reader or the compiler); but in languages where
programmer-defined control structures are the rule rather than the exception, I
think that syntactic uniformity between always-evaluated expressions and
deferred evaluations is /not/ an advantage.
(BTW, and wandering off-topic, I have met C/C++/Java programmers who consider
the short-circuit evaluation rules of && and || to be a "detail" -- even to the
point of recommending that programmers don't rely on it ! They are, of
course, completely wrong ;-)
Anyway, that's why I say that Lisp's macros should be thought of as a fix for
what would otherwise be problems in the language. I'm not at all suggesting
that they aren't a /good/ fix, nor that they are not a very valuable feature of
Lisp. But I /am/ suggesting that for someone to denigrate another (any other)
language for lacking them would only be valid if that language had similar
"problems". All languages have their own toolkits for doing various kinds of
abstraction. When deciding which languages best suit you (or a given task) the
question to ask is not "what tools are available?" but "what kinds of
abstraction are available?". And then the next questions is whether the kinds
of abstraction are the ones that you want (or need) to use. I have no problem
at all with the idea that some people want to use abstractions which don't fit
into the Smalltalk way, and it is perfectly possible that the OP is one of
those people. But what I /do/ think is a mistake is to dismiss Smalltalk
without knowing what kinds of abstraction /it/ provides, let alone trying them
for long enough to know how well they fit with one's own way of thinking.
> In this context it is worthwhile to note that a Smalltalk compiler
> internally recognizes its implementation-provided iteration constructs
> and treats them specially such that the blocks are actually transformed
> into "direct" code.
Just for completeness, that isn't quite true. Most Smalltalk compilers do
recognise, and special-case, a small number of fixed control-flow messages
(#ifTrue:ifFalse: #whileTrue: and some others), but the bulk of uses of blocks
(e.g. iterating over a collection) do exactly what they look as if they are
doing.
-- chris
[*] Ironically, #while is the only control structure that /has/ to be expanded
by the Smalltalk compiler -- at least once -- unless it does at least some
tail-recursion elimination.
Chris Uppal <···········@metagnostic.REMOVE-THIS.org> wrote:
+---------------
| Put it like this. If Lisp had (mabe it has, for all I know)
| a simple and clear syntax for indicating deferred evaluation...
+---------------
You mean like these?
> (defmacro thunk (&body body) `(lambda () ,@body))
THUNK
> (defmacro fn (args &body body) `(lambda ,args ,@body))
FN
> (mapcar (fn (x y) (+ x y)) '(1 2 3 4) '(0 5 10 15))
(1 7 13 19)
>
Or if you *insist* on getting all "syntaxy":
> (mapcar #$(+ $1 $2) '(1 2 3 4) '(0 5 10 15))
(1 7 13 19)
>
[The definition of the "#$" readmacro is left to the reader, but
it's real (and really, *really* ugly!), and I do use it in the REPL
once in a while, through *NEVER* in finished code! (Guess why?)]
+---------------
| ...then are there any cases where macros are used that could not
| be replaced by an combination of ordinary functional evaluation
| (possibly introspective), and the application of that syntax?
+---------------
You're missing the distinction between "could be replaced" and
"would be *desirable* to be replaced". Many, many uses of macros
are simply because they make the code *look* better and/or be more
*readable* [and thus more maintainable in the long term], and in
the Common Lisp community this is valued more than any sort of
"functional purity".
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Robert Uhl
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <m3d5a6a4zi.fsf@NOSPAMgmail.com>
"Chris Uppal" <···········@metagnostic.REMOVE-THIS.org> writes:
>
> Put it like this. If Lisp had (mabe it has, for all I know) a simple
> and clear syntax for indicating deferred evaluation, then are there
> any cases where macros are used that could not be replaced by an
> combination of ordinary functional evaluation (possibly
> introspective), and the application of that syntax ?
I think any of the cases where macros are used for syntactic abstraction
would apply. Macros are often used to add completely new syntax.
E.g. see <http://www.gigamonkeys.com/book/practical-an-id3-parser.html>
where the author uses macros to create an extremely readable ID3 tag
parser. I'll caution that the example is very complex, and possibly
makes the most sense after reading the earlier chapters.
As an example, I use macros to create CLSQL view classes (which
themselves create ordinary CLOS classes and perform some internal
bookkeeping) and then create a whole slew of functions based on the
columns in a table (e.g. with-SLOT and TABLE-SLOT functions to use in a
web templating language).
--
Robert Uhl <http://public.xdi.org/=ruhl>
A lot of plants have taken a rather seriously defencive stance against
being eaten. --Bruce Johnson
From: Pascal Costanza
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <4me3eqF5ovuiU1@individual.net>
Chris Uppal wrote:
> Pascal Costanza wrote:
>
>> The characterization of macros for performance or for getting around
>> language restriction is definitely wrong.
>> [...]
>> A very simple example is a while-loop. With a functional abstraction,
>> you can basically express this as a higher-order function that accepts
>> two other functions:
>
> Then why is it that Smalltalk's while loops[*] and other control structures
> (including the many user-defined ones) are implemented without macros ?
>
> (I did read the rest of your post, btw, so I know that you know about
> Smalltalk's blocks)
I didn't say that macros are required to implement control structures. I
said that macros are required to abstract over certain implementation
details of such control structures.
> Put it like this. If Lisp had (mabe it has, for all I know) a simple and clear
> syntax for indicating deferred evaluation, then are there any cases where
> macros are used that could not be replaced by an combination of ordinary
> functional evaluation (possibly introspective), and the application of that
> syntax ?
In the book "On Lisp", Paul Graham lists the following uses for macros:
+ Implicit quoting. For example, creating a function definition could be
accomplished with a function, roughly like this:
(define-function 'display (lambda (object) ...))
The need to use a quote in front of 'display instead of just leaving it
out is inconvenient. (And there are more interesting cases for this.)
+ Cosmetics. The idea here is that sometimes, a macro can just help to
make the code look nicer. This is especially interesting for embedding
domain-specific languages where it may make sense to tweak the syntax
such that it gets closer to known notations from the problem domain.
+ Controlling evaluation. This is basically the example we have already
discussed.
+ Side effects. It's not possible to express side effects in terms of
functions. So for example, functionality like pushing and popping
elements to/from a list that's stored in a variable can only be
expressed as a macro. In Smalltalk, this is not evident because there
you get an implicit indirection by storing such data inside objects, but
it wouldn't be possible to express more "direct" manipulations in terms
of blocks either. (Maybe you don't care, but this doesn't invalidate
this observation.)
+ Efficiency. However, this is actually one of the worst reasons to use
a macro. If you express something as a macro that could as well be
expressed as a function, it's better to indeed express it as a function.
Otherwise, you lose the ability to pass it around as a first-class
value. Macros are not available as first-class entities at runtime in
this sense.
The two better means to achieve better efficiency are:
- Declaring that a function may be inlined. This is a standard
declaration in Common Lisp, so you can just say something like (declaim
(inline foo)).
- Providing a compiler macro. This allows you to define a function as
before, but additionally give hints to the compiler how it can be
translated differently when it is directly called. With compiler macros,
you can also perform ad-hoc partial evaluation, and other nifty things.
Especially because of compiler macros, one can safely claim that macros
should actually _never_ be used for efficiency.
There are probably other uses for macros, but these are the most
important. In general, "syntactic abstractions" is a good umbrella term
for these uses.
> If not, then the only reason for using them (in this hypothetical
> near-lisp) would be to optimise runtime computation into compile-time
> computation. My personal feeling is that such optimsation should be done by
> the compiler (partial evaluation perhaps) not by the programmer.
Compilers and virtual machines can only perform optimizations up to a
certain extent. For example, they can indeed detect typical usage
patterns and generate specific code for such cases. Virtual machines
have actually very far in this regard (and Strongtalk is a pretty
impressive example here). However, for more domain-specific or less
typical uses of a language, it is probably better to also provide ad hoc
hints to a compiler / runtime system.
>> There is a problem with this code, though. The problem is that the
>> while/function definition leaks an implementation detail, which is the
>> requirement that client code explicitly uses blocks / lambda expression.
>> However, as a programmer of client code I am actually not interested in
>> that detail.
>
> Now this I don't agree with. It is simply not the case that the time when code
> is executed is an implementation detail. E.g. in the following code (in C for
> neutrality ;-)
>
> if (x == NULL)
> kaBoom("!!!!");
>
> it is vital for understanding the code that you can see that kaBoom() is not
> executed except under certain circumstances. In C, with its fixed set of
> control structures, there is no need for special syntax to communicate that
> (either to the reader or the compiler); but in languages where
> programmer-defined control structures are the rule rather than the exception, I
> think that syntactic uniformity between always-evaluated expressions and
> deferred evaluations is /not/ an advantage.
Well, let's just agree that we disagree here. ;)
> (BTW, and wandering off-topic, I have met C/C++/Java programmers who consider
> the short-circuit evaluation rules of && and || to be a "detail" -- even to the
> point of recommending that programmers don't rely on it ! They are, of
> course, completely wrong ;-)
Ahh, it's good to know that we Lispers and Smalltalkers can always agree
when it comes to Java-bashing. ;-)
> Anyway, that's why I say that Lisp's macros should be thought of as a fix for
> what would otherwise be problems in the language. I'm not at all suggesting
> that they aren't a /good/ fix, nor that they are not a very valuable feature of
> Lisp. But I /am/ suggesting that for someone to denigrate another (any other)
> language for lacking them would only be valid if that language had similar
> "problems". All languages have their own toolkits for doing various kinds of
> abstraction. When deciding which languages best suit you (or a given task) the
> question to ask is not "what tools are available?" but "what kinds of
> abstraction are available?". And then the next questions is whether the kinds
> of abstraction are the ones that you want (or need) to use. I have no problem
> at all with the idea that some people want to use abstractions which don't fit
> into the Smalltalk way, and it is perfectly possible that the OP is one of
> those people. But what I /do/ think is a mistake is to dismiss Smalltalk
> without knowing what kinds of abstraction /it/ provides, let alone trying them
> for long enough to know how well they fit with one's own way of thinking.
I am not dismissing Smalltalk because it lacks macros. I have other
reasons for preferring Lisp over Smalltalk. I actually think there are
features in Smalltalk that work better than in Lisp, but they weigh less
in my personal opinion than the advantages that Lisp has. (Especially, I
think the image-based development model works better in Smalltalk.)
>> In this context it is worthwhile to note that a Smalltalk compiler
>> internally recognizes its implementation-provided iteration constructs
>> and treats them specially such that the blocks are actually transformed
>> into "direct" code.
>
> Just for completeness, that isn't quite true. Most Smalltalk compilers do
> recognise, and special-case, a small number of fixed control-flow messages
> (#ifTrue:ifFalse: #whileTrue: and some others), but the bulk of uses of blocks
> (e.g. iterating over a collection) do exactly what they look as if they are
> doing.
Hm, maybe my wording wasn't clear enough, but I actually meant exactly
these special cases.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
"Chris Uppal" <···········@metagnostic.REMOVE-THIS.org> writes:
> Pascal Costanza wrote:
>
>> The characterization of macros for performance or for getting around
>> language restriction is definitely wrong.
>> [...]
>> A very simple example is a while-loop. With a functional abstraction,
>> you can basically express this as a higher-order function that accepts
>> two other functions:
>
> Then why is it that Smalltalk's while loops[*] and other control structures
> (including the many user-defined ones) are implemented without macros ?
>
> (I did read the rest of your post, btw, so I know that you know about
> Smalltalk's blocks)
>
> Put it like this. If Lisp had (mabe it has, for all I know) a simple and clear
> syntax for indicating deferred evaluation, then are there any cases where
> macros are used that could not be replaced by an combination of ordinary
> functional evaluation (possibly introspective), and the application of that
> syntax ? If not, then the only reason for using them (in this hypothetical
> near-lisp) would be to optimise runtime computation into compile-time
> computation. My personal feeling is that such optimsation should be done by
> the compiler (partial evaluation perhaps) not by the programmer.
That's the point.
In Smalltalk, there's no read-time, compile-time or run-time notation.
You only have run-time. The control structures are not implemented as
macros or special operators, but you need special support by the
compiler to compile them. (Or you can just rely on only the message
passing mechanism). When you write:
[ a < b ] whileTrue: [ a := a + 1 ]
you only have run-time objects, message objects with block objects and
other objects.
You need to have compiler magic, a compiler know what whileTrue:
means, to compile it efficiently.
The compiler couldn't do much if you had:
Object subclass #Example
instanceVariableName: 'state'
classVariableName: ''
poolDictionaries: ''
category: nil
!
Example methodsFor: 'running'!
whileTrue: block
"Runs block while the Example is in the right state."
[ self state = #right ] whileTrue: block .
^self
! !
Object methodsFor: 'someFun'!
someFun:arg
"Dear compiler, have fun with this."
| whatAmI |
arg ifTrue: [ whatAmI := Example new ]
ifFalse: [ whatAmI := [ Object getSomeBoolean ] ].
arg whileTrue: [ Transcript show: 'still true' ].
^self
!
Here, the compiler cannot optimize out whileTrue: anymore, since it
doesn't know whether arg is a block or if it's an Example instance.
Of course, it could still opencode the two cases, but you can easily
come with a more complex situation. The compiler _could_,
theorically, analyze the source of the Example whileTrue:, but this is
not really possible because of the dynamic aspect of Smalltalk (you
could create subclasses at run-time, etc).
Now with macros, and compiler macros, what we have is actually HOOKS
into the compiler, that allow the programmer to modify the compiler
and implement the wanted optimizations or new control constructs.
We don't want deferred evaluation. If we needed a nice syntax to have
deferred evaluation, it is simplistic to do it, as has been
demonstrated several times in this newsgroup. What we want, is to
improve the compiler in a controled way.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.
From: ····@nospam.com
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <ifKRg.353$8U2.194@trndny08>
Chris Uppal wrote:
> Anyway, that's why I say that Lisp's macros should be thought of as a fix for
> what would otherwise be problems in the language.
I think it might be worthwhile to ask
"How could macros help Smalltalk?"
"How would macros look in Smalltalk?"
Does Smalltalk need macros? I don't know at this point.
Seeing a concrete example of Smalltalk code that suffers
from the lack of a macro-facility would be helpful indeed
for this discussion.
My basic premise - I think yours too - is that "Just
because you need macros in Lisp, doesn't necessarily
mean you need them in Smalltalk".
Thanks
-Panu Viljamaa
From: Friedrich Dominicus
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <878xkw2cqe.fsf@flarge.here>
···········@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.
···········@googlemail.com wrote:
>
...
> 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.
Why not use the lisp classes in Jun?
It would be beautiful if Lisp could access Smalltalk objects. That is
what I was hoping the Jun LISP thing would be capable of. I was
dreaming of an integrated Lisp/Smalltalk environment that just wasn't there.
cor wrote:
> ···········@googlemail.com wrote:
>
> ...
>
>> 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.
>>
>
> Why not use the lisp classes in Jun?
>
···········@googlemail.com wrote:
>
> 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.
I resisted Emacs for a long time. I finally caved in because the
SchemeWay plugin for Eclipse never worked for me. I went for XEmacs
and installed CUA mode on it, which gives me the usual Windows
cut-copy-paste-undo keys without any hassles. The hassle of course is
learning how to set up CUA mode and other XEmacs configurations.
XEmacs works just fine for editing CMake script files. So would
Notepad; so far I really just use XEmacs as a glorified text editor.
The only other XEmacs functionality I'm currently making heavy use of
is grep. It is not entirely convenient, as I have to type what I want
to grep instead of just clicking on a word and having it automagically
cut-n-paste. I've done very little Scheme programming, only enough to
get Chicken Scheme to build. XEmacs will balance parentheses even in
Fundamental mode, so that's been useful. I couldn't tell you how to
reindent code or run a Scheme shell, I haven't bothered. I downloaded
something called Quack and I have no idea what it does for me; I
suspect nothing.
I use Darcs for source control, and I've become comfortable using it on
the command line. So I don't presently feel a need for source control
integration. Ditto CMake and make. I have wanted a Scheme function
browser, so I started going up the ETAGS learning curve. Didn't
complete it though.
> 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.
Corman Lisp is only $250, and you can use it non-commercially for free
to try it out.
> Smalltalk code seems to look a lot better to the eye than Lisp - very
> personal opinion of course.
I don't have much sense of what problem domains Smalltalk is relevant
to. It always seemed like "GUI stuff" or something. Never seemed like
performance or 3D graphics stuff, which is what I'm into. So I've not
investigated Smalltalk at all. There's a guy named Brian Rice in
SeaFunc who is developing a language called Slate.
http://slate.tunes.org/ He is strongly influenced by both Smalltalk
and Lisp. Depending on what you're trying to do, you might want to
look at this. I do know that "make it usable" is big on his list of
priorities. It just seems to be chasing problem domains that I don't
care about, so I haven't put it through its paces.
Cheers,
Brandon Van Every
Mallor wrote:
> The only other XEmacs functionality I'm currently making heavy use of
> is grep. It is not entirely convenient, as I have to type what I want
> to grep instead of just clicking on a word and having it automagically
> cut-n-paste.
Read the documentation for the grep function (C-h f grep RET), and you
will see (at least in GNU Emacs)
A prefix argument says to default the argument based upon the current
tag the cursor is over, substituting it into the last grep command
in the grep command history (or into `grep-command'
if that history list is empty).
That means you put the point on top of the word you want, type C-u M-x
grep, and said word appears in the minibuffer.
In general, most things you want are included in Emacs somewhere, and
if not they're on the web somewhere (like at emacswiki.org), and if
not, they can be coded in Emacs Lisp. That's why this ancient dinosaur
still walks the Earth.
"Mallor" <···········@gmail.com> writes:
> the command line. So I don't presently feel a need for source control
> integration. Ditto CMake and make. I have wanted a Scheme function
> browser, so I started going up the ETAGS learning curve. Didn't
> complete it though.
Which learning curve is this?
M-! etags *.scm RET
M-. function-name RET
"Mallor" <···········@gmail.com> writes:
> ···········@googlemail.com wrote:
>>
>> 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.
>
> I resisted Emacs for a long time. I finally caved in because the
> SchemeWay plugin for Eclipse never worked for me. I went for XEmacs
> and installed CUA mode on it, which gives me the usual Windows
> cut-copy-paste-undo keys without any hassles. The hassle of course is
> learning how to set up CUA mode and other XEmacs configurations.
> XEmacs works just fine for editing CMake script files. So would
> Notepad; so far I really just use XEmacs as a glorified text editor.
> The only other XEmacs functionality I'm currently making heavy use of
> is grep. It is not entirely convenient, as I have to type what I want
> to grep instead of just clicking on a word and having it automagically
> cut-n-paste.
Very easy to solve.
(defun grep-here (start end)
(interactive "r")
(grep (format "grep %s *"
(shell-quote-argument (buffer-substring start end)))))
(global-set-key (kbd "<f8>") 'grep-here)
>> Smalltalk code seems to look a lot better to the eye than Lisp - very
>> personal opinion of course.
>
> I don't have much sense of what problem domains Smalltalk is relevant
> to. It always seemed like "GUI stuff" or something. Never seemed like
> performance or 3D graphics stuff, which is what I'm into. So I've not
> investigated Smalltalk at all.
Some banks and insurance companies regularly post Smalltalk jobs...
AFAICS, there are about the same number of Smalltalk jobs than Lisp jobs.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
From: Robert Uhl
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <m3hczji2v9.fsf@NOSPAMgmail.com>
Pascal Bourguignon <···@informatimago.com> writes:
>
>> The only other XEmacs functionality I'm currently making heavy use of
>> is grep. It is not entirely convenient, as I have to type what I
>> want to grep instead of just clicking on a word and having it
>> automagically cut-n-paste.
>
> Very easy to solve.
>
> (defun grep-here (start end)
> (interactive "r")
> (grep (format "grep %s *"
> (shell-quote-argument (buffer-substring start end)))))
>
> (global-set-key (kbd "<f8>") 'grep-here)
And assuming that he doesn't already use that mouse button, he could
bind it to the third mouse button with:
(global-set-key [mouse-3] 'grep-here)
Although in that case he'd want to play around a bit more with the
function--but the basics are all there to go forward with.
--
Robert Uhl <http://public.xdi.org/=ruhl>
"The only meaningful numbers in computer science are zero, one, and
infinity." "Though you can often get significant performance
improvements by treating 2 as a special case of 1 rather than a special
case of infinity." --Russ Allbery and Peter da Silva
Greetings,
Pascal Bourguignon wrote:
> "Mallor" <···········@gmail.com> writes:
>>I don't have much sense of what problem domains Smalltalk is relevant
>>to. It always seemed like "GUI stuff" or something. Never seemed like
>>performance or 3D graphics stuff, which is what I'm into. So I've not
>>investigated Smalltalk at all.
>
> Some banks and insurance companies regularly post Smalltalk jobs...
> AFAICS, there are about the same number of Smalltalk jobs than Lisp jobs.
I don�t know the data on the Lisp side, but I keep track of Smalltalk Jobs with
Dabble db:
http://www.cincomsmalltalk.com/userblogs/jsavidge/blogView?searchCategory=Employment
I�d actually like to know how the two job markets compare. :-)
James T. Savidge, Friday, September 8, 2006
"James T. Savidge" <························@get_a_new_job_texas.net> writes:
> Pascal Bourguignon wrote:
>> AFAICS, there are about the same number of Smalltalk jobs than Lisp jobs.
>
> I don’t know the data on the Lisp side, but I keep track of Smalltalk
> Jobs with Dabble db:
>
> http://www.cincomsmalltalk.com/userblogs/jsavidge/blogView?searchCategory=Employment
>
> I’d actually like to know how the two job markets compare. :-)
http://www.googlefight.com/index.php?lang=en_GB&word1=lisp+job&word2=smalltalk+job
for what it's worth...
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
···········@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.
>
> 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.
Yes, in Smalltalk can do bottom up development too.
> 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.
Well, by default there are no equivalent to Lisp macros in Smalltalk.
But you have closures and anonymous functions. They're called blocks.
For example, this method on Integer:
hotpo
"Will this method always terminate?"
| |
self = 1 ifTrue: [ ^ 'Reached 1.' ].
self isOdd
ifTrue: [^ (1 + (self * 3)) hotpo]
ifFalse: [^ (/ x 2) ].
is equivalent to:
(defmethod hotpo ((self integer))
(if-true (= self 1) (lambda () (return-from hotpo "Reached 1.")))
(if-true/if-false (oddp self)
(lambda () (return-from hotpo (hotpo (+ 1 (* self 3)))))
(lambda () (return-from hotpo (hotpo (/ self 2))))))
With:
(defun if-true (condition block-if-true)
(if condition
(funcall block-if-true)))
(defun if-true/if-false (condition block-if-true block-if-false)
(if condition
(funcall block-if-true)
(funcall block-if-false)))
So, if you want to add a new control construct, you can do it without
macros, just implementing some method that takes as argument some
blocks, just like we could do it in lisp with functions and lambda.
The difference, is that the syntax of Smalltalk allows you to do it
seamlessly, while in Lisp we have these "ugly" (LAMBDA () ...).
Now, there's a difference, it's that Smalltalk messages are sent at
run-time only. Methods like ifTrue: or ifTrue:ifFalse: on booleans
are optimized by the Smalltalk compilers, but they couldn't optimize
your own such methods.
If you want to use a macro just to generate some code, at compilation
time, the only thing you can do is to write a method that generates
the source (a string) for the new method, and have it compiled and
added to the target class.
> 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.
Have a look at Squeak. http://www.squeak.org/
It's a complete image based Smalltalk environment, with multimedia GUI.
One interesting application written in Squeak is:
http://www.opencroquet.org/
> 4. Execution speed - Lisp can be very optimised - how does Smalltalk
> compare here?
It's the same as with any programming language, there are
interpreters, compilers to a virtual machine implemented in software,
and compilers to a virtual machines implemented in hardware.
If the system is fast enough to run a 3D real-time virtual environment,
I don't think you should worry about speed...
(Squeak contains a compiler to a virtual machine implemented in
software, with a FFI to optimized C routines or libraries, just like
clisp).
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
From: Pascal Costanza
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <4mbje0F5f8d0U1@individual.net>
···········@googlemail.com wrote:
> 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.
Smalltalk requires you to define at least a class before you can do
anything else. So you have to do more upfront work than strictly
necessary. However, the typical Smalltalk development environment makes
this very convenient, so it's not a real issue as far as I can tell.
> 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.
This depends on your definition of "easy", but Lisp is certainly more
powerful in this regard.
> 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.
I cannot judge this in comparison.
> 4. Execution speed - Lisp can be very optimised - how does Smalltalk
> compare here?
If I understand correctly, all Smalltalk implementations are based on
bytecode-based virtual machines, and are not as heavily optimized as
such architectures can be. Compared to this, Common Lisp implementations
typically compile directly to machine code, and some of them are heavily
optimized. The ANSI Common Lisp specification also gives you detailed
means to influence the compilation and even provide ad-hoc means to
improve the quality of the generated code without penalizing its
readability. So I am pretty sure that Common Lisp fares better in this
regard than Smalltalk.
However, execution speed is not necessarily your most important concern.
Typical programs spend 80% of the time in 20% of the code (or so), so
overall execution speed is far less important than most people seem to
believe.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: HL
Subject: Re: Yet another Smalltalk or Lisp discussion (Windows Centric)
Date:
Message-ID: <86d59w7ljf.fsf@agora.my.domain>
···········@googlemail.com writes:
Hi --
Keep in mind also the price tag. For instance, I believe Dolphin
Smalltalk sells for under $500.00, IIRC and is considered to be an
excellent choice.
You have put yourself in a place between a rock and a hard place,
because you've said you wanted to develop on Windows and then port to
Linux. That seriously limits your cheap Smalltalk choices, I
think.
regs,
HL
···········@googlemail.com wrote:
> 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?
It sounds like you're not quite sure what you want to do and just want
to learn a language that enables you over the long term to do whatever
you want. No worries, I too have this need. I'd suggest the following
1. Download cygwin and don't care much for windows
2. In addition to lisp and smalltalk, also consider tcl and forth;
those requirements you mentioned above are met by those two as well. In
fact, if you really, really want to see bottom-up programming at its
finest, then you ought to look into forth.