Who has the twinbasic,radbasic,everything software,the author detailed introduction?

[Shaggy Hiker]

VB.NET has been abandoned in the same way MS abandoned VB6

That's not true. MS replaced VB6 with VB.NET. They have not replaced VB.NET with anything, nor have they abandoned VB.NET. They stated that they would progress VB slower than C# and darn near everybody read that as abandoning the language. In fact, I would say that they have a point, if we take their statement at face value. It may well be that they do intend to abandon the language eventually, but they haven't said so at this time. The point is that the enhancements added to C# aren't really valuable. They don't add anything that couldn't be done already, they just add yet another way to skin the same cat that has been skun more than once already.

[fafalone]

"Going forward, we do not plan to evolve Visual Basic as a language" was the quote. It's hard to see that as a firm commitment to continued development at any pace. But yeah, many language don't seem to know when to stop. Look at C++. But hey, who would buy VS2024 if they didn't find *something* to add.

[yereverluvinuncleber]

When Microsoft abandon something, they may do it more carefully than they did for VB6 but I would say the writing is still on the wall.

[vbrad]

The point is that the enhancements added to C# aren't really valuable. They don't add anything that couldn't be done already, they just add yet another way to skin the same cat that has been skun more than once already.

I don't know much if anything about .net, c# or vb.net but that's an amazing statement.
Is that a generally held viewpoint I wonder?

[fafalone]

IMO the entire point of VB.NET was an afterthought, and something added for the exclusive purpose of killing VB6 to force everyone into .NET. I remember some articles mentioning insider info to that effect, will have to see if I can find them. Now that this purpose has been fulfilled, they're starting to deprecate. Just slower this time, because there's more alternatives... C# and VB.NET aren't really far apart anyway.

[yereverluvinuncleber]

IMO the entire point of VB.NET was an afterthought, and something added for the exclusive purpose of killing VB6 to force everyone into .NET. I remember some articles mentioning insider info to that effect, will have to see if I can find them. Now that this purpose has been fulfilled, they're starting to deprecate. Just slower this time, because there's more alternatives... C# and VB.NET aren't really far apart anyway.

Yes, that was my feeling and belief entirely - just put into words succinctly.

[techgnome]

"Going forward, we do not plan to evolve Visual Basic as a language" was the quote. It's hard to see that as a firm commitment to continued development at any pace. But yeah, many language don't seem to know when to stop. Look at C++. But hey, who would buy VS2024 if they didn't find *something* to add.

There's also a difference between adding or evolving the language and the framework library ... It's certainly possible to add things to the framework without adding additional baggage to the language. that's the direction VB is heading, and eventually probably C# as well... things will hit a point where there's really nothing more to add to the lexicon, and the language stops evolving... but new functionality will still be added to .NET.

-tg

[SearchingDataOnly]

Microsoft's .NET development team didn't understand the spirit and essence of VB6, nor did it understand the programming habits of VB6ers.

If I were the VB.NET decision-maker on Microsoft's .NET development team, I could easily kill VB6. I would do this:

