Yes, the point was about doing it in a pipeline. The pipeline is the basis for composition of plain text in the unix shell. If something as basic as sorting a table is hard to do, it should make us question just how good the unix shell/plain text philosophy actually is.
Baking --sort flags into shell tools is a sign that the tools do not compose well.
I've spent some time thinking about it, and I respectfully disagree.
I don't think a `--sort` flag is a failure of composability, the producer understands image size semantics better than the sort command, you can either bake everything into sort, making it an all encompassing command or you can simplify the previous step with a sort flag.
Your original powershell command is way more verbose and complicated, and maybe that's the price to pay for composability, but I'd rather just use the `--sort` flag and not spend hours or days coming up with some other undocumented and undiscovered way of doing it, the answer is right there ready to be used.
I think my point is that it's a violation of the UNIX principle of doing one thing really well, but I don't think that is a violation of composability.
Tl;dr: Plain text's bad composability forces the dichotomy that you identify between --sort and sort. I agree with you that --sort often can be a sensible UX choice regardless, but losing out on composable middle ground is strictly a loss in terms of power and expressiveness.
Thanks for taking some time to think about it. Despite my pretty absolute wording in GP, I do think that there's nuance here. But what I want to drive home is that the tight coupling/brittleness inherent in plain text composition systematically limits composition.
What I'm not saying is that every --sort option is bad sign for composition. Like you point at, sometimes it's just a simpler UX to have such an option included with your command. As a matter of fact, you see that in PowerShell sometimes with the -Filter option on various cmdlets.
Plain text's brittleness limits composition by promoting exactly the extremes that you point at (the extremes being overloaded sort, or overloaded producer):
> the producer understands image size semantics better than the sort command, you can either bake everything into sort, making it an all encompassing command or you can simplify the previous step with a sort flag.
I think it should be obvious that baking everything into sort is a bad idea in the general case. Like you say, the producer understands the size semantics better. Moreover, the ergonomics are lousy (see comments by users alloyed and i15e).
Baking everything into --sort is bad because it limits sorting to the producer's own predefined semantics. While arguably better than relying on sort's, the producer won't always have the semantics that the user cares about. E.g. maybe the user wants to analyze the disk space used only on a certain datastore. Maybe some datastores do transparent compression and sorting should be done by physical disk usage. And so on.
These two extremes are basically your only options in a plain text world, but structured data gives you more opportunities for composition. By moving to structured data and eliminating the need for ad-hoc parsing, users and their code can operate at a higher semantic level. In particular, the loose coupling introduced by this approach gives you access to things like lambdas. You're not alone in objecting to PowerShell's verbosity. Here's a terser version that would work if podman image output structured data rather than text, thereby kinda steelmanning this position:
Basically all that has happened is that the plain text->structured parsing was dropped (again, to steelman the structured data vision) and naming conventions were made unix-y.
An alternate version if no specialized podman size command is needed and the sort cmdlet would by default look at an object's size property:
podman image ls --all |
sort -d
In many common cases, I think I agree with you that having --size on the producer is pragmatic and fast. A good UX choice. What's bad about plain text is that there is not/cannot be any middle ground between --sort and sort.
Now, tools shouldn't always oblige the user to compose. Composition is frequently not the best UX. But a shell that systematically limits composition is prima facie worse than one that promotes it. And plain text shells do indeed limit composition.
It's Apple, theres a high chance they'll just delete it and pretend it never existed. They've got a pretty consistent reputation for this now. Dark Sky, PrimeSense, Drive.ai, Beddit, Topsy, NextVR, Fleetsmith, FingerWorks, to name a few.
From what I've heard, it sounds like it's not nearly as good or simple an experience as DarkSky was. But as an Android user I wouldn't know, DarkSky was just killed by Apple for everyone but Apple customers when they merged it in.
This makes it sound like Sherlock was named in response to Watson. It was the other way around.
Earlier versions of Mac OS had an app called ‘Sherlock’[^1] that could search local files and the web in a fairly rigid manner.
‘Watson’[^2] was a third party shareware app very much inspired by Sherlock (and obviously, given the name, not trying to hide that!) that was much more flexible, more ‘OS X-like’, arguably much more user friendly, and was open to plugins (like, there was a movie time search plugin, an eBay plugin, an Amazon plugin etc).
Sherlock 3[^3], in MacOS 10.2, was redesigned with a UI very like that of Watson, and also allowed similar plugins, making Watson obsolete.
In the Apple developer world, “being Sherlocked” came to mean “your app being made obsolete by Apple including identical functionality with the OS”.
But here Apple seems like they avoided that by buying the project instead of creating their own clone. Doesn't that make it nothing lime the Sherlock/Watson situation?
Parent comment said "Well I was thinking about making a competitor...."
Response said "Working on an idea after it has been Sherlocked is a bold choice"
Child comment asked what Sherlocked meant. I explained.
Apple purchasing Swift Package Index is great. The Sherlocking above comment was in response to the suggesting that theyd create a project apple has already made first party
Cloning features and UI in your own product is not dishonorable. Outcompeting someone who didn’t bake in a moat isn’t doing anything wrong, or Burger King and Wendy’s shouldn’t exist.
Well at least they didn't have their product managers reach out to "start a conversation" like Google and Microsoft's who then blatantly rip off the product later.
> "Here's how I see it," Jobs said — I'm loosely paraphrasing.
> "You know those handcars, the little machines that people stand on and pump to move along on the train tracks? That's Karelia. Apple is the steam train that owns the tracks."
> So basically the message was: get out of the way, kid; this is our market.
Hope folks will always keep that in mind as they develop software for proprietary platforms they don't own.
> Hope folks will always keep that in mind as they develop software for proprietary platforms they don't own.
You're right of course and "The Other Road Ahead" was very prescient, but I think the desktop vs web-app divide is marginal nowadays, excepting one huge difference: desktop apps can offer a guarantee of privacy which browser based apps cannot.
Note that a guarantee is just that, Apple offer privacy guarantees, but there is is of course no such thing as absolute privacy or security.
It's perfectly possible to write desktop apps that are thin clients for web apps, so there's no real divide except where the code executes: in the browser sandbox, or in the OS sandbox.
The current issue with desktop apps is mainly UI framework related. The browser based programming model has had so many resources thrown at it that somehow JavaScript and a bunch of divs is probably the best UI framework there is, and it pains me to say that.
I tried running a simple security review on a Terraform module I made and after some thinking, it responded:
> ● The model returned no content because the response was blocked by content filtering.
> Blocked? We are performing a defensive security review on a Terraform module I made, what's blocked by content filtering? This is a legitimate use-case.
> ● The model returned no content because the response was blocked by content filtering.
A waste of money. I'm not going to just hope that the model returns a response, I'm already for paying for wrong responses, I'm not going to pay for no response, especially when I'm paying per token.
I'll never forget the disgust amongst me and my friends when we found out that American television had replaced Attenborough's documentary voice with Oprah fucking Winfrey. Cultural vandalism.
[0]: https://www.youtube.com/watch?v=-dh7COSiB7g