Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> In Java, you can forget about doing it in the cleanest or the best way, because that is impossible. Whatever you do, however hard you try, the code will come out mediocre, verbose, redundant, and bloated

(reason for liking Java)

Well, here are some other reason for liking Java: https://medium.com/i-m-h-o/da3b2c180e9c

But I really believe the future of software is affected more by having better programmers rather than having better languages.

Yes, it helps to have cool languages like Julia, Nimrod, Rust, even Scala (which I think is the best statically typed JVM language out there). But I tend to think that a good developer will be good in any language, Haskell, C, Java or LOLCODE.

I think that a good developer "forced" to use Java will find tools that bring out the good parts of the language: Dropwizard, Play framework / Akka, even latest versions of Spring and Java EE are much more convention over configuration and lightweight than before. They will use Guava and Apache commons to streamline common Java verbosity and bloat. They'll use Java 8 which allows much more robust and concise syntax to common problems.

But I don't think that the language is the problem. I think that a great developer will be able to tackle any problem with the language itself easily, because the real problem is not how to implement X, but more what is X. Designing the software correctly is the main problem at hand, not how to move input to output. This is what stackoverflow is for.

One last point about this all "I hate/like Java" type of post

1) If you write Java for your day job and hate it, either try to introduce something else (Clojure / Scala / Java 8 / Kotlin) If you can't introduce any of these then either accept your fate or just quit and find another job. If you can't find another job, then perhaps you deserve to stay and write Java so stop whining, it's not that bad (and one day you'll get to use Java 8).

2) If you don't write java for your day job but as a freelancer - start getting other non-java gigs. Not so many non Java jobs? well, continue to write Java bashing blog posts until people will stop using it I guess...

3) If you don't write Java for your day job or as a freelancer, then just stop complaining about it. There are million of other things (not just programming languages) out there worth complaining about. They can use your writing talent for a better cause.



But I really believe the future of software is affected more by having better programmers rather than having better languages.

On average, I believe the quality of programmers will decline, simply because as they demand rises more and more people will come to the field that don't do it out of interest/passion but because it a profitable profession. Not that this is already the case today - I think it's a trend that's already begun and will probably continue this way.


This was already happening during the first dot.com boom. The time I studied CS. In Belgium banks would provide cars and a paycheck while you were still graduating in your last year.

This attracted a lot of people who weren't really passionated about programming.

Now years later I was hiring during the bank crisis and I interviewed CS students who got their degree but couldn't find a job. I couldn't understand that if you have your degree and are out of job in 2 years you haven't written a single line of code on a hobby project. But these people exist.

These people will be always there in any field.


> one day you'll get to use Java 8

Only new Java projects would actually use the Java 8 features anytime soon. Existing Java codebases will stick to their Java 6 installation for a long while. It could be years before lambdas are used to any significant degree. Look at how long it took for many Java 1.4 shops to actually upgrade to Java 5, let alone encourage developers to use its features. Even today a lot of places still allow and even encourage use of collections classes without the generics specified.


You can start using Java 8 as soon as you are willing to move. I don't think there are many breaking changes in the new version. Just give it a few months to be really stable. Last week , it took me around ten minutes to move one application from 6 to 7.


"You can start using Java 8 as soon as you are willing to move."

As long as you aren't writing Java code on Android, in which case you're still stuck at Java 6 (with a very small subset of Java 7 features that were added 3 years after Java 7 came out).

Not the fault of the Java language, really, but it is incredibly annoying how unclear Google has been on the future of their dialect of Java post the Oracle lawsuit.


I have been waiting for servlet 3.0 on App Engine since 2010

https://code.google.com/p/googleappengine/issues/detail?id=3...

The funny thing is that google's own GWT requires it now.


It's worth noting that Android 4.4 does support pretty much all JDK7 features (multicatch / try with resources / etc), finally. I've run into the occasional missing method from some of the newer class libraries, but nothing too serious.

Of course, if this is any indication it'll be several years before its safe to use even JDK7 features considering Android's update trends, let alone JDK8 ...


