Listen, long story short: just say no to nonsense like this.
Given the choice of a) tooling, or b) no tooling, you’re not being smart, cool or clever by choosing b.
Obviously, what tools you pick are important and heavy IDEs like IntelliJ are a trade off between speed and functionality, and yeah, more nimble tools do exist, and it’s definitely worth trying different development tools to see what makes you most productive.
…but “no IDE” is just rejecting everything because you didn’t like one thing; it’s just being lazy.
The best developers I've found are the ones who know how to work without an IDE, even if their preference is to use one.
Contrastingly, the worst, slowest developers I've worked with rely on their IDE without understanding what it's doing for them, and are helpless in new/unsupported situations. They also, 100% of the time, screw up their git repositories on a regular basis, and need someone who knows what they're doing to help them out, costing their colleagues time and frustration helping them when they won't help themselves.
Some people from the first group find they prefer not using an IDE. It's rather the opposite of laziness, it's choosing the workflow they find most productive, even if it differs from your preferred workflow.
“Power drills have batteries or cords and motors that wear down and they’re more expensive and complex and can break more easily and it’s just smarter to bring hand crank tools to the worksite.”
There is a very large difference between a very smart source code editor (e.g. Visual Studio Code) and a complete IDE. I consider the first essential and the second completely useless.
For editing or just navigating the source files, the smarter the editor is, the better.
On the other hand I have never seen any IDE where the management of projects (e.g. adding/deleting/moving/renaming files and setting compilation/linking options) and the compilation/building/running functions are as simple and fast as how that can be done without using an IDE (if you know how to do it in the right way).
Especially the Eclipse-based IDE's provided by many vendors of embedded products are the worst offenders.
I have wasted too much time with helping puzzled coworkers to find where in the hierarchy of IDE menus one could find whatever was needed. Even when knowing where to find the commands, using the IDE menus was many orders of magnitude slower than what I could do outside the IDE to perform the same function upon the project.
> …but “no IDE” is just rejecting everything because you didn’t like one thing; it’s just being lazy.
This is the vi vs emacs debate transposed to build tools and as such will never conclude. Some like their tools to be as "complete" as possible, others want them out of the way. You might be closer to the first camp, I'm close to the second, others are in between. All of these choices are fine, there is no canonical truth here and as such the "nonsense" label used above is just that, nonsensical.
I consider not needing to remember library and api details a benefit. I'd rather dedicate my brain cycles to something else. As for syntax, I don't recall ever struggling to remember syntax of languages I frequently code in.
Also the point about IDEs auto generating toHashCode, toString, etc. If your class needs these methods, whether they were auto generated or not seems besides the point. The point the IDE is "compensating for lacking language features" doesn't make sense to me, the code is compensating, whether a human or IDE writes it.
Why do doctors memorize medicines and their effects? Because it's faster to retrieve from memory than from documentation, even automatically presented documentation. It removes a context switch.
The "brain cycles" are only run while doing the memorization, not while actually doing the work.
> I don't recall ever struggling to remember syntax of languages I frequently code in.
Yeah the idea that I have to remember everything in our codebase of millions of LoC made up of TS, JS, Ruby, Kotlin, and Java is ridiculous. IDEs allow me to drop into these codebases and be decently productive from the get go.
When you start to work with too many languages frequently, using syntax from one while writing another is common and IDEs really help at this point. I too prefer not to remember APIs and methods, but with time, our brain starts maintaining a cache of these. Completions make this faster.
That and error detection are only features I like in IDEs. For everything else, dedicated tools are often better (but not necessarily easier) than integrated ones.
There is a common perception with electric bicycles that the rider will pedal less hard to go the same speed. But there is an alternative: they could pedal the same amount and go faster.
I kind of view IDEs like that. You can use it as a crutch, or you can take the energy you would have used thinking about the things the IDE is now doing for you and focus it elsewhere.
To extend that analogy, I choose a regular bicycle because I ride for fun and exercise, not speed. But if biking were a serious mode of transportation for me, I would get one that gave me the most assistance possible so I could go faster and farther.
IDEs are similar. If you want to be as efficient as possible and get as much done as possible, you want an IDE. But if learning and exercising your mind is the goal, you’d be better served with a text editor.
veering off-topic, that's one of the problems I have with electric bikes - they stop being bicycles and become another kind of vehicle - a faster vehicle that needs longer stopping distances and now has a highe r fatality rate when colliding with a pedestrian.
We see this in London cycle lanes. Some cycles are doing a commute, some are trying out for the olympics, some people are doing 25 on a electric scooter and these are alien - hard to predict because they don't obey our intuition about physics. A guy on a scooter does 10mph tops and puts his foot down a lot.
Nitpicking, but in the world of regulations, electric assist tapers off until around 25-30 km/h, at which point you start carrying the entire bike anyway, plus the dead weight of the battery and the motor.
I wonder if this simile could be extended to programming. Being hindered by not being able to choose your own tools?
Sometimes people need to prove that they are a rare breed of pure developer. Their superior discipline and tastemaking in the development toolchain far surpasses the masses of regular developers who are dependent on old slow crutches to get any meaningful work done.
Meanwhile there are real 10x developers out there that while they care about the tools stay out of the weeds of them.
This line of blog post reminds me of a Paul McCartney interview I read where someone asked him what kind of strings he uses on his guitar. Paul replied “shiny ones”. I think Paul is actually a lot more technical than he lets on in interviews and probably knew full well what kind they were. What he communicated to the person asking the question was that it doesn’t matter so much.
The author seems to use IDE for one purpose only: to auto-generate boilerplate code. But this is far from the only benefits of IDEs!
I rarely use IDEs for code generation, I don't even like autocomplete. For this stuff I use code snippets; I develop collections of those for any language I use. You don't need an IDE for it; any good text editor has such features.
For me really important features of a good IDE are:
- Navigation. Being able to right-click on a function or method name and jump to its definition is very handy.
Yeah, I may remember where it's defined; I can also use grep (which does not work all that well for methods).
But jumping is so much faster and does not take you out of the flow.
- Code refactoring. I am refactoring code continuously as I work with it. Even simple stuff like renaming a variable or a function (or a method!) is much easier with an IDE.
- Error highlighting.
Note: I can and sometimes do work without an IDE (esp with more obscure languages which don't have good IDE support).
There is some fun it it too, like going camping and living for a while without creature comforts like running water and electricity. But normally, if a tool is available, why not use it?
About languages: I agree that a well-designed language allows you to factor away most boilerplate code. (This was one thing I really liked about Perl! It basically allows you to develop a language dialect for your particular needs. The downside with Perl was that everybody was "reducing boilerplate" in their own way, but this is another story)
There are languages and environments that are more prone to requiring IDEs.
For example, when I write React and I use the Foo component, either it is defined on the same file or it is in one of the imports.
On the other hand, with Angular, the foo component is not imported anywhere. In fact, there is no foo component, just one or many Foo components which declare to use the foo tag, and one or another may be loaded depending on the context of the current component. Good luck getting anything done with such an obfuscated environment without tools to deobfuscate it.
And then you have the heavy enterprise frameworks that make a science out of obfuscated code, so that you don't know what code is being executed, because it is hidden behind several layers of inheritance and interfaces, and the instance to create is choosen via xml-configurable meta-programming based dependency injector. Working with such code is guaranteed insanity without heavy IDEs. I would say it's also insanity with heavy IDEs, but people tend to find that opinion controversial.
this so much. it's priceless to just type a line and have some warnings such as "hey, you're moving this value but using the variable afterwards, take care" or "hey, it looks like you are only using this argument as a reference, consider not passing it by value" just pop up next to the offending line ; when compared to an IDE-less workflow I pretty much divide the amount of hitting "build" I need by ten or more since the IDE tells me everything wrong beforehand.
I'd like to point out that you don't need an IDE for error reporting. Most editors these days integrate with a language server for inline errors and linting. Even features such as jump-to have existed in Vim/emacs for many years.
I would add graphical debuggers to your list. You can get by with command line debuggers and there are external attachable debuggers but neither is really comparable to an IDE.
Not having an IDE doesn't make me remember things. In my case it just means I use a very limited subset of the features, because I'm not being reminded of the things I don't remember and I don't get to see newer language features unless I happen to read a blog post or see something here on HN. I tend to fall back to implementing things with primitives and fail to use built-in functionality.
For the longest time I was a proponent of limited tooling. In many cases its good to know what you're automating or simplifying because I often found myself in situations where I may have environments I need to do things where I didn't have my tooling to lean on.
In the past, this was possible without too much pressure on cognitive load. In modern code bases with all sorts of libraries and layers of abstraction ontop of abstraction ontop of abstraction ad infinitum, it's just not feasible anymore. I got to a point in certain development ecosystems where not relying on tooling started to really hinder me. Self reliance was no longer a strength and a point occurred where I simply had to lean on more and more tooling or I'd be lost.
I still think if you have tooling that does something, you should understand what it's doing and how it's doing, at least once, then let it do every subsequent need for that task. It's good not to have black boxes in your ecosystem. Unfortunately even that is becoming difficult because of the number of layers of abstraction in some ecosystems (especially web development).
I've never been a fan of black boxes that I simply trust and don't know their tradespaces, then hope for the best.
> Some Projects with 40000+ files might take >5 minutes to load.
I would buy a more powerful computer. I have a project with 34908 files and IntelliJ doesn't care. Not quite 40_000+ files but still a lot :).
Also with IntelliJ I make fewer mistakes. This "thing" is just more intelligent than I am. Add "SonarLint" to the game and I sometimes don't even know _why_ I am wrong :P.
Also I think "Avoid IDE lock-in of your project" is the wrong subtitle for the following paragraph. You would have the same problems by using just a text editor.
Rd6n6 mentioned refactoring. Do that in an editor and you will go crazy after a while :).
Pro tip from an ex-performance guy: Allowing your developers to use machines more powerful than your minimum targeted device is a very good way to produce software that will not run on your maximum targeted device.
When people say "no IDE" what they usually mean is the concept of an IDE turned on its head.
Your command line with vim/emacs and other tools that together arrive at the same feature set as a Integrated Development Environment are still... a development environment.
Not using an IDE doesn't mean you can't have autocomplete, syntax checking, linting, automated rebuilds, and all that other good stuff. It's just not all in one package.
And yes you shouldn't force your choice of (integrated) development environment on others. Different people have different needs: News at 11.
Maybe I’m weird, but at some point I stopped fixating on which tools to use and just settled on a personal workflow:
* terminal open at root of project used for source control
* one or more tabs for ssh/VMs etc
* IDE/VSCode/vim for editing
Any of those is fine. And sometimes I switch between them depending on my mood. If I’m out and about it can be nice to conserve battery and focus by going full terminal mode. If I have AC power and a full screen then I don’t mind an IDE as much.
One thing I insist on is doing as much work with git from the CLI. IDEs often do things like staging new files automatically that I’m not a fan of.
To the point on this one, I sometimes find myself running neovim inside the IntelliJ or VSCode terminal, when I need to edit a config file quickly while running scripts in that terminal, or just to edit a file outside the project directory. Or like you, I primarily use the git CLI, because IDEs often use to me unintuitive mappings of GUI buttons to git actions ("what does Synchronize do for git?"), so then it pops open $EDITOR to write my commit message.
When I need to create a lot of "new" code, I'll usually use nvim. When I need to edit/refactor existing code, I'll more often use atom or vscode.
I like both a lot. When bashing out code that is already reasonably clear in my head, vim works faster and with less "overhead". An ide like vscode works better for me when I need a good global search & replace, or something the ide has plugins for.
I think the benefits of working with KISS tools - the opposite of 'everything but the kitchen sink' in Emacs parlance - is that it significantly lowers the cognitive load. This may sound odd when comparing a rather bare-bones vi + tools setup with a bells-and-whistles IDE like Visual/Android/whatever Studio but it just ends up working that way for me. I already need to keep enough state in my head for the project I'm working on so I'd rather not have to worry over the state of whatever tools I'm using.
As an aside, I feel the same about the unbridled growth of tooling around certain languages (Javascript being a prime example) and environments (Android comes to mind). Maybe it is just because of the way I started out with 8-bit assembly where a macro assembler was a luxury which could not entirely be trusted to do the right thing but I know I'm not the only one.
Agreed, I like (trying) to understand as much as I can about how my environment works so if/when something breaks I only need to learn the last 30% in a crisis, and I'm already familiar with the core. It doesn't always work, sometimes there is just too much.
It's usually useful, at least in some abstract way to the team. It felt essential when I worked alone and was accountable for everything.
> I think the benefits of working with KISS tools - the opposite of 'everything but the kitchen sink' in Emacs parlance - is that it significantly lowers the cognitive load.
No. You're wrong. Not having the right tools raises the cognitive load. You just think it's simpler because you are severely restricted in the complexity of the programs you can create with just your brain and the documentation.
IDEs expand the complexity of what you can build and make you more productive building programs of any size, because features like autocomplete and refactoring take thr cognitive burden off you.
I was developing python/django for a couple of years in notepad++. I had a very slow computer this time and using anything else seemed way too slow. The featured I missed most from notepad++ was not being able to quickly open files for editing (ie like using ctrl+p in vscode).
Beyond that, it was a great experience. Of course, using python contributed to that great experience since most things can be easily remembered and the autocompletes are not so useful due to the dynamic nature of the language. When I needed to do Java/spring development I always fired up eclipse even if though I knew it would take 5 minutes to start and a couple of seconds for each suggestion to appear. However, trying to develop in Java without an IDE by having the javadocs open and copying and pasting all the package and class names all the time and missing everything static typing offers your is a nightmare!
In Linux, it often feels like the whole OS is the IDE. In the same shell, you can edit source files, compile, debug, execute, rename, search, create and execute scripts to do literally anything with any language, use git, surf the web, update, reboot, launch a game, etc, etc.
An IDE on top of that always felt restricting to me. Like why limit yourself? But maybe that's a windows/Mac thing.
I used Webstorm for years, but switched to VSCode.
It's just more flexible, which allows me to use new tech/langs very quickly.
If you don't focus on IDE features, you tend to implement quality of life improvements at a level that also works in an editor. Like in the language, framework, or library you're using (See the code generators point in the article).
With languages like Rust, that have zero cost abstractions, you don't even run into performance problems when doing so.
For context, the author is a student with little real-world work experience producing software for a paycheque. To put it mildly, there’s a lot more to writing software in a modern work environment than your choice of editor or whatever.
Exactly. The youngsters like to show off their L337 hacky editor configurations. The rest of us are just getting actual work done in IntelliJ or Visual Studio.
I've used vanilla vim more or less without plugins and with a few keymap tweaks for the majority of my software development work. Every now and then I have to use an IDE to match some upstream requirements, and I much prefer using a near featureless text editor. Sure the auto-suggest, tab completion, etc. are nice, but I feel like the downsides aren't worth it. I also find it's easy to get lazy when using an IDE and produce sloppier code on the whole.
In most cases I feel that using an IDE nets you short-term, micro-productivity gains and also nets you long-term rot/maintenance headaches. imo it's typically not worth it.
There are probably other things I'm forgetting to mention.
Sure, all of these can either be cobbled together to some degree out of the fundamental individual tools. You can add plugins to Vim or Emacs to help with many of these. With enough effort you can get close to what a polished IDE offers... but you're effectively making your own quirky, fragile, non-portable inferior IDE.
Yeah, a heavy IDE is slow to start and resource hungry. But hardware is cheap, and you only start the IDE once every few days (or weeks).
When I'm on a remote server, then I'm in a shell using vim. Fine, and doable. But to really build and get things done, saving my brain for actual problem solving, I wouldn't want to give up my IDE.
Also, some of the cons on OP's list are problems with the language being developed in, not the IDE.
Why is it so important for some programmers to convince others of working the way they work?
The complaints levied at Java and Android specifically are issues I've really only seen in that language and on that platform. Excise that and all these arguments feel very flat and empty. It has not been my experience at all that using an IDE means I can't remember my project layouts, API calls, etc.
And frankly, this wreaks of the same sort of elitist arguments that only a small minority of grammarians make against spell-check. So what if the tool is a crutch? ALL TOOLS ARE! That's the point of tools, to off-load some forms of manual labor. A table saw and a fence are going to let me make straight cuts a lot quicker and easier than using a hand saw. Humanity grows and life moves on and troglodytes complain that the field is being "ruined", but what they really mean is they can't keep up.
These days I'm seeing more common support for using an IDE with an external build system. Best of both worlds... you get to have the IDE add the tedious import statements at the top of your file, and people without the IDE won't have any problems with your project.
Depending on the language and build system, this might be something I set up manually (set up an IDE project to mirror the build system), something you can set up automatically (export build system to IDE project), or there might be a standard layout for source code that mostly works.
A good ide is all about auto completion and refactoring tools. The autocompletion means you don’t have to spend as much time memorizing apis, so you can focus more on simplifying your design and minimizing coupling. In something like unreal engine, the intellisense really sets ides apart. The refactoring means you can quickly and easily make large changes to make the code easier to work in. You can just work significantly faster if you have both of these things.
I don’t really use other ide features. Separate terminals are great
As the author points out, it does depend on the language. I switched to vim "full-time" when moving to a Go team. (Prev Java).
Java is a language that does not lend itself to vim. Even just compiling and running a sufficiently large java program can be a pain without an IDE setup.
[+] [-] wokwokwok|4 years ago|reply
Given the choice of a) tooling, or b) no tooling, you’re not being smart, cool or clever by choosing b.
Obviously, what tools you pick are important and heavy IDEs like IntelliJ are a trade off between speed and functionality, and yeah, more nimble tools do exist, and it’s definitely worth trying different development tools to see what makes you most productive.
…but “no IDE” is just rejecting everything because you didn’t like one thing; it’s just being lazy.
[+] [-] drunkpotato|4 years ago|reply
Contrastingly, the worst, slowest developers I've worked with rely on their IDE without understanding what it's doing for them, and are helpless in new/unsupported situations. They also, 100% of the time, screw up their git repositories on a regular basis, and need someone who knows what they're doing to help them out, costing their colleagues time and frustration helping them when they won't help themselves.
Some people from the first group find they prefer not using an IDE. It's rather the opposite of laziness, it's choosing the workflow they find most productive, even if it differs from your preferred workflow.
[+] [-] Waterluvian|4 years ago|reply
- Nobody
[+] [-] adrian_b|4 years ago|reply
For editing or just navigating the source files, the smarter the editor is, the better.
On the other hand I have never seen any IDE where the management of projects (e.g. adding/deleting/moving/renaming files and setting compilation/linking options) and the compilation/building/running functions are as simple and fast as how that can be done without using an IDE (if you know how to do it in the right way).
Especially the Eclipse-based IDE's provided by many vendors of embedded products are the worst offenders.
I have wasted too much time with helping puzzled coworkers to find where in the hierarchy of IDE menus one could find whatever was needed. Even when knowing where to find the commands, using the IDE menus was many orders of magnitude slower than what I could do outside the IDE to perform the same function upon the project.
[+] [-] the_third_wave|4 years ago|reply
This is the vi vs emacs debate transposed to build tools and as such will never conclude. Some like their tools to be as "complete" as possible, others want them out of the way. You might be closer to the first camp, I'm close to the second, others are in between. All of these choices are fine, there is no canonical truth here and as such the "nonsense" label used above is just that, nonsensical.
[+] [-] city41|4 years ago|reply
Also the point about IDEs auto generating toHashCode, toString, etc. If your class needs these methods, whether they were auto generated or not seems besides the point. The point the IDE is "compensating for lacking language features" doesn't make sense to me, the code is compensating, whether a human or IDE writes it.
[+] [-] falcolas|4 years ago|reply
The "brain cycles" are only run while doing the memorization, not while actually doing the work.
> I don't recall ever struggling to remember syntax of languages I frequently code in.
Because you've memorized it.
[+] [-] dntrkv|4 years ago|reply
[+] [-] throwawake|4 years ago|reply
That and error detection are only features I like in IDEs. For everything else, dedicated tools are often better (but not necessarily easier) than integrated ones.
[+] [-] nooorofe|4 years ago|reply
[+] [-] bootlooped|4 years ago|reply
I kind of view IDEs like that. You can use it as a crutch, or you can take the energy you would have used thinking about the things the IDE is now doing for you and focus it elsewhere.
[+] [-] snazz|4 years ago|reply
IDEs are similar. If you want to be as efficient as possible and get as much done as possible, you want an IDE. But if learning and exercising your mind is the goal, you’d be better served with a text editor.
[+] [-] lifeisstillgood|4 years ago|reply
We see this in London cycle lanes. Some cycles are doing a commute, some are trying out for the olympics, some people are doing 25 on a electric scooter and these are alien - hard to predict because they don't obey our intuition about physics. A guy on a scooter does 10mph tops and puts his foot down a lot.
[+] [-] taeric|4 years ago|reply
So, at large, I would guess the "as a crutch" use happens far more.
[+] [-] rhn_mk1|4 years ago|reply
Nitpicking, but in the world of regulations, electric assist tapers off until around 25-30 km/h, at which point you start carrying the entire bike anyway, plus the dead weight of the battery and the motor.
I wonder if this simile could be extended to programming. Being hindered by not being able to choose your own tools?
[+] [-] S_A_P|4 years ago|reply
Meanwhile there are real 10x developers out there that while they care about the tools stay out of the weeds of them.
This line of blog post reminds me of a Paul McCartney interview I read where someone asked him what kind of strings he uses on his guitar. Paul replied “shiny ones”. I think Paul is actually a lot more technical than he lets on in interviews and probably knew full well what kind they were. What he communicated to the person asking the question was that it doesn’t matter so much.
[+] [-] beebeepka|4 years ago|reply
[+] [-] IlliOnato|4 years ago|reply
I rarely use IDEs for code generation, I don't even like autocomplete. For this stuff I use code snippets; I develop collections of those for any language I use. You don't need an IDE for it; any good text editor has such features.
For me really important features of a good IDE are:
- Navigation. Being able to right-click on a function or method name and jump to its definition is very handy. Yeah, I may remember where it's defined; I can also use grep (which does not work all that well for methods). But jumping is so much faster and does not take you out of the flow.
- Code refactoring. I am refactoring code continuously as I work with it. Even simple stuff like renaming a variable or a function (or a method!) is much easier with an IDE.
- Error highlighting.
Note: I can and sometimes do work without an IDE (esp with more obscure languages which don't have good IDE support). There is some fun it it too, like going camping and living for a while without creature comforts like running water and electricity. But normally, if a tool is available, why not use it?
About languages: I agree that a well-designed language allows you to factor away most boilerplate code. (This was one thing I really liked about Perl! It basically allows you to develop a language dialect for your particular needs. The downside with Perl was that everybody was "reducing boilerplate" in their own way, but this is another story)
Just my 2 cents :-)
[+] [-] javcasas|4 years ago|reply
For example, when I write React and I use the Foo component, either it is defined on the same file or it is in one of the imports.
On the other hand, with Angular, the foo component is not imported anywhere. In fact, there is no foo component, just one or many Foo components which declare to use the foo tag, and one or another may be loaded depending on the context of the current component. Good luck getting anything done with such an obfuscated environment without tools to deobfuscate it.
And then you have the heavy enterprise frameworks that make a science out of obfuscated code, so that you don't know what code is being executed, because it is hidden behind several layers of inheritance and interfaces, and the instance to create is choosen via xml-configurable meta-programming based dependency injector. Working with such code is guaranteed insanity without heavy IDEs. I would say it's also insanity with heavy IDEs, but people tend to find that opinion controversial.
[+] [-] jcelerier|4 years ago|reply
this so much. it's priceless to just type a line and have some warnings such as "hey, you're moving this value but using the variable afterwards, take care" or "hey, it looks like you are only using this argument as a reference, consider not passing it by value" just pop up next to the offending line ; when compared to an IDE-less workflow I pretty much divide the amount of hitting "build" I need by ten or more since the IDE tells me everything wrong beforehand.
[+] [-] ByteJockey|4 years ago|reply
Seriously, lsps have gotten really good.
[+] [-] realusername|4 years ago|reply
[+] [-] dharmab|4 years ago|reply
I would add graphical debuggers to your list. You can get by with command line debuggers and there are external attachable debuggers but neither is really comparable to an IDE.
[+] [-] noidesto|4 years ago|reply
[+] [-] onion2k|4 years ago|reply
[+] [-] Frost1x|4 years ago|reply
In the past, this was possible without too much pressure on cognitive load. In modern code bases with all sorts of libraries and layers of abstraction ontop of abstraction ontop of abstraction ad infinitum, it's just not feasible anymore. I got to a point in certain development ecosystems where not relying on tooling started to really hinder me. Self reliance was no longer a strength and a point occurred where I simply had to lean on more and more tooling or I'd be lost.
I still think if you have tooling that does something, you should understand what it's doing and how it's doing, at least once, then let it do every subsequent need for that task. It's good not to have black boxes in your ecosystem. Unfortunately even that is becoming difficult because of the number of layers of abstraction in some ecosystems (especially web development).
I've never been a fan of black boxes that I simply trust and don't know their tradespaces, then hope for the best.
[+] [-] schipplock|4 years ago|reply
I would buy a more powerful computer. I have a project with 34908 files and IntelliJ doesn't care. Not quite 40_000+ files but still a lot :).
Also with IntelliJ I make fewer mistakes. This "thing" is just more intelligent than I am. Add "SonarLint" to the game and I sometimes don't even know _why_ I am wrong :P.
Also I think "Avoid IDE lock-in of your project" is the wrong subtitle for the following paragraph. You would have the same problems by using just a text editor.
Rd6n6 mentioned refactoring. Do that in an editor and you will go crazy after a while :).
I love and hate my IDE :).
[+] [-] mcguire|4 years ago|reply
[+] [-] habibur|4 years ago|reply
The requirement is a little bit less for some other popular languages.
[+] [-] chmod775|4 years ago|reply
Your command line with vim/emacs and other tools that together arrive at the same feature set as a Integrated Development Environment are still... a development environment.
Not using an IDE doesn't mean you can't have autocomplete, syntax checking, linting, automated rebuilds, and all that other good stuff. It's just not all in one package.
And yes you shouldn't force your choice of (integrated) development environment on others. Different people have different needs: News at 11.
[+] [-] mattgreenrocks|4 years ago|reply
* terminal open at root of project used for source control
* one or more tabs for ssh/VMs etc
* IDE/VSCode/vim for editing
Any of those is fine. And sometimes I switch between them depending on my mood. If I’m out and about it can be nice to conserve battery and focus by going full terminal mode. If I have AC power and a full screen then I don’t mind an IDE as much.
One thing I insist on is doing as much work with git from the CLI. IDEs often do things like staging new files automatically that I’m not a fan of.
[+] [-] Macha|4 years ago|reply
To the point on this one, I sometimes find myself running neovim inside the IntelliJ or VSCode terminal, when I need to edit a config file quickly while running scripts in that terminal, or just to edit a file outside the project directory. Or like you, I primarily use the git CLI, because IDEs often use to me unintuitive mappings of GUI buttons to git actions ("what does Synchronize do for git?"), so then it pops open $EDITOR to write my commit message.
[+] [-] andruby|4 years ago|reply
When I need to create a lot of "new" code, I'll usually use nvim. When I need to edit/refactor existing code, I'll more often use atom or vscode.
I like both a lot. When bashing out code that is already reasonably clear in my head, vim works faster and with less "overhead". An ide like vscode works better for me when I need a good global search & replace, or something the ide has plugins for.
[+] [-] tcoff91|4 years ago|reply
[+] [-] the_third_wave|4 years ago|reply
As an aside, I feel the same about the unbridled growth of tooling around certain languages (Javascript being a prime example) and environments (Android comes to mind). Maybe it is just because of the way I started out with 8-bit assembly where a macro assembler was a luxury which could not entirely be trusted to do the right thing but I know I'm not the only one.
[+] [-] willjp|4 years ago|reply
It's usually useful, at least in some abstract way to the team. It felt essential when I worked alone and was accountable for everything.
[+] [-] bitwize|4 years ago|reply
No. You're wrong. Not having the right tools raises the cognitive load. You just think it's simpler because you are severely restricted in the complexity of the programs you can create with just your brain and the documentation.
IDEs expand the complexity of what you can build and make you more productive building programs of any size, because features like autocomplete and refactoring take thr cognitive burden off you.
[+] [-] eirki|4 years ago|reply
[+] [-] spapas82|4 years ago|reply
Beyond that, it was a great experience. Of course, using python contributed to that great experience since most things can be easily remembered and the autocompletes are not so useful due to the dynamic nature of the language. When I needed to do Java/spring development I always fired up eclipse even if though I knew it would take 5 minutes to start and a couple of seconds for each suggestion to appear. However, trying to develop in Java without an IDE by having the javadocs open and copying and pasting all the package and class names all the time and missing everything static typing offers your is a nightmare!
[+] [-] fartcannon|4 years ago|reply
An IDE on top of that always felt restricting to me. Like why limit yourself? But maybe that's a windows/Mac thing.
[+] [-] k__|4 years ago|reply
It's just more flexible, which allows me to use new tech/langs very quickly.
If you don't focus on IDE features, you tend to implement quality of life improvements at a level that also works in an editor. Like in the language, framework, or library you're using (See the code generators point in the article).
With languages like Rust, that have zero cost abstractions, you don't even run into performance problems when doing so.
[+] [-] cgh|4 years ago|reply
[+] [-] h4x0r12345|4 years ago|reply
[+] [-] voidhorse|4 years ago|reply
In most cases I feel that using an IDE nets you short-term, micro-productivity gains and also nets you long-term rot/maintenance headaches. imo it's typically not worth it.
[+] [-] noidesto|4 years ago|reply
[+] [-] blunte|4 years ago|reply
1. interactive debugger
2. quick jump to function/constant implementation
3. show usages of function/constant under cursor
4. source control (Git) diffs
5. database browser
There are probably other things I'm forgetting to mention.
Sure, all of these can either be cobbled together to some degree out of the fundamental individual tools. You can add plugins to Vim or Emacs to help with many of these. With enough effort you can get close to what a polished IDE offers... but you're effectively making your own quirky, fragile, non-portable inferior IDE.
Yeah, a heavy IDE is slow to start and resource hungry. But hardware is cheap, and you only start the IDE once every few days (or weeks).
When I'm on a remote server, then I'm in a shell using vim. Fine, and doable. But to really build and get things done, saving my brain for actual problem solving, I wouldn't want to give up my IDE.
Also, some of the cons on OP's list are problems with the language being developed in, not the IDE.
[+] [-] moron4hire|4 years ago|reply
The complaints levied at Java and Android specifically are issues I've really only seen in that language and on that platform. Excise that and all these arguments feel very flat and empty. It has not been my experience at all that using an IDE means I can't remember my project layouts, API calls, etc.
And frankly, this wreaks of the same sort of elitist arguments that only a small minority of grammarians make against spell-check. So what if the tool is a crutch? ALL TOOLS ARE! That's the point of tools, to off-load some forms of manual labor. A table saw and a fence are going to let me make straight cuts a lot quicker and easier than using a hand saw. Humanity grows and life moves on and troglodytes complain that the field is being "ruined", but what they really mean is they can't keep up.
[+] [-] klodolph|4 years ago|reply
Depending on the language and build system, this might be something I set up manually (set up an IDE project to mirror the build system), something you can set up automatically (export build system to IDE project), or there might be a standard layout for source code that mostly works.
[+] [-] Rd6n6|4 years ago|reply
I don’t really use other ide features. Separate terminals are great
[+] [-] Insanity|4 years ago|reply
Java is a language that does not lend itself to vim. Even just compiling and running a sufficiently large java program can be a pain without an IDE setup.