* Rule 1: You cannot tell where a program is going to spend its time. Bottlenecks occur in surprising places, so do not try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
* Rule 2: Measure. Do not tune for speed until you have measured, and even then don't unless one part of the code overwhelms the rest.
* Rule 3: Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
* Rule 4: Fancy algorithms are buggier than simple ones, and they are much harder to implement. Use simple algorithms as well as simple data structures.
* Rule 5: Data dominates. If you have chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
* Rule 6: There is no Rule 6.
Name:
Anonymous2008-02-12 21:59
"This is the Unix philosophy:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface."
-Doug McIlroy
Name:
Anonymous2008-02-12 21:59
1. Small is beautiful.
2. Make each program do one thing well.
3. Build a prototype as soon as possible.
4. Choose portability over efficiency.
5. Store data in flat text files.
6. Use software leverage to your advantage.
7. Use shell scripts to increase leverage and portability.
8. Avoid captive user interfaces.
9. Make every program a filter.
-Mike Gancarz
Name:
Anonymous2008-02-12 22:03
first one, of course, is by Rob Pike
Name:
Anonymous2008-02-12 22:07
and reading this, he was enlightened.
Name:
Anonymous2008-02-12 22:17
*7
Write all your code in Scheme to please Sussman & Co.
Name:
Anonymous2008-02-12 22:45
Write programs using C++ or Java, as these are the most commonly used.
Write programs using Design Patterns.
Search on google first before starting.
>>11
I suspect he means that either data structure design is more important than algorithmic selection/optimization, or that programs should always concentrate on the data they manipulate instead of how they manipulate it, but just said it like a faggot, possibly because he is a faggot, seeing as both points are riddled with bullshit.
Agreed, it's simply not the ENTERPRISE way. As we all know, there are 3 pillars to ENTERPRISE: J2EE, SQL, and XML. I said XML
, not text files! Did I ask for a text-fileable markup language? hell naw .
>>20
Which is a load of bullshit. There are too many ways to do things, and requirements change over the years, hardware performance changes over time (from loop unrolling destroying cache space, to multicore now speeding up different things), to say "the best will be obvious". Seriously, the inventors of Unix were at the fucking newbie stage of computing.
Name:
Anonymous2008-02-14 1:25
>>25
Okay, I now think Rob Pike is awesome from reading his quotes on wikipedia:
* "Not only is UNIX dead, it's starting to smell really bad." - circa 1991 [1]
* "Object-oriented design is the roman numerals of computing." - [2]
* "There's no such thing as a simple cache bug." [3]
* "Caches aren't architecture, they're just optimization." [4]
* "Sockets are the X windows of IO interfaces." [5]
* "Sometimes when you fill a vacuum, it still sucks." - on the X Window System [6]
* "Unix never says `please.'" [7]
* "Those days are dead and gone and the eulogy was delivered by Perl."[8] - on one tool for one job
* "I started keeping a list of these annoyances but it got too long and depressing so I just learned to live with them again. We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy."[9]
1. Make stuff as obscure as possible.
2. Generate a 800kb autoconf file for it so it will fail to compile with different error messages on different systems.
3. RTFM
>>29
lol autoconf/automake/etc. fucking suck ass to configure. actually using them isn't hard because they usually give pretty good messages, usually telling you what libraries you need.
Name:
Anonymous2008-02-15 1:44
>>28
Don't forget checking for a Fortran compiler when configuring a program that only uses C.