I want a text editor that is a pain in the ass

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.