Hello.
I'd like to start learning Lisp. So, I got a few books and found some
really interesting resources on the web... But I still miss one thing:
besides learning Lisp (the language itself), is there some place where I
can also learn something like "good Lisp design", or something that
would be equivalent to "good OO design" in the OO world?
Actually, another question is: how is the development process when you
work with Lisp? (It's my first non-mainstream language, so I am a bit
lost).
Thank you a lot!
-- mnunes
On 25 May, 10:59, Marcos Nunes <··············@gmail.com> wrote:
> Hello.
>
> I'd like to start learning Lisp. So, I got a few books and found some
> really interesting resources on the web... But I still miss one thing:
> besides learning Lisp (the language itself), is there some place where I
> can also learn something like "good Lisp design", or something that
> would be equivalent to "good OO design" in the OO world?
>
> Actually, another question is: how is the development process when you
> work with Lisp? (It's my first non-mainstream language, so I am a bit
> lost).
>
> Thank you a lot!
> -- mnunes
Well you could start here:
http://norvig.com/luv-slides.ps
A tutorial on good lisp style by Peter Norvig and Kent Pitman.
On 2007-05-25, Chris Russell <·····················@gmail.com> wrote:
> On 25 May, 10:59, Marcos Nunes <··············@gmail.com> wrote:
>> Actually, another question is: how is the development process when you
>> work with Lisp? (It's my first non-mainstream language, so I am a bit
>> lost).
>>
>> Thank you a lot!
>> -- mnunes
>
> Well you could start here:
> http://norvig.com/luv-slides.ps
>
> A tutorial on good lisp style by Peter Norvig and Kent Pitman.
Thank you! That is useful. I see on page 87 something about programming
in the large. They mention some software development stages:
- Requirements
- Architecture
- Component design
- Implementation
- Debugging
- Tuning
And later say that exploratory programming helps minimize the time spent
on component design. But I'd like to know more about how using Lisp
affects the other stages of development.
How do you deal with requirements? And (this is particularly important)
how is architecture affected? I suppose I should switch from my
previous Java/C++ architecture/design habits to something else?
Thank you,
-- mnunes
From: John Thingstad
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <op.tsvs2ezwpqzri1@pandora.upc.no>
On Fri, 25 May 2007 13:28:19 +0200, Marcos Nunes
<··············@gmail.com> wrote:
>
> And later say that exploratory programming helps minimize the time spent
> on component design. But I'd like to know more about how using Lisp
> affects the other stages of development.
>
> How do you deal with requirements? And (this is particularly important)
> how is architecture affected? I suppose I should switch from my
> previous Java/C++ architecture/design habits to something else?
>
> Thank you,
> -- mnunes
>
Well one of the best books on abject oriented analysis I have read is
"Object-oriented analysis" by Coad Yourdon.
It is quite old from 1991 but still seems valid enough.
It specifically emphasises spiral development and prototyping for
requirements analysis.
(They used Smalltalk but using it for CL should work just fine.)
Available used and new at bargain prices from amazon. (11$ including
shipment new..)
http://www.amazon.com/Object-Oriented-Analysis-Peter-Coad/dp/0136299814
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On 2007-05-25, John Thingstad <··············@chello.no> wrote:
> Well one of the best books on abject oriented analysis I have read is
> "Object-oriented analysis" by Coad Yourdon.
> It is quite old from 1991 but still seems valid enough.
> It specifically emphasises spiral development and prototyping for
> requirements analysis.
> (They used Smalltalk but using it for CL should work just fine.)
>
> Available used and new at bargain prices from amazon. (11$ including
> shipment new..)
>
> http://www.amazon.com/Object-Oriented-Analysis-Peter-Coad/dp/0136299814
Thank you. So basically, I'd still do something close to OO, but with
the benefits of rapid prototyping and being able to change the design
more quickly?
The process starts, then in the same way as with OO design?
OK, I'll get the book. :-)
Thank you for your help!
-- mnunes
From: John Thingstad
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <op.tsvypxnppqzri1@pandora.upc.no>
On Fri, 25 May 2007 14:14:34 +0200, Marcos Nunes
<··············@gmail.com> wrote:
>
> Thank you. So basically, I'd still do something close to OO, but with
> the benefits of rapid prototyping and being able to change the design
> more quickly?
That is ONE way. Not THE way.
> The process starts, then in the same way as with OO design?
Sort of.
Also you might want to grab the PDF
Accellerating Hindsight
Lisp as a Vehicle for Rapid Prototyping
by Kent Pitman
http://www.nhplace.com/kent/PS/Hindsight.html
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
In article <·····························@localhost.localdomain>,
Marcos Nunes <··············@gmail.com> wrote:
> On 2007-05-25, Chris Russell <·····················@gmail.com> wrote:
> > On 25 May, 10:59, Marcos Nunes <··············@gmail.com> wrote:
> >> Actually, another question is: how is the development process when you
> >> work with Lisp? (It's my first non-mainstream language, so I am a bit
> >> lost).
> >>
> >> Thank you a lot!
> >> -- mnunes
> >
> > Well you could start here:
> > http://norvig.com/luv-slides.ps
> >
> > A tutorial on good lisp style by Peter Norvig and Kent Pitman.
>
> Thank you! That is useful. I see on page 87 something about programming
> in the large. They mention some software development stages:
>
> - Requirements
> - Architecture
> - Component design
> - Implementation
> - Debugging
> - Tuning
>
> And later say that exploratory programming helps minimize the time spent
> on component design. But I'd like to know more about how using Lisp
> affects the other stages of development.
>
> How do you deal with requirements? And (this is particularly important)
> how is architecture affected? I suppose I should switch from my
> previous Java/C++ architecture/design habits to something else?
You won't find that much written about that.
A few notes:
* much what applies to software design with Smalltalk applies to Lisp.
There is some Smalltalk literature (from Kent Beck and others).
* Lisp in general and even Common Lisp is applicable to
a wide range of software systems. These may have very
different development styles.
* Often you see a prototype-based approach: build
a working prototype and refine it in tight cycles
while discussing the results with the customer.
Sometimes the customer may even be present when
changes to the code are made.
Btw., a little-known but cool story comes from
the Smalltalk world: when Steve Jobs of Apple
visited PARC to learn about their projects in
personal computers and guis, they showed him some
stuff. But not the more interesting things. Like
the Smalltalk system. He somehow got to know
that there was more to see and at a second visit
they showed him Smalltalk. There was demo of
scrolling text in some window. Jobs thought
that the scrolling should not be line by line
by smoother. The guy doing the demo (maybe that
was Larry Tesler) went into the source code browser,
looked up the method, changed the method and, 'boom',
there was smooth scrolling.
* There is a mismatch with UML and CLOS. UML seems not to
be used widely.
* There was a book Lisp Style and Design. Hard to get. No
longer available.
* Other books which give hints and explain things
are 'Practical Common Lisp' (Seibel) and 'Paradigms of
Artificial Intelligence Programming' (Norvig).
Both are very good books and are highly recommended.
* Another widely use approach some people call
nowadays is programming with 'domain specific languages'.
In Lisp this is easy, because it can be integrated
into the language and the development environment and
one can reuse all kinds of Lisp infrastructure.
But most of the DSLs people now write about are
just syntactic sugar. In Lisp one did more.
There are several programming books which show
you how to develop embedded languages in Lisp.
The basic idea is that for expressing knowledge
about a problem you need a language for that.
The language implementation needs to provide
the right services. These languages might need
a different paradigm (rules, objects, constraints,
message passing, blackboards, agents, ...).
So you embed a system for that in Lisp and then
you can express the problem domain much easier.
One of those books is: 'Artificial Intelligence Programming'
http://www.amazon.com/Artificial-Intelligence-Programming-Eugene-Charniak/dp/0898596092
This affects architecture. In Java/J2EE you would build
complex object/class architectures with lots of XML
files to describe things. In Lisp you can describe
much more directly and it is much easier to use/build
architectures that don't fit in some 'standard model'.
* Late binding is one principle. You delay many decisions
to runtime. One effect to this is that you
can ship an application to a customer and later
you only send patches. No need to give him a new
version of his/her application every time.
The customer might even load these patches while
the application is still running.
You can imagine that the whole cycle of getting bug
reports and shipping improvements to the customer
can be much shorter.
* Another idea to look out for is that you design software
in Lisp so that the amount of work needed to
change the software depends on the size of the change
and not on the size of the software.
This is one of the core principles of incremental
software development.
* Another stream of ideas came out of the work on
'Open Implementation'. Things like Aspect-oriented
Programming are coming from there.
http://www2.parc.com/csl/groups/sda/publications/
* Here is a more philosophical description
of an operating system written in Lisp:
http://lispm.dyndns.org/genera-concepts/genera.html
It should give you some ideas about the design principles.
>
> Thank you,
> -- mnunes
--
http://lispm.dyndns.org
My question about Lisp design:
How do you choose when to use which paradigm?
Most other languages choose the paradigm for you. With Lisp, you can
freely choose functional programming, object oriented programming,
creating a domain specific language, hacking the meta-object protocol,
and many others. It seems like some people like to add new
programming paradigms to Common Lisp for fun (and we all benefit).
A concrete example of this was a recent question of whether to use a
closure or an object for a specific task. I've also read people
asking about when to use functions or macros. I'm sure you can think
of similar examples.
This is a nice problem to have. But still, I haven't found much
written about this specific issue precisely because it does not come
up in most other languages. I think it could be the topic for a very
interesting Common Lisp book.
Has this book already been written?
-jimbo
········@gmail.com writes:
> How do you choose when to use which paradigm?
By thinking.
> Has this book already been written?
Not yet. It's called Strong AI.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On May 25, 1:08 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> ········@gmail.com writes:
> > How do you choose when to use which paradigm?
>
> By thinking.
If you don't know, you could just say that.
> > Has this book already been written?
>
> Not yet. It's called Strong AI.
Uh, that would mean a machine choosing the correct paradigm. I was
asking about strategies, heuristics, etc. for a human programmer to
decide which strategies to use. So we may not have computers that
can, say, write a good novel, but that does not mean there can't be a
book written about how to write good novels.
And Strong AI is not a book, more a philosophical idea. Or if it is a
book, but it doesn't exist yet, how can you know its name?
Your reply doesn't even make sense.
-jimbo
From: John Thingstad
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <op.tswm0kfhpqzri1@pandora.upc.no>
On Sat, 26 May 2007 00:38:17 +0200, <········@gmail.com> wrote:
> On May 25, 1:08 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>> ········@gmail.com writes:
>> > How do you choose when to use which paradigm?
>>
>> By thinking.
>
> If you don't know, you could just say that.
>
>> > Has this book already been written?
>>
>> Not yet. It's called Strong AI.
>
> Uh, that would mean a machine choosing the correct paradigm. I was
> asking about strategies, heuristics, etc. for a human programmer to
> decide which strategies to use. So we may not have computers that
> can, say, write a good novel, but that does not mean there can't be a
> book written about how to write good novels.
>
> And Strong AI is not a book, more a philosophical idea. Or if it is a
> book, but it doesn't exist yet, how can you know its name?
>
> Your reply doesn't even make sense.
>
> -jimbo
>
On the contrary. Why do you expect there is a recipe for selecting the
right approach.
The only way to know is from experience. Perhaps this might be the time to
introduce Peter Norvig's "Teach yourself to program in 10 years"
http://www.norvig.com/21-days.html
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On May 25, 6:49 pm, "John Thingstad" <··············@chello.no> wrote:
> On the contrary. Why do you expect there is a recipe for selecting the
> right approach.
> The only way to know is from experience. Perhaps this might be the time to
> introduce Peter Norvig's "Teach yourself to program in 10 years"
>
> http://www.norvig.com/21-days.html
Well, yes. But someone could conceivably flesh out this essay into
book form. It would still take 10 years to learn to program, but a
good book could help you know if you were still on course. In fact, I
think reading good books about programming should be added to Norvig's
list. Yes, learning by doing is irreplaceable. But learning from
books is not totally worthless.
There are lots of software books about various kinds of "best
practices", that are not necessarily tied to a specific programming
language. There are good books on software design, user interface
design, software development processes, etc. I think picking a
programming paradigm to suit a particular problem would be a great
topic for such a book. I haven't seen such a book, and apparently
neither does anyone following this thread. I don't think that
necessarily means, however, that such a book is somehow metaphysically
impossible.
Perhaps when I'm ready to retire I will know enough to write it. :)
-jimbo
From: John Thingstad
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <op.tswsumuqpqzri1@pandora.upc.no>
On Sat, 26 May 2007 01:14:18 +0200, <········@gmail.com> wrote:
>
> There are lots of software books about various kinds of "best
> practices", that are not necessarily tied to a specific programming
> language. There are good books on software design, user interface
> design, software development processes, etc. I think picking a
> programming paradigm to suit a particular problem would be a great
> topic for such a book. I haven't seen such a book, and apparently
> neither does anyone following this thread. I don't think that
> necessarily means, however, that such a book is somehow metaphysically
> impossible.
>
The problem is that there isn't one approach that works for all people.
You can't learn to be a good author either by reading about it.
Each has to find a style that suits him or her.
So buy a good on object oriented design. One on functional decomposition.
Top-down decomposition. One on logic programming decomposition.
The try all of the above. The idea is to prototype.
If one approach gets to cumbersome try another.
It simply takes time to find your style. If I were to write a book on
the right approach chances are many would disagree.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On May 25, 8:55 pm, "John Thingstad" <··············@chello.no> wrote:
> It simply takes time to find your style. If I were to write a book on
> the right approach chances are many would disagree.
I think this is where we're coming at this a little differently. I'm
thinking that the problem you need to solve should dictate the style
of programming best suited to solving it. That it's less a matter of
personal style, but more a matter of the problem domain.
For example, I recently found functional programming to be very
natural for implementing mathematical formulas and algorithms from
textbooks. It was almost like transcription. I'm also pretty
experienced with object oriented design techniques.
But I'm thinking there must be more wisdom out there I can draw on.
And I'm thinking that the Lisp community is a likely place to find
such wisdom because of how easy Lisp makes it to combine and switch
paradigms.
Surely someone here has come up with certain heuristics like "Here's a
good place to use an object", "MOP hacking would be overkill here",
"Don't use a macro when passing a function will do"?
I don't think the possibility of many people disagreeing is a good
reason to not write a book or not put forth an argument. Sometime
stimulating more discussion is the more important thing.
-jimbo
From: Richard M Kreuter
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <87bqg7jtbe.fsf@tan-ru.localdomain>
········@gmail.com writes:
> Surely someone here has come up with certain heuristics like "Here's a
> good place to use an object", "MOP hacking would be overkill here",
> "Don't use a macro when passing a function will do"?
People do come up with such heuristics, but Lispers are generally
unwilling to assent to any particular set of rules for how to program,
because, I think, we're willing to grant that we don't all want the
same things in a language. After all, how do you think that Common
Lisp got to be as inclusive and permissive as it is if not for
willingness, if sometimes reluctant, to tolerate difference of opinion
about style and design? This, I think, is why you're seeing people
object to what you seem to think is an innocent request for
guidelines.
If you really are interested in getting a handle on design issues in
Lisp, then do as others have suggested: learn the language, write and
read programs in it.
On May 26, 3:09 pm, Richard M Kreuter <·······@progn.net> wrote:
> ········@gmail.com writes:
> People do come up with such heuristics, but Lispers are generally
> unwilling to assent to any particular set of rules for how to program,
> because, I think, we're willing to grant that we don't all want the
> same things in a language. After all, how do you think that Common
> Lisp got to be as inclusive and permissive as it is if not for
> willingness, if sometimes reluctant, to tolerate difference of opinion
> about style and design? This, I think, is why you're seeing people
> object to what you seem to think is an innocent request for
> guidelines.
Interesting. So I just stepped on a small CL cultural land mine. The
responses make a lot more sense in this context.
> If you really are interested in getting a handle on design issues in
> Lisp, then do as others have suggested: learn the language, write and
> read programs in it.
I did all my homeworks in CL for a course this Spring, am currently
reading Art of the MOP and SICP and will try some more hacking after
I've had some time to relax with family. Indeed, "Keep writing code"
is never a bad suggestion to someone who wants to become a better
programer. :)
-jimbo
On Fri, 25 May 2007 21:51:08 -0700, jimbokun wrote:
> On May 25, 8:55 pm, "John Thingstad" <··············@chello.no> wrote:
>> It simply takes time to find your style. If I were to write a book on
>> the right approach chances are many would disagree.
>
> I think this is where we're coming at this a little differently. I'm
> thinking that the problem you need to solve should dictate the style
> of programming best suited to solving it. That it's less a matter of
> personal style, but more a matter of the problem domain.
It is a seductive line of reasoning, but I have strong doubts that it is
correct. Or rather, my suspicion is that the decision surface is likely
to be more-or-less flat, with many shallow local minima and broad
inflections. Definining "best" in any useful sense is going to be the
trickiest problem. And don't forget that for any given practitioner,
gaining expertise in any new technique is work. There's also been this
15+ year push in the wider programming community to reduce everything to
just the one technique. Easier/cheaper to train programmers, that way.
Getting everyone away from spaghetti BASIC and FORTRAN has been a major
achievement, IMO...
"`Better' is the enemy of `good enough'" and all that...
Cheers,
--
Andrew
On May 25, 6:49 pm, "John Thingstad" <··············@chello.no> wrote:
> http://www.norvig.com/21-days.html
Also from this article:
"Also consider your future friends: the community of programmers that
you will be a part of if you continue. Does your chosen language have
a large growing community or a small dying one? Are there books, web
sites, and online forums to get answers from? Do you like the people
in those forums?"
Perhaps I should heed this advice more carefully.
-jimbo
From: Robert Uhl
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <m3hcpy6cfm.fsf@latakia.dyndns.org>
"John Thingstad" <··············@chello.no> writes:
>
> On the contrary. Why do you expect there is a recipe for selecting the
> right approach.
I don't expect there's a recipe for selecting the _correct_ approach; I
do, however, expect there are several recipes to select a _decent_
approach.
There are plenty of books of patterns for other languages; surely there
are or could be for Lisp. PAIP covers a lot, doesn't it?
--
Robert Uhl <http://public.xdi.org/=ruhl>
> It is truly amazing, the number of people calling themselves IT
> professionals, that still have the guts to ask for FTP access.
Come on, that was an obscene thing to ask for in 1998, let alone
8 years on. --Michel Buijsman
In the last episode, on Friday 25 May 2007 18:08, Pascal Bourguignon wrote:
> ········@gmail.com writes:
>> How do you choose when to use which paradigm?
>
> By thinking.
>
>
Laugh-out-loud funny ;-)
In article <························@k79g2000hse.googlegroups.com>,
········@gmail.com wrote:
> My question about Lisp design:
>
> How do you choose when to use which paradigm?
>
> Most other languages choose the paradigm for you. With Lisp, you can
> freely choose functional programming, object oriented programming,
> creating a domain specific language, hacking the meta-object protocol,
> and many others. It seems like some people like to add new
> programming paradigms to Common Lisp for fun (and we all benefit).
>
> A concrete example of this was a recent question of whether to use a
> closure or an object for a specific task. I've also read people
> asking about when to use functions or macros. I'm sure you can think
> of similar examples.
>
> This is a nice problem to have. But still, I haven't found much
> written about this specific issue precisely because it does not come
> up in most other languages. I think it could be the topic for a very
> interesting Common Lisp book.
I strongly agree that there is a need for a book
that explains software design and architecture in
Common Lisp. It would take quite some time and discussion
with architects to write and refine it.
There must be some practice that has gone beyond
experimentation and common sense thinking.
Common Lisp was thought not for toy problems, but scalable
to big serious applications. This means that lots of
architectural problems have to be solved,
mission critical software will be created that
has to be maintained and first you need developers
which are educated and able to write these
applications.
I find it for example extremely useful that Franz
offers Lisp training:
http://www.franz.com/services/classes/
I have not attended those training sessions from Franz,
but I can easily imagine that it is extremely
useful. Plus you get in contact to other people
who have the same interest (writing Lisp software
and designing Lisp-based software architectures).
>
> Has this book already been written?
>
> -jimbo
--
http://lispm.dyndns.org
From: Ken Tilton
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <2WW5i.1165$3N7.544@newsfe12.lga>
Rainer Joswig wrote:
> In article <························@k79g2000hse.googlegroups.com>,
> ········@gmail.com wrote:
>
>
>>My question about Lisp design:
>>
>>How do you choose when to use which paradigm?
>>
>>Most other languages choose the paradigm for you. With Lisp, you can
>>freely choose functional programming, object oriented programming,
>>creating a domain specific language, hacking the meta-object protocol,
>>and many others. It seems like some people like to add new
>>programming paradigms to Common Lisp for fun (and we all benefit).
>>
>>A concrete example of this was a recent question of whether to use a
>>closure or an object for a specific task. I've also read people
>>asking about when to use functions or macros. I'm sure you can think
>>of similar examples.
>>
>>This is a nice problem to have. But still, I haven't found much
>>written about this specific issue precisely because it does not come
>>up in most other languages. I think it could be the topic for a very
>>interesting Common Lisp book.
>
>
> I strongly agree that there is a need for a book
> that explains software design and architecture in
> Common Lisp. It would take quite some time and discussion
> with architects to write and refine it.
Nah, just ask me. You can usually find me here or down at the corner
pub: legget's manasquan. But don't forget the sign they have: IITYWYBMAD.
kt
On May 26, 9:49 am, Ken Tilton <···········@optonline.net> wrote:
> Nah, just ask me. You can usually find me here or down at the corner
> pub: legget's manasquan. But don't forget the sign they have: IITYWYBMAD.
>
> kt
Great! Then if we can just record and transcribe all of these
dispensations of your wisdom, we'll have our book!
:)
-jimbo
From: John Thingstad
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <op.tsxlg2wfpqzri1@pandora.upc.no>
On Sat, 26 May 2007 09:12:17 +0200, Rainer Joswig <······@lisp.de> wrote:
>
> Common Lisp was thought not for toy problems, but scalable
> to big serious applications. This means that lots of
> architectural problems have to be solved,
> mission critical software will be created that
> has to be maintained and first you need developers
> which are educated and able to write these
> applications.
>
>>
>> Has this book already been written?
>>
Well there is one: "Patters of software" by Richard Gabriel.
Avalible in PDF format only (free) from:
http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> On Sat, 26 May 2007 09:12:17 +0200, Rainer Joswig <······@lisp.de> wrote:
>
>>
>> Common Lisp was thought not for toy problems, but scalable
>> to big serious applications. This means that lots of
>> architectural problems have to be solved,
>> mission critical software will be created that
>> has to be maintained and first you need developers
>> which are educated and able to write these
>> applications.
>>
>>>
>>> Has this book already been written?
>>>
>
> Well there is one: "Patters of software" by Richard Gabriel.
>
> Avalible in PDF format only (free) from:
> http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf.
>
> --Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
So what do you all think about this "worst is better" approach ?
Sacha
Sacha wrote:
> So what do you all think about this "worst is better" approach ?
I think it's often quoted by people who have not taken the trouble to
define a metric of "goodness" in the first place. "worse now" is often
better than "better later", especially if it's likely that "later"
actually means "never, because the project will be cancelled/the company
will die/the free software fairy will be distracted by something
shinier" - that's a big part of the Second System Effect that Brooks
observed. On the other hand, there are applications in which the
available "worse" is just so /much/ worse than acceptable that the
responsible thing to do is say "better the possibility of nothing than
this". Safety-critical systems are the obvious example. Somewhere in
the middle are the applications where you just don't /know/ whether
spending a couple of weeks on a crappy implementation is sensible,and
you need to look at it more deeply.
Just like all the other soundbite maxims: "plan to throw one away", or
"YAGNI", or "rough consensus and tunning code", it's good if it makes
people who might otherwise be planning the Universal Problem Solver stop
and think about the requirements; it's not good if it's used as a
substitute for thinking about the requirements.
-dan
From: Daniel Trstenjak
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <20070526104509.GB7354@linux.ver>
On Fri, May 25, 2007 at 08:20:51AM -0700, ········@gmail.com wrote:
> My question about Lisp design:
>
> How do you choose when to use which paradigm?
>
> Most other languages choose the paradigm for you. With Lisp, you can
> freely choose functional programming, object oriented programming,
> creating a domain specific language, hacking the meta-object protocol,
> and many others. It seems like some people like to add new
> programming paradigms to Common Lisp for fun (and we all benefit).
You are used to look from the wrong point of view on problems. Because
you are used to use programming languages with restricted possibilites.
When programming in languages like Java or C++, you just can't foremost
think of the nicest and simplest solution and then implement it.
Because you just never can implement this solution with the language
itself. So you have to think of the solution inside the possibilites of
the language.
Now you try to do the same thing in lisp. But the possibilites of lisp
are enormous, so you just can't think of a solution inside of lisp, you
are getting overburned. But this isn't necessary, because lisp is so
powerful that "almost" everything is doable. So instead of thinking of a
solution inside the language possibilites, you can think in terms of
beauty and simplicity.
The finding of a solution is in lisp more restricted by the possibilites
of the programmer than of the possibilites of the language.
In article <·····················@linux.ver>,
Daniel Trstenjak <················@online.de> wrote:
> On Fri, May 25, 2007 at 08:20:51AM -0700, ········@gmail.com wrote:
> > My question about Lisp design:
> >
> > How do you choose when to use which paradigm?
> >
> > Most other languages choose the paradigm for you. With Lisp, you can
> > freely choose functional programming, object oriented programming,
> > creating a domain specific language, hacking the meta-object protocol,
> > and many others. It seems like some people like to add new
> > programming paradigms to Common Lisp for fun (and we all benefit).
>
> You are used to look from the wrong point of view on problems. Because
> you are used to use programming languages with restricted possibilites.
> When programming in languages like Java or C++, you just can't foremost
> think of the nicest and simplest solution and then implement it.
> Because you just never can implement this solution with the language
> itself. So you have to think of the solution inside the possibilites of
> the language.
I don't buy that. Having more possibilities does not
mean one needs less guidance. More direct solutions
does not mean you need to find those direct ways.
Just random thoughts:
What is an API in Lisp? How do you write one that is direct
and not reinventing built-in mechanisms? How do you
maximum compile-time checking of the usage of the API?
What is a layered architecture in Lisp? Should you
write your own method combinations? When? Should you
use multi-methods dispatching on more than one arg?
When? Should you use structures or CLOS classes?
How to define a package interface? How many packages
does your application need? Which? Should you
write slot-daemons? Should you extend CLOS? How?
Where to extend (re-)initialization of objects?
What are the drawbacks of hashtables? How do you
implement sparse objects? Should you use lists
instead of objects? Property lists? Should you extend
objects with property lists? What is better a deep
or a flat class hierarchy? When to restrict yourself
to mixins? Should you use a prototype-based approach
to objects? When? Can it be integrated with CLOS? There
are dependencies between objects? Constraints? How?
Cells? (Hi Ken!) You need relations. Now you see
there is Relational Lisp and Ap5. Which one is better?
For what purpose? Your software has ten modules and
fifty files. Should you model the dependencies with DEFSYSTEM?
Is it worth it? You want to use extended documentation
strings? Which tool is good? Should I write my own?
You have generic functions with hundreds of methods?
Is that good? How do you find one? You have large macros?
Do they check their input? How? You want convenient
error checking and recovery? How to use the condition
system to do that? You need rules? What should they
do? CLOS-based? Fast? Expressive? Forward? Backward?
Prolog-style? Ops5-style? What kind of if-then patterns?
What kind of interface to it? TELL? ASK? Compiled?
You need threads? Why are many interfaces so similar? But why
the differences? Should your GUI library use threads?
How does that mix with the host system? How do you
want to react to a button press? A callback? An explicit
function?
I'm not saying that there are definitive answers to
all those questions and everything can be written down,
but to get some possible answers
before inventing your own would be useful. I think
it is useful not only to explain the basic language
constructs and how to use them, but also the pragmatics:
when to you what at which cost. Also: when is the
built in stuff not what I want and what to do next.
> Now you try to do the same thing in lisp. But the possibilites of lisp
> are enormous, so you just can't think of a solution inside of lisp, you
> are getting overburned. But this isn't necessary, because lisp is so
> powerful that "almost" everything is doable. So instead of thinking of a
> solution inside the language possibilites, you can think in terms of
> beauty and simplicity.
>
> The finding of a solution is in lisp more restricted by the possibilites
> of the programmer than of the possibilites of the language.
That's fine. But after twenty totally different graphics APIs
have been developed you'd wish somebody would have written
down what worked and what not, so that the next architect
gets some clue how it is supposed to work and extended.
Looking at the source code is also fine, but it does not
give you the history of it. How it was developed, what
were ideas that didn't work, where was the design changed
and why during the development? What are the weak
parts of the design? And so on.
--
http://lispm.dyndns.org
From: Daniel Trstenjak
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <20070526121826.GA8514@linux.ver>
On Sat, May 26, 2007 at 01:45:46PM +0200, Rainer Joswig wrote:
> I don't buy that. Having more possibilities does not
> mean one needs less guidance. More direct solutions
> does not mean you need to find those direct ways.
That's not what I wanted to express. You are right, knowledge and
experience are the fundament for the ability to use the possibilities in
a appropriate way.
I wanted to show a possible mental state, in which programmers are
trapped. The way in which programming languages or programming pratices
are damaging their brains. When you are using something restrictive,
you are restricting yourself. The worst thing is, you are getting used
to it.
But sometimes I think, people just want exactly this. They can get lazy,
don't have to think, and nothing unusual can frighten them.
On May 26, 7:45 am, Rainer Joswig <······@lisp.de> wrote:
> What is an API in Lisp? How do you write one that is direct
> and not reinventing built-in mechanisms? How do you
> maximum compile-time checking of the usage of the API?
> What is a layered architecture in Lisp? Should you
> write your own method combinations? When? Should you
> use multi-methods dispatching on more than one arg?
> When? Should you use structures or CLOS classes?
> How to define a package interface? How many packages
> does your application need? Which? Should you
> write slot-daemons? Should you extend CLOS? How?
> Where to extend (re-)initialization of objects?
> What are the drawbacks of hashtables? How do you
> implement sparse objects? Should you use lists
> instead of objects? Property lists? Should you extend
> objects with property lists? What is better a deep
> or a flat class hierarchy? When to restrict yourself
> to mixins? Should you use a prototype-based approach
> to objects? When? Can it be integrated with CLOS? There
> are dependencies between objects? Constraints? How?
> Cells? (Hi Ken!) You need relations. Now you see
> there is Relational Lisp and Ap5. Which one is better?
> For what purpose? Your software has ten modules and
> fifty files. Should you model the dependencies with DEFSYSTEM?
> Is it worth it? You want to use extended documentation
> strings? Which tool is good? Should I write my own?
> You have generic functions with hundreds of methods?
> Is that good? How do you find one? You have large macros?
> Do they check their input? How? You want convenient
> error checking and recovery? How to use the condition
> system to do that? You need rules? What should they
> do? CLOS-based? Fast? Expressive? Forward? Backward?
> Prolog-style? Ops5-style? What kind of if-then patterns?
> What kind of interface to it? TELL? ASK? Compiled?
> You need threads? Why are many interfaces so similar? But why
> the differences? Should your GUI library use threads?
> How does that mix with the host system? How do you
> want to react to a button press? A callback? An explicit
> function?
So now we have a table of contents. If we ask Kenny all these
questions down at the pub and get the answers, we'll be all set.
Right?
-jimbo
In article <························@g4g2000hsf.googlegroups.com>,
········@gmail.com wrote:
> On May 26, 7:45 am, Rainer Joswig <······@lisp.de> wrote:
> > What is an API in Lisp? How do you write one that is direct
> > and not reinventing built-in mechanisms? How do you
> > maximum compile-time checking of the usage of the API?
> > What is a layered architecture in Lisp? Should you
> > write your own method combinations? When? Should you
> > use multi-methods dispatching on more than one arg?
> > When? Should you use structures or CLOS classes?
> > How to define a package interface? How many packages
> > does your application need? Which? Should you
> > write slot-daemons? Should you extend CLOS? How?
> > Where to extend (re-)initialization of objects?
> > What are the drawbacks of hashtables? How do you
> > implement sparse objects? Should you use lists
> > instead of objects? Property lists? Should you extend
> > objects with property lists? What is better a deep
> > or a flat class hierarchy? When to restrict yourself
> > to mixins? Should you use a prototype-based approach
> > to objects? When? Can it be integrated with CLOS? There
> > are dependencies between objects? Constraints? How?
> > Cells? (Hi Ken!) You need relations. Now you see
> > there is Relational Lisp and Ap5. Which one is better?
> > For what purpose? Your software has ten modules and
> > fifty files. Should you model the dependencies with DEFSYSTEM?
> > Is it worth it? You want to use extended documentation
> > strings? Which tool is good? Should I write my own?
> > You have generic functions with hundreds of methods?
> > Is that good? How do you find one? You have large macros?
> > Do they check their input? How? You want convenient
> > error checking and recovery? How to use the condition
> > system to do that? You need rules? What should they
> > do? CLOS-based? Fast? Expressive? Forward? Backward?
> > Prolog-style? Ops5-style? What kind of if-then patterns?
> > What kind of interface to it? TELL? ASK? Compiled?
> > You need threads? Why are many interfaces so similar? But why
> > the differences? Should your GUI library use threads?
> > How does that mix with the host system? How do you
> > want to react to a button press? A callback? An explicit
> > function?
>
> So now we have a table of contents. If we ask Kenny all these
> questions down at the pub and get the answers, we'll be all set.
>
> Right?
>
> -jimbo
Make recording of it. Better, a movie.
Looking forward to it.
--
http://lispm.dyndns.org
On 2007-05-25, Rainer Joswig <······@lisp.de> wrote:
> You won't find that much written about that.
WOW!
Thanks for the long list of good resources!
> * Lisp in general and even Common Lisp is applicable to
> a wide range of software systems. These may have very
> different development styles.
Ah, now I'm beginning to understand.
> * Often you see a prototype-based approach: build
> a working prototype and refine it in tight cycles
> while discussing the results with the customer.
> Sometimes the customer may even be present when
> changes to the code are made.
Even for large and complex systems?
> * There is a mismatch with UML and CLOS. UML seems not to
> be used widely.
I suppose you mean UML (Unified Modelling Language) is not widely used
*with CLOS*?
And I guess this is because UML is kind of restricted to the Java view
of OO?
(Domain specific languages)
> This affects architecture. In Java/J2EE you would build
> complex object/class architectures with lots of XML
> files to describe things. In Lisp you can describe
> much more directly and it is much easier to use/build
> architectures that don't fit in some 'standard model'.
OK, so I'd spend my planning time not just figuring out objects and
messages, but planning a language which would involve objects and
methods.
Maybe also I'd work on functional decomposition, etc... So there is a
design stage, but it's much more flexible than what I'm used to.
Very interesting.
Again, thanks for this large list! It certainly helps a lot.
-- mnunes
In article <·····························@localhost.localdomain>,
Marcos Nunes <··············@gmail.com> wrote:
> On 2007-05-25, Rainer Joswig <······@lisp.de> wrote:
> > You won't find that much written about that.
>
> WOW!
> Thanks for the long list of good resources!
>
> > * Lisp in general and even Common Lisp is applicable to
> > a wide range of software systems. These may have very
> > different development styles.
>
> Ah, now I'm beginning to understand.
>
> > * Often you see a prototype-based approach: build
> > a working prototype and refine it in tight cycles
> > while discussing the results with the customer.
> > Sometimes the customer may even be present when
> > changes to the code are made.
>
> Even for large and complex systems?
Yes. That's the idea. If you want to change a function
in a million line software system, you change that
function while the software is running, compile it, load
it and then you can use it. No need for a
lengthy compile, link, run, load sequence.
>
> > * There is a mismatch with UML and CLOS. UML seems not to
> > be used widely.
>
> I suppose you mean UML (Unified Modelling Language) is not widely used
> *with CLOS*?
Yes, right.
>
> And I guess this is because UML is kind of restricted to the Java view
> of OO?
I'm not sure what UML has as a view. It is message passing somehow.
But there is so much in UML 2 and it moved from a drawing
notation to a visual programming language...
I guess it could be used for CLOS-based software somehow.
> (Domain specific languages)
>
> > This affects architecture. In Java/J2EE you would build
> > complex object/class architectures with lots of XML
> > files to describe things. In Lisp you can describe
> > much more directly and it is much easier to use/build
> > architectures that don't fit in some 'standard model'.
>
> OK, so I'd spend my planning time not just figuring out objects and
> messages, but planning a language which would involve objects and
> methods.
> Maybe also I'd work on functional decomposition, etc... So there is a
> design stage, but it's much more flexible than what I'm used to.
> Very interesting.
Even the object systems in Lisp seem to over more things.
CLOS is like assembler for it. Plus you can play around
with objects and classes. Change them while the thing
is running. Extend them.
>
> Again, thanks for this large list! It certainly helps a lot.
>
> -- mnunes
--
http://lispm.dyndns.org
Marcos Nunes <··············@gmail.com> writes:
>> * There is a mismatch with UML and CLOS. UML seems not to
>> be used widely.
>
> I suppose you mean UML (Unified Modelling Language) is not widely used
> *with CLOS*?
>
> And I guess this is because UML is kind of restricted to the Java view
> of OO?
The problem is not an hypothetical mismatch between UML and CLOS (I've
noticed none). But rather, that CLOS is expressive and high-level
enough so you don't need to draw diagrams. You can directly design
your application with the CLOS (lisp) notation.
The best proof is that some CASE tools save their diagrams (of various
kind) as sexp. Then what's the purpose of fighting a GUI with a mouse
to generate sexps? Just write the sexps directly with emacs!
Of course the most advanced CASE propose tools to transform the
diagrams and to generate code. Here again, when you have lisp, you
already have these features provided by lisp macros!
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
From: John Thingstad
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <op.tsx716t7pqzri1@pandora.upc.no>
On Sat, 26 May 2007 19:50:16 +0200, Pascal Bourguignon
<···@informatimago.com> wrote:
> Marcos Nunes <··············@gmail.com> writes:
>>> * There is a mismatch with UML and CLOS. UML seems not to
>>> be used widely.
>>
>> I suppose you mean UML (Unified Modelling Language) is not widely used
>> *with CLOS*?
>>
>> And I guess this is because UML is kind of restricted to the Java view
>> of OO?
>
> The problem is not an hypothetical mismatch between UML and CLOS (I've
> noticed none). But rather, that CLOS is expressive and high-level
> enough so you don't need to draw diagrams. You can directly design
> your application with the CLOS (lisp) notation.
>
> The best proof is that some CASE tools save their diagrams (of various
> kind) as sexp. Then what's the purpose of fighting a GUI with a mouse
> to generate sexps? Just write the sexps directly with emacs!
>
> Of course the most advanced CASE propose tools to transform the
> diagrams and to generate code. Here again, when you have lisp, you
> already have these features provided by lisp macros!
>
You might look into the Coad Yourdon method for object oriented analysis.
No fancy CASE tools. The screen is too small to provide a overview anyhow.
I use a A0 piece of paper and post-it notes for classes. A line is a
relation.
Add a rectangle to the line and it is a instance relation (arity optional)
a upside down U is inheritance.
Name and attributes first. Once then hierarchy has stabilised start adding
methods.
(Multi-methods are a problem) A diagonal slash of the problem space.
Just a diagonal slash of the problem space to show that the main operations
work. The diagram is developed in parallel with the prototype.
Stipled lines to follow the flow of method though some of the main
operations. That's it. (Oh and I use a pencil and eraser, not pen)
Not fancy, but effective. UML just get's in the way of developement
by cluttering things up with too much detail. This seems to get the
balance right.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Pascal Bourguignon <···@informatimago.com> writes:
> Subject: Re: Learning Lisp design techniques (not just the language itself)?
>
> Marcos Nunes <··············@gmail.com> writes:
>>> * There is a mismatch with UML and CLOS. UML seems not to
>>> be used widely.
>>
>> I suppose you mean UML (Unified Modelling Language) is not widely used
>> *with CLOS*?
>>
>> And I guess this is because UML is kind of restricted to the Java view
>> of OO?
>
> The problem is not an hypothetical mismatch between UML and CLOS (I've
> noticed none). But rather, that CLOS is expressive and high-level
> enough so you don't need to draw diagrams. You can directly design
> your application with the CLOS (lisp) notation.
>
> The best proof is that some CASE tools save their diagrams (of various
> kind) as sexp. Then what's the purpose of fighting a GUI with a mouse
> to generate sexps? Just write the sexps directly with emacs!
>
> Of course the most advanced CASE propose tools to transform the
> diagrams and to generate code. Here again, when you have lisp, you
> already have these features provided by lisp macros!
While I don't disagree with what you have said, I do think it overlooks one
aspect of UML that is useful that is harder to achieve with CL and that is
client communication. Often, when I'm working on a project, there is someone
who represents the interests of the stakeholder who, while usually quite
technical, is predominately coming from the business requirements side of
things and is rarely a programmer. In this situation, UML is very useful
because it is a high enough abstraction that the client can understand and
follow things and hopefully, spot issues that are not obvious to the
programmer, who normally isn't as familiar with the business requirements.
If I'm working on something and don't have someone else to work/communicate
with that is an expert with respect tot he business requirements or if I'm also
that expert, then I'm unlikely to use UML to make the initial design.
Tim
--
tcross (at) rapttech dot com dot au
Pascal Bourguignon wrote:
> Marcos Nunes <··············@gmail.com> writes:
>>> * There is a mismatch with UML and CLOS. UML seems not to
>>> be used widely.
>> I suppose you mean UML (Unified Modelling Language) is not widely used
>> *with CLOS*?
>>
>> And I guess this is because UML is kind of restricted to the Java view
>> of OO?
>
> The problem is not an hypothetical mismatch between UML and CLOS (I've
> noticed none). But rather, that CLOS is expressive and high-level
> enough so you don't need to draw diagrams. You can directly design
> your application with the CLOS (lisp) notation.
How would one model a generic function specialized on more than its
first argument in UML? One could fake a modeling a method on a generic
function specialized on its first argument in UML as a "virtual"
function of the class on which it had been specialized. However, that
wouldn't be a true representation of the way that generic function
dispatch occurs. In fact, UML seems to think that functions only
"belong" to classes and doesn't even do a particularly good job of
representing things like the generic algorithms of C++; only classes can
be parameterized with template arguments and C++ algorithms are not
members of classes.
> The best proof is that some CASE tools save their diagrams (of various
> kind) as sexp. Then what's the purpose of fighting a GUI with a mouse
> to generate sexps? Just write the sexps directly with emacs!
I personally don't like the idea that software should be either CLI or
GUI. I love the way that Emacs, for example, has at least four
different ways for its user to tell it to save a file; "C-x C-s", "M-x
save-buffer", "(save-buffer ...)" from an elisp file, or the option
"Save (Current Buffer)" from the "File" drop-down menu GUI. Why fight
about The Right Way to do it when they're all equivalent in expressiveness.
> Of course the most advanced CASE propose tools to transform the
> diagrams and to generate code. Here again, when you have lisp, you
> already have these features provided by lisp macros!
IMO, the best software would give me the best of both worlds. If I were
to write a (defclass ...) in some file and the load it into the world of
the CASE tool, I should have access to a graphical representation of
that class. However, I should also be able to start the CASE tool,
mouse-n-click my way to the creation of a graphical representation of a
class which, when saved to a file, is saved as the same (defclass ...) I
would've typed into a text editor. I haven't played much with either
Allegro Common Graphics or Allegro Composer but from the little
exploring I've done, it seems to me that they both work this way.
In article <····················@newsread2.news.pas.earthlink.net>,
Damien Kick <·····@earthlink.net> wrote:
...
> > The best proof is that some CASE tools save their diagrams (of various
> > kind) as sexp. Then what's the purpose of fighting a GUI with a mouse
> > to generate sexps? Just write the sexps directly with emacs!
>
> I personally don't like the idea that software should be either CLI or
> GUI. I love the way that Emacs, for example, has at least four
> different ways for its user to tell it to save a file; "C-x C-s", "M-x
> save-buffer", "(save-buffer ...)" from an elisp file, or the option
> "Save (Current Buffer)" from the "File" drop-down menu GUI. Why fight
> about The Right Way to do it when they're all equivalent in expressiveness.
Right. Checkout CLIM and McCLIM (an implementation of CLIM).
Same idea. You write an implementation of a command and
you can invoke it in different ways: menus, context menus,
keystrokes, command interpreter, drag&drop, ...
...
--
http://lispm.dyndns.org
From: Pascal Costanza
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <5bri0qF2u2m25U1@mid.individual.net>
Marcos Nunes wrote:
>> * There is a mismatch with UML and CLOS. UML seems not to
>> be used widely.
>
> I suppose you mean UML (Unified Modelling Language) is not widely used
> *with CLOS*?
>
> And I guess this is because UML is kind of restricted to the Java view
> of OO?
When UML was defined, Java didn't exist, at least not for that long.
It's mostly oriented towards Smalltalk and C++ (the two dominant OOP
languages in the first half of the 90's).
The UML simply lacks support for some important concepts in CLOS on the
one hand. There is no support for generic functions / methods defined
outside of classes. There is no support for defining protocols (sets of
related generic functions).
On the other hand, probably no Common Lisp program every uses CLOS
exclusively. UML assumes that you use (class-centric) OOP exclusively.
So apart from the technical differences, there is a huge gap between a
multi-paradigm view on the one hand and a single-paradigm view on the other.
Class diagrams are the mostly used diagrams in UML. However, they are
quite trivial. Decent Common Lisp environments do provide tools to view
the class hierarchy graphically (for example in LispWorks). It doesn't
matter that much how close such diagrams are to any standard because
they pretty much work the same way either way.
For the above reasons, the other diagrams don't fit that well. For
example, a sequence diagram is based on the idea that objects send
messages to each other. That's simply and plainly not the case in CLOS.
Etc. pp.
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: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <EOJ5i.35$3N7.22@newsfe12.lga>
Marcos Nunes wrote:
> Hello.
>
> I'd like to start learning Lisp. So, I got a few books and found some
> really interesting resources on the web... But I still miss one thing:
> besides learning Lisp (the language itself), is there some place where I
> can also learn something like "good Lisp design", or something that
> would be equivalent to "good OO design" in the OO world?
Stop reading, start writing. Code. Post it here, we'll rip it apart.
>
> Actually, another question is: how is the development process when you
> work with Lisp? (It's my first non-mainstream language, so I am a bit
> lost).
Your only problem is The Lisp Mystique. It is indeed a mainstream
language. It is in fact all mainstream languages. Just start developing
as usual and look for chances to make your look the way Graham
recommends in On Lisp.
What it does not have is a mainstream IDE, except for AllegroCL Express
on win32 and (less so) Lispworks and (not so bad) MCL. Get ACL if you
can. Not on the Mac, tho, no IDE there.
kt
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
In the last episode, on Friday 25 May 2007 23:54, Ken Tilton wrote:
> What it does not have is a mainstream IDE, except for AllegroCL Express
> on win32 and (less so) Lispworks and (not so bad) MCL. Get ACL if you
> can. Not on the Mac, tho, no IDE there.
>
In fact, LispWorks' website claims that their IDE is available for Mac.
If you're using Linux, you can use SLIME, the Superior Lisp Mode for EMACS,
with the latter to prototype and compile code. It works with several of the
free Lisp implementations for that platform (including my preferred Steel
Bank Common Lisp). A little Googling also reveals that SLIME works with
LispWorks on the Mac.
HTH
Jeff
On May 25, 7:16 pm, Jeff Rollin <··············@gmail.com> wrote:
> In the last episode, on Friday 25 May 2007 23:54, Ken Tilton wrote:
> > What it does not have is a mainstream IDE, except for AllegroCL Express
> > on win32 and (less so) Lispworks and (not so bad) MCL. Get ACL if you
> > can. Not on the Mac, tho, no IDE there.
> In fact, LispWorks' website claims that their IDE is available for Mac.
It is. It's pretty cool, too. Comes with a CL-programmable Emacsoid
editor and everything.
I still prefer SLIME, but part of that is that I've gotten so used to
paredit.el that I just can't do without it.
Cheers,
Pillsy
From: Ken Tilton
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <LOM5i.64$3N7.44@newsfe12.lga>
Excerpted for those with ADD:
> On May 25, 7:16 pm, Jeff Rollin <··············@gmail.com> wrote:
>>In the last episode, on Friday 25 May 2007 23:54, Ken Tilton wrote:
>>> Get ACL if you can. Not on the Mac, tho, no IDE there.
>>In fact, LispWorks' website claims that their IDE is available for Mac.
What their web site does not claim is that they offer ACL. Franz does
that. Mind you, the Linux version sits atop GTk, should port to the Mac
eventually.
kt
From: Jeff Rollin
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <TOydnX92RIMpBMrbRVnyhgA@pipex.net>
In the last episode, on Saturday 26 May 2007 03:19, Ken Tilton wrote:
> Excerpted for those with ADD:
>
>> On May 25, 7:16 pm, Jeff Rollin <··············@gmail.com> wrote:
>>>In the last episode, on Friday 25 May 2007 23:54, Ken Tilton wrote:
>>>> Get ACL if you can. Not on the Mac, tho, no IDE there.
>>>In fact, LispWorks' website claims that their IDE is available for Mac.
>
> What their web site does not claim is that they offer ACL. Franz does
> that. Mind you, the Linux version sits atop GTk, should port to the Mac
> eventually.
>
> kt
Ah, I misunderstood you as saying that no IDE at all was available on the
Mac.
Sorry.
In article <···············@newsfe12.lga>,
Ken Tilton <···········@optonline.net> wrote:
> Excerpted for those with ADD:
>
> > On May 25, 7:16 pm, Jeff Rollin <··············@gmail.com> wrote:
> >>In the last episode, on Friday 25 May 2007 23:54, Ken Tilton wrote:
> >>> Get ACL if you can. Not on the Mac, tho, no IDE there.
> >>In fact, LispWorks' website claims that their IDE is available for Mac.
>
> What their web site does not claim is that they offer ACL. Franz does
> that. Mind you, the Linux version sits atop GTk, should port to the Mac
> eventually.
I read that at ILC 2007 it has been mentioned that Franz is working on
bringing the IDE to the Mac (with the help of Clozure).
>
> kt
--
http://lispm.dyndns.org
Pillsy wrote:
> On May 25, 7:16 pm, Jeff Rollin <··············@gmail.com> wrote:
>
>> In fact, LispWorks' website claims that their IDE is available for Mac.
>
> It is. It's pretty cool, too. Comes with a CL-programmable Emacsoid
> editor and everything.
and on Windows you can even switch the key bindings from Emacs to Windows
like editors, which is cool for mere mortals like me.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
In the last episode, on Saturday 26 May 2007 00:16, Jeff Rollin wrote:
> In the last episode, on Friday 25 May 2007 23:54, Ken Tilton wrote:
>
>> What it does not have is a mainstream IDE, except for AllegroCL Express
>> on win32 and (less so) Lispworks and (not so bad) MCL. Get ACL if you
>> can. Not on the Mac, tho, no IDE there.
>>
>
> In fact, LispWorks' website claims that their IDE is available for Mac.
>
> If you're using Linux, you can use SLIME, the Superior Lisp Mode for
> EMACS, with the latter to prototype and compile code.
Or rather, to prototype it before you compile it.
Jeff
In article <···············@newsfe12.lga>,
Ken Tilton <···········@optonline.net> wrote:
> Marcos Nunes wrote:
> > Hello.
> >
> > I'd like to start learning Lisp. So, I got a few books and found some
> > really interesting resources on the web... But I still miss one thing:
> > besides learning Lisp (the language itself), is there some place where I
> > can also learn something like "good Lisp design", or something that
> > would be equivalent to "good OO design" in the OO world?
>
> Stop reading, start writing. Code. Post it here, we'll rip it apart.
>
> >
> > Actually, another question is: how is the development process when you
> > work with Lisp? (It's my first non-mainstream language, so I am a bit
> > lost).
>
> Your only problem is The Lisp Mystique. It is indeed a mainstream
> language. It is in fact all mainstream languages. Just start developing
> as usual and look for chances to make your look the way Graham
> recommends in On Lisp.
I'm not sure that 'On Lisp' explains how to write good
Lisp software. It has some interesting bits and a lot
strange bits.
>
> What it does not have is a mainstream IDE, except for AllegroCL Express
> on win32 and (less so) Lispworks and (not so bad) MCL. Get ACL if you
> can. Not on the Mac, tho, no IDE there.
>
> kt
Corman CL has an IDE, too:
http://www.cormanlisp.com/
I can't say much about it, since I don't use Windows
that often, but I guess it is worth checking it out.
It is also not that expensive. The GUI is available
with the commercial version.
--
http://lispm.dyndns.org
On May 26, 3:58 am, "j.oke" <········@gmail.com> wrote:
> Some other ones preferences are much different:
>
> I really love 'On Lisp', and I don't understand all that hype about
> PCL (to me, some chapters are quite good, while others are far away
> from me).
>
> -JO
I dabbled in a lisp maybe for 5-7 years or longer thanks to
encouragement of my friend, but never managed to get enough of it to
be useful. PCL managed to get me over the hump in practicality. Since
then I started using it in my everyday job (may be 25% of the time,
not 100, but still..) This was very important --- you learn language
only when you do real work with it. Now for most of tasks longer then
one hour I manage to do it faster in Lisp then in Python which is a
great motivation to use it more often.
After few months of use something clicked. Now I read "On Lisp" and
enjoy it a lot. I consider myself a novice, of course. For experienced
folks PCL is probably useless.
My Lisp enlightenment is due mostly to PCL + slime movie + Rainer
Joswig "DSL in LISP" movie (which is very hard to watch on older
smaller PC due to 1600x1200 resolution, BTW).
From: Ken Tilton
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <fIW5i.1161$3N7.741@newsfe12.lga>
Rainer Joswig wrote:
> In article <···············@newsfe12.lga>,
> Ken Tilton <···········@optonline.net> wrote:
>
>
>>Marcos Nunes wrote:
>>
>>>Hello.
>>>
>>>I'd like to start learning Lisp. So, I got a few books and found some
>>>really interesting resources on the web... But I still miss one thing:
>>>besides learning Lisp (the language itself), is there some place where I
>>>can also learn something like "good Lisp design", or something that
>>>would be equivalent to "good OO design" in the OO world?
>>
...
> I'm not sure that 'On Lisp' explains how to write good
> Lisp software. It has some interesting bits and a lot
> strange bits.
That is only because you do not remember what's in it. Search on "fluid"
and then "tax" as a start.
>
> Corman CL has an IDE, too:
>
> http://www.cormanlisp.com/
>
> I can't say much about it, since I don't use Windows
> that often, but I guess it is worth checking it out.
Wow, yes, that has totally dropped from my radar... no, there it is, had
to clean off the jelly from the doughnut.
ken
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Ken Tilton <·········@gmail.com> wrote:
+---------------
| Rainer Joswig wrote:
| > Corman CL has an IDE, too:
| > http://www.cormanlisp.com/
| > I can't say much about it, since I don't use Windows
| > that often, but I guess it is worth checking it out.
|
| Wow, yes, that has totally dropped from my radar... no,
| there it is, had to clean off the jelly from the doughnut.
+---------------
Got jammed by Dark Helmet, did you? ;-}
"May the schwartz be with you!"
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Ken Tilton
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <PH56i.1218$3N7.572@newsfe12.lga>
Rob Warnock wrote:
> Ken Tilton <·········@gmail.com> wrote:
> +---------------
> | Rainer Joswig wrote:
> | > Corman CL has an IDE, too:
> | > http://www.cormanlisp.com/
> | > I can't say much about it, since I don't use Windows
> | > that often, but I guess it is worth checking it out.
> |
> | Wow, yes, that has totally dropped from my radar... no,
> | there it is, had to clean off the jelly from the doughnut.
> +---------------
>
> Got jammed by Dark Helmet, did you? ;-}
Omigod, yer right! Subliminal plagiarism at its best.
kt
From: Stefan Mandl
Subject: Re: Learning Lisp design techniques (not just the language itself)?
Date:
Message-ID: <5bqdcuF2u5qbcU1@mid.dfncis.de>
Hi Marcos and all others!
> I'd like to start learning Lisp. So, I got a few books and found some
> really interesting resources on the web... But I still miss one thing:
> besides learning Lisp (the language itself), is there some place where I
> can also learn something like "good Lisp design", or something that
> would be equivalent to "good OO design" in the OO world?
In my opinion, most people are forgetting one of the best resources for learning
"good X design": the source code of well designed X programs!
I guess the study of masterpiece-programs is something that is not common
practice for beginners.
Now, who knows a non-trivial (maybe not to complicated) CL-program with
beautiful source code and clean design?
< feel free to name your project here ;) >
What are the timeless CL (!) masterpieces that are worth studying?
Regards,
Stefan
On 2007-05-26, Stefan Mandl <············@informatik.uni-erlangen.de> wrote:
> Hi Marcos and all others!
>
>> I'd like to start learning Lisp. So, I got a few books and found some
>> really interesting resources on the web... But I still miss one thing:
>> besides learning Lisp (the language itself), is there some place where I
>> can also learn something like "good Lisp design", or something that
>> would be equivalent to "good OO design" in the OO world?
>
> In my opinion, most people are forgetting one of the best resources for learning
> "good X design": the source code of well designed X programs!
> I guess the study of masterpiece-programs is something that is not common
> practice for beginners.
OK, that's a good starting point, indeed!
But it still would be nice to understand the "process" that led to that
design. I guess I've been too long in the mainstream Java/C++ world,
where some people will tell you (particularly Java people) that you
should spend a very long time coming up with a specification, and later
do the coding (which is supposed to be "easy", since the hard problems
are solved in the design process).
And this is also where I thought Lisp would be very different, since a
more flexible design process could be in place (but which one? I'm
pretty sure it isn't trial and error!)
-- mnunes