I've just finished reading Hackers and Painters and have been dabbling
with Lisp a bit, mainly using the Scheme LispMe implementation on Palm.
I have over 20 years development experience, the latter half mainly OO
design and implementing in C++, Python and REALbasic (don't snicker if
you don't know the language).
I have a pretty good understanding of OO design and patterns and in
particular, years of GUI app development have left me with a keen
appreciation of how multiple dispatch improves design.
I've also played with Forth and have a naturally compositional or
"language-building" approach to design.
I understand enough Lisp to see why it is particularly powerful at
examples like Graham cites in H&P p195 - writing a program that
generates accumulators.
However, I'm struggling to understand WHY you would want to write that
kind of code?
Can someone please explain, or point me to references, that clarify this?
What kind of problem is this style of programming particularly good for?
Is it something that I could use to solve a range of programming
problems or only in a particular domain?
I'm searching for that magic example to trigger the "aha" experience I
keep hearing about :-)
TIA
--
Andy Dent BSc MACS AACM http://www.oofile.com.au/
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability
From: Will Hartung
Subject: Re: Why want to do the things Lisp is best at?
Date:
Message-ID: <2ohftpFaqohtU1@uni-berlin.de>
"Andy Dent" <····@oofile.com.au> wrote in message
·······························@news.highway1.com.au...
> What kind of problem is this style of programming particularly good for?
> Is it something that I could use to solve a range of programming
> problems or only in a particular domain?
>
> I'm searching for that magic example to trigger the "aha" experience I
> keep hearing about :-)
You need to write any reasonble size program, and you'll find your own "aha"
moments.
The aha moments will happen someplace you don't expect, either within the
instant turn around, through a cheap macro that saves a boat load of
boilerplate, or simply using a closure in the right place.
The true "aha" nature of CL is when you start writing your application with
the application structures itself (you usually won't actually realize you're
doing this until later).
For example, with something like Java (C, C++, etc), you end up ALWAYS
writing Java (or XML, or whatever). You're always using Java structures,
Java syntax, etc. Your level of abstraction is inherently limited by the
nature of the language.
In CL, your level of abstraction is essentially unlimited. When you build
your code base up to the point that you think solely in the applications
structures and no longer worry about CL's, then all of a sudden you got your
very own little world that can be manipulated at a very high level.
When you realize that everything you add to the environment becomes,
essentially, a first class citizen, you know you're working with CL as an
equal, and not as a dependent. Pretty much whenever CL turns on you and
aggravates you, you have the capability to beat it back into submission to
the point where the earlier aggravation simply no longer exists. Some
aggravations take more beating than others, but the capability is mostly
there.
While there are rules in CL, it's basically a big game of Nomic. You can
change most of the rules.
The problem with giving examples of Aha moments is that, like Grahams, they
basically look contrived and you wonder "how is this applicable". But when
you actually USE CL, these moments come and blind side you where you don't
expect them. Even if they do something identical to what Graham did, now the
moment is actually useful for you application, and all of a sudden it seems
much less contrived. That's when you go "Aha!".
Regards,
Will Hartung
(·····@msoft.com)
>>>>> "Will" == Will Hartung <·····@msoft.com> writes:
Will> "Andy Dent" <····@oofile.com.au> wrote in message
Will> ·······························@news.highway1.com.au...
>> What kind of problem is this style of programming particularly good
>> for? Is it something that I could use to solve a range of
>> programming problems or only in a particular domain?
>>
>> I'm searching for that magic example to trigger the "aha" experience
>> I keep hearing about :-)
Will> You need to write any reasonble size program, and you'll find
Will> your own "aha" moments.
Will> The aha moments will happen someplace you don't expect, either
Will> within the instant turn around, through a cheap macro that saves
Will> a boat load of boilerplate, or simply using a closure in the
Will> right place.
I couldn't agree more. I had my own "aha" moment when I was implementing
GUI dialogs and menus and realized, first, that having first-class
functions lets you implement callbacks really easily, and second, that
closures often allow you to have no callback functions at all!
Think of a little context-sensitive pop-up menu that appears when you
press your right mouse button. When you implement that in Java or C/C++,
you normally have a function that gets called when something is chosen
from the menu. It quickly becomes a large, ugly switch statement, and
you have to worry about managing your application state and passing
context data, because the generation of the context-sensitive menu is
separated from the callbacks tied to menu choices.
Well, using Lisp you can keep all the complexity in one place, by
generating the menu with callbacks already in place, implemented as
closures, using the context available at the time when the menu is
generated. There is no separate callback or dispatching function at all!
I find this produces very clean, readable code, and is very difficult to
do in languages that do not have closures.
--J.
From: Greg Menke
Subject: Re: Why want to do the things Lisp is best at?
Date:
Message-ID: <m3vffg79cz.fsf@europa.pienet>
Andy Dent <····@oofile.com.au> writes:
>
> I understand enough Lisp to see why it is particularly powerful at
> examples like Graham cites in H&P p195 - writing a program that
> generates accumulators.
>
> However, I'm struggling to understand WHY you would want to write that
> kind of code?
>
> Can someone please explain, or point me to references, that clarify this?
>
> What kind of problem is this style of programming particularly good for?
> Is it something that I could use to solve a range of programming
> problems or only in a particular domain?
>
> I'm searching for that magic example to trigger the "aha" experience I
> keep hearing about :-)
My aha moment occurred when I realized I wasn't having to drag a pile
of infrastructure along behind me as I wrote code. The application
was a little puzzle solver.
The puzzle was as folows; on a plane, drop some number of lines at
random slopes and Y intercepts. Then find the number of closed shapes
of 3, 4, 5, etc.. sides. My dad thinks he has a formula to yield the
approximate counts as a function of the # of lines. I used Lisp to
brute-force the solution for up to a few hundred lines. I have some
preliminary results to check w/ him, but he's not dug out his data.
The aha moment arrived when I was able to do the simple grade-school
arithmetic on slopes & intersections without having to constrain
magnitudes so they would fit in 32 bit int types or be concerned about
loss of precision in floats. One really nice thing about Lisp in this
case is the run-time arithmetic will start out with machine register
size integers, which then get promoted to bigger types when the
magnitudes require it- so you only pay the performance cost when the
application requires it and not before. While this is a slightly
exotic application compared to the usual shoveling around of database
records, not having to obsess over data types will pay off in all
sorts of applications- its really nice to simply not have to care.
So I guess my answer would be, one aha moment may be when you realize
how much extra work you've been doing so far that you simply don't
have to do in Lisp. I think nothing less than sitting down for a few
months to really start getting the hang of it will really address the
question however. Lisp can feel really clumsy at first, so keep
trying- it will start making sense pretty quickly.
Gregm
On Wed, 18 Aug 2004, Greg Menke wrote:
> Andy Dent <····@oofile.com.au> writes:
>>
>> I understand enough Lisp to see why it is particularly powerful at
>> examples like Graham cites in H&P p195 - writing a program that
>> generates accumulators.
>>
>> However, I'm struggling to understand WHY you would want to write that
>> kind of code?
>>
>> Can someone please explain, or point me to references, that clarify this?
>>
>> What kind of problem is this style of programming particularly good for?
>> Is it something that I could use to solve a range of programming
>> problems or only in a particular domain?
>>
>> I'm searching for that magic example to trigger the "aha" experience I
>> keep hearing about :-)
>
> My aha moment occurred when I realized I wasn't having to drag a pile
> of infrastructure along behind me as I wrote code. The application
> was a little puzzle solver.
>
> The puzzle was as folows; on a plane, drop some number of lines at
> random slopes and Y intercepts. Then find the number of closed shapes
> of 3, 4, 5, etc.. sides. My dad thinks he has a formula to yield the
> approximate counts as a function of the # of lines. I used Lisp to
> brute-force the solution for up to a few hundred lines. I have some
> preliminary results to check w/ him, but he's not dug out his data.
Daniel A. Klain and Gian-Carlo Rota's book "Introduction to Geometric
Probability" treats of such problems.
http://www.ams.org/bull/2000-37-02/S0273-0979-99-00860-5/S0273-0979-99-00860-5.pdf
oo--JS.
Andy Dent <····@oofile.com.au> writes:
> However, I'm struggling to understand WHY you would want to write that
> kind of code?
For example, one reason we left assembler and started to program to
high level languages such as Modula-2, is that you have ten to twenty
less statements to write to implement a given program.
Well, I find consistently that I get lisp programs that are ten to
twenty smaller than equivalent C or Modula-2 programs.
(Or see Greenspun's Tenth Law).
> What kind of problem is this style of programming particularly good for?
All.
> Is it something that I could use to solve a range of programming
> problems or only in a particular domain?
It's a general purpose language, you can use it to solve the whole
range of _programming_ problems.
--
__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.
From: Peter Seibel
Subject: Re: Why want to do the things Lisp is best at?
Date:
Message-ID: <m33c2kxxhe.fsf@javamonkey.com>
Andy Dent <····@oofile.com.au> writes:
> I'm searching for that magic example to trigger the "aha" experience
> I keep hearing about :-)
Well, no guarantees that this'll give you the aha! moment, but it is
intended for folks like you, so you might want to check out the book
I'm working on. Draft chapters are up on the web at:
<http://www.gigamonkeys.com/book/>
I'd be interested in any feedback you can give me about how this is or
is not helpful as far as helping you to your aha! moment.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Andy Dent wrote:
> I'm searching for that magic example to trigger the "aha" experience I
> keep hearing about :-)
Here's one, which is a lesser-known feature of lisp you likely haven't
heard of.
Most languages optimize 2+2 into 4. But they don't optimize your
personally defined vector_add():
vector_add([1 1 1], foo(a), [1 1 1])
Even though it could have been transformed during compiletime into:
vector_add([2 2 2], foo(a))
Well, lisp can ask your advice on how to do just that. There are
"compiler macros" which you can define, that can take a look at the
parameters to a function at compiletime and figure out how to
transform them into a better-performing runtime form. Along with
performance, a big win is readability -- you can write pristine code,
and stuff complexity into a compiler macro which takes care of special
cases.
http://alu.cliki.net/lisp-user-meeting-amsterdam-april-2004#compiler-macro
So I think the lesson here is lisp opens up places so programmers can
get on with programming. These compiler macros are a lesser-known
feature of lisp, so you don't have to learn it, but it's a powerful
way to let one interact in the midst of the system.
Lisp is about maximizing programmability. It took on an unusual syntax
just for the benefit of operating on code with one's well-trained
data-handling muscles. Instead of trying to look like an average
American high-schooler's notation, making it awkward to program one's
programming language. That's the most visually striking feature; there
are others.
Relatively safe clean power; many debugging/antibugging tools are
built in, so you don't have to depend on an IDE to provide them.
> I understand enough Lisp to see why it is particularly powerful at
> examples like Graham cites in H&P p195 - writing a program that
> generates accumulators.
>
> However, I'm struggling to understand WHY you would want to write that
> kind of code?
An expression's meaning is decided within a particular "environment,"
or place. x+2's meaning depends on where you are in the program,
because x means different things in different places. So his example
is a cute one which demonstrates the programmer's control of what
things mean. It happens to be an important foundation on which to
build on.
I remember thinking, "So what?" when I saw his example too. But it's
useful to wrap code up in a little globe and pass it around. While
keeping that meaning intact.
> I've just finished reading Hackers and Painters and have been dabbling
> with Lisp a bit, mainly using the Scheme LispMe implementation on Palm.
I was bitten hard by believing Scheme was anything like lisp, when I
started using Common Lisp. Greatly different languages despite having
surface similarities; just as people shouldn't confuse all braces 'n
semicolon languages as being very similar.
> What kind of problem is this style of programming particularly good for?
> Is it something that I could use to solve a range of programming
> problems or only in a particular domain?
It's a multiparadigm language. It's not like Scheme, which has bias
towards functional programming. So lisp has pretty recursion, but also
has this one monster of iteration called "loop." You can even define
your own iteration constructs too, instead of waiting for some guy to
add a new kind of loop into the language.
Do you wish to build a state machine into your language, so the
machinery doesn't show? Use a new paradigm harmoniously with the rest
of your language?
MfG,
Tayssir
--
Video, audio, and other lispish odds & ends:
http://alu.cliki.net/AudioVideo
> I understand enough Lisp to see why it is particularly powerful at
> examples like Graham cites in H&P p195 - writing a program that
> generates accumulators.
>
> However, I'm struggling to understand WHY you would want to write that
> kind of code?
>
> Can someone please explain, or point me to references, that clarify this?
Once people have a tool at their disposal and in their mental toolbox
they tend to use them rather often. Even if you don't know now what
the tool is good for - you will know it once you have it.
What are razorblades(the real ones, no gillete stuff) good for? How
could you ever want to go to a drugstore and buy them? Well, I do now
work at an research institute and every second laboratory has
razorblades laying around. They are now at may disposal and in my
mental toolbox too. I use them almost daily now.
Your brain is constantly forming reality into some shape you can
handle with youre mental toolbox. It is pretty good at it.
Norman
"Andy Dent" <····@oofile.com.au> schrieb im Newsbeitrag
·······························@news.highway1.com.au...
> I've just finished reading Hackers and Painters and have been dabbling
> with Lisp a bit, mainly using the Scheme LispMe implementation on Palm.
>
> I have over 20 years development experience, the latter half mainly OO
> design and implementing in C++, Python and REALbasic (don't snicker if
> you don't know the language).
>
> I have a pretty good understanding of OO design and patterns and in
> particular, years of GUI app development have left me with a keen
> appreciation of how multiple dispatch improves design.
>
> I've also played with Forth and have a naturally compositional or
> "language-building" approach to design.
>
> I understand enough Lisp to see why it is particularly powerful at
> examples like Graham cites in H&P p195 - writing a program that
> generates accumulators.
>
> However, I'm struggling to understand WHY you would want to write that
> kind of code?
>
> Can someone please explain, or point me to references, that clarify this?
>
> What kind of problem is this style of programming particularly good for?
> Is it something that I could use to solve a range of programming
> problems or only in a particular domain?
>
> I'm searching for that magic example to trigger the "aha" experience I
> keep hearing about :-)
>
> TIA
>
> --
> Andy Dent BSc MACS AACM http://www.oofile.com.au/
> OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
> PP2MFC - PowerPlant->MFC portability
I think the problem is, you need a good knowledge and some experience to
have the aha effect. After 25 years of programming in a lot of languages I
had to learn lisp. This very hard work for me. Not comparable to learning
any other language. Now I see the following points:
Lisp is extremly abstract. This leads to very short programs. On the other
hand I feel I am less concerned about the machine and I am always close to
the essence of underlying algorithms. Before using Lisp I often got stuck
and had to start over. This doesn't happen anymore to me. Some tiny changes
and everything behaves quite different. Because the code is so abstract it
can be more commonly used. When used to Lisp, code is very easy to read. If
code is short, bugs are easier to find and fix. I think, better abstraction
leads to shorter code, which is easierer to maintain, easier to extend and
also more reliable.
At the moment I work on database programs and do not experience any special
lisp performance problems.
Andreas