How much do we bend to the will of our tools?
thorstenball.com
thorstenball.com
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.
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".
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.
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.
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.
But better yet, if you will hire people based on their tools and not their skills, you might want to stay away from that department.
I don’t have a problem with someone using vi/vim so long as it isn’t a cult.
I don’t care about tools or how many ways someone can write code to identify a palindrome or generate Fibonacci. I care vastly more about how people think, how creative they are, their attention to detail, resiliency, philosophy when faced with failure, ability to learn, approach to facing areas where they might be weak, ability to communicate, organizational skills, honesty, humbleness and more.
Notice I could not care less about coding speed or someone being a code puzzle database or how quickly they can enter 300 lines if code. In the context of what real work is about these things are as irrelevant as what brand if shoes they wear.
As you say, the speed of keypressing is irrelevant when most of the real work is in staring at the screen and puzzling something out.
This project involved a large FPGA driven by an embedded processor talking to UI code running on a PC. Without getting into technical details I can't cover, things were not working correctly in one particular set of states.
I and others went through the relevant code with a microscope, even rewriting some of it out of paranoia. For months we could not figure out what was going on.
One glorious Sunday at 2 AM I found the problem. It was an error in calculating the coefficients for a poly-phase finite impulse response filter in the FPGA. The code was calculated in a monster Excel spreadsheet. The coefficients were copy-pasted into the embedded code. The embedded processor loaded them into the FPGA during operation. The thing didn't work.
The Excel calculation used the ROUND() function when it should have used ROUNDUP() in the math. An innocent mistake, likely the result of haste. It cost us SIX MONTHS. This incident, perhaps more than anything else, made me recoil at the idea that code entry speed is in any way relevant to the delivery of working bug-free product. It truly isn't. In fact, going fast can cost you dearly.
Engineering of good reliable products, whether software-only or multidisciplinary has nothing whatsoever to do with the ability to enter or edit text quickly or efficiently.
I am not sure they care --given what they wrote I don't think they do-- but it is very wrong for a respected entity like MIT to spread false information, as is the case with the nonsense they wrote in this CS course regarding vi/m. At the very least it betrays an utter lack of knowledge of history and, even worse, a fabrication of a preferred narrative and reality.
These editors did not come to exist for any reason other than we had crappy character-only screens, crappy keyboards, no GUI's and terminals that communicated with computers at 1200 BAUD. Package all of that together and the only thing that makes sense is something like vi. In that context vi made sense. In fact, it was necessary. Evolve all of that to modern hardware, UI's and performance and one would never author such a tool, not even close, in fact, one would be laughed out of the room --and rightly so.
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.
Readability is nice, but it's a luxury, and a subjective one.
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?
My time working in Go with its institutionalised gofmt was a blessing.
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.