What Lisp needs to beat Java, etc.
Aaron K . Johnson
Hello friends,
It occurs to me that lesser languages like Java, etc. succeed in
the modern world where Lisp seems like a computer science lesson from days
of old because they have, or are perceived to have, an easy way to
write/design a GUI, and to integrate well with low-level OS
libraries/functions. I love Lisp, but there are things that I would never
attempt with it that I would do in a snap with Python (actually a great
language). I could use TK or WxPython to design a GUI frontend to my
functions in less than an hour. Java, Python, Perl, Tcl/Tk etc. also are
"web aware", i.e. they acknowledge that for a language to be "hot", it has
to appeal to the web-using public, and be usable for the web by the
web-using public.
When Lisp gets its elegance across, as well as having easy access
to all the things people like about things like Tcl/Tk, Java, Perl,
Python; and not just obscure kits like Garnet, etc. (One of the problems
is that various implementations go different lengths to provide such
functionality--Java sucks, but at least you know what you're getting and
what you're able to do with it!) There's only one Python, Perl, and
Tcl/Tk, and that helps them stay central and release one version of the
language--not the fragmented state of affairs that both Lisp as a language
and Linux as an OS suffer.
Aaron Johnson.
Fernando Rodríguez
wrote:
>
>Hello friends,
>
> It occurs to me that lesser languages like Java, etc. succeed in
>the modern world where Lisp seems like a computer science lesson from days
>of old because they have, or are perceived to have, an easy way to
>write/design a GUI, and to integrate well with low-level OS
CAPI, CLIM, Common Graphics and whatever gui toolkit MCL has aren't
enough? :-)
>libraries/functions. I love Lisp, but there are things that I would never
>attempt with it that I would do in a snap with Python (actually a great
Obviously, since Python and CL are very different languages with
different goals. Python is a scripting language, great for quick sysadmin
wizardry, but not for building big, complex apps. Use both. :-)
>language). I could use TK or WxPython to design a GUI frontend to my
>functions in less than an hour. Java, Python, Perl, Tcl/Tk etc. also are
>"web aware", i.e. they acknowledge that for a language to be "hot", it has
>to appeal to the web-using public, and be usable for the web by the
>web-using public.
Well... yes, some _standard_ support for doing web stuff would be
nice.
>what you're able to do with it!) There's only one Python, Perl, and
>Tcl/Tk, and that helps them stay central and release one version of the
>language--not the fragmented state of affairs that both Lisp as a language
>and Linux as an OS suffer.
I don't think so: there's plenty of implementations of c and c++ and
they're freaking popular; there's only one Windows and it doesn't make things
easier for it's users... :-P
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Rainer Joswig
<Pine.LNX.4.21.00112...@ajohnson.21stcentury.net>,
> Hello friends,
>
> It occurs to me that lesser languages like Java, etc. succeed in
> the modern world where Lisp seems like a computer science lesson from days
> of old because they have, or are perceived to have, an easy way to
> write/design a GUI, and to integrate well with low-level OS
> libraries/functions. I love Lisp, but there are things that I would never
> attempt with it that I would do in a snap with Python (actually a great
> language). I could use TK or WxPython to design a GUI frontend to my
> functions in less than an hour.
Why does it take so long? On my Mac I use either the interactive
interface builder or a GUI description tool like CLIM.
> Java, Python, Perl, Tcl/Tk etc. also are
> "web aware", i.e. they acknowledge that for a language to be "hot", it has
> to appeal to the web-using public, and be usable for the web by the
> web-using public.
That's what I use CL-HTTP for.
> When Lisp gets its elegance across, as well as having easy access
> to all the things people like about things like Tcl/Tk, Java, Perl,
> Python; and not just obscure kits like Garnet, etc.
> (One of the problems
> is that various implementations go different lengths to provide such
> functionality--Java sucks, but at least you know what you're getting and
> what you're able to do with it!) There's only one Python, Perl, and
> Tcl/Tk
There is not one implementation of those that comes near
the performance of commercial Lisp implementations. If you
are a script kiddie - go use PERL. If you want to be a programmer,
use Common Lisp.
--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig
Rodr?guez <spa...@must.die> wrote:
> On Thu, 23 Nov 2000 08:52:14 -0600, "Aaron K . Johnson" <a...@21stcentury.net>
> wrote:
>
> >
> >Hello friends,
> >
> > It occurs to me that lesser languages like Java, etc. succeed in
> >the modern world where Lisp seems like a computer science lesson from days
> >of old because they have, or are perceived to have, an easy way to
> >write/design a GUI, and to integrate well with low-level OS
>
> CAPI, CLIM, Common Graphics and whatever gui toolkit MCL has aren't
> enough? :-)
The Macintosh GUI toolkit is amazingly simple and powerful. Digitool
ships almost all of their Lisp system in source code (you
get the full source code for everything GUI related: editor,
interface builder, graphics functionality, inpector,
backtrace). If you look at the contrib directory at
ftp.digitool.com or on the MCL CDROM, you will find literally
MEGABYTES of cool extensions. MCL has stuff to interface
to MIDI, control video disk players, full access to
QuickTime (people have been programming authoring environments
in MCL), speech I/O, QuickDraw 3d, business graphics,
drag&drop, diverse browers, ...
Georges KO
> It occurs to me that lesser languages like Java, etc. succeed
> in the modern world where Lisp seems like a computer science lesson
> from days of old because they have, or are perceived to have, an easy
> way to write/design a GUI, and to integrate well with low-level OS
> libraries/functions.
Java, Python, Perl, VB, etc. succeed because of their libraries:
I'm not talking of libraries supporting the language (à la Common
Lisp), but libraries for GUIs, databases, Internet, etc...
> I love Lisp, but there are things that I would never attempt with it
> that I would do in a snap with Python (actually a great language). I
> could use TK or WxPython to design a GUI frontend to my functions in
> less than an hour. Java, Python, Perl, Tcl/Tk etc. also are "web
> aware", i.e. they acknowledge that for a language to be "hot", it
> has to appeal to the web-using public, and be usable for the web by
> the web-using public.
As Kent Pitman said, (implementations of) Common Lisp should annex
these libraries. As these languages have an interactive mode, they
may be used by Lisp as interfaces to these libraries by generating
code for that language (cf Erik Naggum in
<31838671...@naggum.net>) and communicating through pipes,
sockets, ... For example, you could say:
(setq data (py:call (urllib (urlopen url) (read))))
to tell Python to return you the result of:
urllib.urlopen(url).read()
where `url' is actually replaced by the value of the Lisp variable
`url'.
Here is a POP protocol example (from the book Learning Python):
from poplib import *
server = POP3('mailserver.spam.org')
print server.getwelcome()
server.user('da')
server.pass_('youllneverguess')
|
|
V
(py:import poplib *)
(py:set server (py:call '(POP3 "mailserver.spam.org"))) ;; `server` is a
(format t "~A" (py:call '(server (getwelcome))) ;; variable in
(py:call '(server (user "da"))) ;; the Python world
(py:call '(server (pass_ "youllneverguess")))
Of course, from here, you can write things like :
(with-pop-account (account "mailserver.spam.org" "da" "youllneverguess")
...))
or wrap the whole stuff in nice packages...
The `glue' would deal with conversions between data structures :
(py:call '((range 1 10))) Lisp world
|
V
range(1, 10) Python world
|
V
[1, 2, 3, 4, 5, 6, 7, 8, 9] Python world
|
V
'(1 2 3 4 5 6 7 8 9) Lisp world
> When Lisp gets its elegance across, as well as having easy
> access to all the things people like about things like Tcl/Tk, Java,
> Perl, Python; and not just obscure kits like Garnet, etc. (One of the
> problems is that various implementations go different lengths to
> provide such functionality--Java sucks, but at least you know what
> you're getting and what you're able to do with it!)
Actually, if stuff described above could be achieved with Perl,
Tcl/Tk, Java, etc. as well, then Lisp would be the Emacs of the
languages ! The language stack would then be :
_____________________________________________
| |
| Lisp |
|_____________________________________________|
| | | | | | |
| | Perl+ | Java+ | Python | Tcl/Tk | What |
| | libs | libs | + libs | + libs | Ever |
| |_______|_______|________|________|______|
| |
| C |
|_____________________________________________|
As (new) languages become more and more interactive, Lisp can
easily talk to all these languages and use their libraries...
> There's only one Python, Perl, and Tcl/Tk, and that helps them stay
> central and release one version of the language--not the fragmented
> state of affairs that both Lisp as a language and Linux as an OS
> suffer.
What's important is that they keep interfacing with all the new
technologies so that Lispers can annex them without having to learn
new languages. Let them work for us: use the libs, dump the
languages !
--
Georges KO (Taipei, Taiwan) g...@gko.net
Décade I, Tridi de Frimaire de l'Année 209 de la Révolution
akjm...@my-deja.com
Rainer Joswig <jos...@corporate-world.lisp.de> wrote:
> In article <goeq1tg0lu6qm2rpd...@4ax.com>, Fernando
> Rodr?guez <spa...@must.die> wrote:
>
<a...@21stcentury.net>
> > wrote:
> >
> > >
> > >Hello friends,
> > >
> > > It occurs to me that lesser languages like Java, etc. succeed in
> > >the modern world where Lisp seems like a computer science lesson
from days
> > >of old because they have, or are perceived to have, an easy way to
> > >write/design a GUI, and to integrate well with low-level OS
> >
aren't
> > enough? :-)
>
> The Macintosh GUI toolkit is amazingly simple and powerful. Digitool
> ships almost all of their Lisp system in source code (you
> get the full source code for everything GUI related: editor,
> interface builder, graphics functionality, inpector,
> backtrace). If you look at the contrib directory at
> ftp.digitool.com or on the MCL CDROM, you will find literally
> MEGABYTES of cool extensions. MCL has stuff to interface
> to MIDI, control video disk players, full access to
> QuickTime (people have been programming authoring environments
> in MCL), speech I/O, QuickDraw 3d, business graphics,
> drag&drop, diverse browers, ...
>
sound great- wish I could say that there were something Lisp provided
to us linuxers like that- there'd be no reason for any other languages!
aaron.
> --
> Rainer Joswig, Hamburg, Germany
> Email: mailto:jos...@corporate-world.lisp.de
> Web: http://corporate-world.lisp.de/
>
Sent via Deja.com http://www.deja.com/
Before you buy.
akjm...@my-deja.com
Fernando Rodríguez <spa...@must.die> wrote:
> Obviously, since Python and CL are very different languages with
> different goals. Python is a scripting language, great for quick
sysadmin
> wizardry, but not for building big, complex apps. Use both. :-)
>
Look at www.python.org for a listing of python success stories. i think
you'll find that Python is quite robust and capable of very large apps.
> >language). I could use TK or WxPython to design a GUI frontend to my
> >functions in less than an hour. Java, Python, Perl, Tcl/Tk etc. also
are
> >"web aware", i.e. they acknowledge that for a language to be "hot",
it has
> >to appeal to the web-using public, and be usable for the web by the
> >web-using public.
>
> Well... yes, some _standard_ support for doing web stuff would
be
> nice.
>
> >what you're able to do with it!) There's only one Python, Perl, and
> >Tcl/Tk, and that helps them stay central and release one version of
the
> >language--not the fragmented state of affairs that both Lisp as a
language
> >and Linux as an OS suffer.
>
> I don't think so: there's plenty of implementations of c and
c++ and
> they're freaking popular; there's only one Windows and it doesn't
make things
> easier for it's users... :-P
C/C++ is popular for 2 reasons- speed, and OS functionality. (and i
suppose public gullibility ;) )
>
> //-----------------------------------------------
> // Fernando Rodriguez Romero
> //
> // frr at mindless dot com
> //------------------------------------------------
>
akjm...@my-deja.com
Georges KO <g...@gko.net> wrote:
> Java, Python, Perl, VB, etc. succeed because of their libraries:
> I'm not talking of libraries supporting the language (à la Common
> Lisp), but libraries for GUIs, databases, Internet, etc...
I agree 100%
> Actually, if stuff described above could be achieved with Perl,
> Tcl/Tk, Java, etc. as well, then Lisp would be the Emacs of the
> languages ! The language stack would then be :
>
> _____________________________________________
> | |
> | Lisp |
> |_____________________________________________|
> | | | | | | |
> | | Perl+ | Java+ | Python | Tcl/Tk | What |
> | | libs | libs | + libs | + libs | Ever |
> | |_______|_______|________|________|______|
> | |
> | C |
> |_____________________________________________|
>
> As (new) languages become more and more interactive, Lisp can
> easily talk to all these languages and use their libraries...
.
>
> What's important is that they keep interfacing with all the new
> technologies so that Lispers can annex them without having to learn
> new languages. Let them work for us: use the libs, dump the
> languages !
cool- but will we lose some speed doing all those foreign language
calls that are not to C libs?
Aaron.
> --
> Georges KO (Taipei, Taiwan)
g...@gko.net
> Décade I, Tridi de Frimaire de l'Année 209 de la
Révolution
>
Kent M Pitman
> cool- but will we lose some speed doing all those foreign language
> calls that are not to C libs?
I personally never recommended not calling a C lib. I've merely observed
that there was no C lib to call in many cases and said it's better to
call something than to say "we don't have that". And I think Java has
tons more off the shelf solutions than does C, with new ones appearing
all the time.
Java sucks as an implementation language, IMO, but that's objectively not
enough to stop people from programming in it. And if we don't want to find
ourselves programming in it, then we'd better not ignore the fact that others
are willing to. We can't keep up, except by tying ourselves to it in a way
that makes innovations to it available to us in realtime. If there's a time
lag, we're screwed because we're doomed to be forever at a temporal
disadvantage and not usable as a leading edge tool. If there's no time lag
in accessing cool things, the slowness of an occasional callout (which is
O(1) loss in speed in most cases) can be compensated by the smartness of
other Lisp facilities and even by intangibles like Lisp's ability to debug
things quickly and deliver better "time to market".
Patrick W
"Kent M Pitman" <pit...@world.std.com> wrote in message
news:sfwr942...@world.std.com...
> Java sucks as an implementation language, IMO, but that's objectively not
> enough to stop people from programming in it. And if we don't want to
find
> ourselves programming in it, then we'd better not ignore the fact that
others
> are willing to.
>
> We can't keep up, except by tying ourselves to it in a way
> that makes innovations to it available to us in realtime.
By making it available to "us", it would make Lisp more available to "them".
That's a win, whichever way you look at it.
Perhaps of the two, the latter is the more important in the long run.
Jochen Schmidt
In UNIX versions of the free CLs (CLISP,CMUCL) we can find several
GUI-Toolkits that talk down a socket to a GUI-Server.
The systems I know of are CLM, CLX and cl-gtk (which is outdated).
While reaching some portability over CL-implementations through
the use of the socket-connection, we have no real
cross-plattform-capabilities by using CLM or CLX (Add itionally we have the
fact that this toolkits are ugly compared to higher or more "Lispy"
toolkits like CAPI)
So why not building a GUI-Server in wxWindows - which would run nice on
win32, Linux(Motif), Linux(GTK) and so far I know on BeOS and MacOS too.
wxWindows doesn't provide only GUI it provides us also with a very good
socket-interface (on all supported plattforms).
Most parts would be written on the Lisp side using the GUI-Server whenever
something has to go concrete.
I would prefer a very simple approuch like LispWorks CAPI (or simpler for
the beginnigs).
IMHO if we concentrate on simplicity we could have it in _very_ short time.
What would we get:
A real crossplattform GUI-Toolkit for:
- Linux, Win32, MacOS, BeOS
- Most free and commercial Lisps (e. g. CLISP, CMUCL, ACL, Lispworks...)
- Network distributed GUI (similar to X11 but on a much higher level)
What do you think upon that?
Regards,
Jochen
Aaron K . Johnson wrote:
>
> Hello friends,
>
> It occurs to me that lesser languages like Java, etc. succeed in
> the modern world where Lisp seems like a computer science lesson from days
> of old because they have, or are perceived to have, an easy way to
> write/design a GUI, and to integrate well with low-level OS
> libraries/functions. I love Lisp, but there are things that I would never
> attempt with it that I would do in a snap with Python (actually a great
> language). I could use TK or WxPython to design a GUI frontend to my
> functions in less than an hour. Java, Python, Perl, Tcl/Tk etc. also are
> "web aware", i.e. they acknowledge that for a language to be "hot", it has
> to appeal to the web-using public, and be usable for the web by the
> web-using public.
> When Lisp gets its elegance across, as well as having easy access
> to all the things people like about things like Tcl/Tk, Java, Perl,
> Python; and not just obscure kits like Garnet, etc. (One of the problems
> is that various implementations go different lengths to provide such
> functionality--Java sucks, but at least you know what you're getting and
> what you're able to do with it!) There's only one Python, Perl, and
> Tcl/Tk, and that helps them stay central and release one version of the
> language--not the fragmented state of affairs that both Lisp as a language
> and Linux as an OS suffer.
>
> Aaron Johnson.
>
>
Tim Bradshaw
> C/C++ is popular for 2 reasons- speed, and OS functionality. (and i
> suppose public gullibility ;) )
>
I think you really mean `speed of the 10 line programs that fit in 1st
level cache that are all people ever benchmark'. Certainly I don't
think you can mean `speed of delivered large applications': I've used
some impressively slow C++ applications.
--tim
Kellom{ki Pertti
> So why not building a GUI-Server in wxWindows - which would run nice on
> win32, Linux(Motif), Linux(GTK) and so far I know on BeOS and MacOS too.
> wxWindows doesn't provide only GUI it provides us also with a very good
> socket-interface (on all supported plattforms).
If you plan to go that way, why not use Java? It seems that the push
in GUI is in that front nowadays. Moreover, if you want some parts of
the application to run on the GUI server (a'la NeWS), then I would
quite prefer Java to C++ when extending the server.
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
Georges KO
> > cool- but will we lose some speed doing all those foreign language
> >calls that are not to C libs?
Well, you can write code in that language, much like when you want
to write some parts in C to speed up things, and ask the interpreter
to load it at startup.
> I personally never recommended not calling a C lib. I've merely
> observed that there was no C lib to call in many cases and said it's
> better to call something than to say "we don't have that". And I
> think Java has tons more off the shelf solutions than does C, with new
> ones appearing all the time.
The nature of the "dialog" with C and the other languages are not
of the same nature: with C, it would be by using the classic FFI
approach, whereas with the higher level, the dialog would be through
socket, pipe, whatever: the later has the advantage of not having to
touch the Lisp side when a new module is added to a "slave" language:
you can call it in that language, you can call it in Lisp.
> Java sucks as an implementation language, IMO, but that's objectively
> not enough to stop people from programming in it. And if we don't
> want to find ourselves programming in it, then we'd better not ignore
> the fact that others are willing to. We can't keep up, except by
> tying ourselves to it in a way that makes innovations to it available
> to us in realtime. If there's a time lag, we're screwed because we're
> doomed to be forever at a temporal disadvantage and not usable as a
> leading edge tool.
By having this bridge mechanism, the other languages would do the
dirty job for us.
> If there's no time lag in accessing cool things, the slowness of an
> occasional callout (which is O(1) loss in speed in most cases) can
> be compensated by the smartness of other Lisp facilities and even by
> intangibles like Lisp's ability to debug things quickly and deliver
> better "time to market".
Example: how to get GTK bindings in Common Lisp?
Well, there's a Lisp called librep that binds GTK, so if librep
can be annexed (can be talked to from your Common Lisp
implementation), then GTK would be yours and whenever a better librep
comes out, you just upgrade librep... And if the librep bindings suck,
then you can turn into Python's version... without upgrading anything
on your Lisp side...
That's great, it means that we would have actually MORE choices
than if we were programming in one specific language !
Imagine a Lisp application using Python (libs) to fetch mail, Java
(libs) for the GUI and Perl (libs) for database access stuff :-) or
whatever ...
--
Georges KO (Taipei, Taiwan) g...@gko.net
Décade I, Quartidi de Frimaire de l'Année 209 de la Révolution
Jochen Schmidt
> Jochen Schmidt <j...@dataheaven.de> writes:
> > So why not building a GUI-Server in wxWindows - which would run nice on
> > win32, Linux(Motif), Linux(GTK) and so far I know on BeOS and MacOS too.
> > wxWindows doesn't provide only GUI it provides us also with a very good
> > socket-interface (on all supported plattforms).
>
> If you plan to go that way, why not use Java? It seems that the push
> in GUI is in that front nowadays. Moreover, if you want some parts of
> the application to run on the GUI server (a'la NeWS), then I would
> quite prefer Java to C++ when extending the server.
There are several reasons why I've not chosen Java:
- It is not planned to run parts of the application on the GUI server (as
you mentioned)
- Native Look: wxWindows is using the native look of the several platforms.
- Speed: You can say what you want, actual Java GUIs are _really_ slow
(particularily those written with swing)
- Because I prefer C++ over Java.
But - and there's the point - if someone jumps in to collaborate I could
also live with a Java-Solution. The sideeffect of collaboration would be
that it is much more likely that we end with an working program.
My aim would be to integrate this GUI-Toolkit as good in the several Lisps
I can. At the best there should be no difference between this solution and
e. g. an inbuilt toolkit like CAPI in LispWorks.
Regards,
Jochen Schmidt
Espen Vestre
> - Speed: You can say what you want, actual Java GUIs are _really_ slow
several serious java programmers I've talked have no problems admitting
that java is not suitable for serious GUIs. "BUT", they tend to add,
"it's perfect for servers". However, the java servers I've seen so far
that have really been put to stress tests (real life stress tests,
running on really heavy Sun iron serving a *lot* of clients), have
performed almost unbelievably lousy.
--
(espen)
Aaron K . Johnson
On Fri, 24 Nov 2000, Jochen Schmidt wrote:
> Some day ago I had following idea:
>
> In UNIX versions of the free CLs (CLISP,CMUCL) we can find several
> GUI-Toolkits that talk down a socket to a GUI-Server.
> The systems I know of are CLM, CLX and cl-gtk (which is outdated).
> While reaching some portability over CL-implementations through
> the use of the socket-connection, we have no real
> cross-plattform-capabilities by using CLM or CLX (Add itionally we have the
> fact that this toolkits are ugly compared to higher or more "Lispy"
> toolkits like CAPI)
> So why not building a GUI-Server in wxWindows - which would run nice on
> win32, Linux(Motif), Linux(GTK) and so far I know on BeOS and MacOS too.
> wxWindows doesn't provide only GUI it provides us also with a very good
> socket-interface (on all supported plattforms).
> Most parts would be written on the Lisp side using the GUI-Server whenever
> something has to go concrete.
> I would prefer a very simple approuch like LispWorks CAPI (or simpler for
> the beginnigs).
> IMHO if we concentrate on simplicity we could have it in _very_ short time.
>
> What would we get:
> A real crossplattform GUI-Toolkit for:
>
> - Linux, Win32, MacOS, BeOS
> - Most free and commercial Lisps (e. g. CLISP, CMUCL, ACL, Lispworks...)
> - Network distributed GUI (similar to X11 but on a much higher level)
>
> What do you think upon that?
>
> Regards,
>
> Jochen
>
Jochen and Lispers-
Sounds great. I know so little about how we'd go about coding it.
Is there some sort of documentation about how to begin getting Lisp to
talk to wxWindows. I've used wxPython, and found it to be a faster,
slightly less good-looking version of Tk. My dream-Tk without Tcl slowing
it down, so something like TkInter for Python, but for Lisp. Note that
TkInter still suffers from making calls to Tcl. I never understood why the
Python developers went the route of TkInter instead of wxPython from the
start. After all, since Python is so much better that Tcl in every way,
why rely on Tcl for Gui stuff?
Anyway, is it even possible to make low-level calls to Tk from
another language without Tcl? This would be the cross-platform dream for
Lispers!
Aaron.
Aaron K . Johnson
On 24 Nov 2000, Tim Bradshaw wrote:
> akjm...@my-deja.com writes:
>
> > C/C++ is popular for 2 reasons- speed, and OS functionality. (and i
> > suppose public gullibility ;) )
> >
>
> I think you really mean `speed of the 10 line programs that fit in 1st
> level cache that are all people ever benchmark'. Certainly I don't
> think you can mean `speed of delivered large applications': I've used
> some impressively slow C++ applications.
>
> --tim
>
Apparently, I'm told this is because C was forced into something it was
never meant to do in the first place: Object-Oriented programming.
BTW, I find the whole OO paradigm sort of an annoying catch-phrase
phenomenon that has turned me off to really investigating it, other than
being forced to use it in wxPython.....
-Aaron
Aaron K . Johnson
>
> Example: how to get GTK bindings in Common Lisp?
>
> Well, there's a Lisp called librep that binds GTK, so if librep
> can be annexed (can be talked to from your Common Lisp
> implementation), then GTK would be yours and whenever a better librep
> comes out, you just upgrade librep... And if the librep bindings suck,
> then you can turn into Python's version... without upgrading anything
> on your Lisp side...
>
> That's great, it means that we would have actually MORE choices
> than if we were programming in one specific language !
>
> Imagine a Lisp application using Python (libs) to fetch mail, Java
> (libs) for the GUI and Perl (libs) for database access stuff :-) or
> whatever ...
>
I still have a bad taste in my mouth from the crawl-speed of things like
STk, that I'm skeptical of the language intercommunication
approach. Again, this is a subjective observation- I don't have
benchmarks.
-Aaron
Pierre R. Mai
> In UNIX versions of the free CLs (CLISP,CMUCL) we can find several
> GUI-Toolkits that talk down a socket to a GUI-Server.
> The systems I know of are CLM, CLX and cl-gtk (which is outdated).
Actually CLX works differently: CLX is the CL equivalent of xlib,
i.e. it talks X protocol directly to the X server. This is a direct
consequence of the fact that X11 had been intended to be used
cross-language from the beginning, without having to go through ugly
foreign function interfaces. Sadly this idea was lost later on, when
most widget sets need to be linked to directly.
> While reaching some portability over CL-implementations through
> the use of the socket-connection, we have no real
> cross-plattform-capabilities by using CLM or CLX (Add itionally we have the
> fact that this toolkits are ugly compared to higher or more "Lispy"
> toolkits like CAPI)
CMUCL's CLM can be made quite similar to CAPI with the use of a couple of
convenience macros. Of course you still have to use CLX instead of GP
for the low-level stuff, should that be needed.
The problems I've found with CMUCL's CLM (which is a different
implementation than the portable CLM part of GINA) is that the server
is not very stable when compiled with LessTif, and is slow as a dog
when compiled with a real Motif.
> What would we get:
> A real crossplattform GUI-Toolkit for:
>
> - Linux, Win32, MacOS, BeOS
> - Most free and commercial Lisps (e. g. CLISP, CMUCL, ACL, Lispworks...)
> - Network distributed GUI (similar to X11 but on a much higher level)
>
> What do you think upon that?
I'd think this would be a nice project for someone, so get started
already ;)
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
john...@my-deja.com
>
> > cool- but will we lose some speed doing all those foreign language
> > calls that are not to C libs?
>
> I personally never recommended not calling a C lib. I've merely
observed
> that there was no C lib to call in many cases and said it's better to
> call something than to say "we don't have that". And I think Java has
> tons more off the shelf solutions than does C, with new ones appearing
> all the time.
I am learning Lisp. I have a pretty good grasp of C, Python, and Perl.
I really think that Lisp lends itself to many programs I previously
wrote with the languages I mentioned, but I cannot find a Lisp library
that provides basic networking facilities that are needed to write the
type of programs I want to. I looked at clocc
<http://clocc.sourceforge.net>, but it has almost no documentation or
examples that come with it, and I cannot get it to work. I found many
networking libraries for Scheme (SLIB and libraries in Bigloo) but I
want to use Common Lisp. I know there must be certain libraries like
this, because I heard of people using CL to write network programs -- do
you know of any?
Thanks,
-- John
Stock Crack
news:Pine.LNX.4.21.00112...@ajohnson.21stcentury.net...
>
> Hello friends,
>
> It occurs to me that lesser languages like Java, etc. succeed in
> the modern world where Lisp seems like a computer science lesson from days
> of old because they have, or are perceived to have, an easy way to
> write/design a GUI, and to integrate well with low-level OS
> libraries/functions. I love Lisp, but there are things that I would never
> attempt with it that I would do in a snap with Python (actually a great
> language). I could use TK or WxPython to design a GUI frontend to my
> functions in less than an hour. Java, Python, Perl, Tcl/Tk etc. also are
> "web aware", i.e. they acknowledge that for a language to be "hot", it has
> to appeal to the web-using public, and be usable for the web by the
> web-using public.
> When Lisp gets its elegance across, as well as having easy access
> to all the things people like about things like Tcl/Tk, Java, Perl,
> Python; and not just obscure kits like Garnet, etc. (One of the problems
> is that various implementations go different lengths to provide such
> functionality--Java sucks, but at least you know what you're getting and
> what you're able to do with it!) There's only one Python, Perl, and
> Tcl/Tk, and that helps them stay central and release one version of the
> language--not the fragmented state of affairs that both Lisp as a language
> and Linux as an OS suffer.
What Lisp needs to gain more audience (still, I think, a desirable goal),
is:
1. A corporate sponsor with deep pockets and an axe to grind in the form of
a new platform; a sponsor who is willing to lose money on languages and
tools to gain platform market share. This sponsor needs to choose Lisp as
the language of choice for the new platform.
2. An updated spec so the sponsored Lisp dialect can take advantage of the
new platform's splendid characteristics.
3. Some compelling reason for people to use the new platform.
I base this conclusion on analogies to the three current popular languages,
C/C++ (Unix and to some extent Windows platforms, sponsored by AT&T and then
Microsoft), Visual Basic (Windows sponsored by Microsoft), and Java (the
Internet "platform" sponsored by Sun). Similar analogies to even older
languages could be made, such as PL/I (or whatever) for OS/360 and so on.
BTW, I believe these characterstics are necessary but not sufficient for
widespread success of a serious application programming language.
As none of those things are on the horizon, I don't think Lisp is quite out
of the trenches yet.
-- Harley
Aaron K . Johnson
On Sat, 25 Nov 2000, Patrick W wrote:
>
> "Stock Crack" <stock...@flashcom.com> wrote in message
> news:t1u932c...@corp.supernews.com...
> >
> > What Lisp needs to gain more audience (still, I think, a desirable goal),
> > is:
> >
> > 1. A corporate sponsor with deep pockets and an axe to grind in the form
> of
> > a new platform; a sponsor who is willing to lose money on languages and
> > tools to gain platform market share. This sponsor needs to choose Lisp as
> > the language of choice for the new platform.
> >
> > 2. An updated spec so the sponsored Lisp dialect can take advantage of the
> > new platform's splendid characteristics.
> >
> > 3. Some compelling reason for people to use the new platform.
> >
> > I base this conclusion on analogies to the three current popular
> languages,
> > C/C++ (Unix and to some extent Windows platforms, sponsored by AT&T and
> then
> > Microsoft), Visual Basic (Windows sponsored by Microsoft), and Java (the
> > Internet "platform" sponsored by Sun). Similar analogies to even older
> > languages could be made, such as PL/I (or whatever) for OS/360 and so on.
> > BTW, I believe these characterstics are necessary but not sufficient for
> > widespread success of a serious application programming language.
> >
> > As none of those things are on the horizon, I don't think Lisp is quite
> out
> > of the trenches yet.
>
> I think it would take much less than this to give Lisp a shot in the arm.
>
> The language stands on its own merits. People either love it or hate it, and
> those who hate it can look elsewhere - who needs them? Unfortunately those
> who love it often look elsewhere too. Those are the people who would gladly
> be persuaded to stay without corporate sponsorship or marketing slogans.
>
> I think there's little point in looking at the big issues until the small
> ones are taken into account. The reason for Lisp's lack of growth in
> popularity is very simple in my opinion.
>
> Current and future generations of good programmers are learning their craft
> with cheap and free tools on Linux and the BSDs. Suppose you're a 17 year
> old fledgeling programmer and you want to test your skill with a simple IRC
> client or a graphical logic game. You might have dabbled with clisp or cmucl
> and liked the Lisp language, but would you choose it to write your new toy?
> You'd have a hard time doing so, in spite of the the quality of the
> language.
>
> Would you then fork out for an AllegroCL license, or would you *first* think
> of using Python with Tkinter, C++ with QT or wxWindows, C with GTK+ or some
> other option instead? These other options have everything you need to build
> your toy - for nix. None of them come close to Lisp in language potency, but
> they get the simple jobs done. And from little things, big things grow ...
>
> Two simple features would attract a lot of young blood to the free Lisp
> implementations (thence onward and upward):
>
> 1. Easy gui development
> 2. Easy access to comms (web, mail, ftp, etc).
>
> I believe it really is as simple as that.
>
Excellent points. I couldn't have said it better. In particular, i believe
that Lisp needs a more centralized GUI like Tk. It should be universal,
and easy to use. When I say universal I mean EVERY Lisp implementation
should support it, so that code could be portable to any machine. That
Lisp is as popular as it is at all is a miracle (even though its truly
awesome), because most Lisp/scheme code is nowhere near being portable. I
think the portability issue and the GUI issue are of paramount importance.
Consider this from the Lisp FAQ-a list of how the different Lisps have you
save an image-
Lucid: DISKSAVE
Symbolics: Save World [CP command]
CMU CL: SAVE-LISP
Franz Allegro: EXCL:DUMPLISP (documented)
SAVE-IMAGE (undocumented)
Medley: IL:SYSOUT or IL:MAKESYS
MCL: SAVE-APPLICATION <pathname>
&key :toplevel-function :creator
:excise-compiler
:size :resources :init-file :clear-clos-caches
KCL: (si:save-system "saved_kcl")
LispWorks: LW:SAVE-IMAGE
Is it any wonder that the GUI state of things is any better?
-Aaron
Marco Antoniotti
Jochen Schmidt <j...@dataheaven.de> writes:
> Kellom{ki Pertti wrote:
>
> > Jochen Schmidt <j...@dataheaven.de> writes:
> > > So why not building a GUI-Server in wxWindows - which would run nice on
> > > win32, Linux(Motif), Linux(GTK) and so far I know on BeOS and MacOS too.
> > > wxWindows doesn't provide only GUI it provides us also with a very good
> > > socket-interface (on all supported plattforms).
> >
> > If you plan to go that way, why not use Java? It seems that the push
> > in GUI is in that front nowadays. Moreover, if you want some parts of
> > the application to run on the GUI server (a'la NeWS), then I would
> > quite prefer Java to C++ when extending the server.
>
> There are several reasons why I've not chosen Java:
>
> - It is not planned to run parts of the application on the GUI server (as
> you mentioned)
> - Native Look: wxWindows is using the native look of the several platforms.
> - Speed: You can say what you want, actual Java GUIs are _really_ slow
> (particularily those written with swing)
> - Because I prefer C++ over Java.
>
Why not stick with GTK? Just curious.
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Patrick W
Bruce Hoult
<stock...@flashcom.com> wrote:
> What Lisp needs to gain more audience (still, I think, a desirable goal),
> is:
>
> 1. A corporate sponsor with deep pockets and an axe to grind in
> the form of a new platform; a sponsor who is willing to lose money
> on languages and tools to gain platform market share. This sponsor
> needs to choose Lisp as the language of choice for the new platform.
>
> 2. An updated spec so the sponsored Lisp dialect can take advantage of
> the new platform's splendid characteristics.
>
> 3. Some compelling reason for people to use the new platform.
> As none of those things are on the horizon, I don't think Lisp
> is quite out of the trenches yet.
Well, Apple once started to try to do it with a Lisp-family language.
They axed the project along with many others when they started to lose
money.
Now they have a new platform coming out which, being a Unix with a
pretty face, may well be quite compelling for many people.
-- Bruce
Rainer Joswig
<Pine.LNX.4.21.00112...@ajohnson.21stcentury.net>,
> Excellent points. I couldn't have said it better. In particular, i believe
> that Lisp needs a more centralized GUI like Tk. It should be universal,
> and easy to use. When I say universal I mean EVERY Lisp implementation
> should support it, so that code could be portable to any machine. That
> Lisp is as popular as it is at all is a miracle (even though its truly
> awesome), because most Lisp/scheme code is nowhere near being portable. I
> think the portability issue and the GUI issue are of paramount importance.
>
> Consider this from the Lisp FAQ-a list of how the different Lisps have you
> save an image-
>
> Lucid: DISKSAVE
> Symbolics: Save World [CP command]
> CMU CL: SAVE-LISP
> Franz Allegro: EXCL:DUMPLISP (documented)
> SAVE-IMAGE (undocumented)
> Medley: IL:SYSOUT or IL:MAKESYS
> MCL: SAVE-APPLICATION <pathname>
> &key :toplevel-function :creator
> :excise-compiler
> :size :resources :init-file :clear-clos-caches
> KCL: (si:save-system "saved_kcl")
> LispWorks: LW:SAVE-IMAGE
If this hinders you to write a Common Lisp application, I think you
should better look at another comp.lang.XXX with (not (eq XXX Lisp)).
> Is it any wonder that the GUI state of things is any better?
Take the file systems. Similar important compared to GUIs.
How does C-based software manage to open files on the different
platforms (VMS, Unix, DOS, Windows XXXX, MacOS HFS, MacOS HFS+, ...)?
Is there a standard for that? For pathnames? File attributes?
Still there seems to be plenty software that has been written,
capable of accessing a file system. Common Lisp has a unified
model of pathnames and stream-based IO - still it does not better
than C.
Actually those who manage to write commercially successful
Lisp software seem to be very silent. Those who can't are
telling us once a week.
I once wrote a small application together with a student to
access our telephone system (German Telekom Octopus) and to provide
us daily usage and billing reports. I think I developed it
on MCL and Genera. It got deployed with CLisp on a SUN Enterprise 250
- the core code ran almost unchanged for a year.
The student ported it to LispWorks on Windows. Later it got
a CLIM GUI. Despite what you are saying, carefully written Lisp
code is extremely portable and able to run for years.
I once talked to people who are maintaining an application with a
million+ (!!) lines of Lisp code. They develop on Lisp machine
and deploy on ACL. A port of this application to LispWorks
took them just three months. For a million lines of Lisp code...
Now you tell me Lisp is not portable. (The joke was when they
looked at CL-HTTP, it was a refreshingly small application for
them.)
If you, for example, use CL-HTTP you can deploy your code with a web
interface on several platforms virtually unchanged (Windows,
Unix, Mac, Lispm). John Mallery takes great care to publish
new devos as Mac, tar.gz and Lispm distribution. I often wish
there were more Lisp developers that are as fearless as he is.
Would you, when the White House asked you to write a web
application to distribute government documents, write your
own web server in Lisp, patch the Lisp machine mailer so that
it actually works, write your own document distribution system
for web and mail access in Lisp, use a CLOS database, and ***deploy***
it on a Lisp machine? Without a single line of C/Java/Perl/... code?
Sure not, you would give up *******************long************************
before, just because there are ten ways to dump a Lisp application??!!
John's approach is different: If there is an obstacle (say a bug
in a TCP interface), it gets debugged and fixed once and forever.
If there is an incompatibility in the different Lisps, he provides
a portable version. What's the result: the code he wrote runs at
the White House for several years now and the White House is actively
**using** it. The system even survived the rush hours during the
Lewinsky affair. ;-) Other used the system on different platforms
(NASA: MCL, Honda: ACL, Incops: MCL, XXX: LispWorks, ...) to
deploy complex user interfaces. Have you ever looked at the Lisp course
(http://www.psychologie.uni-trier.de:8000/elmart) that's running
in MCL+CL-HTTP over the web? This application received an "European
Academic Software Award" in 1998.
I also used Paul Meurer's ODBC interface in MCL
and LWW (works also for ACL). Code runs without any changes.
What's wrong using one of those libraries on top of CLX
for X graphics? Say CLUE, CLIO, XIT, CLIM, ...? Choose one.
Most of can be made running in any Lisp. I even once changed
CLX to run in MCL - this is work of a few hours. MCL than
will connect to an X server. If you are really interested, some
companies are offering portable Lisp GUI libraries. IISY
offered a MCL compatible GUI library for ACL, GBB is offering
"Chalkbox", even students seem to be capable of connecting
Java with Lisp (http://www.ai.mit.edu/people/cvince/date/screen-navigator.html).
To give you a last example. Here in Hamburg, a company developed a
Lisp-based application for the telephone support staff of
the local public transport system. It finds routes through
the extensive public transport system (bus, underground train, trains and
ships). The application has been prototyped and later deployed
in three versions: a) for the support staff with SUN+Screen+Keyboard,
b) SUN + touchscreen + printer using a special console that survives
unfriendly usage for the public and c) a CGI version for the web. (now there
is also a Java version for PCs). If you go to
the Hamburg Central station you will be able to use a such a public
terminal - sure nobody knows that it is written in Common Lisp + CLX.
But it is ***cool***. So damn cool.
Greg Menke
> Current and future generations of good programmers are learning their craft
> with cheap and free tools on Linux and the BSDs. Suppose you're a 17 year
> old fledgeling programmer and you want to test your skill with a simple IRC
> client or a graphical logic game. You might have dabbled with clisp or cmucl
> and liked the Lisp language, but would you choose it to write your new toy?
> You'd have a hard time doing so, in spite of the the quality of the
> language.
On the other hand, sometimes you get to a point where you're *tired*
of jumping through hoops just to do simple things- and really sick of
being pushed around by a bunch of "features" that some committee of
marketers think you need. Then you start looking for a stable, well
specified environment, which lets you just do what you want without a
lot of fuss and bother. Given those requirements, the list of
languages gets small pretty fast. Notably, Lisp stays on the list-
suffering not from language problems but from a perceived lack of
"integrability". I find ramping up skill in Lisp is lots more
enjoyable than doing so in C++. But, at some point you get annoyed at
the lack of a thorough, organized top to bottom infrastructure in
clisp/cmucl and then Allegro/Lispworks start to look appealing.
Me, as a nominal Lisp amateur, I'm bartering some time working for my
Dad's company in exchange for them buying me a copy of LispWorks.
Why? Because it makes me think differently. C/C++ is all very well,
but I really value how Lisp makes me reconsider everything. The
recent Sapir-Whorf references on this list make that point especially
germane, as C/C++ and all their brood certainly engender particular
approaches- sometimes nearly programming cliches. "Software
Patterns", indeed. Its kind of fun to think "mapcar" when I see a
menu in restaurant... and I can't even begin to say how much I
appreciate NOT having to fiddle with pointers. People can say all
they like about how 'strange' Lisp syntax is- but those that do have
likely not compared it in detail to some of the more exotic C++
notation.
I'm all for cheap/free tools, I think that is certainly the way to
learn. After acquiring a degree of skill, I think a programmer may
end up at a point where choices must be made to satisify their need
for performance and efficiency in their tools, and I think thats where
the commercial Lisp environments come in.
William James suggested people choose their religions to suit their
tempraments, maybe a similar function occurs with programmers & their
languages. Of course, that means some people tend towards COBOL. To
each their own.. ;)
Gregm
john...@my-deja.com
> Lastly, on the lack of libraries, I'd like to suggest to the people
> that complain about it to write some and make them available. Some
> complainers seem to think it their right to demand such things from
> the people who use CL to write applications. Even setting issues of
> intellectual property aside, making available code to the public has a
> real cost. But even on the availability of libraries, the comparison
> should be made carefully. There is in the {Perl, Python, Java, ...}
> community a plethora of libraries for the more simple things like
> HTTP, SMTP etc.
> This stuff is so trivial in CL that I usually roll my
> own since looking for a library, evaluating the licence, compiling it
> and getting it integrated in my environment would take longer than
> just writing it myself.
I am new to Lisp, and I'm looking for libraries such as those for HTTP
and SMTP.
I don't expect other Lisp programmers to write libraries for me, but
many people who come to Lisp from other languages wonder how come there
aren't many available (I'm talking about networking libs here, not GUI
stuff because there are many of those around) since Lisp has been here
for a while.
I'm not lazy, and I'm willing to write my own libraries and make them
publicly available for no charge, but I don't know where to begin. If I
don't even have a basic socket interface (I can't find any libs that
provide even that), how can I write such libraries? You say it's
trivial, and I'm really curious how. Could you please briefly explain
how one would go about writing a thing like that? Where to begin, etc.
Thanks a lot,
Patrick W
"Rainer Joswig" <jos...@corporate-world.lisp.de> wrote in message
news:joswig-17D2BB....@news.is-europe.net...
>
> Actually those who manage to write commercially successful
> Lisp software seem to be very silent. Those who can't are
> telling us once a week.
Maybe they have a point (beyond the obvious implication that they lack the
ability).
I don't think Aaron intended to imply it's not possible to write
commercially successful software in Lisp. I didn't either. I think both of
us, in contrast to you, were discussing aspects of Lisp's lack of surface
appeal to new generations of programmers, *not* suggesting it isn't a great
practical tool for experienced Lispers.
[ John Mallery's fearlessness]
> Sure not, you would give up
*******************long************************
> before, just because there are ten ways to dump a Lisp application??!!
> John's approach is different: If there is an obstacle (say a bug
> in a TCP interface), it gets debugged and fixed once and forever.
> If there is an incompatibility in the different Lisps, he provides
> a portable version.
Would you step back a bit and look at the context of the discussion? I
notice you've got a Lisp machine on your home page, so is it a fair
assumption you've been around Lisp for a long time? I'm assuming you know
what a great language it is, you're comfortable with the tools you use, and
you're confident in your ability to make Lisp do whatever you desire. John
Mallery's fearlessness must have come from a similar confidence. It's not
something that one would or could do having only a passing acquaintance with
Lisp.
Having more people like John Mallery would be a nice side effect of making
Lisp more accessible to new generations of programmers. Not the only side
effect, to be sure. There would be a lot more noise and stupidity as well.
But if 1% of those who pick up on Lisp are enthusiastic and talented, there
will be progress - in tools, literature, community, momentum, public
profile. Without the bare minimum of surface appeal, there will be fewer
talented people who even *try* Lisp. (I don't know JM, but I know a few who
have the same attitude. Most of them have never touched Lisp They're using
Python).
Not knowing what you're missing is a strong disincentive to perseverance.
You and John Mallery may not have that problem. Others ... well ... don't
know what they're missing.
Fernando Rodríguez
<espen@*do-not-spam-me*.vestre.net> wrote:
>several serious java programmers I've talked have no problems admitting
>that java is not suitable for serious GUIs. "BUT", they tend to add,
I don't have much experience with Java, but the few java apps I've
used were a serious memory hog and slower than Visual Basic. This is why I'm
not sure if I like the idea (Kent's idea?) of adding extensive support for
calling java libs: I'm scared that java libs will bring java performance...
:-P
>"it's perfect for servers". However, the java servers I've seen so far
>that have really been put to stress tests (real life stress tests,
>running on really heavy Sun iron serving a *lot* of clients), have
>performed almost unbelievably lousy.
Maybe CL vendors should go for that market: java programmers who were left
stranded by java's performance. CL seems like the perfect tool for "servlets"
and it might be a good way to increase our small community.
Fernando Rodríguez
<jos...@corporate-world.lisp.de> wrote:
>I once talked to people who are maintaining an application with a
>million+ (!!) lines of Lisp code. They develop on Lisp machine
=:-O Damn, I never went past the 80.000... ;-) What does this app
do? Just curious...
>If you, for example, use CL-HTTP you can deploy your code with a web
>interface on several platforms virtually unchanged (Windows,
>Unix, Mac, Lispm). John Mallery takes great care to publish
I was planning to take a look at it or Allegro serve. How would you
compare both (features, documentation, performance...)? O:-)
>deploy complex user interfaces. Have you ever looked at the Lisp course
>(http://www.psychologie.uni-trier.de:8000/elmart) that's running
Yes, and it's _really_ cool. :-)
Rainer Joswig
<mai...@my-deja.com> wrote:
> Would you step back a bit and look at the context of the discussion? I
> notice you've got a Lisp machine on your home page, so is it a fair
> assumption you've been around Lisp for a long time? I'm assuming you know
> what a great language it is, you're comfortable with the tools you use, and
> you're confident in your ability to make Lisp do whatever you desire. John
> Mallery's fearlessness must have come from a similar confidence. It's not
> something that one would or could do having only a passing acquaintance with
> Lisp.
But I started somehow sometime, writing my share of Pascal, Basic,
Assembler and Modula 2.
> Having more people like John Mallery would be a nice side effect of making
> Lisp more accessible to new generations of programmers.
Maybe it is also the other way round? "The new generation of programmers"
needs to be more accessible? Maybe after some time of experimenting
they will. Like children experimenting with smoking and after
some time the will discover that it is unhealthy not at lot
of fun (besides many telling you).
> Not the only side
> effect, to be sure. There would be a lot more noise and stupidity as well.
Yes, but this is normal.
> But if 1% of those who pick up on Lisp are enthusiastic and talented, there
> will be progress - in tools, literature, community, momentum, public
> profile.
Much of what others want to achieve, is already there. But maybe not
in a way they expect.
If people feel the need for (new) tools, literature, community. etc.
I'd say, go ahead. Create tools, write books, build a community.
You can't expect me to do it for you. I have my own agenda
and write my own tools.
There is also no need to discover and use Lisp. Many programmers can
get along and can survive without ever touching it. Other
programming languages and tools are also productive.
There is no obvious need to drive a Mercedes. But those
who did will know that it is well-engineered and reliable.
> Without the bare minimum of surface appeal, there will be fewer
> talented people who even *try* Lisp. (I don't know JM, but I know a few who
> have the same attitude. Most of them have never touched Lisp They're using
> Python).
They need to learn and discover Lisp. They even need to form the
language for their needs (like the previous generations of users formed
Lisp for their purposes). Lot's of things are simply there and
need to discovered. An example: people would get the impression
that there are no books about Lisp - they look into their
bookstore and they see hundred books about Java and maybe none
about Lisp. They just need to discover that one can order books
and there are book catalogs that one can browse. They also
need to discover that there is a thing called the Internet,
where some of the most important Lisp books are available (CLtL2,
ANSI CL HyperSpec, ...) in various formats.
What they need to be? They need to be programmers in the first
place. Having written 5KLOC of Python doesn't make you a programmer.
Much of the source code you can see at Sourceforge scares me,
it is of incredible poor quality and I wouldn't let it into
my software. Just writing it again gives me much more confidence
in the code. I would agree with Peter Norvig's observations
(http://www.norvig.com/21-days.html) and his motto:
"Teach Yourself Programming in Ten Years".
Lisp is the Zen way of Programming.
Lieven Marchand
> A bit more vibrant community wouldn't be a bad thing. I know that's anathema
> to some of you guys, but the attitude in c.l.l. sometimes reminds me of a
> clan of rich retirees languishing in luxury in an exclusive suburb. If
> someone under thirty arrives you can almost people muttering: "There goes
> the neighbourhood".
I was thirthy-ish when I discovered CL but I don't think your image is
correct. I think one of the strengths of Lisp is that is has been used
for forty years to solve the most challenging and complex problems of
the time. The language has been designed with large and complex
applications in mind. This means that to see the advantages of CL it
helps to have experience with other languages in large applications.
A beginning programmer with his shining new C++ compiler and GUI
toolkit reads the tutorial, writes 100 lines of code and has a small
graphical application with an edit widget, some buttons and an
image. Now you show him that you can do this with 40 lines of
Lisp. This isn't going to convince him. Now go to a team of C++
programmers with 10 million lines of code that is such a tangle of
includes and dependencies that it takes a day to compile on an Ultra
10. Give them a demonstration that you can redefine a class in the
listener, write an update function and have the existing instances in
your system consistent with the new definition, and you'll have their
attention.
But it takes a few years of experience of other languages to
appreciate CL. The same thing goes on with the debate of pricing
(esp. Franz's). If you approach it from the hobbyist programmer's
point of view and compare the price of MS Visual
Whatever-it-is-called-these-days to a commercial Lisp, you'll find it
excessive. If you compare it to stuff from Platinum, Computer
Associates or Rational for Enterprise development it's cheap. Note
that these vendors don't target the home market at all. It is in fact
a significant contribution to the Lisp community by Franz and Xanalys
to make available trial versions. Some people here tend to assume they
have a right to them and for them to be free, but these projects cost
real money to Franz and Xanalys.
Lastly, on the lack of libraries, I'd like to suggest to the people
that complain about it to write some and make them available. Some
complainers seem to think it their right to demand such things from
the people who use CL to write applications. Even setting issues of
intellectual property aside, making available code to the public has a
real cost. But even on the availability of libraries, the comparison
should be made carefully. There is in the {Perl, Python, Java, ...}
community a plethora of libraries for the more simple things like
HTTP, SMTP etc. This stuff is so trivial in CL that I usually roll my
own since looking for a library, evaluating the licence, compiling it
and getting it integrated in my environment would take longer than
just writing it myself. On the other hand, libraries for somewhat more
complex stuff are rare in any language since they take a lot of
work. I'm not aware of too many libraries for z39.50 or free asn.1
compilers or stuff like that.
--
Lieven Marchand <m...@bewoner.dma.be>
Lambda calculus - Call us a mad club
Aaron K . Johnson
The interchange below is extremely funny :) . I just want to say this-we
are all friends here, because we all care about the future os an
elegant language. Rainer, obviously, you are a Lisp guru of sorts who
would have much to bring to the community. I think Patrick is doing a
better job of understanding my points here. I don't mean to insult Lisp,
but merely wish to discuss some of the potential reasons why it isn't more
popular than it should be. You may not agree that it isn't popular, but if
you said that, I'd say you are living in isolation, perhaps working for
one of the few companies that DOES use Lisp.
To re-iterate my points, and I want to say Rainer, that your previous
points were well-taken (in particular re:the filesystem).
1) Lisp may never really well take off like say, Python, if the
public doesn't get a free implemetation that they feel and perceive to be
more or as powerful as Python. This means whipping up a GUI in short order
that will without fuss be portable, handsome/eyecatching, easily
maintained, etc.
2) Lisp has to fight an uphill Public Relations battle at this
point that a new language like Python doesn't. Lisp is doing well
considering the years of apprehension and misunderstanding about it being
an ancient academic language.
3) Tutorials must be written (yes, with pretty screenshots, etc.)
that show a powerful Lisp in action, with colorful GUI's. I cannot
understress this point enough. Its human psychology to consider the "cool"
things to be handsome and colorful. Just Look at Tcl/Tk. As a language,
and how it performs-its terrible. But people look at Tk and think "that's
really attractive". Its sounds superficial, but its true, and, after all,
aesthetics ARE important. I still have a hard time imagining Lisp as being
a visually striking platform to code in. Most people do. Again you could
argue with me, but you'd be wrong because you'd be blind to the hard
numbers of where people are looking (Java, Tcl/Tk, Python)
I'll take this up later....gotta go now.
-Aaron
On Sun, 26 Nov 2000, Patrick W wrote:
>
> "Rainer Joswig" <jos...@corporate-world.lisp.de> wrote in message
> news:joswig-B476C1....@news.is-europe.net...
> > In article <BkKT5.45138$SF5.8...@ozemail.com.au>, "Patrick W"
> > <mai...@my-deja.com> wrote:
> >
> > > Would you step back a bit and look at the context of the discussion? I
> > > notice you've got a Lisp machine on your home page, so is it a fair
> > > assumption you've been around Lisp for a long time? I'm assuming you
> know
> > > what a great language it is, you're comfortable with the tools you use,
> and
> > > you're confident in your ability to make Lisp do whatever you desire.
> John
> > > Mallery's fearlessness must have come from a similar confidence. It's
> not
> > > something that one would or could do having only a passing acquaintance
> with
> > > Lisp.
> >
> > But I started somehow sometime, writing my share of Pascal, Basic,
> > Assembler and Modula 2.
>
> Of course. I'm not suggesting you old-timers had all the breaks and life's
> so much tougher than it used to be. In a lot of ways beginners today have it
> much easier - but they're pampered with the wrong luxuries - like junk
> food - plenty of fat but no real nourishment.
>
> > > Having more people like John Mallery would be a nice side effect of
> making
> > > Lisp more accessible to new generations of programmers.
> >
> > Maybe it is also the other way round? "The new generation of programmers"
> > needs to be more accessible?
>
> Sure. I wouldn't argue with that. However, it's not one or the other. It's
> both.
>
> > > But if 1% of those who pick up on Lisp are enthusiastic and talented,
> there
> > > will be progress - in tools, literature, community, momentum, public
> > > profile.
> >
> > Much of what others want to achieve, is already there. But maybe not
> > in a way they expect.
>
> Fair comment. But IMO the current state of affairs is dangerously close to:
> "much of what others want once was there, and still may be if you look hard
> enough".
>
> > If people feel the need for (new) tools, literature, community. etc.
> > I'd say, go ahead. Create tools, write books, build a community.
> > You can't expect me to do it for you. I have my own agenda
> > and write my own tools.
>
> A bit more vibrant community wouldn't be a bad thing. I know that's anathema
> to some of you guys, but the attitude in c.l.l. sometimes reminds me of a
> clan of rich retirees languishing in luxury in an exclusive suburb. If
> someone under thirty arrives you can almost people muttering: "There goes
> the neighbourhood".
>
> > There is also no need to discover and use Lisp. Many programmers can
> > get along and can survive without ever touching it. Other
> > programming languages and tools are also productive.
> > There is no obvious need to drive a Mercedes. But those
> > who did will know that it is well-engineered and reliable.
>
> And the rarer the Mercedes, the better you enjoy yours hmm? ;-)
>
> >... people would get the impression
> > that there are no books about Lisp - they look into their
> > bookstore and they see hundred books about Java and maybe none
> > about Lisp. They just need to discover that one can order books
> > and there are book catalogs that one can browse. They also
> > need to discover that there is a thing called the Internet,
> > where some of the most important Lisp books are available (CLtL2,
> > ANSI CL HyperSpec, ...) in various formats.
>
> True, the books are few - but of a standard you don't find elsewhere.
> (Norvig's PAIP is worth more than any number of C++ books I've bought).
>
> > What they need to be? They need to be programmers in the first
> > place. Having written 5KLOC of Python doesn't make you a programmer.
> > Much of the source code you can see at Sourceforge scares me,
> > it is of incredible poor quality and I wouldn't let it into
> > my software. Just writing it again gives me much more confidence
> > in the code. I would agree with Peter Norvig's observations
> > (http://www.norvig.com/21-days.html) and his motto:
> > "Teach Yourself Programming in Ten Years".
>
> Yes, an interesting article. It concurs with my experience in other fields.
>
> > Lisp is the Zen way of Programming.
>
> Eh? Vague? Unpredictable? Mind-bendingly illogical? Without structure?
> Inscrutable? Liable to whack you over the head with a thick stick at any
> moment? Jesus, man, what sort of software you creating?? ;-)
>
>
>
>
Paolo Amoroso
> wrote with the languages I mentioned, but I cannot find a Lisp library
> that provides basic networking facilities that are needed to write the
> type of programs I want to. I looked at clocc
> <http://clocc.sourceforge.net>, but it has almost no documentation or
> examples that come with it, and I cannot get it to work. I found many
Part of the reason why you don't find much documentation included with
CLOCC is that the project is still relatively young--about 9 months, if I
remember well. Simply put, there are currently few resources for writing
documentation or examples.
As for CLOCC basic networking facilities, I suggest that you look at
src/port/net.lisp, particularly the function names (mostly
self-explanatory), the lambda lists and the documentation strings. Since
the file is short--around 350 lines--you may also try reading the code
itself. For examples of use check src/cllib/url.lisp. At times beginners
overestimate the difficulties of reading source code.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Rainer Joswig
<Pine.LNX.4.21.00112...@ajohnson.21stcentury.net>,
"Aaron K . Johnson" <a...@21stcentury.net> wrote:
> better job of understanding my points here. I don't mean to insult Lisp,
> but merely wish to discuss some of the potential reasons why it isn't more
> popular than it should be.
You make the assumption that "it should be popular". Why? You are
talking about Lisp in general (which is popular) or about
Common Lisp?
> You may not agree that it isn't popular, but if
> you said that, I'd say you are living in isolation, perhaps working for
> one of the few companies that DOES use Lisp.
No, I'm not simply working for a company that does use Lisp.
If necessary, I make the company use Lisp.
> 1) Lisp may never really well take off like say, Python,
Look, there are areas where Python not even comes close to Lisp.
You are bound to this scripting is programming thing.
> 3) Tutorials must be written (yes, with pretty screenshots, etc.)
> that show a powerful Lisp in action, with colorful GUI's.
See David Lamkins presentation of Macintosh Common Lisp.
See some screenshots of MCL applications on my tiny web site.
> and how it performs-its terrible. But people look at Tk and think "that's
> really attractive".
Then we have a different idea about "attractiveness". The latest
thing that looks relatively attractive is the new MacOS X GUI.
Compared to that most of the stuff out there is UGLY. Plain UGLY
and ANCIENT.
> aesthetics ARE important. I still have a hard time imagining Lisp as being
> a visually striking platform to code in.
See the Sk8 and Igor Engraver screenshots on my web site
(a version of Igor Engraver will be available from Noteheads
for Windows soon - doing cross-platform development for an
application with extreme graphics/font demands using Macintosh
Common Lisp and LispWorks for Windows).
Go to www.wingededge.com and look at the screen shots of Mirai
(an Allegro Common Lisp application). This is as mindblowing as it
gets. Or read a bit about the hundred projects that were done with Sk8:
http://www.cwi.nl/~steven/sigchi/bulletin/1998.2/spohrer.html
See some screenshots of an application called "Eon":
http://www.cs.umass.edu/~tmurray/papers/JLSEon/JLS96.html .
There are lots of examples of highly visual applications
done in Lisp. You just don't know it. Nobody told you.
And you didn't look.
> Most people do. Again you could
> argue with me, but you'd be wrong because you'd be blind to the hard
> numbers of where people are looking (Java, Tcl/Tk, Python)
I'm very fond of visual appeal when it comes to programming, that's
why I most of the time use a Mac. Look&feel is simply so much
better than the Java/Python/TCL/PERL GUI crap.
Kent M Pitman
> A beginning programmer with his shining new C++ compiler and GUI
> toolkit reads the tutorial, writes 100 lines of code and has a small
> graphical application with an edit widget, some buttons and an
> image. Now you show him that you can do this with 40 lines of
> Lisp. This isn't going to convince him. Now go to a team of C++
> programmers with 10 million lines of code that is such a tangle of
> includes and dependencies that it takes a day to compile on an Ultra
> 10. Give them a demonstration that you can redefine a class in the
> listener, write an update function and have the existing instances in
> your system consistent with the new definition, and you'll have their
> attention.
Probably they just won't believe you that it's possible. That would mean
they had wasted their life and that's hard to admit. "And anyway",
they'd add to reassure themselves, "if it were possible, it would surely
have been something someone would have made noise about long before now.
No, probably it's just smoke and mirrors and not serious technology I can
gamble 10 million lines of code on."
Erik Naggum
| modern world where Lisp seems like a computer science lesson from days
| of old because they have, or are perceived to have, an easy way to
| write/design a GUI, and to integrate well with low-level OS
| libraries/functions.
Are you referring to ANSI Common Lisp, the Standard, when you make
these claims? If so, do you consider standardization of a language to
be a negative aspect of its usability? In other words, would you
rather use an unstandardized language with many useful bells and
whistles over a standardized language with many useful, unstandardized
bells and whistles?
All too many of those who complain about Common Lisp have very little
idea what they can do with the language in the available environments,
and seem awfully preoccupied with specific (free) implementations and
what they can do, just like they are willing to use one-implementation
"languages" in ways they _claim_ they would never use a standardized
language, so one must assume that they have some sort of weird hangup
against implementation-specific features unless there is only _one_
implementation.
| I love Lisp, but there are things that I would never attempt with it
| that I would do in a snap with Python (actually a great language).
I'm extremely wary of people who say "I love Lisp, but ...".
There is _nothing_ I would not write in Common Lisp, because just like
Python and whatever other "great" tools are out there, somebody had to
write them and they chose a to build a _language_ to make that tool.
Well, guess what? Common Lisp is the language-building language par
excellence. Why do you need a whole new syntax and cruft just to add
a few nice pieces? That's just an insane abuse of scarce resources,
and a completely misguided notion of "competition".
| I could use TK or WxPython to design a GUI frontend to my functions in
| less than an hour.
Good for you! Have you tried Allegro CL's GUI builder?
| Java, Python, Perl, Tcl/Tk etc. also are "web aware", i.e. they
| acknowledge that for a language to be "hot", it has to appeal to the
| web-using public, and be usable for the web by the web-using public.
Only Java is web-aware qua language as far as I can tell. The rest
have some software written _in_ their language that could make a claim
to being web-aware, but qua language? No way!
You are not really talking about languages, Aaron, but about tools.
If you insist on comparing tools with languages, languages must lose.
An application with an input language that can modify its behavior is
very different from a full-blown programming language with a separate
specification from its implementations, plural.
| When Lisp gets its elegance across, as well as having easy access to
| all the things people like about things like Tcl/Tk, Java, Perl,
| Python; and not just obscure kits like Garnet, etc.
So what's wrong with the _language_ Common Lisp because of this?
| There's only one Python, Perl, and Tcl/Tk, and that helps them stay
| central and release one version of the language--not the fragmented
| state of affairs that both Lisp as a language and Linux as an OS
| suffer.
And what would happen if you added all the stuff that you want to
Common Lisp? I cannot see how it could possibly lead to _less_
fragmentation. You would not use the software written in Common Lisp
if it were there because it is not part of the language (standard),
and so there is no way for Common Lisp to overcome that "I love Lisp,
but" stand that you have chosen to take, is there?
Where, exactly, did you look before you decided what Lisp is missing?
The _only_ way you can get better able to use Common Lisp is, *gasp*,
to _use_ Common Lisp, just like someone decided to _use_ Python, Perl,
etc. If some hypothetical "I love Perl, but ..." crowd had complained
like you do, _nothing_ of what you apparently like about these tools
would ever have happened. Why do these people just get the work done?
Is it because do _not_ "love" their languages? Why is it OK to use
"love" for Common Lisp as an excuse _not_ to use it?
#:Erik, seriously annoyed.
--
Solution to U.S. Presidential Election Crisis 2000:
Let Texas secede from the Union and elect George W. Bush their
very first President. All parties, states would rejoice.
Patrick W
Rob Warnock
+---------------
| So why not building a GUI-Server in wxWindows - which would run nice on
| win32, Linux(Motif), Linux(GTK) and so far I know on BeOS and MacOS too.
This is exactly why the Rice PLT group chose wxWindows for their
"MrEd" <URL:http://www.cs.rice.edu/CS/PLT/packages/mred/index.html>
GUI application toolkit (upon which the "DrScheme" development & teaching
environment is built). MrEd runs on all of Windows 95/98/NT/2000, MacOS,
and Unix/X (including Linux here as a "Unix").[*] It provides:
- A windowing toolbox for creating windows and menus
- A drawing toolbox for drawing to windows, bitmaps,
and printer devices
- An editor toolbox for creating multimedia editors
MrEd's GUI toolbox is integrated with a thread system.
MrEd dispatches each GUI event to the handler thread via
synchronous (single-threaded) callback procedures, but
MrEd also supports multiple eventspaces, which permit
asynchronous (multi-threaded) event handling among
different sets of windows.
MrEd's underlying Scheme engine, "MzScheme", provides a fairly typical
interface to TCP/IP networking, so hooking a Common Lisp application
to a MrEd-based GUI over sockets should be relatively straightforward.
The *real* question is going to be the protocol between the CL application
and a MrEd-based GUI. I don't mean the syntax -- you can certainly use
S-exprs & READ [though one would of course want to stick to the common
subset of the CL & Scheme S-exprs syntaxes] -- I mean the semantics.
There's the inevitable question of trading off simplicity of interface
(which many presume to equate with portability, though that's really a
*different* issue) versus exposing the full functionality (or most of it)
of the backend GUI. Look at this and you'll see what I'm talking about:
<URL:http://www.cs.rice.edu/CS/PLT/packages/doc/mred/index.htm>
The good news is that there's a lot more than Tk there.
The bad news is that there's a lot more than Tk there. ;-} ;-}
+---------------
| I would prefer a very simple approuch like LispWorks CAPI (or simpler
| for the beginnigs). IMHO if we concentrate on simplicity we could
| have it in _very_ short time.
+---------------
Suggestion: Start by defining the protocol. Then publish it for comments.
-Rob
[*] While MzScheme itself does run on BeOS [and even on "bare" x86
PCs, as a kernel based on Utahs' "OSKit"], unfortunately MrEd doesn't,
at least not as distributed. If, as you say, wxWindows *does* run on
BeOS, it might be possible to port MrEd fairly straightforwardly
(though note that the wxWindows which MrEd uses has diverged somewhat
from Julian Smart's original version).
-----
Rob Warnock, 31-2-510 rp...@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043