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.
> 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.
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?
* Johann Höchtl | 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.
> 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?
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
> > 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.
> 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 !
>>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
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.
>>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.
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.
>>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.
>>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.
>>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 ?
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.
> ...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()?
> 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)
There are a lot of apps that does not need a GUI like you mean. I.E. WEB 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 ;-)
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 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. -- 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.
> 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.
Johann Höchtl <big.j...@bigfoot.com> writes: > 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.
> 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.
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.
> 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.
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.
>> 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.
Julian Stecklina <der_jul...@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?
Regards, -- Nils Goesche "Don't ask for whom the <CTRL-G> tolls."
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...
Regards, -- Nils Goesche "Don't ask for whom the <CTRL-G> tolls."
Johann Höchtl wrote: > 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.
