Java for Everything • Hacker News Board

Re: Java for Everything

#151

Post by MarkMc » Sun, Nov 30, 2014, 11:37 PM UTC

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.

Not true - here's my attempt:

Windows: http://www.solaraccounts.co.uk/images/screenshots/invoices.j...

OS X: http://www.solaraccounts.co.uk/images/screenshots/invoices_m...

The trick is to use the Java SWT library rather than Swing. (In my case I also added a few platform-specific hacks such as having a big toolbar at the top of the main window in OS X but not Windows).

Re: Java for Everything

#152

Post by twic » Sun, Nov 30, 2014, 11:37 PM UTC

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…

> I've watched a company spend two years, dozens of developers, and over a million in ESB license fees failing to write a site that was expected to have, at peak, 100 users/day.

I'm sorry to hear that. But you understand that this had nothing to do with Java, right? Java didn't make those people do that. That was just good old fashioned human stupidity. It's entirely possible to write simple things in Java, without ESBs and a person-century of effort.

It's even possible to write simple things in Java EE - there's an enjoyable little book about it: http://press.adam-bien.com/real-world-java-ee-night-hacks-di...

> Nor are the performance advantages "permanent"; even if you use Java, you will probably have to rewrite if you reach Twitter scale, because your initial app won't be clusterable (or if it is, it's massively overengineered and your business will fail).

I don't think this is true either. The normal approach to writing scalable apps these days is the twelve factor approach:

http://12factor.net/

And that works just as well for tiny deployments as huge ones. It doesn't involve doing anything arcane and expensive up front. It's mostly common sense. Scaling out will involve a lot of changes, but incremental ones.

Re: Java for Everything

#153

Post by x0x0 » Sun, Nov 30, 2014, 11:41 PM UTC

blazespin wrote: post #85

msluyter wrote: post #83

There's the language and there's the ecosystem. A lot of negative feelings that still linger are, IMHO, directed more at some of the painful historical aspects of the ecosystem: J2EE XML configuration hell, EJBs, bloated application servers, XML for everything, JAX-WS, SOAP, ant, classloader problems, maven dependency hell, 10 different logging libraries, etc... A lot of this stuff truly sucked. But I feel things hav…

I suspect readability isn't a big priority for you. Here's how I'd write this, lambdas or not: public static List sortDescending(List ints) { ints.sort(new Comparator () { @Override public int compare(Integer o1, Integer o2) { if (o1.equals(o2)) { return 0; } else if (o1 My personal perspective is that your use is a typical abuse which turns simple code into something unreadable and overly complex. This makes code ha…

one line is way more readable than 7 lines taking up valuable vertical and brain space

it could also be accomplished with

    return -1 * o1.compareTo(o2);

Re: Java for Everything

#154

Post by guard-of-terra » Sun, Nov 30, 2014, 11:42 PM UTC

freshflowers wrote: post #34

The same argument can be made for any mature language with a solid ecosystem of tools and libraries. Except the part about scalability, that's just BS. It has little to do with language and is all about architecture. Sure, at some point language can help you squeeze every ounce of performance out of the hardware (although my money would not be on Java for that), but that's only in cases where either performance is cr…

It has a lot to do with language. If your language's runtime has solid threading and reasonably pauseless GC (at several gigabytes heap) you run into much much less problems with scalability.

Java people take many things for granted.

Re: Java for Everything

#155

Post by [deleted] » Sun, Nov 30, 2014, 11:43 PM UTC

twic wrote: post #139

blazespin wrote: post #85

Earlier quoted context omitted.

I suspect readability isn't a big priority for you. Here's how I'd write this, lambdas or not: public static List sortDescending(List ints) { ints.sort(new Comparator () { @Override public int compare(Integer o1, Integer o2) { if (o1.equals(o2)) { return 0; } else if (o1 My personal perspective is that your use is a typical abuse which turns simple code into something unreadable and overly complex. This makes code ha…

I'll meet you halfway: ints.sort((o1, o2) -> { if (o1.equals(o2)) { return 0; } else if (o1 Or may i suggest a version with a guard clause and a simple ternary: ints.sort((o1, o2) -> { if (o1.equals(o2)) return 0; return (o1 There's definitely no need for the 'new Comparator' boilerplate any more. That's not the kind of verbosity that adds clarity; it's just ceremony.

[deleted]

Re: Java for Everything

#156

Post by justinsb » Sun, Nov 30, 2014, 11:46 PM UTC

ks wrote: post #94

> Map userIdMap = new HashMap (); 1.7 introduced a simplified version: Map userIdMap = new HashMap ();

And Guava has Map userIdMap = Maps.newHashMap() which uses Java's type inference rules, and works in 1.6 (I think even in 1.5)

