7 ms·

Because the experience is so much better. The power of command line is intoxicating, and going to GUI tools files like programming with hands tied behind your b

Because the experience is so much better. The power of command line is intoxicating, and going to GUI tools files like programming with hands tied behind your back and being blindfolded.

ZenoArrow 11y ago
I used to think like this, but I don't any more. Both command line development tools and IDEs require work to get the most out of them. I used to think command line tools were better because I was more in control, then I realised if I just spent the time learning what IDEs were doing on my behalf I would still have more or less the same amount of control, especially if the IDE is customisable (which the best ones are). So with command line tools you have the option to customise your workflow from the ground up, but with IDEs you have the option to customise your workflow from the top down. Both have advantages.
- super_mario 11y ago
  That's decidedly not true. Nor is this about customization of workflows. I am talking about actual unadulterated power to do things you cannot do in an IDE. All IDEs optimize for the average use case. If they do expose a set of advanced commands or transformations, they are hidden deep in the menus and what you can do with them is extremely rigid and limited. At most you have a few dozen commands (you would call them menus) available. Compare that to couple of thousand commands available on the command line that do all sorts of things and that can be combined in useful, creative and often times unexpected ways. All that in addition to having a programmable command interpreter (i.e. the shell itself) that allows you to automated things you do often. Vim is often described as programming your text transformations, well command line is programming your workflow, but it is also more powerful because of the shear number of commands available.
  - toyg 11y ago
    As parent said, good IDEs (like IDEA etc) can be customized to no end. You can remap pretty much all "menu" commands to shortcuts, and they have plenty of interfaces to extend their feature-set through plugins and custom commands to invoke the shell or what-have-you. Honestly, it's not a crime to like nice windows, y'know.
    - super_mario 11y ago
      That's another misconception GUI people seem to have. You can have nice windows and color schemes in Terminal as well (even on Windows is you install MSYS2). Except you get absolute control over your windows layouts and behaviors with tmux and friends. And you don't have to reach for the mouse to interact with any of them.
      - toyg 11y ago
        Looking forward to drop shadows and brushed-metal in tmux, which you shall promptly post. Also fullscreen exposé-like dashboard with previews would be nice.
        TeMPOraL 11y ago
        Like we don't have better things to use our processor cycles on :P. Also, I thought skeuomorphism was dead now?
        cytzol 11y ago
        It doesn't necessarily have to be skeuomorphic, but I like to burn some processor cycles making different things look different, not necessarily brushed-metal attractive. So my todo-list files don't look like my source code files which don't look my terminal windows, which helps me tell what's what. (And it's beside the point, but brushed metal has been dead for years by now!)
        super_mario 11y ago
        Funny enough, iTerm2 has expose for its tabs, but I never use it. It's just not how I work. Drop shadows are not needed, since in iTerm2 or tmux the entire active windows is brighter and all others become slightly greyed out, so you never confuse what has focus. Bushed metal on the other hand is not something I want or desire.
        toyg 11y ago
  - ZenoArrow 11y ago
    > "That's decidedly not true. Nor is this about customization of workflows. I am talking about actual unadulterated power to do things you cannot do in an IDE. All IDEs optimize for the average use case. If they do expose a set of advanced commands or transformations, they are hidden deep in the menus and what you can do with them is extremely rigid and limited. At most you have a few dozen commands (you would call them menus) available." Something tells me instead of telling you what you can customise in good IDEs I should show you. With that in mind, tell me something I shouldn't be able to customise in Visual Studio and I'll show you how its done. To start this off, here's how to create custom keyboard shortcuts, as you can see it's very easy to do: https://visualstudiomagazine.com/blogs/tool-tracker/2012/07/create-keyboard-shortcuts.aspx https://visualstudiomagazine.com/blogs/tool-tracker/2012/07/...
    - super_mario 11y ago
      You are assuming I never use any GUI tools or never try IDEs. I do. I know how customizable most of them are (all except XCode which is absolute garbage). And you can spend a lot of time doing that (writing your own extensions or invoking those external command line tools on your text selections etc), but why bother spending time on that when I can use those tools directly in the command line? And if I'm going to write an extension (that's already programming something) then I might as well do it in the command line, and use it anywhere I can edit text.
      - ZenoArrow 11y ago
        Can you give me one example of a command line tool you wrote to help you get your work done?
        super_mario 11y ago
        Just today I wrote a custom git command to help me sync my branch with master without having to first git checkout master, git pull, git checkout <my_branch>, git rebase master and deal with conflicts. I chose BASH for my language of choice, but could have use Python or Ruby or anything that the shell can execute.
