Live data from Hacker News

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

medium.com

11–20 of 44 posts

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

#11
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.

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

#12
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.

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

#13
>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.

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

#14
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 ?

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

#15
post #5

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.

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.

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.

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

#16
post #3

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…

> Try it on Java and say you still want a dumb editor or you don't want to program at all.

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.

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

#17

>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…

This, a million times !

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

#18

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 mainstr…

> 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.

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

#19
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.

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

#20

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 n…

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.

Post reply on HN