> * Brian Rogoff > | Java has multithreading facilities built into the language. While there > | are certainly Lisps, notably EuLisp, which also have built in threads, > | ANSI Common Lisp does not. This may be important to some people.
> can you draw a line between Java the language and Java the implementation > the same way the Common Lisp guys had to draw that line? if you can't, > don't you think it's grossly unfair to compare the two infavorably as long > as there are implementations that support everything you ask for? I do.
I don't understand your point. Java has multithreading as part of the language standard. See
if you don't believe me. This is a fact. Whether or not you like the particular choice of multithreading primitives, and whether or not extant implementations support it fully, is not what I am arguing. ANSI Common Lisp has no primitives for multithreading. That Franz, Harlequin, and others may provide multithreaded implementations is also outside the scope of my argument, but I certainly don't think I was "grossly unfair". The thread packages in Common Lisp implementations are vendor specific. Do you dispute this?
PS -- I am aware that CLIM provides some basic multi-processing functionality.
In article <3343CD48.3...@pcisys.net>, "Brian N. Miller"
<bmil...@pcisys.net> wrote: > Jason Trenouth wrote:
> > I still contest that Java is a poor substitute for Common Lisp.
> I suspect your complaints are against the java language, and not > the jvm. Writing a lisp interpreter
Few are really interested in INTERPRETERS these days.
> that targets the jvm has > already been done more than once. So you can write applets in > lisp and market them as java code.
The limitations of the Java virtual machine for supporting Lisp and similar languages (Smalltalk, Prolog, ...) makes it hard to implement these languages efficiently (this was the last thing I have heard on this topic). SUN has built a *Java* virtual machine - and not a more universal VM. Sigh.
Jason Trenouth wrote: > The language. I believe (correct me if I'm mistaken) that in Java, the stack > is unwound _before_ a handler runs. This makes some kinds of recovery much > clumsier than in Common Lisp, where the handler can run with all the context > of the signaller.
Yes, for exception handlers Java has termination semantics, not resumption semantics. See "The Design and Evolution of C++" (by Bjarne Stroustrup), section 16.6. He discusses at length why they choose termination semantics for C++ (and the reasons given include significant real-world experience with both kinds of semantics). All the same arguments apply for Java.
> > I don't know what you mean by "no real dynamism".
> In this case I meant sometimes having to explicitly tell the compiler what the > type is (via a cast) in order get something to work (again, correct me if I'm > misinformed). In languages like Common Lisp and Dylan, adding explicit typing > doesn't change the semantics of the program: it only improves its performance > or error checking.
The fact that you have to sometimes specify a cast isn't (IMHO) a reduction of dynamism, and it allows static type-checking. You still get dynamic binding, which is "real dynamism".
In article <3341B6DE.6...@felix.cc.gatech.edu>, Susan Fisher RSTC Contractor <sfis...@felix.cc.gatech.edu> wrote:
>I have a similar question. I am taking an AI course where we may >program in any language we choose. I debating the use of C, C++, >and LISP. I am looking for any insight on the pros and cons of >these languages. I am a very new programmer and have honestly >never had the option of which language to use! And advice >would be greatly appreciated.
If your course-work involves mainly the kind of programs typical of such courses -- small planners, natural language parsers, rule-based expert-system type programs, etc -- then you should not use C++. Using lisp will save you lots of time and trouble, and that goes double if you are not an experienced programmer.
David
PS: Before anyone accuses me lisp religious bias, I use primarily C and Prolog in my daily work.
ja...@harlequin.co.uk (Jason Trenouth) writes: >I still contest that Java is a poor substitute for Common Lisp. If there were >a list of Java-only features then it would simply mean that the converse also >held. Both can be true without any contradiction.
I understand and agree.
But usually one is looking for a programming language that will get the job done, no looking for "a substitute for Common Lisp" or "a substitute for Java". For most tasks, if you look at the big picture then I think Java would be a good substitute for Common Lisp, even though on a feature-by-feature basis some Java features may be poor substitutes for the equivalent Commoon Lisp features. I don't think the converse is true, because the features which Java has that Common Lisp doesn't (e.g. portable GUI, multithreading, browser security model, etc.) are a lot harder to simulate.
-- Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
Erik Naggum <e...@naggum.no> writes: >* Brian Rogoff >| Java has multithreading facilities built into the language. While there >| are certainly Lisps, notably EuLisp, which also have built in threads, >| ANSI Common Lisp does not. This may be important to some people.
>can you draw a line between Java the language and Java the implementation >the same way the Common Lisp guys had to draw that line?
Yes, you can. Java the language is defined by the Java Language Specification.
-- Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
Erik Naggum <e...@naggum.no> writes: >since this is posted to comp.lang.java.advocacy, what's to expect? *sigh*
I think a .advocacy group is the right place to discuss language comparisons. A .advocacy group doesn't have do be devoted to mindless religious tracts. It is possible to have useful technical discussions in such groups.
Are you suggesting that serious technical language comparisons are impossible? Are you suggesting that those interested in serious technical discussion should abandon .advocacy groups? If people interested in serious technical discusssions wish to disuss language comparisons, where better to discuss them?
-- Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
> The examples I've seen require 20 or so lines of code to do the work of > one. OTOH the Pizza compiler adds closures to Java without requiring any > changes to the JVM (Pizza code compiles into regular Java code). Now if > someone could get Symantec, Borland, Asymetrix, or someone to support > the Pizza extensions in an IDE..
Yeah, Pizza is much nicer, I agree.
> > Yes, you do miss out > > on macros, but macros have disadvantages as well as advantages.
> I suspect you're thinking of C macros, which are a whole different (and > vastly inferior) animal. Lisp macros are far more flexible and > powerful, and permit techniques which solve most of the problems > associated with simple string-replacement macros.
I know that lisp macros work on s-expressions, not on strings. (Hey, even C macros work on tokens, not strings...)
I'm not very familiar with lisp macros, but I imagine that they are probably pretty similar to something that I am quite familiar with, namely Prolog's de facto standard `term_expansion' feature, which is preprocessing at the level of Prolog terms.
Even processing things at a that level, term_expansion macros share quite a few of the problems of C macros, including added tempatation to invent inscrutable new languages that no-one else will understand, difficulty of source-level debugging, etc.
> The only thing (and it's an important point, I'll admit) you can do in > Java but not in Lisp is:
> Sell your project to management.
;-)
-- Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
* Erik Naggum | can you draw a line between Java the language and Java the implementation | the same way the Common Lisp guys had to draw that line?
* Fergus Henderson | Yes, you can. Java the language is defined by the Java Language | Specification.
the important issue in this regard is that Common Lisp was an effort to standardize what _could_ be standardized among vendors of other Lisps (before CLtL) and Common Lisp (after CLtL). lack of agreement on a multi-processing system excluded it from the standard, although every vendor has their version of it. the same goes for many other things.
Java had the luxury of being specified and implemented by the same vendor. the difference between "language" and "implementation" is thus a question of how much you can agree with yourself to make part of the language.
#\Erik -- I'm no longer young enough to know everything.
* David Hanley | I don't think so. One has to bear in mind that in diffrent languages, | one uses different models. In java, I'm not likely to design my program | around features that don't exist.
which is, I believe, _the_ point. the weak Sapir-Worf hypothesis states that it is hard to think about that for which you do not have a language. (the strong Sapir-Worf hypothesis states that you cannot, but this must be wrong, considering that new languages and words are created.)
| > | Yes, you do miss out on macros, but macros have disadvantages as well | > | as advantages. | > | > what an amusing argument. | | Exactly how is it amusing?
imagine it generalized to other things that have "disadvantages as well as advantages", i.e., everything -- somehow, this is an argument in favor of _not_ supporting it. as such, it is completely devoid of meaning, it is ridiculous on its face. ("no, we're sorry, you car can't have an engine because engines have disadvantages as well as advantages.") this argument can be used about anything by anyone with impunity -- it requires no accountability of those who employ it -- _everything_ has "disadvantages as well as advantages", especially if this is left to people who are somewhat fuzzy on exactly what is being requested. (it appears that Fergus is thinking in terms of C's macro system, which has severely restricted functionality. better macro systems existed before C got its variety.)
| > I think it would have added credibility to your argument if you had | > asked what a `restart' in Common Lisp is. | | Why don't you tell us?
I did.
"restarts are a fundamental part of the Common Lisp condition system."
when an operation fails, the programmer can request certain actions from the exception handler that would rectify the situation and effectively restart the attempted computation. typically, the exception handler would invoke the debugger, which would present the user with some choices and accept an answer.
| Well, let's take a shot at it:
considering that Java is optimized for certain uses, let's look at what you can get from Common Lisp systems that try to address the same needs.
| 1) Portable binaries.
several Common Lisp implementations offer portable byte-code binaries, as well. one outstanding example is Bruno Haible's CLISP implementation. another, not Common Lisp, but proof positive that "portabel binaries" existed before Java was conceived, is GNU Emacs. however, most Lisp vendors and users find that execution speed is important enough to merit native compilation. this is also true of Java, I hear, so we're debating implementations.
| 2) Run-in-the browser models.
Java doesn't run in the browser. JVM byte-code does. JVM is intentionally crippled, but Scheme->JVM compilers exist. as an execution target, nothing prohibits Common Lisp to compile to it, only nobody has done so.
| 3) Secure executable model.
ahem. please see comp.risks and the trade magazines for the precise value of "secure" which makes "secure" a feature of Java.
| 4) True basic types (efficency consideration).
this is something Common Lisp does not have? the mind boggles.
| 5) Built-in graphical user interface model (portable).
granted. remove "built-in", and Common Lisp systems support various GUIs. stick with one vendor's choice, and you're as far as you get with Java.
| 6) *Very* elegant and powerful threading model.
all the commercial Common Lisp implementations provide multiprocessing. again, stick with one vendor, and you're as far as you get with Java.
| 7) Interfaces.
granted. as a language construct, this is neat.
| 8) Simple foreign function interface.
again, true for any particular Common Lisp vendor. not standardized because of the much wider variety of languages to talk to when the various Lisps evolved and from whence came Common Lisp.
| 9) Object serilization.
not sure what you mean here.
| 10) Remote method invocation.
this is standard in all network-capable systems, including those written in Common Lisp. indeed, some Lisp systems work mostly by remotely requesting a form to be executed, then returning the values.
| 11) Robustness of a static type checker
this is certainly debatable as a feature. Common Lisp compilers typically offer type inference without needing the programmer to declare all the types manually. declaring types only helps "prime" the type inference.
| Now, you could do some of these things in lisp, but I refer you to your | earlier pragmatics model.
I think you're overusing the word "model", and I think your list is highly debatable as to the already implemented, already done, _factual_ aspects of Common Lisp that you want to compare to.
| A better list might have showed some examples, and asked how the same | task might be carried out. If the original list were a valid mothod of | discussion, I could post some assembler tricks, and smugly ask how it | would be done in lisp. It would mean nothing related to the current | discussion, much like the original list.
my guess is you'd be very surprised to learn just how much low-level stuff can be done in Lisp.
#\Erik -- I'm no longer young enough to know everything.
* Brian Rogoff | I don't understand your point. Java has multithreading as part of | the language standard. See | | http://www.javasoft.com/doc/language_specification/17.doc.html | | if you don't believe me. This is a fact. Whether or not you like the | particular choice of multithreading primitives, and whether or not extant | implementations support it fully, is not what I am arguing. ANSI Common | Lisp has no primitives for multithreading. That Franz, Harlequin, and | others may provide multithreaded implementations is also outside the | scope of my argument, but I certainly don't think I was "grossly unfair". | The thread packages in Common Lisp implementations are vendor specific. | Do you dispute this?
I hate it when people are fully aware they don't understand the point and yet go on imply that I don't believe or dispute simple facts. puh-lease!
the point is simply that both Java and Common Lisp implementations include multithreading, but because of practical problems in the standard process for ANSI Common Lisp (i.e., obtaining consensus), it is not included in the standard. all Common Lisp systems have good debuggers, foreign function interfaces, editors, inspectors, etc, most of which are at best only hinted at in the standard. Java is a specification closer to the implementation, and intentionally so. considering this, it's grossly unfair to compare the language, and not the implementations.
#\Erik -- I'm no longer young enough to know everything.
With a mighty <3343CD48.3...@pcisys.net>, bmil...@pcisys.net uttered these wise words...
> Jason Trenouth wrote:
> > I still contest that Java is a poor substitute for Common Lisp.
> I suspect your complaints are against the java language, and not > the jvm. Writing a lisp interpreter that targets the jvm has > already been done more than once. So you can write applets in > lisp and market them as java code.
Or even a Lisp compiler. Some Lisp compilers produce C source code. The same is true for a number of Prolog (and Prolog-like) languages. Perhaps we'll see some Lisp and Prolog compilers that generate Java source code, and more compilers that create JVM bytecodes directly.
The JVM may be the ultimate commercial "black box" for delivering code. IMHO it's too early to say what can't be done this way, while the list of things already being done is impressive enough! We may be wondering how we coped for so long without it, a few years from now.
However, this needn't depend on us all using Java. It merely depends on the quality of the "black box", i.e. the JVM, and that's rapidly improving. Even if it seems impractical to some of us today, it's easy to "sell to your management", which should buy us a bit of time.
I'm assuming that it's the JVM that's making Java so successful, and not something else, like Web applets. That's another issue. ;) -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough Martin Rodgers | Programmer and Information Broker | London, UK Please remove the "nospam" if you want to email me.
Fergus Henderson <f...@mundook.cs.mu.OZ.AU> wrote: >Even processing things at a that level, term_expansion macros >share quite a few of the problems of C macros, including >added tempatation to invent inscrutable new languages that no-one >else will understand, difficulty of source-level debugging, etc.
Unfortunately in the absence of powerful macros, people invent languages like "awk", "perl" and C++ -- which are inscrutable, hard to understand and difficult to source-level debug. I think that it is better to not invent a new language to support every new programming paradigm or application domain. Every time we do, we forget all of the good things from the older languages. With macros you can make old languages handle new application domains and paradigms naturally.
In article <3069141939866...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
>I hate it when people are fully aware they don't understand the point and >yet go on imply that I don't believe or dispute simple facts. puh-lease!
Yes, like certain peoplr who don't knwo the existance of the synchronized >keyword< in the >Java language< Multithreading is part of the >Java language<
> * Brian Rogoff > | Java has multithreading facilities built into the language. While there > | are certainly Lisps, notably EuLisp, which also have built in threads, > | ANSI Common Lisp does not. This may be important to some people.
> can you draw a line between Java the language and Java the implementation > the same way the Common Lisp guys had to draw that line? if you can't, > don't you think it's grossly unfair to compare the two infavorably as long > as there are implementations that support everything you ask for? I do.
'unfair' in what respect?? I thought we were interested in pragmatics here. ;) If Java does 'X' better talking about the pressure the implementers were under is not terribly ineresting.
Marco Antoniotti <marc...@infiniti.PATH.Berkeley.EDU> wrote: >If there where two major developers of Java instead of one and each of >them had developed its own flavor of 'native' interface,
Then they would cease to be Java vendors. The JNI is a standard part of Java the runtime (and has little to do with the language as this thread is about).
>saying the same for Java. The truth is that, given an implementation >of Common Lisp, its "connectivity to anything non lisp" (which means >C) is very wel defined and developed.
Ugh. This is worse than the "every language is touring complete" arguments.
> * David Hanley > | I don't think so. One has to bear in mind that in diffrent languages, > | one uses different models. In java, I'm not likely to design my program > | around features that don't exist.
> which is, I believe, _the_ point. the weak Sapir-Worf hypothesis states > that it is hard to think about that for which you do not have a language.
That's not at all what I'm talking about. The fact that java does not have feature 'x' is not a terribly big deal unless the design of a specific program cries out for feature 'x'. If there is another, equally valid design that uses feature 'y', which is present, it isn't a problem at all. There are few programs which actually require 'x'.
> (the strong Sapir-Worf hypothesis states that you cannot, but this must be > wrong, considering that new languages and words are created.)
> | > | Yes, you do miss out on macros, but macros have disadvantages as well > | > | as advantages. > | > > | > what an amusing argument. > | > | Exactly how is it amusing?
> imagine it generalized to other things that have "disadvantages as well as > advantages", i.e., everything -- somehow, this is an argument in favor of > _not_ supporting it. as such, it is completely devoid of meaning, it is > ridiculous on its face.
It is not "ridiculous on its face." Pointer arithmetic in C has some advantages. Lisp doesn't have pointer arithmetic. Therefore, lisp sucks. Refute.
[deletia]
> | 1) Portable binaries.
> several Common Lisp implementations offer portable byte-code binaries, as > well.
Interesting, but since the format is not specified in the standard, each vendor creates their own. This means I'm tied to a specific vendor, and the machines they've decided to support.
> however, most Lisp > vendors and users find that execution speed is important enough
Shouldn't be using lisp then.. ;)
> to merit > native compilation. this is also true of Java, I hear, so we're debating > implementations.
Nope. JIT compilers work quite well.
> | 2) Run-in-the browser models.
> Java doesn't run in the browser. JVM byte-code does. JVM is intentionally > crippled, but Scheme->JVM compilers exist. as an execution target, nothing > prohibits Common Lisp to compile to it, only nobody has done so.
Thanks. That's still a point for me. Rmember, we're discussing pragmatics here.
> | 3) Secure executable model.
> ahem. please see comp.risks and the trade magazines for the precise value > of "secure" which makes "secure" a feature of Java.
Java has a secure executable model. If there is a badly-implemented browser somewhere, that does not refute this. The browser will be fixed.
> this is something Common Lisp does not have? the mind boggles.
It matters a lot for numerical work and graphics.
> | 5) Built-in graphical user interface model (portable).
> granted. remove "built-in", and Common Lisp systems support various GUIs. > stick with one vendor's choice, and you're as far as you get with Java.
No you won't. First of all, sticking with one vendor is bad. It drives up prices, and locks you into a certian system. You sacrifice portability along with a lot of other things.
> | 6) *Very* elegant and powerful threading model. > all the commercial Common Lisp implementations provide multiprocessing. > again, stick with one vendor, and you're as far as you get with Java.
Is it good? Is it portable? What if I need to change vendors because we need another gui? Remember, pragmatics!
> | 8) Simple foreign function interface.
> again, true for any particular Common Lisp vendor. not standardized > because of the much wider variety of languages to talk to when the various > Lisps evolved and from whence came Common Lisp.
Reasons why are not too important. The fact no standard, simple one exists is.
> | 9) Object serilization. > not sure what you mean here.
Changing object 'a into a stream of bytes.
> | 10) Remote method invocation. > this is standard in all network-capable systems, including those written in > Common Lisp.
But is it part of the standard language? Can I call a function on another machine and expect a response?
> | 11) Robustness of a static type checker
> this is certainly debatable as a feature.
Sure. So are some of the lisp 'fetures'
> | Now, you could do some of these things in lisp, but I refer you to your > | earlier pragmatics model.
> I think you're overusing the word "model", and I think your list is highly > debatable as to the already implemented, already done, _factual_ aspects of > Common Lisp that you want to compare to.
I'm not sure what this means.
> | A better list might have showed some examples, and asked how the same > | task might be carried out. If the original list were a valid mothod of > | discussion, I could post some assembler tricks, and smugly ask how it > | would be done in lisp. It would mean nothing related to the current > | discussion, much like the original list.
> my guess is you'd be very surprised to learn just how much low-level stuff > can be done in Lisp.
In article <3341B6DE.6...@felix.cc.gatech.edu>, Susan Fisher RSTC Contractor <sfis...@felix.cc.gatech.edu> wrote:
>I have a similar question. I am taking an AI course where we may >program in any language we choose. I debating the use of C, C++, >and LISP. I am looking for any insight on the pros and cons of >these languages. I am a very new programmer and have honestly >never had the option of which language to use! And advice >would be greatly appreciated.
I actually wrote an AI project in C, instead of Prolog, because it was computationally intensive. I spent most of my time doing fiddly manipulations of pointers and lists, which I wouldn't have had to if I'd chosen Prolog, or even Lisp (my project was late) - my recommendation is, unless you have to use it, avoid C for something like this.
Brian N. Miller wrote: > I suspect your complaints are against the java language, and not > the jvm. Writing a lisp interpreter that targets the jvm has > already been done more than once. So you can write applets in > lisp and market them as java code.
Is such a Lisp to Jvm compiler available (commercially or free)?
Johannes Link -- Abteilung fuer Molekulare Biophysik (0810) Deutsches Krebsforschungszentrum Im Neuenheimer Feld 280 D-69120 Heidelberg
>John Nagle wrote: >> Prolog is useful for a limited class of problems that are >> expressable in its rule form, and almost useless for anything else.
>I do not agree with you. In fact, LOTS of problems are indeed >expressible in rule form. For my master's thesis, I wrote a bytecode >compiler and interpreter for a ML-like language. It did type inference, >and had a very nice syntax error recovery scheme. The source code was >less than 800 lines long, including lexical analysis and syntax >analysis, which accounted for almost half of the size of the program.
Wow, sounds cool; could I take a look at that code?
-- --Office phone: 541-737-5583 (Batcheller 349) home: 757-8772 Office mail: 303 Dearborn Hall, OSU, Corvallis, OR 97331 --I proactively leverage my synergies to grow the business.
i've programmed in lisp, i've programmed in java. java is a sweet language. clean, simple, quick to code, quick to debug, sort of the pascal of the object world. it's my second favorite language (out of 60+ that i've written programs in).
the fundamental reason i like lisp over ALL of the others has NOTHING to do with features. discussing features misses the point.
writing lisp code is like breathing. you just do it. there is almost NO "friction" between the thought and the implementation. i can mix nearly machine level primitives (CAR => *ptr+0 and research level concepts (GeneticallyCombine ...) in the same expression. plus the program is syntactically (and sometimes semantically) the same as the data. these two properties of lisp make it a "language" you use to express ideas rather than a "coding vehicle" which everything else amounts to. there is no distinction between the thought and the writing of the thought in lisp. (too ZEN-like a notion, i guess)
but that's just my considered opinion. now if only i could get paid to write lisp again :-)
* David Hanley | Java has a secure executable model. If there is a badly-implemented | browser somewhere, that does not refute this. The browser will be fixed.
I'm happy for you. good luck with Java, David.
#\Erik -- I'm no longer young enough to know everything.
jos...@lavielle.com (Rainer Joswig) writes: > The limitations of the Java virtual machine for supporting Lisp and > similar languages (Smalltalk, Prolog, ...) makes it hard > to implement these languages efficiently (this was the last > thing I have heard on this topic). SUN has built a *Java* virtual > machine - and not a more universal VM. Sigh.
Could you, or someone else, elaborate on that? It's somewhat disappointing, I sort of naively hoped that Java was close enough to lisp to make the Java VM suitable as a lisp platform, and it would really be interesting to know exactly what parts of lisp that makes it _that_ different from Java (this thread would really benefit from a serious contribution on this topic!).
There is also a document (doc/scm2java.html in the distribution) about the problems of compiling Scheme to the JVM and his ideas for a solution; most of that is also valid for other Lisps.
