Hi all,
We have a series of talks at work, and I want to try to introduce the
Java heathens to the virtues of the REPL, using BeanShell
(http://www.beanshell.org). I already have one great example of how
useful REPLs can be, from the Deep Space 1 mission ("Debugging a program
running on a $100M piece of hardware that is 100 million miles away is an
interesting experience. Having a read-eval-print loop running on the
spacecraft proved invaluable in finding and fixing the problem.").
I was wondering if anyone could point me toward any other sources of
similar stories I could use in my talk, to convince people how useful
REPLs are?
Best wishes,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
William Bland <·······@abstractnonsense.com> wrote in message news:<······························@abstractnonsense.com>...
> I was wondering if anyone could point me toward any other sources of
> similar stories I could use in my talk, to convince people how useful
> REPLs are?
Say you're writing a calculator for research in a scientific
field--tensor calculus, or number theory, or group theory. Then you
really need a REPL. Even if you can program up elaborate examples in
test files, the first thing a researcher says is, "Now just let me
recompute that with 1.7 replacing 1.6 ..."
A classic example in a CS course is symbolic differentiation. What
fun is that without a REPL?
On Wed, 09 Jun 2004 13:31:04 -0700, Mark McConnell wrote:
> William Bland <·······@abstractnonsense.com> wrote in message news:<······························@abstractnonsense.com>...
>> I was wondering if anyone could point me toward any other sources of
>> similar stories I could use in my talk, to convince people how useful
>> REPLs are?
>
> Say you're writing a calculator for research in a scientific
> field--tensor calculus, or number theory, or group theory. Then you
> really need a REPL. Even if you can program up elaborate examples in
> test files, the first thing a researcher says is, "Now just let me
> recompute that with 1.7 replacing 1.6 ..."
>
> A classic example in a CS course is symbolic differentiation. What
> fun is that without a REPL?
Thanks for the example, but there's no way I'm going to use it in my talk.
Having a PhD in pure mathematics, and being a lover of "strange" languages
like Lisp already makes people here think of me as the odd academic
who doesn't understand anything about real world problems. I need
examples that will dispel those kinds of opinions, not encourage them!
Thanks all the same though!
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
In article <······························@abstractnonsense.com>,
William Bland <·······@abstractnonsense.com> wrote:
> On Wed, 09 Jun 2004 13:31:04 -0700, Mark McConnell wrote:
>
> > William Bland <·······@abstractnonsense.com> wrote in message
> > news:<······························@abstractnonsense.com>...
> >> I was wondering if anyone could point me toward any other sources of
> >> similar stories I could use in my talk, to convince people how useful
> >> REPLs are?
> >
> > Say you're writing a calculator for research in a scientific
> > field--tensor calculus, or number theory, or group theory. Then you
> > really need a REPL. Even if you can program up elaborate examples in
> > test files, the first thing a researcher says is, "Now just let me
> > recompute that with 1.7 replacing 1.6 ..."
> >
> > A classic example in a CS course is symbolic differentiation. What
> > fun is that without a REPL?
>
> Thanks for the example, but there's no way I'm going to use it in my talk.
> Having a PhD in pure mathematics, and being a lover of "strange" languages
> like Lisp already makes people here think of me as the odd academic
> who doesn't understand anything about real world problems. I need
> examples that will dispel those kinds of opinions, not encourage them!
Does space count as "real world"? Does the vxWorks shell count as a
REPL? On the Remote Agent Experiment on the DS1 mission in 1999 we were
able to use a Lisp REPL to debug and fix a deadlock brought about by a
race condition on a spacecraft in flight. Without a REPL this would
have required a reboot.
E.
On Wed, 09 Jun 2004 14:30:18 -0700, Erann Gat wrote:
>> > A classic example in a CS course is symbolic differentiation. What
>> > fun is that without a REPL?
>>
>> Thanks for the example, but there's no way I'm going to use it in my talk.
>> Having a PhD in pure mathematics, and being a lover of "strange" languages
>> like Lisp already makes people here think of me as the odd academic
>> who doesn't understand anything about real world problems. I need
>> examples that will dispel those kinds of opinions, not encourage them!
>
> Does space count as "real world"? Does the vxWorks shell count as a
> REPL? On the Remote Agent Experiment on the DS1 mission in 1999 we were
> able to use a Lisp REPL to debug and fix a deadlock brought about by a
> race condition on a spacecraft in flight. Without a REPL this would
> have required a reboot.
>
> E.
Yes it does - this story is what inspired me to give a talk in the first
place (see the start of the thread). One of the people I work with is
about as much of a hardcore Java fan as you could wish to meet, and seems
to disapprove of all the ideas I'm trying to bring in from the Lisp
world. But he has a weak spot: He loves anything connected to
spaceflight even more than he loves Java. I figure the DS-1 story will be
a great hook for him.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
William Bland <·······@abstractnonsense.com> writes:
> place (see the start of the thread). One of the people I work with is
> about as much of a hardcore Java fan as you could wish to meet, and seems
> to disapprove of all the ideas I'm trying to bring in from the Lisp
> world. But he has a weak spot: He loves anything connected to
> spaceflight even more than he loves Java. I figure the DS-1 story will be
Let him watch some of Spacecraft Films' DVD sets:
http://www.spacecraftfilms.com
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
William Bland wrote:
> Having a PhD in pure mathematics, and being a lover of "strange" languages
> like Lisp already makes people here think of me as the odd academic
> who doesn't understand anything about real world problems. I need
> examples that will dispel those kinds of opinions, not encourage them!
One nice thing is being able to backtrace and then use the REPL to
analyze application data structures. With other Lisp code, not by
tediously following pointers in a typical interactive debugger. One can
even toss off an ad hoc diagnostic and then have it run around the
application data reporting back what it finds.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On Wed, 09 Jun 2004 22:47:24 +0000, Kenny Tilton wrote:
> William Bland wrote:
>> Having a PhD in pure mathematics, and being a lover of "strange" languages
>> like Lisp already makes people here think of me as the odd academic
>> who doesn't understand anything about real world problems. I need
>> examples that will dispel those kinds of opinions, not encourage them!
>
> One nice thing is being able to backtrace and then use the REPL to
> analyze application data structures. With other Lisp code, not by
> tediously following pointers in a typical interactive debugger. One can
> even toss off an ad hoc diagnostic and then have it run around the
> application data reporting back what it finds.
>
> kenny
Ooh, pretty! I know at least one person on my team who hates debuggers
and would be very impressed to be able to just type in some code that
follows references and collects all the data he wants to see. Nice! Thanks.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
William Bland <·······@abstractnonsense.com> writes:
> On Wed, 09 Jun 2004 22:47:24 +0000, Kenny Tilton wrote:
>> William Bland wrote:
>>> Having a PhD in pure mathematics, and being a lover of "strange" languages
>>> like Lisp already makes people here think of me as the odd academic
>>> who doesn't understand anything about real world problems. I need
>>> examples that will dispel those kinds of opinions, not encourage them!
>>
>> One nice thing is being able to backtrace and then use the REPL to
>> analyze application data structures. With other Lisp code, not by
>> tediously following pointers in a typical interactive debugger. One can
>> even toss off an ad hoc diagnostic and then have it run around the
>> application data reporting back what it finds.
>>
>> kenny
>
> Ooh, pretty! I know at least one person on my team who hates debuggers
> and would be very impressed to be able to just type in some code that
> follows references and collects all the data he wants to see. Nice! Thanks.
So, not only is Lisp the "Programmable Programming Language",
it is also the "Programmable Debugger".
Another advantage with a REPL is that it gives you a mechanism
for doing incremental changes and testing as you go. The data you have
so far used is still available; it is your choice whether you want to
throw it away or not. In the case where you want to work on data that
takes a long time to set up, this is invaluable.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Raymond Wiker <·············@fast.no> writes:
> Another advantage with a REPL is that it gives you a mechanism
> for doing incremental changes and testing as you go.
Many people, particularly students and beginners, think of the debugger
REPL as a `bad state' and immediately abort to top level. The
debugger is not only a powerful way to find errors; it is a powerful
development environment. The dynamic state of the process is `frozen'
where the error occurred, so new code written at the debugger REPL can
be tested in situ.
I often use an incremental develop-within-the-debugger technique.
After you whip off a first cut at the program, immediately
attempt to run the code. Don't bother looking for the typos,
etc. you'll find them soon enough. Of course your code will fail.
But rather than aborting, fixing, recompiling, and restarting, just
patch the mistake, recompile that one function, and use the debugger
to restart where you left off.
As you proceed through the code fixing bugs along the way, you can see
whether the flow of control is matching your expectations and whether
the flow of data is sufficient (if function FOO needs structure BAR
but the caller doesn't pass it as an argument, that's not sufficient).
When you are done with that one example, *now* go back and look at
your code. You know at this point that at least one path through the
code is correct (the one you forced through) and it should be one of
the main paths unless you tried running with bogus data. So when you
re-examine the functions, you have in the immediate vicinity code that
is known to work. It is much easier to find bugs by comparing new
code to known working code than it is to just stare at untested code.
----
Here's an anecdote I heard once about Minsky. He was showing a
student how to use ITS to write a program. ITS was an unusual
operating system in that the `shell' was the DDT debugger. You ran
programs by loading them into memory and jumping to the entry point.
But you can also just start writing assembly code directly into memory
from the DDT prompt. Minsky started with the null program.
Obviously, it needs an entry point, so he defined a label for that.
He then told the debugger to jump to that label. This immediately
raised an error of there being no code at the jump target. So he
wrote a few lines of code and restarted the jump instruction. This
time it succeeded and the first few instructions were executed. When
the debugger again halted, he looked at the register contents and
wrote a few more lines. Again proceeding from where he left off he
watched the program run the few more instructions. He developed the
entire program by `debugging' the null program.
William Bland <·······@abstractnonsense.com> writes:
> I was wondering if anyone could point me toward any other sources of
> similar stories I could use in my talk, to convince people how useful
> REPLs are?
Check Paul Graham's papers on ViaWeb->Yahoo! Store. They fixed bugs
while the customers was still at the phone.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
On Wed, 09 Jun 2004 18:31:29 +0200, Paolo Amoroso wrote:
> Check Paul Graham's papers on ViaWeb->Yahoo! Store. They fixed bugs
> while the customers was still at the phone.
>
>
> Paolo
Perfect - thanks!
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
Hmm, I just got a funny idea.
It should be possible to make a connection to an irc-server from the
repl. You could join #Lisp or +Lisp and do some chatting while you are
at work :)
The messages from the chatroom could be caught by a listener and get
saved into a global var.
I don't know if it is possible, but at the moment I think it should work!
Andr�
--
William Bland wrote:
> Hi all,
> We have a series of talks at work, and I want to try to introduce the
> Java heathens to the virtues of the REPL, using BeanShell
> (http://www.beanshell.org). I already have one great example of how
> useful REPLs can be, from the Deep Space 1 mission ("Debugging a program
> running on a $100M piece of hardware that is 100 million miles away is an
> interesting experience. Having a read-eval-print loop running on the
> spacecraft proved invaluable in finding and fixing the problem.").
>
> I was wondering if anyone could point me toward any other sources of
> similar stories I could use in my talk, to convince people how useful
> REPLs are?
You could make up an example in which you "patch" a running Java
application by loading a new class from the REPL. Then you could sketch
a more advanced scenario in which the HotSwap feature of Java is used
that allows you to replace methods at run time (and a few things more in
JDK 1.5).
As a final step you could show them the same thing in Common Lisp, but
this probably will blow their heads. ;)
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
On Wed, 09 Jun 2004 23:54:57 +0200, Pascal Costanza wrote:
> As a final step you could show them the same thing in Common Lisp, but
> this probably will blow their heads. ;)
>
You know, I would have thought it would work that way too, but about a
month ago I showed a few of them CMUCL running in SLIME. Defined a
recursive function, with sleeps and enough output printed to the screen to
show what it was doing. Disassembled it ("Look! Can Java do that?!").
Ran it, interrupted it, redefined the function, restarted it... and the
old function called the newly defined one, and it just kept on running.
My head was pretty much blown off when I discovered all this was possible,
but the people I work with pretty much said "why would you ever want to do
that?"
That's why I've decided I need to introduce Lisp more slowly, starting
with a Java REPL.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
In article <······························@abstractnonsense.com>,
William Bland <·······@abstractnonsense.com> wrote:
> On Wed, 09 Jun 2004 23:54:57 +0200, Pascal Costanza wrote:
> > As a final step you could show them the same thing in Common Lisp, but
> > this probably will blow their heads. ;)
> >
>
> You know, I would have thought it would work that way too, but about a
> month ago I showed a few of them CMUCL running in SLIME. Defined a
> recursive function, with sleeps and enough output printed to the screen to
> show what it was doing. Disassembled it ("Look! Can Java do that?!").
> Ran it, interrupted it, redefined the function, restarted it... and the
> old function called the newly defined one, and it just kept on running.
>
> My head was pretty much blown off when I discovered all this was possible,
> but the people I work with pretty much said "why would you ever want to do
> that?"
>
> That's why I've decided I need to introduce Lisp more slowly, starting
> with a Java REPL.
>
> Cheers,
> Bill.
One thing that's unique to Lisp is the "presentation
based Lisp listener". One example is the Listener
of McCLIM:
http://userpages.umbc.edu/~hefner1/listener.png
Or you can see the Dynamic Lisp Listener in action.
I have made a few Quicktime movies (with audio comment) demonstrating
a fair bit of it. Contact me if you need a link
to them...
William Bland wrote:
> I was wondering if anyone could point me toward any other sources of
> similar stories I could use in my talk, to convince people how useful
> REPLs are?
...another story Mario Mommer has told us at the cl-lc meetings is that
he lets CL perform simulations that may take quite a long time, and in
order to see whether the program is heading towards the right direction
he just interrupts it from the REPL, writes out the data to a file and
visualizes them with gnuplot. If everything is fine, he just continues
the calculation, or else he tries to fix it and then moves on.
The cool thing is that you get this all almost for free, without the
need to prepare the program in any significant way.
Pascal
P.S.: I hope I have gotten the details right...
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
On Thu, 10 Jun 2004 02:56:07 +0200, Pascal Costanza wrote:
>
>
> William Bland wrote:
>
>> I was wondering if anyone could point me toward any other sources of
>> similar stories I could use in my talk, to convince people how useful
>> REPLs are?
>
> ...another story Mario Mommer has told us at the cl-lc meetings is that
> he lets CL perform simulations that may take quite a long time, and in
> order to see whether the program is heading towards the right direction
> he just interrupts it from the REPL, writes out the data to a file and
> visualizes them with gnuplot. If everything is fine, he just continues
> the calculation, or else he tries to fix it and then moves on.
>
> The cool thing is that you get this all almost for free, without the
> need to prepare the program in any significant way.
Actually some of our processes are just like this. They run for a long
time, and if you don't get the initial conditions right, they don't run
well. Being able to determine how well they are running, and actually
nudge them on the fly could be a big win for us.
Thanks for the idea.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
Pascal Costanza <········@web.de> writes:
> William Bland wrote:
>
>> I was wondering if anyone could point me toward any other sources of
>> similar stories I could use in my talk, to convince people how useful
>> REPLs are?
>
> ...another story Mario Mommer has told us at the cl-lc meetings is
> that he lets CL perform simulations that may take quite a long time,
> and in order to see whether the program is heading towards the right
> direction he just interrupts it from the REPL, writes out the data to
> a file and visualizes them with gnuplot. If everything is fine, he
> just continues the calculation, or else he tries to fix it and then
> moves on.
More than debugging processes which run for a long time (they actually
wouldn't if I would let them run in peace :-) ), what I often do is to
investigate the progress of the computation to understand better what
is going on in detail. I use a pipe to gnuplot with a cl interface, so
it feels like working inside a gnuplot with a sane syntax and my code
loaded. Sometimes I even change parameters and let the computations
continue (mathematically very dubious, but as an experimental tool it
is not bad). I find that I get a lot of good ideas by really watching
the gears turn, so to speak.
Another thing one can do with this is to test new functions with
realistic data that appears in the middle of a computation. This is
possible without a REPL, but it is so much nicer with it.
> The cool thing is that you get this all almost for free, without the
> need to prepare the program in any significant way.
Indeed.
* William Bland wrote:
> I was wondering if anyone could point me toward any other sources of
> similar stories I could use in my talk, to convince people how useful
> REPLs are?
I've always thought that the best, and most blindingly obvious,
example of where REPLS are useful is ... computers. It is so obvious
that perhaps it's hard to think of, but imagine a trying to look after
a machine which worked on a `compile and go' basis: you'd spend an age
building an OS image, load it onto the machine and hit the boot
switch. It would fail horribly, and then you'd spend lots more time
debugging it and finally start again. Each cycle would take hours.
if the machine was nearly working, but not quite - for instance if the
wrong version of some application was installed - you'd rebuild the
world from scratch. This is so horrible that quite soon interactive
debuggers would appear, which would allow you to investigate problems
and, later, interactively patch the system by loading new components.
Machines would also start to have the tools to build the OS and its
various components on the machine itself, and usable from this fancy
interactive debugger, or shell. Eventually it would be only very rare
that the machine would need to be rebuilt from cold. So rare in fact
that it would become a common problem that people were unable to do
this.
A related, but more specific example of where REPLs are useful is boot
monitors. Recovering Suns that won't boot is enormously more pleasant
recovering typical x86 boxes, because they have a powerful boot
monitor which allows you to poke around the system in considerable
detail, finding disk and network devices, setting parameters and so
on. x86 machines tend to have special-purpose menu-driven things,
which are often less featureful and almost inevitably not usable
without direct access to the screen and keyboard. So we have all these
awful KVM things which let you run x86 boxes remotely. (x86 pre-boot
environments are getting better though, especially on blade-type
machines where it's crucial to have remote access.)
--tim