
Friends don't let friends do Java - 0xmohit
http://www.teale.de/blog/friends-dont-let-friends-do-java.html
======
nnq
_Wow, a language that actually allows you to build such complex abstractions
without getting lost in them, runs them fast enough, and gives you tools to
debug them. That 's... COOL!_ It makes me a bit sad I spend my workdays in
dynamic languages where sometimes the framework/runtime "swallows" any
meaningful stack trace when some "magic code" gets called and you revert to
stone-age print/log debugging...

Now, about the people that went on on to actually pile so many things on top
of each other, just because they knew the language and tools were strong
enough to _let_ them do this _up to a point_... nothing good to be said.

 _But I 've personally grown to admire languages and tools that give you
enough high quality rope to hang yourself properly and thoroughly :)_ In the
end, you can never blame _the rope_ for the idiot hanged with it...

------
agf
I can't post the actual backtrace, but looking at the most recent error email
I received from a Rails app, the backtrace is over 300 calls deep.

50 New Relic, 50 ActiveRecord, 100 ActiveSupport, 50 misc Rails / Rack, and 50
everything else.

This is not a Java problem.

~~~
bazzargh
Rails comes with a backtrace cleaner, that by default excludes lines that
aren't from your app; it's based on an extensible BacktraceCleaner in
ActiveSupport.

[https://github.com/rails/rails/blob/master/railties/lib/rail...](https://github.com/rails/rails/blob/master/railties/lib/rails/backtrace_cleaner.rb)

Perhaps you've disabled this? (FWIW, I don't mind the longer backtraces as
they help in understanding thornier problems.)

~~~
agf
Yeah, we definitely need the full backtraces as we've significantly customized
rails so seeing the full call stack is important.

It's not seeing a long backtrace that bothers me, it's the callstack being
that deep to begin with. In my experience, it makes debugging slower and more
difficult. If you're 30 calls deep, figuring out where you ended up in the
wrong branch of a conditional is much easier than when you're 300 calls deep.

------
Tharkun
Oh no, a deep stack trace, better blame Java. Excuse me while I go roll my
eyes for a bit.

~~~
Annatar
It goes against the core UNIX tenets: simplicity and modularity, which state:

 _design for simplicity; add complexity only where you must_.

 _Write simple parts connected by clean interfaces_. [Kernighan-Plaguer]

[http://www.catb.org/esr/writings/taoup/html/ch01s06.html](http://www.catb.org/esr/writings/taoup/html/ch01s06.html)

------
jakobegger
Now, I'm not familiar with Java, but I don't get what's supposed to be bad
about a deep stack trace.

Sure, in the old days, we had one giant function that did all the work, and we
had a shallow stack.

But if your code is composed of simple methods that do just one thing, you'll
end up with very deep stack traces.

Every modern framework has deep stack traces.

Yes, you need to invest some time in the beginning to understand how the
different parts work together, but once you do, you'll see the beauty and
clarity when all the abstractions are in the right places, and doing what you
want requires just a handful of carefully sprinkled lines of business logic,
with the framework doing much of the heavy lifting for you...

~~~
Arelius
Are you implying that a long call stack is better than a long function? At
least you don't have to have a debugger to read the long function.

~~~
matthewmacleod
Long call stacks are better than long functions, yes.

If a function runs on for more than a few lines, it feels like it rapidly
becomes more difficult to reason about it. More mental overhead is required
and more moving parts are in scope.

Long stack traces might mean you have to read more whole debugging, but it
also means there is less code to debug for a given failure - assuming
modularity!

------
bad_user
That's not Java.

Friends don't let friends use Tomcat/JBoss, Spring MVC, AOP _Whatever_ ,
Hibernate and all that related crap.

Java is a big ecosystem. There's crap in it, as a consequence of it being big.

~~~
objectified
Although you're right, one could argue that this is the world you most likely
end up in when you "do Java", as most Java job openings seem to list at least
one or two of the frameworks you mention, as compared to the job openings for
something that would look more like core Java oriented as opposed to
"Enterprise" oriented.

I have learned that when choosing a language to specialise in, you also choose
the culture around it, which becomes very important when you live in it every
day.

------
pkd
More like Friends don't let friends do web development.

------
davedx
Try a Scala stacktrace if you think that's bad.

You could argue it's a consequence of well designed abstraction, though.

~~~
idobai
I've never met with (large) stack traces in Scala because throwing exceptions
is NOT ok in Scala. But can you share your experience?

~~~
gozur88
So you're not supposed to tell people where errors occur in Scala? Is that
like Inigo Montoya fighting with his left hand, because otherwise it's too
easy?

~~~
idobai
> So you're not supposed to tell people where errors occur in Scala?

You're supposed to use the types `Option` and `Either` or if you're into
scalaz then \/ ([http://eed3si9n.com/learning-
scalaz/Either.html](http://eed3si9n.com/learning-scalaz/Either.html)) and
Validation ([http://eed3si9n.com/learning-
scalaz/Validation.html](http://eed3si9n.com/learning-scalaz/Validation.html)).
Throwing exceptions is a childish way to handle errors in FP.

~~~
gozur88
I don't see why anyone would find this superior to a stack trace.

------
kodfodrasz
How did this poor trolling en up on the top of my HN opening page?

~~~
Apocryphon
Everyone loves a graphic that illustrates information.

------
abalone
To be fair that's really "Friends don't let friends do Spring".

------
vhogemann
People like to point at a Java stacktrace and mock... but actually that's a
awesome part of the language. You can actually get a good grasp of what went
wrong just from taking a close look at it.

Of course other languages have informative stacktraces as well, but IMHO Java
has the most readable, complete and useful one.

------
ers35
See the original: [https://ptrthomas.wordpress.com/2006/06/06/java-call-
stack-f...](https://ptrthomas.wordpress.com/2006/06/06/java-call-stack-from-
http-upto-jdbc-as-a-picture/)

~~~
jessaustin
Hahaha, click through to the RoR post, in which Zed Shaw leaps to the defense
of the first Mongrel! Classic.

[EDIT:] Actually this link should replace TFA, since TFA is a single image
ripped from this link which has additional material to boot.

------
gozur88
Meh. That's web programming.

------
hipjim
stacktrace from hell - a consequence of stacking frameworks over frameworks.
This is the state of our craft as of today :(. This has nothing to do with
Java as a prog language. Java stack traces are quite nice :-)

------
hansjorg
Acegi was renamed Spring Security in 2008, so this is pretty old/legacy.

------
stuaxo
Seems like J2EE (OK Spring / Hibernate) is the problem here.

------
make3
joking on Java is so 10 years ago.

~~~
d_t_w
luckily the example stacktrace is from a blog written in 2006, so it's all
perfectly cromulent.

------
gariany
where is the retweet button?!

