4 ms·

Sounds terrible, but what you're describing seems to still fall in the category of "integrating apps" rather than "no apps". I think the best real world refere

Sounds terrible, but what you're describing seems to still fall in the category of "integrating apps" rather than "no apps". I think the best real world reference point for "no apps" is the terminal. Piping commands together is very powerful and intuitive (in this way they behave more like composable objects than applications). It works well, except for being unfriendly and reliant on low level text streams, which are both surmountable problems.

WJW 6y ago
The terminal is absolutely full of apps though. It's literally an environment designed around invoking other programs. Pipelines are indeed very powerful, but mostly for a specific class of tasks. As soon as you need interactivity, the pipeline model losess a lot of benefits. None of the popular databases, web servers, games or office suites are implemented as terminal pipelines. The other problem with pipelines is that while they scale reasonably well with data size, they don't scale quite as nicely with task complexity. A five-program pipeline with complex command line arguments can already be complex to understand. A 500-program pipeline would be a total nightmare, especially when it starts including components for error reporting and retry behavior.
TeMPOraL 6y ago
No, what they're describing is very much "no apps", unlike terminals. OLE is part of COM, which is all about individual classes, hidden behind interfaces, being available globally in the OS as building blocks. In a COM model, you can imagine, say, a word processor being composed of UI, document model, document store and spellchecker components. In this reality, I could replace the UI with a touch-enabled one, and run the same spell checker on a remote computer, all with few changes in Windows registry. Think of it like OS-level dependency injection and microservices, with RPC and orchestration being handled transparently for you.
- djrobstep 6y ago
  What is in question is the UX, not the literal code. Obviously terminal programs are literally programs and COM is literally objects. However, terminal programs often have a single purpose, along with inputs and outputs that function as a crude interface allowing them them to be combined in a reasonably flexible way by the end user, who can use them to construct functionality of their own.
tsimionescu 6y ago
The terminal is exactly an example of an app-centric workflow and why it is easier to build and/or easier to use than an API focused one. If you want to see a no-apps workflow, something like the Genera LISP OS was probably much closer[0]. People choose to use apps like ls, cat, less, echo, touch, find instead of using the FILE* object directly with readdir(), stat(), read(), write(), open(), creat() etc. All of the apps are designed to have human-readable output first, lots of options for controlling that output to make it as readable as possible etc. However, none of them exposes a rich model for its output that would make it possible to easily integrate it into more complex workflows. Instead, we rely on yet other apps, like sed, grep, xargs and essentially copy-pasting text between these apps (this is all that pipes really are, essentially). This becomes even more obvious when you use stuff like gcc or gdb, which have extremely rich and potentially useful layers of representation that they refuse to expose at all, even as APIs - only text is allowed in the interaction. Hell, the MS Office suite is a better example of a no-apps workflow, since each of the Office UIs has a deep understanding of the data produced by the others, and you can combine these in meaningful ways - much more so than terminal apps (for example, Word can show a portion of a spreadsheet without you having to guess at what contents it might have and how to parse it, like you would if you want to expose a portion of ls's output to a file). Interfacing code is hard, it requires well-thought-out APIs and much more work even with the best APIs. Interfacing apps with extremely minimalistic APIs (copy/paste, share) is much easier for everyone. [0] https://www.youtube.com/watch?v=o4-YnLpLgtk&t=6m0s https://www.youtube.com/watch?v=o4-YnLpLgtk&t=6m0s
- TeMPOraL 6y ago
  In context of terminals, if you want to see a modern API-based instead of app-based CLI experience, check out PowerShell. The underlying principle is that all commands like "ls" or "ps"[0] return their results as .NET objects, and not unstructured text. If you just call "ps" in the shell, you'll get the default visual representation you'd expect - but you can also choose a different one (e.g. list view by Format-List, or filterable GUI table view with Out-GridView), but you can also then filter the objects by properties and call methods on them. For example, to find and kill all instances of notepad.exe, you'd write: Get-Process | ForEach-Object { if($_.ProcessName -eq "notepad") { $_.Kill(); } } A bit verbose (and that's generally a problem with day-to-day PowerShell usage), but relatively trivial to turn into a cmdlet and alias it to "killall". Of course, the above example was trivial, but the same principle works for more complex ones - instead of streams of text, you have streams of objects, which you can filter and run methods on, without doing any parsing. -- [0] - Them being aliases to PowerShell's Get-ChildItem and Get-Process, respectively.

