Arguments against IDEs

22 点作者 arexxbifs超过 1 年前

23 条评论

I've used IDEs and just plain ol vim. And I tells you, having an ide allowed me to debug problems my team thought undebuggable.The reality is that rubymine costs 100/year for personal use, and I pay them with a smile because to me it is worth 10x that price. The reality is that ides can help you hide from bad package management. But package management is but such a tiny portion of code organization. And all editors let you find files by name or jump to definition. Some do it far better than others.Watch someone use the latest jetbrains platform to see type annotation injection into typescript code. I've seen developers abandon vscode and others once they saw how smooth ides can be out of the box with the coolest features.In any case. Just my take.

rewmie超过 1 年前

This blog post isn't insightful and doesn't even manage to present a consistent case against IDEs, and boils down to a sequence of weak strawmen. Describing a IDE's job as making it easier to type is pure nonsense and fails to even acknowledge what a IDE is and what it adds beyond text editors. In the very least, IDEs make it easy to navigate projects and run searches for things like source files or symbols, with the latter supporting types of searches not available in pure text searches such as finding where a function of a particular subclass is called.This sort of article fall into a fallacy trap which is failing to understand what "integrated" in "IDE" means, and proceeds to fail to address what exactly is integrated.

评论 #37279110 未加载

euos超过 1 年前

What is an IDE? As someone who worked on IDEs approx between 2003 and 2014 (I did not like the market afterwards, commercial IDEs I basically impossible now unless you are legacy, like JetBrains).What is an IDE? Personally, I consider IDE an integrated suite of source editor, visual debugger, build system. E.g. I put a breakpoint, push a button, it builds, runs and hits a breakpoint. Other tools (SCM integration, profiler integration, design tools) are an add-on.So, is Bash an IDE? I think pretty much every modern editor allows setting up macros so it is possible to trigger build/run GDB from within the editor. Does author have an issue with Vim, Emacs and Sublime? What is the difference between Sublime and VSCode?I started working after the collapse of RAD (rapid application development, think Delphi/VB) and model-driven tools (where you do UML and generate code from model). I am very strongly against those tools, don't think they can be done well. But those are category separate from IDE :) E.g. Rational Rose - could generate code from UML and parse the code to UML, but no code writing inside.Another thing I take huge offence is people dumping on Eclipse. It was a revolutionary product that disrupted the space. It was blazingly fast compared to Java IDEs of the time (JBuilder, Visual Cafe and such) and had refactoring support comparable to IntelliJ (that was a paid product). It got destuffed at a critical junction (complete rearchitecture from Eclipse3 to E4) and saw crappy plugins (and Java really lost popularity since). But it was an amazing product 24 years ago.

评论 #37281042 未加载

评论 #37289076 未加载

评论 #37298481 未加载

lusus_naturae超过 1 年前

This seems to me like an argument against power screw drivers, just because someone has one doesn't make them a carpenter or make carpentry easy for them. But would a skilled carpenter be better of saving their cognitive resources by offloading things to automation or tools, yes a hundred times.

评论 #37288855 未加载

redhale超过 1 年前

No offense to the article author, but this is written like someone who has either never used a good IDE, or never learned how to really effectively leverage a good IDE (mastering all features, memorizing keyboard shortcuts, adjusting configuration to match your style, etc).Yes, obviously the most time consuming part of developing software is thinking. But with an IDE, I can sometimes do some of that thinking out loud in code and rapidly prototype as I go with refactoring helpers, etc. This is not always the best approach, but it's a technique that has its place and is simply impractical without an IDE.A strong senior engineer in a text editor can likely beat a junior engineer with the best IDE. But a strong senior engineer with the best IDE (and experience with that IDE, this is important!) will absolutely run circles around an equally strong senior engineer with a text editor.For reference, my daily driver IDE is Rider.

评论 #37279659 未加载

评论 #37288838 未加载

评论 #37288813 未加载

hakunin超过 1 年前

