3 ms·

Was anybody's choice of editor really a major point in their developer progress and productivity? Having used multiple IDEs and editors, from DOS edit/qbasic t

Was anybody's choice of editor really a major point in their developer progress and productivity? Having used multiple IDEs and editors, from DOS edit/qbasic to notepad.exe, RHIDE from DJGPP, Visual Studio, Xemacs (briefly), Vim, Eclipse, IntelliJ, probably others... Yes, some of those bring unique abilities that the others lack, that have an effect on the way I write software. Had I just picked one editor or IDE and never used any others, I would be much less accomplished. Vim, for example, is for me incredibly rapid at rearranging and replacing words/lines/regions of text compared to the others.

coldtea 6y ago
>Vim, for example, is for me incredibly rapid at rearranging and replacing words/lines/regions of text compared to the others. Sure, but how much of that clerical work is relevant to programming, where a rate of say 100 lines per day is a major achievement, and it's usually much less? Even if one needs to delete/copy/re-arrange 1000 lines in order to get to those 100 (and usually it's more like 30-50 per day than 100 anyway), it's still a tiny part of the time. In any case, I've seen great coders, from Brian Kernighan and Bill Joy, to Linus, Carmack, and Persson using whatever from Vi and Emacs to Visual Studio and Eclipse, and still getting shit done...
- athrowaway3z 6y ago
  The numbers aren't helping. 100 lines of what? It all boils down to 'it depends'. In my personal experience, before i started using spacemacs i would postpone re-arranging code when i was busy coding something useful. Pushing all the cost into an afternoon of _just_ rearranging code. Besides not having a very 'productive' afternoon, the costs would linger because i need to update my mental map of all the stuff that moved around. Now, most rearranging is a couple of key strokes away. I'm not sure what i would do in another IDE. I would probably do the rearanging as soon as required, because I've learned my lesson. But moving my hand to the mouse and clicking multiple buttons while typing new file names and dragging my mouse over pieces does take a lot of flow out of the session.
  - tsimionescu 6y ago
    > But moving my hand to the mouse and clicking multiple buttons while typing new file names and dragging my mouse over pieces does take a lot of flow out of the session. I don't understand why people equate IDEs with mouse interaction. All major IDEs, from Emacs to VisualStudio, have key combinations for anything you can do. It's fair to say some key combinations are better in one program than another, but there is no reason to imagine that using an IDE means you must also use a mouse. The mouse is always an extra option, not a requirement. And there are code modifications that an IDE can do for you cheaply at the press of a key that would take hours of tedious, error-prone manual work, even with fancy vim fingerwork. Even the lowly 'Extract Function' already can save a good half an hour for more complex cases. And modern IDEs offer things like passing a parameter down through a long call stack in all places (a calls b calls c calls d calls f, and now you want a variable in a to become a parameter in f), with guaranteed 0 manual intervention. Or extracting an interface out of a class and patching all callers. Not to mention all of the code exploration options, such as IntelliJ's 'Dataflow to here', which finds all of the code which is responsible for a variable's value throughout your entire program (or the dataflow from here operation, which finds how a value set in this function is used further down the call stack), stopping only at IO (so if a.foo() reads a value from a file and stores it in a field that is read in a.bar() which puts it in a dictionary, where it is read by baz() which adds 7 to it and prints it out, you can ask for dataflow to the variable being printed and it will find that it was read from some file in a.foo()).
- why_Mr_Anderson 6y ago
  >programming, where a rate of say 100 lines per day is a major achievement Wait, what? 100 lines per day is an achievement? I'm honestly curious in what branch of SW development this happens. I'd assume something that requires formal proof of every piece of code ever written?
  - thrower123 6y ago
    On Brownfield software, your LOC counts probably average out to nearly zero. It wouldn't be uncommon to spend four or five hours diagnosing, tracing, reproducing, then fixing and verifying a bug, and the end result would be two lines of code changed when you were all done, with maybe twenty or thirty more in tests.
  - coldtea 6y ago
    >I'm honestly curious in what branch of SW development this happens Most. It is based on some well studied and established averages, anywhere where it's actual core programming (ie. not counting churning out boilerplate html/css/CRUD code N times for the same/same-ish functionality). Actully 100 lines/day is on the optimistic side: "Capers Jones has compared many methodologies (RUP, XP, Agile, Waterfall, etc) and programming languages over thousands of projects and determined that programmers write between 325 and 750 lines of code (LOC) per month"
  - Ma8ee 6y ago
    The only people I’ve seen creating more than that consistently have been cut and past programmers that either never heard of DRY or thought it a very contentious principle.

