Why I didn't chose LISP
Johann Höchtl
Last year I thought it would be a good idea to learn a new programming
language. But which one ?
I thought a language comming from a research background would be a good
choiche and so i ended up with most notably
O'Caml (Objective Caml, www.ocaml.org)
Mozart/Oz (www.mozart-oz.org)
Python (www.python.org) and
Common Lisp (especially CLISP, clisp.cons.org or
sourceforge.net/projects/clisp)
Useless to say that I discovered in every language pros and cons as
every language is more or less suited for a special programming area.
I read so much good news about Lisp, a language dating back to around
1960 and i decided to give it a closer view.
As in the case of O'Caml, Mozart and Python those implemetations all
cary a licence as free as in 'free beer' and are all especially
cross-plattform (read: Unix-Windows) I decided to pick for Common Lisp a
'free' implementation to: CLISP.
I downloaded the required files for each implementation and installed
both a Linux and a Windows version.
My first impression was: every language comes with a GUI, not so CLISP.
OK, maybe CLISP was the wrong choiche to have a GUI so hopefully a good
language binding to Graphics libraries. Again a failure: there are
bindings, but inferrior both in terms of technical quality (synchrnous
communication with tk) or completely outdated. What about QT, gtk, X?
Well there are a couple of bindings for X, but they are old, most of
them unmaintained, not compatible between various Common LISP
implementaions and unquestionable not cross-plattform. gtk? Yes, I found
two bindings, one (clg) stalled in April 2001 the other one (cl-gtk) in
1999! Qt? No bindings for Qt so far ...
To be fair, this is not an especial lack of CLISP but of all free Common
Lisp implementations - but for most of them (gcl, sbcl, cmucl) X
bindings are just fine, as they are not portable (statet online at least
for cmucl and should at leat be true for sbcl) to windows anyway.
I was sad. So I heard so much good rumour about that great language and
no powerfull, cross plattform language bindings?
The next important thing for a language to be useful in the public,
outside of AI and university halls is multithreading.
I found out that list has it's unique way of co-routines but when it
comes down to OS System call or user-imput, "real" mult-threading, eithr
green threds or native threads are important.
What did I found? CLIM defines some multi-threading? A GUI-builder?
Strange ...
I could continue. Please note that this is by far not a special rant
about the CLISP implementation. This is true for most open source LISP.
In the open source movement it is not clear whether varity is good - is
it good to have several GUI efforts? (KDE, GNOME) Is it good to have
several efforts for free Office Suits?
At least for Common Lisp I can say it is not good. Paul Graham and
others try to convince the community that LISP is not a AI language
only, sthg. suitable for ressearch only, or to be only of academic interest.
Of what I discovered I must say: Sad, but it's not true. Use it to
crunch numbers, debug the flow of messages of the really powerful CLOS
(but hopefully you can use the MOP) -- but never try to get a "Hello
World".lisp both under windows and unix to execute, while a second
thread is reading the contents of a database. Something useful, a
'real-world-scenario' I am talking about.
Regards,
Johann
Jochen Schmidt
> Hello community!
>
> Last year I thought it would be a good idea to learn a new programming
> language. But which one ?
>
> I thought a language comming from a research background would be a good
> choiche and so i ended up with most notably
>
> O'Caml (Objective Caml, www.ocaml.org)
> Mozart/Oz (www.mozart-oz.org)
> Python (www.python.org) and
> Common Lisp (especially CLISP, clisp.cons.org or
> sourceforge.net/projects/clisp)
>
> Useless to say that I discovered in every language pros and cons as
> every language is more or less suited for a special programming area.
>
> I read so much good news about Lisp, a language dating back to around
> 1960 and i decided to give it a closer view.
>
> As in the case of O'Caml, Mozart and Python those implemetations all
> cary a licence as free as in 'free beer' and are all especially
> cross-plattform (read: Unix-Windows) I decided to pick for Common Lisp a
> 'free' implementation to: CLISP.
You could also try CMUCL, SBCL, OpenMCL, ECL, GCL
With varying degrees of features , portability and ANSI-compatibility.
I think you will agree that CL as a language is not defined by one
implementation like O'Caml or Mozart/Oz for example. This fact allows you
to some degree to choose between different implementations with different
design-goals. It is a gain not a lack.
> I downloaded the required files for each implementation and installed
> both a Linux and a Windows version.
>
> My first impression was: every language comes with a GUI, not so CLISP.
By GUI you seem to mean "IDE". The free systems seem to use mainly ILISP
which integrates them nicely into Emacs. A newer IDE that runs with CLISP
and CMUCL is "JabberWocky" which has a Java based GUI.
Xanalys' free "Personal Edition" comes with a really good integrated IDE
which runs under Linux and Windows.
> OK, maybe CLISP was the wrong choiche to have a GUI so hopefully a good
> language binding to Graphics libraries. Again a failure: there are
> bindings, but inferrior both in terms of technical quality (synchrnous
> communication with tk) or completely outdated. What about QT, gtk, X?
> Well there are a couple of bindings for X, but they are old, most of
> them unmaintained, not compatible between various Common LISP
> implementaions and unquestionable not cross-plattform. gtk? Yes, I found
> two bindings, one (clg) stalled in April 2001 the other one (cl-gtk) in
> 1999! Qt? No bindings for Qt so far ...
clg got developed further and AFAIR got a bit delayed by the development of
GTK+2.0. I heard rumours that clg will use UFFI in future this could lead
to a GTK binding which runs on many CL implementations.
Another GUI effort is "McCLIM" a free implementation of "CLIM" which grows
rather quickly. McCLIM will be backend independent. Until now it has a X
and an OpenGL backend.
> To be fair, this is not an especial lack of CLISP but of all free Common
> Lisp implementations - but for most of them (gcl, sbcl, cmucl) X
> bindings are just fine, as they are not portable (statet online at least
> for cmucl and should at leat be true for sbcl) to windows anyway.
Hm... neither are CMUCL/SBCL by definition not portable to Windows nor are
X Applications unusable under Windows.
The nice thing with the CommonLisp bindings to X (CLX) is that they don't
use the C libraries but talk the X protocol directly. So the only thing the
implementation has to provide is sockets (no FFI to GUI libraries in C are
needed).
> I was sad. So I heard so much good rumour about that great language and
> no powerfull, cross plattform language bindings?
Well - there is commercial CLIM running on ACL, LispWorks and MCL and there
is CAPI for LispWorks. So what you seem to miss are "gratis" GUI Toolkits.
As I described above there are several interesting projects in the work and
you are free to help them out.
> The next important thing for a language to be useful in the public,
> outside of AI and university halls is multithreading.
Oh - and multithreading is not useful in AI or university settings - why
is this so?
> I found out that list has it's unique way of co-routines but when it
> comes down to OS System call or user-imput, "real" mult-threading, eithr
> green threds or native threads are important.
Hm - I don't think I understand what you mean. CMUCL on x86 supports
cooperative user-level multi-threading. ACL, LispWorks and MCL support
preemptive multi-threading (AFAIR). I'm not sure but it may be that ACL or
LW support native threads on some platforms.
> What did I found? CLIM defines some multi-threading? A GUI-builder?
> Strange ...
CLIM has a portability-layer called "CLIM-SYS" which defines an interface
for multithreading. CLIM itself is a GUI-Toolkit.
> I could continue. Please note that this is by far not a special rant
> about the CLISP implementation. This is true for most open source LISP.
> In the open source movement it is not clear whether varity is good - is
> it good to have several GUI efforts? (KDE, GNOME) Is it good to have
> several efforts for free Office Suits?
> At least for Common Lisp I can say it is not good. Paul Graham and
> others try to convince the community that LISP is not a AI language
> only, sthg. suitable for ressearch only, or to be only of academic
> interest.
A lot of people use CL in non-academic settings. And I have never seen
anyone here claiming that CL is "only an AI language". Maybe you can cite
someone for claiming this.
> Of what I discovered I must say: Sad, but it's not true. Use it to
> crunch numbers, debug the flow of messages of the really powerful CLOS
> (but hopefully you can use the MOP) -- but never try to get a "Hello
> World".lisp both under windows and unix to execute, while a second
> thread is reading the contents of a database. Something useful, a
> 'real-world-scenario' I am talking about.
I don't see how you came to that conclusion. You have several choices in CL
and you seem to have always chosen the wrong ones. I agree that there are
several things that would be a win. For example a free portable GUI
toolkit. Such things are definitely in work.
ciao,
Jochen
Chris Double
> Another GUI effort is "McCLIM" a free implementation of "CLIM" which
> grows rather quickly. McCLIM will be backend independent. Until now
> it has a X and an OpenGL backend.
I wasn't aware it had an OpenGL backend. Where can I find this?
Chris.
--
http://www.double.co.nz/cl
Erik Naggum
| Last year I thought it would be a good idea to learn a new programming
| language. But which one?
It looks like you would be happiest with Visual Basic or Delphi.
| My first impression was: every language comes with a GUI, not so CLISP.
My first impression is that you need to understand that a language is
defined by its specification, not by its implementations (and that
so-called languages that have only one implementation are not languages
to begin with, they are just programming tools). However, I consider you
a lost cause from the way your entire apporach is so well documented.
| I could continue.
Please don't.
Thank you for you sharing your sob story. We all care deeply. Goodbye.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
Daniel Barlow
[diversity]
> At least for Common Lisp I can say it is not good. Paul Graham and
How do you know? In what parallel universe did you observe the
effects of having only a single Lisp implementation instead of the
many that we have in this one?
Now, please, piss off back there. Thanks.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Kenny Tilton
Johann Höchtl wrote:
>
> Hello community!
Good-bye. You said you wanted to learn a new language pretty much at
random and for no purpose other than to learn a new language (or you
would not have had a list of five) and then you start sweating bullets
over cross-platform capabilities... better luck next troll.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Harvey has overcome not only time and space but any objections."
Elwood P. Dowd
Brian Spilsbury
> Jochen Schmidt <j...@dataheaven.de> writes:
>
> > Another GUI effort is "McCLIM" a free implementation of "CLIM" which
> > grows rather quickly. McCLIM will be backend independent. Until now
> > it has a X and an OpenGL backend.
>
> I wasn't aware it had an OpenGL backend. Where can I find this?
In the cvs, but it isn't up to par with the X11 backend, and needs
some significant redesign work.
The opengl backend has largely been abandoned for a long time,
although I've started to bring it back in line with the X11 code.
If you're interested in developing it, then I'm sure the efforts would
be welcomed.
Regards,
Brian.
Barry Watson
Erik Naggum wrote:
> | My first impression was: every language comes with a GUI, not so CLISP.
>
> My first impression is that you need to understand that a language is
> defined by its specification, not by its implementations (and that
Sometimes the interpreter is the de facto semantics and hence the
specification, e.g. the "discovery" that Lisp had dynamic scope.
> so-called languages that have only one implementation are not languages
> to begin with, they are just programming tools).
Like lisp in the early 1960s?
Andy
Johann Höchtl wrote:
>
> My first impression was: every language comes with a GUI, not so CLISP.
Sorry, that's not true. Gcc does not come with one even most windows or
MAC c compiler doesn't have one. They all interface to the system
libraries.
Thats what most Lisps also let you do.
>
> OK, maybe CLISP was the wrong choiche to have a GUI so hopefully a good
> language binding to Graphics libraries. Again a failure: there are
> bindings, but inferrior both in terms of technical quality (synchrnous
> communication with tk) or completely outdated. What about QT, gtk, X?
QT is still a problem since it is C++. Without being an expert i think i
remember that interfacing C++ to another language is hard to do. However
there are KDE interfaces to C that you can use via FFI.
CLG is a nice gtk interface that works very well (at least for me). The
last 0.51 works for gtk-1x but there are CVS versions for gtk 2.0.
Since i use CMUCL i can state that its clx interface for X is still
working.
What i don't understand is what you mean with outdated ? It still works
;-)
If you want an IDE use (X)Emacs or jabberwokey. I prefer XEmacs since it
is very powerfull and provides an excellent interface (ILISP) to most
lisps.
>
> The next important thing for a language to be useful in the public,
> outside of AI and university halls is multithreading.
>
Yes multithreading is a problem. Fortunally at least CMUCL have it :-))
I can't say about others but as far as i know McClimb has it also and
should work portable with a lot of lisps.
> What did I found? CLIM defines some multi-threading? A GUI-builder?
> Strange ...
No, usefull ;-)
>
> I could continue. Please note that this is by far not a special rant
> about the CLISP implementation. This is true for most open source LISP.
> In the open source movement it is not clear whether varity is good - is
> it good to have several GUI efforts? (KDE, GNOME) Is it good to have
> several efforts for free Office Suits?
Mhh, but that mean that you keep open to all sites. That again leads us
to
i.e. FFI ;-)
>
> At least for Common Lisp I can say it is not good.
You see me wondering. Until now you are not talking about lisp but
about system interfaces. What language features are you missing ? Or the
other way around: What feature can you use in another language that is
not possible in lisp ?
On the good side we have a lot of things in lisp that make programming
much
easy (i.e. closures). So if you wan't to build software you might have a
closer
look to lisp itself. And after understanding how to interface to GUI's
im shure
that you will like it.
And if you just want to start with GUI's there are at least two
commercial
common lisps that are availible in a free personal edition (lispworks &
franz).
Both has good, well documented interfaces and lots of other goodies.
>
> Of what I discovered I must say: Sad, but it's not true. Use it to
> crunch numbers, debug the flow of messages of the really powerful CLOS
> (but hopefully you can use the MOP) -- but never try to get a "Hello
> World".lisp both under windows and unix to execute, while a second
> thread is reading the contents of a database. Something useful, a
> 'real-world-scenario' I am talking about.
Can you tell me more about 'real-world-scenarios' ? For my applications
the
problems are not in the user interface but in the background. And then
lisp
is very handy i.e. for playing araound with different algorithms
specially
the possibility of recompiling code in a running system. And thats a
lisp
feature !
Best regards
AHz
Johann Höchtl
Right.
> which integrates them nicely into Emacs. A newer IDE that runs with CLISP
> and CMUCL is "JabberWocky" which has a Java based GUI.
> Xanalys' free "Personal Edition" comes with a really good integrated IDE
> which runs under Linux and Windows.
I do not care to much about an IDE -- it was only a first impression.
I'used to makefiles and the shell.
>
>
>>OK, maybe CLISP was the wrong choiche to have a GUI so hopefully a good
>>language binding to Graphics libraries. Again a failure: there are
>>bindings, but inferrior both in terms of technical quality (synchrnous
>>communication with tk) or completely outdated. What about QT, gtk, X?
>>Well there are a couple of bindings for X, but they are old, most of
>>them unmaintained, not compatible between various Common LISP
>>implementaions and unquestionable not cross-plattform. gtk? Yes, I found
>>two bindings, one (clg) stalled in April 2001 the other one (cl-gtk) in
>>1999! Qt? No bindings for Qt so far ...
>
>
> clg got developed further and AFAIR got a bit delayed by the development of
> GTK+2.0. I heard rumours that clg will use UFFI in future this could lead
> to a GTK binding which runs on many CL implementations.
>
> Another GUI effort is "McCLIM" a free implementation of "CLIM" which grows
> rather quickly. McCLIM will be backend independent. Until now it has a X
> and an OpenGL backend.
>
Didn't know that, but sounds interesting
I knew that CMUCL has threads. I was pretty sure that ACL and Franz
would support threading. But I refered to cross-plattform "gratis"
environments.
>
>>What did I found? CLIM defines some multi-threading? A GUI-builder?
>>Strange ...
>
>
> CLIM has a portability-layer called "CLIM-SYS" which defines an interface
> for multithreading. CLIM itself is a GUI-Toolkit.
>
>
>>I could continue. Please note that this is by far not a special rant
>>about the CLISP implementation. This is true for most open source LISP.
>>In the open source movement it is not clear whether varity is good - is
>>it good to have several GUI efforts? (KDE, GNOME) Is it good to have
>>several efforts for free Office Suits?
>
>
>>At least for Common Lisp I can say it is not good. Paul Graham and
>>others try to convince the community that LISP is not a AI language
>>only, sthg. suitable for ressearch only, or to be only of academic
>>interest.
>
>
> A lot of people use CL in non-academic settings. And I have never seen
> anyone here claiming that CL is "only an AI language". Maybe you can cite
> someone for claiming this.
>
>
Of course LISP is not AI only and I'm pretty sure that Lisp will do
pretty well in background processes. But the need to escape to rather
unsatisfactory and unintegrated bindings for most kind of user
interaction is prevalent.
Johann Höchtl
Andy wrote:
> Let's discuss this friendly :-)
>
> Johann Höchtl wrote:
>
>>My first impression was: every language comes with a GUI, not so CLISP.
>
> Sorry, that's not true. Gcc does not come with one even most windows or
> MAC c compiler doesn't have one. They all interface to the system
> libraries.
> Thats what most Lisps also let you do.
>
I was not worried about a missing IDE, i think integrating most of the
existing LISP environments into emacs as a subordinate prcoess would be
a snap.
Actually I found the language by itself so powerful (and beautiful too)
that I was wondering the lack of more up-to-date libraries and
deployment scanarios. I consider it's standardised Object System still
to be one of the very best available. The self-morphability, the unclear
distinction between program implementation and execution can lead to new
patterns of thinking and application design which lack itself in
propably all other languages (this is not true for Scheme, Dylan and
other offsprings of LISP)
> On the good side we have a lot of things in lisp that make programming
> much
> easy (i.e. closures). So if you wan't to build software you might have a
> closer
> look to lisp itself. And after understanding how to interface to GUI's
> im shure
> that you will like it.
> And if you just want to start with GUI's there are at least two
> commercial
> common lisps that are availible in a free personal edition (lispworks &
> franz).
> Both has good, well documented interfaces and lots of other goodies.
>
I didn't cared about the commercial ones as I and the company I'm
working for now try to get a bit more into the open source business.
>
>>Of what I discovered I must say: Sad, but it's not true. Use it to
>>crunch numbers, debug the flow of messages of the really powerful CLOS
>>(but hopefully you can use the MOP) -- but never try to get a "Hello
>>World".lisp both under windows and unix to execute, while a second
>>thread is reading the contents of a database. Something useful, a
>>'real-world-scenario' I am talking about.
>
> Can you tell me more about 'real-world-scenarios' ? For my applications
> the
> problems are not in the user interface but in the background. And then
> lisp
> is very handy i.e. for playing araound with different algorithms
> specially
> the possibility of recompiling code in a running system. And thats a
> lisp
> feature !
>
Well there are numerous examples. But it's absolutely useful to have a
responding application whereas a background task performs enormous
analysis of a Database. In Unix environments it's common to spawn a new
process or to fork, but in facts that is a waste of system ressources.
> Best regards
> AHz
Ian Wild
>
> ...But it's absolutely useful to have a
> responding application whereas a background task performs enormous
> analysis of a Database. In Unix environments it's common to spawn a new
> process or to fork, but in facts that is a waste of system ressources.
You're doing "enormous analysis" and worrying about the
time taken to fork()?
Andy
>
> Actually I found the language by itself so powerful (and beautiful too)
> that I was wondering the lack of more up-to-date libraries and
> deployment scanarios. I consider it's standardised Object System still
> to be one of the very best available. The self-morphability, the unclear
> distinction between program implementation and execution can lead to new
> patterns of thinking and application design which lack itself in
> propably all other languages (this is not true for Scheme, Dylan and
> other offsprings of LISP)
>
based
apps use WEB browsers for user interaction (you will find some lisp web
server
on cliki which is itself a lisp application - one without GUI i assume
;-)
I agree that there are to less free libraries. But that holds for all
languages
until i stop to ask for a library that solve my actual problem. When you
think
it over you will find that there are lots of packages for a very large
area
of applications.
If your prefered one is not available the communitiy will shure support
you
when you develop it (and then make it available of course ;-)
> I didn't cared about the commercial ones as I and the company I'm
> working for now try to get a bit more into the open source business.
>
Good idea at all. But then i would like to ask what your goal is ? The
commercial lisps seems to be ready to solve your (GUI/Multithreading)
problem. If you want to make a product than thats the simplest solution.
If you want to use open source products than you should also think about
releasing parts of your solution back to the open source comunity.
If you (just for example) develop an system that make truck logistic
more
intelligent and your program needs an GUI then you can make the GUI open
source since your customers pay for the logistic part.
Only getting things out of the open source for your profit is not the
way
open-source can live over a long time ;-)
> Well there are numerous examples. But it's absolutely useful to have a
> responding application whereas a background task performs enormous
> analysis of a Database. In Unix environments it's common to spawn a new
> process or to fork, but in facts that is a waste of system ressources.
That again is the multiprocessing story ;-) But why don't you ask the
comunity
how you can make a package with portable multiprocessing.
I'm shure you will get some good advices (i always got them and i bet my
requests are often realy worse ;-)
Best regards
AHz
Erik Naggum
all posted articles should be obeyed by reasonably modern news readers,
and it goes like this:
Mail-Copies-To: never
If you feel an urge to mail me a copy of a posted article, at least have
the decency to mark it as such so I can ignore it completely, or I will
believe it is a personal comment requiring personal attention. If you
have no concept of the difference between public and private, please do
not make it my problem, too. I post this because I am annoyed with the
many people who keep mailing me copies of posted articles, and although
it helps to write each one in turn, the bigger problem is not solved that
way. Please stop this practice! That does not mean I do not appreciate
private communication that is just that, but I have to check to see if
the same article is posted some time after I received it as mail unless
it explicitly says it is personal, and that is wasteful, annoying and
delaying. It is doubly annoying when I mail gets lost because I believe
it could have been posted, and it falls through the cracks. So PLEASE do
not mail me copies of posted articles unless you (or your news program)
clearly marks them as such. Is this acceptable? If not, do not reply to
my messages -- you only pollute my mailbox in worse ways than spam. OK?
* Barry Watson
| Sometimes the interpreter is the de facto semantics and hence the
| specification, e.g. the "discovery" that Lisp had dynamic scope.
:
| Like lisp in the early 1960s?
You seem to be unaware of the effects of the passage of time. How can I
help you understand that things and relationships change and evolve and
that what was once true may no longer be, and that what is now true, may
not always have been? It is essentially a deeply philosophical question,
yet some people seem unable to comprehend the concept of "time", hence
have no concept of "context", either, and believe that every statement
is expected to be universally true, both in time and space. I generally
find communication with such people to be inherently impossible, since
they will not allow for either learning or correction.
So, of course, Lisp was once no more than a tool. Over time, it evolved
into a _language_ when the specification became more important than the
documentation of the only implementation and independent implementations
of the language from the _specification_ became possible, not just new
implementations that emulated the first or another implementation. C++
was long Bjarne's favorite perverse toy, then got standardized into a
perverse language, but I very much doubt that anyone has actually tried
to implement C++ solely from the specification.
Barry Watson
Erik Naggum wrote:
>
> PLEASE do not mail me copies of posted articles! The header I include in
> all posted articles should be obeyed by reasonably modern news readers,
> and it goes like this:
>
> Mail-Copies-To: never
>
> If you feel an urge to mail me a copy of a posted article, at least have
> ...
> my messages -- you only pollute my mailbox in worse ways than spam. OK?
You're amazing "Mail-Copies-To: never" doesn't work with Netscape I'm
afraid.
> * Barry Watson
> | Sometimes the interpreter is the de facto semantics and hence the
> | specification, e.g. the "discovery" that Lisp had dynamic scope.
> :
> | Like lisp in the early 1960s?
>
> I generally
> find communication with such people to be inherently impossible, since
> they will not allow for either learning or correction.
Then don't communicate with me.
Raymond Wiker
> Well there are numerous examples. But it's absolutely useful to have a
> responding application whereas a background task performs enormous
> analysis of a Database. In Unix environments it's common to spawn a
> new process or to fork, but in facts that is a waste of system
> ressources.
This is bullshit. Unix is built around the concept of
lightweight processes. Windows NT is not, and requires a threading
model. Anyway, it is eminently possible to create multitasking
applications without resorting to to multiple process/threads - in
fact, for massively large-scale applications, you _cannot_ use either
processor or threads.
--
Raymond Wiker Mail: Raymon...@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Andy Reiter
> Hello community!
>
> Last year I thought it would be a good idea to learn a new programming
> language. But which one ?
"A" new one? I learnt 4 HLLS and 3 assemblies, since january.
> I thought a language comming from a research background would be a good
> choiche and so i ended up with most notably
Always look for something that challenges your normal thinking. Look
for
languages that approach things differently. For example, it will not
do you any
good to learn C, C++, Java, Perl and C#. All you need is to learn
about the libraries,
and some extra language constructs, and you are coding large programs
in no time. Whoever, you have not learnt nothing new.
OTOH, learning C, C++, Lisp, Forth, ML and Assembly, will make you
think ALOT. Which is good.
> O'Caml (Objective Caml, www.ocaml.org)
Learnt a little about it (the O'Reilly book is free online)
> Mozart/Oz (www.mozart-oz.org)
Never heard of it.
> Python (www.python.org) and
Left a bad taste in my mouth.
> Common Lisp
My current fascination, specially CLISP. I skimed over "onlisp" and I
thought I
learnt all there is to learn about lisp. Then went on to implement an
small
project of mine, just to face alot of problems.
I went back to page 1 of "on lisp", and everyday, I sit with the book
on an Emacs
terminal, for one hour, trying every example and solving every
problem.
I am also learning Emacs as I go. So far, here is how my work goes.
1) I open a new file in emacs C-x C-f
2) Create a second window C-x 2
3) Change to the second window C-x o
4) Run an inferrior Lisp process M-x run-lisp
5) Go back to the upper window with the code C-x o
6) [optional] Adjust the height with the mouse or C-x ^
Now, every lisp expression I type, could be evaluated. Just go to the
expression
[I type C-M-a] and then type C-M-x.
I gave up my dearly paid for Visual Studio 6.0 just becuase of that. I
also
visit the lisp process [C-x o] and play with it (call the
documentation function,
use apropos, disassemble functions, use the debugger, etc.)
The thing I like about lisp is, I couldn't evaluate it right from the
start, like
other languages.
I had a feature check-list in mind, when I found it first "is it free?
GPLed?
does it have a corporate backing? does it support CORBA? SOAP? XML?
does it have
a decent database integration? how protable/snappy/OOP is the GUI?
does it support
Rose? ClearCase? " etc.
But it is not like that. Lisp will sit there stubornly, not answering
your question,
and once you bother to go there and see for yourself, you will NEVER
comeback.
I tried to brush up my C++ skills, having heard about new job
oppenings around here,
but guess what? I could never force myself to read the code snippets
(mind you,
this is Bjarne's C++ The language, not some ugly SAMS book.)
I saw through the horror I have been through, the painful syntax I had
to go
through during my study and previous jobs.
Learn Lisp and I dare you to read the "expressions" chapter in
Bjarne's book, without laughing and crying at the same time. Go read
the "binary search" algorithm in Bjarne's or even Sedgewick's books,
and then read the same algorithm
on Graham's, and you will see Lisp for what it truely is.
> I read so much good news about Lisp, a language dating back to around
> 1960 and i decided to give it a closer view.
Yes, I also read McCarthy's "recursive" paper, it is the same Lisp :-)
> I was sad. So I heard so much good rumour about that great language and
> no powerfull, cross plattform language bindings?
Great Language? I think you are lying. You don't know if Lisp is great
or not.
Personally, last time I thought a language was great but lacked some
features,
I went on to read impnotes.html and familiarized myself with the FFI,
so I could
make as many bindings as I need for it.
Julian Stecklina
[...]
> By GUI you seem to mean "IDE". The free systems seem to use mainly ILISP
> which integrates them nicely into Emacs. A newer IDE that runs with CLISP
> and CMUCL is "JabberWocky" which has a Java based GUI.
Won't run on my 16MB RAM laptop. :)
[...]
> Hm... neither are CMUCL/SBCL by definition not portable to Windows nor are
> X Applications unusable under Windows.
> The nice thing with the CommonLisp bindings to X (CLX) is that they don't
> use the C libraries but talk the X protocol directly. So the only thing the
> implementation has to provide is sockets (no FFI to GUI libraries in C are
> needed).
This means I could use X from Windows when running a X Server like
X-Win32 on this machine?
It obviously should work and X-Servers are available for many
OSes... I really never thought about that.
Regards,
Julian
--
Meine Hompage: http://julian.re6.de
Ich suche eine PCMCIA v1.x type I/II/III Netzwerkkarte.
Ich biete als Tauschobjekt eine v2 100MBit Karte in OVP.
Julian Stecklina
> Erik Naggum wrote:
>
> > | My first impression was: every language comes with a GUI, not so CLISP.
> >
> > My first impression is that you need to understand that a language is
> > defined by its specification, not by its implementations (and that
>
> Sometimes the interpreter is the de facto semantics and hence the
> specification, e.g. the "discovery" that Lisp had dynamic scope.
The discovery that Lisp had dynamic scope? You need to explain this one. :)
> > so-called languages that have only one implementation are not languages
> > to begin with, they are just programming tools).
>
> Like lisp in the early 1960s?
In these times most programming languages had been just tools (and
they are today) to help you writing assembly code (indirectly,
though).
Andy
> Anyway, it is eminently possible to create multitasking
> applications without resorting to to multiple process/threads
study available ?
Best regards
AHz
Julian Stecklina
I would not be concerned with the time, but with the memory wasted for a
completely new process.
Jochen Schmidt
> Jochen Schmidt <j...@dataheaven.de> writes:
>
>
> [...]
>
>> By GUI you seem to mean "IDE". The free systems seem to use mainly ILISP
>> which integrates them nicely into Emacs. A newer IDE that runs with CLISP
>> and CMUCL is "JabberWocky" which has a Java based GUI.
>
> Won't run on my 16MB RAM laptop. :)
Hehe - Emacs (Eight Megabytes Always Continuously Swapping) will then be a
hog to I fear ;-)
>> Hm... neither are CMUCL/SBCL by definition not portable to Windows nor
>> are X Applications unusable under Windows.
>> The nice thing with the CommonLisp bindings to X (CLX) is that they don't
>> use the C libraries but talk the X protocol directly. So the only thing
>> the implementation has to provide is sockets (no FFI to GUI libraries in
>> C are needed).
>
> This means I could use X from Windows when running a X Server like
> X-Win32 on this machine?
It should work - but I have not tried it yet.
> It obviously should work and X-Servers are available for many
> OSes... I really never thought about that.
I still think it was a good idea to choose CLX as the first backend for
McCLIM.
Nils Goesche
> Ian Wild <i...@cfmu.eurocontrol.be> writes:
>
> > Johann Höchtl wrote:
> > >
> > > ...But it's absolutely useful to have a
> > > responding application whereas a background task performs enormous
> > > analysis of a Database. In Unix environments it's common to spawn a new
> > > process or to fork, but in facts that is a waste of system ressources.
> >
> > You're doing "enormous analysis" and worrying about the
> > time taken to fork()?
>
> I would not be concerned with the time, but with the memory wasted for a
> completely new process.
You are aware of ``copy-on-write'', are you?
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche
By event driven programming, with lots of state machines and
non-blocking I/O. Can fail miserably on Windows, where select works
only with sockets, not with general file descriptors, IIRC...
Jochen Schmidt
> I do not care to much about an IDE -- it was only a first impression.
> I'used to makefiles and the shell.
Then you should take a look at things like defsystems in lisp. There are
several ones - every vendor has it's own and there are multiple free ones
(ASDF, MK:DEFSYSTEM3.x/4.x...)
>> Another GUI effort is "McCLIM" a free implementation of "CLIM" which
>> grows rather quickly. McCLIM will be backend independent. Until now it
>> has a X and an OpenGL backend.
>>
> Didn't know that, but sounds interesting
Well - it is not yet complete but it begins to get usable AFAICT.
> I knew that CMUCL has threads. I was pretty sure that ACL and Franz
> would support threading. But I refered to cross-plattform "gratis"
> environments.
Well - it depends what you value. In another post you meant that you and
your company want to use more "open-source" stuff. The question is why you
want to do that. If it is only because you get it with no cost then this is
IMHO not a very good thing. If you want to go with open-source why don't
you think about contributing back some value for the value you consume?
If you don't want that you can still simply buy the commercial offerings of
Corman, Digitool, Franz or Xanalys or any of the other commercial vendors I
missed.
Note that all this vendors offer *CL* systems - so you can develop your
program using widely portable CL and run them on all of them. You can
choose what you want.
> Of course LISP is not AI only and I'm pretty sure that Lisp will do
> pretty well in background processes. But the need to escape to rather
> unsatisfactory and unintegrated bindings for most kind of user
> interaction is prevalent.
Well - there are offerings - but up to now you have to pay for them. It
seems as if this could change with projects like McCLIM and CLG but this is
an issue of the *implementations* you chose and not the language CommonLisp.
CLISP is not what defines CommonLisp and neither is any of the other
implementations.
Andy
>
> Well - it depends what you value. In another post you meant that you and
> your company want to use more "open-source" stuff. The question is why you
> want to do that. If it is only because you get it with no cost then this is
> IMHO not a very good thing. If you want to go with open-source why don't
> you think about contributing back some value for the value you consume?
>
people,
rental and so on does not bother on $2000 for a deelopment kit when
there is
at least a chance that a open-source product may make problems that take
more
than two or three days to solve.
The advantages of open-source are specially that you can have the source
and
modify it to your needs. Or that you can still fix bugs on a delivered
and
installed release even when comercial products have incompatible
successors.
Or ...
[imagine a long list with relevant features, i think they are well known
;-)]
But you are absolutly right in asking for back contribution. Without
that none
was interested in putting his product in the open-source comunity. For
the
vendors it is only usefull when they can reduce there own effort in
developing
the product or (same otherround) when they can expect more effort in
developing
as they do alone.
Best regards
AHz
Nils M Holm
> The discovery that Lisp had dynamic scope?
Since a hand-coded implementation of EVAL was in fact the first formal
specification of LISP (1.0), dynamic scoping was indeed 'discovered',
as John McCarthy describes in his paper "History of LISP" [1981]:
[...] In all innocence, James R Slagle programmed the
following LISP function definition and complained when
it didn't work right.
testr[x,p,f,u] <- if p[x] then f[x] else if atom [x] then u[]
else testr[cdr[x],p,f,lambda:testr[car[x],p,f,u]].
[...] The difficulty was that when an inner recursion
occurred, the value of x in car[x] wanted was the outer
value, but the inner value was actually used. In modern
terminology, lexical scoping was wanted, and dynamic
scoping was obtained. [...]
Nils.
--
Nils M Holm <n...@t3x.org> -- http://www.not-compatible.org/nmh/
Raymond Wiker
> Andy <a...@smi.de> writes:
>
> > Raymond Wiker wrote:
> > > Anyway, it is eminently possible to create multitasking
> > > applications without resorting to to multiple process/threads
>
> > Interesting thing. How do you do that ? Are there examples to
> > study available ?
>
> By event driven programming, with lots of state machines and
> non-blocking I/O. Can fail miserably on Windows, where select works
> only with sockets, not with general file descriptors, IIRC...
Add a timeout mechanism, and you're pretty close to what I was
thinking of :-)
Actually, in that case, you may not even need select & friends.
Raymond Wiker
> Julian Stecklina wrote:
>
> > Jochen Schmidt <j...@dataheaven.de> writes:
> >
> >
> > [...]
> >
> >> By GUI you seem to mean "IDE". The free systems seem to use mainly ILISP
> >> which integrates them nicely into Emacs. A newer IDE that runs with CLISP
> >> and CMUCL is "JabberWocky" which has a Java based GUI.
> >
> > Won't run on my 16MB RAM laptop. :)
>
> Hehe - Emacs (Eight Megabytes Always Continuously Swapping) will then be a
> hog to I fear ;-)
Not really. I ran FreeBSD 2.something on a mcahine with 16MB
RAM, with XFree86, MySQL, Apache, Emacs and an ungodly mess of Perl
code that I used to interact with the database.
It worked, but it wasn't fast.
Raymond Toy
Jochen> Julian Stecklina wrote:
>> Jochen Schmidt <j...@dataheaven.de> writes:
>>
>>
>> [...]
>>
>>> By GUI you seem to mean "IDE". The free systems seem to use mainly ILISP
>>> which integrates them nicely into Emacs. A newer IDE that runs with CLISP
>>> and CMUCL is "JabberWocky" which has a Java based GUI.
>>
>> Won't run on my 16MB RAM laptop. :)
Jochen> Hehe - Emacs (Eight Megabytes Always Continuously Swapping) will then be a
Jochen> hog to I fear ;-)
I think "Eight Megabytes" hasn't been true in a long while. :-)
Eighty Megabytes might closer to the truth. At least my XEmacs
processes are usually 40 MB or so.
Ray
Andy
>
> Nils Goesche <car...@cartan.de> writes:
>
> > Andy <a...@smi.de> writes:
> >
> > > Raymond Wiker wrote:
> > > > Anyway, it is eminently possible to create multitasking
> > > > applications without resorting to to multiple process/threads
> >
> > > Interesting thing. How do you do that ? Are there examples to
> > > study available ?
> >
> > By event driven programming, with lots of state machines and
> > non-blocking I/O. Can fail miserably on Windows, where select works
> > only with sockets, not with general file descriptors, IIRC...
>
> Add a timeout mechanism, and you're pretty close to what I was
> thinking of :-)
>
> Actually, in that case, you may not even need select & friends.
>
direction.
Thanks for the tips.
Best regard
AHz
Jochen Schmidt
Well - it works yes - I know it from times when I ran Emacs on NetBSD on my
old Amiga 4000 with an M68040-25Mhz, 2MB ChipRam and 16MB FastRam.
Daniel Barlow
If you're using CMUCL or SBCL, you may want to look at SERVE-EVENT,
which does the event loop stuff for you already (and integrates with
the repl, so you can have functions responding to file/socket
activity even in an apparently idle system). It's available on all
ports (unlike the MP, which is still x86-only at present) and works at
least well enough to power CLiki (unsing Araneida) ...
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Andy
>
> If you're using CMUCL or SBCL, you may want to look at SERVE-EVENT,
> which does the event loop stuff for you already (and integrates with
> the repl, so you can have functions responding to file/socket
> activity even in an apparently idle system). It's available on all
> ports (unlike the MP, which is still x86-only at present) and works at
> least well enough to power CLiki (unsing Araneida) ...
>
Seems that i should read the manual til the end ;-). But really: My list
of hot topics to checkout growth from day to day. I can not understand
what
other people complain about lisps flexibility.
Thanks for the hint
Best regards
AHz
P.S: Cliki is really nice. I visit it often.
A.
Joel Ray Holveck
> language. But which one ?
A very big part of this decision is what you want to do. I recently
wrote a program to rename a group of files to lowercase, replacing
spaces with dashes. I used Perl.
For my last device driver, I used C.
If I want to search a problem tree, recognize patterns, integrate a
formula, or do any other complex task, I'll use Lisp.
The question is, what do you want out of a language? Most of us here
feel that Lisp is an excellent language for a wide variety of tasks.
For instance, I'm looking to being able to write device drivers in
Lisp, under GNU. However, to help discuss whether Lisp is right for
you or not, we need to know what you want out of the language.
> Common Lisp (especially CLISP, clisp.cons.org or
> sourceforge.net/projects/clisp)
Why this implementation in particular?
> As in the case of O'Caml, Mozart and Python those implemetations all
> cary a licence as free as in 'free beer' and are all especially
> cross-plattform (read: Unix-Windows) I decided to pick for Common Lisp
> a 'free' implementation to: CLISP.
CLISP is not the only gratis Lisp. I usually use CMUCL for my work,
although it's pretty much Unix- and Mach-oriented. Xanalys also has a
gratis Lisp that runs across Linux and Windows.
But here's another issue. Why do you insist on using a single
implementation? I have a large and complex program running here. I
recently decided to port it to a different OS for development than I
use for deployment. I only needed to add about 20--30 lines of
system-specific code, and even though the server API was much
differently structured, the flexibility of Lisp made it easy to
integrate my code with the different APIs.
> My first impression was: every language comes with a GUI, not so CLISP.
I wasn't aware that Python came with a GUI. I can't speak for the
other languages you mentioned, but Perl certainly doesn't, and neither
does C. These are layered products.
IMHO, the only good reason to have a GUI as a built-in part of a
language is if the language is designed for graphics. GUIs have
changed a lot over the history of computing, and I hope they continue
to do so. Having a GUI as an integral part of the language is a
recipe for dating it.
> What about QT, gtk, X? Well there are a couple of bindings for X,
> but they are old, most of them unmaintained, not compatible between
> various Common LISP implementaions and unquestionable not
> cross-plattform.
Most GUIs are notoriously bad for cross-platformness. Both GTK and QT
have pretensions of being cross-platform, but in practice, you don't
see that happen often.
CLX is indeed cross-platform. It works by implementing the X
protocol, instead of binding to X libraries, so it doesn't have the
problems of different FFI conventions on different OSs, like most GUIs
do. I'm not a user of CLX myself, but that's because of how I like to
use a GUI, rather than problems with CLX.
> gtk? Yes, I found two bindings, one (clg) stalled in April 2001
You look at the CVS tree lately? I'd hardly call it stalled! Rather
the opposite... it's preparing for GTK+ 2, and is doing a good job of
it.
Meanwhile, I use clg for most of my GUI work in the meantime. Even
the Apr01 version is a great binding, and I have no trouble with it.
The fact that it's open-source means that if it lacks something, I can
easily add it-- and the implementation (using a lot of Lisp's
advantages) makes it usually just a couple of lines of code.
> the other one (cl-gtk) in 1999! Qt? No bindings for Qt so far ...
Qt set out to be C++ specific from the word "Go".
> To be fair, this is not an especial lack of CLISP but of all free
> Common Lisp implementations - but for most of them (gcl, sbcl, cmucl)
> X bindings are just fine, as they are not portable (statet online at
> least for cmucl and should at leat be true for sbcl) to windows anyway.
Are you looking for gratis, or open source, or what? From the earlier
bit of your post, I thought you needed gratis. Again, Xanalys's Lisp
(personal edition) is gratis, and has an excellent GUI toolkit.
> I was sad. So I heard so much good rumour about that great language
> and no powerfull, cross plattform language bindings?
Take a look at CLIM sometime. It's so powerful, it's amazing. It's
more cross platform than any other language I've seen, and blends
wonderfully with the native toolkits.
> The next important thing for a language to be useful in the public,
> outside of AI and university halls is multithreading. I found out
> that list has it's unique way of co-routines but when it comes down
> to OS System call or user-imput, "real" mult-threading, eithr green
> threds or native threads are important.
Why green or native threads? What's wrong with other thread
implementations?
My current big project is a remote object server, that also hosts a
web server (for introspective purposes). Certainly, multiprocessing
was a big deal for me.
Right now, I'm using CMUCL's SERVE-EVENT facility, which implements
cooperative threading. It's a total piece of cake. Furthermore,
CMUCL/x86 implements preemptive multithreading. I'm using that for
the web server, and thinking about moving some of the longer
processing bits to that model.
> What did I found? CLIM defines some multi-threading? A GUI-builder?
> Strange ...
CLIM-SYS includes multithreading. A lot of early multithreading was
only needed for GUI work, so it seemed to be a natural bit of that
standard.
> I could continue. Please note that this is by far not a special rant
> about the CLISP implementation. This is true for most open source
> LISP.
Again, are you after gratis or open source? If you're after gratis,
then Xanalys defines a lot of what you need. If open source is your
thing, then you can tune existing libraries to your liking.
I've found modifying Lisp libraries to be much easier than modifying
libraries in other languages. Consider CLG. The version I was using
omitted colormap-alloc-color, so I added it. Now, CLG already had the
infrastructure flexible enough that it just took five lines:
(define-foreign colormap-alloc-color () boolean
(colormap colormap)
(color color)
(writable boolean)
(best-match boolean))
I certainly don't think that adding this to, say, Perl would be so
easy. (Yes, I've dealt with Perl's FFI.) I can't speak for other
languages.
> In the open source movement it is not clear whether varity is good -
> is it good to have several GUI efforts? (KDE, GNOME) Is it good to
> have several efforts for free Office Suits?
I think so, but this is a different discussion.
> At least for Common Lisp I can say it is not good.
I'm going to have to get a bit snippy here. What experience qualifies
you make this analysis? To make that determination, you'd really have
to be part of the Lisp community over a long time, enough to see the
long-term effects of having multiple implementations. A brief
exposure to a single implementation of Lisp certainly doesn't give you
what you need to make that judgment.
I'm neither agreeing nor disagreeing with your statement. There are
several people who argue both sides of this idea, with very good
reasons for each. I'm just saying that you shouldn't make snap
judgments like that.
> Paul Graham and others try to convince the community that LISP is
> not a AI language only, sthg. suitable for ressearch only, or to be
> only of academic interest.
> Of what I discovered I must say: Sad, but it's not true. Use it to
> crunch numbers, debug the flow of messages of the really powerful CLOS
> (but hopefully you can use the MOP) -- but never try to get a "Hello
> World".lisp both under windows and unix to execute, while a second
> thread is reading the contents of a database. Something useful, a
> 'real-world-scenario' I am talking about.
I work for a router company, and write complex, heavily used internal
systems in Lisp. When they described the project to me, my first
words were, "I need to use Lisp."
I'll agree, some things are not ideal cross-implementation. But the
power that Lisp gives far outweighs any of these relatively minor
inconveniences.
Cheers,
joelh
Johann Höchtl
Joel Ray Holveck wrote:
>>Last year I thought it would be a good idea to learn a new programming
>>language. But which one ?
>
>
> A very big part of this decision is what you want to do. I recently
> wrote a program to rename a group of files to lowercase, replacing
> spaces with dashes. I used Perl.
>
> For my last device driver, I used C.
>
> If I want to search a problem tree, recognize patterns, integrate a
> formula, or do any other complex task, I'll use Lisp.
>
> The question is, what do you want out of a language? Most of us here
> feel that Lisp is an excellent language for a wide variety of tasks.
> For instance, I'm looking to being able to write device drivers in
> Lisp, under GNU. However, to help discuss whether Lisp is right for
> you or not, we need to know what you want out of the language.
>
That's true, undoubtly. but i was thinking to pick a language which
enforces a different way of thinking than the widespread imperial ones
like C(++,#), Perl ... so i came across functional ones.
>
>>Common Lisp (especially CLISP, clisp.cons.org or
>>sourceforge.net/projects/clisp)
>
>
> Why this implementation in particular?
>
It is inherently cross-plattform, has a good GC, a reasonable fast
bytecode interpreter, implements most of CLOS, will have a MOP soon and
conforms most to "Common Lisp, the standard".
>
>>As in the case of O'Caml, Mozart and Python those implemetations all
>>cary a licence as free as in 'free beer' and are all especially
>>cross-plattform (read: Unix-Windows) I decided to pick for Common Lisp
>>a 'free' implementation to: CLISP.
>
>
> CLISP is not the only gratis Lisp. I usually use CMUCL for my work,
> although it's pretty much Unix- and Mach-oriented. Xanalys also has a
> gratis Lisp that runs across Linux and Windows.
>
> But here's another issue. Why do you insist on using a single
> implementation? I have a large and complex program running here. I
> recently decided to port it to a different OS for development than I
> use for deployment. I only needed to add about 20--30 lines of
> system-specific code, and even though the server API was much
> differently structured, the flexibility of Lisp made it easy to
> integrate my code with the different APIs.
>
Admitted, there is a great choice among Lisp implementations but i
picked CLISP because of the aforementioned reasons.
>
>>My first impression was: every language comes with a GUI, not so CLISP.
>
>
> I wasn't aware that Python came with a GUI. I can't speak for the
> other languages you mentioned, but Perl certainly doesn't, and neither
> does C. These are layered products.
>
Python comes with IDLE, a GUI based on TK. It's not very sophisticated
but better than nothing.
> IMHO, the only good reason to have a GUI as a built-in part of a
> language is if the language is designed for graphics. GUIs have
> changed a lot over the history of computing, and I hope they continue
> to do so. Having a GUI as an integral part of the language is a
> recipe for dating it.
>
>
>>What about QT, gtk, X? Well there are a couple of bindings for X,
>>but they are old, most of them unmaintained, not compatible between
>>various Common LISP implementaions and unquestionable not
>>cross-plattform.
>
>
> Most GUIs are notoriously bad for cross-platformness. Both GTK and QT
> have pretensions of being cross-platform, but in practice, you don't
> see that happen often.
>
I can't imagine too that Gimp and gtk+ was only a pick from the Unix CVS
tree, copied to a windows box and compiled out of the box. But The Gimp
is an impressive example, that a complicated, huge application can be
cross-plattform. BTW. it relies on scheme-scripting, doesn't it?
> CLX is indeed cross-platform. It works by implementing the X
> protocol, instead of binding to X libraries, so it doesn't have the
> problems of different FFI conventions on different OSs, like most GUIs
> do. I'm not a user of CLX myself, but that's because of how I like to
> use a GUI, rather than problems with CLX.
>
I used to run a X-Server (MIX) under Windows to get the benefits of two
worlds and it actually worked. But X is not known to be fast and this
setup given, performance completely deteriorated.
>
>>gtk? Yes, I found two bindings, one (clg) stalled in April 2001
>
>
> You look at the CVS tree lately? I'd hardly call it stalled! Rather
> the opposite... it's preparing for GTK+ 2, and is doing a good job of
> it.
>
No, I haven't. Thanks.
'Built-in' threads are actually a good idea. They bring threading to
OSes which would natively not support it and are very portable. But use
such kind of a thread while listening to a socket. Most implementations
will stall the whole interpreter as they don't implement the 'select'
system call. So native threads are a good idea too.
Paolo Amoroso
<Barry....@uab.ericsson.se> wrote:
> Erik Naggum wrote:
[...]
> > so-called languages that have only one implementation are not languages
> > to begin with, they are just programming tools).
>
> Like lisp in the early 1960s?
I must be missing something. Wasn't the LISP 1.5 manual published around
1962?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Paolo Amoroso
On Mon, 27 May 2002 20:48:18 +0200, Johann Höchtl <big....@bigfoot.com>
wrote:
> My first impression was: every language comes with a GUI, not so CLISP.
This rings a--loud--bell.
> What did I found? CLIM defines some multi-threading? A GUI-builder?
CLIM is not a GUI builder. If you actually studied it in more depth, you
would also understand why it deals with multi-threading. But the statement
of yours I have quoted above suggests that your approach is rather
superficial.
Sverker Wiberg
> [...] i was thinking to pick a language which
> enforces a different way of thinking than the widespread imperial ones
^^^^^^^^
> like C(++,#), Perl ...
^^^^^^^
I think you meant "imperative", but it makes sense as it stands (bonus
points for C#)...
/Sverker Wiberg
Joel Ray Holveck
>>> language. But which one ?
>> A very big part of this decision is what you want to do.
> enforces a different way of thinking than the widespread imperial ones
> like C(++,#), Perl ... so i came across functional ones.
Ah, okay. Then Lisp may very well be a good way to go. You may be
familiar with a famous quote of Eric S. Raymond's:
LISP is worth learning for ... the profound enlightenment
experience you will have when you finally get it. That experience
will make you a better programmer for the rest of your days, even
if you never actually use LISP itself a lot.
I wholeheartedly agree. (And I do use Lisp a lot.)
>>> Common Lisp (especially CLISP, clisp.cons.org or
>>> sourceforge.net/projects/clisp)
>> Why this implementation in particular?
> It is inherently cross-plattform, has a good GC, a reasonable fast
> bytecode interpreter, implements most of CLOS, will have a MOP soon
> and conforms most to "Common Lisp, the standard".
I see. Here's a few things to consider:
* A cross-platform implementation may not be necessary. It's
commonplace these days to move large bodies of code across Lisp
implementations. (GLS says something to this effect in the
introduction to CLtL2.)
In an earlier message in this thread, I mention that I recently
moved a large program of mine between two OSs that are about as
different as any two I've used (Unix and Genera), and that it was a
painless process-- much less so than moving, say, a Tcl/Tk program I
wrote from Unix to Win9x (my next most recent porting effort).
* There is no publication entitled "Common Lisp, the standard". I
assume you're referring to the ANSI standard for Lisp, which is what
CLISP strives to adhere to. You'll find that most Lisp interpreters
you'll see around these days are close enough to the ANSI spec that
it rarely makes a difference, particularly if you're just starting
out with Lisp.
* You don't need to box yourself into an implementation up front.
When you get more experienced with Lisp, if you find that the
implementation you're using doesn't provide what you need / want,
then you can switch relatively painlessly to a different impl.
>> But here's another issue. Why do you insist on using a single
>> implementation?
> Admitted, there is a great choice among Lisp implementations but i
> picked CLISP because of the aforementioned reasons.
Good reasons, certainly, but don't get caught up in the
cross-platformness. It's perfectly reasonable to use one
implementation on Windows and another on Unix.
>>> My first impression was: every language comes with a GUI, not so CLISP.
>> I wasn't aware that Python came with a GUI. I can't speak for the
>> other languages you mentioned, but Perl certainly doesn't, and neither
>> does C. These are layered products.
> Python comes with IDLE, a GUI based on TK. It's not very sophisticated
> but better than nothing.
Thanks, I didn't realize that. (I don't do much with Python.)
FWIW, the implementations of Lisp that I usually use also come with
GUIs. CMUCL comes with CLM (Motif) and CLX (X11), and Genera comes
with Dynamic Windows and CLIM. I usually use CLG on CMUCL instead,
though. (I do use DW/CLIM on Genera.) Since GUIs can be such a
matter of preference, I like them as a layered product.
Really, the only time that I picked a language because of its built-in
GUI was when I used Tcl/Tk for Vigor. That was an unusual
circumstance, too: I needed portability, cross-calling between C and
the target language, and a GUI that I could learn quickly, and still
get a basic product out after one day. If I knew then what I know
now, I wouldn't have used Tcl.
>> Most GUIs are notoriously bad for cross-platformness. Both GTK and
>> QT have pretensions of being cross-platform, but in practice, you
>> don't see that happen often.
> I can't imagine too that Gimp and gtk+ was only a pick from the Unix
> CVS tree, copied to a windows box and compiled out of the box. But The
> Gimp is an impressive example, that a complicated, huge application
> can be cross-plattform.
Yes, indeed.
> BTW. it relies on scheme-scripting, doesn't it?
Yes, it uses a derivative of SIOD (Scheme In One Defun) if memory
serves, and a large part of Gimp is written in Scheme.
>> CLX is indeed cross-platform. It works by implementing the X
>> protocol, instead of binding to X libraries, so it doesn't have the
>> problems of different FFI conventions on different OSs, like most GUIs
>> do. I'm not a user of CLX myself, but that's because of how I like to
>> use a GUI, rather than problems with CLX.
> I used to run a X-Server (MIX) under Windows to get the benefits of
> two worlds and it actually worked. But X is not known to be fast and
> this setup given, performance completely deteriorated.
MI/X is a very slow server, and from an X hacker's point of view, very
primitive too. It was built for a single purpose, and never extended
beyond that. (A case study in why you should open source your code?)
You may want to look at the port of XFree86 to Windows, though. I
haven't used it, but it looks encouraging.
>>> gtk? Yes, I found two bindings, one (clg) stalled in April 2001
>> You look at the CVS tree lately? I'd hardly call it stalled! Rather
>> the opposite... it's preparing for GTK+ 2, and is doing a good job of
>> it.
> No, I haven't. Thanks.
No worries. It is still in a dev state, and the build process is
pretty Linux-oriented. I didn't look too closely, though, since the
CLG for GTK+ 1.2 does what I need (as mentioned in my other email).
I have a lot of hope for CLG. GTK+ isn't CLIM (my preference), but
it's not Xt.
>>> The next important thing for a language to be useful in the public,
>>> outside of AI and university halls is multithreading. I found out
>>> that list has it's unique way of co-routines but when it comes down
>>> to OS System call or user-imput, "real" mult-threading, eithr green
>>> threds or native threads are important.
>> Why green or native threads? What's wrong with other thread
>> implementations?
> 'Built-in' threads are actually a good idea. They bring threading to
> OSes which would natively not support it and are very portable. But
> use such kind of a thread while listening to a socket. Most
> implementations will stall the whole interpreter as they don't
> implement the 'select' system call. So native threads are a good idea
> too.
I don't normally consider green threads to be built in, but that's a
different discussion.
Lisp has a head start in building transparent cooperative threading
like you described: no crap from the linker. Most portable thread
libraries for C have all these convolutions that they go through to
wrap around the blocking system calls. Lisp doesn't have those
hurdles to go over.
As mentioned previously, I use both SERVE-EVENT and CLIM-SYS's MT in a
program I'm presently writing. I use different models because they
serve different purposes. You may want to investigate these more
closely before throwing out Lisp's multithreaded capabilities.
Cheers,
joelh
Paolo Amoroso
[...]
> I must be missing something. Wasn't the LISP 1.5 manual published around
> 1962?
Here is what I'm missing: there's a difference between a _manual_ and
a language specification.
Paolo Amoroso
Julian Stecklina
I got FreeBSD 4.5 to eat only about 2 MB of RAM. Emacs+ILISP is about
5 MB. CLISP is at about 3 when started.
It is enough for most work I do. And if not, it reminds me with
swapping. ;)
The same laptop with Windows NT 4 + Corman Lisp was not very
usable... But luckily I mostly coded in Assembly language these
times.
Julian Stecklina
[...]
> I tried to brush up my C++ skills, having heard about new job
> oppenings around here,
> but guess what? I could never force myself to read the code snippets
> (mind you,
> this is Bjarne's C++ The language, not some ugly SAMS book.)
> I saw through the horror I have been through, the painful syntax I had
> to go
> through during my study and previous jobs.
> Learn Lisp and I dare you to read the "expressions" chapter in
> Bjarne's book, without laughing and crying at the same time. Go read
> the "binary search" algorithm in Bjarne's or even Sedgewick's books,
> and then read the same algorithm
> on Graham's, and you will see Lisp for what it truely is.
The simple raytracer in 'ANSI Common Lisp' is fascinating.
Julian Stecklina
> Julian Stecklina <der_j...@web.de> writes:
>
> > Ian Wild <i...@cfmu.eurocontrol.be> writes:
> >
> > > Johann Höchtl wrote:
> > > >
> > > > ...But it's absolutely useful to have a
> > > > responding application whereas a background task performs enormous
> > > > analysis of a Database. In Unix environments it's common to spawn a new
> > > > process or to fork, but in facts that is a waste of system ressources.
> > >
> > > You're doing "enormous analysis" and worrying about the
> > > time taken to fork()?
> >
> > I would not be concerned with the time, but with the memory wasted for a
> > completely new process.
>
> You are aware of ``copy-on-write'', are you?
Yes, I am. Despite your comment, creating a new process (even though
it shares some pages of memory with the one that forked) uses more
memory than creating a new thread inside the old process itself.
At least in most cases.
Hannah Schroeter
In article <87hekrt...@blitz.comp.com>,
Julian Stecklina <der_j...@web.de> wrote:
>[...]
>Yes, I am. Despite your comment, creating a new process (even though
>it shares some pages of memory with the one that forked) uses more
>memory than creating a new thread inside the old process itself.
>At least in most cases.
AFAIK, at least on Linux with the usual pthreads implementation
(LinuxThreads), a pthread_create() maps to something similar to
fork(). One difference, of course, is that the writable memory
is shared except for the stack (COW). I.e. LinuxThreads threads
aren't much cheaper than fork() on Linux.
Btw, is there any other method to do *really* lightweight threads
with native code except having the compiler do a full CPS transform
(ą la "compiling with continuation" by Appel[sp.] et al.)?
>Regards,
>Julian
Kind regards,
Hannah.
Kaz Kylheku
Sometimes language specifications are called reference manuals, for example,
the Ada 95 standard.