What if he doesn't want to spend the next 6yrs learning Emacs?
c9 has a very low entry bar. It's not reinventing the wheel, it's improving it. You can't really compare a terminal based editor, with an extremely high learning curve, to a preconfigured web based IDE.
>> Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
It's really not hard to use a decent text editor like emacs.
> You can't really compare a terminal based editor
emacs has supported X11 since at least November 1994 — your information is at least two decades out of date.
I've got a nice GUI emacs frame open right now.
> with an extremely high learning curve
Learning emacs is not really hard at all. There's a lot to learn, but that's because it does a lot. If something is quick to learn, by definition there can't be much substance to it.
> to a preconfigured web based IDE
Check out emacs prelude (https://github.com/bbatsov/prelude): it's a great some of mostly-sane emacs defaults in one easy-to-use package.
Heck, emacs out of the box is pretty great, too. It evens displays a nice little message about how to use its built-in tutorial.
> > If something is quick to learn, by definition there can't be much substance to it.
> That's as wrong as 2+2=5.
If something can be quickly learnt, then it can't have been too different from what one already knows: i.e., the diff between HEAD & HEAD~1 is relatively small. But small diffs don't do much.
Emacs has a gentle but very long learning curve: it's quick to pick up (quicker than vi!) because it does have some similarities to tools one may already be familiar with, but there's real depth and complexity to emacs as a whole, which means that one never stops learning it. Kinda like life in general: being born was easy, and we never stop learning after.
As someone that's tried many times to learn Emacs, I found Vim's basic features a lot easier to pick up.
I think that may be because all the mode changes are single keys, rather than Emacs, where I constantly have to ask things like "Okay, was it control, alt, meta, or some combination + S to save my file?"
Vim does the : command line thing, but it's an actual command line, with editing, rather than a series of hotkeys.
This annoys me because I'd really like to learn Emacs. It seems you can live in it - but the learning curve is hardly gentle.
I have more or less the same problem coming from vi(m). I forced myself to use Emacs for about 2-3 months to get past the "this is hard because it is unfamiliar" stage.
I found Emacs to be relatively pleasant as an environment for hacking source code but I was nowhere near the same level of proficiency at editing with it after several months of usage compared to where I was within a few weeks of forcing myself to learn vi(m).
Emacs has a lot going for it as far as out of the box functionality and the ease of installing packages but it seems that unless you want to take the time to dive deep and learn the minutiae of elisp and configuration you are never really going to become super proficient with it.
The one thing I did come away with after using Emacs was that swapping ctrl/capslocks is the best thing ever and helps even with vi(m) and I now do that for all my environments even though I never touch Emacs anymore.
At the risk of sounding precocious but I doubt a novel programmer today has as much time for a project as the folks had back in the 70s and 80s. Development cycles have gotten much, much shorter. And there are already numerous tools which you have to learn for an efficient workflow, like build and testing tools, code repositories, etc. Every bit of time saved in dealing with your environment rather than the actual programming problem at hand is very valuable nowadays. Remember software has always been about raising productivity, not just of an industry but of the developer himself. Eventually we'll look back on programmers using text editors and rsync for development and deployment the same way we look at people developing software in Pascal and BASIC.
> And there are already numerous tools which you have to learn for an efficient workflow, like build and testing tools, code repositories, etc.
emacs already has interfaces to build and testing tools. It has Magit, the best git interface I've used.
> Remember software has always been about raising productivity, not just of an industry but of the developer himself.
That's why I'm advocating a user-extensible editing environment! That's why I use emacs.
> Eventually we'll look back on programmers using text editors and rsync for development and deployment the same way we look at people developing software in Pascal and BASIC.
We emacs users already look at folks using editors and rsync for development that way: we have TRAMP (https://www.gnu.org/software/tramp/), which enables one to run an editor locally on remote files. One can even run commands on the server a remote file is located on.
There's no reason that elisp can't be written to spin up DigitalOcean droplets, AWS EC2 instances, fire off Lambda code, deploy pods to kubernetes, control a Mesos cluster, &c. &c. &c. And if one does that, one gets all that plus a world-class, best-of-breed text editing environment with millions of lines of code to do just about anything else one might want to do already written.
Or one could spend time trying to extend a proprietary product, running elsewhere, ignoring forty years of experience and improvements. One could try to reinvent the wooden wheel while others are running transcontinental airline service.
That's really how I feel: every day I'm taking a teleporter to the office, and meanwhile I'm watching others talk about how they've noticed that if they rub a pair of sticks together they get pretty warm. I'm not saying that the folks busily reinventing fire are dumb — most definitely not: they're brilliant — but rather that no-one has bothered teaching them all the innovations which have occurred since fire was first invented.
Setting the metaphor aside, our industry seems to do an amazing job of utterly refusing to learn from and develop on the past. Every half-decade or so someone comes along and reinvents things which were truly groundbreaking ideas before I was born. We seem to be stuck repeating 1970s computer science, over and over and over, rather than trying to live in the 2010s.
I think it's clear to everybody here that you can integrate any type of functionality into emacs. But if most new programmers prefer browsers, then that's what they are going to use... Maybe they just prefer building tools on top of javascript/css (where they can create actual GUIs) rather than lisp. For most programmers this is kind of a moot discussion because usually you don't get to choose the tools yourself and have to make do with what's supported. On a side note: Your TRAMP teleporter appears to use rsync most of the time anyway ;)
> But if most new programmers prefer browsers, then that's what they are going to use...
If most new programmers prefer to edit code in browsers than in editors, then they are just wrong. I don't know why the preferences of new programmers should matter to professionals any more than the preferences of peewee football players matter to the NFL. The whole point of education is to improve people, not leave them satisfied where they are.
> Maybe they just prefer building tools on top of javascript/css (where they can create actual GUIs) rather than lisp.
Anyone who prefers JavaScript to Lisp or SmallTalk is just wrong. And, of course, one can create 'actual GUIs' in Lisp or SmallTalk just as in JavaScript. In fact, SmallTalk kinda invented the GUI IIRC.
> On a side note: Your TRAMP teleporter appears to use rsync most of the time anyway ;)
At least in my experience it's mostly SSH, not rsync.
> Anyone who prefers JavaScript to Lisp or SmallTalk is just wrong.
I also happen to share that opinion, but the trick is to avoid falling into the Smug Lisp Weenie trap.
It is amazing how primitive most editors are in comparison to Emacs. However, what is also amazing is how fast they are progressing. I've been trying (of all things!) Atom, and it is already adequate for most folks.
Just the other day I've overhead colleagues talking about how some editor (MS Code?) finally added tabs. I kept to myself, but couldn't help rolling my eyes. Not only buffers are more practical (specially if paired with something like Helm), one could hack their own tab bar in a reasonable amount of time (or just download something to do so).
Recent editors are just not customizable enough (not yet, at least). Doesn't matter if they are written in Lisp or BrainF*ck.
> the trick is to avoid falling into the Smug Lisp Weenie trap.
Yeah, I know — that's why I included a shoutout to SmallTalk, another great language. There are any number of truly great languages out there (ML, Erlang also leap to mind), although not all of them are great for writing a great editor.
It's hard to avoid being a Smug Lisp Weenie when one sees so much effort wasted on haphazardly reinventing stuff which has been working well for decades elsewhere. Why not spend a few hours or weeks improving what is already great rather than spending years building something new which will probably never be great?
It's probably the thing which makes me most bitter about our profession: the amount of sloppy and wishful thinking, which includes ignoring the numerous lessons of the past. Can you imagine where automotive technology would be if every new engineer spent the first decade of his career playing with rubber trees and ore trying to develop tyres and engine-suitable alloys rather than building on over a century of experience of others?
What's really weird is that there's so much new territory to explore in our field. We're spending entire careers re-exploring our own backyards when there's an entire continent out there to discover.
One of the most important metrics for a language is the number of people using it.
For new programmers learning elisp adds possibility to create best possible editor on base of emacs (a problem they still don't want to solve), learning javascript allows to find a job (a problem many want to solve). When they learn javascript for their day job, they like the language that gives them power to create things, and they don't see emacs as great, because what they can do for js based editor in hours, will take them months in emacs.
But all that aside, the most important advantage building editor in the browser instead of in emacs, is the huge amount of work that large groups of very good engineers put into making browsers fast, stable and well documented. Small emacs team never can make the part of emacs written in c on par with browser, even for handling the small number of features needed for the ide.
So on one hand we had to redo some of the things lisp had acomplished earlier, on the other hand there is a high chance we won't have to redo in the future what web is doing now.
c9 has a very low entry bar. It's not reinventing the wheel, it's improving it. You can't really compare a terminal based editor, with an extremely high learning curve, to a preconfigured web based IDE.