- mikekchar 11y ago
  The thing is, I'm a programmer. I want to extend my tools with code, not configuration. The power of the command line is not so much that it's a command line -- the power is that it is a programmable environment. I'm not limited to configuring what the tools are doing on my behalf. I'm writing my own tools. I think this is the biggest draw for Emacs. It's a fully featured lisp development environment. If you want to change it, you just write lisp. If your IDE is free software, you can do the same thing, but they aren't always that easy to extend. Emacs, shell script, and the various tools are a set of APIs that you can code against. Most IDEs are geared towards giving you a UI interface to the functionality, not a programming API. And that's fair, but not really what I'm after most of the time.
  - ZenoArrow 11y ago
    > "I want to extend my tools with code, not configuration." You can do that with Visual Studio too with Visual Studio Extensions. You can also manage extensions (including those from other users) with a built-in package manager, just like in Emacs. Here's a Visual Studio Extensions tutorial if you're interested: https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Building-Extensions-Part-1 https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Buildi...
    - wtetzner 11y ago
      Yes, but writing a Visual Studio extension (or Eclipse, etc.) is much higher friction than Emacs. In emacs, I can just open a buffer in emacs-lisp-mode, write a quick function, immediately eval it and start using it. The instant feedback means that quick, small customizations are very low cost. It's like the difference between writing a code generator for Java vs using macros in Lisp.
      - ZenoArrow 11y ago
        I see. Can you give me an example of a function you wrote in that way?
        11y ago
cytzol 11y ago
I apologise in advance if this sounds dismissive, but: I've tried to use both Vim and Emacs and Neovim and Spacemacs, and every time my pain point is that they're designed for use on the command line rather than as an environment I can switch in and out of. I know this isn't strictly true as both editors can be run as separate applications that you don't quit for weeks, but their roots have persisted into how they're expected to be used. Take my first foray into vi, at its most basic level. I'm at a shell prompt, where I can use vi to edit multiple files, saving each one when I'm done with it and occasionally switching to another window to run something else, coming back when I need to edit more. But there's nothing storing my list of open files or buffers and where they are on my screen, my position in each file isn't saved; it's like vi expected me to spawn a new instance every five minutes. When I tried emacs, which allows much more functionality inside the editor -- connecting to servers, databases, or hosting shells or debuggers -- it just made the problem worse. If I started a shell inside emacs before stopping the emacs process entirely, that shell won't be there when I get back and my files won't either. If I want to have a specific file on the right-hand side of my screen, emacs will forget where I put it. If I open a file in a new window, that file will be gone. If I want to have a file stand out by changing its background colour to a subtly-different hue, that will have changed back by the time I need to re-open my editor. I don't like this idea; I don't want my editing environment to be some ephemeral process that's created when I start and gets destroyed when I'm finished. And while Vim has sessions and Emacs probably has three forms of saved states, they don't quite work: no saved window positions and sizes, no working with files you haven't given a name. I imagine that it's the same feeling you get when you read that something allows Emacs-like functionality: on a checklist, they might both have tick marks on each row, but when you try to use it, it doesn't work how you expect. I think that Emacs and Vim's command-line history have made its users used to this behaviour, spawning all sorts of tools to make configuring your environment easier instead of just trying to save the changes as they happen. I've seen plugins like CtrlP or projectile that enforce the idea that your environment shouldn't last, you can just set it up again each time. And that means you don't bother personalising your environment and putting things where you want them to be, because it's all going to be irretrievably gone if your computer crashes, so don't get attached. Alright, rant over.
- protomikron 11y ago

