Why I Still Use Vim - <AUTHOR> https://medium.com/@caspervonb/why-i-still-use-vim-67afd76b4db6 <comment><USER4> These kinds of comparisons always seemed a bit silly to me.

It's like complaining that opening a 6MB file in windows took over 3GB on my system! (ignoring that most of that is the OS getting ready to do other things, and enabling the OS to do things other than opening and reading a 6MB file).

Yes, Atom isn't the most resource friendly editor out there, and nobody is claiming it is. But it is one of the more capable editors out there. That 1GB allows for things like easy theming, inline image viewing, styling/theming via CSS, plugins/extensions written in a web language (which many of it's target demographic use), complete freedom for plugins to do almost anything and everything, a full web browser for easily rendering markdown/websites-in- progress/documentation/etc, code linting, compiling, debugging, decompiling, etc...

Not to mention that a 6MB file is pretty fucking big for something like atom. Yes, I know, 6MB isn't "big", but for an editor which is designed to only work on source files which are AT MOST a MB, it's big.

If all you are going to do is open a 6MB file with none of that, then stop using it, and stop acting like it's bad software because it doesn't cater to your needs. Vim won't show me 4 panes with ES2016 in one, the compiled version in scrolling-lockstep with the ES2016 pane in the next, and a visual preview of the page as it currently is in the 3rd, and the documentation to a function i'm working on in the 4th. That still doesn't mean it's bad software, just that it's not a good fit when compared to the alternatives for me.

Stop complaining that the hammer is better than the screwdriver because it can hammer in nails better.

<comment><USER5> This is ridiculous. I just should not complain that some program is useless and terribly resource hungry? What will be next? "Stop complaining that the browser uses 10GB of ram to show a page, as it is bigger than standard page"? This is just ridiculous.

For showing the html I just use multiple browsers. My page must look good in multiple browsers, not in my editor. For the whole environment I just consoles with full logging, and running different parts. For database I have another specialized editor - much better than any IDE.

I have opened a couple javascript files in Atom. About 30, all quite short, about 50-100kB each. The total memory used by Atom was over 900MB.

Should I be just a brainless monkey, and be happy that it's fine? Well, my machine has lots of ram, but I need it to some other things as well.

For me Atom is just useless, I don't even get half of the functionality I get from Idea and it uses twice as memory just for beginning.

I think most of the comments to mine would be: just use the editor normally, no one is opening 20 files at the same time, just learn how to code, and have one small file opened.

So instead of learning some good tools, you just prefer sticking hardly to one regardless the pain. OK, good luck with that. I just need a fast editor with lots of functionality and great speed. Atom doesn't give me that.

<comment><USER4> You don't need to like Atom, but to claim it's a "bad editor" for everyone is silly.

You can use multiple browsers to preview, I prefer to have it in the editor which makes it easier to switch between (same argument for code tabs vs windows). I still test and work in multiple browsers to ensure compatibility, but being able to get the rough parts laid out in the editor itself and fix/develop on things that are the same in all browsers is a great productivity boon (especially when i'm working on my laptop with limited screen real estate).

And again, I could run everything in a separate console window, logging to files, etc... But having that in the browser is a boon to my productivity. Having notifications in the browser window that a test that was running in the background failed and being able to click a button and open right to the test file + source file that failed along with annotations about coverage data in the sidebar saves me quite a lot of time and effort.

If Atom is useless for you, don't use it! But don't act like it's garbage for everyone. I don't need a car that goes 200MPH but that doesn't mean every F1 car is entirely useless, just that it's designed for a different purpose.

I currently have 3 different atom windows open, each with 1-4 panes with probably 5-20 tabs open in each and it's using a whopping 1.8GB (super rough counting, didn't want to actually add it all up). That's a lot, but it's not enough to outweigh the benefits for me. I'm not "sticking hardly to one regardless the pain", i'm sticking to the one which makes me the most productive and is the "nicest" for me to use (if i'm frusturated by constantly finding windows, i'm not going to be a better developer) It might be too slow/bloated/whatever for you, and that's okay, but for me it's more than fine.

<comment><USER6> > I don't need a car that goes 200MPH but that doesn't mean every F1 car is > entirely useless, just that it's designed for a different purpose.

Those cars use huge resources for extreme performance. I don't think Atom provides extreme performance even after using extreme resources.

<comment><USER4> It depends on what you consider "performance".

An F1 car is going to be the worst tow truck in existence. It's "towing performance" is basically a 0/100.

Atom's "extreme performance" for me is in my productivity. the 2GB of ram that my atom windows are currently using is a very _very_ small price to pay for better productivity.

Even if Atom were so resource hungry that I needed to buy a new laptop every other year for $5000 (which I don't), if it makes me more than 2% more productive, it's paid for itself.

<comment><USER5> I think any discussion with you is pointless. You just love this editor, and whatever things you need to sacrifice to use it are file. This includes buying a new laptop each year, using only small files, buying more ram etc.

I'm just too old for flame wars with their-own-church believers. I just need to write code, so I switch tools to appropriate ones. It's just a tool. I'm sure that some hammer-loving guys do all things with hammers, even if that's terribly hard.

If you really think that Atom has "extreme performance", you really don't know other tools that are on the market.

Good luck, the hardware industry will love you even more.

<comment><USER4> I really feel I described why I think that pretty well.

If you are more productive doing things another way, that's fantastic! I use IDEA when i'm working in Java code, I use Atom when i'm working with web stuff, I use tail/grep when searching through log files, I use CLI tools as much as possible for everything else as they integrate with things like editors and IDE's very easily.

Everything is a tradeoff, and nothing is perfect. Atom enables me to be a better dev in some areas, and is frustratingly awful in others. But I do genuinely love the editor. I'm glad someone has finally made the tradeoffs that I prefer in an editor, as for me reducing memory usage by a few hundred MB will make literally 0 difference in my life, but adding the ability to click a spot in the embedded browser window and have it take me to the code that defines that component is a nice productivity boost.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> On a whim, and looking for a middle ground in native GUI editors, I fired up Textastic on my Mac (it's the most lightweight editor I have that does syntax highlighting and simple autocomplete), downloaded that text.xml file and opened it. Activity Monitor reported 29MB upon startup and 146MB RAM use with the file loaded, and moving to and from the end of the file is instantaneous (on a 7-year-old 2010 Mac Mini).

Startup time is 1 seconds without a file (from typing "tt" in a terminal) and 2 when doing "tt test.xml".

Search and replace for "thing" on every line was brutal, though. 5m32s, although I can't blame the editor - sampling the process, I see it doing a loop featuring CFStringCheckAndReplace, which is part of Core Foundation and likely not used to be subject to this kind of abuse - i.e., Textastic does not seem to use a custom internal buffer optimised for editing operations - <USER2> leverages what the OS already has.

vim on this Mac is about as fast as described in the article, which is also why I generally stick to it. :)

(edit: typos)

</comment><comment><USER8> Being in 2 slack teams use up as much memory as the entire visual studio 2017 does on my machine.

It is electron that is the root cause here and it is the same for all electron based apps.

<comment><USER9> Has anyone published a memory-map - a breakdown of what exactly is in the process' memory space - of these cases where Electron-based applications use orders-of-magnitude more memory than the native programs we used before?

Previously I've remarked that high memory usage in web-browsers in itself is not a cause for alarm, and is mostly a good thing because it means the browser is aggressively caching assets so future pageloads will be much faster without needing to load things from disk - however that doesn't apply to Electron- based software because all of the assets are local already so there's nothing to cache that won't be loaded into memory already. So - I'm willing to bet that Electron's high memory usage is probably the JavaScript part - because a native DOM itself, even with all layout information and source assets for images and backgrounds, cannot be more than a few megabytes for even a complicated page (memory usage only shoots up once you start having to download 20MB+ autoplaying video ads). Then multiply the usage overhead of the V8 engine multiple times for the fact that Electron uses V8 to run Node internally, and for each process instance it spawns in the name of reliability - these child processes shouldn't be necessary: "desktop software" shouldn't be running untrusted scripts downloaded from the Internet (WebViews notwithstanding - but they can be isolated already) so adequate testing (and good software design) will ensure a JavaScript snippet will not bring down a process. If they insist on spamming processes, what does that say about their confidence in their code-quality?

I'll join-in on the Slack-bashing. I know Slack is very capable and a breath of fresh air compared to Lync/Skype-for-Business, but right now it's consuming 755MB (70% private) between 6 slack.exe process instances on my machine - while the native Windows Telegram client (written in Qt) - with considerably more human-useful-data in-memory (over 200+ groups/channels/etc) is taking up a relatively miserly 133MB (85% private).

<comment> alex-e There's a new native desktop app for Slack, Skype, WhatsApp, etc:

