--WIyZ46R2i8wDzkSu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 22, 2003 at 04:15:13PM +0200, Guillaume Laurent wrote:
> On Monday 22 September 2003 03:45, Daniel Stone wrote:
> > So flat files don't always cut it?
>=20
> Of course not. They do _most of the time_ for a typical desktop usage.

So why remove functionality globally, when it has practical application?

> > > Several flat files if you want. Come on, I can find | xargs grep thro=
ugh
> > > the 150KLOCs of Rosegarden in seconds. And recipes are fairly short b=
its
> > > of texts, you could probably even load the whole bunch in memory if y=
ou
> > > really have to.
> >
> > On a fast box (like my AthlonXP 2400+, for example), sure. On a slower =
box?
> > Good luck.
>=20
> Yes you can. Try it.

I used to maintain a database of around 1500 recipes on a P166. It hurt.

> > You're also assuming that people just dump recipes in as flat files. Wh=
at
> > if I want to say "I have trout fillets, bacon, artichoke hearts,
> > breadcrumbs, mint, sour cream, lemon, and I want to cook something that
> > takes under two hours, all up"?
>=20
> First of all, I'm not assuming anything, in this particular case I know f=
rom=20
> direct experience (my mother has been in that branch of business for year=
s).=20
> That use case you made up hardly exists in practice.

I use it all the time. Professional chefs and such don't use it much, but I=
 can
assure it's very much used among enthusiasts (myself and my friends often f=
ind
ourselves in that situation, ditto family members). But we've gone too far =
into
the semantics of recipe-finding than database libraries, IMO.

> Second, yes, you very easily can do that through plain text files, and ge=
t=20
> perfectly decent response times to such a query even on a P90 with 10.000=
=20
> recipes. Do the math, at a 2KB per recipe (which is a very generous=20
> estimation), it's 20Mb to grep through. A P90 will do that in seconds.

The reason you can't do it through flat files, is because 'grep' doesn't cu=
t it
for complex queries like "under 2 hours preparation time", or given quantit=
ies,
or whatever.

> > Flat files aren't much use there - you'd need XML to do it in a flat fi=
le,
>=20
> There are other ways to structure data than XML, you know.

Most of which are close enough to databases to not be 'flat files' anymore.

> > Have a look at some of the
> > commercial recipe apps on Windows some day - they're not just a bunch of
> > text files.
>=20
> That doesn't mean it can't be done with just a bunch of text files (somet=
hing=20
> which, BTW, no Windows app ever does : it's primarily a cultural problem,=
 not=20
> an implementation one).

I don't see why it shouldn't be done with a DB. By the time you get all that
functionality in a flat file you've duplicated so much code it's useless.

> On Monday 22 September 2003 03:36, Daniel Stone wrote:
> > "But CPU power is cheap these days" does not hold water, and is
> > not a valid excuse. Instead, it should always be taken to expose the re=
al
> > underlying reason: lazy developers.
>=20
> Oh please, spare us the clich?s.

The best cliche among that paragraph was "But CPU power is cheap these days=
". It
is, sure. But with two large catches: a) in *RELATIVE* terms (relative to, =
say,
a CD player at $au35, decent CPU power is still hellishly expensively), and=
 b)
that assumes people are buying it. There's no excuse for locking out a segm=
ent
of our target market. If you want to write lazy code that takes 100 cycles
longer for every op, fine, but please keep it out of kdelibs/kdebase (and
preferably KDE altogether).

--=20
Daniel Stone                                              <daniel@fooishbar=
.org>
http://www.debian.org - http://www.kde.org - http://www.freedesktop.org
"Configurability is always the best choice when it's pretty simple to imple=
ment"
  -- Havoc Pennington, gnome-list

--WIyZ46R2i8wDzkSu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj9v0gsACgkQcPClnTztfv2siwCfbQA2z3KI1gE+dHFAxLLJCw4H
xN0An3pKIyzFaqla1UxbFcK4/LgQn02Z
=bVH6
-----END PGP SIGNATURE-----

--WIyZ46R2i8wDzkSu--