Why is VB.Net/C#/XAML + VS2019 is better than VB6? Here's why.....

[PlausiblyDamp]

Olaf cannot change the compiler. A lot of the things we enjoy in VB.Net/C# etc are actually implemented by the compiler and not the framework. Generics, delegates and Async/Await are some of the most well known examples.

After 20 years of delegates, 15 years of Generics, 13 years of Linq and lambdas, and 8 years of async / await, I honestly wouldn't want to go back to a language that didn't provide these things. I think having access to these things becomes "normal", if I am writing .Net code these things (along with all sorts of other little features) have just become how I think about problems. I remember writing type safe collections back in VB6 / .Net 1 days and never had a problem doing so, these days though it would seem such a waste of my time to put any real effort into such basic things.

[peterst]

Some language/platform features: multi-class definitions in single file; partial classes; extensions; delegates; expressions; attribute decorators for classes, properties and methods; object-oriented features (protection levels, abstraction, inheritance); reflection...

Can we live without these features? Yes, as we did 20+ years ago when they didn't exist. But it is almost 2022...

[yereverluvinuncleber]

I'm going to throw the 'sixers a bone and talk about one positive thing that using VB6 gives a programmer, a higher level of knowledge and grit.

I was looking over some of my larger VB6 projects, you know just reminiscing. I saw a lot of stuff I wrote that I can't even remember how half of it works. I don't even know how to do some of the stuff I did back then anymore. .Net spoils you because everything is just so easy. But with VB6, you have to basically do everything yourself. It's like programming in a low level language. You don't just get to import a library and make a couple calls like you could in .Net. You have to hand-roll a lot stuff which requires a higher level of knowledge about lower-level details. Win32 API calls are the most prominent example. You cannot live without them in VB6 but you rarely ever use them in .Net. You could write an entire enterprise level application in .Net without ever making a single Win32 call directly. This is impossible to do in VB6.

You must know how Windows works. You will almost never see things like VarPtr, StrPtr or CopyMemory in a .Net program but even the most basic VB6 applications sometimes require them. This would requires you to have knowledge about pointers and virtual memory and a whole slew of knowledge that a typical .Net programming just would not need to know.

In this respect, I'm eternally grateful for VB6 because it required me to learn a lot of stuff I would never have had to learn had I started in VB.Net. This however, doesn't mean I want to go back to writing programs in VB6 or that I would recommend it to anyone over VB.Net. I'm grateful for the knowledge I acquired during my time with VB6, that's true but like I said, it's really necessary to know these things. VB.Net programmers can get along just fine not knowing what a BSTR is or how a pointer works.

I'd agree with all of this, in fact this is one of VB6's main strengths and I am sure I tried to articulate this earlier. With VB6 you are closer to the metal. All that use of APIs teaches you about Windows and how it does what it does. Those requirements or weaknesses in regard to functionality make VB6 a perfect tool for learning about Windows itself. C is a language more suited to o/s level programming but if you are a beginner in programming and the Windows o/s VB6 is a perfect place to start. My perspective and reason for programming is in the end to be able to contribute in code to the ReactOS project, with that in mind I set about trying to replicate or utilise o/s functionality with VB6. It teaches me the internals of ReactOS whilst learning about Windows. If I was using .NET, it would be just another level of abstraction away from the o/s.

Earlier it was stated "horses for courses" and I would suggest VB6 is a very good horse for this very specific course amongst others.

I am currently struggling with a task that .NET can do easily and simply. It has taken me two (admittedly slow progress due to circumstance) days to get VB6 to write UTF8 compatible text files due to the peculiarities of writing ADO binary streams, positioning to remove the BOM &c. I should not have to do all these shennanigans just to write a UTF8 file but I do have to in VB6.

As a result I have started to learn ADO, stream status, checking why a file remains open whilst writing a lot of data to a stream. I am using new (to me) APIs to test the opening of a file and most of it will be gone in the final code... It matters not as I am being exposed to new (to me) technologies all because of VB6.

VB6 is an extremely good learning playground.

[yereverluvinuncleber]

So you mean to tell me that you don't like going back to look at code you wrote 10 years ago just to reminisce from time to time?

I am still working on code from 10 years ago!

[yereverluvinuncleber]

You think I get this triggered when I hear people say C# is better language than VB.Net.

Oh yes you do... You definitely 'get' triggered, in fact I'd say you ARE the trigger, the chamber, the bullet, the barrel and the whole gun itself.

