Live data from Hacker News

Atom was archived today

github.com

581–590 of 614 posts

Re: Atom was archived today

#581
post #229

Earlier quoted context omitted.

again, like the JVM I am not particularly fond of Java (I know I am not alone :-D).

Java can perform well, and even with all the enterprizey bullshit, it still performs much better than your run of the mill, best practices follower javascript program. Javascript actually can perform well, not nearly as well as java can, but it doesn't have to be as bad as what you see on most electron applications. But it's not trivial to make it so.

Yeah, I wasn't really thinking of performance. I was thinking of the dislike I have for working with Java. Past experiences with "enterprizey" Java is the worst. AbstractWidgetFactoryBuilderLoaderMaker, etc.

Re: Atom was archived today

#582
post #578

Earlier quoted context omitted.

I made a related reply here: https://news.ycombinator.com/item?id=34020775 It's not just the code, we'd want everyone on the team to use the appropriate toolsets including debugging and error checking support. They can set it up in Vim and Emacs if they want but it saves time for the team as a whole if we all use a standardized set of tools.

Yes, that makes perfect sense. If they want to set up an alternative editor, doing it on their own time is a reasonable expectation. No question vscode is millions of times easier for juniors.

These kinds of hyperboles are really really bad. You are stating that if it took 1 minute to install a plugin and get to work in vscode, it would take 694.4 days to do the same in other editors? Please use reasonable numbers if you are trying to make a valid point.

Re: Atom was archived today

#583
post #444

Earlier quoted context omitted.

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…

> 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. Completely agree: the entire company should be on a common, future-proof, extensible, free platform: Emacs! I honestly don’t understand why anyone bothers wasting effort on any other editor.

You misspelled Vim/Neovim. wink

Re: Atom was archived today

#584
post #143

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…

Good tools usually have a beneficial tradeoff - it takes a minute or two to learn how to do it, but you have recurrent measureable gains in productivity after that. That includes closing Vim.

Re: Atom was archived today

#585
post #581

Earlier quoted context omitted.

Java can perform well, and even with all the enterprizey bullshit, it still performs much better than your run of the mill, best practices follower javascript program. Javascript actually can perform well, not nearly as well as java can, but it doesn't have to be as bad as what you see on most electron applications. But it's not trivial to make it so.

Yeah, I wasn't really thinking of performance. I was thinking of the dislike I have for working with Java. Past experiences with "enterprizey" Java is the worst. AbstractWidgetFactoryBuilderLoaderMaker, etc.

Well, all the discussion about Atom, all around we is about performance. Even when the people in the discussion don't actually notice this.

But I'd put javascript and java on the same cohort when talk about usability (programability?, what name do I use here?). They are not as bad to be dangerous, but neither is any good either. Anyway, the JVM allows some other languages that don't solve all the problems but bring you some expressivity (honestly, I have no idea if this is a positive), while electron can work with typescript (much better than javascript) and can run wasm (what currently implies on rust, what means low expressivity but high confidence on your code).

I'm not ready to declare any winner here.

Re: Atom was archived today

#586
post #578

Earlier quoted context omitted.

Yes, that makes perfect sense. If they want to set up an alternative editor, doing it on their own time is a reasonable expectation. No question vscode is millions of times easier for juniors.

These kinds of hyperboles are really really bad. You are stating that if it took 1 minute to install a plugin and get to work in vscode, it would take 694.4 days to do the same in other editors? Please use reasonable numbers if you are trying to make a valid point.

Not just 'other editors', I was thinking about emacs specifically. I think my point was fairly obvious. Maybe not a million times, but probably hundreds. Vscode and other modern editors use key combinations everyone knows by default, eg. C-q, C-c, C-v, etc., have gui directory browsing- so there is essentially no learning curve.

It takes weeks (at least) using emacs/vim until text editing/movement starts to pay off. There's no learning curve for `M-x package-install`, but if there is some variable that needs to be customized, like the path to an executable or something, that's a whole rabbit hole to go down, and at some point you need to learn lisp or you'll waste a lot of time being confused by errors.

During the only programming course I took in college, one in which emacs was required, I spent as much time learning emacs as anything else (it was also the most valuable thing I learned so I'm grateful in the long run).

Re: Atom was archived today

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

LSP was a HUGE step forward, all editors benefit from it nowadays. Having multiple communities contributing back to the same language server makes maintaining those plugins a lot more comfortable.

I still fail to understand the importance of a language server.

One could have created a library which conformed to some specification, written the library a single time, then compiled it for different platforms. Editors could then have loaded that shared library and used it just as they wrote in support for a language server. There's no need to get a network server involved.

You still have the majority of development effort in the library, instead of individual text editors. You still have the joy of a nearly pure piece of code, without OS-specific paradigms like networking which impede progress. You still have a simple interface with the editor.

I see exactly zero benefits of having a language server over a traditional shared library, except with a network server you make a trade off where you gain latency and other networking problems, and you gain absolutely nothing.

I don't even know of any central language servers, which were one of the core benefits of the LSP design. "ooh we can all share a language server which is kept up to date independently of our editors! squeeee!" Where's that? Why is that a benefit at all? Presumably you'd still need to shut it down to update it, and someone has to manage it.

The experience that people using editors got when aeditor developers started thinking about how to do something better is what the users love, not the LSP itself. LSP triggered this change in thinking, but anything could have, and I'm honestly surprised that nothing else did prior to LSP.

Re: Atom was archived today

#588
post #568

Earlier quoted context omitted.

VirtualDOM is why. vanilla.js is better

Have fun rewriting your own ad hoc, informally-specified, bug-ridden, slow implementation of half of ̶C̶o̶m̶m̶o̶n̶ ̶L̶i̶s̶p̶ React.

that's the "problem" tho — i dont need that level of abstraction, i already know how to assign event listeners and toggle css classes, which covers 99% or real-life needs

Re: Atom was archived today

#589
post #588

Earlier quoted context omitted.

Have fun rewriting your own ad hoc, informally-specified, bug-ridden, slow implementation of half of ̶C̶o̶m̶m̶o̶n̶ ̶L̶i̶s̶p̶ React.

that's the "problem" tho — i dont need that level of abstraction, i already know how to assign event listeners and toggle css classes, which covers 99% or real-life needs

For small projects, sure. But it breaks down in larger ones, ask me how I know. The reality is React and other tools solve problems at scale, plus they're genuinely nice to develop in, while vanilla JS simply is not.

Re: Atom was archived today

#590

Earlier quoted context omitted.

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

The claim was not that VSCode is a better editor than vim or emacs, but rather that "VSCode is the greatest productivity tool in the history of software engineering". To me, the tool that matches that description is the one which most increases the productivity level for the most people. Emacs or Vim might be better at increasing the productivity of a single individual (super huge might here – I personally found VSCode improved my productivity much more than vim ever did), but once you multiply that out by the number of people impacted, I doubt there is much contest.
Post reply on HN