> Think about adding up some numbers in a tabular structure. That's straightforward with most programming languages. But what if that same table is in a web pag

> Think about adding up some numbers in a tabular structure. That's straightforward with most programming languages. But what if that same table is in a web page, or a mobile app, or a PDF? It's right there on the screen, it's probably encoded as a table in the markup. So the data is there. And yet, we can't query it. I mean, it sounds like you're describing command line tools that fetch the data you want, wherever it might exist (in a table, in an image, on the web, across a network link, whatever) and pipes the data you're interested in on the command line so you can use a whole ecosystem of filtering/transforming/combining/querying whatever — even your own code. > Currently, "doing programming" is a segregated activity from mainstream computing - separate software, command lines, specialist knowledge, clunky text-driven interfaces. What's clunky about a text-based interface like a command line, or code written to process simple data in text form or in files or in a database? It seems like you have a /integration/ and /ingestion/ problem, not a programming or app design problem. The issue is that, wherever the data lives, you simply need to get it out and transformed into a format that makes it easy to process it with the amazing and existing tools that have existed for decades. The reason that apps, websites, etc. exist are either because those interfaces aren't built for programmers to consume (i.e. it's for non-technical users, or business people, or some other purpose), or out of ignorance of the power of the command line, or because of personal preferences of the person who designed it. > How do you build ubiquitous programmability into interfaces without adding clutter or reducing usability? You don't. You build integrations and ingestion pipelines to move data from wherever it may currently live into a place that is easy for your system to process. The reason you can't get ubiquitous programmability is because different users/consumers need different things from interfaces, and that's just a simple fact of life. The closest (and one of the most powerful) thing we have that's pretty close to ubiquitous across so many different types of users are spreadsheets. But these come with tradeoffs as well — first of all if you just need the information and don't want all the surrounding capability then a spreadsheet is overkill. If you need rigid validation, and hugely powerful query capabilities then it needs to be in a database. > The realization that the software experience is still built on artifacts of computing from the 80s like text-based command lines is a lot less surprising considered within the context of this ongoing decline. Software is built on these text-based command lines because they work. They're not clunky once you get to learn them — they're pretty much the best thing anyone's ever done. They're still around because no one has improved on them to a degree so significant as to replace them. It sounds like this article is proposing a new way to do things, will which just end up being yet another walled garden. It's absolutely preposterous to think you're going to reinvent 60+ years of advancements in computing when the things that have been working, evolving, and still constantly improving for at least the last 20 years of those 60 years work incredibly well already. > Climate change has shown us that mere awareness of the situation we are in isn't enough. Actual liberation from disaster requires a bold change of direction and a acknowledgement of shared, public goals beyond the financial. Climate change taught us this? Wow. Learn your history. There's /always/ a mix of short-term and long-term research going on, there always will be, and while the mix might change a bit no one part of it has even been completely dried up. Some people and organizations have short-term goals. Some have long-term goals, and lots of orgs fall somewhere in between. Innovation only looks like a really inefficient search and cobbled-together mess when looking at it in hind sight, where you can look backwards and see, "If only the people 20 years ago would have done X, Y, and Z and not wasted time on A, B, and C we would have been in the present 20 years earlier" —- but the major problem with this kind of thinking is that this is only obvious in hind sight, and nobody has the benefit of predicting the future from the present. Is there waste? Sure. But the idea that old stuff is clunky, or terrible, or poorly designed just because you're judging it from modern standards and a place where you have access to more information than people in the past is just silly. You're just going to wind up creating yet another attempt at "solving" computing once and for all. This kind of silver-bullet thinking is naive at best. No one has invented a silver bullet because there either isn't one, or so much collectively learning needs to happen /before/ it can be found that we just need to keep doing the sometimes boring work of trying things and seeing what works. It doesn't feel glorious in the present, but that's what it takes. The problem with judging the past is that there's always waste, you never know which part is the waste and which part is going to lead you to a good solution. The searching (researching) is what gets you there, and it's hard work. > Rare-but-notable efforts like Xerox PARC suffered similar fates, able to fend off the bean-counters for a while but not indefinitely. This is romanticism, and "good old days" kind of thinking. The past is worse in almost every single way, and to put Xerox PARC up so as to imply that modern research orgs aren't probably better in almost every way is a bit foolish. Is modern research flawed? Sure, but so it was in the past as well.