Hi, this is the original author. You sent me an email asking me to respond so I will.
> Are we using the same Java?
No, I originally wrote the article back in 2008 or so.
>> GC Sucks So Badly, That You Should Avoid Using Memory
> I'm assuming this is from before Java 8. The latest GC algorithms don't do this.
AFAIK people still complain about the GC. I've noticed that more modern languages don't have advanced GC like Java's.
>> Worst of Exceptions and Value Checking
> Sometimes the correct thing to do is to throw an exception and other times it is to return a sensable value. An exception is an unrecoverable state, a null is a sensable value for when nothing exists. Something not existing and an unrecoverable state are two very different things.
I rarely deal in absolutes when I'm coding. It's all about engineering tradeoffs.
It's true that something not existing may not be an error, but often it is, particularly when you expect it to exist. IE, if I go to fetch a record by ID from the database, but it's not there, there's no way to recover from that type of error.
An exception does not represent an unrecoverable state. It just represents that your code doesn't know the proper behavior. For instance, in a web server, the proper behavior is to throw a 500 and log the exception causing the error. In a UI, you might want to show a dialog box explaining the error and its source, maybe even sending the stacktrace to the developers. A CLI will print the exception and cease operation.
Mid-level code doesn't necessarily know what the appropriate response to an error is, so it shouldn't have to have to check for them. If things are working as expected, no exception. If something goes awry, let the calling code figure out the right response.
>> Won't cast an int to a long
> Again, are we using the same language? This works. see code example at the end.
Did you read my update?
> > name clash: X and Y have the same erasure
> This is not sensable behavior but entierly avoidable. Objects contain data and then process them, then return the processed data to another object. The Java way of doing this is to pass "List<Long> listOfLongs" and "List<String> listOfStrings" to the constructor of foo and to have funcLong() and funcString().
So, you have to encode in the name of the function the type of parameters it takes?
And what's the point of classes if you can't take advantage of them?
> > incompatible types
> I've never seen this but I also suspect that this isn't an issue as I've never run into it and I've had interfaces in interfaces.
It is an issue. LinkedList is a type of List, so a List<LinkedList> should match a List<List>. It certainly knows that a LinkedList<List> matches List<List>.
> > static methods and members in a class
> Static means the meaning of the method or object never changes. It will mean the same thing in every instance of usage. As such this makes sense. You never need to override a constant meaning as it will always mean the same thing.
You seem to use this argument a lot: "You never need to..."
Did you read my introduction to the topic?
> > The "class" type is an afterthought
> What does he mean by this?
Originally, classes in languages like C++ were simply syntactic sugar. You could not have a variable that stored a class. It didn't make any sense, anymore than a variable that stored a function.
Java continues this tradition.
In every other language, classes are first-class values that can be stored by any variable. So are functions.
The idea of storing a class in a variable is probably just as foreign as storing a variable in a function to a Java coder.
> > No control on member access
> Use lombok. Not an issue and is fixed at compile time, not runtime.
Or I could use Python.
> > RSI
> This makes no sense. An IDE is a tool that Java is deisgned to make use of. Locking yourself in your cave and saying it's bad isn't going to pursuade anyone.
Let me help you understand.
A programming language like Java consists of many parts, but in the end, it is a program that takes a bunch of text files and converts it into bytecode that the CPU can understand and execute.
Why do you insist on using an inferior programming language that requires the use of specialized tools, when those tools can be built directly into the programming language itself? IE, if I want to create a class, I'll just type "class A", not load up an IDE, click around a few times and hope I fill in the boxes right to have a hundred lines of boiler-plate code autogenerated for me.
It's not the 1960s anymore. We can write code that writes code. Let's do more of that and less fussing with the minor details that no one cares about.
> > Camel Case
> Nameing conventions aren't a reason a language is bad.
It is if you have to type those names.
> > Class-centric
> That is the idea behind Java. The other concenrns not addressed by the title have been fixed by the Java 8 additions allowing you to treat one-method interfaces in Java 8.
I'm not familiar with Java 8, but it sounds like they realized how bad of an idea it was if they're moving away from it.
> > Iterators SUCK!
> That is an implementation but it's fairly standard to just have tihs backed by some form of collection and see if there is data left in it. I usually use an index in an array and see if I have run past the end of the array.
So you're saying I shouldn't use iterators because it's easier just to code around them?
Iterators can be a powerful programming paradigm that is a major head-ache saver and time saver, but Java's implementation is so horrible you're recommending avoiding it. Got it.
> > foreach doesn't take iterators
> Yea this is crap.
I bow to your superior arguing skills.
continued ...
> Are we using the same Java?
No, I originally wrote the article back in 2008 or so.
>> GC Sucks So Badly, That You Should Avoid Using Memory
> I'm assuming this is from before Java 8. The latest GC algorithms don't do this.
AFAIK people still complain about the GC. I've noticed that more modern languages don't have advanced GC like Java's.
>> Worst of Exceptions and Value Checking
> Sometimes the correct thing to do is to throw an exception and other times it is to return a sensable value. An exception is an unrecoverable state, a null is a sensable value for when nothing exists. Something not existing and an unrecoverable state are two very different things.
I rarely deal in absolutes when I'm coding. It's all about engineering tradeoffs.
It's true that something not existing may not be an error, but often it is, particularly when you expect it to exist. IE, if I go to fetch a record by ID from the database, but it's not there, there's no way to recover from that type of error.
An exception does not represent an unrecoverable state. It just represents that your code doesn't know the proper behavior. For instance, in a web server, the proper behavior is to throw a 500 and log the exception causing the error. In a UI, you might want to show a dialog box explaining the error and its source, maybe even sending the stacktrace to the developers. A CLI will print the exception and cease operation.
Mid-level code doesn't necessarily know what the appropriate response to an error is, so it shouldn't have to have to check for them. If things are working as expected, no exception. If something goes awry, let the calling code figure out the right response.
>> Won't cast an int to a long
> Again, are we using the same language? This works. see code example at the end.
Did you read my update?
> > name clash: X and Y have the same erasure
> This is not sensable behavior but entierly avoidable. Objects contain data and then process them, then return the processed data to another object. The Java way of doing this is to pass "List<Long> listOfLongs" and "List<String> listOfStrings" to the constructor of foo and to have funcLong() and funcString().
So, you have to encode in the name of the function the type of parameters it takes?
And what's the point of classes if you can't take advantage of them?
> > incompatible types
> I've never seen this but I also suspect that this isn't an issue as I've never run into it and I've had interfaces in interfaces.
It is an issue. LinkedList is a type of List, so a List<LinkedList> should match a List<List>. It certainly knows that a LinkedList<List> matches List<List>.
> > static methods and members in a class
> Static means the meaning of the method or object never changes. It will mean the same thing in every instance of usage. As such this makes sense. You never need to override a constant meaning as it will always mean the same thing.
You seem to use this argument a lot: "You never need to..."
Did you read my introduction to the topic?
> > The "class" type is an afterthought
> What does he mean by this?
Originally, classes in languages like C++ were simply syntactic sugar. You could not have a variable that stored a class. It didn't make any sense, anymore than a variable that stored a function.
Java continues this tradition.
In every other language, classes are first-class values that can be stored by any variable. So are functions.
The idea of storing a class in a variable is probably just as foreign as storing a variable in a function to a Java coder.
> > No control on member access
> Use lombok. Not an issue and is fixed at compile time, not runtime.
Or I could use Python.
> > RSI
> This makes no sense. An IDE is a tool that Java is deisgned to make use of. Locking yourself in your cave and saying it's bad isn't going to pursuade anyone.
Let me help you understand.
A programming language like Java consists of many parts, but in the end, it is a program that takes a bunch of text files and converts it into bytecode that the CPU can understand and execute.
Why do you insist on using an inferior programming language that requires the use of specialized tools, when those tools can be built directly into the programming language itself? IE, if I want to create a class, I'll just type "class A", not load up an IDE, click around a few times and hope I fill in the boxes right to have a hundred lines of boiler-plate code autogenerated for me.
It's not the 1960s anymore. We can write code that writes code. Let's do more of that and less fussing with the minor details that no one cares about.
> > Camel Case
> Nameing conventions aren't a reason a language is bad.
It is if you have to type those names.
> > Class-centric
> That is the idea behind Java. The other concenrns not addressed by the title have been fixed by the Java 8 additions allowing you to treat one-method interfaces in Java 8.
I'm not familiar with Java 8, but it sounds like they realized how bad of an idea it was if they're moving away from it.
> > Iterators SUCK!
> That is an implementation but it's fairly standard to just have tihs backed by some form of collection and see if there is data left in it. I usually use an index in an array and see if I have run past the end of the array.
So you're saying I shouldn't use iterators because it's easier just to code around them?
Iterators can be a powerful programming paradigm that is a major head-ache saver and time saver, but Java's implementation is so horrible you're recommending avoiding it. Got it.
> > foreach doesn't take iterators
> Yea this is crap.
I bow to your superior arguing skills.
continued ...