9 ms·

After doing this shit professionally for more years than I could care for anymore, when I see programming language or framework comparisons I immediately think

After doing this shit professionally for more years than I could care for anymore, when I see programming language or framework comparisons I immediately think of something like[1]: "Why Klein Cushion Grip screwdrivers are better than Wera Kraftform screwdrivers", or in this case "The myth of using Kraftform as a better screwdriver". And then I imagine myself going back to using my shitty old Phillips screwdriver set to screw in a few screws in a non-optimal fashion and someone might say "Wow, thanks for hanging my door!" and I imagine the surprise on my face as I realize that people want functioning doors and are not too bothered about which brand of screwdriver was used to achieve that. [1] http://blog.cnccookbook.com/2015/08/19/8-brands-to-consider-for-the-worlds-best-screwdriver/ http://blog.cnccookbook.com/2015/08/19/8-brands-to-consider-...

lumpypua 10y ago
To counter with an alternative tool comparison: drills and impact drivers look very similar. I'd bet that most of my friends don't really know the difference. But for some situations, an impact driver is an entirely more capable tool. If you use a drill all day, professionally, you'd be a fool not to take a serious look at an impact driver and see if it makes your life easier.
- timc3 10y ago
  I don’t think using different tools (which a drill and impact driver really is) is what the OP mean’t. He was more along the lines that must people don’t care whether you picked a Bosch impact driver or a DeWalt impact driver to fix their problem. And if you explain to someone the difference, they usually get it. Even my daughter when she was five could understand why I had two similar looking things when I was working with them..
  - azernik 10y ago
    But, again - if you're the person using those tools, you care about the difference. The difference in reliability, usability, power, whatever.
  - kelnos 10y ago
    That may be the point the OP was making, and if that's so, I'd counter that the point is irrelevant to make. Sure, the user of your software doesn't care what it's written in. Duh. Why should they? If they did, it'd be weird. But the people actually writing the software should care about choosing tools that fit the problem. Not because the end-user will care, but because choosing a more appropriate tool will allow them to build software that gets to market faster, and has fewer bugs and is easier to maintain.
kalleboo 10y ago
So I take it you develop in QBASIC?
- trustfundbaby 10y ago
  to be fair, that would be like using a shovel to hang the door. Just doesn't make sense :)
  - dwringer 10y ago
    Indeed. Maybe the original point is better analogized as saying "shovels are better than screwdrivers" rather than comparing two brands. Of course, it's even more meaningless to debate the merits of shovels vs screwdrivers than it is to debate the merits of two different screwdriver manufacturers.
- yellowapple 10y ago
  Depends. Is there a web framework for it? ;)
- throwawayish 10y ago
  FreeBASIC is actually still around ... and used ... ... for whatever reason ...
gotofritz 10y ago
What a crap, supercilious comment. Yes laypeople want functioning doors, but this is not an article for laypeople, it's an article for engineers. What we want are tools that allow us to build performant, maintainable, reliable code. Besides, if all you do is to fix a door than you may be right. But we build entire tower blocks, with doors, windows, elevators, ventilation systems, structures able to hold up tons of material, and all the rest. Your screwdriver metaphor may be good go way to score a cheap point with strangers on an internet forum, but not much besides.
- RyanZAG 10y ago
  When you're building a 'tower', what is more important? The strange new hammers and screwdrivers you're using, or the architecture, algorithms and data structures?
  - continuational 10y ago
    Please don't compare a programming language to a hammer. They're not similar in complexity, and it makes a really bad metaphor. Besides, unless you write entire applications in assembler, you DO care about programming languages.
    - btschaegg 10y ago
      I completely agree. Bricks would be a better metaphor and still completely contrived. And turns out, you can't build skyscrapers without concrete and steel :) And just to be pedantic: When I bought my first SwissTools Insider[1], I realized that it's actually still possible to innovate in screwdriver design. That doesn't make them better for every task, but hey, that's the way it is. [1]: http://www.pbswisstools.com/de/werkzeuge/quality-hand-tools/schraubenzieher/produkt/pb-6461cn/ http://www.pbswisstools.com/de/werkzeuge/quality-hand-tools/...
    - ganfortran 10y ago
      They are similar in outcome. Do u care about what language Amazon uses to write S3? Do u believe it is the language that make S3 succeed, or fail? Even as a programmer, as to the other services I am calling, things I do care about involving their stability and correctness that affecting my work. I care shit about what how they write their service underneath, may it be cool or dumb.
