Subject: Re: Kernel config file
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Johnny Billquist <bqt@softjar.se>
List: tech-kern
Date: 06/19/2007 11:09:03
Well, that pretty much summed it up for me. Thanks, Mouse.
I could possibly add that people in the past didn't normally think using
lex and yacc was such a difficult task. Maybe times are changing.
But I guess I'm throwing wood on the fire now. :-)
But hey! I was just being accused of being a bit luddite...
Johnny
der Mouse skrev:
>> As to your comments about not having to use tools, well we always use
>> tools now. We just use ones named "vi" or "emacs" (or "ed" for the
>> truly insane). Needing to use different ones doesn't seem like that
>> big a deal.
>
> You clearly have never stumbled into the middle of an editor
> religious-war flamefest.
>
> It actually *is* a big deal, though, because no one tool is going to be
> appropriate for all tasks. That's why we still ship with two editors
> and people commonly install any of numerous others. No matter what
> plist editor you build, it will be a Wrong Thing for at least some
> important cases. The best I can think of, actually, is a tool which
> converts between XML and some human-comprehensible format in both
> directions, with a run of $EDITOR on a temporary file in between.
>
>> As to "what's so cool about XML," people have said it but you didn't
>> hear them. There are a few reasons, but the big one for me is that
>> we end up with multi-stage parsers. The first stage understands the
>> XML, and the second stage or layer understands what the XML is
>> describing.
>
> This to me is actually one of the biggest reasons to *avoid* XML: it is
> turning the human/computer relationship upside down. Computers should
> do the drudgework so as to make humans' lives easier. Switching to a
> language that makes humans' lives harder simply because it makes
> parsing easier is...backwards.
>
> Of course, you may disagree with one or more of the bases that argument
> rests on. But I think that if you grant the bases, the conclusion is
> more or less inevitable.
>
>> One advantage is that we can future-proof tools. If a tool looks for
>> a certain object hierarchy in a file, as long as it's there, it
>> works. So we can add extra elements over time that older tools can
>> safely ignore.
>
> This is not so much an argument for XML per se as it is an argument for
> well-thought-out and extensible configuration languages. XML may be
> one such, but it is not the only one, and quite possibly not the best.
>
> Not that I maintain it is - or isn't - the best such. I've been
> staying out of *that* question and I intend to continue to do so.
>
> /~\ The ASCII der Mouse
> \ / Ribbon Campaign
> X Against HTML mouse@rodents.montreal.qc.ca
> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B