[Melbourne-pm] Stack traces

[Andrew McNaughton]

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.

Andrew