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

291–300 of 614 posts

Re: Atom was archived today

#291

Post by fragmede »

TeMPOraL wrote: post #286
fragmede wrote: post #250

Earlier quoted context omitted.

It sounds like your 8 year old computer can't keep with today's technology. If it's possible, might I suggest upgrading your computer? A more modern system would let you run Electron apps without being irritatingly slow. It seems silly that I had to upgrade my laptop in order to run a text editor, but it seems that's just the world we live in.

> A more modern system would let you run Electron apps without being irritatingly slow. That's the problem though: it won't. There is no modern system on which Electron apps run without being irritatingly slow.

I get what you're saying, but Electron apps on like a Core2Duo is unusably bad. On a modern system with plenty of ram they're much more usable.

Re: Atom was archived today

#292

Post by anyfoo »

dima55 wrote: post #53
anyfoo wrote: post #9

Earlier quoted context omitted.

emacs may probably let you do this too, and better. The big problem is: You need to know emacs beforehand, which is seriously a lot, and likely bizarre to any modern person. I do, and I will likely never give it up, but I've been at it since the 90s. In my mind, emacs suffers the same problem as TeX/LaTeX. Some parts of it are very antiquated and just don't fit into the modern world anymore. They'd need an overhaul.…

They (whoever they are) would be well-served to move to emacs, and stay there forever. I don't know which "antiquated" thing you're referring to, specifically, but it all works quite well. Both back in the day and today.

How often do you have emacs hanging because TRAMP is completing some network operation, for example? I’m a big emacs fan, have been using it since the 90s, and will likely never move away. But there’s no reason to pretend that it doesn’t have warts.

Re: Atom was archived today

#293

Post by vertis »

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…

I'm not sure it's fair to say it failed. Not everything is forever. It served very important purposes, helped push technology forward and paved the way for editors like VSCode.

I'd call that success.

Re: Atom was archived today

#294

Post by fragmede »

themoonisachees wrote: post #277
themoonisachees wrote: post #273

Earlier quoted context omitted.

On one side, I agree that expecting an 8yo machine to keep up with modern workflows is silly, and that at some point even bill gates or whoever you attribute the famous 512kb RAM quote to had to admit they were wrong

Forgot to type the rest and can't edit for some reason. On the other hand, vim or Emacs with all features I personally currently use in vscode come in at a fraction of the memory usage, and it is a bit dumb to have to use that much ram for slack or discord considering how light IRC clients used to be.

Yeah it's dumb but what're you gonna do? Technology evolves and the way this industry works is you gotta keep up. Can't keep computing like we're still on mainframes writing Cobol.

Re: Atom was archived today

#295

Post by wsc981 »

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.

It’s also supported out of the box in SublimeText, though probably not as extensive as VSCode. Code completion, for example, is more like guessing in SublimeText. Though I can’t imagine either emacs or VSCode to respond as quickly to input as SublimeText, which is one of the reasons it will remain the text editor of choice for me. At least when writing some code in Lua.

Re: Atom was archived today

#296

Post by rodw »

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

Except just as you noted the conventions change across platforms, contexts and over time, so they aren't really uniform at all.

If you're moving between Windows, macOS, and Linux, or between GUI, command line and remote shell (either within or across any of these) you're already context switching on a regular basis. And if you stick around long enough an OS upgrade will come along that moves the window controls and menu buttons around so you need to retrain your muscle memory (and update your end-user documentation).

If anything some of the long-established, old-school conventions are probably _more_ uniform and consistent. E.g. in vi/vim `:w` will save and `:n` will jump to line n - always and everywhere. In a terminal `find . -name foo` will search the filesystem - (almost) always and everywhere.

That sort of thing isn't comprehensive (i.e. it doesn't cover action you'll need to take) but it's kinda nice when it's available. Maybe we'd be better off if select-then-middle-click worked for copy/paste everywhere.

Re: Atom was archived today

#297

Post by _cenw »

rajeshp1986 wrote: post #174
bearon wrote: post #36

Make no mistake... This project, Atom. Provided the runway that others copied, then improved upon (and on and on... with plenty of funding). Atom provided the seed, excitement and vision for what is possible on this platform, and should be proud of that fact.

People started focussing on text editors again after Atom came out.

I'd credit Sublime Text with that.

Re: Atom was archived today

#298

Post by aembleton »

RektBoy wrote: post #281
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…

VScode is also crap. It doesn't even support multi screen multi-window, heh no thank you. I can't comprehend, how anybody can use VScode for any real work.

What do you recommend over VSCode for real work?

Re: Atom was archived today

#299

Post by throwaway14356 »

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 wouldn't put it that blunt but I do agree. The problem are these nerds with seemingly infinite memory. It is almost impossible for them to make a UI for the rest of us.

I tried editing a txt document in vim one time. After gazing at the UI for much to long I had to ask for help because it wouldn't let me edit the txt.

I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.

They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.

I could certainly learn some of vim's functionality but there would be very little disk space left to write the software. I'm seriously more productive using MS notepad or nano. I can totally see myself forget how to engage edit mode in a week or 2. I'm having visuals of picard ordering enterprise to engage

All i need is a shuttle!

The edit mode feels like a child safety feature where I'm the child.

Human children flying Vulkan space ships, think about it.

If non of this makes sense, that is the whole point.

Re: Atom was archived today

#300

Post by brozaman »

constantcrying wrote: post #234
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…

>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 used works and all. With VSCode I don't even know in which language are extenssions written.

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.

Post reply on HN