4 ms·

""looks cool, but can't be made". Why not? It's definitely cool and definitely can be made. The question is: will anyone want to use it, or is it just cool? Is

by Aqueous 15y ago

""looks cool, but can't be made". Why not? It's definitely cool and definitely can be made. The question is: will anyone want to use it, or is it just cool? Is the learning curve too steep to make us want to adopt it as our primary text editor? Does it really confer efficiency advantages over Emacs/Vim/TextMate/XCode/Eclipse/etc? To me, it stands a good chance of being widely adopted if and only if it is actually more efficient to use it and if the time of adoption doesn't outweigh those efficiency advantages. I don't have an answer to this question, because I haven't actually used it. I suggest that since everyone else hasn't either, we wait to pass judgment on whether it will work or not.

edanm 15y ago
Efficiency is actually not the only, or even most important, concern. At least, not necessarily. For example, one important consideration is how easy to use it is, especially for new programmers. For better or worse, Eclipse makes programming in Java easier for many programmers. This is a pretty important consideration for most organizations.
- Aqueous 15y ago
  Right - I include that under the learning curve question. But, that said, there are plenty examples of editors that are obviously not easy to use(cough Emacs?) and yet tons of people still use them because (apparently) they are more productive in Emacs. I'm not one of those people - I tend to prefer TextMate or TextMate-like GUI editors. But I can see how people are willing to suffer through a steep learning curve in order to ultimately become more productive. LightTable might end up being the same way.
- tikhonj 15y ago
  I think valuing how easy it is to learn over efficiency is not the best option: learning even a difficult text editor takes a constant and reasonably small amount of time. Being more efficient is a benefit proportional to how much you use the editor. So anybody planning to program for a long time is probably going to be well served by learning a more efficient but "harder" editor. Now, in the real world there are other considerations and the question is more complicated with regards to actual editors. However, given a hypothetical choice between something harder to learn but more efficient or easier to learn but less efficient I'd go for the former each time.
  - 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 Aqueous 15y ago

edanm 15y ago

Efficiency is actually not the only, or even most important, concern. At least, not necessarily. For example, one important consideration is how easy to use it is, especially for new programmers. For better or worse, Eclipse makes programming in Java easier for many programmers. This is a pretty important consideration for most organizations.

Aqueous 15y ago
Right - I include that under the learning curve question. But, that said, there are plenty examples of editors that are obviously not easy to use(cough Emacs?) and yet tons of people still use them because (apparently) they are more productive in Emacs. I'm not one of those people - I tend to prefer TextMate or TextMate-like GUI editors. But I can see how people are willing to suffer through a steep learning curve in order to ultimately become more productive. LightTable might end up being the same way.
tikhonj 15y ago
I think valuing how easy it is to learn over efficiency is not the best option: learning even a difficult text editor takes a constant and reasonably small amount of time. Being more efficient is a benefit proportional to how much you use the editor. So anybody planning to program for a long time is probably going to be well served by learning a more efficient but "harder" editor. Now, in the real world there are other considerations and the question is more complicated with regards to actual editors. However, given a hypothetical choice between something harder to learn but more efficient or easier to learn but less efficient I'd go for the former each time.
- 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.