Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java for Everything

teamten.com

Post reply on HN
Print view View original

91–100 of 344 posts

Re: Java for Everything

#91

Post by edwinnathaniel »

andor wrote: post #11
Mithaldu wrote: post #4

He learned something that most good Perl programmers learn fairly quickly: The interpreter/compiler is just the VM; the real language is the combination of all libraries available for it.

There's no shortage of good libraries for Python. He just chose to not learn about them.

Some good, some aren't, some used to not work with Python 3, some still don't work with Python 3, some reinvent the wheel died due to not being popular (sql object, pylon, turbogears), some looked relic and not worth to learn ( plone, zope).

Like the article said, it's fun and quick to hack in Python but just ain't everybody taste... especially seeing the age and the quality of some of those libraries.

Re: Java for Everything

#92

Post by pimlottc »

jim_greco wrote: post #59

The biggest thing for me is that the tooling around Java makes maintaining large projects extremely easy. Being able to refactor hundreds of files in a few keystrokes without worry lets me sleep well at night. It's certainly a lot faster to get up and running with a dynamic language, but the initial build out is a small percentage of the overall time you are going to spend with a codebase. I've also built just about…

I think this is the key point in the debate - weighing initial development time against ongoing development and maintenance. It's something that's hard to grasp until you've been around for a while working on real-world large-scale projects. And it's a hard thing to get the sense of when you're in school, writing throwaway code that doesn't last past the end of the semester.

When you understand this, then you can make an honest assessment - is it really important to get the first build out that much quicker? Sometimes it is. But I think it's overemphasized. The first one to market doesn't always win. And the shift from new development to maintenance happens quicker than you might think.

Re: Java for Everything

#93

Post by chadrs »

This whole "expressive vs. performance" is a false dichotomy. Languages like Scala and Haskell are performant like Java and expressive like Python. Not to mention the work being done on JIT compilers by V8/HHVM/PyPy that are helping to close the performance gap for dynamic languages.

Re: Java for Everything

#95

Post by br_smartass »

drivingmenuts wrote: post #35
fenesiistvan wrote: post #26

Java is perfect also for client side. We have a client app (a complex VoIP softphone) with different codebase for all platforms (C++ for windows, java for android, ObjectC for iOS). Right now we are in the way to reduce all this in one single codebase written in Java and the user interface in html/css/javascript, so the user interface is always running in a webview. -Java for windows desktop (there are pretty install…

> Java is perfect also for client side. Unless you want it to look totally native client-side. The extra effort required to make a Java app look platform native is something that (near as I can tell) no one has ever attempted.

Isn't Java FX tackling that?

Re: Java for Everything

#96

Post by mike_hearn »

drivingmenuts wrote: post #35
fenesiistvan wrote: post #26

Java is perfect also for client side. We have a client app (a complex VoIP softphone) with different codebase for all platforms (C++ for windows, java for android, ObjectC for iOS). Right now we are in the way to reduce all this in one single codebase written in Java and the user interface in html/css/javascript, so the user interface is always running in a webview. -Java for windows desktop (there are pretty install…

> Java is perfect also for client side. Unless you want it to look totally native client-side. The extra effort required to make a Java app look platform native is something that (near as I can tell) no one has ever attempted.

IntelliJ has historically looked pretty native on MacOS X. At least until Yosemite pointlessly reskinned Aqua to look more ugly. Now I find myself quite happy that IntelliJ is not a native Mac app because I preferred the old look anyway :)

You can make the apps look native, if you really care. But in an era when web apps are the shizzle why would you even care? No web app even tries to look native. They just do their own thing and nobody cares.

Re: Java for Everything

#97

Post by edwinnathaniel »

lmm wrote: post #89

Verbosity matters for reading and maintenance far more than it does for writing. IDEs can make the writing faster, but they can't make the code as easy to comprehend as it would be in a more expressive language. And remember that lines of code is the only proven risk factor for bugs. Most sites are not Twitter. They're not Stack Overflow. They're not even Nanowrimo. I've watched a company spend two years, dozens of d…

Care to share more details of these companies including how the Ruby ones become profitable after a month with 4 guys on payroll? No offense but I've got to check the facts these days.. :).

Also, don't forget Fred Brooks article about the Second System. I betcha smart engineers on tight budget can hack in Java just as quick as those 4 guys and achieve the same result. My apology, Java today is as productive as Ruby on Rails.

The difference between rewriting a Rails site to Java and an already written system un Java to a more modern architecture is huge. One can slowly move from old Java architecture to the newer one but it'll be trickier from Rails to something else... don't forget the accumulated Ops experience managing jvm based app server, the devil in details for those experienced engineers who have been there and done that...

Re: Java for Everything

#98

Post by mike_hearn »

iolsantr wrote: post #72
lkesteloot wrote: post #40

It's not so much that Java is great at everything. It's more like it doesn't suck at anything. Every other language has, somewhere, a deal-breaker for some particular use. I've not found one for Java. And Java's biggest downside, frankly, is that it hasn't attracted fresh young talent in a while, so it doesn't have really hot frameworks and libraries.

Java's start up time makes it pretty crappy for command line utilities.

When did you last try it? Startup time was optimised heavily some time ago and nowadays I don't notice any real difference unless I wrote some toy app and used "time". The JVM starts fast enough that you can write command line utilities just fine.

Re: Java for Everything

#99

Post by one-more-minute »

pimlottc wrote: post #79
one-more-minute wrote: post #17

The problem with verbosity and repetition is not that it takes longer to type the code, at all. The problem is that it creates dependencies which you have to manage by hand. Changing `Foo a = new Foo()` to `Bar a = new Bar()` doesn't seem that bad... except when you have to propagate that change through the code base. Half of Java's tooling is dedicated to solving a problem that doesn't exist in good duck-typed langu…

> Changing `Foo a = new Foo()` to `Bar a = new Bar()` doesn't seem that bad... except when you have to propagate that change through the code base. Half of Java's tooling is dedicated to solving a problem that doesn't exist in good duck-typed languages or those with type inference. A sweeping change like that is hard in Java, but it's nearly impossible in Python. That is, unless you're willing throw up your hands and…

I'll be the first to agree that Java-style class hierarchies and duck typing don't mix well, but not every dynamic language is Python. Clojure, for example, is very easy to refactor when it's (very rarely) necessary.

Not saying static typing doesn't have it's advantages – tooling is probably Java's greatest strength – but there are other, equally valid, solutions to the problem.

Re: Java for Everything

#100

Post by ridiculous_fish »

You have to appreciate bombastic statements like this for forcing you to confront your assumptions. "Everything in Java? Even a kernel? That's absurd." you think, and then wonder what makes it absurd, and realize that it could perhaps be done with some modifications, and remember Singularity, etc.

But on the other hand, this is well trod ground. Everything WAS going to be Java. Remember picoJava, the bytecode-native processor? Remember Cocoa Java, for OS X desktop apps? Remember HotJava, the pure Java web browser? These things were tried, and they failed. Performance issues, especially around startup and memory usage. The weightiness of the JVM, what Jobs called a "big ball and chain." The weird foreignness of Swing apps. The generalized misery of applets. Etc.

So honest question: what's different this time?

Post reply on HN