Live data from Hacker News

Atom was archived today

github.com

361–370 of 614 posts

Re: Atom was archived today

#361

Earlier quoted context omitted.

> VSCode is one of the greatest pieces of engineering of our time. That must be one of the saddest things I read this month.

Yes, it’s not. It’s just free. What people mean when they say “I can’t believe how good this is” is: “I can’t believe how good this is for something I got for free” That’s not engineering excellence. It’s just engineering; being given away as a loss leader. Vscode is good and well maintained, but that’s because a lot of money is being spent making it so. Enjoy it; there’s no harm in taking money people are giving awa…

It's not like commercial alternatives are automatically better though, see Visual Studio (some aspects of VStudio are still better than VSCode, but VSCode has caught up fast, and as IDE for multi-language projects it is already better - the only important feature that's still inferior in VSCode compared to VStudio is the debugger integration).

If the current 'trajectories' remain roughly the same, VSCode will leave Visual Studio entirely in the dust in a couple of years.

Re: Atom was archived today

#362
post #328
post #255

Earlier quoted context omitted.

> Very minor feature. Moreover it is supported out-of-the-box in emacs: `M-x list-packages`. I think `:packadd` or something may be the equivalent for vim.

> Moreover it is supported out-of-the-box in emacs: `M-x list-packages`. Or just use the menu; click on "Options” → “Manage Emacs Packages”. No need to scare people with “M-x” weirdness right out of the gate when it isn’t necessary since the option is right there in the menu.

Menus? Clicking? That doesn't seem very emacs-y of you. M-x weirdness - up to and including the fact that it refers to a "Meta" key not found on modern keyboards - is exactly the kind of gatekeeping that allows me to feel superior for knowing how to exit emacs gracefully.

But seriously you raise a good point. The OS-native menus in aquaemacs and similar go a long way toward making emacs more accessible and explore-able.

No joke, it is legitimately hard for a newbie to figure out how to close emacs, which is pretty ridiculous. (It's `C-x C-c` btw, but I honestly don't know how a first-time user could figure that out on their own without a menu. You need to be _told_. It's absolutely crazy that you need to consult the manual to know how it exit the program.)

EDIT: It looks like this thread is too deep for me to post a genuine reply, but just to respond to the "it's just plain emacs too" comment. Good point, and I was aware of that but I didn't know what to call the plain-vanilla Windowed/GUI-enabled emacs. I guess it's just "emacs". I actually hesitated on naming aquaemacs for exactly this reason, which is why I hedged with "or similiar".

Re: Atom was archived today

#363
post #43

Tree-sitter[0] came out of Atom performance optimization, I think, and that's a legacy that will live on a long time. Atom was in my view the closest thing to emacs out there, and it's sad to see that sort of user-empowerment not live on. [0] https://tree-sitter.github.io/tree-sitter/

Lots of things came from Atom and it's development, so much I'd still consider it a success although the editor itself didn't live on. Tree-sitter, Electron, "text-editor as a browser app" all became popular ideas thanks to Atom. Is there more things coming from Atom that I'm missing?

Re: Atom was archived today

#364
post #7

Sad to see this go. I was an early adopter of Atom, and I wrote two extensions for it, one of which while it was still in beta. The Atom developers made some technology choices that in retrospect were ill-advised, CoffeeScript being the worst of them and splitting everything into dozens of packages a close second. They tried to backpedal on both of these later on, but by that time VSCode, with its far superior engine…

I also was an early tester (not adopter) of Atom and I kinda hated it right from the start, but it's been a while and I could never really put my finger on it. I think it always somehow felt sluggish (I'm talking trying out several builds over several months, not just a one-off). But I've also never warmed up to Sublime (which was fast but also felt off).

Interestingly the moment I tried out VS Code (many years later) I instantly liked it and have been using it sporadically ever since, and as people always liken the two, I am confused to this day why one felt wrong and one felt right.

Re: Atom was archived today

#365

Earlier quoted context omitted.

What’s preventing this from being done in VSCode? Other than it hasn’t yet? I don’t think it ticks every box for you, but have you tried Jupyter Notebooks in VSCode[0]? [0] https://code.visualstudio.com/docs/datascience/jupyter-noteb...

VSCode doesn't support an API to put outputs inline in the text editor. IIRC there have been longstanding feature requests for it but it would probably have a performance hit. The closest thing is having a separate output window on the right side

VSCode’s Jupyter Notebooks is slightly different from Hydrogen in that it’s basically a MarkDown document with executable code blocks (cells) in the text editor that show their output in the text editor.

Again, not exactly the same as Hydrogen but there’s definitely some overlap in use cases and VSCode’s Jupyter Notebooks is pretty good. You should give it a shot and see if it’s a viable replacement for what you were using Hydrogen for.

This showcases the UI a bit if I’m not being clear: https://code.visualstudio.com/learn/educators/notebooks

Re: Atom was archived today

#366
post #75

Earlier quoted context omitted.

VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn. VSCode did almost everything right: The choice of TypeScript as the base language (with wh…

VSCode is good but as someone who’s been writing software for nearly 40 years, I really feel you’ve over doing the compliments by a long long way. Compilers, operating systems, browser engines (unfortunately) and reverse engineering proprietary hardware/firmware are all significantly harder challenges than writing an IDE. in fact there have been excellent IDEs around for decades before VSCode came along. Yes the indu…

VSCode is good but as someone who’s been writing software for nearly 40 years, I really feel you’ve over doing the compliments by a long long way.

I agree.

Lots of people talk about how great VS Code is. But how many of them would sing that tune if they had to pay for it?

VS Code's killer feature isn't customization or extensibility. Clearly it isn't speed or stability. It's price.

Re: Atom was archived today

#367
post #32
post #7

Sad to see this go. I was an early adopter of Atom, and I wrote two extensions for it, one of which while it was still in beta. The Atom developers made some technology choices that in retrospect were ill-advised, CoffeeScript being the worst of them and splitting everything into dozens of packages a close second. They tried to backpedal on both of these later on, but by that time VSCode, with its far superior engine…

Atom predated the LSP and leaned heavily into customizations with all the plugins running inside the UI thread (more like a traditional web page and 3p scripts). At the time they viewed the extreme customization support as a feature, and there was a thriving ecosystem of folks making plugins. That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up…

> The interesting thing has always been that both were built on Electron.

Atom wasn't just "built on" Electron, they made Electron.

Electron was made from Atom, literally. Electron was originally called Atom Shell https://www.electronjs.org/blog/electron

Re: Atom was archived today

#368
post #7

Sad to see this go. I was an early adopter of Atom, and I wrote two extensions for it, one of which while it was still in beta. The Atom developers made some technology choices that in retrospect were ill-advised, CoffeeScript being the worst of them and splitting everything into dozens of packages a close second. They tried to backpedal on both of these later on, but by that time VSCode, with its far superior engine…

Don't be sad it's gone; be glad it happened.

Re: Atom was archived today

#369
post #143

Earlier quoted context omitted.

> All good tools need getting to know them Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival. Great tools are obvious in their base functionality and have optional additional layers that can be discovered…

>Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival. You mean like a nail gun? The kind that all professional roofers use?

Does one need to "get to know a nail gun first" to use it well?

Re: Atom was archived today

#370
post #297

Earlier quoted context omitted.

People started focussing on text editors again after Atom came out.

I'd credit Sublime Text with that.

I second that, Sublime raised the bar and set the new standard, the only advantage VScode now has over sublime is it's open source license.
Post reply on HN