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

461–470 of 614 posts

Re: Atom was archived today

#461

Post by donum »

Hendrikto wrote: post #360
gizzlon wrote: post #242

Earlier quoted context omitted.

Both Sublime Text and Merge are great and well worth the price for me :)

I do not really see the point of Sublime Merge. Tried it a few times, but it just seems unnecessary. Is it just for people who want to avoid the CLI?

I'm a heavy git user, but I've never used anything else except Sublime Merge.

Because of that, I am also comfortable now with the CLI: Sublime Merge uses git terminology and made me understand a lot of details about git that I can transfer to the CLI. Things like using stash, cherry picking, tagging or rebasing are all very easily doable in Sublime Merge and if you choose to use one of those features, you automatically get familar with the CLI commands you'd need to use. Brilliant.

I'm not familiar with the whole feature set of the CLI, but I'm not missing much during day-to-day work in Sublime Merge.

PS: Clearly when it comes to more specific issues to fix, there is still the option to use the CLI for that.

Re: Atom was archived today

#462

Post by kylebarron »

__ryan__ wrote: post #365
kylebarron wrote: post #58

Earlier quoted context omitted.

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…

That's exactly my complaint though. I don't want to work in a notebook frame of mind. I don't want to have to demarcate `#%%` every time I run code (especially because you'd need to scroll down to put another `#%%` where the code you're running should stop.)

As I noted in a sibling comment, I wrote a quick extension [0] that makes this easier by automatically inferring code blocks, but VSCode Jupyter is lacking in other ways: you can't have multiple Jupyter kernels running at the same time and it doesn't show you runtime completions in the editor (necessary for compiled packages without type support).

[0]: https://github.com/kylebarron/vscode-jupyter-python

Re: Atom was archived today

#463

Post by ameliaquining »

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

I dunno, I'm not convinced that a compiler or OS is a harder problem than an IDE. "Turns out humans are complicated and making computers do things they want is hard."[1] UX design is not only a whole complicated field in its own right, it imposes additional technical constraints that interlock with UX ones in complex ways. (E.g., VS Code's plugin API is architected the way it is partly to limit the ability of a plugin to accidentally add latency in the places that are most critical for usability, or otherwise undermine the editing experience.)

Obviously some compilers and OSes and IDEs are larger in scope than others, but all else being equal, if I had to pick one to write and it was really important to deliver something good, I'd rather do one of the former.

(This applies to any kind of GUI program that needs to be very feature-rich in order to meet the needs of power users, and where user productivity is at a premium because those users spend all their time in it. IDEs are just the subcategory of that that we as programmers most often use.)

[1] https://wiki.alopex.li/LetsBeRealAboutDependencies#yeah-but-...

Re: Atom was archived today

#464

Post by kylebarron »

satvikpendem wrote: post #123
kylebarron wrote: post #58

Earlier quoted context omitted.

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

Is that not what Jupyter notebook support is about? I can run something and see the output below the code.

But with Hydrogen you could do that in a regular Python script without needing to create a notebook or think in terms of cells. There's an example of this in the Hydrogen readme: https://github.com/nteract/hydrogen#hydrogen-

Re: Atom was archived today

#465

Post by pizza234 »

heather45879 wrote: post #411
hnlmorg wrote: post #189

Earlier quoted context omitted.

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…

Honestly I’m not a fan of VSCode as a user. It’s too generic and lacks identity (too powerful to edit simple configs); it auto-updates every time I start it; it’s too complicated to configure; JSON is ugly and it’s 2022, why not favor GUI configurations? If my goal is to program in language X then I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about. That being said,…

These seems impression by somebody who's not a VSC user at all. Specifically:

> it’s 2022, why not favor GUI configurations?

VSC provides, at all the (four) levels, both GUI and text-based configuration editing.

> JSON is ugly

You can't get any simpler than JSON. The VSC designers have actually been admirably pragmatic, and opted for JSON5-ish, which supports comments and terminal commas (in arrays).

> too powerful to edit simple configs

Editors are complex by nature; other editors are not different.

It is actually quite the opposite; one can edit a subset of options in the GUI, then observe the changed values only in the JSON editor.

> it auto-updates every time I start it

VSC updates once a month, plus once or twice for patch releases in-between. It auto-updates every time if one opens it two/three times per month.

Plugins do auto update, but one can disable this, if they want.

> I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about

There is no default configuration that satisfies all the users; this is not specific to VSC.

Actually, the extensions experience is probably the most polished out there, and this matters, because if one makes something easy to use, users will use that feature more.

Re: Atom was archived today

#466

Post by livarot »

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…

> Vim and Emacs cannot compare to VSCode when it comes to productivity.

That is true but not in the way you think ;)

Re: Atom was archived today

#467

Post by kylebarron »

taink wrote: post #301
kylebarron wrote: post #58

Earlier quoted context omitted.

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

I don't think it's an API problem, because Scala Worksheets work in VSCode[0] (and in most editors actually). [0] https://scalameta.org/metals/docs/editors/vscode/#worksheets

I think you're referring to the "inlay hint" API, which is different from being able to visualize any HTML in the current text editor, like Hydrogen is able to: https://cloud.githubusercontent.com/assets/13285808/20360886...

Re: Atom was archived today

#468

Post by topherPedersen »

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…

Are they killing off Atom because Microsoft bought GitHub and they already have VSCode?

Re: Atom was archived today

#469

Post by gregors »

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…

I remember when I couldn't fly across the country without running out of power due the terrible power usage of VSCode.

One such example was the cursor blinking causing hight cpu usage - https://github.com/Microsoft/vscode/issues/22900 I'm assuming they've fixed it?

Electron in general continues to be a bloated memory hog and inefficient. I think the real interesting thing is how good it is despite the runtimes/frameworks they are using, not because of them. It's more an example of there's no such thing as the "right tool".

Re: Atom was archived today

#470

Post by heather45879 »

kevinmchugh wrote: post #431
heather45879 wrote: post #411

Earlier quoted context omitted.

Honestly I’m not a fan of VSCode as a user. It’s too generic and lacks identity (too powerful to edit simple configs); it auto-updates every time I start it; it’s too complicated to configure; JSON is ugly and it’s 2022, why not favor GUI configurations? If my goal is to program in language X then I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about. That being said,…

> it’s too complicated to configure; JSON is ugly and it’s 2022, why not favor GUI configurations? GUIs can change layout and users have to spend time learning where things are. Someone who is using a text editor is probably comfortable editing text.

Well unfortunately that’s a typical assumption developers make. “It’s an editor, Bob! The users ought to know how to read JSON!” Well thought-out UIs actually help the user find things and they don’t need to change all the time.

Unfortunately, even though we engineer with code, reading long streams of text is actually a terrible user experience by itself.

Good user experience should hold the user’s hand through the process so they don’t need to sift through a haystack of configurations.

VS Code has the power of emacs and an autogenerating UI which maps to the configuration files. To me, that’s the easy way out—make the UI map one-to-one with the data underneath, obviating the burden of considering the UX of each configuration path, and missing out on the benefits of good UX.

Post reply on HN