5 ms·

Yet another software opinion article preaching mediocrity. Imagine a carpenter that only uses a hammer because learning other tools is too hard for them, and he

Yet another software opinion article preaching mediocrity. Imagine a carpenter that only uses a hammer because learning other tools is too hard for them, and he'd have to bring his colleagues up to speed, and ah forget it we can use nails instead of screws anyway. "Oh! Drain pipe for the faucet? I know, I'll just use leftover air vent ducts, that's what I'm already familiar with anyway!" (Using nails to join everything of course, how's that for a leaky abstraction?) As he proclaims the "first sprint" done he walks up to you, demanding a 100K/year salary. When you decline, because the house is falling apart, he angrily mutters something about how "tech debt" is wrecking this industry (he's blaming the failure on you for not giving enough time to address it) and that he was thinking about finding another job anyway, since he was already working for you close to a year now.

swores 4y ago
The point isn't to use a hammer for everything, it's that you maybe don't need to get a new, slightly different sized, hammer every time you get a slightly different size of screw to hit in. And that when you want to pull a nail out you can use the other side on your claw hammer, rather than go hunting for a dedicated NailRemoverPro TM that you've heard will make your nail removal even smoother. Unlike with carpentry, when it comes to programming languages there actually are multiple options that can be used for such a wide range of purposes that it's possible to built entire projects/products using just the single one you prefer, which is of course less likely to be feasible when it comes to using a single tool like a hammer.
- bruce343434 4y ago
  Choice of language has much larger implications than you are implying. Yes, every language is turing complete. Now write a regex engine in pure "turing machine". Sucks, doesn't it? This is known as the "Turing Tarpit". Every language has unique strengths and weaknesses and it's absurd to pretend they're all kinda the same. I wouldn't write a website in C. I wouldn't write a robot arm driver in PHP. I wouldn't write anything more complicated than a throwaway script in bash. I don't mean to be disrespectful, and perhaps I didn't read your reply right. But it seems to me if you don't differentiate languages, then you either don't have enough knowledge of and exposure to various programming techniques and language design ideas, or you're making an argument in bad faith.
  - TazeTSchnitzel 4y ago
    I think you do your point a disservice with your examples. General-purpose programming languages are nothing like Turing tarpits. > I wouldn't write a website in C. With appropriate libraries, why not? The safety issues might be a problem, but you could sandbox it. > I wouldn't write a robot arm driver in PHP. I would. It's general-purpose enough to speak binary protocols without too much hassle, though it'd be more fun to use something else.
    - bruce343434 4y ago
      > With appropriate libraries, why not? The safety issues might be a problem, but you could sandbox it. Ok, go ahead use air ducts as water pipes. Just "sandbox" it with some plastic wrap.
    - tialaramex 4y ago
      I have written a web site in C about twenty years ago, and it was terrible. Absolutely Turing Tarpit category, the language is just completely inadequate for this problem and so you spend all your effort trying to build something which is suitable out of the language, which again, yes, Turing Completeness, of course it's technically possible but it's a bad idea. Web sites are full of strings, and C doesn't really grok strings. Not in the way WUFFS doesn't grok strings (there are no strings in WUFFS, it has no string type, it's not a general purpose language it's not for that), more like the way New Forest ponies don't grok traffic laws.
      - TazeTSchnitzel 4y ago
        Many high-level languages with good string support are implemented in C. The C standard library sucks but it's not your only option for handling strings.
  - wiseowise 4y ago
    > Now write a regex engine in pure "turing machine". Sucks, doesn't it? This is known as the "Turing Tarpit". Jesus, we’re talking about primitive CRUDs here, not tegen engines.
- userbinator 4y ago
  The hammer analogy makes me feel obligated to post this classic: https://gwern.net/docs/cs/2005-09-30-smith-whyihateframeworks.html https://gwern.net/docs/cs/2005-09-30-smith-whyihateframework...
- sokoloff 4y ago
  > don't need to get a new, slightly different sized, hammer every time you get a slightly different size of screw to hit in. I don’t know for 100% if that (hammer in a screw) was intentional or not, but it was beautiful.
