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

191–200 of 614 posts

Re: Atom was archived today

#191

Post by Kwpolska »

IshKebab wrote: post #163
eyelidlessness wrote: post #125

Earlier quoted context omitted.

Sorry but the very good Electron app which actually is very good, VSCode, really does suck if you maintain 10 projects. That’s not a lot of projects. It’s just a lot of browser tabs multiplied by documentation in an actual browser.

I agree you have to keep the number of VSCode windows quite low (5 is ok, 10 will make it struggle) but in fairness how many times have you had 10 instances of Visual Studio or IntelliJ running? I've never got close to that.

Visual Studio (purple icon) can struggle with just one instance, especially if you're using ReSharper. As for the IntelliJ family, I've run Rider with about 10 projects a few times and it was fine (granted, those projects were small).

Re: Atom was archived today

#192

Post by adiabatty »

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've mostly switched over to VS Code from both vim and BBEdit, although I still use both somewhat regularly. It seems to me that VS Code is the 21st-century equivalent of Eight Megabytes And Constantly Swapping — that is, an editor that does a lot at the cost of quite a few CPU cycles and more than a bit of RAM.

While Emacs isn't quite as heavyweight as it was 25 years ago (hooray for Moore's Law), it still makes me grin to see Emacs fans sneer at the resource usage of a modern Electron-based editor.

Re: Atom was archived today

#193

Post by mosselman »

fastball wrote: post #109
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).

How many daily users do vim and emacs have? How many daily users does VSCode have?

How many people believed the earth was flat at one point?

To be clear, I don’t care either way about vim or vscode. I use vim mode in vscode right now, but I might use something else later. All I care about is being able to work pleasantly.

What I meant is that numbers of people doing something is not proof for something being better.

For instance: How many people listen to Justin Bieber and how many listen to The Doors?

Re: Atom was archived today

#194

Post by Existenceblinks »

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…

Typescript makes VSCode very slow though. I remember the feeling when switched from Atom to VSCode it's wicked fast. And then Typescript happens, my macbook's fan keeps spinning from time to time.

Re: Atom was archived today

#196

Post by jjav »

p-e-w wrote: post #143
kuratkull wrote: post #131

Earlier quoted context omitted.

If we're talking about professional tools i'm not sure if setting it up as fast as possible is the best productivity comparison. All good tools need getting to know them, and setting things up yourself (eg. in vim) means you also know how to fix any issues that pop up in the future. Installing a vscode plugin for playing around is great, but it doesn't automatically make you a professional and stable production envir…

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

> > All good tools need getting to know them

> Wrong. Good tools don't require that.

No, good tools absolutely require learning how to use them.

To think that they don't is a maddening take because it has led to the infantilization of applications in so many areas of the software world.

There is definitely a place for simplistic tools that have no customization, no configuration, a single limited way to do anything and no hooks/APIs to modify their internal behavior. Yes, such tools are easiest to pick up and casually use in the limited way they can be used and that's often all that is needed.

But, the world also need professional tools. In the non-software world this is obvious and such tools exist in every profession. Even your hammer example is wrong as the sibling post noted, there are "professional hammers" (nail guns) that require a bit more care to use but are much better.