the-dude 10y ago
Ah, as my father used to call a hammer 'an American screwdriver'.
TeMPOraL 10y ago
Your example is looking at it from completely wrong way. Computer software users don't care about programming languages and frameworks either, because they know even less about them than they do about screwdrivers. Imagine your surprise if I came to you after you hung my door and said to you "thanks, but no thanks - that screwdriver of yours totally sucks!". On the other hand, if you worked as a carpenter (or even did some more door hanging on the side), you'd find yourself debating the tools and techniques of your trade with your fellow craftsmen, maybe even engaging in heated debates about their relative performance. The same is true about programming languages - they're tools of our trade. They have different performance characteristics. The discussion about that (and the flame wars) are between the craftsmen, not between the worker and the buyer.
- discreteevent 10y ago
  In my experience, no they don't spend much time debating the tools with their fellow craftsmen. And if you look at the tools themselves, they don't change much. They do tend to spend money on good quality versions of the same old tools though and just get on with it. It's more like spending money on a boring well supported commercial framework and focusing on the application rather than jumping to every half invented new thing every week. To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools. When Carmack wrote Doom he didn't use half of what C++ had to offer. It was just boring C with classes. But the application (Doom) was more than interesting at the time.
  - TeMPOraL 10y ago
    > To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools. That's true for many of us (but not all - probably e.g. not for most of my cow-orkers; for some people, this is just a 9-5 job). This is the "art" aspect of programming. We can care about the process just as much (or more) than we care about the actual deliverable. I definitely see most of the jobs I've done so far as utterly boring; e.g. most of the web development work I've seen or done would barely challenge a monkey cognitively. What makes things difficult there is usually not the problem, but a) constantly changing definition of the problem, and b) self-imposed complexity. Same seems to be true in desktop projects I work on now. That's why I like hobby projects - you get to choose problems that are interesting.
weego 10y ago
This is exactly how I feel. Too many developers lose sight of what they actually valued for. Sure there are a subset who we need to be at a higher level to do the leg work on building tools etc, but 95% of developers really are far too involved in issues and obsess over things that distract from their actual role.
- vmateixeira 10y ago
  Despite what a developer is mostly valued for (delivery), his professionalist on picking the best tools for the job (obviously to his knowledge) should also be expected, so that his client has the best outcome from his work: Deliverable suitable for the use case, performant, scalable if required, maintainable, etc
throwawayish 10y ago
> They also sell a step-up model whose main difference seems to be that it is made of stainless steel. What will the Germans think of next? Only stainless steel tools on stainless steel work pieces and vice versa. Don't mix stainless/non-stainless tools and non-stainless/stainless work pieces. Hence stuff like screw drivers will be needed in both variants.
xiaoma 10y ago
Comparing the decision of a type of screwdriver to use with a programming language is disingenuous at best, given the vast differences in complexity, switching costs and effects on productivity. A more honest comparison would be screwdriver choice vs whether to use 80 or 100 character column limits.
brianmcc 10y ago
I agree, and feel compelled to link this old gem. I never tire of it. http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12& http://discuss.joelonsoftware.com/default.asp?joel.3.219431....
pif 10y ago
> people want functioning door Sure! And people want functioning software, too. The biggest difference between the two worlds being that maintenance is an exceptional event for a door while being the essence of its lifetime for software.
ZoFreX 10y ago
As someone who used to put in dozens or hundreds of screws in a day, sometimes: Yeah, if you're hanging one door maybe you don't care so much. But on door #100, when your hand is covered in blisters, and your screwdriver has rounded off to the point it can no longer put in screws, maybe you'll care which screwdriver you're using.
cutler 10y ago
The language as physical tool metaphor is meaningless as far as I'm concerned. Physical tools and programming languages have very little in common. The reason so much is written about programming languages on HN and Reddit is because a language shapes the way you think and anything that alters your way of thinking is a serious matter. Some are expressive, others are not. In that sense a programming language has more in common with a political ideology or religion than something found in a garden shed. That's why programmers - at least those with a soul intact after x years in a Java shop - often obsess over the pros and cons of a programming language. To a craftsman it matters. DHH once made an excellent defence of programmers as writers rather than engineers and it's perhaps no coincidence that the language he was referring to has ancestry with Perl which was designed by a linguist. Try Clojure/Lisp sometime if you haven't already. Then you'll experience programming as closer to expressive linguistic art than engineering. My first programming language was Perl and I had to choose between Java and Perl at the time. If you haven't read Larry Wall's "Programming Perl" I recommend it regardless of the status of Perl in the current scene. It's a classic, written in a warm, witty style. 5 minutes with Deitel and Deitel's turgid Java tome and I was sold on Perl. The point I'm making is that choosing Perl over Java as my first language made a huge difference to how I programme today having learned many languages since. I still keep my use of objects to a minimum, prefer functional over OOP and love Clojure with a passion. Sorry, "just a tool" is meaningless.
tjalfi 10y ago
Philip Greenspun made a similar comment. "Another issue is a perennial side-show in the world-wide computer programming circus: the spectacle of nerds arguing over programming tools. The data model can't represent the information that the users need, the application doesn't do what what the users need it to do, and instead of writing code, the "engineers" are arguing about Java versus Lisp versus Perl versus Tcl. If you want to know why computer programmers get paid less than medical doctors, consider the situation of two trauma surgeons arriving at an accident scene. The patient is bleeding profusely. If surgeons were like programmers, they'd leave the patient to bleed out in order to have a really satisfying argument over the merits of two different kinds of tourniquet." http://blogs.harvard.edu/philg/2003/08/12/ http://blogs.harvard.edu/philg/2003/08/12/
- no_flags 10y ago
  I don't think this a fair analogy, or that it plausibly explains the wage gap between programmers and doctors. I'm sure doctors discuss the merits of different medical techniques at conferences. In a similar "emergency" situation (e.g. customer demands bug fixed by tomorrow) I have not see anyone agonize over the right tool for the job. In both industries there is a time and place to discuss best practices and how we can improve them. I admit that the programming world seems to have these discussions more frequently.
