Re:One simple reason why it won't work:
on
The Euro
·
· Score: 1
Hm... it is obvious that you do not come from europe...
Europe _has_ a common culture - the fact that there are local traditions does not contradict that. There are even local traditions _within_ particular countries like e. g. Germany. Americans may think that all Germans are like Bavarians with "Lederhosen" and "Schuhplattler" but this is only the common xenophobic and rest-of-the-world ignorant stuff we already know from many Americans. Thanks God that I know enough smart Americans to recognize that not all Americans are such morons...
Common Lisp and Scheme have never yet won a prize here (though I believe Common Lisp could), and it seems that the large number of Java and Perl and Python entries produced every year simply don't run fast enough to do well. On the other hand, the vast majority of C and C++ programs get eliminated because of bugs (occasionally one gets through!).
This implies an interesting thought I think. Is that how reality works for software market? C/C++ succeed by evolution?
Most of his arguments boil down to "if you learned LISP, you'd like it." But that's bogus. There are some (many?) of us who used LISP and discarded it. Most people who went through a good computer science school in the days before Java used LISP.
Most people who learned Lisp at some school seem to dislike it first. Learning something and getting something learnt is sometimes something completely different. The Lisp that you can learn on most schools is insanely crippled down to months of hacking low-level, useless list-fiddling programs.
Another problem is that most of these people did not see any need for many of the high-level features offered by lisp and therefore see no urge to use/learn/understand it.
The object system in Common LISP was an afterthought, and it shows. It's really a macro package kind of thing. LISP has a strong history of overly elaborate macros; ever see the MIT LOOP macro? These have the usual problem; what you're looking at in the source isn't what's running, and debugging macros (especially those written by others) is hell.
Many people have a bad taste in mind if a notion like "macro" is mentioned. It remembers them on crippled things like C Preprocessor macros , stupid little script languages or embedded pseudo-languages like VBA. But in Lisp a macro is in fact some kind of generalisation over functions. The reasoning is rather simple:
1) Programs are written to solve problems.
2) Writing a program is a problem
3) Solving 2 with 1 means simply to write a
program that writes a program.
4) If still too complex goto 2
Most other high-level languages have banished macros, or discourage their use.
I don't think that that is really true. Most other high-level languages never had macros. Often enough the designers of other high-level languages do not even know what macros (in the Lisp way of sense) are...
I don't know why - but to me you sound like a insulted little child.
It is amazingly astonishing how you - proclaiming of multiple years of Lisp experience - shows up here with nowing so little on the details. To me it is much more likely that you are simply a moron that has read some articles and now plays the role of an insider to create some nice little flamewars.
I urge you to get a live - so you can finally stop your ridiculous existence of having fun through insulting and attacking other people.
Second, I am aware that Lisp has some graphical toolkits available. However, nothing that I have seen comes remotely close to Swing's power and expressiveness.
You then should definitely have a look at CLIM - it is _very_ different to more conservative toolkits like Swing, but it is a very powerful tool. (I would always take a complete CLIM over Swing+Java2d)
I hardly consider airplane logistics "forging into new territory and kicking the world's ass", by the way. Yes, it's a terribly involved problem, but it's also a boring one, and I seriously doubt that it would be significantly tougher in Java.
"I kicked the world's ass today, Mom!"
"Oh, what did you do?"
"I wrote an *AIRPLANE LOGISTICS PROGRAM*!!! WHOOOOO!! I ROCK!!!"
See? Maybe I'm just getting cynical in my old age, but that just doesn't sound like bragging rights to me.
I worked a while for a vendor of airplane logistics software. I can ensure you that this topis is so complicated that there are not many vendors for that tools. Fact is that only a few vendors was able to develop good enough algorithms to scale up to big airports. One of the newer vendors explicitely used Common Lisp even if it would have been easier to find Java Programmers than Common Lisp programmers.
That's a valid question. My response is that I don't view Scheme and CommonLisp as covering the same ground. CommonLisp really tried to claim being an industrial-strength application development language, and I think it failed badly at that. Scheme, at least to me, is a variety of things that CommonLisp never really was: an extension language, a scripting language, a prototyping language, and a teaching language. At its chosen problem domains, Scheme is quite good.
If you don't think they are covering the same ground then you simply compare apples and oranges.
Yes, it is very easy to write C/C++ code that is completely unportable. Even worse, the source code contains no indication of the use of unportable constructs. This is a major problem with C/C++. However, unlike CommonLisp, it is also very easy to write C/C++ code that is both efficient and completely portable. I think that has contributed to making C/C++ so popular.
It is easy to write portable C/C++ code? I completely disagree here - there are plenty of ugly problems even between compilers like GCC and Visual C++!
In my experience it is by far more easy to write portable software in Common Lisp than in C/C++. I personally maintain a fullscale Webserver completely written in Common Lisp which originated in Franz Inc.'s AllegroCL and which now runs on LispWorks, CMUCL and Corman Lisp under Windows, several UNIX OSs including Linux. My first port of this webserver was the work of a half day - and this contained non-trivial topics like Multithreading, Network-I/O and OS interfacing.
Having had several years of experience in C/C++ I was impressed by the general portability of Common Lisp which essentially ruled out any need for Java for my work.
The condition system itself is OK, but the standard leaves a lot of leeway to implementations of what exceptional conditions are actually detected and what their consequences are. And the CL standard still contains many undefined effects. The hope was that this would allow implementations to be more efficient, but that doesn't seem to have panned out.
This is not really true. The problems here are not efficiency issues but more the wish to collect more real-life experience before making a decision that is difficult to remove later. Your argument implies that there can be no consensus between vendors after the ANSI Standard - this is completely wrong.
Another problem with your rationale is that you merge "Community Standards" like those of Python and Java and "Institutional Standards" like ANSI Common Lisp. Neither Python nor Java have anything comparable to the ANSI CL Standard - but Common Lisp can have (and already has) not only it's ANSI Standard but also "Community Standards. So ANSI Common Lisp has in this comparison a much better base.
Altogether, I think CommonLisp has the right idea in terms of overall language functionality for an advanced language for rapid development and prototyping: Lisp syntax, macros, reflection, powerful object system, interactive development, dynamic modification of code, etc. But the ANSI CL standard just got too many practical issues wrong as far as I'm concerned. The right thing to have done would have been to start over and not accomodate the half-dozen or so vendors with their oddball interests. In fact, some such efforts were around in the early 1990s, but the existence of the ANSI CL standard never let them get off the ground, and I think ANSI CL gave Lisp such a bad name that eventually people just gave up on it. In fact, in many ways, systems like Java and Python are Lisp systems disguised carefully enough so as to not offend a Lisp-weary public.
I cannot really follow your rationale - it is all very fuzzy and subjective.
Nobody forces you to like or use Common Lisp but don't spread such FUD to the people. Most of what you have written on "better" or on what in your sole opinion the ANSI CL Standard got wrong is absolutely subjective without any concrete argumentation.
Sorry for the bad formatting - but after dozens of tries to preview the article which only resulted in network timeouts I hit the submit button and to my astonishment seemed to work...
I formatted the text appropriately in the text-field but do not know why it got so crippled (*grr*)
There are several opportunities for Common Lisp.
The commercial Lisps tend to come with decent GUI
support.
- Xanalys LispWorks comes with "CAPI" which is a
portable (between OSes) Toolkit that uses the
WinAPI on Windows and Motif on UNIX/Linux.
- Franz Inc. AllegroCL comes with "Common
Graphics" which is a Toolkit written for
Windows
- Digitools MCL comes with decent MacOS GUI
support
- Xanalys _and_ Franz _and_ Digitool offer
implementations of "CLIM" (Common Lisp
Interface Manager) a GUI Framework portable
between OSes and Lispsystems
Free GUI Toolkits (probably incomplete)
- CLX is an implementation of the X Protocol in
pure (!) Common Lisp (no binding to the C
libs!). Therefore it runs on nearly every
Lispsystem available. You need a X-Server to
use Programs written with it, and the Toolkit
is rather low-level.
- CLM is a binding to Motif available for CMUCL
and AFAIK some other systems.
- Garnet is a rather extensive (but
unfortunately not further developing) GUI
Toolkit for several Systems
- CLG and CL-GTK are Bindings to GTK for at least
CMUCL
- McCLIM is an effort to build a free
implementation of CLIM (see above) which is
developing rather quickly and looks very
promising.
Rationale:
It is possible to use Toolkits like GTK or QT with Lisp, but there are several Problems with those:
- Both GTK _and_ QT make sometimes stretch the
image of what can be counted as easy portable
C Interfaces (with QT offering until recently
only a C++ interface)
- GTK Does not look native on Windows, QT does
but cannot be used commercially without paying
license fees on Windows.
- Simply writing bindings is not enough it will
look like coding C in Lisp if there is no good
layer above the low-level stuff.
Therefore IMHO the right way for Common Lisp is to count on McCLIM getting _the_ OS and Lisp-System independent GUI Toolkit it deserves to be (with the possibility of having GTK, Motif, QT, WinAPI... as Backends)
Slashdot Mirror
Hm... it is obvious that you do not come from europe... Europe _has_ a common culture - the fact that there are local traditions does not contradict that. There are even local traditions _within_ particular countries like e. g. Germany. Americans may think that all Germans are like Bavarians with "Lederhosen" and "Schuhplattler" but this is only the common xenophobic and rest-of-the-world ignorant stuff we already know from many Americans. Thanks God that I know enough smart Americans to recognize that not all Americans are such morons...
This implies an interesting thought I think. Is that how reality works for software market? C/C++ succeed by evolution?
Most people who learned Lisp at some school seem to dislike it first. Learning something and getting something learnt is sometimes something completely different. The Lisp that you can learn on most schools is insanely crippled down to months of hacking low-level, useless list-fiddling programs.
Another problem is that most of these people did not see any need for many of the high-level features offered by lisp and therefore see no urge to use/learn/understand it.
The object system in Common LISP was an afterthought, and it shows. It's really a macro package kind of thing. LISP has a strong history of overly elaborate macros; ever see the MIT LOOP macro? These have the usual problem; what you're looking at in the source isn't what's running, and debugging macros (especially those written by others) is hell.Many people have a bad taste in mind if a notion like "macro" is mentioned. It remembers them on crippled things like C Preprocessor macros , stupid little script languages or embedded pseudo-languages like VBA. But in Lisp a macro is in fact some kind of generalisation over functions. The reasoning is rather simple: 1) Programs are written to solve problems. 2) Writing a program is a problem 3) Solving 2 with 1 means simply to write a program that writes a program. 4) If still too complex goto 2
Most other high-level languages have banished macros, or discourage their use.I don't think that that is really true. Most other high-level languages never had macros. Often enough the designers of other high-level languages do not even know what macros (in the Lisp way of sense) are...
I don't know why - but to me you sound like a insulted little child.
It is amazingly astonishing how you - proclaiming of multiple years of Lisp experience - shows up here with nowing so little on the details. To me it is much more likely that you are simply a moron that has read some articles and now plays the role of an insider to create some nice little flamewars.
I urge you to get a live - so you can finally stop your ridiculous existence of having fun through insulting and attacking other people.
You then should definitely have a look at CLIM - it is _very_ different to more conservative toolkits like Swing, but it is a very powerful tool. (I would always take a complete CLIM over Swing+Java2d)
I hardly consider airplane logistics "forging into new territory and kicking the world's ass", by the way. Yes, it's a terribly involved problem, but it's also a boring one, and I seriously doubt that it would be significantly tougher in Java. "I kicked the world's ass today, Mom!" "Oh, what did you do?" "I wrote an *AIRPLANE LOGISTICS PROGRAM*!!! WHOOOOO!! I ROCK!!!" See? Maybe I'm just getting cynical in my old age, but that just doesn't sound like bragging rights to me.I worked a while for a vendor of airplane logistics software. I can ensure you that this topis is so complicated that there are not many vendors for that tools. Fact is that only a few vendors was able to develop good enough algorithms to scale up to big airports. One of the newer vendors explicitely used Common Lisp even if it would have been easier to find Java Programmers than Common Lisp programmers.
If you don't think they are covering the same ground then you simply compare apples and oranges.
Yes, it is very easy to write C/C++ code that is completely unportable. Even worse, the source code contains no indication of the use of unportable constructs. This is a major problem with C/C++. However, unlike CommonLisp, it is also very easy to write C/C++ code that is both efficient and completely portable. I think that has contributed to making C/C++ so popular.It is easy to write portable C/C++ code? I completely disagree here - there are plenty of ugly problems even between compilers like GCC and Visual C++!
In my experience it is by far more easy to write portable software in Common Lisp than in C/C++. I personally maintain a fullscale Webserver completely written in Common Lisp which originated in Franz Inc.'s AllegroCL and which now runs on LispWorks, CMUCL and Corman Lisp under Windows, several UNIX OSs including Linux. My first port of this webserver was the work of a half day - and this contained non-trivial topics like Multithreading, Network-I/O and OS interfacing. Having had several years of experience in C/C++ I was impressed by the general portability of Common Lisp which essentially ruled out any need for Java for my work.
The condition system itself is OK, but the standard leaves a lot of leeway to implementations of what exceptional conditions are actually detected and what their consequences are. And the CL standard still contains many undefined effects. The hope was that this would allow implementations to be more efficient, but that doesn't seem to have panned out.This is not really true. The problems here are not efficiency issues but more the wish to collect more real-life experience before making a decision that is difficult to remove later. Your argument implies that there can be no consensus between vendors after the ANSI Standard - this is completely wrong.
Another problem with your rationale is that you merge "Community Standards" like those of Python and Java and "Institutional Standards" like ANSI Common Lisp. Neither Python nor Java have anything comparable to the ANSI CL Standard - but Common Lisp can have (and already has) not only it's ANSI Standard but also "Community Standards. So ANSI Common Lisp has in this comparison a much better base.
Altogether, I think CommonLisp has the right idea in terms of overall language functionality for an advanced language for rapid development and prototyping: Lisp syntax, macros, reflection, powerful object system, interactive development, dynamic modification of code, etc. But the ANSI CL standard just got too many practical issues wrong as far as I'm concerned. The right thing to have done would have been to start over and not accomodate the half-dozen or so vendors with their oddball interests. In fact, some such efforts were around in the early 1990s, but the existence of the ANSI CL standard never let them get off the ground, and I think ANSI CL gave Lisp such a bad name that eventually people just gave up on it. In fact, in many ways, systems like Java and Python are Lisp systems disguised carefully enough so as to not offend a Lisp-weary public.I cannot really follow your rationale - it is all very fuzzy and subjective.
Nobody forces you to like or use Common Lisp but don't spread such FUD to the people. Most of what you have written on "better" or on what in your sole opinion the ANSI CL Standard got wrong is absolutely subjective without any concrete argumentation.
Sorry for the bad formatting - but after dozens of tries to preview the article which only resulted in network timeouts I hit the submit button and to my astonishment seemed to work... I formatted the text appropriately in the text-field but do not know why it got so crippled (*grr*)
There are several opportunities for Common Lisp. The commercial Lisps tend to come with decent GUI support. - Xanalys LispWorks comes with "CAPI" which is a portable (between OSes) Toolkit that uses the WinAPI on Windows and Motif on UNIX/Linux. - Franz Inc. AllegroCL comes with "Common Graphics" which is a Toolkit written for Windows - Digitools MCL comes with decent MacOS GUI support - Xanalys _and_ Franz _and_ Digitool offer implementations of "CLIM" (Common Lisp Interface Manager) a GUI Framework portable between OSes and Lispsystems Free GUI Toolkits (probably incomplete) - CLX is an implementation of the X Protocol in pure (!) Common Lisp (no binding to the C libs!). Therefore it runs on nearly every Lispsystem available. You need a X-Server to use Programs written with it, and the Toolkit is rather low-level. - CLM is a binding to Motif available for CMUCL and AFAIK some other systems. - Garnet is a rather extensive (but unfortunately not further developing) GUI Toolkit for several Systems - CLG and CL-GTK are Bindings to GTK for at least CMUCL - McCLIM is an effort to build a free implementation of CLIM (see above) which is developing rather quickly and looks very promising. Rationale: It is possible to use Toolkits like GTK or QT with Lisp, but there are several Problems with those: - Both GTK _and_ QT make sometimes stretch the image of what can be counted as easy portable C Interfaces (with QT offering until recently only a C++ interface) - GTK Does not look native on Windows, QT does but cannot be used commercially without paying license fees on Windows. - Simply writing bindings is not enough it will look like coding C in Lisp if there is no good layer above the low-level stuff. Therefore IMHO the right way for Common Lisp is to count on McCLIM getting _the_ OS and Lisp-System independent GUI Toolkit it deserves to be (with the possibility of having GTK, Motif, QT, WinAPI... as Backends)