4 ms·

How is that different to any other advancements we've made? C is slower than assembly. Python is slower than C. Programmers will continually pick higher leve

How is that different to any other advancements we've made? C is slower than assembly. Python is slower than C. Programmers will continually pick higher level programming languages since it's easier. I keep on seeing people complaining about Electron here, but it's brought about an age of hundreds of thousands of applications that have compatibility across OS' to do very specific tasks. I just feel that the ~80MB memory usage and large file size (30-60MB) is inconsequential in modern computing.

slhck 9y ago
It's not necessarily about large file size (storage is cheap anyway) and memory usage (although RAM on portable devices is still kind of limited). Performance in Electron-based editors (e.g., Atom) is horrible. When you're used to vim or fast GUI-based editors like Sublime, even typing in Atom feels sluggish. That's not even talking about loading large files, search-and-replace operations, multiple cursors, etc. Example stats: https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-performance-dec-2016/ https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...
bayindirh 9y ago
Atom doesn't use 80MB, it uses 800MB. On the other side, my Eclipse installation uses ~1100MB and runs whole array of analyzers and background stuff that an IDE should run. Atom runs nothing at the back or provides the same functionality while using 800MB. Also, Eclipse is portable around all major operating systems. Resource usage can be justified if the that resources is used toward something meaningful. C is "slower" than assembly, yes; however both assembly can be inlined into C, and magnitudes more can be done with C at near-assembly speeds. I develop in C/C++/Python mainly and in some other languages for fun and curiosity. Python is easy, but it's not as performant unless the underlying library is native, hence nobody is using it if it can't obtain very high performance in my field (scientific computing, HPC, and related areas). Actually, writing a low performance GUI is pretty hard since most of its cycles are idle. If you can write an application with a GUI which slow to respond to low-complexity, common tasks (naive text editing, input, menus, moving windows), something is very, very wrong (to be clear, GUI can trigger resource intensive background tasks, but that's not what I'm saying).
- Klathmon 9y ago
  >Atom doesn't use 80MB, it uses 800MB. This is an over exaggeration, and quite a large one. Facebook just released information on the average memory usage of "nuclide" (their Atom editor bundled with a metric ton of plugins which use quite a lot of memory) to be around 600mb. And that's not indicative of a "normal" Atom user (if there can be such a thing). I personally have currently 5 windows open in atom, with about a combined 40 tabs, and about 30 plugins installed, and my instance is using 360mb of memory right now across all processes. And those windows have been open for about a week now. And that Atom instance is running a lot of what your Eclipse instance is running. Linters, autocomplete, code analysis tools, CI server integration, a webserver for serving up my application in the editor, a debugger that links the live preview in the editor with the code in the editor, and a ton more. Switching to something which uses a few hundred less MB of RAM for a fraction of the capability would be a monumentally stupid thing to do, as Atom makes me significantly more productive than any other editor I've tried has ever before. There are a lot of problems with Electron, but memory usage isn't one of them any more. It can be, just like with any language/platform, but it's not "inherent" to the technology.
  - rootlocus 9y ago
    Out of curiosity, how large is the project you're working on? How many source files / lines of code?
    - Klathmon 9y ago
      Well each window has open a different repo right now. But the general sizes are (all ignoring 3rd party dependencies): * 1 front-end react monorepo which contains a handful of front-end projects with about 50k LOC of js files only across them all * 1 backend node.js projects with about 7k LOC * 2 npm packages that I'm working on. One that's like 300 LOC total, and another that probably hits around 1k (haven't measured, just a guess) * 1 go project that I'm hacking on in my spare time, but I just keep the window open because why not? this has about 1k loc.
  - bayindirh 9y ago
marrs 9y ago
That's all very fine and well, but programmers are rarely programming for themselves. If you are targeting your product at the user specifically then you should be aiming at least at a pleasant user experience. If the "advancement" you cite is at the expense of the user then perhaps it's not that much of an advance.
- bayindirh 9y ago
  That's a very nice perspective to think.
rootlocus 9y ago
> but it's brought about an age of hundreds of thousands of applications that have compatibility across OS' to do very specific tasks. Quantity over quality seems to be the recent trend.

slhck 9y ago

It's not necessarily about large file size (storage is cheap anyway) and memory usage (although RAM on portable devices is still kind of limited). Performance in Electron-based editors (e.g., Atom) is horrible. When you're used to vim or fast GUI-based editors like Sublime, even typing in Atom feels sluggish. That's not even talking about loading large files, search-and-replace operations, multiple cursors, etc. Example stats: https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-performance-dec-2016/ https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...

bayindirh 9y ago

Atom doesn't use 80MB, it uses 800MB. On the other side, my Eclipse installation uses ~1100MB and runs whole array of analyzers and background stuff that an IDE should run. Atom runs nothing at the back or provides the same functionality while using 800MB. Also, Eclipse is portable around all major operating systems. Resource usage can be justified if the that resources is used toward something meaningful. C is "slower" than assembly, yes; however both assembly can be inlined into C, and magnitudes more can be done with C at near-assembly speeds. I develop in C/C++/Python mainly and in some other languages for fun and curiosity. Python is easy, but it's not as performant unless the underlying library is native, hence nobody is using it if it can't obtain very high performance in my field (scientific computing, HPC, and related areas). Actually, writing a low performance GUI is pretty hard since most of its cycles are idle. If you can write an application with a GUI which slow to respond to low-complexity, common tasks (naive text editing, input, menus, moving windows), something is very, very wrong (to be clear, GUI can trigger resource intensive background tasks, but that's not what I'm saying).

Klathmon 9y ago
>Atom doesn't use 80MB, it uses 800MB. This is an over exaggeration, and quite a large one. Facebook just released information on the average memory usage of "nuclide" (their Atom editor bundled with a metric ton of plugins which use quite a lot of memory) to be around 600mb. And that's not indicative of a "normal" Atom user (if there can be such a thing). I personally have currently 5 windows open in atom, with about a combined 40 tabs, and about 30 plugins installed, and my instance is using 360mb of memory right now across all processes. And those windows have been open for about a week now. And that Atom instance is running a lot of what your Eclipse instance is running. Linters, autocomplete, code analysis tools, CI server integration, a webserver for serving up my application in the editor, a debugger that links the live preview in the editor with the code in the editor, and a ton more. Switching to something which uses a few hundred less MB of RAM for a fraction of the capability would be a monumentally stupid thing to do, as Atom makes me significantly more productive than any other editor I've tried has ever before. There are a lot of problems with Electron, but memory usage isn't one of them any more. It can be, just like with any language/platform, but it's not "inherent" to the technology.
- rootlocus 9y ago
  Out of curiosity, how large is the project you're working on? How many source files / lines of code?
  - Klathmon 9y ago
    Well each window has open a different repo right now. But the general sizes are (all ignoring 3rd party dependencies): * 1 front-end react monorepo which contains a handful of front-end projects with about 50k LOC of js files only across them all * 1 backend node.js projects with about 7k LOC * 2 npm packages that I'm working on. One that's like 300 LOC total, and another that probably hits around 1k (haven't measured, just a guess) * 1 go project that I'm hacking on in my spare time, but I just keep the window open because why not? this has about 1k loc.
- bayindirh 9y ago

marrs 9y ago

That's all very fine and well, but programmers are rarely programming for themselves. If you are targeting your product at the user specifically then you should be aiming at least at a pleasant user experience. If the "advancement" you cite is at the expense of the user then perhaps it's not that much of an advance.

bayindirh 9y ago
That's a very nice perspective to think.

rootlocus 9y ago

> but it's brought about an age of hundreds of thousands of applications that have compatibility across OS' to do very specific tasks. Quantity over quality seems to be the recent trend.