6 ms·

You Want Technology with Warts

100 points by tartoran 1y ago

adityaathalye 1y ago
So much this. Warts = (software longevity) life lessons. (Though it must be noted that warts != bad design.) Some years ago, I gave a talk on functional-style shell programming which began with this: Prelude: Why even bother? Personally… Text is everywhere, better learn to process it The masters already solved it better Stable tools, well-known warts Personal/team productivity, tool-building autonomy To learn about good and successful design bad and successful design computer history For the fun of it ref: Dr. Strangepipes Or: How I Learned To Stop Worrying && Function In Shell (Functional Conf 2019) org-mode slideware: https://gist.github.com/adityaathalye/93aba2352a5e24d31ecbcae2e8197457 https://gist.github.com/adityaathalye/93aba2352a5e24d31ecbca... live demo: https://www.youtube.com/watch?v=kQNATXxWXsA&list=PLG4-zNACPCsNVwz3ohXKeoeQjRLoFsc7F&index=4 https://www.youtube.com/watch?v=kQNATXxWXsA&list=PLG4-zNACPC...
socalgal2 1y ago
long lasting warts might be evidence that the software is backward compatible. It might also be evidence the software is full of footguns and ways to screw yourself. I'm sure it's an unpopular opinion but sh/bash scripts suck. There are magic incantations all over and if you get one wrong then you've got code injection. We can't go back and fix it but we could either replace it, or update in some way so it it's easy to be safe and only one way to do things that "does the right and safe thing" always. I don't think keeping unsafe by default is a good model and I think all of the daily headlines of people/companies/hospitals/airports/goverments being hacked in large part because we keep the warts.
- grebc 1y ago
  I don’t know how you take the article OP wrote/posted and conflate it with security breaches. Long lived shipping code is typically not aesthetically pleasing.
  - aloha2436 1y ago
    Some of these warts are problems with security, or data integrity, or resource usage, etc. It's a difference of opinion more than it is a conflation with something else. My _personal_ preference is that software does the "correct" thing by default even if it breaks my build or my tests or even running software; I would rather it break visibly than work nefariously.
- drdo 1y ago
  I don't think it's unpopular at all that bash scripts suck a lot.
grebc 1y ago
I think when you’re young & doe eyed what is shiny & new is exciting and your wants are easily confused with needs. You don’t need the shiniest & newest framework to tell a computer to generate some HTML & CSS with a database and some logic. And don’t have the lived experience of building & shipping to realise that only 1 in 1,000,000 projects probably ever get more than 100 sets of eyeballs so end up using much more complicated tools than necessary. But all the news & socials will sing praise to the latest shiny tools x.x.9 release so those needs easily get confused.
- ehnto 1y ago
  I more or less agree, if you are a small company with a small real world userbase, you don't need hyperscaling tech, and thus hyperscaling problems. I think some companies oversubscribe to reliability technology too. You should assess if you really need 99.9999% uptime before building out a complex cloud infrastructure setup. It's very likely you can get away with one or two VMs. As I understand, HN runs on a single server with a backup server for failover.
- pixl97 1y ago
  You may not need the shiniest new framework, but you do have to ensure your old framework has not been abandoned or is no longer getting security updates.
m4rc3lv 1y ago
I think I would use PHP for the backend instead of Node or Perl.
- stefantalpalaru 1y ago
  [dead]
cjfd 1y ago
I don't think anyone wants warts. It is a fact that every technology has them, though. And also that every attempt to get rid of warts seems to introduce new, perhaps yet unknown warts. There is a kind of law of conservation of misery here. I think I now have said in a somewhat more clear way what the article is trying to say and without a title that is actually false.
- eucyclos 1y ago
  This makes me think of Alexander's pattern language- according to that framework one of the key components of beauty is texture. I wonder if our dislike of untextured experiences stem from an unease at not knowing where the thing is hiding its warts.
  - cjfd 1y ago
    That could be true. What it makes me think about is the danger of things that magically just work. Things that magically just work also may stop working for some reason and then you do not have an idea how to fix them.
- imiric 1y ago
  I think you're conflating warts with bugs. The point of the article is that warts are subjective. What one person considers unwanted behavior, another might see it as a feature. They are a testament to the software's flexibility, and to maintainers caring about backwards compatibility, which, in turn, is a sign that users can rely on it for a long time. Nobody wants bugs. But I agree with the article's premise.
