From ... From: Erik Naggum Subject: Re: Java vs lisp (was: Re: Prolog vs. Lisp) Date: 1997/04/04 Message-ID: <3069141470022625@naggum.no> X-Deja-AN: 230636793 References: <3340DFEC.3C0F@netvision.net.il> <3341B6DE.6970@felix.cc.gatech.edu> <3365440d.698147468@newshost> <5huud5$fkt@mulga.cs.mu.OZ.AU> <3069065551958052@naggum.no> <3343D014.11A4@nospan.netright.com> mail-copies-to: never Organization: Naggum Software; +47 2295 0313; http://www.naggum.no Newsgroups: comp.ai,comp.lang.java.advocacy,comp.lang.lisp * 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.