Query About Lisp Use
Wayd Wolf
It's been a number of years since I came across some old Lisp books at a
library book sale and only recently began checking back into it to see if I
could make something out of learning it. Corman's stuff looks interesting to
start with.
Anyhow, I was wondering if any of you could give a quick purely opinion
response, preferrably a professionally experienced one, on the following:
1. Where do you see Lisp as being put to best advantage in IT?
2. If you know of Ruby as well, how do you see it in comparison for areas of
application?
3. What do you see as the best path to get on for a career using Lisp to a
major extent, that is, what industry would it be best applied in?
Just some of the questions going through my head of late. Back to
studying...
-Wayd Wolf
Janos Blazi
the mistery case of the *waylaid wolf*.
J.B.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Eric Moss
> Anyhow, I was wondering if any of you could give a quick purely opinion
> response
can do ;)
> 1. Where do you see Lisp as being put to best advantage in IT?
Anywhere that doesn't directly depend on intimate coupling with
processor architecture (e.g. low-resource situations where bit-twiddling
is de rigeur).
> 2. If you know of Ruby as well, how do you see it in comparison for areas of
> application?
Practically every new language I have seen is a partial implementation
of lisp, but without the ability to cleanly mix paradigms. They tend to
do one thing quite nicely, but at the expense of most or all other
areas. One example is Perl, which I think is OK for regex scripting
work, but hell for any large projects. Another is Java, which implements
one limited OO protocol and has GC, but no macros. ML does neat
functional things but has inconsistent syntax and forces the user to
spend inordinate amounts of time dedicated to defining types. Pick just
about any "modern" language and I think you would find the same thing.
> 3. What do you see as the best path to get on for a career using Lisp to a
> major extent, that is, what industry would it be best applied in?
Learn a specific area of science or finance or whatever, and use lisp as
a tool in that area. If, for example, you know lisp really well but
don't know chemistry, you have less chance of being hired than a chemist
that can muddle along in <some language>.
Eric
Coby Beck
"Wayd Wolf" <waydwolf@hot(spam)mail.com> wrote in message
news:ZPQv7.21389$tp1.2...@news1.wwck1.ri.home.com...
> All,
> It's been a number of years since I came across some old Lisp books at a
> library book sale and only recently began checking back into it to see if I
> could make something out of learning it. Corman's stuff looks interesting to
> start with.
> Anyhow, I was wondering if any of you could give a quick purely opinion
> response, preferrably a professionally experienced one, on the following:
>
> 1. Where do you see Lisp as being put to best advantage in IT?
>
-In any area where the problem space is complex. eg where you need objects
with complicated behaviour; where you need to build alot of high level
abstractions.
-In areas where you are forging new ground and the work is very "exploratory"
eg NOT just reinventing wheels, like 90% of programming is.
-In areas well suited to artificial intelligence technologies.
>
> 3. What do you see as the best path to get on for a career using Lisp to a
> major extent, that is, what industry would it be best applied in?
>
I would study Artificial Intelligence and keep all the doors as open as
possible. I have managed to have a career using lisp but only by being ready
to move (Vancouver Canada to Sydney Australia to Tampa Florida...almost to
California, Italy, Arizona, Guatemala City(!) along the way) and being open to
learning anything that came my way (airline industry crew scheduling rules and
policy, the science of modeling how humans make choices, how to administer
First Aid, data parsing abstractions)
The point is, lisp jobs are there but few and far between. You'll have to
chase them. But at the same time, lisp programmers are few and far between,
employers have to do some chasing of their own...
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
Erik Naggum
| 1. Where do you see Lisp as being put to best advantage in IT?
Where (Common) Lisp programmers can prosper.
| 2. If you know of Ruby as well, how do you see it in comparison for areas
| of application?
Languages often come with communities that collectively decide to solve
certain problems. I find it rather pointless to compare communities.
The Common Lisp community has decided to solve and to not solve certain
problems. Some people seem to be very strongly dissatisfied with the
choice of problems that the Common Lisp community has decided to solve.
It is, however, clear that other communities have decided to solve more
"modern" problems, meaning, in essence, that they retreat to a level that
Common Lisp left 40 years ago and try to invent something better than the
favorite point of reference: C. The amount of energy poured into solving
yet another set of problems caused by choosing C as the reference is very
impressive, but you will often find that people who have been through it
a couple of times are much less impressed with yet another new language
with a only few new significant features over the prevailing crop is not
worth the effort to create a whole new language and support infrastructure
-- Common Lisp people seem to behave in a way that is akin to the Borg:
they study the various new things that people do with interest and then
find that it was eminently doable in Common Lisp all along and that they
can use these new techniques if they think they need them.
There is no application area for which I think Common Lisp is unsuited.
There will, however, always be a number of areas that have a very low
entry threshold with any particular tool-oriented development process,
but application development never stops just over the threshold. If you
have any real business developing a new application, that first threshold
frequently turns out to be a very serious problem. The siren song of low
thresholds cause people to choose the easiest of the choices confronting
them at every junction. Only if you have a pretty good idea where you
are going and your grasp of the reality of real application development,
will you be able to sum the threshold you know you will have to cross and
choose one that is not the lowest at a particular point. The Common Lisp
community has done very little to present a low threshold at any junction
that normal programmers are likely to meet, but once you cross the high
threshold to Common Lisp, most programmers find that all other threshold
become taller while the new thresholds in their Common Lisp world are so
low as not to be perceived as thresholds, anymore.
| 3. What do you see as the best path to get on for a career using Lisp to
| a major extent, that is, what industry would it be best applied in?
Excellent programming is about solving fundamental problems for people
who did not konw they had them. Common Lisp excels in this part of the
application domain in any industry. If you are really good at what you
do and are not afraid to spend a _lot_ of time learning from people who
are not programmers, Common Lisp will be the language of choice when you
desire to build an advanced programming environment for any industry.
That is to say, Common Lisp is currently, and may remain, unsuitable for
"tinkering" with any particular "hot" industry. E.g., people today think
that application development will always involve the WWW and "optimized"
tools for generating web pages. This is wrong, but those who think they
need to have super-easy access to web tools are likely not to think that
Common Lisp can offer anything despite the very strong evidence of a much
lower sustained average effort per new feature in an evolving Common Lisp
system than in a comparable Perl or PHP or Ruby or whatever environment.
///
James A. Crippen
> There is no application area for which I think Common Lisp is unsuited.
The only application area that I've encountered where Common Lisp is
unsuited is in the embedded systems area. I've found that it is very
difficult to warrant using Lisp on a machine which will have <= 4
MBytes of memory.
Not that I wouldn't love to have a Lisp that would work well in 4
Mbytes with misc libraries, OS kernel, networking software, etc, but I
haven't found one yet that provides all the operating system
interconnections that C does. This is mostly because embedded
operating systems are written with C programming in mind, though.
'james
--
James A. Crippen <ja...@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
Thomas F. Burdick
> Wayd Wolf wrote:
> > Anyhow, I was wondering if any of you could give a quick purely opinion
> > response
>
> can do ;)
>
> > 1. Where do you see Lisp as being put to best advantage in IT?
>
> Anywhere that doesn't directly depend on intimate coupling with
> processor architecture (e.g. low-resource situations where bit-twiddling
> is de rigeur).
(with-pedantry
I'd say "where bit-twiddling is needed". A couple of days ago I was
sitting at a brand-new Sun workstation hacking away at some code in
CLISP, quite pleased with how blazingly fast it ran on this new
machine, when I caught some conversation a few workstations down.
Someone was hacking on some C code and explaining about all the
bit-twiddling in his code to some poor soul trying to read it. See,
this allowed him to use only 3 variables in this function instead of
the 6 a "naïve" implementation would have used. I didn't bother to
ask him if he knew exactly how many registers these machines *had*.
So, apparently it's de rigeur to twiddle bits and conserve registers
like a madman when writing a goddamn Motif app on a
brand-spaking-new Sun.)
Erik Naggum
| The only application area that I've encountered where Common Lisp is
| unsuited is in the embedded systems area. I've found that it is very
| difficult to warrant using Lisp on a machine which will have <= 4 MBytes
| of memory.
Heh. There were perfectly usable Apple Macintoshes with that amount of
memory providing what I am told (Espen?) would _still_ be a fantastic
Lisp experience.
///
--
My hero, George W. Bush, has taught me how to deal with people. "Make no
mistake", he has said about 2500 times in the past three weeks, and those
who make mistakes now feel his infinite wrath, or was that enduring care?
Marco Antoniotti
Erik Naggum <er...@naggum.net> writes:
> * James A. Crippen
> | The only application area that I've encountered where Common Lisp is
> | unsuited is in the embedded systems area. I've found that it is very
> | difficult to warrant using Lisp on a machine which will have <= 4 MBytes
> | of memory.
>
> Heh. There were perfectly usable Apple Macintoshes with that amount of
> memory providing what I am told (Espen?) would _still_ be a fantastic
> Lisp experience.
>
I fondly remember my Mac Plus with 4Mb (upgrade done by manually
removing what I think was a condenser on the main board) running Coral
Common Lisp (now Digitool). A fantastic programming environment.
Alas, when you talk to "embedded system programmers" you talk to
people who design systems with as little memory as possible (the macro
and long-term rationale about this choice still leave cold). We are
nowadays talking in the order of 1Mb. Not only. Only recently (< 2
years) you have started seeing FPUs on embedded processors as well.
Alas, you can have CL working on these systems as well. Of course
you cannot have a CL runtime running there (even the jury is still
oout for the Java VM). But you can have a fancy development
environment which takes up a specialized sublanguage (a CL
"extension") and then compiles it for the given target.
This is what people working with C do. You will not see a full
fledged libc on an embedded processor (say one of the ARM family).
You will see a carefully tailored libraries, crammed in the little
space youhave available.
So, in this arena, the game for a company working with CL would be to
use the system to construct a high level sublanguage (mostly to nail
down a well defined temporal and concurrent semantics) and a
supporting environment and to write a compiler for the desired target.
After all this is also what the C world is doing. Check out the
SystemC page <http://www.systemc.org/>, and note that a lot of
"embedded systems" development tools are actually doing just what I
described (deploying multi Mb development environments, which could be
written in CL as well).
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Espen Vestre
> Heh. There were perfectly usable Apple Macintoshes with that amount of
> memory providing what I am told (Espen?) would _still_ be a fantastic
> Lisp experience.
yes, MCL 1.3 (which was CLtL 1 with an interesting OO extension and lots
of other stuff)) was perfectly usable on a little 8Mhz Mac SE with only
2.5MB RAM.
--
(espen)
Christopher Stacy
Marco> Alas, when you talk to "embedded system programmers" you talk to
Marco> people who design systems with as little memory as possible (the macro
Marco> and long-term rationale about this choice still leave cold). We are
Marco> nowadays talking in the order of 1Mb. Not only. Only recently (< 2
Marco> years) you have started seeing FPUs on embedded processors as well.
I know people who would like to use Lisp for embedded programming,
but they are on 8-bit processors with only a few kilobytes of space.
Carl Shapiro
> I know people who would like to use Lisp for embedded programming,
> but they are on 8-bit processors with only a few kilobytes of space.
Are you referring to LIL?
Christopher Stacy
Carl> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>> I know people who would like to use Lisp for embedded programming,
>> but they are on 8-bit processors with only a few kilobytes of space.
Carl> Are you referring to LIL?
No, I'm just disagreeing with the idea that all embedded applications
these days have megabytes of memory and fast CPUs. The programmer I
had in mind would like to use Lisp, but there isn't one for his platform.
(It's such an extreme case that I don't think he will ever get to use
Lisp, either. Certainly not Common Lisp.) I presented it just to
clarify what the boundary conditions were for embedded application
platforms in the 21st century.
Christian Lynbech
Marco> Alas, when you talk to "embedded system programmers" you talk to
Marco> people who design systems with as little memory as possible
Probably depends a bit on your definition of an embedded system. I
have grown used to think of it as anything with a strictly dedicated
purpose as opposed to a (desktop) computer. Thus I personally consider
a router to be a sort of an embedded system, and the routers we work
on has 256Mb of RAM (so this is of course in the "far other end" of
the embedded systems spectrum).
Marco> But you can have a fancy development environment which takes up
Marco> a specialized sublanguage (a CL "extension") and then compiles
Marco> it for the given target.
Sounds pretty much what ThinLisp is trying to do
http://sourceforge.net/projects/thinlisp/
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: christia...@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Pierre R. Mai
If I were to be in his situation (which I presently am not), I'd take
a look at Henry G. Baker's COMFY 6502 (and Z80 IIRC) stuff, which he
describes for the current day reader in the Septemper 1997 edition of
ACM's SIGPLAN notices, in his Garbage In/Garbage Out column. The
TeX source of that column is also available on his home page under
http://www.pipeline.com/~hbaker1/sigplannotices/column04.tex.gz
His approach leverages of the capabilities of the compile-time
environment (macro expansion, etc.), but compiles into 6502 machine
code. So while you don't get to program in Common Lisp, you still get
much more leverage than your average current-day C or assembler
environment gets you.
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Marco Antoniotti
"Pierre R. Mai" <pm...@acm.org> writes:
> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>
....
> > No, I'm just disagreeing with the idea that all embedded applications
> > these days have megabytes of memory and fast CPUs. The programmer I
> > had in mind would like to use Lisp, but there isn't one for his platform.
> > (It's such an extreme case that I don't think he will ever get to use
> > Lisp, either. Certainly not Common Lisp.) I presented it just to
> > clarify what the boundary conditions were for embedded application
> > platforms in the 21st century.
>
> If I were to be in his situation (which I presently am not), I'd take
> a look at Henry G. Baker's COMFY 6502 (and Z80 IIRC) stuff, which he
> describes for the current day reader in the Septemper 1997 edition of
> ACM's SIGPLAN notices, in his Garbage In/Garbage Out column. The
> TeX source of that column is also available on his home page under
>
> http://www.pipeline.com/~hbaker1/sigplannotices/column04.tex.gz
>
> His approach leverages of the capabilities of the compile-time
> environment (macro expansion, etc.), but compiles into 6502 machine
> code. So while you don't get to program in Common Lisp, you still get
> much more leverage than your average current-day C or assembler
> environment gets you.
Which is more or less what I was pointing to. The fact that now you
start to see embedded processors with FPU's and more than a few Ks of
memory does not mean that the vast majority of people work with much
"smaller" (in every sense) chips.
Erik Naggum
| The programmer I had in mind would like to use Lisp, but there isn't one
| for his platform. (It's such an extreme case that I don't think he will
| ever get to use Lisp, either. Certainly not Common Lisp.)
What part of Lisp does he want to use? Is he equipped and willing to
write a compiler and runtime system for his special environment? The
more specialized, the more likely that a reasonably comfortable system
can be built with really minimal resources. E.g., Forth-based systems
have shown that memory can be really tight while you can still get a lot
of real work done. Compiling a Lisp-like language to a Forth-like stack
machine and interpreter should not be an incredibly hard task given the
appropriate skill set of the programmer.
Jeff Sandys
in the "My Real Baby" was programmed in Lisp.
http://www.irobot.com/mrb
Petter Gustad
> * James A. Crippen
> | The only application area that I've encountered where Common Lisp is
> | unsuited is in the embedded systems area. I've found that it is very
> | difficult to warrant using Lisp on a machine which will have <= 4 MBytes
> | of memory.
>
> Heh. There were perfectly usable Apple Macintoshes with that amount of
> memory providing what I am told (Espen?) would _still_ be a fantastic
> Lisp experience.
My first Macintosh (1984) had 128 KB RAM and I was running
Expertelligence Lisp (does anybody know what happened to this
product?) as well as XLisp (by David Betz if memory serves me
correctly) on this machine.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.com
Marc Battyani
"Petter Gustad" <newsma...@gustad.com> wrote in message
news:878zek7...@zener.home.gustad.com...
> Erik Naggum <er...@naggum.net> writes:
>
> > * James A. Crippen
> > | The only application area that I've encountered where Common Lisp is
> > | unsuited is in the embedded systems area. I've found that it is very
> > | difficult to warrant using Lisp on a machine which will have <= 4
MBytes
> > | of memory.
> >
> > Heh. There were perfectly usable Apple Macintoshes with that amount
of
> > memory providing what I am told (Espen?) would _still_ be a fantastic
> > Lisp experience.
>
> My first Macintosh (1984) had 128 KB RAM and I was running
> Expertelligence Lisp (does anybody know what happened to this
> product?) as well as XLisp (by David Betz if memory serves me
> correctly) on this machine.
LeLisp worked perfectly fine on a 48Ko Z80 (TRS80)
"le-lisp: A Portable and Efficient Lisp System", J. Chailloux et al, Proc
1984 ACM Symp on Lisp and Functional Programming, ACM.
Marc