4 ms·
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 cyc
by 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.
- jcfrei 10y agoI 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 ;)
- zeveb 10y ago> 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.
- outworlder 10y ago> 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.