WJW 6y ago

The terminal is absolutely full of apps though. It's literally an environment designed around invoking other programs. Pipelines are indeed very powerful, but mostly for a specific class of tasks. As soon as you need interactivity, the pipeline model losess a lot of benefits. None of the popular databases, web servers, games or office suites are implemented as terminal pipelines. The other problem with pipelines is that while they scale reasonably well with data size, they don't scale quite as nicely with task complexity. A five-program pipeline with complex command line arguments can already be complex to understand. A 500-program pipeline would be a total nightmare, especially when it starts including components for error reporting and retry behavior.

TeMPOraL 6y ago

No, what they're describing is very much "no apps", unlike terminals. OLE is part of COM, which is all about individual classes, hidden behind interfaces, being available globally in the OS as building blocks. In a COM model, you can imagine, say, a word processor being composed of UI, document model, document store and spellchecker components. In this reality, I could replace the UI with a touch-enabled one, and run the same spell checker on a remote computer, all with few changes in Windows registry. Think of it like OS-level dependency injection and microservices, with RPC and orchestration being handled transparently for you.

djrobstep 6y ago
What is in question is the UX, not the literal code. Obviously terminal programs are literally programs and COM is literally objects. However, terminal programs often have a single purpose, along with inputs and outputs that function as a crude interface allowing them them to be combined in a reasonably flexible way by the end user, who can use them to construct functionality of their own.

tsimionescu 6y ago

The terminal is exactly an example of an app-centric workflow and why it is easier to build and/or easier to use than an API focused one. If you want to see a no-apps workflow, something like the Genera LISP OS was probably much closer[0]. People choose to use apps like ls, cat, less, echo, touch, find instead of using the FILE* object directly with readdir(), stat(), read(), write(), open(), creat() etc. All of the apps are designed to have human-readable output first, lots of options for controlling that output to make it as readable as possible etc. However, none of them exposes a rich model for its output that would make it possible to easily integrate it into more complex workflows. Instead, we rely on yet other apps, like sed, grep, xargs and essentially copy-pasting text between these apps (this is all that pipes really are, essentially). This becomes even more obvious when you use stuff like gcc or gdb, which have extremely rich and potentially useful layers of representation that they refuse to expose at all, even as APIs - only text is allowed in the interaction. Hell, the MS Office suite is a better example of a no-apps workflow, since each of the Office UIs has a deep understanding of the data produced by the others, and you can combine these in meaningful ways - much more so than terminal apps (for example, Word can show a portion of a spreadsheet without you having to guess at what contents it might have and how to parse it, like you would if you want to expose a portion of ls's output to a file). Interfacing code is hard, it requires well-thought-out APIs and much more work even with the best APIs. Interfacing apps with extremely minimalistic APIs (copy/paste, share) is much easier for everyone. [0] https://www.youtube.com/watch?v=o4-YnLpLgtk&t=6m0s https://www.youtube.com/watch?v=o4-YnLpLgtk&t=6m0s

TeMPOraL 6y ago
In context of terminals, if you want to see a modern API-based instead of app-based CLI experience, check out PowerShell. The underlying principle is that all commands like "ls" or "ps"[0] return their results as .NET objects, and not unstructured text. If you just call "ps" in the shell, you'll get the default visual representation you'd expect - but you can also choose a different one (e.g. list view by Format-List, or filterable GUI table view with Out-GridView), but you can also then filter the objects by properties and call methods on them. For example, to find and kill all instances of notepad.exe, you'd write: Get-Process | ForEach-Object { if($_.ProcessName -eq "notepad") { $_.Kill(); } } A bit verbose (and that's generally a problem with day-to-day PowerShell usage), but relatively trivial to turn into a cmdlet and alias it to "killall". Of course, the above example was trivial, but the same principle works for more complex ones - instead of streams of text, you have streams of objects, which you can filter and run methods on, without doing any parsing. -- [0] - Them being aliases to PowerShell's Get-ChildItem and Get-Process, respectively.