36 ms·

Development Environments

124 points by 8b16380d 4y ago

invalidname 4y ago
I've been programming since well before we had IDEs... I love them. Proper modern IDEs provide a level of insight and tooling that the anti-IDE crowd just don't get. A couple of decades ago they were problematic. But today's unified toolchains and improvements made them far better. The one semi legitimate problem people have is performance. I run on an M1 Max with 64gb of RAM and gave a lot of RAM to IntelliJ (Ultimate). It flies. As professionals we need to spend on our tools and on our hardware to get the most out of both. The depth of insight that IntelliJ allows me at a glance when debugging, reviewing, refactoring, etc. is as a league that is so beyond what the CLI enables. I can't even begin to describe that. To be fair, this isn't universal. E.g. for kernel development, some embedded use cases, etc. the IDE might have less of a benefit. But for most day to day app development avoiding an IDE seems like a Luddite approach.
- anonymoushn 4y ago
  It seems like Java is in a pretty unique place in terms of the quality of the tools and the frequent need to use complex tools to get even a vague idea what's going on.
  - invalidname 4y ago
    True. But Idea Ultimate works surprisingly well with JavaScript and very well with Typescript including react code, etc. It's so much easier than going through NPM noise. Just auto fix and in 95% of the cases it's just what I need. The JetBrains IDEs for other platforms have almost the same level of capabilities. I also worked a lot with xcode, its not nearly as good as AppCode but it's still an improvement over trying to build iOS from the command line... I did that a lot and that isn't a pleasant experience in the least.
    - deleted 4y ago
      [deleted]
    - Macha 4y ago
      I should give it another go I guess. My last serious shake of Jetbrains for JS was on an angular 1 + gulp project a few years ago and it just couldn't do anything helpful.
  - spullara 4y ago
    The only reason Java can even have the most powerful tools is because it is easy to see what is going on. Also, JetBrains does really well with all languages, generally more than any other IDE.
    - anonymoushn 4y ago
      I haven't encountered features in other languages that are pervasively used and work by leaving meaningless markers in the code which some other (typically undocumented, typically in another repository) code will eventually use to do codegen, AST rewriting, and so on. But other than this feature that's like way more difficult than macros in Lisp or C, which makes up like 20% of non-whitespace lines in Java code I have encountered in the last few years, I agree.
      - spullara 4y ago
        If you mean annotations that are easily traceable to the package that provides them, I suppose. That isn't how I program in Java these days but a lot of people do like that style. Honestly though I don't find it much different than Derive in Rust or extension methods in Swift.
  - EdwardDiego 4y ago
    Any large code base benefits from complex tools to get an idea of what's going on. Intellij / PyCharm does remarkably well with large Python code bases lacking type annotations, even if it has to take a guess here and there. But when you add type annotations, it's even better.
- jillesvangurp 4y ago
  I think a professional software engineer can be expected/required to use proper tools. That includes using decent hardware. Fast computers allow you to wait less and waste less time. If you are any good, the accumulated savings in time are worth more than the hardware in a matter of days or weeks. So, don't cheap out on hardware. It's unprofessional. Within reason, you can actually get away with some budget hardware these days. And you can also use remote tools to make your hardware matter even less. But whatever you do, minimize the waste of time. And if you use e.g. rust, kotlin, or js based development tools, you likely have some non trivial build times that can benefit greatly from good CPUs, fast SSDs and enough memory. Those build times add up quickly. I'm old and wise enough to not get between developers and their tool choices no matter how odd they are. So, I tend to give a lot of freedom to my people; and also take that freedom occasionally because I love trying out different things and optimizing my workflow. I love learning from others on how to improve my own workflow. I have a simple rule: your code must be properly formatted, refactored, and free of warnings when you create a pull request. Boy scout rule basically. Anything less than that is sloppy work and I'll call it out and will make you fix it. Always be refactoring and cleaning up code. I don't care how you do it and whether you do it the smart way (using proper tools) or the dumb way (manually using notepad and staring at compiler output) as long as you do it and know how to do it and when to do it. If it looks like you are being clumsy/sloppy/negligent with your tools, I'll have to have a word with you and tell you how to improve. That may include some not so subtle hints about your tool choices.
- ainiriand 4y ago
  CLion for C++ is just brilliant.
- pech0rin 4y ago
  I dunno. I have used a lot of IDEs in my day but I always go back to emacs. I know its not for everyone but I can still have a running python, ruby, etc process and send bits of code to the process and interactively iterate on ideas smoothly. Also with the advent of language servers jump to definition, large refactoring of symbols, etc are pretty straightforward. The number 1 thing I hate about IDEs and will always hate about IDEs is that you open a "workspace" you cannot access all of your files at once. So often I am working with multiple git repos or various things scattered around my computer. In emacs I can simply open the file and have all the syntax highlighting, linting, etc just work. Instead of waiting for 10s for a whole new IDE workspace to open. And then not even have the ability to switch between them easily. Anyway, I don't think I am Luddite and I try to love modern IDEs and editors because everyone says how much more productive they are in them. I honestly have to think that editors are not whats holding back software development, and seems disingenuous to say shying away from them is somehow negative.
  - zorr 4y ago
    The way I get around that is by opening multiple workspaces so I can alt-backtick between them. At least on my setup the ideavim copy buffers are shared between workspaces so I can easily yank from one and paste in the other. It requires a bit of memory though as IJ just works better if you give it a lot of memory. Not really a problem for me as my dev machines have at least 32 or 64G and besides IJ, firefox and a terminal I don't have much open.
  - invalidname 4y ago
    A lot of my friends used emacs back at Sun. Modern IDEs really improved since then and I haven't seen a feature that emacs can do that they can't. Yes a JetBrains IDEs will take longer to build the AST model in RAM but once you have it they do amazing things with it. E.g semantic search and replace, etc. The debugger capabilities are spectacular, they literally show the values of variables on the side of the line you stepped over. Another cool thing, inferred types just show next to the variable definition, parameter names appear in the method call, etc. These are small things that add up to a lot on the day to day. About projects. JetBrains do create project files but don't require a project structure in newer versions of their IDEs. The problem is that IDEs are very simple to pick up and people stop after that basic usage. They have depth that exceeds emacs in some respects.
- parentheses 4y ago
  I’ve yet to give VSCode a fair shake. I used IntelliJ a lot back in the day. IntelliJ is special. Last I had seen they employ their own language tooling for almost everything. Nowadays the CLI (TUI) experience is capable of a LOT. CLI editors have fantastic integration with languages via LSP. You end up with similarly fat but more modular tooling. They offer a modularity and options that give you more choice in building the experience you want. (Not just color schemes and layouts) You have to do more work to configure and learn your tools but it makes so much more personalization of workflow possible. My personal CLI tooling for git is really nice and hacking on it keeps teaching me more about git creating a flywheel of optimization and joy from using things I made. There is a cost to changing your personal workflow. As nice as some new and shiny things appear I don’t like flip flopping on my personal/professional setup. There comes a time when you start fresh. That will be when I try something different.
  - soggybutter 4y ago
    This has been my experience. I'm by no means an IDE power user, but the only things I really missed while using vim were finding references and going to definition. Nowadays I can do that in vim for every language I care about without much configuration or effort, and there's a bunch of additional features available I still leave on the table
