I've spent my entire career avoiding IDEs, and now VS Code has finally sucked me into what I'm increasingly suspicious is an IDE cunningly disguised as a text editor.
I use it to edit random text files full of notes too, because I trust it to bring back my unsaved work if my laptop crashes.
Everybody I know that uses VIM and VS Code uses them with a bunch of plugins to make them more IDE-like. The result will still probably be more performant than a true IDE, but the downside is there is additional setup time and brittleness. The JetBrains IDEs, at least the ones I've used, just work.
I don’t get why these articles get written. They are so predictable and just…overdone. What’s next “the unreasonable effectiveness of the vim text editor”? You are literally verbatim repeating the a thing that has been written one million times.
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
Refactoring is where it's at for me. The ability to rename functions and variables across not just a local file, but all references in the code base is huge.
Relatedly, the ability to find all usages of a symbol and navigate between them is indispensable for me at this point.
> Relatedly, the ability to find all usages of a symbol and navigate between them is indispensable for me at this point.
I don't know if people just aren't aware, but vi and emacs have been doing this since at least the 90s. This isn't some fancy feature that requires an IDE. Recently the support has improved even more through LSP.
> I don't know if people just aren't aware, but vi and emacs have been doing this since at least the 90s. This isn't some fancy feature that requires an IDE. Recently the support has improved even more through LSP.
No, rtags & friends aren't remotely comparable to an IDE which has a semantic understanding of the code, and will catch the uses without false positives.
I mean, I think they are? Sure jumping to a generic definition like getId will give you more choices, but i know which one i want. Having to push space and then 9 to get the second page and choose the one i want isn't the end of the world.
Recently LSP provides exactly what you desire anyways with context sensitive jumps.
Edit: Regardless, perhaps our difference here lies around what the minimum specification is. My reading of this thread and the post i responded to is that people think moving around in code without an IDE means closing one file, navigating to the next file and opening that one. This is patently not how it works, and what i was adressing.
> I mean, I think they are? Sure jumping to a generic definition like getId will give you more choices, but i know which one i want. Having to push space and then 9 to get the second page and choose the one i want isn't the end of the world.
I often do codebase-wide renamings. I would definitely lose a lot of time if I had to check every single instance of "getId" as you say (to give more precise figures, if I want to rename an "id" I get ~2000 matches). With my IDE I can just ctrl-shift-r and rename any symbol and it works without me having to think about it.
> Recently LSP provides exactly what you desire anyways with context sensitive jumps.
that's likely implementation issues but LSP for C++ in 2021 is definitely not as good & integrated as e.g. native clang integration for parsing.
LSP gives you exactly the same functionality though, since it's what VS Code is also using.
Whether the implementation is prone to false positives (it really shouldn't be) is up the server, not the client (e.g. vim or VS Code). The client actually doesn't have 'a semantic understanding of the code' - that's the point of it, not needing every editor to implement an understanding of every language it wants to support.
> I don't know if people just aren't aware, but vi and emacs have been doing this since at least the 90s. This isn't some fancy feature that requires an IDE. Recently the support has improved even more through LSP.
We know about them. When you start adding these scripts to vi and Emacs they're no longer in the realm of plain text editors. You can add a bunch of hacks to turn vi or Emacs into a poor mans IDE.
I'm surprised how many of my colleagues don't use the debugging features of their IDE. Being able to step through code line by line and see all the variables states at any time and evaluate arbitrary expressions given those states seems far superior to print/console based guesstimation. However, somehow my colleagues still do great work!
Depending on which ecosystem you're working with you may be able to get those tools elsewhere. If you're working with client-side JavaScript for example, then you have multiple choices of browsers with excellent debuggers built in.
That’s still not the same as debugging within your IDE. Having to switch from the browser back to your IDE to find the files to make changes is just another context switch that slows you down. Plus, dealing with async loaded files can be a pain in the browser.
I've tried using VSCode's debugger for Javascript before. And it can be kind of nice, but ultimately on larger projects with their own build tools it can be hard to keep the sourcemaps working in such a way as to not screw up VSCode's debugger, and the gain over Firefox's built in debugger wasn't worth the effort for me to continue to maintain that config.
You can actually configure chrome to be able to edit your local files and save changes directly. Although admittedly it was a bit unreliable when I tried it.
It's a fair sight better than notepad. You get syntax highlighting, Ctrl/Cmd-P to fuzzy search for files to open, and even things like multiple cursors. But you're right that it's not quite the same experience as a full editor. You won't get linting, type checking or autocomplete.
I prefer printf debugging. a) it works everywhere, even say when the bug is only reproducible in a remote CI, or in languages that don't have good IDE support. My printf skills are top notch thanks to using it everywhere. b) the printf stuff can stay around until the next compile. I can easily vary it, put it into VCS, share it with others, etc. For IDEs such features may exist, but again I'm locked into an IDE.
Sure, in some settings the source code is not available and you still want to debug. Then I use debuggers. But outside of that I prefer printf debugging.
Note that I'm not saying that people who prefer debuggers are wrong. They probably have their reasons, as I have. Everyone should be allowed to use the method they prefer the most.
So far as I can tell from having worked with lots of people with lots of different preferences, there is basically no correlation between preferences in debugging approaches and ability/productivity.
I do however really wish the world made it easier to help turn both state introspection via interactive debugger and state introspection via printf shotgun into structured trace-level logging that could be shared and/or committed to the codebase independent of the original debugging tool used.
Yes this. Distributed tracing is making these concepts more popular but in many cases it requires manual instrumentation of every function call and state one wants to track. I would love to see more auto-instrumentation but seems this should be implemented at the interpreter or compiler level.
Using this right now to break apart a 5k line file. Being able to see the call hierarchy of all the functions allows me to move over functions with less dependencies and slowly work towards the ones that are heavily intertwined. I can see it all at a glance without having to jump from one function to another over and over.
Error detection is a big one too. My code in an interpreted language wouldn’t error until this corner case hit, but my IDE tells me the issue as soon as I write it. It’s a huge boost.
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.
> I used Webstorm for years, but switched to VSCode.
> It's just more flexible, which allows me to use new tech/langs very quickly.
I'm sure you know, but Webstorm is limited by license/design. JetBrains sells editors to deal with almost every tech. I personally subscribe to the Toolbox for ~$200/yr and get all the IDEs. Some languages (like Rust) don't have a custom IDE, just a plugin into IntelliJ, the ur IDE from them.
The JetBrains IDE family is half way there. You can run your code on remote targets now, but I think the code itself still has to actually be on your machine.
He bashes VS Code at the end but that seems exactly what he wants. VS Code is more of a text editor then an IDE, and you can turn off all the “issues” he complains about.
Man, I've been going back to full-fat VS after working in VS Code for a while, and boy, does VS just chug even opening a "Hello World" C# project.
(I used VS at work regularly and the performance on a million-SLoC solution was quite bad, but I didn't expect it to be much better given the size of the solution)
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.
I'm not sure it's about sloppiness, some things are more complex than others. I believe IDEs are tools that allow one to handle more complexity. They have resulted in more complex software, but maybe that's because they've enabled us to write more complex software (and more of it).
Like an architect that uses CAD to create plans for a large building -- sure, they could do that with a pen on paper as well, but it would require a lot more people and a lot more time.
That can be said about languages, libraries, plugins, any tools you choose to make use of. It's just about sticking to good practices and understanding what you're using instead of choosing to be a bad dev. That shouldn't require excluding everything that has the potential to be used improperly.
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.
Same. I would very much like to use a text editor full-time given how strapped for resources my machine is, but I work on either Java or Angular 90% of the time. The productivity loss is too much to deal with, and the solution is to add a bizarre number of plugins to the editor to the point that it becomes somewhat of an IDE itself, without the guarantee that the plugins will interact well with each other.
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.
I use vim's stdin and stdout redirection to interact with git and can do things like staging or unstaging files or diff hunks and committing from within the editor.
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.
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.
The difference between an IDE and a souped-up vim or emacs configuration is ... very little. Your average fancy pants vim config has auto-completion, debuggers, etc.
I think this is not wrong. When you are using the better quality IDEs (for example C# with Visual Studio, or Java with IntelliJ), they offer you a lot this isn't there in Emacs or VIM.
I currently mostly work in Python using Emacs, because I don't know of anything that adds really compelling full-blown IDE features for a dynamically typed language.
I will also say that Datagrip and Microsoft SQL Server Studio are both way ahead of any Emacs SQL packages I've tried.
With JetBrains PyCharm or the PyCharm plugin in IntelliJ, you can treat all python3 as statically typed ... use the type-annotations and then linter will catch your mistakes.
Yes, I agree. Conditional on some "difficult" languages like Java, the experience is quite different. For non-difficult languages like C, R, and Python, the gap is small.
1. Optional: do install of neovim
2. git pull dotfiles
3. cd dotfiles
4. install.sh
5. Profit $$$
Sure, there's some initial setup time but I'm not seeing how its orders of magnitude faster unless your vim config is super bloated and/or has a lot of external dependencies.
Yeah. For my vim I need fd, fzf and rg. So my dotfiles repo also has an install script. I never had the patience to setup lsp correctly. Maybe I’ll try again with all lua neovim plug-ins and config.
None of these feel particularly true to me, but in particular "less code is more readable" is just so clearly not true. If this was the case we'd all still be using Perl.
I see some truth to this, under a more reasonable interpretation. Clearly, well-golfed k/j/q/apl isn't doing the reader any favors. On the other hand, unnecessarily verbose code can be just as tortuous as unnecessarily terse code. And when you're comparing apples to apples (e.g. same algorithm, same data structures), shorter code is somewhat correlated to better performance.
In terms of developer productivity, less code faster to write and faster to read. To a point. The sweet spot is the shortest code that's still easy to read & write.
However "less conceptually complex code is often easier to reason about' is absolutely true and it takes most people a fair amount of practice (and at least if you're me, a lot of wondering why your foot suddenly has a hole in it) to properly appreciate the difference between "less conceptually complex" and "less".
I write very different code when not using an IDE.
If I’m not using an IDE, my code has to be contextually simpler for me to remember it (because I can’t just jump to definition) which makes my code ultimately better organized. However, I assume this comes at some speed penalty, at least in the short term.
For personal projects I don’t use an IDE, but for work because everyone else writes IDE-style code, I also need to use an IDE to wrangle it.
> When you have to manually find a file to change a subroutine implementation, or to refactor a subroutine, you will have good file names and a good directory structure. The Antipattern of the directory layout of your typical Java Enterprise Project is a Testament to this. (src/main/java/org/company/product/...)
To play devil’s advocate, isn’t the goal of a good IDE to abstract away the actual filesystem organization of the code? As long as I can quickly look up function definitions via the IDE, I don’t care how they’re actually organized on disk. As an analogy, I’m sure my Gmail inbox is internally stored across multiple different databases and would be a nightmare to manually browse at the database level, but I don’t care because I can easily access all my messages through my email client or the web UI.
Disclaimer: I’m not an IDE user myself (simply because I’m oldschool, have all the emacs keybindings burned into my muscle memory, and I’ve never taken the time to learn one well), and in principle agree with the author’s point. IDEs are not (yet) at a point where they’ve rendered the filesystem completely irrelevant, although some are getting pretty close.
I may be talking out of my ass, as I've never used it, but this is my impression of most smalltalk environments, that they just expose objects and functions, not files. For example: https://pharo.org/features.html under "Software as objects"
> By not using an IDE, you have to remember the syntax of the language you are using, the subroutines from your own project and their arguments. You also remember (standard-)library subroutines better for your chose programming language.
Use an IDE, and discover + learn the syntax by being assisted. Start biking on a unicycle, and fail.
> When you have to manually find a file to change a subroutine implementation, or to refactor a subroutine, you will have good file names and a good directory structure. The Antipattern of the directory layout of your typical Java Enterprise Project is a Testament to this. (src/main/java/org/company/product/...)
There were no IDEs for Java when it started. And it immensely structured everything. Not having an IDE doesn't mean anything about naming.
> With big projects, it might slow you down to have the IDE load the entire project before you can start working. Some Projects with 40000+ files might take >5 minutes to load.
But in return you'll get something that will tell you what's going on, or even do hot code swaps, saving you a lot more than those 5 min.
> This is almost always the result of bad language design and/or bad library design. An example is developing android apps in Java with Android studio. Here, you will be slowed down a great deal in order to program without Android Studio. There will be a steep learning curve.
The IDE does more than just edit code. Welcome to different resolutions, devices, etc. Please tell me you'd rather have the device mess of J2ME // Symbian.
> Good Open Source Projects encourage people to clone, fork, and maybe even to contribute to a Project. People are able to directly edit files on github, if an IDE is not required and they know the language being used. Not requiring an IDE makes it easier for blind people, who might be using screenreaders to understand your project, and enables people without modern hardware (which might be unable/impractical to run an IDE) to work on your project.
IDEs have makefiles / build.xml / whatever. You're totally uninformed
> Have you ever seen a Java Enterprise Project? Sometimes the Java classes in there have 20+ import statements, automatically generated by the IDE. Working in this style, with such long package names and lots of classes/namespaces eventually almost forces you to use an IDE because there is just so much, that it becomes impractical to remember.
All Java IDEs support maven or whatever is popular right now.
> Not having Autocomplete / Code Generation guides you naturally to writing more compact and idiomatic Code in the Language of your Choice. It helps you to learn language-specific features and syntactic sugar.
That's a language design issue.
In Java, there is the Concept of Getters, Setters, toString, hashCode and so on. These methods can be auto-generated by the IDE.
In practise, this leads to bloat. The IDE is simply compensating for missing language features (built-in hashing of a composite data type, built-in string representation ).
Agreed. And, also, who cares? Yes, Java is a mediocre language and way too verbose. I spend a bunch of time in Java and I don't notice the worst of that because I (like literally every Java dev I know) use an IDE. You shouldn't separate a language from the standard tooling it comes with/enables - they're intertwined.
Java fields themselves, along with their setters and getters, are entry points in which to control via annotations whether properties are read-only, write-only, or read/write in multiple contexts (e.g. Spring Configuration, JSON de/serialization), how they're serialized in JSON (serialized type can be different, field name can be adjusted), field ordering, and human readability.
Just thinking setters and getters set and get the property is naive and retrograde.
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.
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.
I understand, I just wonder if he/she really means to it. Who knows, some people have very good memory. When I work with a new (for me) topic, I am trying to get basic understanding of topic, still it far from remembering exact method signatures.
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.
You can't easily consider a treatment or remedy or library function you don't remember. Better to use all the tools at hand (memory being a useful tool - a L2 cache as it were) than handicap yourself by only using a few.
I'd rather have my doctor consulting recent knowledge base than use their 30 year old memories from school. Medicine is not set in stone and recommendations change.
The problem with using cache is that you can feel certain it's correct but you don't really know until you check with the source. And since you check with the source anyway, the cache becomes a drag to correctness
Do they have every single medicine memorized, or just the ones they most commonly use? Sure, I tend to remember the parts of libraries and apis I use often, but I'd still argue my editor having a reminder just a keystroke away is very beneficial.
There are over 20,000 approved medications in the US. I don't really feel like this analogy is holding up very well. But, have I happened to remember about 200 or so API and library calls over my career? Probably.
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.
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.
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.
> 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 :).
> You might think it’s obvious that you need to rename both A.f and B.f, but that’s just because this snippet is trivial.
In the general case, yes – but that's like saying “no termination analysis is possible because of the halting problem”. The IDE can safely refactor, unsafely attempt a refactor, and warn when it does the latter rather than the former.
Though I didn't know PyCharm didn't do that! That's dangerous; thanks for the warning.
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.
The minimum targeted device is sometimes not even capable of running the development environment. Doom was developed on $10k NeXT workstations. Good luck trying to develop Doom on a 386.
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.
Agreed. It's obvious this is written by some pseudo intellectual who wants to feel smart and different by saying they don't use an IDE. Benefits easily out weigh any downsides.
“Men have become the tools of their tools. Money is not required to buy one necessity of the soul. Most of the luxuries and many of the so-called comforts of life are not only not indispensable, but positive hindrances to the elevation of mankind.”
Henry David Thoreau
One day the IDE will do most of the coding. Users will just click “ok” and spend most of their time asking IT to reboot and reinstall things until it all just works(tm).
This isn't an actual verbatim Thoreau quote, it's rather a mishmash of disparate sentences from Walden,[0] so perhaps the use of the quotes is mistaken.
The sentences do carry a general spirit, however, which is very nice and pleasing, until you're reminded that Thoreau's rugged existence in nature was supported by his mum cooking him dinner.
I would instead offer the following sentence from Walden as a better encapsulation:
"The best works of art are the expression of man’s struggle to free himself from this condition, but the effect of our art is merely to make this low state comfortable and that higher state to be forgotten."
Namely, our arts and crafts come to cater to the alleviation of the burden of our physicality, yet neglect the needs of our spirituality.
I doubt that either the command line or an IDE can cater much to spirituality, although I've heard some argue that there's much food for the soul in Emacs and Lisp.
The internet is a tool that I’ve again become tool of, it seems. The fuller context of the quote I was searching for I think still applies as much to IDEs as emacs. Lisp is arguably a more solid and earthly foundation.
But lo! men have become the tools of their tools. The man who independently plucked the fruits when he was hungry is become a farmer; and he who stood under a tree for shelter, a housekeeper. We now no longer camp as for a night, but have settled down on earth and forgotten heaven. We have adopted Christianity merely as an improved method of agri-culture. We have built for this world a family mansion, and for the next a family tomb. The best works of art are the expression of man’s struggle to free himself from this condition, but the effect of our art is merely to make this low state comfortable and that higher state to be forgotten. There is actually no place in this village for a work of fine art, if any had come down to us, to stand, for our lives, our houses and streets, furnish no proper pedestal for it. There is not a nail to hang a picture on, nor a shelf to receive the bust of a hero or a saint. When I consider how our houses are built and paid for, or not paid for, and their internal economy managed and sustained, I wonder that the floor does not give way under the visitor while he is admiring the gewgaws upon the mantel-piece, and let him through into the cellar, to some solid and honest though earthy foundation.”
“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.”
Portable electric power tools are such a game changer when working on cars. I could never go back to the days of doing it by hand, it would be ten times worse for construction.
I would never use power tools on my motorcycle or car. On threading, nuts/bolts/screws should always be torqued gently into spec. On unthreading, I prefer to feel if there's significant resistance, warranting a cleaning/deoxidization of the part.
Predrilling a screw hole in some hard wood? Yeah I don't need to feel anything except the power of lithium cells dumping electricity into torque.
Power drills are simple tools, they are the 'vi' equivalent of the 'ed' manual drill.
The physical equivalent of an IDE would be a laser-guided auto-centering/levelling drill with automatic drill bit changer/sharpener, depth guide, dust evacuation and material sensor with automatic lookup for which hole size and depth to use for the given task. It would weigh 15 kg, need an external power pack and be unusable in tight corners. For some tasks it would be a great time saver, for others it would just be in the way. Some workers would love it, others would fight it. Some would be more productive using it, others would be far more productive if only that damn megadrill did not insist on using that oversized drill bit while they knew the construction would be much stronger by using a slightly smaller bit, necessitating them to override the megadrill tool selector for each and every hole they drilled.
No, a CNC machine is a distinct entity which enables the user to create objects which can not be created using only a power drill. The lower-tech predecessor of a CNC machine is a milling machine [1], not a hand-held drill.
There isn’t anything a CNC can make that someone with a file and a lot of times on their hands cant.
Heck you can do that with a drill too mostly using jigs.
I had to create a few times quite complex shapes from a block of aluminum and what I did I just 3D print a bunch of jigs and drilled out 98-99% of the material away in the same way a CNC would and finished it with dremmel.
> There isn’t anything a CNC can make that someone with a file and a lot of times on their hands cant.
True, but the comparison here was against a power drill, not a person with a file and lots of time on his hands. While it may be theoretically possible to achieve the accuracy of a CNC mill using a power drill it would not be the tool of choice. Achieving the repeatability of a CNC mill using hand tools is hard, the more complex the piece the harder it becomes.
To get back to basics without getting lost in a forest of tools these comparisons are based around the 'To IDE, or not to IDE' question. The CNC mill was pulled in through a side door but doesn't really feature in the comparison which was between a simple power drill and the hypothetical 'smart drill' I dubbed 'megadrill' which tries to be as 'helpful' as possible. Some people would like such a contraption, others would shun it.
I don't feel I pulled in the CNC through a side door, I was responding to your comment of:
`laser-guided auto-centering/leveling drill with automatic drill bit changer/sharpener, depth guide, dust evacuation and material sensor with automatic lookup for which hole size and depth to use for the given task.`
Which at that point you probably, as I said, just want a CNC machine.
Given I have and use a handheld drill, a drill press, a manual mill, a CNC mill, a manual lathe, and a CNC lathe, as well as Vim, Emacs, VS Code, and Intellij, I think I'm decently well informed on this topic.
If you setup a CNC mill, you can use it as a manual mill, some people just don't like those ergonomics. I mainly keep my manual mill as a better drill press, and use the CNC for most stuff.
I generally just use intellij for everything in the same way.
CNC mills are super useful. But not all the time. I regularly (not all the time, or even a majority, but regularly) choose a manual mill over my cnc because for simple jobs that only require a part or two, it's faster than setting up the 3d model, deciding on cutting strategies, setting up the tools, etc.
My choice in editors follows the same logic. If I just need to jot down some notes, or knock together a simple bash script or something, it doesn't really matter what I use. Whatever has syntax highlighting and is available on that system is great. Something more complex, where I don't want to spend brain cycles on repetitive tasks or management that the tools can handle for me, I'd rather use something that will handle that for me.
No, a Hole-Hawg [1] - made famous in these circles by Neal Stephenson's essay 'In the beginning was the command line' [1] - is just a powerful drill without any bells and whistles, a "lump of metal with a handle sticking out of it". It would be more sort of an 'ed on steroids', trading off ease of use for raw power.
I think both your and parent's analogy are somewhat off.
IDE is like a big machine that can make a variety of parts to the exact spec very fast with minimal waste. This machine can help even inexperienced operator become productive in short time.
vi/ed is like manual power tools that can accomplish the same task but it takes a lot longer, wastes a lot more material and only experienced operators can be somewhat productive but nowhere near what they could achieve with the big machine.
When users become experts with these tools, they can produce all sorts of custom parts that big machine is not configured for but like they always say - use the right tool for the job: if you are making 5 custom parts then use the hand tools, when you are making hundreds of the same part, use the big machine.
I think you've hit upon an important distinction, because while construction workers won't be bringing hand tools "to the worksite," there are in fact many people who do use hand tools for fine woodworking in their woodshops.
People work with wood for different reasons and people write software for different reasons. All of these tools and approaches can be valid.
Some may be interested in rapid and low cost large scale construction - big teams working fast. Others may be interested in creating a thing of beauty either independently or in small groups of likeminded craftsmen. It shouldn't be surprising that we have many different tools and practices.
Exactly. When I’m tinkering around in Scheme crafting cutesy little interpreters a simple text editor is great, and having an IDE would feel like having someone standing over my shoulder whispering to me every rule of a game I already know by heart.
On the other hand, when I’m working on a new area in a several thousand file project with dozens of contributors, or any number of its side-projects that I may have never seen before in my life, it’s more like having talented counsel at my shoulder informing me of all the various contracts I’d be expected to observe for any possible plan of action I might consider taking.
Conversely, for model building, I have much better results using #80 drill bits in a hand held twist drill than trying to chuck them into a power drill and hope that it will not break the bit or rip the delicate work asunder.
Similarly, an IDE can be overkill when you're writing a self-contained one-off task, or dealing with an opinionated IDE that doesn't fit with the project you're importing.
Wouldn't another analogy be knowing how to navigate a boat with a sextant and a chronometer versus modern radio and GPS maritime navigational aides? The latter's more efficient, but those with deep knowledge of navigation understand how to use the former if necessary.
As someone replied to GP, you should definitely know how to complete tasks with only basic tools and without advanced tools. But it doesn't mean you should only use basic tools or no tools at all. I mean I do know how to calculate without calculator but it doesn't mean I dont use calculator. I use it all the time. Of course deep knowledge almost always means that you have a strong hold on the basics.
It's not being lazy. There is no need for me to use an Integrated Development Environment.
Many of the most highly productive people use Separated Development Environments. The integration is most times not necessary. I have never had an IDE provide a feature that I needed and couldn't quickly create or obtain.
People let you install your tools in your monolithic IDE package. Why are you so insistent on degrading people who are experts in their fields?
In 20 years of working as an engineer and also interviewing, I’ve seen maybe 3 people that could be as productive without an IDE. They certainly exist, but I believe they are rare exceptions.
It kind of depends on how we are defining IDE. Every developer I know who doesn't use an IDE uses either VS Code, vim or emacs with a bunch of plugins which approximate IDE functionality (but are much more customizable and configurable which I suspect is what they like about it). At the end of the day every IDE is just a text editor with plugins too. It really comes down to whether you want something that just works (and probably forces you to do some things THEIR way on some margin) or you want to tweak your dev environment to be just right for your workflow.
Yeah, that's true. For me, it'd be somewhat irritating to work without LSP features like "jump to definition," "hover to view doc string," or even tab completion. Arguably, these are IDE features. But when it comes to higher-level features like build tooling or even grepping, I'd much rather work from a command line.
Something like tab completion can't exist outside the editor, but as soon as features can exist as separate tools, bundling them together begins to feel like a limitation. Having separate tools means you can discard the ones you don't need, which is part of what leads to fully-featured IDEs feeling so bloated to me.
True. I've been slowly moving towards VSCode from IntelliJ over the past year or so and that has mostly been driven by better Scala LSP implementation (Metals has gotten immeasurably better over that time). And even when I used IntelliJ exclusively, I more or less used it as a text editor with code completion/jump to definition. I still used a separate terminal for git, builds, etc.
I think there are also certain efficiencies that come with bundling as well though. You end up with a bunch of things specifically designed to work together so they in some cases are better than the generic, composable tools. I still find myself firing up IntelliJ from time to time because sometimes it just seems to work better (faster, more responsive, etc) even though the feature I am using technically exists in VSCode + Metals.
> …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.
For me the choice is more a) tooling that does everything but distracts me all the time b) tooling with some limitations but versatile, consistent across languages and completely modular.
I'm not rejecting IDEs because I didn't like one thing. I like nothing about IDEs except the refactoring feature; but even that doesn't make up for the painful UX. IDEs are like MS Word: they do everything I need but I hate every moment of it.
Dunno, I kind of like no IDE. If you use an IDE, it's basically editor + a bunch of command line tools being invoked from the IDE's interface. You can also just use an editor + those command line tools from a terminal. It's the same functionality with a slightly different workflow and IMO not worse.
I disagree with the author's dislike of code completion tools but somewhat agree with the other points. In particular how some IDEs create their own project structure.
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.
> 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.
The best swimmers can stay afloat with pounds and pounds of weight dragging the down; the worst swimmers will drown. Doesn't mean weighing you down makes you a better swimmer.
Yes, it does; but when you're trying to set a record swimming the English Channel, or escaping from a sinking ship you'd be an idiot to do it deliberately weighing yourself down with weights.
I suppose there's something to be said for both ways of doing things ultimately, depending on what situation you're in, and what your goal is.
...but unconditionally advising people to swim with weights, is simply bad advice.
> when you're trying to set a record swimming the English Channel
Your training time to competition time is about 99:1 (on the high side for the competition time). The record attempts (or the emergencies) are a poor continuation of this analogy when it comes to programming.
> unconditionally advising people to swim with weights, is simply bad advice
So we should advise them to use floats instead, since it makes swimming so much easier?
Well the analogy doesn't actually allow for a starter/bad swimmer as they drown first.
Also, swimmers don't swim with weights to improve technique or strength. I'd expect it would result in unorthodox or worsened technique due to trying to swim around the artificial imbalance of the weights.
> Also, swimmers don't swim with weights to improve technique or strength.
They use the aquatic analog to weights - disabling their arms or legs, drastically increasing drag (via multiple swimsuits, or suits with chute-like pockets), swimming against bungee cords.
Other than bungee cords for small pools/space usage, can't say I've heard of such drag methods, only of resistance training outside of the pool. Though, I didn't mean to take the analogy off-topic, maybe I got too literal.
The thing I hate most about IDEs is when they insinuate themselves into a project's development workflow so deeply that you can't make do without them.
Do I have to spin up a whole session of the IDE just to run my test suite? Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter? Is there so much boilerplate or XML or whatever within the frameworks we're using that writing or changing code is impossible without automation? These are bad things.
An IDE can be a powerful abstraction, but when the underlying layer it's abstracting over becomes inaccessible, then all it's doing is adding more complexity by obscuring concrete details.
"An IDE can be a powerful abstraction, but when the underlying layer it's abstracting over becomes inaccessible, then all it's doing is adding more complexity by obscuring concrete details"
I can edit, compile and install my kernel and all its drivers in a few command lines from shell, why more and more projects, most way simpler than a kernel, ask me to install for example VSC just to build them? Give me a Makefile and possibly enough instructions to integrate its options into the favorite IDE, but making the IDE a requirement, especially for small projects or those one simply wants to build and install, adds only more complexity.
> Do I have to spin up a whole session of the IDE just to run my test suite?
In the java ecosystem at least, the answer is no. But in highly CI-based situations, the answer is still no, but you DO need the CI system to be up, and the only way to run a test at all is to just commit something and see the CI system run it, e.g. because the tests require a database engine that isn't installed on your development machine.
I'm not saying that's a good idea, just saying that I have seen that in real (as in, for pay and for real eyeballs) dev teams. I've never observed 'I only know how to run my tests inside the IDE'. IDEs (again, this is mostly speaking from the perspective of the java ecosystem) use build tools as project definitions, and those build tests all know how to run the test suite from the command line. `mvn test` is all you need to type.
> Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter?
No, it's `mvn install` or `mvn build` or whatever take on 'build' you are looking for specifically.
If you ditch your IDE, __nothing__ whatsoever would change: Your build is _still_ based on a build tool. (it better be, in the sense that trying to run the build by hand or by patching a bunch of shell scripts together is almost 100% correlated with very low quality dev teams in my experience).
In other words...
what are you on about? IDEs don't abstract such details away to extreme degrees. In fact, insofar that they ever did (generally in GUI builders, which, what with the web and languages like java and Adobe Air and silverlight falling by the wayside in the past few years for front-end dev - are kinda dead), the new takes on such tools all very explicitly keep the whole 'actually this just edits a text file of some sort and this automated click-the-GUI-together tool is bending over backwards to ensure that the underlying file looks as close as possible to what you would write by hand.
In my current organization I saw a project, where there is no Maven. The build system is a couple of configuration files for Eclipse IDE and that's the only way to run it. I'm glad I didn't have to do anything around that.
My team used to have stuff off that nature after we inherited the code base. Acquisition and movement of HQ meant a brand new team on a 15 year old B2B SaaS. Trying to move away from the combination of shell scripts, perl scripts, eclipse config, etc. Over to Gradle has been painful, but with it for onboarding new devs.
That definitely does happen with really poorly considered starting points, but in my experience it's also maybe a day's work to pull that apart and put it into Maven/Gradle (unless you've also got, like, some really terrifying ant stuff to go with it, and even then you can sometimes ask "is this even necessary?" and get with the chopping down).
The ant eclipse plugin does some lifting for you. Sometimes, it can be better this way than having 2 buildthings not in sync... But yeah ant all the way if everyone's happy with it...
I had to fix one such case 6 years ago where the build procedure was to build in IntelliJ.
It took a day or two to get kt over to Maven: basically create a Maven file, make sure everything were in the correct standard Java layout, then build and unzip the war file and compare it to the unzipped war file from the existing build process repeatedly while getting the last tweaks in place.
If you're not familiar with them, have a look at visual studio SLN files. They are exactly what was described. There is more and more being pushed into the msbuild files instead (a separate format, that is at least theoretically separate from visual studio) but the weird and underdocumented sln file still exists. And msbuild files are absolutely unreadable XML crap anyway, good luck writing one by hand.
>> Do I have to spin up a whole session of the IDE just to run my test suite?
> what are you on about?
This complaint is based on a .NET project I used to work on. I'm sure this isn't universally the case for everything .NET, but I had to work with one instance of visual studio open in the code repository and a second instance of visual studio open in the test repository. Everything we did was configured in and executed through VS. It was pretty nasty.
Poor project management != fault of IDE, it's the one responsible for choosing to configure the project in said way. That's not dismissing the fact that VS and other IDEs allow, and even recommend, nasty setups but, unless they force them, I don't see blaming optional features or poor usage of a tool as a rational reason to write off an entire toolset that can be powerful and productive.
A) that makes managing relevant information more efficient, while not hiding any of that information.
B) vs. a tool that hides some details, providing a tradeoff of higher productivity MOST of the time, but at the cost of requiring a fall back tool on other (rare?) occasions.
I would say, once a tool stops providing access to any (even rarely) relevant details, it has become an abstraction.
> The thing I hate most about IDEs is when they insinuate themselves into a project's development workflow so deeply that you can't make do without them.
Isn't this the case with Android Studio? Is it even possible to do Android development without Android Studio?
> Do I have to spin up a whole session of the IDE just to run my test suite? Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter?
Can you say what language/platform you talk abojt here?
I currently work in Kotlin with IntelliJ where sadly the only working IDE is IntelliJ,but you can build it just fine and even fix bugs using whatever editor you want.
I also maintain a lot of React code, used to work on .Net Core and some plain old C# before Core, I've maintained Angular and before that Java, older Delphi versions and even PHP.
The only projects that had the problem you talk about were
- Visual Studio (not Visul Studio Code) projects from before .Net core
- and old Delphi projects.
That said, I'm kind of stuck with IntelliJ now because of Kotlin (which is an awesome language) but I miss NetBeans a lot and how it - instead of saving everything in its own configuration files - simply accepted Maven .pom files as configuration, meaning uncluttered repos and still having all config synced and up to date everywhere. (Maven is well though out so if you just accept the defaults the files are small and contain only the things they need to contain like name, namespace and version, dependencies and necessary configuration.)
You mean when you or a team chooses to embed them into the project's workflow to that degree? Or are you talking about the worst IDEs no one should use while sounding like it is a general IDE issue with the industry standards?
Any decent IDE doesn't enforce such things, it is something questionable devs choose to incorporate. You may inadvertently do this if you don't know an IDE, and try to use excessive features available, but that's still on you for doing so. It shouldn't have been a decision made by someone lacking in knowledge/experience, whether a junior dev or a senior selecting an unknown tool without proper evaluation.
Or are you implying such features from IDEs can somehow be attained by non-IDE toolchains that don't also ingrain you in those toolchains to make use of said features?
But you don't use git to write your code. Code autocompletion and cross referencing are pretty big productivity boosters that won't prevent you from learning command line git. Also I bet you don't use the command line for diffing files.
Also the problems is that most IDEs half ass their git client. When I was using Sourcetree, I rarely ever felt the need to go to the command line.
> Also I bet you don't use the command line for diffing files.
Wait, isn't this normal? I run "diff" and "git diff" all the time (I think I have those both set up to invoke colordiff, but it's still a command line program). Also vim -d.
Occasionally I browse diffs on Github or Bitbucket instead. I don't find it an improvement. I do favour editors over IDEs, but I don't think I'm an extremist on this one.
For my sibling using `git diff`, can i introduce you to tig[0]? I think it is inferior to magit, but you can install and test it with `apt install tig` and then `tig` in a git directory.
> 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.
"Best" is a marketing term. How do you mean it as it applies to software quality or productivity?
I'm trying to understand if you're serious, since the author (who notes "I myself use IntelliJ, CLion and MySQL workbench almost everyday") doesn't even seem to believe what he's writing.
Specifically: "The best developers" indeed know how to work without an IDE. They also know 5 programming languages, 50 libraries, and know a whole bevy of esoteric randomness, such as difference between a Thompson-NFA style regex engine and the limitations thereof, or something like that.
There is no such thing as a 'the best developer' that doesn't know much. The 'knows many things and has lots of experience' is a tautologic argument.
In the mean time, bad programmers 'use an IDE a lot and are lost without it'. That's also tautologic.
In other words, your observation proves absolutely nothing, in regards to whether it is wise to use an IDE or not. You're not going to magically turn a bad programmer into a good one by uninstalling their IDE. You're not going to ensure a new programmer is going to turn into a good one if you advise them to forego an IDE, nor will you ruin a potentially good one if you install an IDE on their computer.
Being able to do the wrong thing should not be confused with power. It's just a broken tool, that is broken so often, it needs this so-called "power" to clean up after it when it shits the bed.
I'm not even sure what to make of this. No sane developer I know will work without an IDE, much less prefer not using an IDE.
Sure, we can probably write code without an IDE but in what way does that mean I'm a better developer? I feel myself cringing whenever I hear that a developer is going to reach for TextEdit or Notepad++ to write code.
Those editors aren't really part of the conversation anymore. I would say they were maybe over 12 years ago. Not so nowadays.
People are referring to SublimeText, Vim, Emacs, VSCode as Programming Text editors. VSCode is currently the most popular with vim as purist second and Emacs for "elite" hackers.
I'm really just asking, do you think VSCode is a text editor? I used to put it in the same categories as IDE (and thought that it was really better than Netbeans and Eclipse)
The lines have blurred. I would put it more in the editor category. You really need to download plugins for it to come close to an IDE and it's not as feature complete as say pycharm or Clion.
I would say VSCode is more in the code editor category, but as I said before the lines are blurring. With enough plugins and configuration even vim and emacs can straddle that line.
In general IDE's tend to have more features less bugs, and have all of these features out of the box.
That's just confusing big-brand mature IDE suites as the definition for IDE though. Any dev working on an actual project is going to be using those tools with plugins/extensions, configured as an IDE.
A dev would require completely separate tools that provide that functionality to say otherwise.
No it's not. "Big branded" IDE's are actually more feature complete in terms of intellisense and auto complete and auto formatting when compared to "code editors" that are fully loaded with plugins.
They usually achieve much better integration with the projects and this is not including the side features like remote development or database browsers. VSCode comes close to an IDE much closer than vim or emacs when fully loaded on plugins but even in this case jetbrains edges them out.
The "programming text editors"/"code editors" of now that are used in place of traditional IDEs are practically always extended to, by definition, being an IDE, albeit a leaner, more custom-fit one.
naw, despite this there is a noticeable lack of features from the "code editors" side. So much so that the definitions have evolved but the distinction remains.
Nah if you ever used a modern IDE from the jetbrains line. In order to even get the IDE working with a project you need to configure it to work.
That absolutely necessitates understanding of the details of what's going on. You are literally building automation by using additional tooling. It doesn't build it for you.
Also screwing up a git repo, what does that even mean? A bad commit?
If you have a Maven project, IntelliJ will open it and configure itself automatically. The IDE user doesn't need to know anything about Maven build configurations. It just works.
The Maven Project IS the configuration. Intellij is only a shortcut. It let's you access configurations via click rather than via a command line expression.
In the end if you want to create a Maven Project configuration or edit the configuration it's on you to do it. At most intellij will just generate boilerplate for you.
No that's not how it works. IDEA has its own project files (*.iml, .idea), separate from Maven. We are talking about IDE projects which are separate from Maven.
Yes that's configuration for the IDE. But the project itself is configured off of Maven, the project files for the IDE are ADDITIONAL settings for the IDE itself.
For example in CLion you can't create a new target from the IDE, you have to edit the cmake file.
Exactly this. Productive use of IDEs (or vim, or emacs, or vsc, or …) is the opposite of cargo-culting: one knows exactly how to decompose the abstractions presented by the IDE. Should they fail, or prove limited, one grumbles a bit and then goes and does it by hand.
Using or not using an IDE because good developers use but don’t need an IDE misses the point. It’s never the choice of tool, it’s knowing how to use it.
The Git tools built into IDEs are indeed very convenient, but I often warn junior (and even mid) developers to NOT use them unless you understand exactly what they’re doing.
The US Navy is teaches C without an IDE. This makes sense for them. If they had institutional knowledge going back to the 1970s, it all still pretty much applies and looks the same as it did 50 years ago, or another 50 years from now.
Yes. You should use a good tooling if your goal is to make something.
Me too I dislike this kind of absolute statements about IDEs.
The author make a few good points about abusing some features; just like abusing any tool beyond their intended purposes.
IMO the best is the compromise of making the code IDE agnostic. So yeah, I do use IDEs and other tools in conjunction to that the tools I used and the skills I know are not bound to a specific project.
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.
Rubymine can, with one click, make an ER diagram of your ActiveRecord model -- from the code, not the db schema. That pays for itself right there, especially if you're learning someone else's code base. Try it for a day, you'll never go back.
I've used it before. I found it valuable, but there were a number of reasons I went back to a smart editor instead. I do use Jet Brain's DataGrip, so I'm a big fan of their tools overall.
> 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.
I know VSCode is positioned this way in the market, probably to differentiate it from VS. And I switched to it from a much less “smart” editor (TextMate, which I still adore! No offense meant to TM creator/maintainers!).
I’m having a hard time seeing this as a clear distinction, however. I mean, VSCode has a built in debugger/protocol, language server/protocol/intellisense, file system aware refactoring, code rewriting refactoring, integrated git client, inline blame and history navigation, GitHub integration, linter integration including automated fixes…
I understand it’s a different tool than VS, but I honestly don’t have a clear understanding of what separates editor from IDE in this case.
The good editors for programmers, since ancient times, for example already in the BRIEF editor for MS-DOS, before 1990, provide means to attach arbitrary CLI commands or scripts to menus or keyboard shortcuts.
Therefore, if you want you can invoke from inside the editor any commands needed for project management or for compiling/linking/running/debugging.
So in the end you are right that a powerful editor can do what an IDE does, after some customization.
The main difference with IDE's is that the project management provided by the IDE is normally non-optional, you are forced to always use it.
In 30 years of experiencing a very large number of IDE's I have not seen even a single one where using its project management functions would not waste a lot of time comparing to non-integrated alternatives.
I think that it is sad that only a very small number of developers know how to use correctly the ancient program "make". I do not know why this happened. To use correctly "make" I have never needed anything else besides reading the GNU make manual provided with gmake, but it seems that very few people read the manual.
The only time when I had to write makefiles was more than 20 years ago, when I have written a set of universal makefiles, which I have been using unchanged for every software project ever since. For any new project I need to just (optionally) add a file with some extra definitions, e.g. a list of directories where the source files are located or the names of the executables or libraries that must be built. If no definitions are provided, suitable defaults are used, e.g. the directory with the Makefile also contains the source files and the target is an executable with the same name as the directory. The Makefile per target directory may contain just a single line, with an include directive for the universal makefile. The universal makefile searches all the source directories for all the possible types of source files, selects automatically the appropriate compilers based on the language indicated by the file name extensions and on the cross-compilation target if one is specified, generates automatically all the dependencies and so on.
Instead of using "make" like this, almost all the open-source projects that I have seen have huge and immensely complicated makefiles that are much more difficult to read, understand and modify than the source files of the programs. When the makefiles are generated from templates, those are typically even more difficult to understand and modify.
I have no idea who loves those extremely complex methods of compiling and building software projects.
During the years, a lot of replacements for "make" have been introduced, which are better than "make" used wrongly, but I have not seen any which is better than "make" used rightly, without pointless complications.
It is not published, but there is not really much about it, except exploiting most features provided by gmake.
For easy maintenance, the universal makefile is split into 4 files that are completely universal + 1 makefile with extra definitions per each combination of operating system and CPU type that might be a target for compilation.
The extra files for specific compilation targets, e.g. skylake-linux-gnu, armv7e-m4-none-eabi, i686-cygwin and so on, contain definitions for the names of all the tools that might be used, e.g. compilers for various programming languages, linking commands, librarian commands, binary file modification commands (e.g. objcopy), default locations for library files, default locations for include files, default values for compilation flags.
The 4 completely universal files do not contain directly any command name or command flags or any file name or any directory name. They contain only variable names whose values are either defined in the operating system/CPU specific makefile or whose values are determined by the make command by scanning the project and by transforming the found files, e.g. by replacing the file name extensions.
The 4 completely universal files are:
1. A file for the top directory of a complex project, which descends recursively in all subdirectories and runs there the given make command, if a Makefile exists in the subdirectory
2. A file with make targets. Examples of make targets:
4. A file with definitions, which is the most important in simplifying the makefiles needed for any new project, which are typically almost empty, because they do not need any other line besides including the universal makefile, even if I usually add a definition with a list of source directories, in order to separate the place where the project is built from the place where the source files are stored and possibly some options, e.g. building a debug version instead of a release version, or building for a cross-compilation target.
Example how to determine the directories with source files:
I use many more kinds of source files, so the OBJS above is just a shortened example.
The operating system/CPU type specific makefile includes the 3 universal files with targets, rules and definitions and it also includes the automatically generated dependencies:
include $(OBJS:.o=.d)
so later only the specific makefile needs to be included, depending on the compilation target.
There are many more details, but these are the general principles. They are intended to make me write as little as possible in the Makefile for a new project...
I think the difference is that when you start out with VSCode, you tend to do things by editing text and using the CLI, and with time you add plugins and tools that makes it more into an IDE. When starting out with IntelliJ or Pycharm or whatever, you first start by trying to understand the IDE itself to generate your project, and then you start writing code inside the project. A bit like libraries and frameworks. At least that has been my experience.
My experience has been that I’ve installed very few extensions, and all of them improve the editing experience. I haven’t added anything that provides an IDE experience, I just use those features that are built in.
The comments have just devolved into people arguing or confusing mature big-brand IDEs, with excessive and all-encompassing features, as the definition for an IDE.
Anything lesser, they're calling a simple code editor but, by actual definition, they are referring to a lighter IDE (as the ones that can be installed as base editors they have all extended with plugins/extensions to that point) and then acting like the topic is about the big-brand IDEs, even though it is making points against tooling they are all using with their "editors" just like what you're using VSCode for.
Regarding especially Eclipse, project and build management in an IDE can be good. Typical Java projects that use Maven and are built "officially" with scripts and CI systems without an IDE can be worked on by Eclipse quite cleanly by
- Checking sources out of version control
- "Importing" them in the Eclipse workspace as projects from existing code in an arbitrary location
- Configuring what Maven installation, and with what configuration files, is to be used to build your projects
- Defining a grimoire of Maven command lines (build and test locally, build and deploy somewhere else, package for release, etc.) as run/debug configurations
The impact is limited to harmless project metadata files (containing nothing important that isn't mirrored from Maven POM files) and repeating in the closed world of Eclipse options configurations, paths etc. that are probably already in scripts, CI pipeline definitions and so on.
A lot of this is starting to result in talking semantics of what an IDE is. A powerful/smart code editor, extended to have the functionality most will ever use an IDE for (and definitely incorporating the base definition of what an IDE is), ends up being argued as different because the base product didn't start as an IDE or it isn't as feature-rich as the mature, big-brand IDEs people have grown up hearing. Why people are even playing semantics with this when the topic is making points against tooling, that programmers are very much using with tools like VSCode, I really don't understand.
The tooling and layout of the same functionality you choose to use is something more modern tools, and product versions, have improved upon but is unrelated to what an IDE is. It also differs between tools and IDEs. For you to say you've never used an IDE with simple or fast file handling is either a lie or a severe lack of experience, as almost all decent ones have a 1 or 2-click approach via the explorer (and toolbar/hotkeys if you don't like an explorer side-pane). I actually can't think of any half-decent IDE that doesn't have the same approach for files as popular code editors, and I've used a lot of both for different platforms and languages. The only time I've had noticeable experiences is in cases via command/terminal but we're talking GUI editors here.
Worth noting, I have never in my career found myself mentioning any Eclipse-based IDE as an example of a good IDE. In fact, almost every dev I've ever met regards them as the worst IDEs they have experienced, not as a baseline standard for or expectation of IDEs. It's basically redundant to comment on x experience being bad as anyone that has ever used one already knows that is expected.
Your sentiment about the right tools for the job is spot on, and one should strive to choose tools that make you more productive but IDEs are one tool of many.
There's a host of other things to consider, like what is the testing environment like, library management, repository layout, etc. When you're working across a wide variety of languages, setups, environments, etc. choosing an IDE like Eclipse or Atom might not always be the right tool for the job. This also completely neglects the fact that vi/vim and Emacs, while mostly considered "text editors", can be enhanced to essentially be IDEs in their own right.
I think the article's arguments are weak, but so is this counter-argument, sorry.
jesus christ. coding used to mean something. i guess we all should eat baby food because we arent being smart cool or clever by wasting time and energy chewing.
Definitely. There's no dichotomy though. I use some of the features of my IDE: editing obviously, interactive debugging and just general exploration via Ctrl-click are infinitely faster and more powerful than anything I've used on the command line. It's not great for everything though. So I keep swapping to the terminal for everything which I find more effective there: Git, running tests, creating projects, and the like.
Basically, don't think a single toolset is always going to be superior to your other toolsets. Feel free to mix and match, and change over from one toolset to the other when it's convenient or just more efficient. But of course moderation isn't going to get the clicks.
What? No, sorry, your comment is the nonsense. Not using an IDE doesn't mean 'no tooling', it just means 'different tooling we don't happen to call 'IDE''.
I think it's so blurry now as to be a pointless debate anyway - is VS Code an 'IDE'? Or is it an editor with a load of plug-ins available that give it equivalent functionality to an IDE? Because the latter definitely applies to vim and emacs and sublime too, and if it's the first, then... A lot of people don't use an IDE!
It seems to really depend on the type of work that you are doing. If you write high level code using many external libraries in a language like Java, using an IDE can be a time saver. If you are write low level C code, I found that using an IDE does not seem to be that helpful. But that's just my 2c.
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.
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.
What blows my mind is that in New York, we've decided to deal with this by requiring speed governors on pedal-assist bicycles to limit them to around 20mph... while they're required to share the street with cars that are free to travel at almost any speed.
Traffic rules basically give drivers a way to deal with other vehicles going different speeds. So a the driver of a scooter going 20 mph and the driver of a car going 40 mph can share the same road, just like a driver of a truck going 40 mph can share the road with the driver of a car going 60 mph.
The key difference is whether a motorcycle driver's license is required. The electric bicycle manufacturer can choose to forgo the speed governors and be subject to motorcycle safety/licensing/etc regulations.
(They've also done some more motorized cycle and electric content lately. A recent video showed how to rebuild an old motorcycle's frame into an electric motorcycle using a kit.)
An e-bike that goes 60kph seems a bit out of the ordinary. Most are limited to 25kph or 45kph. But even 45 is still fast with only a bicycle helmet though
I see, your own peddling can make them go faster. Ok these things should be illegal!
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?
Not everywhere. Australia supports both the European pedelec classification of 250W with a 25km/h cutout and a local one of 200W with no speed limit (which can be hand-throttle in some states but must be pedal-assist in others). New Zealand just has a flat 300W with no speed limit.
I live out in the country in Australia. I’m planning a velomobile with an auxiliary motor for both touring and local use, and with this combination I expect and hope to attain an average speed of over 50km/h for the ~39km trip to the nearest town for church and groceries on Sundays. (I currently tend to average 22–24km/h on my recumbent tricycle with no motor, the trip typically taking 1h35–1h50m, with an estimated average power output of 120W. 200W is quite a lot to add!)
In the US, class 3 electric bicycles can assist up to 28 miles per hour, or around 45 km/h. I might be able to ride 28 miles per hour on a regular bicycle, but I can't do it for very long.
Are they regulated like non-electric bikes? In Europe, I believe the main difference is insurance and license, which are required for e-bikes with motor-supported speeds > 25km/h (at least in some countries, not sure how uniform it's handled).
As far as I know there is no jurisdiction in the US where you need either a license or auto insurance for a class 3 electric pedal assist bicycle. I think you generally ride them wherever regular bicycles are ridden.
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.
Now imagine your job being to get from point A to B. 99.5% of all the devs I've seen that insist on "VS Code" struggle so bad it's laughable, and yet when you point it out they turn it into some sort of IDE pissing contest.
There has been a great surge of ebikers among people working in food delivery services around Prague last year. Before that most of the guys used regular bikes.
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 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.
What about refactoring tools? What about integrated debugging, stepping right into the code you're editing on your screen? What about hot reload?
If Unixheads would stop pretending their stone-knives-and-bearskins development tools were equivalent to full-fledged IDEs, development would have advanced much more than it has decades ago.
The whole "real men use vi" type superiority complex failure mode is intensely annoying (and I say this as somebody who often has original ex-vi installed) but the inverted version where you just have a superiority complex from the opposite direction isn't actually any better.
It continues to amaze me that "it's worth becoming familiar with a wide range of tools and then pick the one that's going to work best for you in any given situation" is a concept so many people have trouble with.
This is why normally I err on the side of complaining at "anti-IDE" people since my setup is way more minimalist than most of theirs so at least I'm complaining about people who're theoretically on the same side :)
We have that to. We even have post Mortem debugging. Did you know you can load a core dump into gdb? To me it seems like a new generation of developers is reinventing the wheel because they don’t know about what tools are available.
The old unix editors have had rename across project, find references, go to definition/implementation for several years at this point via lsps (the same way vscode gets its functionality).
> What about integrated debugging
Those are usually (slightly ecosystem dependent) wrappers around a terminal debugger.
> What about hot reload?
Correct me if I'm wrong, but these are also wrappers around cli functionality (once again, might be ecosystem dependent). And you're probably just saving yourself the trouble of writing/running a script.
The whole system is the IDE in the sense that it's meant to be an "integrated development environment".
But that's not really a good thing: you only have one system, therefore only one environment.
For example:
How do you use multiple versions of the same library for different project? It's not an easy thing to do if you rely on the system paths for libraries.
It's much better if libraries are just a thing you install to the current project rather than being a system wide thing.
I know it's a personal anecdote, but 100% of the devs I've worked with who refused to use an IDE ranged from below average to flat out bad at software development.
388 comments
[ 3.0 ms ] story [ 435 ms ] threadOn the other side, I’d never use vsc to edit a normal text file…
I use it to edit random text files full of notes too, because I trust it to bring back my unsaved work if my laptop crashes.
I highly doubt that.
I don’t really use other ide features. Separate terminals are great
Relatedly, the ability to find all usages of a symbol and navigate between them is indispensable for me at this point.
I don't know if people just aren't aware, but vi and emacs have been doing this since at least the 90s. This isn't some fancy feature that requires an IDE. Recently the support has improved even more through LSP.
No, rtags & friends aren't remotely comparable to an IDE which has a semantic understanding of the code, and will catch the uses without false positives.
Recently LSP provides exactly what you desire anyways with context sensitive jumps.
Edit: Regardless, perhaps our difference here lies around what the minimum specification is. My reading of this thread and the post i responded to is that people think moving around in code without an IDE means closing one file, navigating to the next file and opening that one. This is patently not how it works, and what i was adressing.
I often do codebase-wide renamings. I would definitely lose a lot of time if I had to check every single instance of "getId" as you say (to give more precise figures, if I want to rename an "id" I get ~2000 matches). With my IDE I can just ctrl-shift-r and rename any symbol and it works without me having to think about it.
> Recently LSP provides exactly what you desire anyways with context sensitive jumps.
that's likely implementation issues but LSP for C++ in 2021 is definitely not as good & integrated as e.g. native clang integration for parsing.
Whether the implementation is prone to false positives (it really shouldn't be) is up the server, not the client (e.g. vim or VS Code). The client actually doesn't have 'a semantic understanding of the code' - that's the point of it, not needing every editor to implement an understanding of every language it wants to support.
We know about them. When you start adding these scripts to vi and Emacs they're no longer in the realm of plain text editors. You can add a bunch of hacks to turn vi or Emacs into a poor mans IDE.
Having the ability to do everything from your IDE allows you to leverage all of the tooling built into that IDE.
Sure, in some settings the source code is not available and you still want to debug. Then I use debuggers. But outside of that I prefer printf debugging.
Note that I'm not saying that people who prefer debuggers are wrong. They probably have their reasons, as I have. Everyone should be allowed to use the method they prefer the most.
I do however really wish the world made it easier to help turn both state introspection via interactive debugger and state introspection via printf shotgun into structured trace-level logging that could be shared and/or committed to the codebase independent of the original debugging tool used.
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.
I'm sure you know, but Webstorm is limited by license/design. JetBrains sells editors to deal with almost every tech. I personally subscribe to the Toolbox for ~$200/yr and get all the IDEs. Some languages (like Rust) don't have a custom IDE, just a plugin into IntelliJ, the ur IDE from them.
Only benefit I see is remote development over terminal.
https://blog.jetbrains.com/idea/2021/01/run-targets-run-and-...
https://visualstudio.microsoft.com/
(I used VS at work regularly and the performance on a million-SLoC solution was quite bad, but I didn't expect it to be much better given the size of the solution)
https://languagetool.org/
(it is 'than', not 'then')
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.
I don't know that I view that as a positive. A lot of software development is about managing complexity. IDEs allow developers to be sloppier.
In the same way that faster CPUs have resulted in less optimized software over the years, IDEs have resulted in more complex software.
Like an architect that uses CAD to create plans for a large building -- sure, they could do that with a pen on paper as well, but it would require a lot more people and a lot more time.
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.
Much holy warring ensues from people forgetting this ;)
* 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.
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.
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.
I currently mostly work in Python using Emacs, because I don't know of anything that adds really compelling full-blown IDE features for a dynamically typed language.
I will also say that Datagrip and Microsoft SQL Server Studio are both way ahead of any Emacs SQL packages I've tried.
I've also enjoyed the Emacs/Python experience :)
Sure, there's some initial setup time but I'm not seeing how its orders of magnitude faster unless your vim config is super bloated and/or has a lot of external dependencies.
In terms of developer productivity, less code faster to write and faster to read. To a point. The sweet spot is the shortest code that's still easy to read & write.
However "less conceptually complex code is often easier to reason about' is absolutely true and it takes most people a fair amount of practice (and at least if you're me, a lot of wondering why your foot suddenly has a hole in it) to properly appreciate the difference between "less conceptually complex" and "less".
If I’m not using an IDE, my code has to be contextually simpler for me to remember it (because I can’t just jump to definition) which makes my code ultimately better organized. However, I assume this comes at some speed penalty, at least in the short term.
For personal projects I don’t use an IDE, but for work because everyone else writes IDE-style code, I also need to use an IDE to wrangle it.
To play devil’s advocate, isn’t the goal of a good IDE to abstract away the actual filesystem organization of the code? As long as I can quickly look up function definitions via the IDE, I don’t care how they’re actually organized on disk. As an analogy, I’m sure my Gmail inbox is internally stored across multiple different databases and would be a nightmare to manually browse at the database level, but I don’t care because I can easily access all my messages through my email client or the web UI.
Disclaimer: I’m not an IDE user myself (simply because I’m oldschool, have all the emacs keybindings burned into my muscle memory, and I’ve never taken the time to learn one well), and in principle agree with the author’s point. IDEs are not (yet) at a point where they’ve rendered the filesystem completely irrelevant, although some are getting pretty close.
Use an IDE, and discover + learn the syntax by being assisted. Start biking on a unicycle, and fail.
> When you have to manually find a file to change a subroutine implementation, or to refactor a subroutine, you will have good file names and a good directory structure. The Antipattern of the directory layout of your typical Java Enterprise Project is a Testament to this. (src/main/java/org/company/product/...)
There were no IDEs for Java when it started. And it immensely structured everything. Not having an IDE doesn't mean anything about naming.
> With big projects, it might slow you down to have the IDE load the entire project before you can start working. Some Projects with 40000+ files might take >5 minutes to load.
But in return you'll get something that will tell you what's going on, or even do hot code swaps, saving you a lot more than those 5 min.
> This is almost always the result of bad language design and/or bad library design. An example is developing android apps in Java with Android studio. Here, you will be slowed down a great deal in order to program without Android Studio. There will be a steep learning curve.
The IDE does more than just edit code. Welcome to different resolutions, devices, etc. Please tell me you'd rather have the device mess of J2ME // Symbian.
> Good Open Source Projects encourage people to clone, fork, and maybe even to contribute to a Project. People are able to directly edit files on github, if an IDE is not required and they know the language being used. Not requiring an IDE makes it easier for blind people, who might be using screenreaders to understand your project, and enables people without modern hardware (which might be unable/impractical to run an IDE) to work on your project.
IDEs have makefiles / build.xml / whatever. You're totally uninformed
> Have you ever seen a Java Enterprise Project? Sometimes the Java classes in there have 20+ import statements, automatically generated by the IDE. Working in this style, with such long package names and lots of classes/namespaces eventually almost forces you to use an IDE because there is just so much, that it becomes impractical to remember.
All Java IDEs support maven or whatever is popular right now.
> Not having Autocomplete / Code Generation guides you naturally to writing more compact and idiomatic Code in the Language of your Choice. It helps you to learn language-specific features and syntactic sugar.
That's a language design issue.
In Java, there is the Concept of Getters, Setters, toString, hashCode and so on. These methods can be auto-generated by the IDE. In practise, this leads to bloat. The IDE is simply compensating for missing language features (built-in hashing of a composite data type, built-in string representation ).
That's a language design issue.
What a shit article
Agreed. And, also, who cares? Yes, Java is a mediocre language and way too verbose. I spend a bunch of time in Java and I don't notice the worst of that because I (like literally every Java dev I know) use an IDE. You shouldn't separate a language from the standard tooling it comes with/enables - they're intertwined.
Just thinking setters and getters set and get the property is naive and retrograde.
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.
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.
You can't easily consider a treatment or remedy or library function you don't remember.
https://www.youtube.com/watch?v=jR7d56UeeeU <= Song-based memorization aide for 200 different medications
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.
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.
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.
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 :).
The requirement is a little bit less for some other popular languages.
Dynamically typed languages can hardly be automatically refactored.
https://www.beust.com/weblog/2021/06/20/refactoring-a-dynami...
In the general case, yes – but that's like saying “no termination analysis is possible because of the halting problem”. The IDE can safely refactor, unsafely attempt a refactor, and warn when it does the latter rather than the former.
Though I didn't know PyCharm didn't do that! That's dangerous; thanks for the warning.
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.
Henry David Thoreau
One day the IDE will do most of the coding. Users will just click “ok” and spend most of their time asking IT to reboot and reinstall things until it all just works(tm).
The sentences do carry a general spirit, however, which is very nice and pleasing, until you're reminded that Thoreau's rugged existence in nature was supported by his mum cooking him dinner.
I would instead offer the following sentence from Walden as a better encapsulation:
"The best works of art are the expression of man’s struggle to free himself from this condition, but the effect of our art is merely to make this low state comfortable and that higher state to be forgotten."
Namely, our arts and crafts come to cater to the alleviation of the burden of our physicality, yet neglect the needs of our spirituality.
I doubt that either the command line or an IDE can cater much to spirituality, although I've heard some argue that there's much food for the soul in Emacs and Lisp.
[0] https://gutenberg.org/files/205/205-h/205-h.htm
But lo! men have become the tools of their tools. The man who independently plucked the fruits when he was hungry is become a farmer; and he who stood under a tree for shelter, a housekeeper. We now no longer camp as for a night, but have settled down on earth and forgotten heaven. We have adopted Christianity merely as an improved method of agri-culture. We have built for this world a family mansion, and for the next a family tomb. The best works of art are the expression of man’s struggle to free himself from this condition, but the effect of our art is merely to make this low state comfortable and that higher state to be forgotten. There is actually no place in this village for a work of fine art, if any had come down to us, to stand, for our lives, our houses and streets, furnish no proper pedestal for it. There is not a nail to hang a picture on, nor a shelf to receive the bust of a hero or a saint. When I consider how our houses are built and paid for, or not paid for, and their internal economy managed and sustained, I wonder that the floor does not give way under the visitor while he is admiring the gewgaws upon the mantel-piece, and let him through into the cellar, to some solid and honest though earthy foundation.”
- Nobody
Predrilling a screw hole in some hard wood? Yeah I don't need to feel anything except the power of lithium cells dumping electricity into torque.
The physical equivalent of an IDE would be a laser-guided auto-centering/levelling drill with automatic drill bit changer/sharpener, depth guide, dust evacuation and material sensor with automatic lookup for which hole size and depth to use for the given task. It would weigh 15 kg, need an external power pack and be unusable in tight corners. For some tasks it would be a great time saver, for others it would just be in the way. Some workers would love it, others would fight it. Some would be more productive using it, others would be far more productive if only that damn megadrill did not insist on using that oversized drill bit while they knew the construction would be much stronger by using a slightly smaller bit, necessitating them to override the megadrill tool selector for each and every hole they drilled.
[1] https://en.wikipedia.org/wiki/Milling_(machining)
Heck you can do that with a drill too mostly using jigs.
I had to create a few times quite complex shapes from a block of aluminum and what I did I just 3D print a bunch of jigs and drilled out 98-99% of the material away in the same way a CNC would and finished it with dremmel.
True, but the comparison here was against a power drill, not a person with a file and lots of time on his hands. While it may be theoretically possible to achieve the accuracy of a CNC mill using a power drill it would not be the tool of choice. Achieving the repeatability of a CNC mill using hand tools is hard, the more complex the piece the harder it becomes.
To get back to basics without getting lost in a forest of tools these comparisons are based around the 'To IDE, or not to IDE' question. The CNC mill was pulled in through a side door but doesn't really feature in the comparison which was between a simple power drill and the hypothetical 'smart drill' I dubbed 'megadrill' which tries to be as 'helpful' as possible. Some people would like such a contraption, others would shun it.
`laser-guided auto-centering/leveling drill with automatic drill bit changer/sharpener, depth guide, dust evacuation and material sensor with automatic lookup for which hole size and depth to use for the given task.`
Which at that point you probably, as I said, just want a CNC machine.
Given I have and use a handheld drill, a drill press, a manual mill, a CNC mill, a manual lathe, and a CNC lathe, as well as Vim, Emacs, VS Code, and Intellij, I think I'm decently well informed on this topic.
If you setup a CNC mill, you can use it as a manual mill, some people just don't like those ergonomics. I mainly keep my manual mill as a better drill press, and use the CNC for most stuff.
I generally just use intellij for everything in the same way.
My choice in editors follows the same logic. If I just need to jot down some notes, or knock together a simple bash script or something, it doesn't really matter what I use. Whatever has syntax highlighting and is available on that system is great. Something more complex, where I don't want to spend brain cycles on repetitive tasks or management that the tools can handle for me, I'd rather use something that will handle that for me.
[1] https://www.milwaukeetool.com/Products/Power-Tools/Drilling/...
[2] https://web.archive.org/web/20180218045352/http://www.crypto...
IDE is like a big machine that can make a variety of parts to the exact spec very fast with minimal waste. This machine can help even inexperienced operator become productive in short time.
vi/ed is like manual power tools that can accomplish the same task but it takes a lot longer, wastes a lot more material and only experienced operators can be somewhat productive but nowhere near what they could achieve with the big machine.
When users become experts with these tools, they can produce all sorts of custom parts that big machine is not configured for but like they always say - use the right tool for the job: if you are making 5 custom parts then use the hand tools, when you are making hundreds of the same part, use the big machine.
People work with wood for different reasons and people write software for different reasons. All of these tools and approaches can be valid.
Some may be interested in rapid and low cost large scale construction - big teams working fast. Others may be interested in creating a thing of beauty either independently or in small groups of likeminded craftsmen. It shouldn't be surprising that we have many different tools and practices.
On the other hand, when I’m working on a new area in a several thousand file project with dozens of contributors, or any number of its side-projects that I may have never seen before in my life, it’s more like having talented counsel at my shoulder informing me of all the various contracts I’d be expected to observe for any possible plan of action I might consider taking.
When I’m paid to produce, I use tools that help me produce.
When I’m enjoying my passion, I actually do use an entirely different set of tools!
https://youtu.be/ShEez0JkOFw
https://old.reddit.com/r/Clojure/comments/4j3ani/with_all_of...
Similarly, an IDE can be overkill when you're writing a self-contained one-off task, or dealing with an opinionated IDE that doesn't fit with the project you're importing.
And then we did it once.
And then we used GPS and Total Stations ever since.
Many of the most highly productive people use Separated Development Environments. The integration is most times not necessary. I have never had an IDE provide a feature that I needed and couldn't quickly create or obtain.
People let you install your tools in your monolithic IDE package. Why are you so insistent on degrading people who are experts in their fields?
I'm, of course, not talking about certain platforms that almost certainly expect or require the use of a specific IDE build tool.
Something like tab completion can't exist outside the editor, but as soon as features can exist as separate tools, bundling them together begins to feel like a limitation. Having separate tools means you can discard the ones you don't need, which is part of what leads to fully-featured IDEs feeling so bloated to me.
I think there are also certain efficiencies that come with bundling as well though. You end up with a bunch of things specifically designed to work together so they in some cases are better than the generic, composable tools. I still find myself firing up IntelliJ from time to time because sometimes it just seems to work better (faster, more responsive, etc) even though the feature I am using technically exists in VSCode + Metals.
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'm not rejecting IDEs because I didn't like one thing. I like nothing about IDEs except the refactoring feature; but even that doesn't make up for the painful UX. IDEs are like MS Word: they do everything I need but I hate every moment of it.
I disagree with the author's dislike of code completion tools but somewhat agree with the other points. In particular how some IDEs create their own project structure.
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.
The best swimmers can stay afloat with pounds and pounds of weight dragging the down; the worst swimmers will drown. Doesn't mean weighing you down makes you a better swimmer.
An excellent choice in analogies.
Yes, it does; but when you're trying to set a record swimming the English Channel, or escaping from a sinking ship you'd be an idiot to do it deliberately weighing yourself down with weights.
I suppose there's something to be said for both ways of doing things ultimately, depending on what situation you're in, and what your goal is.
...but unconditionally advising people to swim with weights, is simply bad advice.
Your training time to competition time is about 99:1 (on the high side for the competition time). The record attempts (or the emergencies) are a poor continuation of this analogy when it comes to programming.
> unconditionally advising people to swim with weights, is simply bad advice
So we should advise them to use floats instead, since it makes swimming so much easier?
Also, swimmers don't swim with weights to improve technique or strength. I'd expect it would result in unorthodox or worsened technique due to trying to swim around the artificial imbalance of the weights.
They use the aquatic analog to weights - disabling their arms or legs, drastically increasing drag (via multiple swimsuits, or suits with chute-like pockets), swimming against bungee cords.
Do I have to spin up a whole session of the IDE just to run my test suite? Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter? Is there so much boilerplate or XML or whatever within the frameworks we're using that writing or changing code is impossible without automation? These are bad things.
An IDE can be a powerful abstraction, but when the underlying layer it's abstracting over becomes inaccessible, then all it's doing is adding more complexity by obscuring concrete details.
This. All day long.
I can edit, compile and install my kernel and all its drivers in a few command lines from shell, why more and more projects, most way simpler than a kernel, ask me to install for example VSC just to build them? Give me a Makefile and possibly enough instructions to integrate its options into the favorite IDE, but making the IDE a requirement, especially for small projects or those one simply wants to build and install, adds only more complexity.
In the java ecosystem at least, the answer is no. But in highly CI-based situations, the answer is still no, but you DO need the CI system to be up, and the only way to run a test at all is to just commit something and see the CI system run it, e.g. because the tests require a database engine that isn't installed on your development machine.
I'm not saying that's a good idea, just saying that I have seen that in real (as in, for pay and for real eyeballs) dev teams. I've never observed 'I only know how to run my tests inside the IDE'. IDEs (again, this is mostly speaking from the perspective of the java ecosystem) use build tools as project definitions, and those build tests all know how to run the test suite from the command line. `mvn test` is all you need to type.
> Do I have to dig through eleven nested GUI settings dialogues to find out what the command to build the damn project is, just so I can tweak a build parameter?
No, it's `mvn install` or `mvn build` or whatever take on 'build' you are looking for specifically.
If you ditch your IDE, __nothing__ whatsoever would change: Your build is _still_ based on a build tool. (it better be, in the sense that trying to run the build by hand or by patching a bunch of shell scripts together is almost 100% correlated with very low quality dev teams in my experience).
In other words...
what are you on about? IDEs don't abstract such details away to extreme degrees. In fact, insofar that they ever did (generally in GUI builders, which, what with the web and languages like java and Adobe Air and silverlight falling by the wayside in the past few years for front-end dev - are kinda dead), the new takes on such tools all very explicitly keep the whole 'actually this just edits a text file of some sort and this automated click-the-GUI-together tool is bending over backwards to ensure that the underlying file looks as close as possible to what you would write by hand.
IntelliJ even has tooling to get you started:
https://www.jetbrains.com/help/idea/convert-a-regular-projec...
It took a day or two to get kt over to Maven: basically create a Maven file, make sure everything were in the correct standard Java layout, then build and unzip the war file and compare it to the unzipped war file from the existing build process repeatedly while getting the last tweaks in place.
You nailed it in one — visual studio is exactly what I was complaining about.
> what are you on about?
This complaint is based on a .NET project I used to work on. I'm sure this isn't universally the case for everything .NET, but I had to work with one instance of visual studio open in the code repository and a second instance of visual studio open in the test repository. Everything we did was configured in and executed through VS. It was pretty nasty.
how IDE "can" be an abstraction?
It's tool, it's wrapper (e.g button over commandline commands), but abstraction?
I do agree
There is a line between a tool:
A) that makes managing relevant information more efficient, while not hiding any of that information.
B) vs. a tool that hides some details, providing a tradeoff of higher productivity MOST of the time, but at the cost of requiring a fall back tool on other (rare?) occasions.
I would say, once a tool stops providing access to any (even rarely) relevant details, it has become an abstraction.
Isn't this the case with Android Studio? Is it even possible to do Android development without Android Studio?
Oh yes: https://www.lambdanative.org/
That said, it would be quite difficult to write anything substantial without Android Studio.
Can you say what language/platform you talk abojt here?
I currently work in Kotlin with IntelliJ where sadly the only working IDE is IntelliJ,but you can build it just fine and even fix bugs using whatever editor you want.
I also maintain a lot of React code, used to work on .Net Core and some plain old C# before Core, I've maintained Angular and before that Java, older Delphi versions and even PHP.
The only projects that had the problem you talk about were
- Visual Studio (not Visul Studio Code) projects from before .Net core
- and old Delphi projects.
That said, I'm kind of stuck with IntelliJ now because of Kotlin (which is an awesome language) but I miss NetBeans a lot and how it - instead of saving everything in its own configuration files - simply accepted Maven .pom files as configuration, meaning uncluttered repos and still having all config synced and up to date everywhere. (Maven is well though out so if you just accept the defaults the files are small and contain only the things they need to contain like name, namespace and version, dependencies and necessary configuration.)
I can happily say that this problem doesn't exist on the other platforms I deal with but I guess you already know :-)
Any decent IDE doesn't enforce such things, it is something questionable devs choose to incorporate. You may inadvertently do this if you don't know an IDE, and try to use excessive features available, but that's still on you for doing so. It shouldn't have been a decision made by someone lacking in knowledge/experience, whether a junior dev or a senior selecting an unknown tool without proper evaluation.
Or are you implying such features from IDEs can somehow be attained by non-IDE toolchains that don't also ingrain you in those toolchains to make use of said features?
Also the problems is that most IDEs half ass their git client. When I was using Sourcetree, I rarely ever felt the need to go to the command line.
Wait, isn't this normal? I run "diff" and "git diff" all the time (I think I have those both set up to invoke colordiff, but it's still a command line program). Also vim -d.
Occasionally I browse diffs on Github or Bitbucket instead. I don't find it an improvement. I do favour editors over IDEs, but I don't think I'm an extremist on this one.
Maybe I'm old - my whole os/shell is my ide
[0] http://jonas.github.io/tig/
"Best" is a marketing term. How do you mean it as it applies to software quality or productivity?
I'm trying to understand if you're serious, since the author (who notes "I myself use IntelliJ, CLion and MySQL workbench almost everyday") doesn't even seem to believe what he's writing.
Specifically: "The best developers" indeed know how to work without an IDE. They also know 5 programming languages, 50 libraries, and know a whole bevy of esoteric randomness, such as difference between a Thompson-NFA style regex engine and the limitations thereof, or something like that.
There is no such thing as a 'the best developer' that doesn't know much. The 'knows many things and has lots of experience' is a tautologic argument.
In the mean time, bad programmers 'use an IDE a lot and are lost without it'. That's also tautologic.
In other words, your observation proves absolutely nothing, in regards to whether it is wise to use an IDE or not. You're not going to magically turn a bad programmer into a good one by uninstalling their IDE. You're not going to ensure a new programmer is going to turn into a good one if you advise them to forego an IDE, nor will you ruin a potentially good one if you install an IDE on their computer.
It says nothing.
People take pride in being less productive and making things harder than they need to be.
Sure, we can probably write code without an IDE but in what way does that mean I'm a better developer? I feel myself cringing whenever I hear that a developer is going to reach for TextEdit or Notepad++ to write code.
People are referring to SublimeText, Vim, Emacs, VSCode as Programming Text editors. VSCode is currently the most popular with vim as purist second and Emacs for "elite" hackers.
I would say VSCode is more in the code editor category, but as I said before the lines are blurring. With enough plugins and configuration even vim and emacs can straddle that line.
In general IDE's tend to have more features less bugs, and have all of these features out of the box.
A dev would require completely separate tools that provide that functionality to say otherwise.
They usually achieve much better integration with the projects and this is not including the side features like remote development or database browsers. VSCode comes close to an IDE much closer than vim or emacs when fully loaded on plugins but even in this case jetbrains edges them out.
That absolutely necessitates understanding of the details of what's going on. You are literally building automation by using additional tooling. It doesn't build it for you.
Also screwing up a git repo, what does that even mean? A bad commit?
The Maven Project IS the configuration. Intellij is only a shortcut. It let's you access configurations via click rather than via a command line expression.
In the end if you want to create a Maven Project configuration or edit the configuration it's on you to do it. At most intellij will just generate boilerplate for you.
For example in CLion you can't create a new target from the IDE, you have to edit the cmake file.
> In order to even get the IDE working with a project you need to configure it to work.
Meaning you already have a Maven/SBT/Gradle project and need to get the IDE to work with it.
Why else would I come on here to make some claim that is false?
Using or not using an IDE because good developers use but don’t need an IDE misses the point. It’s never the choice of tool, it’s knowing how to use it.
Some examples of Teaching/learning.
The US Navy is teaches C without an IDE. This makes sense for them. If they had institutional knowledge going back to the 1970s, it all still pretty much applies and looks the same as it did 50 years ago, or another 50 years from now.
Yes. You should use a good tooling if your goal is to make something.
> you’re not being smart, cool or clever by choosing
c
The author make a few good points about abusing some features; just like abusing any tool beyond their intended purposes.
IMO the best is the compromise of making the code IDE agnostic. So yeah, I do use IDEs and other tools in conjunction to that the tools I used and the skills I know are not bound to a specific project.
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.
I know VSCode is positioned this way in the market, probably to differentiate it from VS. And I switched to it from a much less “smart” editor (TextMate, which I still adore! No offense meant to TM creator/maintainers!).
I’m having a hard time seeing this as a clear distinction, however. I mean, VSCode has a built in debugger/protocol, language server/protocol/intellisense, file system aware refactoring, code rewriting refactoring, integrated git client, inline blame and history navigation, GitHub integration, linter integration including automated fixes…
I understand it’s a different tool than VS, but I honestly don’t have a clear understanding of what separates editor from IDE in this case.
Therefore, if you want you can invoke from inside the editor any commands needed for project management or for compiling/linking/running/debugging.
So in the end you are right that a powerful editor can do what an IDE does, after some customization.
The main difference with IDE's is that the project management provided by the IDE is normally non-optional, you are forced to always use it.
In 30 years of experiencing a very large number of IDE's I have not seen even a single one where using its project management functions would not waste a lot of time comparing to non-integrated alternatives.
I think that it is sad that only a very small number of developers know how to use correctly the ancient program "make". I do not know why this happened. To use correctly "make" I have never needed anything else besides reading the GNU make manual provided with gmake, but it seems that very few people read the manual.
The only time when I had to write makefiles was more than 20 years ago, when I have written a set of universal makefiles, which I have been using unchanged for every software project ever since. For any new project I need to just (optionally) add a file with some extra definitions, e.g. a list of directories where the source files are located or the names of the executables or libraries that must be built. If no definitions are provided, suitable defaults are used, e.g. the directory with the Makefile also contains the source files and the target is an executable with the same name as the directory. The Makefile per target directory may contain just a single line, with an include directive for the universal makefile. The universal makefile searches all the source directories for all the possible types of source files, selects automatically the appropriate compilers based on the language indicated by the file name extensions and on the cross-compilation target if one is specified, generates automatically all the dependencies and so on.
Instead of using "make" like this, almost all the open-source projects that I have seen have huge and immensely complicated makefiles that are much more difficult to read, understand and modify than the source files of the programs. When the makefiles are generated from templates, those are typically even more difficult to understand and modify.
I have no idea who loves those extremely complex methods of compiling and building software projects.
During the years, a lot of replacements for "make" have been introduced, which are better than "make" used wrongly, but I have not seen any which is better than "make" used rightly, without pointless complications.
For easy maintenance, the universal makefile is split into 4 files that are completely universal + 1 makefile with extra definitions per each combination of operating system and CPU type that might be a target for compilation.
The extra files for specific compilation targets, e.g. skylake-linux-gnu, armv7e-m4-none-eabi, i686-cygwin and so on, contain definitions for the names of all the tools that might be used, e.g. compilers for various programming languages, linking commands, librarian commands, binary file modification commands (e.g. objcopy), default locations for library files, default locations for include files, default values for compilation flags.
The 4 completely universal files do not contain directly any command name or command flags or any file name or any directory name. They contain only variable names whose values are either defined in the operating system/CPU specific makefile or whose values are determined by the make command by scanning the project and by transforming the found files, e.g. by replacing the file name extensions.
The 4 completely universal files are:
1. A file for the top directory of a complex project, which descends recursively in all subdirectories and runs there the given make command, if a Makefile exists in the subdirectory
2. A file with make targets. Examples of make targets:
clean:
$(RM) $(RMFLAGS) $(MAP) $(BIN) $(IMPLIB) $(EXE) $(LIB) $(WEXE) $(DLIB)
$(RM) $(RMFLAGS) $(OBJS) $(OBJS:.o=.d) $(OBJS:.o=.lst)
and
all : $(EXE) $(LIB) $(WEXE) $(DLIB)
The 4 variables above are the files to be built, respectively CLI executables, static libraries, GUI executables and dynamic libraries.
As I have said everything must be expressed using variables that will be defined elsewhere.
3. A file with make rules, for how to build any kind of file that might be encountered. Examples of rules:
%.o: %.c
$(CC) $(CFLAGS) $(DEFINES) $(INCLUDES) -o $@ -c $<
%.s: %.cpp
$(CXX) $(CXXFLAGS) $(DEFINES) $(INCLUDES) -o $@ -S $<
%.d: %.cpp
$(CXX) $(CXXFLAGS) $(DEFINES) $(INCLUDES) -MD -o $(@:.d=.o) -c $<
4. A file with definitions, which is the most important in simplifying the makefiles needed for any new project, which are typically almost empty, because they do not need any other line besides including the universal makefile, even if I usually add a definition with a list of source directories, in order to separate the place where the project is built from the place where the source files are stored and possibly some options, e.g. building a debug version instead of a release version, or building for a cross-compilation target.
Example how to determine the directories with source files:
ifeq "$(strip $(SOURCE_DIRS))" ""
SOURCE_DIRS := .
endif
ifeq "$(strip $(PREFIX_DIR))" ""
VPATH := $(SOURCE_DIRS)
else
VPATH := $(addprefix $(PREFIX_DIR)/, $(SOURCE_DIRS))
endif
Example of how to scan the source directories for source files written in a certain programming language:
CPP_FILES := $(notdir $(wildcard $(addsuffix /*.cpp, $(VPATH))))
The list for every kind of source files is stored in a corresponding variable like above.
For the source files that are compiled to object files, the list of object files that must be made is computed so:
OBJS := $(CPP_FILES:.cpp=.o) $(C_FILES:.c=.o) $(SS_FILES:.S=.o) $(S_FILES:.s=.o) $(O_FILES)
I use many more kinds of source files, so the OBJS above is just a shortened example.
The operating system/CPU type specific makefile includes the 3 universal files with targets, rules and definitions and it also includes the automatically generated dependencies:
include $(OBJS:.o=.d)
so later only the specific makefile needs to be included, depending on the compilation target.
There are many more details, but these are the general principles. They are intended to make me write as little as possible in the Makefile for a new project...
Anything lesser, they're calling a simple code editor but, by actual definition, they are referring to a lighter IDE (as the ones that can be installed as base editors they have all extended with plugins/extensions to that point) and then acting like the topic is about the big-brand IDEs, even though it is making points against tooling they are all using with their "editors" just like what you're using VSCode for.
The tooling and layout of the same functionality you choose to use is something more modern tools, and product versions, have improved upon but is unrelated to what an IDE is. It also differs between tools and IDEs. For you to say you've never used an IDE with simple or fast file handling is either a lie or a severe lack of experience, as almost all decent ones have a 1 or 2-click approach via the explorer (and toolbar/hotkeys if you don't like an explorer side-pane). I actually can't think of any half-decent IDE that doesn't have the same approach for files as popular code editors, and I've used a lot of both for different platforms and languages. The only time I've had noticeable experiences is in cases via command/terminal but we're talking GUI editors here.
Worth noting, I have never in my career found myself mentioning any Eclipse-based IDE as an example of a good IDE. In fact, almost every dev I've ever met regards them as the worst IDEs they have experienced, not as a baseline standard for or expectation of IDEs. It's basically redundant to comment on x experience being bad as anyone that has ever used one already knows that is expected.
Your sentiment about the right tools for the job is spot on, and one should strive to choose tools that make you more productive but IDEs are one tool of many.
There's a host of other things to consider, like what is the testing environment like, library management, repository layout, etc. When you're working across a wide variety of languages, setups, environments, etc. choosing an IDE like Eclipse or Atom might not always be the right tool for the job. This also completely neglects the fact that vi/vim and Emacs, while mostly considered "text editors", can be enhanced to essentially be IDEs in their own right.
I think the article's arguments are weak, but so is this counter-argument, sorry.
Basically, don't think a single toolset is always going to be superior to your other toolsets. Feel free to mix and match, and change over from one toolset to the other when it's convenient or just more efficient. But of course moderation isn't going to get the clicks.
I think it's so blurry now as to be a pointless debate anyway - is VS Code an 'IDE'? Or is it an editor with a load of plug-ins available that give it equivalent functionality to an IDE? Because the latter definitely applies to vim and emacs and sublime too, and if it's the first, then... A lot of people don't use an IDE!
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.
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.
On a steep enough descent, a cyclist could get up to speeds beyond 50 mph, which really isn't safe given the equipment.
(They've also done some more motorized cycle and electric content lately. A recent video showed how to rebuild an old motorcycle's frame into an electric motorcycle using a kit.)
I see, your own peddling can make them go faster. Ok these things should be illegal!
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?
I live out in the country in Australia. I’m planning a velomobile with an auxiliary motor for both touring and local use, and with this combination I expect and hope to attain an average speed of over 50km/h for the ~39km trip to the nearest town for church and groceries on Sundays. (I currently tend to average 22–24km/h on my recumbent tricycle with no motor, the trip typically taking 1h35–1h50m, with an estimated average power output of 120W. 200W is quite a lot to add!)
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.
So, at large, I would guess the "as a crutch" use happens far more.
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!
An IDE on top of that always felt restricting to me. Like why limit yourself? But maybe that's a windows/Mac thing.
If Unixheads would stop pretending their stone-knives-and-bearskins development tools were equivalent to full-fledged IDEs, development would have advanced much more than it has decades ago.
It continues to amaze me that "it's worth becoming familiar with a wide range of tools and then pick the one that's going to work best for you in any given situation" is a concept so many people have trouble with.
The old unix editors have had rename across project, find references, go to definition/implementation for several years at this point via lsps (the same way vscode gets its functionality).
> What about integrated debugging
Those are usually (slightly ecosystem dependent) wrappers around a terminal debugger.
> What about hot reload?
Correct me if I'm wrong, but these are also wrappers around cli functionality (once again, might be ecosystem dependent). And you're probably just saving yourself the trouble of writing/running a script.
>Those are usually (slightly ecosystem dependent) wrappers around a terminal debugger.
And, in my experience, are vastly more convenient than terminal debuggers alone.
This view is exactly the view esposed by Brian W. Kernighan and Rob Pike in The Unix Programming Environment from 1984:
https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...
But that's not really a good thing: you only have one system, therefore only one environment.
For example:
How do you use multiple versions of the same library for different project? It's not an easy thing to do if you rely on the system paths for libraries.
It's much better if libraries are just a thing you install to the current project rather than being a system wide thing.