Direction of the gun is determined by the sound of two words said together, VB6, VB.NET

[yereverluvinuncleber]

And by the way, the project I'm doing, I already did in .Net and it took a fraction of the time because I didn't have to spend all this time worrying about writing my own Collections or trying to find ways to encapsulate data structures.

However, doing it in VB6 taught you a lot about the complexities of what you were really trying to achieve, those things that .NET hides from you. So many people just use tools without really knowing what the language is doing under-the-bonnet/hood.

VB6 told you how difficult it was but you gave up. I have code from La Volpe in my programs that read and display all sorts of image types, none of which are native to VB6. I doubt I could have written all that to my satisfaction, certainly not in the timescales involved. The existence of that code shows me how much work is actually required to achieve what some see as a simple task, ie. displaying a PNG.

It really isn't easy at all. Sometimes taking the easy route is a road that leads to nowhere but more roads to nowhere.

How many souls have been temperered in the fires of convenience? None.

I am taking the hard route, admittedly not the hardest route as I am still letting other's do some coding for me but it is still the hard route as I attempt to understand and debug, implement their code whilst writing my own alongside to do the same or similar. What I learn on the way are some of the fundamentals.

We are all standing on the shoulders of giants, some without knowing it.

[PlausiblyDamp]

However, doing it in VB6 taught you a lot about the complexities of what you were really trying to achieve, those things that .NET hides from you. So many people just use tools without really knowing what the language is doing under-the-bonnet/hood.

VB3 - VB6 were certainly easier than C/ C++, both of them were easier than assembler - I appreciate what lower level programming made me understand, I just wouldn't want to still work that way when easier and more powerful ways exist.

VB6 told you how difficult it was but you gave up. I have code from La Volpe in my programs that read and display all sorts of image types, none of which are native to VB6. I doubt I could have written all that to my satisfaction, certainly not in the timescales involved. The existence of that code shows me how much work is actually required to achieve what some see as a simple task, ie. displaying a PNG.

Nope, VB was a lot easier than things I had done in the past - it certainly didn't make things difficult, however things are easier now by using different languages. It isn't a matter of giving up, it is a matter of being productive. If a better tool comes along that makes things easier, why not use the better tool that makes things easier? I appreciated the ease of VB 20+ years ago when it was an easier tool than the alternatives, these days I appreciate easier tools again. I remember similar disagreements between VB programmers and C++ programmers, I remember similar disagreements between C++ and C programmers, C and assembler programmers.

Giving up implies defeat, as if I couldn't cope with the complexity; the truth is something better / easier / more powerful came along and I chose to leave VB6 and earlier behind because I could see the benefits in he newer tools.

It really isn't easy at all. Sometimes taking the easy route is a road that leads to nowhere but more roads to nowhere.

How many souls have been temperered in the fires of convenience? None.

I am taking the hard route, admittedly not the hardest route as I am still letting other's do some coding for me but it is still the hard route as I attempt to understand and debug, implement their code whilst writing my own alongside to do the same or similar. What I learn on the way are some of the fundamentals.

We are all standing on the shoulders of giants, some without knowing it.

I appreciate that earlier in my career, and as a hobby, I had to learn more about how computers work under the hood. I also appreciate that I don't have to think about these things on a daily basis anymore. If I needed to I could probably remember how to write 16bit segmented addressing C code and the joys of malloc etc. Why would I want to when I can use a strongly typed, garbage collected language that effectively makes 95%+ of memory management a non-issue and the remaining few percent have fairly well established rules to follow?

[yereverluvinuncleber]

I appreciate that earlier in my career, and as a hobby, I had to learn more about how computers work under the hood. I also appreciate that I don't have to think about these things on a daily basis anymore. If I needed to I could probably remember how to write 16bit segmented addressing C code and the joys of malloc etc. Why would I want to when I can use a strongly typed, garbage collected language that effectively makes 95%+ of memory management a non-issue and the remaining few percent have fairly well established rules to follow?

So, we are in agreement. Horses for courses and all that. For the route I am following, it is better for me. I do not doubt that for writing real-world programs in a timely manner with minimal fuss that for many .NET is more convenient. It just isn't always the better or more appropriate option.

That sums it all up then really. Shall we close the thread before Niya gets a chance to leave the last word as usual?

[szlamany]

I am still working on code from 10 years ago!

All my income comes from a program that I created in 2011 and still enhance and build upon today. All my clients run the same code base, so as features are added, they all get them. I am constantly bringing clients up to current revision levels - and they really appreciate it. That's how you can charge an on-going annual maintenance fee of 15% for software sold a decade ago. Some of my clients are still using the VB6 version - the predecessor - of this app - and will eventually be migrated.

