Note, I own Sublime and still use it. However, I do see great value in the Atom project. Developers shouldn't fall in love with an editor. Key bindings perhaps. The ideal editor would let me turn it into vim or Emacs, for example.
>Then you apply an exponential curve and one day the much larger development community and Moore's Law push Atom past Sublime.
First, there are no more free "Moore's Law pushes". There haven't been any to write home about for at least 2-3 years. It's now all about multicore (which is also not exactly the best thing for a JS based editor to benefit from).
Another issue is that JS performance has already reached most of the optimizations out there. With the JIT-based JS engines there has been a 100x or more speedup from early JS to circa 2010 or so. Not it's at best some 20%-30% speedup year over year, and that only in some narrow cases. Even webassemply (when that lands as a viable option) is not expected to change that much.
As for the larger developer community, ST already has a huge development community for plugins -- which is where most of the action happens. And sometimes a talented programmer with a strong opinion can be better than "design by comitee".
That said, I find Atom to be a nicely designed editor which would have a great potential, if only it wasn't burdened with a crappy architecture and runtime choices. It might not even be JS fault, as Microsofts VS Code seems to do much better.
Moore's Law isn't over. You are asking us to believe the recent past means that we will not get more single cpu performance increases over the next 10-20 years.
And you're saying that a 20%-30% (6x-13x) improvement over then next 10 years won't make a big difference? If Atom was 10x faster, would it be more useable?
As for concurrency not being applicable, that might be true for some tasks but I can easily imagine scenarios where is would help greatly. Multiple buffers and files. Replace and search for example. Indexing, concurrent garbage collectors, ...
So, in your scenario, if cpu's only become 10x faster and we get 60 CPUs, we won't be able to make a better editor?
The "transistor count" version of Moore's Law has been saved by multiple cores. The speed version hasn't been true for single core performance for years.
> You are asking us to believe the recent past means that we will not get more single cpu performance increases over the next 10-20 years.*
Moore's law is put in specific time terms -- transistors/power(speed) should double every 18 months. So if this hasn't been the case for the recent 2-3 years, then Moore's Law is already broken -- no belief required. The fact that it's very possible we'll might see another CPU speed breakthrough in, say, 2022 or 2028 or 2050 doesn't change that -- as Moore's Law talks about sustained improvements over 18 month periods.
Besides, few in the industry disagree that the Moore Law is pretty much over. That's a great motive behind all the talk of optimizing multicore performance, functional techniques etc.
>And you're saying that a 20%-30% (6x-13x) improvement over then next 10 years won't make a big difference? If Atom was 10x faster, would it be more useable?
As already said, this 20-30% is "at best" and covers specific benchmarks and uses, not general speed. And nobody said this is sustainable long term either. After a JIT engine reaches a specific point of sophistication, there are few things that one can add to make it even faster.
Case in Point: Java. Were it possible to make it as fast as C/C++ for the general case, there's been enough money and time thrown at it to get it there. It's fast (frequently fast enough), but it's absolutely plateaued. That Javascript is nearly on par with Java tells me that it's also nearing its own plateau.
>Next month, the worldwide semiconductor industry will formally acknowledge what has become increasingly obvious to everyone involved: Moore's law, the principle that has powered the information-technology revolution since the 1960s, is nearing its end.
No, I mean an editor that allows you to build a complete vim with macros, for example. The source for vim wouldn't be in C and you could implement plugins like EasyMotion.
Only if you want all the stuff (including crap) that vim offers. If you're OK with the 50-100 core commands, then those emulations can be perfectly fine.
(Also some of us used vi too, and that didn't have all the stuff vim comes with either).
Improvements in single-core performance (the kind that matters for Javascript and most real-world applications) has been near-stagnant for many years now.
Your projection also implies that programmers of the future won't also produce exponentially slower code. I have doubts about that, considering how unresponsive programs these days are, compared to their counterparts of two decades ago (when most programmers actually cared about performance).
https://en.m.wikipedia.org/wiki/Exponential_growth
Note, I own Sublime and still use it. However, I do see great value in the Atom project. Developers shouldn't fall in love with an editor. Key bindings perhaps. The ideal editor would let me turn it into vim or Emacs, for example.