- dhzhzjsbevs 4y ago
  Yea but you only need all that junk because you use Java. The rest of us just don't have that many files to refactor when we change things. I don't really hate ide's, I get the appeal, and sometimes it works out useful. It's just that most of the time it comes back to enterprisey software being the source of your problems, not the lack of features in your editor.
  - emsy 4y ago
    Not everyone works on small codebases. Encouraging refactoring is a good thing.
  - pjmlp 4y ago
    Good IDEs precede Java, e.g. Borland products for Turbo Pascal and C++, Common Lisp and Smalltalk environments. The anti-IDE crowd seems to like to pick on Java.
    - deleted 4y ago
      [deleted]
    - Supermancho 4y ago
      > The anti-IDE crowd seems to like to pick on Java. It's largely because Java is verbose. Because of that, the java ecosystem continues to produce frameworks and libraries that make it easier for programmers to convolute their code behind functionally opaque interfaces, eg Spring, Lombok, etc. which also happen to provide "solutions" to reducing repetitive or traditionally verbose code. We have computers to automate processes, primarily. Not using computers to do rote inspection (like argument intellisense or class method discovery), is backward and it helps a great deal until you start using pre-processor annotations which are a series of programs that run before your program is run. 1 step forward, 1 step back. Ofc there are still people who use handmade nails and leaves for toilet paper and they insist it's better than Java. I'm not sure they are wrong.
      - pjmlp 4y ago
        Somehow it is still much better than most hispter frameworks with their interpreted languages and monkey patching galore, or this Google worshipped language thanks its author's pedigree.
- tsujp 4y ago
  What happens when you now want to work in say.. Crystal, or Shell, or Rust, or Zig, or any other language for which there is not an IDE (even those also by JetBrains) which is 1:1 feature compatible to IntelliJ? Not all JetBrains IDEs have the same features. Rider (for .NET) only recently got remote editing support which IntelliJ already had for instance. Now you're only as good as your tool (IntelliJ) and you cannot work with any other language or tool which isn't 1:1 feature complete. If you had an extensible text editor beit vim, neovim, Sublime Text, emacs, VS Code or others then you could add extensions or features per language and keep using your single core tool (said text editor) with a configuration per-language.
  - invalidname 4y ago
    I can use text editors and other IDEs just fine. An IDE gives me more power and for 99% of my work I can live within it. I'm just slower. I used Visual Studio when working with C# which is fine. Not as great. Didn't get a chance to do either Zig or Rust in practice (both look great and I would want to go there). This argument is like arguing against shoes because of "what will you do when you're barefoot".
    - ungamedplayer 4y ago
      I think its more like "what will you do when you need need hiking boots and you've got snow shoes and no budget"
      - invalidname 4y ago
        If I have no budget then I'm probably not a professional. Would you expect a contractor to build your house with just a hammer just because he ran out of cash buying the materials? I accept that some people live in poorer countries. I work with a lot of them and spend a great deal of time abroad. Even they have more powerful machines than the median and they get great discounts for those machines. Maybe not a machine as powerful as this but somethings that can still make the IDE fly.
        4y ago
- pjmlp 4y ago
  Same here, heck even James Gosling, the author of XEmacs and many UNIX utilities, says he would rather use an IDE nowadays.
  - lispm 4y ago
    James Gosling is the author of XEmacs?
    - pjmlp 4y ago
      I got it wrong, https://en.wikipedia.org/wiki/Gosling_Emacs https://en.wikipedia.org/wiki/Gosling_Emacs XEmacs is the Lucid one, https://www.emacswiki.org/emacs/LucidEmacs https://www.emacswiki.org/emacs/LucidEmacs
  - eikenberry 4y ago
    Makes sense as XEmacs was an attempt to make Emacs more IDE like.