In 2000, when the beta version of .NET was released, I also released a separate VB7-IDE, which was a 100% clone of VB6-IDE, which was almost identical to VB6-IDE, except that VB7-IDE only supported VB.NET code (note: VB7-IDE will automatically convert VB6 code to VB.NET code). Then, even if Microsoft could not provide VB6 upgrade tools, VB6ers would gradually migrate to VB.NET. (If I were the VB.NET project manager, I wouldn't let a completely amateur-level VB6 upgrade tool out of the cage.)

And just like that, after 5-10 years, VB6 was killed.

[fafalone]

I doubt the IDE would have mattered when the language was so vastly different. That was *a* complaint but I really doubt that was the deal breaker for anyone, compared to having to rewrite from scratch in a whole new language with a whole different approach to programming. An upgrade tool for that is beyond practical ability even now; it's just too different.

[Shaggy Hiker]

I don't know much if anything about .net, c# or vb.net but that's an amazing statement.
Is that a generally held viewpoint I wonder?

Probably not. Some folks will always want to use anything new. I'm not one of them. For me, it all comes down to the tradeoffs. Things like Tasks were clearly beneficial, and were added to both languages. LINQ was also added to both languages, but is more controversial: It is always more compact than non-LINQ, but is usually slower, and generally a bit harder to read/debug once it gets beyond the trivial. So, the question becomes whether the smaller amount of total code justifies the slight decrease in performance and the subjective difference in maintainability.

When it comes to the features added to C#, of late, they are more like LINQ than like Tasks, in my opinion. Things like tuples can be used, but they don't solve a problem that has no other solution, so what is the actual benefit to them?

[Shaggy Hiker]

IMO the entire point of VB.NET was an afterthought, and something added for the exclusive purpose of killing VB6 to force everyone into .NET. I remember some articles mentioning insider info to that effect, will have to see if I can find them. Now that this purpose has been fulfilled, they're starting to deprecate. Just slower this time, because there's more alternatives... C# and VB.NET aren't really far apart anyway.

I am the insider info (or at least closely related to it), and that isn't what I heard. For one thing, there wasn't anywhere near as much strategy to this as people seem to think. There was largely an argument with two sides and a decision had to be made. People presented the pros and cons of the various alternatives. The right path was not at all clear, just a judgement call and everybody knew it. What resulted was the guess of the people in the room, which included Gates and Balmer.

People like to look at past decisions and suggest that it was all directed. It wasn't. It was a gamble, and everybody who made that gamble knew the alternatives and made their best guess, but there wasn't a whole lot of certainty as to whether the choice was the right one.

[techgnome]

Probably not. Some folks will always want to use anything new. I'm not one of them. For me, it all comes down to the tradeoffs. Things like Tasks were clearly beneficial, and were added to both languages. LINQ was also added to both languages, but is more controversial: It is always more compact than non-LINQ, but is usually slower, and generally a bit harder to read/debug once it gets beyond the trivial. So, the question becomes whether the smaller amount of total code justifies the slight decrease in performance and the subjective difference in maintainability.

When it comes to the features added to C#, of late, they are more like LINQ than like Tasks, in my opinion. Things like tuples can be used, but they don't solve a problem that has no other solution, so what is the actual benefit to them?

I've got a case where I'm using a Triple (a tuple with three parts) ... the reason was simple, it's also the only area across 4 services that uses something like this.... the case for it is I have a process that needs to gather up some meta data related to X .... now depending on where X is going, I need either MetaData_A or MetaData_B... in either case I also need MetaData_Z no matter what... of course A & B are not compatible with each other so I couldn't create a common class... as a result the data needs for both are also different. So I call a process that gets A, B, and Z ... now if it's being sent to Place1, then the data for A is available and gets set. B will not get set and remains null. Z gets filled no matter what. If it isn't going to Place1, then the data for it won't be available, and it gets set to null. But that means the data for B is there and so B is created.... I then create a triple where value1 is A, value2 is B, and value3 is Z ... and return that. From the calling side, I check Value1, if it is not null, then I pull it and value3 and send it off ... if it is null, I then pull value2 and value3 and send it off in the other direction.

I did it this way because the data gathering process is already isolated and to break that up into something saner, would have caused a lot of problems, rewrites, and pushing things down through layers and properties needlessly.

That said, if I can help it, I avoid tuples if I can, but in those rare occasions when you need one, they are quite handy.


-tg

[Shaggy Hiker]

I doubt the IDE would have mattered when the language was so vastly different. That was *a* complaint but I really doubt that was the deal breaker for anyone, compared to having to rewrite from scratch in a whole new language with a whole different approach to programming. An upgrade tool for that is beyond practical ability even now; it's just too different.

That's correct. The meeting that ended VB6 was essentially a meeting at which the leadership was presented a detailed explanation as to why a functional upgrade tool would never be viable. They could have been wrong, and might still be, but since none has been created to date, it appears they were right. The decision, then, was whether to put all the eggs in one basket. That's never an easy choice to make.

[Shaggy Hiker]

I've got a case where I'm using a Triple (a tuple with three parts) ... the reason was simple, it's also the only area across 4 services that uses something like this.... the case for it is I have a process that needs to gather up some meta data related to X .... now depending on where X is going, I need either MetaData_A or MetaData_B... in either case I also need MetaData_Z no matter what... of course A & B are not compatible with each other so I couldn't create a common class... as a result the data needs for both are also different. So I call a process that gets A, B, and Z ... now if it's being sent to Place1, then the data for A is available and gets set. B will not get set and remains null. Z gets filled no matter what. If it isn't going to Place1, then the data for it won't be available, and it gets set to null. But that means the data for B is there and so B is created.... I then create a triple where value1 is A, value2 is B, and value3 is Z ... and return that. From the calling side, I check Value1, if it is not null, then I pull it and value3 and send it off ... if it is null, I then pull value2 and value3 and send it off in the other direction.

I did it this way because the data gathering process is already isolated and to break that up into something saner, would have caused a lot of problems, rewrites, and pushing things down through layers and properties needlessly.

That said, if I can help it, I avoid tuples if I can, but in those rare occasions when you need one, they are quite handy.


-tg

Perhaps I should think about it more. Maybe even break out some time over several days. These could be mull tuple times.

[yereverluvinuncleber]

I'm having a tuple at the moment, Tamnavulin with a little water. Followed by a pint and a half of bitter.

[fafalone]

I am the insider info (or at least closely related to it), and that isn't what I heard. For one thing, there wasn't anywhere near as much strategy to this as people seem to think. There was largely an argument with two sides and a decision had to be made. People presented the pros and cons of the various alternatives. The right path was not at all clear, just a judgement call and everybody knew it. What resulted was the guess of the people in the room, which included Gates and Balmer.

People like to look at past decisions and suggest that it was all directed. It wasn't. It was a gamble, and everybody who made that gamble knew the alternatives and made their best guess, but there wasn't a whole lot of certainty as to whether the choice was the right one.

I don't think what you said is mutually exclusive to what I said; at least from the details you've provided. There's public info from people on the VB programming team that some work had been done on VB7; when was that decision made, how far along was C# and the .NET Framework when VB.NET was introduced, and when was the decision made to use it kill off the original VB line? I mean you just confirmed it wasn't a well thought out plan; so only the timeline is in dispute. I don't think "everyone" knew it was a close call considering how near universal opposition was among MVPs. It just sounds ridiculous on it's face, 20 years on and I've still not heard a compelling argument for why VB6 should have been killed, which was an entirely different question from whether C# and the .NET Framework should have been introduced-- I don't think anyone disputes there was need for a cross-platform, modern web supporting alternative with professional toolset of VS; but what was the reasoning behind "we're going to force everyone to do it this way by ending the other way rather than let it stand on it's own merits"? There could be no doubt it was a radically different language that wasn't beginner-friendly but a tool for professional developers, and it's really hard to accept nobody in that room understood why VB classic was the incredible success it was and what kind of a barrier incompatibility represented.

[Shaggy Hiker]

I'm having a tuple at the moment, Tamnavulin with a little water. Followed by a pint and a half of bitter.

HA!! That's a good one.

[Shaggy Hiker]

I don't think what you said is mutually exclusive to what I said; at least from the details you've provided. There's public info from people on the VB programming team that some work had been done on VB7; when was that decision made, how far along was C# and the .NET Framework when VB.NET was introduced, and when was the decision made to use it kill off the original VB line? I mean you just confirmed it wasn't a well thought out plan; so only the timeline is in dispute. I don't think "everyone" knew it was a close call considering how near universal opposition was among MVPs. It just sounds ridiculous on it's face, 20 years on and I've still not heard a compelling argument for why VB6 should have been killed, which was an entirely different question from whether C# and the .NET Framework should have been introduced-- I don't think anyone disputes there was need for a cross-platform, modern web supporting alternative with professional toolset of VS; but what was the reasoning behind "we're going to force everyone to do it this way by ending the other way rather than let it stand on it's own merits"? There could be no doubt it was a radically different language that wasn't beginner-friendly but a tool for professional developers, and it's really hard to accept nobody in that room understood why VB classic was the incredible success it was and what kind of a barrier incompatibility represented.

The new version was VB 6.5, not VB7, which was always VB.NET. The reason was, "to put all the wood behind one arrow" (Microsoft does love their jargon, acronyms, and clichés). I don't think anybody in the room failed to understand that VB6 was successful. It also hadn't been around for very long at a company that had eaten the lunch of several other competitors that didn't move with the times. For example, by the time the suit between Lotus and Borland was settled, both of them were fading memories while Excel had taken the market. MS had been fighting a close race with Borland over C++. At the time when .NET was coming out, the Dot Com bubble was large and still inflating, Linux was the the threat to Windows while Apple was still reeling from the OS 8 debacle, and people were gushing over the (never realized) promise of Java and write-once-run-anywhere.

In that environment was VB6, which came out in 1998, with VB4 coming out only a few years earlier. Basically, things were moving really fast and everybody was fighting everybody else, with no real giants and several pseudo-giants falling over the last few years because they tried to protect their lead rather than improving (Lotus, Borland). VB6 was certainly popular, but it had only been out for a year or two. That's nothing. The future appeared to be Java-like, web based, and possibly not Windows.

Basically, given what they knew at the time, I think they made the most plausible choice. Of course, they could have followed the strategy of maintaining two different, quite different, languages, but there would be a serious cost to them for doing so. The staff required to maintain an international product of that size, even if you never intended to produce another version, would be profound. Consider that Excel had a dozen software engineers at that time, which doesn't count management & overhead, sales & marketing, tech support, and possibly not QA engineers. The annual cost for Excel would be in the tens of millions of dollars. VB6 wouldn't be less than that, and was likely more. So, they had that cost. Did they believe enough people would buy that program, which had only been out for a couple years, each year to justify that cost when the world was changing towards a web and/or IL world? I would think not.

[fafalone]

They understood it *was* successful but you're just reinforcing the jawdropping idea nobody understood *why* it was successful. If they had, they would have realized that, like the large majority of the VB world was screaming at them from the second the decision was announced and no doubt told them, or would have told them if asked, in pre-decision market research, it wouldn't have been "I would think not", it would have been a resounding "Either do that or find a way to make a compatible product which doesn't reject the reasons VB classic was popular". Because to replace it with .NET, it tells me nobody understood the success wasn't in dedicated, experienced professional developers who'd have little trouble adapting, but in the rapid production of tool to execute business logic accessible to people without the experience of a seasoned software engineer (or were just completely delusional and thought .NET was too).

Also MS had 22,000 employees in 1997, 30,000 in 1998 and 40,000 in 2000; you're telling me they hired 18,000 people in this time period but balked at a few hundred to avoid a wildly unpopular decision to kill a product that enjoyed a massive market share and had a complete monopoly on it's niche? The phrase "penny wise, pound foolish" comes to mind.

[SearchingDataOnly]

I doubt the IDE would have mattered when the language was so vastly different. That was *a* complaint but I really doubt that was the deal breaker for anyone, compared to having to rewrite from scratch in a whole new language with a whole different approach to programming. An upgrade tool for that is beyond practical ability even now; it's just too different.

A well-designed VB7-IDE can greatly reduce the sense of difference between VB6 and VB7.

[Shaggy Hiker]

They understood it *was* successful but you're just reinforcing the jawdropping idea nobody understood *why* it was successful.

Why do you find that so surprising? If you are right about your analysis as to why it was popular (and it sounded pretty reasonable to me), then consider who was making that decision: A whole bunch of people who were solely in the category that you said would have no problem switching. They were all very dedicated, experienced, professional developers.

If they had, they would have realized that, like the large majority of the VB world was screaming at them from the second the decision was announced and no doubt told them, or would have told them if asked, in pre-decision market research, it wouldn't have been "I would think not", it would have been a resounding "Either do that or find a way to make a compatible product which doesn't reject the reasons VB classic was popular". Because to replace it with .NET, it tells me nobody understood the success wasn't in dedicated, experienced professional developers who'd have little trouble adapting, but in the rapid production of tool to execute business logic accessible to people without the experience of a seasoned software engineer (or were just completely delusional and thought .NET was too).

Also MS had 22,000 employees in 1997, 30,000 in 1998 and 40,000 in 2000; you're telling me they hired 18,000 people in this time period but balked at a few hundred to avoid a wildly unpopular decision to kill a product that enjoyed a massive market share and had a complete monopoly on it's niche? The phrase "penny wise, pound foolish" comes to mind.

I don't think the number of employees was ever the issue. Instead, I think it was the money. MS is one of the most valuable, profitable, companies in history, and they have gotten there by ruthlessly chopping out things that made millions in favor of things that made hundreds of millions. They have touted and abandoned numerous products over the decades, and have been extraordinarily successful throughout. Considering the track record, you certainly can't think that they have any particular regrets about their choices.

Business is about the bottom line. If you make good choices, you thrive. If you make bad choices, you go under. People will be pissed at ANY change. By now, while there are passionate followers of VB6, there aren't that many of them, and very few new ones are being created. Meanwhile, Java may be the most popular language, JS may be even more so if you count all the flavors as one, yet other things are growing pretty fast. VB6 was big in academic circles for the very reasons you mentioned, you'd now find it to be R. VS now includes R, but VS is also now free, something that was never true back in the days of VB6.

Things change, MS has become rich by not clinging to their own past, successful or not.

[fafalone]

That's surprising because the large number of MS MVPs who signed petitions opposing .NET were no doubt experienced professionals too, but they understood it fine. Then it's surprising MS didn't have market research people looking at what worked for their customers and why (or did but ignored them too).

As for change for the sake of change... Office sends it's regards... Office is, I believe, their biggest profit center up until the last few years when it moved to second place after the server/cloud division.

The Office team seems to understand the importance of VBA. I would think they do have regrets on VB6... I have little doubt the disastrous VB6 move convinced them not to pull the plug on the VBA despite it being the same language with the same weaknesses. The near-total lack of updates save for a begrudging addition of LongPtr in 2013 and 64bit common controls in 2015 after years of complaints tells me they would very much like to. They lost an *enormous* market share to things like Java and Python, because so many of the experienced people were staring down learning a new language anyway, why not just move to the proven real deal for web rather than Microsoft's new attempt, when Microsoft had just demonstrated to them they can't be depended on for long term programming tools? Office stays on top no doubt in no small part by virtue of not abruptly pulling the plug on VBA.

[OptionBase1]

Microsoft Bob says hi.

[Shaggy Hiker]

That seems like a backwards looking view. Java was the shiny new thing when .NET showed up. It was far from a proven real deal, and has never managed to live up to the hype around it at the time.

Office hasn't remained in one place, either. VBA might have, but Office has been re-written more than once. All the new file types (docx, xmlsx...or whatever that is) are zip files, which is a far cry from what they were when Office first rolled out. They haven't even kept the same face on it, and people complained bitterly about THAT change, too...until they likely realized that it had some real advantages. Now it's changing yet again with the semi-always-online Office 365 and Web Office. They did keep continuity, though, which you can't say for VB. They wanted to, they just couldn't figure out how to do it, nor has anybody since then.

MVPs may not be experienced professionals. I was offered an MVP at one point, and back then I was far from a professional programmer...not all that experienced, either. The MVP program was more about rewarding those who assisted others to get into programming rather than a recognition of capability. They were also distributed much more liberally. How many MVPs were there at the time? What percentage spoke out, and in what way? I think there were probably a LOT, so even a large number of objections may have been a trivial percentage. Still, it was people who were recognized for passing on knowledge of an existing system. One might expect they'd be less enthusiastic about that existing system being changed radically.

Not sure, though, as I don't know how many MVPs there were, nor what percentage spoke out, nor why. It just seems like there are multiple possible answers to those which will result in different interpretations.

[2kaud]

AFAIK, .net came about because Sun (who originally developed Java) wouldn't let MS change/alter Java. So MS came up with c# and .net and vb.net as the alternative to Java. They wanted everything then to be .net based. They even came up with c++/cli (which is C++ using .net - yuk!). As VB6 wasn't .net based it didn't fit into their 'portfolio' of everything being .net so was basically forgotten with MS hoping it would just die and go away. With typical MS attitude they thought they could dictate to the community which languages was used for development. There was even an idea being floated with MS that Windows 7 shouldn't allow VB6 IDE to work. Luckily that idea didn't get any traction...

Starting in 2000 MS re-branded many products as xxx.net (eg VS .net etc). However from about 2004-2005 this re-branding fell out of flavour and the more traditional names were re-instated for products.

[Shaggy Hiker]

AFAIK, .net came about because Sun (who originally developed Java) wouldn't let MS change/alter Java.

change/alter/hijack/steal/undercut...yeah, that's what I heard, too. Borland and MS had competing flavors of C++ out there, each with extensions that would effectively lock a developer into their ecosystem if used. I always assumed that they wanted to do the same with Java, but weren't allowed to.

[2kaud]

Borland and MS had competing flavors of C++ out there

They still do. Although the underlying C++ language is now based on the current C++ standard, for frameworks MS has MFC and WinRT, and Embarcadero (new name for Borland) has VCL (used to be OWL). They are not compatible!

[Shaggy Hiker]

I guess I stopped paying attention a while back. I didn't realize they were still doing that. I kind of thought that the standard put an end to that nonsense.

[2kaud]

I guess I stopped paying attention a while back. I didn't realize they were still doing that. I kind of thought that the standard put an end to that nonsense.

The standard doesn't cover frameworks - just the core language/libraries (and specifically doesn't cover any gui/network/sound etc). Any-one is free to add - eg QT which is another 'framework' although x-platform.

