[Melbourne-pm] Stack traces

Adam Clarke adam.clarke at strategicdata.com.au
Tue Feb 12 21:30:56 PST 2013


On 13/02/2013, at 4:21 PM, Andrew McNaughton <andrewmcnnz at gmail.com> wrote:

> On 13/02/13 15:41, Toby Corkindale wrote:
>> On 13/02/13 13:02, Sam Watkins wrote:
>>> On Wed, Feb 13, 2013 at 10:50:56AM +1100, Toby Corkindale wrote:
>>>> I've seen Java stack traces that are easier to figure out than this.
>>> 
>>> <snip 646 line stack trace>
>>> 
>>> Frankly, I think the solution is - don't use all that ridiculous
>>> bloated crap!
>>> Keep it simple.  If you can write it in one line, do so;
>>> Don't write 20 pages when 1 will do.  Don't use bloated 3rd party
>>> modules,
>>> only if they are as clean and simple as possible for the necessary task.
>> 
>> It's not really as simple as that.
>> 
>>> Read "The Practice of Programming" ...
>>> Chant "Simplicity, Clarity, Generality" ...
>> 
>> But there's also: Don't Repeat Yourself.
>> Don't copy and paste code around when you could use a single package.
>> But as requirements get more complex, so do your dependencies, which
>> may themselves be simple, but be made up of many further dependencies.
>> Even if they are all relatively simple in and of themselves, the
>> combination of all grows complex.
> 
> So we have simplicity at the top level with all the complexity hidden,
> until you get to the stack trace.  If you're using the same frameworks a
> lot and want to hide the complexity in the stack traces too, it likely
> makes sense to write something to filter the stack traces to recover the
> simplicity there.
> 
> Of course this also exaggerates the tendency for the programmer to lose
> track of the performance implications of all that complexity they're
> hiding.  Sometimes it matters.

Please note, tongue firmly on cheek!

So we have a choice. We can stand on the shoulders of giants, sometimes 
slipping off  and falling into their excrement. Or we can stand on a pile of
our own excrement desperately trying not to sink into it before we reach
the level of those shoulders.

Sounds to me like we are stuck between a sometimes soft place and an
always soft place ;)





More information about the Melbourne-pm mailing list