oldsj 10y ago
What if screwdriver choice affects how quickly you can deliver your hung door, and how well it will scale and be maintainable in the future? You COULD write a website in pure ASM[0], but should you? https://asm32.info/fossil/repo/asmbb/index https://asm32.info/fossil/repo/asmbb/index
- iso-8859-1 10y ago
  That message board is actually amazingly fast. I do think it is possible to do in a language with automatic memory management, though.
dkarl 10y ago
In theory, you're right, Java versus Scala is just small difference in how you express the same things in two different languages. In practice, you're wrong. Choosing Java or Scala makes a huge difference in style and culture. The mere existence of Scala (and Clojure, and Go) as a viable alternative has intensified the bad tendencies in Java culture, the tendencies responsible for the stereotypes of overabstraction, OO overkill, framework bloat, and gratuitous "enterprisiness." In the past, large numbers of people who did not have a high tolerance for those things worked in Java for good pragmatic reasons. They served as a loyal opposition that called out and pushed back against excesses, saying things like, we can't make every call over CORBA, it's asinine to need reams of XML to configure a simple web application, and Hibernate is harder to get right than the thing it's supposedly protecting us from. The loyal opposition are dwindling as more developers choose Scala and Go for application development. More and more the people sticking with Java are people who were perfectly happy wiring their applications in XML and learning "best practices" from Sun's marketing department. The Java ecosystem isn't going to regress overnight back to those bad old days, but that's the culture you adopt when you adopt Java as a language for application development.

lumpypua 10y ago

To counter with an alternative tool comparison: drills and impact drivers look very similar. I'd bet that most of my friends don't really know the difference. But for some situations, an impact driver is an entirely more capable tool. If you use a drill all day, professionally, you'd be a fool not to take a serious look at an impact driver and see if it makes your life easier.

timc3 10y ago
I don’t think using different tools (which a drill and impact driver really is) is what the OP mean’t. He was more along the lines that must people don’t care whether you picked a Bosch impact driver or a DeWalt impact driver to fix their problem. And if you explain to someone the difference, they usually get it. Even my daughter when she was five could understand why I had two similar looking things when I was working with them..
- azernik 10y ago
  But, again - if you're the person using those tools, you care about the difference. The difference in reliability, usability, power, whatever.
- kelnos 10y ago
  That may be the point the OP was making, and if that's so, I'd counter that the point is irrelevant to make. Sure, the user of your software doesn't care what it's written in. Duh. Why should they? If they did, it'd be weird. But the people actually writing the software should care about choosing tools that fit the problem. Not because the end-user will care, but because choosing a more appropriate tool will allow them to build software that gets to market faster, and has fewer bugs and is easier to maintain.

kalleboo 10y ago

So I take it you develop in QBASIC?

trustfundbaby 10y ago
to be fair, that would be like using a shovel to hang the door. Just doesn't make sense :)
- dwringer 10y ago
  Indeed. Maybe the original point is better analogized as saying "shovels are better than screwdrivers" rather than comparing two brands. Of course, it's even more meaningless to debate the merits of shovels vs screwdrivers than it is to debate the merits of two different screwdriver manufacturers.
yellowapple 10y ago
Depends. Is there a web framework for it? ;)
throwawayish 10y ago
FreeBASIC is actually still around ... and used ... ... for whatever reason ...

gotofritz 10y ago

