Re: [Gnu-arch-users] Extension language

[Joshua Haberman]

On Fri, 2003-10-17 at 11:42, Tom Lord wrote:
>     > From: Joshua Haberman <address@hidden>
> 
>     > On Fri, 2003-10-17 at 08:53, Tom Lord wrote:
>     > > But you're also suggesting a firm separation between the interactive
>     > > CLI and the programmatic interface.  That's a fine idea and it remains
>     > > a fine idea even if we say that the programmatic interface is itself a
>     > > CLI.  There's nothing wrong with adding new commands (presumably
>     > > hidden by default) whose primary purpose is to provide a programmatic
>     > > interface.
> 
>     > I personally resist the CLI-as-programmatic-interface idea for two main
>     > reasons:
> 
>     > 1. The vast majority of programs I have encountered that use external
>     > programs through a CLI have been fragile and had not very useful
>     > interfaces.  They are fragile because supplying input requires careful
>     > treatment of the shell and quoting, 
> 
> Not at all.  Not a few popular languages seem to think that the
> primary interface to subprocesses is `system(3)' which does exhibit
> the problems you describe.

Despite the ongoing discussion on this point, I concede it.

> I'm all for structured I/O of this or that sort, but the need to parse
> something is not, in and of itself, a source of fragility.  (What
> might sources of fragility are poorly designed or documented formats,
> formats that change rapidly, and the absense of help from a compiler
> that warns you when an interface has changed -- such problems have
> reasonable solutions, though.)

I think it's a source of fragility to the extent that this parser has to
be reimplemented in each language that wishes to use this CLI
programmatic interface, with the potential for bugs in each.

>     > and finding the location of the target binary.  
> 
> It does not, in all instances, but even when it does: how does that
> "reduce portability"?  Generally speaking, providing configuration
> options that say where to look for a particular binary _increases_
> portability.

Strictly speaking, it probably does not decrease portability.  What it
decreases is the ease of such applications working out-of-the-box on a
wide range of platforms.  Windows sans Cygwin, for example, does not
have a standard place for installing third party command-line binaries. 
Therefore, client applications will probably have to ask the user where
the tla binary is, and the user may not know.

Instead of saying it "reduces portability" I should have said it
"demands more system-specific knowledge of the operating system." 
Specifically, it demands:

- that the client program find an appropriate tla binary, either by
guessing or asking the user
- that the client program use an appropriate process control mechanism
for every target platform (ie. Windows does not have fork()/exec())
- that the client program be aware of system-specific gotchas, such as
the fact that on Windows, stdin/stdout do newline conversion by default
and must be put in binary mode to avoid it.

You will notice that I think in terms of applications that are written
once and designed to work across UNIX, Mac OS X, and Windows, because
those are the kind of applications I am familiar with developing.  For
applications (such as tla) that don't inherently demand more of an
operating system than the intersection of what these common operating
systems provide, I don't see any reason to gratuitously introduce
os-specific dependencies.

>     > Do you intend to increasingly depend on
>     > a POSIX environment, such that the possibility of running on (say)
>     > Windows without Cygwin becomes more remote?
> 
> Why not?   In the worst case, supposing a native windows port suddenly
> became highly desirable, the system is small enough to reimplement
> from scratch.

I would argue that a native Windows port is highly desirable right now,
and that any version control software that seeks to become pervasive
will need to run on plain Windows.  The cross-platform projects I work
on could never move to a version control system that didn't support
Windows because it would isolate the contributors that use Windows.  I
understand arch's traditional UNIX-centricity in its design, and I would
not ask you or others to invest energy porting tla to a platform you do
not use.  However I would request that you avoid making design decisions
that unnecessarily make tla more dependent on POSIX than it already is.

You have given reasons why using the CLI as a programming interface
could work reasonably well compared with more traditional
"librification."  But those are only a defense; what are your
"offensive" reasons for favoring this approach over librification?

Josh