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

221–230 of 344 posts

Re: Java for Everything

#221

Post by Osmose »

edwinnathaniel wrote: post #103
Osmose wrote: post #81

A significant amount of the article is arguing that Java for everything is better because the author and his coworkers already knows it. I can make the same argument for Python _for me_. And for my company too; we have a ton of Python developers already, so it makes sense to write things in Python if possible in case someone needs to change or improve anything. The author also talks about how Java's verbosity is a tr…

Though the lack of noise could also translate to parsing things in my head trying to understand what is happening in this super short code....hence it takes longer to read the code!

True! It requires some skill to write concise code that can be understood easily. I think that the required verboseness of Java makes things worse than the potential for excessively-short code does in Python, though.

Re: Java for Everything

#222

Post by diltonm »

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 was with you until the Lambda stuff. I find the anonymous class _far_ easier to read and code.

Re: Java for Everything

#223

Post by diltonm »

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?

Google's GSON is the one I've turned to on several projects.

Re: Java for Everything

#224

Post by thanksgiving »

lmm wrote: post #160
twic wrote: post #152

Earlier quoted context omitted.

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

> I expect those four guys won't keep their system in Rails forever.

For people who didn't know this, I would like to add that Twitter was written in Rails as well. They switched later on for a couple of reasons[stackoverflow].

[stackoverflow] https://stackoverflow.com/questions/9747857/why-couldnt-twit...

Re: Java for Everything

#225

Post by diltonm »

untitaker_ wrote: post #20

The JVM is not usable for short-living processes such as command-line tools. Apart from the ecosystem and the language itself, it's often the reference (or only) implementation which makes it unsuitable for a particular job.

I don't understand the argument, I've used it for several small CLI tools, it works great.

Re: Java for Everything

#226

Post by diltonm »

SixSigma wrote: post #80
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…

That's why I like Limbo and later Go's implicit typing: a := Foo(): a now has whatever type Foo() returns. If you change the definition of Foo then you don't have to cascade your type change through all of your source code.

I hesitate to even begin to imagine the kinds of bugs this could lead to.

Re: Java for Everything

#227

Post by diltonm »

MarkMc wrote: post #163
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…

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

Agreed, ant is solid, the build system makes sense and is clearly laid out.

Re: Java for Everything

#228

Post by choicenotchance »

I would say that making something fast and effectively in Python (or such languages), and then scaling their apps by rewriting them (or the core) in Java/C++, is the way to go.

Nobody should be preemptively think of Python as a bad language for enterprise apps. That's the gist that I'm getting from this article. That is total baloney.

We have written enterprise apps in Django for a lot of clients, and all of them are working just fine. Not all of them get the traffic that twitter gets, but even scaling in Python is possible, and although it may require many more servers and top notch optimizations, it's still better to have it up and running from idea to app in about 2-3 months rather than spending about a 8-12 months doing it in Java.

BTW, if I were to switch to Java for projects that have the potential to grow to Twitter's scale, what's the most Django like framework in it?

Re: Java for Everything

#229

Post by Turing_Machine »

Turing_Machine wrote: post #213
applecore wrote: post #195

> You can complain all day about public static void main, but have fun setting up 500 servers. The downsides of dynamic languages are real, expensive, and permanent. Love this quote. This is a thought-provoking article, even if you don't agree with everything as stated.

500.times {ec2.instances.create(:image_id => "ami-foobar")} Or if you want to own the hardware, you can do the equivalent with a Chef script, or a Puppet script, or.. No one is going to set up 500 servers by hand.

The point being that you can start 500 servers with a trivial amount of effort, rather than it being some kind of major undertaking as the author pretends. This is 2014, guys. You don't have to unbox and plug in all the HDs yourself.

If they're (e.g.) ec2 microinstances, 500 servers would cost you about $6,000/month, which is comparable to the monthly cost of just one extra programmer (maybe much less, if you're in a high wage location and you add in all the benefits, etc.) And remember, that's assuming you're operating at reddit scale, which, to be blunt, you're not likely to be doing.

The article is full of similar handwaving (e.g, "it's only 3 extra characters" when most class names are far longer than 3 characters, and you also have to multiply that extra typing by the number of lines in your codebase).

I'm glad Java works for him. Me, I abandoned it around the year 2000 and have never looked back.

Re: Java for Everything

#230

Post by waps »

desdiv wrote: post #202
waps wrote: post #145

Earlier quoted context omitted.

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

Still don't understand. Let's take the changes you need to make :

  Foo.java
    ...
    class Foo {
      ...
    }

  SomeOtherFile.java
    ...
    Foo x = new Foo();
    ...
Equivalent in Python:

  some_file_in_a_library.py
    class Foo:
      ...

  some_other_part_of_the_program.py:
    x = Foo()
Keystrokes to change the name "Foo", in Java :

1) Position cursor on Foo.

2) Alt-shift-R "Bar" (+ enter)

Keystrokes to change this name, in Python :

1) position cursor on Foo

2) Change to bar (5 or 6 keystrokes)

3) Open some_file_in_a_library.py (couple dozen keystrokes, most people I see do this have to switch to mouse and use that)

4) Change the classname

5) Go through all the unit tests that you should have that test the class (you need 5x more unit tests in Python compared to Java as well, to have equivalent tests), and do the same. Yes, all of them.

Java wins out, by a factor of 3, maybe even 5. Even if the class definition and the usage were in the same file, it would still win by a lot.

Refactoring simply doesn't work reliably in Python. Heroic efforts by Jetbrains notwithstanding, it just doesn't compare.

So I don't see what you're complaining about. Making changes is only faster in Python in tiny programs, where you don't have the problem of interdependencies. As soon as you have some of them, Python starts losing out, bigtime.

Post reply on HN