[https://eul.im/slack](https://eul.im/slack)

It's only 4 MB and can handle tens of thousands of messages in one chat without lag.

<comment><USER8> I would use it but I am afraid that it might steal my accounts. I would feel safer paying for it and I would gladly do that.

Now, it just feels like the creator can simply steal my accounts without my knowledge. Windows 10 warns me about the app as well, perhaps because it is not from the Store?

I don't really care about size of the application, I just want it to not consume a crazy amount of memory.

<comment> alex-e You are right to be cautious.

Like the home page says, the binaries are not signed yet, that's why Windows is complaining. Documents are being verified right now, getting a code signing certificate is a slow process unfortunately.

There will be a paid option soon. The app sends nothing to the server, only error reports.

eul uses 5x less RAM on average.

</comment></comment></comment></comment></comment><comment><USER10> Most people in CA prefer to drive a car rather than ride a bike. Bikes use far fewer resources to accomplish the same thing as a car (go from point A to B), but most people like to have the option of turning on the AC, playing music, and all the other add-ons that a car can bring to the experience.

I personally choose to bike, but if I started making charts about the relative energy consumption of the two, I'd reach a similarly obvious conclusion. If I used those charts to convince people to start biking, I doubt I'd be very successful, since people usually have strong preferences to one over the other.

One difference in this analogy is that cars pollute, whereas I couldn't care less how much memory your computer is using because it has practically zero impact on the environment or anyone other than yourself.

<comment><USER11> This is an interesting analogy.

> Bikes use far fewer resources to accomplish the same thing

Bikes use a lot more time, which is a pretty important resource to most people. When I drive, that's usually why. So, are the additional features that Atom provides "driving saves significant time" variety or only "driving allows you to listen to the radio" variety? If the former, it might be worth the occasional freeze or slow down.

> If I used those charts to convince people to start biking, I doubt I'd be > very successful.

I think if people actually didn't know that cars used more resources, the charts could have an impact on behavior. The fact that it's obvious (especially financially) means people already carpool or even (in cities) don't own a car at all. I don't think it's as obvious to some people that not every editor uses this much RAM, and you don't need another laptop upgrade, you can just switch to another editor.

> I couldn't care less... because it has practically zero impact on the > environment or anyone other than yourself

I think you're right, but I'm not totally sure. If enough users refuse to use unreasonably resource-intensive software, then more effort will be spent on keeping most software efficient. We still seem to have plenty of options, but I'd rather try to convince others to use efficient software than eventually have to continually upgrade my hardware to keep up.

<comment><USER10> This is an interesting response!

For the first point, I'd say it's less about time as it is about ease-of-use. I still use Vim when I'm SSH'd somewhere or the common occasions where I just need to change one line of a file. The process of "vi", entering the editor, using the shortcuts to find, edit, replace, save the file is done before an editor even loads. Time is valuable and not using Vim in some situations is like choosing a hand saw over a power tool (my analogy game is on point today).

On the last one about encouraging less resource-intensive software, I completely agree with you, and think software has grown increasingly careless toward memory usage. Unfortunately I'd estimate that less than 10% of computer users have ever opened the Activity Monitor on their mac or know which particular app is slowing it down. For developers I'm sure that's closer to 100%, so tools like Xcode/Atom/Eclipse will have their usage scrutinized more, but I certainly haven't seen anything close to mass rejection over it - <USER3> accept the free benefits and pay for it with better hardware. I also think the benefits of the underlying Electron library being seamless across platforms, plus the added benefit of extensions being as easy to write as a webpage, makes it a good trade-off for memory.

I really don't mean to minimize or refute any point you just made, what you wrote makes a lot of sense and really got me thinking. Maybe car vs bike should be the analogy for a more convincing blog post ;)

</comment></comment></comment><comment><USER12> I really wish developers stop using the JS editors and switch to platform specific editors. It's 2017 and all platforms have great native text editors, like Notepad++, GEdit, and if you need cross-platform, Sublime text.

I don't see the point I using these electron based editors which waste tons of CPU cycles, and provide nothing of value.

<comment><USER13> Frankly, VS Code is WAY better in terms of plugin and configuration than any of the editors you mention.. from git integration, search, integrated terminal, integrated debugging with ui driven break points, etc, not even counting plugins. None of the editors you mention support those features.

It's not wasting CPU cycles, and frankly even if it is, it's better than wasting _my_ cycles having to switch between several terminal windows, apps, and file system browsers all because you don't think I shouldn't use an electron app.

<comment><USER14> Then try out the JetBrains IDEs, and report back. All the features, none of the slowdown.

I can't believe a Java IDE is actually faster than the new default editors.

<comment><USER15> The JetBrains IDEs are _far_ slower then VSCode. Granted they do more, but they're still slow. And this is on a top-of-the-line MBP.

<comment><USER14> I've ran the JetBrains IDEs on my thinkpad and desktop, and they're consistently faster than VSCode when you compare them 1:1 (as in, you have a language plugin for that language + refactoring + co in VSCode).

</comment></comment></comment></comment></comment><comment><USER16> I recall the Turbo Pascal text-mode IDE that left enough space to actually run the programs you were developing. The machines had 640KB RAM, and I think the IDE was using perhaps as much as 100KB.

I recall using fully-featured GUI IDEs like VB, VC++ etc on machines with whopping 64MB RAM, and having enough space left to actually run the programs you were developing.

I have a laptop now with 16GB RAM. The other day I tried to edit a large text log file in Atom and it ran out of memory. That was the first - and last - time I tried to use Atom. I went back to my fav editor, jEdit, which currently says in its tray that its using a whopping 28MB RAM. No idea what it can be doing to fill that up, as I have barely anything open. But still...

<comment><USER11> This is a strange story. Why did you download and install Atom and decide to test it for the first time on a large log file? Did you think that was what Atom would be good at?

<comment><USER16> It happened that I installed Atom to give it a try, and one of the first things I wanted to do was look at a log file that was several MB big. I have 16GB of RAM. I was not expecting any problems.

</comment></comment></comment><comment><USER17> The other takeaway from this is that if (like me) you prefer a GUI / X style editor, sublime text is a pretty good contender.

Personally, I really like Sublime, it was one of the best returns on investment for me (even buying it twice).

</comment><comment><USER18> I was intrigued by this article. So I tested it myself using VSCode 1.15.1 (x64), and a 6.16 MB (6 462 222 bytes) XML file. File opened in < 4 seconds. Uses about 180MB of memory. All 16013 lines show. Scrolling isn't an issue. Code folding isn't an issue. Memory usage dropped to 160MB, and then jumped to 330MB. Still high, but for me it works well and not a scenario I'd typically encounter.

</comment><comment><USER19> Title: "Why I Still Use Vim"

First Two Lines: "Vim is my default editor. There's no particular reason for this, except that I ended up learning it when I moved over to Linux many years ago. "

Well, that's that then.

</comment><comment><USER20> > I've primarily stuck with [vim] because it's an extensible editor that > doesn't hog all the resources and kill my machines.

Exactly, BUT ... Vim has a non-mainstream shortcut interface, which I've always thought is an unfortunate caveat. So over the years I've actually managed to massage Vim into behaving like a 'normal' editor. It fits into a plugin if you're interested: [https://github.com/tombh/novim- mode](https://github.com/tombh/novim-mode)

<comment><USER21> But then what's... the point? That vim has a rich and expressive language for text navigation and manipulation is the only thing that sets it apart from more modern competitors.

<comment><USER20> That was the part of the sentiment of the quote - the point is that Vim is notable for _2_ distinct, but unfortunately inseparable, reasons;

1\. Modal editing. 2\. One of the most ubiquitous, lightweight, stable and extensible editors in existence.

I just want there to be at least a semblance of a possibility to separate these 2 things.

<comment><USER22> Have you tried emacs?

<comment><USER20> Yes, but it doesn't exactly have 'conventional' shortcuts either, right? It's a little more heavyweight over Vim as well. So in the light-but-powerful editor universe, I think Vim just pips it to the post. Which is why I use it, albeit with 'normal' shortcuts.

<comment><USER22> Depends on what you mean by conventional. It's the default key binding style in most terminals.

</comment></comment></comment></comment></comment></comment><comment><USER23> I've tried Atom - quickly went back to Sublime from my speed tests. I had a similar speed issues with [https://hyper.is](https://hyper.is) vs iTerm. These new tools look pretty but performance matters, especially for your most-used tools.

<comment><USER13> I'm not much into Hyper, but the terminal library has had a lot of performance improvements... VS Code uses the same terminal emulation library for its' integrated terminal and it saw some huge gains the past couple months.

</comment></comment><comment><USER24> Little bit off topic but if you are afraid of opening large files on Mac OS, try Hex Fiend. It will open for example a 6GB database dump in mili-seconds (no joke) and it will let you search anything in it without you waiting.

I just tested the memory usage with that 6GB dump file and it only requires 21MB to open that file.

I discovered this program while checking who is behind my favorite shell (Fish Shell) :)

[http://ridiculousfish.com/](http://ridiculousfish.com/)

</comment><comment><USER25> How much of that is fixed cost? i.e. how much of that 1Gb is still consumed if you have no file (or a single empty file) open and how much is consumed when you open a second 6MB file?

<comment><USER26> It took 256 Meg to open a 60 byte file. So we can probably assume that is the floor.

<comment><USER27> Was it the first file open? Or the first of it's kind? I doubt atom will use 2.5 gb to open ten 60 byte files.

</comment></comment></comment><comment><USER28> I actually care more about power usage than anything else these days. If it takes 1GB of memory to do that then so be it; that's cool (literally)

/EDIT this comment refers to the general case not Atom in particular

<comment><USER29> Aren't Electron apps such as Atom known to have a significant impact on battery life/power usage?

</comment></comment><comment><USER30> I wonder if there is any possibility of using a newer iteration of Firefox with a configurable number of threads rather than Chrome as the engine for Electron (or something like it). In the browser at least this helps a lot to bring down memory consumption.

Electron does more than just about any other tool to enable building high quality cross platform apps. As someone who runs Linux on the desktop it's quite nice to be able to use the same apps as folks running Mac/Win. I just don't have any computers with less than 16 GB of memory :)

</comment><comment><USER31> What I take from this is to continue using Sublime...

</comment><comment><USER32> the hero image with vim meanings on keyboard keys is pretty and apropos. my eyes were drawn to it and I found a typo:

[pushes up glasses]

There aren't ex commands ":ZZ" / ":ZQ", but "ZZ" and "ZQ" are normal mode commands.

</comment><comment><USER33> A good thing to learn is gnu ed. You can navigate around, replace text, append, prepend and delete lines on a 1GB file using a few KB of memory.

<comment><USER34> It's the standard editor after all [https://www.gnu.org/fun/jokes/ed- msg.html](https://www.gnu.org/fun/jokes/ed-msg.html)

</comment></comment><comment><USER35> Not just that, for example GitKraken uses Electron, and consumes ~700MB RAM, compared to Smartgit that takes only 120MB on my machine.

</comment><comment><USER36> Even though a lot of people hate it, nano is a good editor as it has been stated in the stats. Maybe nano is a screwdriver what vim is a complete toolbox, and sublime a mechanical workshop (but paying a graphical requirement, like a rental fee)... Usually you only need to tighten a screw, other times fix a hose, others repair a car ;)

