[flohofwoe]

It's not about the touch screen, the UI, the hardware or "casual" vs "professional" users, but simply about the ability to create(!) and combine small specialized tools into something that's bigger than the sum of its parts.

The "walled garden app ecosystem" is exceptionally bad for this, and the UNIX shell is exceptionally good, but both are extremes. It's hard to imagine how a UNIX-like flexibility can be achieved inside an ecosystem that's optimized for passive media consumption and online shopping though.

[fallenhitokiri]

This is IMHO a really good point. Somewhere in between App Groups, Share Extensions and custom URL schemes I really hoped at some point we would see a way to make this happen.

My wife is currently using Affinity and Adobe products to work on illustrations. It works mostly the same for her as on her Mac. She does not care about small, specialised tools, she wants one app that does everything she needs. The iPad is doing a great job running those apps.

I am not sure how many users (outside of the ones who got used to it) want UNIX-like flexibility vs "give me an app that does everything I need". If the later group keeps getting larger the walled garden approach to apps might actually work.

[howaboutnope]

But for anything non-trivial, that app that does everything person A needs doesn't do what person B needs, and vice versa. It mostly does what person C needs, who is a whiteboard made subset of the most used features and doesn't match anyone.

It's not just UNIX-like flexibility, it's human uniqueness, and the uniqueness of the tasks they perform and the ideas they have. It's also the difference between owning and knowing how to use a tool, versus renting someone to do it for you who might help you today, but could rob or hurt you tomorrow.

Just consider how we spend decades to teach new humans to read and write as well as they can learn it, versus just giving them a bunch of emoticons to signal when they're hungry or sleepy or bored. Because we expect them to become full peers, and architects of their world, responsible for the next generation, not just consumers picking options others prepared for them. And we don't care if they want that, because we know what they don't know, yet. We base our judgement on the information we have, not the information they lack.

