News for hackers. Stuff that matters.

jgardner1

Re:Why Java Sucks – Jonathan Gardner on Monday December 19, 2016 @06:09PM (#13215817)
I'm not a luddite.

I just prefer the best tools for the job, tools that can be used with any software project. The Unix IDE is the best in the world.

Re:Why Java Sucks – Jonathan Gardner on Monday December 19, 2016 @06:07PM (#13215805)
What's the point of a static type system if I'm going to write unit tests anyways?
Re:Why Java Sucks – Jonathan Gardner on Monday December 19, 2016 @06:06PM (#13215800)
Hey guys, I'm the original author of that article, and I appreciate the comments.

A few points:

* I started this article about 8 years ago.

* I've been trying to keep it up to date, so your comments are being reviewed.

* If you really, really love Java, I'm glad you found something in life to get passionate about.

* If you intend to be a professional software developer, you need to broaden your horizons before you start calling yourself senior anything. Java is only one programming language in the world.

Feel free to email me at [email protected]. I've been putting this email up everywhere for a very long time so getting more exposure just helps train the spam filters that much faster.

Re:Why Java Sucks – Jonathan Gardner on Monday December 19, 2016 @06:00PM (#13215764)
> > Function Pointers -- Missing

> Java 8

Yet again, they admitted an important feature was missing. Again, I am not familiar with Java 8 but I suspect their implementation is horribly wrong.

> > Constructors can't call each other

> Again see the code at the end.

See my response.

> > Methods With the Same Name as Constructors

> Yea that's allowed, I don't see what's wrong with that. It's a real function name so it should be allowed. I've never accidently made this error.

I have. I guess I have just logged more time in Java than others.

> > Run-time Dispatch: Fantasy

> This is a design pattern issue but you're meant to use the highest or lowest version of an abstraction. From there you can ideally handle it in a generic way or if not you can use if (x instanceof Object) to filter out specific cases.

Please tell me how to do it properly. IE, if I have a variable of type Foo that is holding a value of type Bar, how do I invoke the function with Bar instead of Foo in the signature?

> > No Globals means Frameworks

> This is where decorators and static/singleton classes come in handy. You can do some amazing things with decorators, singleton/static classes, and if you need it a bit of reflection.

My point exactly.

Other languages just use globals. Because they are useful and people need them.

Java makes you invent a new programming paradigm to overcome its artificial limitations.

> > import is Useless

> You can just use the fully-qualified name of the other class and it will work fine. I've had maybe one instance where my naming conflicted with another package but that was a rare case.

And what do you do when you blow out the 80-char limit on columns?

Oh let me guess. You like your 1024-char limit on columns because you are using a superior IDE.

> > No List Literals

> Arrays.asList

I don't recall that being an option. I do know that people used to prefer the curly brace format but that turned out to cause memory leaks.

> > Inner classes Don't Work

> I don't know what he means as this works perfectly fine for some design patterns. Inherit state? No way. Provide impelemntations of an abstract/interface for a specific object? Yes way.

> In ArrayList it is perfectly fine to make an ArrayListIterator as they are the same bits of ideas and as such should be in the same file.

> I also prefer state enums to be defined in a class.

The issue with inner classes is that so many thing are contrary to expectations. I started to list them all but it got too long. I'll have to revisit it and try to condense it down.

> > Java is So Hard People Prefer to Write Code in XML, Jython, Scala, and Clojure

> I don't do this only """ENTERPRISE""" Java developers do this. There's a lot of great work being done moving away from this mentality but there is still a lot to be done.

The point is the reason why they do it is because it's easier to write, test and debug these other languages than Java. People know that coding in native Java is slow and cumbersome and time-consuming with no significant benefit.

> > Speaking of the JVM...

> I'd love some numbers on these claims.

What claims need numbers? LLVM and PyPy exist. JS with JIT kicks the pants off of almost everything --- because it is compiled down to native machine code. Go look them up for yourself.

JIT is the new fad, and it's a huge deal.

> > DNS Client Implementation

> Yea this is a problem. It's in here for compatability. There are many libraries implementing this better at the moment.

Name one.

> > Why Use Java at All?

> Why use any language at all? Write binary and opcodes (like I've been doing in my CPU project). It's very fun!

I write code to get the job done so I can get paid, my company's stock price can go up, and I can get money. It's a job. Yes, I love programming, but I prefer to get as much done with as little work as possible.

> In seriousness Java gets concurency right and I've not found another language that lets me write concurrent code like this ever before. Very nice platform to run on and one of the worlds best VMs. Everything is simple and documented well. I don't need to read a novel to get something working. I can think of a class, type that a control-space on my IDE, get a list of classes, find the one in the right package and move on. No google, no searching, just tooling and built in documentation. What's even better is most of the language is implemented in Java! I have the sources downloaded so CNTRL+Click and I can see everything's implementation! I'd love to see a python dev do that (I cant and I've been writing python for years).

Yeah, you strike me as someone who only knows Java. Let me know if I'm wrong.

> I'll be emailing the author at this email: jgardner @ XXX .net and giving him this comment. I hope he can rebute some of these points.

My email is [email protected]. It's been around for decades so feel free to send me as much email as you like. I'll see the good stuff and the spam folder will eat the rest.

Let me change your example:

   class Test {
   	private final int i;
   	public Test(int i) {
   		this.i = i;
   	}
   	public Test() {
                this.test(7);
   		this(10);
   	}
   
   	private void test(long number) {}
   }
Tell me how that works out for you.
Re:Why Java Sucks – Jonathan Gardner on Monday December 19, 2016 @06:00PM (#13215760)
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 ...