[HN Gopher] Programs are a prison: Rethinking the building block...
___________________________________________________________________
Programs are a prison: Rethinking the building blocks of computing
interfaces
Author : vortex_ape
Score : 51 points
Date : 2020-11-05 15:35 UTC (2 days ago)
(HTM) web link (djrobstep.com)
(TXT) w3m dump (djrobstep.com)
| lowlevel wrote:
| Sounds like unix to me.
| rakoo wrote:
| Indeed, it sounds like the author is looking for the UNIX of
| the 21st century:
|
| * Widely reusable meaning: everything behaves like a file. The
| types of files we can have are defined by specs: an Image can
| be described as a PNG file, which every process can understand.
| A table can be a CSV or a SQLite file. A Conversation can be a
| maildir folder. We might not have the best descriptions of
| "things" but we do have something
|
| * Data without borders: if you can read from stdin and write on
| stdout, you can interact with the data. In fact, joining two
| tables is a base task and can be done with join
| (https://linux.die.net/man/1/join)
|
| * Inherent, ubiquitous programmability: I'm not sure I
| understand the author's point, but it sounds like the entities
| in a software are too specific to the program. Again, if every
| "application", or rather set of utilities, used the filesystem
| with clearly defined specifications for what data is, then they
| can work together
|
| What is not following the UNIX guidelines is definitely the Web
| and mobile platforms, as the author focuses on. There were some
| attempts at doing things the UNIX way, like uzbl
| (https://www.uzbl.org/) where every thing is a script away, or
| ii (https://tools.suckless.org/ii/) which gives a filesystem
| interface to IRC conversations. Want to parse a message ? It's
| just a string in the filesystem, any script can do it.
|
| There's a reason it didn't work as well as we want, and it's
| that in practice it's all clunky and hard to maintain when the
| alternative is a single, unified application. Especially when
| the alternative is from a commercial vendor with a lot of cash.
| The incentives of doing FOSS that interacts with each other are
| not aligned with making money.
| ptx wrote:
| > We need computing environments ... without the concept of
| applications appearing at all.
|
| Platforms keep trying to enable this, but application vendors
| want to control the UX and branding, so they're not going to
| provide these generic reusable building blocks.
|
| Android, for example, lets apps make use of views from other apps
| and securely delegate a task (e.g. take a photo, pick a file,
| etc.) to the user's preferred app without needing to request
| permission for direct access. But nobody does this - apps just
| requests all permissions and do everything themselves.
| djrobstep wrote:
| Author here, yes this is a big problem (the biggest?), as the
| incentives are all wrong. As I noted in the post: "Often ...
| apps will have features to integrate with other apps and the
| wider operating system - but not so much that they become
| invisible. Instagram still wants you to see its logo, consume
| its specific content and stay within its ecosystem. Once again,
| the implementation and architecture are driven by economic
| imperatives."
| [deleted]
| gdrift wrote:
| Open intents is trying to standardize and promote such
| cooperation between apps on android. Tasker and similar apps
| are also a way to stitch together apps.
|
| http://www.openintents.org/
| orbital-decay wrote:
| _> Inherent, ubiquitous programmability: Currently, "doing
| programming" is a segregated activity from mainstream computing -
| separate software, command lines, specialist knowledge, clunky
| text-driven interfaces. This must end. Real expressiveness
| demands that every entity in the interface is inherently
| programmable - a table of data shouldn't just be a rendered
| picture of a table of data - it should be a table. Programming
| shouldn't be separate at all._
|
| Almost every attempt at such an environment has failed for a
| reason. The problem with programming is not the syntax and other
| particularities, but inherent complexity of explaining the task
| to a computer.
|
| Natural interfaces like modern voice assistants have a lot more
| chances to succeed than programming, because _a)_ they imitate
| normal human communication and _b)_ they are less dependent on
| unambiguous programming. And they are still limited because their
| fuzzy nature makes them unreliable and unpredictable.
| hedora wrote:
| > Almost every attempt at such an environment has failed for a
| reason.
|
| Basic and spreadsheets are notable exceptions. However, they
| don't scale to complex programs.
| mcguire wrote:
| If you want to scare yourself, look up reports of
| spreadsheets with errors.
| djrobstep wrote:
| > The problem with programming is not the syntax and other
| particularities, but inherent complexity of explaining the task
| to a computer.
|
| Not really. A great deal of the the complexity is accidental,
| not inherent. Take the example from the post of adding up some
| numbers in a table. The inherent complexity is very low, the
| complexity comes from all the stuff not inherent to the problem
| itself.
| loopz wrote:
| Real world is always complex, ambigous and changing. So any
| simple model will in time be found inadequate, and complex
| models unusable.
|
| The problem of programming isn't so much the interface. Text
| has been used for decades and remains a robust communication
| platform among humans. The real problem is defining the
| problem to be solved, its scope and adaptability to a complex
| and changing world.
|
| The real difficulty is the gap between vague ideas and real
| world outcomes of automation and human-computer interactions.
| To codify and implement ideas require precise understanding,
| design and adaptability which are otherwise demanding,
| understated and neglected.
|
| Notice there is little need to focus on the tools themselves
| in this realization.
| djrobstep wrote:
| What's vague and hard to define about adding up some
| numbers in a table?
| juancampa wrote:
| This is a problem I have personally spent several years thinking
| about and working on. The trick IMO will be to build it
| incrementally from what we already have. For anyone interested,
| here's my take on it: https://membrane.io
|
| The TL;DR is that I've been building a orthogonally persistent,
| message-based, user centric, programmable (js/ts) graph
| wrnr wrote:
| Why do articles like this keep being written and upvoted? It just
| keeps raising problems ranging from design, technology, politics
| and economy. Perhaps the author should try to answer his own
| questions as an exercise.
| PaulHoule wrote:
| Sounds like what Microsoft wanted Windows to be back in the Win
| 3.1 era with COM and all that.
| GartzenDeHaes wrote:
| Also in PRISM for WPF.
|
| https://docs.microsoft.com/en-us/archive/msdn-magazine/2008/...
| vortex_ape wrote:
| Can you elaborate a bit on what COM was? (or link a resource) I
| couldn't find its mention on the Windows 3.1 Wikipedia page.
| qppo wrote:
| It's a language agnostic binary interface. It's kind of hard
| to explain without getting into the technical details of how
| it works. For many years it was the only stable ABI on
| windows.
| PaulHoule wrote:
| https://en.wikipedia.org/wiki/Component_Object_Model
|
| which is an elaboration of
|
| https://en.wikipedia.org/wiki/Dynamic_Data_Exchange
|
| A common use of COM was scripting with Visual Basic in the
| 1990s, for instance, ask Excel what is in cell B7, or
| dynamically load a GUI component out of a DLL and script it
| into a Visual Basic application.
|
| This blends the boundaries between applications in that you
| might have a Word document that has an Excel spreadsheet
| embedded in it, and it really does boot up Excel and has
| Excel render itself in a rectangle inside the Word document.
| vortex_ape wrote:
| Thank you for the links!
|
| > A common use of COM was scripting with Visual Basic in
| the 1990s ...
|
| This sounds nifty!
| cheschire wrote:
| It was! Then the malware came. Those links opened a
| million security holes that were effectively untestable.
| AnIdiotOnTheNet wrote:
| Nowadays you still interface with COM through PowerShell
| scripting, and it is pretty nifty.
| brazzy wrote:
| So basically what Amiga OS had with ARexx in the 1980s.
|
| Edit: I misremembered, that was the 90s as well because it
| was a later development in the Amiga ecosystem.
| ptx wrote:
| This use didn't go away after the 1990s - Office still uses
| Visual Basic which still uses COM.
| pshc wrote:
| Codebases are, in my mind at least, a virtual space. I believe
| that one day programs will look like factory floors or cities.
| They will produce and consume physical analogues for values and
| types, which you can pick up and examine. Want to debug a
| function? Strap on your VR headset, teleport into its physically
| reified room and watch the execution. Tinker with the pipeline in
| real time.
|
| I've been dreaming about this forever, and there have been many
| attempts, but with remote work and VR going mainstream I think
| someone will eventually build something usable and scalable.
| Tyr42 wrote:
| I mean, pay Factorio and you can see it.
| djrobstep wrote:
| Sounds cool, although a long way away when we're still dealing
| with text-based development interfaces right now. Definitely
| need more immersive environments and fully inspectable
| programs, and actual graphics in our terminals and editors!
| samsquire wrote:
| I call this idea If you can see it you can use it and right click
| use.
|
| So if you see a filename on the CLI, you can right click on the
| file name and interact with the file with a GUI.
|
| Or you could hover over a <pre> tag in the browser of some dot
| syntax or table and right click and click Use. It would run
| various heuristics over the data to work out what the data is and
| then import it to the right program.
| djrobstep wrote:
| I like your thinking!
| mcguire wrote:
| Like the Acme or Wily editors?
___________________________________________________________________
(page generated 2020-11-07 23:01 UTC)