Making an exception for computer literacy just because it is hard (as if language and reading and writing aren't until you get used to them) set us on a terrible path.

[walterbell]

> Just consider how we spend decades to teach new humans to read and write as well as they can learn it, versus just giving them a bunch of emoticons to signal when they're hungry or sleepy or bored. Because we expect them to become full peers, and architects of their world, responsible for the next generation, not just consumers picking options others prepared for them.

Thanks for this summary of the case for general purpose computing.

[arvinsim]

The problem is that company incentives want users to just be consumers. Because locked in users that are dependent on the company is very profitable.

[emodendroket]

Why should the average person learn these skills in particular rather than plumbing, cooking, woodwork, auto repair, or any number of other useful skills they could also learn?

[sixstringtheory]

I don’t see your point. I think people should learn those too if they want. And we do need people to learn them.

But nobody would suggest that someone that can only put together an IKEA nightstand is qualified for carpentry on the level of house building or fine cabinetry. Just because you can water a garden with a hose doesn’t qualify you to work on water mains.

[emodendroket]

Right. But most people do not work on water mains or as professional carpenters, nor does society need them to be able to start at any time.

[giovannibonetti]

Because most of those skills are relatively easy to be picked up at any stage in life, whereas computer literacy - or even a new programming language - is quite hard to introduce into people after they are 30 or so.

Take this with a grain of salt, as it is based mostly on my own experiences, although I remember at least an essay from Paul Graham talking about how rare it is to have a programmer switch languages after some age.

[emodendroket]

I have changed languages every time I started a new job and sometimes just switching projects on the same job. I don’t think learning a language is really that big a deal for a programmer.

I’m sure it’s hard to learn to be a serious programmer past a certain age. But it’s not easy to learn a new (human) language or get really good at many of the other skills I mentioned that quickly either.

[arvinsim]

Why not? What makes software development any less useful than the skills you mentioned?

[emodendroket]

Nothing. But I don't see anyone claiming that every high schooler needs to do mandatory shop or culinary arts classes, or lamenting that because you can just buy furniture in a store people no longer know how to make it themselves.

[vladvasiliu]

> I am not sure how many users (outside of the ones who got used to it) want UNIX-like flexibility vs "give me an app that does everything I need". If the later group keeps getting larger the walled garden approach to apps might actually work.

I think this is crux of the matter. Even outside the Apple ecosystem I see a tendency in people to not think about composing multiple tools but to look for an app that does everything.

I'm talking about my colleagues, working in IT, but in a Windows environment.

And on Windows there's PowerShell, which, although slow and to me not as flexible as bash, still allows one to do quite a lot of things. But people seem to see using it as a last resort, when there's absolutely no way of doing what they want by clicking around some window.

[emodendroket]

It's hard to remember all the arguments for a passel of command line utils. Discoverablility is much better for a GUI, and only someone who wishes to do something unusual or specialized will chafe against the limitations.

[flohofwoe]

UI discoverability has massively declined with the advent of touch UIs though. You can't hover a UI item to see what it does, and there's a lot of non-intuitive "magic swipes" and hidden UI elements in smartphone UIs which you just have to know about.

[zozbot234]

Touch UI items tend to be larger by necessity (and to have surrounding padding as a safety factor, which increases their "effective" size even further), so you don't really need to do the hover thing. Just redesign them to be more self-explanatory as opposed to wasting that space.

"Magic swipes" could also be redesigned to be more intuitive, e.g. with some background soft-3D effects that make swipe-sensitive areas "stand out" from the neutral background.

[emodendroket]

Aren't magic swipes basically the analog to keyboard shortcuts?

[sixstringtheory]

Your argument applies to all kitchen sinks, regardless of whether they are considered one application like VSCode or an operating system withs collection of applications like Unix. Both still have all the capabilities for text editing, syntax highlighting, version control and executing scripts. You can spread complexity around in different ways but you can’t eliminate it.

Personally I find GUI discoverability to be like the hunt-and-peck model of typing, vs touch typing being CLI, and I don’t think it’s a coincidence that touch typing and CLI go hand in hand: you never leave home row. You think about what you want to do and type the command, instead of looking through panels of icons or more exotically arranged buttons (which in the newest web apps, constantly jump around as the page lazily loads, new elements appear forcing layout changes, fonts load causing text reflow… I frequently tap the wrong menu item because what I really wanted got pushed down by a new appearing element as my finger approached the screen.)

[emodendroket]

Maybe with something like PowerShell, with very consistent command names and arguments, this model is believable, but I don't know what other than memorization is going to tell you that "less" is for reading a file and "dd" is for copying one disk to another.

[vladvasiliu]

I agree with you about discoverability, but in practice I find that tasks aren't completely new every time, there usually are common principles. With usage, you kinda get to know what is and isn't possible, even if you don't recall the precise details of each and every command. So you can look them up, knowing more or less what you're looking for.

On Linux, `--help` usually... helps. Or there's the man. On Windows, the MS docs are usually usable to find things.

Of course, it may not work 100% of the time, but I find it's a question of philosophy. I'm not a Windows user, so I generally approach it with a mentality of "it would be nice to be able to do this, let me check real quick if there's a way". I usually manage to not have to click around for two hours when I have to do something repetitive.

[emodendroket]

Hm, well, part of the problem is, what man page are you even looking for? You already have to at least know the command you want. Honestly I usually end up resolving my queries with Google instead.

[eecc]

Uh no.

Take clicking around a Microsoft ISS configuration on Windows 2000 vs an Apache httpd config file and it’s online doc.

I briefly tried both, and didn’t look back

[emodendroket]

For a task like configuring a Web server you're right. But do you think most tasks people do on a computer are like that? I don't think that they are.

[giovannibonetti]

I think I saw a command line tool that would show the documentation for all flags when you pressed tab... I don't remember it's name, though.

[emodendroket]

Even in Unix it's not like everyone is satisfied with small and specialized applications, or Emacs, let alone modern IDEs, would never have been created.

[adrusi]

That's just it. The future is very likely most people using iPad-like devices. They will need some kind of keyboard, so I'm not sure it's going to be tablets mostly, but the software will resemble that of smartphones.

But no desktop operating systems are well suited to being used primarily by professionals, not even Linux. The desktop paradigm is fine, but it was designed with the idea of making computers more accessible, and it inhibits composing different pieces of software together, which is what a professional-first operating system should optimize for.

I'm not sure how viable a good professional OS is. It would arguably require graphical software vendors through the biggest design paradigm shift in their history, to serve a relatively small market. The transition to the desktop paradigm wasn't as demanding — you just switched from taking control of the graphics hardware and controlling the entire screen to doing basically the same thing, just with the OS as a proxy so that you're rendering to a smaller rectangle. Composable graphical interfaces means abandoning the idea of having complete control over your rectangles.

[f6v]

> But no desktop operating systems are well suited to being used primarily by professionals

I love macOS and I’m a professional. I mean, I get paid for what I do. I’m a professional, right?

[adrusi]

Well it's roughly as good as your other two options, none of which are terrible. I'm not trying to insult the people who use.. literally any operating system available today.

But surely you can imagine ways that macOS could be better suited to your needs. Why (to give an example that's easy to explain briefly, not necessarily the most important one) are the various things you have open organized primarily by which application can open them, instead of which task they're relevant to? You can organize your browser tabs by task by using multiple windows, but why can't those windows hold anything relevant to the task they represent except browser tabs? Why can't you have your terminal and text editor grouped with your webpages? It's because less sophisticated users expect each window to belong to exactly one "application," and because software vendors assume that their job is to make self contained "applications," and not composable graphical components.

[woah]

You can use separate desktops. I don’t bother though

[adrusi]

Yes. And yet people who use workspaces still use windows with multiple tabs, and have the layout of windows in the workspace dictated by application-level sorting.

I actually used a desktop that let you group content from different application in the same group of tabs for a couple years in college, by using i3/sway and a custom Firefox extension. It's an upgrade over just workspaces. I stopped working this way because I switched to tree-style-tabs and there's no window manager that gives you anything like that, and it was on net a workflow improvement.

[heavyset_go]

Plasma Desktop does this with Activities.

[_fat_santa]

I feel like a traditional OS will always stick around because of software developers. I couldn't imagine trying to build an iOS app on an iPad, even an iPad Pro with a keyboard. There will always be some more advanced tool that is used to build the tools.

Thought it will still be interesting to see where that will go in the next 20 years. Like you said with the convergence of desktop and mobile devices on the one hand I can't see traditional OS's surviving but on the other hand I don't se another option given that's the only medium to build the higher level software.

[adrusi]

That all sounds right to me. And with everyone who doesn't need all the nitty gritty access that software developers (and some others) off using different OSs, the advanced OSs that software developers use will have no reason to cater to anyone who doesn't understand how a computer works or isn't willing to read a bit of technical documentation.

[jonas21]

> I couldn't imagine trying to build an iOS app on an iPad, even an iPad Pro with a keyboard.

Why not? The only officially-supported way to build iOS apps right now is using Xcode on a Mac. What would be the difference between using the Xcode app on a Mac or the Xcode app on an iPad with a keyboard?

[skydhash]

Yesterday, I was debugging some code. I had 3 macvim windows, 3 iterm tabs, firefox and the simulator open. That’s just in one space. The others were general browsing, communication and media. As most as I love my iPad, it only works great for single and focused task (note taking, researching, video meeting, drawing,…)

[GeekyBear]

The sheer number of on-screen controls in a single professional app Window present a problem when you have to make them all large enough to be a touch target.

[adrusi]

That might be an issue for non-programming work like video editing, 3d modeling, animation, &c. But tons of programmers just need a text editor with a total of zero buttons, a terminal, and a web browser.

Xcode for macOS isn't designed for that, but no reason xcode for iPadOS couldn't be.

[kcb]

1 monitor and cumbersome multi-tasking would be a nightmare for development work

[diegof79]

> The desktop paradigm is fine, but it was designed with the idea of making computers more accessible, and it inhibits composing different pieces of software together,

The Xerox Parc and Smalltalk are the ancestors of today’s WIMP UI. If you look at Squeak (or Pharo) you’ll see how is possible to make a desktop UI that’s more composable than the usual Unix shell. The problem is not the desktop paradigm, but a lack of commercial interest.

[adrusi]

I wouldn't call smalltalk systems part of the same paradigm as mainstream desktops, although if historians call them both desktops then we can use that name for both.

I think we can do better than squeak/pharo, but they're fine, really. They're at least the kind of thing I'm talking about.

[diegof79]

> I wouldn't call smalltalk systems part of the same paradigm as mainstream desktops

Yes, Windows and Mac copied the WIMP UI. But, they ignored the composable message passing architecture. The goal of Smalltalk was to make a computing environment with a GUI, the programming language was like C to Unix.

During the 9x-2000 there was a lot of hype on providing the same system composition capabilities in Windows and Mac: ActiveX, Windows Scripting Host, AppleScript, etc. But, these things are dying. Those frameworks are not cross-platform, and they were not designed with security in mind. The interest shifted to the web.

My point is: It's possible to make a programable/extensible desktop UI. But, today the cost of doing it is high, and the interest is low.

> I think we can do better than squeak/pharo

I agree. I used Smalltalk -to work- for 3yrs. Smalltalk is full of good ideas, but it also has many bad ones.

I'll love to see something better too... In a sense JavaScript and the browser share some of the St GUI capabilities: you can inspect, experiment, and browse the code of any app. But, in other aspects the web platform is terrible.

I hope that the competence between Apple (pushing for apps in iOS/iPadOS) and Google (pushing for PWA), will renew the interest on creating environments where anybody can code and tinker with other apps. (if PWAs evolve to have the same capabilities as native apps, Apple will need work hard on removing the app creation barriers to compete -I don't see native Android apps as a competence to Apple iOS... but I might be wrong)

[GeekyBear]

> During the 9x-2000 there was a lot of hype on providing the same system composition capabilities in Windows and Mac: ActiveX, Windows Scripting Host, AppleScript, etc. But, these things are dying.

iOS and MacOS are both converging on Shortcuts to accomplish this.

[rank0]

Which “professionals” do not use desktop operating systems?

[adrusi]

Well I'm claiming that most future ones will not. There's no reason that smartphone/tablet style OSs couldn't accomodate video editor, graphic designers, writers, salespeople, real estate brokers, etc in the future. And the demand exists, so I'm betting that that'll be our actual future.

But they cannot in principle accomodate software developers.

[rank0]

You think people will abandon the mouse and keyboard for a touch based interface?

[idoh]

You can just remote into a terminal if you want a CLI from an iPad.

[ratww]

> the ability to create(!) and combine small specialized tools into something that's bigger than the sum of its parts

Funny, the possibility to do that currently exists in a walled garden, for audio apps: https://audiob.us . This is used by creators and live performers, exclusively. I don't think anyone uses applications in this ecosystem for "consumption" purposes.

The problem was never was the current OSs, it was just about app makers not willing or not knowing how to collaborate amongst themselves. It was also never about open vs closed, since AudioBus is proprietary and 99% of the apps that support it are also proprietary.

The thing about UNIX pipes is that they use plain text. AudioBus uses audio. Those are two things that naturally impose limitations. Developers seem ok with those "natural limitations" but whenever you want to impose limitations to something else you immediately get pushback.

You wouldn't be able to do that in a business CRUD app for example. The amount of wheel-reinvention is too big on those, compared to audio/video/unix-tools.

[jon-wood]

Assuming enough apps expose functionality through it, Shortcuts is the bridge between walled garden apps and UNIX pipelines, and Apple made a very clever move in making Shortcuts how Siri discovers functionality.

[walterbell]

Is there a way to version-control shortcuts and import/export them between devices, especially for those unwilling to use iCloud and associated keyring upload and content scanning?

[jon-wood]

Not that I can see, but frankly if you’re not willing to use iCloud, give up on Apple devices because it’s what makes basically all the good stuff work. (This is not an invitation to get into yet another debate on recent events)

[walterbell]

There are enough good iPhone/iPad apps to use Apple devices with self-hosted storage (WebDAV, CalDAV, SMB/SFTP/DLNA, Git).

[tomjen3]

The Unix shell was exceptionally good for its time. Powershell, IMHO, go it right by not sending strings but objects around. This gets you around the issue of spaces and means you can send more than one value.

I haven't been able to play with the shortcuts functionality because I don't have an iPhone, but if it is what I think it is it, it is a powerful tool to do things with.

We shouldn't fail to acknowledge that most, if not all, spend more time consuming than creating.

Then you have the group that isn't served with something as powerful as a real computer. My grandparents would be much better served with an iPad instead of a computer, since all they need is a browser and a system to do video calls.

[flohofwoe]

And that's exactly why the "great unification" doesn't make sense.

[linguae]

I wholeheartedly agree; the app-centric model of today's desktop environments is the antithesis of the Smalltalk vision of composability. In an environment where everything is a live object, programmers can send messages to those objects. Thus, in the Smalltalk environment you end up with something even more powerful than Unix pipes and redirection.

Now, Smalltalk provides the infrastructure for composability, but Smalltalk by itself doesn't provide us the full-fledged desktop environment and applications that users have come to expect; they would have to be implemented in Smalltalk. But where things get interesting in a Smalltalk-implemented desktop environment is that the live object environment is still there, leading to interesting possibilities. Imagine being able to control a word processing program through scripts written outside the word processor, without the word processing program itself having to implement something like Visual Basic for Applications? Imagine being able to control a spreadsheet with Smalltalk methods on cells instead of having to learn the spreadsheet's language or having to learn Visual Basic for Applications? The possibilities become even more intriguing when objects can interact with each other in ways that are far more general than Unix pipes. This is the desktop environment I dream of using, the unification of the ease of use of GUIs and the flexibility and programmability similar to the Unix shell.

Oddly enough, in the mid-1990's Apple implemented a less-ambitious (but still very ambitious for its time) version of this vision known as OpenDoc (https://en.wikipedia.org/wiki/OpenDoc). There are some wonderful videos at https://www.youtube.com/watch?v=oFJdjk2rq4E (a three minute summary) and at https://youtu.be/2FSFvEIpm5o (a 50-minute demo). OpenDoc was released in 1996, if I recall correctly, and there were some applications written with OpenDoc, most notably the CyberDog web browser (https://en.wikipedia.org/wiki/Cyberdog). However, once Apple bought NeXT in late 1996, Apple committed itself to building its next-generation operating system on NeXT, which had its own collection of object-oriented APIs. The cancellation of OpenDoc led to this famous spat during WWDC 1997 when a disgruntled developer questioned Steve Jobs on Apple's decision to cancel OpenDoc (https://www.youtube.com/watch?v=oeqPrUmVz-o).

Why was OpenDoc cancelled? One can argue that OpenDoc's cancellation was due to Apple needing to have a tight focus during its very vulnerable period in 1997. The proof is in the pudding: mid-1990's Apple before the return of Steve Jobs was an unfocused beacon that was able to produce many interesting technological demos (the Dylan programming language, SK8, OpenDoc), but there was no single coherent vision. The Taligent and Copland projects, which strove to replace the classic Mac OS with then-modern underpinnings, were disasters. OpenDoc was just one out of the many, sometimes competing, visions that Apple had during this time. Steve Jobs was able to turn around Apple's fortunes by having Apple focus on one vision for the Mac.

However, another way of looking at the cancellation of OpenDoc is that its success would have completely upended the software industry. Instead of software vendors selling apps, software vendors would sell components, which users can integrate to create custom workflows. While I believe that this would have led to a lot of flexibility and user-empowerment, OpenDoc would have also been seriously challenged by major software vendors like Microsoft and Adobe, whose empires were built on selling large, proprietary software packages. They were not going to give up their moats without a fight.

Still, I dream of the modern realization of component-based software, and it's something I've been thinking a lot about for the past few years.

[wrs]

You forgot Newton: applications are components written in a memory safe language all running in the same address space with full access to each others’ objects. The “imagine…” scenarios above are entirely doable (indeed, were done) in NewtonOS.

[musesum]

> another way of looking at the cancellation of OpenDoc is that its success would have completely upended the software industry.

Ironically, that was the main interest of Brad Cox who, with Tom Love, created Objective-C, which was acquired by NeXT, and became the way forward for Apple.

In my experience, it is very hard to build a business around software objects. I spent a couple years trying to build an App around the Apple Watch. But, Apple only allows 3rd party complications. It is essentially a component. Apple recommends focusing on doing only one thing.

Moreover, as a component, you the developer often have less control over the UX. On the Apple Watch, when a user opens -say- Spotify on the iPhone, your app is kicked out.

So, a couple weeks ago, I decided to put the Apple Watch development on hold and do something else on the iPad.

[linguae]

I concur; I believe selling software components is a difficult business model for the reasons that you mentioned. This may have contributed to Steve Jobs' decision to cancel OpenDoc in 1997: Apple needed the support of its existing base of software vendors, especially Microsoft and Adobe, in order for the Mac to survive, and OpenDoc, which was designed with the express purpose of challenging the types of monolithic, large applications that Microsoft and Adobe developed, was not going to win the support of Microsoft and Adobe. Even when it came to the question of whether Microsoft Office and Adobe Photoshop would be ported to NeXT's APIs (later named Cocoa), both Microsoft and Adobe balked, which forced Apple to develop the Carbon API to make it easier for software developers to port programs written for the classic Mac OS. If Microsoft and Adobe balked at having to use Cocoa, imagine the howls that would have came from a demand to port their software to OpenDoc.

However, I believe that component-based software is a natural fit in the FOSS community. One of my favorite Hacker News comments of all time is https://news.ycombinator.com/item?id=13573373, where the author makes the case for why component-based software would have been a better fit for the Linux desktop than the standard approach of trying to build a FOSS replica of large, commercial platforms.

[wibblewobble123]

For a modern take on this you might like Paul Chiusiano’s work

http://pchiusano.blogspot.com/2013/05/the-future-of-software...

And that culminated in

https://www.unisonweb.org/

Essentially all code is pure functional and content addressable, meaning it’s inherently distributable and transferable (including closures). Like Smalltalk but with more use of modern programming language theory.

[simonh]

Are Windows, Linux and MacOS really better platforms for lots of tasks, performed by mainstream and professional users for daily tasks, principally because they are used to pipe text between command line tools? This is delusional.

I have good news, iOS user's productivity woes are solved. Using iSH you can pipe text between command line tools all day every day. Finally the power of the iPad is unleashed!

[imiric]

This must be sarcasm... There's much more to being productive with an OS than piping text on the command line in an emulated and highly restricted environment. The command line is a management interface to the OS, not a sandbox you get to play in with the tools the manufacturer allows you to.

I would like seamless interoperability between CLI and GUI apps, a unified file system, the ability to run virtual machines, containers[1] or maybe just nginx[2].

And then you have the usability issues of the iPad(OS) like external displays being mirrored only, or only recently being able to actually access files from a USB drive...

The iPad is a great media consumption device, that has some limited professional use (art, video editing maybe), but let's not fool ourselves that it's anywhere near being a replacement for a fully functional computer.

[1]: https://github.com/ish-app/ish/issues/63

[2]: https://github.com/ish-app/ish/issues/137

[flohofwoe]

The text piping is just one small part and not the most important, instead its about sharing and processing any type of data with small tools that can be combined like lego blocks (and if there isn't the right lego block for a problem you can build your own). The UNIX shell is just one very primitive implementation of that idea (and yet it's still much more powerful than anything we have on iOS or Android).

In the "mobile app ecosystem", each application is more or less an island. It would be possible to achieve something similar on iOS/Android devices, but the entire "value proposition" of walled garden ecosystems isn't compatibel with this idea of open and creative computing. One prerequisite is that I actually own my device and can do anything I want with it, without the platform owner getting in the way.

[simonh]

On iOS now we have all the same interchange mechanisms between applications we have on desktop. Decent file management, rich content cut-and-paste, side-by-side applications. Share sheets are great.

The main limitation is the interaction model, and that's just down the the mechanics of touch interfaces. Firstly fingers are imprecise big fat squishy blobs. Secondly the tablet form factor doesn't afford a large physical keyboard. These are the impediments and they're just facts of the form factor. the new multi-tasking interface in iPadOS looks like a great step forward, but it's always an issue.

[amelius]

iOS is also great as a software copy protection scheme. You can't have that in an open OS without compromises.

[amelius]

It's basically like DRM at the device level.

[Glide]

Counterpoint to this, is that I’ve seen people be reluctant to click where they are not reluctant to touch. That barrier is vital for people who did not grow up with tech to interact and experiment with it.

Here’s one question: hover on focus vs click to focus?

Hover makes sense if you think of the pointer as a finger.

[flohofwoe]

Those are just different input paradigms that have evolved over time, one isn't inherently superior to the others. Cars have a much more difficult UX than kbd+mouse, touch, gamepad or (Wii-style) point-and-wiggle interfaces, yet the relative difficulty of driving a car for "technical" vs "non-technical" people rarely comes up in discussions.

[mhuffman]

>That barrier is vital for people who did not grow up with tech to interact and experiment with it.

Who are you talking about? Senior citizens? Or maybe people outside of the US in developing countries? Because anyone under 50 in the US has grown up around tech.

[gjsman-1000]

Don't just assume that default. Remember more than 10% of the US still doesn't have internet, and a shocking portion of the US has smartphones as their only method of computing and would be dumbfounded at a PC.

[mhuffman]

Yeah, I don't buy that, unless you are talking about the Amish or someone willfully avoiding technology. And in that case, we are not really losing "future techies" are we?

Regarding the smartphone point, again, you might be talking about elderly people or self-isolated people. Otherwise all people under 50 have used computers in their school classes and would not be dumbfounded at a PC.

[musicale]

You can automate and glue iOS apps together using Shortcuts, script them with Scriptable or Pythonista, etc..

It's somewhat analogous to using Automator and/or macOS' Open Scripting Architecture.

[_fat_santa]

Yeah but to even try and compare that to the power of the UNIX shell is silly.

[zepto]

> The "walled garden app ecosystem" is exceptionally bad for this, and the UNIX shell is exceptionally good, but both are extremes.

Very true.

> It's hard to imagine how a UNIX-like flexibility can be achieved inside an ecosystem that's optimized for passive media consumption and online shopping though.

Unix-like flexibility is also extremely insecure and easy to screw up.

It’s fairly obvious that the App Store ecosystem can and is becoming increasingly flexible. Things like shortcuts and safari extensions are obvious examples.

Unix-like flexibility will likely never come to iOS, nor should it, but it’s easy to imagine a steady drumbeat of easy to use managed points of flexibility that ultimately provide 80% of what people use Unix-flexibility for but without the insecurity or brittleness.

It’s not so easy to imagine how ease of use, security and robustness can be retrofitted to unix any other way.

Remember iOS is Unix. It’s just a matter of what they build for end users.