</comment><comment><USER37> > Code requires a whopping 349 megabytes in order to open a 60 byte file. Atom > comes in at 256 megabytes. Where Vim "only" needs 5 megabytes, which is > still kind of high, but representative of an average configuration

These numbers seem off. I just tested it and my VS Code uses 39MB of memory for loading a bunch of Python files and having a few plugins activated. Where are these numbers coming from? How was this test done?

I switched from Vim to Sublime a while ago. For me Sublime feels much faster and user friendly. I'm now trying VS Code for Python, Go and Clojure. I know is not as fast as Sublime or Vim but it's really user friendly and I'm impress of how quickly the developers have been able to provide awesome functionality into their editor. That for me sounds like a fair tradeoff given that computers these days have several Gigabytes of memory.

<comment><USER38> You need to be careful, because Code launches multiple subprocesses which you would all need to add up. I remember something around 250MB for basic file editing, which is fine for me.

</comment></comment><comment><USER39> I didn't realize why I hated some of the concepts behind vim until I saw a recent article that explained the creator of vi was using the older style keyboard with esc and control keys in more convenient places as well as arrow graphics where movement keys are in vi. I know I would have loved it back then but I also know that if it were created today decisions would be very different and could be better right from the start with out me having to mod the hell out of it. I'm not good at keeping config files for my personal setups from matchine to machine and I wipe operating systems and try new ones all the time, just doesn't click with me. I'm sure if I stuck with it and these things were second nature I would love it.

<comment><USER40> Yeah, vim with a standard querty layout is just painful. I have a few configs floating about that swap esc & tilde, turn caps into another control. Using Vim with anything else is a quick way to destroying my pinky.

A few years ago I started rebinding my window controls to be more Vim like (alt-j/k instead of cmd-tab and the like) and noticed less strain. Eventually installed Vimium in Chrome so I could browse using my keyboard and noticed similar reduction of strain. Did you know you can enable vi-editing in your shell with `set -o vi`? Oh god now I've installed Xmonad and the vi bindings are everywhere. Four shells on a desktop, devtools over there alt-HL for monitor control, flick the J to swap windows, build scripts singing along the bottom.

It's fucking horrible and I love it. Vim is love, Vim is life.

<comment><USER41> > Oh god now I've installed Xmonad and the vi bindings are everywhere

Tell me about it :|

