This post is entirely underwhelming and reminds me of the earlier post Java for Everything. The article makes very few arguments for Java. And any argument it makes where Java is not total rubbish, there are superior solutions out there.
Blocking calls sucks? Yes, Go, Ocaml, Haskell, Erlang, and heck even Python offer nicer solutions than Java.
Long load times means you need to use microservers? Wtf? An architectural decision should be driven by good design, not because my language runtime can’t handle how I want to program. I think SOA is the better solution, but not because my runtime takes awhile to get warm.
I’m not sure if the authors of these articles are ignorant, have stockholm syndrome, or have poor sense of self-reflection, but there isn’t anything in this post that persuasively argues why Java doesn’t suck.
There is value in the size and momentum of the ecosystem, even if the language itself is meh. Obviously many languages are better than Java. These articles are more about sucking it up and getting shit done. Pushing Haskell or Ocaml or Erlang at your company is great, but at the end of the day just write some Java that does the job. At a bigger company, it’s just easier. Interns can write Java, new hires can write Java, and the JVM itself is actually quite flexible.
The only thing the runtime is lacking is easy async IO, which honestly isn’t that important when other things will take care of that for you. Jetty will use async IO and use a thread per request rather than a thread per connection nowadays. You can use Netty if you really need it to write more custom stuff.
I would prefer to write Clojure or Erlang any day of the week, but I suck it up and write in Java and Go when it’s easier for reasons that are more important than the awesomeness of the language.
There is value in the size and momentum of the ecosystem, even if the language itself is meh.
I completely agree, which is why I think these articles are so underwhelming. They are trying to make an argument for Java based on technical merit. There isn’t any.
Interns can write Java, new hires can write Java,
In my experience, many people say they can write Java but the quality of said Java is almost always abysmal. This argument carries little weight for someone like me. I’d much rather have somebody who is a blank slate on a language so I can teach them how to develop in it rather than someone who has learned a little bit and fights me on what they think they know.
In my experience, many people say they can write Java but the quality of said Java is almost always abysmal. This argument carries little weight for someone like me.
In my experience as well. The fact that any easily-found, replaceable cog can write bad Java is an argument against adoption, to me at least.
I have not found this to be the case. Using language has a selection mechanism has been counter beneficial in my experience. Instead I prefer to find and sell people on the problems they will be solving. Most people I have met who get excited about a problem don’t care that much about what language restrictions they might have.
I think we are on the same page here. We both are looking for good programmers, who don’t care about the language. I know excellent programmers who don’t know Clojure, and some more who don’t know Haskell, and so on. But they all can write Java. Picking one language that is more often a “side language” throws out some good programmers, or at least makes it harder for them to spin up. When everyone you would already want to hire can dive into a code base and start solving the problem faster, that’s good.
Perhaps I was unclear, your statement was roughly that anybody can write Java, including your new hires and interns. I think this argument is fallacious. I’m going to have to break in those people no matter what. So using Java may be what your company needs but I don’t think it is a valid argument against using another language.
Also, I’m not against using other languages, but I do think having the main body of code in Java often, but not always, has advantages. If there is a niche aspect of an application where Java would be seriously outclassed by another language then I’m all for using that other language. But that niche codebase would ideally stay small enough that it can be maintained by only a fraction of the available developers who know that language. The classic example of this is the “write the chat server in Erlang” approach that so many companies are taking.
The java language affords coding a certain “OOPish” way. That’s why I hate it. I can see the same people code not like retarded monkeys when they code in python.
This post is entirely underwhelming and reminds me of the earlier post Java for Everything. The article makes very few arguments for Java. And any argument it makes where Java is not total rubbish, there are superior solutions out there.
Blocking calls sucks? Yes, Go, Ocaml, Haskell, Erlang, and heck even Python offer nicer solutions than Java.
Long load times means you need to use microservers? Wtf? An architectural decision should be driven by good design, not because my language runtime can’t handle how I want to program. I think SOA is the better solution, but not because my runtime takes awhile to get warm.
I’m not sure if the authors of these articles are ignorant, have stockholm syndrome, or have poor sense of self-reflection, but there isn’t anything in this post that persuasively argues why Java doesn’t suck.
There is value in the size and momentum of the ecosystem, even if the language itself is meh. Obviously many languages are better than Java. These articles are more about sucking it up and getting shit done. Pushing Haskell or Ocaml or Erlang at your company is great, but at the end of the day just write some Java that does the job. At a bigger company, it’s just easier. Interns can write Java, new hires can write Java, and the JVM itself is actually quite flexible.
The only thing the runtime is lacking is easy async IO, which honestly isn’t that important when other things will take care of that for you. Jetty will use async IO and use a thread per request rather than a thread per connection nowadays. You can use Netty if you really need it to write more custom stuff.
I would prefer to write Clojure or Erlang any day of the week, but I suck it up and write in Java and Go when it’s easier for reasons that are more important than the awesomeness of the language.
I completely agree, which is why I think these articles are so underwhelming. They are trying to make an argument for Java based on technical merit. There isn’t any.
In my experience, many people say they can write Java but the quality of said Java is almost always abysmal. This argument carries little weight for someone like me. I’d much rather have somebody who is a blank slate on a language so I can teach them how to develop in it rather than someone who has learned a little bit and fights me on what they think they know.
In my experience as well. The fact that any easily-found, replaceable cog can write bad Java is an argument against adoption, to me at least.
I don’t know about easily found, it’s still hard to hire good people. But there are more people who can write in Java, which increases your chances.
I have not found this to be the case. Using language has a selection mechanism has been counter beneficial in my experience. Instead I prefer to find and sell people on the problems they will be solving. Most people I have met who get excited about a problem don’t care that much about what language restrictions they might have.
I think we are on the same page here. We both are looking for good programmers, who don’t care about the language. I know excellent programmers who don’t know Clojure, and some more who don’t know Haskell, and so on. But they all can write Java. Picking one language that is more often a “side language” throws out some good programmers, or at least makes it harder for them to spin up. When everyone you would already want to hire can dive into a code base and start solving the problem faster, that’s good.
Many people are not good programmers who would write trash in any language.
Yes, my statement doesn’t argue that isn’t true.
Indeed. I suppose I meant that people who are going to write abysmal Java are probably also going to write abysmal code in other languages.
Perhaps I was unclear, your statement was roughly that anybody can write Java, including your new hires and interns. I think this argument is fallacious. I’m going to have to break in those people no matter what. So using Java may be what your company needs but I don’t think it is a valid argument against using another language.
The other comment I just made also addresses this one.
Also, I’m not against using other languages, but I do think having the main body of code in Java often, but not always, has advantages. If there is a niche aspect of an application where Java would be seriously outclassed by another language then I’m all for using that other language. But that niche codebase would ideally stay small enough that it can be maintained by only a fraction of the available developers who know that language. The classic example of this is the “write the chat server in Erlang” approach that so many companies are taking.
The java language affords coding a certain “OOPish” way. That’s why I hate it. I can see the same people code not like retarded monkeys when they code in python.