Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to")

[Pierce T.Wetter III]

> > in the same way that Makefiles are really a rather bizarre
> > language.
>
> Are they?  The language of `make(1)' has some serious, big-ass
> glitches.  That's because it was an ad hoc design, aimed at solving
> one particular need for a language, but absent any larger perspective
> on languages in general.  But aside from those glitches, it's very,
> very good.   It's a tiny, domain-specific language, enabling
> economical expression of the most common patterns.....

 Yeah, you're just being pedantic here. My point is that furth will
be used for "rule files", not so much for feature development. Which you
confirmed.

 By "bizarre" here, I meant that any configuration file, for any program
could be viewed as a programming language. That's a certain mental state
you have to be in to see things that way.

> >   1. There is currently only one person in the world that knows how to
> > program in furth.
>
> Actually, there are 0.   It's not done yet.

  Which is overly pedantic again, and actually proves my point, not
disproves it.
> >   2. I doubt that furth will have ever have the feature set of say, 
> > perl
> > or python, given that it is pretty much gaurunteed to never have as
> > many people working on it.
>
> Perhaps.  None of us is good at predicting the future.
>
> The number of people working on it is not obviously the most important
> metric, by the way.   Orders of magnitude improvements in productivity
> can override that metric.

 Orders of magnitude improvements in productivity for you, or for your
users? I'm telling you that if people reading about arch find out that
they have to learn how to program in some new language, they will stay
away.
> >   3. I'm not sure it makes sense to EVER force a decision on the user 
> > of
> > what language to use.
>
> That's just confused.  Every program that accepts user input forces a
> decision about what language to use.

 You really posted the roadmaps in the wrong order. None of us care 
about
documents 1 or 2, we only care about 3.

 Its hard to argue in a vacuum, but since engineers can argue anywhere, 
here
goes. I'll illustrate where I see you headed.

  Let's say I want to add a submit rule.

 "Builds correctly" or "if make"

 That seems like a logical use for a shell script, because all I really 
want
to do is run make and get the result.

  So I suppose that there are two ways to go here. In one case, the 
config file for
submit rules could be a complete language like Python (I'm using Python 
since I don't know furth):

 def submit():
        if os.system("make"):
                return true;
        else
                return false;

So tla would look for "Rules.py", and it would look for definitions of 
specific Python routines (like submit) which it would call in certain 
cases.

Now this would force tla users to learn Python, which besides causing a 
flamefest, would require only using tla where python is available. On 
the other hand, I see several benefits:

 1. Since Rules.py is only read once per tla command, and probably only 
compiled once in a great while when Rules.py changes, this would make 
tla pretty fast at reading and processing the rules.

 2. Personally, I hate shell scripting, and much prefer doing things in 
Perl or Python then I do
.sh files. Plus as Tom points out, all config files are a language of 
some sort, and I'd rather not learn yet another one.

 3. tla could set certain variables and read others, making it easy to 
pass information back and forth between the rule code and the main 
code.

 Or, there's this alternative. Tla will execute any file named 
.rules.submit. So this file could
 look like this:

#!/usr/bin/python

        if os.system("make"):
                sys.exit(0);
        else
                sys.exit(-1);

The advantages of this are:

   1. User can use anything: Perl, Python, Shell scripts, c programs.
   2. Tla has to launch a whole process to ask one question, which while
      easy for a global operation like submit, its bad for any per file
      thing.

The third alternative would be of course:

   arch implements some ad-hoc configuration language, which has 
whatever
features the arch users felt we're needed, and which gradually gets 
hacked
on, but is actually harder to learn then Perl/Python etc.

So that's where you're coming from, except you came with with a fourth
alternative:

   Given Tom's experience with creating a language, Tom creates his own
VM, with the theory being that people can write code in multiple 
languages
which compile down to this code. Tom will probably write a scheme 
compiler
for instance. (See Emacs/Lisp/Richard Stallman)

 So I think that's where you're coming from. My feedback as a user is 
that:

  1. I don't want to learn a new language.
  2. I don't want to learn a new config file format either.

 But of the two, I would rather choose #2 then #1.

 Additionally, while I'm confident in your ability to create a new 
general purpose language, I'm not sure that furth is the right answer 
for what you want to do in a rule file. submit rules, etc. probably 
have more in common with what people do with shell scripts and Perl 
then what you
would see in Perl. You probably don't like Perl, but I have to tell you 
that while its a
terrible language in many ways, its a really nice "extracting and 
reporting language".

 So I don't disagree entirely with your decision to integrate a 
language into tla,
I disagree with your decision to invent a new one, or even a new VM. It 
would be much
better if you integrated a language that there was an O'Reilly book 
available for, or
was a subset of some other language like tiny-c or something. I'm 
pretty sure there
already exist some language interpreters out there that you could use.
> > Why can't tla call out to any shell, perl,
> > python, ruby,
> > script or program? If it needs tight integration, integrate with
> > Parrot, lets
> > not have yet-another-vm...
>
> Parrot pretty much blows as technology though as pedagogical project
> it seems to have considerable value.

   I just suggested that because there's some talk of having both
 Python -> Parrot
and
 Perl -> Parrot.

 But its probably overkill for a config file.
> >   I can't be any more blunt then this:
>
> >    If you insist on creating your own language+VM for use with arch, 
> > you
> > will
> > condemn arch to obscurity. Anyone who ever looks at arch from now on
> > will say
> > "oh, written in some weird language I don't want to learn. Next..."
>
> No, arch will be written in C.

  I understand that but other people won't. That's just how it is, that 
since
they don't think of the config file as a language they have to learn, 
they don't
mind learning it. (Especially since most config files are pretty 
simple.) If
they have to learn "furth" to configure arch, that is going to set their
perception of the difficulty of learning arch that much higher.

  Even though that may not be true, that "tiny-scheme" may be easier to 
learn
then say, Makefile syntax, their perception is that its harder. They 
may be
right after all. Its very easy to "tweak" a typical config file, while 
its
harder to "tweak" most languages.
> >    You may have all the technical reasons in the world, but its a bad 
> > UI
> > decision.
>
> Yadda yadda yadda.
>
> You seem to think I'm going to stop everything and immediately
> completely rewrite arch in some strange language that I made
> up on the spot.   That's not the plan.   Reacting against that
> non-plan is really off topic.

  No, I think that you like working on languages so you're thinking of
creating one for use in arch rule files. I don't disagree with having
a language in rule files, I disagree with having a language you made
up in the rule files...

 So while many people's first reaction to all this was, "why a 
language?",
my reaction is "why YOUR language?".

Pierce