| 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. |
| 13 |
|
| 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. |
| 18 |
|
| 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. |
| 34 |
|
| 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. |
| 40 |
|
| 41 |
So Tom's point stands. |
| 42 |
|
| 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 |
| 45 |
|
| 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. |
| 50 |
|
| 51 |
*wipes tears from eyes and moves on* |
| 52 |
-- |
| 53 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |
Archives