[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc.
From: |
Aaron Bentley |
Subject: |
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc. |
Date: |
Thu, 22 Jul 2004 14:21:54 -0400 |
User-agent: |
Mozilla Thunderbird 0.5 (X11/20040309) |
Tom Lord wrote:
> From: Aaron Bentley <address@hidden>
> If Tom promises we'll never see code like that example, then we can all
> go home early. But that would raise the question: why go further than xl0?
> See, xl0 looks like a perfect balance to me, in terms of its structure.
> I agree that it's better to have one system for managing configuration
> data, and I can't imagine having difficulty writing a parser for xl0.
I really don't see where the superstition arises that the boundary
between xl0 and xl0+expressions has much practical significance at all
(for implementors
Sorry I was unclear. My argument wasn't "xl1 is too hard to implement".
I meant to say "there's no point implementing xl1 if all you're going
to use is the xl0 subset".
for users it's obviously a huge boost in expressiveness).
I'm saying that increase in expressiveness has costs in terms of
iteroperability, user comprehension, ease of use, and that I don't
believe those costs are appropriate for the domain of Arch configuration.
I use procmail. I'd be crushed under a mountain of kipple if I didn't.
The other day, I was editing my rules files, and I made an error. The
result was that it created a new folder called "From:", and started
sticking most of my mail in there.
Procmail's expressive, but it has downsides, too. It's got a higher
barrier to entry than the Outlook rules wizard. You've got to
understand regexes. You've got to understand procmail syntax. You need
access to a mail server. It doesn't have a lot of trigger guards.
For my purposes, Procmail is overkill. But even the Outlook rules
wizard is more than I really need.
See, the mountain of kipple is spam. I deal with it by having SpamProbe
scan messages and categorize them. I dump uncaught spam into my
"makespam" folder, and a cron job uses that folder to update SpamProbe's
database.
All of that's nifty, but it's excessive. Mozilla Thunderbird has spam
scanning built in, and it uses the same detection approach. But all you
have to do is point and click. No wizards, no regexes. Simple and easy.
Not nearly as powerful, but the gains are worth the lost functionality.
Anyone can use that, not just techies like me.
That's just an analogy, of course: I hold that, in general, more
powerful tools are harder to use, and introduce more possibilities for
confusion and error. Sometimes powerful tools are warranted--
especially when needs are diverse. But when common use cases are
prevalent, it makes sense to simplify functionality for those cases.
> Here's my argument: I don't want more than xl0, because beyond that,
> configuration data becomes opaque to programs.
Why do you believe that?!?
...
So, what kind of program is it that will have an xl0
parser but can't, for some reason, have an xl0+expressions
interpreter?
What I mean is that when all you have is assignment, all the rules for
how values are used can be known in advance, and programmed into the
programs that use the data. Programs can use this knowlege to display
it in ways that make sense to users, and manipulate it in ways that are
based on a deep understanding of the way the data is used.
When expressions get involved, you can no longer display the data based
on how it's used. Sure, you can evaluate the expression. And you may
be able to get a parse tree, and allow people to query and manipulate
the expression's structure like a good IDE can.
Why can't the GUI say:
my-default-archive
value: address@hidden
definition: (archive-of my-default-fq-version)
and allow users to edit the definition but not the value?
It certainly can, but I don't believe that's appropriate for this
domain. I can only think of two or three ways that users would generate
my-default-archive. It would be better to have a UI tailored to those
options, but I question the value of computing it in the first place.
Is it going to make anyone's life any easier?
Of course,
that would be the generic display. Read the discussion between
Jeremy Shaw and I for some hints about how some config files could
wind up with customized interfaces that implement domain-specific
rules for editting definitions in high-level ways.
I don't see anything in that discussion that could come close to the
simplicity of the alternative I proposed. Some of it requires custom
data types, so I don't think xl0+expressions will cut it.
In order for programs to intelligently handle previously-unknown Arch
configuration data, you'll need types like those implemented by PyArch:
Archive, Patchlog, WorkingTree, etc. Then you can have an Archive-list
dropdown or a Revision browser.
Aaron
--
Aaron Bentley
Director of Technology
Panometrics, Inc.
- [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., (continued)
- [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., John Meinel, 2004/07/21
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Jan Hudec, 2004/07/22
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Bruce Stephens, 2004/07/22
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Jan Hudec, 2004/07/22
- [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Stefan Monnier, 2004/07/22
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., James Blackwell, 2004/07/21
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Aaron Bentley, 2004/07/21
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., James Blackwell, 2004/07/21
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Tom Lord, 2004/07/22
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Tom Lord, 2004/07/22
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc.,
Aaron Bentley <=
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Tom Lord, 2004/07/22
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Tom Lord, 2004/07/22