Re: Java blunders
On 7/23/2014 2:26 PM, taqmcg@gmail.com wrote:
You might like to add to the list.
Here are a few possibly idiosyncratic issues I have. I don't anticipate that any except the last could conceivably be implemented.
- Integer promotion of byte, short and char types: This really aggravates the problem of bytes being signed. I've had to clear sign-extensions from promoted bytes or shorts countless times. The semi-supported status of these types has lots of ramifications. The special rules for x += y; where x is a byte and y is an integer is just one.
As with C before it, this is a concession to the underlying
hardware. Machines capable of 8-bit arithmetic exist, but nowadays
are found in microcontrollers and the like rather than in servers,
desktops, tablets, and phones. The architectural tendency has been
to move away from memory-to-memory arithmetic and toward a style of
load-operate-store -- and when you load a "narrow" value into a
"wide" register, you can't just leave the other bits in a state
that's neither one nor zero!
I'll also take issue with your use of "semi-supported:" Can you
find a Java implementation anywhere, even one implementation, on
which these operations are *not* supported as described in the JLS?
- The vast mess that is Java IO and NIO with a myriad of classes that do almost the same thing. Streams and Readers and Channels and RandomAccessFile off on its own, and Buffers and Formatters and Charsets and Selectors and .... My suspicion is the the underlying problem here is that we've decided that I/O somehow is read out of the language itself -- it's an add-on library. Doing I/O is critical to essentially all programs but thinking that some syntax beyond method calls might be useful in making what how program does I/O clear is beyond the pale. I suspect that the desire to support printf-like calls was one of the big drivers for variable length argument lists but that's not even scratching the surface.
The class libraries testify to the fact that their designers had
not yet read "Effective Java" or gained comparable experience. Of
course, they would have to have been unusually prescient to do so ...
- Statements with side effects: This infection has been virally grafted into core genes of many C-based languages. While the ability to do
a += b;
is a tremendous boon and quite clear, the added benefit of
a += b += c;
versus
b += c;
a += b;
is lost to me. The first suggests the wrong order. The second is clear and
unambiguous.
Seems clear enough to me -- although I can't recall, off-hand, a
situation where I'd have found the construct useful. I think it's
more of a gotcha question for a snarky Java exam than something that
would arise much in practice.
More broadly: Java is an imperative language. In an imperative
framework it's hard to see how one could manage without side-effects:
No assignments, no methods that modify Collections, no I/O ... I guess
a language that did none of these things could compute, in a fashion,
but I'm not sure how you could prove that it had done so.
The prime vector in this contagion are the increment and decrement operators, which I completely eschew. (I use x += 1 or x -= 1 instead). So increments, decrements and assignments should (imho) be statements, not values.
De gustibus non disputandum est. Java syntax is pretty obese
already; anything that liposuctions even a little fat away is something
I applaud.
4. The switch statement. The problems with fall through have already been noted, but it also seems silly that switches are restricted to a limited set of
types. One should be able to switch on any value: String, double, Objects, enumerations .... Just use == [for primitives] or equals() [for objects] to find the appropriate case. Sometimes this is just syntactic sugar for a
nested if, but that's fine. The nested if's hide the constraints, while a switch can be much clearer. I don't see why the compiler can't easily optimize the integer and enumeration switches but leave the language more powerful and simpler (i.e., there are fewer special cases).
IMHO Java would be a better language if `switch' were removed
altogether, fall-through or not. But that's just MHO, which (clearly)
is not widely shared. Meanwhile, I oppose anything that encourages
the use of the construct.
Just a few of my pet peeves.
Here's one I haven't seen mentioned yet: I think the precedence
of `instanceof' w.r.t. `!' is wrong:
// What I want:
if (! thing instanceof T) // if it's not a "T" ...
// What I must write instead:
if (!(thing instanceof T)) // if it's false that it's a "T" ...
Anybody else?
--
esosman@comcast-dot-net.invalid