What a crap, supercilious comment. Yes laypeople want functioning doors, but this is not an article for laypeople, it's an article for engineers. What we want are tools that allow us to build performant, maintainable, reliable code. Besides, if all you do is to fix a door than you may be right. But we build entire tower blocks, with doors, windows, elevators, ventilation systems, structures able to hold up tons of material, and all the rest. Your screwdriver metaphor may be good go way to score a cheap point with strangers on an internet forum, but not much besides.

RyanZAG 10y ago
When you're building a 'tower', what is more important? The strange new hammers and screwdrivers you're using, or the architecture, algorithms and data structures?
- continuational 10y ago
  Please don't compare a programming language to a hammer. They're not similar in complexity, and it makes a really bad metaphor. Besides, unless you write entire applications in assembler, you DO care about programming languages.
  - btschaegg 10y ago
    I completely agree. Bricks would be a better metaphor and still completely contrived. And turns out, you can't build skyscrapers without concrete and steel :) And just to be pedantic: When I bought my first SwissTools Insider[1], I realized that it's actually still possible to innovate in screwdriver design. That doesn't make them better for every task, but hey, that's the way it is. [1]: http://www.pbswisstools.com/de/werkzeuge/quality-hand-tools/schraubenzieher/produkt/pb-6461cn/ http://www.pbswisstools.com/de/werkzeuge/quality-hand-tools/...
  - ganfortran 10y ago
    They are similar in outcome. Do u care about what language Amazon uses to write S3? Do u believe it is the language that make S3 succeed, or fail? Even as a programmer, as to the other services I am calling, things I do care about involving their stability and correctness that affecting my work. I care shit about what how they write their service underneath, may it be cool or dumb.

the-dude 10y ago

Ah, as my father used to call a hammer 'an American screwdriver'.

TeMPOraL 10y ago

Your example is looking at it from completely wrong way. Computer software users don't care about programming languages and frameworks either, because they know even less about them than they do about screwdrivers. Imagine your surprise if I came to you after you hung my door and said to you "thanks, but no thanks - that screwdriver of yours totally sucks!". On the other hand, if you worked as a carpenter (or even did some more door hanging on the side), you'd find yourself debating the tools and techniques of your trade with your fellow craftsmen, maybe even engaging in heated debates about their relative performance. The same is true about programming languages - they're tools of our trade. They have different performance characteristics. The discussion about that (and the flame wars) are between the craftsmen, not between the worker and the buyer.

discreteevent 10y ago
In my experience, no they don't spend much time debating the tools with their fellow craftsmen. And if you look at the tools themselves, they don't change much. They do tend to spend money on good quality versions of the same old tools though and just get on with it. It's more like spending money on a boring well supported commercial framework and focusing on the application rather than jumping to every half invented new thing every week. To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools. When Carmack wrote Doom he didn't use half of what C++ had to offer. It was just boring C with classes. But the application (Doom) was more than interesting at the time.
- TeMPOraL 10y ago
  > To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools. That's true for many of us (but not all - probably e.g. not for most of my cow-orkers; for some people, this is just a 9-5 job). This is the "art" aspect of programming. We can care about the process just as much (or more) than we care about the actual deliverable. I definitely see most of the jobs I've done so far as utterly boring; e.g. most of the web development work I've seen or done would barely challenge a monkey cognitively. What makes things difficult there is usually not the problem, but a) constantly changing definition of the problem, and b) self-imposed complexity. Same seems to be true in desktop projects I work on now. That's why I like hobby projects - you get to choose problems that are interesting.

weego 10y ago

This is exactly how I feel. Too many developers lose sight of what they actually valued for. Sure there are a subset who we need to be at a higher level to do the leg work on building tools etc, but 95% of developers really are far too involved in issues and obsess over things that distract from their actual role.

vmateixeira 10y ago
Despite what a developer is mostly valued for (delivery), his professionalist on picking the best tools for the job (obviously to his knowledge) should also be expected, so that his client has the best outcome from his work: Deliverable suitable for the use case, performant, scalable if required, maintainable, etc

throwawayish 10y ago

> They also sell a step-up model whose main difference seems to be that it is made of stainless steel. What will the Germans think of next? Only stainless steel tools on stainless steel work pieces and vice versa. Don't mix stainless/non-stainless tools and non-stainless/stainless work pieces. Hence stuff like screw drivers will be needed in both variants.

xiaoma 10y ago

Comparing the decision of a type of screwdriver to use with a programming language is disingenuous at best, given the vast differences in complexity, switching costs and effects on productivity. A more honest comparison would be screwdriver choice vs whether to use 80 or 100 character column limits.

