The biggest problem with LISP is its lack of social acceptance in the
computing community.
The first and the foremost thing to change about LISP is the personal
relations department.
What would be the best way to make people change the mind about LISP?
People are so against LISP. How to change their minds??
I dont think that way (well I am from academeia what do you expect).
But seriously..do you think that keeping secrets is a good strategy?
Look at Linux. There is a lot of money to be made and everybody can
win.
Thats what I think. Getting more and more talented open-source-hackers
involved in LISP based projects is the way to go. The question is how
to woo them ???
On Sat, 23 Apr 2005 14:31:16 -0700, nikhilketkar wrote:
> The question is how to woo them ???
Get rid of their fear of "(" and ")", and while we're at it "<" and ">" :)
Nikhil Ketkar wrote:
> If you are using the right editor (which is emacs...uh..dont wanna
> start a war wit vi but it is a fact ) you dont have a problem with "("
> and ")"
I think this attitude is part of the problem set.. if everyone gets
confronted with "use emacs", Lisp gets a bad rap as being the "weird
emacs people thing". Lisp is associated neither with emacs nor with AI
anymore (10 years ago, it was the "weird AI language"), in any
particular way but is a general purpose programming langauge (BTW. what
is it with emacs and parens? I can't even jump to matching parentheses
in emacs in default, like I can in vi with %. And even the primitive
Joy/Horton vi had automatic lisp indentation 20 years ago, although not
a very good one. "Modern" reimplementations like vim work quite well in
that department.)
mkb.
Matthias Buelow wrote:
<snip>
> I can't even jump to matching parentheses
> in emacs in default, like I can in vi with %.
Look at forward-sexp, backward-sexp, forward-up-list, back-list, and
their ilk. I have these bound to M-right, M-left, M-up, and M-down,
respectively. These are by default bound to C-M-f, C-M-b, and such.
-- MJF
"nikhilketkar" <············@gmail.com> writes:
> Thats what I think. Getting more and more talented open-source-hackers
> involved in LISP based projects is the way to go. The question is how
> to woo them ???
Here is a possible answer:
Practical Common Lisp
http://www.gigamonkeys.com/book
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
nikhilketkar wrote:
> People are so against LISP. How to change their minds??
The best way to change their minds would to be to do impressive things.
If you can do impressive things using Lisp, and want to tell them all
about it later, that's fine. Paul Graham got some traction for Lisp by
building Yahoo Store. Likewise for ITA doing Orbitz.
Evangelism for religious purposes leads nowhere in this situation.
Open-minded people will look at Lisp when they believe it will help
them accomplish some other goal. And they'll stick with it if it turns
out to be true. Lots of people learn Python or Perl because they
believe it will help them in some programming activity. Many people
learn Java simply because they think it will get them a job.
Nobody is going to try Lisp simply because they hear some pitch, no
matter how compelling, from someone they have no particular desire to
listen to.
People who go hand out religious tracts or go door-to-door have
terrible results. (Read just the other day that the average Mormon
going on their "mission" gets one convert per thousand knocks on a
stranger's door.) They do it because their religion commands them to,
not because it is fun or rewarding in itself.
nikhilketkar wrote:
> The biggest problem with LISP is its lack of social acceptance in the
> computing community.
> The first and the foremost thing to change about LISP is the personal
> relations department.
> What would be the best way to make people change the mind about LISP?
> People are so against LISP. How to change their minds??
>
The question is WHY change their minds?
As Stefan Ram writes, Lisp might give you an advantage, so I for
one prefer that all the world uses Java, and Lisp is a minority
language.
If you want to make people go "oooh" and "aaaah" about Lisp, write
Really Cool (tm) software in it and put it online for free / sell it.
If you can do with 20MB RAM and a decent startup time what Java
does with 5 seconds startup time and 100MB RAM, and you have
better response time, too, then that would be good thing, for
instance. If you can develop a really good website, that would be
good (just put something like "powered by Lisp" at the bottom).
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
From: Florian Weimer
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <87acnoa5go.fsf@deneb.enyo.de>
* Ulrich Hobelmann:
> The question is WHY change their minds?
Increased developer mindshare tends to increase the quality and scope
of tools and libraries.
> As Stefan Ram writes, Lisp might give you an advantage, so I for
> one prefer that all the world uses Java, and Lisp is a minority
> language.
Just because potential competition would choose poorer tools and have
to invest even more resources as a result, the work I have to invest
doesn't become less. I usually work in areas where there is virtually
no competition (due to lack of interest in the commercial sector,
issues of scale, or maybe even because the problem I'm trying to
address is not widely understood yet). Keeping Lisp a secret won't
help me a bit. It only makes it harder to find fellow developers and
good tools.
Your (and Stefan's) reasoning would be correct if there was a scarcity
of development tasks. But fortunately, there isn't, not even of
interesting tasks.
I don't think the free Lisps are finished in the sense that adding
further features could only make things worse. Much like Java, they
integrate poorly into a traditional UNIX environment (mainly because
the process creation overhead is too large). On the other hand, I
wouldn't dare to use a proprietary development environment for a
medium or long term project because once you rely on its particular
feature set or performance characteristics, you are subject to the
vendor's whims. Look what happened to Visual Basic, it's not only a
going-out-of-business issue.
Ulrich Hobelmann wrote:
> nikhilketkar wrote:
>
>> The biggest problem with LISP is its lack of social acceptance in the
>> computing community.
>> The first and the foremost thing to change about LISP is the personal
>> relations department.
>> What would be the best way to make people change the mind about LISP?
>> People are so against LISP. How to change their minds??
>>
>
> The question is WHY change their minds?
>
> As Stefan Ram writes, Lisp might give you an advantage, so I for one
> prefer that all the world uses Java, and Lisp is a minority language.
The OP said that he/she is a researcher. The idea of keeping Lisp as a
"secret weapon" is not an option if you take your job as a scientist
seriously. That's what you're paid for. (If it doesn't matter for your
research what language you use, you would not talk about it, but not
because you want to hide that fact from someone.)
> If you want to make people go "oooh" and "aaaah" about Lisp, write
> Really Cool (tm) software in it and put it online for free / sell it.
That's a better approach. For example, you could also do demonstrations
as part of your presentations. This requires you to be very comfortable
with using a running program during a presentation because you may need
to deal with possible bugs live. But this can work.
Lisp has many features that you probably only grasp when you see it.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
nikhilketkar wrote:
> The biggest problem with LISP is its lack of social acceptance in the
> computing community.
> The first and the foremost thing to change about LISP is the personal
> relations department.
> What would be the best way to make people change the mind about LISP?
> People are so against LISP. How to change their minds??
Personally I think the only way to change people's mind is to show them
complete and fully functional applications they could appreciate and
use. The only problem I see is that an application to be "attractive"
to non lisp users need a "cool" gui and here, unfortunately, lisp has
still to improve. What if some of the most famous KDE apps would have
been written in Lisp instead of C++ QT ?
From: Florian Weimer
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <87wtqq3d5p.fsf@deneb.enyo.de>
> Personally I think the only way to change people's mind is to show them
> complete and fully functional applications they could appreciate and
> use. The only problem I see is that an application to be "attractive"
> to non lisp users need a "cool" gui and here, unfortunately, lisp has
> still to improve.
I find the constant references to GUIs confusing. I'm under the
impression that most potential Lisp developers are pretty suspicious
of GUIs. GUIs are boring, they are just a huge coding and (graphical)
design effort, and there's not much room for innovation if you want
something which usable. (The only real GUI innovation I've
encountered in the last decade or so are treemaps.)
> What if some of the most famous KDE apps would have been written in
> Lisp instead of C++ QT ?
KDE's impact on language choice beyond KDE is minimal. If it wasn't
so hard to write bindings for C++ libraries, C++ would be less
dominant even within the KDE project.
Florian Weimer wrote:
>>Personally I think the only way to change people's mind is to show them
>>complete and fully functional applications they could appreciate and
>>use. The only problem I see is that an application to be "attractive"
>>to non lisp users need a "cool" gui and here, unfortunately, lisp has
>>still to improve.
>
>
> I find the constant references to GUIs confusing. I'm under the
> impression that most potential Lisp developers are pretty suspicious
> of GUIs. GUIs are boring, they are just a huge coding and (graphical)
> design effort,
Take a look at Apple's Interface Builder.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
I agree with you that GUI are boring (unless you use a GUI builder) but
are the only way to make software visible to user. You can write the
most advanced, innovative and sofisticated software in Lisp but if you
are not able to make it usable and visible to standard user it will be
discarded. If we want Lisp to become widely accepted and not confined
to back-end application only we need it to have a state of the art,
portable GUI toolkit. There are many examples of languages and
operating systems totally not advanced and not innovative but with a
huge developers base because of their easy GUI. Many times I found
myself to use lisp in real world business apps but only as a back-end
engine where the front end was a browser. Unfortunatly not all
applications can be developed with a browser based interface.
Minion: tell Massimiliano Campagnoli about McCLIM
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
David,
McCLIM is not a toolkit you can use to make GUI for a commercial
application. Customers expect all the look and feel available in today
desktop applications.
The only available solution today is make the GUI with a standard class
library such as Qt or MFC and develop the back end in Lisp. This is not
as easy as it seems to be, especially when you need an heavy
interaction between presentation logic (front end) and business logic
(back end). It could be so hard that you can decide to give up using
Lisp and opt for a full C++ solution only because of the GUI library
available in C++. Obviously then you miss Lisp whenever you need to do
some high-level logic.
(We had an hard time when we developed a job shop scheduling
applications in Lisp but the customer wanted also a cool front-end with
draggable and droppable gant charts and machine load diagrams).
Sometimes the best way to go is to use Lisp as an embedded language in
a more procedural programming language like C++ doing in Lisp all the
complex logic and let C++ handle the presentation; this means not to
call C++ from Lisp but to call Lisp from C++.
Massimiliano Campagnoli wrote:
> David,
> McCLIM is not a toolkit you can use to make GUI for a commercial
> application. Customers expect all the look and feel available in today
> desktop applications.
> The only available solution today is make the GUI with a standard class
> library such as Qt or MFC and develop the back end in Lisp. This is not
> as easy as it seems to be, especially when you need an heavy
> interaction between presentation logic (front end) and business logic
> (back end). It could be so hard that you can decide to give up using
> Lisp ...
And that will make it easier? A little FFI work is too hard, but I can
throw away all the power of Lisp and come out ahead? Plz check your
calculator.
> ..and opt for a full C++ solution only because of the GUI library
> available in C++. Obviously then you miss Lisp whenever you need to do
> some high-level logic.
So why not call a C library from Lisp, via the FFI? There is lambdaGtk,
Cells-gtk, and I have called the win32 api directly myself. Lots of code
in the CormanCL libraries for that, since it does not offer any special
lisp-ified API as Lispworks and AllegroCL (and MCL on the Mac) do.
> (We had an hard time when we developed a job shop scheduling
> applications in Lisp but the customer wanted also a cool front-end with
> draggable and droppable gant charts and machine load diagrams).
> Sometimes the best way to go is to use Lisp as an embedded language in
> a more procedural programming language like C++ doing in Lisp all the
> complex logic and let C++ handle the presentation; this means not to
> call C++ from Lisp but to call Lisp from C++.
>
As you suggested above, Lisp is great to have when you are doing the
GUI, too. People act like the GUI is some trivial veneer on the
interesting internal model. Ha! The GUI will kill you even with a good
internal model. The GUI is where one hits the combinatorial explosion of
interactions between GUI elements with overlapping responsibility, and
the GUI is the thing driven by that most chaotic, non-deterministic of
systems, the User.
Do that in C++? nahh. As long as you are looking at biting a bullet, get
a GTk interface working or write a procedural C api for some C++ GUI,
then forget it exists. That is what the big boys do, anyway (AllegroCL,
Lispworks).
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> Massimiliano Campagnoli wrote:
> > David,
> > McCLIM is not a toolkit you can use to make GUI for a commercial
> > application. Customers expect all the look and feel available in
today
> > desktop applications.
> > The only available solution today is make the GUI with a standard
class
> > library such as Qt or MFC and develop the back end in Lisp. This is
not
> > as easy as it seems to be, especially when you need an heavy
> > interaction between presentation logic (front end) and business
logic
> > (back end). It could be so hard that you can decide to give up
using
> > Lisp ...
>
> And that will make it easier? A little FFI work is too hard, but I
can
> throw away all the power of Lisp and come out ahead? Plz check your
> calculator.
>
> > ..and opt for a full C++ solution only because of the GUI library
> > available in C++. Obviously then you miss Lisp whenever you need to
do
> > some high-level logic.
>
> So why not call a C library from Lisp, via the FFI? There is
lambdaGtk,
> Cells-gtk, and I have called the win32 api directly myself. Lots of
code
> in the CormanCL libraries for that, since it does not offer any
special
> lisp-ified API as Lispworks and AllegroCL (and MCL on the Mac) do.
>
> > (We had an hard time when we developed a job shop scheduling
> > applications in Lisp but the customer wanted also a cool front-end
with
> > draggable and droppable gant charts and machine load diagrams).
> > Sometimes the best way to go is to use Lisp as an embedded language
in
> > a more procedural programming language like C++ doing in Lisp all
the
> > complex logic and let C++ handle the presentation; this means not
to
> > call C++ from Lisp but to call Lisp from C++.
> >
>
> As you suggested above, Lisp is great to have when you are doing the
> GUI, too. People act like the GUI is some trivial veneer on the
> interesting internal model. Ha! The GUI will kill you even with a
good
> internal model. The GUI is where one hits the combinatorial explosion
of
> interactions between GUI elements with overlapping responsibility,
and
> the GUI is the thing driven by that most chaotic, non-deterministic
of
> systems, the User.
>
> Do that in C++? nahh. As long as you are looking at biting a bullet,
get
> a GTk interface working or write a procedural C api for some C++ GUI,
> then forget it exists. That is what the big boys do, anyway
(AllegroCL,
> Lispworks).
>
> kt
>
>
> --
> Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
> Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
>
> "Doctor, I wrestled with reality for forty years, and I am happy to
> state that I finally won out over it." -- Elwood P. Dowd
Ok Kenny,
you succeded in "changing my mind" about GUI in Lisp. I've decided to
give Cell-Gtk+ a try. I wonder if I can really give up with all the
mess involved in C++ GUI/Lisp interaction and go for a "pure" Lisp GUI
solution.
Ciao, Massimiliano.
"Massimiliano Campagnoli" <····@paoloastori.com> wrote:
> I wonder if I can really give up with all the
> mess involved in C++ GUI/Lisp interaction and go for a "pure" Lisp GUI
> solution.
yes, this is possible, too. For example you can call the OS functions
without any layer between, like I've done with CL-Canvas:
http://www.frank-buss.de/lisp/canvas.html
But then you have to implement it for every OS yourself.
If you don't need the OS standard GUI elements, you can use OpenGL.
Together with Glut, is very easy and platform independant for 2D and 3D
graphics, including all the window and event handling.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
> So why not call a C library from Lisp, via the FFI? There is
lambdaGtk,
> Cells-gtk, and I have called the win32 api directly myself. Lots of
code
> in the CormanCL libraries for that, since it does not offer any
special
> lisp-ified API as Lispworks and AllegroCL (and MCL on the Mac) do.
>
Why bother with Lisp making GUIs when you can make them with VS/C# with
simple clicks? Making browser in C#/VS is trivial .
Also VS EE is free ,Allegro and LW cost .
And with FFI you have to keep in mind that you'll need to interact
with C++ not C.
·············@hotmail.com writes:
>> So why not call a C library from Lisp, via the FFI? There is
> lambdaGtk,
>> Cells-gtk, and I have called the win32 api directly myself. Lots of
> code
>> in the CormanCL libraries for that, since it does not offer any
> special
>> lisp-ified API as Lispworks and AllegroCL (and MCL on the Mac) do.
>>
> Why bother with Lisp making GUIs when you can make them with VS/C# with
> simple clicks? Making browser in C#/VS is trivial .
> Also VS EE is free ,Allegro and LW cost .
> And with FFI you have to keep in mind that you'll need to interact
> with C++ not C.
Does "EE" mean something like "educational edition"?
For most people, versions of Visual Studio in which
you can "make GUIs with simple clicks" are not free.
Have you in fact tried making a GUI using Visual Studio
and then talking to it via FFI? I admit that I haven't,
but I'd rather expect it to be an exercise in frustration...
--
Gareth McCaughan
.sig under construc
·············@hotmail.com wrote:
>>So why not call a C library from Lisp, via the FFI? There is
>
> lambdaGtk,
>
>>Cells-gtk, and I have called the win32 api directly myself. Lots of
>
> code
>
>>in the CormanCL libraries for that, since it does not offer any
>
> special
>
>>lisp-ified API as Lispworks and AllegroCL (and MCL on the Mac) do.
>>
>
> Why bother with Lisp making GUIs when you can make them with VS/C# with
> simple clicks?
(a) GUI builders are an awful way to build GUIs
(b) You missed my point: GUIs (beyond a toy level) can be harder than
internal models to develop. You want the power of Lisp there, too, even
if it means some unpleasant few days of FFI work. Mind you, that has
been done for you so you really do not have to do it (the Lisp GTk
projects I mentioned).
> Making browser in C#/VS is trivial .
> Also VS EE is free ,Allegro and LW cost .
(a) There are cheaper Lisps
(b) You /do/ expect to see huge productivity benefits with Lisp, right?
So buy a frickin Lisp. Was your computer free? <sigh>
> And with FFI you have to keep in mind that you'll need to interact
> with C++ not C.
That is why I suggested a C library such as Gtk.
Is it Ground Hog Day? :)
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
From: Ulrich Hobelmann
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <3dulg4F9khmU1@individual.net>
Kenny Tilton wrote:
> (a) GUI builders are an awful way to build GUIs
Do you mean that automatic generation of GUI forms is better, or
just that most GUI builders suck?
I like Apple's Interface Builder, but I haven't seen most of the
Java/VM crap, either.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Ulrich Hobelmann <···········@web.de> writes:
> Kenny Tilton wrote:
> > (a) GUI builders are an awful way to build GUIs
>
> Do you mean that automatic generation of GUI forms is better, or just
> that most GUI builders suck?
>
> I like Apple's Interface Builder, but I haven't seen most of the Java/VM
> crap, either.
No, that they tend to suck in general once a certain level of interface
complexity is reached. Once that level is reached, the increasing
complexity of the gui-based project makes working on it ever more
difficult, often for no other reason than the perceived simplicity of a
gui environment tends to make the design more ad-hoc, evolutionary and
less thoroughly considered. Not that those things are bad as such, but
if you're going to write something complicated, then the design before
coding must also be complicated. GUI builders that suck more will have
a lower threshold where convienence inflects into pain, but all GUI
builders will exhibit that threshold.
Lispworks CAPI builder is an interesting case. It has a "suck-point"
too, but its offset by the complete openness of the entire gui
infrastructure, so its quite easy to assemble composite code/display
object strcutures that mix gui stuff and app stuff so the app doesn't
have to hack its way around brain-damaged, broken or just somewhat
unsuitable features of gui elements. The ability to do that gives a
degree of freedom I've never experienced in a gui builder before. I
think thats a direct result of Lisp being the cool language that it is.
Gregm
Greg Menke wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>>Kenny Tilton wrote:
>>
>>>(a) GUI builders are an awful way to build GUIs
>>
>>Do you mean that automatic generation of GUI forms is better, or just
>>that most GUI builders suck?
(a) Amen to what Greg said below
(b) Ahem: with something like Cells, one writes declarative code
defining the GUI. Layout is calculated automatically (albeit with full
control by the developer so you get the exact layout you want
painlessly) and the GUI itself (layout and even which widgets exist) can
be easily made dynamic, ie, responding intelligently to the changing
semantic scene. Rules are driving everything, not just literal values,
so the expressiveness is unlimited. I have worked with Interface Builder
or whatever the world champ in GUI builders may be, but I suspect the
best of them cannot touch the things possible with a constraint-driven
GUI. And of course one has the pleasure of not bouncing back and forth
between the GUI builder and the application code, which I think starts
to get into Greg's comments.
kenny
>>
>>I like Apple's Interface Builder, but I haven't seen most of the Java/VM
>>crap, either.
>
>
>
> No, that they tend to suck in general once a certain level of interface
> complexity is reached. Once that level is reached, the increasing
> complexity of the gui-based project makes working on it ever more
> difficult, often for no other reason than the perceived simplicity of a
> gui environment tends to make the design more ad-hoc, evolutionary and
> less thoroughly considered. Not that those things are bad as such, but
> if you're going to write something complicated, then the design before
> coding must also be complicated. GUI builders that suck more will have
> a lower threshold where convienence inflects into pain, but all GUI
> builders will exhibit that threshold.
>
> Lispworks CAPI builder is an interesting case. It has a "suck-point"
> too, but its offset by the complete openness of the entire gui
> infrastructure, so its quite easy to assemble composite code/display
> object strcutures that mix gui stuff and app stuff so the app doesn't
> have to hack its way around brain-damaged, broken or just somewhat
> unsuitable features of gui elements. The ability to do that gives a
> degree of freedom I've never experienced in a gui builder before. I
> think thats a direct result of Lisp being the cool language that it is.
>
> Gregm
>
>
>
>
>
>
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Ulrich Hobelmann wrote:
> Kenny Tilton wrote:
>
>> (a) GUI builders are an awful way to build GUIs
>
>
> Do you mean that automatic generation of GUI forms is better, or just
> that most GUI builders suck?
>
Its that most GUI builders only build *static* interfaces.
A simple example of a problem :
If you have an interface with a row of push-buttons. If depending on
what the user has done you want to change the number of buttons:
what they do; maybe adding another row; or deleting the row, then
this can be difficult with a graphical builder because
the combinatorial user state explosion. Also, which buttons that are on
the row may be dynamically calculated based on some data displayed.
In the effort to provide a user with a beautiful and effective GUI it
usually has to be dynamic otherwise you end up with a brutish interface.
Wade
Ulrich Hobelmann <···········@web.de> writes:
> Kenny Tilton wrote:
>> (a) GUI builders are an awful way to build GUIs
>
> Do you mean that automatic generation of GUI forms is better, or just
> that most GUI builders suck?
>
> I like Apple's Interface Builder, but I haven't seen most of the
> Java/VM crap, either.
Interface Builder was written in Lisp originally.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
From: Ulrich Hobelmann
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <3dvhgaFelu7U1@individual.net>
Pascal Bourguignon wrote:
> Interface Builder was written in Lisp originally.
I know that it was part of the original NeXTStep (or OpenStep) in
some form, but this is new :)
Do you know what Lisp they used and how they connected Lisp to the
(probably Obj-C) GUI library? Via C functions? This is getting
interesting...
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Jean-Marie Hullot[1], who wrote the predecessor of IB (called SOS
Interface), may have used LELISP[2]. Not sure on what platform, but it
may have been on a Macintosh, as ExperTelligence were reselling it for
the Mac.
I don't recall there ever being a single line of Lisp in Interface
Builder, though.
An other reference is the following:
"The stimulus for building a dialog editor came from a timely talk by
Jean-Marie Hullot about a user interface editor in a Lisp environment,
which later developed into the ExperTelligence Interface Builder
[Hullot 86, Hullot 87]. The latter program turned out to be very
similar to this work, modulo the diversity of the underlying
environments."[3]
This is all purely conjectural.
Cheers,
Olivier
Sources:
---------------------
[1]
http://portal.acm.org/citation.cfm?id=802027&jmp=abstract&coll=GUIDE&dl=GUIDE&CFID=43473572&CFTOKEN=31021004#abstract
[2] http://www.levenez.com/NeXTSTEP/Personnes.html
[3] Luca Cardelli (1987, 1993), Building User Interfaces by Direct
Manipulation
In article <························@z14g2000cwz.googlegroups.com>,
"Olivier Drolet" <·······@mac.com> wrote:
> Jean-Marie Hullot[1], who wrote the predecessor of IB (called SOS
> Interface), may have used LELISP[2]. Not sure on what platform, but it
> may have been on a Macintosh, as ExperTelligence were reselling it for
> the Mac.
>
> I don't recall there ever being a single line of Lisp in Interface
> Builder, though.
>
> An other reference is the following:
>
> "The stimulus for building a dialog editor came from a timely talk by
> Jean-Marie Hullot about a user interface editor in a Lisp environment,
> which later developed into the ExperTelligence Interface Builder
> [Hullot 86, Hullot 87]. The latter program turned out to be very
> similar to this work, modulo the diversity of the underlying
> environments."[3]
>
> This is all purely conjectural.
>
> Cheers,
> Olivier
>
> Sources:
> ---------------------
> [1]
> http://portal.acm.org/citation.cfm?id=802027&jmp=abstract&coll=GUIDE&dl=GUIDE&CFID=43473572&CFTOKEN=31021004#abstract
>
> [2] http://www.levenez.com/NeXTSTEP/Personnes.html
>
> [3] Luca Cardelli (1987, 1993), Building User Interfaces by Direct
> Manipulation
Apple's Interface Builder was not written in Lisp. But Apple hired
Jean-Marie Hullot to develop the Interface Builder after they saw his
SOS (or a later incarnation of it). SOS was written with LeLisp on a Mac.
Later it was ported to ExperCommonLisp (maybe even to the earlier ExperLisp)
and Macintosh Allegro Common Lisp, where it was sold as Action! by ExperTelligence.
So I've tried Cells-Gtk.
I must say I am quite impressed.
There are all the widgets requested for a modern GUI, thanks to GTK;
moroever handling GUI logic is like writing "if-then rules" triggered
by changes in widget's states, thanks to Cells.
The only remark I must do is the lack of documentation that makes
Cells-Gtk learning curve quite steep.
Kenny what about writing a bit more docs ? I think it would be very
helpful for all of us trying to get the maximum from Cells-Gtk,
Thanks, Max
Massimiliano Campagnoli wrote:
> So I've tried Cells-Gtk.
> I must say I am quite impressed.
Yep, Vasilis did a fine job.
> There are all the widgets requested for a modern GUI, thanks to GTK;
> moroever handling GUI logic is like writing "if-then rules" triggered
> by changes in widget's states, thanks to Cells.
Yep.
> The only remark I must do is the lack of documentation that makes
> Cells-Gtk learning curve quite steep.
Yep. :) I guess you mean learning Cells in general? Or do you mean
specifically how Gtk looks different when accessed via Cells-Gtk? I
guess Gtk itself is satisfactorily documented.
> Kenny what about writing a bit more docs ? I think it would be very
> helpful for all of us trying to get the maximum from Cells-Gtk,
Depends on the answer to the above. If you mean Cells-Gtk specifically,
i would try the Cells-Gtk list. I do not use or know it myself.
As for Cells doc, the Open Source Fairy has retired to Florida. Maybe
I'll write a book. Breath should not be held.
Aside from that, I am working on new example code now (somewhat
distracted by discovering that I totally broke Synapses recently). I am
more likely to help with small starter examples sent in by users than
attempt a reference-style write-up.
Also, someone sent me a 6502 assembler which uses Cells. It requires an
enhancement to Cells before being shared more widely, but it is a
trivial enhancement, so watch for that soon as well.
kenny
--
Cells? Cello?: http://www.common-lisp.net/project/cells/
Cells-Gtk?: http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
From: Florian Weimer
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <8764yca52w.fsf@deneb.enyo.de>
> The biggest problem with LISP is its lack of social acceptance in the
> computing community.
I dob't think this is true. The general computing commonity frowned
upon Visual Basic, too, and it didn't reduce its popularity among
developers.
There are too few Lisp developers, true, but blaming this on a vague
concept of "social acceptance" is an oversimplification. A lot of
good development teams do what they consider worthwhile, independently
of what is currently en vogue, and are even quite successful. I fear
that the real cause for lack in Lisp lies within Lisp itself, or more
precisely, the type of available implementations.
On Sun, 24 Apr 2005 11:37:11 +0200, Florian Weimer <··@deneb.enyo.de>
wrote:
>> The biggest problem with LISP is its lack of social acceptance in the
>> computing community.
>
>I dob't think this is true. The general computing commonity frowned
>upon Visual Basic, too, and it didn't reduce its popularity among
>developers.
>
>There are too few Lisp developers, true, but blaming this on a vague
>concept of "social acceptance" is an oversimplification. A lot of
>good development teams do what they consider worthwhile, independently
>of what is currently en vogue, and are even quite successful. I fear
>that the real cause for lack in Lisp lies within Lisp itself, or more
>precisely, the type of available implementations.
Could you expand? What is wrong with the available limitations that so
sabotages lisp?
--
adamnospamaustin.rr.com
s/nospam/c\./
From: Florian Weimer
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <87d5si4sdh.fsf@deneb.enyo.de>
* Adam Connor:
>> I fear that the real cause for lack in [interested in] Lisp lies
>>within Lisp itself, or more precisely, the type of available
>>implementations.
>
> Could you expand? What is wrong with the available limitations
> [implementations?] that so sabotages lisp?
Here are some ideas for technical issues someone could take with
current free Lisp implementations:
* The per-process overhead is relatively large (even an empty
program needs 3 to 4 MB of non-shared address space). Most
scripting languages use less.
* Process creation overhead is at least an order of magnitude worse
than compiled, statically typed languages.
* Process creation becomes even more expensive if FFI is used to
load additional DSOs (this is in part an OS limitation, but other
languages support lazy loading to hide some of the overhead).
* The garbage collector in SBCL and CMUCL seems to be pretty weak
(CLISP is much faster for short-lived small objects).
* The native code generated by SBCL and CMUCL is rather verbose.
It's still much faster than CLISP, but anyone who can read
assembly language and just discovered DISASSEMBLE will end up
scratching their head and wonder if this is really
state-of-the-art technology (still true if you add full type
annotations, BTW).
Other languages don't have DISASSEMBLE, so inefficiencies are
easily swept under the carpet.
* Unlike Perl or Python, you cannot embed the leading free Lisp
implementation into executables. Part of this has to do with the
fact that they do not follow the traditional compile/link model.
* Cross-referencing does not work in any free implementation I've
tried so far (not a real problem, but still a bit disappointing).
* It's not clear to me which implementations (besides CLISP) provide
protection against machine code injection through buffer overflow
bugs.
* Linux distributions usually ship only a single Lisp implementation
which is generally frowned upon. If they ship additional ones,
backwards compatibility is probably not a main concern for them.
(Not a showstopper, of course, people use PHP, too.)
* AFAIK, Debian's Lisp environment is unique, which means that
you'll face trouble when you try to set up your array of tools on
Solaris, say.
* Unfortunately, creating single-file executables is quite hard.
This would be quite handy if you have separate development
machines, and it helps to avoid dependency problems.
* Some people (including me, it seems) prefer statically typed
languages over dynamically typed ones, even if they are less
productive in the short run.
I looked at seriously Lisp two years ago, and I ended up not using it
for my projects. Looking back, the main factors driving me away from
Lisp were the packaging issues I mentioned above. At that time, I
thought it would be necessary to the main program on lots of machines,
under the control of many different system administrators. If all of
them had to install CMUCL or SBCL, my project was doomed. Or so I
thought. There was another issue that gave me headaches: How can I
implement a server which can concurrently process hundreds of
connections? (The occasional reference to SERVE-EVENT was not
helpful, for various reasons.)
So I went with C++. The standard library was a major factor in this
decision because I needed proven implementations of container types.
It was quite refreshing because I hadn't to deal with the constant
whining along the lines of "my favorite language is so superior to
everything else, but most people are just too stupid to recognize
this". (At that time, Lisp was not the only language I was interested
in whose Usenet group saw regular postings of this kind.)
I should have taken CLISP more seriously. I'm quit confident it would
have been possible to distribute my application as a patch on top of
CLISP, with the speed-critical parts written in C. In the end, the
packaging problems were less severe because the final architecture was
quite different from what I had on my mind initially. Peter Seibel's
book would have help with the binary parsing tasks, too. However, I
must admit, that the ability to separate development and run-time
environment was critical in the beginning, when I hadn't got a
dedicated machine to run the software on and couldn't install a full
development environment on the target machine.
Well, C++ was not the end of the story. I was able to write the
generic binary serialization/serialization facility in C++, but after
the second attempt, I discovered that even though the generated code
was extremely efficient, it was a maintainance nightmare, thanks to
template metaprogramming. The buffer overflow potential was a major
turnoff, too, and I was quite relieved when all the mess was gone.
With all that effort, I probably could have ended up with a
CLISP-based application with similar performance and maintainability
characteristics. 8-/
"nikhilketkar" <············@gmail.com> writes:
> What would be the best way to make people change the mind about LISP?
If you check the comp.lang.lisp archive, you will find a lot of
background material on it. This was discussed a lot in the past, the
latest time less than a few weeks ago.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
nikhilketkar wrote:
> People are so against LISP. How to change their minds??
Teaching at an university and programming in Lisp since the 70ies I
find that most people learned to dislike Lisp as ugrad during a
"programming languages" course. Before that they were pretty neutral.
These course introduce students, in quick succession, to a number of
programming languages including Lisp. The Lisp part usually is based on
using some old computer in the basement or by downloading some free
Lisp. Then they do the car/cdr and some quick recursion hack. After
that they either hate Lisp or at least see no value in it. The same
students all get Visual Studio DVDs from Microsoft for free. When they
compare the two they conclude Lisp is from the dark ages and is just
one small step up from punch cards.
In some sense I cannot blame these students. They don't want to write
little silly recursive functions or hear about the beauty of closures
etc. They want to hack cool stuff such as games. They want to have
access to interesting APIs such as OpenGL. They want to learn about
OOP. Lisp could give them all that. Best of all now would be a good
time since the "I must learn Java" crowd has gone.
As instructor I would need a textbook. That textbook could not be ABOUT
Lisp but it could use Lisp. As much as I would want to I cannot offer a
Lisp course. But I can offer a OOP course or game design course. Both
could use Lisp. But what textbook could I use? Many textbooks (e.g., On
Lisp, Ansi Common Lisp) are written by folks who officially hate OOP.
This does not work for me. I need a Lisp book written by somebody who
likes OOP/CLOS and actually uses it. PCL looks like a good book. I
could use that for graduate student learning Lisp as part of research
project but it would not work for most of my courses.
When I show OpenGL + Lisp in my game design courses that really gets
students excited. Now the question is who is going to write a nice book
on making games (with OOP) in Lisp?
Alexander Repenning wrote:
> In some sense I cannot blame these students.
You don't blame them for choosing one language over another based
on the shininess of the GUI instead of the language's capabilities?
OTOH, I don't blame them either. Their own problem to write
programs in that mess. ;)
> They don't want to write
> little silly recursive functions or hear about the beauty of closures
> etc. They want to hack cool stuff such as games. They want to have
> access to interesting APIs such as OpenGL. They want to learn about
> OOP. Lisp could give them all that. Best of all now would be a good
> time since the "I must learn Java" crowd has gone.
Does that mean there's currently no OpenGL binding for Lisp?
About games: when I started programming, I wanted to do games,
too. That was what led me the way through well a dozen
programming languages, looking for something decent to code in.
Now I don't really want to do games anymore, though.
> As instructor I would need a textbook. That textbook could not be ABOUT
> Lisp but it could use Lisp. As much as I would want to I cannot offer a
> Lisp course. But I can offer a OOP course or game design course. Both
> could use Lisp. But what textbook could I use? Many textbooks (e.g., On
> Lisp, Ansi Common Lisp) are written by folks who officially hate OOP.
And they're dead right, IMHO. CLOS might be different, though
(have to learn it yet), and I don't consider it orthodox OOP.
> This does not work for me. I need a Lisp book written by somebody who
> likes OOP/CLOS and actually uses it. PCL looks like a good book. I
> could use that for graduate student learning Lisp as part of research
> project but it would not work for most of my courses.
CLOS != what other people consider OOP (since they only know one
or two C dialects, or maybe Smalltalk)
> When I show OpenGL + Lisp in my game design courses that really gets
> students excited. Now the question is who is going to write a nice book
> on making games (with OOP) in Lisp?
What OpenGL is that? Are the binding cross-platform (especially Mac)?
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Ulrich Hobelmann <···········@web.de> writes:
> Alexander Repenning wrote:
> > As instructor I would need a textbook. That textbook could not be ABOUT
> > Lisp but it could use Lisp. As much as I would want to I cannot offer a
> > Lisp course. But I can offer a OOP course or game design course. Both
> > could use Lisp. But what textbook could I use? Many textbooks (e.g., On
> > Lisp, Ansi Common Lisp) are written by folks who officially hate OOP.
>
> And they're dead right, IMHO. CLOS might be different, though (have
> to learn it yet), and I don't consider it orthodox OOP.
CLOS is different. CLOS is Reformed OOP and thus more flexible. CLOS
is very much worth learning. Peter's PCL book talks about CLOS more
than Graham or Norvig. Keene's book is the definitive tutorial. Buy
it. Read it.
> > This does not work for me. I need a Lisp book written by somebody who
> > likes OOP/CLOS and actually uses it. PCL looks like a good book. I
> > could use that for graduate student learning Lisp as part of research
> > project but it would not work for most of my courses.
>
> CLOS != what other people consider OOP (since they only know one or
> two C dialects, or maybe Smalltalk)
The lack of 'private', 'protected', and 'public' key words should not
be held against CLOS. Nor should the fact that CLOS fully supports
Multiple Inheritance. OOP is no silver bullet, but it is useful when
used properly.
> > When I show OpenGL + Lisp in my game design courses that really gets
> > students excited. Now the question is who is going to write a nice book
> > on making games (with OOP) in Lisp?
>
> What OpenGL is that? Are the binding cross-platform (especially Mac)?
Look up CL-SDL. If you Google for Lisp OpenGL bindings, you will find
there is actually a selection to choose from out there. Of course the
commercial Lisps have bindings as well. OpenMCL's FFI gives you
direct access to OpenGL APIs on the Mac. I've even created my own
UFFI targeted OpenGL bindings for OS X (only tested on OpenMCL so far
and not really completed in terms of clean up and such).
OpenGL is hardly new ground for Lisp.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
David Steuber <·····@david-steuber.com> writes:
> CLOS is different. CLOS is Reformed OOP and thus more flexible. CLOS
> is very much worth learning. Peter's PCL book talks about CLOS more
> than Graham or Norvig. Keene's book is the definitive tutorial. Buy
> it. Read it.
Hmm...
Sounds tempting.
Amazon says about the Keene book:
"$34.53 & This item ships for FREE with Super Saver Shipping."
Not too expensive.
vermicule wrote:
> Amazon says about the Keene book:
> "$34.53 & This item ships for FREE with Super Saver Shipping."
>
> Not too expensive.
Recommended!
Paul
David Steuber wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>
>>Alexander Repenning wrote:
>>
>>>As instructor I would need a textbook. That textbook could not be ABOUT
>>>Lisp but it could use Lisp. As much as I would want to I cannot offer a
>>>Lisp course. But I can offer a OOP course or game design course. Both
>>>could use Lisp. But what textbook could I use? Many textbooks (e.g., On
>>>Lisp, Ansi Common Lisp) are written by folks who officially hate OOP.
>>
>>And they're dead right, IMHO. CLOS might be different, though (have
>>to learn it yet), and I don't consider it orthodox OOP.
>
>
> CLOS is different. CLOS is Reformed OOP and thus more flexible. CLOS
> is very much worth learning. Peter's PCL book talks about CLOS more
> than Graham or Norvig. Keene's book is the definitive tutorial. Buy
> it. Read it.
>
>
It strikes me that learning about OOP throug CL would be GREAT! You
could demonstrate various styles of OOP, different styles of CLOS (i.e.
use the MOP), various other object systems for CL (flavours), and even
use macrology to mimic the Java and C++ characteristics. Endless
opportunity to "compare and contrast". How about writing a book about
different OO styles, using CL to implement them all? CL would be the
ONLY language that could pull it off!
Using ONE language with all the styles would force students to look
beyond the surface to see the real differences in the various styles.
Maybe have different groups solving the same (largish) task using a
different set off OO tools, and have them compare their
results/difficulties.
Ulrich Hobelmann <···········@web.de> writes:
>> In some sense I cannot blame these students.
>
> You don't blame them for choosing one language over another based on
> the shininess of the GUI instead of the language's capabilities?
The same thing is happening with todays undergraduates but with Haskell
in the role of Lisp.
Haskell is a language of great beauty and power.
However, after a first year exposure to it in a programming 101
class( followed by years of Java ), the kids hate it since they think that
it is worthless ( because they do only elementary first year things with it)
and because hugs and ghc have pretty basic ides.
In addition, they think of it as a "1st year language".
vermicule wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>
>>>In some sense I cannot blame these students.
>>
>>You don't blame them for choosing one language over another based on
>>the shininess of the GUI instead of the language's capabilities?
>
>
> The same thing is happening with todays undergraduates but with Haskell
> in the role of Lisp.
True.
> Haskell is a language of great beauty and power.
Also true.
> However, after a first year exposure to it in a programming 101
> class( followed by years of Java ), the kids hate it since they think that
> it is worthless ( because they do only elementary first year things with it)
> and because hugs and ghc have pretty basic ides.
I've read somewhere about someone using Haskell in a first
semester course, which gradually introduced functional
programming, and *in the end* imperative programming with monads.
Sounded great.
I'm one of those people who are still somewhat clueless about
monads, and I prefer strict languages, also for memory and
efficiency (and FFIs).
And I love macros ;)
> In addition, they think of it as a "1st year language".
Maybe the world needs some demos how to write really cool stuff in
hOpenGL...
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Martha Stewart called it a Good Thing when vermicule <······@bigpond.net.au> wrote:
> The same thing is happening with todays undergraduates but with Haskell
> in the role of Lisp.
>
> Haskell is a language of great beauty and power.
>
> However, after a first year exposure to it in a programming 101
> class( followed by years of Java ), the kids hate it since they think that
> it is worthless ( because they do only elementary first year things with it)
> and because hugs and ghc have pretty basic ides.
>
> In addition, they think of it as a "1st year language".
The do "only elementary first year things" thing seems to be quite a
common problem.
Everyone here is aware of how it's a problem with Lisp, where people
come away with such impressions as:
- Lisp is all about doing things with lists.
- Lisp is _terrible_, what with fighting with c[ad]*r functions.
- Lisp is all about recursion.
- Ewww! What's with the stupid parentheses?!?
If you restrict learning to the "elementary first year things," these
are all true statements. They are also equally true whether talking
of Common Lisp or Scheme, and affectations otherwise are futile.
I regret that when in school I only saw the "elementary first year
stuff" in Prolog. I wish I knew more of it... Taking it a step
further, I have been building tax formulae over the last couple years
such that I have a "tax calculator" that is more than sophisticated
enough to do my tax return, if not to "NetFile" it. And I daresay for
the tax application, I prefer Prolog to Lisp. I just wish I knew a
bit more Prolog as that would probably let me do the job with greater
elegance.
ML and Haskell look as though they have the potential to be quite a
lot nicer to work with than the 'traditional' languages, but again, it
tends to prove difficult to get decent references to do other than
variations on the "futile elementary first year things."
It's good news for Common Lisp that there is new literature coming out
like PCL. That's the sort of thing to help push past the "futile
elementary things."
--
"cbbrowne",·@","ntlug.org"
http://cbbrowne.com/info/emacs.html
Rules of the Evil Overlord #10. "I will not interrogate my enemies in
the inner sanctum -- a small hotel well outside my borders will work
just as well." <http://www.eviloverlord.com/>
Ulrich Hobelmann wrote:
> CLOS != what other people consider OOP (since they only know one
> or two C dialects, or maybe Smalltalk)
It's different but I think I could have my students learn CLOS. In
previous versions of my OOP and Game design courses I used Java and
C++. Pedagogically speaking the Java coding was much cleaner but the
results were often disappointing especially in terms of stability.
GL4Java was a mess. C++ with Visual Studio worked but, to my surprise,
most students did not like C++. They see it as something that is good
to know for the real world but only few of them could develop real
excitement.
>
> > When I show OpenGL + Lisp in my game design courses that really
gets
> > students excited. Now the question is who is going to write a nice
book
> > on making games (with OOP) in Lisp?
>
> What OpenGL is that? Are the binding cross-platform (especially
Mac)?
We have our own: http://agentsheets.com/lisp/OpenGL.html Meanwhile,
and with the friendly help from Franz we also have a simple version for
ACL. OpenGL alone is too low level. You need to have texture, model
loaders and many more things which are not part of OpenGL. Our code
includes a simple game engine with CLOS wrappers (windows, events,
mouse) and QuickTime interface (textures, images, sounds). The Mac
version has more stuff including gamepad, joystick, and 3D drag and
drop. This will be fun to port ;-)
In a previous version of the course we had a much simpler game engine
in C++. It worked well enough to have all the teams produce some pretty
nice games and learn a lot about OOP. Now we have more functionality in
Lisp but need additional support. The OpenGL Red Book will do as
graphics book. The Sonya Keen book for CLOS may do the trick. I feels a
little dated. Most of the Red book examples are straight forward to
code in Lisp. The trickier part is to get Lisp vendors to support this
kind of activity. Most either offer some student version which is not
really that cheap or some kind of education site license. Compare this
to the free version of Visual Studio that MS offers to each student. I
want to use OS X/MCL/Digitool and Windows/ACL/Franz (because we have
the code). Personally, I think both companies, or Lisp companies in
general, would benefit from offering a FREE one semester/course
license. If I can have student hack on games for an entire semester
using Lisp and in the end they still hate Lisp then I just don't know
what to do. I am pretty sure this would work and the free copies would
be a good investment. Franz, Digitool... are you listening?
"Alexander Repenning" <·····@cs.colorado.edu> writes:
> the code). Personally, I think both companies, or Lisp companies in
> general, would benefit from offering a FREE one semester/course
> license. If I can have student hack on games for an entire semester
Maybe Franz did/does something like that. Several months ago, at a
Franz event, attendees were given a CD with a full[*] Allegro CL and a
limited-time license (around 3-6 months, if I recall correctly). You
might try negotiating a similar deal.
Paolo
[*] It was for Windows only and I have Linux, so I couldn't check.
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: André Thieme
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <d4mfuu$a6l$2@ulric.tng.de>
Paolo Amoroso schrieb:
> "Alexander Repenning" <·····@cs.colorado.edu> writes:
>
>
>>the code). Personally, I think both companies, or Lisp companies in
>>general, would benefit from offering a FREE one semester/course
>>license. If I can have student hack on games for an entire semester
>
>
> Maybe Franz did/does something like that. Several months ago, at a
> Franz event, attendees were given a CD with a full[*] Allegro CL and a
> limited-time license (around 3-6 months, if I recall correctly). You
> might try negotiating a similar deal.
You probably know that: Franz also offers Allegro 7.0 for students for
99$. This version looks complete to me and it runs two years.
Andr�
--
Do you have any sample Lisp code out there showing how to implement
b-splines and surfaces? I've tried a couple of times myself but the
results are always very app-specific. -M
"Alexander Repenning" <·····@cs.colorado.edu> writes:
> As instructor I would need a textbook. That textbook could not be ABOUT
> Lisp but it could use Lisp. As much as I would want to I cannot offer a
> Lisp course. But I can offer a OOP course or game design course. Both
> could use Lisp. But what textbook could I use? Many textbooks (e.g., On
> Lisp, Ansi Common Lisp) are written by folks who officially hate OOP.
> This does not work for me. I need a Lisp book written by somebody who
> likes OOP/CLOS and actually uses it. PCL looks like a good book. I
> could use that for graduate student learning Lisp as part of research
> project but it would not work for most of my courses.
>
> When I show OpenGL + Lisp in my game design courses that really gets
> students excited. Now the question is who is going to write a nice book
> on making games (with OOP) in Lisp?
Given your experience, you might consider submitting to Apress a
proposal for writing such a book yourself.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> writes:
> Given your experience, you might consider submitting to Apress a
> proposal for writing such a book yourself.
Excellent idea.
I know that I certainly would buy two copies of the book.
(One for myself and one for my children)
"Alexander Repenning" <·····@cs.colorado.edu> writes:
> nikhilketkar wrote:
>
> > People are so against LISP. How to change their minds??
>
> Teaching at an university and programming in Lisp since the 70ies I
> find that most people learned to dislike Lisp as ugrad during a
> "programming languages" course. Before that they were pretty neutral.
Blame SICP? Some of the myths I hear seem to be rooted in the small
subset of Scheme that is called Lisp. But there are some cool things
in that book, so it's probably the presentation, not the book.
> These course introduce students, in quick succession, to a number of
> programming languages including Lisp. The Lisp part usually is based on
> using some old computer in the basement or by downloading some free
> Lisp. Then they do the car/cdr and some quick recursion hack. After
> that they either hate Lisp or at least see no value in it. The same
> students all get Visual Studio DVDs from Microsoft for free. When they
> compare the two they conclude Lisp is from the dark ages and is just
> one small step up from punch cards.
Those punch cards keep clogging up my DVD drive. Xcode is fairly
attractive on the Mac side of life. So yes, there is some competition
there. Appearance does matter.
> As instructor I would need a textbook. That textbook could not be ABOUT
> Lisp but it could use Lisp. As much as I would want to I cannot offer a
> Lisp course. But I can offer a OOP course or game design course. Both
> could use Lisp. But what textbook could I use? Many textbooks (e.g., On
> Lisp, Ansi Common Lisp) are written by folks who officially hate OOP.
> This does not work for me. I need a Lisp book written by somebody who
> likes OOP/CLOS and actually uses it. PCL looks like a good book. I
> could use that for graduate student learning Lisp as part of research
> project but it would not work for most of my courses.
An OOP book that uses CLOS but is not about Lisp? Tricky. In the
meantime:
Object-Oriented Programming in Common Lisp
A Programmer's Guide to CLOS
Sonja E. Keene
Addison-Wesley
0-201-17589-4
The Art of the Metaobject Protocol
Gregor Kiczales &
Jim des Rivieres &
Daniel G. Bobrow
The MIT Press
0-262-61074-4
> When I show OpenGL + Lisp in my game design courses that really gets
> students excited. Now the question is who is going to write a nice book
> on making games (with OOP) in Lisp?
You just volunteered. Get to work! Don't forget to setup a website
with the rough drafts.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
From: Florian Weimer
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <87vf6a3d4p.fsf@deneb.enyo.de>
* Alexander Repenning:
> The same students all get Visual Studio DVDs from Microsoft for
> free. When they compare the two they conclude Lisp is from the dark
> ages and is just one small step up from punch cards.
This doesn't explain why Lisp isn't well-received by the free software
crowed, either.
Why are so few system administrators using Lisp as a gluing language,
or the language of choice for throw-away programs? Hardly anybody
writes small network servers in it, either.
Florian Weimer wrote:
> * Alexander Repenning:
>
>
>>The same students all get Visual Studio DVDs from Microsoft for
>>free. When they compare the two they conclude Lisp is from the dark
>>ages and is just one small step up from punch cards.
>
>
> This doesn't explain why Lisp isn't well-received by the free software
> crowed, either.
>
> Why are so few system administrators using Lisp as a gluing language,
> or the language of choice for throw-away programs? Hardly anybody
> writes small network servers in it, either.
The interesting things (sockets, threads) are not standardized.
Creating compact executables that you can copy to /usr/local/bin
isn't exactly easy or even possible. For other languages you have
the language (because there's one de-facto standard
implementation) installed, or even just compile the program and
you're done.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
From: Christopher C. Stacy
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <uy8b6bnw1.fsf@news.dtpq.com>
Ulrich Hobelmann <···········@web.de> writes:
> Florian Weimer wrote:
> > * Alexander Repenning:
> > Why are so few system administrators using Lisp as a gluing language,
> > or the language of choice for throw-away programs? Hardly anybody
> > writes small network servers in it, either.
>
> The interesting things (sockets, threads) are not standardized.
Is it common for system adminstrators write glue scripts that do threads?
For that matter, do those folks do a lot of sockets programming?
(Perhaps I misconstrue what you mean by "system administrator",
but neither of those is true in my extensive experience.
Could you please provide some typical examples?)
Anyway, it's true that the network sockets interface is no more
standardized than it is in, say, Perl. In Lisp, you could either
call the vendor-specific networking interface (if you're just going
to stick with, say, CLISP), or you could decide to use one of the
portable standard networking libraries.
> Creating compact executables that you can copy to
> /usr/local/bin isn't exactly easy or even possible.
In what way is it not easy? On my machine, I just put the
usual "#!" thingie at the front of my Lisp source code file.
Christopher C. Stacy wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>
>>Florian Weimer wrote:
>>
>>>* Alexander Repenning:
>>>Why are so few system administrators using Lisp as a gluing language,
>>>or the language of choice for throw-away programs? Hardly anybody
(I was commenting on the line that follows.)
>>>writes small network servers in it, either.
>>
>>The interesting things (sockets, threads) are not standardized.
>
>
> Is it common for system adminstrators write glue scripts that do threads?
> For that matter, do those folks do a lot of sockets programming?
> (Perhaps I misconstrue what you mean by "system administrator",
> but neither of those is true in my extensive experience.
> Could you please provide some typical examples?)
> [...]
>>Creating compact executables that you can copy to
>>/usr/local/bin isn't exactly easy or even possible.
>
>
> In what way is it not easy? On my machine, I just put the
> usual "#!" thingie at the front of my Lisp source code file.
Oh, sure, people could do it. I'm just starting to look at Lisp.
I hope the Unix system functions (well, file and directory
manipulation) are good, so I can use it for everything :)
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Christopher C. Stacy wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>
>>Florian Weimer wrote:
>>
>>>* Alexander Repenning:
>>>Why are so few system administrators using Lisp as a gluing language,
>>>or the language of choice for throw-away programs? Hardly anybody
>>>writes small network servers in it, either.
>>
>>The interesting things (sockets, threads) are not standardized.
>
>
> Is it common for system adminstrators write glue scripts that do threads?
> For that matter, do those folks do a lot of sockets programming?
> (Perhaps I misconstrue what you mean by "system administrator",
> but neither of those is true in my extensive experience.
> Could you please provide some typical examples?)
I didn't need a book to write an awk script. "man awk" gave me
everything I needed to know. Same can be said for tcsh and bash. A
script programmer can get just about everything they need to know from
"man tcsh" or "man bash".
There's little returned in "man clisp" that indicates how to easily
access environment variables, iterate through files, loop through a
pattern glob, code conditional statements, declare variables, set their
values, etc.
Thomas Gagne <······@wide-open-west.com> writes:
>I didn't need a book to write an awk script. "man awk" gave me
I must admit, though, that for me O'Reilly's sed+awk book was a lot
better introduction than the man page.
My prime example is the ksh93 book ("The New KornShell Command and
Programming Language", by Morris Bolsky and David Korn; yes, I've
bought it, although it was pretty expensive for what is mostly a
reference book.)
When you thoroughly check against the ksh93 manpage, you'll find
(almost) everything in there.
But you would never know, had you not read the book before.
So, I'd say, manual pages are only for a short introduction, including
the command invocation interface, a short explanation and a reference
to full documentation. You simply cannot document clisp entirely in
the manpage. This would include a complete ANSI Common Lisp
reference.
mkb.
Matthias Buelow wrote:
<snip>
>
>
> I must admit, though, that for me O'Reilly's sed+awk book was a lot
> better introduction than the man page.
>
> My prime example is the ksh93 book ("The New KornShell Command and
> Programming Language", by Morris Bolsky and David Korn; yes, I've
> bought it, although it was pretty expensive for what is mostly a
> reference book.)
>
> When you thoroughly check against the ksh93 manpage, you'll find
> (almost) everything in there.
>
> But you would never know, had you not read the book before.
>
> So, I'd say, manual pages are only for a short introduction, including
> the command invocation interface, a short explanation and a reference
> to full documentation. You simply cannot document clisp entirely in
> the manpage. This would include a complete ANSI Common Lisp
> reference.
That's true, but misses the point. When people are simply investigating
the candidates for a quick-n-dirty job they're unlikely to purchase
books. They'll evaluate the man page and play with it. They'll try
some of the examples.
As you indicated, sed, awk, and ksh are best documented in books, but
we're not talking about the best documentation, we're talking about
basic introductory tasks for everyday use.
Thomas Gagne <······@wide-open-west.com> writes:
> [...]
> That's true, but misses the point. When people are simply
> investigating the candidates for a quick-n-dirty job they're unlikely
> to purchase books. They'll evaluate the man page and play with it.
> They'll try some of the examples.
>
> As you indicated, sed, awk, and ksh are best documented in books, but
> we're not talking about the best documentation, we're talking about
> basic introductory tasks for everyday use.
The main advantage of man, is that it's one common place to look for
documentation. GNU breaks this with its info(1). The web breaks it
even more with the ease of publishing documentation on it.
Perhaps the solution would be to replace man(1) with a wrapper that'd
search the data in the man page, the info files and the web and
display whatever it'd find.
lynx -dump http://clisp.cons.org/impnotes.html
is as good as:
man clisp
or as:
info emacs
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
From: Karl A. Krueger
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <d4m3ch$gr6$1@baldur.whoi.edu>
Pascal Bourguignon <···@informatimago.com> wrote:
> Thomas Gagne <······@wide-open-west.com> writes:
>> As you indicated, sed, awk, and ksh are best documented in books, but
>> we're not talking about the best documentation, we're talking about
>> basic introductory tasks for everyday use.
>
> The main advantage of man, is that it's one common place to look for
> documentation. GNU breaks this with its info(1). The web breaks it
> even more with the ease of publishing documentation on it.
GNU _does_ break the "man" convention with info, but neither "man gcc"
nor "info gcc" will teach you how to program in C. :)
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
From: Florian Weimer
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <87k6mq1q8c.fsf@deneb.enyo.de>
* Christopher C. Stacy:
> Is it common for system adminstrators write glue scripts that do
> threads?
No, absolutely not.
> For that matter, do those folks do a lot of sockets programming?
Not directly, either.
> (Perhaps I misconstrue what you mean by "system administrator",
> but neither of those is true in my extensive experience.
> Could you please provide some typical examples?)
Scripts invoked by inetd are fairly common, for example special WHOIS
or finger daemons, or something involving a custom query language.
Note that you don't need socket support because inetd takes care of
the details.
> Anyway, it's true that the network sockets interface is no more
> standardized than it is in, say, Perl. In Lisp, you could either
> call the vendor-specific networking interface (if you're just going
> to stick with, say, CLISP), or you could decide to use one of the
> portable standard networking libraries.
Correct, there isn't much difference.
>> Creating compact executables that you can copy to
>> /usr/local/bin isn't exactly easy or even possible.
>
> In what way is it not easy? On my machine, I just put the
> usual "#!" thingie at the front of my Lisp source code file.
Well, it depends. Your Lisp implementation must compile your Lisp
script fast enough, otherwise this isn't satisfactory if you invoke
the script in a closed loop.
However, you still have to figure out how to access the argument
vector, and how to prevent the Lisp system from entering the debugger
on failure. 8-)
From: Christopher C. Stacy
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <u8y36bjyb.fsf@news.dtpq.com>
Florian Weimer <··@deneb.enyo.de> writes:
> Well, it depends. Your Lisp implementation must compile your Lisp
> script fast enough, otherwise this isn't satisfactory if you invoke
> the script in a closed loop.
This is true for all languages. Is there some reason to believe that
the existing implementations of Lisp are defficient in this regard?
> However, you still have to figure out how to access the argument
> vector, and how to prevent the Lisp system from entering the debugger
> on failure. 8-)
If by "figure out how to" you mean "read the documentation",
and "prevent the Lisp system from entering the debugger"
you mean "read the documentation", then yes, those are issues.
From: Florian Weimer
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <87is2azcab.fsf@deneb.enyo.de>
* Christopher C. Stacy:
> Florian Weimer <··@deneb.enyo.de> writes:
>
>
>> Well, it depends. Your Lisp implementation must compile your Lisp
>> script fast enough, otherwise this isn't satisfactory if you invoke
>> the script in a closed loop.
>
> This is true for all languages.
It's less an issue if you can easily create precompiled executables. 8-)
> Is there some reason to believe that the existing implementations of
> Lisp are defficient in this regard?
CLISP is fast enough, SBCL definitely isn't unless you have fast
hardware. I used to generate DNS zone files using a Lisp program, and
it was okay with CLISP, but a bit painful with SBCL (compilation took
much longer than actual execution).
>> However, you still have to figure out how to access the argument
>> vector, and how to prevent the Lisp system from entering the debugger
>> on failure. 8-)
>
> If by "figure out how to" you mean "read the documentation",
> and "prevent the Lisp system from entering the debugger"
> you mean "read the documentation", then yes, those are issues.
I did. It was not documented back then. I didn't take CLISP for full
(which was a mistake), and SBCL didn't have the nice explanation at:
<http://www.sbcl.org/manual/Unix-style-Command-Line-Protocol.html>
(Which should probably mention SB-EXT:*POSIX-ARGV*, by the way.)
From: Christopher C. Stacy
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <uvf6a9nu0.fsf@news.dtpq.com>
Florian Weimer <··@deneb.enyo.de> writes:
> CLISP is fast enough, SBCL definitely isn't unless you have fast
> hardware. I used to generate DNS zone files using a Lisp program, and
> it was okay with CLISP, but a bit painful with SBCL (compilation took
> much longer than actual execution).
But you only compile the program once, and then run it
many times, right? The executable program is compiled,
and then installed into /usr/local/bin or wherever.
What does it matter if compilation takes a few seconds
(or minutes, for that matter)?
> >> However, you still have to figure out how to access the argument
> >> vector, and how to prevent the Lisp system from entering the debugger
> >> on failure. 8-)
> >
> > If by "figure out how to" you mean "read the documentation",
> > and "prevent the Lisp system from entering the debugger"
> > you mean "read the documentation", then yes, those are issues.
>
> I did. It was not documented back then. I didn't take CLISP for full
> (which was a mistake), and SBCL didn't have the nice explanation at:
>
> <http://www.sbcl.org/manual/Unix-style-Command-Line-Protocol.html>
Good to know that the documentation is getting better.
> (Which should probably mention SB-EXT:*POSIX-ARGV*, by the way.)
You should send their doc writers a note, I guess.
From: Stefan Nobis
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <87y8b6vw7c.fsf@snobis.de>
Florian Weimer <··@deneb.enyo.de> writes:
>> Anyway, it's true that the network sockets interface is no more
>> standardized than it is in, say, Perl. In Lisp, you could either
>> call the vendor-specific networking interface (if you're just going
>> to stick with, say, CLISP), or you could decide to use one of the
>> portable standard networking libraries.
> Correct, there isn't much difference.
With one imporant exception: If there's only one implementation,
then everything (produced for the language, like special
libraries) will fit with this single implementation. But in the
case of many different implementations with different extensions,
not every library out there will play nice with every
implementation.
So you may choose implementation A for the very good extension for
say socket programming but then you need library X and it don't
work with implementation A but only with B and C (UFFI and non-CVS
CLisp may be an example, and i think there are more).
In short: Perl, Python (and the like) have a little advantage in
this field.
--
Stefan.
From: Christopher C. Stacy
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <upswhjv0i.fsf@news.dtpq.com>
Stefan Nobis <······@gmx.de> writes:
> Florian Weimer <··@deneb.enyo.de> writes:
>
> >> Anyway, it's true that the network sockets interface is no more
> >> standardized than it is in, say, Perl. In Lisp, you could either
> >> call the vendor-specific networking interface (if you're just going
> >> to stick with, say, CLISP), or you could decide to use one of the
> >> portable standard networking libraries.
>
> > Correct, there isn't much difference.
>
> With one imporant exception: If there's only one implementation,
> then everything (produced for the language, like special
> libraries) will fit with this single implementation. But in the
> case of many different implementations with different extensions,
> not every library out there will play nice with every
> implementation.
That's true, you need to read the documentation cover page
for the library to see which Lisp platforms it runs on.
(Of course, it's also possible to write Perl libraries
that will only work on Windows, etc.)
From: Edi Weitz
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <ufyxe7825.fsf@agharta.de>
On Mon, 25 Apr 2005 14:52:35 -0500, Ulrich Hobelmann <···········@web.de> wrote:
> Creating compact executables that you can copy to /usr/local/bin
> isn't exactly easy or even possible.
<http://www.cons.org/cmucl/doc/executable.html>
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Mon, 25 Apr 2005 14:52:35 -0500, Ulrich Hobelmann <···········@web.de> wrote:
>
>
>>Creating compact executables that you can copy to /usr/local/bin
>>isn't exactly easy or even possible.
>
>
> <http://www.cons.org/cmucl/doc/executable.html>
>
Nice. It would be cool to have a portable (platform, not
necessarily Lisp, unless .fasls are standardized) way to have a
little C program load code and dump an (enhanced) executable, much
like Emacs AFAIK eats Lisp files and dumps the final executable.
Anyway, for my purposes CLisp and #! will be fine.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Ulrich Hobelmann wrote:
[...]
> Creating compact executables that you can copy to /usr/local/bin
> isn't exactly easy or even possible.
False and false. CLISP offers the easiest replacement for
/bin/sh scripts, but it's possible with CMUCL and SBCL as well.
My master /usr/local/bin contains over 78 CLISP scripts at this
time.
> For other languages you have
> the language (because there's one de-facto standard
> implementation) installed, or even just compile the program and
> you're done.
>
Like Perl? Really. You mean every one of the 37 servers I manage
has all of CPAN installed? Well. Screw CLISP. Larry's my daddy.
Florian Weimer <··@deneb.enyo.de> writes:
> Why are so few system administrators using Lisp as a gluing language,
> or the language of choice for throw-away programs?
There are large amounts of material on using Perl and python as
systems admin glue. Where is the material on using Lisp in a similar role ?
From: Christopher C. Stacy
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <ud5sibk3w.fsf@news.dtpq.com>
vermicule <······@bigpond.net.au> writes:
> Florian Weimer <··@deneb.enyo.de> writes:
>
> > Why are so few system administrators using Lisp as a gluing language,
> > or the language of choice for throw-away programs?
>
> There are large amounts of material on using Perl and python as
> systems admin glue. Where is the material on using Lisp in a similar role ?
I am not necessarily disputing the idea that there might be some
missing educational resources, but I don't believe that we've
established in this conversation what this "role" is supposed to be.
There are web sites like "The Common Lisp Cookbook", which shows
how to do regexps, file IO, sockets, threads, and other things.
There's the book "Practical Common Lisp" that teaches basic
Lisp programming and shows how to write network servers.
There's both the CLiki and the hyper-cliki.
The question you posed was, "Why are so few [people]...?" and
the assertion that "Hardly anybody...". Probably the answer
is that most people don't know Lisp and have no interest in it,
and most Lisp programmers just don't really care about writing
the kind of programs that you're asking about.
On Mon, 25 Apr 2005 21:51:47 GMT, ······@news.dtpq.com (Christopher
C. Stacy) wrote:
>The question you posed was, "Why are so few [people]...?" and
>the assertion that "Hardly anybody...". Probably the answer
>is that most people don't know Lisp and have no interest in it,
>and most Lisp programmers just don't really care about writing
>the kind of programs that you're asking about.
Probably because to be employable one must have Perl (and Python,
Java, C, C++) on the resume. I have never seen employer that is
looking for somebody who knows Lisp. People know this quite well and
invest their monies/time to study thingks that incerase their value
on job market. Who cares about Lisp?...
A.L.
A.L. <·················@hotfuck.com> writes:
> Who cares about Lisp?
We do :-)
But many of us also care about Bach, Haskell, cats, Ocaml and
the play of light on autumn leaves, none of which enhances our employability.
But they certainly enhance our lives :-)
On Tue, 26 Apr 2005 00:34:18 GMT, vermicule <······@bigpond.net.au>
wrote:
>A.L. <·················@hotfuck.com> writes:
>
>> Who cares about Lisp?
>
>We do :-)
>
>But many of us also care about Bach, Haskell, cats, Ocaml and
>the play of light on autumn leaves, none of which enhances our employability.
>
>But they certainly enhance our lives :-)
Who cares about the quality of live?... I do care about paying my
mortgage, having health insurance and about many other things that
can be only purchased with real, green dollars.
I started buying lottery tickets. When I win, I will have time to
play with Lisp...
A.L.
A.L. wrote:
> Who cares about the quality of live?... I do care about paying my
> mortgage, having health insurance and about many other things that
> can be only purchased with real, green dollars.
>
> I started buying lottery tickets. When I win, I will have time to
> play with Lisp...
If you cared about saving money for when you're old, you'd invest
the lottery money in stocks or bonds with a much higher return on
investment over the next 10 years ;)
Miracles don't just happen like that. You're more easily hit by
lightning!
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
On Tue, 26 Apr 2005 08:08:01 -0500, Ulrich Hobelmann
<···········@web.de> wrote:
>A.L. wrote:
>> Who cares about the quality of live?... I do care about paying my
>> mortgage, having health insurance and about many other things that
>> can be only purchased with real, green dollars.
>>
>> I started buying lottery tickets. When I win, I will have time to
>> play with Lisp...
>
>If you cared about saving money for when you're old, you'd invest
>the lottery money in stocks or bonds with a much higher return on
>investment over the next 10 years ;)
>
>Miracles don't just happen like that. You're more easily hit by
>lightning!
Well.... Too late for me.... Lottery is the only chance...
A.L.
A.L. <·················@hotfuck.com> writes:
>>But many of us also care about Bach, Haskell, cats, Ocaml and
>>the play of light on autumn leaves, none of which enhances our employability.
>>But they certainly enhance our lives :-)
>
> Who cares about the quality of live?... I do care about paying my
> mortgage, having health insurance and about many other things that
> can be only purchased with real, green dollars.
A friend once said ," Money is like sex. People think that it is important
only if they arent getting enough of it."
Because of Lisp ( see , it is good for something:-) ) and other things, I am in a fortunate position
where money is not an issue any more.
The problem is that quality of life, relationship, existential and philosophical issues then come up.
These problems are rather more difficult to solve. Throwing dollars at them does nothing
to solve them.
Quality of life is one of the more tractable of these problems.
The relationship issues are much harder but can be dealt with.
The philosophical issues are truly intractable and are probably best dealt with
using Candide's approach," Let us go work in the garden"
or Wittgenstein's approach,"My propositions are elucidatory in this way:
he who understands me finally recognizes them as senseless,
when he has climbed out through them, on them, over them.
(He must so to speak throw away the ladder, after he has climbed up on it.)"
vermicule wrote:
> A friend once said ," Money is like sex. People think that it is important
> only if they arent getting enough of it."
Might be true. I think both are somewhat important.
> Because of Lisp ( see , it is good for something:-) ) and other things, I am in a fortunate position
> where money is not an issue any more.
What do you do? Contract-based development? "Consulting?" Where
and how?
> The problem is that quality of life, relationship, existential and philosophical issues then come up.
> These problems are rather more difficult to solve. Throwing dollars at them does nothing
> to solve them.
It's just two different classes of problems; one requires money,
while the philosophical problem requires, hm, maybe philosophy.
After almost a decade of doing nothing but thinking I think I've
found all the philosophical answers I'll ever need in life. So
now I think I'll go find some money and start living ;)
> Quality of life is one of the more tractable of these problems.
True. And it works without much money, too. But I'd still like
more of it (money).
> The relationship issues are much harder but can be dealt with.
Yep.
> The philosophical issues are truly intractable and are probably best dealt with
> using Candide's approach," Let us go work in the garden"
> or Wittgenstein's approach,"My propositions are elucidatory in this way:
> he who understands me finally recognizes them as senseless,
> when he has climbed out through them, on them, over them.
> (He must so to speak throw away the ladder, after he has climbed up on it.)"
Hm, that's too high for me. I've decided that all philosophy is
just people talking about stuff that doesn't in the least affect
my life anyway.
I've been to brainland, returned and threw away the ladder, cause
I don't plan to go there ever again ;)
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
On Mon, 25 Apr 2005 18:25:39 -0500, A.L wrote:
> On Mon, 25 Apr 2005 21:51:47 GMT, ······@news.dtpq.com (Christopher C.
> Stacy) wrote:
>
>
>>The question you posed was, "Why are so few [people]...?" and the
>>assertion that "Hardly anybody...". Probably the answer is that most
>>people don't know Lisp and have no interest in it, and most Lisp
>>programmers just don't really care about writing the kind of programs
>>that you're asking about.
>
> Probably because to be employable one must have Perl (and Python, Java,
> C, C++) on the resume. I have never seen employer that is looking for
> somebody who knows Lisp. People know this quite well and invest their
> monies/time to study thingks that incerase their value on job market.
> Who cares about Lisp?...
>
> A.L.
[ISBN:0-8493-1489-5]
" The Future of software Development
The problem with most coding languages is that they are domain non-
specihc. We can use C++ to write a payroll system and write a machine
control function. The language neither knows nor cares which you are
writing (with the exception, of course, of the data typing enforced by
the object classes and methods used, and the presence or absence of
specihc function libraries). Because the language has no insight into
what you are doing, it cannot help you do it. Packages such as SAP do not
have this limitation. They "know," within quite a narrow range, what you
are trying to do, and can be very helpful in directing you. We could
write a device driver or a paper report using an assembly language.
Crystal ReportsTM" is very good at writing reports but could not be used
for creating a device driver. This apparent "limitation" of the Crystal
Reports language is, of course, nothing of the sort because we would
never consider trying to use the tool to write a device driver in the
first place. Because Crystal Reports is highly conversant within the
domain of report writing (read: contains a lot of knowledge of the
activity of report writing), it is able to both recognize what we are
trying to do and greatly assist us in it. Domain nonspecihc languages do
not.
One of the reasons for the present-day prolieration of languages is that
each language carries with it a certain degree of domain specificness.
Even the most domain-free languages tend to have some bias toward a
flavor of processing - assembly languages map closely to the processor,
HTML maps closely to the physical nature of the screen presentation of
text, many scripting languages are designed for string and regular
expression manipulation, etc. These languages tend to attract their quota
of adherents who can become quite vocal in their support of their version
of the one true language. The reason for the certain degree of chauvinism
that seems to accompany the enthusiasm is that through repeated use the
language becomes peoples' way of thinking. Naturally, because they have
started to think using the language constructs and structure, they tend
to be highly effective using it, and the language seems very logical to
them. Some of the brightest minds of the 20th century such as Minsky,**,
Bohm and Peat,*** and Weiner**** have shown just how dependent the view
of the problem is on the language we use to express it. But it seems that
along with the facility comes a certain amount o tunnel vision on the
subject. That said, one of the realities of many current projects is that
they are routinely pr grammed in a variety of programming languages and
approaches. This
*A product of the Crystal Decisions Company. ""For instance the
"interpreted operation" in Matter, Mind, and Models, by Marvin Minsky,
Proc. Int.. Fed. Inf. Process. Cong., 1965, Vol. l, pp. 45-49. """In
Science, Order, and Creativity, by David Bohm and David F. Peat, Bantam
Books, New York, 1987.
""""Weiner observed that learning in humans is a Function of language in
Cybernetics, or Con- trol and Communication in the Animal and the
Machine, MIT Press, Cambridge, Massachusetts, 1948/1961." (OCR errors
mine)
.
.
······@news.dtpq.com (Christopher C. Stacy) writes:
> There are web sites like "The Common Lisp Cookbook", which shows
> how to do regexps, file IO, sockets, threads, and other things.
I didnt know about that.
I knew about the Perl Cookbook, the Ruby cookbook and even the Scheme Cookbook
at schematics.org. However, I did know about the Lisp version until just now.
I have had a quick look at it between sentences :-) and it looks fine.
> There's the book "Practical Common Lisp" that teaches basic
> Lisp programming and shows how to write network servers.
And it is an excellent book.
However it was published in 2005 ( admittedly it has been online for much longer.
From: Florian Weimer
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <87mzrm1qnp.fsf@deneb.enyo.de>
* > Florian Weimer <··@deneb.enyo.de> writes:
>
>> Why are so few system administrators using Lisp as a gluing language,
>> or the language of choice for throw-away programs?
>
> There are large amounts of material on using Perl and python as
> systems admin glue. Where is the material on using Lisp in a similar role ?
I think CLISP was already quite mature when Python was not a serious
contender to Perl in sysadmin scripting. So the question is: Why were
resources create for Python, and increasingly for PHP (!) and Ruby,
but not for Lisp?
I think Matthias' conjecture that Lisp implementators dislike the
C/UNIX environment and therefore want to suck as much as possible into
the Lisp image might explain the sorry state of affairs.
Florian Weimer <··@deneb.enyo.de> writes:
> I think Matthias' conjecture that Lisp implementators dislike the
> C/UNIX environment and therefore want to suck as much as possible into
> the Lisp image might explain the sorry state of affairs.
Do Lisp implementors dislike Unix/Posix?
http://www.cliki.net/Common-Lisp-POSIX
http://www.cliki.net/cirCLe
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> writes:
> Do Lisp implementors dislike Unix/Posix?
I can't answer for all Lisp implementors (indeed, given the amount of
actual hackiung I've done lately I'm not sure I qualify to answer for
any Lisp implementors at all) but I'm certainly not blind to its weak
spots. The trouble is that all the alternatives readily available to
me are worse.
> http://www.cliki.net/Common-Lisp-POSIX
TTBOMK that's vapourware, and whatever CLiki may say about the
date on it, it was last changed at least two years ago.
> http://www.cliki.net/cirCLe
To the extent that it's an exercise in picking existing useful CL
tools and libraries that are succeeding or likely to succeed on their
own merits, cirCLe is doing quite nicely. It's unclear to me that
there's actually any value added by the overarching "virtual package"
of cirCLe itself, but it does work very nicely as my personal TODO
list ;-)
You may be entertained to learn that the original title of cirCe was
"Play Nice With Unix", though ;-) Well, the emphasis shifted a bit
over time.
Some other resources for unixy stuff can be found from the index at
http://www.cliki.net/unix
-dan
Daniel Barlow <·············@uk.clara.net> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
>> Do Lisp implementors dislike Unix/Posix?
>
> I can't answer for all Lisp implementors (indeed, given the amount of
> actual hackiung I've done lately I'm not sure I qualify to answer for
> any Lisp implementors at all) but I'm certainly not blind to its weak
> spots. The trouble is that all the alternatives readily available to
> me are worse.
My impression--or maybe gut feeling--on Lisp implementors and Unix was
more along the lines of "patches welcome" than a deliberate choice not
to fully support it.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Daniel Barlow <·············@uk.clara.net> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
>> Do Lisp implementors dislike Unix/Posix?
There's some "impedence" mismatch that makes it unnatural to implement
the POSIX API in Lisp.
A plain FFI API is rather unsatisfying, and in some areas, redundant
with facilities already existing and better implemented in Common
Lisp, and in other areas, awkward or too low-level.
Right now, I'm thinking that a mid-to-thick layer is preferable to a
thin layer for a good Lisp POSIX API.
>> http://www.cliki.net/Common-Lisp-POSIX
>
> TTBOMK that's vapourware, and whatever CLiki may say about the
> date on it, it was last changed at least two years ago.
Yes, it still needs a *lot* of work.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
From: Sam Steingold
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <u3btdckzu.fsf@gnu.org>
> * Pascal Bourguignon <···@vasbezngvzntb.pbz> [2005-04-26 22:28:35 +0200]:
>
> Right now, I'm thinking that a mid-to-thick layer is preferable to a
> thin layer for a good Lisp POSIX API.
please contribute to
<http://www.podval.org/~sds/clisp/impnotes/syscalls.html>
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.jihadwatch.org/> <http://www.mideasttruth.com/>
<http://www.memri.org/> <http://www.camera.org>
cogito cogito ergo cogito sum
Florian Weimer <··@deneb.enyo.de> writes:
>I think Matthias' conjecture that Lisp implementators dislike the
>C/UNIX environment and therefore want to suck as much as possible into
>the Lisp image might explain the sorry state of affairs.
I didn't say that Lisp implementors dislike Unix. I said that I get
the impression that the creators of some Lisp implementations hate
Unix. I hope most don't, of course.
mkb.
Florian Weimer <··@deneb.enyo.de> writes:
>Why are so few system administrators using Lisp as a gluing language,
>or the language of choice for throw-away programs? Hardly anybody
>writes small network servers in it, either.
The simple reason might be that it's so hard to use it as a drop-in C
replacement. I don't know anything about the commercial offerings but
that's hardly relevant here anyways, when we're talking about
glue-languages.
Even with CMU CL, which is one of the more usable implementations and
at least offers most Unix system calls, they are _undocumented_ in the
user's manual. The only way to find out about them is to a) use
apropos+describe (which will not always produce enough information),
and b) to look them up in "unix.lisp", a file that possibly exists in
the source distribution but not in my installed cmucl anywhere. And
then, do those system calls even work like in C? Do the sockets
support IPv6? I see select() is available as `unix:unix-select' but
it's interface is everything but programmer-friendly (apparently
directly mapped to the Unix function and using FFI arguments).
Where's poll(), which doesn't have the upper limit of 1024 fds like
select does? I can't find it. And it's not just missing stuff.
Instead of giving a fully detailed documentation about the supported
Unix system calls, the manual blathers about stuff like `serve-event'
and a number of BSD sockets functions that have different names and
different functionality than the (de-facto standard) BSD API. So
you'll have to apropos+describe for the real thing to make use of your
hitherto acquired knowledge of the Unix API. Not very encouraging to
a new potential Lisp programmer who wants to use CMU CL instead of C
in the Unix environment.
Contrast this with Perl, which, in addition to its main functionality
of taking apart text streams in all possible ways, imports most of the
Unix system calls, under their original names, and well documented,
maintained and fully operational. You can translate many C programs
directly into Perl. But then again, Perl's creator has been a Unix
fan. I sometimes get the impression that the creators of at least
some of the Lisp implementations really, really hate Unix, want to
touch it as little as possible, and deliberately want to set their
system apart from it. No wonder then that the result does not appeal
to Unix programmers.
mkb.
From: Christopher C. Stacy
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <uu0lubnrb.fsf@news.dtpq.com>
Matthias Buelow <···@incubus.de> writes:
> Florian Weimer <··@deneb.enyo.de> writes:
>
> >Why are so few system administrators using Lisp as a gluing language,
> >or the language of choice for throw-away programs? Hardly anybody
> >writes small network servers in it, either.
>
> The simple reason might be that it's so hard to use
> it as a drop-in C replacement.
System administrators write throw-away programs in C?
Or did you mean that Perl is a drop-in replacement for C?
What does "drop-in replacement for C" mean?
······@news.dtpq.com (Christopher C. Stacy) writes:
>System administrators write throw-away programs in C?
>Or did you mean that Perl is a drop-in replacement for C?
>What does "drop-in replacement for C" mean?
Simple example: Most of /usr/bin/* is written in C. What's the effort
of rewriting these programs in any Lisp implementation (say, CMUCL)?
And what's the effort of rewriting them in Perl?
I know CMUCL better than Perl but I'd wager that for me it would be
far easier to rewrite them in Perl, than in CMU CL (not that I would
want to, though).
mkb.
From: Christopher C. Stacy
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <upswibnhx.fsf@news.dtpq.com>
Matthias Buelow <···@incubus.de> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> >System administrators write throw-away programs in C?
> >Or did you mean that Perl is a drop-in replacement for C?
> >What does "drop-in replacement for C" mean?
>
> Simple example: Most of /usr/bin/* is written in C
Most if /usr/bin is throw-away programs written by system administrators?
······@news.dtpq.com (Christopher C. Stacy) writes:
>> Simple example: Most of /usr/bin/* is written in C
>Most if /usr/bin is throw-away programs written by system administrators?
No but they're the kind of programs that are typical for the Unix
environment. With throw-away programs doing sysadmin stuff the
problem is perhaps even worse, since I for sure wouldn't do lengthy
apropos+describe rummaging through the bowels of CMUCL for a couple
system calls that I need for the particular problem at hand, if I just
want to hack together a quick throw-away program.
mkb.
From: Christopher C. Stacy
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <uhdhubkx9.fsf@news.dtpq.com>
Matthias Buelow <···@incubus.de> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> >> Simple example: Most of /usr/bin/* is written in C
> >Most if /usr/bin is throw-away programs written by system administrators?
>
> No but they're the kind of programs that are typical for the Unix environment.
The question was specifically about throw-away programs written
by system administrators, so I don't know what your point is.
>With throw-away programs doing sysadmin stuff the problem is perhaps
>even worse, since I for sure wouldn't do lengthy apropos+describe
>rummaging through the bowels of CMUCL for a couple system calls that
>I need for the particular problem at hand, if I just want to hack
>together a quick throw-away program.
Apparently your point is that you feel the documentation for CMUCL is
not up to snuff. Feel free to write something better, or pay someone
else to write it for you. However, note that other people are not
reporting this same lack of documentation. Maybe you just need to
read some of online documentation available on the web about how
to write these sorts of programs? There are lots of examples.
Christopher C. Stacy wrote:
<snip>
>
>
> Apparently your point is that you feel the documentation for CMUCL is
> not up to snuff. Feel free to write something better, or pay someone
> else to write it for you. However, note that other people are not
> reporting this same lack of documentation. Maybe you just need to
> read some of online documentation available on the web about how
> to write these sorts of programs? There are lots of examples.
Smug Smalltalk Weenies (not too unlike myself) have similar responses.
It's a catch-22. To broaden the use of Smalltalk and Lisp to wider
audiences (people unfamiliar with either) it is necessary to compete
with what other languages provide the same audience is equally
unfamiliar with.
On Unix, the answer to "man lisp" or "info lisp" competes with the same
documentation for tcsh, bash, perl, awk, etc. The people asking the
questions are ill-equipped to write the documentation. 30 pages into
PCL and they still won't know how to loop through filenames , match
expressions in text files, etc.
Perhaps there's market for something called lish or lsh which is nothing
more than lisp but with its own manpage for doing that kind of stuff.
From: Florian Weimer
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <8764ya1pen.fsf@deneb.enyo.de>
* Christopher C. Stacy:
>> The simple reason might be that it's so hard to use
>> it as a drop-in C replacement.
>
> System administrators write throw-away programs in C?
Some of them do, yes. But Perl is much more common, especially among
the younger generation.
> Or did you mean that Perl is a drop-in replacement for C?
Lisp could be a drop-in replacement for Perl. Not for all of Perl's
features, of course, but in areas where it makes sense. What you'd
need is a reasonably documented system call/libc interface (and for
that, you apparently need FFI support for 64 bit numbers). cl-ppcre
could be helpful, too, if it compiles regular expression fast enough.
Otherwise, just link in PCRE. You just go along and add the things
you need, and at some point, publish your collection, and commit to
its maintainance.
Actually, it's not too hard to compete with Perl in this area. Perl
has some weaknesses (not just code maintainability). An instructive
example is that regular expressions as a first-class type are pretty
recent innovation in Perl land. 8-)
From: Christopher C. Stacy
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <u4qdubif7.fsf@news.dtpq.com>
Florian Weimer <··@deneb.enyo.de> writes:
> What you'd need is a reasonably documented system call/libc interface
> (and for that, you apparently need FFI support for 64 bit numbers).
> cl-ppcre could be helpful, too, if it compiles regular expression
> fast enough. Otherwise, just link in PCRE.
Ah, finally, something specific to talk about!
CLISP has both PCRE and POSIX regexps, take your pick.
Normally one would not use the system calls, but rather the
interfaces in the language that allow you to manipulate files,
run other programs, pipe data around, networking, etc.
CLISP does have the POSIX/OS package, though, so you can
call SETUTXENT or whatever.
I have found that between the various web sites and the CLISP
documentation (which is badly labeled as "Implementation Notes"),
all this stuff is fairly well documented.
Maybe someone should put together a Lisp for Unix sysadmins in a box.
Probably based on CLISP.
······@news.dtpq.com (Christopher C. Stacy) writes:
> [...]
> I have found that between the various web sites and the CLISP
> documentation (which is badly labeled as "Implementation Notes"),
Yes, these are the notes about this specific Common Lisp
implementation, not the notes about the implementation of this Common
Lisp implementation...
> all this stuff is fairly well documented.
> Maybe someone should put together a Lisp for Unix sysadmins in a box.
> Probably based on CLISP.
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
Centuries ago, Nostradamus foresaw when Pascal Bourguignon <···@informatimago.com> would write:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>> [...]
>> I have found that between the various web sites and the CLISP
>> documentation (which is badly labeled as "Implementation Notes"),
>
> Yes, these are the notes about this specific Common Lisp
> implementation, not the notes about the implementation of this Common
> Lisp implementation...
>
>> all this stuff is fairly well documented.
>
>> Maybe someone should put together a Lisp for Unix sysadmins in a box.
>> Probably based on CLISP.
Create a Common Lisp-based equivalent to Mark Burgess' cfengine tool,
and I think you'd have something.
cfengine is a system configuration tool that allows configuring a
number of things using a somewhat Prolog-like declarative language.
- It's class-based in that the environment defines a whole bunch of
'variables' or 'classes' for you, from which you can then define
your own classes.
classes include various system properties such as OS, host
identification info, what time it is. I might then define that
certain hosts are in particular classes, e.g. 'database_hosts' or
'enduser_workstations'.
- There are a whole bunch of kinds of "actions" you can then invoke,
such as:
- directories - defining what directories should be around
- resolve - how should IP resolution be handled
- mountables - what NFS mounts should go where
- editfiles - what sorts of config should go in various files,
and how can it get there
- tidy/disable - purging/rotating files
- processes - what processes are expected, or should be killed off
- copy - what files should be copied from somewhere
- shellcommands - what programs ought to be run to manage
configuration
You can specify that some of the actions take place only for
particular "classes" (e.g. - only mount certain NFS filesystems on the
hosts that need them), or vary directories based on them. (Mount
SPARC bins on SPARC servers, mount AMD64 bins on AMD64 servers...)
A present problem with cfengine is that while it is admirably elegant
and tidy at handling some configuration matters, it's pretty terrible
at others.
It hasn't got a programming language, so that extending it requires
some sort of "plugin system" that is anything but elegant.
I could easily see a Lisp equivalent being as unwordy, while also
being vastly more extendable.
CLISP would be an excellent platform for this because it is portable
to plenty of platforms, and doesn't mandate having a C compiler
kicking around everywhere. It may not be compiling to machine code,
but the bytecode is by no means of "crummy" performance...
--
let name="cbbrowne" and tld="acm.org" in name ^ ·@" ^ tld;;
http://linuxdatabases.info/info/nonrdbms.html
Pound for pound, the amoeba is the most vicious animal on earth.
From: Christopher C. Stacy
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <ur7gy9no5.fsf@news.dtpq.com>
Pascal Bourguignon <···@informatimago.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> > [...]
> > I have found that between the various web sites and the CLISP
> > documentation (which is badly labeled as "Implementation Notes"),
>
> Yes, these are the notes about this specific Common Lisp
> implementation, not the notes about the implementation of this Common
> Lisp implementation...
Yes, I finally realized that. But this confused me initially.
I was wondering where the hell the documentation was!
I'd call it something else. Like "The CLISP Documentation".
Florian Weimer <··@deneb.enyo.de> writes:
>Lisp could be a drop-in replacement for Perl. Not for all of Perl's
Actually, there are already such things. Only not in Lisp but Scheme
(this sentence may make no sense, when you consider Scheme to be a
dialect of Lisp). Although this is a Lisp newsgroup, I have to say
that I find Scheme more suitable than Common Lisp for sysadmin /
prototyping / throw-away jobs simply because the language is a lot
more compact and more consistent and not such a goddamn heavyweight
monstrosity, which also results in a smaller runtime (all Scheme/Lisp-
systems that I know are monolithic).
For scripting-style stuff, scsh comes to mind ("Scheme shell") and
perhaps Gnu guile also counts. I've never used any of these for
scripting (only PLT Scheme, which worked well enough, much easier on
my blood pressure than Perl at any rate) so I can't really comment on
how useful they really are. But as I get it, scsh was written
explicitly for doing scripting in Scheme, instead of sh/ksh/bash. If
I find some time, I'll hack me my own Unix-integrated Scheme and then
I've found my peace and to hell with Perl, Python, etc., for me at
least.
mkb.
From: Florian Weimer
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <874qdu1oao.fsf@deneb.enyo.de>
* Matthias Buelow:
> Florian Weimer <··@deneb.enyo.de> writes:
>
>>Why are so few system administrators using Lisp as a gluing language,
>>or the language of choice for throw-away programs? Hardly anybody
>>writes small network servers in it, either.
>
> The simple reason might be that it's so hard to use it as a drop-in C
> replacement.
Nowadays, it's Perl (or even Python or one of the more obscure
scripting languages). I often have to replace shell scripts which
grew too complicated, too. (Currently, it's Shell -> Perl -> Ada for
me.)
> Even with CMU CL, which is one of the more usable implementations and
> at least offers most Unix system calls, they are _undocumented_ in the
> user's manual.
Probably because they are not cross-platform? There must have been
times when CMUCL ran on non-UNIX platforms (or UNIX platforms of a
greater variety than we have to deal with today).
> The only way to find out about them is to a) use
> apropos+describe (which will not always produce enough information),
> and b) to look them up in "unix.lisp", a file that possibly exists in
> the source distribution but not in my installed cmucl anywhere.
It could be worse. Doesn't SBCL use hard-coded structures instead of
importing the C layout when SBCL itself is compiled?
> And then, do those system calls even work like in C?
Yes, very valid question. What about restarting syscalls, and EINTR?
How do Lisp streams interact with underlying syscall failures?
Admittedly, I don't know the answer for C streams (or Perl's buffered
I/O), either, but they seem to work quite quite well (in contrast to
the GNU implementation of C++ streams, for example).
> So you'll have to apropos+describe for the real thing to make use of
> your hitherto acquired knowledge of the Unix API. Not very
> encouraging to a new potential Lisp programmer who wants to use CMU
> CL instead of C in the Unix environment.
Yes, this pretty much sums up the situation I was in two years ago. I
had already forgotten that it was *so* painful. Ugh.
I believe the BSD sockets binding I used lacked proper recvfrom/sendto
functions which made it unsuitable for datagram sockets. Okay, here
we are leaving the area of typical sysadmin stuff, but these APIs
aren't really obscure, either. What's worse, the FFI implemenation I
was dealing with was too much for me. I'm not sure if I ever managed
to add the missing APIs myself, or just gave up and asked on a mailing
list (where I did get some help). I remember that the package system
was complicated to use as well, even though I had considerable
experience with such concepts in other languages. I never managed to
split my application into separate packages.
> I sometimes get the impression that the creators of at least
> some of the Lisp implementations really, really hate Unix, want to
> touch it as little as possible, and deliberately want to set their
> system apart from it.
Indeed. And they want you to do everything inside a single
long-living Lisp image. Like Java, the sysadmin's nightmare.
> No wonder then that the result does not appeal to Unix programmers.
And UNIX programmers are probably the only people who will use
something which doesn't have a colorful GUI. 8-/
Florian Weimer <··@deneb.enyo.de> writes:
>> The only way to find out about them is to a) use
>> apropos+describe (which will not always produce enough information),
>> and b) to look them up in "unix.lisp", a file that possibly exists in
>> the source distribution but not in my installed cmucl anywhere.
>
> It could be worse. Doesn't SBCL use hard-coded structures instead of
> importing the C layout when SBCL itself is compiled?
In SBCL, the SB-UNIX package (which was originally based on CMUCL's
UNIX) is not considered part of the supported interface, and only
continues to exist for SBCL's own needs. There are a few places it
uses hard-coded structures and C helper functions to convert to/from
whatever layout the OS uses - e.g. struct stat, which due to past gnu
libc decisions is nigh-on impossible to ascertain programmatically.
If you want a supported (for the usual SBCL value of "supported":
"unlikely to change or go away /completely/ randomly") interface to
do unixy stuff, look at the SB-POSIX contrib module -
http://cvs.sourceforge.net/viewcvs.py/sbcl/sbcl/contrib/sb-posix/README?rev=HEAD
I don't claim it's good for writing scripts any more than that the
equivalent interfaces in C make that language good for writing scripts.
-dan
From: Sam Steingold
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <uekcxcpzh.fsf@gnu.org>
> * Florian Weimer <··@qraro.ralb.qr> [2005-04-25 20:49:42 +0200]:
>
> Why are so few system administrators using Lisp as a gluing language,
> or the language of choice for throw-away programs?
because people use the tool they are used to (or something similar)
instead of diligently searching for the best tool for the specific task.
the tool every system administrator knows is /bin/sh used for syntactic
glue for commands like ln(1), ls(1), cp(1), mv{1} &c.
now, try telling the sysadmin that "there is no cp (easy to implement),
no cat (ditto), no sed (hard), no grep (hard), no ln (no way, but see
[1]), no mknod (ditto), new syntax, &c" - he will run away.
[1] <http://www.podval.org/~sds/clisp/impnotes/syscalls.html>
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://ffii.org/> <http://www.mideasttruth.com/> <http://www.dhimmi.com/>
<http://www.iris.org.il> <http://www.jihadwatch.org/> <http://www.camera.org>
Parachute for sale, used once, never opened, small stain.
In article <··············@deneb.enyo.de>, Florian Weimer wrote:
> * Alexander Repenning:
>
>> The same students all get Visual Studio DVDs from Microsoft for
>> free. When they compare the two they conclude Lisp is from the dark
>> ages and is just one small step up from punch cards.
>
> This doesn't explain why Lisp isn't well-received by the free software
> crowed, either.
>
> Why are so few system administrators using Lisp as a gluing language,
> or the language of choice for throw-away programs? Hardly anybody
> writes small network servers in it, either.
I sent a proposal to several publishers about writing a book
dealing with Scheme as a systems programming language for interaction
with backups, configuration, monitoring, etc. Two of the publishers
contacted me for further discussion. None of the publishers found
any worth (profitability) in such a book.
Mike
Mike <·····@mikee.ath.cx> writes:
> I sent a proposal to several publishers about writing a book
> dealing with Scheme as a systems programming language for interaction
> with backups, configuration, monitoring, etc. Two of the publishers
> contacted me for further discussion. None of the publishers found
> any worth (profitability) in such a book.
If Apress and BOOKFIX.COM are not among those you refer to, you may
consider contacting them:
Apress
http://www.apress.com
BOOKFIX.COM
http://bookfix.com
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
On 4254 September 1993, Alexander Repenning wrote:
> nikhilketkar wrote:
>> People are so against LISP. How to change their minds??
Wrt. LISP, I've no idea. But showing them what Common Lisp can do
might teach them a little bit about opening their minds to the outer
space beyond the language of the day.
> Teaching at an university and programming in Lisp since the 70ies I
> find that most people learned to dislike Lisp as ugrad during a
> "programming languages" course. Before that they were pretty
> neutral.
That's my personal experience, too.
> Lisp. Then they do the car/cdr and some quick recursion hack. After
> that they either hate Lisp or at least see no value in it. The same
> students all get Visual Studio DVDs from Microsoft for free.
Well, deal with it. :-)
More seriously, I've seen enough students struggle with whatever IDE
to not blame it on the development environment. However, I agree that
there are a lot of folks whose dislike of Lisp is directly related to
some horrible course. I wonder, are there really that many bad
Lisp instructors around and so many good teachers with a crush on Java
etc.?
> In some sense I cannot blame these students.
Right.
> They don't want to write little silly recursive functions or hear
> about the beauty of closures etc. They want to hack cool stuff such
> as games. They want to have access to interesting APIs such as
> OpenGL. They want to learn about OOP. Lisp could give them all
> that. Best of all now would be a good time since the "I must learn
> Java" crowd has gone.
I don't know about the OpenGL part and I'm also not sure about
the OOP part. But I agree that as an instructor it won't help selling
Lisp by merely praising it's virtues. Using exciting examples helps a
lot. Then you'll be able to talk about the beauty of closures, the
usefulness of macros etc.
> As instructor I would need a textbook. That textbook could not be ABOUT
> could use Lisp. But what textbook could I use? Many textbooks (e.g., On
> Lisp, Ansi Common Lisp) are written by folks who officially hate OOP.
> This does not work for me.
I've used ACL as the foundation for a course, quite successfully. As
the students had a linguistics background, I made up some NLP code,
too, and that seemed to be enough to keep them going. Probably, that
was the main part of their motivation, to see how their main topic
could be addressed with that paren-ridden language. :-)
> When I show OpenGL + Lisp in my game design courses that really gets
> students excited.
See? It's not the language per se, but how you can solve interesting
problems with them, that's the key.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
Fachbegriffe der Informatik - Einfach erkl�rt
115: pure virtual member function
nicht kreatibel (Frank Klemm)
Holger Schauer wrote:
> More seriously, I've seen enough students struggle with whatever IDE
> to not blame it on the development environment. However, I agree that
> there are a lot of folks whose dislike of Lisp is directly related to
> some horrible course. I wonder, are there really that many bad
> Lisp instructors around and so many good teachers with a crush on Java
> etc.?
I don't think so. I had Scheme on my first semester (second:
Java), but everybody in class got the impression, that it's not
terribly useful for real-world use. I'm the one (out of those
beginning 200) who actually read SICP ;)
>
>>In some sense I cannot blame these students.
>
>
> Right.
For what? Everybody is responsible for himself. So in the sense
that they waste time by coding in Java (for their own projects),
they are the ones to blame.
> I don't know about the OpenGL part and I'm also not sure about
> the OOP part. But I agree that as an instructor it won't help selling
> Lisp by merely praising it's virtues. Using exciting examples helps a
> lot. Then you'll be able to talk about the beauty of closures, the
> usefulness of macros etc.
Mostly it's Scheme that's taught, and books like SICP don't
mention macros at all. The lack of a standard module system and
OOP doesn't help either (so in the end there are few good
libraries available).
Now a course using PLT might do better, but just like a course
using CL it would take probably a full year, and most institutions
face some pressure to teach their ()-suffering students at least
some Java...
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
nikhilketkar wrote:
> What would be the best way to make people change the mind about LISP?
Have fun doing really cool things with it.
Paul
From: Wade Humeniuk
Subject: Re: How to change people's minds about LISP?
Date:
Message-ID: <a5sbe.345$3V3.94@edtnps89>
nikhilketkar wrote:
> What would be the best way to make people change the mind about LISP?
> People are so against LISP. How to change their minds??
>
If you could change their behaviour, how would you like them to act?
If you want them to be open-minded, then you have to realize that you
cannot TELL them to be open-minded. If you force them to change
their minds then they do not have an open-mind, even if
you benevolently manipulated them. (Just like you cannot give
someone freedom).
What I want is for people to be open-minded, playful and thoughtful.
Wanting people to change their minds is competitive. As you
have found you get exasperated at the competition.
My suggestion:
People are up-to-their-eyeballs in competition. Propaganda,
advertising, open-source politicking, platform wars, economic
competition, .... the list goes on and on. Worst is
ideas and ideals, many shrouded in misinformation, idealistic
language and PR. The key is to keep Lisp on the side of
playful and thoughtful. You will be happier and those around
you will receive the well deserved respite from the idealogical
battles. Lisp had a downturn when it became too serious and
the stakes went through the roof.
Wade
3
When praise is lavished upon the famous,
the people contend and compete with one another.
When exotic goods are traded and treasured,
the compulsion to steal is felt.
When desires are constantly stimulated,
people become disturbed and confused.
Therefore, the wise person sets an example by
emptying her mind,
opening her heart,
relaxing her ambitions,
relinquishing her desires,
cultivating her character.
Having conquered her own cunning and cravings,
she can't be manipulated by anyone.
Do by not-doing.
Act with nonaction.
Allow order to arise of itself.
The Tao Te Ching of Lao Tzu
Translated by Brian Browne Walker