[OptionBase1]

Sometimes a successful product or company is as much, if not more, about a lack of alternatives than it is about fantastic or innovative ideas.

[xiaoyao]

Why do you find that so surprising? If you are right about your analysis as to why it was popular (and it sounded pretty reasonable to me), then consider who was making that decision: A whole bunch of people who were solely in the category that you said would have no problem switching. They were all very dedicated, experienced, professional developers.



I don't think the number of employees was ever the issue. Instead, I think it was the money. MS is one of the most valuable, profitable, companies in history, and they have gotten there by ruthlessly chopping out things that made millions in favor of things that made hundreds of millions. They have touted and abandoned numerous products over the decades, and have been extraordinarily successful throughout. Considering the track record, you certainly can't think that they have any particular regrets about their choices.

Business is about the bottom line. If you make good choices, you thrive. If you make bad choices, you go under. People will be pissed at ANY change. By now, while there are passionate followers of VB6, there aren't that many of them, and very few new ones are being created. Meanwhile, Java may be the most popular language, JS may be even more so if you count all the flavors as one, yet other things are growing pretty fast. VB6 was big in academic circles for the very reasons you mentioned, you'd now find it to be R. VS now includes R, but VS is also now free, something that was never true back in the days of VB6.

Things change, MS has become rich by not clinging to their own past, successful or not.

