3 ms·

The flip side of this is that because digital plumbing is "boring", the industry is constantly seeking ways to avoid it. Writing assembly language was (usually

by ken 7y ago

The flip side of this is that because digital plumbing is "boring", the industry is constantly seeking ways to avoid it. Writing assembly language was (usually) really boring, so we developed good compilers to do that for us. I look forward to the day where I can send data from one place to another and not have to bother with file formats, text encodings, port numbers, network protocols, and so on. IP (and especially TCP/IP) is so prevalent today that we use "IP connection" and "network connection" interchangeably. Someday I hope we have that consistency at some other layers of the stack. I shouldn't have to say "send me that file -- what app did you use to make it?"

3pt14159 7y ago
I've been thinking through this for a while now and I've come to the conclusion that the details keep getting more complicated faster than other things can automate them. For example, I remember a time when software served ascii and when the Canadian government asked to buy a version of some software we were writing for the Americans the reason the head of the company said no was because we'd have to support French and that meant non-ascii characters. Now, UTF-8 is a given and there is a mess of potential issues. No longer are byte-by-byte comparisons reliable, especially in some languages like Vietnamese. Your example of IP connection and network connection is true, but overall connections are more complicated. Some clients can't use HTTP2, some clients are behind firewalls, some clients need CORS support, etc. And plus there is this accelerating wave of advancements everyone is trying to keep up with, but that come with real investment. Upgrading OSes, programming languages, frameworks, libraries. Figuring out how to keep data secure. I really don't see things getting less complicated as time goes on. At least not until we have some real form of AI, but even there I have my doubts because there will always be tradeoffs.
- bobthepanda 7y ago
  That's why we have libraries and frameworks to do complicated, human-facing bits. If you're rolling your own dateTime, it's a bad idea, but fortunately other people have solutions for this. If you want to get into the nitty gritty you can but you do so at your own peril, similar to how the vast majority of people are not reinventing TCP/IP. It'll take a bit of evolution to get there depending on how new the problem is, but it also took a bit of evolution to get where we are today, and nothing is ever perfect.
  - 3pt14159 7y ago
    My argument is that, as a function of time, there are more things to consider, not less. Abstraction works to a point, but it doesn't keep up with the growing complexity.
  - nradov 7y ago
    Except by the time those libraries and frameworks become stable and well documented enough for serious use, we decide to reinvent the wheel and move on to something new.
fragmede 7y ago
In fact, that's already been solved for the most boring of digital plumbing. The data is JSON (which requires UTF-8), and the port number either 80 or 443 - the library automatically handles that depending on if the URL starts with http or https. `requests.get(URL).json()` will grab that data for you (Python). That only covers a very specific but very prevalent use case, just like TCP/IP covers the most prevalent use case for networking. What are you doing where that can't covered by that use case? Actually, I can think of tons. What are you doing that can't be covered by that use case, but is still boring?
- perl4ever 7y ago
  I think you are coming from a common perspective for people on HN and elsewhere in IT, where you can just install anything and provision any equipment to install it on and direct others to do the same. A lot of people aren't in a position to do this. I think actual plumbers also have to deal with similar constraints. It's nice to not be constrained, but it's also more impressive to do a good job under severe constraints, IMO.
- jniedrauer 7y ago
  Something I find myself doing repeatedly is implementing arcane protocols that were created long before JSON. Bit-packed mainframe protocols. After the second or third time of working with another binary format, there's no new knowledge to gain, and it's not interesting work. But it requires meticulous attention to detail and can't be automated. Most industries don't require you to solve this specific problem but it's all variations of this. Shuffle data from one format to another format. Even if it's JSON, you're still moving it from one business domain to another, or one tech stack to another. Backend to frontend. Etc.

by ken 7y ago

3pt14159 7y ago

I've been thinking through this for a while now and I've come to the conclusion that the details keep getting more complicated faster than other things can automate them. For example, I remember a time when software served ascii and when the Canadian government asked to buy a version of some software we were writing for the Americans the reason the head of the company said no was because we'd have to support French and that meant non-ascii characters. Now, UTF-8 is a given and there is a mess of potential issues. No longer are byte-by-byte comparisons reliable, especially in some languages like Vietnamese. Your example of IP connection and network connection is true, but overall connections are more complicated. Some clients can't use HTTP2, some clients are behind firewalls, some clients need CORS support, etc. And plus there is this accelerating wave of advancements everyone is trying to keep up with, but that come with real investment. Upgrading OSes, programming languages, frameworks, libraries. Figuring out how to keep data secure. I really don't see things getting less complicated as time goes on. At least not until we have some real form of AI, but even there I have my doubts because there will always be tradeoffs.

bobthepanda 7y ago
That's why we have libraries and frameworks to do complicated, human-facing bits. If you're rolling your own dateTime, it's a bad idea, but fortunately other people have solutions for this. If you want to get into the nitty gritty you can but you do so at your own peril, similar to how the vast majority of people are not reinventing TCP/IP. It'll take a bit of evolution to get there depending on how new the problem is, but it also took a bit of evolution to get where we are today, and nothing is ever perfect.
- 3pt14159 7y ago
  My argument is that, as a function of time, there are more things to consider, not less. Abstraction works to a point, but it doesn't keep up with the growing complexity.
- nradov 7y ago
  Except by the time those libraries and frameworks become stable and well documented enough for serious use, we decide to reinvent the wheel and move on to something new.

fragmede 7y ago

In fact, that's already been solved for the most boring of digital plumbing. The data is JSON (which requires UTF-8), and the port number either 80 or 443 - the library automatically handles that depending on if the URL starts with http or https. `requests.get(URL).json()` will grab that data for you (Python). That only covers a very specific but very prevalent use case, just like TCP/IP covers the most prevalent use case for networking. What are you doing where that can't covered by that use case? Actually, I can think of tons. What are you doing that can't be covered by that use case, but is still boring?

perl4ever 7y ago
I think you are coming from a common perspective for people on HN and elsewhere in IT, where you can just install anything and provision any equipment to install it on and direct others to do the same. A lot of people aren't in a position to do this. I think actual plumbers also have to deal with similar constraints. It's nice to not be constrained, but it's also more impressive to do a good job under severe constraints, IMO.
jniedrauer 7y ago
Something I find myself doing repeatedly is implementing arcane protocols that were created long before JSON. Bit-packed mainframe protocols. After the second or third time of working with another binary format, there's no new knowledge to gain, and it's not interesting work. But it requires meticulous attention to detail and can't be automated. Most industries don't require you to solve this specific problem but it's all variations of this. Shuffle data from one format to another format. Even if it's JSON, you're still moving it from one business domain to another, or one tech stack to another. Backend to frontend. Etc.