What next for Visual Studio? Microsoft's monster IDE can't please everyone and 64-bit will not solve legacy problems Microsoft has announced 64-bit Visual Studio, but in its rush towards modern development some developers using older Windows or Azure technology are feeling left behind. The forthcoming release of 64-bit Visual Studio 2022 (VS 2022) is huge news for devs who have been requesting this for over a decade. But the company still …
Why does this need to be a problem? Who said that it is desirable to have one IDE to rule them all? I've used both VS and VS Code, each for different purposes.
Yes, it would be nice to have an IDE that has all the features of VS but at the same is as fast as Code, and so wonderfully designed that the gazillion of features don't feel like bloat. And I understand that's really difficult to do in practice.
But, frankly, I can just use Code for some stuff, VS for some other, and be happy that way.
I just want something that's easy to use, does NOT look "all 2D FLATTY FLATSO", doesn't require excessive "mousie clickie" operations that mean removing my fingers from home row a BOZILLIAN TIMES to get ANYTHING done, and so on.
I also don't want something written in JAVA SCRIPT. Kludgy bad performance and bloatware NodeJS to run it... ew. Just because "you can do it in javaScript" does NOT mean you should actually TRY it. I could write it in BF myself, given enough time. I doubt that would be easy to maintain [but if written by ME, it would be efficient and functional].
I really liked DevStudio 97. I had to run it for a long time to maintain a 16-bit application written in the 90's. The dialog editor was SO MUCH BETTER than ANYTHING that I've seen since then, especially because THE HOT KEYS WERE EASY TO USE. Translation: you could keep your fingers on the keyboard THE ENTIRE TIME you edited a dialog box, even when moving controls around - that's right, you could use the tab and arrow keys to do that.
Mousie/Clickie is ALSO imprecise. Too easy to be "off by one pixel" or struggle with the size grabber or the move grabber. PRODUCTIVITY DEMANDS THE WAY IT USED TO BE!!!
So while Micros~1 is off doing their own thing with "new shiny and now, 64 bit!", the basic "usability" features of the IDE (probably) still stink. It's a fair bet, yeah.
And I do _NOT_ want "crazy new flavor of the week" to be the core of any new application I write. How about C++ with MFC for windows applications? And not a BLOATED MFC either, but an MFC that is tight, tiny, and efficient, and does NOT require hauling shared components around to use it.
(I normallty static link which fixes some of this, but MFC used to compile to EXEs that were about 120kb in size, not 500kb or larger, with NO clear benefit to the extra bloat. Bandwidth costs money, you know)
The thing is, you've got the OLDER VERSION, which was simpler and PROBABLY more efficient on CPU and resources. A typist could keep his fingers on the keyboard the ENTIRE TIME. THAT is PRODUCTIVITY. And it had the much nicer 3D Skeuomorphic look to it. And it used simple "Makefile" builds at the core (ok using nmake but still).
SO, HOW ABOUT THE SAME *KIND* OF THING FOR LINUX ??? I'd _LOVE_ to have Visual Studio '97 for Linux, especially if it integrated with the autotools AND github support.
But no bloat, please.
I remember the days when desktop application stuff run perfectly fine on a 286, obviously processor power have increase a bucket load, its a crying shame software is going in the opposite direction, more bloaty, more pointless crap, brainfarts abound
I just get the impression that software houses are selling license agreements, and not quality engineering
These cunts are so confident in their product its wrapped in legalese and clauses
I just want something that's easy to use, does NOT look "all 2D FLATTY FLATSO", doesn't require excessive "mousie clickie" operations that mean removing my fingers from home row a BOZILLIAN TIMES to get ANYTHING done, and so on.
I use an IDE that incorporates my preferred editor, build toolchain, debugger, and other tools as first-class components. It's called "bash". On Windows, I run it under Cygwin (because I'd been doing that long before WSU morphed into WSL). Lightweight, fast, extremely scriptable, no stupid eye candy, no mysterious black boxes to get in the way of doing work.
I've never yet seen an IDE with the power and transparency of the shell and a set of dedicated-purpose tools.
Maybe I'm odd, but I use a separate tool for interacting with git and so any pulls, commits, pushes etc. are done using that (usually in GUI, but occasionally in command prompt for some more obscure gittery) but do nothing git related in VS. Use VS to write, build & debug code. Don't need it to be a git tool.
In same way that if I need to add some images to a project I will use a dedicated graphics editor not inbuilt VS basic image editing tools
Because GitHub Desktop (last time I checked which was over 18 months ago) was so damn basic that you can't set a second remote. Therefore you can't keep a fork up to date with upstream. So unless you just work on projects you maintain, and never contribute to others, it is just dead weight.
Personally I also never use Git features in my IDE, unless you count the fact that my terminal is in my IDE, and from that I run Git.
This, precisely.
VS now does far too much, too slowly and is frequently broken as a result of poor integration of its myriad parts. It needs to be decomposed by design rather than simply decomposing of its own accord.
And 64 bits? The IBM 1130 FORTRAN compiler ran in 8K (2^13) bytes and whereas VS is still significantly more productive as a development tool, I can't believe it's up to 2^51 times better.
VS git is really bad:
It is usable if you keep stuff simple but prefer VS Code.
Having said that I don't find git to be particularly intuitive outside of push/pull on clean, single-branch, fully synched repos.
Visual Studio used to be by far and away the best IDE out there. But since Visual C++ 6 it ever so slowly gone down hill.
These days it's an incredibly slow monster. They have tried to make mends in the latest version but its still incredibly slow. The trends point to Visual Studio code / electron which is just more bloat.
While they also have various slowness and memory bloat problems with large projects, the Jetbrains tools are all in all far better and more usable and of course just work out of the box on Linux.
Microsoft would do well to strip the beast down.
Instead of one nightly IDE that does everything, perhaps having specialist version of it for key languages would be a good plan.
When you install VS you can choose what you want in it - there's no need to install everything you'll never need. So I frequently go back in and remove bits in-between projects.
It does seem to use load-on-demand for some tools but giving you the option of profiles with more fine-grained control for when you just need particular tools/languages would be nice.
I can honestly see .net 6 or 7 (VS2024 or 2026) being the version where windows dev options become a complete install or explicit opt in option when installing (much like windbg used to be part of a default install), cant remember the last time i did anything that exclusively targeted windows
If they allow WASM then yes.
But even if restricted to true js, you can minify it. Which reduces the information content to about that you'd get out of a good disassembler.
Websites all over the world allow users to poke at the source and a lot of apps have significant chunks of easily accessible js and the sky hasn't fallen in. A few idiots will rip you off. But that was always the case. And they lose access to new features and support.
"huge news for devs who have been requesting this for over a decade"
Genuinely surprised by this. If your *IDE* needs more than 2GB, you're doing it wrong. This is basically an editor/debugger with the ability to launch other programs like compilers. MS themselves long ago created a component framework to let multiple processes contribute to a single UI, so there is precisely zero technical reason to extend to 64-bits. I can see that there is equally no reason to stay at 32-bits, so I am not *surprised* if MS have had a rolling program of quietly porting components over and they have now finished that, so the fully 64-bit product can be released. But it is not huge news.
The huge news in development environments (and I'm pleased to note that it is mentioned in the Fine Article) is that VScode, which at least started life as a "stripped down, but runs almost anywhere" version of the VS editor, is arguably now as important as its ancestor. There's a lesson there for people who think that the next version of a product always has to have more gold-plated kitchen sinks than a previous version.
https://answers.microsoft.com/en-us/windows/forum/windows_10-windows_store-winpc/windows-10-installs-games-without-permission/35eff95a-f030-4642-ab5b-657aff8ec4dd
https://www.engadget.com/windows-10-installing-forced-office-web-apps-154530942.html
https://www.xda-developers.com/microsoft-installing-office-web-apps-windows-10-without-permission/
https://www.easeus.com/computer-instruction/stop-windows-10-installing-apps.html
...
I've read Raymond Chen's The Old New Thing blog for years and years - he's clearly someone who knows a lot about Windows, and way more than I knew even when I knew a lot about Windows, and has written many great and informative articles.
But his recent articles on C++ co-routines, whilst being as pithy as ever, just seems pointless; like writing about a new algorithm for optimal deckchair placement whilst everyone else is sitting in the lifeboats waiting to get the hell away from the sinking ship. Once, everyone who developed for Windows would use this stuff; now, everyone who isn't pure server side is pasting teh codez from stack overflow and reinventing yet another menu framework that requires pixel level selection accuracy or yet another web/app/io framework that is written in the scripting language du jour and runs slowly and buggily in it too. I mean, Python asyncio - one of the more recent new greatest things - apart form having an implementation so ugly even its mother would keep the lights off - is using exactly the same event model as Windows/386 used.
Software development is getting deeply dull; a vanishingly small audience write, need, use or understand the clever stuff, and for the rest - the ones who haven't much of a clue: well, web "development", Apple watches with dirty straps, beards and beard oil seems to be the future.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
