Flutterby™! : The next decade will be built to give it back.

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

The next decade will be built to give it back.

2026-02-11 19:41:13.963683+01 by Dan Lyke 2 comments

Assaad Abousleiman on LinkedIn

The last decade of software was built to capture attention.

The next decade will be built to give it back.

I don't agree with his "plausible sentence generators are the future" conclusion that the rest of this essay goes on to conclude, but I like the strong opener. We have a decade or so of computing that's actively user hostile, and we need software which we can trust, which is on our side.

I do agree with two points:

First, that we need to treat the computing developments of the last decade or decade and a half as actively hostile. Google, Facebook, Apple, Microsoft, et al all have gone completely over from enabling us to finding ways extracting every possible bit of value from us.

Built in applications on our platform have gone from utilities to worthless for our own data unless we cave to demands for additional subscription payments. From media players to just using our own damned hard drives, it's getting harder and harder to use our own data, the focus becomes ways to sell us mediated subscriptions.

We're no longer in control of what we see, instead we're being fed information that serves the wants of capital in ways that emotionally triggers us, with automated measures of the efficacy of those information feeds. Our conversations with our friends and our communities are being mediated by hostile forces.

In the social media and email tools of the '90s, we had the ability to build incredibly nuanced filters to help us automatically control what information we were going to let the assholes impose on our lives. Now, the best of these tools (things like Mastodon on the Fediverse) give us simple yeah/nay keyword filtering.

Second, that this software needs to help us automate processes that we currently do manually. As operating systems have moved from the command-line to GUI, we've lost the physical artifacts of process. I think it's worth diving deeper into this.

Every use of an LLM to write code is an acknowledgement of the failure of the programming languages that it's implementing code in. We can describe the process well enough that a lossy plausible sentence generator can guess at what we meant, why can't we make the language express that same meaning unambiguously, in ways that are accessible?

We need a move forward in computing language design to give us languages with grammars flexible enough that people can express, and we can iteratively guide them into a repeatable formal definition that they understand, and that the computers can deterministically execute.

Finally, we need business models, and computing tools, that serve us, rather than those who are looking to further exploit us.

[ related topics: Apple Computer Humor Microsoft Software Engineering moron Writing Journalism and Media Graphic Design Community Douglas Adams ]

comments in ascending chronological order (reverse):

#Comment Re: made: 2026-02-11 19:51:12.172757+01 by: markd

> languages with grammars flexible enough that people can express

So long as they learn the lessons from AppleScript. It's very readable, but for a bunch of us, very very difficult to write until you "get it" (and try as I might, I never did). Back in the early 2000s at the GOOG, we had a guy that was our applescript whisperer (love ya DPO). If any of the mac developers needed some Applescript to say drive Google Earth to do something, or our desktop product, we'd go to him.

#Comment Re: made: 2026-02-11 21:07:07.271397+01 by: Dan Lyke

Yeah, a few years working with Perl taught me that for connector code I care much more about writability than readability, and often those are at odds. But for short things, often it's as fast to simply re-express the idea as it is to figure out what the previous person was trying to express.

For longer things, there's the issue of systems integrity and weird-ass side effects (yeah, looking at Perl's OO wrappers there).

And I think there's a lot that can be taken from a Rust-like approach to "Did you mean?" with integrated command completion, so people are guided through he process of building code artifacts.

Add your own comment:




Format with:

(You should probably use "Text" mode: URLs will be mostly recognized and linked, _underscore quoted_ text is looked up in a glossary, _underscore quoted_ (http://xyz.pdq) becomes a link, without the link in the parenthesis it becomes a <cite> tag. All <cite>ed text will point to the Flutterby knowledge base. Two enters (ie: a blank line) gets you a new paragraph, special treatment for paragraphs that are manually indented or start with "#" (as in "#include" or "#!/usr/bin/perl"), "/* " or ">" (as in a quoted message) or look like lists, or within a paragraph you can use a number of HTML tags:

p, img, br, hr, a, sub, sup, tt, i, b, h1, h2, h3, h4, h5, h6, cite, em, strong, code, samp, kbd, pre, blockquote, address, ol, dl, ul, dt, dd, li, dir, menu, table, tr, td, th

Comment policy

We will not edit your comments. However, we may delete your comments, or cause them to be hidden behind another link, if we feel they detract from the conversation. Commercial plugs are fine, if they are relevant to the conversation, and if you don't try to pretend to be a consumer. Annoying endorsements will be deleted if you're lucky, if you're not a whole bunch of people smarter and more articulate than you will ridicule you, and we will leave such ridicule in place.


Flutterby™ is a trademark claimed by

Dan Lyke
for the web publications at www.flutterby.com and www.flutterby.net.