·······@runbox.com wrote:
> Emacs scares me (there, I said it!) Smalltalk seems to have the more
> productive environment...but Lisp seems to have more open-source code
> available.
[Caution: advocacy ahead]
Taking this as a point to enter this thread (but I'm replying as much to the
other posts as this one).
The editor question is an illustration of one of the differences between the
"Smalltalk way" and the "Lisp way" (at least as I understand them).
Specifically, of the role of the IDE in the whole programming experience.
As far as I can tell from these threads (and others in the past) Emacs is about
as good as it gets for Lisp development. A complex, powerful, flexible
editor that appears to provide a feature set that is well tuned for
editing/developing in lisp. I've tried out a couple of Lisp IDEs, but as far
as I can see, they are little more than editors with an interactive loop built
in. I.e. it seems that /at best/ you can do with them what you would in Emacs.
I hated them. (And not because I'm an Emacs addict, either ;-)
In contrast, as a Smalltalk programmer, I've been using Dolphin Smalltalk for
5-6 years. The editor built into that IDE is about on a par with Window's
Notepad for functionality (in fact it's just the Windows rich text edit
control). In all that time I have only /occasionally/ missed being able to use
my preferred editor (vi, actually), and (IIRC) only twice bothered to dump out
the code to a file in order to make some complex changes. I've also only spent
no more than an hour to two adding a little extra power to the editor.
And that's the difference I started talking about. I simply /have no need/ for
a powerful, flexible, editor for Smalltalk. If anything it would get in the
way.
I think the reasons for that illustrate what's different about Smalltalk, and
its hard-line OO, that are /not/ different about Lisp (which, in this respect,
is Just Another Programming Language(tm)). It also illustrates the different
approaches to abstraction in the two programming languages -- and why
abstraction in Smalltalk doesn't /feel/ like abstraction.
A good Smalltalk IDE is /not/ primarily a tool for reading/editing/debugging
code; it is a place where you interact with your objects. You talk to them,
quite literally (except that the "talking" is done by typing one form of
"structured English" -- specifically, Smalltalk -- into a workspace). It's
that aliveness of the objects that makes programming in Smalltalk different to
any other language I've ever seen or heard of (I'm considering SELF to be part
of the extended ST family here).
I'm interested in my objects, and in their behaviour. The code is merely an
implementation artefact. I'm not wildly interested in it, and I'm certainly
not interested in fancy editors for it.
If I need a higher level of abstraction, then I build more objects. Object
that I can, /and do/ talk to. "There's nothing so concrete as a good
abstraction", is nowhere so true as in a Smalltalk IDE.
Contrast that with what I understand is a ("the" ?) classical Lisp approach to
abstraction: extending the language to match the problem domain. An effective
and worthwhile approach, granted; but messing around at the linguistic level
(and /macros/ -- pah!), sitting typing dead code into a morgue of an IDE, when
you could be working with live objects ?!? Thanks, but not for me...
-- chris
Chris Uppal wrote:
> ·······@runbox.com wrote:
>
> > Emacs scares me (there, I said it!) Smalltalk seems to have the
more
> > productive environment...but Lisp seems to have more open-source
code
> > available.
>
> [Caution: advocacy ahead]
>
> Taking this as a point to enter this thread (but I'm replying as much
to the
> other posts as this one).
>
> The editor question is an illustration of one of the differences
between the
> "Smalltalk way" and the "Lisp way" (at least as I understand them).
> Specifically, of the role of the IDE in the whole programming
experience.
>
> As far as I can tell from these threads (and others in the past)
Emacs is about
> as good as it gets for Lisp development. A complex, powerful,
flexible
> editor that appears to provide a feature set that is well tuned for
> editing/developing in lisp. I've tried out a couple of Lisp IDEs,
but as far
> as I can see, they are little more than editors with an interactive
loop built
> in. I.e. it seems that /at best/ you can do with them what you would
in Emacs.
>
> I hated them. (And not because I'm an Emacs addict, either ;-)
>
> In contrast, as a Smalltalk programmer, I've been using Dolphin
Smalltalk for
> 5-6 years. The editor built into that IDE is about on a par with
Window's
> Notepad for functionality (in fact it's just the Windows rich text
edit
> control). In all that time I have only /occasionally/ missed being
able to use
> my preferred editor (vi, actually), and (IIRC) only twice bothered to
dump out
> the code to a file in order to make some complex changes. I've also
only spent
> no more than an hour to two adding a little extra power to the
editor.
>
> And that's the difference I started talking about. I simply /have no
need/ for
> a powerful, flexible, editor for Smalltalk. If anything it would get
in the
> way.
>
> I think the reasons for that illustrate what's different about
Smalltalk, and
> its hard-line OO, that are /not/ different about Lisp (which, in this
respect,
> is Just Another Programming Language(tm)). It also illustrates the
different
> approaches to abstraction in the two programming languages -- and why
> abstraction in Smalltalk doesn't /feel/ like abstraction.
>
> A good Smalltalk IDE is /not/ primarily a tool for
reading/editing/debugging
> code; it is a place where you interact with your objects. You talk
to them,
> quite literally (except that the "talking" is done by typing one form
of
> "structured English" -- specifically, Smalltalk -- into a workspace).
It's
> that aliveness of the objects that makes programming in Smalltalk
different to
> any other language I've ever seen or heard of (I'm considering SELF
to be part
> of the extended ST family here).
>
> I'm interested in my objects, and in their behaviour. The code is
merely an
> implementation artefact. I'm not wildly interested in it, and I'm
certainly
> not interested in fancy editors for it.
>
> If I need a higher level of abstraction, then I build more objects.
Object
> that I can, /and do/ talk to. "There's nothing so concrete as a good
> abstraction", is nowhere so true as in a Smalltalk IDE.
>
> Contrast that with what I understand is a ("the" ?) classical Lisp
approach to
> abstraction: extending the language to match the problem domain. An
effective
> and worthwhile approach, granted; but messing around at the
linguistic level
> (and /macros/ -- pah!), sitting typing dead code into a morgue of an
IDE, when
> you could be working with live objects ?!? Thanks, but not for me...
In Lisp you can work with live objects and live code. In fact whole
operating
systems written in Lisp have been built around the idea of live
objects.
For example this http://lispm.dyndns.org/genera-concepts/genera.html
describes
the philosophy behind the Genera operating system from Symbolics. Its
presentation-based user interface is very dynamic -
where you interact with the objects through their presentations. Behind
everything you see on the screen you have objects and you can interact
with them (via commands, gestures, menus, ...). A directory listing
lists file and directory objects and the listing itself is an object
- and you can change aspects of these objects later,
or use some of these these objects in commands, etc.
In 'lesser' development environments like LispWorks, still you have
objects and you manipulate them (for example via the listener). This
is typical development style - that you work on a running application
and not on dead code. This is really similar to Smalltalk. Earlier
Lisp systems (InterLisp) had also a very similar code organization
like popular Smalltalk systems. Nowadays code is written in files
grouped to systems. But some of that code might only exist to
allow you as a developer to manipulate your objects during
development/runtime. Once you have started your application, you can
as a developer interact with your objects. Like you find the code for
the class of the object, change the class and Lisp will lazily update
the live object according to your new class definition. If you
are unsatisfied with a method, delete it and write another one - while
you have your live object for testing. If you need another object,
you create it. If you want to set this object in relationship with
some other you will do that directly - without working on dead code,
compiling dead code and restarting you application. In Lisp, as in
Smalltalk,
you talk to the objects directly. It's just not ship move: 20 (is that
Smalltak? ;-) ) but (move ship 20) . Conceptionally it is quite the
same.
The domain specific language comes into play when you have a special
extension
to Lisp for example to describe ships: (defship ship :capacity 100
:position (10 20)), organize fleets (deffleet armada (ship ship2
ship4)) and then
you can move your fleet by (move armada 100), have defined a planning
language
how to move fleets from one place to another etc. (logistics is a
domain, where Lisp is still popular)
.
On Mon, 24 Jan 2005 11:05:59 -0000, "Chris Uppal" <···········@metagnostic.REMOVE-THIS.org> wrote:
> As far as I can tell from these threads (and others in the past)
> Emacs is about as good as it gets for Lisp development. A complex,
> powerful, flexible editor that appears to provide a feature set that
> is well tuned for editing/developing in lisp. I've tried out a
> couple of Lisp IDEs, but as far as I can see, they are little more
> than editors with an interactive loop built in.
You obviously didn't look very closely. The LispWorks IDE or SLIME
(to name just two) offer a /lot/ more than just "an interactive loop."
Edi.
"Chris Uppal" <···········@metagnostic.REMOVE-THIS.org> writes:
> As far as I can tell from these threads (and others in the past) Emacs is about
> as good as it gets for Lisp development. A complex, powerful, flexible
> editor that appears to provide a feature set that is well tuned for
> editing/developing in lisp. I've tried out a couple of Lisp IDEs, but as far
> as I can see, they are little more than editors with an interactive loop built
> in. I.e. it seems that /at best/ you can do with them what you would in Emacs.
See this for how good CL environments can get:
http://lemonodor.com/archives/000103.html
> And that's the difference I started talking about. I simply /have no need/ for
> a powerful, flexible, editor for Smalltalk. If anything it would get in the
> way.
Uh... With Emacs it's so much easier to handle code. Wouldn't miss it
for a day. I seriously cannot code CL in say notepad.
Have you ever tried the advanced features that Emacs (or any other
"real" text editor) gives you?
> I think the reasons for that illustrate what's different about Smalltalk, and
> its hard-line OO, that are /not/ different about Lisp (which, in this respect,
> is Just Another Programming Language(tm)). It also illustrates the different
> approaches to abstraction in the two programming languages -- and why
> abstraction in Smalltalk doesn't /feel/ like abstraction.
If I write
(iterate
(generate i from 0 to 6)
(for (key . value) in '((a . 2) (zero . 10) (one . 20) (d . 5)))
(when (>= value 10)
(collect (cons key (next i)))))
does it feel like an abstraction? (Example taken from cliki.net) Would
you notice that iterate is not a part of the language?
> A good Smalltalk IDE is /not/ primarily a tool for reading/editing/debugging
> code; it is a place where you interact with your objects. You talk to them,
> quite literally (except that the "talking" is done by typing one form of
> "structured English" -- specifically, Smalltalk -- into a workspace). It's
> that aliveness of the objects that makes programming in Smalltalk different to
> any other language I've ever seen or heard of (I'm considering SELF to be part
> of the extended ST family here).
Please watch the lisp machine videos. :)
http://lispm.dyndns.org/
"Using a Symbolics Lisp Machine"
> Contrast that with what I understand is a ("the" ?) classical Lisp approach to
> abstraction: extending the language to match the problem domain. An effective
> and worthwhile approach, granted; but messing around at the linguistic level
> (and /macros/ -- pah!), sitting typing dead code into a morgue of an IDE, when
> you could be working with live objects ?!? Thanks, but not for me...
I think you are seriously confused...
Regards,
--
____________________________
Julian Stecklina / _________________________/
________________/ /
\_________________/ LISP - truly beautiful