Because the experience is so much better. The power of command line is intoxicating, and going to GUI tools files like programming with hands tied behind your back and being blindfolded.

ZenoArrow 11y ago

I used to think like this, but I don't any more. Both command line development tools and IDEs require work to get the most out of them. I used to think command line tools were better because I was more in control, then I realised if I just spent the time learning what IDEs were doing on my behalf I would still have more or less the same amount of control, especially if the IDE is customisable (which the best ones are). So with command line tools you have the option to customise your workflow from the ground up, but with IDEs you have the option to customise your workflow from the top down. Both have advantages.

super_mario 11y ago
That's decidedly not true. Nor is this about customization of workflows. I am talking about actual unadulterated power to do things you cannot do in an IDE. All IDEs optimize for the average use case. If they do expose a set of advanced commands or transformations, they are hidden deep in the menus and what you can do with them is extremely rigid and limited. At most you have a few dozen commands (you would call them menus) available. Compare that to couple of thousand commands available on the command line that do all sorts of things and that can be combined in useful, creative and often times unexpected ways. All that in addition to having a programmable command interpreter (i.e. the shell itself) that allows you to automated things you do often. Vim is often described as programming your text transformations, well command line is programming your workflow, but it is also more powerful because of the shear number of commands available.
- toyg 11y ago
  As parent said, good IDEs (like IDEA etc) can be customized to no end. You can remap pretty much all "menu" commands to shortcuts, and they have plenty of interfaces to extend their feature-set through plugins and custom commands to invoke the shell or what-have-you. Honestly, it's not a crime to like nice windows, y'know.
  - super_mario 11y ago
    That's another misconception GUI people seem to have. You can have nice windows and color schemes in Terminal as well (even on Windows is you install MSYS2). Except you get absolute control over your windows layouts and behaviors with tmux and friends. And you don't have to reach for the mouse to interact with any of them.
    - toyg 11y ago
      Looking forward to drop shadows and brushed-metal in tmux, which you shall promptly post. Also fullscreen exposé-like dashboard with previews would be nice.
      - TeMPOraL 11y ago
        Like we don't have better things to use our processor cycles on :P. Also, I thought skeuomorphism was dead now?
        cytzol 11y ago
        It doesn't necessarily have to be skeuomorphic, but I like to burn some processor cycles making different things look different, not necessarily brushed-metal attractive. So my todo-list files don't look like my source code files which don't look my terminal windows, which helps me tell what's what. (And it's beside the point, but brushed metal has been dead for years by now!)
      - super_mario 11y ago
        Funny enough, iTerm2 has expose for its tabs, but I never use it. It's just not how I work. Drop shadows are not needed, since in iTerm2 or tmux the entire active windows is brighter and all others become slightly greyed out, so you never confuse what has focus. Bushed metal on the other hand is not something I want or desire.
        toyg 11y ago
- ZenoArrow 11y ago
  > "That's decidedly not true. Nor is this about customization of workflows. I am talking about actual unadulterated power to do things you cannot do in an IDE. All IDEs optimize for the average use case. If they do expose a set of advanced commands or transformations, they are hidden deep in the menus and what you can do with them is extremely rigid and limited. At most you have a few dozen commands (you would call them menus) available." Something tells me instead of telling you what you can customise in good IDEs I should show you. With that in mind, tell me something I shouldn't be able to customise in Visual Studio and I'll show you how its done. To start this off, here's how to create custom keyboard shortcuts, as you can see it's very easy to do: https://visualstudiomagazine.com/blogs/tool-tracker/2012/07/create-keyboard-shortcuts.aspx https://visualstudiomagazine.com/blogs/tool-tracker/2012/07/...
  - super_mario 11y ago
    You are assuming I never use any GUI tools or never try IDEs. I do. I know how customizable most of them are (all except XCode which is absolute garbage). And you can spend a lot of time doing that (writing your own extensions or invoking those external command line tools on your text selections etc), but why bother spending time on that when I can use those tools directly in the command line? And if I'm going to write an extension (that's already programming something) then I might as well do it in the command line, and use it anywhere I can edit text.
    - ZenoArrow 11y ago
      Can you give me one example of a command line tool you wrote to help you get your work done?
      - super_mario 11y ago
        Just today I wrote a custom git command to help me sync my branch with master without having to first git checkout master, git pull, git checkout <my_branch>, git rebase master and deal with conflicts. I chose BASH for my language of choice, but could have use Python or Ruby or anything that the shell can execute.
