Honestly the only IDE I’ve used in recent memory that I like is PyCharm, it mostly just works right out of the box with only a little tweaking to fit how I like it.
With IntelliJ, it’s the best option of a bunch of crap, and it made some things much easier when it came to working with Amazon’s build system. Due to the way it was structured, building anything locally required importing hundreds of packages, and Amazon made an IntelliJ plugin to make managing all that much easier. Plus, when you’re working with a dozen packages at once, being able to navigate them and work on multiple files in different packages on one screen is nice. I still did most of the actual building in CLI on a different computer (rsync was the true hero of my dev workflow).
When I get right down to it, I suspect I can be equally effective whether I use an IDE or not, I just adapt to whatever seems to work best for the project at hand. I will also favor making things easier to work with my teammates. If that means using a crap IDE because they like it, so be it.
Why do you have to use what your teammates use? Every place I’ve worked everyone uses what they personally like best. There’s no reason to use something just because someone else uses it. The common language is text files.
True… There’s no reason why you need to use the same exact editor/IDE/etc. your teammates use. Even if they use some kind of IDE-specific build system or something, you can work-around it if you’re clever enough.
I started using Pycharm soon after starting a big project, about 6 years ago, and really dig it. I don’t even understand the mental model I would need to do programming without all the help it provides.
If you type the same things 5 days a week for 15+ years eventually they are muscle memory. What would be a helpful reminder for a beginner becomes as annoying as Microsoft’s Clippy.
I agree that this is true, there are technically no restrictions for what I decide to use, but having a common view of the world as everyone else is helpful. If a teammate comes over to my desk with a question and I walk them through it on my setup, it doesn’t help if they can’t parse what I’m showing them. For a lot of younger developers who grew up on IDEs, it’s easier for them if I use the same tools they are to show them how to do something. This is especially true when doing pair programming. And in 99% of cases, using an IDE doesn’t reduce my effectiveness since I already said I do most of the actual building outside of it. At that point it’s just a text editor that can correct my mistakes without compiling.
There are some other very specific times where it was necessary. With Visual Studio in particular, their directory structure doesn’t match up with the filesystem and it doesn’t refresh the structure when you add new files outside of the project. So if I’m adding files and building them using CMake, the VS project that the rest of the team is using doesn’t get updated unless I add those files in manually. So I might as well just use VS since I have to do those updates anyway. (This problem was eventually fixed by using a build system that auto-generated those VS project files, but it was something we had to live with for months)
This is a perfect example of the kind of thing that makes me hate and never use IDEs. Your code is right. Your file system is right, But shit doesn’t work because your project files in your IDE are messed up. The IDE is creating problems to solve that otherwise don’t exist if you use a plain old text editor and a shell. Every single time I’ve used an IDE something like that has happened.
Then you’re using a crappy IDE. Admittedly the older ones were much more picky about directory layout, but newer ones pretty much don’t care so much, especially if they start using a standard build system like CMake. Hell, even newer versions of Visual Studio support using CMake now. And in other cases, you just usually just need to point the IDE to the source root and you’re good to go.
But as I said, you can also use an editor and shell if that’s your thing, provided you have the proper toolkit to go along with it and don’t mind jumping through the hoops needed to configure it. Oh, and so long as it’s an editor with a modern UI unless you’re just really, really, really used to something designed for a time when cars looked like this:
Okay, okay, you’re using vim, not original vi, so this is probably more appropriate:
I don’t configure it. I leave just about everything as the default. No zsh bullshit. No lengthy vim config. 90% of my vim config basically just changes the fonts, colors, indentations, etc. I can work without it. My .bashrc just sets some environment variables for the projects I’m working on. The only configuring I need to do is install a Linux environment that has bash as the default shell, and some sort of package management, preferably apt. That’s it.
Also, any configuring you do in bash/vim is just to make things nicer. Making some alias shortcuts. Changing some fonts. None of that configuring is to make your build actually work or your application run. IDEs require configuring just to make things run. The last time I pressed the “play” button in an IDE and had it actually work correctly was using Visual Basic in high school in 1999.
Also, your car analogy is hella busted. IDEs have been around since what, Borland? Actually I looked it up, it was Dartmouth BASIC from 1964. Bash, Linux, and Vim are all actively developed and well maintained projects, as are all the GUI IDEs you are using.
If anything I tend to argue that when it comes to development tools, I prefer things that have stood the test of time over the new hotness. Look at all the trash fire in the nodejs npm world. Look what happened to all those NoSQL hipsters. Old stuff that is still alive is usually the best. I don’t trust new hotness. That Visual Studio Code everyone loves is what, 3 years old? Let’s see if it lives to be ten, without falling to some other fad.
Well, you’re not configuring a code index tool, or even a way to pipe output from grep directly into vim so you can just use the keyboard/mouse/etc. to jump to the line in code that grep produced. You need to manually look at your terminal window and then type the appropriate command into vim to jump to the correct file/line instead of letting the computer do the jump for you just by effectively saying, "jump to the 3rd line of grep output you spit out. You’re still doing a lot of stuff manually.
You don’t need to configure all that crap in your IDE if you don’t want to. Outside of the same sort of fonts/colors/etc. stuff you do, I basically don’t do any configuring of any of my IDEs. Okay, strike that slightly, I optionally did some weird stuff just so that I could click/hot-key “build” and have build results appear with a clickable list of compiler errors just for the sake of convenience.
Running? I can’t even run my product on my local machine with or without my IDE – I need to transfer it to a test VM, so that isn’t even a thing I worry about. And you know what, my IDE doesn’t care. So I don’t use that feature of it, but I don’t have to, and it’s fine with that.
Okay, the car analogy isn’t perfect. Maybe 1970’s shag carpet and rotary telephones are a better analogy as we’re talking about the look and feel of Vim as opposed to something designed for modern graphical interfaces. I don’t know if you’ve noticed, but we’re not accessing a VAX over a 300 bps modem link using an ADM-3A dumb terminal anymore when writing code:
The use of the HJKL keys for moving the cursor in the vi editor and its descendants stems from the ADM-3A; it had the cursor-movement arrows printed on those four keys.
Okay, let’s look at Vim then. It apparently was first developed for the Atari ST (where is that nowadays) in 1987 as the Stevie editor. Vim was based on this code and first publicly released for the Amiga (ditto) in 1991. This is 7 years after the Mac came out, one year after Windows 3.0 (the first widely adopted version of Windows) came out, and it still insisted on using a 1970’s-era shag carpet/rotary phone user interface when people already had superior interface standards like Apple’s HIG and IBM/Microsoft’s CUA. Hell, you didn’t even need a GUI for CUA – several DOS programs followed those guidelines as well. So Vim, when it was released as such, was born with a user interface that was already 15 years out of date. Even if we go back to Stevie, it still had an out of date user interface given that it was released 3 years after the Mac on the Atari ST which also had a full blown GUI.
It’s also insane to compare a text editor to something like a database or a package manager when it comes to talking about dev tools. Those subsets of dev tools are completely orthogonal to each other. IDEs and text editors are the only valid comparison as they all pretty much do the same thing at a fundamental level: edit source code. Also, provided you’re using something with a modern, standardized user interface, it’s relatively easy to change to something else if it were to go by the wayside.
Agreed. It also follows interface standards meaning that it doesn’t take long to be productive in it once you switch from something else or vice versa.
I have never even considered wanting such a feature. Opening a file and going to specific line is so trivial that I can do it with keyboard-only entirely on subconscious muscle reflex.
Esc
:tabnew filename.txt
:31
Of course I’m also gonna tab complete that filename. 31 is obviously an example line number.
Tangent: I have changed my muscle memory to use Ctrl+[ instead of Esc in vim because it works on all computers everywhere. More importantly it works on keyboards everywhere. Lots of them these days are removing the Esc key, shrinking it, or misplacing it. Ctrl+[ even works on my iPad, which has no Esc. Ctrl+[ also is faster than Esc even on a standard 104 key layout because the Esc key is very far away, and Ctrl+[ requires a lot less reaching. Really reduces fatigue on the left pinky finger.
This is why you aren’t configuring anything! You’re not using the IDE, you’re just using the text editor part of it. The 90% of the IDE that I am primarily criticizing you are not even using! My only criticism of the text editor part is that it has a bunch of features that are useless to me and get in the way, like the autocompletion and such. All my other IDE criticisms are with the other parts.
And this also explains why you have this weird perspective. An IDE is not just a text editor. A text editor is a text editor. An IDE is an integrated development environment. Editing text is just one of its many functions. It also provides source control, building, testing, debugging, etc. all within a single combined user interface. The real Visual Studio had a great debugger (maybe the best ever?) when I used it, but I have never found an IDE that was better than a shell at any of those other development essentials.
Yeah, my CLI may look like a terminal, but my CPU is running all my projects, and more. I got all kinds of stuff running locally, even Postgres. That’s what a powerful computer is for. You are just shipping out everything to a VM that does the actual work. Your computer is the terminal, not mine! Just editing text and shipping it off to some other computer to do the actual work. Another computer that I imagine is best operated via a *nix shell.
Imagine If you had the stack of that VM running on your local hardware. Are you going to configure your IDE so that it builds and launches your app when you press the play button?
3 steps as opposed to one single step. You lose a bit of efficiency there.
Fair enough. I don’t use most of the IDE’s features, as you said. I use it as a glorified editor, which is probably why I don’t complain about it as much as others do. And while you don’t like features like autocompletion, code indexing, code navigation stacks, intelligent refactoring, and such, I find them to be a huge productivity boost.
Just now I had my editor/IDE run an operation where I added a new argument to a function and it automatically updated all the function declarations, definitions (this is C++) and calls to use the new argument, all in a couple of seconds. It would take me much longer to do the same thing in an editor without this sort of “intelligence” about my code. I know, because I’ve done so in the past before I had an editor that supported this feature.
Fair enough again. I mostly focus on the “editor” part of the IDE as it’s what I use. However, I do use a subset of the other features, like code browsing, that typically are only in IDEs or require you to set up plugins with your plain editors (although, if I remember correctly, Vim does have built-in support for browsing with a ctags index file).
That said, you’re right in that I don’t use the source control part (although that’s relatively new to IDEs as I remember using an older version of Visual Studio that didn’t have any source control built in). My IDE (CLion) uses an external, standard shell-based build system (CMake), though it happens to ship with it out of the box. I actually have a wrapper script I wrote so I can execute my company’s custom build system from CMake so I can get nice build output just for convenience. I don’t even know what kind of testing stuff my IDE uses, and as far as debugging, it’s just a GUI wrapper around another external shell-based debugger, GDB, and it’s often easier for me to just use GDB directly. If I wanted to use the GUI GDB wrapper, I’d need to set up remote debugging for my work projects.
Now, if you’re using an IDE that has everything built-in instead of just being a GUI wrapper around existing shell-based tools, I can see more of the problems there and I can agree with you to an extent. I’m fortunate that the ones I prefer to use now pretty much just wrap around shell tools so I have the option of using both. In fact, for source control, I may just use the IDE for quick git commits as I don’t trust it for anything more sophisticated, but I’ll drop down to the shell for anything more complicated.
Actually, it’s not quite so simple as that. While I ship off bits to be tested on a VM, my CPU still does a lot of work. All the compilation, linking, etc. is done on my CPU. To give you the idea of what I’m talking about, a clean rebuild of my project takes about 20-30 minutes on my CPU, which is an 8 core i7 (though if I had an SSD it would be faster). I only test compiled binaries on the VMs. So I do more on my machine than merely edit text.
FWIW, you’re right in that I do access those VMs via shell as those VMs are basically embedded Linux systems.
Well, I have my IDE configured so it builds my app, but that just consisted of adding a single line to CMakeLists.txt that runs a small script I wrote. That script was only necessary because our build system does weird stuff with environment variables and that script sets them up before invoking the actual build. The IDE reads CMake files directly and uses them as its native project format, so that was almost trivial.
The nature of my product means I can’t run anything locally, even if I wanted to. My IDE recently did add remote run/debug features, but they’re new (as in only came out this month) and I haven’t bothered getting them set up yet. I’m not even sure they’d work correctly given the unique nature of what I work on anyway.
