Newsgroups: comp.ai,comp.lang.java.advocacy,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!goldenapple.srv.cs.cmu.edu!das-news2.harvard.edu!news.dfci.harvard.edu!camelot.ccs.neu.edu!news.mathworks.com!usenet.logical.net!news.dal.ca!news.nstn.ca!newsflash.concordia.ca!torn!kwon!watserv3.uwaterloo.ca!undergrad.math.uwaterloo.ca!j2lynn
From: j2lynn@undergrad.math.uwaterloo.ca (James F'jord Lynn)
Subject: Re: Java vs lisp (was: Re: Prolog vs. Lisp)
Sender: news@undergrad.math.uwaterloo.ca (news spool owner)
Message-ID: <E8ErE8.p23@undergrad.math.uwaterloo.ca>
Date: Thu, 10 Apr 1997 06:01:20 GMT
References: <3340DFEC.3C0F@netvision.net.il> <scf4tdnerjs.fsf@infiniti.PATH.Berkeley.EDU> <E84p94.n4q@undergrad.math.uwaterloo.ca> <scf4tdlxpe0.fsf@porsche.PATH.Berkeley.EDU>
Nntp-Posting-Host: noether.math.uwaterloo.ca
Organization: University of Waterloo
Lines: 117
Xref: glinda.oz.cs.cmu.edu comp.ai:45423 comp.lang.java.advocacy:8050 comp.lang.lisp:26594

Marco Antoniotti <marcoxa@porsche.PATH.Berkeley.EDU> wrote:
>In article j2lynn@undergrad.math.uwaterloo.ca (James F'jord Lynn) writes:
>My argument was not against Java "per se" (I like Java more and more -
>Gosling and G. L . Steele seem to get closer and closer to the "right
>thing") My argument was an "historical one".  The evolution of Common
>Lisp has not been "centralized" and the different vendors at the time
>did play a (nefarious IMHO) role in influencing what went and what
>stayed out of the language.  The "foreign function interface" (toward
>C) in CL parlance is one of these.  Multiprocessing (Threading) was
>another and the UI substrate was another again.

   But is this a good thing or a bad thing.  The above just makes me happier
 that Java was not this way and dread the day it is.

>   >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. 
>
>This was not an argument.  It was a descriptive statement.
 
  So is saying "every language is turing complete".

>Because one of those imperscrutable events in history, Java got
>developed in one place with the right people in the same lab and with
>no competition from other groups.  This is history.  It has nothing to
>do with the merits of one language over the other.  But it was
>necessary to point out that CL does not "lack" certain features.

  But it is also necessary to point out that it does lack certain 
 >standardized< features that are found in Java just as Java lacks certain
 standardized features that are in CL.  This does not mean they can not be done
 and it does not mean that an API can exist to provide them. It just means that
 they aren't standard.

  As far as this whole thread goes, it seems rather ludacrous to me to compare
 the two languages.  "Java's no replacement for common lisp!" Well the Sun's
 no replacement for water, but that doesn't mean jack or shit when the lights
 go out.
  The point is that LISP (original LISP now) was designed for one thing:
 AI. Because of this, it allows some constructs that are not typically needed
 in non-AI projects. Oak was designed for embedded systems, and Java
 add some more design issues giving what we have: robustness, multithreading,
 network friendliness, abstraction and object-orientism, security smurfing, 
 internationalization, dynamism, and simplicty. 1.1 added more network
 friendliness, more dynamisism, database awareness, component structuring, 
 encryption, and data awareness.  What the hell am I talking about? well..

 Robustness: bounds checking on arrays, dereference checks, dynamic cast checks
  all add to the robustness of a system. I know a lot of times it's just a 
  pain in the ass to handle, but it's better than not being able to handle it
  at all.

 Multithreading: the syncronized keyword adds a powerful multithreading
  primative. The Object class has key monitor related methods and the API
  makes multithreading simple to achieve.
 
 Network Friendliness (mix of 1.0/1.1): The net API is standardized, object
  serialization allows for exciting network useds, all build ontop of a
  platform neutral system that works well in homogenous network environments.
  Top this off with RMI abstraction, badda bing, badda bang, cold fusion.

 Abstraction and object-orientism: Abstraction through interfaces, OO through
  inheritance. It is a new model that takes getting used to, but it can
  actually work wonders for design.

 Security smurfing: The Java runtime allows you to define any security smurf
  you may wish to impose on your system or subsets of your system. One
  section of your application may have a different security smurf applied to it
  than another and the smurf may change based on whatever the hell you feel
  like. Sections are defined by classloader instance and it is trival to
  implement smurfs that would have previously taken kernel hacking.  All of
  this is standardized.  The bytecode verifier helps a little here too.
 
 I8n: Unicode, yadda yadda.  At least they tried (can you tell I'm not a big
  Unicode fan).

 Dynamicism (1.0/1.1 mix): Dynamic linking, custom classloaders (linkers), 
  dynamic method invocation through reflection (yeah yeah this is in lisp.
  the custom class loaders aren't tho)

 Database awareness: Formal interface defined to databases through JDBC and
  SQL

 Component structuring: Java Beans gives a standardized structured way of
  defining a component and there is the API to support it. 

 Encryption: standard interfaces for encryption concepts (public-private keys,
  blah blah) and BigNum classes for doing quick RSA rip-offs in less than
  a second.

 Data awareness: standardised "Universal Data Transfer Mechanism", with
  model and supporting API
 

  Java also tends to have more infrastructure and CL has, i.e. there are more
 people running Netscape, IE, and HotJava, than are running a CL interpreter
 and deployment is handled for you.
  Java also tends to look more like C++ than CL, and so it is an easier
 transition. The standardized API's give C++'ers a reason to stay.

  But the thing is that CL has advantages over Java.  And in the applications
 where those advantages are key, then don't use Java.  Use that Scheme thingy
 that those people with those hands did. Or write a CL->Java converter and
 use CL.  Or just use CL.

  But I advocate Java for doing serious application work. I don't currently
 advocate it for fluffy Windows App type application work, but for serious
 apps, I think it is more than ready. It's also good for non-action games. I
 would say great for MOOs, but I can also see CL being better at those in 
 certain cases.
  Beyond that, I don't know, cause I don't go there.

-- 
Royalty free widgets - http://www.undergrad.math.uwaterloo.ca/~j2lynn/java.html