</comment></comment></comment><comment><USER42> How much cpu and memory you can accept being used is depending on what you get for it. An IDE is always going to hog a lot more memory than an editor because typically they will keep hundreds of files in memory, do some kind of syntax analysis (and keep the results such as AST's in memory the whole time) to be able to provide symbol navigation and so on.

There is of course _wasted_ memory here in the case of electron, because while I'm happy for the editor to use memory for things I want (that will help me be more productive than in the plainest of editors) I'm not very happy to let an editor use hundreds of megs e.g. just for rendering text.

What is it in electron editors that takes so much memory, in the case of a simple file?

<comment><USER43> Storing hundreds of files in memory is absolutely not necessary. You can incrementally page files in and out, keeping the total size low. Anything that requires an entire file to be loaded instead of using some structure like an automatically-loaded/unloaded rope is asking to make an editor that crashes when you use it to read a log. Same for ASTs. If you're lazy, just allocate it in a memmap, but there are smarter ways to do it. There's a great series by a Google engineer about their project "Xi" [https://github.com/google/xi- editor/tree/master/doc/rope_sci...](https://github.com/google/xi- editor/tree/master/doc/rope_science)

<comment><USER42> > Storing hundreds of files in memory is absolutely not necessary. You can > incrementally page files in and out, keeping the total size low.

The metadata such as symbol lookup data for a project of say 10k source files is going to be larger than the source itself. The source might be 10-100mb but the data you need in memory in order to e.g. do error highlighting and symbol navigation without having to re-parse code is going to be a lot larger than that. And all of that is IN context, i.e. once you loaded 10k source files you could theoretically page out the text content of non-visible files, but all the metadata about symbols etc is still required to be in memory - the whole time.

Obviously if you view a huge file the actual _text_ content of the file is a memory concern in itself - and then you need a high perf data structure for the _text itself_. This is exactly why a text editor and an IDE are good for different things.

</comment></comment></comment><comment><USER44> I would love to use atom, but every time I install it, I find it slow and buggy (on my 6GB Linux machine). The code completion doesn't seem to work properly either, and that's the deal breaker. I reluctantly uninstall, and go back to eclipse or geany.

</comment><comment><USER45> (Meta comment on the dicussion here) I find it mind-boggling why so many people have such strong emotions about other people's preferences for things that don't affect them. While I have preferences for what editors I like to use, I don't understand why various strangers on the internet having different preferences would be so upsetting to people. Once you extend this to other areas of life, it becomes even more obviously silly; I personally find the smell and taste of bacon rather repugnant, but there are a lot of people who really enjoy it, and I don't feel the need to criticize them for it. Why should it be any different with text editors?

</comment><comment><USER46> Or use sublime text. Seems to fare well.

</comment><comment><USER47> Vim is the best brain-computer interface I've experienced. Once you have enough commands in muscle memory, you can think about what you want the text to do, and it happens. You can look at the screen, decide what you want to do, and then perform complex edits with your eyes closed. I would liken Vim's editing experience to doing kung fu in your head.

I tried Atom, but it does not have passable Vim emulation. Sublime's is passable, but many things are missing in comparison to Vim (or neovim).

</comment><comment><USER48> I gave up on Atom when I found MS Visual Code, for this very reason.

<comment><USER13> To be fair, up until the latest VS Code release, it didn't do very well with larger files either... much better since 1.15, but I rarely have to look at a file that big.

</comment></comment><comment><USER49> Something seems off, I just opened a 8.7MB file with Code and it still uses 264MB memory. (Win10)

"> Conclusion Learn Vim."

It's like saying "getting tired of long commuting?" Buy a Ferrari.

<comment><USER50> Except everyone can learn vim in a few days whereas not everyone can buy a Ferrari in a few days.

<comment><USER49> I've heard multiple people stating that it took months of using it (and configuring it) until they kinda get used to vim.

Not hard data, but interesting to read also: [https://www.reddit.com/r/programming/comments/66wnd/how_long...](https://www.reddit.com/r/programming/comments/66wnd/how_long_does_one_have_to_use_vim_until_you_feel/)

When it takes reading tutorials to set up mouse + clipboard support, then I feel it's just simply not for me.

It just irks me that someone finds editors bad that sacrifices resource handling in order to gain extreme flexibility and the he then concludes that the best thing to do is to learn something he spent probably a lots of time mastering. I skip tips from the ivory tower.

</comment></comment></comment><comment><USER51> One question bugs me: how the hell did _VSCode developers_ manage to get _so incredibly much better performance_ (both low memory usage and responsiveness), using such a similar technical platform (also Node/js/Electron)?!

There are _surely lots of tricks to be learned from such a comparison, so if someone would dissect and compare Atom vs VSCode I 'd even pay to read such an article!_

<comment><USER52> I believe there is a podcast that discussed this. Unfortunately I can't remember which,

Maybe one of these:

[https://programmingpodcasts.com/episode/net- rocks/building-v...](https://programmingpodcasts.com/episode/net- rocks/building-visual-studio-code-with-sean-mcbreen)

[https://programmingpodcasts.com/episode/javascript- jabber/24...](https://programmingpodcasts.com/episode/javascript- jabber/240-jsj-visual-studio-code-with-chris-dias)

[https://programmingpodcasts.com/episode/javascript- jabber/19...](https://programmingpodcasts.com/episode/javascript- jabber/199-jsj-visual-studio-code-with-chris-dias-and-erich-gamma)

[https://programmingpodcasts.com/episode/ms-dev- show/powershe...](https://programmingpodcasts.com/episode/ms-dev- show/powershell-in-vs-code-with-david-wilson)

[https://programmingpodcasts.com/episode/adventures-in- angula...](https://programmingpodcasts.com/episode/adventures-in- angular/044-aia-visual-studio-code-with-erich-gamma-and-chris-dias)

</comment></comment><comment><USER53> I'd highly recommend to use log scales for the graphs. It doesn't have the same shock impact but it transmit the information much better.

</comment><comment><USER54> How does this compare to other full(er) featured editors like IntelliJ? I don't remember it taking that much RAM, and it's a workhorse.

</comment><comment><USER55> It looks like Atom is at least moving in the right direction - I see 736MB RAM on OSX with that 6MB XML file open.

For me it's less the RAM usage and more latency that annoys me. Things like the way you can see the syntax highlighting being done down the screen in even small file, or the half second delay switching channels in Slack.

</comment><comment><USER56> I still can't for the life of me see why Electron was ever a good idea for apps like Atom. It's not like they haven't had to lean on native solutions before - they've already rewritten their JS based buffer in C++.

Is it really that hard to find people who can write native UIs these days?

</comment><comment><USER57> I like and use Atom, I started using it because I wanted a change from Sublime (not that there's anything wrong with Sublime). I have noticed though that it uses much more resources than Sublime so it drains my lap top battery faster and sometimes it feels slow.

</comment><comment><USER58> After using Atom on OS X and Windows for a long time, default installing it on every computer here at the company, I'm back to Notepad++ on Windows.

</comment><comment><USER59> Thank you for the insight. I use Code and Notepad++, these analysis allow to predict which one I should use based on size as the factor.

</comment><comment><USER60> I see large files as data to process instead of editing. Those sizes are unmanageable for editing. Doing an exceptional hack is fine, but normal workflow? If a file has more than 200 lines isn't time to think refactoring some component to aother file, and so on? Said that, I find Atom to be a good toot but also scandalous as pointed by the article. For me becomes a non-issue because I never find myself needing to edit such large files.

<comment><USER61> 200 lines? That's ridiculous. We have methods longer than 200 lines in our code. Splitting it into smaller methods would be a waste of time, and would make th code more complex. None of the logic is reusable, the intention is well documented and the code is all in one place, rather than having to jump around to 5 diffeeent files and step in to 1 line methods.

<comment><USER60> Why ridiculous? I have the outcome you mention and more or less that metric. I have many methods that are one liners. As secondary benefit, it makes the code extraordinarily testable, reusable and flexible. When you code what's the prevailing paradigm you're using?

</comment></comment></comment><comment><USER62> There should be a lot more focus on creating good multiplatform C++ GUI frameworks. Javascript is not the future.

</comment><comment><USER63> So in other words use Sublime, or Vim.

</comment><comment><USER64> Nothing new, right? A lot of Electron based apps use lots of memory.

</comment><comment><USER65> I just realized even Eclipse uses less memory than Atom.

</comment><comment><USER66> I use IntelliJ IDEA. Everything else is for kids.

</comment><comment><USER67> Time waste to read. Nonsense article comparing pears and apples and he is believing he knows everything. It is not worth to discuss it.

</comment><comment><USER68> Comparison with GNU Emacs seems not found. Or is it implicit that Eight Megabytes And Constantly Swapping?

</comment><comment><USER69> Is this Jonathan Blow?

</comment><comment><USER70> Trigger warning: the author is a Vim apologist/Emacs denier. /s

</comment><comment><USER71> These types of articles are little, if anything, more than pure fanboy-ism that is littered with hyperbolic claims.

I'm running a 2013 Macbook pro w/ 8 GB of RAM, the Intel Iris graphic card, sttached to two external, stacked Ultra wide HD monitors(sometimes a 3rd 1080p in portrait). The only "upgrade" it has received is an extra SSD installed after I removed the optical drive. You would be insulted if, as a dev, a company gave you this as a workstation in 2017.

Currently, I am running 8 electron apps(Slack, Discord, Headset, kiwi for Gmail, Insomnia as a GraphQL client, Visual Studio Code, Hyper as my terminal emulator, Spotify. When I feel like being unproductive, I open Pocket and push the total to 9) Bartender manages another dozen+ apps.

Oh, and I also have open Chrome, Chrome Canary, Firefox Nightly, and Opera Neon. Chrome is running with 60 or so enabled extensions, Firefox has another 15 active add ons. And between all the browsers, I usually have around 75 open tabs, 18 or so sre running video or some other resource intrnsive media.As well as the occasional Linux VM. Iused to run the McAfee Global Threat map animation as a live background, but that was a little too much. Depending on what Im working on, Im usually running at least 4 or 5 servers. none that have to deal with huge amoubts of data, as id usually just provision cloud resources for that.

Did I mention my 2013 8 GB MacBook handles this with ease? If I had a more powerful workstation, it would nit make me any more productive. I type at around 100-110 wpm and a more powerful machine wouldnt allow me to interface faster.

So, when ornery devs violate the DRY principle on every single HN thread that is tangentially related to electron and trash it with an exuberance that would make McCarthy proud, I wonder, why?

I imagine most have more powerful workstations than my own. I understand it from the perspective of those who have hundreds or thousands of tabs open (Around 30 or do open tabs causes cognitive overload for me and refuces productivity the more i have open.) I did have issues when running Atom and trying to open 30MB log and JSON files, but I wiuld also usually have 4 or more open projects. Ive since moved to VSCode after a year of apprehension due to having to give up ny many atom extensions, without looking back

It doesnt sound like the author is doing anything that complex. There is no way that it takes minutes to open a 6MB log file, especially if using the newer version of atom.

The idea that electron brings yoyr system to a crawl is simply not true, especially one app(unless its Atom).

Electron apps work. The performance benefits of native apps are negligible on my productivity . And, usually, their aesthetics are a hindrance as I like ny apps to be visually appealing. All the other cross-platform solutions almost always look like crap. But this is only important if one values those particular aesthetics of which i speak.

So, the attacks remind me of the discussion of artificial benchmarks comparing gpus or game consoles... immaterial and irrelevant to actual usage. Its an argument of pitentials and thereoticals never achieved. Especially for a freaking web developer.

Even if you disagree with me, these threads are trash because nothing new or original is said. Just the complaints about the "kids these days" from a small, but extremely vocal minority whose comments are in stark contrast to the threads overall karma.

Oh, and if If you're working out of emacs, electron apps are not for you.

</comment><comment><USER72> __grabs popcorn __

</comment><comment><USER73> We've updated the title from "Atom uses nearly 1GB of RAM to open a 6MB file" to that of the article. Submitters, please don't write your own titles.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment><comment><USER74> IntelliJ is just as heavy. Android studio is even heavier.

If Sublime had features on par with Code I would happily use it.

Though honestly I don't know much about Sublime. Can anyone comment on how it compares to Code?

</comment><comment><USER75> > Using Atom or Code I experience frequent freezes for several minutes when > just typing a single character.

Sounds like a Linux problem. VS Code works great for me on Windows and the Apple Macintosh OS.

</comment><comment><USER76> I use both vim and atom, but I can't imagine writing code all the time in vim.

</comment><comment><USER77> Blah blah this is ridiculous! Electron is horrible... blah blah... who cares? My macbook runs this fine and Atom is nice, blah blah, I switched to VS Code and its kinda nice, blah blah I tried this and went back to sublime... blah blah :q

<comment><USER22> People without copious amounts of memory?</comment></comment>


Too much information as an impediment for action - <AUTHOR> https://ovidem.com/blog/information-overload/ <comment><USER2> Completely unconstructive aside from selling a book on a known method of task management unrelated to the problem. Thinly veiled infomercial?

So what solution so you propose? Preferably one that does not suffer from limiting perspective like current media gatekeepers and social networks and search engines do? There are known traps in filtering.

<comment><USER3> I reduce information inputs and cognitive load because it helps me focus on things I find to be important.

Current things I do to relieve the stress of information overload: I do not use Facebook, Instagram, Snapchat, or Twitter and I only look at my ~10 subscribed subreddits, all of which are meme-free. I only have a Netflix subscription, which I use infrequently. I use a decoy email for all non- important things like receipts, mailing lists, etc., about which I receive no notifications. I pre-cook my meals whenever possible. I live in an apartment even though I can afford not to. I have one debit and one credit card through the same bank, and my wallet has only these cards, an ID and a transit pass. I exercise at a circuit training gym so I don't have to plan my workouts.

To some people this seems like ridiculous/overboard, but to me the opposite is true. I estimate that I have re-gained 3+ hours per day of high quality personal time by reducing my consumption and getting a job closer to my home. This has allowed me to do work I consider important such as volunteering and creating less superficial relationships. This doesn't even account for the stress relief that comes with not having constant FOMO and political malaise from social media or having to worry about house maintainence.

I still try to evaluate my life to see if I can further streamline unimportant nonsense, but I think I'm hitting a point of diminishing returns--if I removed more information inputs and responsibilities it would reduce the quality of my social life, enjoyment of hobbies, and/or personal growth. For instance, I would get rid of my car as I use it infrequently, but I feel that if I got rid of it I would become more of a burden on family and friends in my life, many of whom would need to be drive to me if we wanted to meet. Eventually I would like to start my own business, which will cause me to have to deal with a lot more of the types of things I avoid in my life, but I will be able to do it because of the singular focus I am afforded by not filling my brain with saccharine garbage.

People, myself included, get caught up wanting the best things, but we can get caught in thinking that having more good things is more good in itself, when probably the opposite is true. It is very similar to how the FDA, due to political reasons, will say things like "people should eat more vegetables", when in reality the advice should be "people should eat less overall".

</comment></comment><comment><USER4> This is part of the (recent-ish) history in psychology on the effects of choice. Maybe relevant: "When Choice is Demotivating".

[https://www.researchgate.net/profile/Mark_Lepper/publication...](https://www.researchgate.net/profile/Mark_Lepper/publication/12189991_When_Choice_is_Demotivating_Can_One_Desire_Too_Much_of_a_Good_Thing/links/56107d7d08ae6b29b49c75fa/When- Choice-is-Demotivating-Can-One-Desire-Too-Much-of-a-Good-Thing.pdf)</comment>


The unstoppable TI-84 Plus: An outdated calculator still holds a monopoly - <AUTHOR> http://www.washingtonpost.com/blogs/innovations/wp/2014/09/02/the-unstoppable-ti-84-plus-how-an-outdated-calculator-still-holds-a-monopoly-on-classrooms/?tid=sm_fb <comment><USER2> "We have to keep evolving on this platform, but it can't be innovation for the sake of innovation," said Peter Balyta, president of Texas Instruments' calculator division. "While it's tempting for us to build in WiFi, Bluetooth, audio, a camera, a whole bunch of things, we could do, but teachers don't want us to. And it's because we want to have a tool that kids can use in a classroom, on their way home, at home when they're doing homework and also a tool they can bring in during their most important exam."

What a bunch of crap. They could make it more powerful, less bulky, add rechargeable batteries, or drop the price. No one is asking for a camera or audio.

<comment><USER3> _> and also a tool they can bring in during their most important exam._

This is the most important part. Cheating is probably the primary reason these are used and not computers/smartphones etc. That is their niche. Test taking. With that, if you change the form factor etc, it becomes more difficult for test administers to recognize etc, and more power allows for programs that can be more "creative" and how they find answers to problems.

The tool is a perfect reflection of being built for a very particular market.

<comment><USER4> I use to write programs in HS for these things that helped me during math tests.

<comment><USER5> Chances are, if you were able to program the algorithms required to solve the problems, you understood them well enough or more than enough to pass the course.

<comment><USER6> Yes but you can copy a program more easily than you can "copy" the knowledge behind it.

What happens when one kid writes a quadratic solver and gives it to half the class?

</comment></comment></comment></comment></comment><comment><USER7> I still use my TI-83+ pretty often.

All the years of using it with physics homework and statistics homework and whatnot has wired its usage into my brain.

Sure, I could use R or Python, but when all I need to do is some simple math the calculator is always faster. It has tactile buttons I can operate with one hand, a clear readable screen, and a battery that lasts long. And it's simple.

If mine broke I'd buy another one.

</comment><comment><USER8> This is a repost (from 18 hours ago): [https://news.ycombinator.com/item?id=8260038](https://news.ycombinator.com/item?id=8260038)

</comment><comment><USER9> One thing that was the "killer app" for graphing calculators, at least through college in the last decade (even with wifi), was the fact that there were apps.

Graphing calculators were the first mass market mobile computers under $200 with what you could almost refer to as an app store, via ticalc.org (oh how many hours I spent on there). The interfaces had to be easy to use with low resolution screens and usually four directional buttons. Apps had to be about content. Games were pretty fun.

My TI-89 has survived 11 years. It's survived bike falls, being thrown across the room several times (when I was too quick to grab it and it went flying out of the cover). I use it infrequently but the batteries haven't been changed in over a year. I still have more screen real estate when I am typing on it than I do with my iPhone 5 (both in vertical and landscape). It has actual buttons and I have muscle memory so I don't even have to look at it when I type in numbers and symbols.

I have a periodic table app on my TI-89 that has been on there since 2003. The information someone in chemistry or physics needs is quicker to access than [http://www.ptable.com](http://www.ptable.com) or wikipedia. I'm sure there are apps on an iPod that are probably better now, but an iPod's batteries don't last months.

What could usurp it? Something in the same form factor that can last 48+ hours and take AA or AAA batteries. Something that provides temporary instructor override, allowing an instructor to enforce a policy temporarily (i.e. disable the CAS). Something that might integrate well with tools from TI that are out there. Something that's useful from middle school up to engineering/chemistry/physics.

Maybe something e-ink (and/or e-ink buttons), plastic, ARM or Atmel, Linux, python and some sort of CAS (Mathematica/Maple branded) by default, with an App store/ecosystem. Something $50-$75. WiFi only, but off by default. Something that probably looks a bit like a nokia n800 or blackberry. I think that would be reasonable.

</comment><comment><USER10> In high school I programmed a mini-RPG on a TI-85. It actually was quite a lot of fun (the programming, not so much the game). In our last year I think we could also buy either a TI-89 or TI-92 (which was quite the behemoth). In our school the math teachers were free to choose between TI and HP calculators, so we had some other classes / groups that had to calculate with reverse polish notation. At that time I laughed at this idea, thinking why would anyone choose this over infix notation. Then years later, after learning LISP and prefix notation, I laughed at my dumb younger self.

Incredible that TI still reigns supreme.

</comment><comment><USER11> I've got a TI 92+ which was, in my mind, the pinnacle of the calculator era. As I recall the 83 was Z80 based and the 92 was 68000 based, but what really made the 92 something I needed to keep was that it did pretty much everything Mathematica could do on a Sun-2 Workstation back in the day.

As far as disrupting goes, I use TyDig on my iPad as my most often used "calculator" these days. The 92 doesn't come out much. But for the market (high school) it is hard to beat the combination of features and cost that a calculator brings to the table.

</comment><comment><USER12> There are worse monopolies, I guess. The 83+/84+ has good software and is neigh indestructible. The physical interface is very good and beats a touch screen.

A TI calculator fast enough to run NumPy to build simulations and interactive gizmos would be super cool though. Allowing students to build colorful mathematical animations and physics simulations using simple building blocks would be awesome. Of course that can all be done with laptops but having things in the palm of your hand shouldn't be underestimated.

</comment><comment><USER13> I've owned 4 (!) different TI graphing calculators throughout the years. I believe it started with the TI-85 in the mid-90s, followed by the 86, then the 92, and finally culminating with the TI-89 in 1999. I don't think they've really surpassed the 89 in terms of functionality. I ended up selling the 92, as it was replaced with the functionally-equivalent 89 (in the familiar TI form-factor), and gave the 85 to my sister, so today all that remains is the 89 and the 86. I have fond memories of playing games and writing small programs on TI graphing calcs (ticalc.org still exists, apparently). At first only BASIC programs were supported, but then some folks figured out how to hack the 85 to run assembly, which continued on the other models. TI fought it at first, but later reluctantly supported assembly programs. Some enterprising hackers managed to implement rudimentary audio support via the data port, which I thought was quite impressive. The 84 Plus is essentially the old TI-82 platform iterated a number of times (TI-82, TI-83, 83 Plus, 83 Plus Silver, etc.)

I've been waiting for years for TI to make a graphing calc smartphone app, but with margins such as those described in the article, why would they? It'll likely take a major shift in the testing standards (i.e. allowing mobile devices) for this situation to change. Test proctors might have to become more vigilant, but I imagine if airplane mode was strictly enforced, then smartphones might be allowed. Seems that the communications features (which can facilitate cheating) are the primary concern.

</comment><comment><USER14> Relevant XCKD: [http://xkcd.com/768/](http://xkcd.com/768/)

If TI is such an incumbent, why haven't they been disrupted? Could someone come in and make a better calculator for a cheaper price (like Casio, in the article. Not sure if it's a better calculator though)?

The other problem is, even if they did, no one would buy it because it wouldn't be available for the SAT/ACT.

Edit: Casio in the article competes on price.

<comment><USER15> I don't think the problem is the SAT/ACT. That's a problem with cellphones, but lots of calculators are allowed on those tests, including the Casios[1]. The bigger challenge seems to be that teachers default to assigning TIs to their students.

[1] [http://sat.collegeboard.org/register/calculator- policy](http://sat.collegeboard.org/register/calculator-policy) Five different brands have at least 3 approved graphing calculators for the SATs.

<comment><USER16> This is it. In high school statistics, I tried to use my dad's HP-48g, which I dearly loved (in large part thanks to RPL---this was fairly soon after I discovered Scheme and dc). This didn't really work: the teacher would explain how to do something (automated statistical tests, for example) on a TI-89, and I'd have to spend a whole bunch of time trying to figure out the equivalent.

This was a pain, and it was compounded by the fact that the HP-48 didn't have the same features as the TI-89, so I was frequently out of luck. The teacher wrote his homeworks and tests with an eye towards what was doable without too much effort on a TI-89, and I imagine that the TI people chose the featureset for the 89 with an eye towards what people would want to do in high school classes, so using anything else was an uphill battle.

(We also had occasional homeworks in Excel, and I ran into the same trouble trying to do them in Perl. It didn't help that I was _very far_ from an expert in either Perl or the HP-48g.)

<comment><USER17> As a counterpoint, my HS classes used TI-81s, and I had bought a TI-85. Not all the things were in the same place, and so I often had to think of other ways of getting to the same place. At the time I thought it was a good thing, but I'm not sure if it was just that I was geeking out on the nicer hardware. ;)

</comment></comment></comment></comment><comment><USER18> From the article:

"Apple sells an iPod touch for $199 that comes with 16 gigabytes of memory"

I tend to let it slide when people get memory and storage confused, but I hold journalists to a higher standard. This isn't even a semantic error; this came right after describing the RAM capacity of a TI-84 Plus C Silver. Nothing Matt McFarland wrote in this article was _wrong_ , but it certainly wasn't highly- informed either...

Comparing TI calculators to consumer electronics is a rather moot point. It's better to compare against the plummeting costs of microcomputers in general. The Raspberry Pi is better proof that TI is marking their products up 1000%+! Nobody needs a calculator with a 1GHz processor and 512GB of RAM, and 8-128GB of flash storage, so why are we paying for even more than what that would cost?

<comment><USER19> > so why are we paying for even more than what that would cost?

Because TI has tried in the past to introduce more powerful calculators, and that fell flat.

The 84 exists because schools expect it. That is all. Until they accept your smartphone as a calculator, TI can markup the 84 as much as they want and everyone _has_ to buy it because there is no free market in school calculators.

</comment></comment><comment><USER20> Oh the one hand, TI calcs were a wonderful tool and toy for the yound math needs -- i lusted for the 81 and 85. Maybe the 84+ is perfect for its job. On the other hand, it must have less than $15 wholesale unit cost now, and has no right to enforce a proprietary OS/software lockdown.

<comment><USER21> well, since you can sideload apps onto the tiny rom... and there are romdumps available online as well as the official ROM from TI's website... presumably one could make their own ROM or tweak it... but... I don't see much of a market for that as it's main purpose is to calculate...

</comment></comment><comment><USER22> I have fond memories of the TI-89 - all the power of a TI-92, but the same form factor as the TI-83/84, so it wouldn't raise much attention.

Having a computer algebra system in my handheld calculator got me all the way from pre-algebra to intro diff eq in high school. It's hard to say whether it was unfair, but being able to try algebra and calculus things out on the CAS really helped me explore and understand concepts.

</comment><comment><USER23> Speaking of calculators, I have one of those HP stack-based (48 ?) things from 20+ years ago sitting around. Is there a market for those at all?

<comment><USER24> I have the HP-50g. Love that thing, though I don't get to use it much these days. I bought it for taking the tests in my intro physics course at uni, after my TI-89 got stolen by some doucherocket. My physics professor was a huge fan of the HP RPN calculators, and recommended them highly.

I was also notorious for bringing a slide rule into tests in case the batteries ran out on the calculator.

</comment></comment><comment><USER25> So in US teachers get to decide the calculator to use? That's crazy.

When I was in junior high (in France) it was about 50/50 between TI and Casio. In high school a few kids had an HP48. The rare time there was something specific to do with the calculator (eg. calculating sequences) the teacher would ask one geek from each camp to explain to the class how to do it with calculators of that brand.

<comment><USER26> Yes, its seen as vocational training. Rather than teaching trig or how to apply it or what it means, you get how to display sine waves on a specific TI model.

I'm old enough that my vocational training in high school math classes was on the venerable yet new at that time TI-81. That vocational training was not terribly useful in university classes, the rot had not reached that high (at that time)

</comment></comment><comment><USER27> Here's a link for anyone who wants a TI simulation on their phones: [https://play.google.com/store/apps/details?id=com.Revsoft.Wa...](https://play.google.com/store/apps/details?id=com.Revsoft.Wabbitemu&hl=en)

</comment><comment><USER28> >"While it's tempting for us to build in WiFi, Bluetooth, audio, a camera ... "

How about a bigger screen, more memory and a faster chip? I get that there still exists a calculator niche, but come on, it doesn't mean you just don't even try!

</comment><comment><USER29> The TI-83 is more in the textbook market than the electronics or calculator market. Once you realize this, the price doesn't seem so surprising. At least, it doesn't seem any more surprising than textbook prices.

</comment><comment><USER21> I still have mine from high school statistics class. The best part was being able to side-load apps and play that spaceship game (phoenix something?) in class while looking like you were mad calculating some P Value.

<comment><USER30> So much nostalgia around that game. If you didn't get the ultimate weapon by the time the fast moving circles came around you're basically screwed, and would need to restart. (since money drop was RNG).

I think that was actually the game that got me into programming, to figure out "how did they even do that." (and taught myself in isolation such terrible things as not understanding what a for loop was actually used for, and using it as a time delay loop.)

</comment></comment><comment><USER31> You'd be better with an Open Pandora running R to do any kind of Science work at school in a portable format. These calculators are completely ancient.

<comment><USER32> Things like Battery Life, use during exams and the keyboard/button layout might be an issue, though. That and the fact that most high-school classes probably use TI calculators rather than R.

<comment><USER31> I have a Pandora and I only need to charge it one a week or something, the battery lasts very long (even though I used it a couple of hours a day). So in the school context it would do just fine.

</comment></comment></comment><comment><USER33> I'm suprised how expensive Ti-89 Titanium was when I bought it compared to phones. Fucking TI.</comment>


Reverse Engineering for Beginners: Free book - <AUTHOR> http://beginners.re/ <comment><USER2> For understanding the stack frame layout on x86-64, I found this post to be quite useful:

[http://eli.thegreenplace.net/2011/09/06/stack-frame- layout-o...](http://eli.thegreenplace.net/2011/09/06/stack-frame-layout- on-x86-64/)

<comment><USER3> You can also take a look at one article from my company: "64-bit Microsoft Office Applications Do Not Like Stack Walking" [1]

[1] [http://blog.nektra.com/main/2014/04/23/64-bit-microsoft- offi...](http://blog.nektra.com/main/2014/04/23/64-bit-microsoft-office- applications-do-not-like-stack-walking/)

</comment></comment><comment><USER4> Reverse engineering has come up a few times in the past few months:

Automated reverse engineering (of DRM) - [https://news.ycombinator.com/item?id=7989490](https://news.ycombinator.com/item?id=7989490)

Open-source debugger for Windows - [https://news.ycombinator.com/item?id=8092273](https://news.ycombinator.com/item?id=8092273)

</comment><comment><USER5> After just visiting DEFCON and watching all the teams partake in CTF, this is what I want to learn. This is computing.

<comment><USER6> As a regular CTF competitor for over 4 years now, I cannot emphasize the value in simply playing CTFs if you really want to learn this stuff. So many people seem to think there's a secret manual laying around that teaches you all that is involved in going from a compiled binary to a shell. The referenced book should be used as a resource for when you come across a new topic and need some help. If you want to get started here are some useful links.

[http://smashthestack.org/](http://smashthestack.org/)

[https://ctftime.org/](https://ctftime.org/)

[http://overthewire.org/wargames/](http://overthewire.org/wargames/)

[http://repo.shell-storm.org/CTF/](http://repo.shell-storm.org/CTF/)

[https://github.com/ctfs/write-ups](https://github.com/ctfs/write-ups)

<comment><USER7> Sorry for the n00bish question, but I've never done any reversing. What does CTF stand for?

<comment><USER8> "Capture The Flag", typically the challenges will have a "flag" hidden somewhere that you have to locate.

<comment><USER7> Gotcha; that is what came to mind from playing FPS games, but figured it was probably something different in this context.

Thanks.

</comment></comment></comment></comment></comment><comment><USER9> Takes me back to high school. I used to sit in my room for hours working on keygennerators.

<comment><USER10> Same here. The good old days spent hanging in Fravia+, Woodmann and RETeam's forums..

</comment></comment><comment><USER11> I have been contemplating taking up coding in my spare time, especially after the post about turning the $200 Chromebook into an el cheapo learning machine. This could be the starting block I have been searching for.

<comment><USER12> Reverse engineering is probably _not_ the place to learn to code.

<comment><USER13> For high level languages, you are correct. However, lots of people learn assembly as they are learning to reverse engineer software.

That being said, I don't think the $200 Chromebook is going to cut it. Eventually he's going to want to run a Windows VM.

<comment><USER11> This is more of a knowledge expansion endeavor rather than career endeavor. Something to tinker with on the side was the appeal of the Ubuntu'd Chromebook in a threat here last week.

As far as learning and reversing goes, it has often been helpful to see how something is working while also attempting to make it work for me.

<comment><USER13> You should still be able to learn quite a bit with just the Chromebook. After reading the article, I'm thinking about getting one myself so I can get back into learning web development again.

Did you end up buying the Acer C720?

<comment><USER11> Not quite yet. I usually wait until the semester is in full swing before I make purchases. Both for time and money's sake.

That will be the one I more than likely go with. I was worried about 2GB of RAM coming from a Windows background, 2GB isnt anything. But apparently it runs fine in Ubuntu.

</comment></comment></comment></comment></comment></comment><comment><USER14> I remember how I spent a summer going through Lenas videos tutorials (look them up). They were really good and I learned a lot. Reverse engineering is an addictive thing.

</comment><comment><USER15> Is there a good reversing toolset for linux? For instance this book recommends a windows only tool called Ida.

<comment><USER16> It's not Windows only

[https://www.hex-rays.com/products/ida/debugger/index.shtml](https://www.hex- rays.com/products/ida/debugger/index.shtml)

it's still somewhat expensive though.

</comment></comment><comment><USER17> Does anyone know of a tool that can dump C++ vtables from 64 bit macho files?

<comment><USER18> You can try this [https://github.com/lvc/vtable- dumper](https://github.com/lvc/vtable-dumper) or even modify it for your needs</comment></comment>


New York City is flooding subway entrances to prepare for climate change - <AUTHOR> https://qz.com/1753814/nyc-is-flooding-subway-entrances-to-prepare-for-climate-change/ <comment><USER2> If climate change turns out to be a vast exaggeration, this period in history is going to look very silly.

<comment><USER3> I mean, that's how we felt about a coming nuclear apocalypse in the cold war era. What's your point?

<comment><USER4> The common refrain I've heard from these type of folks is "well we were going to have a global ice age because the ozone was 'being depleted'!"

Explaining to them that a concerted international effort is the only thing that prevented that gets laughed off.</comment></comment></comment>


Hugo and IPFS: how this blog works (and scales to serve 5k% spikes instantly) - <AUTHOR> https://withblue.ink/2019/03/20/hugo-and-ipfs-how-this-blog-works-and-scales.html <comment><USER2> The basis of this post isn't too sound:

* The "5k% spikes" being discussed here are on a tiny base load. His peak is 6K page views in a day. That's 4 pages a MINUTE. A raspberry pi could handle that. Anything can handle that. There's no load here.

* It's not clear what IPFS is getting him, but it's certainly not performance. Any performance improvements are coming from using the Cloudflare caching proxy, which is basically just using Cloudflare as a CDN. You can get that with a normal website behind Cloudflare with a lot less hassle.

It's fine to check out the implementation details for interest's sake, but let's just be clear that it all could have been done with a $5 VPS.

<comment><USER3> The question is, is CloudFlare caching IPFS or not?

If CloudFlare is running IPFS naked, then IPFS seems to be scaling.

If CloudFlare is caching IPFS, then it is CloudFlare saving their butts.

Can we confirm which it is?

I'm trying to chat with CloudFlare about my own P2P protocol, which I've seen handle HackerNoon's 15M monthly users (I saw about 10K concurrent users per second at peak load), to run GUN ( [https://github.com/amark/gun](https://github.com/amark/gun) ).

Because I do think it is important to test all these protocols out at bigger/larger scales, that certainly makes it easier to then debug and then fix problems (assuming CF isn't caching).

<comment><USER4> > If CloudFlare is running IPFS naked, then IPFS seems to be scaling.

> If CloudFlare is caching IPFS, then it is CloudFlare saving their butts.

They are caching IPFS for people who don't support IPFS. They are not caching IPFS for people who do support IPFS, and instead passing the user through to the IPFS servers.

Which means Cloudflare is indeed saving their butts, because as soon as IPFS has widespread support, this falls flat on its face. Same as traditional hosting would without a CDN. Their IPFS setup may be able to distribute the load enough to avoid an internet hug crippling it (that's part of IPFS's point), but this setup in no way demonstrates that.

</comment></comment></comment><comment><USER5> So the way I think of IPFS (disclosure: haven't deepdived) is something like the world we could have if we had a broadly supported CDN protocol for the Internet (this seems really overdue).

This very naturally answers the repeated questions from people about the why of IPFS.

Yes you COULD serve this via 1 or 5 of the other 20-30 incredibly individually complex stacks with CDN functionality as well. But why would you if there was a common CDN protocol?

What would the upsides be if your ISP could offer you an opt in localish IPFS instance?

IPFS is a functional expression of the long term academic research into creating an internet oriented around content blocks vs server socket oriented as it is today -

[https://en.wikipedia.org/wiki/Content_centric_networking](https://en.wikipedia.org/wiki/Content_centric_networking)

We, of course, need both so its not an either or.

We are backing our way into this world via javascript SRI -

[https://en.wikipedia.org/wiki/Subresource_Integrity](https://en.wikipedia.org/wiki/Subresource_Integrity)

Look at that, we need blocks of code that we know is what we want but we want flexibility in where it comes from.

<comment><USER6> I agree this is an interesting research area and it's likely to stay one for awhile until the underlying economic blockers are well solved: storage, bandwidth, and support all cost money.

If you host it yourself you have easy answers for that but if you're relying on generous strangers you are going to hit limits: how many people are going to mirror large amounts of content, deal with DMCA takedowns and other legal requirements, etc. before giving up? Performance could in theory be competitive but there's no guarantee and it's notoriously hard to deal with unreliable nodes — which again can be dealt with if you have skilled support staff available. You'll get some volunteers for the right cause but that only gets you so far – that's why there's a a couple decades of these projects dreaming big and failing once they get popular.

</comment></comment><comment><USER7> I've handled being Slashdotted back when being Slashdotted was still a thing.

Yeah, thanks, I'm ancient. Before I fart myself to sleep reminiscing the good old days, we got ~10k visits _in a hour_ , on a ASP.NET website (admittedly with good caching) but on the absolute dirt-cheapest of _shared_ hosting. It didn't skip a beat. I've done similar with PHP and Django. As long as you can avoid hitting the database every request, you can scale to the moon with very little work.

Hugo is static. Your toaster should be able to support 5k users.

</comment><comment><USER8> > one issue I've experienced with running an IPFS node is that it can use > quite a bit of bandwidth, just for making the network work (not even for > serving your content!). This has been greatly mitigated with IPFS 0.4.19, > but my Azure VMs are still measuring around 160GB/month of outbound traffic > (it was over 400 GB with IPFS 0.4.18).

I'm not sure if that's 160gb/vm or 160gb across all vms - but either way that's 10-30 usd/month in bandwidth?

Pretty steep compared to a (single) 5usd/month vm or free (free tier of cdn provider).

Interesing write-up, though. Nice to see cf support ipfs.

<comment><USER9> I wonder why EC2 bandwidth costs so much more than s3 bandwidth (and the same equivalent questions for Azure).

</comment></comment><comment><USER10> Good on the author for an excellent write-up but I really don't see the point of this except as a learning exercise.

Instead of running a single static server, they now have a cluster of three servers plus Cloudflare to serve up a few static files to a fairly small number of people. And even then they have problems with caching and IPFS- related bandwidth. And almost nobody actually accesses the site via IPFS, making the whole thing rather pointless.

</comment><comment><USER11> What proportion of the load was just Cloudflare CDN being a CDN and loading from cache?

This article seems to be mostly about the benefits of IPFS, but I can only see the benefits of Cloudflare caching. What am I missing?

</comment><comment><USER12> Where is the analysis on the percentage of traffic served via IPFS to back up any claims of the benefits of IPFS.

It appears to me that Cloudflare accepts IPFS as (another) source for it's CDN operations & any benefits of flat CPU utilization are likely from the CDN and not IPFS.

In fact, 3 VMs in 3 regions is complete overkill. If the traffic numbers are to be believed, one could simply post their Hugo site to GitHub Pages or Netlify with zero extra steps or dollars spent. No IPFS needed

</comment><comment><USER13> The stupid-simplest solution I ever saw for this was all the way back in the Slashdot era, where people would filter on refer headers and redirect all traffic from news sites to the Google cache version of their page.

That works great for static pages. Hugo and Jekyll are basically precompiling static pages.

For a more dynamic site? I know some people who do special handling for bot and spider traffic. The bots get not exactly static content but much less dynamic content. I could see rerouting all traffic, especially for everyone without session cookies, to that version during a big spike.

Those solutions behave a little bit like the eventual consistency you see on very large websites, where values are approximated or cached with a very short TTL.

As others have commented, the simplest way to get that on a small site is to pony up money for a CDN. Maybe not the cheapest, but certainly the simplest.

<comment><USER14> genius. why a focus on refer headers from news sites instead of using some content identifier to indicate whether to route to a more static or dynamic page?

</comment></comment><comment><USER15> Nice write up and includes a lot of links with technical details on how to deploy your own IPFS node(s).

I agree that the benefit of this implementation (3x IPFS + Cloudflare) over the dedicated VM/VPS might not be obvious for the amount of traffic/visits this specific blog is having, but it's a good alternative to know :-)

On a side note... Wouldn't it be great if OpenStreetMap/Google maps/your_favorite_map_provider was hosted on or via IPFS and there was an easy interface between the IPFS network and the www? This way the distribution of the tiles would be peerless, the CDN would be huge and each user would have locally the tiles most frequently used and serve them at the same time. No more dependency on big companies/providers, immune to DDoS/blocking/restrictions and free for all ;-)

</comment><comment><USER16> I really appreciate the work of getting this up and running; it's certainly a good exercise in making a fully-distributed content site.

What I'm missing is where a collection of static files couldn't just be served up from an S3 bucket and Cloudfront or Cloudflare on the front end -- you arguably have the same caching performance if not better since Amazon and Cloudflare have real SLAs for getting your bits from your bucket to a user's browser.

IPFS seems like un-needed complexity when there are a huge amount of options available. If you personally don't like Amazon, you can use Github pages, or DigitalOcean, or Netlify, or Fastly, or the list goes on and on.

Does anyone have a use for IPFS that isn't already covered by existing hosting+cdn options?

<comment><USER17> You can have both. Cloudflare has an IPFS gateway that you can use with a Cloudflare domain. Content hosted in IPFS and CDN-ed via Cloudflare's network. An IPFS-capable client will bypass Cloudflare via the dnslink entry.

See [https://developers.cloudflare.com/distributed-web/ipfs- gatew...](https://developers.cloudflare.com/distributed-web/ipfs- gateway/connecting-website/)

<comment><USER4> Except then you still have to cover the demand from requests which bypass Cloudflare through the dnslink entry.

Essentially it's a gimmicky system which is propped up by using Cloudflare, which ultimately fails once it actually gets user adoption, in a way the tradition setup (CDN + basic or even free hosting) would not. This only works because most users don't have IPFS support currently, and if they did the servers would grind to a halt just as they would with no CDN at all.

<comment><USER18> IIUC the theory is that the clients using native IPFS will be caching the content for a period of time and serving it to other IPFS clients. Therefore the load should be shared across viewers leading to a minimal increase on "origin" load.

<comment><USER4> Yes, theoretically that's the goal. Given they're showing 160GB of transfer on their servers, it doesn't seem like that's working particularly effectively. Regardless, this implementation does not demonstrate at all that IPFS would save a site from an internet hug -- just that Cloudflare can.

</comment></comment></comment></comment></comment><comment><USER19> I love Hugo and direction it has been heading and always appreciate notes about how easy it is to install and how fast it is (mainly because it is written in Go).

I have been struggling to get adoption with students working on web sites at the university I work at but when we get it up and working it is so great for 90% of the things we do.

</comment><comment><USER20> IPFS looks great, but the whole article smells like (not that)subtle Cloudflare advertising.</comment>


A Gentle Introduction to Algorithm Complexity Analysis (2012) - <AUTHOR> http://discrete.gr/complexity/

<comment><USER2> A handy tip to reverse engineer complexity from empirical examples is plot on a log-log plot and measure the gradient (if its a straight line). The gradient is the exponent, ie. O(n^gradient). Great if your algorithm is so complex you can't analyze it.

[http://www.dgp.toronto.edu/people/JamesStewart/378notes/05lo...](http://www.dgp.toronto.edu/people/JamesStewart/378notes/05logLog/)

<comment><USER3> Isn't this the same as the power law?

</comment></comment><comment><USER4> Very nice resource to have in mind. Thanks. I just started reading SICP. Decided to take a short detour to get a better grasp on all this complexity stuff that's hardly elaborated in SICP. Right now I am working through the chapter on Algorithm Efficiency Analysis in Discrete Math and Applications by Susanna Epp.

</comment><comment><USER5> Well, I appreciate that the article is easier to read than most textbooks on the subject. (But for as long as it is, it really is just an _introduction_ \- scrapes the surface.)

Also, what's up with the random pictures in the comments?

</comment><comment><USER6> Which problem is more important a) Make simple algorithms more accessible to the masses who do not get it even after reading a book. OR b) Make more complex algorithms and programming patters/styles more accessible to the good programmers who want to become excellent programmers ? I would like your opinion and how you define "importance" ( it could be market size, or economic impact in the world, or as some people have argued -- reduces gender inequality in tech)

</comment><comment><USER7> What's with the pics in the comments? I'm a bit confused. Is this something about that site?

<comment><USER8> FTA: Thanks for reading. I didn't get paid to write this article, so if you liked it, send me an e-mail to say hello. I enjoy receiving pictures of places around the world, so feel free to attach a picture of yourself in your city!</comment></comment>


Things you can't say in Silicon Valley (non-political version) - <AUTHOR> https://medium.com/@nimishgautam/things-you-cant-say-in-silicon-valley-non-political-version-174ea277736d <comment><USER2> "Let's think things through before we dive into coding."

"'Enterprise' and 'legacy' shouldn't be insults. Those are the systems that actually run our economy."

"Microsoft is more innovative than Apple."

</comment><comment><USER3> I find it so interesting how different "tech" companies and "industrial" companies are from each other (apparently engineers who work in the industry such as OEMs are not really "tech" from what I read in the media, _shrug_ ). I worked from startup (that was working on only hardware) to multi-billion "life-style" companies, and I never hangout with my coworkers after work, let alone beer-bashes. I have a coworker who won't even come to free Christmas lunches. It's just expected where we can talk and joke during work, but when it comes to personal time, its personal. Also as a MechE, people tend to listen to you more when you're more experienced (typically older), not the other way around. People I work with understand while dreams are important, it does not feed your family. I really want to get into the software side of things but the culture from what I read is almost repulsive...

<comment><USER2> Almost? ;) I think my Silicon Valley employer has a great culture in a lot of ways, but the whole "not just your employer but your whole world" attitude still bugs me. I also threw myself into work every waking moment when I was younger. I was also happy for my coworkers to be my primary social partners as well. Those were great years, but that kind of thing stops working once you have a family. Treating people with families as exceptions to the overall company culture - even if they're pretty well tolerated exceptions - is ageist and not OK.

<comment><USER3> I think the biggest reason for this is because Silicon Valley has an abundance of younger workers (relatively speaking). When you're young, you spend literally every moment working to strive for your ambitions. When I got older, I started to learn that every hour you spend at work is one less hour for you to spend on something meaningful to your personal life. At the end of the day, working long hours is just not worth it. There's literally nothing to show for it at the end of the day. You make less per hour. Your family hates you. And you have no personal life. The only people that really benefit from this mentality is the owners and investors and this is so unfair and toxic to the workers.

<comment><USER2> Agreed. To be fair, though, this is neither new nor limited to Silicon Valley. The most severe case of this attitude that I've encountered during my career was in Ann Arbor thirty years ago. Exploitation of young workers, both high- and low-skill, goes back much further than that. At least I didn't live in a literal company town, or work in a literal sweat shop.

</comment></comment></comment></comment><comment><USER4> Interestingly I agree with these sentences (sans not being 30 yet and not having kids and leaving at precisely 5:30)

I want to start a product because I think it'll be useful and I have bills to pay, I concern myself with user privacy first and foremost when designing and I don't want to fall into the trap of doing an "apple design". I don't want to scale either, I want to have a healthy and slow growth, maybe not even grow beyond a point. From a pure business standpoint these things are irrational (except paying bills) but personally I find them important.

<comment><USER5> > maybe not even grow beyond a point

Meaning you'd refuse access to your product to customers?

<comment><USER4> I don't really see the problem with that. It is not a requirement for a business to constantly grow or seek the maximum amount of customers. If I make some profit without growing, I'm satisfied, especially if my existing customers are satisfied.

(And there are many ways to control growth beyond just "refusing access")

<comment><USER5> What would you get from controlling growth? Existing customers more happy? Anything else? Just curious.

<comment><USER4> Less work, better customer relations, etc.

I personally believe that a small business is just better at making customers happy than a big business (atleast for a lot of things on the internet)

<comment><USER5> Less work is great.

</comment></comment></comment></comment></comment></comment><comment><USER6> "maybe having an entire c-suite with less than 10 employees is premature."

</comment><comment><USER7> Sorry, but it sounds like bunk - out of top 10, I've said most myself and heard others to say it. Well, except the beer bash thing, I must admit - though I have had coworkers that did not drink alcohol (and nobody resented them for that), I didn't really hear anyone claiming beer bash can't be fun. So I guess 1 out of 10 is kinda plausible?

</comment><comment><USER8> Ironically this is political as well just not civic political but office/work political instead (although really what's the difference if you think about it? Not much IMO). You can't have a "Things You Can't Say" that isn't political in one way or another. Man is a political animal.</comment>


Version your RESTful API responses - <AUTHOR> http://hribar.info/2012/09/version-your-api-responses/

<comment><USER2> The whole point of a REST API version bump is that it is an artifact of introducing necessary breaking changes (either removing an endpoint at X path, removing Y keys, or even serializing dates in Z format).

Though there have been many detractors, I still think URL based versioning is the best way to go. How do you version a header on a resource that goes away or pops into existence? What if I just ask for "application/json" or the "freshest" due to ignorance and you move the target and get even fresher? There is very little practical benefit to versioning in a HTTP header except some argument about URI purity.

<comment><USER3> If you're writing a client which is sensitive to the resource representation changing over time and you're using something that calls itself an API, hopefully one would skim the provided docs enough to see that you might want to explicitly state the version you want. Or notice that the Content-Type returned for the generic application/json query is a versioned type.

I acknowledge that it's a little more work than just banging out a versioned URI, but it's not that much work and I like the URI/conceptual purity.

<comment><USER4> > and I like the URI/conceptual purity.

This sums up pretty much the whole debate. Pragmatics vs idealists.

<comment><USER5> The interesting thing is that it is a false dichotomy - it's easy enough to implement both. Perhaps enhanced by adding a flag on the documentation to flip between pragmatist/idealist so each only sees their one way to do it right...

</comment></comment></comment></comment><comment><USER6> While this seems like a good solution, I'm not sure the problem is real: to me, a v1 API and a v2 API are two separate APIs, so the URLs for that API aren't really changing during it's lifetime (ie. the v1 stuff will stay the same for those continuing to use it). I think this is just a mis- interpretation of a core REST/web principle that the URIs for a specific resource in the API shouldn't change (hence creating a v2 or other sub- directory if you're going to change the output or functionality).

<comment><USER7> Ok, therefore:

      GET / HTTP/1.0
      GET / HTTP/1.1

should be

      GET /v1
      GET /v2

and YOU'd have to tell the browser which site uses which version.

Wouldn't it be nicer if the browser could tell the server which version of the interface it understands?

It happens that the metadatum follows the URI in HTTP requests. The author can't do that, but he can use a header field to achieve the same.

Hence the idea to use "Accept:" for versioning.

<comment><USER4> That's not the same layer. HTTP versioning is on the transport level.

All that the author is going to achieve is to have broken client codes every time he's going to bump his API version because most developers won't bother to check the content-type. Or he has control of both the client and server code and then in that case it doesn't matter.

<comment><USER7> N.B.: yes it's the same layer. HTTP is at the Application layer in the Internet layer model (and this is the Internet, not your school's Network class where they dream about OSI layers).

It's irrelevant which layer this is happening at. The point is that there is a resource address and a resource version. Decoupling those allows you to retain the same resource address for different resource versions - whether this is done for backwards compatibility, multi-language support or other reasons.

"All that the author is going to achieve is to have broken client codes every time he's going to bump his API version because most developers won't bother to check the content-type."

The point of the article was in fact to teach those mediocre developers who "won't bother", to actually bother to understand these concepts.

</comment></comment></comment></comment><comment><USER4> How often do you update the major version of your API ? Most of the time you can just augment your API with new end-points and keep the old paths around for backward-compatibility. When you're ready to change the major version you might as well start a new service from scratch with everything that you have learned.

Now that all your responses have a non IANA-approved[1] content-type, standard clients won't see it as JSON by default. Your curl requests are longer to type because you have to add this '-HAccept:application/vnd.something+json' string to your them. The reality is that bad developers will have broken clients when you update your API in any case.

I'm grateful that the REST movement brought attention to follow the HTTP protocol more closely but in practice, nobody writes truly RESTful clients. For that you would need to write a client that follows URLs passed in the body or in the headers. For example if you implement pagination, you're supposed to fetch page 1 and then follow the links until you're at the page you want. In reality you just make a page= attribute convention that avoids all these unnecessary round-trips.

[1]: <http://www.iana.org/assignments/media-types/index.html>

</comment><comment><USER8> I personally prefer this approach - certainly if the changes you're making are only to the representation of your resources, then (assuming they can't be made purely additively, i.e. without breaking existing clients) simply making a new content type available seems the natural way to go.

If it's of interest, I wrote a couple of articles about how we implemented exactly this sort of versioning in Rails for our app's API:

[http://techblog.tribesports.com/blog/2011/09/24/versioning-t...](http://techblog.tribesports.com/blog/2011/09/24/versioning- the-tribesports-api) [http://techblog.tribesports.com/blog/2011/09/24/separating-a...](http://techblog.tribesports.com/blog/2011/09/24/separating- api-logic-with-decorators)

I think these demonstrate the advantages of content negotiation as a versioning mechanism. To introduce a new API representation, we simply have to define a new set of decorators for our exposed resources, define a new MIME type and we're set. No monkeying with our routing, no messing around in controllers; a view-level change entails only view-level code alterations.

</comment><comment><USER9> I don't hate the idea or anything but I don't see what problem this solves in practice?

<comment><USER10> Agree ... normally the V2 API comes out with major revisions, such that it would not work with someone that coded up an app based on the V1 API. Using /v1/ and /v2/ allows customers to transition over some set amount of time. There is some value in keeping things simple for your end-users.

<comment><USER11> If the customers use 'Accept: application/vnd.example.v1+json' and 'Accept: application/vnd.example.v2+json' they can also transition over in the same manner.

</comment></comment></comment><comment><USER12> I like this idea a lot! I'm curious if anyone else finds major flaws in this idea but it seems to make a lot of sense to me. Yes, it may change slightly how you do your calls, but if the logic works and that's the "worse thing" that could come from this then I think it's worth implementing.

<comment><USER13> * You cannot test this from the browser.

* Many, many client developers will be confused by this approach. Also if they're using a shitty http library (often, yes) they'll hate you.

* What happens when someone sends an "Accept: application/json"? If you default to "send the latest" developers will fail to read your docs and get pissed when your next version breaks their code.

* His citation of Fielding's dissertation at best fails to support his claim and at worst is a misunderstanding of it. How is "put this in your accept header" any more of a uniform interface than "this thing goes in urls"? If you're doing HATEOAS[1] properly the answer is: "accept headers are _less_ general and thus worse". If you include api versions as a fundamental part of the notion of a resource they seem to become important enough to need top level (e.g. URI) support.

All in all this seems like a thinly veiled argument for URI purity for its own sake. API versions change the definitions of what a resource looks like _and_ what you can do with it. What more is there to a resource? What benefits, aside from sweeping the versioning mess under the header rug, does this provide?

[1] <http://en.wikipedia.org/wiki/HATEOAS>

<comment><USER14> URIs should be black boxes. My understanding is that the client should need no understanding _at all_ of their content.

<comment><USER13> I agree. This is only possible when all resource access flows from a predefined "root" resource via hyperlinks. If you're doing that, why force (arguably more difficult) accept header handling on your api clients? Then they have to set the accept header correctly at _every_ request instead of getting the version number right once when retrieving the root document. Beyond that debugging now requires access to / a record of the accept headers involved, and returning the latest version for plain application/json creates a _very_ nasty bug for clients.

I don't think REST meaningfully comes down on either side of this idea. I do think practicality sits highly in favor of versions in URIs.

<comment><USER3> Setting the same Accept header at every request is _not_ difficult or error- prone.

But that aside, what happens when you store versioned resource URLs in the client, and then you want to upgrade your client to a new version of the API? Do you just lose all of your data from the old version, since you don't have a single URL for a resource?

</comment></comment></comment></comment></comment><comment><USER15> With just a bit of forethought and a little planning, an API almost never really needs to be versioned in either way. One of the problems with versioning is that it almost encourages changing the API and most consumers are slow to update, if at all.</comment>