Gentoo Archives: gentoo-dev

From: "Steven J. Long" <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: [OT] pkgcore bikeshed (was Portage team)
Date: Tue, 14 Jan 2014 07:45:20
In Reply to: Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) by Ciaran McCreesh
1 On Mon, Jan 13, 2014, Ciaran McCreesh wrote:
2 > On Mon, 13 Jan 2014 19:27:36 +0100
3 > Tom Wijsman <TomWij@g.o> wrote:
4 > > > Not an API. APIs are bad. What we should have is a good set of
5 > > > lightweight Unix-friendly command line tools. See, for example, the
6 > > > "Scripting Commands" section of "man cave".
7 > >
8 > > It still is an API that way, just expressed differently
9 >
10 > The term "API" seems to mean "library or communication interface" these
11 > days (see "Git API" and the like). So for clarity, it's probably better
12 > to make the distinction.
14 I think Tom was aware of that: hence "expressed differently". You appear
15 to have missed his point, which was not about something so simple and
16 well-known, judging by your inability to perceive it, and the state of
17 "modern" software.
19 > > if you would only do this you're introducing forks where you might
20 > > not need them. Providing shell commands is one possible binding to
21 > > the API...
22 >
23 > Forks are far less of a big deal than trying to share a process between
24 > programming languages. This is a *huge* deal when trying to integrate
25 > modern C++ with languages with primitive thread-hostile runtimes like
26 > Python and Ruby.
27 >
28 > Unless you're doing a heavy GUI (in which case portability probably
29 > isn't going to cut it anyway, without a far larger API than it's worth
30 > providing), most of the cost for most of the use cases for this is in
31 > the PM reading in configs and the like. The way around that is to allow
32 > communication via pipes, still in a Unix-friendly manner. This can be
33 > implemented nearly transparently.
35 Yes and the traditional Unix way to implement those shell commands is
36 to write a lib and then some apps as thin wrappers on top of it, and
37 possibly more complex ones on top of that as time goes by, and users
38 require. These components can in turn be used by other apps, or their
39 crappy non-C runtimes, as a basis for future development.
41 So Tom's point stands.
43 As for modern C++ being the be-all and end-all that sets the exemplar
44 .. LMAO. Good one. 30 years to reimplement LISP badly. Greenspun^N
46 I won't bother with your assertions about GUIs etc. Just don't presume
47 silence for agreement, as you are so wont to do. The obvious truths
48 about pipes etc, while true have very little to do with the point being
49 made. Still, glad you finally got hold of APUE.
51 *wipes tears from eyes and moves on*
52 --
53 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)