This has made me use C++ for my hobby graphics programming on Android instead.

The NDK has all the support I need, when coupled with something like Qt/SDL/openFramerworks and C++11 feels better than Google's Java fork.


you should consider using Scala on android. works really well for my projects.


Which scala android project are you using?


There are quite a few breaking changes in Java 8, here's the official compatibility guide: http://www.oracle.com/technetwork/java/javase/8-compatibilit...

One worth noting: If existing code is using Proxy.getProxyClass and the Constructor.newInstance method to create a proxy instance, it will fail with IllegalAccessException. RFE 4487672


Why would you ever do that..? If your production code is using those kind of proxies, it must be one terrible mess. First order of businesses would be to fix the code at the very least.


This used to be the right way to create dynamic proxies. Why one would do this is another discussion. For completeness here's a link to the usage in Spring: https://github.com/spring-projects/spring-framework/search?q...


The Spring code is still fine. You didn't quote the entire advisory:

> If existing code is using Proxy.getProxyClass and the Constructor.newInstance method to create a proxy instance, it will fail with IllegalAccessException if the caller is not in the same runtime package as the non-public proxy interface. For such code, it requires a source change to either (1) call Constructor.setAccessible to set the accessible flag to true, or (2) use the Proxy.newProxyInstance convenience method.

To end up in that specific condition is fairly difficult and usually means something is wrong with the code to begin with. It's still a very easy fix in any event (adding in 1 extra line of code before the call).


"java.lang.UnsupportedClassVersionError: Test : Unsupported major.minor version 51.0"

(yeah, shouldn't happen in the best of all possible worlds, but may still happen anyway)


Java had major shifts in the language in 1.2 and 1.5. Java 8 isn't one of those cases. I think you'll find adoption won't be terribly slow.


I would put lambdas in the "major shifts in the language" category.


> I would put lambdas in the "major shifts in the language" category.

Recompile away, stuff just works. Add lambdas to your code, compile. Still works. This isn't like 1.2 where you were adding collections classes (arguably for the first time) or 1.5 where you encounter generics.


Java input output api is cumbersome, so is its date api. That is why you use Apache commons and yoda time to deal with them.

He sounds like someone who never learn Java in the first place. Neither he learned what it is good for, what it is bad for. I think that if you interview in some language, you should understand what kind of problems are easy to solve in that language and which are hard or never done.

If I have to write libraries less input output example in interview, my code will be ugly and long. I'm not saying that interview should not ask these questions, it tests whether the candidates ability to find his way around api he uses rarely. It is needed skill, so no problem there.

If I have to design complicated system, adjust it to changing requirements and maintain it for years, I feel most comfortable in Java. Type safety, tools and language itself allow me to focus on the system itself and how systems parts cooperate with each other.

He also sounds like somebody who is biased against whoever uses java, because he worked once in bad java shop. It sounds that it really does not matter what those people would do, they used java, so they are incapable in his eyes.

"In Java, you can forget about doing it in the cleanest or the best way, because that is impossible. Whatever you do, however hard you try, the code will come out mediocre, verbose, redundant, and bloated."

Guess I was right about learning Java.


The date api is refreshed in java 8, the spec lead was creator of joda time.


> But I really believe the future of software is affected more by having better programmers rather than having better languages.

Better programmers will likely make better languages. Undoubtedly a good programmer can learn to program in any language, because its the same process, but languages do certainly have their limitations.


> LOLCODE

Sorry, no. That's just too far. Imagine being handed a codebase of LOLCODE.


LOL

I hope to God no one ever was or will be handed a codebase of LOLCODE for a "real" commercial system.

But if anyone ever does, it will sure be fun to hear about it in a blog post.


To be fair, it probably wouldn't be too hard to write a parser/translator to turn into into a more readable language. Unlike something like Perl of C++, where you'd pretty much have to be superhuman to write a parser single-handedly.



Then in this case we should write a production system in LOLCODE, hitting a PostgreSQL database full of user defined functions written in plbf....




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

Search: