Hacker News Reader

Comment by TheKarateKid | Hacker News Reader

Can someone please explain to me why $80 for Sublime Text is a good price for a text editor?

I'm not flaming, I genuinely want to know. I've tried Gedit, Atom, VS Code, Notepad++ and I fail to see what Sublime offers over those to justify the price.

View on HN

>I'm not flaming, I genuinely want to know. I've tried Gedit, Atom, VS Code, Notepad++ and I fail to see what Sublime offers over those to justify the price.

It's better than Gedit in every way, it's way faster and more lightweight than Atom and VS Code, and it has a far better plugin ecosystem and functionality than Notepad++.

I'd pay triple the price.

> it's way faster and more lightweight

Now you've got me wondering why editor speed is actually a thing.

It matters for huge files

So not source code, for the most part.

I don't use Sublime Text as an IDE (I have Intellij for that), mainly to edit scripts, large CSV files, as a scratchpad etc. but It's always open and increases my productivity a lot.

You mean why some editors are slow or why I care?

Not sure about the first.

I care about speed because I like to use "large" files. I prefer a few large files to many small files.

Slow software is frustrating. A text editor is a tool, it should help and not hinder.

There are a lot of factors that play into the speed (perceived and real) of an editor. Sublime is written in C, which is generally recognized as a performant language when used correctly. In contrast, Atom and VS Code are Electron[1] apps, which mean they have to deal with browser optimization. They both use a lot of tricks[2] to operate as quickly as they do. And in all editors, one bad extension can kill performance, from my recent experience Resharper in Visual Studio increases startup time by 3x.

An editor is not as simple as displaying lines of text a la Notepad, different editors optimize for different use cases.

1. https://electron.atom.io/

2. http://blog.atom.io/2017/06/22/a-new-approach-to-text-render...

Sublime Text is written is C++ FYI.

Having tried Atom, it's the main reason I stuck with Sublime. Somehow, even typing was slow in some larger files...

Try using something like xcode or a jetbrains IDE with a large codebase (for the record I like jetbrains software, but it can be slow comparatively).

edit: not sure I correctly understood the parent

The same reason its annoying when any other kind of program is slow, especially interactive ones.

I don't want to see freezes for 2-3 seconds for some GC run, I don't want the letters to appear several 100ms after I've typed, I don't want to wait minutes for it to parse a large-ish file or update the autocomplete suggestions.

https://pavelfatin.com/typing-with-pleasure/

Not only does the editor need to track project folders and open files, even something seemingly simple like syntax highlighting can be surprisingly complex[0]. The editor needs to be able to read your inputs (mouse and keyboard) and represent those changes onscreen just like every other piece of software. It needs to repaint the screen with your changes and, depending on the complexity of the editor, load and implement a host of features (auto-complete? bracket matching? code indentation? code standards a la pep8? updates to source control?), with every single keypress and ideally in a matter of milliseconds. All of that takes memory and different editors make different sacrifices.

Of course the extent to which this happens is the whole reason there are different editors. If all you want to do is write text with zero features, then speed isn't an issue at all and you can just write directly in your terminal to a single file with pico or something.

[0] https://code.visualstudio.com/blogs/2017/02/08/syntax-highli...

> even something seemingly simple like syntax highlighting can be surprisingly complex

I was troubleshooting something with a colleague who was using Atom, and every time he opened a new file, it'd take somewhere between 1 and 2 seconds before the syntax highlighting was applied. As someone who's in and out of files all day, that'd drive me bananas.

It's highly likely that OP simply stumbled upon it, or someone recommended it, and now he learned it and is used to it and knows how productive it can be.

Thing is, same is true for any other good IDE, of which there are plenty.

Personally, it always blows my mind that people don't use VIM :) if they actually spent 5-20hours learning VIM correctly they would not touch these inferior pretty looking UIs

Agree! I do almost everything in VIM for file-efficient languages and environments (NodeJS projects, Python projects, HTML, C++ ROS packages, most things that promote DRY coding, etc.)

For file-inefficient environments (e.g. Java/Android -- 79 files for a "hello world" Android app!) I have to grudgingly use an IDE because I have no idea how to update the 78 other manifest/gradle/workspace/resource/etc. files based on the 1 file I change and the IDE takes care of the magic, as much as I hate that way of working.

Whereas I view vim as simply a necessary evil and I mean "necessary" in the sense that I want to edit something over ssh.

Bret Viktor's oft-quoted "Inventing on Principle" talk touches on this subject where a lot of research has shown that bimodal editors are worse. While I can't argue for how true that statement is, it's certainly been my experience. I always find it jarring to think I'm in command mode but I'm actually in edit mode or vice versa. Any vim user has had the experience of pasting text in command mode. I just absolutely hate bimodal editors.

Additionally, staunch vim (and emacs) users I know seem to spend an inordinate amount of time screwing around with plugins to get some pale version of behaviour you get out the box on any halfway decent IDE or even text editor.

I feel the same way about learning yet another series of keyboard shortcuts for, say, tmux/screen.

You could argue the mouse is slower. I'm not sure if this actually holds up to empirical measurement (or at least not to the degree that's claimed) but the point is, the barrier for entry is so much lower. You can just click around and find things. If you find yourself doing something a lot, you can find out what the keyboard shortcut is.

Thus you don't need to spend 50 hours upfront on a GUI editor.

From the point of view of "onboarding" (aka barriers to entry), as you say, point-and-click is miles ahead of the unfriendly-at-first-glance Vim.

But I'd like to say that I cannot honestly recall an instance where I was in normal mode and ended up pasting something -- I assume you mean Ctrl-V-ing and having the paste interpreted as commands? -- once I got used to it after leaving Sublime Text, which I'd say took me a couple of weeks of hating myself. It's a matter of how much effort one thinks it makes sense to put into learning the editor, but IME there is a significant payoff, even if it is hard-won.

I'm not sure if it's harder for some people to internalize (which is by no means a value judgment; it's why Emacs/ST/Atom/whatever exist and are powerful) but once that is done, one never gets confused about what mode you're in simply because one is almost never in insert mode! "Probabilistically" speaking, you are in insert mode for 0 time. ;)

In any case, I don't hate non-bimodal editors, just hope that the subset of those using them who have not seen Vim for what it is yet do so quickly. (And, of course, there are those who are genuinely repulsed by modal editing, and that's fine!)

I can't speak to "inordinate amount of time screwing around with plugins": I have a plugin for each language I use, and perhaps four or five others. The rest of my init.vim (I use Neovim) is about ... 30 lines long? It's my experience that most (Neo)vi(m) users use little of the power of plain vi -- I know that because I myself was like that for almost three or four years after I started using Vim. (This is ignoring, e.g. large Java projects, where IDE-style code navigation is basically a requirement if you want to get anything done.) But there is definitely a culture where a customized-to-the-hilt editor is seen as something to be proud of, and why shouldn't it? It's what you "live in", isn't it? :)

You don't know the right vim / emacs users then :)

It's possible to go overkill with learning tons of unnecessary shortcuts, but in my opinion all you really need for tmux is attach, detach, split horizontal, split vertical, fullscreen.

5 shortcuts is a paltry investment for a pretty sweet gain.

And unlike an IDE, this can be readily available on any machine you SSH into. Which is also what makes VIM so handy.

The 'micro' text editor is a fantastic vim replacement for SSH editing. It's a text-ui like vim, but it has mouse support (for selecting text, etc), and keyboard shortcuts that match bio stands, ctrl-s for save, ctrl-q for quit, etc.

Worth noting, Vim has full mouse support for scrolling, selecting text, resizing windows, etc. in the terminal and when working over SSH.

> You could argue the mouse is slower. I'm not sure if this actually holds up to empirical measurement

It is slower, and does hold up to empirical measurement. Yes, if you want 'ease of onboarding', then vim is not for you. It's a powerful tool for professionals, and like a lot of such tools, it requires some training. No-one ever complains that Photoshop requires training, yet a brand new user to Photoshop is completely befuddled and it takes a long time before they're proficient.

I've owned Photoshop since it was distributed on diskettes and I'm still befuddled every time I need its impressive power. (I'm not a professional graphics/photography person so I use the program only a few times per year now.)

I think this is a really good analogy to using pro-level text editing tools (e.g. Emacs or Vi). A mouse is great for poking around menus and operating sliders in a new or unfamiliar program, but Emacs and especially Vim are so fast to use without a mouse that it pains me to watch other programmers editing while using one.

ST is a fine editor, and I use IntelliJ for Java, but I've already spent the time (years) learning Emacs. Is it worth it for me to start over? No. I use IntelliJ for Java programming, but I use only its basic Emacs keybindings and the mouse for everything else (befuddled like I am in Photoshop).

You can have your cake and eat it too.

There are some really great vim plugins for Sublime Text, including one that uses NeoVim. For me, Sublime Text is basically Vim with an nice UI and some IDE features built in. And Goto Anything. I wouldn't want to live without Goto Anything.

They're always inferior editing experiences, these vim bolt-on plugins. Missing key features like 'jk' mash escaping and other remapping support.

      { "keys": ["j", "k"],       "args": {"key": "<esc>"},    "context": [{ "key": "setting.actual_intercept", "operand": true }], "command": "actual_keypress" },

That, in your Sublime keymap, should map jk to escape if you're using the ActualVim plugin.

On the backend, it's using NeoVim... So it's literally just vim. You can even use vim plugins. There really shouldn't be any missing features.

Oh! Didn't know this. Thanks.

I don't want to put anyone off they're favourite editor but you can have all of that cake (well maybe not all the eye candy) in Vim/NeoVim.

e.g. Goto anything you can use the Ctrl-P plugin.

Counter-example: I used vim for years, then switched to Sublime.

I bought a license simply beacuse Sublime Text was the only editor that could open a wikipedia json data dump. I installed many editors before I more than willingly paid for Sublime.

For me, same thing: no other editor gives me the decent UI of a GUI-based editor, but with the speed of vim when working with large text files (e.g. 10MB+).

I will often use sed or other CLI tools to parse through giant files (1GB+), but sublime only takes a short bit to load in a pretty hefty file, or a do regex search across entire projects with multiple-GB of files, and it works natively on Mac and Windows, so even when I'm forced to work on something on my Windows 10 laptop, I can be productive.

Well worth whatever I paid for it 4 years ago.

It has almost all of the features of the Electron based editors (aka Atom) but with a C++ backend instead of HTML/JS toilet water. So you have all the customization you could ever want with the speed of low level code.

It's a dead simple editor, comparing to VIM or Emacs (both I used a lot). Everything behaves just as you would expect.

And it's fast, it's small, and it's got a lot of packages. What more do you want?

Terminal support? To be fair, sublime text is great and I use it sometimes, but if your job requires you to work over ssh then vim definitely beats all modern editors.

Yeah, I agree. That's when I use vim/emacs.

Speed and stability, search, command palette, file navigation, Goto.

And the excellent Python plugin API, which has made the plugin ecosystem so vibrant. Here's one I wrote, https://github.com/kylebebak/Requester, an HTTP client that goes toe to toe with Paw and Postman on features and outdoes them on usability.

I couldn't have have written something like this for any other editor, or any other platform.

I think it is in a similar situation as JavaScript. It is not strictly better than its competitors, but it still manages to attract an entire community of people[1] to contribute actively to the project and its popularity.

[1] https://packagecontrol.io/stats

Nothing is faster for me when opening gargantuan text files. It's never broken for me and never lagged either. I think that's pretty impressive, not to mention the customizability options.

Define gargantuan. I just opened a 900MB CSV and it choked part-way through and eventually opened after about a minute. Windows 10, 8GB RAM and running on an SSD.

Not to mention if you hit ctrl-f and search for something in the file. Another lock-up for a few minutes while it tries to figure out highlighting. This is something I've reported to them. I have never considered Sublime to be a good handler of large files.

> Windows

Same problem on my mac with 16GB RAM and also an SSD

Opened a 1GB text file on MacOS 15gb ram and SSD.

Agree, yet even SlickEdit - which costs several times more, is still running strong. I wonder what kind of audience pays for it.

The small things are really well done.

It's an organic, artisanal text editor lovingly hand-carved from gap-buffer wood by craftsmen from a remote Tibetan village. A steal at thrice the price!

Reply on news.ycombinator.com