MS lost the plot when they killed Visual Basic with .NET
Microsoft has further clarified its plans for the Universal Windows Platform, a desktop application framework which at the launch of Windows 10 was said to be the future but now looks headed for oblivion. Principal program manager lead Thomas Fennel has posted on GitHub about the choices facing developers invested in UWP …
.Net 4.0 was released in 2010. Since then, every version of .Net framework has been backwards compatible with it.
4.0 wasn't backwards compatible with 3.5 because of breaking changes to the libraries, hence the major version number change. Code written in 3.5 is overwhelmingly likely to compile just fine against the latest framework version, because the languages that compile to the .Net IL (C#, F#, and VB.Net) don't contain breaking changes between versions.
The later .Net Core is a different framework again, because this is designed to be cross-platform (There are already cross-platform compilers and runtimes for .Net Framework, minus the Windows-specific stuff, but Core is designed to be cross-platform from the bottom up).
There is also ".Net standard" which I believe contains the core shared stuff between Framework and Core, and the upcoming .Net 5 which, I believe is supposed to bring Framework and Core together.
Microsoft have only done what a sensible business would do - try to predict what the future is going to bring, plan for it, and have the balls to stand up and say, "we're deprecating this" when it becomes apparent that something isn't working out.
Meanwhile, you're bigging up a tech stack built on Windows 9x which is totally unsuited to modern programming challenges. I'd like to see the pain you'd have to go through trying to deploy that in a Kubernetes container, or in anything remotely resembling a growing online business. It's like someone living in the world of streaming music touting the benefits of the wax cylinder.
"modern programming challenges."
And that's different than previous programming challenges exactly how? Are For loops now tighter? Do sorts now start in the middle and work outwards? Are pixels different colors these days? No, it's the same programming challenges as always, but you "modern" guys have agreed to enslave yourselfs to the incredible layers of cruft that Microsoft has built around their various Windows APIs over the years. The OP was just lamenting the fact that 20 years ago, those layers of cruft were much thinner and more manageable.
And that's different than previous programming challenges exactly how?
Well, let's start with the fact that VB6 comes from an era when "security" meant locking the case of the beige box, in the computer room, so nobody could steal the sticks of RAM? Yes, it’s still loops and conditions under the hood, but the tech stacks and environment are vastly different.
If you're talking about "thinner layers of cruft", I don't see anyone writing embedded code in VB. It's C/C++, or Python if you want the toy language. VB never was, and never will be, a serious language, for serious use. You know the "B" stands for "Beginner's", right?
As for referring to me as "modern", well, I've been crafting code, in one form or another, since the mid '80s. I learned to code using BASIC. As a child.
There was NOTHING stopping the VB 6 guys in the 90's from doing proper validation on network inputs, they just didn't know (or think) to do it. But the "programming challenge" was still there, it was just unrecognized. Input sanitization isn't some new thing that MS thought up with .NET 4.5.
Thinner layers of cruft meaning the "mindspace" needed to understand the environment was much smaller. VB 6 wasn't too hard to learn, even if you decided to throw in a large amount of Windows API calls. It was relatively easily digestible in its scope. Same goes for Delphi, maybe even C++ using bare-knuckles API. But then MS started adding cruft with the various .NET environments, and then added even more cruft with things like WPF and UWP. Suddenly it's not just drawing rectangles on the screen anymore, it's a whole lot of other stuff going on around it to draw the rectangle on the screen. But, in the end, it's still just drawing a rectangle on the screen, pretty much the same as since VB 3.0. Same "programming challenge", just a lot more cruft getting in the way.
The fact that it took you 4 decent-length paragraphs to explain the .NET versions actually highlights the issue pretty well.
I can explain the history of other extant programming frameworks over the same amount of time in comparable numbers of paragraphs. Java perhaps? That has had a bit of a torturous history. Python maybe? How about the various Android environments and ATKs? My point is that .NET is nothing special in this regard. It is in the nature of something that is under current development, and is moving with the times, to change.
The ongoing history of VB, on the other hand, can be summed up with one word; "dead".
Meanwhile, you're bigging up a tech stack built on Windows 9x which is totally unsuited to modern programming challenges
(I don't know whether to laugh or facepalm)
that word "modern" - I do not think it means what you think it means
And as for wax cylinders, believe it or not, audio recording on a wax cylinder (with current tech, and slightly better materials) is likely to sound VERY good, as it is on high quality vinyl. Some people prefer the sound of vinyl recordings. They also like tube/valve amplifiers better. Just because it is old does not make it obsolete.
Microsoft have only done what a sensible business would do - try to predict what the future is going to bring
How's that working out for them, since the early noughties when Ballmer took over and introduced the ".Not" initiative ... ?
(they need to FIRE their astrologers and crystal gazers)
I cannot shout this loud enough: WIN32 and 3D SKEUOMORPHIC!!
If Micros~1 gets THAT right, we'll all be better off for it. But they won't. They're too busy trying to find the right lipstick to put on the non-oinky-end of the boar, i.e. TIFKAM and UWP and that eldritch abomination, ".Not".
In the old days, you could fix up your unix code and recompile it for a different unix, and that's what unix mavens meant by 'portable'.
.NET went the same way. No, you can't just take the program and run it on a different platform: you can take the source code, modify it, and recompile it for the other platform.
Good enough for unix in the 20th century, but not compatible with the Windows model expected by users and developers (cf SFU).
You do know that "Cross platform" means the same thing for .NET, right? The tech stack to compile on of all those different flavours of Unix / Linux?
Nobody should realistically expect OS specific features to cross-compile, so stuff that is designed to use specific Windows features isn't going to magically work on ANOtherOs.
"It's just Microsoft can't make a plan and stick to it."
To their credit, they do stop flogging a dead horse eventually.
But how do they manage to get it so wrong, so often ? And waste their and so many developer's efforts trying to keep it wrong before they give up ?
I'm so glad I don't develop for Windows.
"But how do they manage to get it so wrong, so often ?"
A frequent suggestion is that they hear only an echo chamber - the echo being of their own unsubstantiated belief about where the future market is going.
IMHO it's also based on panic, ever since they failed to spot the nascent WWW and almost got fucked over.
If I dare jump in; Microsoft aren't doing that bad a job in my opinion.
Google also can't make a plan and stick to it, but in that case the users pay as whatever Google is abandoning simply ceases to be. Microsoft's discarded frameworks at least continue to function.
Apple can make a plan and stick to it, but that plan usually involves a large amount of technology churn and the assumption that developers will keep up. As a developer you at least never get stranded by a complete horse change, but as a user you can still expect unmaintained applications to expire.
I primarily develop applications with Delphi Object Pascal (always on the latest version) and to this day I've been able to consistently deliver reliable applications for Windows (and other platforms too from the same code base).
It have saved me a ton of work not having to deal with the indecisiveness Microsoft frequently pull developers in the .NET space through.
Once again, sticking with the "Win32" APIs guarantees you reliability.
Well, in general, I agree with you. But writing to the original C Win32 API is an immense hemorrhoid. And then there is the cross-platform angle, which is not insignificant.
From the article:
Well, in general, I agree with you. But writing to the original C Win32 API is an immense hemorrhoid
I'm glad someone's mentioned that, with all the talk of Win32 that's going on here people might start to think it's a good API. It's not, it's just prevelent.
Just to be clear youngsters, no matter what anyone tells you, Win32 is an awful awful awful API.
(I mean why have one function to do a thing when you can have all the fun of getting whatever handle and security descriptor you need to call the function that returns you a handle to the thing you need to call the method to transform it into a handle you need to generate a handle to to pass to the API routine you want to do a thing.
That routine returns an HWND.)
"...writing to the original C Win32 API is an immense hemorrhoid..."
You'd only think that if you're young enough never to have written for 16 bit windows - segmented architecture and all. But in all seriousness there are some odd decisions which were of their time or grew out of what had come before. In that way, in resembles x86. But it's the tortoise that's outlived the hares.
A native C/C++ cross platform desktop app was a nightmare and was pretty much killed by Apple dropping Carbon. But they are fundamentally hard because you end up with conflicting conceptual models about how things should be done. That platforms cannot even agree on a common language underlines the problem. (Yes, you can call Objective C by hand from C, but... Oh, and now you need Java for the mobile version.) We went for separate apps with as much stuffed in a common library as possible which meant we could just write a new Objective-C front end.
In some ways, MS never actually got the plot. Just take the Windows file selector for example. Open it and it shows an unordered heap of file names in multiple columns. You have to do two clicks to get a list with details that you can sort. And even then, there's no guarantee that the columns are wide enough for their contents, so you may have to drag the boundaries of some of them to see things like file creation dates. it would have been so easy to set the defaults to something more convenient, or allow the user to set their own preferred defaults, but you can't. Then of course, there's the infamous hidden file extension default.
allow the user to
IMAO Microsoft has been determinedly doing its absolute best to prevent the users from doing anything that makes using their software easy for users to make work for them ever since the infernal "Ribbon".
Each iteration of software removes options from the users to make things easier to use.
Once we could easily customise the Start menu, grouping programmes according to function, rather than (often unrecognisable) name. In Win 10 it needs a fair bit of tech skill to do so- and there are bits (like "Store Apps" ) that are treated differently and can't be moved out of the stupid alphabetic list. In Win 11 they apparently have prevented it totally. So teh Start Menu will be a mess of programme names in alphabetical order, with all/any other crap the software publisher wants to add.
Everywhere you look Microsoft have made perfectly sensible customisations difficult or impossible. Not to simplify how we use the tech or to reduce support issues- there are better ways than that - a simple "Restore defaults" button if people messed up their Office menus, rather than making modifying them a massively difficult job.
A simple, trivial illustration, the Windows start up sound. Once it could easily be changed. Now it can't (without a 3rd party tool -Winaero will do it). There can't be any great technical justification for that. It has to be pure stubbornness.
I never thought I'd find myself agreeing with you BB. But yes, MS has had a strange belief that they should be defining users' work flow and methods for at least as long as they've had the dreaded Ribbon. Probably longer. As if they know the secret for how every office wallah should be doing their jobs. It's why I harp on about the Ribbon so much. Pre-Ribbon I used to create specialised menus for my staff. I didn't want them, highly professional, expensively trained, incredibly experienced and skilled in their actual (front line) jobs and with specific uses and skills for the computer, spending times hunting for functions they needed among crap they wouldn't use before the heat death of the universe. They weren't computer people. Some had had to be dragged kicking and screaming in front of a screen. (Took 10 years to get one away from his little Brother typewriter). Particularly since the way we would group items wasn't the same as how MS seemed to think they should be grouped. The WORD Edit menu for example lacked certain items that we'd consider useful for working on our analysis reports*, so I put them in there and moved some other stuff to where it could be found if needed. Ribbon meant this was no longer a trivial activity, but became a major task, and I had my own front line work to get through.
*It's a long time since I retired- but I think one thing I did was to put some Table commands in the Edit menu. Something they'd need to include in a report would often be a simple table of observations or test scores they'd obtained and which had been used to support a conclusion. " Insert Table " would have made sense to us in the edit menu.
"(Took 10 years to get one away from his little Brother typewriter)."
At the previous gig (a University), one of the eldest English Profs was still using WordPerfect daily until he retired in 2010. Sure, he'd use Word when he had to, but if left to his own devices, it was always WordPerfect.
Everywhere you look Microsoft have made perfectly sensible customisations difficult or impossible.
I suspect that's because their devs can't figure out how to make those perfectly sensible customisations (sic) work properly, reliably, and securely.
There can't be any great technical justification for that. It has to be pure stubbornness.
Hanlon's razor: Never attribute to malice that which is adequately explained by stupidity.
Would you kindly provide additional details on what the "Windows file selector" is, so I can (hopefully) help you figure out what is going wrong here? In Windows File Explorer you can indeed set defaults, and holding down CTRL whilst rotating your mouse's scroll wheel rotates the view through everything from a list to extra-large icons.
well In My Bombastic Opinion it was BETTER in older windows versions, particularly the 'File Open' 'common dialog' box. It loaded faster because it DID NOT HAVE TO DO ANALYSIS ON EVERY STINKING FILE EVERY TIME IT LISTED THEM so that MAYBE some shell extension would do something later IF you selected it. They could always populate icon lists and tree diagrams based on a cache or in a background thread, and NOT delay the selection of files for A SINGLE MOMENT LONGER than absolutely necessary.
Admittedly, gnome is just as bad - open up the /usr/bin directory some time in a 'File Open' box and ask "why is this thing SO SLOW???" [same reason why Micros~1 file open boxes are so slow, I say]
Hey buddy, you trusted Microsoft. It's your fault, really.
How many more times is it going to take for people to understand ? Borkzilla launches a new tool ? Fine. Wait 'till version 3 to check it out. Wait 'till version 5 to start developing on it. Check the initial promises, compare to realization. If at V5 it's at less than 75% of initial promises, you should know that it will never get there.
Then decide what to do with it, knowing that there's a better than 50% that it will be discontinued in the next ten years.
Either that, or it will be "replaced" with something else you can no longer avoid using.
Honestly, these days you're better off with Open Source.
The problem with all their new UI API's is two fold. They are fucking slow and they use enormous amounts of memory. They make incredibly fast machines chug along.
I hare to say it, but if you want to write something fast and efficient you still have to use Win32/MFC. Or use QT which has picked up a fair amount of bloat.
Just look at the latest generation of Outlook. Of you resize the window it is absolutely terrible as it stutters and re-renders. And it uses so much memory. Internet Explorer 3 never did this. It was fast with smooth scrolling, a marvel 25 years ago.
I know to never use a new Microsoft platform after they defect deprecated WinForms in .NET for all the junk that came after with WPF and WCF the later I am pretty sure they junked in less than 2 years. WPF is fucking terrible. It's an XML monstrosity.
There's been a couple of times I was forced to write some .NET utilities with WPF and it is a total disaster.
I'm happy that the majority of applications I write happens with Delphi, either the rock solid VCL or the multi platform FireMonkey framework. It is consistent, reliable and just get the job done quick.
I only use M$ Windows because work has always insisted I do, not once since 3.0 have I had reason to enjoy the experience. The number of people in here doing logical gymnastics to find something positive to say about the M$ API wildlife park is mind blowing, truly effing mind blowing.
Biting the hand that feeds IT © 1998–2021