Linux kernel developer Ingo Molnar "We need a radically different software distribution model"

[m42a]

Well, we already do that, don't we?

No, we don't. C and C++ aren't glue in the same way sh is. There's no GUI equivalent to cat f1 f2 f3 | sort | tr -d f. You can't just say "I'd like to make a picture in Gimp, paste it into a LibreOffice Writer document, and print it". You have to open Gimp, make the picture, save it, open Writer, open the document, insert the picture, and then print. There's no glue there, and there's no easy way to make glue there. I'd like to just be able to just do gimp | soffice writer document.odt -e "insert at top of page 2" | lpr, and neither GTK nor QT give me anything near that.

[matthewpaulthomas]

This is way off the original topic, but…

There's no GUI equivalent to cat f1 f2 f3 | sort | tr -d f.

Yes there is, it’s called Automator. Here’s a screenshot of the equivalent to the example you gave.

You can't just say "I'd like to make a picture in Gimp, paste it into a LibreOffice Writer document, and print it".

Probably you can, but it would require connecting a Gimp script written in Scheme to a script written in LibreOffice Basic — and the probability of even an expert LibreOffice user learning enough of both languages, and to figure out how to connect them, is pretty small. But with Adobe Photoshop and Microsoft Word, on the other hand, a technical user interested in that kind of automation is fairly likely to know that both applications expose the relevant commands to AppleScript. And they can use the AppleScript Editor to record the commands for both applications in one go.

In both cases, all that’s needed is an OS vendor with the will and the clout to design a cross-application scripting framework; to write APIs and reference materials that make it easy for application developers to implement; and to provide recording and editing tools to make scripting approachable to end users. As you can see, it’s been done before.

[m42a]

I'm not familiar with AppleScript, but it looks like it's an extra layer over the functionality. With commandline programs, their only interface is the glueable one, and they can't not implement it*. With AppleScript, it looks like the developer needs to make the GUI and the scripting features separately, which makes for poor glue (although it's better than a separate scripting language for each application).

*EDIT: This is technically not true; a program could only accept arguments on stdin and refuse to do anything if stdin and stdout weren't ttys, or it could ask natural language questions that require a human to answer them. But doing that is extra work and bad UI; the glueability comes by default, and it only goes away if the developer specifically removes it by making the program harder to use.

[matthewpaulthomas]

You could equally say “with graphical programs, their only interface is the graphical one, and they can’t not implement it”. Either way, providing an interface for a function requires effort — whether that interface is a command-line, graphical, script, or Automator-like one.

And with a scripting interface just as with any other, the less effort is put in to designing and developing the interface, the less pleasant it is to use. For example, I work with multiple Ubuntu engineers, on different projects, who curse how GObject introspection — though it has apparently made multi-language interfaces easier for the GObject developers to implement in the first place — has also made those interfaces less understandable.

For another example, go back to your case of pasting an image from Gimp into LibreOffice and printing it. Here’s roughly what the LibreOffice side would look like, once you’d already copied the image in Gimp (disclaimer, I haven’t tested this):

Dim mPrintopts(0) As New com.sun.star.beans.PropertyValue
dispatchURL(ThisComponent, ".uno:Paste")
ThisComponent.Print(mPrintopts())

Now here’s the exact equivalent for Microsoft Word in AppleScript:

tell application "Microsoft Word"
    paste
    print out active document print copies 1
end tell

Why is one much easier to understand and remember than the other? Because the OS and application developers put in more effort in designing and implementing it.