8 ms·

How much do we bend to the will of our tools?

26 points by Teckla 7y ago

fhood 7y ago
I don't understand. Is it really all that common for developers to auto-format code and not spot check the result? Is using auto-formatting tools particularly widespread? Don't most people just format the code to their liking as they write it? Am I completely off base here?
- Macha 7y ago
  Yes. Not just that, but those developers then add these tools to be enforced in their CI pipeline because "It's good to be consistent", and if that tool occasionally barfs out something extremely suboptimal, that's just the cost of consistency.
  - nothrabannosir 7y ago
    I'm sensing some sarcasm, but I want to go on record and say I actually completely agree with this message. My time working in Go with its institutionalised gofmt was a blessing.
  - timw4mail 7y ago
    I'd argue that's more likely a deficiency of the tool, as well as the fact that consistency just isn't the best solution in all cases.
  - fhood 7y ago
    Haha, I've always found that me and those CI checks get along pretty well 70% of the time, I made a mistake 20% of the time, and an ignore flag handles the remainder.
- dutchCourage 7y ago
  > Is using auto-formatting tools particularly widespread? Don't most people just format the code to their liking as they write it? Am I completely off base here? It's everywhere in the javascript world. I started using it a few years ago and would never go back. Having a consistent formatting when working with a team is great and it comes at basically no costs. And for the few exceptions where the auto-formatted code is harder to read, it can be disabled by a comment.
robomartin 7y ago
Well, when you have a Sawzall you pretty much let it drive...just pull the trigger and go. Half-joking, of course. Now, that might seem like an off-topic comment but, if you think about it, the analogy might be somewhat reasonable. BTW, I am NOT implying this is a bad thing. And yet I have to thrown in the "With great power comes great responsibility". I like intelligent tools that help me do my job. I don't care about things like --sorry-- the cult of vi/vim (text entry speed is irrelevant). My reality is that, as a multi-disciplinary engineer I find myself context switching all the time, from mechanical engineering, to optics, electronics, embedded, FPGA's, workstation, mobile and even web. When you context-switch like that the tools can really help you make the switch with less friction. So, yes, when you are changing languages and frameworks with some frequency rather than working in the same ecosystem for years, things like intelligent completion and suggestion, intelligent awareness of libraries and frameworks and a few other features can be massively helpful. This, BTW, is why I like the Jetbrains tools, not only are they excellent and well done, they help with all sorts of intelligence and integrations. But, yes, if you don't know what you are doing a Sawzall can cut off your leg.
- musingsole 7y ago
  >text entry speed is irrelevant Tools help you think in units of your usage of them. If you produce more words in a given amount of time with one editor over another, then the faster editor will enable you to begin thinking/planning in bigger blocks of a text at a time. Arguably though, vim's strength isn't text entry speed alone but faster abstract manipulation of text. Use a tool long enough, and it's best use cases become the default cases you lean towards when planning your next move.
  - robomartin 7y ago
    Nope. Text entry facilitation is useful but irrelevant. Go work on code for an MRI machine, a spacecraft or an implantable insulin pump (all of which I have worked on) and see just how much you care about how quickly you can enter text or manipulate it. The answer: It is absolutely irrelevant. You will spend 10x, 100x, 1,000x longer doing other things that are actually important. I said this in another comment: Real software development is not assembly line work. It isn't mass data entry. Because of that text entry speed and efficiency is immaterial. It can feel good to have auto-completion and such tools, but, at the end of the day, it doesn't produce better code with less bugs any faster than any other approach. If text entry speed were important I would still be using APL (which I used professionally for ten years). In one line of code you can write what would require tens to hundreds of lines with other languages. If this were the case everyone would be using APL, because, if you want to compute at the speed of thought you need that kind of an approach. Reality, on the other hand, is that solving problems computationally is far more than text entry. A simple thought exercise would be to take three teams solving the same real problem. For example, writing the code to run an implantable insulin pump. One team uses vi/vim. The other uses Notepad++. The third uses a modern IDE. Which team will deliver a fully-functional, safe, bug-free product that will pass all necessary tests and ship to customers without killing them? Which one will do so faster? The answer is: The editor/IDE choice has nothing to do with both of these questions. And, in fact, when things really matter, you care far more about good bug-free code than how fast you wrote it. Banking or spacecraft are other examples of this. It's OK to use whatever tools make one happy, no issues there. Just don't lie to yourself about what they are and what they are not. Another view: I would not hire anyone who insists on using vi/vim. I don't deliver code-writing athletic performance. I deliver hardware+software products that have to work correctly and, ideally, not kill anyone. Coming in with a misplaced religious view about code entry means the person has no clue about the reason we do what we do and what's important.
