Hacker News Reader

Comment by lmm | Hacker News Reader

Warts are the product of caring about backwards compatibility with initial design mistakes. So I'm not sure they're a reliable heuristic for better choice of technology. E.g. YAML is definitely much wartier than JSON, but I think the latter is a much better choice for long-term use than the former.

View on HN

I don't think the claim is "More warts is better". I think the claim is, "A technology with at least a few warts is an indication of longevity".

Basically, if there are no obvious warts, then either:

1. The designers magically hit upon exactly the right needed solution the very first time, every time, or

2. The designers regularly throw away warty interfaces in favor of cleaner ones.

#1 is possible, but #2 is far more likely.

Another possibility is that the designers carefully examined predecessors to learn from their mistakes, and went through a long refinement period before stabilizing the design. This is Common Lisp.

Common Lisp does have plenty of warts.

You can not have the old warts, but your correction may itself be a wart. Sometimes you learn the hard way why the last version was that wey

Common Lisp is basically a constellation of warts that people put up with in exchange for its macro system and REPL-driven development.

Nothing warty about functions named "car, cdr, caar, cadr, cdar, cddr, caaar, caadr, cadar, caddr, cdaar, cdadr, cddar, cdddr, caaaar, caaadr, caadar, caaddr, cadaar, cadadr, caddar, cadddr, cdaaar, cdaadr, cdadar, cdaddr, cddaar, cddadr, cdddar, cddddr"[1]

a domain specific language for walking into nested lists based on an implementation detail of how linked list pointers and values were packed into a single 36-bit memory location on an IBM 704 computer from the 1950s.

[1] https://franz.com/support/documentation/ansicl/dictentr/carc...

[2] https://en.wikipedia.org/wiki/CAR_and_CDR

Dude, Common Lisp has so many warts that it makes fairy tale witches envious.

It’s probably possible to minimize warts without negatively impacting other aspects of the software. It just isn’t done very often, probably because that requires either a full feature freeze (allowing all resources to go towards disposing of the figurative bathwater while keeping the baby). At minimum a pointedly slow, judicious approach to feature additions that helps designers and devs to get more right the first time and only ship fully baked products to users is required.

No, everything today is about endless frenzied stacking of features as high as possible, totally ignoring how askew the tower is sitting as a result. Just prop it up again for the 50th time and above all, ship faster!

JSON also has a few warts that aren't going away exactly due to backwards compatibility. So I think that's actually a pretty good illustration of the point.

> JSON also has a few warts that aren't going away exactly due to backwards compatibility. So I think that's actually a pretty good illustration of the point.

How? All nontrivial software has warts, you're never choosing between warts and no warts, you're choosing between more warts and less warts. And JSON has few warts compared to the alternatives, especially YAML.

Reply on news.ycombinator.com