Live data from Hacker News

Java for Everything

teamten.com

201–210 of 344 posts

Re: Java for Everything

#201

Earlier quoted context omitted.

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.

I wrote a SOAP webservice -- not because I'm insane, but because our business relies on data sent to us. We could certainly tell everyone that they'll need to write code to send us the data we need to be of use to them. Or we could look at the installed systems that hold their data, and see what built-in support those systems have for external integrations. And so: we quickly added a simple SOAP endpoint. About seria…

So you're consuming data of an existing (legacy) SOAP service? Or complying with exisiting clients of a (legacy) SOAP service? That's not the same as writing a new SOAP service.

If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. This is the very essence of languages that are homoiconic. Perhaps you should familiarize yourself with that before down-voting what I have to say about it.

Re: Java for Everything

#202
post #145
post #47

Earlier quoted context omitted.

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…

I don't understand the point. Are you claiming that search and replace functionality provides the same ease of use as an actual rename refactor ? Foo x = new Foo(); int Fool = 5; I'm sure you see the problem. Dynamic languages are great, until the program grows. Then you hate yourself for having picked a duck/dynamic typed language (including Go, btw : programs become unmaintanable if they grow, not as bad as python…

I don't understand the point. Are you claiming that search and replace functionality provides the same ease of use as an actual rename refactor ?

No, I'm saying you need extra key strokes to activate that rename refactoring functionality, which is unnecessary in an ideal situation.

To refactor the java code

    Foo x = new Foo();
you need to hit the key combo to active your IDE's refactoring thingy, then type the new name.

To refactor a less verbose statically typed language:

    x = new Foo();
You just type over the old name, no refactoring key combo necessary.

This discussion isn't about static versus dynamic. It's about useless verbosity versus less useless verbosity.

Re: Java for Everything

#203

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…

Or in Clojure, it's

(sort #(compare %1 %2) coll)

To reverse it

(sort #(compare %2 %1) coll)

Where coll is the collection you want to sort. Same caveat applies with:

(reverse coll)

Try as I might I can't get Clojure to bench slower than its comparative Java. I see no reason to program in Java anymore wherever possible.

Re: Java for Everything

#204
The argument can be made both ways. One can say that Python is better cause readability.

Many can give examples of successful or failed projects in both languages but it's just conjecture.

The only correct way to look at language choice, and the only objective one, is to use the language you are productive in. The best language is the one you master.

Re: Java for Everything

#205
post #65

Earlier quoted context omitted.

In current version of Groovy you can mix static and dynamic typing in different sections of code by telling the compiler what are your preference.

Why would you ever _not_ want typechecking?

Static typing comes with benefits and costs. If you don't want to pay the costs and can forego the benefits, dynamic typing is fine.

Re: Java for Everything

#206

You have to admit that for coders, the joy of writing helps a lot for job satisfaction. I write both Java and Python (for very different applications) and I just always feel like Java makes it hard to write anything elegant almost on purpose. The proliferation of huge frameworks and FactoryFactories clearly doesn't help. I think you can underestimate the value in actually enjoying writing - I'm just more motivated ev…

With dependency injection you dont need factories.IoC containers will make write you way less code.And they scale better.

Re: Java for Everything

#207

Earlier quoted context omitted.

I wrote a SOAP webservice -- not because I'm insane, but because our business relies on data sent to us. We could certainly tell everyone that they'll need to write code to send us the data we need to be of use to them. Or we could look at the installed systems that hold their data, and see what built-in support those systems have for external integrations. And so: we quickly added a simple SOAP endpoint. About seria…

So you're consuming data of an existing (legacy) SOAP service? Or complying with exisiting clients of a (legacy) SOAP service? That's not the same as writing a new SOAP service. If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. This is the very essence of languages that are homoiconic. Perhaps you should familiarize yourself with that be…

>If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it.

Yeah. If only that language and "not needing serialization" code format didn't have 200 other problems, like NONE of the major services accepting it, lack of tooling, a sorry state of an ecosystem, difficulty of finding programmers and/or jobs, etc...

Re: Java for Everything

#209
post #175

Do Java/JVM folks miss the simple deployment of Go? I haven't used Java for a while (used Jetty to deploy), but words like "application servers" are the things that make Java sound "heavy".

I think most people are using embedded Jetty or Netty (or even Tomcat in embedded mode) so deployment is just a jar that can be run with any old JRE.

Re: Java for Everything

#210

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…

>>Java8's lambdas + streams provide significant improvements.

It will take more than a decade before we see any decent adoption of Java 8 in the industry.

You are still going to see piles and piles of getters/setters, Enums, your design patterns taken to far extreme. Writing such pointless ceremonial code is the bloodline of Java community.

Merely introducing a new version hardly changes anything.

Post reply on HN