4 ms·

> [The JVM is] still unusable for end-user applications because [it makes application startup slow and uses too much RAM.] I can't agree. The poster child for

> [The JVM is] still unusable for end-user applications because [it makes application startup slow and uses too much RAM.] I can't agree. The poster child for "bloated, overweight, slow-as-shit Java application" is Eclipse. Circa 2013, I found it to be not substantially slower or any less usable than Visual Studio on the exact same hardware.

yellowapple 11y ago
That's implying that Visual Studio isn't also bloated, overweight, and slow-as-shit - three traits which VS serves as the textbook definition of. It makes Emacs look like ed in comparison, yet without offering any actual improvement in functionality. In other words, "but it's on par with Visual Studio" does absolutely nothing to counter the argument that the JVM is unusable for end-user applications; if anything, it proves it.
- simoncion 11y ago
  After several years of working with both VS and Eclipse, I can say that IDEs are slow because they're doing a lot of work. (Eclipse suffers a bit because the Eclipse Steering Committee[0] won't let go of the dream that is the Eclipse Platform, but that dream primarily damages the ease of writing software for Eclipse, rather than Eclipse's execution speed.[1]) Consider two applications that each solve tasks of comparable complexity: One of these applications is written in C++. The other is written in Java. Both are written by programmers skilled in their respective languages. If both of these programs have roughly equivalent performance, what does that say about each underlying language? [0] Or whatever their official name is. [1] Source: In a former life, I was tasked to write and maintain bespoke software written on top of the Eclipse Platform. I cannot recommend the Platform for any new development that isn't writing software for Eclipse, itself.
- oldmanjay 11y ago
  >It makes Emacs look like ed in comparison, yet without offering any actual improvement in functionality. Well, it does offer the functionality of being usable integrated environment, which I know a lot of the emacs/vi people dismiss, but it's a very real thing despite those dismissals. On the other hand, I don't really care much, since I've never had the emacs/vi user disease of insisting that everyone else acknowledge that my opinions are superior.
  - yellowapple 11y ago
    > Well, it does offer the functionality of being usable integrated environment, which I know a lot of the emacs/vi people dismiss Maybe the vi people do, but I'm not sure about the Emacs people, seeing as SLIME is the modern day free integrated environment for Common Lisp programming. Regardless, my point was less about the superiority of Emacs and more that Emacs is the oft-cited textbook example of a "bloated" program (as per the "Emacs is an excellent operating system; too bad it's missing a good editor" joke), yet is dwarfed in size by the likes of VS and Eclipse while having parity or near-parity functionality-wise.
    - simoncion 11y ago
      The "Emacs is bloated" meme stopped being relevant at least fifteen years ago. ;) But seriously; some serious questions, seeing as how I've never really used Emacs: How does Emacs compare to versions of Eclipse CDT or Visual Studio released in the past four years for C++ development? How well does Emacs's autocomplete [0] work for templated types of varying complexity? How about its ability to navigate to method definitions and implementations of non-obvious types? Does its autocomplete database update quickly and automatically, or must one trigger the update oneself? [0] I figure that C++ development support isn't in mainline Emacs and is provided by extensions. For brevity's sake, I'll continue to improperly attribute this functionality.
tracker1 11y ago
In fairness Visual Studio (and most IDEs) are pretty bloated and slow. As to the grandparent, that is what asm.js was for, was a subset of JS that could be heavily optimized and JITed... I also really prefer .Net method of native invocation over JNI stubs.
- simoncion 11y ago
  After several years of working with VS, Eclipse, and a couple of other developers' IDEs, I can say -with a straight face- that developers' IDEs are slow primarily because they do a lot of work.
  - tracker1 11y ago
    Absolutely.. and if you're using one on a system without an SSD, it's outright painful. There's a lot that goes on with IDEs, effectively on-demand compilation, file watching, and there's a lot to that. Of course, sometimes I find I'm actually more effected when I can just work on a small module in a plain text editor, and keep things organized so its' relatively easy to follow.

yellowapple 11y ago

That's implying that Visual Studio isn't also bloated, overweight, and slow-as-shit - three traits which VS serves as the textbook definition of. It makes Emacs look like ed in comparison, yet without offering any actual improvement in functionality. In other words, "but it's on par with Visual Studio" does absolutely nothing to counter the argument that the JVM is unusable for end-user applications; if anything, it proves it.

simoncion 11y ago
After several years of working with both VS and Eclipse, I can say that IDEs are slow because they're doing a lot of work. (Eclipse suffers a bit because the Eclipse Steering Committee[0] won't let go of the dream that is the Eclipse Platform, but that dream primarily damages the ease of writing software for Eclipse, rather than Eclipse's execution speed.[1]) Consider two applications that each solve tasks of comparable complexity: One of these applications is written in C++. The other is written in Java. Both are written by programmers skilled in their respective languages. If both of these programs have roughly equivalent performance, what does that say about each underlying language? [0] Or whatever their official name is. [1] Source: In a former life, I was tasked to write and maintain bespoke software written on top of the Eclipse Platform. I cannot recommend the Platform for any new development that isn't writing software for Eclipse, itself.
oldmanjay 11y ago
>It makes Emacs look like ed in comparison, yet without offering any actual improvement in functionality. Well, it does offer the functionality of being usable integrated environment, which I know a lot of the emacs/vi people dismiss, but it's a very real thing despite those dismissals. On the other hand, I don't really care much, since I've never had the emacs/vi user disease of insisting that everyone else acknowledge that my opinions are superior.
- yellowapple 11y ago
  > Well, it does offer the functionality of being usable integrated environment, which I know a lot of the emacs/vi people dismiss Maybe the vi people do, but I'm not sure about the Emacs people, seeing as SLIME is the modern day free integrated environment for Common Lisp programming. Regardless, my point was less about the superiority of Emacs and more that Emacs is the oft-cited textbook example of a "bloated" program (as per the "Emacs is an excellent operating system; too bad it's missing a good editor" joke), yet is dwarfed in size by the likes of VS and Eclipse while having parity or near-parity functionality-wise.
  - simoncion 11y ago
    The "Emacs is bloated" meme stopped being relevant at least fifteen years ago. ;) But seriously; some serious questions, seeing as how I've never really used Emacs: How does Emacs compare to versions of Eclipse CDT or Visual Studio released in the past four years for C++ development? How well does Emacs's autocomplete [0] work for templated types of varying complexity? How about its ability to navigate to method definitions and implementations of non-obvious types? Does its autocomplete database update quickly and automatically, or must one trigger the update oneself? [0] I figure that C++ development support isn't in mainline Emacs and is provided by extensions. For brevity's sake, I'll continue to improperly attribute this functionality.

tracker1 11y ago

In fairness Visual Studio (and most IDEs) are pretty bloated and slow. As to the grandparent, that is what asm.js was for, was a subset of JS that could be heavily optimized and JITed... I also really prefer .Net method of native invocation over JNI stubs.

simoncion 11y ago
After several years of working with VS, Eclipse, and a couple of other developers' IDEs, I can say -with a straight face- that developers' IDEs are slow primarily because they do a lot of work.
- tracker1 11y ago
  Absolutely.. and if you're using one on a system without an SSD, it's outright painful. There's a lot that goes on with IDEs, effectively on-demand compilation, file watching, and there's a lot to that. Of course, sometimes I find I'm actually more effected when I can just work on a small module in a plain text editor, and keep things organized so its' relatively easy to follow.