Hacker News new | past | comments | ask | show | jobs | submit login
Complaints I'm Seeing About Java (dlweinreb.wordpress.com)
10 points by mqt on Dec 10, 2007 | hide | past | favorite | 20 comments



I have been programming with Java for several years now, I have professional experience with C, C++, Smalltalk and Perl.

From this list I would like to have this: - A short cut syntax to declare getters and setters. - A shorter syntax to use "functions as objects". - Easier to use stream classes.


I also get tired of auto-generating getter/setters all the time. I think annotations to designate getters/setters would be easy and fit in nicely. No need to invent new class "properties" to complicate things.


How about code blocks and yield? I recently started learning Ruby, and this has been one of the first major transitions in how I write code (after programming in Java for several years).


Any pratical application for yield that you couldn't do just as simply with a for loop? I'm not criticizing, I'm just curious.


Well, I can't guarantee that this is was a good use of block and yield, or even if it was advisable, but here's what I did one time...

I needed to construct a bunch of polynomials from a set of 20 odd coordinates (x,y) coordinates. I decided to use langrange interpolating polynomials, and I wanted the polynomial to match three of the twenty points (otherwise they bounce all over the place). The idea was then to select the polynomial that minimized the least squares difference with the other points that weren't used to create the curve(I'm not sure if this counts as practical, since there are other approaches to polynomial curve-fitting that would have been more appropriate). Anyway, I had a method that evaluated the least squares, and then I constructed the polynomial as a block of code and yielded to it in the iteration that evaulated all the point for the least-squares fit...

There are other ways to do it (always are) - I could have broken the polynomials into terms and reconstructed them in the method, for instance - but block and yield were very convenient in this case.


One complaint I've always had that no one else seems to bring up: I can't take a flat array of bytes and map a struct over it. You have to fake that out in the most lamentable way...

I guess most people don't need to do that anymore.


It's also annoying that there aren't any unsigned (primitive) data types in Java. You end up doing weird bitwise operations to get the correct results.

for example, to convert an unsigned byte to an integer:

    byte a = (some unsigned byte data);
    int b = 0xff & a;


I guess you are right, because I don't even understand what you mean?


He wants fine control over memory allocation.

Most people who want that much control use C or C++.


struct MyStruct { int a; } ;

char bytes[]={0,1,0,0};

MyStruct *myStruct=((MyStruct [asterisk] )bytes);

...myStruct->a is now 256.

How do you format code here?


I see - I am glad that Java does not support that ;-)

Presumably what you want can be achieved with ByteArrayInputStream and DataInputStream.

    byte[] bytes = {0,1,0,0};
    DataInputStream in = new DataInputStream(new ByteArrayInputStream(bytes));
    int a = in.readInt();
    in.close();
untested, but something like that... There is also object serialization. I never had a use case for what you describe.

(format code with 4 leading spaces)


object serialization is horribly inefficient in java.


Guess how many CPU cycles my C code requires.


What time sensitive operation requires you to transform byte arrays into objects? I assumed something like reading from disk or network, and then CPU cycles are usually not the bottleneck.

Anyway, no doubt that you can write faster code in C, but I am glad that I did not have to look at pointer arithmetic for the last 8 years. Using your array->struct technique would be a major headache if the struct get's more complex.


There are plenty of other practical use cases for this kind of control. For example, casting an array of byte[]s to an array of int[]s. It's not hard to convert using a ByteBuffer, but its still annoying. You and up duplicating a ton of memory for no good reason.


You're assuming a 32-bit little-endian system.

Indent at least two spaces for code.


Woa, I just had a year 2000 flashback!


Way to stick your head deeper into the sand!


Considering how Dan Weinreb is one of the designers of Common Lisp, perhaps it is not he who is narrow minded.


Uhm, so what? It's not like he's infallible. His comments on why Java's misunderstood are silly! Judge the man by what he says, not by his past reputation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: