As a person who has to use visual studio every day, I find that it’s by far one of the worst IDEs I’ve ever used
Beyond being slow and confusing and unintuitive I think the most annoying part is whats mostly mentioned in this article. Either you do things the visual studio way or screw you. Even creating a blank file is annoying and it keeps trying to shunt you into various templates.
Having worked on in a wide variety of C++ development environments (Linux, Windows, & Mac with a variety of IDEs), VS is hard to beat. It’s parallel stacks feature is particularly helpful in debugging threading issues.
It would be fine but it is slow. Watch window refreshes and responds to expanding trees like it is traversing dozens of gigabytes on every single action. (if you enjoy watching rants there's one: https://youtu.be/GC-0tCy4P1U?t=1767)
I don’t see how anyone can have this opinion. If you are producing code for which VS was designed (.net for example) it is obviously and definitely one of the greatest IDEs ever produced. If you are having to fight with VS, then you may not be using it for one of its main use cases. I certainly don’t think it is perfect (git support being quite annoying at times) but to say that it isn’t an incredible achievement is ridiculous.
Try programming for Xamarin, UWP, or anything involving multitargeting.
The list of actions for which closing visual studio, deleting a bunch of random folders, and restarting is long. Unfortunately it includes any changes to project files, because the project system is super broken with anything multitargeting related. That basically means I have to completely restart my IDE and run a script to clean everything maybe 15 times a day. And fuck me if I’m trying to find where a regression happened (which means changing dependencies, which live in the csproj).
I remember when I didn’t have to restart VS 30 times a day, and memorize which build errors actually aren’t errors, and do random sequences of events to work around bugs, and memorize which unsuppressable warnings are legitimate and which are not. Before those days, Visual Studio was indeed an incredible accomplishment.
> Try programming for Xamarin, UWP, or anything involving multitargeting.
The complaints in the original article fell rather flat to me, but this is one area where it's absolutely fair to criticize VS. More generally, the reason that build tooling in the .net sphere is such a mess is because of historical baggage from VS.
With that said, if you're coloring within the lines[1], VS is very powerful and productive.
[1] To an extent. There definitely are use cases that are "supported" only in name.
I used VS for years across a couple of C/C++/C# projects, and it was second to none with one exception.
The exception was Xamarin/Xamarin.Forms. Seriously, congrats to the Xamarin people for getting that project going, but it was (at least into Xamarin.Forms 1-3) more than a little hacky and extremely frustrating. Granted, it kind of had to be though given that it was intended for a broader audience targeting completely different platforms, and at least initially didn't have a lot of MS support iirc.
I think the issues surrounding cross-platform targeting were/are less a problem with the IDE itself than what it was/is forced to work with. The whole iOS "code in VS on Windows, but build on a Mac" was a nightmare, I don't know if things have gotten any better.
They’ve actively gotten worse. I should have clarified that my “I remember when” comment applied to 5 years ago, not 15. Reverse progress on that timescale just isn’t acceptable IMO. MAUI is supposed to fix it, but I’m not sure they’ll have a developer community left to use it by then.
>I remember when I didn’t have to restart VS 30 times a day, and memorize which build errors actually aren’t errors, and do random sequences of events to work around bugs, and memorize which unsuppressable warnings are legitimate and which are not. Before those days, Visual Studio was indeed an incredible accomplishment.
This is because the software you're building today is far more complicated than before (from the IDE's perspective), and it doesn't do a good job of keeping up. There's a reason why so many people jump to VSCode these days - it gives you less bells and whistles, but it won't blow up on you when you try to do something moderately complex.
I'm one! I work with VS daily and I think it's pretty bad. Some examples; I cannot get a plain folder view. Intellisense is very inept compared to Jetbrains products. Bad refactor support, can't find things you're looking for etc. File tabs are hard to keep organized. The source control support has been worst of the worst up util recently (blame view taking minutes to show up etc), and now it's only mediocre. Best way to find stuff is through "find all", which is an order of magnitude slower than grep. "Track changes" resets on file close, not when you save or commit, making it rather useless. VS also crashes quite frequently if you aren't gentle with keypresses. Single-threaded plugin model causing keyboard input lag. Etc etc. I could go on.
The good parts of VS is hot-reload (when it works), the debugger, and the profiler. Otherwise I'm not a fan.
Yes, but what do YOU expect from an ideal IDE? That was the question.
If you're targeting .NET or C++ development for Windows, there's not a lot of competition to be able to claim that there's something substantially better. Rider, IMO, is on par, with better refactoring. However, VS debugger is still better.
Use the "Switch between solutions and available views" button and select "Folder view." Seems about right to me.
> Visual assist is very inept compared to Jetbrains products
Jetbrains does have better refactoring, but you don't really have to choose one or the other; Resharper and Resharper C++ give you the best of both worlds. Jetbrains is missing some stuff that Visual Studio can do, too. Visual Studio does some static analysis to detect out-of-bounds errors and other mistakes, which is useful to have as quick feedback in the IDE, in my opinion.
Sure, I'm aware and have ReSharper C++ plus the clang linting enabled.
VS isn't all too shabby, they've been shaping up recently. But it certainly isn't the best, or even among the better, in my opinion. Even the file editor is pretty weak compared to other editors IMO.
Yes, I have. And although Microsoft claim otherwise, I find intellisense sorely lacking in a lot of areas. Indexing is bad, search is bad, and their refactorings miss the mark a lot of the time. It's clear that Jetbrains lexical analysis is a lot better. I can search for implementers, find usages, rename and restructure without thinking twice, most of the time.
ReSharper has been really slow, yes, but it's also much better than intellisense and noticably better than Visual Assist. As of now, it's at least usable for me. Have to turn off full solution scanning, but other than that it works.
I agree that the general experience is degraded by ReSharper, sometimes severely, but VS is just too dumb without it, IMHO.
I've recently uninstalled Resharper, mostly due to slowness and frequent VS crashes. For refactoring I've found Roslynator to be a fairly good replacement. In the codebase I'm working on ice noticed the worse options for jumping to derived types, etc., but at least I know that codebase very well so I have other means of going where I need to. It's generally been more than offset by having a responsive IDE.
Code completion is over thing that previously caused me to reinstall, but Intellicode is good enough by now. That one also comes with one very nice feature that I've used a few times by now: turning manual code changes into refactorings. Once you start editing the same thing over and over it starts suggesting you too do the same as a refactoring. And so far it's been very good with detecting such pattern changes and changing them on its own.
I actual like vs (but that is more inertia than anything). But that is one annoying thing about it. The features are usually there, but buried in some inscrutable way. It is one of the more robust IDEs out there. But you kind of have to do it the VS way or you will get mad at it.
There are hundreds of things the prog does. But literally have no icon to click on or short cut bound to them. You have to dig them out of the options and bind them or add them to a menu item to even get at them. Its been like that since the mid 90s.
FWIW I (a daily VS user and someone who is generally fond of it) don't particularly like the VS folder view. I find it slow to open and a bit clunky; accordingly I often have VS Code or a terminal or Explorer open in addition to VS.
Last time I had to use Visual Studio (about 10 years ago) I used emacs to write my C# code and used Visual Studio to manage the "project" and run builds. Mainly because I had 2 decades of Emacs muscle memory and I kept fighting it in VS (yes, I tried the emacs keybindings in VS).
I would think visual c++ must be one of the intended use cases. it's far from the worst c++ ide, but it can be pretty frustrating. you basically can't trust "find all references" in large projects.
> If you are having to fight with VS, then you may not be using it for one of its main use cases.
So I worked on VS tooling for a few years and I'm proud of what me and my peers achieved, but I don't think this is the right perspective. People should not be surprised by the behavior of their tools, and they should not be frustrated by random freezes or crashes all of the time. What the person you're replying to has experienced is very real - I saw it come up again and again and again in reports - and I hope that things improve for them with subsequent releases.
VS 2022 is a fantastic new release (64-bit solves so many perf and user-perceived reliability issues), but there is so much more to go. VS still relies on a very very old COM-based UI model with one of the most convoluted and complex threading models to manage it that I've ever seen. It's so easy for any little component to mess things up, hang the UI, and make someone have a terrible experience. I know folks on the inside are working to improve this dramatically (they know roughly how to do it), but it's a long road ahead.
You should be very proud. I remember the early .NET 2.0/3.0 days where you had to have ReSharper installed and it made VS almost unusable.
Nowadays (the last 5-6 years) I use Visual Studio without any third party extensions - it's a blast!
I believe Visual Studio to be one of the crown jewels of Microsoft.
> 64-bit solves so many perf and user-perceived reliability issues
I love how in tech everything is always evil one day and the next one nearly the panacea. Now I understand the timing component is actually not to get rid of entirely, in the sense that maybe a 64-bit VS would have been a bad idea the year AMD released x64, but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance.
I suspect the cold reality was that the code base was not ready and the migration just took some time :)
>but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance.
Yeah, this was from a series of articles that were a great example of managing to be right about all kinds of things but still be wrong in the end.
Specifically, the articles laid the blame for things like memory usage (which when high enough, causes a foreground GC in the devenv.exe process that freezes your UI), on language services that get all too happy to allocate tons of memory. If you make this 64-bit, pointers double in size and you could observe even more memory usage. 64-bit is also objectively slower than 32-bit in terms of CPU time to execute stuff. The solution it suggested was for memory-intensive components to move out of process, which is actually what many of them did in VS 2017 and VS 2019.
But the problem with this article is that it was entirely speculation. It did not account for several things:
* A 64-bit devenv.exe process gives the GC more "room to work with" and do more background GCs rather than foreground GCs, which will pause the UI far less
* Marshaling data between processes still requires use of the UI thread in VS in various scenarios, due to a wildly complicated threading model that people mess up all the time
* You really don't know what the impact of something is going to be until you actually do it
* If you commit to something ambitious like going 64-bit only, engineers can meet the challenge and produce something very good
My personal belief is that 64-bit could have been reasonably accomplished many years ago, and it would have been the right call to do it then. But I won't be looking a gift horse in the mouth. The codebase I contribute to is so much more pleasant to work in with VS 2022.
From the outside it seems to be in maintenance mode. It hasn't received new features in a decade (other than the port to .NET Core, if that counts). The Windows team has staffed it with a skeleton crew (a manager and 2 devs last I checked). They don't have bandwidth to review most community PRs, and even the .NET team doesn't get responses to issues: https://github.com/dotnet/wpf/issues/3811
idk, I hope I'm wrong but they have been promising improvements for a while and I'll believe it when I see it.
Ooof, yeah, I should have looked at the commit history. It does look like a skeleton crew and all the knowledge of WPF is in another team now. What a shame. At least WPF is stable for what it is though.
Lately VS has been breaking my code with its autocomplete, for example lets say I'm working on a web project and want to wrap an element in a div, I may have some existing code I want to reuse so I will copy and paste the opening tag for example, <div style="some styling" class="class1 class2 class3">, then I will hand code the closing tag like so, </div> but VS will 'correct' it to this </div>> for some reason and my code wont work, I start debugging only to find that the autocomplete has again broken my code.
Couldn't agree more - love visual studio (on windows), and vs code even more (lighter weight, but less features) when I am on a mac or ubuntu.
Also use Visual Studio on the Mac - that one I could agree is terrible - but hope it will improve over time.
Probably helps that I have used every version of VS since it was released - so like anything else, if you are used to it and use it every day for 20+ years you become biased - but for C# programming, imo, nothing even comes close.
On the Mac I use Rider which is in many ways a huge improvement over Visual Studio. No visual editing of XAML files though, so I am slowly migrating the codebase to use views fully written in C#.
I've been a long time VS user. Started with Visual C++ 6... In my experience, it's never been a straight forward conclusion of version X is better than the one before. With each release, it does somethings better, or new, but others worse, sometimes cripplingly so. And one of the most frustrating things for the longest time was that if you needed a specific C++ compiler major version, you were stuck using the specific VS version that shipped with the compiler (unless you were willing to ditch projects and go with makefiles). Only in 2019 did that finally change. And speed of the IDE itself has been dodgy at times, even for brand new projects. I've tried the 2022 preview (I have not yet tried RTM), and there are excruciating pauses in the UI for seconds to create a new file in an empty project! But, there are great new features in there, too...
Like Pretzold, I have a love hate relationship with IntelliSense. I think I can boil down my gripes with this: IntelliSense is wonderful for consuming APIs. It is an active hindrance for writing/designing APIs. It is great for telling you about what exists, but falls on its face when you're trying to write something new. If I am undoing the suggestions I didn't want, yet it insisted on placing, it is counterproductive. Personally, I get rather tired of slapping the escape key to cancel IntelliSense multiple times just so I can write out a dotted expression.
Not all portions of VS are maintained to the same degree - their BI tools were horrible for years, and there was not much in the way of alternatives. I'd often spend more time fixing/triaging the IDE issues than I would my own code/projects. And when you then start to add multiple versions of VS into the mix (this was required for the BI projects + newest SQL Server database projects) it gets even worse.
> I don’t see how anyone can have this opinion. If you are producing code for which VS was designed (.net for example) it is obviously and definitely one of the greatest IDEs ever produced.
Hard disagree. VS makes code harder to navigate than any other popular IDE out there to the point where even vscode is more intuitive and capable, it's extremely slow at that too, and makes even the tiniest change to a build config something that requires jumping through a myriad arcane menus.
Having used other IDEs to develop Java, C# and C++ code, the only explanation I can find to explain Visual Studio's adoption, besides privileged access to Microsoft's emergent technologies and frameworks, is the boiling frogs analogy.
> If you are having to fight with VS, then you may not be using it for one of its main use cases.
I guess that writing software and building projects are not Visual Studio's main use cases, then.
However, I'm not sure if other C++ IDE beats VS. The thing about VS is: I started to use VS back in VS2012, and for EVERY version that follows, it seems to be slower and slower. The last version that I stay put is VS2017 and I still have it installed.
I have very good experience about Jetbrain products so maybe I'll try their C++ product as well, but so far I heard it's not very good for large projects.
Rider for sure. I commonly see mistakes in code reviews that likely wouldn’t have happened if they were using an IDE that provided more information.
Once Rider and dotnet core liberated my work from Windows, I don’t see myself going back to VS unless there’s some technical reason it’s use is required.
I find VS2022 to be anything but slow now that it’s 64bit. Having said that, without ReSharper I find VS to be a terrible experience (I’ve been using R# for 15 years.) Rider is also a viable alternative.
I have a project here that won’t even open with Resharper on in VS2022. It just hangs and wedges the CPU at 100%, then my shitty laptop overheats and hibernates.
Then I get pissed off and go for a walk and wonder why the hell I ever invested so much time in this.
Laptops have always been a compromise between portability, battery life, thermals, and performance. In my opinion, Visual Studio was never meant to run well on a laptop.
>>without ReSharper I find VS to be a terrible experience
Resharper was always one of my favorite must have utilities to use for C# development in VS - but I have had the opposite experience as you, it became so slow and so bloated I had to give it up - often spiking my CPU to 100% and making the entire solution unusable - until I uninstalled it.
Never could figure out why, but maybe resharper has gotten better since then?
> Never could figure out why, but maybe resharper has gotten better since then?
R# runs in-process and has its own project system, language service, UI elements, etc. That's simply a lot of stuff to do in the same process that also has the VS project system, language service(s), UI elements, etc. running. Both have added tons of features over the years, so over time it just slows down.
The R# team is working to run it out of process, but it's an enormous amount of work. I suspect that VS 2022 (64-bit) will help with this compared to previous versions though.
I strongly disagree with Visual Studio being slow.
Visual Studio 2022 is hands down the best IDE ever created.
(I have been using Visual Studio since 6.0 and .NET since the Beta of 2000)
2022 does seem reasonable. 2017 and 2019 have been very bad.
If they had moved to 64-bit a decade ago when it was obvious that they needed to do so, they would have never developed this reputation for being unusably slow and kludgy.
Worst was 2010, when they tried to switch to WPF or something. It was really slow.
The top versions of Visual Studio for me: VS 2022, VS 2008 and VS 2019.
The Chief Architect of Visual Studio mentioned on the VS 2022 launch event that they were planning to migrate it earlier, but according to telemetry data - just the past 2-3 years people started to use 64 bit operating systems et mass :)
Btw I would love to see percentage of programmers who have families and children broken down by:
1. Ones using IDE like Visual Studio, Eclipse, Rider, etc.
2. Ones using IDE-ish editors like VS Code, Sublime
3. Ones using vim/emacs
> according to telemetry data - just the past 2-3 years people started to use 64 bit operating systems et mass
This is what happens when you blindly trust telemetry when the target group of a product is the most likely to disable it because of company policy or personal preference.
Yeah. You just create new code files outside of VS, and re-run CMake or add them to the project. Adding a new source file in VS will always shoot it in the wrong folder, and apply some useless template.
Same could be said for Mac or Linux development, but those ecosystems have continued to evolve, and the modern approaches to things can generally be taken seriously (unlike WinRT/UWP/WinUI2/WinUI3). It’s worth meditating on how thoroughly Microsoft failed to keep their stack modern. I think it’s much easier/faster/cheaper to create a great product using web tech these days than Windows, and that’s 100% on Microsoft.
Agreed. It's not for lack of investment either; they invested staggering amounts of engineering time in WinRT and UWP and they actually built some cool stuff.
But, well... it certainly didn't help that they made it so difficult to adopt the new technologies. Project Reunion/WASDK makes it seems like they've learned that lesson and are trying to salvage what they can - but it's much too little and much too late.
Their cloud “stack” is pretty modern. I thats clearly where a lot of their effort has gone.
And not to be too “fanboy” about it, .NET 6 is superb (for web dev at least).
I think it’s worth giving MS some credit for what they’ve achieved there. Like it or not, Azure is impressive.
But I agree with you with regards to the traditional Windows stack. It’s not in a good state at all. I rarely use Windows any more, at least where I can help it. And I’ve been an MS orientated developer (starting with VB/ASP) my whole career.
At this stage I’d be very happy to never touch Windows again unless they make a very sharp course correction in the next year or two!
(And to the point of the article, I’ve switched from a career-long use of Visual Studio on Windows to Rider on the Mac and I’ll hopefully never go back!)
I used Visual Studio a lot until 3 years ago, to the point that I was almost addicted to Intelisense.
I'd answer yes but it is not just Visual Studio, it is the whole comfortable, automated, well integrated and productive environment of MS tools: VS, .Net, SQL Server, ASP .Net, C#, etc. But that can be said about all sorts of sophisticated, strongly integrated and powerful tools, not only Microsoft's. The whole XCode/Swift/Apple ecosystem is not very far off.
The good thing is that these tools will never be the ultimate answer. Computing environment changes and that moves people away from their comfort zones and forces them to try new environments.
While Windows has a huge API, the Unix/Linux-side is particularly huge as well. Win32 API includes a wide variety of cryptography for example, while modern Linux leverages a 3rd party open source program: OpenSSL or similar, to accomplish the same thing.
Another example: Windows Jet Red, which is roughly equivalent to Berkley DB (older style database focused on concurrency of access features / transactions, WITHOUT building up to a higher level SQL interface)
There's also obsolete / legacy technology. GDI is fully legacy these days (GDI is simply a layer on top of the "modern" DirectX framework, replaced by Direct2D). So all of those HBrush / Printing code is as unused as GTK 1.0 (or perhaps lower level XWindows code).
1. The Win32 team is very good at supporting legacy code. The API is monstrous, but it accomplishes its goal to a significant degree. Code written 30 years ago largely still works, you can't say the same about any other modern windowing API.
2. The technologies used in Win32 API cover a huge number of competing technologies. Not just OS-level stuff (files and IPC), but also cryptography, databases, threading and more. Furthermore: this API has remained consistent for decades (while Linux has had huge threading changes: the shift from Linux threads to NPTL threads for example).
3. Obsolete portions of the Win32 API hang around. Both the good and bad bits. Other OSes retire these supporting libraries (ex: GTK 1.0 or GTK 2.0, or KDE) more quickly.
> Avalon and XAML
Oh man. Petzold didn't even get the half of it since he couldn't see the future.
XAML's biggest issue is the lack of legacy support. Here he's talking about how Avalon/Longhorn (precursor to Vista, precursor to Silverlight, precursor to Win8) was being handled by programmers inside of Microsoft.
Maybe if Avalon stuck around for a while, it'd have been cool. But the amount of change that occurs over the next 17 years has made any bet on XAML a poison pill. Win-Vista gadgets are gone, fully obsolete and unsupported. If you moved your stuff to Silverlight, too bad, Silverlight is _also_ gone.
But don't worry, your Silverlight code got translated to Win8/Metro right? Or... was it UWP?
I think ultimately, the XAML has become much more beautiful and elegant. But these days, its an issue of "trust". Its a big and expensive hassle to rewrite your code into other frameworks, and Microsoft just didn't want to build XAML-stuff on top of anything steady.
It does seem like things have settled down upon UWP finally. Win10 / Win11 seems like its holding that API "steady". But Microsoft really shot itself in the foot too many times.
Hmmm. I thought the migration path between WinUI 2.0 (aka: UWP) and WinUI 3.0 was easier.
Looks like Microsoft screwed the pooch one more time for one more upgrade cycle. Why do they keep doing this? They really need to think about code compatibility for more than a couple of years.
Its not like Android or iOS developers need to deal with 3+ migrations over the past decade.
I left Windows programming around 2006 or so, when it was Win32 and maybe MVC if C++ was your thing. Recently was noodling around with the idea of porting one of my hobby projects to Windows, and a just can't believe the mess the platform has become! Now we have Windows Forms, dotNet, WPF, UWP, WinUI, and probably a dozen more. What API should I use to "get back into Windows"? Will it be deprecated next year? If I pick the wrong one, and drive the train down those tracks for a few months, am I basically throwing all the code away? What an absolute mess!
Based on everything I've seen in the last year and a half: WebView2 (i.e. Chromium) is getting more investment from the Windows team than any of the "native" UI technologies. I'm not thrilled about it but I'm adjusting my plans accordingly.
I can speak to the UWP -> WinUI 3 transition a little: it's a hard transition because UWP did so many things its own way. It's often really difficult to migrate concepts from UWP to the Win32 app model. And I get the impression that the number of people working on WinUI+WASDK is pretty small; it's more of a "salvage what we can" operation than a "build out the future of Windows app development" one.
Ignoring the entire article, after using it for 20 years now, it rots my patience and will to live on large projects. It’s like driving a 30 year old car that was serviced 20 years ago and veers off the road uncontrollably once an hour.
I suppose the last feature is modern if you compare to a Tesla.
The twisted thing is that from what I have seen, the entire .Net development community is so compartmentalised that they think this is business as usual. Literally spending all day in pain with no idea there is a better life out there.
What’s better out there? I’m using VS with a solution that eaaily has VS use 10Gb ram. I have tried vscode and Rider too, but Rider really wasn’t an option with parity until this last year or so. The perf in Rider is a bit better but I wouldn’t say it’s a dramatic difference.
VS on reasonably small solutions (fewer than say 50 projects or 10k source files) is more than snappy enough these days.
It’s on those large solutions it runs like a dog when each GC collects 2-3gigs of garbage in 5 frozen seconds and runs every minute.
What would be better is if they actually tore down the myriad of shitty misfeatures, bloat and bugs and did some housekeeping rather than change the theme and pile on features like an Indian train at rush hour.
The one that kills me is the moment I hit . After an identifier I have to wait 30 seconds for it to work out what to do.
That’s just broken.
As always with Microsoft they need to actually go talk to the customers rather than collect telemetry.
They can’t because VS is a pile of COM-mess compatibility. So when they clean up they did it in vscode because there are decades of compat to maintain in VS. Every VS has to do what every old VS did and the new things. And it has to do it the same way too.
We had to build tooling to break out solutions into multiple working solutions for use in VS and then use the actual solution for the build system. This meant that people would often break the build by modifying their local solution but not understanding what was really going on in the central build.
Our cutoffs were way smaller than 50 projects and 10K source files, though! (We had a lot of generated code, which we eventually mostly switched from generating code to generating MSIL directly to save the IDE.)
It definitely would have; unfortunately, that was introduced in VS2019 and we had the need a decade before that, but glad to see that a better solution is now available.
im having a hard time to relate to this, i like vs for c# .net, where i can see it as a problem if its forced upon clients with js or nodejs projects these do not seem to run well.
Worked on nodejs projects like this before, where VS was the prescribed IDE. All it does is mix in the worst parts of the VS experience into node development.
I would make changes in Webstorm, and then other devs couldn’t see my changes in VS because the proj file wasn’t updated. So then you _have_ to open VS to impose it’s junk on something that would normally be editor-agnostic
> I don’t speak to user groups or developer groups very often, partially because of a bad experience I had a number of years ago… I decided to talk about something that people could not read about in my book… Well, people went berserk. I suppose they had been expecting me to tell them everything they needed to know about Windows programming in the space of a few hours, and that’s certainly not what I was interested in doing.
> That was a very traumatic experience for me, and since that time, I have been reticent about speaking before groups like this…
This is bizarre! It's hard for me to imagine an audience reacting this way to a talk. Maybe it's because I haven't been to any user group or developer group meetings. What does "went berserk" in a way that was traumatic for him mean? Did people start heckling him in the middle of his talk? Even harder to imagine!
I think VS of 2005 and VS of 2021 is wildly different.
Back then, chatty Apis like MFC made wizards and code generation almost a requirement for doing anything useful. Putting a window on screen required the equivalent of rendering with Vulkan today.
The problem wasn’t Visual Studio rotting the mind, it would have rotted under Win32+mfc anyway.
For comparison, a netcore6 command line app is now a one liner.
> Putting a window on screen required the equivalent of rendering with Vulkan today.
I'm honestly doubting you've done either because these are not remotely comparable. A "hello world" win32 program that draws a 2D image is easily at least one or two orders of magnitude less code than the vulkan equivalent. I've sold win32/mfc software that was only a few hundred lines.
Talking just about the title since the contents of the article are about as relevant as a discussion of Java 1 nowadays. No.
I had a huge amount of insecurity about this until I tried AoC this year.
You know what's really great? Tools, power drills, printers, word processors, chainsaws, indoor toilets, heating. You know what's also great? Not trying to code in notepad with a paper reference manual.
There's a weird subculture of developers who get off on playing on hard mode and I can finally see there's no great secret in the suffering, it's just rubbish. Language servers, autocomplete, intellisense, inline documentation, time travel debugging, it's just better.
Sure if you enjoy the challenge of coding in Google Docs go for it. But if I want to get work done I'm going to use tools to assist me and I'm no longer going to feel lesser for being productive.
I remember having a discussion with someone in the late 90s. He said he could code websites in notepad. I assume he was trying to brag. I said so could I but who the hell would want to.
I think "no" as well, but I still think it's an interesting read because he lists some consequences that I hadn't ever thought much about. None of them have anything to do with mind-rot, though.
I think it's worse than that. If you are expending mental energy on your dev environment, that's energy you're not spending on thinking about security, readability, maintainability, etc.
My father learned to program in FORTRAN in the 70's. He used punched cards, wrote his code, left the batch of cards at the computer operator and came back a few days later to get the printed results of his program. Sometimes the results were "syntax error in line 11". He never saw the computer but he learned to think before writing.
I met some real old people who used to print their code on paper for review. They made annotations, spent some time reading it like old people used to do with newspapers. They thought about it, sometimes discussed about it, you could see the code was carefully studied out by marks of coffee or cigarette ash.
I learned to program on 8-bit 80's home computers. I later turned to IDE's on PC's. I was impressed by the apparent gain in productivity. I then tried to use linux as old time unixers did. I was impressed that I could feel and sometimes even see what was happening. I saw some great and productive coders who used nothing else than a well configured programming text editor and a terminal. For me that was the most productive and advanced way to write code. I didn't change my mind even after using jetbrains IDE's.
I then became a teacher. I saw students who couldn't tell the difference between a programming language and an IDE. I heard people say java was much better than C and asked why; they explained how great eclipse was. I saw students who were not really writing code, they were writing some random code here and there and waiting the IDE to suggest corrections.
One day I said: "Today we'll write code, but we'll do it on pen and paper first and then we'll type it." After a few days, their skills clearly improved. Syntax errors were rare, off-by one errors mostly disappeared and they started thinking before writing.
I'm not against IDE's, but it is easy to get bad habits because of them. I don't think IDE's are a good replacement for a terminal with a good set of tools. They can improve productivity of good and experienced developers, but when used as a complement, not as a replacement.
This resonates with me. I’m teaching myself Clojure and doing AoC questions as the vehicle. The highly interactive nature is a blessing and a curse. It’s a blessing if I’m thinking clearly and just want to quickly test my code. It’s a curse when I’m not thinking deeply and instead just layering bandage after bandage on the code until it “works”.
> I heard people say java was much better than C and asked why; they explained how great eclipse was.
To be fair, the language ecosystem may be why one language ends up more popular than another that is superior in both memory safety and performance on paper. Of course, these are beginner students who don't have the full context to understand that.
> "Today we'll write code, but we'll do it on pen and paper first and then we'll type it." After a few days, their skills clearly improved. Syntax errors were rare, off-by one errors mostly disappeared and they started thinking before writing.
How anal were you with semicolons, parenthesis matching, and quotation balance? I can't imagine that would be remotely enjoyable to grade. That said, writing down the high-level structure on paper (annotated with the occasional implementation detail I don't want to forget when it's typing time) is immensely helpful.
> How anal were you with semicolons, parenthesis matching, and quotation balance?
In something like an exam, I would completely ignore mistakes like these as mere typos. But it prevented students from trying to write loops by trial-and-error and really understand what they were doing.
As a teacher, I am rather surprised that you would frown on trial and error exploration.
My first program was written on punch cards, It took a shoe box full of them to complete trivial assignments. I was thankful when I got to use my first line editor, my first page editor, my first general editor and my first IDE.
I don't believe anything would be gained by going back to carving programs out of stone tablets.
I've worked with several junior programmers who, when they encountered an error in a program they were working on, would immediately go back to their editor and try changing something to see if it fixed it. I encouraged them to stop, read the error and stack trace, and understand the issue before they changed anything to fix it. I think their skills improved for it.
Trial and error is good, but you have to understand what you are trying, and if it works, why. Writing out a program up front can encourage this.
Yeah. I take this a step further, FWIW: I often look at something and think I know what is wrong, but I still force myself to prove it before allowing myself to try it, as the goal is to get better enough to not make the mistake in the future as well as be sure it works rather than merely looking correct for some "test".
Trial and error to learn something new is one thing. Trial and error of random modifications to fix something without ever understanding what was wrong is another entirely different thing.
As someone that learned programming with editors/IDE, it's nice once in a while to go back to more basic methods, think more about the code. This is useful when at work the edit/deploy/test cycle is ~5 minutes.
I can assure you that even trivial programs in Fortran and Cobol could be a shoebox or more of punchcards.
Imagine someone knocking your shoebox off the table and having to sort them all by hand. Imagine that on your 3rd run, the reader eats one or more of your cards, then they all start to fail.
Programming was wonderous to be sure, but no one is worse off with an IDE and a interpreted language.
I saw students who were not really writing code, they were writing some random code here and there and waiting the IDE to suggest corrections.
Your experience --- especially with teaching --- is basically exactly the same as mine. IDEs add a lot of distraction from the process of actually thinking about and "mentally executing" the code you're writing, which is an important skill to develop especially for someone who is learning.
"How can you tell the computer what to do, if you don't know how to do it yourself?"
IDE being complement of a terminal - sorry been there done that. I started my programming with machine codes. Do I want to go back to that stage - frigging no. And the scope of the programs I had written back then was way smaller than what I do now. IDE along with the other tools are now invaluable help.
His IntelliSense-enforces-bottom-up-programming rant couldn't be more wrong these days.
IntelliSense (plus refactoring suggestions) is perfectly happy for you to speculatively make a method call that doesn't exist and then to infer (and auto-implement) its definition based on the types of the parameters passed in the example call.
I find meet-in-the-middle works quite well, starting with a top down outline of what I'm trying to accomplish combined with implementations of the design-critical algorithms that I know I need at the bottom, and having all of that come together in the middle. I find that the bridge rarely fails to join up correctly in the middle of the lake.
Sometimes I get some rubbish automatically filled in by IntelliSense but most of the time I can just press 'esc' and continue doing what I want and not what editor is proposing.
> Most of the really innovative interactive design stuff found its first expressions in the Windows-based versions of Visual Basic, and here’s where I started becoming nervous about where Windows programming was headed. Not only could you move a button onto your form, and interactively position and size it just the way you wanted, but if you clicked on the button, Visual Basic would generate an event handler for you and let you type in the code.
At this point in the essay, we find ourselves arm-pit deep in get-off-my-lawn. He goes on to make the argument that a disjoint pile of event handlers attached to UI elements do not make a coherent program.
Even while conceding that this claim is 100% true, there most definitely exist cases where all you need is a hand-drawn UI with disjoint event handlers to breathe a little bit of life into the experience. Frankly, most simple web pages find themselves DELIGHTFULLY in this category.
When just editing code, I prefer VSCode. But for debugging C++ there is nothing that comes even close on any platform productivity-wise to Visual Studio.
I guess if you're not doing cross-platform and staying within the ecosystem (MSBuild, NuGet, etc.), the project management is also nice.
Socrates: I heard, then, that at Naucratis, in Egypt, was one of the ancient gods of that country, the one whose sacred bird is called the ibis, and the name of the god himself was Theuth. He it was who invented numbers and arithmetic and geometry and astronomy, also draughts and dice, and, most important of all, letters.
Now the king of all Egypt at that time was the god Thamus, who lived in the great city of the upper region, which the Greeks call the Egyptian Thebes, and they call the god himself Ammon. To him came Theuth to show his inventions, saying that they ought to be imparted to the other Egyptians. But Thamus asked what use there was in each, and as Theuth enumerated their uses, expressed praise or blame, according as he approved or disapproved.
"The story goes that Thamus said many things to Theuth in praise or blame of the various arts, which it would take too long to repeat; but when they came to the letters, "This invention, O king," said Theuth, "will make the Egyptians wiser and will improve their memories; for it is an elixir of memory and wisdom that I have discovered." But Thamus replied, "Most ingenious Theuth, one man has the ability to beget arts, but the ability to judge of their usefulness or harmfulness to their users belongs to another; and now you, who are the father of letters, have been led by your affection to ascribe to them a power the opposite of that which they really possess.
"For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom, for they will read many things without instruction and will therefore seem to know many things, when they are for the most part ignorant and hard to get along with, since they are not wise, but only appear wise."
This is spot on, and I've found myself making the same argument recently about GitHub's Copilot. It's changing the way I write code in a way that I can already tell is allowing me to be much lazier than I've previously been about learning various details of languages and libraries. There's an obvious tendency to play Thamus and judge that as a bad thing, but I think the reality is that Copilot and future generations of tools inspired by it will completely change the operation of programming in ways we can't even imagine yet, allowing us to build software more quickly than we currently suspect.
It's a train of thought that spans the arc of history: the New Thing, which allows young people to get by without developing deep skills in an area that was previously critical to success, is inherently bad because it enable laziness. In reality, it provides the leverage necessary to do things faster, or sometimes to do previously-unimaginable things.
That's a straw man. I've not seen anybody argue copilot is a bad thing because it makes developers lazy.
I haven't tried it (I'm registered, no joy) but I'm skeptical of its utility, to me at least, because it replaces writing code with reviewing code to identify whether it does what it should and fixing it if it doesn't, and I find the latter vastly more time consuming and mentally taxing than the former.
I have it, and it's quite good. I believe you'll change your opinion once you actually get a chance to use it in a real project. For example, I was able to have it write a bunch of boilerplate for me for converting a database query into their proper TypeScript types. I could have done that manually but it's, well, called boilerplate for a reason.
It also helped me learn new features or ways to do certain actions. One such case was how it used immutable data structures to represent a change rather than mutating. Think `arr = [...arr, newElement]` rather than `arr.append(newElement)` which is not exactly the code I was writing but simply an example.
I have an open mind, and if I find it a useful tool I'll adopt it enthusiastically. However I remain skeptical for the reason I said.
The positive comments I read from people who've tried it give examples of things it's done right, effort saved, things learned, but make no mention of the effort taken to verify what it produces. I don't know if that's because they're uncritically accepting what it produces (which would be bad), because it's only usefully producing trivial bits of code (which would put it in a race against how fast I can type, handicapped by whatever percentage of the time it gets it wrong and the time taken for me to check) or because I am somehow unusual in finding reading code much, much harder than writing it.
I'm getting pretty frustrated with the limited access. I signed up months ago. Just release it already.
It's not a straw man; I'm articulating one of several thoughts I personally have about the tool after using it for some time. I'd be surprised if I'm the only one it's occurred to and I'll be _extremely_ surprised if we don't hear a whole lot of it once Copilot is more widely available.
At any rate, I was also initially somewhat skeptical but it is hard to overstate how effectively it predicts exactly the code I was about to write, or suggests the code I don't know I want. It is, for me at least, significantly faster in the languages I know well, and monumentally faster in the languages I don't know well.
Yep! And a lot of his concerns and contempt for the written word were addressed by the post-structuralists later, so citing Socrates as evidence here is pretty dang old-fashioned indeed. A lot of the other comments here would find his viewpoint sympathetic though; if your concern is that new tools increase the rate of syntax errors and spelling mistakes in programmers, the case is obvious.
But can I controversially suggest that once we learned to write, we may've traded away some of our memory, but in order to gain an enhanced capacity for reflection and development of thought? Writing freed us from the burden of remembering as much so we could apply that energy to creativity instead. Likewise in programming, I'm happy to trade not being able to memorise and internalise a language's grammar if my IDE helps me accomplish the task more easily. I can focus on devising a solution rather than focus on nesting a parenthesis correctly. I appreciate there's a certain pride in doing these things without fault, but for the 95% of us who program to solve problems, the busywork can go.
> Well, the debate is now over. In order to get IntelliSense to work correctly, bottom-up programming is best. IntelliSense wants every class, every method, every property, every field, every method parameter, every local variable properly defined before you refer to it. If that’s not the case, then IntelliSense will try to correct what you’re typing by using something that has been defined, and which is probably just plain wrong.
This gives me an idea: somebody should make an inverse intellisense that lets you type as if a function exists that you haven’t created yet, and instead of using a bunch of red squigglies and making you feel like a fool for typing broken code, offers you a shortcut to create the code that doesn’t exist yet.
Bonus points if it uses the language’s type inference to inform what to create, like:
String s = foo.bar(someInt);
Would offer a quick way to make the stub:
// (class of foo)
String bar(int someInt) {
// TODO
}
There’s probably tons of ways to make this super ergonomic too, maybe with an easy keyboard shortcut (maybe if ctrl+space triggers intellisense, ctrl+enter could trigger the “make stub” functionality) and could work quickly and with no fuss. The method just gets added in the background, you don’t even see it, you just get to keep typing out your train of thought.
This could be extended to more than just methods, but whole classes/structs/etc.
I know IDE’s have lots of affordances for creating new code from templates/quick actions, but there would be something magical about being able to just type out your mental model at the current abstraction layer, all at once without distraction, and have the IDE better help you “make real” the code you just referenced.
There's a code first approach that's pretty common in VS - but it's at the class level - Just write the code inline and click on it and it generates the class/method stub. So What you are suggesting already exists in standard VS.
The tweaking of allowing possible results in the dropdown is a very very interesting idea - imagine if you let copilot suggest possible methods based on the domain context of the current project.
> pretty common in VS - but it's at the class level
I haven’t used VS in over 10 years - what does “at the class level” mean? Does it only create stubs for the current class, or any class that’s in the current project?
It is interesting that VS has this at all though, as a daily Xcode user I’m jealous. Especially because ObjC and Swift have first class (and popular) ways to add methods to classes you don’t own via extensions… the concept of adding new methods automatically as you type is even more attractive in this ecosystem.
Sorry I said "class level" since that is what I remember specifically but I think it's actually everything. Classes, methods, types - also I mis-remembered that this was built in. It's actually resharper which I always used.
> instead of using a bunch of red squigglies and making you feel like a fool for typing broken code, offers you a shortcut to create the code that doesn’t exist yet.
The Haskell Language Server allows this. On the other hand, its autocomplete doesn’t seem to work so well yet (at least on Emacs), so I guess it’s not really comparable.
Not sure about other IDEs, but Visual Studio pretty much does exactly this and more (for C# anyway). You can pretty much design an entire class by first _using_ it and then use Intellisense to generate the class/method/property stubs all with the correct types.
> Eventually, the interactive design stuff found its way into development with C++ and the Microsoft Foundation Classes, and there, I truly believe, code generation was used to hide a lot of really hairy MFC support that nobody wanted to talk about.
Every so often for my day to day job I need to work with some really old and crusty MFC-based UI code and while Visual Studio still technically supports MFC, in practice it seems to be basically unusable. I doubt anybody at Microsoft actually tests this functionality because much of the time it fails spectacularly for me - even the templates don’t even really work. So this means I need to struggle through manually messing around with impenetrable machine-generated code files and hope for the best through extensive trial and error.
Many of the arguments against IDEs in general apply just as well to the punch card -> text editor transition. It's just that the arguments are more easily seen as folly in the latter case.
In terms of code completion, the complaints in the article seem more focused on it being buggy, but there's also complaints about it dictating how code is written or feeling bad for using it (??). Code completion is a win. Automatic completion of names is a speed win. The ability to get essentially an locally relevant API reference is a win. Even the ability to write code by relying on code completion giving you correct suggestions is a win: it clearly lowers the barrier to writing functional code. The issues people have with the last one boil down to "people can get the job done without knowing how everything works".
A lot of the rest of it seems more griping about VS default behavior rather than the impact it has on the code being produced.
When push comes to shove, the real issue people have with many of these things is essentially that it lowers the bar to getting a program to "work". It lets "bad coders" succeed. Sure, such tools can result in bad code, but in the end the goal of anyone writing code in any form is to getting a task done, in which case "bad" code is better than no code.
Even better is that people who start off thinking that programming is some magical impossible skill may start with some basic tutorial + stack overflow + code-completion code, but in doing so and getting something to work they may do it again, and after a while develop their skill. Maybe they'll laugh at their old code, maybe they won't, but the important thing is that the tools doing some of the work made it possible for them to do the rest.
Another simple analogy is manual vs. automatic cars. Are automatic cars bad because learning to drive in an automatic means you don't know how to drive a manual? Some people argue yes, despite the abundant evidence that the existence of automatics made driving much more accessible. It also reduces the need for a driver to focus on anything other than driving, which is very clearly a good thing.
If anything things like refactor suggestions and the like can make bad coders better by telling them things to fix before they even save their changes. It’s like a “code review in a can”. I try to encourage the people I work with to use these tools because it means less time is wasted on nitpicking over things like style and common mistakes during code reviews and everything can go more smoothly.
149 comments
[ 3.3 ms ] story [ 240 ms ] threadBeyond being slow and confusing and unintuitive I think the most annoying part is whats mostly mentioned in this article. Either you do things the visual studio way or screw you. Even creating a blank file is annoying and it keeps trying to shunt you into various templates.
The list of actions for which closing visual studio, deleting a bunch of random folders, and restarting is long. Unfortunately it includes any changes to project files, because the project system is super broken with anything multitargeting related. That basically means I have to completely restart my IDE and run a script to clean everything maybe 15 times a day. And fuck me if I’m trying to find where a regression happened (which means changing dependencies, which live in the csproj).
I remember when I didn’t have to restart VS 30 times a day, and memorize which build errors actually aren’t errors, and do random sequences of events to work around bugs, and memorize which unsuppressable warnings are legitimate and which are not. Before those days, Visual Studio was indeed an incredible accomplishment.
The complaints in the original article fell rather flat to me, but this is one area where it's absolutely fair to criticize VS. More generally, the reason that build tooling in the .net sphere is such a mess is because of historical baggage from VS.
With that said, if you're coloring within the lines[1], VS is very powerful and productive.
[1] To an extent. There definitely are use cases that are "supported" only in name.
This is part of why the .NET hot reload fiasco was such a big deal to me; it felt like doubling down on one of .NET's biggest weaknesses.
The exception was Xamarin/Xamarin.Forms. Seriously, congrats to the Xamarin people for getting that project going, but it was (at least into Xamarin.Forms 1-3) more than a little hacky and extremely frustrating. Granted, it kind of had to be though given that it was intended for a broader audience targeting completely different platforms, and at least initially didn't have a lot of MS support iirc.
I think the issues surrounding cross-platform targeting were/are less a problem with the IDE itself than what it was/is forced to work with. The whole iOS "code in VS on Windows, but build on a Mac" was a nightmare, I don't know if things have gotten any better.
This is because the software you're building today is far more complicated than before (from the IDE's perspective), and it doesn't do a good job of keeping up. There's a reason why so many people jump to VSCode these days - it gives you less bells and whistles, but it won't blow up on you when you try to do something moderately complex.
it's pretty common amongst those who used Delphi 15 years ago (or those that use JetBrains products today)
The good parts of VS is hot-reload (when it works), the debugger, and the profiler. Otherwise I'm not a fan.
Yes you can. Change from solution view to folder view.
>The good parts of VS is hot-reload (when it works), the debugger, and the profiler
So everything you want from an IDE?
What are you actually angry at?
I'm not angry, I just don't think it's fair to claim that VS is a good IDE.
If that's all you expect from an IDE, I understand why you're happy with VS :D
If you're targeting .NET or C++ development for Windows, there's not a lot of competition to be able to claim that there's something substantially better. Rider, IMO, is on par, with better refactoring. However, VS debugger is still better.
Like this?
https://raw.githubusercontent.com/jchv/files/main/devenv_G81...
Use the "Switch between solutions and available views" button and select "Folder view." Seems about right to me.
> Visual assist is very inept compared to Jetbrains products
Jetbrains does have better refactoring, but you don't really have to choose one or the other; Resharper and Resharper C++ give you the best of both worlds. Jetbrains is missing some stuff that Visual Studio can do, too. Visual Studio does some static analysis to detect out-of-bounds errors and other mistakes, which is useful to have as quick feedback in the IDE, in my opinion.
VS isn't all too shabby, they've been shaping up recently. But it certainly isn't the best, or even among the better, in my opinion. Even the file editor is pretty weak compared to other editors IMO.
I find Resharper slows everything down significantly and makes VS worse overall.
ReSharper has been really slow, yes, but it's also much better than intellisense and noticably better than Visual Assist. As of now, it's at least usable for me. Have to turn off full solution scanning, but other than that it works.
I agree that the general experience is degraded by ReSharper, sometimes severely, but VS is just too dumb without it, IMHO.
Code completion is over thing that previously caused me to reinstall, but Intellicode is good enough by now. That one also comes with one very nice feature that I've used a few times by now: turning manual code changes into refactorings. Once you start editing the same thing over and over it starts suggesting you too do the same as a refactoring. And so far it's been very good with detecting such pattern changes and changing them on its own.
There are hundreds of things the prog does. But literally have no icon to click on or short cut bound to them. You have to dig them out of the options and bind them or add them to a menu item to even get at them. Its been like that since the mid 90s.
That's literally what GP is trying to say: "either you do it the VS way or screw you."
It takes like 20s to search source filenames of large projects, with fast SSD and 64 cores.
So I worked on VS tooling for a few years and I'm proud of what me and my peers achieved, but I don't think this is the right perspective. People should not be surprised by the behavior of their tools, and they should not be frustrated by random freezes or crashes all of the time. What the person you're replying to has experienced is very real - I saw it come up again and again and again in reports - and I hope that things improve for them with subsequent releases.
VS 2022 is a fantastic new release (64-bit solves so many perf and user-perceived reliability issues), but there is so much more to go. VS still relies on a very very old COM-based UI model with one of the most convoluted and complex threading models to manage it that I've ever seen. It's so easy for any little component to mess things up, hang the UI, and make someone have a terrible experience. I know folks on the inside are working to improve this dramatically (they know roughly how to do it), but it's a long road ahead.
I believe Visual Studio to be one of the crown jewels of Microsoft.
I love how in tech everything is always evil one day and the next one nearly the panacea. Now I understand the timing component is actually not to get rid of entirely, in the sense that maybe a 64-bit VS would have been a bad idea the year AMD released x64, but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance.
I suspect the cold reality was that the code base was not ready and the migration just took some time :)
Yeah, this was from a series of articles that were a great example of managing to be right about all kinds of things but still be wrong in the end.
Specifically, the articles laid the blame for things like memory usage (which when high enough, causes a foreground GC in the devenv.exe process that freezes your UI), on language services that get all too happy to allocate tons of memory. If you make this 64-bit, pointers double in size and you could observe even more memory usage. 64-bit is also objectively slower than 32-bit in terms of CPU time to execute stuff. The solution it suggested was for memory-intensive components to move out of process, which is actually what many of them did in VS 2017 and VS 2019.
But the problem with this article is that it was entirely speculation. It did not account for several things:
* A 64-bit devenv.exe process gives the GC more "room to work with" and do more background GCs rather than foreground GCs, which will pause the UI far less
* Marshaling data between processes still requires use of the UI thread in VS in various scenarios, due to a wildly complicated threading model that people mess up all the time
* You really don't know what the impact of something is going to be until you actually do it
* If you commit to something ambitious like going 64-bit only, engineers can meet the challenge and produce something very good
My personal belief is that 64-bit could have been reasonably accomplished many years ago, and it would have been the right call to do it then. But I won't be looking a gift horse in the mouth. The codebase I contribute to is so much more pleasant to work in with VS 2022.
WPF has been more-or-less abandoned by the Windows team, and that's a little scary since VS uses WPF so much...
idk, I hope I'm wrong but they have been promising improvements for a while and I'll believe it when I see it.
Also use Visual Studio on the Mac - that one I could agree is terrible - but hope it will improve over time.
Probably helps that I have used every version of VS since it was released - so like anything else, if you are used to it and use it every day for 20+ years you become biased - but for C# programming, imo, nothing even comes close.
Like Pretzold, I have a love hate relationship with IntelliSense. I think I can boil down my gripes with this: IntelliSense is wonderful for consuming APIs. It is an active hindrance for writing/designing APIs. It is great for telling you about what exists, but falls on its face when you're trying to write something new. If I am undoing the suggestions I didn't want, yet it insisted on placing, it is counterproductive. Personally, I get rather tired of slapping the escape key to cancel IntelliSense multiple times just so I can write out a dotted expression.
Hard disagree. VS makes code harder to navigate than any other popular IDE out there to the point where even vscode is more intuitive and capable, it's extremely slow at that too, and makes even the tiniest change to a build config something that requires jumping through a myriad arcane menus.
Having used other IDEs to develop Java, C# and C++ code, the only explanation I can find to explain Visual Studio's adoption, besides privileged access to Microsoft's emergent technologies and frameworks, is the boiling frogs analogy.
> If you are having to fight with VS, then you may not be using it for one of its main use cases.
I guess that writing software and building projects are not Visual Studio's main use cases, then.
I have very good experience about Jetbrain products so maybe I'll try their C++ product as well, but so far I heard it's not very good for large projects.
Eclipse is surely worse. Qt Creator and CLion/Rider are the only two I think are better . Xcode is terrible in comparison too.
Once Rider and dotnet core liberated my work from Windows, I don’t see myself going back to VS unless there’s some technical reason it’s use is required.
Then I get pissed off and go for a walk and wonder why the hell I ever invested so much time in this.
Resharper was always one of my favorite must have utilities to use for C# development in VS - but I have had the opposite experience as you, it became so slow and so bloated I had to give it up - often spiking my CPU to 100% and making the entire solution unusable - until I uninstalled it.
Never could figure out why, but maybe resharper has gotten better since then?
R# runs in-process and has its own project system, language service, UI elements, etc. That's simply a lot of stuff to do in the same process that also has the VS project system, language service(s), UI elements, etc. running. Both have added tons of features over the years, so over time it just slows down.
The R# team is working to run it out of process, but it's an enormous amount of work. I suspect that VS 2022 (64-bit) will help with this compared to previous versions though.
On this machine[1] Visual Studio 2022 flies :)
[1] - https://valid.x86.fr/nkby1v
If they had moved to 64-bit a decade ago when it was obvious that they needed to do so, they would have never developed this reputation for being unusably slow and kludgy.
The Chief Architect of Visual Studio mentioned on the VS 2022 launch event that they were planning to migrate it earlier, but according to telemetry data - just the past 2-3 years people started to use 64 bit operating systems et mass :)
Btw I would love to see percentage of programmers who have families and children broken down by:
1. Ones using IDE like Visual Studio, Eclipse, Rider, etc. 2. Ones using IDE-ish editors like VS Code, Sublime 3. Ones using vim/emacs
:)
This is what happens when you blindly trust telemetry when the target group of a product is the most likely to disable it because of company policy or personal preference.
Other than that, VS is great.
But, well... it certainly didn't help that they made it so difficult to adopt the new technologies. Project Reunion/WASDK makes it seems like they've learned that lesson and are trying to salvage what they can - but it's much too little and much too late.
And not to be too “fanboy” about it, .NET 6 is superb (for web dev at least).
I think it’s worth giving MS some credit for what they’ve achieved there. Like it or not, Azure is impressive.
But I agree with you with regards to the traditional Windows stack. It’s not in a good state at all. I rarely use Windows any more, at least where I can help it. And I’ve been an MS orientated developer (starting with VB/ASP) my whole career.
At this stage I’d be very happy to never touch Windows again unless they make a very sharp course correction in the next year or two!
(And to the point of the article, I’ve switched from a career-long use of Visual Studio on Windows to Rider on the Mac and I’ll hopefully never go back!)
The development process has changed a bit too, but like any other desktop or systems programming it’s mostly the same.
I like that.
Wow - so prescient
I'd answer yes but it is not just Visual Studio, it is the whole comfortable, automated, well integrated and productive environment of MS tools: VS, .Net, SQL Server, ASP .Net, C#, etc. But that can be said about all sorts of sophisticated, strongly integrated and powerful tools, not only Microsoft's. The whole XCode/Swift/Apple ecosystem is not very far off.
The good thing is that these tools will never be the ultimate answer. Computing environment changes and that moves people away from their comfort zones and forces them to try new environments.
> API Proliferation
While Windows has a huge API, the Unix/Linux-side is particularly huge as well. Win32 API includes a wide variety of cryptography for example, while modern Linux leverages a 3rd party open source program: OpenSSL or similar, to accomplish the same thing.
Another example: Windows Jet Red, which is roughly equivalent to Berkley DB (older style database focused on concurrency of access features / transactions, WITHOUT building up to a higher level SQL interface)
There's also obsolete / legacy technology. GDI is fully legacy these days (GDI is simply a layer on top of the "modern" DirectX framework, replaced by Direct2D). So all of those HBrush / Printing code is as unused as GTK 1.0 (or perhaps lower level XWindows code).
1. The Win32 team is very good at supporting legacy code. The API is monstrous, but it accomplishes its goal to a significant degree. Code written 30 years ago largely still works, you can't say the same about any other modern windowing API.
2. The technologies used in Win32 API cover a huge number of competing technologies. Not just OS-level stuff (files and IPC), but also cryptography, databases, threading and more. Furthermore: this API has remained consistent for decades (while Linux has had huge threading changes: the shift from Linux threads to NPTL threads for example).
3. Obsolete portions of the Win32 API hang around. Both the good and bad bits. Other OSes retire these supporting libraries (ex: GTK 1.0 or GTK 2.0, or KDE) more quickly.
> Avalon and XAML
Oh man. Petzold didn't even get the half of it since he couldn't see the future.
XAML's biggest issue is the lack of legacy support. Here he's talking about how Avalon/Longhorn (precursor to Vista, precursor to Silverlight, precursor to Win8) was being handled by programmers inside of Microsoft.
Maybe if Avalon stuck around for a while, it'd have been cool. But the amount of change that occurs over the next 17 years has made any bet on XAML a poison pill. Win-Vista gadgets are gone, fully obsolete and unsupported. If you moved your stuff to Silverlight, too bad, Silverlight is _also_ gone.
But don't worry, your Silverlight code got translated to Win8/Metro right? Or... was it UWP?
I think ultimately, the XAML has become much more beautiful and elegant. But these days, its an issue of "trust". Its a big and expensive hassle to rewrite your code into other frameworks, and Microsoft just didn't want to build XAML-stuff on top of anything steady.
It does seem like things have settled down upon UWP finally. Win10 / Win11 seems like its holding that API "steady". But Microsoft really shot itself in the foot too many times.
They officially cancelled UWP 2 months ago, after a few years of "not quite dead, not actively supported" limbo. I guess it's settled down, but not in a good way. https://www.theregister.com/2021/10/26/microsofts_uwp_unwant...
Looks like Microsoft screwed the pooch one more time for one more upgrade cycle. Why do they keep doing this? They really need to think about code compatibility for more than a couple of years.
Its not like Android or iOS developers need to deal with 3+ migrations over the past decade.
I can speak to the UWP -> WinUI 3 transition a little: it's a hard transition because UWP did so many things its own way. It's often really difficult to migrate concepts from UWP to the Win32 app model. And I get the impression that the number of people working on WinUI+WASDK is pretty small; it's more of a "salvage what we can" operation than a "build out the future of Windows app development" one.
I suppose the last feature is modern if you compare to a Tesla.
The twisted thing is that from what I have seen, the entire .Net development community is so compartmentalised that they think this is business as usual. Literally spending all day in pain with no idea there is a better life out there.
VS on reasonably small solutions (fewer than say 50 projects or 10k source files) is more than snappy enough these days.
It’s on those large solutions it runs like a dog when each GC collects 2-3gigs of garbage in 5 frozen seconds and runs every minute.
The one that kills me is the moment I hit . After an identifier I have to wait 30 seconds for it to work out what to do.
That’s just broken.
As always with Microsoft they need to actually go talk to the customers rather than collect telemetry.
I mostly resent having to use a text editor and msbuild because the tools are made of butter.
Our cutoffs were way smaller than 50 projects and 10K source files, though! (We had a lot of generated code, which we eventually mostly switched from generating code to generating MSIL directly to save the IDE.)
I would make changes in Webstorm, and then other devs couldn’t see my changes in VS because the proj file wasn’t updated. So then you _have_ to open VS to impose it’s junk on something that would normally be editor-agnostic
> That was a very traumatic experience for me, and since that time, I have been reticent about speaking before groups like this…
This is bizarre! It's hard for me to imagine an audience reacting this way to a talk. Maybe it's because I haven't been to any user group or developer group meetings. What does "went berserk" in a way that was traumatic for him mean? Did people start heckling him in the middle of his talk? Even harder to imagine!
Back then, chatty Apis like MFC made wizards and code generation almost a requirement for doing anything useful. Putting a window on screen required the equivalent of rendering with Vulkan today.
The problem wasn’t Visual Studio rotting the mind, it would have rotted under Win32+mfc anyway.
For comparison, a netcore6 command line app is now a one liner.
I'm honestly doubting you've done either because these are not remotely comparable. A "hello world" win32 program that draws a 2D image is easily at least one or two orders of magnitude less code than the vulkan equivalent. I've sold win32/mfc software that was only a few hundred lines.
I had a huge amount of insecurity about this until I tried AoC this year.
You know what's really great? Tools, power drills, printers, word processors, chainsaws, indoor toilets, heating. You know what's also great? Not trying to code in notepad with a paper reference manual.
There's a weird subculture of developers who get off on playing on hard mode and I can finally see there's no great secret in the suffering, it's just rubbish. Language servers, autocomplete, intellisense, inline documentation, time travel debugging, it's just better.
Sure if you enjoy the challenge of coding in Google Docs go for it. But if I want to get work done I'm going to use tools to assist me and I'm no longer going to feel lesser for being productive.
I met some real old people who used to print their code on paper for review. They made annotations, spent some time reading it like old people used to do with newspapers. They thought about it, sometimes discussed about it, you could see the code was carefully studied out by marks of coffee or cigarette ash.
I learned to program on 8-bit 80's home computers. I later turned to IDE's on PC's. I was impressed by the apparent gain in productivity. I then tried to use linux as old time unixers did. I was impressed that I could feel and sometimes even see what was happening. I saw some great and productive coders who used nothing else than a well configured programming text editor and a terminal. For me that was the most productive and advanced way to write code. I didn't change my mind even after using jetbrains IDE's.
I then became a teacher. I saw students who couldn't tell the difference between a programming language and an IDE. I heard people say java was much better than C and asked why; they explained how great eclipse was. I saw students who were not really writing code, they were writing some random code here and there and waiting the IDE to suggest corrections.
One day I said: "Today we'll write code, but we'll do it on pen and paper first and then we'll type it." After a few days, their skills clearly improved. Syntax errors were rare, off-by one errors mostly disappeared and they started thinking before writing.
I'm not against IDE's, but it is easy to get bad habits because of them. I don't think IDE's are a good replacement for a terminal with a good set of tools. They can improve productivity of good and experienced developers, but when used as a complement, not as a replacement.
It’s not the tools; it’s the carpenter.
To be fair, the language ecosystem may be why one language ends up more popular than another that is superior in both memory safety and performance on paper. Of course, these are beginner students who don't have the full context to understand that.
> "Today we'll write code, but we'll do it on pen and paper first and then we'll type it." After a few days, their skills clearly improved. Syntax errors were rare, off-by one errors mostly disappeared and they started thinking before writing.
How anal were you with semicolons, parenthesis matching, and quotation balance? I can't imagine that would be remotely enjoyable to grade. That said, writing down the high-level structure on paper (annotated with the occasional implementation detail I don't want to forget when it's typing time) is immensely helpful.
In something like an exam, I would completely ignore mistakes like these as mere typos. But it prevented students from trying to write loops by trial-and-error and really understand what they were doing.
My first program was written on punch cards, It took a shoe box full of them to complete trivial assignments. I was thankful when I got to use my first line editor, my first page editor, my first general editor and my first IDE.
I don't believe anything would be gained by going back to carving programs out of stone tablets.
Trial and error is good, but you have to understand what you are trying, and if it works, why. Writing out a program up front can encourage this.
Imagine someone knocking your shoebox off the table and having to sort them all by hand. Imagine that on your 3rd run, the reader eats one or more of your cards, then they all start to fail.
Programming was wonderous to be sure, but no one is worse off with an IDE and a interpreted language.
Just to be clear: I didn't say anyone is better without and IDE.
Your experience --- especially with teaching --- is basically exactly the same as mine. IDEs add a lot of distraction from the process of actually thinking about and "mentally executing" the code you're writing, which is an important skill to develop especially for someone who is learning.
"How can you tell the computer what to do, if you don't know how to do it yourself?"
Some previous discussion not that long ago:
2 years ago https://news.ycombinator.com/item?id=22258198
IntelliSense (plus refactoring suggestions) is perfectly happy for you to speculatively make a method call that doesn't exist and then to infer (and auto-implement) its definition based on the types of the parameters passed in the example call.
I find meet-in-the-middle works quite well, starting with a top down outline of what I'm trying to accomplish combined with implementations of the design-critical algorithms that I know I need at the bottom, and having all of that come together in the middle. I find that the bridge rarely fails to join up correctly in the middle of the lake.
At this point in the essay, we find ourselves arm-pit deep in get-off-my-lawn. He goes on to make the argument that a disjoint pile of event handlers attached to UI elements do not make a coherent program.
Even while conceding that this claim is 100% true, there most definitely exist cases where all you need is a hand-drawn UI with disjoint event handlers to breathe a little bit of life into the experience. Frankly, most simple web pages find themselves DELIGHTFULLY in this category.
Does Visual Studio Rot the Mind? (2005) - https://news.ycombinator.com/item?id=22258198 - Feb 2020 (118 comments)
Does Visual Studio rot the mind? - https://news.ycombinator.com/item?id=3386102 - Dec 2011 (2 comments)
Do modern IDEs make us dumber? - https://news.ycombinator.com/item?id=387495 - Dec 2008 (37 comments)
I guess if you're not doing cross-platform and staying within the ecosystem (MSBuild, NuGet, etc.), the project management is also nice.
Socrates: I heard, then, that at Naucratis, in Egypt, was one of the ancient gods of that country, the one whose sacred bird is called the ibis, and the name of the god himself was Theuth. He it was who invented numbers and arithmetic and geometry and astronomy, also draughts and dice, and, most important of all, letters.
Now the king of all Egypt at that time was the god Thamus, who lived in the great city of the upper region, which the Greeks call the Egyptian Thebes, and they call the god himself Ammon. To him came Theuth to show his inventions, saying that they ought to be imparted to the other Egyptians. But Thamus asked what use there was in each, and as Theuth enumerated their uses, expressed praise or blame, according as he approved or disapproved.
"The story goes that Thamus said many things to Theuth in praise or blame of the various arts, which it would take too long to repeat; but when they came to the letters, "This invention, O king," said Theuth, "will make the Egyptians wiser and will improve their memories; for it is an elixir of memory and wisdom that I have discovered." But Thamus replied, "Most ingenious Theuth, one man has the ability to beget arts, but the ability to judge of their usefulness or harmfulness to their users belongs to another; and now you, who are the father of letters, have been led by your affection to ascribe to them a power the opposite of that which they really possess.
"For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom, for they will read many things without instruction and will therefore seem to know many things, when they are for the most part ignorant and hard to get along with, since they are not wise, but only appear wise."
It's a train of thought that spans the arc of history: the New Thing, which allows young people to get by without developing deep skills in an area that was previously critical to success, is inherently bad because it enable laziness. In reality, it provides the leverage necessary to do things faster, or sometimes to do previously-unimaginable things.
I haven't tried it (I'm registered, no joy) but I'm skeptical of its utility, to me at least, because it replaces writing code with reviewing code to identify whether it does what it should and fixing it if it doesn't, and I find the latter vastly more time consuming and mentally taxing than the former.
It also helped me learn new features or ways to do certain actions. One such case was how it used immutable data structures to represent a change rather than mutating. Think `arr = [...arr, newElement]` rather than `arr.append(newElement)` which is not exactly the code I was writing but simply an example.
The positive comments I read from people who've tried it give examples of things it's done right, effort saved, things learned, but make no mention of the effort taken to verify what it produces. I don't know if that's because they're uncritically accepting what it produces (which would be bad), because it's only usefully producing trivial bits of code (which would put it in a race against how fast I can type, handicapped by whatever percentage of the time it gets it wrong and the time taken for me to check) or because I am somehow unusual in finding reading code much, much harder than writing it.
I'm getting pretty frustrated with the limited access. I signed up months ago. Just release it already.
At any rate, I was also initially somewhat skeptical but it is hard to overstate how effectively it predicts exactly the code I was about to write, or suggests the code I don't know I want. It is, for me at least, significantly faster in the languages I know well, and monumentally faster in the languages I don't know well.
I'm keen to try it out just as soon as they let me.
Therefore, if Plato didn't write Socrates' words they would be lost, as are the words of all the other illiterate Athenians from those times.
But can I controversially suggest that once we learned to write, we may've traded away some of our memory, but in order to gain an enhanced capacity for reflection and development of thought? Writing freed us from the burden of remembering as much so we could apply that energy to creativity instead. Likewise in programming, I'm happy to trade not being able to memorise and internalise a language's grammar if my IDE helps me accomplish the task more easily. I can focus on devising a solution rather than focus on nesting a parenthesis correctly. I appreciate there's a certain pride in doing these things without fault, but for the 95% of us who program to solve problems, the busywork can go.
This gives me an idea: somebody should make an inverse intellisense that lets you type as if a function exists that you haven’t created yet, and instead of using a bunch of red squigglies and making you feel like a fool for typing broken code, offers you a shortcut to create the code that doesn’t exist yet.
Bonus points if it uses the language’s type inference to inform what to create, like:
Would offer a quick way to make the stub: There’s probably tons of ways to make this super ergonomic too, maybe with an easy keyboard shortcut (maybe if ctrl+space triggers intellisense, ctrl+enter could trigger the “make stub” functionality) and could work quickly and with no fuss. The method just gets added in the background, you don’t even see it, you just get to keep typing out your train of thought.This could be extended to more than just methods, but whole classes/structs/etc.
I know IDE’s have lots of affordances for creating new code from templates/quick actions, but there would be something magical about being able to just type out your mental model at the current abstraction layer, all at once without distraction, and have the IDE better help you “make real” the code you just referenced.
The tweaking of allowing possible results in the dropdown is a very very interesting idea - imagine if you let copilot suggest possible methods based on the domain context of the current project.
I haven’t used VS in over 10 years - what does “at the class level” mean? Does it only create stubs for the current class, or any class that’s in the current project?
It is interesting that VS has this at all though, as a daily Xcode user I’m jealous. Especially because ObjC and Swift have first class (and popular) ways to add methods to classes you don’t own via extensions… the concept of adding new methods automatically as you type is even more attractive in this ecosystem.
https://www.jetbrains.com/help/resharper/Code_Generation__Ge...
It's been a hot minute since I used it, but it really is exceptional.
The Haskell Language Server allows this. On the other hand, its autocomplete doesn’t seem to work so well yet (at least on Emacs), so I guess it’s not really comparable.
17 years later checking in here.. humanity shows barely any reduced appetite here.
Every so often for my day to day job I need to work with some really old and crusty MFC-based UI code and while Visual Studio still technically supports MFC, in practice it seems to be basically unusable. I doubt anybody at Microsoft actually tests this functionality because much of the time it fails spectacularly for me - even the templates don’t even really work. So this means I need to struggle through manually messing around with impenetrable machine-generated code files and hope for the best through extensive trial and error.
In terms of code completion, the complaints in the article seem more focused on it being buggy, but there's also complaints about it dictating how code is written or feeling bad for using it (??). Code completion is a win. Automatic completion of names is a speed win. The ability to get essentially an locally relevant API reference is a win. Even the ability to write code by relying on code completion giving you correct suggestions is a win: it clearly lowers the barrier to writing functional code. The issues people have with the last one boil down to "people can get the job done without knowing how everything works".
A lot of the rest of it seems more griping about VS default behavior rather than the impact it has on the code being produced.
When push comes to shove, the real issue people have with many of these things is essentially that it lowers the bar to getting a program to "work". It lets "bad coders" succeed. Sure, such tools can result in bad code, but in the end the goal of anyone writing code in any form is to getting a task done, in which case "bad" code is better than no code.
Even better is that people who start off thinking that programming is some magical impossible skill may start with some basic tutorial + stack overflow + code-completion code, but in doing so and getting something to work they may do it again, and after a while develop their skill. Maybe they'll laugh at their old code, maybe they won't, but the important thing is that the tools doing some of the work made it possible for them to do the rest.
Another simple analogy is manual vs. automatic cars. Are automatic cars bad because learning to drive in an automatic means you don't know how to drive a manual? Some people argue yes, despite the abundant evidence that the existence of automatics made driving much more accessible. It also reduces the need for a driver to focus on anything other than driving, which is very clearly a good thing.
[edit: minor (?) tone issue]