What's missing here is the programming language.There are incredibly flexible, concise, low-ceremony languages, with implicit types where placing an IDE between you and code kinda obfuscates them. These are the languages where I think the best representation of code is the code itself.Then there are elaborate, verbose, high-ceremony languages with explicit types, where looking at code and keeping up with ceremony might be a bit overwhelming. For those languages you probably want a lot more automation and a variety of info representation that goes way beyond code.I'd go out on a limb to say that everyone here who likes/dislikes IDEs will split almost perfectly among those two language categories.

评论 #37293340 未加载

userbinator超过 1 年前

IDEs Can Hide ProblemsNot only problems but understanding; as someone who once taught beginning programmers, and assisted someone else before that wherein the students were given step-by-step instructions with an IDE and as a result many had little idea what to do if something didn't work, I started with the "text editor and command line" approach and those little problems mostly disappeared. Another side-effect I noticed is students being more confident in their work, which is likely because they felt like they understood what was happening at a deeper level of detail.

syndicatedjelly超过 1 年前

While reading this article, I could not understand what the alternative was. Did he mean it's better to use Notepad++? Vim? Both of those have extensions that turns them into decent Integrated Development Environments. So just plain text files, no extensions? That just sounds annoying.Finally understood what he was talking about in the last few paragraphs, when he mentioned only knowing how to run tests and pipelines through an IDE. He was talking about a GUI! I agree, clicking a button on a GUI that's magically hooked up to GitHub and runs whatever it needs to for testing is "complexity that pretends it's invisible", which was a great phrase. It's always a good idea to learn how to run everything from the terminal, because it's hard to hide complexity behind terminal commands. Not that it's impossible, but it's more of a philosophy from Unix for every command to only do one "action". So to build a project in Go, one runs `go build .`. And to run it, `go run .`. To test it, `go test ./...`. To debug, a set of flags must be passed to build. To build for a different target, a different tag. It's very explicit. In an IDE, relying on whatever buttons are made available means that these commands may be combined, or simply made unavailable

minimaul超过 1 年前

The section on Lock In effects makes little sense to me - if you look at popular .NET IDEs for instance, they mostly produce .sln and .csproj files - which is the defacto .NET standard, and works with the standard command line tooling. They're portable between IDEs, and you still produce .cs files with raw source code that you can open in any text editor.It's similar with PHP via something like PHPStorm, Python via something like PyCharm - there's no real lock-in beyond personal habits in IDEs I've used.More generally, in this space... using a text editor (with or without plugins) and using an IDE are both valid approaches. I do not believe either are fundamentally better than the other. Try both approaches and choose for yourself - it's all about finding what suits you as an individual and makes you more productive. You may even find that your choice differs depending on what software stack or language you're working with - mine does."Hot takes" aiming to belittle or degrade people that choose the opposite to you are unhelpful at best and discourage people from trying both options for themselves. No one is a worse developer because they like working with a simple UI with minimal distractions and separate tools for separate tasks, and no one is a worse developer because they like more integrated tooling with code suggestions, refactoring tools, integrated debuggers, etc.

评论 #37289040 未加载

dkarl超过 1 年前

The author makes some good points about project organization and general attention to detail. I've used IDEs for over 20 years. Even when I used emacs for C++ and scripting languages, back in the day there weren't worthwhile IDEs for them on the platform I used, I looked forward to the day when there would be. I'm an IDE believer. However, I'm a stickler for organization, naming consistency, and general tidiness in codebases, because I think it affects onboarding speed and mental overhead for programmers, and I often rub up against programmers who don't notice shortcomings in these areas, because they rely on their IDE features to avoid spending any thought on code organization.They don't care if a method is badly named or misspelled because they barely read names before they ctrl-click them. They don't care that files are haphazardly organized because they navigate by searching. They pick up a ticket and slack somebody to ask where the fix should go. Once they're in the right place, it's click click click and they're on their way.The best programmers read class names and method names. They look at the directory structure to get a sense for how the codebase is organized. They try to understand the logic behind code they inherit, they try to write code with an evident logic that the next person can follow, through good organization and meaningful, consistent naming.I've had programmers tell me that they didn't know a word was misspelled because they figured it was a word they didn't know. I told them if they see a word in our codebase they don't know, they shouldn't gloss over it, they should look it up, because somebody thought about that word before they typed it. They roll their eyes. They think everyone is like them and craps out names without thinking about them. They don't realize this has anything to do with why they're still mid-level at their age and people don't trust them with anything important.In the end, I don't think the author is correct. I don't think that using a poor tool makes a programmer better, even if it forces them to do important things they wouldn't otherwise, like notice how things are named and organized. And I think the best programmers are better and faster with an IDE. But I certainly understand where he is coming from.

