Here are a few things that triggered major Aha! moments for me, in no
particular order.
- reading the source of cl-ppcre, which illustrated
- run-time compilation (to chains of closures) without using
COMPILE or COMPILE-FILE
- parsing regular expression strings, with nice error-reporting
via conditions
- that Lisp solutions to practical problems can be concise,
comprehensible, and *fast*
- reading Keene's CLOS book
- finding an application of continuable errors; it replaced a
convoluted scheme of checking return values at multiple levels
with a simple handler-bind wrapper.
- realizing that file formats and communication protocols are just
bits on disk or on a wire or sometimes even in memory, and Lisp
is pretty good at generating the right bits and octets; inspired
by (among other stuff):
- learning that CLX is a Lisp program, not a binding to the C xlib
- learning that Marc's CL-PDF is a Lisp program
- learning about Frode's binary-types
- reading Peter's chapters on parsing binary files
- reading Will Hartung's "Guerilla Lisp Opus"
- realizing that most Common Lisp implementations are mostly
written in Common Lisp
A few themes:
- Despite conceptually understanding how tools like CLOS and
closures and conditions work, it took a tricky problem solved
neatly by the tool to really make an Aha! moment
- Aha! moments have made complicated tasks simpler and
unapproachable tasks approachable (given the right amount of time
and effort). They take the magic out of things. (Philip Greenspun
used to say that his course would teach undergrads how to build
Amazon in a semester; despite the hyperbole, it really did take
the mystery out of how useful web applications can be
constructed.)
Advice:
- Be actively curious about how interesting things work ("how can
cl-ppcre be faster than Perl?")
- Be broadly aware of the tools available, and don't worry about
immediate application
- Don't settle for tedium (it's hard to have a breakthrough if you
have resigned yourself to something that feels substandard)
- People who write one interesting thing usually keep it up; find
and watch interesting people (trickle-down Aha! effect?)
Minor delights:
- format tricks (~v and ~{~^~} specifically)
- inspecting a GF object in slime
What are some of the things that triggered your own Aha! moments? What
sort of stuff delighted you when you discovered it? What advice would
you give people who want to have more Aha! moments?
Zach
Zach Beane <····@xach.com> writes:
> Here are a few things that triggered major Aha! moments for me, in no
> particular order.
Oops, I forgot one:
- seeing the output of DISASSEMBLE for the first time (it was on a
native-compiling Lisp), and the realization that the
functionality is part of standard CL
Zach
Zach Beane wrote:
> Zach Beane <····@xach.com> writes:
>
> > Here are a few things that triggered major Aha! moments for me, in no
> > particular order.
>
> Oops, I forgot one:
>
> - seeing the output of DISASSEMBLE for the first time (it was on a
> native-compiling Lisp), and the realization that the
> functionality is part of standard CL
>
> Zach
That got me into lisp actually... few months ago. Downloaded the
allegro trial, got a book from a colleague (The Winston & Horn one),
put some samples, and one of the first things I did was ... compile,
then optimizations, and that bought me. Too bad my daily job is C/C++
coding (game development).
Zach Beane wrote:
> What are some of the things that triggered your own Aha! moments? What
> sort of stuff delighted you when you discovered it? What advice would
> you give people who want to have more Aha! moments?
I guess "code is data" is the most basic lisp aha! But its implications
continue to be sources for many more such aha moments.
For instance, in most other programming languages, new abstractions are
built by writing code on /top/ of existing abstractions. But in lisp,
its possible to build new abstractions by writing code *beneath*
existing code.
Here's an example (in scheme):
(define (square x) (* x x))
(define (power x n)
(cond ((= n 0) 1)
((odd? n) (* x (power x (- n 1))))
(else (square (power x (/ n 2))))))
This is a simple function which raises x to the integer power n, with a
minimum number of multiplications. (let ((x 5)) (power x 3)) returns
125.
Now its possible to make the same piece of code return optimized
symbolic output by just writing a new implementation of '*' !
(power 'x 3) -> (* x (* x x))
See the original article by Darius Bacon for the details:
http://cybertiggyr.com/gene/peval/peval.cgi
[sreeram;]
On 27 Sep 2006 17:12:44 -0400, Zach Beane <····@xach.com> wrote:
>
> [snip]
>
> - inspecting a GF object in slime
>
> What are some of the things that triggered your own Aha! moments? What
> sort of stuff delighted you when you discovered it? What advice would
> you give people who want to have more Aha! moments?
- macros of course, in particular, writing a DSL for defining
GUI menu hierarchies
- learning what generic functions are and what you can do
with them in CLOS (e.g. the different kinds of specializers)
- the MOP (and every MOP-related thread in this newsgroup is
making me aware that I'm still hanging onto preconceived
notions about OOP)
- incremental programming with SLIME
--
Jack Unrue
Jack Unrue wrote:
> [ . . . ]
>
> - incremental programming with SLIME
I don't quite follow, Jack. Would you care to expand a little, or point me
to a URL ?
On Thu, 28 Sep 2006 21:16:34 +1200, <······@example.com> wrote:
> Jack Unrue wrote:
>
>> [ . . . ]
>>
>> - incremental programming with SLIME
>
> I don't quite follow, Jack. Would you care to expand a little, or point me
> to a URL ?
Then you've never used slime, it's pretty self-evident.
<goes back to ignoring trolls>
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
Well, :Slime 2005-04-27 is there in my usual Emacs setup - I just don't
actively or consciously use it. C-h m shows reports no mode specifics. C-h
a slime lists very many slime commands. What Swank is I have no idea.
GP lisper wrote:
> Then you've never used slime, it's pretty self-evident.
> <goes back to ignoring trolls>
Your logic doesn't quite follow.
Slime is a superior interaction mode, yet it doesn't show up as a mode.
How Slime helps with "incremental programming" thus remains a mystery.
No Aha! moment for me then.
Adam <······@example.com> writes:
> Slime is a superior interaction mode, yet it doesn't show up as a mode.
> How Slime helps with "incremental programming" thus remains a mystery.
Start your Lisp and then
(asdf:operate 'asdf:load-op :swank)
(swank:create-swank-server 4005)
Then do M-x slime-connect from emacs. Open up a source file. Modify a
function and type C-c C-c and the new version is compiled into your
enviroment.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Thanks, Petter. I'll try some things out, as I appear to be under-using its
potential, it does seem.
Looking at;
http://www.cliki.net/SLIME Features
and quickly into;
http://common-lisp.net/project/slime/doc/html/
I wouldn't say Slime's operation is very transparent, intuitive or
easily-grasped, but then I'm just clicking code into a Lisp application,
and evaluating from there. I'm not developing any multipart application.
Oh, and yes, my bad. C-h m does pop up with plenty of Slime commands,
several only of which I'm regularly using.
> Then do M-x slime-connect from emacs. Open up a source file. Modify a
> function and type C-c C-c and the new version is compiled into your
> enviroment.
>
> Petter
Maybe the Aha moment is, that "incremental programming" is inserting
newly-compiled chunks into a running Lisp environment.
Thanks again, Petter.
On Fri, 29 Sep 2006 01:29:35 +1200, Adam <······@example.com> wrote:
>
> Maybe the Aha moment is, that "incremental programming" is inserting
> newly-compiled chunks into a running Lisp environment.
Adam,
Yep, that's what I meant -- my Aha! moment here was finding out how
much easier slime makes that style of work. The same is possible
with a bare REPL, but a lot less convenient.
--
Jack Unrue
Adam <······@example.com> writes:
> I wouldn't say Slime's operation is very transparent, intuitive or
> easily-grasped, but then I'm just clicking code into a Lisp
> application, and evaluating from there.
(with-shamless-plug
http://common-lisp.net/movies/slime.mov )
watch a bit of that and you'll see some of the stuff SLIME can really
do. (warning: big file, long movie)
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Marco Baringer wrote:
> http://common-lisp.net/movies/slime.mov
> watch a bit of that and you'll see some of the stuff SLIME can really
> do. (warning: big file, long movie)
Yep, thanks Marco. I've seen that referred to repeatedly. I really must get
a copy somehow - have been putting it off on dialup, but will do !
Aha.
Adam <······@example.com> writes:
> Well, :Slime 2005-04-27 is there in my usual Emacs setup - I just don't
> actively or consciously use it. C-h m shows reports no mode specifics. C-h
> a slime lists very many slime commands. What Swank is I have no idea.
>
> GP lisper wrote:
>> Then you've never used slime, it's pretty self-evident.
>> <goes back to ignoring trolls>
>
> Your logic doesn't quite follow.
>
> Slime is a superior interaction mode, yet it doesn't show up as a mode.
> How Slime helps with "incremental programming" thus remains a mystery.
>
> No Aha! moment for me then.
>
Try typing M-x slime
that will give you an aha moment!
Tim
--
tcross (at) rapttech dot com dot au
Adam <······@example.com> writes:
> Jack Unrue wrote:
>
> > [ . . . ]
> >
> > - incremental programming with SLIME
>
> I don't quite follow, Jack. Would you care to expand a little, or point me
> to a URL ?
Slime itself wasn't an aha! moment for me, but ILISP was. The basic
revelations for me were that the Lisp system I was interacting with
didn't follow the usual cycle of edit, compile+run, test, debug,
restart; instead, it was something that had a long life and that
accumulated state (in the form of functions and objects), and that
gently modifying the state was better than trashing all of it and
reloading it from scratch. This isn't something specific SLIME, but
SLIME enables it in a very nice way.
(The other nice features like arglist display, inline annotation of
compilation notes, the inspector and debugger, etc are great too.)
When I first started using Linux, I accidentally unpacked a nethack
tarball in the /dev directory. I had no idea how to see what I had
done or how to fix the resulting clutter. So I just reinstalled the
system from scratch to get back to a known state. (I would also
reinstall when my IP address changed, because I only knew that an
installation dialog box prompted for the IP.) This is the same sort of
wholesale flushing of state that just isn't necessary if you know how
to interrogate your evolving, active system and update it to bring it
into the state you need.
I haven't used CLOS's object evolution protocol yet
(i.e. update-instance-for-redefined-class, make-instances-obsolete),
but the fact that the object system accomodates evolution of state
without throwing out progress so far is very encouraging.
Zach
Zach Beane ha escrito:
> I haven't used CLOS's object evolution protocol yet
> (i.e. update-instance-for-redefined-class, make-instances-obsolete),
> but the fact that the object system accomodates evolution of state
> without throwing out progress so far is very encouraging.
Any point on how to do it?
And another question too: how to redefine generic functions in a living
environment to change, for example, the number of arguments, supposing
that you have already defined methods to that generic function?
"Javier" <·······@gmail.com> writes:
> And another question too: how to redefine generic functions in a living
> environment to change, for example, the number of arguments, supposing
> that you have already defined methods to that generic function?
(fmakunbound 'generic-function-name)
Bill Atkins wrote:
> "Javier" <·······@gmail.com> writes:
>
>> And another question too: how to redefine generic functions in a living
>> environment to change, for example, the number of arguments, supposing
>> that you have already defined methods to that generic function?
>
> (fmakunbound 'generic-function-name)
A simple defgeneric will actually also do. However, when you change the
lambda list, you will also lose the methods defined on the generic function.
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/
Pascal Costanza <··@p-cos.net> writes:
> Bill Atkins wrote:
> > "Javier" <·······@gmail.com> writes:
> >
> >> And another question too: how to redefine generic functions in a living
> >> environment to change, for example, the number of arguments, supposing
> >> that you have already defined methods to that generic function?
> > (fmakunbound 'generic-function-name)
>
> A simple defgeneric will actually also do. However, when you change
> the lambda list, you will also lose the methods defined on the generic
> function.
This will signal an error if the methods with incongruent lambda lists
were defined with DEFMETHOD rather than by the previous DEFGENERIC.
Zach
Pascal Costanza <··@p-cos.net> wrote:
> Bill Atkins wrote:
>> "Javier" <·······@gmail.com> writes:
>>
>>> And another question too: how to redefine generic functions in a living
>>> environment to change, for example, the number of arguments, supposing
>>> that you have already defined methods to that generic function?
>>
>> (fmakunbound 'generic-function-name)
>
> A simple defgeneric will actually also do.
No it won't, except in the special case of all methods on the generic
function having been defined using :METHOD in a previous DEFGENERIC.
: If a defgeneric form is evaluated and some methods for that generic
: function have lambda lists that are not congruent with that given in
: the defgeneric form, an error is signaled.
--
Juho Snellman
Juho Snellman wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>> Bill Atkins wrote:
>>> "Javier" <·······@gmail.com> writes:
>>>
>>>> And another question too: how to redefine generic functions in a living
>>>> environment to change, for example, the number of arguments, supposing
>>>> that you have already defined methods to that generic function?
>>> (fmakunbound 'generic-function-name)
>> A simple defgeneric will actually also do.
>
> No it won't, except in the special case of all methods on the generic
> function having been defined using :METHOD in a previous DEFGENERIC.
>
> : If a defgeneric form is evaluated and some methods for that generic
> : function have lambda lists that are not congruent with that given in
> : the defgeneric form, an error is signaled.
Ah right. I just confused this with the fact that in most
implementations, this is a correctable error.
Thanks for the correction.
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/
Zach Beane wrote:
> Adam <······@example.com> writes:
>
> > Jack Unrue wrote:
>
> Slime itself wasn't an aha! moment for me, but ILISP was. The basic
> revelations for me were that the Lisp system I was interacting with
> didn't follow the usual cycle of edit, compile+run, test, debug,
> restart; instead, it was something that had a long life and that
> accumulated state (in the form of functions and objects), and that
> gently modifying the state was better than trashing all of it and
> reloading it from scratch. This isn't something specific SLIME, but
> SLIME enables it in a very nice way.
That is the coolest part of lisp -- but once in a while I find myself
after a whole day of hacking wanting to make sure something will work
on another machine, and end up restarting lisp (and loading everything
afresh) to make sure of that (as it could be some old definition or
binding lying around in the environment). Is there an easier way than
restarting lisp to do this? One very crude thing might be to blow the
symbol table away?
Thanks.
"remixer" <········@gmail.com> writes:
> That is the coolest part of lisp -- but once in a while I find myself
> after a whole day of hacking wanting to make sure something will work
> on another machine, and end up restarting lisp (and loading everything
> afresh) to make sure of that (as it could be some old definition or
> binding lying around in the environment). Is there an easier way than
> restarting lisp to do this? One very crude thing might be to blow the
> symbol table away?
I tend to have Emacs save any unsaved buffers, start a fresh Lisp, and
use asdf to load the system from scratch. Then I patch up any problems
that crop up in the running Lisp.
Sometimes I do "scratch" development; I have a small experimental
project that is contained in one file, with a defpackage/in-package at
the top followed by the code. At the REPL I work entirely within the
package. When I want to clean things out, I delete-package the package
and reload the file.
Zach
Zach Beane wrote:
> Adam <······@example.com> writes:
>
> > Jack Unrue wrote:
>
> Slime itself wasn't an aha! moment for me, but ILISP was. The basic
> revelations for me were that the Lisp system I was interacting with
> didn't follow the usual cycle of edit, compile+run, test, debug,
> restart; instead, it was something that had a long life and that
> accumulated state (in the form of functions and objects), and that
> gently modifying the state was better than trashing all of it and
> reloading it from scratch. This isn't something specific SLIME, but
> SLIME enables it in a very nice way.
That is the coolest part of lisp -- but once in a while I find myself
after a whole day of hacking wanting to make sure something will work
on another machine, and end up restarting lisp (and loading everything
afresh) to make sure of that (as it could be some old definition or
binding lying around in the environment). Is there an easier way than
restarting lisp to do this? One very crude thing might be to blow the
symbol table away?
Thanks.
On 27 Sep 2006 17:12:44 -0400, <····@xach.com> wrote:
> Here are a few things that triggered major Aha! moments for me, in no
> particular order.
>
> - reading Keene's CLOS book
For 20 years, I've successfully avoided OOP, halfway thru Keene, I
lusted for CLOS. The next program is the CLOS teaching tool.
> - realizing that file formats and communication protocols are just
> bits on disk or on a wire or sometimes even in memory, and Lisp
> is pretty good at generating the right bits and octets; inspired
STREAMS! It's all streams, and lisp rocks at that. In-line filters
and transforms of the 'data-stream', branching and colalescing,
sources and sinks.
> - Aha! moments have made complicated tasks simpler and
> unapproachable tasks approachable (given the right amount of time
> and effort). They take the magic out of things. (Philip Greenspun
s/magic/fear/
s/things/improbables/
> - Be broadly aware of the tools available, and don't worry about
> immediate application
The tough one. It's too easy to code up a solution to a problem, you
don't think about distributing the answer, since other lispers can
code as solution just as fast.
> What advice would you give people who want to have more Aha!
> moments?
Write more lisp!
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper <········@CloudDancer.com> writes:
> > - Be broadly aware of the tools available, and don't worry about
> > immediate application
>
> The tough one. It's too easy to code up a solution to a problem, you
> don't think about distributing the answer, since other lispers can
> code as solution just as fast.
By this I mean being aware, even superficially, of built-in things
like CLOS and its standard protocols, conditions, bit-twiddling
functions, format, etc. When the need for a tool arises in the future,
it's good that it can tickle your memory ("isn't there something in
Lisp related to this?") instead of seeming like a frustrating
roadblock.
Zach
Zach Beane <····@xach.com> wrote:
+---------------
| - learning that CLX is a Lisp program, not a binding to the C xlib
+---------------
Learning that Eric Marsden's "PG" talks the PostgreSQL socket
protocol directly, and is not a binding to "libpq.so".
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Zach Beane <····@xach.com> wrote:
> +---------------
> | - learning that CLX is a Lisp program, not a binding to the C xlib
> +---------------
>
> Learning that Eric Marsden's "PG" talks the PostgreSQL socket
> protocol directly, and is not a binding to "libpq.so".
Yes! New examples keep coming to my mind, too. Two in particular are
Franz's NFS server for Windows and their FTP server. When I first saw
them, I couldn't imagine that people might write that sort of software
from scratch with Lisp.
Zach
CL series were an Aha! moment for me. I had studied GPU-based
algorithms for a little bit and knew about Brook and Cg and
"stream-based computation" but, once again, CL had done it years before
:) (The whole "on-line" vs. "off-line" series thing is a pretty good
encoding of how languages like Brook express their kernels.)
mfh
Zach Beane wrote:
> What are some of the things that triggered your own Aha! moments? What
> sort of stuff delighted you when you discovered it? What advice would
> you give people who want to have more Aha! moments?
"The other" meaning of object orientation I found in Lisp, as in
<http://www.nhplace.com/kent/PS/Name.html>
Several moments about read-time, compile-time and run-time, and what
can be done at the different times.
I was delighted about getting to be my own language designer through
macros. Even if I don't come up with stuff I like all that often, I
still think it's a delightful process. :)
Thomas
My over 30 years with Lisp have been one continuous Aha insight. Each
new function a finely tuned concept. And macros -- Ah sweet mystery of
abstraction! - capture the infinitely more sensuous discovery of
entire new ways of thought! Even debugging often leads me to deeper
understanding; facets reflect facets reflect facets -- a recursive maze
of perfectly ground mirrors that when set aright prismatically undress
the deep nature of the problem domain, and of Lisp itself, before the
mind's eye.
········@gmail.com writes:
> My over 30 years with Lisp have been one continuous Aha insight. Each
> new function a finely tuned concept. And macros -- Ah sweet mystery of
> abstraction! - capture the infinitely more sensuous discovery of
> entire new ways of thought! Even debugging often leads me to deeper
> understanding; facets reflect facets reflect facets -- a recursive maze
> of perfectly ground mirrors that when set aright prismatically undress
> the deep nature of the problem domain, and of Lisp itself, before the
> mind's eye.
Nicely put. Who's writing the next book about/on/for Lisp? I vote for
this paragraph to be part of the Preface or some chapter heading.
Congrats!
Frank
Zach Beane wrote:
> What are some of the things that triggered your own Aha! moments? What
> sort of stuff delighted you when you discovered it? What advice would
> you give people who want to have more Aha! moments?
My initial encounter with lisp was through a capital/article in
hofstadters metamagical themas, after which i promptly started writing
an email to a friend of mine, in which i tried to cramp as many
parenthesis as possible. I didn't program at the time and was mainly
fascinated with those parens which neatly closed off one meaning from
the other.
A few years back i started dabbling in a few sub-par programming
languages, searching for one that stuck. I came across some emacs code.
I tried to make sense out of it, but to no avail. It was the first time
that i was absolutely sure that i could finally scratch a programming
language off my to learn list. Ridiculous language.
Then, a year and a few months ago, i stumbled upon lisp again, and i
got an aha moment, which was at the same time an aha erlebnis. Those
sweet parens soothed the mind and burned it at the same time. No or {
or = or . or -> or * or order of evaluation that snoops the mind from
processor power and focus. I'm a simple person,with simple needs. I
like my programming language straight and smooth, like Beyonce likes
her hair. Later of course you learn about all these wicked toys like
macros and clos. It blows your mind and all, but underneath it all it's
that kind of weird satisfying calmness that comes over me when i
securely lock up yet another statement in a closing paren. For my
atheist mind it's the closest i ever came to what i guess should be a
mystic experience. (hmm... one gets into some assumption problems in
that last sentence.)
"Ties Stuij" <·······@gmail.com> writes:
> Then, a year and a few months ago, i stumbled upon lisp again, and i
> got an aha moment, which was at the same time an aha erlebnis. Those
> sweet parens soothed the mind and burned it at the same time. No or {
> or = or . or -> or * or order of evaluation that snoops the mind from
> processor power and focus. I'm a simple person,with simple needs. I
> like my programming language straight and smooth, like Beyonce likes
> her hair. Later of course you learn about all these wicked toys like
> macros and clos. It blows your mind and all, but underneath it all it's
> that kind of weird satisfying calmness that comes over me when i
> securely lock up yet another statement in a closing paren. For my
> atheist mind it's the closest i ever came to what i guess should be a
> mystic experience. (hmm... one gets into some assumption problems in
> that last sentence.)
http://infogroep.be/GodWroteInLisp
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pour moi, la grande question n'a jamais �t�: �Qui suis-je? O� vais-je?�
comme l'a formul� si adroitement notre ami Pascal, mais plut�t:
�Comment vais-je m'en tirer?� -- Jean Yanne
Zach Beane wrote:
> What are some of the things that triggered your own Aha! moments? What
> sort of stuff delighted you when you discovered it?
Well, I am only a newbie, so these are beginner aha!s on the lispy
foothills, but for the record:
(i) Doing symbolic differentiation and hence Newton's method in SICP.
(ii) Realising that I understood call/cc well enough to write python-style
generator functions was pretty cool. When I realized that I could use
macros to replace all that code with nice defgenerator and yield statements
I think I might have had one of those moments. Oooh, power!
(iii) The recent s-expressions/sweet-expressions spat was one, because I
realised that I actually *prefer*
(defun factorial (n)
(if (<= n 1)
1
(* n (factorial (- n 1)))))
to
defun factorial (n)
if (n <= 1)
1
n * factorial(n - 1)
A month ago it would have been the other way round.
(iv) A conversation in the pub the other day with a Ruby-speaking friend:
I speak Python and he speaks Ruby. After a long debate we'd pretty much
agreed that Python and Ruby are just different syntaxes for the same
things, and so I got on to evangelising Scheme, and he already knew what
call/cc did, because Ruby has it, and we wondered if maybe that makes it
better than Python for web stuff? And of course a bit of a web search
reveals many brave efforts to add call/cc to Python.
And so now I have independent evidence for the often repeated assertion that
the widely-used languages are converging back to lisp.
c->c++->java->python->ruby->........->lisp?
John.
--
Contractor in Cambridge UK -- http://www.aspden.com
John Lawrence Aspden <····@surname.com> writes:
> (i) Doing symbolic differentiation and hence Newton's method in SICP.
From what I've heard, this is why Lisp was created. So yeah, that was
THE "aha!" moment from which all others sprang.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Zach Beane <····@xach.com> writes:
> Here are a few things that triggered major Aha! moments for me, in no
> particular order.
>
[...]
> What are some of the things that triggered your own Aha! moments? What
> sort of stuff delighted you when you discovered it? What advice would
> you give people who want to have more Aha! moments?
One for me was Peter Seibel's compiler for a simple machine shown here:
http://groups.google.com/group/comp.lang.lisp/msg/2108939e399c5c4e.
In particular, realising that you could write a handful of primitives
and then use regular CL macros to bootstrap the rest of the language off
those was a big "Aha!" for me.
Cheers,
Mark
--
Mark Triggs
<···@dishevelled.net>
Zach Beane <····@xach.com> writes:
> - reading Will Hartung's "Guerilla Lisp Opus"
A few people have had trouble finding this. Here's the link:
····························@newssvr14.news.prodigy.com
http://groups.google.com/group/comp.lang.lisp/msg/86cf454beb8a42f9
Zach
Zach Beane <····@xach.com> writes:
> What are some of the things that triggered your own Aha! moments? What
> sort of stuff delighted you when you discovered it? What advice would
> you give people who want to have more Aha! moments?
SERIES
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Zach Beane wrote:
>
> What are some of the things that triggered your own Aha! moments? What
> sort of stuff delighted you when you discovered it? What advice would
> you give people who want to have more Aha! moments?
>
> Zach
Recently I was chasing a quite difficult bug, and realised I could add
(breaks) to
functions and recompile on the spot while I was in the debugger. Having
come from
the C++ mindset of "set this breakpoint here, that one there"..it was
bit of an
aha! Now I realise why CL debuggers don't set breakpoints. This was
closely
followed by the realisation of the sheer handiness of the inspector,
enabling me to figure out the difference between a lisp-2 and lisp-1
just by eyeball. Also, discovering kill-sexp..
Routine stuff for a seasoned Lisper, but mindblowing from someone
coming from
C++ land. I felt like some crusty old 16th century accountant who has
just been shown
how this newfangled "zero" thing makes it easier to compute compound
interest, and
has just got it...
"JohnFredCee" <·····@yagc.ndo.co.uk> writes:
> Recently I was chasing a quite difficult bug, and realised I could add
> (breaks) to
> functions and recompile on the spot while I was in the debugger. Having
> come from
> the C++ mindset of "set this breakpoint here, that one there"..it was
> bit of an
> aha!
What do you mean by this?
> Now I realise why CL debuggers don't set breakpoints.
But they do.
Bill Atkins wrote:
> "JohnFredCee" <·····@yagc.ndo.co.uk> writes:
>
> > Recently I was chasing a quite difficult bug, and realised I could add
> > (breaks) to
> > functions and recompile on the spot while I was in the debugger. Having
> > come from
> > the C++ mindset of "set this breakpoint here, that one there"..it was
> > bit of an
> > aha!
>
> What do you mean by this?
I expected setting breakpoints to be a function of the debugger,
not the language. Inserting asm{ "int 3" }'s into C++ and
recompiling and running would be a very tedious way of
debugging misfiring control flow.
With Lisp+SLIME, it's viable, as recompile of your function is
avaliable very quickly with a couple of keystrokes. I imagine it's
the same for other IDE's.
>
> > Now I realise why CL debuggers don't set breakpoints.
>
> But they do.
But they don't *have* to, when you can compile in (break) into
interesting functions at any time. I imagine the debugger is there
to add to the raw (break)..
"JohnFredCee" <·····@yagc.ndo.co.uk> writes:
> Bill Atkins wrote:
>
>> "JohnFredCee" <·····@yagc.ndo.co.uk> writes:
>>
>> > Recently I was chasing a quite difficult bug, and realised I could add
>> > (breaks) to
>> > functions and recompile on the spot while I was in the debugger. Having
>> > come from
>> > the C++ mindset of "set this breakpoint here, that one there"..it was
>> > bit of an
>> > aha!
>>
>> What do you mean by this?
>
> I expected setting breakpoints to be a function of the debugger,
> not the language. Inserting asm{ "int 3" }'s into C++ and
> recompiling and running would be a very tedious way of
> debugging misfiring control flow.
>
> With Lisp+SLIME, it's viable, as recompile of your function is
> avaliable very quickly with a couple of keystrokes. I imagine it's
> the same for other IDE's.
Ah, got it.
Zach wrote:
> What are some of the things that triggered your own Aha! moments? What
> sort of stuff delighted you when you discovered it? What advice would
> you give people who want to have more Aha! moments?
Hi,
Apologies for raking up a slightly old thread but this only happened a
few weeks ago and qualifies as my first "Aha moment".
I'd been learning Common Lisp for a couple of months but had done very
little beyond the tutorial code in text books.
Unrelated to this, I was to present a workshop titled "How compilers
and interpreters work" to a group of bright but inexperienced
developers in my company. As showing working code generally proves more
stimulating than a bunch of slides plundering material from the Dragon
book I wanted to build a truly minimal stack machine with a tiny
language. I'd spent some spare hours writing a C++ version and had an
interpreter up and running. The problem was that while the interpreter
was simple, the code increasingly was not, running to about 800 lines
of templates and object graphs often doing little more than
circumventing the type system.
With 4 days to go I made the seemingly absurd decision that I could do
it better in Common Lisp. Despite my inexperience with the language and
armed with just the CLHS, Practical Common Lisp and the archives of
this group, I managed to replace the 800 lines of convoluted C++ with
about 200 lines of simple (not necessarily good) Lisp code.
The presentation went very well. I didn't concentrate too much on
showing the actual code as it wasn't the main point of the presentation
but it piqued the interest of the audience and importantly for me, my
program didn't let me down.
Phil