Live data from Hacker News

Java Developers

nsainsbury.svbtle.com

161–170 of 321 posts

Re: Java Developers

#161

Earlier quoted context omitted.

Some of the complaints about the over-formal language is a matter of taste, perhaps, but it does grate and is not a new complaint (see also: the Kingdom of Nouns rant). However Java developers are learning (or migrating to Scala/Groovy/Clojure). And there is hope -- the Play framework, for example, is an example of Java done right (imho). Spring 4 is moving in the right direction.

I don't think it's a matter of taste. TBH I write very little of the code that is checked in to the source control. The IDE does all the boilerplate. I literally design the method signatures, define the access policy for the methods and fill in a few gaps here and there. Play is not Java done right by any means. It's tightly coupled, has really poor documentation, breaking changes galore between major releases, deplo…

I agree a bit with the Play framework comments. It has some interesting things borrowed from Rails but it borrowed to much of the magic for my tasted. I'm using Wicket right now. which is very nice and flexible and well documented. The source code is easy to understand it is not lasagna.

Re: Java Developers

#162
As a newly hired Java dev I can understand the problems that Java has with many levels of unnecessary complexity. However, I do not think it is right to simply say that all or even most Java devs are bad. First of all the definition of bad is relative to the person and secondly I would not agree in saying that they are all or mostly bad. People are usually trying to do the right thing and if that does not fit inside your ideals then it is bad?

I guess all I am saying is not the throw stones. No one is perfect and to bash a whole community today based a snapshot of what you have seen is narrow-minded, look for the good parts and focus on those at least. Teach someone to code well in Java, if you feel so inclined to say that you know better. I know that there is a lot to learn, personally. I currently do like Javascript and Python as well but I would never look down on Javascript, Python, or Java communities. They are all great in their own way and in many similar ways.

We all enjoy coding at some level, why does anotehr way of doing that have to be so worng?

Re: Java Developers

#163

Earlier quoted context omitted.

I did the two FP courses from Mr. Odersky using Scala as the main language and then continued playing with the language for small experiments. While the language is awesome in general, I would not recommend it at work.

Any particular reason you wouldn't recommend it at work?

As the author of this post mentioned the culture of the Java developers, the "architect" thing and the frameworks, Scala has its own similar problems: it attracts a group of academics on type systems and creates over-engineering in a completely different direction.

Also, while I think Scala is simple at its core concepts and syntax, it gets complex because it has too many features and tries to support all features present in other programming languages. Why do you want structural typing there?.

Also, I hated sbt.

Re: Java Developers

#164
post #122

Earlier quoted context omitted.

There are several examples of simple libraries in Java that makes you realize it is possible to provide solutions to problems without the "culture" that predominates the ecosystem. For example Simple ( http://simple.sourceforge.net ) is a great XML serialization framework that does very well what it is supposed to do. And there are others I haven't used, but you look at the API and think, this is what I want. I was v…

Just had a look at jDBI and it doesn't exactly look like a simple library to me. There's a lot of run-time annotation processing. Have a look at jOOQ if you haven't seen it yet. There is a pre-compilation stage which generates DAO for you and they can then be used with static type guarantees.

I mentioned I haven't used it, I only got the impression from the API, but you are criticizing the implementation right, not the API?

Re: Java Developers

#165
I think most of the problems are caused by enterprise, enterprise frameworks, and the sheer age of Java. There's a lot of technical debt built up and a lot of enterprisey frameworks that are way over engineered.

I use Java, but I tend to do low level stuff, stick to basic I/O, Guava, etc.

I think the article is right in one important aspect: the way Sun built Java was to pretend as if everything should be a competitive market. So pluggable drivers for everything. Rather than build in say, one XML parser, instead let's build in a whole system to allow you to plug in any XML parser. As a result, it takes 4 lines of code to do what should work in 1 line. On other platforms, Python, Ruby, Go, et al, there is no such assumption that one needs an abstract interface to allow multiple implementation providers. You have an opinionated built-in implementation, or you use third party APIs.

This is why you have stuff like DocumentBuilderFactory/DocumentBuilder/etc.

When really, you want to write: Document doc = XML.parse(...)

Enterprise developers copied the basic design of having provider lookup/locators. This is why we have AbstractFactoryLocatorServiceLocator stuff.

Where I part company with the author is the total trashing of OO and the language. There are certainly lots of warts and things to complain about, but I haven't used a single language where I didn't have a boatload of things to bitch about.

I think you fall in love and there's a honey moon period with most languages, and then the beer goggles wear off after daily use and you see all the flaws.

Re: Java Developers

#166
post #47

Java can be really glad that there is Google with Android. Otherwise this language would be a strong enterprise focused language with very bad reputation on the end user side.

However - how many developers are turned off of being Android devs by the fact they have to use Java? (and I know that probably many more are attracted because they already know Java but that's not my point)

I was turned off by a.) horribly slow speed of Android virtual machine b.) being hard to code for it with maven c.) I did not particularly liked their xml language for gui.