delta_p_delta_x超过 1 年前

The author seems like they have never used Visual Studio or Rider to its greatest extent.The Unix equivalent of a single Visual Studio install and all its functionality is- clang- CMake- gdb (which is pretty lousy compared to VS' debugger)- valgrind- perf- some record-replay tool (maybe perf?)- system package manager- language server protocol tool- clang-format- clang-tidyAnd a whole other host of refactoring tools that just aren't present or possible in the author's tool of choice, Vim.Sure, one could do complicated editing with indecipherable incantations in Vim, but I spend most of my time thinking, not typing—ironically the same argument that the author uses. I don't need a faster, more to-the-metal tool. I like the abstractions an IDE provides. Working with Git is immensely simpler in an IDE than it is in the command-line. Autocomplete, refactoring, and go-to-definition functionality is superb. All these help me think and write better code.

评论 #37288551 未加载

评论 #37281854 未加载

LASR超过 1 年前

The author seems to have a particular IDE/text editor and programming environment in mind. But they don’t ever reveal what those are and makes an argument much more general than that.Ie: This one IDE is worse than this one text editor for this one programming environment. So every IDE is worse than every text editor for everyone.I am sorry, but there is zero truth in a sweeping generalization like that.What is an IDE anyway these days? VSCode with plugins is more IDE than some IDEs. The lines are all blurry. Is syntax highlighting considered to be an IDE? Clearly it’s doing more than text editing. It’s understanding the language.Believe it or not, those days of pure text editors are long gone. Almost every modern iteration of a text editor does a lot of what would have been squarely in the realm of IDEs some years ago.These are all just tools. Some are better than others in specific situations. Without the specifics, this kind of argument is noise.

malkia超过 1 年前

It's impossible to have large team at a company working without a small set of IDEs. Just the sheer amount of explanation/teaching one has to do to any new to the team is going to overwhelm them. We can't expect people to be fine with just the command-line and some minimal editor. It doesn't work that way.

janosdebugs超过 1 年前

Let's also not use linters because... why exactly? Or let's go back to writing ASM because programmers no longer know how the CPU works. The whole point of abstraction is that we can do more, better, more efficiently.

评论 #37289295 未加载

评论 #37288832 未加载

vinaypai超过 1 年前

This is one of those opinion pieces that serves as a stronger argument for the opposite position. If this is the best the author can come with, it's a very weak position indeed.

vorpalhex超过 1 年前

I agree with the authors conclusion but the argument here is underwhelming.IDEs are sloppy and slow and they make engineers do dumb things."Why did you change all the whitespace in this file?""I dunno my IDE did it."And almost every time I've had to retrain someone on git, it's because they were using an IDE and never understood how git works. The same issue pops up with debugging in situations where you only have gdb or ptrace and not your ide.

deagle50超过 1 年前

I disabled all the UI elements in IntelliJ so it looks like Emacs, and I learned Vim motions. IdeaVim takes a .vimrc and I have almost everything I'd want from Emacs/Vim. Works great for me, I can pretend it's an old school editor until I need the IDE stuff which is rare. Plus it scrolls smoothly at 120 fps and I can tweak it, manage plugins, and install plugins without editing config files.

mgkimsal超过 1 年前

Working without an IDE, I have less confidence when making potentially impactful changes. Where else is 'foo' used? What are the code paths that lead to method 'x'? If I rename this, will my tests also reference the new name?

wilde超过 1 年前

I might believe the argument more if there wasn’t a typo in the first sentence.

评论 #37277990 未加载

评论 #37278059 未加载

flashgordon超过 1 年前

As a power vim user I still use a solid step by step by debugger and auto complete in which ever tool that provides. It just so happens to be vimbindings inside a jetbrains/vscode window!

camgunz超过 1 年前

I use vim instead of an IDE and I've tried lots of IDEs (Visual Studio/C++, Code::Blocks, JetBrains stuff, Eclipse, VS Code). For more table setting, I also use a lot of linters and formatters (via ale), but I don't use any autocomplete.I don't have any problems getting by with shell, sed, grep, and whatever debugger. I've debugged bonkers issues (gdb is super powerful), I've changed the names of things across huge codebases using sed, I've found all instances of things using grep, etc. I've written scripts to do these things and some of them I've reused (ex: I have a script that grep's the output of git status to see what I need to add to a commit to continue a rebase and then runs that git command).It did take time to learn, but I would argue it didn't take longer than really getting to know an IDE. And now, I have pretty good knowledge of standard tools that's broadly applicable to lots of other problem domains. This has been useful as I've had to dip in and out of data engineering in the last few years, but it's also nice to just be able to whip up utilities to solve random problems that always crop up (does Funko sell some kind of Doug McIlroy talisman?).As a result, I've always felt that IDEs were vaguely disempowering. I'm good at using *NIX on a variety of problems, and deploying these skills over the years I've gained a pretty deep understanding of how lots of things work (what makes grep fast, forking overhead, file descriptors, buffering on pipes and I/O in general, etc). I can't overstate the degree to which this has made me a better SWE. I'm not a PyCharm user or CLion user, I'm a computer user.I don't want to veer too far into "IDE users are sheep" or whatever; I definitely don't think that. But for me, digging into *NIX tools essentially taught me about computers and software engineering, and gave me a broadly-applicable skillset that I use to solve bonkers problems all the time, but where I wouldn't even know where to start in something like VS Code. A good example here is I was just rereading tptacek's post on hiring (from also rereading the "Misidentifying Talent" post by luu) [0] [1], and he talks about one of the interview work sample prompts involves reverse-engineering a custom binary protocol. I don't really know how I would do that in PyCharm (or whatever the Ruby equivalent is), but I would make pretty quick work out of it in Wireshark.I think these arguments just come down to aesthetics. Some people think that IDEs are fun to work with in their GUI magnificence and find a vim/emacs/etc. system extremely opaque and tedious. Others think that it's fun to wire your own system together to suit your own way of thinking and working, and feel suffocated and disempowered by an IDE. Use what you like, have fun, don't yuck my yum.[0]: <a href="https://sockpuppet.org/blog/2015/03/06/the-hiring-post/#worksample" rel="nofollow noreferrer">https://sockpuppet.org/blog/2015/03/06/the-hiring-post/#work...</a>[1]: <a href="https://danluu.com/talent/" rel="nofollow noreferrer">https://danluu.com/talent/</a>

评论 #37282701 未加载

评论 #37288872 未加载

评论 #37313759 未加载

retrocryptid超过 1 年前

Finally. Someone is talking sense. If Eclipse was the answer, it must have been a pretty stupid question.

评论 #37288895 未加载

akasakahakada超过 1 年前

My experience is that is it obvious from code that who did't used Pycharm. My colleagues use JupyterLab as best, mostly vim, and their code quality is underwhelming. Open their code in Pycharm, immediately see red highlights everywhere: They can't see any of those syntax and type errors in vim.Full search or replacement has never been easiler after I shifted my workflow to Pycharm. Of course same thing can be done in the terminal, by typing 800 time `cd A/somewhere; vi something`. Why make life harder when tools are accessible?