Live data from Hacker News

Java for Everything

teamten.com

251–260 of 344 posts

Re: Java for Everything

#251
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…

> they can't make the code as easy to comprehend as it would be in a more expressive language. It's a little hard to make a general statement using an vague term like "expressiveness". Static typing can actually make things clearer . That's a kind of expressiveness. You can know with complete certainty what type of data the code works with, just by looking at it. No need to rely on a certain set of unit tests living…

Static typing can make things clearer, indeed, however Java has really shitty static typing. Also this is a common misconception:

> You can know with complete certainty what type of data the code works with, just by looking at it.

First of all, the type is only a limited view of the shape of the underlying data, written from the perspective of the business logic using it. In a micro-services architecture it happens often to see the same data exposed with types that are often very different, depending on what you're trying to accomplish. And too often developers that work with Java are complecting the business logic with the actual data, which is often pure data that's being messed up with short term business logic rules.

And furthermore, Java developers don't work with static type safety. Tell me, what does a String tell you? What does a Double tell you? How often have you seen explicit type-safe numeric types in Java (e.g. lets say values that are in kilowatts, or meters, or other units of measure)? You don't see that, because Java is awful at expressing such types, from the lack of operating overloading, to the completely retarded generics system and the lack of type-classes.

Second of all, the type IS NOT sufficient documentation when dealing with non-determinism and if side-effects happen in your system, then that's non-determinism. And when non-determinism happens, you need to document the protocol of communication and static types in mainstream languages cannot capture that, which is a PITA because that would be far more useful than seeing that this Person has an email address.

Re: Java for Everything

#252
post #121
post #64

Earlier quoted context omitted.

There isn't "The JVM", there are certified JVMs and quite a few of those allow for AOT compilation to native code.

...quite a few of those allow for AOT compilation to native code Do you know of any good and free ahead-of-time Java compilers that produce native binaries without any additional dependencies? I haven't been able to find any, but perhaps my Google-fu is weak. gcj is obviously not a good answer.

gcj is dead.

For good ones I only know of commercial like Aonix, Websphere Real Time, Excelsior JET, JamaicaVM and a few others.

If you want to go free and are happy just with GNU/Linux and Mac OS X/iOS, then RoboVM might be an option.

If you want to go research, there is Graal/SubstrateVM from Oracle Labs and JikesRVM, a meta-circular JVM.

Re: Java for Everything

#253
post #47

Earlier quoted context omitted.

DISCLAIMER: I write mostly java, at home and at work. Refactoring goes a lot further than just renaming types. A refactor script _WILL_ rename both sides of 'Foo x = new Foo();' to 'Bar x = new Bar();', so given the right utilities (and if you use java for everything, it's _MUCH_ easier to become an expert at the tools!) this is not any more effort at all. However, there are refactors for things that are much more di…

Refactoring goes a lot further than just renaming types. A refactor script _WILL_ rename both sides of 'Foo x = new Foo();' to 'Bar x = new Bar();', so given the right utilities (and if you use java for everything, it's _MUCH_ easier to become an expert at the tools!) this is not any more effort at all. Ctrl-Shift-R B A R No, not much effort at all. Just twice as many keystrokes. I wouldn't even mind the verbosity if…

Counting keystrokes in programming is like counting letters in a novel - the amount of time put to think of something, to discuss it, takes the vast majority of time. Keystrokes used to write something is irrelevant (especially if you type with more than 2 fingers)

And if the whole arguments boils down to Java not having a var/val keyword - yes, that would be handy; but you would then still need tools to figure out what is the type of val foo = calculateSomething();

Re: Java for Everything

#254
post #160

Earlier quoted context omitted.

> 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…

i use PHP and i got customers and revenue and retention rate too facebook use php deal with it programming language is one thing, marketing your solution is another thing

facebook is using php compiled to C++, and that's only for their frontend. Mind your anecdotal evidence :)

Re: Java for Everything

#255
post #169

Earlier quoted context omitted.

So what? For most problems there are fast, well-designed libraries available with idiomatic python interfaces; why would you care about the implementation details?

Note, this is coming from the same guy who programs in x, which was also implemented in C(++). Like the JVM, CLR ad nauseum. :)

Do you know that there are JVM and CLR meta-circular implementations, right?

And that the reference implementations get less C++ code with each release.

Re: Java for Everything

#256
post #169
post #28

Earlier quoted context omitted.

And all the fast ones aren't implemented in Python....

So what? For most problems there are fast, well-designed libraries available with idiomatic python interfaces; why would you care about the implementation details?

Because the whole point of the OP is being able to use the same language for the whole stack.

Re: Java for Everything

#257

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.

While I do think Java is great I think that's an exaggeration, I'm sure there are quite a few deal-breakers for particular uses. Personally I've opted not to use Java before because it cannot compile to a self contained native binary.

Java projects can be compiled to a self contained native binary using http://www.excelsiorjet.com/ (though this is a proprietary tool, with a gratis license option for non-commercial projects).

Curious: why is this a requirement for you?

Re: Java for Everything

#259
post #163

Earlier quoted context omitted.

Ant has a bad reputation? I clearly didn't get the memo - I find Ant to be a great little tool.

I've used Ant, Maven, and Gradle, and Ant is the only one that's never given me a minute's trouble. But it's true that it has a bad reputation. It feels harder to use when everything is working right.

Agreed, find errors in Ant scripts is a pleasure compared with piles of Maven plugin errors.

Re: Java for Everything

#260

Earlier quoted context omitted.

Keep in mind that JAX-WS with JAX-B beats other rival libraries in other languages. If your requirement is to be a client that consumes SOAP web service given wsdl, I'd take Java any given day. The wsimport and wsdl tool that JDK provides beat any libraries. Also, JAX-B annotation can serialize and deserialize to JSON given the right provider. That's JSON, XML with POJO with the price of one. Good example of Java eco…

False. If you use a language that's homoiconic (any Lisp), you don't need to serialize anything. The source code of the language is already in its serialzed form. You can't beat the speed of not having to do something in the first place. As an aside, no sane person would write a SOAP webservice today.

You've clearly never tried to implement a REST API using any flavor of Lisp before. Guess what: most clients of web services understand JSON and XML, not S-expressions.
Post reply on HN