bediger4000 7y ago
I know this article relates to programming, not linguistics, but... I live near a street named "Elati". Humans pronounce that Uh-lah-tee, all 3 syllables nearly the same emphasis. Google maps calls it Ell-uh-tee, emphasis on the "Ell". How long before human language bends to the will of Google maps' pronunciation algorithm. I don't think this is good or bad, merely interesting, and I'd like to know the name linguists have for this phenomenon.
- wccrawford 7y ago
  I live near a few cities that are pronounced very differently by locals than by visitors. That hasn't convinced the locals to change their pronunciation yet, so I seriously doubt that Google will manage it, either. I think pretty much everyone has something that GPS pronounces incorrectly near them.
- silicon2401 7y ago
  The closest I can think of (not a linguist) is hypercorrection, which is essentially 'correcting' what's already correct, and ending up with something that wouldn't previously be considered correct. But language correctness is defined by speakers, so eventually hypercorrection could eventually become the new standard. https://en.wikipedia.org/wiki/Hypercorrection https://en.wikipedia.org/wiki/Hypercorrection
  - caleb-allen 7y ago
    Is the use of the word "literally" an example of this?
    - silicon2401 7y ago
      I would say no. "Literally" has been used in a non-literal sense for centuries. https://www.etymonline.com/word/literally#etymonline_v_30161 https://www.etymonline.com/word/literally#etymonline_v_30161
pjc50 7y ago
Nah, I've seen people write things that horrible long before they had tools to deal with it. People used to write BASIC that looked like this: https://cdn.arstechnica.net/wp-content/uploads/2012/12/BASIC-code.jpg https://cdn.arstechnica.net/wp-content/uploads/2012/12/BASIC... Readability is nice, but it's a luxury, and a subjective one.
christiansakai 7y ago
Yes I noticed myself doing this and also my colleagues when I used IDE. Now I mostly use vim and I notice myself trying as best as I can to code so that I can understand it with plain text editor. And it shows. I personally keep using vim because of this reason.
thedirt0115 7y ago
"Can we explain the differences in identifier length preferences between language communities by pointing to the availability of reliable auto-complete in one and lack thereof in another?" I'd have to say "no" to this. What immediately jumped to mind was Java vs Go, where there seems to be a strong preference towards shorter identifiers in Go even though there has basically never been a time when Go did NOT have good autocomplete capabilities. One might argue that Go tends to have shorter identifiers because the authors of a lot of the earliest Go code came from a C background where there wasn't autocomplete. But nearly every language has reliable auto-complete these days, so I'm gonna stick with "no".
pixelrevision 7y ago
The example in the article certainly did not bend to the will of the “code review” tool. The issues had nothing to do with a linter, the author just never went back to consider if it was legible.
deleted 7y ago
[deleted]

26 points by Teckla 7y ago

I don't understand. Is it really all that common for developers to auto-format code and not spot check the result? Is using auto-formatting tools particularly widespread? Don't most people just format the code to their liking as they write it? Am I completely off base here?

Macha 7y ago
Yes. Not just that, but those developers then add these tools to be enforced in their CI pipeline because "It's good to be consistent", and if that tool occasionally barfs out something extremely suboptimal, that's just the cost of consistency.
- nothrabannosir 7y ago
  I'm sensing some sarcasm, but I want to go on record and say I actually completely agree with this message. My time working in Go with its institutionalised gofmt was a blessing.
- timw4mail 7y ago
  I'd argue that's more likely a deficiency of the tool, as well as the fact that consistency just isn't the best solution in all cases.
- fhood 7y ago
  Haha, I've always found that me and those CI checks get along pretty well 70% of the time, I made a mistake 20% of the time, and an ignore flag handles the remainder.
dutchCourage 7y ago
> Is using auto-formatting tools particularly widespread? Don't most people just format the code to their liking as they write it? Am I completely off base here? It's everywhere in the javascript world. I started using it a few years ago and would never go back. Having a consistent formatting when working with a team is great and it comes at basically no costs. And for the few exceptions where the auto-formatted code is harder to read, it can be disabled by a comment.

robomartin 7y ago

Well, when you have a Sawzall you pretty much let it drive...just pull the trigger and go. Half-joking, of course. Now, that might seem like an off-topic comment but, if you think about it, the analogy might be somewhat reasonable. BTW, I am NOT implying this is a bad thing. And yet I have to thrown in the "With great power comes great responsibility". I like intelligent tools that help me do my job. I don't care about things like --sorry-- the cult of vi/vim (text entry speed is irrelevant). My reality is that, as a multi-disciplinary engineer I find myself context switching all the time, from mechanical engineering, to optics, electronics, embedded, FPGA's, workstation, mobile and even web. When you context-switch like that the tools can really help you make the switch with less friction. So, yes, when you are changing languages and frameworks with some frequency rather than working in the same ecosystem for years, things like intelligent completion and suggestion, intelligent awareness of libraries and frameworks and a few other features can be massively helpful. This, BTW, is why I like the Jetbrains tools, not only are they excellent and well done, they help with all sorts of intelligence and integrations. But, yes, if you don't know what you are doing a Sawzall can cut off your leg.