keithnz 1y ago
Thing is, with AI, this is much less of an issue, as long as AI can maintain the code it would be able to transition it through tech change. This seems a better bet than trying to choose things that will remain static.
- ehnto 1y ago
  How is that any different than having a developer work on it, which also doesn't happen? It's not a money thing, huge companies with dev teams fail at this too. I don't disagree that things probably won't stay static though, but you can do a lot to minimise the surface area of change you are exposed to.
behnamoh 1y ago
> There’s a chart in the presentation that shows how environmental churn and api deprecation leads desktop applications to have an expected lifetime of maybe a decade, and phone apps closer to a couple of years. On the other hand, simple web pages have worked unmodified for over 40 years! That’s a good reason to default to the web as a technology. isn't it the opposite? Just take a look at any web app and tell me if it wasn't rewritten at some point due to the rapid shift in web frameworks and hype cycles. heck, even HN was rewritten afaik. meanwhile i have Matlab that has remained literally the same for over a decade.
- eru 1y ago
  Matlab, at least the language, has changed quite a bit when I was using it. Eg they added being able to pass functions as first class values. But that was more than a decade ago, I guess?
  - kqr 1y ago
    Languages often add features in ways that does not break existing code. I think here we are discussing changes that are backwards-incompatible.
- ehnto 1y ago
  It said simple web pages, not web apps. Web apps that use APIs are basically in the same boat as a phone app. Constantly moving API target and platform requirements ever changing.
  - cylemons 1y ago
    Just like simple webpages, simple desktop and mobile apps last a long time too. It is only when working on complex applications that use cutting edge apis that churn is a problem
    - kqr 1y ago
      > mobile apps last a long time too Really? How come half of the apps I've used in the past are listed in the app store as "not compatible with this device, but they can be installed on $device_gone_to_rest_in_drawer_14_years_ago"? I'm genuinely curious! I thought it was aggressive deprecation of mobile OS APIs that made old apps no longer work on new phones.
yxhuvud 1y ago
Keeping warts around is also how you end up with systems and frameworks noone wants to touch without a pole.
lmm 1y ago
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.
- gwd 1y ago
  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.
  - massysett 1y ago
    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.
    - lieks 1y ago
      Common Lisp does have plenty of warts.
    - bluGill 1y ago
      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
    - neutronicus 1y ago
      Common Lisp is basically a constellation of warts that people put up with in exchange for its macro system and REPL-driven development.
    - jodrellblank 1y ago
imiric 1y ago
I agree with the article's premise, but would add one thing: warts might be a sign that the software is too flexible, and/or is doing too many things. For programming languages and databases this, of course, doesn't apply, since they're designed to be flexible. But simple tools that follow the Unix philosophy rarely have warts. I've never experienced warts with Unix tools such as `cat`, `cut`, `uniq`, etc., which I believe is primarily because they do a single thing, and their interface is naturally limited to that task. Maybe there were some growing pains when these tools were new, but now their interfaces are practically cemented, and they're the most reliable tools in my toolbelt. More advanced tools such as `grep`, `sed`, and particularly `awk`, are a bit different, since their use cases are much broader, they support regex, and `awk` is a programming language. This is why my first instinct when automating a task is to write a shell script. Yes, shells like Bash are chock-full of warts, but if you familiarize yourself with them and are able to navigate around them, a shell script can be the most reliable long-term solution. Even cross-platform if you stick to POSIX. I wouldn't rely on it for anything sophisticated, of course, but I have shell scripts written years ago that work just as well today, and I reckon will work for many years to come. I can't say that about most programming languages.
- jodrellblank 1y ago
  > "I've never experienced warts with Unix tools such as `cat`, `cut`, `uniq`, etc." Literally the first time of using uniq and finding duplicates in the output is a wart. Having to realise it's not doing "unique values" it's doing "drop consecutive duplicates" and the reason it's doing it is because 1970s computers didn't have enough memory to dedupe a whole dataset and could only do it streaming. cat being "catenate" intended to catenate multiple files together into one pipeline stream, but always being used to read single files instead of a pager. "cat words.txt | less" is a wart seen all over the place. cut being needed to separate fields because we couldn't all come together and agree to use ASCII Field Separator character to separate fields is arguably warty. Or the find command where you can find files by different sizes and you can specify +100G for finding files with sizes 100 Gibibytes or larger, or M for Mebibytes, K for Kibibytes, and b for bytes. No just kidding b is 512-byte blocks, it's nothing at all for bytes just +100. No just kidding again that's also 512-byte blocks. It's c for bytes. Because the first version of Unix happened to use 512-byte blocks on its filesystem[1]. And the c stands for characters so you have to know that it's all pre-Unicode and using 8-bit characters. [1] https://unix.stackexchange.com/questions/259208/purpose-of-find-commands-default-size-unit-512-bytes https://unix.stackexchange.com/questions/259208/purpose-of-f...