- a-dub 4y ago
  the problem i have with ides is that you never know when some boss or it department will stand in the way of your favorite being available. from open source work at home to the most paranoid of high security environments, vim tends to be there pretty reliably.
  - invalidname 4y ago
    This is like saying the problem with using my hands is that I never know when my next job will be a football (soccer) player. I get that it's a muscle you need to practice. But limiting yourself to fit a potential restriction makes no sense.
    - a-dub 4y ago
      i've made use of various windows based microsoft ides, intellij, eclipse, wind river tornado, the qt creator, various activestate ides, various notebook ides and others i probably cannot even remember. i've encountered these ides in various corporate environments in varying degrees of broken where fixes are essentially impossible. (assuming they're available in the first place) i like vim, and other simple open source tools as they work reliably and are reliably available.
    - bandrami 4y ago
      There's something to that argument, though. You probably shouldn't use an IDE when you're learning a language. You should at least understand what it's doing behind the scenes and why.
      - invalidname 4y ago
        I think that when you're learning you should take the easy route and the IDE reduces some of the frustration we get when dealing with simple errors.
        jacobyoder 4y ago
        Good IDE will usually highlight style and basic issues as you're typing them, and you can get a better idea of what 'canonical' foo-lang is. I'm not a ruby expert, but using RubyMine I'm reminded of some things while I'm coding, and (some) errors (or just style issues) are spotted before I run.
- tpoacher 4y ago
  I realise I'm probably alone in this, but this "depth of insight" is exactly one of the curses of IDEs for me. When you write on a terminal, you are encouraged to make good choices so that your code is clean, with a well-thought-out structure and conventions that allow it to be read and processed by a number of tools as painlessly as possible. When you're on the IDE, your code structure invariably reflects whatever workflow template has been defined for that particular IDE, and good conventions matter less because you can always use live links and stuff to inspect stuff via the IDE. Of course, you could argue that there's nothing stopping you from following those good practices on your IDE too, or making the extra effort to configure it with good structure and conventions. But in practice, it's a bit like making the extra mental effort to choose salad when there's steamy melty pizza right in front of you every single time. The temptation to take shortcuts and not think your code out properly and just rely on the IDE to dump its defaults is just too great. In the end, when you compare (professional) well-thought out code written in a terminal vs templated code written in an IDE, I feel that the difference in quality is often palpable. Also, I reject the idea that "tooling" is a concept unique to IDEs (or, in any case, that IDEs should necessarily imply superior "tooling"). Yes they offer the convenience of a suitethat is (hopefully) interoperable by design, but for me arguing that this makes them better tools is a bit like saying the Apple Store has better software than "the internet" and you should therefore only stick to Apple Store stuff.
  - rvdginste 4y ago
    I think it's a bit naive to think that a given developer will produce better code when using an editor instead of an IDE. I believe that a certain developer will produce the same quality code whether he uses an editor or an IDE. If you use default templates and don't really care about the structure of your code when using an IDE, you won't suddenly start to care when using an editor. If you don't care about all kinds of shortcuts and specific functionality in your editor, you won't care about learning the shortcuts (and even functionality) in your IDE. Some people seem to think they will become better developers by learning to do their development with an editor, but I do not believe that is true. Maybe except for one thing: if you do use an editor and don't use something like LSP in your editor, you will be forced to memorise the standard libraries of your programming language; you need to memorise those to stay productive with an editor. And in general, I do believe that the pure text editing part is often more advanced in a good editor than in an IDE. But, a good IDE is an amazing tool when you have the hardware to run it. Especially with typed languages, an IDE makes it a lot easier to refactor code and change the design of your code. This really lowers the threshold to change the design of your code when requirements change. Since the changes are simple and fast, developers are more confident to do those changes and will consider those changes in more cases. And aside from that, IDEs also often include an analysis part and warn you about fishy things in your code. I have been an Emacs user for a very long time. I used it for C long time ago, and recently used (limited) it with an LSP server for C# (using the Doom Emacs distribution). And that is working nicely: magit is great, integration with LSP servers is great... you can get a lot of the stuff that is typical for IDEs. But when you do activate all those integrations, you will notice that it is also heavier to run and less responsive. So, in the end, when the hardware can run it, my preference is still the full-blown Rider IDE for C#. The IDE is much more complete out-of-the-box.
- eikenberry 4y ago
  IMO this has 2 issues. #1 If you need an IDE to handle simple things like you list I think the language's development model is designed with IDEs in mind (eg. Java). Better language support and tooling makes all these things trivial without an IDE. #2 There are no good Free Software IDEs and I will not make ethical compromises with my maker tooling.
  - invalidname 4y ago
    Java didn't have a decent IDE for the first 10 years of its existence and I hated IntelliJ/NetBeans etc. when I first used them. The tools improved. They work great for all the languages I use. I'm not smart enough to keep an entire code base of every project I ever worked on in my head. Maybe you're a genius of a different level, even then... Wouldn't it make sense to clear the area of your brain that needs to remember every parameter name to a method call so the IDE will show that to you. IntelliJ community is free and open source. NetBeans too and it's decent. So is Eclipse. VSCode isn't exactly an IDE so I won't go into that.
    - eikenberry 4y ago
      You don't need an IDE to get, eg. function parameters, all normal programming oriented text editors do this now. IMO all of the 'editor' focused parts of IDEs are done great by the programming oriented text editors. It is the non-editor parts where IDEs differentiate themselves. Integrating testing, debugging, project management, refactoring, etc. Some of these things IDEs do pretty well and would be nice but they are not worth the tradeoffs you give up IMO. I prefer the looser coupling and composition you get with CLI oriented tools and value those aspects over the limited things that IDEs would offer. And none of this covers the fact that none of the good IDEs are Free Software. Which automatically removes them from consideration.
      - invalidname 4y ago
        Editors get this wrong when there are multiple complex and overriden functions/methods. Furthermore, they can't display things in the same way an IDE displays them. I suggest checking out a modern (admittedly non-free but open source) IDE. JetBrains displays argument names in an ineditable area next to the argument values. When debugging it shows the values that changed in each line in an area next to the line of code. It's amazing.
- analog31 4y ago
  What finally pushed me to use an IDE was the code inspection tools running in the background, and lighting up my likely bugs and style mistakes. So it's actually reacting to my code and doing something, rather than just flooding me with information. For now, Spyder (for Python) is just right. VSCode is too much, and I haven't figured out how to turn off the features that I don't care about.
- Narishma 4y ago
  > I run on an M1 Max with 64gb of RAM and gave a lot of RAM to IntelliJ (Ultimate). It flies. As professionals we need to spend on our tools and on our hardware to get the most out of both. The problem with that is you'll more than likely create applications that work fine on your fancy high-end systems but end up unusably slow on normal people's hardware.
  - invalidname 4y ago
    That's why we have software testers. Most of the stuff I build nowadays is server backend stuff and mobile. For server backend this runs on strong machines. No problem. For mobile I use a device. For desktop stuff we have a minimum machine which we test. Also IDE's have profilers integrated where you can see if you take up too much RAM or CPU. There's no need to suffer slow performance to create apps that run in constrained resources. You can have more than one computer too. Even as a one person shop.
- bitwize 4y ago
  If you need an IDE to manage the complexity in large, complex software projects, then you need an IDE for the kernel -- one of the largest, most complex single software projects around. IDEs are written for this purpose -- modern CodeWarrior, for one. The fact that many kernel devs including Linus himself get along fine without one suggests that IDEs are not the universal good you seem to think they are. In particular, they are great if you follow the happy path anticipated by the IDE developers, but when things get weird, the IDE won't help you. So I tend to see a lot of IDE users alt-tabbing between their IDE, terminals, Postman, DBVisualizer, and what else have you which plays havoc with my brain and would only slow me down if that were my workflow. There's a perspective dependency to whatever the best tool for the job is. Some people can't live without a bell- and whistle-laden IDE; I can't live without a code editing tool that I can shape to my needs while I'm using it Which is why I won't be giving up Emacs any time soon.
  - invalidname 4y ago
    I accept that I'm not nearly as smart as Linus. Also most Kernel developers know their own relatively narrow module not the entire project. Again, I programmed without an IDE (in Java too) and manage that completely fine. Just like I can walk barefoot without shoes. Same thing. It's a power tool that provides amazing capabilities. I go out of the IDE a lot too. I prefer using the native terminal rather than the one builtin the IDE (although some use that and that's fine) we each have our habits. CTO of my current company is a VIM nut. Uses it a lot. And an IDE. He uses each in the context he sees fit to his needs. I used to see a lot of people at my later days in Oracle (after the Sun acquisition) switching between Emacs and an IDE back and forth. Sometimes even on the same project. Each tool has its own power. It isn't a zero sum game between the two. I use external editors too for the right things.
  - crummy 4y ago
    > I tend to see a lot of IDE users alt-tabbing between their IDE, terminals, Postman, DBVisualizer For what it's worth, IntelliJ use an IDE with an inbuilt terminal, HTTP client, and DB GUI.
- alexvoda 4y ago
  I would say that for embedded, your logic analyzer and you oscilloscope are actually part of the IDE. Embedded devs have the fanciest of IDEs.
mcint 4y ago
The workflows enabled by Jupyter and iPython address some of your biggest concerns. You have references to previous outputs, don't recompute things, and in browser can have GUI interactive elements. You can likely find live streaming monitors too. Though that starts to break what the environment is best at: composing an edited, rational path through a process based on interactive exploration, trial and error. https://en.wikipedia.org/wiki/Project_Jupyter#Jupyter_Notebook https://en.wikipedia.org/wiki/Project_Jupyter#Jupyter_Notebo...
- anothernewdude 4y ago
  The problem with in browser anything is that editing text in the browser sucks. It steals a lot of key bindings you can never get back, it allows for selection of the wrong element. Also notebooks are a horrible way of working. They encourage code to get extremely unwieldy and make managing state harder than it needs to be.
aaws11 4y ago
site gives 404 error when I try reloading it. firefox on windows
linguae 4y ago
One part of the article that resonates with me is the need for composable software that uses a more sophisticated mechanism than Unix pipes to connect components to provide an integrated experience. Over the past few years I've been interested in the idea of component-based software through IPC protocols and metaprogramming. This year I've been playing around with Plan 9, and I've found its ideas of component-based software through the 9p protocol interesting. I also got to spend some time using acme, which is one of the editors that comes with Plan 9. What makes acme interesting is that I can run external commands in the editor to perform various tasks, ranging from text manipulations to tasks such as compiling code. Each output shows up as its own window pane. One could create a sort of IDE using acme's ability to run external commands. While acme can seamlessly support external commands, a limitation, however, is there is no metaprogramming facility for changing the functionality of the editor itself. This makes acme less powerful than Emacs, which has the Emacs Lisp subsystem for extending and modifying the behavior of the editor. For example, suppose I wanted to add syntax highlighting to acme. Doing so requires modifying acme's source code. However, if acme provided some type of metaprogramming interface to the editor, then I could write code adding syntax highlighting. Ideally, this metaprogramming interface should be language-agnostic and take advantage of the 9p protocol. This would make acme just as powerful as Emacs, and in fact would give acme an advantage since extending acme won't require a specific language. Come to think of it, some of this metaprogramming capability may already be present in Plan 9 through the use of the /proc directory, thus obviating the need for application-specific metaprogramming mechanisms, though its offered at the binary level. I'll have to investigate this some more, though. My thought is that sophisticated IPC protocols and support for application-level metaprogramming can provide the rich interoperability that the writer of the article wants for creating composable development environments.
davidkunz 4y ago
"Modern" IDEs suck. They are not meant to be _fully_ controlled by the keyboard, have delays, cluttered UIs and interrupt your workflow with popups. That's why I prefer Neovim. https://youtu.be/9wsl6wvjdCg https://youtu.be/9wsl6wvjdCg
namaria 4y ago
I understand where the author is coming from and I myself sympathize with the idea of sticking to Unix philosophy of composing small focused tools instead of using complicated tools. That said, I have learned to stick to defaults and start from a clean slate every time. I often say that the main problem in software is containing complexity. When you need to deliver a product that works reliably, you want to remove all but essential concerns from your routine work. So I'd rather create a clean VM, install git CLI, VSCode, write a Dockerfile and get a nice clean package. If I learn how to use everyone of these tools out of the box with the default configuration, then I never have to think about dotfiles, plugins, set up etc. I think we need more software hygiene. Keep environments clean and ready to go.
- truffdog 4y ago
  My experience is that IDEs do not really support that sort of clean separation- you're always fighting to get it to support your VM or Dockerfile.
- chriswarbo 4y ago
  > write a Dockerfile I was sort-of agreeing with you until this point. In my experience "write a Dockerfile" usually means "run a bunch of fragile, non-deterministic nonsense, like `apt-get update && apt-get -y install`, `yum install`, `pip install`, `npm install`, etc.; often all at the same time!" (AWS are a serial offender IMHO, e.g. their documentation recommends this sort of crap https://docs.aws.amazon.com/lambda/latest/dg/images-create.html#images-create-from-alt https://docs.aws.amazon.com/lambda/latest/dg/images-create.h... https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html#user-data-launch-instance-wizard https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-dat... etc.)
  - meatmanek 4y ago
    Docker is a way of taking fragile, non-deterministic things like package installations, and make them less fragile, in very practically-useful ways. Compared to the old way of doing these things (which would likely be a shell script that would run those exact same apt-get/pip/yum/npm install commands), Dockerfiles give you: - a much more predictable starting state, which lets you remove a bunch of complexity from your installation script. The old style of installation script might need to detect which OS it's running on, which version of Python is installed, whether you're using GCC or clang, whether libgomp or lzma or whatever is installed, whether or not the script is running as root, whether or not there are existing sites configured in the local nginx install. With a Dockerfile built on a slow-moving image, you can know exactly where everything is, what version is installed, and whether there are any other conflicting applications. - limiting side effects (As a user, you can be fairly sure that a `docker build` isn't going to clobber your nginx configs.) Containers have a whole pile of downsides, but making builds _more_ fragile is not really one of them.
chriswarbo 4y ago
I agree that it would be nice to cache a command's output, so we can iterate processes on it. I'm a heavy user of Emacs, which is based around "buffers", so should naturally support such a workflow; yet in the decade I've been using it, such a workflow hasn't really occurred to me. Emacs makes it easy to run commands, e.g. with M-&; the output goes into a buffer called `Async Shell Command`. Unfortunately, that buffer gets replaced each time we run a command. It's common to override this behaviour (as I do), so a new buffer gets spawned each time, which gets a bit closer to that workflow. Still, I've never really used this to chain commands together; this post has inspired me to try that a bit more :)
- jrop 4y ago
  This is how I use NeoVim's terminal: run a command, visually select the lines I want to operate on and yank them, then paste them in a new buffer. After that, it's a matter of transforming the text via whatever means one normally does (macros, text objects, search/replace, etc.)
  - chriswarbo 4y ago
    Manipulating text within the editor is pretty common; e.g. I use shell-mode in Emacs, which is mostly just a normal text buffer (except Return acts differently when the cursor is over the commandline!); eshell is similar. What I was describing above is manipulating such buffers with external commands (similar to Emacs `shell-command-on-region`)
sirsinsalot 4y ago
Many people seem to think using a commercial proprietary IDE means you somehow forget how to use the CLI or other editors to get the job done. Like they're junk food that makes you dumb. This is as ridiculous as saying an electrician will forget how to correctly wire because their wire cutters are too good. I used to be a build-my-own IDE person via VIM. After using PyCharm and realising an IDE is more than an editor, I realise the productivity gains every day. If I need VIM or something else, it's just another tool in the box and the partisan fist shaking has no place in a mature profession and trade.
- anotherhue 4y ago
  It's not that one has forgotten, it's that one never learned. I watch senior engineers struggle with basic CLI usage daily. In the modern sense of Senior of course.
  - sirsinsalot 4y ago
    Well the modern sense of senior leaves it likely that they have not yet learned to dress themselves either. That aside, what one doesn't learn doesn't mean the mistake is what one does. Just that they didn't.
- annowiki 4y ago
  I consider myself quite adept at cli, I can sed, grep, find, vim, and git quite well. However, what I never found convenient in cli was debugging. I was a print debugger for years until my job convinced me to try PyCharm. I've always thought the reason I never found a suitable debugger in cli was just because I was either too dumb to figure out integrating something like vimspector, or too lazy to get used to gdb/pdb. Ctrl-f on this article has no mention of the word "debug." I think I'm not the only one that never used a debugger before I tried an IDE. I wonder how many people still feel superior in their CLI-Vim/Emacs-only workflow and are just print debugging.
  - jrop 4y ago
    I use NeoVim for everything except debugging. For that I (frequently) open up VSCode or Chrome to debug (NodeJS). I haven't figured out a good debug workflow for Rust, though, because I hate print debugging.
timberfox 4y ago
My experience is quite different: I feel extremely productive working in the terminal, and what is described in the article as "The frozen world" is for me a virtue of the UNIX philosophy: the structure is not embedded in the data, but the programs can project a structure on it. That allows programs to be filters, and text to be the only format for exchanging information. What the article describes as "The nightmare that is composition iteration" is for me a very pleasant experience: the terminal provides a very fast feedback loop where I can iteratively examine the output of a command and refine the filters I apply. As a result, I am able to prototype commands quickly and accurately.
- Firadeoclus 4y ago
  > the terminal provides a very fast feedback loop where I can iteratively examine the output of a command and refine the filters I apply. As a result, I am able to prototype commands quickly and accurately. That's what any REPL does. And it works great with typed data. Sometimes even with graphical output.
- nomel 4y ago
  > the terminal provides a very fast feedback loop where I can iteratively examine the output of a command and refine the filters I apply An IDE would be used to develop those commands, more than compose them. > text to be the only format for exchanging information For this to work, with non-text data, you end up using the file system as a buffer, then passing filepaths between commands. For many contexts, this isn't performant enough.
z9znz 4y ago
There are four things which IDEs typically provide which I find invaluable. It's probable that some or maybe even all of them could be wedged into Vim or Emacs, but then you'd have basically an IDE. 1. Quick go to _anything_. In IntelliJ IDEs, it's double-shift, and then start typing some of what you want. Usually you can find the class or module or file you want easily, if not automatically. 2. Interactive debugging. This is so very useful. Usually it's just the fastest way for me to inspect a data structure at a certain point in time, or even find out what's going on in a framework that uses a lot of metaprogramming. 3. Jump to definition of thing (function, constant, etc.), and conversely show usages. In a well designed system of composable single responsibility functions, one can almost forget about files and navigate only with these (and (1)). 4. Git diff my branch to branch X. Lots of extra goodies can be included in this, such as interactive merge conflict tooling, etc.
- sunsunsunsun 4y ago
  My neovim does all of this and more. Yes ive blurred the lines of text editor and IDE. I enjoy the portability, speed, and customization it offers. I also like that I have everything I need in the terminal. Its not for everyone though and it takes a lot of time to customize it perfectly for you.
- spoils19 4y ago
  I'm able to do all these with a simple text editor, an IDE takes up resources, implements tracking, and real programmers basically have no use for anything aside from a simple text editor.
  - 9dev 4y ago
    Is that the classical „real men don’t need guns, we kill with our bare hands“?
  - IshKebab 4y ago
    Bit of a stretch to describe something that has all the features of an IDE as a "simple text editor". Notepad is a simple text editor. What you have is a text editor that you've (presumably) augmented with a ton of plugins to turn it into a full IDE.
RcouF1uZ4gsC 4y ago
>We could write a code / text editor that wouldn’t have to be worried about extensions like Git: the Git support would come as a native application (equivalent of the CLI git application) that would open an overlay, for instance. That application wouldn’t even know about the code editor: you would make that connection via the platform. >Applications could communicate between each other to manipulate buffers, get the contents of the buffer and do various kind of operations on them (LSP servers, for instance). >Because the protocol would be completely rendering-agnostic, that would allow people to write an application that would work for any kind of “platform implementations.” Composition would use the low-level protocol to compose applications. You could imagine supporting an interface between applications allowing to filter the contents of the buffer of one by using another application. Applications such as fzf could branch on the buffers of a text editor, for instance. Or you could even open a buffer in the text editor by running a fuzzy finder as another application. All of that would compose in a seamless way. Etc. etc. Actually this sounds a lot like OLE 2.0 from 1995.

124 points by 8b16380d 4y ago

I've been programming since well before we had IDEs... I love them. Proper modern IDEs provide a level of insight and tooling that the anti-IDE crowd just don't get. A couple of decades ago they were problematic. But today's unified toolchains and improvements made them far better. The one semi legitimate problem people have is performance. I run on an M1 Max with 64gb of RAM and gave a lot of RAM to IntelliJ (Ultimate). It flies. As professionals we need to spend on our tools and on our hardware to get the most out of both. The depth of insight that IntelliJ allows me at a glance when debugging, reviewing, refactoring, etc. is as a league that is so beyond what the CLI enables. I can't even begin to describe that. To be fair, this isn't universal. E.g. for kernel development, some embedded use cases, etc. the IDE might have less of a benefit. But for most day to day app development avoiding an IDE seems like a Luddite approach.

anonymoushn 4y ago
It seems like Java is in a pretty unique place in terms of the quality of the tools and the frequent need to use complex tools to get even a vague idea what's going on.
- invalidname 4y ago
  True. But Idea Ultimate works surprisingly well with JavaScript and very well with Typescript including react code, etc. It's so much easier than going through NPM noise. Just auto fix and in 95% of the cases it's just what I need. The JetBrains IDEs for other platforms have almost the same level of capabilities. I also worked a lot with xcode, its not nearly as good as AppCode but it's still an improvement over trying to build iOS from the command line... I did that a lot and that isn't a pleasant experience in the least.
  - deleted 4y ago
    [deleted]
  - Macha 4y ago
    I should give it another go I guess. My last serious shake of Jetbrains for JS was on an angular 1 + gulp project a few years ago and it just couldn't do anything helpful.
- spullara 4y ago
  The only reason Java can even have the most powerful tools is because it is easy to see what is going on. Also, JetBrains does really well with all languages, generally more than any other IDE.
  - anonymoushn 4y ago
    I haven't encountered features in other languages that are pervasively used and work by leaving meaningless markers in the code which some other (typically undocumented, typically in another repository) code will eventually use to do codegen, AST rewriting, and so on. But other than this feature that's like way more difficult than macros in Lisp or C, which makes up like 20% of non-whitespace lines in Java code I have encountered in the last few years, I agree.
    - spullara 4y ago
      If you mean annotations that are easily traceable to the package that provides them, I suppose. That isn't how I program in Java these days but a lot of people do like that style. Honestly though I don't find it much different than Derive in Rust or extension methods in Swift.
- EdwardDiego 4y ago
  Any large code base benefits from complex tools to get an idea of what's going on. Intellij / PyCharm does remarkably well with large Python code bases lacking type annotations, even if it has to take a guess here and there. But when you add type annotations, it's even better.
jillesvangurp 4y ago
I think a professional software engineer can be expected/required to use proper tools. That includes using decent hardware. Fast computers allow you to wait less and waste less time. If you are any good, the accumulated savings in time are worth more than the hardware in a matter of days or weeks. So, don't cheap out on hardware. It's unprofessional. Within reason, you can actually get away with some budget hardware these days. And you can also use remote tools to make your hardware matter even less. But whatever you do, minimize the waste of time. And if you use e.g. rust, kotlin, or js based development tools, you likely have some non trivial build times that can benefit greatly from good CPUs, fast SSDs and enough memory. Those build times add up quickly. I'm old and wise enough to not get between developers and their tool choices no matter how odd they are. So, I tend to give a lot of freedom to my people; and also take that freedom occasionally because I love trying out different things and optimizing my workflow. I love learning from others on how to improve my own workflow. I have a simple rule: your code must be properly formatted, refactored, and free of warnings when you create a pull request. Boy scout rule basically. Anything less than that is sloppy work and I'll call it out and will make you fix it. Always be refactoring and cleaning up code. I don't care how you do it and whether you do it the smart way (using proper tools) or the dumb way (manually using notepad and staring at compiler output) as long as you do it and know how to do it and when to do it. If it looks like you are being clumsy/sloppy/negligent with your tools, I'll have to have a word with you and tell you how to improve. That may include some not so subtle hints about your tool choices.
ainiriand 4y ago
CLion for C++ is just brilliant.
pech0rin 4y ago
I dunno. I have used a lot of IDEs in my day but I always go back to emacs. I know its not for everyone but I can still have a running python, ruby, etc process and send bits of code to the process and interactively iterate on ideas smoothly. Also with the advent of language servers jump to definition, large refactoring of symbols, etc are pretty straightforward. The number 1 thing I hate about IDEs and will always hate about IDEs is that you open a "workspace" you cannot access all of your files at once. So often I am working with multiple git repos or various things scattered around my computer. In emacs I can simply open the file and have all the syntax highlighting, linting, etc just work. Instead of waiting for 10s for a whole new IDE workspace to open. And then not even have the ability to switch between them easily. Anyway, I don't think I am Luddite and I try to love modern IDEs and editors because everyone says how much more productive they are in them. I honestly have to think that editors are not whats holding back software development, and seems disingenuous to say shying away from them is somehow negative.
- zorr 4y ago
  The way I get around that is by opening multiple workspaces so I can alt-backtick between them. At least on my setup the ideavim copy buffers are shared between workspaces so I can easily yank from one and paste in the other. It requires a bit of memory though as IJ just works better if you give it a lot of memory. Not really a problem for me as my dev machines have at least 32 or 64G and besides IJ, firefox and a terminal I don't have much open.
- invalidname 4y ago
  A lot of my friends used emacs back at Sun. Modern IDEs really improved since then and I haven't seen a feature that emacs can do that they can't. Yes a JetBrains IDEs will take longer to build the AST model in RAM but once you have it they do amazing things with it. E.g semantic search and replace, etc. The debugger capabilities are spectacular, they literally show the values of variables on the side of the line you stepped over. Another cool thing, inferred types just show next to the variable definition, parameter names appear in the method call, etc. These are small things that add up to a lot on the day to day. About projects. JetBrains do create project files but don't require a project structure in newer versions of their IDEs. The problem is that IDEs are very simple to pick up and people stop after that basic usage. They have depth that exceeds emacs in some respects.
parentheses 4y ago
I’ve yet to give VSCode a fair shake. I used IntelliJ a lot back in the day. IntelliJ is special. Last I had seen they employ their own language tooling for almost everything. Nowadays the CLI (TUI) experience is capable of a LOT. CLI editors have fantastic integration with languages via LSP. You end up with similarly fat but more modular tooling. They offer a modularity and options that give you more choice in building the experience you want. (Not just color schemes and layouts) You have to do more work to configure and learn your tools but it makes so much more personalization of workflow possible. My personal CLI tooling for git is really nice and hacking on it keeps teaching me more about git creating a flywheel of optimization and joy from using things I made. There is a cost to changing your personal workflow. As nice as some new and shiny things appear I don’t like flip flopping on my personal/professional setup. There comes a time when you start fresh. That will be when I try something different.
- soggybutter 4y ago
  This has been my experience. I'm by no means an IDE power user, but the only things I really missed while using vim were finding references and going to definition. Nowadays I can do that in vim for every language I care about without much configuration or effort, and there's a bunch of additional features available I still leave on the table
dhzhzjsbevs 4y ago
Yea but you only need all that junk because you use Java. The rest of us just don't have that many files to refactor when we change things. I don't really hate ide's, I get the appeal, and sometimes it works out useful. It's just that most of the time it comes back to enterprisey software being the source of your problems, not the lack of features in your editor.
- emsy 4y ago
  Not everyone works on small codebases. Encouraging refactoring is a good thing.
- pjmlp 4y ago
  Good IDEs precede Java, e.g. Borland products for Turbo Pascal and C++, Common Lisp and Smalltalk environments. The anti-IDE crowd seems to like to pick on Java.
  - deleted 4y ago
    [deleted]
  - Supermancho 4y ago
    > The anti-IDE crowd seems to like to pick on Java. It's largely because Java is verbose. Because of that, the java ecosystem continues to produce frameworks and libraries that make it easier for programmers to convolute their code behind functionally opaque interfaces, eg Spring, Lombok, etc. which also happen to provide "solutions" to reducing repetitive or traditionally verbose code. We have computers to automate processes, primarily. Not using computers to do rote inspection (like argument intellisense or class method discovery), is backward and it helps a great deal until you start using pre-processor annotations which are a series of programs that run before your program is run. 1 step forward, 1 step back. Ofc there are still people who use handmade nails and leaves for toilet paper and they insist it's better than Java. I'm not sure they are wrong.
    - pjmlp 4y ago
      Somehow it is still much better than most hispter frameworks with their interpreted languages and monkey patching galore, or this Google worshipped language thanks its author's pedigree.
tsujp 4y ago
What happens when you now want to work in say.. Crystal, or Shell, or Rust, or Zig, or any other language for which there is not an IDE (even those also by JetBrains) which is 1:1 feature compatible to IntelliJ? Not all JetBrains IDEs have the same features. Rider (for .NET) only recently got remote editing support which IntelliJ already had for instance. Now you're only as good as your tool (IntelliJ) and you cannot work with any other language or tool which isn't 1:1 feature complete. If you had an extensible text editor beit vim, neovim, Sublime Text, emacs, VS Code or others then you could add extensions or features per language and keep using your single core tool (said text editor) with a configuration per-language.
- invalidname 4y ago
  I can use text editors and other IDEs just fine. An IDE gives me more power and for 99% of my work I can live within it. I'm just slower. I used Visual Studio when working with C# which is fine. Not as great. Didn't get a chance to do either Zig or Rust in practice (both look great and I would want to go there). This argument is like arguing against shoes because of "what will you do when you're barefoot".
  - ungamedplayer 4y ago
    I think its more like "what will you do when you need need hiking boots and you've got snow shoes and no budget"
    - invalidname 4y ago
      If I have no budget then I'm probably not a professional. Would you expect a contractor to build your house with just a hammer just because he ran out of cash buying the materials? I accept that some people live in poorer countries. I work with a lot of them and spend a great deal of time abroad. Even they have more powerful machines than the median and they get great discounts for those machines. Maybe not a machine as powerful as this but somethings that can still make the IDE fly.
      - 4y ago
pjmlp 4y ago
Same here, heck even James Gosling, the author of XEmacs and many UNIX utilities, says he would rather use an IDE nowadays.
- lispm 4y ago
  James Gosling is the author of XEmacs?
  - pjmlp 4y ago
    I got it wrong, https://en.wikipedia.org/wiki/Gosling_Emacs https://en.wikipedia.org/wiki/Gosling_Emacs XEmacs is the Lucid one, https://www.emacswiki.org/emacs/LucidEmacs https://www.emacswiki.org/emacs/LucidEmacs
- eikenberry 4y ago
  Makes sense as XEmacs was an attempt to make Emacs more IDE like.
a-dub 4y ago
the problem i have with ides is that you never know when some boss or it department will stand in the way of your favorite being available. from open source work at home to the most paranoid of high security environments, vim tends to be there pretty reliably.
- invalidname 4y ago
  This is like saying the problem with using my hands is that I never know when my next job will be a football (soccer) player. I get that it's a muscle you need to practice. But limiting yourself to fit a potential restriction makes no sense.
  - a-dub 4y ago
    i've made use of various windows based microsoft ides, intellij, eclipse, wind river tornado, the qt creator, various activestate ides, various notebook ides and others i probably cannot even remember. i've encountered these ides in various corporate environments in varying degrees of broken where fixes are essentially impossible. (assuming they're available in the first place) i like vim, and other simple open source tools as they work reliably and are reliably available.
  - bandrami 4y ago
    There's something to that argument, though. You probably shouldn't use an IDE when you're learning a language. You should at least understand what it's doing behind the scenes and why.
    - invalidname 4y ago
      I think that when you're learning you should take the easy route and the IDE reduces some of the frustration we get when dealing with simple errors.
      - jacobyoder 4y ago
        Good IDE will usually highlight style and basic issues as you're typing them, and you can get a better idea of what 'canonical' foo-lang is. I'm not a ruby expert, but using RubyMine I'm reminded of some things while I'm coding, and (some) errors (or just style issues) are spotted before I run.
tpoacher 4y ago
I realise I'm probably alone in this, but this "depth of insight" is exactly one of the curses of IDEs for me. When you write on a terminal, you are encouraged to make good choices so that your code is clean, with a well-thought-out structure and conventions that allow it to be read and processed by a number of tools as painlessly as possible. When you're on the IDE, your code structure invariably reflects whatever workflow template has been defined for that particular IDE, and good conventions matter less because you can always use live links and stuff to inspect stuff via the IDE. Of course, you could argue that there's nothing stopping you from following those good practices on your IDE too, or making the extra effort to configure it with good structure and conventions. But in practice, it's a bit like making the extra mental effort to choose salad when there's steamy melty pizza right in front of you every single time. The temptation to take shortcuts and not think your code out properly and just rely on the IDE to dump its defaults is just too great. In the end, when you compare (professional) well-thought out code written in a terminal vs templated code written in an IDE, I feel that the difference in quality is often palpable. Also, I reject the idea that "tooling" is a concept unique to IDEs (or, in any case, that IDEs should necessarily imply superior "tooling"). Yes they offer the convenience of a suitethat is (hopefully) interoperable by design, but for me arguing that this makes them better tools is a bit like saying the Apple Store has better software than "the internet" and you should therefore only stick to Apple Store stuff.
- rvdginste 4y ago
  I think it's a bit naive to think that a given developer will produce better code when using an editor instead of an IDE. I believe that a certain developer will produce the same quality code whether he uses an editor or an IDE. If you use default templates and don't really care about the structure of your code when using an IDE, you won't suddenly start to care when using an editor. If you don't care about all kinds of shortcuts and specific functionality in your editor, you won't care about learning the shortcuts (and even functionality) in your IDE. Some people seem to think they will become better developers by learning to do their development with an editor, but I do not believe that is true. Maybe except for one thing: if you do use an editor and don't use something like LSP in your editor, you will be forced to memorise the standard libraries of your programming language; you need to memorise those to stay productive with an editor. And in general, I do believe that the pure text editing part is often more advanced in a good editor than in an IDE. But, a good IDE is an amazing tool when you have the hardware to run it. Especially with typed languages, an IDE makes it a lot easier to refactor code and change the design of your code. This really lowers the threshold to change the design of your code when requirements change. Since the changes are simple and fast, developers are more confident to do those changes and will consider those changes in more cases. And aside from that, IDEs also often include an analysis part and warn you about fishy things in your code. I have been an Emacs user for a very long time. I used it for C long time ago, and recently used (limited) it with an LSP server for C# (using the Doom Emacs distribution). And that is working nicely: magit is great, integration with LSP servers is great... you can get a lot of the stuff that is typical for IDEs. But when you do activate all those integrations, you will notice that it is also heavier to run and less responsive. So, in the end, when the hardware can run it, my preference is still the full-blown Rider IDE for C#. The IDE is much more complete out-of-the-box.
eikenberry 4y ago
IMO this has 2 issues. #1 If you need an IDE to handle simple things like you list I think the language's development model is designed with IDEs in mind (eg. Java). Better language support and tooling makes all these things trivial without an IDE. #2 There are no good Free Software IDEs and I will not make ethical compromises with my maker tooling.
- invalidname 4y ago
  Java didn't have a decent IDE for the first 10 years of its existence and I hated IntelliJ/NetBeans etc. when I first used them. The tools improved. They work great for all the languages I use. I'm not smart enough to keep an entire code base of every project I ever worked on in my head. Maybe you're a genius of a different level, even then... Wouldn't it make sense to clear the area of your brain that needs to remember every parameter name to a method call so the IDE will show that to you. IntelliJ community is free and open source. NetBeans too and it's decent. So is Eclipse. VSCode isn't exactly an IDE so I won't go into that.
  - eikenberry 4y ago
    You don't need an IDE to get, eg. function parameters, all normal programming oriented text editors do this now. IMO all of the 'editor' focused parts of IDEs are done great by the programming oriented text editors. It is the non-editor parts where IDEs differentiate themselves. Integrating testing, debugging, project management, refactoring, etc. Some of these things IDEs do pretty well and would be nice but they are not worth the tradeoffs you give up IMO. I prefer the looser coupling and composition you get with CLI oriented tools and value those aspects over the limited things that IDEs would offer. And none of this covers the fact that none of the good IDEs are Free Software. Which automatically removes them from consideration.
    - invalidname 4y ago
      Editors get this wrong when there are multiple complex and overriden functions/methods. Furthermore, they can't display things in the same way an IDE displays them. I suggest checking out a modern (admittedly non-free but open source) IDE. JetBrains displays argument names in an ineditable area next to the argument values. When debugging it shows the values that changed in each line in an area next to the line of code. It's amazing.
analog31 4y ago
What finally pushed me to use an IDE was the code inspection tools running in the background, and lighting up my likely bugs and style mistakes. So it's actually reacting to my code and doing something, rather than just flooding me with information. For now, Spyder (for Python) is just right. VSCode is too much, and I haven't figured out how to turn off the features that I don't care about.
Narishma 4y ago
> I run on an M1 Max with 64gb of RAM and gave a lot of RAM to IntelliJ (Ultimate). It flies. As professionals we need to spend on our tools and on our hardware to get the most out of both. The problem with that is you'll more than likely create applications that work fine on your fancy high-end systems but end up unusably slow on normal people's hardware.
- invalidname 4y ago
  That's why we have software testers. Most of the stuff I build nowadays is server backend stuff and mobile. For server backend this runs on strong machines. No problem. For mobile I use a device. For desktop stuff we have a minimum machine which we test. Also IDE's have profilers integrated where you can see if you take up too much RAM or CPU. There's no need to suffer slow performance to create apps that run in constrained resources. You can have more than one computer too. Even as a one person shop.
bitwize 4y ago
If you need an IDE to manage the complexity in large, complex software projects, then you need an IDE for the kernel -- one of the largest, most complex single software projects around. IDEs are written for this purpose -- modern CodeWarrior, for one. The fact that many kernel devs including Linus himself get along fine without one suggests that IDEs are not the universal good you seem to think they are. In particular, they are great if you follow the happy path anticipated by the IDE developers, but when things get weird, the IDE won't help you. So I tend to see a lot of IDE users alt-tabbing between their IDE, terminals, Postman, DBVisualizer, and what else have you which plays havoc with my brain and would only slow me down if that were my workflow. There's a perspective dependency to whatever the best tool for the job is. Some people can't live without a bell- and whistle-laden IDE; I can't live without a code editing tool that I can shape to my needs while I'm using it Which is why I won't be giving up Emacs any time soon.
- invalidname 4y ago
  I accept that I'm not nearly as smart as Linus. Also most Kernel developers know their own relatively narrow module not the entire project. Again, I programmed without an IDE (in Java too) and manage that completely fine. Just like I can walk barefoot without shoes. Same thing. It's a power tool that provides amazing capabilities. I go out of the IDE a lot too. I prefer using the native terminal rather than the one builtin the IDE (although some use that and that's fine) we each have our habits. CTO of my current company is a VIM nut. Uses it a lot. And an IDE. He uses each in the context he sees fit to his needs. I used to see a lot of people at my later days in Oracle (after the Sun acquisition) switching between Emacs and an IDE back and forth. Sometimes even on the same project. Each tool has its own power. It isn't a zero sum game between the two. I use external editors too for the right things.
- crummy 4y ago
  > I tend to see a lot of IDE users alt-tabbing between their IDE, terminals, Postman, DBVisualizer For what it's worth, IntelliJ use an IDE with an inbuilt terminal, HTTP client, and DB GUI.
alexvoda 4y ago
I would say that for embedded, your logic analyzer and you oscilloscope are actually part of the IDE. Embedded devs have the fanciest of IDEs.

mcint 4y ago

The workflows enabled by Jupyter and iPython address some of your biggest concerns. You have references to previous outputs, don't recompute things, and in browser can have GUI interactive elements. You can likely find live streaming monitors too. Though that starts to break what the environment is best at: composing an edited, rational path through a process based on interactive exploration, trial and error. https://en.wikipedia.org/wiki/Project_Jupyter#Jupyter_Notebook https://en.wikipedia.org/wiki/Project_Jupyter#Jupyter_Notebo...

anothernewdude 4y ago
The problem with in browser anything is that editing text in the browser sucks. It steals a lot of key bindings you can never get back, it allows for selection of the wrong element. Also notebooks are a horrible way of working. They encourage code to get extremely unwieldy and make managing state harder than it needs to be.

aaws11 4y ago

site gives 404 error when I try reloading it. firefox on windows

linguae 4y ago

One part of the article that resonates with me is the need for composable software that uses a more sophisticated mechanism than Unix pipes to connect components to provide an integrated experience. Over the past few years I've been interested in the idea of component-based software through IPC protocols and metaprogramming. This year I've been playing around with Plan 9, and I've found its ideas of component-based software through the 9p protocol interesting. I also got to spend some time using acme, which is one of the editors that comes with Plan 9. What makes acme interesting is that I can run external commands in the editor to perform various tasks, ranging from text manipulations to tasks such as compiling code. Each output shows up as its own window pane. One could create a sort of IDE using acme's ability to run external commands. While acme can seamlessly support external commands, a limitation, however, is there is no metaprogramming facility for changing the functionality of the editor itself. This makes acme less powerful than Emacs, which has the Emacs Lisp subsystem for extending and modifying the behavior of the editor. For example, suppose I wanted to add syntax highlighting to acme. Doing so requires modifying acme's source code. However, if acme provided some type of metaprogramming interface to the editor, then I could write code adding syntax highlighting. Ideally, this metaprogramming interface should be language-agnostic and take advantage of the 9p protocol. This would make acme just as powerful as Emacs, and in fact would give acme an advantage since extending acme won't require a specific language. Come to think of it, some of this metaprogramming capability may already be present in Plan 9 through the use of the /proc directory, thus obviating the need for application-specific metaprogramming mechanisms, though its offered at the binary level. I'll have to investigate this some more, though. My thought is that sophisticated IPC protocols and support for application-level metaprogramming can provide the rich interoperability that the writer of the article wants for creating composable development environments.

davidkunz 4y ago

"Modern" IDEs suck. They are not meant to be _fully_ controlled by the keyboard, have delays, cluttered UIs and interrupt your workflow with popups. That's why I prefer Neovim. https://youtu.be/9wsl6wvjdCg https://youtu.be/9wsl6wvjdCg

namaria 4y ago

I understand where the author is coming from and I myself sympathize with the idea of sticking to Unix philosophy of composing small focused tools instead of using complicated tools. That said, I have learned to stick to defaults and start from a clean slate every time. I often say that the main problem in software is containing complexity. When you need to deliver a product that works reliably, you want to remove all but essential concerns from your routine work. So I'd rather create a clean VM, install git CLI, VSCode, write a Dockerfile and get a nice clean package. If I learn how to use everyone of these tools out of the box with the default configuration, then I never have to think about dotfiles, plugins, set up etc. I think we need more software hygiene. Keep environments clean and ready to go.

truffdog 4y ago
My experience is that IDEs do not really support that sort of clean separation- you're always fighting to get it to support your VM or Dockerfile.
chriswarbo 4y ago
> write a Dockerfile I was sort-of agreeing with you until this point. In my experience "write a Dockerfile" usually means "run a bunch of fragile, non-deterministic nonsense, like `apt-get update && apt-get -y install`, `yum install`, `pip install`, `npm install`, etc.; often all at the same time!" (AWS are a serial offender IMHO, e.g. their documentation recommends this sort of crap https://docs.aws.amazon.com/lambda/latest/dg/images-create.html#images-create-from-alt https://docs.aws.amazon.com/lambda/latest/dg/images-create.h... https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html#user-data-launch-instance-wizard https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-dat... etc.)
- meatmanek 4y ago
  Docker is a way of taking fragile, non-deterministic things like package installations, and make them less fragile, in very practically-useful ways. Compared to the old way of doing these things (which would likely be a shell script that would run those exact same apt-get/pip/yum/npm install commands), Dockerfiles give you: - a much more predictable starting state, which lets you remove a bunch of complexity from your installation script. The old style of installation script might need to detect which OS it's running on, which version of Python is installed, whether you're using GCC or clang, whether libgomp or lzma or whatever is installed, whether or not the script is running as root, whether or not there are existing sites configured in the local nginx install. With a Dockerfile built on a slow-moving image, you can know exactly where everything is, what version is installed, and whether there are any other conflicting applications. - limiting side effects (As a user, you can be fairly sure that a `docker build` isn't going to clobber your nginx configs.) Containers have a whole pile of downsides, but making builds _more_ fragile is not really one of them.

chriswarbo 4y ago

I agree that it would be nice to cache a command's output, so we can iterate processes on it. I'm a heavy user of Emacs, which is based around "buffers", so should naturally support such a workflow; yet in the decade I've been using it, such a workflow hasn't really occurred to me. Emacs makes it easy to run commands, e.g. with M-&; the output goes into a buffer called `Async Shell Command`. Unfortunately, that buffer gets replaced each time we run a command. It's common to override this behaviour (as I do), so a new buffer gets spawned each time, which gets a bit closer to that workflow. Still, I've never really used this to chain commands together; this post has inspired me to try that a bit more :)

jrop 4y ago
This is how I use NeoVim's terminal: run a command, visually select the lines I want to operate on and yank them, then paste them in a new buffer. After that, it's a matter of transforming the text via whatever means one normally does (macros, text objects, search/replace, etc.)
- chriswarbo 4y ago
  Manipulating text within the editor is pretty common; e.g. I use shell-mode in Emacs, which is mostly just a normal text buffer (except Return acts differently when the cursor is over the commandline!); eshell is similar. What I was describing above is manipulating such buffers with external commands (similar to Emacs `shell-command-on-region`)

sirsinsalot 4y ago

Many people seem to think using a commercial proprietary IDE means you somehow forget how to use the CLI or other editors to get the job done. Like they're junk food that makes you dumb. This is as ridiculous as saying an electrician will forget how to correctly wire because their wire cutters are too good. I used to be a build-my-own IDE person via VIM. After using PyCharm and realising an IDE is more than an editor, I realise the productivity gains every day. If I need VIM or something else, it's just another tool in the box and the partisan fist shaking has no place in a mature profession and trade.

anotherhue 4y ago
It's not that one has forgotten, it's that one never learned. I watch senior engineers struggle with basic CLI usage daily. In the modern sense of Senior of course.
- sirsinsalot 4y ago
  Well the modern sense of senior leaves it likely that they have not yet learned to dress themselves either. That aside, what one doesn't learn doesn't mean the mistake is what one does. Just that they didn't.
annowiki 4y ago
I consider myself quite adept at cli, I can sed, grep, find, vim, and git quite well. However, what I never found convenient in cli was debugging. I was a print debugger for years until my job convinced me to try PyCharm. I've always thought the reason I never found a suitable debugger in cli was just because I was either too dumb to figure out integrating something like vimspector, or too lazy to get used to gdb/pdb. Ctrl-f on this article has no mention of the word "debug." I think I'm not the only one that never used a debugger before I tried an IDE. I wonder how many people still feel superior in their CLI-Vim/Emacs-only workflow and are just print debugging.
- jrop 4y ago
  I use NeoVim for everything except debugging. For that I (frequently) open up VSCode or Chrome to debug (NodeJS). I haven't figured out a good debug workflow for Rust, though, because I hate print debugging.

timberfox 4y ago

My experience is quite different: I feel extremely productive working in the terminal, and what is described in the article as "The frozen world" is for me a virtue of the UNIX philosophy: the structure is not embedded in the data, but the programs can project a structure on it. That allows programs to be filters, and text to be the only format for exchanging information. What the article describes as "The nightmare that is composition iteration" is for me a very pleasant experience: the terminal provides a very fast feedback loop where I can iteratively examine the output of a command and refine the filters I apply. As a result, I am able to prototype commands quickly and accurately.

Firadeoclus 4y ago
> the terminal provides a very fast feedback loop where I can iteratively examine the output of a command and refine the filters I apply. As a result, I am able to prototype commands quickly and accurately. That's what any REPL does. And it works great with typed data. Sometimes even with graphical output.
nomel 4y ago
> the terminal provides a very fast feedback loop where I can iteratively examine the output of a command and refine the filters I apply An IDE would be used to develop those commands, more than compose them. > text to be the only format for exchanging information For this to work, with non-text data, you end up using the file system as a buffer, then passing filepaths between commands. For many contexts, this isn't performant enough.

z9znz 4y ago

There are four things which IDEs typically provide which I find invaluable. It's probable that some or maybe even all of them could be wedged into Vim or Emacs, but then you'd have basically an IDE. 1. Quick go to _anything_. In IntelliJ IDEs, it's double-shift, and then start typing some of what you want. Usually you can find the class or module or file you want easily, if not automatically. 2. Interactive debugging. This is so very useful. Usually it's just the fastest way for me to inspect a data structure at a certain point in time, or even find out what's going on in a framework that uses a lot of metaprogramming. 3. Jump to definition of thing (function, constant, etc.), and conversely show usages. In a well designed system of composable single responsibility functions, one can almost forget about files and navigate only with these (and (1)). 4. Git diff my branch to branch X. Lots of extra goodies can be included in this, such as interactive merge conflict tooling, etc.

sunsunsunsun 4y ago
My neovim does all of this and more. Yes ive blurred the lines of text editor and IDE. I enjoy the portability, speed, and customization it offers. I also like that I have everything I need in the terminal. Its not for everyone though and it takes a lot of time to customize it perfectly for you.
spoils19 4y ago
I'm able to do all these with a simple text editor, an IDE takes up resources, implements tracking, and real programmers basically have no use for anything aside from a simple text editor.
- 9dev 4y ago
  Is that the classical „real men don’t need guns, we kill with our bare hands“?
- IshKebab 4y ago
  Bit of a stretch to describe something that has all the features of an IDE as a "simple text editor". Notepad is a simple text editor. What you have is a text editor that you've (presumably) augmented with a ton of plugins to turn it into a full IDE.

RcouF1uZ4gsC 4y ago

>We could write a code / text editor that wouldn’t have to be worried about extensions like Git: the Git support would come as a native application (equivalent of the CLI git application) that would open an overlay, for instance. That application wouldn’t even know about the code editor: you would make that connection via the platform. >Applications could communicate between each other to manipulate buffers, get the contents of the buffer and do various kind of operations on them (LSP servers, for instance). >Because the protocol would be completely rendering-agnostic, that would allow people to write an application that would work for any kind of “platform implementations.” Composition would use the low-level protocol to compose applications. You could imagine supporting an interface between applications allowing to filter the contents of the buffer of one by using another application. Applications such as fzf could branch on the buffers of a text editor, for instance. Or you could even open a buffer in the text editor by running a fuzzy finder as another application. All of that would compose in a seamless way. Etc. etc. Actually this sounds a lot like OLE 2.0 from 1995.