musingsole 7y ago
>text entry speed is irrelevant Tools help you think in units of your usage of them. If you produce more words in a given amount of time with one editor over another, then the faster editor will enable you to begin thinking/planning in bigger blocks of a text at a time. Arguably though, vim's strength isn't text entry speed alone but faster abstract manipulation of text. Use a tool long enough, and it's best use cases become the default cases you lean towards when planning your next move.
- robomartin 7y ago
  Nope. Text entry facilitation is useful but irrelevant. Go work on code for an MRI machine, a spacecraft or an implantable insulin pump (all of which I have worked on) and see just how much you care about how quickly you can enter text or manipulate it. The answer: It is absolutely irrelevant. You will spend 10x, 100x, 1,000x longer doing other things that are actually important. I said this in another comment: Real software development is not assembly line work. It isn't mass data entry. Because of that text entry speed and efficiency is immaterial. It can feel good to have auto-completion and such tools, but, at the end of the day, it doesn't produce better code with less bugs any faster than any other approach. If text entry speed were important I would still be using APL (which I used professionally for ten years). In one line of code you can write what would require tens to hundreds of lines with other languages. If this were the case everyone would be using APL, because, if you want to compute at the speed of thought you need that kind of an approach. Reality, on the other hand, is that solving problems computationally is far more than text entry. A simple thought exercise would be to take three teams solving the same real problem. For example, writing the code to run an implantable insulin pump. One team uses vi/vim. The other uses Notepad++. The third uses a modern IDE. Which team will deliver a fully-functional, safe, bug-free product that will pass all necessary tests and ship to customers without killing them? Which one will do so faster? The answer is: The editor/IDE choice has nothing to do with both of these questions. And, in fact, when things really matter, you care far more about good bug-free code than how fast you wrote it. Banking or spacecraft are other examples of this. It's OK to use whatever tools make one happy, no issues there. Just don't lie to yourself about what they are and what they are not. Another view: I would not hire anyone who insists on using vi/vim. I don't deliver code-writing athletic performance. I deliver hardware+software products that have to work correctly and, ideally, not kill anyone. Coming in with a misplaced religious view about code entry means the person has no clue about the reason we do what we do and what's important.

bediger4000 7y ago

I know this article relates to programming, not linguistics, but... I live near a street named "Elati". Humans pronounce that Uh-lah-tee, all 3 syllables nearly the same emphasis. Google maps calls it Ell-uh-tee, emphasis on the "Ell". How long before human language bends to the will of Google maps' pronunciation algorithm. I don't think this is good or bad, merely interesting, and I'd like to know the name linguists have for this phenomenon.

wccrawford 7y ago
I live near a few cities that are pronounced very differently by locals than by visitors. That hasn't convinced the locals to change their pronunciation yet, so I seriously doubt that Google will manage it, either. I think pretty much everyone has something that GPS pronounces incorrectly near them.
silicon2401 7y ago
The closest I can think of (not a linguist) is hypercorrection, which is essentially 'correcting' what's already correct, and ending up with something that wouldn't previously be considered correct. But language correctness is defined by speakers, so eventually hypercorrection could eventually become the new standard. https://en.wikipedia.org/wiki/Hypercorrection https://en.wikipedia.org/wiki/Hypercorrection
- caleb-allen 7y ago
  Is the use of the word "literally" an example of this?
  - silicon2401 7y ago
    I would say no. "Literally" has been used in a non-literal sense for centuries. https://www.etymonline.com/word/literally#etymonline_v_30161 https://www.etymonline.com/word/literally#etymonline_v_30161

pjc50 7y ago

Nah, I've seen people write things that horrible long before they had tools to deal with it. People used to write BASIC that looked like this: https://cdn.arstechnica.net/wp-content/uploads/2012/12/BASIC-code.jpg https://cdn.arstechnica.net/wp-content/uploads/2012/12/BASIC... Readability is nice, but it's a luxury, and a subjective one.

christiansakai 7y ago

Yes I noticed myself doing this and also my colleagues when I used IDE. Now I mostly use vim and I notice myself trying as best as I can to code so that I can understand it with plain text editor. And it shows. I personally keep using vim because of this reason.

thedirt0115 7y ago

"Can we explain the differences in identifier length preferences between language communities by pointing to the availability of reliable auto-complete in one and lack thereof in another?" I'd have to say "no" to this. What immediately jumped to mind was Java vs Go, where there seems to be a strong preference towards shorter identifiers in Go even though there has basically never been a time when Go did NOT have good autocomplete capabilities. One might argue that Go tends to have shorter identifiers because the authors of a lot of the earliest Go code came from a C background where there wasn't autocomplete. But nearly every language has reliable auto-complete these days, so I'm gonna stick with "no".

pixelrevision 7y ago

The example in the article certainly did not bend to the will of the “code review” tool. The issues had nothing to do with a linter, the author just never went back to consider if it was legible.

deleted 7y ago

[deleted]