On 3/29/10, Eris Discordia <eris.discor...@gmail.com> wrote: >> 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 >>> >>> >>> >> > > > > > >
Without reading your post: No, just ... that sometimes less is more.
