Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atom was archived today

github.com

Post reply on HN
Print view View original

321–330 of 614 posts

Re: Atom was archived today

#321

Post by ngoilapites »

esprehn wrote: post #32
p-e-w wrote: 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…

Slow means more than just lack of speed here, for the average folk it means tedious.

Re: Atom was archived today

#322

Post by oblio »

rahen wrote: post #231
p-e-w wrote: post #115

Earlier quoted context omitted.

Vim and Emacs cannot compare to VSCode when it comes to productivity. With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment for that language ready to go. This is light years ahead of the traditional editors, and saves many hours of time. Not to mention that VSCode has countless other productivity boosters built in which…

Reading such posts really makes me wonder how people wrote UNIX (up to V7) with just ed and an ASR33. And productive, they were. I've seen some old timers on ACME who dislike even the "distraction" of syntax coloring with modern editor such as vim. I wonder how they would fare with something like MS VSCode.

The complexity of any software system built in the 70s and 80s is laughably low compared to the biggest system we build today.

Their constraints were much harsher, but the fact of the matter is the end result was rather simple by today's standards.

I think just the Bluetooth stack in a modern OS contains as much code as an entire Unix kernel from any time up to 1990 or so.

Re: Atom was archived today

#323

Post by dw-im-here »

p-e-w wrote: post #75
esprehn wrote: post #32

Earlier quoted context omitted.

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…

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…

lol

lmao

Re: Atom was archived today

#324

Post by Beltalowda »

p-e-w wrote: post #115
JonathonW wrote: post #90

Earlier quoted context omitted.

"VSCode is the greatest productivity tool in the history of software engineering" in a world where vi and emacs exist seems like a bit of an exaggeration, and I'm not even a fan of either (VS Code is my daily driver; I like my GUI editors and I like them to behave like normal apps on the platform I'm running).

Vim and Emacs cannot compare to VSCode when it comes to productivity. With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment for that language ready to go. This is light years ahead of the traditional editors, and saves many hours of time. Not to mention that VSCode has countless other productivity boosters built in which…

That is kind of a bad example, because installing extensions is something you do rarely. Making that easy is nice, but not a huge productivity win.

I think Emacs also has a lot of stuff for extensions and such built-in, but I'm not too familiar with Emacs. With Vim it's a bit more manual, but really not all that much work. Basically search "Vim $my_language", usually click the first link, "git clone" in your ~/.vim/pack, and you're ready to do for most plugins, which will work out of the box. That you need to spend "hours" on this is just nonsense.

And the last time I tried VSCode with Go I had to spend some time fiddling around with things to make it work too.

What it comes down to is personal preference. Some people prefer A, others B. I strongly dislike VSCode's default settings and need to spend quite a bit of time fiddling with that too. But ... I don't pawn off my preferred way of doing things as somehow objectively superior to anyone else's. There's just one person why needs to use your editor: you. So ... whatever works for you, ya know. I can't believe it's 2022 and we're still doing this "editor war" bullshit.

Re: Atom was archived today

#326

Post by rahen »

Jorengarenar wrote: post #319
rahen wrote: post #231

Earlier quoted context omitted.

Reading such posts really makes me wonder how people wrote UNIX (up to V7) with just ed and an ASR33. And productive, they were. I've seen some old timers on ACME who dislike even the "distraction" of syntax coloring with modern editor such as vim. I wonder how they would fare with something like MS VSCode.

>the "distraction" of syntax coloring Also known as "spitzensparken blinkenlichten"

Liebe!

Re: Atom was archived today

#327

Post by Beltalowda »

brozaman wrote: post #300
constantcrying wrote: post #234

Earlier quoted context omitted.

>With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment Very minor feature. It is not usefull unless you are constantly hunting for new languages. >Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs. This i…

>>With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment > Very minor feature. It is not usefull unless you are constantly hunting for new languages. The big advantage isn't just installing but keeping them up to date without any actual effort. I used to know vimscript, used to understand how the vim package managers I us…

> I work mostly on golang, and now the environment is certainly more stable, but I remember that in order to have go extensions working on vim I used to have to be updating manually the extensions pretty much every release and it was some effort. Now I update the golang version and things just work.

Most of that is because the Go ecosystem moved ahead. Five years ago something like vim-go would depend on maybe 15 different binaries that operated on the source code. Automatically updating all of that is possible, but somewhat slow and tricky (especially because there were no modules yet, so had to "go get -u" all these different binaries to check for updates).

Now, it's basically just gopls. You don't even need vim-go any more; just Vim + $any_lsp + gopls gives a very similar experience.

Re: Atom was archived today

#328

Post by teddyh »

rodw wrote: post #255
constantcrying wrote: post #234

Earlier quoted context omitted.

>With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment Very minor feature. It is not usefull unless you are constantly hunting for new languages. >Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs. This i…

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

Re: Atom was archived today

#329

Post by mgaunard »

rtpg wrote: post #155
JonathonW wrote: post #90

Earlier quoted context omitted.

"VSCode is the greatest productivity tool in the history of software engineering" in a world where vi and emacs exist seems like a bit of an exaggeration, and I'm not even a fan of either (VS Code is my daily driver; I like my GUI editors and I like them to behave like normal apps on the platform I'm running).

Of course a lot goes on but pre-LSP and post-LSP are day and night. There is now a huge amount of serious language tooling that _isn't_ locked up into one or several editors. Now some might point out that LSP-based stuff is, like, bloat. Sure, OK. But there's a lot of motivation to do work that can pay off across the board. So much language stuff was based off of random regexes! It's hard to overstate how much better…

I don't know what LSP is or why you'd think it's anything special or game-changing.

It just seems to be a generic interface to describe language bindings, which most text editors have.

In practice it's mostly a bad thing because any advanced language has special needs which will end up difficult to address by funneling everything through a common interface.

Re: Atom was archived today

#330

Post by rahen »

oblio wrote: post #322
rahen wrote: post #231

Earlier quoted context omitted.

Reading such posts really makes me wonder how people wrote UNIX (up to V7) with just ed and an ASR33. And productive, they were. I've seen some old timers on ACME who dislike even the "distraction" of syntax coloring with modern editor such as vim. I wonder how they would fare with something like MS VSCode.

The complexity of any software system built in the 70s and 80s is laughably low compared to the biggest system we build today. Their constraints were much harsher, but the fact of the matter is the end result was rather simple by today's standards. I think just the Bluetooth stack in a modern OS contains as much code as an entire Unix kernel from any time up to 1990 or so.

Don't underestimate the complexity of software built in the seventies either for the business, financial or scientific world. We already had virtual machines, HA, realtime and distributed computing back then.

Some code running at CERN or NASA was far more complex than a bluetooth stack, yet was also written with teletypes or ADM-3A style terminals.

Post reply on HN