6 ms·

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

by mawburn 10y ago

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.

zeveb 10y ago
> What if he doesn't want to spend the next 6yrs learning Emacs? From rms's ruminations on Lisp & emacs (https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html): >> 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 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.
- mawburn 10y ago
  >If something is quick to learn, by definition there can't be much substance to it. That's as wrong as 2+2=5.
  - zeveb 10y ago
    > > 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.
    - Karunamon 10y ago
      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.
      - alyandon 10y ago
        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.
- jcfrei 10y ago
  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.
  - zeveb 10y ago
    > 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/ 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.

by mawburn 10y ago

zeveb 10y ago

> What if he doesn't want to spend the next 6yrs learning Emacs? From rms's ruminations on Lisp & emacs (https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html): >> 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 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.

mawburn 10y ago
>If something is quick to learn, by definition there can't be much substance to it. That's as wrong as 2+2=5.
- zeveb 10y ago
  > > 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.
  - Karunamon 10y ago
    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.
    - alyandon 10y ago
      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.
jcfrei 10y ago
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.
- zeveb 10y ago
  > 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/ 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.