Why does Java have both datatypes and objects?
D'Arcy Smith
James W. Howe wrote:
>
> One of the things I find the most annoying about Java is the fact that
> it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
> the language designers simply use Objects for everything?
Speed and efficiency.
There are tradoffs for everything - the designers felt speed would
be better than simplicity or orthogony I suppose.
..darcy
--
D'Arcy Smith
Symantec
James W. Howe
If that's true then I believe they have made a major mistake.
Machines, compilers, etc. will only get faster. Creating a confusing
language based on speed criteria is simply short sighted. I can't
believe that having true objects would have made a significant
difference in execution speed. Oh well.
James W. Howe internet: j...@allencreek.com
Allen Creek Software, Inc.
Ann Arbor, MI 48103
Doug Bell
j...@allencreek.com wrote:
> D'Arcy Smith <DSm...@symantec.com> wrote:
>
> >James W. Howe wrote:
> >>
> >> One of the things I find the most annoying about Java is the fact that
> >> it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
> >> the language designers simply use Objects for everything?
> >
> >Speed and efficiency.
> >
> >There are tradoffs for everything - the designers felt speed would
> >be better than simplicity or orthogony I suppose.
> >
>
> If that's true then I believe they have made a major mistake.
> Machines, compilers, etc. will only get faster. Creating a confusing
> language based on speed criteria is simply short sighted. I can't
> believe that having true objects would have made a significant
> difference in execution speed. Oh well.
I guess it's all a matter of perspective about what's confusing. I'm not
sure I would find having to declare:
int i = new int(5);
instead of simply
int i = 5;
an improvement, but then there are the issues like the Vector class. (And
I'm sure that int i = 5 syntax would have been supported, as String s =
"hi" is currently, but there's always int i = new int(), which I'm not
sure how you avoid unless int is implicitly instantiated, but then it
doesn't have all the properties of an object.)
Also, if every int is an object, then it is a reference, which takes up
space in addition to the now dynamically allocated int, which must be
dereferenced to get at the value.
Consider if I have an int[] which contains image data. Is this stored
with each element in the array being a reference to a pixel of image
data? How much larger is this than a simple array of int? How much
slower for image processing? How well does this mess with the underlying
OS and the ImagePeer classes?
Due to it's interpretted nature, Java already has a performance deficit to
make up, but at least JIT compilers offer a solution. I'm not sure how
you overcome the performance and memory deficit that eliminating simple
types would create, unless you require a runtime library on the order of
size of what you get with Smalltalk. IMO it would have been a major
mistake to *not* include basic data types.
Doug Bell
db...@shvn.com
Paul Hepworth
>>> One of the things I find the most annoying about Java is the fact that
>>> it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
>>> the language designers simply use Objects for everything?
>>
>>Speed and efficiency.
>>
>>There are tradoffs for everything - the designers felt speed would
>>be better than simplicity or orthogony I suppose.
>>
>If that's true then I believe they have made a major mistake.
>Machines, compilers, etc. will only get faster. Creating a confusing
>language based on speed criteria is simply short sighted. I can't
>believe that having true objects would have made a significant
>difference in execution speed. Oh well.
I, too object to the fact that base types are not objects.
However, it was not (just) for speed/efficiency. Notice that objects
are ALWAYS passed by reference whereas the base types are passed by value.
There is no way of passing an object by value. In languages such as C++
where there is no difference between base types and objects, additional
operators are required to specify reference vs. value (which is not a bad
thing). Also, there is confustion as to whether copy, assignment, and
comparisons of objects are "deep" (value) or "shallow" (reference) or some
somewhere in between (affecting part of the value). The folks at Sun
opted for simplicity by making base types values and objects references.
There is no confusion on copies and compares -- for base types, they are
always value-based; for objects, they are always reference-based (shallow).
They chose not to support operator overloading for the same reason.
Unfortunately, the fact that there are no user-defined value-types (you
can't pass an object by value) makes Java too inefficient for many scientific
applications. (complex numbers, etc.)
--
Paul Hepworth
James W. Howe
One of the things I find the most annoying about Java is the fact that
it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
immense pain to have to deal with converting certain items from
objects to datatypes and back again. For example, adding integer
values to a Vector involves converting an int into an Integer. If you
want to do any work with the value, you have to extract the value out
of the object. It would have been so much easier to simply have the
object understand arithmetic constructs and not have the datatype at
all.
Brian Rogoff
D'Arcy Smith <DSm...@symantec.com> writes:
James W. Howe wrote:
>
> One of the things I find the most annoying about Java is the fact that
> it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
> the language designers simply use Objects for everything?
Speed and efficiency.
There are tradoffs for everything - the designers felt speed would
be better than simplicity or orthogony I suppose.
The designers fucked up bigtime in this case. User defined value classes,
with the basic types being the built-in value classes of Java, would have
provided speed (value classes need not be heap allocated), are relatively
simple, and orthogonality (every object is a class instance). Eiffel also
had a lame approach like Java had with basic types, until "expanded" classes
were adopted. It isn't too late to fix this, but I doubt Sun will do it...
-- Brian
James W. Howe
db...@shvn.com (Doug Bell) wrote:
>j...@allencreek.com wrote:
>
>> D'Arcy Smith <DSm...@symantec.com> wrote:
>>
>> >James W. Howe wrote:
>> >>
>> >> One of the things I find the most annoying about Java is the fact that
>> >> it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
>> >> the language designers simply use Objects for everything?
>> >
>> >Speed and efficiency.
>> >[...]
>>
>> [...]
>> Creating a confusing language based on speed criteria is simply short
>> sighted.
>> [...]
>
>I guess it's all a matter of perspective about what's confusing. I'm not
>sure I would find having to declare:
>
>int i = new int(5);
>
>instead of simply
>
>int i = 5;
>
If the compiler were implemented correctly you wouldn't have to. The
compiler would recognize that 5 was an object and simply assign it to
i, just the way String works.
>Also, if every int is an object, then it is a reference, which takes up
>space in addition to the now dynamically allocated int, which must be
>dereferenced to get at the value.
Again not true. The object pointer could simply contain the real
integer value. No dereferencing is needed and no additional syntax is
required. For example, in Smalltalk the following is perfectly valid
code:
| index |
index := 1.
index := index + 1.
bar := foo at: index. "assign the value found at the index location
if foo to bar"
>
>Due to it's interpretted nature, Java already has a performance deficit to
>make up, but at least JIT compilers offer a solution. I'm not sure how
>you overcome the performance and memory deficit that eliminating simple
>types would create, unless you require a runtime library on the order of
>size of what you get with Smalltalk. IMO it would have been a major
>mistake to *not* include basic data types.
>
As someone else pointed out, the runtime library in Smalltalk is not
large because it has all objects instead of datatypes and objects. The
library is large because it contains a wealth of useful classes which
are omitted from Java.
Chris Dollin
db...@shvn.com (Doug Bell) writes:
j...@allencreek.com wrote:
> D'Arcy Smith <DSm...@symantec.com> wrote:
>
> >James W. Howe wrote:
> >>
> >> One of the things I find the most annoying about Java is the fact that
> >> it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
> >> the language designers simply use Objects for everything?
> >
> >Speed and efficiency.
> >
> >There are tradoffs for everything - the designers felt speed would
> >be better than simplicity or orthogony I suppose.
> >
>
> If that's true then I believe they have made a major mistake.
> Machines, compilers, etc. will only get faster. Creating a confusing
> language based on speed criteria is simply short sighted. I can't
> believe that having true objects would have made a significant
> difference in execution speed. Oh well.
I guess it's all a matter of perspective about what's confusing. I'm not
sure I would find having to declare:
int i = new int(5);
instead of simply
int i = 5;
That's simply syntax; there would be no problem supporting it. (Indeed ``5''
ould simply denote an object.)
Also, if every int is an object, then it is a reference, which takes up
space in addition to the now dynamically allocated int, which must be
dereferenced to get at the value.
Not at all; if they hadn't been so explicit about integers being 32 bits
wide, you could steal a couple of bits as a tag. This is a common trick in
Lisp implementations, for example. An object reference is then either a
pointer, an integer, perhaps one of a small set of special values (such
as true, fasle, or nil), and maybe a short floating-point number.
There are trade-offs of course, but this one seems to work pretty well.
Consider if I have an int[] which contains image data. Is this stored
with each element in the array being a reference to a pixel of image
data? How much larger is this than a simple array of int? How much
slower for image processing? How well does this mess with the underlying
OS and the ImagePeer classes?
And of course arrays of integers can tag their contents, or not, as they
choose. (This is especially useful if the language has bignums as well).
Due to it's interpretted nature, Java
*current implementations of* Java
already has a performance deficit to make up, but at least JIT
... or indeed conventional batch ...
compilers offer a solution. I'm not sure how you overcome the performance
and memory deficit that eliminating simple types would create,
unless you require a runtime library on the order of
size of what you get with Smalltalk.
The Smalltalk runtime is not large on account of its handling of basic types.
IMO it would have been a major mistake to *not* include basic data types.
The question is whether they could have been represented as objects.
--
Regards, | ``"I can't suit myself," said Weinbaum, a little petulantly.
Kers. | "I work for the Government".'' - Blish, "The Quincunx of Time".
James W. Howe
rog...@sccm.Stanford.EDU (Brian Rogoff) wrote:
>D'Arcy Smith <DSm...@symantec.com> writes:
> James W. Howe wrote:
> >
> > One of the things I find the most annoying about Java is the fact that
> > it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
> > the language designers simply use Objects for everything?
>
> Speed and efficiency.
>
> There are tradoffs for everything - the designers felt speed would
> be better than simplicity or orthogony I suppose.
>
>The designers fucked up bigtime in this case. User defined value classes,
>with the basic types being the built-in value classes of Java, would have
>provided speed (value classes need not be heap allocated), are relatively
>simple, and orthogonality (every object is a class instance). Eiffel also
>had a lame approach like Java had with basic types, until "expanded" classes
>were adopted. It isn't too late to fix this, but I doubt Sun will do it...
>
Who knows, maybe Sun is hard at work on 'Object Java' which will turn
Java into a real object-oriented language. <g>
D'Arcy Smith
Paul Hepworth wrote:
> I, too object to the fact that base types are not objects.
> However, it was not (just) for speed/efficiency. Notice that objects
> are ALWAYS passed by reference whereas the base types are passed by value.
Actualy the Object REFERENCE is passed by value.
:-)
Tom Harrington
James W. Howe (j...@allencreek.com) wrote:
: One of the things I find the most annoying about Java is the fact that
: it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
: immense pain to have to deal with converting certain items from
: objects to datatypes and back again. For example, adding integer
: values to a Vector involves converting an int into an Integer. If you
: want to do any work with the value, you have to extract the value out
: of the object. It would have been so much easier to simply have the
: object understand arithmetic constructs and not have the datatype at
: all.
I tend to disagree. However, that's not really important. What's
important is that, if it bothers you, you could easily implement
your own version of the Integer class that would work the way you
want it to. You don't have to use Sun's Integer class if you
don't like it; roll your own.
--
Tom Harrington ------- t...@rmii.com ------- http://rainbow.rmii.com/~tph
"You will someday thank us for saving your mind."
-The Book of the SubGenius
-> Fractal Kit: http://rainbow.rmii.com/~tph/fractalkit/fractal.html <-
Peter Sulc
In article <31eab469.456313727@gustav>,
James W. Howe <j...@allencreek.com> wrote:
>D'Arcy Smith <DSm...@symantec.com> wrote:
>
>>James W. Howe wrote:
>>>
>>> One of the things I find the most annoying about Java is the fact that
>>> it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
>>> the language designers simply use Objects for everything?
>>
>>
>>There are tradoffs for everything - the designers felt speed would
>>be better than simplicity or orthogony I suppose.
>>
>
>Machines, compilers, etc. will only get faster. Creating a confusing
>language based on speed criteria is simply short sighted. I can't
>believe that having true objects would have made a significant
>difference in execution speed. Oh well.
>
I disagree. I like the fact that the language I use can be optimized
by me algorithmically at a level close enough to assembly that I
might only get marginally better performance if I wrote it in
assembly. There are, in any perfomance intensive application, critical
sections of code that benefit tremendously by optimizations. So when
your marketing guy/gal goes head to head against the competition, and
your app kicks a**, you may be putting some "Object purist" out of
work because there product won't sell. The flip side, of course, is
that the object purist can add really cool features much faster than
you because they have "pure" and therefore predictable and consistent
design so they don't write crap no one can understand besides the
author. Seems to me that something like Java (if a real compiler ever
emerges) or C++ (probably more so) can satisfy both desires.
Peter Sulc
In article <4sh3cm$e...@eccdb1.pms.ford.com>,
Tom Harrington <t...@rmii.com> wrote:
>James W. Howe (j...@allencreek.com) wrote:
>: One of the things I find the most annoying about Java is the fact that
>: it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
>: immense pain to have to deal with converting certain items from
>: objects to datatypes and back again. For example, adding integer
>: values to a Vector involves converting an int into an Integer. If you
>: want to do any work with the value, you have to extract the value out
>: of the object. It would have been so much easier to simply have the
>: object understand arithmetic constructs and not have the datatype at
>: all.
>
>I tend to disagree. However, that's not really important. What's
>important is that, if it bothers you, you could easily implement
>your own version of the Integer class that would work the way you
>want it to. You don't have to use Sun's Integer class if you
>don't like it; roll your own.
>
>--
>Tom Harrington ------- t...@rmii.com ------- http://rainbow.rmii.com/~tph
> "You will someday thank us for saving your mind."
> -The Book of the SubGenius
>-> Fractal Kit: http://rainbow.rmii.com/~tph/fractalkit/fractal.html <-
Not so!
Java architects decided *not* to implement operator overloading ...
eccpt for the f**king String class ... so your Int class necessarily
must blow chow.
Please Sun. Rethink that. Revisit the operator overloading question.
Hank Shiffman
In article <31eab469.456313727@gustav>, j...@allencreek.com writes:
> D'Arcy Smith <DSm...@symantec.com> wrote:
>
> >James W. Howe wrote:
> >>
> >> One of the things I find the most annoying about Java is the fact that
> >> it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
> >> the language designers simply use Objects for everything?
> >
> >Speed and efficiency.
> >
> >There are tradoffs for everything - the designers felt speed would
> >be better than simplicity or orthogony I suppose.
> >
>
> If that's true then I believe they have made a major mistake.
> Machines, compilers, etc. will only get faster. Creating a confusing
> language based on speed criteria is simply short sighted. I can't
> believe that having true objects would have made a significant
> difference in execution speed.
I can. There are several distinctions in the language between data
types and objects. The one that I suspect has the biggest impact on
performance is that data types are stored in place and objects are
created on the heap and linked to by pointers. To treat data types
as objects would mean that every int or short would involve following
a pointer (or a Lisp Machine technique of a tagged pointer to
distinguish between immediate data and real pointers). It also means
that a lot more objects would be created, which means more work for
the garbage collector.
The reason that just-in-time compilers produce performance that's close
to C for numerical codes is that their data representations are so
similar that most of the overhead can be reduced. Giving numeric types
the flexibility of objects also means giving them the overhead. (It
also gives programmers the fun if distinguishing among the many different
kinds of tests for equality that Lisp programmers know and love: are two
objects the same object, or do they point to the same object or do they
look the same or do they have the same value?)
--
Hank Shiffman shif...@sgi.com
RapidApp Product Manager phone: 415-933-2330
Silicon Graphics Computer Systems fax: 415-969-6327
SGI internal: http://slappy.engr/~shiffman
External: http://reality.sgi.com/shiffman
James W. Howe
t...@oddjob.uucp (Tom Harrington) wrote:
>James W. Howe (j...@allencreek.com) wrote:
>: One of the things I find the most annoying about Java is the fact that
>: it has datatypes (i.e. int, boolean, etc.) and Objects.
>: [...]
>: It would have been so much easier to simply have the
>: object understand arithmetic constructs and not have the datatype at
>: all.
>
>I tend to disagree. However, that's not really important. What's
>important is that, if it bothers you, you could easily implement
>your own version of the Integer class that would work the way you
>want it to. You don't have to use Sun's Integer class if you
>don't like it; roll your own.
Unfortunately this isn't true in any practical sense because Java
lacks the ability to define unary messages (aka operator overloading).
I could define my own integer class, but I would be forced to write
'wordy' method names instead of being able to use commonly used
symbols (i.e. +, -, /, <, >, etc.). If I had the ablity to define
unary messages AND had the ability to tell the compiler to use my
objects when it encountered numeric values, I wouldn't complain too
much about Java's lack of orthoganality.
James W. Howe
ps...@nyx10.cs.du.edu (Peter Sulc) wrote:
>In article <31eab469.456313727@gustav>,
>James W. Howe <j...@allencreek.com> wrote:
>>D'Arcy Smith <DSm...@symantec.com> wrote:
>>
>>>James W. Howe wrote:
>>>>
>>>> One of the things I find the most annoying about Java is the fact that
>>>> it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
>>>> the language designers simply use Objects for everything?
>>>
>>>Speed and efficiency.
>>>
>>If that's true then I believe they have made a major mistake. [...]
>
>I disagree. I like the fact that the language I use can be optimized
>by me algorithmically at a level close enough to assembly that I
>might only get marginally better performance if I wrote it in
>assembly.
>
>[...]
It is certainly beneficial for a language to allow for algorithmic
optimization when necessary. However, premature optimization is never
a good idea. The Java language designers have prematurely optimized
things by creating a two level language which has some things which
are objects and some things which are not. The proper way to handle
optimization is to let the user create primitive (aka native)
implementations for areas of code which need high performance. This
keeps the language consistent and understandable, but still gives the
developer the opportunity to make optimizations where necessary and
appropriate.
David James Hanley
James W. Howe (j...@allencreek.com) wrote:
: It is certainly beneficial for a language to allow for algorithmic
: optimization when necessary. However, premature optimization is never
: a good idea. The Java language designers have prematurely optimized
: things by creating a two level language which has some things which
: are objects and some things which are not. The proper way to handle
: optimization is to let the user create primitive (aka native)
: implementations for areas of code which need high performance.
Ack! This is an absolutely awful soloution! Do you feel
that a project implemented in mixed languiage for performance
critical soloutions is a understandable soloution? Do you feel
that the platform independence lost is worth it? I sure don't.
Java has the potential to be as fast as "C" while being very easy
to understand as well.
--
------------------------------------------------------------------------------
David Hanley, |______ Computer Science graduate student.
dha...@lac.eecs.uic.edu |\ ___/__ Martial Artist. Biker. Chess Freak
www_lac.eecs.uic.edu/~dhanley/| \\ / / Libertarian. Atheist. Bisexual.
My employer barely KNOWS me. | \/BI/ Aspiring novelist.Joyce Kafka Neitzsche
-----------------------------------\/-----------------------------------------
DO NOT TAUNT happy fun ball.
Frank Teusink
ps...@nyx10.cs.du.edu (Peter Sulc) writes:
>Not so!
>Java architects decided *not* to implement operator overloading ...
>eccpt for the f**king String class ... so your Int class necessarily
>must blow chow.
>Please Sun. Rethink that. Revisit the operator overloading question.
Yes. Let's get back to the overloading issue. It is much more
important.
I WANT OPERATOR OVERLOADING (or I'll start bombing Silicon Valley)
(c:
Cheers,
Frank (in a silly mood)
--
Frank Teusink CWI
email: fra...@cwi.nl P.O.Box 94079
tel: +31 20 592 4075 1090 GB Amsterdam
fax +31 20 592 4199 The Netherlands
Chris Dollin
shif...@slappy.engr.sgi.com (Hank Shiffman) writes:
In article <31eab469.456313727@gustav>, j...@allencreek.com writes:
> D'Arcy Smith <DSm...@symantec.com> wrote:
>
> >James W. Howe wrote:
> >>
> >> One of the things I find the most annoying about Java is the fact that
> >> it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
> >> the language designers simply use Objects for everything?
> >
> >Speed and efficiency.
> >
> >There are tradoffs for everything - the designers felt speed would
> >be better than simplicity or orthogony I suppose.
> >
>
> If that's true then I believe they have made a major mistake.
> Machines, compilers, etc. will only get faster. Creating a confusing
> language based on speed criteria is simply short sighted. I can't
> believe that having true objects would have made a significant
> difference in execution speed.
I can. There are several distinctions in the language between data
types and objects. The one that I suspect has the biggest impact on
performance is that data types are stored in place and objects are
created on the heap and linked to by pointers. To treat data types
as objects would mean that every int or short would involve following
a pointer (or a Lisp Machine technique of a tagged pointer to
distinguish between immediate data and real pointers).
Yes; what problems do you see with this approach?
It also means that a lot more objects would be created, which means more
work for the garbage collector.
If the premise were true, the conclusion might follow.
The reason that just-in-time compilers produce performance that's close
to C for numerical codes is that their data representations are so
similar that most of the overhead can be reduced. Giving numeric types
the flexibility of objects also means giving them the overhead. (It
also gives programmers the fun if distinguishing among the many different
kinds of tests for equality that Lisp programmers know and love: are two
objects the same object, or do they point to the same object or do they
look the same or do they have the same value?)
These problems are already there in Java for non-basic types. Also they're
``real'' problems; the language can't wish them away, as the distinction
between identity and equality is important in any imperative language and,
I think, absolutely fundamental in any ``object-oriented'' one.
Nelson Gallash
> > If that's true then I believe they have made a major mistake.
> > Machines, compilers, etc. will only get faster. Creating a confusing
> > language based on speed criteria is simply short sighted. I can't
> > believe that having true objects would have made a significant
To take an apposing view I think the belief that launguages can be
inefficient because the machines will be faster is naive. I don't care how
fast a machine or compiler gets speed will always be a criteria in
programming. Why? Because people will always demand more and
companies/programmers to stay ahead will have to deliver.
Basic economics and programmer's pride all rolled into one.
Mellow
Nelson
James F'jord Lynn
>lacks the ability to define unary messages (aka operator overloading).
>I could define my own integer class, but I would be forced to write
>'wordy' method names instead of being able to use commonly used
>symbols (i.e. +, -, /, <, >, etc.). If I had the ablity to define
>unary messages AND had the ability to tell the compiler to use my
>objects when it encountered numeric values, I wouldn't complain too
>much about Java's lack of orthoganality.
So then design a language and implement a compiler that does this and
compiles to Java. I see no problems with this as far as the VM goes. And
if you truely believe that other people want this solution as well, you could
make a quite a bit of money off of it.
>
>James W. Howe internet: j...@allencreek.com
>Allen Creek Software, Inc.
>Ann Arbor, MI 48103
--
Life - F'jord of Timelord, James Lynn
Java - http://www.undergrad.math.uwaterloo.ca/~j2lynn/java.html <NEW LOCATION>
SuperButton v1.1, SuperApplet v1.0, MessageBox v1.0.1 available there
Chris Dollin
In article <TMB.96Ju...@best.best.com> t...@best.com (--) writes:
In ... ke...@hplb.hpl.hp.com (Chris Dollin) writes:
Also, if every int is an object, then it is a reference, which takes up
space in addition to the now dynamically allocated int, which must be
dereferenced to get at the value.
Not at all; if they hadn't been so explicit about integers being 32 bits
wide, you could steal a couple of bits as a tag. This is a common trick in
Lisp implementations, for example. An object reference is then either a
pointer, an integer, perhaps one of a small set of special values (such
as true, fasle, or nil), and maybe a short floating-point number.
There are trade-offs of course, but this one seems to work pretty well.
Actually, for a general purpose programming language, it's a bad
crutch. You need by-value types that are larger than pointers,
This is an interesting claim; would you like to expand on it? (I can
see potential efficiency issues, but I don't know if that's what you're
referring to.) I've got along quite happily in Pop11 (which, for these
purposes, is much the same as Lisp) with no by-value types, sticking in
the odd thing.copy when required; is it a question of style or application
domain?
[Since I'm in the middle of revising my own grandson-of-Pop language even
as we speak, this would be a good time for me to reconsider adding
value types; at the moment I can see no reason to do so, but then the
real reason for building Cayenne is to give *me* a pleasant programming
environment.]
Chris Dollin
Like all designs, Java is a compromise, and as far as compromises go,
it's a pretty useful one between performance, simplicity, and
expressiveness. I have yet to see a language that treats numbers as
full objects and achieves good performance on them.
Well, given that Java has a static typing system, wouldn't a tagged
scheme for integers still give good performance? [I'm assuming here a
``low two bits => integer'' scheme which allows addition and subtraction
to use machine instructions. There's a little loss on multiplication
and division, of course, but they're rarer and more expensive anyway.
I think. Of course if there are subclasses of such integers then many
bets will be off, but I think the subtyping goes the other way -- integers
are a subtype of bignums, etc. Small floats are another issue; with
modern fp performance being so close to integer, the tag-stripping needed
for float arithmetic *even when statically typed* becomes a problem.]
The proper way to handle optimization is to let the user create
primitive (aka native) implementations for areas of code which need
high performance.
I personally think replacing a relatively simple and common
distinction between numbers and objects with a platform dependent,
unsafe foreign function interface is throwing out the baby with the
bathwater, but if that's what you like, there are dozens of languages
that will cater to your taste.
In this I agree with you in general, although I can see that there'd
be programs for which this *might* be the best compromise for blazingly
fast performance.
Brian Rogoff
ke...@hplb.hpl.hp.com (Chris Dollin) writes:
In article <TMB.96Ju...@best.best.com> t...@best.com (--) writes:
crutch. You need by-value types that are larger than pointers,
This is an interesting claim; would you like to expand on it? (I can
see potential efficiency issues, but I don't know if that's what you're
referring to.) I've got along quite happily in Pop11 (which, for these
purposes, is much the same as Lisp) with no by-value types, sticking in
the odd thing.copy when required; is it a question of style or application
domain?
The efficiency reason is primary IMO, and catering to this efficiency concern
by creating a special, *non-extensible* set of value types is a common hack
of language design. So in Java (and BETA, and Eiffel (<3 I think), and ...)
the first user that wants to build a Matrix of type Complex (gee, no one would
want to do that!) or some other such structure has to resort to the heap
allocated types of the language and hope that compilers will eventually inline
the code or ditch the language for the kind of work that requires high
performance.
-- Brian
Matt Kennel
Chris Dollin (ke...@hplb.hpl.hp.com) wrote:
: I can. There are several distinctions in the language between data
: types and objects. The one that I suspect has the biggest impact on
: performance is that data types are stored in place and objects are
: created on the heap and linked to by pointers. To treat data types
: as objects would mean that every int or short would involve following
: a pointer (or a Lisp Machine technique of a tagged pointer to
: distinguish between immediate data and real pointers).
: Yes; what problems do you see with this approach?
: It also means that a lot more objects would be created, which means more
: work for the garbage collector.
: If the premise were true, the conclusion might follow.
: The reason that just-in-time compilers produce performance that's close
: to C for numerical codes is that their data representations are so
: similar that most of the overhead can be reduced. Giving numeric types
: the flexibility of objects also means giving them the overhead. (It
: also gives programmers the fun if distinguishing among the many different
: kinds of tests for equality that Lisp programmers know and love: are two
: objects the same object, or do they point to the same object or do they
: look the same or do they have the same value?)
: These problems are already there in Java for non-basic types. Also they're
: ``real'' problems; the language can't wish them away, as the distinction
: between identity and equality is important in any imperative language and,
: I think, absolutely fundamental in any ``object-oriented'' one.
Yes the distiction is fundamental but the Java designers still muffed it.
Yet again, see
http://www.icsi.berkeley.edu/Sather
for a superior solution.
Yes I use it all the time for numerically intensive computations.
: --
: Regards, | ``"I can't suit myself," said Weinbaum, a little petulantly.
: Kers. | "I work for the Government".'' - Blish, "The Quincunx of Time".
--
Matthew B. Kennel/m...@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
*NO MASS EMAIL SPAM* It's an abuse of Federal Government computer resources
and an affront to common civility. On account of egregiously vile spamation,
my software terminates all email from "interramp.com" and "cris.com" without
human intervention.
Matt Kennel
D'Arcy Smith (DSm...@symantec.com) wrote:
: James W. Howe wrote:
: >
: > One of the things I find the most annoying about Java is the fact that
: > it has datatypes (i.e. int, boolean, etc.) and Objects. Why didn't
: > the language designers simply use Objects for everything?
: Speed and efficiency.
: There are tradoffs for everything - the designers felt speed would
: be better than simplicity or orthogony I suppose.
The real reason is that the Java designers were not clever enough figure it
out on their own and not wise enough to consult existing practice.
The two needs can be easily accomodated if you introduce the notion of
value vs reference classes like Sather and Eiffel. The distinction
concerns the meaning of assignment and reference and aliasing,
but still everything can be put inside one nice coherent typesystem.
And you get high speed, and real orthogonality, and so on and so on.
It also means you should be able to have user-defined value types too.
I understand the pressures of 'get something out now' but at least they
could have desgined for the future, even if "The only value types
are the built in int, boolean, char et cetera; the ability to define
new ones will come in a later version of the language."
Bottom line, they fucked up.
: --
: D'Arcy Smith
: Symantec
--
Scott Wheeler
In Article <ROGOFF.96J...@sccm.Stanford.EDU> Brian Rogoff
writes:
>The efficiency reason is primary IMO, and catering to this efficiency
>concern by creating a special, *non-extensible* set of value types is
>a common hack of language design. So in Java (and BETA, and Eiffel (<3
>I think), and ...) the first user that wants to build a Matrix of type
>Complex (gee, no one would want to do that!) or some other such
>structure has to resort to the heap allocated types of the language
>and hope that compilers will eventually inline the code or ditch the
>language for the kind of work that requires high performance.
Eiffel has user-defined value types.
Scott
Paul Houle
I don't think it's that bad. If one is clever about using arrays
one can implement such beasts as Complex Matrices very efficiently. The
trick is that you ~don't~ define a type Complex and then make a Vector
of Vectors of Complex. I mean, you can do that, it will be very easy
to understand and very pedagogical, but performance will be awful.
Instead you have to implement a matrix class that has a nice
interface but an ~awful~ representation inside. Such as two
one-dimensional
arrays...
I've been thinking about doing scientific programming in Java and
I've come to see it is like using Matlab or IDL -- if you are clever in
the way you use them you can get very reasonable performance; using
endogenous matrix types and so forth. If you decide to write a loop in
the interpreter that iterates 50 million times, you deserve what you
get.
Since Java lets one define classes that hide implementation, it
seems to me that it would not be hard at all to make a few matrix
classes.
You might have GenericComplexMatrix which is written in java and is
portable everywhere -- you ship that with your applets. When you're
doing
~big~ calculations, you use AIX4.1_ComplexMatrix which uses native
method
calls to run fast matrix code in FORTRAN.
==========================================================================
Paul Houle ph...@cornell.edu
http://www.msc.cornell.edu/~houle
Physics of paper crumpling:
http://www.msc.cornell.edu/~houle/crumpling/
Hysteresis applet:
http://www.msc.cornell.edu/~houle/hysteresis/
The truth about the NC:
http://www.msc.cornell.edu/~houle/web/nc.html
==========================================================================
Peter Froehlich
Hi!
m...@caffeine.engr.utk.edu (Matt Kennel) wrote:
> The two needs can be easily accomodated if you introduce the notion of
> value vs reference classes like Sather and Eiffel. The distinction
> concerns the meaning of assignment and reference and aliasing,
> but still everything can be put inside one nice coherent typesystem.
>
> And you get high speed, and real orthogonality, and so on and so on.
>
> It also means you should be able to have user-defined value types too.
Okay, seperating into value (expanded) and reference ("normal") classes
might solve that problem, but are you really trying to say that it does not
introduce *other* problems, e.g. for dynamic binding?
Besides, the tone of your mail seems to indicate some weird hatred
against JAVA. Why's that then? If it's so bad, just don't use it...
_
By(T)e... /| _ //3000 /\ People who use Pascal for serious programming |\
Peter... \| \X/\miga \/ fall into a fatal trap. (Brian W. Kernighan) |/
David Engberg
java.awt.Container.locate() is currently unusable because it relies on
java.awt.Component.inside() to determine whether a point is inside of a
child. The reason this fails is that each of these operations
performs
the translation from the parent's coordinate system to the child's.
Unfortunately, this duplication means that the translation happens
twice, and the 'location' of the of components is perceived to be off
by some proportionate amount.
This bug spills over into other parts of the AWT as well ... for
example, deliverEvent() will never work correctly.
Marty Hall
In article <3202490A...@eecs.com> David Engberg <gepp...@eecs.com> writes:
>java.awt.Container.locate() is currently unusable because it relies on
>java.awt.Component.inside() to determine whether a point is inside of a
>child. The reason this fails is that each of these operations
>performs
>the translation from the parent's coordinate system to the child's.
>
>Unfortunately, this duplication means that the translation happens
>twice, and the 'location' of the of components is perceived to be off
>by some proportionate amount.
I don't think this is broken in general, just in Netscape (at least as
of 2.02). It works properly in applications from JDK 1.02 as well as
via appletviewer from JDK 1.02.
- Marty
Java Programming Resources: <http://www.apl.jhu.edu/~hall/java/>