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.
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.
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?
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.
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.
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.
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.
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
People take pride in being less productive and making things harder than they need to be.
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?
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.
"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.
- Nobody
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.
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.
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.
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.
[1] https://www.milwaukeetool.com/Products/Power-Tools/Drilling/...
[2] https://web.archive.org/web/20180218045352/http://www.crypto...
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.
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!
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.
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.
https://old.reddit.com/r/Clojure/comments/4j3ani/with_all_of...
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.
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.
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.
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.
If I do not define in the Makefile from the project directory what shall be built with "make all", then either an executable is built, having the same name as the Makefile directory, or another kind of file is built, if the directory has a special suffix, e.g. a static library for a directory ending in "_lib".
When I add, delete, move or rename source files, I do not have to do anything for project management, except doing a "make clean" before that, because the next "make" will update the lists of source files.
- 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 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.
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 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.
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?
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.
I'm, of course, not talking about certain platforms that almost certainly expect or require the use of a specific IDE build tool.
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.
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.
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.”
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.
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.
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.
> you’re not being smart, cool or clever by choosing
c
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!
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.
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.