From: David Leimbach <leimy2k@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Google finally announces their lightweight OS
Date: Thu, 9 Jul 2009 08:24:21 -0700 [thread overview]
Message-ID: <3e1162e60907090824ubc72a6cw6f43e8dd41469685@mail.gmail.com> (raw)
In-Reply-To: <fe291f2c118c277ff15583e342329ec5@quanstro.net>
[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]
Indeed, Voltaire had it right. Better is the enemy... (of my enemy is my
friend??)
On Wed, Jul 8, 2009 at 9:10 PM, erik quanstrom <quanstro@quanstro.net>wrote:
> > > I expect to see code immediately, by the way, finished or not, and you
> better be
> > > around to answer my questions.
> >
> > You have something here: these are central software-development tenets
> > of agile/scrum/xp/lean/kanban du jour, and help the open-source
> > community work. Essentially, "done" is an elusive illusion, so enlist
> > others throughout the process.
>
> i'm just going to take a guess that you have never had egg
> on your face caused by publishing code before it's time?
>
> i can't stand my own silly mistakes, unfinished and crap code.
> why should i look at anyone elses? by the way, can you
> name operating systems that develop in this way? i
> was under the impression that even, e.g., linux code is submitted
> in fairly complete fashion and tends to get rejected even
> on style grounds.
>
> i think the idea that is illusary is that there is no difference
> between code that doesn't work and code that does work
> but might be improved.
>
> part of the craft of programming is to know when something
> is actually finished. the mistake is to "improve" things that
> work well enough. i think one could write quite an interesting
> book critiquing modern software development for failing to
> stop at good enough. but one would need to be quite a bit
> smarter, more educated and less lazy than i. i'll satisfy myself
> by quoting some such people. (oddly #1 and #3 are missing
> from fortune)
>
> Rule 3. Fancy algorithms are slow when n is small, and n is usually small.
> - rob pike, Notes on Programming in C
> Inside every large problem is a small problem struggling to get out.
> - niklaus wirth
> When in doubt, use brute force.
> - ken thompson
>
> - erik
>
>
[-- Attachment #2: Type: text/html, Size: 2408 bytes --]
next prev parent reply other threads:[~2009-07-09 15:24 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-08 7:48 Aharon Robbins
2009-07-08 8:48 ` tlaronde
2009-07-08 9:02 ` Richard Miller
2009-07-08 9:23 ` tlaronde
2009-07-08 9:41 ` Richard Miller
2009-07-08 10:33 ` Uriel
2009-07-08 12:39 ` erik quanstrom
2009-07-08 9:28 ` Anselm R Garbe
2009-07-08 10:22 ` Uriel
2009-07-08 10:40 ` Richard Miller
2009-07-08 11:05 ` Uriel
2009-07-08 11:34 ` Anselm R Garbe
2009-07-08 12:07 ` erik quanstrom
2009-07-08 15:07 ` David Leimbach
2009-07-08 16:15 ` Balwinder S Dheeman
2009-07-08 16:27 ` erik quanstrom
2009-07-08 16:56 ` Devon H. O'Dell
2009-07-08 19:34 ` erik quanstrom
2009-07-08 19:41 ` Devon H. O'Dell
2009-07-08 19:47 ` erik quanstrom
2009-07-08 19:56 ` Uriel
2009-07-08 20:44 ` Noah Evans
2009-07-08 21:14 ` Dan Cross
2009-07-08 21:23 ` Devon H. O'Dell
2009-07-08 19:50 ` Uriel
2009-07-08 19:56 ` Devon H. O'Dell
2009-07-08 20:04 ` Uriel
2009-07-08 20:10 ` Devon H. O'Dell
2009-07-08 20:19 ` ron minnich
2009-07-08 20:25 ` Benjamin Huntsman
2009-07-08 20:30 ` Devon H. O'Dell
2009-07-08 20:44 ` Benjamin Huntsman
2009-07-08 20:32 ` John Floren
2009-07-08 22:21 ` Jason Catena
2009-07-08 22:41 ` Venkatesh Srinivas
2009-07-09 4:10 ` erik quanstrom
2009-07-09 5:43 ` Jason Catena
2009-07-09 17:48 ` Micah Stetson
2009-07-09 17:50 ` Devon H. O'Dell
2009-07-09 17:50 ` erik quanstrom
2009-07-09 19:47 ` Jason Catena
2009-07-09 20:29 ` tlaronde
2009-07-09 20:58 ` Jason Catena
2009-07-09 21:34 ` erik quanstrom
2009-07-09 21:44 ` Jack Johnson
2009-07-10 4:21 ` Bakul Shah
2009-07-09 21:59 ` Jason Catena
2009-07-09 22:18 ` erik quanstrom
2009-07-10 6:32 ` tlaronde
2009-07-09 12:45 ` Eric Van Hensbergen
2009-07-09 15:24 ` David Leimbach [this message]
2009-07-08 20:11 ` ron minnich
2009-07-08 20:43 ` Francisco J Ballesteros
2009-07-08 20:59 ` Devon H. O'Dell
2009-07-08 21:04 ` Francisco J Ballesteros
2009-07-08 17:34 ` Dan Cross
2009-07-08 17:52 ` ron minnich
2009-07-08 19:30 ` erik quanstrom
2009-07-08 19:40 ` Devon H. O'Dell
2009-07-08 20:09 ` ron minnich
2009-07-08 16:12 ` Balwinder S Dheeman
2009-07-08 9:04 ` Charles Forsyth
2009-07-10 6:32 Akshat Kumar
2009-07-10 12:02 ` Anthony Sorace
2009-07-10 12:14 ` erik quanstrom
2009-07-10 12:52 ` Robert Raschke
2009-07-10 17:11 ` Ethan Grammatikidis
2009-07-10 19:54 ` Richard Miller
2009-07-10 19:14 ` Bakul Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e1162e60907090824ubc72a6cw6f43e8dd41469685@mail.gmail.com \
--to=leimy2k@gmail.com \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).