Which is the "Lisp" way of programming?
Ray
I just started learning Lisp about a week ago. I'm really impressed
with the wealth of free Lisp material accessible right at my fingertips
(Practical Common Lisp, the HyperSpec, CL CookBook, and myriads of PDFs
available from very smart people, onLisp, history of lisp, etc. etc.).
I've been reading Practical Common Lisp everyday while trying the
examples using Lisp in a box.
I was wondering about one thing though. Correct me if I'm wrong, but
it's entirely possible to write a whole application without doing it
the OO way, just like it's possible to write C++ programs without
typing "class" even once, right?
So these days, what is considered the best practice for developing an
application in Lisp? Does this affect your analysis & design process in
any way? Or is it still OOAD, and you proceed as you would in, say,
Java/Python/C++, or it is somewhat different because Lisp can do things
that those other languages can't?
Thanks for any pointers/enlightenment,
Ray
Pascal Bourguignon
Well, actually there is no lisp way of programming. (and there's no
list, no syntax and no parenthese in lisp either, see some other
recent post of mine about it ;-))
There's no "lisp way" in the sence that lisp leaves you the freedom to
choose your programming paradgim. Lisp is supple enough to help you
with any programming paradigm you like.
You want procedural with go to? Use TAGBODY and GO.
You want functional and recursion? Of course you can.
You want OO programming? Lisp has the best OO system (CLOS), but if
you're not happy with it, there are a lot of other OO systems (like KR
which is prototype based) and you can write your own.
You want declarative programming? You can do it easily.
You want any paradigm of your invention? It's possible in lisp
because what Lisp is good at, is at _meta_-programming.
The best way to develop an application, well, it depends on the kind
of application. There is not one best way, there are several best
ways. In Lisp you can easily use a different way for each
application, or even, for each application parts.
Some successful applications have parts written in different
programming languages. Instead, they could be written entirely in
Lisp, but each part being written in a different lisp "style".
So what distinguish lisp programming from the other programming
languages or specific paradigms, is that in lisp you can easily do
meta programming, you can easily implement syntactic abstractions and
meta-linguistic abstractions (in addition to the classical data and
procedural abstractions). This allow you to easily develop language
layers, to get a domain specific language adapted to the application
(or application part) domain. And what's interesting in the lisp
approach, it's that all the domain specific languages you write in
lisp can coexist happily, which wouldn't not be possible or not easily
with C + lex + yacc.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again."
Ray
Pascal Bourguignon wrote:
<snip>
> There's no "lisp way" in the sence that lisp leaves you the freedom to
> choose your programming paradgim. Lisp is supple enough to help you
> with any programming paradigm you like.
> < snipped the rest>
Thanks for your reply! I understand what you mean, so CLOS is there not
because people are saying that "OO is the one true way and you must do
it in Lisp" (like in Java), but it's more along the line of "If you
want to do OO, you can".
It's just that when I started picking Python last time, I found / was
often told that I was "programming Java with Python syntax", that is,
my Python code was not "Pythonic" enough :)
That said, although Lisp allows you to do procedural style programming,
is there a.. how should I say this, a "way" in which Lisp really shines
and gives you all the advantages over other languages? Would that be
about creating DSLs? Does that include a lot of macros? (I haven't read
"On Lisp" since I'm still going through Practical Common Lisp).
It seems that the success stories of Lisp (e.g.: Naughty Dog) is where
Lisp is used in this particular way (that is, to create DSL,
Programming Bottom Up)?
Warm regards,
Ray
nall...@gmail.com
I think this talk by Peter Seibel will definetly be interesting to you
(based on your question):
http://video.google.com/videoplay?docid=448441135356213813
IMHO the best Lisp is functional and "bottom up" (which doesn't
necessarily exclude OO), so I would recommend making a goal to get
through On Lisp.
This paper might be interesting to you as well ("Why Functional
Programming Matters"), but I can't back this one up. I've heard of it
but I haven't read it yet, I'll try to read it tomorrow on my lunch
break:
http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
Lisp's greatest strength/weakness is that you can do anything with it.
Reading PCL or the HyperSpec will help you learn lisp, but it won't
help you learn *what* to write with lisp. I recommend learning as much
as possible about as many different programming paradigms as you can
(especially functional and logic). You can use them all in lisp and
it's important to work on expanding your style because the language is
powerful enough to make you lazy.
good luck, hth
Nick
Ray
nall...@gmail.com wrote:
<snip>
> This paper might be interesting to you as well ("Why Functional
> Programming Matters"), but I can't back this one up. I've heard of it
> but I haven't read it yet, I'll try to read it tomorrow on my lunch
> break:
>
> http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
Regarding functional programming, recently I read an article by this
guy, which I find very enlightening and easy to understand:
http://www.defmacro.org/ramblings/fp.html
Thanks for the info and the links again! :)
Ray
<snip>
Lars Rune Nøstdal
> I was wondering about one thing though. Correct me if I'm wrong, but
> it's entirely possible to write a whole application without doing it
> the OO way, just like it's possible to write C++ programs without
> typing "class" even once, right?
Of course. If you want you can ignore the OO (it's called CLOS) in Common
Lisp and add your own OO-support.
> So these days, what is considered the best practice for developing an
> application in Lisp?
`nallen05' mentioned "bottom up" and I agree. It's fun because you'll
see results at once in real-time while you build, run, test and debug. The
whole process is much faster and thus more fun. Instead of compiling,
waiting and restarting - then bring your application to the same point as
last time to test - you'll be hammering code, run, test and debug
continuously.
Using a background-thread (or other ways of multiplexing events); you can
manipulate a running program without having to interrupt it:
(defmacro with-thread (&body body)
`(sb-thread:make-thread
(lambda ()
,@body)))
(let ((change-me 0)
(app-thread nil))
(defun start ()
(write-line "Starting application..")
(setf app-thread
(with-thread
(loop ;; Application loop.
(format t "`change-me': ~A~%" change-me)
(sleep 1)))))
(defun stop ()
(write-line "Stopping application..")
(sb-thread:terminate-thread app-thread))
(defun (setf change-me) (new-value)
(setf change-me new-value))
(defun change-me ()
change-me))
cl-user> (start)
Starting application..
`change-me': 0
#<sb-thread:thread {A9FD5B9}>
`change-me': 0
`change-me': 0
`change-me': 0
cl-user> (setf (change-me) 1324)
1324
`change-me': 1324
`change-me': 1324
`change-me': 1324
cl-user> (setf (change-me) 4321)
`change-me': 1324
4321
`change-me': 4321
`change-me': 4321
`change-me': 4321
`change-me': 4321
cl-user> (stop)
Stopping application..
nil
(probably not a good example - but ok ..)
This is very cool when it comes to manipulating real-time graphics on the
screen. :)
> Does this affect your analysis & design process in any way?
Yes, very much. For non-trivial things I need to hammer down some code and
tests to determine design anyway. Using Lisp this is much quicker - and
when I'm happy with the design-part Lisp is easy to optimize.
> Or is it still OOAD, and you proceed as you would in, say,
> Java/Python/C++, or it is somewhat different because Lisp can do things
> that those other languages can't?
Lisp has more features than these languages; most of the time you can
do what you please. Pascal Bourguignon explains this in his post.
--
Lars Rune Nøstdal
http://lars.nostdal.org/
Ray
Lars Rune Nøstdal wrote:
<snip>
> > Does this affect your analysis & design process in any way?
>
> Yes, very much. For non-trivial things I need to hammer down some code and
> tests to determine design anyway. Using Lisp this is much quicker - and
> when I'm happy with the design-part Lisp is easy to optimize.
Thanks Lars--that confirms my suspicion--now I can't wait to finish
"practical common lisp" and then move on to "on lisp"! :)
Warm regards,
Ray
<snip>
Rob Thorpe
Whether you use objects or not depends on whether or not the program
task is well modelled by them. Since you aren't force to use them or
force not to you can choose on the basis of need.
Sometimes Lisp programs are little different from procedural programs
in other languages. This is a reasonable way to write a program if the
things it deals with are easily done with the base language.
There is no right way to do it, only ways more suitable to certain
problems.
Ray
Rob Thorpe wrote:
<snip>
> There is no right way to do it, only ways more suitable to certain
> problems.
Yeah... but I came to Lisp from Python, where there's one right way to
do it ;-)
John Thingstad
wrote:
>
> There is no right way to do it, only ways more suitable to certain
> problems.
>
That is a bit vague.
Some people do everything using OOP.
I tend to mix paradigms.
I can give you a few examples.
I want to write a compiler.
Depends .. Sometimes recursive decent.
Sometimes it is simpler to work a syntactic tree.
Remember in Lisp You have closures which can be used for modularity
so you don't have to encapsulate data in classes to prevent it from
becoming global.
A closure is a expression on the form:
(let ((my-var 1))
(defun my-func (my-param)
(setf my-var my-param)
...)
(defun ...)
...)
But procedural.
To me a object corresponds to a real thing.
Car (the vehicle) is a object.
Window is a object.
A singleton is not a object.
For this use a variable.
There is no need to use awkward hacks needed in Smalltalk
to make everything object oriented when perfectly good
ones exist in Lisp. Norwig discusses software patterns and their
use in some detail at www.norvig.com.
Generally a combination of functional programming and OO do the trick.
Functional thinking can be tricky is you are not used to it.
Paul Graham ANSI CL introduces a more functional style.
Note that these are personal opinions.
Try stuff and see what feels the most natural for you.
Finally Lisp programming tends to encourage a bottom up approach rather
than a
top down approach to programming.
So write a class, test a class, paste you tests into the test framework
etc.
then move on to the next. Depending on the program some analysis is needed
of course.
But a more spiral approach to programming tends to develop.
Also there is no main so you can have many program entry points.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Ari Johnson
The Lisp way of programming is knowing that you have a full toolbox,
and using the hammer to pound nails and the screwdriver to turn
screws. Not everything has to look like a nail when you have Lisp.
Joe Marshall
Ray wrote:
> I came to Lisp from Python, where there's one right way to
> do it ;-)
Python: `at *most* one right way to do it'
Lisp: `at *least* one right way to do it'
Pascal Bourguignon
Perl: 'several wrong ways to do it'
C: 'several hard ways to do it wrong'
Basic: 'no way to do it'
etc... ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
nominolo
> Thanks Lars--that confirms my suspicion--now I can't wait to finish
> "practical common lisp" and then move on to "on lisp"! :)
I second the suggestion to read "On Lisp". It certainly helped me a
lot to get a good feeling how to use Lisp to gain best results. Also,
reading other peoples code is very helpful. Lisp code can often be
very readable. This thread has some hints:
<http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/5b166acb740ebd14>
As suggested by others, the interactive, bottom-up way, possibly using
macros to build a DSL for your language, is probably the most "Lispy"
way. Then again, if OOP fits your problem best, just use OOP. Or FRP
(functional reactive programming, e.g. using Cells) or constraint-based
/ logic. So another definition of "Lispy" is: Keep your mind open for
new ideas or paradigms, try to pick the best one for your problem. I'd
also say that trying out other languages may help you write better Lisp
programs--or show you cases where maybe using a different Language
might be even better. (e.g. Haskell or Erlang have features which
are--at least ATM--hard to "embed" in CL.)
Ok, so the bottom line is, read "On Lisp" and keep your mind open. :)
-ts
Benjamin Teuber
Pascal Bourguignon wrote:
> You want OO programming? Lisp has the best OO system (CLOS), but if
> you're not happy with it, there are a lot of other OO systems (like KR
> which is prototype based) and you can write your own.
Does anyone have a link where I can download KR? I'd like to take a
closer look at it, but e.g. the Cliki-Page has a dead asdf-link.
Thanks for any help,
Benjamin
Pascal Bourguignon
It's part of garnet.
http://garnetlisp.sourceforge.net/
--
__Pascal Bourguignon__ http://www.informatimago.com/
Un chat errant
se soulage
dans le jardin d'hiver
Shiki
Ray
nominolo wrote:
> > Thanks Lars--that confirms my suspicion--now I can't wait to finish
> > "practical common lisp" and then move on to "on lisp"! :)
>
> I second the suggestion to read "On Lisp". It certainly helped me a
> lot to get a good feeling how to use Lisp to gain best results. Also,
> reading other peoples code is very helpful. Lisp code can often be
> very readable. This thread has some hints:
>
> <http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/5b166acb740ebd14>
Ah, thank you!! That looks like just what I need.
> As suggested by others, the interactive, bottom-up way, possibly using
> macros to build a DSL for your language, is probably the most "Lispy"
> way. Then again, if OOP fits your problem best, just use OOP. Or FRP
> (functional reactive programming, e.g. using Cells) or constraint-based
> / logic. So another definition of "Lispy" is: Keep your mind open for
> new ideas or paradigms, try to pick the best one for your problem. I'd
> also say that trying out other languages may help you write better Lisp
> programs--or show you cases where maybe using a different Language
> might be even better. (e.g. Haskell or Erlang have features which
> are--at least ATM--hard to "embed" in CL.)
>
> Ok, so the bottom line is, read "On Lisp" and keep your mind open. :)
Got it ;-)
Cheers,
Ray
>
> -ts
Vagif Verdi
It is not the fisrt book for beginner. I would suggest PCL first.
But as a second book it is excellent, and answers your question how to
design programs without OO paradigm.
Also book How To Design Programs: HTDP.org answers the same question.
But is is about scheme.
dus...@gmail.com
Python is known to be rather dogmatic about the one "Python way" to do
things. And that's fine for Python. If it were a government, it would
be utopian socialism. There is one method that works best for everyone,
but you better not try to stray from that path.
On the other hand, Lisp is anarchy. Do whatever you want, especially
things that help you to expand your freedom. Just don't duplicate code
- refactor instead - and don't write code that's mundane - write code
which writes it. If there were to be one, this would be the Lisp way.
Jim Ottaway
> "Benjamin Teuber" <bet...@web.de> writes:
>
>> Does anyone have a link where I can download KR? I'd like to take a
>> closer look at it, but e.g. the Cliki-Page has a dead asdf-link.
>
> It's part of garnet.
> http://garnetlisp.sourceforge.net/
I searched for kr_2.3.4.tar.gz [the version mentioned on the Cliki page]
and found it at various sites, including
http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/distfiles/kr_2.3.4.tar.gz
It appears to be more recent than the version in garnet, most of the
changes are to make it stand alone from garnet.
Regards,
--
Jim Ottaway
Rob Thorpe
> "Benjamin Teuber" <bet...@web.de> writes:
>
> > Hi,
> >
> > Pascal Bourguignon wrote:
> >> You want OO programming? Lisp has the best OO system (CLOS), but if
> >> you're not happy with it, there are a lot of other OO systems (like KR
> >> which is prototype based) and you can write your own.
> >
> > Does anyone have a link where I can download KR? I'd like to take a
> > closer look at it, but e.g. the Cliki-Page has a dead asdf-link.
>
> It's part of garnet.
> http://garnetlisp.sourceforge.net/
Crikey, whenever I look for Lisp GUI systems more start appearing.
Someday I'll have to sit down and figure out which is best for what.
Rob Thorpe
In programming I think there are many situations where there are many
right ways to do things. There are a few places where there is only
one right way, but it's fairly rare. What language you're writing in
makes little difference.
What Pythonistas generally mean by "one right way" is that at quite a
low level in the code, at the level of variables and messages there is
an order to how things should be used. They also mean that to do X
there is a specific library which is most useful. Neither of these
things are really a "one right way" though, even if people think they
are. Code for any programming problem and you'll find at least 3
reasonable approaches both at the high level of design and low levels
of implementation.
Thomas A. Russ
> It's just that when I started picking Python last time, I found / was
> often told that I was "programming Java with Python syntax", that is,
> my Python code was not "Pythonic" enough :)
Well, you will occasionally get the same comment about Lisp.
Although there are multiple pardigms supported, there are various
conventions and styles that are a bit different. One of the main
stylistic differences is that there tends to be a lot more nested
function calls rather than use of variables.
Variables generally (but not always) tend to be bound in LET forms
initially rather than through a lot of SETF expressions. Again, there
are often good reasons to not do it this way, but it is much more common
to see something like this:
(defun f1 ()
(function-8 (function-a 1 2 3)
(function-b #\a "fubar")))
or perhaps this:
(defun f2 ()
(let ((a (function-a 1 2 3))
(b (function-b #\a "fubar")))
(function-8 a b)))
than the following, C- or Java-like code:
(defun f3
(let ((a nil)
(b nil)
(r nil))
(setf a (function-a 1 2 3))
(setf b (function-b #\a "fubar"))
(setf r (function-8 a b))
(return-from f3 r)))
One of the more subtle differences between traditional procedural
languages and Lisp is that in lisp, EVERYTHING is an expression. The
distinction between expressions and statements doesn't exist. Since all
expressions return values [*], this is exploited to avoid introducing a
lot of variables. This generally leads to slightly briefer code, which
is then easier to understand.
There are also some other conventions. One is that functions named with
multiple words use a hyphen ("-") character to separate the parts. A
second is that special variable names start and end with asterisk ("*")
characters. Test functions end in "p" if a single word and "-p" if a
multi-word name. There are some other naming conventions that are less
common, but these are the main ones that I can think of.
One final, but critical style tip:
Don't name your top-level function "main" ;)
[*] Ignore (values) for now. Besides, it actually does return a value
of NIL if a value is needed.
--
Thomas A. Russ, USC/Information Sciences Institute
Ray
Thomas A. Russ wrote:
> > It's just that when I started picking Python last time, I found / was
> > often told that I was "programming Java with Python syntax", that is,
> > my Python code was not "Pythonic" enough :)
>
> Well, you will occasionally get the same comment about Lisp.
>
> Although there are multiple pardigms supported, there are various
> conventions and styles that are a bit different. One of the main
> stylistic differences is that there tends to be a lot more nested
> function calls rather than use of variables.
Thomas, thanks for taking time to write this! I find it informative and
relevant to my question.
> One final, but critical style tip:
> Don't name your top-level function "main" ;)
I won't, promise! ;-)
Cheers
Ray
jos...@corporate-world.lisp.de
Lisp does not force you to do things (though there is some preferences
built
in), but supports you to choose of various styles.
But there are preferences that influence the architectural design
choices.
See the paper by Norvig/Pitman on Good Lisp Programming Style:
http://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf
Just to list some of my preferences:
When possible prefer a simple Functional Programming approach.
Prefer a Symbolic Programming approach (use symbols,
descriptive symbol names, ...).
Don't change variables. Bind them. Avoid side-effects.
For larger code systems use CLOS for the architecture, avoid
structures.
Use an interactive, incremental development style.
Build tools with Lisp to save time.
Follow the usual Lisp traditions before inventing a new one.
Create runnable specifications (DSLs, ...) of your application domain.
Develop tests while you code.
Use late-binding to your advantage.
Avoid macros unless really needed.
>From earlier AI programming their came a lot of influence into Lisp
programming.
One of the typical approaches for so-called AI-based applications
was to determine what kind of programming system would be needed
to express the problem. It was more of a linguistic approach. You
find out what would be the right language to talk about the problem.
A language has syntax, semantics, pragmatics, etc. (many people
now are just focused on the syntax, but that is the easy part). Then
in Lisp you would build machine that runs this language.
Then you would describe the problem in this new higher-level
language and run it. Lisp has some building-blocks for this
approach and a few tools/libraries are available to support
that kind of programming. It is not the simplistic view of DSLs
what you hear nowdays of. It is a deeper approach where you
look into what kind of language you have to develop,
and how you control the complexity of the problem domain.
As an example see the domain where you have to plan
something (how to get hundreds of containers from a ship and
where to store these containers, etc.). The usual 'linguistic' approach
would be to understand the complexity of the planning task,
to implement a planner language and to formulate the specific
problem then in this new plan language.
The book from Norvig (PAIP) explains some of that. There are
other books also...
See here for some inspiration in a very tough domain:
http://www.itasoftware.com/news/pr/siam.php
http://www.demarcken.org/carl/papers/ITA-software-travel-complexity/ITA-software-travel-complexity.pdf
Looks like ITA now is the company with the most Common Lisp programmers.
Ray
jos...@corporate-world.lisp.de wrote:
> Lisp does not force you to do things (though there is some preferences
> built
> in), but supports you to choose of various styles.
>
> But there are preferences that influence the architectural design
> choices.
> See the paper by Norvig/Pitman on Good Lisp Programming Style:
> http://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf
Thanks! I become more and more aware of the advantages of learning Lisp
over learning other languages, the wealth of information available
about it is just incredible!
<snip>
All good stuff, I'm fired up now :) In fact I've started reading On
Lisp in parallel with PCL because you and other kind people in this
group are making me _too_ curious :)
Warm regards,
Ray
Pascal Costanza
> "Ray" <ray_u...@yahoo.com> writes:
>
>> It's just that when I started picking Python last time, I found / was
>> often told that I was "programming Java with Python syntax", that is,
>> my Python code was not "Pythonic" enough :)
>
> Well, you will occasionally get the same comment about Lisp.
>
> Although there are multiple pardigms supported, there are various
> conventions and styles that are a bit different. One of the main
> stylistic differences is that there tends to be a lot more nested
> function calls rather than use of variables.
This is true, but: Most of the conventions and styles for programming in
Lisp are more of an aesthetic and/or superficial nature. For example, it
doesn't really matter a lot whether you name defining macros with
"def...", with-style macros with "with-...", predicates ending in
"...-p", etc. These conventions merely exist for communicating that
common idioms are used.
This is different from conventions in other languages which say more
about the actual design of the program ("don't use global variables",
"don't use goto statements", "don't use side effects", "put everything
in classes", etc.) From a design perspective, you're free to do almost
anything you want in Lisp.
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/
Rainer Joswig
Pascal Costanza <p...@p-cos.net> wrote:
> Thomas A. Russ wrote:
> > "Ray" <ray_u...@yahoo.com> writes:
> >
> >> It's just that when I started picking Python last time, I found / was
> >> often told that I was "programming Java with Python syntax", that is,
> >> my Python code was not "Pythonic" enough :)
> >
> > Well, you will occasionally get the same comment about Lisp.
> >
> > Although there are multiple pardigms supported, there are various
> > conventions and styles that are a bit different. One of the main
> > stylistic differences is that there tends to be a lot more nested
> > function calls rather than use of variables.
>
> This is true, but: Most of the conventions and styles for programming in
> Lisp are more of an aesthetic and/or superficial nature. For example, it
> doesn't really matter a lot whether you name defining macros with
> "def...", with-style macros with "with-...", predicates ending in
> "...-p", etc. These conventions merely exist for communicating that
> common idioms are used.
>
> This is different from conventions in other languages which say more
> about the actual design of the program ("don't use global variables",
> "don't use goto statements", "don't use side effects", "put everything
> in classes", etc.) From a design perspective, you're free to do almost
> anything you want in Lisp.
Yeah, and attitude will create unmaintainable code.
Especially with Lisp you need architecture guidelines
for any 'real' project with more than two guys. Lots
of Lisp software ended up not maintainable because
there was this 'everything is allowed' attitude -
more though since lots of software in Lisp has
experimental character and nevers gets cleaned up
or even refactored.
Typical problem: it gets written and is not portable
to other Lisp environments without a complete
rewrite. 'Production quality' code has guidelines.
If I'd be the architect on a Lisp software project, people
in the team are definitely NOT free to do almost
anything they want. Especially not with Lisp. Lisp
is a 'programmer amplifier'. Which also means that
it amplifies bad designs beyond imagination.
Common Lisp desperately needs architectural conventions
that are written down and communicated. Unfortunately
the only book on that topic (Lisp Style and Design) is
out of print and outdated.
>
>
> Pascal
Raffael Cavallaro
> Common Lisp desperately needs architectural conventions
> that are written down and communicated. Unfortunately
> the only book on that topic (Lisp Style and Design) is out of print and
> outdated.
Norvig and Pitman's paper "Tutorial on Good Lisp Programming Style" is
still available on the net (though it is also more than a decade old):
pwbd...@gmail.com
trouble with, is that the best technique is reserved for its most
applicable use. So for instance, in a language like C++ or Python you
have the capability to use either functions or objects to solve a
particular problem. It's up to the programmer to decide which is more
useful for solving a problem. Lisp takes that mentality a few steps
further by offering first class functions, runtime generated functions,
generic functions, macros, metaprogramming, etc. The thing with lisp
is that there's almost too many ways to solve the same problem so it
becomes not an issue of HOW to solve the problem but what is the most
efficient way to solve a problem, either in terms of code space,
runtime efficiency, or whatever. When I programmed alot of CL I found
I spent more time figuring out exactly how to balance those factors
(runtime performance vs code density) than actually how to solve the
problem at all. That's why I switched to Python/Pyrex/Psyco. Now I
love lisp as a concept language, but I think CL is almost over kill for
alot of things because of the reasons I stated above. Python
subscribes to a mentality of having one good way to solve any problem,
and I think CL totally missed the boat on that one. Perhaps a future
lisp dialect will simplify things a great deal without sacrificing the
multi-faceted capabilities inherent to lisp style programming. Or
perhaps I'm just talking out of myass, i'm drunk and it's 2am. ;P
Pascal Costanza
I don't see a contradiction here. You can have "local" guidelines that
fit the requirements of your project.
Wade Humeniuk
> runtime efficiency, or whatever. When I programmed alot of CL I found
> I spent more time figuring out exactly how to balance those factors
> (runtime performance vs code density) than actually how to solve the
> problem at all. That's why I switched to Python/Pyrex/Psyco. Now I
> love lisp as a concept language, but I think CL is almost over kill for
> alot of things because of the reasons I stated above. Python
> subscribes to a mentality of having one good way to solve any problem,
> and I think CL totally missed the boat on that one.
That's an interesting assertion. This would imply that ....
1) Code written by different two different Python programmers would
look almost identical.
and an even stronger assertion ...
2) That since there exists one good way of solving a problem, then
a program can be written that can write the program that solves the
problem.
Obviously these two assertions are wrong.
It is wrong because there is no such thing as solving a problem in
computer programming. There is such a thing as writing a program
which is decent enough so that human beings can adapt their behaviour
to its operations. I would say that most programmers write programs that
allow them to adapt their own individual thinking to a problem. Maybe
this is what Python is good at. But in the bigger picture programs
will be more successful when they are able to expressible in the
domain language of the experts (who are not programmers).
I understand and can relate to your experiences with CL, but ....
there is always a but.
Wade
Pascal Bourguignon
> [...] Python
> subscribes to a mentality of having one good way to solve any problem,
> and I think CL totally missed the boat on that one. Perhaps a future
> lisp dialect will simplify things a great deal without sacrificing the
> multi-faceted capabilities inherent to lisp style programming. Or
> perhaps I'm just talking out of myass, i'm drunk and it's 2am. ;P
It's always a good idea to mention it. ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
Ken Tilton
pwbd...@gmail.com wrote:
> What lisp teaches you, which is what I think people have the most
> trouble with, is that the best technique is reserved for its most
> applicable use. So for instance, in a language like C++ or Python you
> have the capability to use either functions or objects to solve a
> particular problem. It's up to the programmer to decide which is more
> useful for solving a problem. Lisp takes that mentality a few steps
> further by offering first class functions, runtime generated functions,
> generic functions, macros, metaprogramming, etc. The thing with lisp
> is that there's almost too many ways to solve the same problem so it
> becomes not an issue of HOW to solve the problem but what is the most
> efficient way to solve a problem, either in terms of code space,
> runtime efficiency, or whatever. When I programmed alot of CL I found
> I spent more time figuring out exactly how to balance those factors
> (runtime performance vs code density) than actually how to solve the
> problem at all.
Some argued for slavery on the grounds that the slaves would not be able
to handle freedom. I thought that daft until now.
> That's why I switched to Python/Pyrex/Psyco. Now I
> love lisp as a concept language, but I think CL is almost over kill for
> alot of things because of the reasons I stated above.
Your panic attacks in the face of choice?
> Python
> subscribes to a mentality of having one good way to solve any problem,
Here is where your brilliant argument against a big toolset falls on its
face: Python does /not/ have one good way to solve every problem. Safely
enslaved, your panic attacks ameliorated, you confuse limitations for
completeness.
> and I think CL totally missed the boat on that one.
No, CL trusted you to differentiate the wide array of tools such that,
when confronted with a programming problem, you would think of only one
tool to use (more accurately, reach for it without thinking).
> Perhaps a future
> lisp dialect will simplify things a great deal without sacrificing the
> multi-faceted capabilities inherent to lisp style programming. Or
> perhaps I'm just talking out of myass, i'm drunk and it's 2am. ;P
Right. It makes no sense to say it is a problem that there three ways to
do something. The folks who cannot tell those three ways apart do not
have a problem, they just pick one and go if they really have work to
do. I think you are making the whole thing up. :)
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
Rob Thorpe
> What lisp teaches you, which is what I think people have the most
> trouble with, is that the best technique is reserved for its most
> applicable use. So for instance, in a language like C++ or Python you
> have the capability to use either functions or objects to solve a
> particular problem. It's up to the programmer to decide which is more
> useful for solving a problem. Lisp takes that mentality a few steps
> further by offering first class functions, runtime generated functions,
> generic functions, macros, metaprogramming, etc. The thing with lisp
> is that there's almost too many ways to solve the same problem so it
> becomes not an issue of HOW to solve the problem but what is the most
> efficient way to solve a problem, either in terms of code space,
> runtime efficiency, or whatever. When I programmed alot of CL I found
> I spent more time figuring out exactly how to balance those factors
> (runtime performance vs code density) than actually how to solve the
> problem at all.
You can't really have too much choice. Some people though are
bewildered by choice and spend too long managing it. After you've
programmed a little while you learn to avoid this.
One useful approach is to program in a high-level language using its
basic procedural programming features until you find something needing
more. Another is to program using it's basic procedural + OO features
until you need more. Sometimes though it is useful to design in use of
advanced features from the beginning.
Not programming at 2am after a few drinks helps in this too.
Pascal Costanza
> pwbd...@gmail.com wrote:
>> What lisp teaches you, which is what I think people have the most
>> trouble with, is that the best technique is reserved for its most
>> applicable use. So for instance, in a language like C++ or Python you
>> have the capability to use either functions or objects to solve a
>> particular problem. It's up to the programmer to decide which is more
>> useful for solving a problem. Lisp takes that mentality a few steps
>> further by offering first class functions, runtime generated functions,
>> generic functions, macros, metaprogramming, etc. The thing with lisp
>> is that there's almost too many ways to solve the same problem so it
>> becomes not an issue of HOW to solve the problem but what is the most
>> efficient way to solve a problem, either in terms of code space,
>> runtime efficiency, or whatever. When I programmed alot of CL I found
>> I spent more time figuring out exactly how to balance those factors
>> (runtime performance vs code density) than actually how to solve the
>> problem at all.
>
> You can't really have too much choice.
You _always_ have too much choice. Even when programming in Python,
there is always the option to stop using Python and choose a different
language.
> Some people though are
> bewildered by choice and spend too long managing it. After you've
> programmed a little while you learn to avoid this.
...and limiting yourself to one (restricted) language is just one
strategy in this regard.