NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
about I/O disciplines and I should retire to the Tassili-in-Aijer
mountains in Sahara as a camel herder :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Talks I Want to See (if not give) (Score:2)
One thing which surprises a lot of developers after they've been doing testing for a while is discovering that testing doesn't just make their code more reliable, it makes them a better programmer. Your functions tend to do less, but do it better. You learn to decouple things. You learn that your function with 13 arguments might be poorly designed. You learn how to write less code and get more done. You learn how to refactor safely. You design better APIs. You learn first-hand the pain of violating t
Re:Talks I Want to See (if not give) (Score:2)
I'd never heard of the Liskov Substitution Principle [wikipedia.org], but after reading the Wikipedia article it sounds like it's related to the protocol good neighbor principle "be lax in what you receive, strict in what you output".
Reply to This
Parent
Re: (Score:2)
Liskov is something that confuses a lot of programmers because it's often explain in arcane ways. Condider the explanation from the Wikipedia link you provided:
Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.
Well, that's true, but since most of us aren't computer scientists, it can be confusing, particularly since many programmers don't realize that classes are merely types and operators are merely shortcuts for met