Benefits of Not Using an IDE
alexander-hansen.dev
alexander-hansen.dev
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.
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.
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.
Isn't this the case with Android Studio? Is it even possible to do Android development 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.)
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?
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.
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?
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.
"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.
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.
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.
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.
- 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?
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.
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.
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.
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.
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.
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.
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.
(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!
So, at large, I would guess the "as a crutch" use happens far more.
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!)
Meanwhile there are real 10x developers out there that while they care about the tools stay out of the weeds of them.
This line of blog post reminds me of a Paul McCartney interview I read where someone asked him what kind of strings he uses on his guitar. Paul replied “shiny ones”. I think Paul is actually a lot more technical than he lets on in interviews and probably knew full well what kind they were. What he communicated to the person asking the question was that it doesn’t matter so much.
Me: you realise always doing things the hard way does not improve your output, right?
Young jedi: nah, it's fine. GUI only slows me down, also Perl is the best
Me: alright then
And here I am, doing everything in typescript for my job, use VSCode and Webstorm, in love with GitKraken. What a shame. I'm not a cool kid anymore.
I rarely use IDEs for code generation, I don't even like autocomplete. For this stuff I use code snippets; I develop collections of those for any language I use. You don't need an IDE for it; any good text editor has such features.
For me really important features of a good IDE are:
- Navigation. Being able to right-click on a function or method name and jump to its definition is very handy. Yeah, I may remember where it's defined; I can also use grep (which does not work all that well for methods). But jumping is so much faster and does not take you out of the flow.
- Code refactoring. I am refactoring code continuously as I work with it. Even simple stuff like renaming a variable or a function (or a method!) is much easier with an IDE.
- Error highlighting.
Note: I can and sometimes do work without an IDE (esp with more obscure languages which don't have good IDE support). There is some fun it it too, like going camping and living for a while without creature comforts like running water and electricity. But normally, if a tool is available, why not use it?
About languages: I agree that a well-designed language allows you to factor away most boilerplate code. (This was one thing I really liked about Perl! It basically allows you to develop a language dialect for your particular needs. The downside with Perl was that everybody was "reducing boilerplate" in their own way, but this is another story)
Just my 2 cents :-)
For example, when I write React and I use the Foo component, either it is defined on the same file or it is in one of the imports.
On the other hand, with Angular, the foo component is not imported anywhere. In fact, there is no foo component, just one or many Foo components which declare to use the foo tag, and one or another may be loaded depending on the context of the current component. Good luck getting anything done with such an obfuscated environment without tools to deobfuscate it.
And then you have the heavy enterprise frameworks that make a science out of obfuscated code, so that you don't know what code is being executed, because it is hidden behind several layers of inheritance and interfaces, and the instance to create is choosen via xml-configurable meta-programming based dependency injector. Working with such code is guaranteed insanity without heavy IDEs. I would say it's also insanity with heavy IDEs, but people tend to find that opinion controversial.
There's always the option of not working with such obfuscated environments. I know I don't.
this so much. it's priceless to just type a line and have some warnings such as "hey, you're moving this value but using the variable afterwards, take care" or "hey, it looks like you are only using this argument as a reference, consider not passing it by value" just pop up next to the offending line ; when compared to an IDE-less workflow I pretty much divide the amount of hitting "build" I need by ten or more since the IDE tells me everything wrong beforehand.
Seriously, lsps have gotten really good.
Rename across the project is introduced by lsps.
As for renaming, I don't use it particularly often, but it's documented in microsoft's code action documentation[0] to include: Extract method, Extract function, Extract variable, Extract interface from class (some of those might be language/server dependent).
The neovim framework[1] at least does provide a wrapper for the code action.
VSCode gets most of its capabilities outside text editing from language servers. So the rule of thumb is that if VSCode has it, vim/neovim/emacs usually have it these days.
[0] https://microsoft.github.io/language-server-protocol/specifi...
It's not a solution to a problem, it's a problem searching for a solution.
I would add graphical debuggers to your list. You can get by with command line debuggers and there are external attachable debuggers but neither is really comparable to an IDE.
I left them out because I very rarely use them, unfortunately. It's my personal vice, of sort. I tried to learn to use and love them, more than once, but never learned to be more efficient with them than without, and when a deadline hits, usually drop them and never look back.
I grew up as a programmer without graphical debuggers, developed a rather sophisticated way to debug with essentially "print" statements, but on steroids -- I have a library of debugging utilities which I kind of recreate for any language I am working with. I've a habit to anticipate where they may be needed, and my code is usually peppered with commented out debugging statements (of course all of them generated via code snippets), which help me to be very efficient in debugging my code.
I must say that some of my collaborators over the years hated it, others loved it, adapted my system and used it in their own code.
I think it would be good to un-learn this habit and learn to use debuggers efficiently, and to produce a bit more conventional code. On the other hand, life is short, and there are only so many fights you can hope to win...
Perl for example is extremely difficult for an editor to get right, especially if you use OO framework other than Moose.
On the other hand, as others pointed out, where is the line between an IDE and a sufficiently customized editor using language server?
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.
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...
Your command line with vim/emacs and other tools that together arrive at the same feature set as a Integrated Development Environment are still... a development environment.
Not using an IDE doesn't mean you can't have autocomplete, syntax checking, linting, automated rebuilds, and all that other good stuff. It's just not all in one package.
And yes you shouldn't force your choice of (integrated) development environment on others. Different people have different needs: News at 11.
* terminal open at root of project used for source control
* one or more tabs for ssh/VMs etc
* IDE/VSCode/vim for editing
Any of those is fine. And sometimes I switch between them depending on my mood. If I’m out and about it can be nice to conserve battery and focus by going full terminal mode. If I have AC power and a full screen then I don’t mind an IDE as much.
One thing I insist on is doing as much work with git from the CLI. IDEs often do things like staging new files automatically that I’m not a fan of.
To the point on this one, I sometimes find myself running neovim inside the IntelliJ or VSCode terminal, when I need to edit a config file quickly while running scripts in that terminal, or just to edit a file outside the project directory. Or like you, I primarily use the git CLI, because IDEs often use to me unintuitive mappings of GUI buttons to git actions ("what does Synchronize do for git?"), so then it pops open $EDITOR to write my commit message.
When I need to create a lot of "new" code, I'll usually use nvim. When I need to edit/refactor existing code, I'll more often use atom or vscode.
I like both a lot. When bashing out code that is already reasonably clear in my head, vim works faster and with less "overhead". An ide like vscode works better for me when I need a good global search & replace, or something the ide has plugins for.
As an aside, I feel the same about the unbridled growth of tooling around certain languages (Javascript being a prime example) and environments (Android comes to mind). Maybe it is just because of the way I started out with 8-bit assembly where a macro assembler was a luxury which could not entirely be trusted to do the right thing but I know I'm not the only one.
It's usually useful, at least in some abstract way to the team. It felt essential when I worked alone and was accountable for everything.
No. You're wrong. Not having the right tools raises the cognitive load. You just think it's simpler because you are severely restricted in the complexity of the programs you can create with just your brain and the documentation.
IDEs expand the complexity of what you can build and make you more productive building programs of any size, because features like autocomplete and refactoring take thr cognitive burden off you.
In other words, you state that your way is the right way while my way is wrong.
Notice I did not state that my way is the right way for everyone? What makes you think yours is?
As long as you're working on a fairly standard type of project much of the taxing minutiae of programming is automated away by a good IDE that, unless you're working on a very small project, the time and effort saved is worth it.
In other words, that IDE which may assist you while you're building yet another CRUD project gets in the way when you're, say, developing a driver for a sensor on an IP camera based on a reverse-engineered example.
Sometimes, all the things the IDE lets you not think about is hugely more helpful than the additional cognitive load of modeling what the IDE itself is doing in your head.
Sometimes, having the thinnest possible layer between you and what you're running is hugely more helpful than the additional cognitive load of handling the things the IDE would've turn for you in wetware.
As ever, it's trade-offs all the way down.
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.
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...
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 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.
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.
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.
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.
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.
1. interactive debugger
2. quick jump to function/constant implementation
3. show usages of function/constant under cursor
4. source control (Git) diffs
5. database browser
There are probably other things I'm forgetting to mention.
Sure, all of these can either be cobbled together to some degree out of the fundamental individual tools. You can add plugins to Vim or Emacs to help with many of these. With enough effort you can get close to what a polished IDE offers... but you're effectively making your own quirky, fragile, non-portable inferior IDE.
Yeah, a heavy IDE is slow to start and resource hungry. But hardware is cheap, and you only start the IDE once every few days (or weeks).
When I'm on a remote server, then I'm in a shell using vim. Fine, and doable. But to really build and get things done, saving my brain for actual problem solving, I wouldn't want to give up my IDE.
Also, some of the cons on OP's list are problems with the language being developed in, not the IDE.
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.
Depending on the language and build system, this might be something I set up manually (set up an IDE project to mirror the build system), something you can set up automatically (export build system to IDE project), or there might be a standard layout for source code that mostly works.
I don’t really use other ide features. Separate terminals are great
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.
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.
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.
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 ;)
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".
Of course, tooling is better for some languages than for others. But even the ones you think are not that well supported actually do have some nice IDEs these days. Worth checking out such tools. Of course you can compensate with discipline and use command line build tools to tell you what's wrong and then manually look up the code location and fix all the issues .... or you could just autofix the warning in your IDE and move on to dealing with more interesting problems.
As a good friend used to tell me, laziness is a sign of intelligence. In IDE terms, if you spend half an hour manually fixing something that a tool could have fixed for you in seconds, you are being an idiot. Or alternatively, if you can't be bothered to understand and use the command line tools available to you, do consider using an IDE as it will save you some time mastering those tools you clearly can't be bothered with mastering. It's the intelligent choice.
I came to realize that the more the IDE did for me the worse I became as a programmer!
Today I’m back to plain text editing with a powerful text manipulation tool - (Neo)Vim.
And I program like back in the 90s — I have all file names, methods, the complete code structure of _all_ products and services of our company on my mind. I can see the final solution in my mind before I start typing a single letter. Refactoring is done with regex, it works the same in all programming languages. I work full stack. And I’m really fast. And I’m not tired by having all code and APIs in my mind. Because programming is pure joy again for me. Pure text editing is what makes me fast and having tons of fun. I ship so fast and things very rarely break. Bugs are fixed within minutes because I see the root causes flashing up in my mind.
To me IDEs are for intermediate programmers. It’s a good thing to temporarily improve your skills but I don’t see them as a means to achieve mastery, at least not for the mastery that I could achieve.
So I reject the argument made in the article. Just choose your IDE wisely and make the tradeoffs you want to be productive.
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.
If everyone is using IntelliJ and you're using Atom, it's going to be problematic. Not because of either of those tools, but because you now have a discrepancy that is not relevant to the work you're doing yet it's creating problems for the work you're doing. Adding friction like that doesn't help anyone.
"Works on my machine" doesn't just apply to the artifacts you build, it also applies to the way you work on your project.
Of course there is some difference between multiple people editing random plain text in a random editor and multiple people building a piece of software with a toolchain, deployment strategy, tests etc. If everyone in your team can scaffold the tests in 1 second because that's what the IDE does, and you're the only one that has to burn half a day on manually stubbing out the same scaffolding, you're the problem.
You don't have CI/CD? You sure as hell aren't going to run an IDE in CircleCI or Jenkins to do your builds.
You mention scaffolding tests, things like this can be left to external tools and then it works for all IDEs and all editors.
Then you can let people use what they find most ergonomic.
Like I get it, some people know their language inside and out and can fix it in a second because they know all the pitfalls and inner workings of the tool chain. But 99.5% of them don't, yet when they fix it they act like code ninja messiahs because they configured some random json config file after googling it and it worked. That's all I see Vscode users doing.
Either way whatever tool you use, nothing can be worse than pairing with someone who copies and pastes with a mouse.
I can just feel my life ebbing away as my inner voice screams “LEARN THE SHORTCUTS” and they slowly move 3 characters across the screen, make a mistake and try again. :P
The point was: if you make it difficult to work together because you have a high horse / hill to die on / unique incompatibility, it makes teamwork unreasonably hard and inefficient, which becomes a problem as soon as time and/or money is involved. The "haha I am so much better because I don't use an IDE" line of thought falls within that category. So does "I run TempleOS so that my code is blessed" and "I don't like git so I use TFS and you can all suck it".
Now, say you have something much easier to not care about tools; i.e. a gitops driven workflow for your terraform code. Then it doesn't really matter what you have locally because until your code is merged it is in no way/shape/form going to create a problem. On the other hand, if you refused to use efficient tooling your performance might be half of what other people might present and that means the people that pay you don't get a good value from your work. Efficient tooling might mean: something that understands the syntax or AST of what you write and points out errors so you don't find out after the fact.
- Running tests (test running requires juggling a hierarchy of tests, their results, their declarations, plus with an IDE you can run tests directly from the test declaration)
- Lint / Static analysis (you get the warnings automatically as you code)
- Debugging (it's easier to watch several things at once, easier to inspect a complex object, you can inspect through a tooltip when hovering over a variable on the code)
I really don't care about how anyone prefers to work, but I fear that anti-IDE people in many cases don't even debug (except by printing), lint or test... which I DO care about, if I have to work with them. These things are about being a responsible coder.
I could also add that the "Local history" feature of Jetbrains IDEs can save code from accidental deletion, which is another thing that goes beyond personal preferences.
Same with the test... it's easier to react to the test result, check what's failing, re-run the test directly from the IDE.
This would be in addition to the CI/CD... to aid the coder, not just to secure the integrity of the codebase.
For example you mention the “local history” feature of Jetbrains IDEs as being essential.
Vim, and I think Emacs, have had that built in for more than 20 years in the form of backed up undo trees.
There are still somethings IDEs can do that editors can’t e.g. deep static analysis, but with LSP support that set is reducing all the time.
I know that some editors have a lot of advanced features / plugins for coding. I still think a lot of people prefer editors over IDEs because they don't debug, or lint, or test... not because they're terminal wizards that are slowed down by any sort of GUI.
(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)
(it is 'than', not 'then')
However, if I'm thrown in half-finished projects as consultant, the tooling in IDEs can help me to get a grasp on what needs to get done without necessarily having to construct the whole map inside my head. Whether this approach leads to better code is highly dubious, but one doesn't always get to pick outside factors.
These are just tools, each with their own purpose, benefits and weak points. The main criticisms of IDEs seem based on a certain type of developer that does not know the world outside of their favourite IDE and programming language, which of course is not a problem of the tool itself.
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.
Are you more independent for it? Sure, I guess. But I'd rather be efficient then get brownie points
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.
For me it's mostly about:
1. proximity to the terminal: I find cli tools very useful for most of my daily tasks. Using an editor puts the terminal first, and my editor second. One-off tasks are a tmux split/tab/session away and everything is neatly organized.
2. consistent interface: Working with a terminal is neat because everything is text and it is composable. Working in vim, all menus are just buffers - you can navigate them the same way as you would your code. Searching, navigation, jumping between windows/menus, filtering -- everything stays consistent.
3. quick n' dirty workflows: If I identify a task-specific workflow I want to improve in vim, it is pretty easy to drop in functions and/or keybindings to do what I want. The interface was built in a way that makes this easy. Writing a plugin for visualstudio, or jetbrains etc. requires knowing a lot more about the editor you're working in and how it's built. Maybe it just feels that way to me.
4. 0% adjustment when working over SSH: tabs, splits, etc. both in my editor and terminal are identical in an SSH session. No discomfort. Mostly useful at home.
5. low distraction: This one's personal. IDEs are intimidating, hundreds of buttons, menus, logs prompts all fighting for your attention. If I click through a deeply nested menu I often forget what I'm doing - especially if there is a fire. Functions and Muscle memory works for me. It clearly does not work for everyone.
> 0% adjustment when working over SSH: tabs, splits, etc. both in my editor and terminal are identical in an SSH session. No discomfort. Mostly useful at home.
Aren't these two benefits mutually exclusive? If you're got a very personalised vim setup, then vim on your workstation is going to be potentially dramatically different to vim when sshed into a remote machine
Now that vscode has a plugin that uses your local setup to edit files over SSH, my argument is a lot less compelling. Even at home, I have a lesser vimrc I provision to servers - I found it hard to justify installing treesitter, linters, etc. on a server where I'm mostly dealing with json/yaml/shellscript.
The points made and most of these comments are a joke. Basically bad practice and poor use of source control is being blamed on IDEs. Anyone with these problems (in modern times, old projects/approaches are products of their time) simply isn't a competent dev and/or never studied. I don't even recall any of these things being an issue in the first months of learning to code, 10 years ago.
To be a good programmer, don't learn from bad sources and don't be overly lazy to the point you develop bad habits. You can do all of that while still using an IDE. How you use the tools available is on you, not on the tools.
If a tool is so bad it enforces bad practice and has no way to avoid complicating workflow, find a better alternative. A tool is meant to streamline and improve workflow, not hinder it. I've never chosen to use an IDE that has enforced any of the issues being commented on, as if the only alternative is avoiding IDEs outright. I choose to use IDEs that are best-suited for the language I am using, are flexible and allow me to work how I like without convoluting my workflow. I also never commit IDE or user-specific files to a repository as that's just awful practice.
I'm also yet to read a complaint in comments here that claims to be a specific IDE forcing or creating problems that isn't actually about a company/team that has created a terrible dev ecosystem (or backing off an archaic one) for a project that they restricted and boxed into an IDE. Just because poor project management can make a project a nightmare to work with doesn't make the tools involved the problem.
> because there is just so much, that it becomes impractical to remember
I got more comfortable and faster with large projects when I stopped caring about remembering and switched to search & find. I'm always amused seeing someone trying to navigate a directory tree of 2000 files.
I don't think the tooling matters at all, unless you work in a very specific field where certain tools may be mandatory.
Whether you look up APIs in documentation or read that same documentation in your editor, who cares? Seeing red squiggles as you type or in a terminal window that refreshes on change? Who cares. It wouldn't even make a difference if you only saw errors when manually starting compilation.
None of it really matters in the end.
https://www.amazon.com/gp/product/B00J9PQXOE/ref=dbs_a_def_a...
I would say that an editor that INTEGRATES knowledge of your source in some way, like auto-complete, or red-squiggles, is very much a big step towards an IDE and should could as "using an IDE". Whether it does that using plug-ins/extensions or natively doesn't matter. If it has that functionality there's not that much more separating it from an IDE.
VSCode, for example, is more like an IDE than an editor especially as you add more and more extensions.
But it's a general and trivial comparison. Like using MS word vs markdown, or Ubuntu vs Arch or Alpine.
It all comes down to your use case and it's not black and white. My Swiss knife is VS Code, arguably an IDE-minus, or an editor-plus. And given that I work all day on software it happens that I occasionally go down (vim) or up (XCode, Visual Studio, Android Studio) and I have no problem with that.
However, I credit my understanding to the time I spent in Notepad++ and times I explored code on the whiteboard while reading docs. Thus, I feel my "internal compiler" would not be anywhere as useful if I had always relied on productivity tools (IDEs).
That said, my input isn't maximized by more efficiently producing the same thing, like a factory, in which case I say IDE all the way.
My eye twitched when I read this. My company recently switched to a new build system and for whatever reason this required (I guess??) a change to the src/main/java... structure. The commit history going back over a decade, gone. It's not great.
On 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've yo-yo'd between minimalist setups and full blown IDEs over the years.
Nowadays I'm happy with IntelliJ for Go development and a little bit of Rust. There's something quite freeing from not having to tinker much with configs and just get on with actual work!
Admittedly I do use the terminal feature in IntelliJ quite extensively so I'm not making full use of the features, but meh.
Only benefit I see is remote development over terminal.
https://blog.jetbrains.com/idea/2021/01/run-targets-run-and-...
when I could write a makefile to finally jar / launch a java app on my own, I felt such a relief..
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
Just thinking setters and getters set and get the property is naive and retrograde.
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.
I mean, I don't use an IDE, but at the same time, reading the comments, I don't miss much of what it offers.
What's with the wild capitalization?
thanks for your genuine post. I can't help but notice the big red disclaimer you put on the beginning.
Once I wrote a blog post about a thing I didn't like about Typescript and submitted it to Hacker News [1]. Bad choice. The hate was immense and unnecessary. I even had one guy write a long post about what a "soy dev" I am. That made me feel sad and dislike the HN and dev community.
Anyways, I just wanted to say that I appreciate your blog post and that I think you've made some good points. Thanks!
> Respect the Unix Philosophy
I have no respect for the unix philosophy.
They go on to clarify:
> (Visual Studio's poor man's autocomplete is a prime example)
And so from this I deduce that the author considers autocomplete to NOT be part of the "one thing" that an editor, under the Unix Philosophy, is supposed to do. But both emacs and vim have autocomplete capability, so either autocomplete in an editor is only philosophically acceptable if it's good enough, or emacs and vim are not worthy of the Philosophy.
I'm happy taking advantage of the strengths of many editors for many different situations
However, why any developer would reach for one of these tools now when working on application development is beyond me (other than to feel like a 1337 OG hax0r of course)
Power tools > hand tools
I get 90% of the features with LSP. Faster performance. Magit. Extreme configurability. It's easier to write a quick function in elisp and have it at my fingertips at anytime. (ie. M-x my/do-repetitive-thing)
This is a good thing, no?
what more do you need? typing the code is never the bottleneck lol
And art of creating clickbaity titles.
We can expect that considering tools has to be complicated, e.g., apparently the rise of civilization involved the development of many tools for many purposes.
Closer to Hacker News, there is a LOT of data. The explosion in price/performance of computing and digital communications has the amount and variety of data growing. So, handling data can be a challenge, and picking tools can also be a challenge.
For handling data, there are some tools/data types, e.g., SQL, IDEs, Word, TeX, Aspell spelling checker, the old file search utility grep, HTML, JPG, comma separated values (CSV), spreadsheets, ....
Of course, if concentrate on one source of data for a few narrow purposes, then can have some specialized tools that were expensive to develop and needed training to learn to use but with a lot of usage can be very productive. Maybe a good analogy is the factory that produces the cans of beef ravioli that I eat sometimes for a fast meal -- no doubt they prepare ravioli by the square mile, and I doubt that they use a rolling pin!
Then there are people; they tend to be different: Some of these people work in a gold/copper mine, coal mine, on a huge fishing trawler that goes from catching the fish to having them frozen in retail packages, ..., down to changing the air filter in the family car once a year, getting the garage door back on track about each two years, cleaning up after the kittens have accidents, .... Some of this work uses big, expensive, specialized tools, and some uses just simple, old, general purpose tools, hammers, pliers, screwdrivers, maybe Vise Grips, a 1/4" electric drill, etc.
So, to give some evidence of case n = 1, me, and in computing, I use various tools. Examples include Google, Wikipedia, YouTube.
But for what I do on my PC where Google, etc., doesn't help, I settled on a broad strategy: As much as I reasonably and efficiently can, stay with text, standard ASCII (maybe more accurately with some UTF definition) text. Then to manipulate this text, use my favorite text editor, KEDIT.
I can customize this editor using its macro language, Kexx, a version of the M. Cowlishaw Rexx. Rexx is no toy -- before internets or the Internet, IBM had something similar in their internal computing, and a lot of it was run by servers written in Rexx. Currently I have something over 250 Kexx macros for KEDIT.
So, where I make use of KEDIT directly?
(a) Since some of my most important writing is pure/applied math, I've had to get good with D. Knuth's math word processing TeX -- I've written about 100 macros in TeX. So, I use KEDIT with its macros to type in documents in TeX with my TeX macros. Now that I'm good with TeX, it is also my favorite word processing for letters, business cards, and more.
(b) For remembering URLs, phone numbers, mailing addresses, other little items of information, I have a very simple little system based on KEDIT and a few, simple macros. All the data is in one file of, currently, 3,368,455 bytes. Currently I have 5947 such entries starting in September, 2005 and more in other files going back some decades. With the 5947 entries and 3,368,455 bytes, that is an average of
3,368,455 / 5947 = 566
bytes per entry.
Since
5947 / 16 = 371
on average I add an item to this file about once a day.
KEDIT makes it fast and easy to count the number of entries.
(c) In a file I maintain with KEDIT, I keep medical, diet, exercise, etc. history. I have some macros I use to extract data to read in with Excel and draw graphs.
That Excel will read in data from just simple text files is terrific.
(d) Mostly KEDIT is good for editing files one or a few at a time, but I use the Windows file system as a taxonomic hierarchy for organizing the files. Then I have a little program in Rexx that puts the data describing a file system subtree in a text file with several columns of fixed widths and use KEDIT to sort, search, select that content.
(e) One of my favorite macros is IDC, insert dated comment, e.g.,
Modified at 13:24:42 on Saturday,
August 21st, 2021.
Just these time/date stamps are a good, fast, single way to provide first-cut documentation of work -- that months or years later are great to have if don't have anything else.
(f) I wrote a little KEDIT macro calc, abbreviates calculate to evaluate simple numerical expressions. E.g., at one point in my career my manager believed that a disk drive of 100 million bytes was large, much larger than necessary. At Amazon I just ordered an external hard disk drive with 5 trillion bytes. So, using calc, we can find the ratio
(5 * 10*12)/(100 * 10*6) = 50,000
(g) So I write code in Rexx, Kexx, TeX, C (occasionally), and Microsoft's .NET. And now that I'm good with KEDIT, I use it to write all this code. In .NET, with a little C, for my startup I typed in code in 100,000 lines of typing with 24,000 programming language statements. So, about 75% of the lines are documentation for me to understand the code! Some random exogenous events pulled me away from that code, but I will be back to it soon, and then the comments will be very welcome, get me back to 100% in understanding all the code.
Most of the comments have tree names on my development computer of, usually, HTML files of .NET or other documentation, and, sure, I have a macro that helps with that. E.g., with one keystroke, Firefox will display a file of HTML documentation.
The comments are essentially just text, technical writing, and KEDIT with its formatting is good for that. Also my standard spell checker, Aspell, works with that text. That is, the code is, to KEDIT and Aspell, just text.
(h) Sure, I use KEDIT to write email and often to read email. I went for some years using some code I wrote in Rexx for email -- then email got more complicated and I had to use Outlook or now what my ISP provides (I intend to return to Outlook). But when I write email, I still use KEDIT. When I receive email that is just simple text, I use KEDIT to format (flow it) and read it.
(i) Sometimes I still want to print some things, e.g., shopping lists, envelopes, etc., and use KEDIT for that.
I'm numbering, labeling, my external hard disk drives with PASSPORTnnn sequentially with integers nnn, and I print these with KEDIT.
(j) Sure, eating is necessary, and I cook my own food. For that, I develop recipes and use KEDIT to create those. To take a recipe to the kitchen, I can print via KEDIT.
(k) Sometimes URLs have hex characters. So, I have a little KEDIT macro to convert those URLs back to just text.
(l) And, sure, I'm using KEDIT for typing this Hacker News post.
So, as in these examples, (a) -- (l), as much as I can I use just simple text files maintained with KEDIT. Then I get good with KEDIT, macros, muscle memory, etc. and use that skill as much as I can.
I can't use KEDIT for everything, so sometimes I use other tools.
Once I tried to use Microsoft's Visual Studio. I didn't like the documentation but charged ahead. I created a project, and before I had typed in any code I looked and saw a directory subtree with maybe, IIRC, 50 files I knew nothing about. I stopped right there. Maybe someday I will see need to use an IDE, maybe Visual Studio, and will return to it.
All the programming I do is in languages where the code is in just simple text files. To me that use of simple text is terrific, and I take advantage of it.
So, net, I use KEDIT and simple text files for dozens of varieties of work; in principle each variety, done with enough volume, could be done with more productivity with a specialized tool, but for just my work, where I use KEDIT and text files, none of the varieties are worth the investment, overhead, of a specialized tool.
By analogy, to me KEDIT is like a Swiss Army knife with 15 tools including a can opener. If I opened enough cans, I might want some restaurant kitchen $500 counter top electric can opener, but for me, now, the Swiss Army Knife is better.
whether they had an opportunity to use Visual Studio's features like
expression evaluation during debugging with access to local variables,
ability to change code at fly,
ability to execute code in immediate window with access to local variables
Doing software development means using a variety of different standard APIs which many combinations of methods/parameters/etc as well as any number of custom, project-specific APIs. Sure, if you work on the same project using the same codebase for years on end then you can probably effectively memorize all the relevant APIs, but few developers are in that situation. You move from project to project and have to drop in to large, existing codebases with their own conventions and abstractions.
This is very common in embedded systems.
I ditched one such IDE in a project a couple of years ago and switched to Emacs + git + make + command line compilers. The productivity improvement was huge. Finally, decent tools.
Even debugging worked better via command line GDB. It was more reliable than the one in the IDE, and scriptable.
The quality of what went into the repo went up as well.
I highly doubt that.