mikekchar 11y ago
The thing is, I'm a programmer. I want to extend my tools with code, not configuration. The power of the command line is not so much that it's a command line -- the power is that it is a programmable environment. I'm not limited to configuring what the tools are doing on my behalf. I'm writing my own tools. I think this is the biggest draw for Emacs. It's a fully featured lisp development environment. If you want to change it, you just write lisp. If your IDE is free software, you can do the same thing, but they aren't always that easy to extend. Emacs, shell script, and the various tools are a set of APIs that you can code against. Most IDEs are geared towards giving you a UI interface to the functionality, not a programming API. And that's fair, but not really what I'm after most of the time.
- ZenoArrow 11y ago
  > "I want to extend my tools with code, not configuration." You can do that with Visual Studio too with Visual Studio Extensions. You can also manage extensions (including those from other users) with a built-in package manager, just like in Emacs. Here's a Visual Studio Extensions tutorial if you're interested: https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Building-Extensions-Part-1 https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Buildi...
  - wtetzner 11y ago
    Yes, but writing a Visual Studio extension (or Eclipse, etc.) is much higher friction than Emacs. In emacs, I can just open a buffer in emacs-lisp-mode, write a quick function, immediately eval it and start using it. The instant feedback means that quick, small customizations are very low cost. It's like the difference between writing a code generator for Java vs using macros in Lisp.
    - ZenoArrow 11y ago
      I see. Can you give me an example of a function you wrote in that way?
      - 11y ago

cytzol 11y ago

I apologise in advance if this sounds dismissive, but: I've tried to use both Vim and Emacs and Neovim and Spacemacs, and every time my pain point is that they're designed for use on the command line rather than as an environment I can switch in and out of. I know this isn't strictly true as both editors can be run as separate applications that you don't quit for weeks, but their roots have persisted into how they're expected to be used. Take my first foray into vi, at its most basic level. I'm at a shell prompt, where I can use vi to edit multiple files, saving each one when I'm done with it and occasionally switching to another window to run something else, coming back when I need to edit more. But there's nothing storing my list of open files or buffers and where they are on my screen, my position in each file isn't saved; it's like vi expected me to spawn a new instance every five minutes. When I tried emacs, which allows much more functionality inside the editor -- connecting to servers, databases, or hosting shells or debuggers -- it just made the problem worse. If I started a shell inside emacs before stopping the emacs process entirely, that shell won't be there when I get back and my files won't either. If I want to have a specific file on the right-hand side of my screen, emacs will forget where I put it. If I open a file in a new window, that file will be gone. If I want to have a file stand out by changing its background colour to a subtly-different hue, that will have changed back by the time I need to re-open my editor. I don't like this idea; I don't want my editing environment to be some ephemeral process that's created when I start and gets destroyed when I'm finished. And while Vim has sessions and Emacs probably has three forms of saved states, they don't quite work: no saved window positions and sizes, no working with files you haven't given a name. I imagine that it's the same feeling you get when you read that something allows Emacs-like functionality: on a checklist, they might both have tick marks on each row, but when you try to use it, it doesn't work how you expect. I think that Emacs and Vim's command-line history have made its users used to this behaviour, spawning all sorts of tools to make configuring your environment easier instead of just trying to save the changes as they happen. I've seen plugins like CtrlP or projectile that enforce the idea that your environment shouldn't last, you can just set it up again each time. And that means you don't bother personalising your environment and putting things where you want them to be, because it's all going to be irretrievably gone if your computer crashes, so don't get attached. Alright, rant over.

protomikron 11y ago