Re: [Gnu-arch-users] Some plans about arch infrastructure in Perl

[Aaron Bentley]

Mikhael Goikhman wrote:

> On 11 Mar 2004 21:45:26 -0500, Aaron Bentley wrote:
>  
>
> > Mikhael Goikhman wrote:
> >
> >    
> >
> > > * axp - command line tool and wrapper for tla (Arch eXtended by Perl)
> > >      
> > aba's just 106 lines, and it would probably be shorter in Perl.  You'd 
> > get 37 (and counting) extension commands for free, but since I don't 
> > know Perl, I'd probably keep maintaining aba too.
> >    
>
> Aaron, I am sure you are not the only person who may be disappointed by
> this message. I want to make it clear.
>
> I wish we have as many tools as the developers are willing to maintain.
> This is healthy for arch. These kinds of things are hard to be envisioned.
>  
I agree with you on this.  But the multiplicity of tools can have a 
downside: people don't know what's out there, and wind up rewriting the 
same tool over and over again.  (For example, "aba branch-this" appears 
to be the same as "tla fork", and they're both in the same package!)  
What I like about tlacontrib is the idea of unifying the collection of 
tla tools, so people can find what's available more easily.  aba takes 
this one step further by providing a unified way of finding and using 
the available tools. 

> The more developers work on different aspects of Arch infrastructure, the
> stronger lobby we have to request changes/fixes in the arch core. So, we
> are on the same boat.
>
> Regarding aba. Honestly, I didn't use it, but I really like some its
> sub-commands you posted on this list.
Perhaps the key point if you're considering writing an aba alternative 
is that aba subcommands are simply scripts (or binaries, I guess) that 
support this interface:
foo exec $*: Perform their operation on the supplied arguments
foo exec (-h|--help): Provide short help
foo exec (-H)Provide long help
foo desc Describe the script's function, in 'tla help' format

> I like tla-tools and others too.
> My problem is I don't believe in /bin/sh as the language for powerful,
> unbreakable by bogus input, configurable, extendable, debug-able scripts.
>  
Yes, I'm not over the moon about shell scripting, either.  Do bear in 
mind though that it's a well-known, simple language, and robust enough 
to be used for system startup in most unices and unix-likes.  aba 
commands work well and save me time.  Perfection can wait (until I 
encounter the bugs)

> There are currently 3 appropriate languages I may think about.
>  
Well, I'll accept scripts in any common language.  I just merged the 
first aba command written in Perl yesterday.  If axp commands are of use 
to me, I'll probably wrap them, too.

> > Actually, I haven't tried Python, but it sounds more like my kind of 
> > language.
> >    
>
> Python is very nice language. Ruby is brilliant too. Still, I have _very_
> good reasons to prefer Perl, the ones I listed are only a small part.
>  
The big negative that I see with Perl is that it seems a poor choice for 
collaboration.  Even in the clearest languages, it can be hard to 
understand another programmer's code, but Perl is often called a 
"write-only" language.

Anyhow, I certainly don't want to start a Perl vs shell language war.  
Competition would probably be good for aba, and I'm sure the rest of 
your plans will bring benefits to everyone if they bear fruit.

Aaron