pflenker 4y ago
That's not what I took away from the article. On the contrary, to me, the article listed several trade-offs that come with choosing what might be the "right" tool at any given time. The carpenter metaphor does not really fit here, because at some point, a carpenter is clearly "done" and moves on to other projects, whereas developers continuously maintain and extend the work - their own and their colleague's.
- bruce343434 4y ago
  When what you have built is effectively a bike, and the customer requests 2 additional wheels, you don't duct tape them on. You rewrite from scratch, building the customer a car this time. Sometimes, you can salvage parts. Maybe the frame is still good when the customer reveals they actually want a minivan instead of a car. Maybe you can reuse the engine and wheels and transmission and seats. But the other stuff has got to be replaced. Why is our industry so against rewriting? There seems to be a massive focus on building stuff so generic such that it is magically extendable into anything. Hint: it never is. It never will be. Write specialized code, which is always smaller, clearer, easier to understand code against the heavily abstracted bullshit you'd otherwise get. And yes, sometimes that means the "bicycle wheel" library/framework/language needs to be replaced in your shop.
  - yladiz 4y ago
    This ignores the cost of replacing code. I agree with your point that you should focus on the problem at hand, and not make code too generic, but if you only make specialized code with the idea of “we can rewrite or replace it later” you will end up with a lot of specialized code that is never rewritten.
intelVISA 4y ago
"Look boss, I aint here to reinvent the wheel." You stare in horror at your new GoLand house with GoLand(tm) roof, floor, tiles and windows. At least it isn't Node you reassure yourself as the AWS bills roll in.
- cdogl 4y ago
  I don’t understand this comment one bit. GoLand is a decent IDE. Go is a fairly fast compiled language, likely to produce faster code than the average AWS workload.
TurboHaskal 4y ago
It seems for some our industry is not boring and tedious enough.
vault_ 4y ago
This isn't a fair analogy. There's a cost to adding new tools to a software environment, and an ongoing cost to maintaining that tool. Closer, IMO, is you're speccing out a new house with a builder and ask for a swimming pool, a hot tub, jacuzzi tubs, and body sprayers in the showers. Getting all of those installed and running to spec is going to be much more expensive than getting one or two of them. If your builder says "You really need the pool. I'll see if I can get that dug in my free time, don't worry about it." you are probably going to worry about what you're actually getting. If you do have the budget to do everything properly, you also need to have the ongoing budget for cleaning and maintenance. Pools and tubs have very different maintenance profiles. The same is true for software. Which is to say, using the "right" tool is nice, but not always in the budget. R or Julia may be a better language for data science than Python, but if you're the only one using them, you're just making things harder for the rest of your team. A Python shop has probably invested in coding standards, linters, test infrastructure, common libraries, and has expectations for how code runs "in production". Expect that you'll need to clear at least some of that bar for a new tool you introduce. Expanding towards tools that better fit problems is good, but unless you're doing 100% green field development it needs to be intentional and measured.

swores 4y ago

The point isn't to use a hammer for everything, it's that you maybe don't need to get a new, slightly different sized, hammer every time you get a slightly different size of screw to hit in. And that when you want to pull a nail out you can use the other side on your claw hammer, rather than go hunting for a dedicated NailRemoverPro TM that you've heard will make your nail removal even smoother. Unlike with carpentry, when it comes to programming languages there actually are multiple options that can be used for such a wide range of purposes that it's possible to built entire projects/products using just the single one you prefer, which is of course less likely to be feasible when it comes to using a single tool like a hammer.

bruce343434 4y ago
Choice of language has much larger implications than you are implying. Yes, every language is turing complete. Now write a regex engine in pure "turing machine". Sucks, doesn't it? This is known as the "Turing Tarpit". Every language has unique strengths and weaknesses and it's absurd to pretend they're all kinda the same. I wouldn't write a website in C. I wouldn't write a robot arm driver in PHP. I wouldn't write anything more complicated than a throwaway script in bash. I don't mean to be disrespectful, and perhaps I didn't read your reply right. But it seems to me if you don't differentiate languages, then you either don't have enough knowledge of and exposure to various programming techniques and language design ideas, or you're making an argument in bad faith.
- TazeTSchnitzel 4y ago
  I think you do your point a disservice with your examples. General-purpose programming languages are nothing like Turing tarpits. > I wouldn't write a website in C. With appropriate libraries, why not? The safety issues might be a problem, but you could sandbox it. > I wouldn't write a robot arm driver in PHP. I would. It's general-purpose enough to speak binary protocols without too much hassle, though it'd be more fun to use something else.
  - bruce343434 4y ago
    > With appropriate libraries, why not? The safety issues might be a problem, but you could sandbox it. Ok, go ahead use air ducts as water pipes. Just "sandbox" it with some plastic wrap.
  - tialaramex 4y ago
    I have written a web site in C about twenty years ago, and it was terrible. Absolutely Turing Tarpit category, the language is just completely inadequate for this problem and so you spend all your effort trying to build something which is suitable out of the language, which again, yes, Turing Completeness, of course it's technically possible but it's a bad idea. Web sites are full of strings, and C doesn't really grok strings. Not in the way WUFFS doesn't grok strings (there are no strings in WUFFS, it has no string type, it's not a general purpose language it's not for that), more like the way New Forest ponies don't grok traffic laws.
    - TazeTSchnitzel 4y ago
      Many high-level languages with good string support are implemented in C. The C standard library sucks but it's not your only option for handling strings.