Re: Java for Everything

#157

Post by adiM » Sun, Nov 30, 2014, 11:49 PM UTC

x0x0 wrote: post #153

blazespin wrote: post #85

Earlier quoted context omitted.

I suspect readability isn't a big priority for you. Here's how I'd write this, lambdas or not: public static List sortDescending(List ints) { ints.sort(new Comparator () { @Override public int compare(Integer o1, Integer o2) { if (o1.equals(o2)) { return 0; } else if (o1 My personal perspective is that your use is a typical abuse which turns simple code into something unreadable and overly complex. This makes code ha…

one line is way more readable than 7 lines taking up valuable vertical and brain space it could also be accomplished with return -1 * o1.compareTo(o2);

Why not:

    return o2.compareTo(o1);

Re: Java for Everything

#158

Post by waps » Sun, Nov 30, 2014, 11:51 PM UTC

freshflowers wrote: post #34

The same argument can be made for any mature language with a solid ecosystem of tools and libraries. Except the part about scalability, that's just BS. It has little to do with language and is all about architecture. Sure, at some point language can help you squeeze every ounce of performance out of the hardware (although my money would not be on Java for that), but that's only in cases where either performance is cr…

You forget just how much difference there is between languages. Comparing Python and Java for example, it's easy to find things that take 1-2 cpu cycles in Java (or even 0), that take thousands of cpu cycles in Python (e.g. function calls).

http://benchmarksgame.alioth.debian.org/u32/python.php

I mean, I would agree that 1s versus 1.3 seconds doesn't really matter. But look at those numbers we're talking 40-50 TIMES faster in half the cases. The number I tend to use is that one programmer is worth 10 servers. But this has diminishing returns : the larger the site gets, the more you'll focus on servers.

But even for small sites. Python is about double java's productivity, no more. That only helps you for very small programs.

So for large sites, python would have to be 40-50 times more productive than java. This is exactly python's weak point, and java's strong point ...

And from experience I know. Large python programs are horrendously difficult to change. They're like how large perl programs used to be. Changing a tiny thing in one far removed part of the program affects 10 other places in the program, with absolutely no warning, until the site crashes. And then you put a try-catch in your main loop and AAARGH.

Re: Java for Everything

#159

Post by justinsb » Sun, Nov 30, 2014, 11:51 PM UTC

facepalm wrote: post #118

How do you even parse JSON in Java? I remember in the days of XML, there was a kind of specification standard for the xml (a specification for how to specify a specification?). From that you could generate Java classes that would correspond to the elements of the XML. But for JSON there is no such meta description, so you are stuck with manually parsing the JSON and hoping you catch all nuances?

I'd recommend Google Gson; it works either with model classes, or with a generic JsonObject.

Jackson is good, and more powerful in terms of model mapping, but I find it much more complicated to work with.

Re: Java for Everything

#160

Post by lmm » Sun, Nov 30, 2014, 11:53 PM UTC

twic wrote: post #152

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…

> I've watched a company spend two years, dozens of developers, and over a million in ESB license fees failing to write a site that was expected to have, at peak, 100 users/day. I'm sorry to hear that. But you understand that this had nothing to do with Java, right? Java didn't make those people do that. That was just good old fashioned human stupidity. It's entirely possible to write simple things in Java, without E…

> I'm sorry to hear that. But you understand that this had nothing to do with Java, right? Java didn't make those people do that. That was just good old fashioned human stupidity. It's entirely possible to write simple things in Java, without ESBs and a person-century of effort.

It's an extreme example of the same mistake this blog post is making. I mean, from a certain point of view they were right - if the site had reached twitter scale, it would have needed those things. The market genuinely is growing, and the problems the system solves exist in almost every industry. I expect those four guys won't keep their system in Rails forever.

Maybe using PHP really will make your system slower by a factor of 15. So what? A trivial saving in development time - say a week over your first year, a 2% factor - is well worth that 15x performance penalty for most businesses.

((Don't use PHP, kids. But not because of the performance))

> The normal approach to writing scalable apps these days is the twelve factor approach

Hmm, I wonder how many people have heard of this, and you say it's "the normal approach".

Debugging distributed systems is and always will be harder than debugging monolithic systems. Even the simple engineering good practices from that page, like explicitly declaring dependencies, have a cost. My Google friends tell me their explicit policy is to design a service for one order of magnitude more than the current traffic, and expect to rewrite it after that.

And once you're doing the things you need to scale - explicitly defined interfaces, all calls going via the network or something equivalent to it, service discovery - then changing the language used in parts of the system really isn't that big a deal. You can do it incrementally. (I have experience of doing just that, at last.fm)