I would have to write mobile, I would use one of those languages that compile into both Android and iOS as much as possible.

Re: Java Developers

#167
Recently-graduated student here, middle-aged and with more than my fair share of life challenges under my belt. I fell in love with coding by accident, after half a life in the restaurant trenches. But one of the things you can learn in the trenches is the value of patterns, and the value of recognizing patterns. Over the years I've come to trust my instinct for recognizing patterns, hard-won as it was.

Java is swamped in an over-proliferation of verbiage. That is the first impression one has of the language in school: that it requires twice as much code to do anything. And that was, as well, my last impression, as they tried to prepare us for our entry into the world of enterprise computing by steeping us in a rolling, boiling stew of jEverything. Too many cutesy names in a programming language just felt WRONG, and I think my instincts have been borne out. Java is a mess to behold and to work in, and I am fantastically glad that I didn't get that first (Java) job I applied for, but instead got the second (ASP.NET) job.

Irony abounds, I know, but .NET seems streamlined and elegant compared to Java EE. Turns out, sometimes you actually CAN judge a book by its cover. And by the 1496 pages in that Java textbook, which, hysterically, serves as merely an introduction...

I don't know where I'll be in a few years, but I'm fairly certain I'll not be coding in Java.

Re: Java Developers

#168
Java combines OO with strict typing (unlike Ruby which has OO without the strict typing). As such, that particular combination leads to bloat and verboseness. See:

What did Rich Hickey mean when he said, “All that specificity kills your reuse!”

http://programmers.stackexchange.com/questions/199217/what-d...

Part of the answer given:

"If you have two entities { "name":"John" } of type Person, and { "name": "Rover" } of type Dog, in Java-land they probably cannot interoperate unless they share a common interface or ancestor (like Mammal, which means writing more code). So the interfaces/types here are "killing your reuse": even though Person and Dog look the same, one cannot be used interchangeably with the other, unless you write additional code to support that. Note Hickey also jokes about projects in Java needing lots of classes ("Who here has written a Java application using just 20 classes?"), which seems one consequence of the above."

Re: Java Developers

#169
post #132

Earlier quoted context omitted.

Talk about workarounds.

Lisp macros ? (first-class and generic, not bad for a workaround)

No, faced with the fact that CLOS is also verbose, although in a language that is all about closures, you started to present workarounds how to simplify its verbosity.

Re: Java Developers

#170
post #149
post #134

Earlier quoted context omitted.

There are many models: - OO like in Smalltalk - OO like in SELF - OO like in BETA - OO like in CLOS - OO like in COM - OO like in Haskell - OO like in C++ - OO like in Eiffel - OO like in Ada - OO like in Sather A few more models might exist.

> OO like in Haskell Please explain. Are you referring to type classes?

Yes. Type classes is a way of doing polymorphism in Haskell, the central point of OO.
Post reply on HN