All right,
this has been a blast but for the sake of the rest of this board I will agree to
disagree.
--
On Wed, 16 Jun 1999 17:43:49 Sergio Carvalho wrote:
>[EMAIL PROTECTED] wrote:
>
>> I disagree with most of what you say here.
>>
>> Saying that Java Classes have classes is not
>> the answer, what is the class of class? with out
>> a meta layer writing things like serializers and
>> integrated tools is much harder ( So does the fact
>> that it is typed but that is a whole other religous
>> war ).
>
>The class of class is java.lang.Class. I can't write it clearer than this.
>
>java.lang.Class was the first of a group of classes which form the meta layer for
>Java, and are now collected in the Java Reflection API, package
>java.lang.reflect. It allows you to find out absolutely everything about any
>descedant of Object (every class you can write in Java). You can write
>serializers, and integrated tools at will. Have a look at:
>
>http://java.sun.com/products/jdk/1.2/docs/api/java/lang/reflect/package-summary.html
>
>and find out what am I talking about.
>
>Moreover, you don't need to write serializers in Java. Classes ObjectOutputStream and
>ObjectInputStream (package java.io) already use the reflection API to
>query object data and serialize it. You just need to tag your serializable classes
>with the Serializable interface, allowing the referred streams to query the
>class for data.
>
>> It a conference someone in the audience asked one of the designers of Java to
>compare it to smalltalk. He said.
>> "Java is like Smalltalk with a Straight jacket for
>> protection"
>>
>
>I can't defend his comment. I have no idea what he meant by that, being that good or
>bad. Quotations out of context can have very different meanings.
>
>> you don't see a difference in elegance and readability between
>>
>> anInstance perform: #myMethod
>>
>> and
>> anInstance.getClass().getMethod("aMethod",null).execute(anInstance, null);
>>
>
>I can't think of anything more object oriented than the structure presented by Java.
>An instance is an instance *of* a class, a class *has* methods, a method
>can be executed. This code is so elegant that I wrote it without referring to the
>docs - I hope it's right :) -, just by using this knowledge about the API
>structure (and the fact that a method's signature is it's name and parameter types).
>
>The simplicity comes from the fact that, with the same technique, you can find what
>is the return type for the method:
>anInstance.getClass().getMethod("aMethod",null).getReturnType();
>or which exceptions it may generate:
>anInstance.getClass().getMethod("aMethod",null).getExceptionTypes();
>etc, etc...
>
>How do you do that in Smalltalk?
>
>> Keep in mind that software needs to be read and maintained (and which is easier to
>learn?).
>
>Humans respond better to structured data, than raw data. It is easier to remember
>that a class has methods that can be invoked and queried, than to learn
>there is a perform method in every class, a methodFields (?) method to find field
>types, etc.
>
>> And this is just a small example.
>
>An example that proves nothing is useless.
>
>> Using key words instead of having an extensible language does make the language
>more complicated.
>
>It would, except that every programmer knows what for, if, while, switch mean. the
>functionality vs complexity ratio is favorable to the adoption of these
>keywords.
>
>> There are good reasons why the best java development
>> environment is written in Smalltalk.
>
>Yes. VisualAge for Smalltalk is very similar, and was already on the market when the
>VisualAge for Java project started. No company is more commited to Java
>than IBM, and they've produced other very good tools with java. Check the alphaworks
>site - http://www.alphaworks.ibm.com
>
>VisualAge for Java contains Java code, and will increasingly be written in Java, just
>because it's simpler to write a compiler/debugger for Java in Java.
>
>> You think it is an exceptable solution to have two
>> types of Integer, one that is primitive and one that isn't? This doesn't make
>systems harder to read and maintain?
>
>As I mentioned, this is an almost reigious issue. There are undeniable performance
>benefits. Also, mathematical formulas - a+b*c - are easier to read, than
>a.add(b.multiply(c)). I don't think systems are harder to read and maintain because
>of primitive types. There are a number of things you can't do with a
>primitive type, but that is why Class types are there.
>
>> Let me ask you something. Have you ever seen a study
>> saying that programmers are more productive in Java
>> than in Smalltalk? There is an interesting study comparing the two at
>http://www.lineaengineering.com/Resources/Productivity_/productivity_.html web site.
>
>I said I am more productive with Java than with any other language I've used (and
>there have been lots...). A great number of factors can influence the
>productivity with a language, as well as popularity (JavaOne just beat the record of
>attendants for a developer conference), and I haven't used popularity as
>an argument.
>
>> Simplicity is elagance.
>
>Simple things I learn, I don't memorize.
>
>--
>Sergio Carvalho
>---------------
>[EMAIL PROTECTED]
>
>If at first you don't succeed, skydiving is not for you
>
>
>
>
--== Sent via Deja.com http://www.deja.com/ ==--
Share what you know. Learn what you don't.
