In fact, we have both printed on paper hanging from the wall of the
corridor near our office. Let's hope they learn.
Learn to...
1. ... not comment their code?
2. ... not include usage instructions?
3. ... not heed that their code might need to compile on any one of a
number of platforms that are far from glitch-free?
4. ... not include a preamble introducing their file, automatically
assuming they work in "clean environs" where nobody except people they know
on a face-to-face basis commits to their code repository?
5. ... not accommodate their user base insisting they know better what's
good for the users thereby dramatically cutting down the number of people
who may want to merely use, and not hack, their code?
6. ... forget to see past appearances in others' code instead of simply and
rationally counting the lines of code in the body of function 'simple_cat'
for a proper comparison of equivalent functionality between a feature-heavy
'cat' and a minimalist 'cat' each with its own merits?
7. ... avoid provisioning for a time when 'coreutils,' in order to become
feature-heavy, will inevitably contain copious amount of code that needs to
be amenable to automated testing and documentation?
8. ... avoid any secondary optimization of their first solution under the
illusion that every optimization counts as the dreaded "premature
optimization?"
9. ... condescendingly refuse to write or maintain code that is capable of
cooperation with a dominant archaic design which can only be phased out
gradually?
10. ... allow themselves to be flattered by agreement from the close-knit
community of like-minded developers fully shutting their minds close to the
potential merits of functionally rival software?
Never mind my trolling. I just needed to attention-whore. Continue, please.
--On Thursday, March 25, 2010 22:17 +0100 Francisco J Ballesteros
<n...@lsub.org> wrote:
As a example for our students we use
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;hb
=HEAD
versus
http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c
In fact, we have both printed on paper hanging from the wall of the
corridor near our office. Let's hope they learn.
On Thu, Mar 25, 2010 at 7:51 PM, <blstu...@bellsouth.net> wrote:
in similar vein, there's this handful guide on how to make your life
really hard in 11 easy steps:
http://www.pixelbeat.org/docs/unix_file_replacement.html
make sure you check out the final copy.c linked at the bottom of the
page
It's a sign of the apocalypse. The configuration of the 6th edition
kernel Lions presented was about 10,000 lines of code. This version
of cp is nearly 1/4 of that, and the function copy_internal() is over
1000 lines long. I'm clearly not smart enough to function in a world
where cp is that complex...
Back to real work...again...for real this time...I promise...
BLS
