4 ms·

This whole talk of efficiency surprises me. if that is what we are looking for, then in my mind you are either writing too much code or aren't thinking the prob

by alttab 15y ago

This whole talk of efficiency surprises me. if that is what we are looking for, then in my mind you are either writing too much code or aren't thinking the problem through. In my experience, coding takes up less time because you get better at it.

tikhonj 15y ago
Efficiency isn't really about entering text, it's about quickly navigating around large amounts of text, editing parts, performing larger operations, integrating the rest of your workflow (maybe a REPL or a browser preview or tests...), testing code, exploratory programming, combining different languages, working with markup languages (HTML, XML, Markdown, LaTeX), writing documentation, reading documentation...etc. The beauty of Emacs is that it does all this (and more :)) well for a whole range of languages. The goal is not just to be able to do anything you need quickly, but to do it in a way that doesn't break your concentration and doesn't take much thought. Moreover, this has to apply to pretty much every sort of thing you do with your source files, which is actually quite a lot. Today, almost any work you do on your software project as a developer involves text, not just programming, so efficiency really matters. Additionally, it should be really easy to create complicated workflows for your specific project. For example, I am working on some code that operates on two trees and produces a third. It literally took me half and hour to create an Emacs command that took some (configurable) input, ran my function on it, rendered the result with LaTeX (using a tree-drawing package) and displayed it. This way, when I make an edit to the algorithm, I just run a single command and see the output immediately with a nice visualization. This makes playing around with modifications to the algorithm very simple.
- alttab 15y ago
  I use VI with default key bindings and few macros. In my mind workflow is based more on how you approach the problem and less about what tools you end up using. You wrote an emacs command that I would imagine could be done with bash just as well. Have to tab to a different terminal to run the command? Not that big of a deal in the grander scheme of things. If you need to build new software to shave a couple of seconds off of finding a piece of code, or switching to documentation, or running a command without pressing ALT-TAB, I would venture to say you have other problems not related to workflow or tools. Say, your ability to stay concentrated and focused without interruptions, understanding that your development workflow does not a product team make, or focusing on the problem your product is trying to solve in the real world market versus getting into self-masturbatory work-flow science. I don't disagree that component-based workflows are important, but I also can't count how many times I've seen developers more concerned with how they work than what they produce.

by alttab 15y ago

tikhonj 15y ago

Efficiency isn't really about entering text, it's about quickly navigating around large amounts of text, editing parts, performing larger operations, integrating the rest of your workflow (maybe a REPL or a browser preview or tests...), testing code, exploratory programming, combining different languages, working with markup languages (HTML, XML, Markdown, LaTeX), writing documentation, reading documentation...etc. The beauty of Emacs is that it does all this (and more :)) well for a whole range of languages. The goal is not just to be able to do anything you need quickly, but to do it in a way that doesn't break your concentration and doesn't take much thought. Moreover, this has to apply to pretty much every sort of thing you do with your source files, which is actually quite a lot. Today, almost any work you do on your software project as a developer involves text, not just programming, so efficiency really matters. Additionally, it should be really easy to create complicated workflows for your specific project. For example, I am working on some code that operates on two trees and produces a third. It literally took me half and hour to create an Emacs command that took some (configurable) input, ran my function on it, rendered the result with LaTeX (using a tree-drawing package) and displayed it. This way, when I make an edit to the algorithm, I just run a single command and see the output immediately with a nice visualization. This makes playing around with modifications to the algorithm very simple.

alttab 15y ago
I use VI with default key bindings and few macros. In my mind workflow is based more on how you approach the problem and less about what tools you end up using. You wrote an emacs command that I would imagine could be done with bash just as well. Have to tab to a different terminal to run the command? Not that big of a deal in the grander scheme of things. If you need to build new software to shave a couple of seconds off of finding a piece of code, or switching to documentation, or running a command without pressing ALT-TAB, I would venture to say you have other problems not related to workflow or tools. Say, your ability to stay concentrated and focused without interruptions, understanding that your development workflow does not a product team make, or focusing on the problem your product is trying to solve in the real world market versus getting into self-masturbatory work-flow science. I don't disagree that component-based workflows are important, but I also can't count how many times I've seen developers more concerned with how they work than what they produce.