[deleted]
Atom was archived today
211–220 of 614 posts
Re: Atom was archived today
#212Earlier 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…
An operating theatre is filled with tools that require decades to master and years to learn to use originally. Even if you forget the surgeon's skill there is still the likes of ECMO (run full time by a perfusionist), EMG/NCS (an electrophysiologist) or the old classic, an anaesthetic machine (anaesthetist). Many of the UIs on these are, to the outside eye, downright janky.
Re: Atom was archived today
#213Earlier 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 isn't the most complex of projects or most widespread etc. But from perspective of engineering a large project is about making 100s of small and large choices. In hindsight, lot of them are wrong. Take any software WinNT, Linux, Atom, IntelliJ, Adobe* you can now with all the extra information available today can find some decisions that were wrong.
With VSCode these wrong decisions are very few and minor compared to the brilliant choices made by the team. That's why it is right to cite it as an engineering excellence project.
Re: Atom was archived today
#214So sad :(
Re: Atom was archived today
#215Sad 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…
[deleted]
Re: Atom was archived today
#216Earlier 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.
For me you are 100% correct. In either vim or emacs I am at least 10 times more productive than I would ever be in VSCode. No comparison.
> 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.
First, there are distributions of both vim and emacs that come bundled with sets of plugins, if that is the sort of thing you like.
Second, some people enjoy customizing their editor to work exactly the way they want to. You obviously prefer the "set up out of the box" experience, and that is totally fine. Others boost their productivity by customizing their tools. Different people work differently.
Everyone else is not like you. That doesn't make their preferences invalid.
I have known many developers over the years who use both editors, and are extremely productive using their tool of choice. I am certain many of them would not be more productive using VSCode - it simply does not offer them anything significant enough to them to make that big of a difference.
Re: Atom was archived today
#217About damn time
Re: Atom was archived today
#218Earlier quoted context omitted.
Electron is essentially an operating system that runs on every operating system, so you can target just a single OS and your application works everywhere.
Yes, and that's exactly what people hate about it: every application written in Electron lugs around its own copy of this OS. You can imagine why this might not be a good idea, especially for applications designed to run in the background, like the Slack client. For me, it was a godsend when Slack decided that my Linux version was too old to support and the client stopped working. Then I switched to the in-browser ve…
What's the big deal? Surely you have at least 512 GB of RAM, not the typical 1 TB for good measure these days. Modern computers with these bare minimum hardware requirements can handle a few electron apps.
Re: Atom was archived today
#219Earlier quoted context omitted.
Electron is essentially an operating system that runs on every operating system, so you can target just a single OS and your application works everywhere.
Yes, and that's exactly what people hate about it: every application written in Electron lugs around its own copy of this OS. You can imagine why this might not be a good idea, especially for applications designed to run in the background, like the Slack client. For me, it was a godsend when Slack decided that my Linux version was too old to support and the client stopped working. Then I switched to the in-browser ve…
There are two sides to this.
In the Electron case, it’s wasteful to some degree. Especially if the app is not doing much with files/storage etc. For VSCode it makes sense to not run in the browser but for Slack, not so much.
But generally I feel like there’s too much overlap between OS, browsers, IDEs and language runtimes (JVM, V8/Node etc.). It gets worse if you add containers and VMs.
I wonder how many garbage collectors, file abstractions, JITs, databases, schedulers, GUI engines, indexers and so on are running on my machine. How many flavors and versions of essentially the same libraries are used.
There is no unified vision, of what an OS/runtime/IDE/browser should be. There’s not even a common understanding!
Re: Atom was archived today
#220Earlier 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…
On the contrary, working in a professional environment, almost no one I know is using vim or Emacs seriously day to day for coding. We all use VSCode because that is a tool that just works for our team and company. Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs. No, everything sim…
My experience of VSCode _is_ messing around with my config, but giving up and going back to a more mature editor because I could never get it to do what I wanted. I suppose capitulation was also an option, but I dislike the characterisation of tooling as something other than ‘actual coding’.