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

[Tom Lord]

    > From: "Pierce T.Wetter III" <address@hidden>

    >> An extension language is required for usability features, especially
    >> those that simplify both "upstream" and "downstream" configuration and
    >> process integration.  For example, suppose that we want commands like:

    > >         % tla fork <my-favorite-project>

    > > and

    >>  % tla submit <my-favorite-project>  <some-of-my-changes>

    >> Those both require project-specific rules to be followed.  `submit'
    >> especially just cries out for something turing complete.   Other
    >> examples are not hard to construct.

    >    So furth will be needed when people want to add custom rules to
    > how tla works, 

Yes.

    > 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.....

There was an entire quasi-academic line of thought, the "tiny
languages approach" (written up mostly by Jon Bentley), about tiny
domain specific languages.   I'm just making an incremental
improvement to that approach by keeping in mind a general purpose
super-language of which all tiny languages should be an approximation.



    >    Ok, so why furth? Because you like scheme? Why not use one of the
    > existing languages that let you embed an interpreter (perl, python),
    > why a whole new language that only you can program in.

It would take years to answer in detail but the 5 gems cited by 
Shriram Krishnamurthi sum it up well.  These gems aren't "nice to
have" -- they're essential:


    ~ closures                  |
    ~ continuations             | The Crown Jewels

    ~ That stupid parenthetical |
      syntax                    | The
    ~ macros                    | Lesser
    ~ tail calls                | Gems


Scheme and lisp generally are _not_ the only languages that can
provide those things.   Perl and Python are examples of languages
taht, pragmatically speaking, can not provide all of those things
(only some).


    >   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.

    >   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.


    >   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.


    > 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 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.


    >    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.

-t