[Shaggy Hiker]

I'd agree with all of this, in fact this is one of VB6's main strengths and I am sure I tried to articulate this earlier. With VB6 you are closer to the metal.

HA! I've made essentially the same argument for programming in ASM....but I still wouldn't want to do so anymore. It was really interesting and really informative, but I'm not going back there.

[Shaggy Hiker]

All my income comes from a program that I created in 2011 and still enhance and build upon today. All my clients run the same code base, so as features are added, they all get them. I am constantly bringing clients up to current revision levels - and they really appreciate it. That's how you can charge an on-going annual maintenance fee of 15% for software sold a decade ago. Some of my clients are still using the VB6 version - the predecessor - of this app - and will eventually be migrated.

I might try the same thing, except that I also want to retire, so I'll be looking at a modified approach.

[yereverluvinuncleber]

but I still wouldn't want to do so anymore. It was really interesting and really informative, but I'm not going back there.

I don't have any choice on my specific path. ReactOS is the end point for me and I have no other language that I can reliably and successfully teach myself about these o/s components. To take on pure C at my stage in development would be a mistake and I would obviously fail. C++ might be a better choice but C++ is still not generally used for core o/s development, it used however for the some of the tools but I do not have C++ under my belt yet.

VB6 is already in this head of mine already and it is a better choice for this reason alone.

[PlausiblyDamp]

I'd agree with all of this, in fact this is one of VB6's main strengths and I am sure I tried to articulate this earlier. With VB6 you are closer to the metal. All that use of APIs teaches you about Windows and how it does what it does. Those requirements or weaknesses in regard to functionality make VB6 a perfect tool for learning about Windows itself. C is a language more suited to o/s level programming but if you are a beginner in programming and the Windows o/s VB6 is a perfect place to start. My perspective and reason for programming is in the end to be able to contribute in code to the ReactOS project, with that in mind I set about trying to replicate or utilise o/s functionality with VB6. It teaches me the internals of ReactOS whilst learning about Windows. If I was using .NET, it would be just another level of abstraction away from the o/s.

Earlier it was stated "horses for courses" and I would suggest VB6 is a very good horse for this very specific course amongst others.

I am currently struggling with a task that .NET can do easily and simply. It has taken me two (admittedly slow progress due to circumstance) days to get VB6 to write UTF8 compatible text files due to the peculiarities of writing ADO binary streams, positioning to remove the BOM &c. I should not have to do all these shennanigans just to write a UTF8 file but I do have to in VB6.

As a result I have started to learn ADO, stream status, checking why a file remains open whilst writing a lot of data to a stream. I am using new (to me) APIs to test the opening of a file and most of it will be gone in the final code... It matters not as I am being exposed to new (to me) technologies all because of VB6.

VB6 is an extremely good learning playground.

Is being closer to the metal really a benefit for a higher level language? Being closer to the metal ties you into Windows and a specific architecture (x86 on windows, nothing else). Being removed from the metal means the same code base can potentially run on Windows, Linux, Mac, possibly others and also x86, x64, ARM - possibly even without recompiling. I would say being a step removed is good thing for most LOB applications.

VB6 is no longer supported by Microsoft, hard to obtain, 32 bit only, and has lots of odd quirks. It is hardly an ideal tool to learn windows programming anymore - it abstracts away quite a bit of Windows and the API (No need to create windows yourself, no handling of WndProc, no need to handle PostMessage / SendMessage) but then requires you to dig into the APIs for other cases and often the learning curve to mix and match VB6 and the Windows API is non-trivial and documentation is increasingly out of date.. If you are going to learn the Windows API then VB6 is too much of an abstraction to be useful (especially considering odd differences like Integer sizes etc.)

[yereverluvinuncleber]

Is being closer to the metal really a benefit for a higher level language?

Of course not. But that's not what anyone implied.

[Shaggy Hiker]

Of course not. But that's not what anyone implied.

If you really want to be closer to the metal, you really need to be coding in Rockstar....and in your case, I'm kind of surprised that you aren't. It seems like a very steam punk thing to do.

[Niya]

After 20 years of delegates, 15 years of Generics, 13 years of Linq and lambdas, and 8 years of async / await, I honestly wouldn't want to go back to a language that didn't provide these things. I think having access to these things becomes "normal", if I am writing .Net code these things (along with all sorts of other little features) have just become how I think about problems. I remember writing type safe collections back in VB6 / .Net 1 days and never had a problem doing so, these days though it would seem such a waste of my time to put any real effort into such basic things.