coldtea 6y ago

>Vim, for example, is for me incredibly rapid at rearranging and replacing words/lines/regions of text compared to the others. Sure, but how much of that clerical work is relevant to programming, where a rate of say 100 lines per day is a major achievement, and it's usually much less? Even if one needs to delete/copy/re-arrange 1000 lines in order to get to those 100 (and usually it's more like 30-50 per day than 100 anyway), it's still a tiny part of the time. In any case, I've seen great coders, from Brian Kernighan and Bill Joy, to Linus, Carmack, and Persson using whatever from Vi and Emacs to Visual Studio and Eclipse, and still getting shit done...

athrowaway3z 6y ago
The numbers aren't helping. 100 lines of what? It all boils down to 'it depends'. In my personal experience, before i started using spacemacs i would postpone re-arranging code when i was busy coding something useful. Pushing all the cost into an afternoon of _just_ rearranging code. Besides not having a very 'productive' afternoon, the costs would linger because i need to update my mental map of all the stuff that moved around. Now, most rearranging is a couple of key strokes away. I'm not sure what i would do in another IDE. I would probably do the rearanging as soon as required, because I've learned my lesson. But moving my hand to the mouse and clicking multiple buttons while typing new file names and dragging my mouse over pieces does take a lot of flow out of the session.
- tsimionescu 6y ago
  > But moving my hand to the mouse and clicking multiple buttons while typing new file names and dragging my mouse over pieces does take a lot of flow out of the session. I don't understand why people equate IDEs with mouse interaction. All major IDEs, from Emacs to VisualStudio, have key combinations for anything you can do. It's fair to say some key combinations are better in one program than another, but there is no reason to imagine that using an IDE means you must also use a mouse. The mouse is always an extra option, not a requirement. And there are code modifications that an IDE can do for you cheaply at the press of a key that would take hours of tedious, error-prone manual work, even with fancy vim fingerwork. Even the lowly 'Extract Function' already can save a good half an hour for more complex cases. And modern IDEs offer things like passing a parameter down through a long call stack in all places (a calls b calls c calls d calls f, and now you want a variable in a to become a parameter in f), with guaranteed 0 manual intervention. Or extracting an interface out of a class and patching all callers. Not to mention all of the code exploration options, such as IntelliJ's 'Dataflow to here', which finds all of the code which is responsible for a variable's value throughout your entire program (or the dataflow from here operation, which finds how a value set in this function is used further down the call stack), stopping only at IO (so if a.foo() reads a value from a file and stores it in a field that is read in a.bar() which puts it in a dictionary, where it is read by baz() which adds 7 to it and prints it out, you can ask for dataflow to the variable being printed and it will find that it was read from some file in a.foo()).
why_Mr_Anderson 6y ago
>programming, where a rate of say 100 lines per day is a major achievement Wait, what? 100 lines per day is an achievement? I'm honestly curious in what branch of SW development this happens. I'd assume something that requires formal proof of every piece of code ever written?
- thrower123 6y ago
  On Brownfield software, your LOC counts probably average out to nearly zero. It wouldn't be uncommon to spend four or five hours diagnosing, tracing, reproducing, then fixing and verifying a bug, and the end result would be two lines of code changed when you were all done, with maybe twenty or thirty more in tests.
- coldtea 6y ago
  >I'm honestly curious in what branch of SW development this happens Most. It is based on some well studied and established averages, anywhere where it's actual core programming (ie. not counting churning out boilerplate html/css/CRUD code N times for the same/same-ish functionality). Actully 100 lines/day is on the optimistic side: "Capers Jones has compared many methodologies (RUP, XP, Agile, Waterfall, etc) and programming languages over thousands of projects and determined that programmers write between 325 and 750 lines of code (LOC) per month"
- Ma8ee 6y ago
  The only people I’ve seen creating more than that consistently have been cut and past programmers that either never heard of DRY or thought it a very contentious principle.