Josh Hawkins began coding at 9 years old, focusing on video games, but now focuses on full stack dev, compiler dev, and hacks away every day on countless open source projects related to the field.
Totally agree, the "fancy vim" setup I was referring to is when someone installs vim plugins or configures cscope to get back what they're missing from an IDE to bridge the gap between text editor and IDE, though maybe still lacking a debugger.
Overhead though, sure. I could see that, but I still don't see why that overhead is more deserved when running compiled languages.
Good code needs no colors.
Not to derail this (acme seems like a bold take at what you do best!), but I disagree. Syntax highlighting isn't to look pretty (though it can), but to point out typos and syntax errors before I sit down and run rake test or gcc. Fact is, we type the wrong thing or misunderstand computers once in a while, so syntax hints about it are handy for me, personally. So I like IDEs (or vim plugins if you prefer) for this!
Most studies find a weak but real effect. In other words, syntax highlighting doesn't help much, but it does help. The effect tends to get lessened the more experienced a programmer is. That said, as a pretty experienced programmer: I will take all the help I can get.
Josh Hawkins began coding at 9 years old, focusing on video games, but now focuses on full stack dev, compiler dev, and hacks away every day on countless open source projects related to the field.
That’s interesting, thanks! I would have thought a little more than a “weak” help as it helps you quickly recognize code blocks and find definitions and weed out comments without having to read the code and comprehend it.
Come to think of it, an eye-tracking study would be really neat to see on this...
So I like IDEs (or vim plugins if you prefer) for this
Indeed. Computers are inherently much better suited for this kind of thing. It's the same reason why we have statically typed languages (or in fact any language above byte code), unit tests, CI workflows, and at the end of the day computers themselves: human fallibility is best resolved by taking the human out of the equation, with the added benefit that said human can put their focus and energy to better use.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Totally agree, the "fancy vim" setup I was referring to is when someone installs vim plugins or configures cscope to get back what they're missing from an IDE to bridge the gap between text editor and IDE, though maybe still lacking a debugger.
Overhead though, sure. I could see that, but I still don't see why that overhead is more deserved when running compiled languages.
Not to derail this (acme seems like a bold take at what you do best!), but I disagree. Syntax highlighting isn't to look pretty (though it can), but to point out typos and syntax errors before I sit down and run
rake test
orgcc
. Fact is, we type the wrong thing or misunderstand computers once in a while, so syntax hints about it are handy for me, personally. So I like IDEs (or vim plugins if you prefer) for this!Fun fact! There is literally psychology research on whether syntax highlighting improves code comprehension. ppig.org/sites/default/files/2015-...
Most studies find a weak but real effect. In other words, syntax highlighting doesn't help much, but it does help. The effect tends to get lessened the more experienced a programmer is. That said, as a pretty experienced programmer: I will take all the help I can get.
That’s interesting, thanks! I would have thought a little more than a “weak” help as it helps you quickly recognize code blocks and find definitions and weed out comments without having to read the code and comprehend it.
Come to think of it, an eye-tracking study would be really neat to see on this...
Overhead should always be kept low.
Indeed. Computers are inherently much better suited for this kind of thing. It's the same reason why we have statically typed languages (or in fact any language above byte code), unit tests, CI workflows, and at the end of the day computers themselves: human fallibility is best resolved by taking the human out of the equation, with the added benefit that said human can put their focus and energy to better use.