EXACTLY!

This man gets it! It's like you're reading my mind

[Niya]

However, doing it in VB6 taught you a lot about the complexities of what you were really trying to achieve, those things that .NET hides from you. So many people just use tools without really knowing what the language is doing under-the-bonnet/hood.

This is true.

VB6 told you how difficult it was but you gave up.

I gave up on figuring out a way to neatly organize my data structures because it is not possible in VB6 without introducing additional complexity. For this particular case, either the ability to declare multiple classes per file or the ability to group class modules into sub-folders within the IDE would have been adequate. Both of these options are available to VB.Net programmers using any version of Visual Studio after Visual Studio 6.

I have code from La Volpe in my programs that read and display all sorts of image types, none of which are native to VB6. I doubt I could have written all that to my satisfaction, certainly not in the timescales involved. The existence of that code shows me how much work is actually required to achieve what some see as a simple task, ie. displaying a PNG.

Fun memories. Manipulating PNGs were a rite of passage for me too in VB6. Though back then, I knew nothing about VBForums or the amazing stuff they had for VB6 over here. I used the Free Image library in combination with some of my own hand written code to manipulate PNGs. I don't know if Free Image is around today but god damn! It was such a great library and they had all the bindings for VB6 .

We are all standing on the shoulders of giants, some without knowing it.

There is a greater point to be made here but I'll come back to it after I release what I'm working on. The point I want to make is directly relevant to what I'm doing in VB6 right now.

[Niya]

Look at this:-


This is what I wanted to avoid. Just chaos. There's no way to group related classes in VB6. In Visual Studio 2019, we could create sub folders to group files instead of having this huge list of things just sitting there completely unorganized. We also have the option of defining multiple classes in a single file so related classes can be grouped that way as well in VB.Net/C# etc..

If I revisit this 10 years later, I'm going to have a very hard time figuring out how this works because this flat list structure gives no clues about how this program is organized. This is some serious caveman type stuff right here lol...

[Niya]

In contrast look how the same project is organized in VB.Net:-


Everything is neatly categorized and grouped. It's very easy to figure out what is related to what.

[yereverluvinuncleber]

The VB IDE should be improved as you would expect given 20 years of development.

Nonetheless, I like the VB6 IDE as it isn't cluttered with functionality and as a result it is quick to operate. There is always a penalty or a downside to all improvements and I still use my older, slick and fast to run editors when I am editing some .js rather than the all-singing and dancing advanced editors that do it all for me. Sometimes it is good to be lean in both the language and/or the IDE.

The downside of 20 years of continuous development by Microsoft, well... some might have something to say about that but I cannot comment as my experience is minimal.

When I change from XML, .js in an advanced editor, the VB6 IDE still seems like an upgrade, the integration of the designer, interpreter, the debugger and compiler and the speed of the whole package - it is still usable 20 years later, that is the real testament to the thing.

You drive a 1973 Aston Martin V8 and as a car, it may have very little a more modern car can't do better in almost all respects but still be prepared to give it some respect when it fires up that engine. It can still GO!

[Niya]

Nonetheless, I like the VB6 IDE as it isn't cluttered with functionality and as a result it is quick to operate. There is always a penalty or a downside to all improvements and I still use my older, slick and fast to run editors when I am editing some .js rather than the all-singing and dancing advanced editors that do it all for me. Sometimes it is good to be lean in both the language and/or the IDE.

Ah and here is the crux of it, we are fundamentally different different people.

From my point of view, I paid no penalty for choosing Visual Studio 2019 over Visual Studio 6. The only slight cost is a bit of start up time. Visual Studio 2019 takes a bit of time to start up but the features that come with it make this small cost more than worth it, like way more than worth it!

You on the other hand are a bit of an "old soul". You tend to stick with the things you know and trust. I'm sure most of us here know someone like an older relative, an uncle or perhaps a grandfather, that still does certain things the way he did it in his youth and nobody could convince him that the modern way is better. It could be construction techniques, his choice of tools, his choice of cars or his favorite brand of cigarettes. You strike me as one of these types.

There's nothing wrong with that, it's just that I was always of the assumption that programmers of all people would be quick to appreciate progress. It's just surprising to find people in any IT field that think this way. I had never considered this to be honest.

[techgnome]