capestart 1y ago
[dead]
snowwrestler 1y ago
Is there some version of Betteridge’s Law of Headline Questions but for the imperative voice? But seriously I don’t think warts are the key to long-serving web applications without maintenance. The key is to pick technologies with no security vulnerabilities. That way you won’t ever have to install patches (which risk breaking functionality, which requires maintenance to fix), and you won’t ever get hacked (which also requires maintenance to fix). Do such technologies exist? I don’t think so. Which is why I think the concept of constant maintenance is inherent to web applications and everyone should just accept that. I think we’re far enough along in this journey to recognize that the dream of “immortal frictionless machinery” is not what software actually is. We create the friction (via usage, attacks, and patches) and we should plan to address it. Bridges do receive regular maintenance BTW, even very well-engineered ones…
- 1313ed01 1y ago
  No, ideally you pick technologies that still have maintenance and security updates, but no other changes. Assuming it already does what you need it for already, and that is usually the case. Without other changes there also will be no new security issues to fix.
  - snowwrestler 1y ago
    It’s just impossible to exclude the possibility of breaking changes because it’s impossible to exclude unforeseen bugs. Operationally it is much better to accept the need for software maintenance and plan for it.
  - pixl97 1y ago
    >, ideally you pick technologies that still have maintenance and security updates These are exceedingly rare, and even more rarely do those stable technologies cover your actual needs.
mapontosevenths 1y ago
The entire premise, that our goal is to create the software equivalent of 100+ year old bridges, is a bit flawed. We aren't building a historical legacy here. Our crummy web-apps are not the great pyramids, and should not be built like them. Nobody likes to admit it, but 99% of what we build today is disposable, and it should be built cheaply and quickly. I see this attitude, especially with juniors, and often with project managers, that we need perfection and are building things that are meant to last for decades. Almost nothing does though. Many/most business applications are obsolete within 5 years and it costs more to cling to the fiction that what we're doing is important and lasting.

100 points by tartoran 1y ago

So much this. Warts = (software longevity) life lessons. (Though it must be noted that warts != bad design.) Some years ago, I gave a talk on functional-style shell programming which began with this: Prelude: Why even bother? Personally… Text is everywhere, better learn to process it The masters already solved it better Stable tools, well-known warts Personal/team productivity, tool-building autonomy To learn about good and successful design bad and successful design computer history For the fun of it ref: Dr. Strangepipes Or: How I Learned To Stop Worrying && Function In Shell (Functional Conf 2019) org-mode slideware: https://gist.github.com/adityaathalye/93aba2352a5e24d31ecbcae2e8197457 https://gist.github.com/adityaathalye/93aba2352a5e24d31ecbca... live demo: https://www.youtube.com/watch?v=kQNATXxWXsA&list=PLG4-zNACPCsNVwz3ohXKeoeQjRLoFsc7F&index=4 https://www.youtube.com/watch?v=kQNATXxWXsA&list=PLG4-zNACPC...

socalgal2 1y ago

long lasting warts might be evidence that the software is backward compatible. It might also be evidence the software is full of footguns and ways to screw yourself. I'm sure it's an unpopular opinion but sh/bash scripts suck. There are magic incantations all over and if you get one wrong then you've got code injection. We can't go back and fix it but we could either replace it, or update in some way so it it's easy to be safe and only one way to do things that "does the right and safe thing" always. I don't think keeping unsafe by default is a good model and I think all of the daily headlines of people/companies/hospitals/airports/goverments being hacked in large part because we keep the warts.

grebc 1y ago
I don’t know how you take the article OP wrote/posted and conflate it with security breaches. Long lived shipping code is typically not aesthetically pleasing.
- aloha2436 1y ago
  Some of these warts are problems with security, or data integrity, or resource usage, etc. It's a difference of opinion more than it is a conflation with something else. My _personal_ preference is that software does the "correct" thing by default even if it breaks my build or my tests or even running software; I would rather it break visibly than work nefariously.
drdo 1y ago
I don't think it's unpopular at all that bash scripts suck a lot.

grebc 1y ago

