Does Visual Studio rot the mind? (2005)
charlespetzold.com
charlespetzold.com
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.
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?"
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.
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 :)
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.
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'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.
> 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!
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)
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.
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);
// (class of foo)
String bar(int someInt) {
// TODO
}
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.
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.
Wow - so prescient
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.)
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]
Some previous discussion not that long ago:
2 years ago https://news.ycombinator.com/item?id=22258198
17 years later checking in here.. humanity shows barely any reduced appetite here.
I guess if you're not doing cross-platform and staying within the ecosystem (MSBuild, NuGet, etc.), the project management is also nice.
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
> 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.
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.
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.