There's nothing wrong with that, it's just that I was always of the assumption that programmers of all people would be quick to appreciate progress. It's just surprising to find people in any IT field that think this way. I had never considered this to be honest.

I take it you've never met a COBOL programmer have you?

-tg

[Niya]

I take it you've never met a COBOL programmer have you?

-tg

I have never met one but I'd be extremely surprised if I did and he started making grand claims about COBOL being the best programming language ever invented and that everything else is trash

[Shaggy Hiker]

I've never found a field where people are really into progress for the sake of progress. All programmers I know have settled in at some point, and move forwards only when convenient. That makes sense, really. Once you've invested a significant amount of time into one tech, you only move forwards if the cost isn't too high.

The IDE has vastly improved, in my opinion, but the current VS IDE could stand to have...more options! Hard to believe, but I really do feel that way. There are so MANY features that the performance isn't excellent. I've often stated that the VS2010 IDE was the most beautiful IDE that MS ever put out, and was as fast as anybody could ask for, as well (or at least anybody reasonable. I realize some people would like it to be open before they realized they wanted to open it, but that's just unreasonable). I've come to appreciate many features that have been added since then, and VS2019 is really quite nice, but it isn't instant. On my computer, there is a delay of a second or two for the IDE to come up, and it's hard to not think that might have something to do with all the graphical elements that are being shown. I don't believe I use all that it does, so having some of them be opt in rather than opt out seems like it might be a good idea.

On the other hand, since I'm currently working on an even more graphically intensive application, I'm also well aware that the graphical elements of VS may not be the cause of the starting time. If that's the case, then I wouldn't want more options.

[Shaggy Hiker]

I have never met one but I'd be extremely surprised if I did and he started making grand claims about COBOL being the best programming language ever invented and that everything else is trash

Well, I wouldn't expect him to say that about the language, but I wouldn't be surprised if he didn't have some choice words about young whippersnappers like yourself as he hit you with his cane.

[Niya]

Well, I wouldn't expect him to say that about the language, but I wouldn't be surprised if he didn't have some choice words about young whippersnappers like yourself as he hit you with his cane.

lmao. It makes me recall an incident on a C forum where an old guy from the DOS days got into a massive war because he thought DOS was superior to Windows because he felt Windows was bloated(wonder where we have heard this before

...it's hard to not think that might have something to do with all the graphical elements that are being shown.

It has nothing to do with the graphics. Visual Studio 2019 is something of it's own operating system. It has to load all kinds of stuff in the background. I mean the intellisense uses machine learning! I sincerely doubt we can get such advanced features without paying some kind of cost. That cost is paid in start up time. It might rub some people the wrong way but I'm fine with it as long as it doesn't take a week to open.

[peterst]

Niya, you have to try VS2022 with C#. You will find it do (black?) magic

[Niya]

Niya, you have to try VS2022 with C#. You will find it do (black?) magic

Oh I intend to but when last I checked, I think it was still in beta or something. I like to give them time to mature and work out all the bugs before I jump ship. But yea, VS2022 is a must. I will go there eventually.

[Niya]

Funny, as you mentioned VS2022 a thought just occurred to me. What if on a whim Microsoft just decided to include the ability to open VB6 projects in some future version of Visual Studio. I'd love to see how the VB6 community would react to this. I wonder how many people are still gonna stubbornly refuse to move and what kind of mental gymnastics would they perform to justify it.

[Niya]

Out of curiosity I decided to do a Google search. It seems someone already attempted this.

[Episcopal]

Funny, as you mentioned VS2022 a thought just occurred to me. What if on a whim Microsoft just decided to include the ability to open VB6 projects in some future version of Visual Studio. I'd love to see how the VB6 community would react to this. I wonder how many people are still gonna stubbornly refuse to move and what kind of mental gymnastics would they perform to justify it.

I don't know if it would be worth it, but it would even be a microsoft marketing game to push the resistance crowd to new platforms once and for all. LOL

[Shaggy Hiker]

I'm not sure that it would work, and I REALLY don't think MS has the desire or necessarily the capability, anymore. It's been twenty years since that team has been together. All have moved on and many have retired. For MS, it would likely be about as easy as getting any other third party language working in VS. In addition to that, they likely have no incentive. I certainly don't think they are interested in getting other people to try VB6.

One final point is that I think the debugging model works quite differently, so it might not be all that easy to make it work in modern VS.

[Niya]

I know it's never going to happen but it was just fun to think about this alternate reality.

Also, I don't think we should underestimate Microsoft's capability of doing this. This is Microsoft we are talking about after all. If two guys could cobble together a decent VB6-comptible IDE in their spare time(TwinBASIC), Microsoft could more than do it with their resources, not to mention that despite the VB6 team's disbandment, they would still have the source code for VB6. Wayne Phillips was able to make very impressive strides with TwinBASIC on his own without the VB6 source code. Imagine what a billion dollar company with hundreds of programmers could do with the source code.

[Niya]

I don't know if it would be worth it, but it would even be a microsoft marketing game to push the resistance crowd to new platforms once and for all. LOL

I would have done this. I'm confident that .Net could stand well on it's own merits. There is no need to force people to move by killing off VB6. People would have still figured out all the amazing things you can do in .Net and the world would have moved on anyway.

[Niya]

Here's something I just ran into while looking up something completely unrelated to this kind of discussion:-



This is why Visual Basic always seems to be struggling. VB6 has been abandoned and VB.Net has been put into maintenance mode. The world really doesn't like BASIC. Sometimes I wish I never got involved with this language but instead cut my teeth on something like C. It's always risky using something that the world hates. You never know when the rug will get pulled out from under you because whatever company you depend on to support it has found it to be unprofitable because the majority don't like it.

This is one of the main reasons I wanna finish off all the little loose ends and pet projects I have going on in VB.Net and finally close the Visual Basic chapter in my life for good and move on to something more popular like C# or Python. When that day finally reaches, I'm never coming back to anything with BASIC in it. People hate it for whatever a reason and none of us can change that. At some point we have to accept that this is the reality.

[Niya]

And to be fair, I do think C# is a better language than VB.Net so I can't really blame the masses for their distaste. I still absolutely love VB.Net despite this and would never stop using it if I knew that it's future was secure.

[PlausiblyDamp]

And to be fair, I do think C# is a better language than VB.Net so I can't really blame the masses for their distaste. I still absolutely love VB.Net despite this and would never stop using it if I knew that it's future was secure.

I think it is a matter of effort to develop the language compared to how many people use the new features. This may be unfair, and is only my opinion, but VB seems to attract developers who don't like change and tend to avoid new features.

I can certainly see why Microsoft are happy to support vb but aren't willing to invest time in developing it further.
In the C# communities language / library changes just seem to be adopted quicker. These forums are a great example, the number of people using VB.Net who are still working with Datasets etc. and avoid EF, Linq, any 3rd party ORM.

I remember a lot of negativity here when extension methods and anonymous types were added. I am not sure if I have ever seen VB code using Tuples as a way to return results.

In fact the number of questions you see that are using arrays rather than generics, despite generics being over 15 years old now, shows just how slowly the language features are being adopted.

[Niya]

I think it is a matter of effort to develop the language compared to how many people use the new features. This may be unfair, and is only my opinion, but VB seems to attract developers who don't like change and tend to avoid new features.

I can certainly see why Microsoft are happy to support vb but aren't willing to invest time in developing it further.
In the C# communities language / library changes just seem to be adopted quicker. These forums are a great example, the number of people using VB.Net who are still working with Datasets etc. and avoid EF, Linq, any 3rd party ORM.

I remember a lot of negativity here when extension methods and anonymous types were added. I am not sure if I have ever seen VB code using Tuples as a way to return results.

In fact the number of questions you see that are using arrays rather than generics, despite generics being over 15 years old now, shows just how slowly the language features are being adopted.

Yea this is so true. Even I am that way. It took me quite a while to adopt Async/Await and I only used VB.Net's Tuples for the first time in a real application a few months back.

I'm making an effort to not be this way in the future. I hate trying some new feature for the first time only to discover I should have been using it years ago but didn't because I didn't make a real effort to see it's value.

[dday9]

I’m genuinely curious, what advantages do you gain using a tuple over a class or anonymous objects? The only time I’ve use tuples is to avoid typing a class which isn’t a very good excuse to use them.

[Niya]

I’m genuinely curious, what advantages do you gain using a tuple over a class or anonymous objects? The only time I’ve use tuples is to avoid typing a class which isn’t a very good excuse to use them.

I've wondered the same thing. The only real benefit I can see is that the VB.Net compiler supports them but then this just means that it's really the compiler that's providing that benefit and not tuples. The compiler could easily use normal classes or structures the same way and provide the same benefit as tuples.

Tuples do seem to be popular outside of our little world here in VB. They are supported in quite a few popular languages and I've been seeing more and more code use them.