I think when you’re young & doe eyed what is shiny & new is exciting and your wants are easily confused with needs. You don’t need the shiniest & newest framework to tell a computer to generate some HTML & CSS with a database and some logic. And don’t have the lived experience of building & shipping to realise that only 1 in 1,000,000 projects probably ever get more than 100 sets of eyeballs so end up using much more complicated tools than necessary. But all the news & socials will sing praise to the latest shiny tools x.x.9 release so those needs easily get confused.

ehnto 1y ago
I more or less agree, if you are a small company with a small real world userbase, you don't need hyperscaling tech, and thus hyperscaling problems. I think some companies oversubscribe to reliability technology too. You should assess if you really need 99.9999% uptime before building out a complex cloud infrastructure setup. It's very likely you can get away with one or two VMs. As I understand, HN runs on a single server with a backup server for failover.
pixl97 1y ago
You may not need the shiniest new framework, but you do have to ensure your old framework has not been abandoned or is no longer getting security updates.

m4rc3lv 1y ago

I think I would use PHP for the backend instead of Node or Perl.

stefantalpalaru 1y ago
[dead]

cjfd 1y ago

I don't think anyone wants warts. It is a fact that every technology has them, though. And also that every attempt to get rid of warts seems to introduce new, perhaps yet unknown warts. There is a kind of law of conservation of misery here. I think I now have said in a somewhat more clear way what the article is trying to say and without a title that is actually false.

eucyclos 1y ago
This makes me think of Alexander's pattern language- according to that framework one of the key components of beauty is texture. I wonder if our dislike of untextured experiences stem from an unease at not knowing where the thing is hiding its warts.
- cjfd 1y ago
  That could be true. What it makes me think about is the danger of things that magically just work. Things that magically just work also may stop working for some reason and then you do not have an idea how to fix them.
imiric 1y ago
I think you're conflating warts with bugs. The point of the article is that warts are subjective. What one person considers unwanted behavior, another might see it as a feature. They are a testament to the software's flexibility, and to maintainers caring about backwards compatibility, which, in turn, is a sign that users can rely on it for a long time. Nobody wants bugs. But I agree with the article's premise.

keithnz 1y ago

Thing is, with AI, this is much less of an issue, as long as AI can maintain the code it would be able to transition it through tech change. This seems a better bet than trying to choose things that will remain static.

ehnto 1y ago
How is that any different than having a developer work on it, which also doesn't happen? It's not a money thing, huge companies with dev teams fail at this too. I don't disagree that things probably won't stay static though, but you can do a lot to minimise the surface area of change you are exposed to.

behnamoh 1y ago

> There’s a chart in the presentation that shows how environmental churn and api deprecation leads desktop applications to have an expected lifetime of maybe a decade, and phone apps closer to a couple of years. On the other hand, simple web pages have worked unmodified for over 40 years! That’s a good reason to default to the web as a technology. isn't it the opposite? Just take a look at any web app and tell me if it wasn't rewritten at some point due to the rapid shift in web frameworks and hype cycles. heck, even HN was rewritten afaik. meanwhile i have Matlab that has remained literally the same for over a decade.

eru 1y ago
Matlab, at least the language, has changed quite a bit when I was using it. Eg they added being able to pass functions as first class values. But that was more than a decade ago, I guess?
- kqr 1y ago
  Languages often add features in ways that does not break existing code. I think here we are discussing changes that are backwards-incompatible.
ehnto 1y ago
It said simple web pages, not web apps. Web apps that use APIs are basically in the same boat as a phone app. Constantly moving API target and platform requirements ever changing.
- cylemons 1y ago
  Just like simple webpages, simple desktop and mobile apps last a long time too. It is only when working on complex applications that use cutting edge apis that churn is a problem
  - kqr 1y ago
    > mobile apps last a long time too Really? How come half of the apps I've used in the past are listed in the app store as "not compatible with this device, but they can be installed on $device_gone_to_rest_in_drawer_14_years_ago"? I'm genuinely curious! I thought it was aggressive deprecation of mobile OS APIs that made old apps no longer work on new phones.

yxhuvud 1y ago

Keeping warts around is also how you end up with systems and frameworks noone wants to touch without a pole.

lmm 1y ago

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.

gwd 1y ago
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.
- massysett 1y ago
  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.
  - lieks 1y ago
    Common Lisp does have plenty of warts.
  - bluGill 1y ago
    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
  - neutronicus 1y ago
    Common Lisp is basically a constellation of warts that people put up with in exchange for its macro system and REPL-driven development.
  - jodrellblank 1y ago

