Hacker News Reader

It's entirely possible to write simple things in Java, without ESBs and a person-century of effort.

That I don't disagree with (see Java4K and various other demoscene-like competitions), but when the mainstream culture of Java is oriented towards architecture-astronautism and "enterprisey" bureaucratic excesses of complexity, that's what the majority of Java developers you find are going to do. Ask them why a simpler (and less time-consuming) solution wouldn't suffice and they'll respond with things like "robustness", "extensibility", "modularity", "encapsulation", "abstraction", etc. even when none of these properties are truly applicable to the situation at hand. If I were to guess why, they're just so accustomed to writing code with such indirectness that a simple solution feels "wrong" to them. I worked very briefly for a Java shop and on one occasion my code was rejected, and was told to "refactor" a fairly trivial 20-line method in one class into 8 separate classes each containing 1-line methods on account of the fact that my original code was not "extensible" nor "modular" enough. I was suggested to introduce a design pattern to do this. Any advantage of that extra flexibility was never realised since the application was eventually completely scrapped in a rewrite. (I left shortly after that.)

"was told to "refactor" a fairly trivial 20-line method in one class into 8 separate classes each containing 1-line methods"

How typical is this level of non-value adding misguided pedantism? I understand that big software consultancies would want to milk their clients for all the work they can for implementing function points. But what profitability models drive developers to this level of weirdness? Is it just a cultural pathology?

This is excessive but I've seen numerous similar cases. Premature code future-proofing has always struck me as similar to premature code optimisation. Generally something that newer/weaker devs tend to do until they learn better.

It's plain and simple pedantry, and it's not confined to Java. This mindset has a healthy representation in the Ruby community, which actually makes programming in Java much less distasteful to me -- if I'm going to be writing AbstractSingletonFactoryAdapters, then at least let my AbstractSingletonFactoryAdapters be fast.

Enterprise. It is just how the enterprise world works.

No it is not. Just because you have a one bad experience, doesn't mean that is how the enterprise works. There are hundreds of thousands of enterprise shops out there. We don't do anything like the craziness you guys are talking about. We make it work with the easiest code possible. If necessary we refactor when we need to make a solution more generic.

Java at Amazon, Google, Twitter etc. is generally less pedantic and more focused. I have been a Java developer since 1997 and the only time I've seen the type of pedantry you are talking about is at non-technology companies where the most important metric is how cheap a developer is, not how much value they can add.

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

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

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 :)

Actually, Facebook is using PHP executing on a JITting virtual machine:

https://www.facebook.com/notes/facebook-engineering/speeding...

Mind your out-of-date rebuttals to anecdotal evidence :)

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

I've never even heard of this. I agree with most of this advice, but, I wouldn't exactly call it a defacto standard.

My bad. I suppose i live in a bubble just like anyone else. I do think this is a well-known approach within the bits of software culture that talk about scalability. If you're a regular reader of highscalability.com, or a developer at Netflix, or one of the sad nerds who wish they were (eg me), or you've read the Heroku documentation, you've heard of 12-factor. But no, not everyone has, and in particular not every working stiff who shovels Java for a living.

Is there an update to this book or something similar that speaks to Java +7?

The book is mostly about the use of the Java EE APIs. As such, it's not all that affected by the evolution of the core language from 6 to 7 to 8.

However, it probably will be affected by the evolution of the Java EE API. EE 6 was a huge, massively simplifying, change from EE 5, which is why it needed a book like this. EE 7 was a fairly incremental change from EE 6, and EE 8 is set to also be a modest step forward.

The biggest change in EE 8 - and i don't know whether to laugh or cry about this - is that Java will be getting a standard web MVC layer. Fifteen years after such things first appeared on the scene, and five years after they became passé. Maybe there'll be an API for controlling dialup modems or AIM clients next.