

I want a text editor that is a pain in the ass - erikpukinskis
https://medium.com/p/a15593f2dcbf

======
Ensorceled
I started programming when 'ed' was the editor of choice, then vi (not vim or
even elvis, but plain old vi).

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.

~~~
patrickmay
I started programming when the editor wars were between vi and Emacs. Somehow
we've ended up on the same side.

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.

~~~
marcosdumay
I'm one of the people that thinks that IDEs are a language smell. And yeah,
boilerplate smells too.

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.

------
FreshCode
If you write bad code because your editor makes it easy for you to write code
fast, then it is not your editor that is at fault.

~~~
hohohmm
Can't agree more. I have yet seen a good programmer who complained about their
tool making them write fast. When you write shitty code you don't blame it on
the good IDE.

~~~
rpedroso
I don't buy the point about forcing programmers to refactor either. Vim gives
me access to commands that make text manipulation faster, which often means I
can refactor faster.

In fact, I'd say that a slower refactor process would almost certainly
discourage me from refactoring.

------
hohohmm
Try it on Java and say you still want a dumb editor. It's like saying you want
to do rocket science while doing all the math by hand. Why drive a car. Why
not walk to grocery so you could reflect carefully on what you want to buy and
feel your muscle twitching after carrying 30 pounds of grocery back. Tools are
there to help out with the labor and free up your mind for the more important.
There is nothing wrong with understanding all the details, but there is no
point repeating it all the time once you do.

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.

~~~
philwelch
> Try it on Java and say you still want a dumb editor. It's like saying you
> want to do rocket science while doing all the math by hand.

Whenever I try Java, I don't want a smarter editor. I want a smarter language.

~~~
wging
That's true of most people, but in some situations Java's unavoidable.

------
giberson
A good programmer will contribute to writing good code. A bad programmer will
not.

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.

------
mistercow
Programmers already have a ridiculous number of constraints to juggle. Every
constraint you add reduces your ability to optimize for the others.

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.

------
cmancini
Interesting points, but I'd argue my IDE should make refactoring so easy I do
it all the time. Since, I don't write perfect software the first time, I have
to iterate. That iterative process shouldn't be a punishment.

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.

------
n1ghtmare_
This is the most ridiculous post I've read in a while. It's written by someone
who's never used a proper IDE. The IDE makes you write bad code ? This must
have been written by someone who's a complete noob, honestly. What a rubbish.
"You should only be writing a couple of lines of code per day" ... Really ?

~~~
acuozzo
Well, you called him a noob, so I guess personal attacks are fair-play.

Let me guess: You're the kind of programmer who immediately invokes a debugger
when something unexpected happens.

~~~
n1ghtmare_
No I actually rely on my unit tests and very rarely I'm using the debugger
(which is awesome by the way). In my book any "programmer" who say's "You
shouldn't be writing more than a couple of lines of code a day" is a ... not
even noob, dunno what to call him. If your opinion is that IDE makes you a
shitty programmer than I honestly don't think you know what you're talking
about. Sorry.

------
mjn
I think one of the tensions underlying this article and responses is a quite
longstanding debate over the relative strengths of writing text and
interactive editing for specifying and editing computations. Smalltalk was
perhaps the first to take a strong position against writing text as the best
way to do things, and instead pushed for an interactive system that just
happened to have text as one component. A certain style of macro/DSL-oriented
Lisp is perhaps the other end of the spectrum, which aims at coming up with
expressive code interfaces to a problem (though there are also very
interactive approaches to developing Lisp, going all the way to the extreme of
image-based development where there actually is no easy way to recover the
running image's source code). The Lisp impulse (in one flavor of Lisp dev) is
to find a way to write a macro as a new interface to common patterns, while
the tool approach is to find a way to write refactoring/manipulation/codegen
interfaces to deal with common patterns.

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.

------
krenel
> Writing lots of code quickly is not a good thing. You shouldn’t be writing
> more than a few lines of code per day.

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

------
jplur
I like the point of this article, things that make me sigh while writing code
are often the things I need to learn to do a new way.

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.

------
matthewmacleod
I can't really agree with this. I get the point, obviously - sometimes, IDE or
text editor features end up curing the symptoms rather than the disease.
That's valid, insofar as it's probably a bad sign when a coder has to enter
loads of boilerplate, or struggles to remember the correct method to call from
a sprawling API.

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.

------
FrankenPC
I disagree with pretty much every assertion in this article's rant. Advanced
visual editors like Visual Studio make the syntax irrelevant and the
architecture easy to focus on. Now I can keep my brain focused on separation
of concerns with relative ease. Re factoring is also ALMOST irrelevant if you
are adhering to a good MVC or MVVM pattern. Granted, if you are a genuine
hacker and not interested in building mainstream web apps, then what the
author is saying may be true. I wouldn't know.

~~~
dragonwriter
> Advanced visual editors like Visual Studio make the syntax irrelevant and
> the architecture easy to focus on

I disagree. If they made the syntax irrelevant, there wouldn't be a need for
the source code window at all.

------
marcelocamanho
This is not wise in my opnion. You do not have to go to the other extreme
because some programmers do mistakes when using IDEs. What CAN be done is keep
improving IDEs and make the autocomplete features, for instance, smarter and
more interactive. One idea related to that, for example, that I've always had
in mind but was always lazy to implement is a smarter contextual Copy and
Paste feature (i.e. "hey, this variable is already in this context, do you
wanna rename this and declare another variable instead?" in a visual way).

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.

------
oh_sigh
Hilarious. I stopped taking this post seriously at "You shouldn't write more
than a few lines of code a day".

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.

------
freakpower
Maybe if our keyboards had sharp pins sticking out of the keys we'd refactor
earlier, too.

------
aneth4
If you write too much code because your editor makes it easy, you're a bad
programmer. Period.

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.

------
opminion
I can only agree with this, having spent my first 6 months of C#/.Net
programming with only a highlighting text editor and the command-line
compiler. And a browser window open to read the official .Net reference.

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.

------
dkarl
_I don’t want to be able to easily rename a hundred method calls, because why
the hell am I calling a method from a hundred different places?_

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.

------
thejacenxpress
While I understand where you are coming from, a pain in the ass text editor or
a built up IDE won't make a difference. Your IDE does not manipulate and
refactor your thought process in solving a problem. Good programmers know how
to solve problems efficiently regardless of how many keystrokes it takes.

------
gnuvince
He'll be happy with something like mg, acme or even sam.

~~~
catenate
Acme would give him an easy interface to sed/awk for search and replace, and
any command-line tools to refactor.

------
codex
If all of humanity thought this way we'd still living in log cabins, hewn by
hand, or worse

------
oddshocks
> implying that Vim is an IDE

~~~
cheald
It's certainly capable of being one.

------
Chanel_Bunnell
>Writing lots of code quickly is not a good thing. You shouldn’t be writing
more than a few lines of code per day. And if your editor is helping you write
a lot of code really quickly, it’s encouraging you to write bad code.

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.

~~~
n1ghtmare_
This, a million times !

