Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

That's not fixing the biggest flaw, it's just addressing a small set of specific use cases.

If anything, it's a bandaid that highlights the biggest flaw of UNIX philosophy: everything is passed as unstructured text. Because of it, half of shell programming is just piecing together ad-hoc, buggy parsers that interpret the input, possibly rearrange it, and then dump it down the pipeline as unstructured text, so the next step can do it all over again. And then, of course, every CLI program has to do that too.

This program is using a machine learning model to parse its input; while this may be the only reasonable way to go about guessing emojis from arbitrary text, I can easily see people doing the same to parse outputs of Linux CLI tools at runtime, because it looks much more pleasant and might be even more reliable than writing input parsers by hand. Let's pause here to consider the absurdity of that situation.

View on HN

I don't use PowerShell often at all, but this IMO is one thing it gets right, by piping .NET objects and implicitly piping to `Out-Default` at the end.

Of course this is another standard that tools would have to be incredibly careful to keep track of, but JSON is decently mature and a bunch of modern tools can operate in it, so at least there's slow progress away from the plaintext quagmire.

> might be even more reliable

simply impossible. when a input parser breaks, it breaks. with a LLM, it breaks... sometimes, for different reasons. Let alone the enourmous computing power needed compared to simple input parsers.

Mmmm... perhaps a </sarcasm> was called for there. Clearly it isn't the biggest flaw of any system that it fails to properly label everything with emojis automatically. Indeed, I think I fear the day when I see an editor pop up on Hacker News and it is listed as a feature that it doesn't use machine learning to automatically splatter whatever open standard GenMojis turns into everywhere into its input, because of what it implies about everything else....

And yet it is precisely that unstructured text which allows programs to be infinitely composable, whether they were written 30 years ago, today, or are yet to be written. This is what allows programs like teemoji to work with any other program, without directly supporting it.

Besides, what format should the data be structured in? In the 1960s and 70s, it might've been GML. In the 80s, maybe SGML. In the 90s, XML, and later maybe JSON, or... shudder YAML? Or, no, it obviously should've been some binary format.

OK, so let's say everyone agrees on a single format for several decades. Should all programs written for all those shells that support it also support the data format? Even if that's handled by shells and not the programs, there will surely be bugs and incompatibilities in each shell implementation, leading to fragmentation.

Furthermore, will the data format support versioning? Will it be backwards compatible? Will all programs or shells need to support this? Will users have to mix and match, and experience all sorts of compatibility issues?

So, clearly, unstructured text is the only "format" that is both flexible and future proof enough, at the expense of convenience for the user to glue programs together. I'd rather have that than have to depend on the structured format du jour that will have to be continuously maintained and supported by all programs in the ecosystem.

Besides, there are projects like Nushell and Murex that wrap the input and output of existing programs or write their own to support piping structured data. I'm not a big fan of them, but it points out that unstructured data is not some UNIX flaw, but a deliberate design decision which is IMO partly what enabled it to proliferate in the first place.

Maintaining a shell that supports piping structured data can only be done by a single entity that oversees the entire ecosystem, like Microsoft does with PowerShell, or the above mentioned projects. That is the antithesis of the UNIX philosophy where disparate tools can be written by anyone, yet somehow still be made to interoperate by the user. It's also a gargantuan project that realistically not even mega corporations can successfully maintain without limiting the user or introducing bugs. Plus it will always be a bottleneck for adding new tools to the ecosystem. For these reasons I don't foresee any of the structured data shells to be nearly as popular as UNIX shells have been and will continue to be 30 years from now.

I feel you’ve gone on a tangent there. Particularly your unrelated comment about using of using ML because people are too lazy to write parsers.

That all said, I don’t really disagree with any of your individual points. But teemoji is clearly not meant to be considered a serious tool so I wouldn’t be too critical of UNIX that this tool exists.

I'm not critical of UNIX for this tool specifically, and I think it would be useful even if UNIX did things differently - a "pick best fitting emoji for arbitrary line of text" is a well-defined task, and I hit scenarios where I'd wish I had such tool surprisingly often.

Reply on news.ycombinator.com