It did not work out the way the author thinks it would.
You don't refactor. Because refactoring is a pain in the ass with a terrible editor.
You use terrible variables like r, rr, a, t, ... because typing is a chore and typos are frustratingly hard to fix. With autocompletion those nice, descriptive variable names are just a few keystrokes.
The better my editor, the more likely I am to refactor. If my IDE allows me to update a method name everwhere at once, I'll update it as soon as the old name doesn't make sense.
Modern IDE's are a boon, but bad programmers are bad; blaming it on their editor doesn't make sense.
I can sympathize with some of the arguments the author makes. I don't like autocomplete or "IntelliSense" as I feel it's a crutch and if I rely on it I don't really learn the language syntax or libraries I'm working with.
I find that grep, awk/sed, and emacs functionality are adequate to refactor.
I would find an editor like Notepad way too limiting however... it just doesn't offer enough efficiencies in basic text editing. Though I have known good programmers who used it as their main editor.
Good programmers did, in fact, refactor even with simpler tools. They did use descriptive names. They wrote tight code because they were good programmers, not because they weren't perfectly capable of generating reams of boilerplate.
I'm seeing a lot of negative comments in this thread that miss the core points made in the blog post. Boilerplate is a code smell. The need for broad refactorings is another. Not being able to understand where methods are used is yet another. A good programmer will use tools that help him or her identify and fix those issues. IDEs allow bad programmers to create the smells far too easily.
But keeping the language constant, I agree with the GP. Yeah, good programmers refactor code on any environment (grep is great), but when it's easier, a good coder has more time to think about what he's writing, instead of wondering if he let any instance of a variable pass with the wrong name.
I understand the broad strokes the author was applying, but it's missing the point. Modern IDE's make everybody more productive so bad programmers produce more bad code, but good programmers also produce more good code.
Overall, software quality is far better than it was 20 years ago and there is more of it.
When was this armistice signed? I am afraid to know the answer but I have to ask: Who do you think the belligerents are in the current editor war?
In fact, I'd say that a slower refactor process would almost certainly discourage me from refactoring.
Edit: That post also mentioned the fear of exploding complexity. The whole point of abstraction is to manage complexity. The fact that you have a function being called at a hundred places and you don't keep track of them all in your mind is not something to fear, if you do the abstraction right. The fact that the previous fact makes you feel unsettling, should make you feel doubly unsettling.
On the one hand, a smarter editor is a useful tool; on the other hand, if a language makes me feel like I need a smart editor, that means that it isn't clear and concise on its own, and even if the editor helps me find and write things, there's a lot of visual noise in the code itself that's preventing me from seeing things as easily as I want.
The language itself is both a part of the UI, and a part of the infrastructure on which additional programming UI can be built. As infrastructre, its good if it supports good additional tooling; as UI, its bad if it needs additional tooling.
If most of the interaction is through tooling because the base language is not human-usable enough to be the primary interaction mechanism for programmers, then the "source" language needs to be defined in terms of the pieces that programmers should primarily interact with and the other form should be an intermediate representation used internally by the toolchain but not normally exposed to the programmer.
Whenever I try Java, I don't want a smarter editor. I want a smarter language.
That said, I have occasionally needed an IDE for java projects but in hindsight that seems to be because those projects were so needlessly large and convoluted that it didn't make sense to try to understand to the entire project in my head. That sounds bad, but that's how I see it. Some projects aren't worth understanding fully, and a good IDE is required for them.
Long story short, I can see the need for a java ide sometimes, but I won't call it a necessity.
A good editor will help a programmer do what the are going to do already, quicker and more accurately. A bad editor will slow progress and amplify error.
If you think that you need a barrier to impede your ability to get things out of your head and into reality to prevent you from slipping out garbage then I think you are just a bad programmer.And not just because you cant pound out the correct solution on the first try but because you think you can if you just think about it long enough. Any writer will tell you the key to writing is just write. Get yiur ideas out and on to paper. Fix them later during editing and revisons. And coding is just like writing in that sense. Get your code into the editor then revise, improve and optimize. Most of all let your editor help you do these things.
Potentially, using a low-feature editor could arguably be like jogging with weights. It could teach you good habits that then make you more effective once you switch back to a powerful editor. But you don't bring your weights on race day.
Also I don't want to have to think about code formatting. It's a necessary piece of writing but it only gets in the way of logic flow.
Let me guess: You're the kind of programmer who immediately invokes a debugger when something unexpected happens.
I disagree. If they made the syntax irrelevant, there wouldn't be a need for the source code window at all.
There are levels of complexity where an MVC architecture isn't enough to make refactoring "almost" irrelevant, and you run into them pretty quickly.
But good coders solve these issues regardless of having tools that make them easier to ignore - and I don't think that making it more time-consuming to write code, for the 99% of the time I'm not doing that, is worthwhile.
I want to enter a few lines of messy code, and have my editor automatically format it; I want to be able to find all uses of a particular function across my codebase; I want my linter to pick up syntax errors or unidiomatic code before I get to the point of running it; I want to be able to autocomplete tokens; I want to easily select and move blocks of code without fiddling with a mouse. These are all features which make it easier to refactor, and not more difficult.
Perhaps this is more valid in the context of people using IDEs rather than text editors, and I'd argue that when working with a new stack it's always worth having a crack at using a text editor/command line environment over an IDE to get a better feel for the environment. Whatever works most effectively for you, at the end of the day.
Before I started using multiple cursors in sublime text, I would invent interesting function patterns to avoid having to copy paste sets of stuff in the editor.
Now I'll rely on my editor, because it's easier to write and easier to change in the future.
I guess whatever keeps me productive is what's important. It could be better patterns in my code, or it could be better tools to write it.
Some studies says that on average a programmer writes a few lines per day. So OK.
> And if your editor is helping you write a lot of code really quickly, it’s encouraging you to write bad code.
Are you implying that being able to write faster results in more code produced ergo lower quality code? Usually being able to write/refactor/replace/etc faster means you have less friction between the code and your thoughts. You can more easily express what you have in your mind, in the code.
> Why? Because it puts pressure on me to refactor.
Make a refactoring without the right tools can be counter productive. Try to refactor a 400 lines of code of Python with Notepad. You will only detect the errors on run time, I promise.
> I don’t want my editor to refactor my code.
As far as I know, you editor does NOT refactor you code. YOU are the one who does it. The editor is just a tool that allows you to do it without pain, preventing common errors and helping you to do your jobs, no the other way round.
And not just that. Any good editor should do syntax highlight for you (you are more productive, but this does not imply to write more code). And automatically indenting. And maybe balancing the braces. And a long etc.
The editor is a tool. Any professional should use the right tools for doing its job. Is your best tool a pain-in-the-ass editor and you can do a good refactor as fast as your team mates? Good for you! :D
Maybe some defenders of XML are one extreme in the tool-oriented direction; some explicitly argue that human-editable syntax doesn't matter, because concrete syntax is for machines, and how a human should input it is an interface-design question. I'm tempted to think some C++ advocates also have views along those lines.
Anyway I think a lot of these debates are about where exactly on that spectrum constitutes a sweet spot, so point to some fairly deep splits. I personally lean towards wanting expressive source code, and start getting suspicious when I'm shoveling around huge amounts of boilerplate with an IDE; I start thinking, why is this something I'm manipulating in an editor, rather than something that gets abstracted by a macro or language feature? But I still use a number of semi-automated things in vim, certainly the low-level stuff like variable-name completion and folding.
Let's be honest, who here never had a "copy'n paste" bug. I always kid around the office that developers should not have CTRL+V.
Also, one might argue that by his point of view you could just program in assembly, or in XKCD butterfly style.
I wonder what substantial project this person has worked on in the past, and if they kept metrics of how many lines of code they actually wrote day to day.
Now that I have been using Visual Studio with Resharper for much longer, I understand how unbelievable that setup was to those who followed the Visual Studio path. But if it were my own dime, and still constrained by having to use C#/.Net, I would go back to the text editor + command-line compiler.
Good programmers detest redundant code and seek to reduce it regardless.
Maybe this guy used too many code generators or something. Regardless he is way off.
Good editors make refactoring easy, which encourages refactoring. And what's wrong with calling a method from lots of places? That's what methods are for.
Good editors also reduce typos and cognitive load, both of which contribute to faster, higher quality development.
So if I don't have a tool that lets me rename a method everywhere it's called, then the guy who left the company two years ago won't have called it a hundred times from poorly-factored code? Sweet! I'll uninstall my IDE first thing Monday morning and let you know how it goes.
Here speaks a man who has never worked on a green field project, never built something from start to finish, never had to write more than a few lines of code a day.
How many programmers would it take to build a new version 1 product if they're all writing just a few lines of code a day? Would 10,000 do the trick, with six months to finish? There's a time to talk, discuss, prepare, plan, draw stuff on whiteboards, etc. And then there's the other time, when you sit down and build the product, which means writing all the code.
I'm not talking about an app that displays a random number, in which case, fire away with your few lines a day, and you'll be up and running in a few days. I'm talking about products with a capital P.
I'm starting the coding work on a new version of an existing product the week after next, and I'll be spending 15 solid 8 hour days writing code. I've made the plans, sat in the meetings, tossed more than half the features over board. And now comes the time to actually build it -- or at least, a first iteration of it before I get hit with user feedback.