What I do see a lot though, and maybe that's what this is getting at, is code that is broken into more parts and components and glue than is remotely necessary, making it much harder to understand that it all does, which might even be some very very simple thing. It's like each bolt is turned into it's own city. THAT kind of code is indeed, awful and disrespectful to humans all in sides (the programmer for obvious reasons, the user because what the software does & whether it even does that in a sensible way or whether it's even the right solution, is much further removed from the programmer's attention or even ability to analyze)
Although I 1000% support code that is as simple as possible, there's major problems with this comparison.
If the goal is just to order a damn meal, then yes all the "polite interaction" is a waste. But a commandline is not the same context as a restaurant. If you were coding a software driven restaurant of robot-workers, then you better damn well code them to create a good experience, or you've made a crappy service that will fail. But what if it's a restaurant for technologists who don't want to waste time with "nonsense"? Well, now we're taking about understanding the makeup of your users and what creates a good experience for them.
The user is the most important human, because it's the reason the software exists at all. Proper respect for the programmer is to respect the programmer as you say, but also help them to respect the user by providing a well thought out decomposition of the *human* experience that is to be delivered, in the form of clear chunks of behavior and state that map well to the thing the software is to be.
(This code reflects a poor understanding of what that would even look like, because the wrong objects own the wrong methods. The host does not follow, and the waiter does not wait for themself to be available. So in this sense you're disrespecting the programmer even more by presenting backwards abstractions. Maybe host.leadToTable(guest)?)
The human equivalent to the crappy code experience would be like a restaurant where before you can order food, you must talk about cars, and then try on different hats explain your favorite, and open and edit text files between every interaction. It doesn't fit the context at all!
Manners do exist in programming though, like good error messages, good naming so intention and purpose is clear, etc. Those things do *nothing* to improve the actual program itself, it's all about people. You've compared two very different contexts.
Maybe there is a place for both. Were a new customer gets the full service negotiation but a regular just has to walk in and nod to waiter. Application menus vs shortcut keys.
The part about this I don't understand is that it takes more effort to make the interactive "Smilies" program than the "Le Nix" one you call once and pass all the arguments into. Is there a plague of programmers making these sort of programs? You'd think there would be less of them just due to laziness. Or maybe I am just not understanding the analogy correctly.
What I do see a lot though, and maybe that's what this is getting at, is code that is broken into more parts and components and glue than is remotely necessary, making it much harder to understand that it all does, which might even be some very very simple thing. It's like each bolt is turned into it's own city. THAT kind of code is indeed, awful and disrespectful to humans all in sides (the programmer for obvious reasons, the user because what the software does & whether it even does that in a sensible way or whether it's even the right solution, is much further removed from the programmer's attention or even ability to analyze)
Although I 1000% support code that is as simple as possible, there's major problems with this comparison.
If the goal is just to order a damn meal, then yes all the "polite interaction" is a waste. But a commandline is not the same context as a restaurant. If you were coding a software driven restaurant of robot-workers, then you better damn well code them to create a good experience, or you've made a crappy service that will fail. But what if it's a restaurant for technologists who don't want to waste time with "nonsense"? Well, now we're taking about understanding the makeup of your users and what creates a good experience for them.
The user is the most important human, because it's the reason the software exists at all. Proper respect for the programmer is to respect the programmer as you say, but also help them to respect the user by providing a well thought out decomposition of the *human* experience that is to be delivered, in the form of clear chunks of behavior and state that map well to the thing the software is to be.
(This code reflects a poor understanding of what that would even look like, because the wrong objects own the wrong methods. The host does not follow, and the waiter does not wait for themself to be available. So in this sense you're disrespecting the programmer even more by presenting backwards abstractions. Maybe host.leadToTable(guest)?)
The human equivalent to the crappy code experience would be like a restaurant where before you can order food, you must talk about cars, and then try on different hats explain your favorite, and open and edit text files between every interaction. It doesn't fit the context at all!
Manners do exist in programming though, like good error messages, good naming so intention and purpose is clear, etc. Those things do *nothing* to improve the actual program itself, it's all about people. You've compared two very different contexts.
Of course the grey beard doesn't tip
Maybe there is a place for both. Were a new customer gets the full service negotiation but a regular just has to walk in and nod to waiter. Application menus vs shortcut keys.
The part about this I don't understand is that it takes more effort to make the interactive "Smilies" program than the "Le Nix" one you call once and pass all the arguments into. Is there a plague of programmers making these sort of programs? You'd think there would be less of them just due to laziness. Or maybe I am just not understanding the analogy correctly.