8 ms·
Because you only need to know one tool for every type of work you do. Except for inherently graphical tasks like drawing and diagramming. When you use Emacs or
by skummetmaelk 6y ago
Because you only need to know one tool for every type of work you do. Except for inherently graphical tasks like drawing and diagramming.
When you use Emacs or Vim and live on the command line every project has the same workflow. You don't need to install 10 different IDEs and learn 10 different workflows for 10 different projects. You don't need to go through 117 layers of menus to apply compilation options because your IDE invokes the compiler for you. You don't need to use a mouse. No googling "how to X in PyCharm" 5 minutes after googling "How to X in Eclipse".
- garmaine 6y ago> Except for inherently graphical tasks like drawing and diagramming Let me introduce you to graphviz. https://graphviz.org https://graphviz.org
- TeMPOraL 6y agoOr, for the lazy, PlantUML. https://plantuml.com/ https://plantuml.com/ It's backed by Graphviz, but optimized for the kinds of diagrams software people typically do. Works very nicely with org mode too!
- npsimons 6y ago> When you use Emacs or Vim and live on the command line every project has the same workflow. You don't need to install 10 different IDEs and learn 10 different workflows for 10 different projects. When I was demonstrating emacs to some co-workers last week, I opened up code in three different languages and pointed out how the comments were all the exact same color. It's little things like that. And having things like hl-todo-next/previous and flycheck-next/previous-error bound to the same keys in multiple programming languages, or binding F4/F5 to compile/recompile, and that works for any command I want to run, then I can parse through error and warning messages with next/previous-error, or cruise through blocks of code with C-M-a/C-M-e. And all of this works in C/C++, Python, Lisp, Perl, etc.
- saurik 6y agoI have been using my same vim workflow now for twenty years, ever since I switched from Visual C++ 6... and, at the time, I configured some of the colors in vim to match parts of what I had been previously getting from Microsoft's editors. I thereby have had largely consistent colors for like, "a quarter of a century". Despite thinking a lot about syntax highlighting for various reasons, it honestly never once occurred to me--before reading your comment--that some (many?... _most_?!?) software developers don't have consistent syntax highlighting even across different languages much less through their career. OMG.
- remus 6y agoIt may well just be me, but what I find valuable about syntax highlighting isn't the colours per se, but the differentiation between different kinds of token in the language (comments, keywords, argsb etc.) Therefore I don't really notice the individual colours, I notice when the colour changes.
- npsimons 6y agoThis is what I'm talking about. It's that comments are one color, function/method/class/struct definitions are another, keywords are another. And it's the same, no matter what language I'm programming in. Heck, I can open up a language I haven't touched in years (or ever) and just start to get a feel for the structure based on the syntax highlighting alone.
- dleslie 6y agoI love blowing minds with using multiple major modes. IE, executable code snippets in Org, or Javascript inside HTML. There many Emacs packages that can do this, for example: https://polymode.github.io/screenshots/ https://polymode.github.io/screenshots/
- berkes 6y agoThis is really neat. And AFAIK not something that Vim does well. At least, in my vim setup, nested modes are clumsy. Code-inside-markdown means Markdown has to support the syntax (and snippets and shortcuts etc). Or requires a entire language (or dialect) like erb being both Ruby and HTML which cannot leverage the ruby and HTML at the same time, AFAIK. What is, or are the common vim solution for nested or mixed modes?
- jjav 6y agoTo add to all these good points, also the fact that vi/emacs isn't going away on the whim of some company that comes and goes. So the effort to learn these (and any long-lived open source components) is amortized over my lifetime, not the short lifetime of a commercial tool. Whenever I change projects or jobs I know emacs will be there as efficient as always so I can concentrate on being productive instead of on learning yet another ephemeral IDE.
- azemetre 6y agoI haven't even been a developer long, but I remember everyone was using Eclipse then Sublime then Atom then Brackets then VSCode. This was all within a span of 3 years. I've been using vim for most of my career but will use other tools when pairing or working with others, the only thing I regret is not learning the intricacies of vim more. I'm not proficient but every few months I improve more and more, and it's nice to use a tool that has been around for decades and will continue to be around for decades more.
- jnxx 6y ago> I remember everyone was using Eclipse then Sublime then Atom then Brackets then VSCode. This was all within a span of 3 years. Yes. The half-life of these things is rather short. And there are few reasons to expect that this will be better with the IDEs which are currenyly touted by one marketing department or another. In the meantime I am using Emacs since over 20 years. I can adapt it to new things (such as magit) when this is useful but it never breaks my flow.
- jnxx 6y agoThe most important advantage of Emacs and vi are, these are open systems, which come out of an open culture, not just "open source" but really free software, with no strings attached. Granted, open source is having its successes, so companies are trying to jump onto that bandwagon, but this has mainly the consequence that the strings attached are less visible - like "telemetrics", inacceptable spyware, waste of attention, artificial obstacles to competitor languages / systems, unwarranted and empty hype, and so on. It is important to recognize the tone of that, and to listen to it, and to think about it, because it can warn you before making bad decisions. Also, Emacs has top-notch documentation. While basic commands are not that hard to learn, there is certainly a lot of stuff one can learn, so much that it takes some amount of conscious effort to learn a good fraction of what is relevant to certain tasks. That said, Emacs also makes fantastic use of a undervalued property of the human brain, which is automatic decluttering, forgotting and blending out things which are not in use, like a diligent and friendly housemaid which brings anything which you haven't really used in the last year into the attic ;-) But, jokes aside, exactly like learning the Linux command line well, learning some Emacs is an /excellent/ use of ones time as a programmer, because the half-life time of the knowledge you gather is much much longer than when you just learn the latest IDE. Chances are that your IDE du jour will be mostly forgotten five or six years from now. Chances are high that the basic command-line tools and Emacs commands you learn now will still be useful twenty and thirty years from now.
- nicoburns 6y agoThis also applies to using modern graphical text editor such as Sublime Text or VS Code.
- Scarblac 6y agoTbh if I was starting now, I would probably use one of those and be happy with them. But I started using Emacs in 1992, and it still does what I need (thank you language server protocol). Will VS Code exist and offer the same experience over a whole career?
- achikin 6y agoI have started with Visual Studio, then moved to Eclipse, then I've learned Vim and then Emacs and I stuck to Emacs finally.
- bmitc 6y agoI think you may be overly generous to Emacs. When I use Emacs, it's more I need to go through hundreds of lines of others' Emacs Lisp configurations to figure out how to do the thing I want to do or spend many times 5 minutes Googling how to do <x> in Emacs. A good example of this is Elixir's helpful coloring and tab completion in its help documents. When I tried running Iex in an Emacs terminal, it just didn't work, and after Googling, it's just a mess of solutions. It literally just works in Visual Studio Code's terminal. I forced myself to learn Emacs for a class, and it was really quite painful. I get the power of the bindings and all that, but it's really a mess of an ecosystem, and I encountered plenty of bugs. Even then, I never got things to work just right, and it worked poorly when doing things across Windows and WSL boundaries. Another thing was that any time someone used my Emacs, they couldn't because it wasn't like their Emacs. So I've just gotten used to Visual Studio Code because I spend more time doing the thing I wanted to do than finding out how to do something simple in the editor. I add a single custom keybinding for toggling between the terminal and the code window, which can now be synced using a Microsoft account. I just install whatever extension I want (through one extension manager) and go at it. Combine this with the extremely powerful and useful extensions of Remote - SSH and Remote - WSL that allow you to use Visual Studio Code on basically any other computer with your extensions as they work on Windows, then you have a one-stop shop for development. https://code.visualstudio.com/docs/remote/remote-overview https://code.visualstudio.com/docs/remote/remote-overview And by the way, Visual Studio Code can do graphical tasks: https://marketplace.visualstudio.com/items?itemName=hediet.vscode-drawio https://marketplace.visualstudio.com/items?itemName=hediet.v... Is Visual Studio Code perfect? No. Can someone be more productive in Emacs than Visual Studio Code? Yes, but likely only if they've spent an inordinate amount of time learning Emacs and Emacs Lisp. But Visual Studio Code provides a nice balance of a single environment across languages that evolves with users' needs and basically anyone can be productive in it today. My personal preference is to use the standard IDE with whatever language I am using, and then to default to Visual Studio Code whenever there is no such standard. I also use a fair amount of visual languages that text editors do not work for.
- alyandon 6y agoAnother thing was that any time someone used my Emacs, they couldn't because it wasn't like their Emacs. You hit the nail on the head. I spent months forcing myself to use nothing but Emacs to get past the "this is unfamiliar and therefore hard" stage. My final conclusion after the experience was that Emacs is pretty powerful out of the box but it is absolutely a general purpose environment and you have to meld it to your own workflow to truly unlock its potential. Even though I don't use Emacs these days, one thing I did keep was swapping capslock and ctrl on my keyboard. That is useful for so many other things and I'm never going back.
- internet_user 6y agoI've watched someone struggle for literally hours in Emacs wading through dependencies to track down an issue. He then resorted to grep and kept spending time. The same task would be accomplished in one click in Eclipse. There is a reason why specialized tools exist.
- metafunctor 6y agoI don't follow. How is it that graphical tasks require multiple tools, but for every other type of work you need just one tool? That seems just obviously incorrect to me. I do all sorts of things, and use all sorts of tools. Am I missing something?
- burning_hamster 6y agoIf you learn vim or emacs, you will discover that for literally any task that is interacting with text in some form (plain text, code, spreadsheets, presentations), there is almost always an extension in these "text editors" (which really are working environments) that facilitates that work. Hence the claim that you only need to learn one tool rather than a dozen.
- metafunctor 6y agoI've been using Emacs for a lot of things for a quarter of a century. Mostly programming. Or, really, editing program source code plus some haphazard IDE features I've bothered to hack in. Emacs is definitely is not the only tool I need. It is ill suited for graphical tasks, sure, but it is also not the best tool for email, web browsing, taking notes, calendars, and a wide variety of other things. Sure, you CAN do most of those things in Emacs, but it's not the best tool out there for any of them. Emacs is a great IDE, but it simply doesn't exist on most of the platforms I use all the time to make in a realistic contender. Home surveillance? Password management? Backups? Website authoring? Keeping basketball scores? Managing personal photos? Learning a new language? Literally (and NOT figuratively!) most tasks are better done not in Emacs, but some other tool. I'm not sure why this needs to be said out loud. Yes, like a piece of paper, you can use it for any of those tasks. Almost anything can be viewed as a "text task". But it there are better tools out there for almost all of them.
- bitwize 6y ago> Emacs is a great IDE, but it simply doesn't exist on most of the platforms I use all the time to make in a realistic contender. Emacs is available on Windows, Mac, and all extant forms of Unix, so... are you talking about mobile platforms?
- KptMarchewa 6y agoThat's basically what I have with Jetbrains tools. They all look the same, they are just slightly specialized for the language.
- commandlinefan 6y agoRight, but you only have Jetbrains installed locally. It's useless if you're SSH'ed into a remote machine (usually through a jump box for security reasons).
- bitwize 6y agoSo buy the deluxe edition of IntelliJ and you will get the same workflow for most modern programming languages.