> "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 cou

> "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. [1] https://wiki.python.org/moin/PythonWarts* https://wiki.python.org/moin/PythonWarts*