VB6 and twinBASIC are "twins". You know, just like Arnold Schwarzenegger and Danny DeVito are twins.
https://nolongerset.com/the-twinbasic-family-tree/


For example, the lowest price of an iPhone in China is $1,000 and the highest is $2,500.
Although he could also release a lower-priced product based on the IPHONE4. But it could seriously hamper sales of higher-priced products.

That is, if you keep VB6 updated continuously, with a small number of updates every year, it will cause many companies to not want to buy development tools like VS2019.
Just like if you have been XP,WIN7 a small number of updates, mainly to solve problems such as vulnerabilities. Although the workload will not be too large, but the maintenance of stable, small memory occupation of the classic old version of the operating system, will hinder the new version of WIN10,WIN11 sales.

What Microsoft needs is for businesses and individuals to keep buying new products, rather than sticking with old ones (which are almost free to upgrade) or not upgrading with no impact on usage, which is self-defeating for Microsoft.

But Microsoft did not consider the needs of users, such as forcing the installation of the new Google-kernel edge browser, and 100% blocking users from opening iexplorer.exe.
For individual developers and some small businesses, a 200mb VB6 is sufficient.
But a vs2022 requires 45GB, and it may be necessary to add a separate hard drive specifically for development tools.
PYTHON 3.11, the installation package is only 10MB, unpack 19MB
VB6 core file 4.5MB, extract 11.5MB
vb6 sp6 Simplified Version 10.5MB 30MB
vscode 1.82; 90MB
A simple IDE with a relatively small footprint is also what many developers need.
There are many programmers who don't keep writing code every day, and installing an IDE within 500MB is the most convenient.