Re: Java blunders
On 7/22/2014 2:41 PM, Roedy Green wrote:
I have composed an essay about what I consider were the blunders in
the design of Java. I hold out hope many of them will eventually be
fixed. You might like to add to the list.
see http://mindprod.com/jgloss/javablunders.html
# byte is signed. You almost never want a signed byte. Further,
# there is no unsigned byte. ubyte would be trivial to implement. It
# would require no changes to the JVM (Java Virtual Machine). It would
# catch all manner of bugs forgetting to do & 0xff after a byte load.
I completely agree.
# for each requires you to specify the type of the indexing
# variable. The compiler knows that from the type of the set it
# iterates over. This means needlessly propagating type information in
# more than one place in your program.
# You should be able to declare a temporary variable as having the same
# type as some other variable, so that for example if the original
# variable changes from int to long, the temporary will automatically
# change too.
You are really asking for the ability to use var/val and let the compiler
determine the type via type interference.
That is quite popular in languages today.
It could certainly be added to Java.
But I am so conservative that I think it would go against some
core Java principles.
# Java overuses {}. If you drop a } you can spend 15 minutes trying to
# get them balanced again. If methods, classes, loops, etc had unique
# end markers, there would be no problem. If methods, classes, loops
# etc had unique visual markers at begin and end, (perhaps small icons
# generated on the fly by the IDE (Integrated Development
# Environment)), code would be much easier to read and scan.
There are languages that use:
if ... end if
for ... end for
while ... end for
record ... end record
class ... end class
function ... end function
procedure ... end procedure
etc.
And I actually like that syntax.
But this can not be changed in Java without creating total
confusion.
Next language!
# Java uses + for both concatenation and addition. The ambiguity leads
# to all kinds of strange bugs.
Really?
That is not my impression.
You should be able to have arrays of Objects, not just arrays of
> references to Objects so you could do an efficient Complex class.
You are asking for value types.
It could be added.
But it is a big chunk of complexity to add.
And I somewhat question whether the benefits are big enough
to outweigh the complexity.
Arne