- wiseowise 4y ago
  > Now write a regex engine in pure "turing machine". Sucks, doesn't it? This is known as the "Turing Tarpit". Jesus, we’re talking about primitive CRUDs here, not tegen engines.
userbinator 4y ago
The hammer analogy makes me feel obligated to post this classic: https://gwern.net/docs/cs/2005-09-30-smith-whyihateframeworks.html https://gwern.net/docs/cs/2005-09-30-smith-whyihateframework...
sokoloff 4y ago
> don't need to get a new, slightly different sized, hammer every time you get a slightly different size of screw to hit in. I don’t know for 100% if that (hammer in a screw) was intentional or not, but it was beautiful.

pflenker 4y ago

That's not what I took away from the article. On the contrary, to me, the article listed several trade-offs that come with choosing what might be the "right" tool at any given time. The carpenter metaphor does not really fit here, because at some point, a carpenter is clearly "done" and moves on to other projects, whereas developers continuously maintain and extend the work - their own and their colleague's.

bruce343434 4y ago
When what you have built is effectively a bike, and the customer requests 2 additional wheels, you don't duct tape them on. You rewrite from scratch, building the customer a car this time. Sometimes, you can salvage parts. Maybe the frame is still good when the customer reveals they actually want a minivan instead of a car. Maybe you can reuse the engine and wheels and transmission and seats. But the other stuff has got to be replaced. Why is our industry so against rewriting? There seems to be a massive focus on building stuff so generic such that it is magically extendable into anything. Hint: it never is. It never will be. Write specialized code, which is always smaller, clearer, easier to understand code against the heavily abstracted bullshit you'd otherwise get. And yes, sometimes that means the "bicycle wheel" library/framework/language needs to be replaced in your shop.
- yladiz 4y ago
  This ignores the cost of replacing code. I agree with your point that you should focus on the problem at hand, and not make code too generic, but if you only make specialized code with the idea of “we can rewrite or replace it later” you will end up with a lot of specialized code that is never rewritten.

intelVISA 4y ago

"Look boss, I aint here to reinvent the wheel." You stare in horror at your new GoLand house with GoLand(tm) roof, floor, tiles and windows. At least it isn't Node you reassure yourself as the AWS bills roll in.

cdogl 4y ago
I don’t understand this comment one bit. GoLand is a decent IDE. Go is a fairly fast compiled language, likely to produce faster code than the average AWS workload.

TurboHaskal 4y ago

It seems for some our industry is not boring and tedious enough.

vault_ 4y ago

This isn't a fair analogy. There's a cost to adding new tools to a software environment, and an ongoing cost to maintaining that tool. Closer, IMO, is you're speccing out a new house with a builder and ask for a swimming pool, a hot tub, jacuzzi tubs, and body sprayers in the showers. Getting all of those installed and running to spec is going to be much more expensive than getting one or two of them. If your builder says "You really need the pool. I'll see if I can get that dug in my free time, don't worry about it." you are probably going to worry about what you're actually getting. If you do have the budget to do everything properly, you also need to have the ongoing budget for cleaning and maintenance. Pools and tubs have very different maintenance profiles. The same is true for software. Which is to say, using the "right" tool is nice, but not always in the budget. R or Julia may be a better language for data science than Python, but if you're the only one using them, you're just making things harder for the rest of your team. A Python shop has probably invested in coding standards, linters, test infrastructure, common libraries, and has expectations for how code runs "in production". Expect that you'll need to clear at least some of that bar for a new tool you introduce. Expanding towards tools that better fit problems is good, but unless you're doing 100% green field development it needs to be intentional and measured.