There is a place for test lights (that anyone can touch to a wire to see if there's voltage). But we can also buy voltage meters of increasing complexity and capabilities. They start to require a little bit of understanding of volts and amps and ohms, but they are so much more useful. But yes you need to learn a little to use them. There are also things like oscilloscopes which an untrained person wouldn't stand a chance to know how to use at first sight. But of course they are vastly more useful once you learn the tool.

Just one random example of thousands. Yes, good tools absolutely require training.

Re: Atom was archived today

#197

Post by ilikehurdles »

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…

You’re definitely not coming in to this having much familiarity with the ecosystem of either other tool. Distributions like LunarVim, Spacemacs, and Doomemacs exist that fill that gap between the basic terminal editors and a ready-for-anything experience. Think, open a source file and get the language server auto detected and suggested for installation, right in vim.

Not to mention IntelliJ which I can’t help but keep coming back to after repeatedly getting frustrated enough trying to adopt VSCode. The git tooling in VSCode’s marketplace is a far cry from what’s available for some of these other tools. Fortunately for me, Fleet (new editor aimed at VSCode segment) is maturing at a rapid enough pace that I’ll likely be able to migrate to it in months/weeks and hopefully have a more zen experience.

Re: Atom was archived today

#198

Post by hnlmorg »

p-e-w wrote: post #143
kuratkull wrote: post #131

Earlier quoted context omitted.

If we're talking about professional tools i'm not sure if setting it up as fast as possible is the best productivity comparison. All good tools need getting to know them, and setting things up yourself (eg. in vim) means you also know how to fix any issues that pop up in the future. Installing a vscode plugin for playing around is great, but it doesn't automatically make you a professional and stable production envir…

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

I’ve seen so many people use a hammer wrong. They don’t swing it effectively, hold it too high on the handle, or even use the wrong type of hammer for the job (yes, there are different types of hammers designed for different types of hammering).

And that’s before you go into all the other technologies invented that are evolutions of the hammer, from nail guns to jackhammers.

Re: Atom was archived today

#199

Post by nocman »

p-e-w wrote: post #122
satvikpendem wrote: post #113

Earlier quoted context omitted.

They're all terminal apps so I'm not sure why platform conventions would matter. Sure some people use GUI wrappers but most people primarily use them in terminals which have the same conventions everywhere, generally speaking.

Platform conventions matter because uniformity matters. It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser. That is terrible usability, consumes brain cycles for no good reason, and is above all else completely unnecessary because modern alternatives exist that actually blend in with the system they're a part of.

> Platform conventions matter because uniformity matters.

There are tradeoffs to using software that has different shortcuts for similar things you might do in other software. Uniformity is nice, but I don't find it to be so essential that there is no room for any different ways of working.

> It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser.

I don't think they "just accept" it. In the case of emacs (and I believe vim also), you can enable a CUA mode if you wish, and have keybindings that are more like the system. However, in my experience, users of both of those text editors (and indeed, I use both) often choose to use the normal keybindings of those editors intentionally. In my opinion, it doesn't "consume brain cycles for no good reason". There are two very different approaches between those two editors, both are perfectly reasonable and valid. The fact that "modern alternatives exist..." is not necessarily relevant. People have been using both of those editors for years, and they are well versed in how they work and can be very efficient using them. Suggesting that they should just switch to a modern alternative makes some broad assumptions. 1) That they would be happier using some "modern alternative". 2) That whatever value they get from using those editors with different keybindings pales in comparison to what they would gain from switching to an editor with bindings more consistent with the system.

I don't believe you can assume either of those things for most of the people who choose to continue to use either of those editors after working in them for a significant amount of time.

Don't get me wrong, I understand your viewpoint. It's just that not everyone finds that uniformity to be as important as you do.

I also think it is important to point out that both vim and emacs are in active development, so it is not as if either of them has been "mothballed". So while their user interface conventions are very different from much "modern" software, it is not as if they are abandoned -- both are still being developed. They obviously both have significant value to a lot of people.

Re: Atom was archived today

#200

Post by Gud »

p-e-w wrote: post #143
kuratkull wrote: post #131

Earlier quoted context omitted.

If we're talking about professional tools i'm not sure if setting it up as fast as possible is the best productivity comparison. All good tools need getting to know them, and setting things up yourself (eg. in vim) means you also know how to fix any issues that pop up in the future. Installing a vscode plugin for playing around is great, but it doesn't automatically make you a professional and stable production envir…

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

This is completely wrong. Basic tools that solve basic tasks are easy to learn and understand.

I use spectrum analyzers to identify partial discharges in high voltage equipment. Sometimes I use a hammer. One of them require deep knowledge, with the other one I just give the equipment a whack with to see where the fault lies.

Post reply on HN