brianmcc 10y ago

I agree, and feel compelled to link this old gem. I never tire of it. http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12& http://discuss.joelonsoftware.com/default.asp?joel.3.219431....

pif 10y ago

> people want functioning door Sure! And people want functioning software, too. The biggest difference between the two worlds being that maintenance is an exceptional event for a door while being the essence of its lifetime for software.

ZoFreX 10y ago

As someone who used to put in dozens or hundreds of screws in a day, sometimes: Yeah, if you're hanging one door maybe you don't care so much. But on door #100, when your hand is covered in blisters, and your screwdriver has rounded off to the point it can no longer put in screws, maybe you'll care which screwdriver you're using.

cutler 10y ago

The language as physical tool metaphor is meaningless as far as I'm concerned. Physical tools and programming languages have very little in common. The reason so much is written about programming languages on HN and Reddit is because a language shapes the way you think and anything that alters your way of thinking is a serious matter. Some are expressive, others are not. In that sense a programming language has more in common with a political ideology or religion than something found in a garden shed. That's why programmers - at least those with a soul intact after x years in a Java shop - often obsess over the pros and cons of a programming language. To a craftsman it matters. DHH once made an excellent defence of programmers as writers rather than engineers and it's perhaps no coincidence that the language he was referring to has ancestry with Perl which was designed by a linguist. Try Clojure/Lisp sometime if you haven't already. Then you'll experience programming as closer to expressive linguistic art than engineering. My first programming language was Perl and I had to choose between Java and Perl at the time. If you haven't read Larry Wall's "Programming Perl" I recommend it regardless of the status of Perl in the current scene. It's a classic, written in a warm, witty style. 5 minutes with Deitel and Deitel's turgid Java tome and I was sold on Perl. The point I'm making is that choosing Perl over Java as my first language made a huge difference to how I programme today having learned many languages since. I still keep my use of objects to a minimum, prefer functional over OOP and love Clojure with a passion. Sorry, "just a tool" is meaningless.

tjalfi 10y ago

Philip Greenspun made a similar comment. "Another issue is a perennial side-show in the world-wide computer programming circus: the spectacle of nerds arguing over programming tools. The data model can't represent the information that the users need, the application doesn't do what what the users need it to do, and instead of writing code, the "engineers" are arguing about Java versus Lisp versus Perl versus Tcl. If you want to know why computer programmers get paid less than medical doctors, consider the situation of two trauma surgeons arriving at an accident scene. The patient is bleeding profusely. If surgeons were like programmers, they'd leave the patient to bleed out in order to have a really satisfying argument over the merits of two different kinds of tourniquet." http://blogs.harvard.edu/philg/2003/08/12/ http://blogs.harvard.edu/philg/2003/08/12/

no_flags 10y ago
I don't think this a fair analogy, or that it plausibly explains the wage gap between programmers and doctors. I'm sure doctors discuss the merits of different medical techniques at conferences. In a similar "emergency" situation (e.g. customer demands bug fixed by tomorrow) I have not see anyone agonize over the right tool for the job. In both industries there is a time and place to discuss best practices and how we can improve them. I admit that the programming world seems to have these discussions more frequently.

oldsj 10y ago

What if screwdriver choice affects how quickly you can deliver your hung door, and how well it will scale and be maintainable in the future? You COULD write a website in pure ASM[0], but should you? https://asm32.info/fossil/repo/asmbb/index https://asm32.info/fossil/repo/asmbb/index

iso-8859-1 10y ago
That message board is actually amazingly fast. I do think it is possible to do in a language with automatic memory management, though.

dkarl 10y ago

In theory, you're right, Java versus Scala is just small difference in how you express the same things in two different languages. In practice, you're wrong. Choosing Java or Scala makes a huge difference in style and culture. The mere existence of Scala (and Clojure, and Go) as a viable alternative has intensified the bad tendencies in Java culture, the tendencies responsible for the stereotypes of overabstraction, OO overkill, framework bloat, and gratuitous "enterprisiness." In the past, large numbers of people who did not have a high tolerance for those things worked in Java for good pragmatic reasons. They served as a loyal opposition that called out and pushed back against excesses, saying things like, we can't make every call over CORBA, it's asinine to need reams of XML to configure a simple web application, and Hibernate is harder to get right than the thing it's supposedly protecting us from. The loyal opposition are dwindling as more developers choose Scala and Go for application development. More and more the people sticking with Java are people who were perfectly happy wiring their applications in XML and learning "best practices" from Sun's marketing department. The Java ecosystem isn't going to regress overnight back to those bad old days, but that's the culture you adopt when you adopt Java as a language for application development.