Hacker News new | comments | show | ask | jobs | submit login
I want a text editor that is a pain in the ass (medium.com)
32 points by erikpukinskis 1626 days ago | hide | past | web | favorite | 42 comments



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.


I started with emacs in the mid 1980s and have never used any other editor unless I had no choice. Even when I've worked on ASP[.NET] projects I would still edit code in Emacs and use Visual Studio for builds, VSS integration, and managing the project metadata.

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.


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.


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.


Lol, I tried emacs for a couple of months but went back to vi.

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 the editor wars were between vi and Emacs"?

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?


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.


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.


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


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


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


I use emacs or sublime for java coding 90% of the time. Of course it is vital to have large screen real estate/extra monitors so I can keep the various docs open for reference. I prefer this approach because I learn more about the particular apis I'm using rather than just autocomplete and go.

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.


True. The need for a full IDE is probably not always necessary. The need for no more than a notepad.exe? Hell no.


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.


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.


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.


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 ?


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.


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.


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.


> 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 factoring is also ALMOST irrelevant if you are adhering to a good MVC or MVVM pattern.

There are levels of complexity where an MVC architecture isn't enough to make refactoring "almost" irrelevant, and you run into them pretty quickly.


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.


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.


> 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


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.


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.


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.


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


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.


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.


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.


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.


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


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


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


> implying that Vim is an IDE


It's certainly capable of being one.


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


This, a million times !




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: