Microsoft Visual Studio: Cluttering up developer disks for 25 years Microsoft is celebrating 25 years of Visual Studio, as devs take a moment to ponder whether another quarter of a century of Microsoft's flagship Integrated Development Environment is in the cards. Visual Studio was first unleashed in 1997 and marked the first time Microsoft bundled so many of its development tools in one place …
I wrote (due to a fskd up laptop... mainboard likely developed hairline fractures, as no amount of component swapping fixed it) quite a large LaTeX manuscript using eclipse on Windows. At that time it was snappy enough and let me avoid the mess that MikTeX is. Using LaTeX on Linux is way simpler...
I was really impressed how well Eclipse implemented both TeX and R! It got bloated quickly, and plugins ceased working. Fortunately by then I could afford to buy a new laptop....
I tried IntelliJ CLion and Eclipse, only Eclipse could do remote Makefile projects properly (if you were patient). This was when I last looked at it about a year and a half-two years ago, maybe someone can tell me IntelliJ have improved things since then.
As it was a new feature in CLion I was expecting it to be all streamlined an straightforward but they did CMake first and Makefile is obviously second-class and added later, and it was even more obtuse to configure a remote Makefile project in CLion than in Eclipse, or maybe Eclipse has messed with my head too much.
Having to run this in an offline environment while keeping it patched is a nightmare due to all the bloat in the packages. A couple of months in a row, offline patching will work fine, and then things will just blow up in your face necessitating a complete removal and install (MS offline documentation for this is abysmal!). Online systems it seems to work fine on, offline however, I absolutely hate this application.
Why would you want to do that? In the full install is:
C++ and libraries for 4 architectures for multiple builds.
Java
Python
R
Node.JS
.Net Framework versions going back to 3.5
4 different .Net Core version.
Android
Unreal
4xWindows 10 SDK
1x Windows 11 SDK
C++ build tools for Linux
Language Packs for 14 languages
Unless you are truly multi platformed then you are just hoarding stuff you don't need.
"...but with 2002's Visual Basic .NET, Microsoft ditched backwards compatibility and offered only an iffy conversion tool that rarely resulted in fully compatible source."
I thought it was my lack of programming skills that caused the failures to convert. This is good to know.
Of course, I'm still a lousy programmer, its just good to know that wasn't the (only) reason for my problems bringing a VB6 program into VB.net.
Visual Basic.NET isn't even really Visual Basic, it's just a language parser for the .NET framework. As such you basically have to port your applications from Visual Basic to Visual Basic.NET. On top of that it doesn't support many of the cool new wiz-bang features of .NET. This is why almost everyone writing .NET is using C#.
Not only that, they were going to discontinue Visual Basic with the .NET Core rewrite. They eventually changed their mind but it's more of a side project than anything else and I wouldn't want important code written in a language that is a Microsoft side project.
Visual Basic was also comprehensivelyruinedoverhauled with Visual Basic .NET.
Nicely done, but there are those who would argue (convincingly) that Visual Basic was ruined from its inception.
Where Visual Studio has become somewhat bloated with age, Visual Studio Code, now approaching the seventh anniversary of its release, remains lightweight enough to run comfortably within a browser.
The damn thing is an Electron abomination app, and I, for one, have never seen 'Electron' properly conflated with 'lightweight' or 'un-bloated'. (YMMV, of course...but probably not much.)
100 percent. Another article on here said that VS code was "closer to the metal" because it requires you to directly edit settings files instead of having a proper UI.
Yes, that's right, the electron program is closer to the metal than the C++ program because it doesn't have a GUI. Somebody doesn't know what "closer to the metal" means.
I like Visual Studio. It has lots of exciting tools that I use to actually get work done, and has organized the myriad of configuration options in a way that at least starts to be approachable.
It's based on Chrome/Electron, its as bloated as hell, consuming all your system resources. Chrome/Electron is basically an OS in a web browsers and its a fucking disaster for application efficiency in the modern world.
Nothing runs in less than half a gig with the fucking thing.
Yes it matters. Shuttling half a gig between storage and RAM hammers responsiveness, also the half-gig is unlikely to stay at half a gig - memory leaks and poor management mean that'll likely be upwards of 1.5GB by the time you've finished a session. You've also got to ask what the living hell are they coding that could consume 512MB of space, unless it's horribly inefficient. Which brings its own performance issues.
Plus; with the exception of a few top-shelf Androids there aren't many phones that come with 16GB RAM (because they need it to stay afloat - Asus Zenfone 8 I'm looking at you); even the iPhone 13 Pro Max 'only' has 6GB.
Bloat hurts cache utilization, too. It's not just RAM footprint that matters.
Personally, I loathe all the modern IDEs I've used. None come close to the power of bash. Sure, it doesn't do much for software development by itself; but I can plug in my choice of editor, debugger, build system, etc., and indeed use a variety of them in the same session. And I have all sorts of tools to eliminate repetitive tasks.
Why should combining all of your toolchain into a monolithic application be a good idea?
Why should combining all of your toolchain into a monolithic application be a good idea?
Not having to alt-tab a thousand times a day?
Being able to double click on a compiler error and jump directly to the character that caused it?
Being able to edit code, compile, and continue execution in the same debug session?
Being able to navigate code while still viewing the current debug context?
Being able to debug multiple executables from a single "solution" concurrently and jump between breakpoints in all of them as they communicate?
When >90% of the application's size and RAM usage comes from running a packed version of chrome, yes, it matters.
If you still think that's not a problem, let me write a 10GB program that eats 14GB of RAM that just tells you the current time. I mean, it's not like you're using all those 16GB of phone RAM for anything else, right? Efficient resource usage? Pah! If it's there, we're supposed to use ALL of it!
What VB did very well is to show that certain kinds of small and medium sized apps could be built without recourse to C and complex SDKs. Was it the first? No - there was SQL/Windows, there was Actor, and probably others. Was it the world's cleanest or neatest programming language? Lord, no. After a year or so, Turbo Pascal for Windows knocked it out of the park in so many ways. Was it particularly fast? Nah. Was it the kind of tool that amateurs could write terrible code? Yes. I don't wear rose-tinted glasses when I think about it. "Option Explicit" came too late to stop people making awful errors. People often didn't understand how Variant worked. There was the bizarre DOS-only mutant. Team programming was hard. It never really got to grips with O-O programming until VB.NET forced a complete overhaul. Having two different versions for VB4 (16 and 32 bit) was a pain. "On Error Resume Next" was the dumbest idea ever. I don't think VB6 had a true compiler (feel free to correct me). By all means, list the unfixed quirks and bugs. I never got to grips with data binding. No, I don't want purple and yellow buttons, oh my eyes!
But it opened the market very convincingly. It was just-good-enough, and sometimes that is what counts. You could paint a screen, write the event handlers, and get things done. It had enough extension capability (calling C DLLs, and the VBX/OCX development model) to support a decent third-party tool market. In the city of extreme visual impairment, the monocular one reigns.
Visual Studio 6 was a great product, other than the fact that MSVC at the time (and for quite a while after) was a somewhat limited compiler. It was fine for standard C stuff, but then I created a mail server which used the STL which MS' compiler couldn't handle. Intel's compiler needed to be used via a plug in. However some of MS' code was specific to their compiler, so some had to be compiled with MSVC, and some with Intel.
It then bloated out a bit before MS were daft enough to release Visual Studio Express 2010, which was free for everyone, including professional use. They worked out that was a bad idea with their more recent licensing scheme, which doesn't affect home or quite small office use, but does if your number of employees starts to grow.
VS Code is a bit fragile with some of the plugins, particularly for git under Linux, but it has a decent number of addons to handle syntax highlighting, editing, and good enough vim emulation.
Visual C++ 6 was the start of modern code bloat. In Visual C++ 5, it was still possible to build truly tiny executables. I managed to create a window, initialise directx, and sit clearing the screen until you hit the escape key in an executable of just 720 (ish - it's been a while) bytes. And 500-something bytes of that was the PE header. VS6 couldn't come anywhere close. I don't know what they changed in that particular version, but it's been downhill ever since.
"VS Code is a bit fragile with some of the plugins, particularly for git under Linux, but it has a decent number of addons to handle syntax highlighting, editing, and good enough vim emulation."
You know what else has decent syntax highlighting, editing, and a pretty good vim emulation?
Vim.
For a while now I've only installed VS on sacrificial machines or virtual machines. The damage it does to a regular installation of Windows is too much and is unfixable without wiping the OS and starting again from scratch. Running in VMs also allows me to have different versions of VS without one of them trashing another.
The way to run multiple versions of VS is to install them in release order. same seems to apply to MSSQL.
I normally have 2 versions of VS on my works machine our maintenance team can have up to 4.
BTW here's a tip which which I found useful to avoid a fair bit of maintenance work. As a developer when you get a new PC just install the latest version of VS and MSSQL you are developing for. Because when a bug comes up from a a few years back you can say "sorry can't work on that as it requires VS or MSSQL version x and I am running version y and I can't run version x without first uninstalling version y. ;)
Those were the days when a couple of Borland programmers could mop the floor with an army of visual studio guys. Today it's all the web stuff getting the glory these days, but those web guys will likely spend eternity in hell for all the broken mess that the web is. Somebody somewhere is surely writing himself a minivan or two.
While I do use it myself when I'm working on Linux, VSCode is a steaming pile of garbage compared to real Visual Studio. While dealing with its monumentally awful UI and in between being continuously gobsmacked at how poorly it does pretty much everything, I am constantly amazed that a) it's so popular, and b) it is still the best thing I've used on Linux for development.
I use it because I haven't had time to port a decent theme to another editor and judging by the fact that the themes extensions websites are the most popular results when looking for extensions I'd hazard a guess that this is the reason for popularity.
In use I've had no end of problems with syntax highlighting getting stuck, spent hours switching off Intellisense junk and auto-completes and dealing with numerous updates that often seem to reset most of my custom configuration. The settings in VSCode are a joke, completely illogical naming schemes, equally bad descriptions, weird side effects and most get lost in the ocean of extensions available.
The best thing I've used on Linux for development is Geany, Kate, Micro and whichever appropriate command line tools. When I've got time I'll customise a color theme for Geany, but so far VSCode is the only editor with ready to go themes that my eyes agree with.
If you're going paid JetBrains is very nice on Linux.
I could never get into any of the bloated visual IDE crap. Perhaps that's from getting tennis elbow from using smalltalk back in the days I guess. All that space wasted for boxes filled with this and that and the need to click-click-click on a mouse.
Emacs still works like a charm for development and is clocking in at about 50MB of RAM on my Mac. 45MB of that is likely for the framework stuff being dragged in. And if you must use vi, there is vim mode. And yes, I use it on Windows for those rare occasions I actually spin up a Windows box.
I could never get into any of the "not being able to hover over the name of any variable and see its current value while paused during debugging" crap.
Or the "not having a single interface that shows me the call stack of all running threads, and allows me to jump to the code for any point in that call stack with one click" crap.
Or the "not having an intelligent renaming tool that actually does semantic analysis to see which instances it should rename instead of just doing text substitution against the whole file" crap.
Or the "only telling me that an #include cannot be found when I compile, instead of immediately when I write 'strign' instead of 'string' " crap.
I taught myself C++ by writing a networked program between an SGI Indy and Windows. Most of the time I wrote the IRIX code on the Indy using Nedit and the Windows code in VS. I learned a lot of stuff about build systems and translation units and stuff from the Indy, but I got considerably more actual work done (and learned more about C++ itself) on the Windows side.
I'd rather have a program that consumes a bit too much memory and does what I want than a program that does almost nothing very efficiently. I've got 32GB, I can live with it.
PS: VS code doesn't get a pass...it manages to do less AND be inefficient under the hood!
VS6 was nice for writing C, and occasionally the ++ variant. What it didn't do, at all, was Visual Basic.
VB6 came on the same installation media, but was a completely separate standalone product, which even put a different folder in the start menu. As did "visual" FoxPro 6.
I'm still using VB6 and, less often, VFP6, for legacy work. VS6, not so much.
-A.
"yes, this writer has been baffled as Visual Studio versions from the past opted to have issues on a 16GB rig when that magic 4GB barrier was breached."
Wow, that is some serious bloat !
I'm using VS latest for just Azure training, with a couple of dozens lines of code, really nothing serious. But yeah, it looks quite bloated even for this.
BTW, I just discovered the MS Azure shell console provides emacs. Yes, you read this correctly, emacs. I'll have to learn again all the basics, it was too long ago, for me, emacs.
I do a lot of Python, and lighter stuff, so VS Code suits me fine for that,
The behemoth that is full-fat Visual studio is complete overkill in that use case IMO
On the other hand, if I'm fully in the MS ecosystem, doing .NET stuff, then there probably is an argument for full-fat first.
YMMV.
I used to have a Systems Manager who spent as much time upgrading stuff and attending the associated training courses as he could manage. This article has reminded me of those lovely days when I was allowed to upgrade things like Visual Studio and other apps on my system I needed for work, that had to be updated because the main systems had been updated to provide 'new' facilities I'd done in code ages ago. ISTR you could get nearly a weeks rest while slamming CDs into the machine if you could slow the system down with some surreptitious gaming!
Maybe I'm too far out of the Microsoft Certified (certifiable?!) loop to get MS dev environments these days. VS, plus some fairly obvious options and APIs - multiple gigs before you even begin But programming long since ceased about interfacing with hardware and instead become about interfacing APIs for majority of cases, which is the reason for bloat.
It's also my biggest bugbear to "staying current". Learning syntax and methods? Eminently do-able. Staying on top of endless API revisions is the real difficulty. So much so that the only practical way I've found to keep dev environments "stable" is to keep them inside a VM where one has an element of control and reversion. I know I'm not the only outfit employing development VM's this way.
It's enough to put anyone off actually learning how to do stuff. And god help the next generation who won't be exposed to low level stuff; so who will maintain that in future?
There is a reason why I keep a C64 of course. You know, when programming was (and still is) fun.
"Where Visual Studio has become somewhat bloated with age, Visual Studio Code, now approaching the seventh anniversary of its release, remains lightweight enough to run comfortably within a browser."
VS Code is far too bloated and complicated to do simple editing, and far too simplistic and complicated (how many add-ons do I need to do *that*?) to do anything serious. I really don't understand why I don't remove it. Maybe I just like to be fashionable.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