imiric 1y ago

I agree with the article's premise, but would add one thing: warts might be a sign that the software is too flexible, and/or is doing too many things. For programming languages and databases this, of course, doesn't apply, since they're designed to be flexible. But simple tools that follow the Unix philosophy rarely have warts. I've never experienced warts with Unix tools such as `cat`, `cut`, `uniq`, etc., which I believe is primarily because they do a single thing, and their interface is naturally limited to that task. Maybe there were some growing pains when these tools were new, but now their interfaces are practically cemented, and they're the most reliable tools in my toolbelt. More advanced tools such as `grep`, `sed`, and particularly `awk`, are a bit different, since their use cases are much broader, they support regex, and `awk` is a programming language. This is why my first instinct when automating a task is to write a shell script. Yes, shells like Bash are chock-full of warts, but if you familiarize yourself with them and are able to navigate around them, a shell script can be the most reliable long-term solution. Even cross-platform if you stick to POSIX. I wouldn't rely on it for anything sophisticated, of course, but I have shell scripts written years ago that work just as well today, and I reckon will work for many years to come. I can't say that about most programming languages.

jodrellblank 1y ago
> "I've never experienced warts with Unix tools such as `cat`, `cut`, `uniq`, etc." Literally the first time of using uniq and finding duplicates in the output is a wart. Having to realise it's not doing "unique values" it's doing "drop consecutive duplicates" and the reason it's doing it is because 1970s computers didn't have enough memory to dedupe a whole dataset and could only do it streaming. cat being "catenate" intended to catenate multiple files together into one pipeline stream, but always being used to read single files instead of a pager. "cat words.txt | less" is a wart seen all over the place. cut being needed to separate fields because we couldn't all come together and agree to use ASCII Field Separator character to separate fields is arguably warty. Or the find command where you can find files by different sizes and you can specify +100G for finding files with sizes 100 Gibibytes or larger, or M for Mebibytes, K for Kibibytes, and b for bytes. No just kidding b is 512-byte blocks, it's nothing at all for bytes just +100. No just kidding again that's also 512-byte blocks. It's c for bytes. Because the first version of Unix happened to use 512-byte blocks on its filesystem[1]. And the c stands for characters so you have to know that it's all pre-Unicode and using 8-bit characters. [1] https://unix.stackexchange.com/questions/259208/purpose-of-find-commands-default-size-unit-512-bytes https://unix.stackexchange.com/questions/259208/purpose-of-f...

capestart 1y ago

[dead]

snowwrestler 1y ago

Is there some version of Betteridge’s Law of Headline Questions but for the imperative voice? But seriously I don’t think warts are the key to long-serving web applications without maintenance. The key is to pick technologies with no security vulnerabilities. That way you won’t ever have to install patches (which risk breaking functionality, which requires maintenance to fix), and you won’t ever get hacked (which also requires maintenance to fix). Do such technologies exist? I don’t think so. Which is why I think the concept of constant maintenance is inherent to web applications and everyone should just accept that. I think we’re far enough along in this journey to recognize that the dream of “immortal frictionless machinery” is not what software actually is. We create the friction (via usage, attacks, and patches) and we should plan to address it. Bridges do receive regular maintenance BTW, even very well-engineered ones…

1313ed01 1y ago
No, ideally you pick technologies that still have maintenance and security updates, but no other changes. Assuming it already does what you need it for already, and that is usually the case. Without other changes there also will be no new security issues to fix.
- snowwrestler 1y ago
  It’s just impossible to exclude the possibility of breaking changes because it’s impossible to exclude unforeseen bugs. Operationally it is much better to accept the need for software maintenance and plan for it.
- pixl97 1y ago
  >, ideally you pick technologies that still have maintenance and security updates These are exceedingly rare, and even more rarely do those stable technologies cover your actual needs.

mapontosevenths 1y ago

The entire premise, that our goal is to create the software equivalent of 100+ year old bridges, is a bit flawed. We aren't building a historical legacy here. Our crummy web-apps are not the great pyramids, and should not be built like them. Nobody likes to admit it, but 99% of what we build today is disposable, and it should be built cheaply and quickly. I see this attitude, especially with juniors, and often with project managers, that we need perfection and are building things that are meant to last for decades. Almost nothing does though. Many/most business applications are obsolete within 5 years and it costs more to cling to the fiction that what we're doing is important and lasting.