
Java: Real or Not? - mechazawa
http://java.metagno.me/
======
overgard
It never hurts to study the masters in serious enterprise software:
[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

~~~
gfodor
This is great but it brings up a serious question I've always had. Taken to
the extreme, things like the single responsibility principal, the open closed
principal, etc, result in messes like this. I've been wondering if anything
has been written around a concrete methodology of doing OOP that doesn't
naturally converge onto something like this, and why it happens.

~~~
ignoramous
It is fancy around these parts to bash OOP and other things that aren't
JavaScript/Clojure/Haskell/Rust/etc;

DRY, SRP, LSP, OCP are very valuable. There's a reason there's a score of
enterprise-grade software being written with exactly those principles in mind.
I am not discounting Functional Programming in anyway. But to dismiss OOP and
the design patterns is a fool's errand. It has its place, and rightly so.

Look at what the programming Lords (Ken Thompson! Rob Pike! Lars Bak!) at
Google came up with when they sat down to design a language-- Go (which is
part-OO, part-imperative [1]), or Dart (OO again). OO detractors often point
out that "popular opinion isn't always right" and that "people are afraid of
change" and there's some level of truth to that, but the fact is, a lot of
developers out there are proficient with OO, and see it as a good way to
develop massive programs (1 million plus SLOC) unless some radical shift
happens in the coming years [2].

[1] [https://golang.org/doc/faq#Is_Go_an_object-
oriented_language](https://golang.org/doc/faq#Is_Go_an_object-
oriented_language)

[2]
[http://worrydream.com/LearnableProgramming/](http://worrydream.com/LearnableProgramming/)

~~~
sparkie
The problem isn't that those principles are bad - they're useful - but the
languages we're attempting to use them from are not sufficiently expressive
enough to follow them all in a practical way. "Design patterns" and DRY don't
mix very well - because the act of implementing a design pattern is largely
repetitious. We create XFactory, YFactory, ZFactory for example, with largely
the same structure but slightly different logic - then someone takes DRY to
the extreme and tries to abstract it away into a FactoryFactory, using
reflection or some other tool to get around the host language's lack of
expressivity.

This is where the mess begins, because it becomes so cryptic to figure out how
to use the FactoryFactory to create your own Factory to create some other
types you need. It may be trivial to people who've been hacking with the same
languages and frameworks for years, but the principle of least surprise is
abandonded for new users attempting to use a framework for the first time.

Functional programming suffers from the same overuse of idioms which are
unwelcoming to novices, and often throws away some useful ones in favor of
ease of use. FP doesn't necessarily dismiss OOP, and it's often used in
combination with functions to write practical programs.

Functional programmers don't see OOP as a problem - it's a very practical
tool. The problem is that it's the wrong tool for many problems - particularly
if you're just computing functions[1]. That a lot of developers are proficient
with OOP and see it as a good way to develop programs is part of the cause -
they're blind to alternative methodologies and shoehorning something into an
object where it doesn't fit is seen as a being skillful. Also, anything that
doesn't conform to the language's narrow view of "the right way" is considered
an anti-pattern.

[1]:[http://www.yegor256.com/2014/05/05/oop-alternative-to-
utilit...](http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-
classes.html)

------
Nitramp
The names are extremely predictable (as shown by this Markov chain), which is
actually a Good Thing (tm). The bad thing is that things got complex enough to
warrant these names.

It's the knee jerk reflex of decoupling everything, to the point that you have
80% configuration/wiring/setup vs 20% of code that actually does something
useful.

Each extension point in the framework is represented by a couple of these
classes to handle the layer of indirection. Maybe Spring should run a study
and see which of their extension points is actually used, at all, or by more
than x % of users, and then cut down all the useless ones. I'm not too
familiar with Spring these days, but I'd expect that the vast majority of
indirections isn't actually useful for anybody.

The other problem is that our mechanisms to introduce and handle these
abstractions are too verbose. Each extension point spawns multiple classes
where it's really just one little method that needs to be called instead of
another block of code. That makes software systems extremely hard to
understand and use, and the overall bloat does actually slow things down - if
not in production, then in deployment, startup, and build.

~~~
acdha
> Maybe Spring should run a study and see which of their extension points is
> actually used, at all, or by more than x % of users

That last part seems key: I'd be shocked if you didn't find someone, somewhere
for every one of those features – and, based on some of the enterprise apps
I've seen, doing so because it allowed a quick hack rather than solving a
problem more correctly and expensively. The question really should be “Is the
value from having this work the non-trivial obscurity and maintenance cost?”
to emphasize that features and extensibility aren't free.

------
parasubvert
This is sort of like making fun of German for using long combinations of
smaller words to denote a concept.

Or making fun of medical jargon. (ha ha, you said subdermal hematoma not
bruise)

Once you know what the individual words mean, you can use them in different
places, and know right away what the class does. Do you need to use 80% of
these? No, but they're there, like parts in a car, in case you need to tinker.

~~~
the8472
And it's not like anyone is typing these words out. IDEs have auto-completion
for that purpose.

~~~
therealdrag0
Moreover, in Eclipse you can do camel-case completion. So you can type "ACV"
and get "AbstractCookieValueMethodArgumentResolver". (I'm not sure if other
IDEs do this)

~~~
bitmapbrother
I believe IntelliJ does this also, but Eclipse did it first.

------
soup10
Most of the atrocious stuff is in J2EE related frameworks (looking at you
spring and hibernate).

I think core java libraries are amazingly designed and a good part of why the
language became popular. You won't find many FactoryFactories there, The land
of c,c++ libraries that came before is incredibly fragmented, inconsistent and
difficult to use by comparison, not to mention the documentation. Good lord
the docs ;x.

------
mkozlows
It's not surprising that a Markov chain could put together plausible sounding
class names, because yeah, there are definitely patterns that class names fall
into.

What's surprising is that one third of the names it's showing me are actually
real. I mean, "MetaMetaContextHierarchyConfig" actually exists?

~~~
McGlockenshire
> I mean, "MetaMetaContextHierarchyConfig" actually exists?

Apparently.

[https://github.com/spring-projects/spring-
framework/blob/mas...](https://github.com/spring-projects/spring-
framework/blob/master/spring-
test/src/test/java/org/springframework/test/context/hierarchies/meta/MetaMetaContextHierarchyConfig.java)

"Custom context hierarchy configuration annotation that is itself meta-
annotated with MetaContextHierarchyConfig"

~~~
agency
It's worth pointing out that this is test code.

------
elevensies
Are the generated names verified to be non-real? There could be some overlap.

~~~
guard-of-terra
There is definitely overlap, it tells me that HttpSession is not real, and
guess what,
[https://docs.oracle.com/javaee/6/api/javax/servlet/http/Http...](https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSession.html)

~~~
icebraining
The real ones are supposed to come from Spring, not the Java stdlib.

------
haddr
Some answers are not 100% right. I got:

\- HttpServlet

\- AbstractXmlWebMvcResultProcessingInterceptorAdapter

\- MockJtaTransaction

While there is HttpServlet class, it is considered wrong, and 3rd option is
considered correct :(

~~~
mike_hearn
It's only talking about classes from Spring specifically. HttpServlet isn't a
Spring thing.

~~~
Terr_
That makes it even-more-pointless. It's like people criticizing command-names
in linux and going "LOL a computer made that one" even though the command
actually exists in another distribution or shell.

------
clamprecht
Are you calling the Spring developers Markov chains?

------
tibiapejagala
I don't like complaining about submissions not working in my browser, but this
time I feel like I'm missing a lot of fun.

On Firefox DevEdition nothing past "Pick the one that's not made up!" appears.
On latest IE it's every time "ComplexPortletApplicationContext.EditController"
vs "ModelMapBasedHandlerMethodProcessor" vs
"AbstractPlatformTransactionAttributeSource". 16 times the same question.
Well, this could be just bad luck if questions are random. With randomness you
never know.

~~~
Nikhil_teja
Trust me you are having more fun than anybody out here.Unless being humiliated
in a way that you will never dare claim mastery on any thing (even when its
the only thing that you think you are good at) sounds like fun to you ;)

------
lkrubner
"The principle of least surprise" is sadly missing from this API.

~~~
lmm
Not true. The reason these class names are so long is that they explain in
great detail what the class does.

------
kaddar
Note that some classes exist (even if not in Spring, at least in base Java)
[http://imgur.com/sNk4mE2](http://imgur.com/sNk4mE2)

The key thing to keep in mind with generative models based on real data is
that just because results were based on random generation doesn't mean they
can't match something real.

------
dmcg
Nice. We made fridge-magnets in my last project to help generate excellent
names like these.

~~~
therealidiot
Haha, I need to try this but for the whiteboards at work. We sometimes try to
come up with ridiculous names too

------
impostervt
Spring is not the only framework with bad names; look at this class name from
aspectj:

org.aspectj.weaver.patterns
.HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor

------
billrobertson42
It's utter bullshit to conflate Spring and Java like this.

------
ibejoeb
It's been a few years since I've seriously used Spring, but I when I did, I
used the hell out of it. I'm pretty surprised by how many times I was fooled.

------
dschiptsov
Like any other primitive, dogmatic religion, Java will stay for ages, because
there will never be a shortage of idiots to repeat the dogmas and mediocries
to have a decent living by manipulating the crowd.

Java is triumph of the "packers mindset".

[http://the-programmers-stone.com/the-original-talks/day-1-th...](http://the-
programmers-stone.com/the-original-talks/day-1-thinking-about-thinking/)

~~~
peterashford
This post perfectly sums up a mindset I detest. Engineers get shit done and
don't care about whatever the most recent hipster programming language is.
They can probably spell "mediocrity" as well.

~~~
wumbernang
I'm with you.

I really don't think people with that mindset could put together the sort of
shit we do on the enterprise mindset side of things. The tools are carefully
picked to be entirely the opposite to the contrarian mindset.

So we have a system that has about 500 HTTP endpoints, 600 service endpoints,
4MLoC, several TiB of data, several TiB of documents, handles 5000 concurrent
users 24/7 ramping up to 2 million euro consumers (not concurrent) and 10 full
42U racks of kit in two facilities. Oh and strict security isolation through
several layers.

Java+c# is the only answer.

But 50 times a day someone says, hey rewrite it all in Ruby and Monogo. That's
a joke.

~~~
danieltillett
Out of curiosity does your system need to be this complex? Could it have
broken down into smaller sub-systems that maybe aren't as integrated, but get
the job basically done?

~~~
wumbernang
70% of this is required to be this complex as the sector we work in is very
rule and workflow heavy and the customisation support is immensely
complicated. 30% is hacked in stuff for single clients and legacy stuff from
the dark ages that we had to hang on to.

We're breaking it down into tiny subsystems at the moment i.e. moving to a
microservices architecture. I'm describing the "monolith" that we're starting
from.

In time it'll have 1/2 the code, 2-5x the throughput and significantly less
cost.

------
peterashford
Nice job blaming all of Java for Spring's foibles

------
davelnewton
The chained names are often too long; I find it hard to believe that my very
rusty Java/Spring is the reason I got almost all of these right.

~~~
antod
Rusty Spring? Reminds me of that literary classic by I.P. Knightly.

------
jhallenworld
It amuses me that names in Verilog 1995 (a language with no structures) look
pretty much the same: oc48_transp_decode_data.

------
ExpiredLink
HN goes reddit. Java, oink, oink, lol!

