I think you're misunderstanding what a "wart" is. None of those examples are warts. They're the way those programs work, which you can easily understand by reading their documentation. Your point about `cat` is an example of misuse, and `cut` is needed because of the deliberate design decision to make text streams the universal interface, which has far greater benefits than forcing any specific separator.
A wart is not surprising or unintuitive behavior. It is a design quirk—a feature that sticks out from the program's overall design, usually meant to handle edge cases, or to preserve backwards compatibility. For example, some GNU programs like `grep` and `find` support a `POSIXLY_CORRECT` env var, which changes their interface and behavior.
My point is that the complexity of the software and its interface is directly proportional to the likelihood of it developing "warts". `find` is a much more complex program than `cut` or `uniq`, therefore it has developed warts.
Next time, please address the point of the comment you're replying to, instead of forcing some counterargument that happens to be wrong.
The context of the blog post is that "warts" are the way something was originally designed or built, which is now outdated and you would change it if you could, but you don't want to break backwards compatibility so you don't.
> "For example, some GNU programs like `grep` and `find` support a `POSIXLY_CORRECT` env var, which changes their interface and behavior."
By your own logic that's not a wart, that's the way the programs work and they are documented to work like that. Twisting yourself into knots to pretend Linux/Unix utilities are perfectly designed isn't good logic. There's no excuse "it was designed that way" or "it's documented to work like this" which makes something not warty. Something might have been a good design originally and become a bad design as the world changed around it.
For example unserialised byte streams where you have to fight whether \n or 0 (null byte) are data or record separators, is a wart. How do we know? Because when people design newer tools they don't keep that, they design it away. Serialised JSON and jq, .NET objects in PowerShell, structured data in nushell[1] and oilshell YSH[2].
Do you see any warts in it? No? Well, my point is that the likelihood of a program developing warts is partly related to its complexity. That's it.
I mentioned Unix tools as an example of this, since they're by far the most reliable tools I use, particularly the simpler ones. I never said that they were "perfectly designed". Don't put words in my mouth.
> By your own logic that's not a wart, that's the way the programs work and they are documented to work like that.
A wart can be documented. I mentioned the case of `POSIXLY_CORRECT` since GNU tools predate the POSIX standard by a few years, so presumably that env var and the change in behavior was introduced when POSIX was first established. I'm not familiar with the detailed history, but that example is beside my point.
> Something might have been a good design originally and become a bad design as the world changed around it.
Again, you're misunderstanding what a wart is. It has nothing to do with bad design, and it doesn't appear on its own over time. It is a deliberate quirk that deviates from the program's original design—whatever that may be—in order to support some functionality without breaking backwards compatibility.
Just because you don't like the design doesn't mean that the software has warts.
Read that again.
Those fancy shells you mention have at least one major drawback: interop between tools only works if structured I/O is supported by each tool, whether that is because they were written from scratch, or because it was tacked on via shims. In practice, this can only be done if the entire ecosystem is maintained by a single organization. And if that strict interface needs to be changed, good luck updating every single tool while maintaining backwards compatibility. Talk about warts...
In contrast, using unstructured text streams as the universal interface means that programs written 40 years ago can interoperate with programs written today, without either author having to add explicit support for it, and without requiring centralized maintenance. Most well-designed programs do support flags like `-0` to indicate a null separator, which has become somewhat of a standard, but otherwise the user is in control of how that interop happens. This freedom is a good thing, and is precisely what makes programs infinitely composable.
In any case, this discussion has veered off from my original point and the article, because you don't like how Unix programs are designed, and misunderstand what warts are. So for that reason, I'm out.
> "Look, here's a program: print "Hello" Do you see any warts in it? No?"
Yes. It's Python 2's print statement, in PythonWiki's PythonWarts[2] page. And it counters a lot of your claims:
- It was right there from the beginning, it wasn't designed in later.
- It may have been good design at the time when Python was a teaching language, and did appear on its own over time as the world and Python's use cases changed around it.
- It wasn't added as a workaround to keep backward compatibility.
- It is a single line of code, as small as you could reasonably get, and still warty.
> "A wart can be documented. [A wart] is a deliberate quirk that deviates from the program's original design"
It was your point that "x is not a wart because it's documented to work that way". How does the article's "Haskell .. built in String type is bad data structure for storing text" 'deliberately deviate' from Haskell's original design? How does sqlite "tables being flexibly typed by default" deliberately deviate from SQLite's original design? On that PythonWarts page "Explicit self in methods" is Python's original design. It's you who has come up with some personal defition of wart that nobody else is using.
> "I mentioned Unix tools as an example of this, since they're by far the most reliable tools I use"
That's orthogonal to their wartiness. And incidentally that should make you suspicious. By the blog post's reasoning, tools are far more likely to be (warty + reliable) than (wart-free + reliable) since the latter relies on them being designed perfectly and not changed and in an environment which isn't changing or to have a design that lets them be changed very flexibly. All those are unlikely and difficult, whereas the former (warty+reliable) can apply to anything, and probably does.
> "Just because you don't like the design doesn't mean that the software has warts."
And just because you like the design doesn't it's wartless.
> "In contrast, using unstructured text streams as the universal interface means that programs written 40 years ago can interoperate with programs written today, without either author having to add explicit support for it"
Unix/Linux shell streams are not unstructured text streams. That's why tools like `cut` exist, because the text has structure. And null bytes can be used as record separators because the stream is not text. And it's why "interop between tools only works if structured I/O is supported by each tool" applies - each tool can only read the byte streams that are within the ad-hoc informally specified half of a common serialization standard. It's not that I don't like this, it's that I don't like people spreading Linux propaganda about how this is wartless and brilliant when it's barely good enough even for tasks of the 1970s and should be in a museum.
A wart is not surprising or unintuitive behavior. It is a design quirk—a feature that sticks out from the program's overall design, usually meant to handle edge cases, or to preserve backwards compatibility. For example, some GNU programs like `grep` and `find` support a `POSIXLY_CORRECT` env var, which changes their interface and behavior.
My point is that the complexity of the software and its interface is directly proportional to the likelihood of it developing "warts". `find` is a much more complex program than `cut` or `uniq`, therefore it has developed warts.
Next time, please address the point of the comment you're replying to, instead of forcing some counterargument that happens to be wrong.