Post #66,834
12/5/02 5:43:17 AM
|
Java - a baby step towards Smalltalk -a giant leap towards C
[link|http://jcp.org/en/jsr/detail?id=201|http://jcp.org/en/jsr/detail?id=201]
Instead of the stupid autoboxing idea - howabout we just make everything really an objects. Then maybe things like:
Number n = new Integer(3);
Number m = new Long(3);
if(n.equals(m)) { System.err.println("Wow, they fixed it!"); }
else { System.err.println("This is what happens now"); }
The static import gives us back functions - just like C.
Make up your mind.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #66,850
12/5/02 9:55:51 AM
|
Re: Java - a baby step towards Smalltalk -a giant leap
What is autoboxing?
-drl
|
Post #66,883
12/5/02 11:12:52 AM
|
Read the link
An automatic conversion from primitive types to their corresponding reference type wrappers. This conversion facilitates the integration of generics into the language, and reduces inessential clutter.
Many fears are born of stupidity and ignorance -
Which you should be feeding with rumour and generalisation.
BOfH, 2002 "Episode" 10
|
Post #66,884
12/5/02 11:13:35 AM
|
Java gravitating towards C#?
All the features cited are merely copying nicety features from C#. Autoboxing is the automatic encapsulation (de-encapsulation) of primitive types into object types (vice-versa) when required. It's always been a pain in Java to have collections of primitives, since the primitives have to be boxed in terms of their related Class Type:
Integer i = new Integer(123);
int j = i.intValue();
Boxing tries to obviate the need for explicit casting, so that you can write:
Integer i = 123;
int j = i;
|
Post #66,890
12/5/02 11:31:51 AM
|
Re: Java gravitating towards C#?
That's a horrible idea - the return of the implicit cast in a way.
-drl
|
Post #66,877
12/5/02 11:00:34 AM
|
They won't admit they were wrong
Let's face it, the guys who developed Java were C/C++ guys who knew a little Objective C. Java 1.0 was pathetic in what it was missing. A guy at IBM (Sherman Alpert), write a great paper called "Primitive Types Considered Harmful" in 1998 where he showed all the disadvantages of primitive types and he offered a simple solution. Nothing came of it, and in fact, IBM removed the paper (without his knowledge). If anyone wants I can post some of his points here.
|
Post #66,878
12/5/02 11:02:36 AM
|
I had a "discussion" with a C++ programmer
I mentioned that Java had its problems, and he said, "what do you mean?"
So I went through the whole spiel about primitive types, etc.
He didn't really get it. :-)
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #66,921
12/5/02 1:42:49 PM
|
Re: I had a "discussion" with a C++ programmer
This thing appears so many places on the web that its a cliche - yet it remains very apt.
[link|http://www.harshman.com/archives/apes.html|http://www.harshman....rchives/apes.html]
Its funny - I got hammered at my San Diego job interview by a comp sci guy with good street cred (phd with decent papers - computational linguist and ai) because I ventured that Java was a productivity killer.
He got nasty and said - "Look, James Gosling and friends are not bozos, they are not rubes, they know lisp, smalltalk, objective c, C++ and some other languages - why do you suppose they selected the feature set they did for Java?"
I ventured that 1) they don't really know all those languages - not from the standpoint of working daily in them - acquainted sure - know - nope. 2) Language design is an art involving many factors - including taste - apparently they're short on that and 3) I think they were trying to capture the folks C++ orphaned and thus had to make it appeal to people who like crappy languages.
Apparently he remains unconvinced cause I didn't get the gig. I probably blew the job on this point alone - but then I want to work with really good people and this guy was newly converted to the Java way (after being burned on a TCL oriented project that was a little too unstructured for its own good).
Its downright frustrating - we're never going to get off of Gilligan's island.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #67,462
12/9/02 9:40:00 AM
|
Re: I had a "discussion" with a C++ programmer
He got nasty and said - "Look, James Gosling and friends are not bozos, they are not rubes, they know lisp, smalltalk, objective c, C++ and some other languages - why do you suppose they selected the feature set they did for Java?" I think it's because Oak had a very small implementation budget. It was an experimental set-top box language. From that perspective, Java is a great language design, considered from the perspective of, "How can we get as much benefit from modern language design, given that we have this teeny-tiny budget?" So, look at all the things they did: -> No first-class functions, because that complicates the type system. -> No parametric types, because that complicates the type system. -> No clever object layout strategies. -> Whenever this caused a potential performance problem, they added a hack to fix just that problem, rather than solving the general problem. For example, consider string concatentation in Java, which implicitly creates StringBuffers, and also think about the primitive type/object distinction. -> They fixed bad intuitions with runtime checks: for example, Java arrays are covariant, rather than invariant. The unsoundness is fixed with a runtime typecheck on every access, rather than properly engineering the type system. Java probably does as well as can be expected given the amount of design effort put into it, but there are plenty of much better-engineered languages. (In fact, I'm creating one.)
|
Post #67,635
12/9/02 5:34:17 PM
|
Roll your own...
You wouldn't by chance be working on [link|http://neelk.dyndns.org:8080/needle/mit-needle-talk.pdf|Needle] would you? :-)
|
Post #67,658
12/9/02 6:55:04 PM
|
Interesting summary
Looked interesting but I don't have time to consider it closely. Randomly noticed that you need to correct the spelling of Once from p28 to 30...
Cheers,
Ben
"Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly."
- [link|http://www.nationalinterest.org/issues/58/Mead.html|Walter Mead]
|
Post #67,763
12/10/02 8:34:03 AM
|
Needle...
...is indeed what I am working on. :)
Not yet ready for prime time, but I think I've got something that will be moby fun to hack with when it is.
|
Post #67,841
12/10/02 1:22:39 PM
|
What is the underlying motivation?
Why do it? What problem is it intended to address? IOW, what is the central point? Thanks.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #67,891
12/10/02 4:46:58 PM
|
Re: What is the underlying motivation?
There are a couple. First of all, I wanted to write a language to use as part of my "portfolio" to get into grad school.
Since I didn't want to waste my time on building yet another toy language, I thought about what I really wanted from a programming language, and deciding to actually implement it. I do a lot of exploratory programming, and it's my experience that I need three key features to go as fast as possible.
1. I wanted support for functional programming. Higher-order functions (blocks to a Smalltalker) are an essential tool for avoiding code duplication, because they let you abstract common patterns of execution. They also let you reduce the size of your program's class hierarchy, because you can use first-class functions to parameterize behaviors. Both of these make programs more compact, and hence easier to understand and modify.
2. I wanted support for OO-style subclassing. When doing exploratory programming, I want to be able to extend existing datatypes as needed. In a functional language like Haskell or ML, this isn't possible -- one must edit the original datatype declaration and all of the code that uses it. This kind of sucks.
3. I wanted a generic function/multimethod based OO system. This solves the binary method problem completely, and makes extending existing classes with new behavior very easy. The Visitor pattern just vanishes, for example. Furthermore, being able to extend existing classes in a disciplined way lets you avoid adding useless subclasses to your system, and making messages first-class function values lets you integrate OO and FP easily. This makes programs smaller and easier to modify, again.
4. I wanted static typing with type inference. IMO, type inference is one of the most amazing technlogies out there. You get all of the benefits of static type-checking with almost none of the costs, with the additional benefit that when you are doing experimental programming you can use type errors as a tool to help figure out what the structure of your program should be.
I've used languages like Dylan, which support everything I want but #4, and languages like Ocaml, which give me everything but #3. In each case I found myself missing either generic functions or static type inference.
Finally, I wanted to write a language that would let me replace Python as my tool of choice for quick hacks. For example, I like Ocaml more than I like Python, but I turn instinctivly to Python for quick hacks because Python has a very clean set of libraries, and Ocaml has a rather irregular and quirky set of libraries. I want to write a FPL that took its direction from the practicality and pragmatism of the scripting languages -- I'd like to help bring the sheer speed and fun of statically typed OO languages to the scripting world.
|
Post #67,948
12/10/02 8:47:27 PM
|
Suggestion...
Look at [link|http://www.rubycentral.com/book/builtins.html|http://www.rubycentr...ook/builtins.html] closely. This is Ruby's libraries, which seem to do a very good job of abstracting a lot of what is good about a scripting language into a fairly cleanly designed library. Essentially, "Perl as a class library." You might get some useful ideas from browing that.
The most major thing that I think is wrong in the class structure is that it would have been nice if it was designed with something like [link|http://artengine.ca/matju/MetaRuby/|http://artengine.ca/matju/MetaRuby/] in mind from the start. What that is is a series of mixins whose purpose is to make it easy to implement a new data type which happens to resemble one of the basic built-in ones. (Think Perl's tie - only it falls out of the design of the language...)
Cheers,
Ben
"Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly."
- [link|http://www.nationalinterest.org/issues/58/Mead.html|Walter Mead]
|
Post #68,054
12/11/02 3:18:27 AM
|
Have fun
"I'd like to help bring the sheer speed and fun of statically typed OO languages to the scripting world."
Hmmmm. Clearly fun is in the eye of the beholder - I'm not fond of static typing at all. For instance I think its a bit weird that in this day and age the developer at the application level (programming to the metal is something else) is required to note implementatin details of whether a number is an integer or floating point.
IOW, Numbers should all work together to appear to be a seamless continuum. Sadly, this is one of those things that has become the box that people don't seem to be able to think outside of.
x = 5 // so its an int
x = 3.4 // its a double
x = 23984289827394828398792837598475928739847298374928374 // its a LargeInt
Every time I read the preamble to some new language and it starts out with differentiating short and long integers - I tend to dismiss it as yet me too language by another stone aged thinker.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #68,078
12/11/02 9:41:19 AM
|
Re: Have fun
Hmmmm. Clearly fun is in the eye of the beholder - I'm not fond of static typing at all. For instance I think its a bit weird that in this day and age the developer at the application level (programming to the metal is something else) is required to note implementatin details of whether a number is an integer or floating point. In statically typed functional languages like Haskell and Ocaml, there are no type declarations. It's the compiler's job to infer the necessary type annotations, and to warn the user if there are any inconsistencies. So you get most of the flexibility and ease of use of a dynamically-typed language, plus the sanity-checking of type declarations of a static language. Type inference also enables a new style of programming, in which you write some code, and then run the compiler to figure out what the type of a subexpression should be in order for the program to be consistent. I find this to be very addictive.
|
Post #68,084
12/11/02 9:52:02 AM
12/11/02 9:55:29 AM
|
Sounds cool - compare it to Strongtalk?
[link|http://www.cs.ucsb.edu/projects/strongtalk|http://www.cs.ucsb.e...ojects/strongtalk]
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #66,919
12/5/02 1:32:53 PM
|
I'd like to see it.
I can always use more ammo.
I wouldn't be nearly as annoyed if the wrappers weren't so impossibly lame. Could we have the ability to just *compare* numbers for equality? Maybe just the int types?
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #67,303
12/7/02 3:21:00 PM
12/8/02 7:39:19 AM
|
Some shortcomings of primitives
1. Here are some really good ones about reflection and primitives.
Java's reflection code has incorporated an assortment of kludges to be able to handle primitives. A few examples:
a. There are times when using the reflection API "magic" happens with regard to primitive types and wrapper classes. Sometimes, we expect a primitive but instead get an instance of a wrapper. Conversely, at times we must remember to wrapper primitives before passing them as arguments to reflection methods.
Given the following code:
public class Tester {
public boolean test (int i) {
return i > 3;
}
}
The method takes an int and returns a boolean. Yet to invoke it via reflection I need to pass it an Integer object and I receive back a Boolean object. Here is the code:
Object[] args = new Object[1];
args[0] = new Integer(3);
Boolean result = (Boolean)m.invoke(t,args);
In short, if I invoke test via a normal method call I pass it an int (primitive) and it returns a boolean (primitive). If I invoke test via reflection I need to pass it an Integer (object) and it returns a Boolean object, does that make sense????
b. Every object is an instance of a class and I can obtain the Class instance at runtime by calling getClass(). However, primitives, have no class and therefore the following is not allowed:
int i = 1;
i.getClass();
However, I can get a Class object for a primitive in a number of ways. For example:
class Test {
public int i;
}
Test test = new Test();
Class c = test.getClass();
Field fieldi = c.getField("i");
Class classOfI = fieldI.getType();
I now have a a Class object for int!!
classOfI.getName(); //returns int
We can ask it its name, and we find that we have a Class named "int." Realizing part of the problem, the developers of Class included a message to ask if the Class is a primitive:
classForI.isPrimitive() // returns true
But, how can a Class be a primitive? What does that mean???
There are other ways to get a Class object. We can say:
Class class = int.class;
and obtain a Class object whose name is int. Yet we cannot do the following:
Class.forName("int");
this does work for regular classes such as:
Class.forName("java.lang.String");
In short Java's reflection code has incorporated a series of kludges to be able to handle primitives. We have classes that are primitives, somethings work somethings don't, etc.
2. Because of primitive types polymorphism and thus a big piece of
good object-oriented design is defeated and we need to code special
cases for primitives. For example: String needs 8 different valueOf
methods to deal with all the primitive types. Here is the code:
public static String valueOf(Object obj) {
return (obj == null) ? "null" : obj.toString();
}
This should be all that is needed, an Object decides how it is printed (in fact even this method has a problem in that it needs to explicitly check for null and handle it, in a real OO language like Smalltalk, nil knows how to print itself). However for primitives we need to take a procedural approach, the decidison is made by code separate from data.
public static valueOf(boolean b) {
return b ? true: false;
}
3.Primitive variables cannot be used wherever objects can be used;
You can't have a collection of int's
Edited by bluke
Dec. 8, 2002, 07:39:19 AM EST
|
Post #67,446
12/9/02 5:08:06 AM
12/9/02 5:24:46 AM
|
Yep, seen all those.
FWIW, I've been having an email exchange with Gilad Bracha - one of the sponsors of this thing who, as it turns out, is one of the creators of Strongtalk (bought by Sun and killed).
His explanation is that, yes this is lame, but you can't lead them out of the darkness all at once - you have to do it incrementally and this is one more step on the path.
His response:
"The JSR has been very well received - Java people love it. Only Smalltalkers complain."
But I wasn't complaining about his JSR - rather that its a bit of a bandaid on a sucking chest wound. And of course Java people love it - Java people love Java.
I am out of the country for the duration of the Bush administration.
Please leave a message and I'll get back to you when democracy returns.
|
Post #67,464
12/9/02 9:47:58 AM
|
Unfortunately people like Gosling ...
are not headed in the same direction. Here is a quote from Gosling
[link|http://java.sun.com/features/2002/03/gosling.html|ABOUT JAVA TECHNOLOGY An Interview with James Gosling ]
"JAVA DEVELOPER CONNECTION PROGRAM (JDC): If you could start again, would you make everything an object rather than the current int, boolean, byte, etc, viz-a-viz object disconnect?
JAMES GOSLING: No, actually I tend to go the other way, which is to say, a way to make classes behave more like primitives, so that they can be optimized and become extremely efficient, and maybe have a way to do autoboxing so that they sort of go back and forth between being objects. There are a lot of subtle problems around autoboxing that always make me nervous, and the big one being questions around identity. "
I agree with you that Java as it stands today is unsalvageable, they just keep adding more and more stuff on top of a very lousy foundation.
|
Post #67,529
12/9/02 11:35:23 AM
|
Heh. There's a reason for that.
And of course Java people love it - Java people love Java. Java people love Java because it's the only alternative to .ASP they can get past the managers. So let me them love it.
Many fears are born of stupidity and ignorance -
Which you should be feeding with rumour and generalisation.
BOfH, 2002 "Episode" 10
|
Post #67,904
12/10/02 5:44:29 PM
|
Java 1 wasn't *that* bad
But the all-in-one language libraries that really weren't sucked.
|
Post #68,055
12/11/02 3:39:26 AM
|
Wasn't bad???
Let us look at what was missing (basically what has been added since) excluding missing stuff from the libraries such as collections etc. (what I mean is stuff that a 3rd party can provide like a collections library or things like that) Note: this list is off the top of my head by no means complete, and in no specific order.
1. A completely brain dead event mechanism for the AWT which had to be completely redone in 1.1
2. No support for printing (not very useful to have an application that can't print anything), clipboard (copy/paste), etc.
3. No support for reflection which made it very hard to do any kind of generic or meta programming
4. No JAR file format, you had to ship the whole directory structure
5. No RMI
6. No object serialization
7. No JDBC (not much use as a business language if you can't access a database)
8. No internationalization support
9. No I/O character streams
10. No reference Objects
11. No fine grained security (either sandbox or not)
12. No JNI (which made it very hard to write native code)
13. No inner classes
14. A brain dead Date class which case all kinds of problems if you worked in more then 1 time zone
Based on this (and I know from experience in trying to write apps in 1.02) it was almost impossible to write any kind of serious application 1.02, eve Sun admitted that. On top of all this, it was incredibly buggy.
|
Post #67,306
12/7/02 3:38:04 PM
|
The Java-Language-Design Research Algorithm, Unleashed
I got this from a usenet newsgroup discussion
The Java-Language-Design Research Algorithm, Unleashed:
if (objective-C shows a way to do things better than C++)
\t do that;
else if (we really really hate this thing as C++ does it)
\t/* do nothing */;
else
\tc++.copy_from_slavishly_without_much_more_thought;
|
