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

[SearchingDataOnly]

What is VB6-2020?

I am not familiar with Babel, and not all that familiar with RC6, aside from some things I have read on here and a discussion with Olaf. Therefore, I can't even begin to compare the two.

I have written a post about VB6-2020, but now I can't search for it in vbForums because the search engine of vbFourms does not support multi-word searches.

[techgnome]

I have written a post about VB6-2020, but now I can't search for it in vbForums because the search engine of vbFourms does not support multi-word searches.

Worked fine for me...
maybe this is the post you're referencing: https://www.vbforums.com/showthread....=1#post5508914
Or rather it looks like this one - https://www.vbforums.com/showthread....=1#post5508906

Jeezes... it's like arguing with an anti-vaxxer, and they tell you to do their research for them when you ask for proof...

-tg

[SearchingDataOnly]

Worked fine for me...
maybe this is the post you're referencing: https://www.vbforums.com/showthread....=1#post5508914
Or rather it looks like this one - https://www.vbforums.com/showthread....=1#post5508906

Thank you, tg.

Jeezes... it's like arguing with an anti-vaxxer, and they tell you to do their research for them when you ask for proof...

RC5/RC6 and its predecessor dhRichClient have been developed for almost 20 years. Some people in this forum (including me) have used RC5/RC6 for more than 10 years.

[SearchingDataOnly]

What is VB6-2020?

I am not familiar with Babel, and not all that familiar with RC6, aside from some things I have read on here and a discussion with Olaf. Therefore, I can't even begin to compare the two.

IMO, there are two kinds of VB6 in the world
(1) VB6-1998:
The main technologies used by people who use VB6-1998 are: UserControl, Win-APIs, Subclass, DAO, ADO, Access, SQLServer. Some people use Html, XML, and VBScript in small amounts. These people mainly use VB6-1998 to develop and maintain some old Win-Apps.

(2) VB6-2020 (it is 100% compatible with VB6-1998):
In addition to using all the technologies of VB6-1998, the main technologies used by people who use VB6-2020 are: RC5/RC6, ActionScript, Hash-Table, Sqlite (including MemDB), Cairo, Html5, WebKit, WebView, JS-Libs , WebServer, Ngnix, VBFastCGI, JSON, XML, Serialization/Deserialization, Web-APIs, OpenUI5, SPA. These people mainly use VB6-2020 to develop modern Win-Apps and transform old Win-Apps.

Not only many people use VB6-2020 for life, but many people use VB6-1998 for life.

[Niya]

What is VB6-2020?

It's another bait and switch tactic used by VB6 fans to promote VB6 as a modern tool, which isn't 100% wrong but it is a bit misleading. Basically they use 3rd party libraries like Olaf's RichClient and Krool's controls to bolster arguments that VB6 is strong. This argument often ignores the fact that they are just that, 3rd party libraries. Anyone could do the same thing with COM Interop. In fact, when if I need modern functionality in VB6 without having to write it myself, I just import it from .Net through COM Interop. I don't bother have to bother myself with having to learn RichClient or any other 3rd party library. Boom! That's my "VB6-2020"

[Shaggy Hiker]

That's a point. I'm working on a project based on plugins. Since you can build anything into a plugin, I could add Excel to my project (thought about doing so as a demo), add something written in ASM, C, VB6, or anything else, to my project...and so on. I'm not sure whether I could use something written in R to my project, but that's okay with me.

As long as you have a language that can be extended, it can be extended in whatever direction up to the capability of the hardware it runs on.

[Niya]

As long as you have a language that can be extended, it can be extended in whatever direction up to the capability of the hardware it runs on.

Thing is, all serious development platforms can do this. When you take away this from the debate, then whatever is left can go towards really evaluating which tools are better in specific domains.

[Schmidt]

...they use 3rd party libraries like Olaf's RichClient and Krool's controls to bolster arguments that VB6 is strong.

VB6 (with its minimalistic runtime) was developed with exactly that in mind:
COM-libs... (which always had to be checked-in as either OCX- or Dll-references over the appropriate Dialogs).
Be that MS- or Krools-CommonControls, or DAO or ADO - or one of the "big Grids" like MS-FlexGrid or vsFlexGrid.

This argument often ignores the fact that they are just that, 3rd party libraries.

There's nothing wrong with 3rd party-libs, when they were professionally written (free available for anybody) -
and maintained for a long time (Krools stuff for nearly one decade now, and the RC-libs for nearly two decades).

You .NETers have to download and reference NuGet-packets for common stuff like SQLite- or SVG- or JSON-support.
All that is available to the VB6-community for a long time now (via RC5/RC6).

There is no language on this planet, which works independent from libraries (even C depends on the C-runtime).
Trying to "exclude them" when comparisons are made, is just nuts.

Olaf

[Shaggy Hiker]

I'm not quite sure that's true, but I mostly agree. The reason I think it might not be true is because of R. The way that language is taking over the biology/academic fields is truly impressive. I think you'd have to call it a serious development platform for that reason, but I'm not at all sure that R meets my statement. It can certainly be extended, since that's the way it was designed, it just has limits.

[Shaggy Hiker]

You .NETers have to download and reference NuGet-packets for common stuff like SQLite- or SVG- or JSON-support.
All that is available for the VB6-community for a long time now (via RC5/RC6).

There is no language on this planet, which works independent from libraries (even C depends on the C-runtime).
Trying to "exclude them" when comparisons are made, is just nuts.

Olaf

In fact, you can go further than that, because .NET is paring back what is in the language and what comes from NuGet packages. I think that this is so that the resulting exes in Core applications are as small as is reasonably possible, but that's just a guess. An example of this is that .NET framework always included a series of data providers for Ole, ODBC, and SQL Server, but those are no longer in the base package, but are included via NuGet.

The other possible reason for MS to go in that direction (aside from the fact that NuGet is so darn easy) is that VS is now so sprawling. There are so many languages, options, extensions, add ons, and so forth, that the idea of a 'complete' install has become nuts. Once you realize that you HAVE to make your system modular, it changes your approach to everything. So, they may have made it more modular because they had to make it at least a little modular...and then just ran with it.

[Schmidt]

I'm not quite sure that's true, but I mostly agree.
The reason I think it might not be true is because of R.

When a domain-language claims, to be strong in math and statistics,
then I'd expect that it ships with a decent set of "pre-installed libs" (runtime-libs, if you want).

But not each and everything can (or should) be covered with the "base-install":
https://support.rstudio.com/hc/en-us...ful-R-packages

Olaf

[Shaggy Hiker]

R has loads of libraries. It's all about the libraries. I've talked to people who are pretty dismissive of base R in favor of some library package that I have now forgotten. I'm just not sure that R measures up to my earlier statement of being able to be extended to the full limit of the hardware. I think it's more like an increasingly big fish deliberately staying in a small pond.

[Delaney]

As far as I know, R is a very specific language and has been developed mostly for data analysis and statistical analysis. That's mostly the reason why the scientific community use it more and more. it seems also not to difficult to learn and use. I have a colleague who use it for a few time and do interesting thing with it and he never programmed before.

[Niya]

VB6 (with its minimalistic runtime) was developed with exactly that in mind:
COM-libs... (which always had to be checked-in as either OCX- or Dll-references over the appropriate Dialogs).
Be that MS- or Krools-CommonControls, or DAO or ADO - or one of the "big Grids" like MS-FlexGrid or vsFlexGrid.


There's nothing wrong with 3rd party-libs, when they were professionally written (free available for anybody) -
and maintained for a long time (Krools stuff for nearly one decade now, and the RC-libs for nearly two decades).

You .NETers have to download and reference NuGet-packets for common stuff like SQLite- or SVG- or JSON-support.
All that is available to the VB6-community for a long time now (via RC5/RC6).

There is no language on this planet, which works independent from libraries (even C depends on the C-runtime).
Trying to "exclude them" when comparisons are made, is just nuts.

Olaf

I think you completely missed the point of what I was saying.

There are people in your camp that use this to will claim equivalence between VB6(this includes the IDE, runtime etc) and VB.Net(also inclusing the IDE/runtime tec) or even dare to suggest that VB6 is better which is patently false. Now, what you said here is 100% accurate. I won't dispute any of that. But here is where the rubber meets the road and the disingenuousness comes in. They would use this to prop up their argument while completely ignoring very important details.

Lets take an example. Your libraries must have some kind of List type right? .Net also has a List type. However, .Net supports generics while VB6 does not. How is this important? It means you can create strongly typed lists of any type you want in .Net while you cannot in VB6. Strong typing gives several benefits. You get compile time safety, performance benefits and you get intellisense support. The benefit of intellisense support is compounded when you factor in extension methods, another thing that VB6 lacks. It means you can tack on a bunch of additional functionality while having the IDE make them easily discoverable as if they were part of the List class itself. This is how LINQ is implemented. People care about these things and they are deliberately ignored by the people in your camp.

I don't know if you really want to dispute whether we are better off without compile time type safety and intellisense support.

[Schmidt]

I don't know if you really want to dispute whether we are better off without compile time type safety and intellisense support.

Recently, I gave you already an alternative VB6+RC6 example (in the TwinBasic-thread),
which was doing the exact same thing as your VB.NET generics-example (with less LOC).

In other words, when "generic-behaving List-containers" are already implemented at Lib-Level
the differences become marginal.

Good (short) code is to nearly 90% ensured by "using good libs" (not by language-features).

Olaf

[Niya]

I think you're still missing the point. It's more about the journey than the destination. It feels a lot better actually writing the code in a modern version of Visual Studio than it does in VB6. The process of actually developing the application goes a lot smoother and it's due to multiple factors including the one I mentioned.

[Shaggy Hiker]

I think you're all missing the point: We LIKE to argue.

That's the only point. I really don't care what languages others use. Still, I do like the argument, though I try to restrain myself.

[xiaoyao]

html,js is better than vb6

It's not that less typing is more powerful than a deductive program with more code.
To put it bluntly, it is just a control. .NET installation requires 1G, and development tools require 20Gb.
If you use the MINIBLINK control DLL, the 20M file realizes the function of the Google kernel browser. You can use JQUERY or JSON, or HTML, SVG to describe the UI interface. No need for a line of programming code

[xiaoyao]

IMO, there are two kinds of VB6 in the world
(1) VB6-1998:
The main technologies used by people who use VB6-1998 are: UserControl, Win-APIs, Subclass, DAO, ADO, Access, SQLServer. Some people use Html, XML, and VBScript in small amounts. These people mainly use VB6-1998 to develop and maintain some old Win-Apps.

(2) VB6-2020 (it is 100% compatible with VB6-1998):
In addition to using all the technologies of VB6-1998, the main technologies used by people who use VB6-2020 are: RC5/RC6, ActionScript, Hash-Table, Sqlite (including MemDB), Cairo, Html5, WebKit, WebView, JS-Libs , WebServer, Ngnix, VBFastCGI, JSON, XML, Serialization/Deserialization, Web-APIs, OpenUI5, SPA. These people mainly use VB6-2020 to develop modern Win-Apps and transform old Win-Apps.

Not only many people use VB6-2020 for life, but many people use VB6-1998 for life.

IT'S NOT VB6-2020.
RC6.DLL it's only like a ocx control(vsflexgrid.ocx),or like ado,sqlite.dll

This is just a function extension, just like the early VB.NET did not support websocket, later Microsoft also added the EDGE webview interface.

In fact, we can also package all the controls and all components of .net into an OCX control or COM DLL for VB6 use, or package some DELPHI controls into general OCX controls for VB6 use, or use SVG or web page HTML buttons , The report is packaged for VB6 use.

rc6 did not modify the source code of VB6.exe at all, did not add a control, and did not add an ADD-IN. So it can't even be called VB6 SP7.
If it is used in VB6 SP7, multiple ADD-IN functions should be added, like CDECL support, CARIO control, WEBKIT (CHROME) control, and SVG control.
Then the open source VB controls are fully integrated, which can be searched, downloaded, automatically updated, source code formatted, and junk code can be removed. Just like NPM or Install-Package Microsoft.Web.WebView2 -Version 0.9.515-prerelease



A new version of VB6 requires a lot of changes in the IDE at least, such as the addition of toolbars, menus, etc.
There is a VSTO extension of the excel toolbox, which has a large number of code libraries, code smart tips, powerful toolbars, many buttons and functional areas.

[xiaoyao]

Set objWMIService = GetObject("winmgmts:" & strComputer & "\root\cimv2:Win32_Process")
Set objWMIService = GetObject("winmgmts:" & strComputer & "\root\cimv2")

In essence, RC6.DLL is like VIA or WIM objects, which packs some functions. It has nothing to do with the IDE itself. It cannot parse the VB6 source code, nor can it directly generate a standard DLL, nor can it directly use the VB6 IDE. It supports multi-threaded debugging, and it is impossible to generate 64-bit programs or allow VB6 to support assembly mixed programming.

WebSocket ActiveX Reference Documentation
https://www.chilkatsoft.com/refdoc/x...SocketRef.html

like this:
Chilkat is a cross-language, cross-platform API providing 90+ classes for many Internet protocols, formats, and algorithms.
Some classes need a license:
SSH, SFTP, FTP2, HTTP, REST, Socket/TLS, IMAP, ...

Some are free:
JSON, XML, Cert, PrivateKey, ...
Programmers use Chilkat with:
ASP, C, C++, C++ Builder, C#, DataFlex, dBase, Delphi, Electron, Excel, F

[SearchingDataOnly]

html,js is better than vb6

It's not that less typing is more powerful than a deductive program with more code.
To put it bluntly, it is just a control. .NET installation requires 1G, and development tools require 20Gb.
If you use the MINIBLINK control DLL, the 20M file realizes the function of the Google kernel browser. You can use JQUERY or JSON, or HTML, SVG to describe the UI interface. No need for a line of programming code

Please show an example.

[SearchingDataOnly]

IT'S NOT VB6-2020.
RC6.DLL it's only like a ocx control(vsflexgrid.ocx),or like ado,sqlite.dll

This is just a function extension, just like the early VB.NET did not support websocket, later Microsoft also added the EDGE webview interface.

Yes, like you said, .NET is just a huge control.

In fact, we can also package all the controls and all components of .net into an OCX control or COM DLL for VB6 use, or package some DELPHI controls into general OCX controls for VB6 use, or use SVG or web page HTML buttons , The report is packaged for VB6 use.

rc6 did not modify the source code of VB6.exe at all, did not add a control, and did not add an ADD-IN. So it can't even be called VB6 SP7.
If it is used in VB6 SP7, multiple ADD-IN functions should be added, like CDECL support, CARIO control, WEBKIT (CHROME) control, and SVG control.
Then the open source VB controls are fully integrated, which can be searched, downloaded, automatically updated, source code formatted, and junk code can be removed. Just like NPM or Install-Package Microsoft.Web.WebView2 -Version 0.9.515-prerelease

A new version of VB6 requires a lot of changes in the IDE at least, such as the addition of toolbars, menus, etc.
There is a VSTO extension of the excel toolbox, which has a large number of code libraries, code smart tips, powerful toolbars, many buttons and functional areas.

If someone does this, then you must ask, can the size of this .NET control be reduced to only 10M or 20M, right?

[xiaoyao]

If you just wrap some controls or methods of .NET for VB6, it can achieve about 5M like RC6, even 50M is not a problem.
We just turned the latest .NET technology into vb6 sp7 for VB6.
There is no need to install the 40-100GB VB.NET development environment (VS2019), only 4-40M can use most of the functions you want, which is enough.
This is the advantage of sharpdevelop ide, an IDE with only 18M, beginner developers can replace VS, used to develop some small work or life tools.

Some .NET related controls developed by the company VSflexgrid need to take up 5-10G of space

[xiaoyao]

The VB6 installation package has 200MB, which may occupy 500-800MB after decompression. In fact, most people develop it and only need a simplified version of VB6.
5-10M installation package, only 30M after decompression. Installation only takes 5 seconds (BAT file is automatically installed, mainly to register DLL, OCX control and write registry)

If there are 300 controls in VB.NET and we want to upgrade VB6, we may only need 10-30 common controls.
Such as tabs, DATAGRIDVIEW, ADO.NET, etc.

[Schmidt]

If you just wrap some controls or methods of .NET for VB6, it can achieve about 5M like RC6...

No, that's not at all the same thing.

The 3MB-zipped (of the RC6) includes all the Sub-Dependencies.
Whereas your 5MB .NET-Control-wrapper would still require "the whole 500MB of the .NET-framework" as a Sub-Dependency.

This is the advantage of sharpdevelop ide, an IDE with only 18M...

Also wrong - because it depends on the .NET-framework as well (+500MB Sub-dependencies).
On Linux it is called "Mono-Develop" - and will then require the 220MB Mono-package as a Sub-dependency).

A new VB6-IDE-successor can be developed with RC6 as the sole COM-reference (no OCXes or other COM-libs will be needed).

This means, a future (TwinBasic-based) platform-independent version could be shipped in about 3.5MB zipped (+1..2MB for the TwinBasic-compiler).

On this planet there is not other complete Class-Framework (including GUI) which is as small as the RC-package.
(that's mainly thanks to COM and efficiently written "C-based flat-libs", and the reason why one shouldn't "contaminate" a VB6-successor with "higher-level-VM-based monstrosities")

Olaf

[Shaggy Hiker]

Man, don't GO there. Just let it flow in all it's strange glory.

[yereverluvinuncleber]

We have two of these threads running simultaneously. Could we sustain a third?

I wish we could give reputation on these chit chat threads as I want to give some now ... I always feel very positive when Olaf talks about the VB that is yet to come. It could be called "Olaf's Deep Thought" or the "The Milliard Gargantubrain".

Catchy eh? Desperate for it!

[Schmidt]

...when Olaf talks about the VB that is yet to come...

Not sure, what you mean with "yet to come", because the tB-compiler is already available in a real, testable binary.

It currently contains still too many "little bugs and glitches", but give it a year or two -
and there's a good chance, it'll be as stable as the VB6-compiler (whilst being fully compatible in language- and COM-support).

And that means, that we really only need:
- the tB-compiler (currently in a ~ 1MB binary)
- and a decent Class-Runtime-lib (e.g. RC6, or whatever the tB-folks or others come up with GUI-wise)

And that means, that a fully featured IDE-binary (based on this single ClassLib-reference) would have roughly:
- 500KB-zipped for the IDE-Executable
- 500KB-zipped for all the Icon- and Image-Resources
- 3MB-zipped for the RC6-binaries (or any other COM-based GUI-lib)
- 500kB-zipped for the tB-compiler

Which gives (in sum) about 4.5MB-zipped for the complete IDE-package (without any Sub-Dependencies other than the C-runtimes).

Now compare that with SharDevelop(16MB) + .NET-dependencies(500MB), and you see immediately,
why MS never resorted to "writing big, complicated Apps like MS-Office" in .NET (they use COM for that).

The threads here are pointless, as long as "only language-differences" are discussed.
VB.NET is a nice language, C# is a nice language (I never told otherwise) ... but so is VB6.

The problem lies in the underlying "class-framework-tech", which in case of .NET is a horrible, bloated mess IMO.

Olaf

[Niya]

The problem lies in the underlying "class-framework-tech", which in case of .NET is a horrible, bloated mess IMO.

The interesting thing is that no one is complaining about this but you guys.

[Schmidt]

The interesting thing is that no one is complaining about this but you guys.

Then ask the Kubernetes or Docker-guys, whether they'd prefer to deploy (or startup):
- a compressed Image which is 5MB
- or an Image which is about factor 100 larger

What I'm criticising, is the whole "sloppy approach" we see in software-development and -tech these days
(not only in ".NET-land", but also in "Javascript-land" as far as frameworks are concerned).

Man, there's whole Operating-Systems which include a modern Linux_Kernel 5.10 + a Window-Manager aka Desktop-GUI,
which come in a (VMWare- or VBox-startable) ISO-image of 16MB (not a typo).
http://tinycorelinux.net/

Olaf

[Niya]

Then ask the Kubernetes or Docker-guys, whether they'd prefer to deploy (or startup):
- a compressed Image which is 5MB
- or an Image which is about factor 100 larger

What I'm criticising, is the whole "sloppy approach" we see in software-development and -tech these days
(not only in ".NET-land", but also in "Javascript-land" as far as frameworks are concerned).

Man, there's whole Operating-Systems which include a modern Linux_Kernel 5.10 + a Window-Manager aka Desktop-GUI,
which come in a (VMWare- or VBox-startable) ISO-image of 16MB (not a typo).
http://tinycorelinux.net/

Olaf

I don't disagree with what you're saying but hear me. Why isn't the world complaining about it? Pockets of people here and there are small in comparison to the masses that don't say anything. Why is Windows the most popular OS in the world and not this 16 MB pygmy Linux thing?

What I'm getting at is that this isn't the 90s where megabytes of memory and disk space are at a premium. You have a very 90s mindset, a thing very typical of developers that spent their formative years fighting tooth and nail for every kilobyte of memory they can get in a time when having a gigabyte of anything was mere science fiction.

[Schmidt]

Why isn't the world complaining about it?

That's an argument, along the lines of "one million flies cannot err..."

...typical of developers that spent their formative years fighting tooth and nail for every kilobyte of memory...

What I'm getting at is, that one can play in the same ball-park as e.g. "tinycore-linux" (producing efficient, small high-performance-binaries), without even trying to "save every little bit of memory" (whilst having basically the same development-comfort as other high-level languages and environments)...

My efforts, in supporting a language (and COMponent-tech) which allows that (including porting-efforts to other platforms),
is a nice little side-project for the "remaining few good decades" I still expect to have, if you ask me...

<shrug>

Olaf

[yereverluvinuncleber]

Elegant and compact code bloated by an absolutely massive framework does tend to defeat the object rather.

There is a lot to be said for a small and discrete binary but as these days every Windows system has the .NET framework built in, I suppose it is really a moot point.

.NET will never be used to build an o/s (someday, someone will try one day) and it is not really suitable for fast and compact o/s components.

[Niya]

What I'm getting at is, that one can play in the same ball-park as e.g. "tinycore-linux" (producing efficient, small high-performance-binaries), without even trying to "save every little bit of memory" (whilst having basically the same development-comfort as other high-level languages and environments)...

My efforts, in supporting a language (and COMponent-tech) which allows that (including porting-efforts to other platforms),
is a nice little side-project for the "remaining few good decades" I still expect to have, if you ask me...

<shrug>

Olaf

The thing is, all that is fine and well. But understand, some of us don't have time for all that. We are just going to use what's there. We don't have time to fight with a 20 year old development environment, rolling our own stuff just to save a few megabytes especially since those savings don't make a lick of difference to the bottom line. And the bottom line is the answer to a simple question....does the software work? If it works, no one cares what it was written in.

For example, I wrote a piece of software in a couple days where customers in a store can quickly get the price of an item by scanning it on a tiny computer that was fixed in a wall near the isles. Do you think the client cared that it was written in VB.Net? Do you think he cared one bit that it used a 500 MB framework? No. He doesn't even know how it works. He just knows that it does exactly what he wanted it to do. If I had chosen to do this in VB6, all it would have accomplished is give me a harder time writing it. I wrote the UI in WPF which naturally provides a flexible layout system that scales seamlessly and preserves aspect ratios no matter what size the Form is. In VB6, I would have to write all that logic myself. I don't have time for that. I just want to get it done and over with. This "rolling your own" approach is not viable for those of us that want to be competitive.

You're a back-end low level developer so of course you care about that stuff but most of us are front end guys. The people we write software for don't even know how the software works so we can use the tools that give us the best productivity. The size of the framework literally means nothing in my world. It's literally a non-issue. No one cares one bit about that.

[Niya]

.NET will never be used to build an o/s (someday, someone will try one day) and it is not really suitable for fast and compact o/s components.

.Net was never intended for this purpose. Writing an OS will always be the domain of C/C++ and assembly. Newcomer Rust might also be very suited to this task as well.

[Shaggy Hiker]

What's the dependency load for .NET Core (or .NET 5, these days)?

[SearchingDataOnly]

Although the fighting tired me, my project went well. I'm glad I'm going to have a nice week off.

[Shaggy Hiker]

I'm going to be staggering up streams looking for fish that aren't there.

[SearchingDataOnly]

In some streams (even streams with large drops) in China , there are often small fish called stone-fish, which grow in the crevices of rocks in the water.

I've explored some underground rivers, where the fish grow in the cold river water and only grow 1-2 centimeters a year, but fishermen often catch dozens of kilograms of big fish in the river. The taste of these fish is amazing.

[yereverluvinuncleber]

The size of the framework...No one cares one bit about that.

Well, actually it is a measurable metric and people do care. Just because you don't say "look at the size of my bloat", means that you care enough not to say it - as it is an embarrassment if stated out loud. Put it bluntly, bloat isn't one of .NET's strengths... just an undeniable characteristic.

When someone comes up with an efficient language, size matters and it is something to be boasted about whilst the bloat of others is laughed at. Bloat is implicit in many Microsoft offerings and especially so in .NET. It's known and it is a given.

Perhaps we don't go on about it any more because we've experienced it and heard it so often, as a result we just accepted it. But still, the .NET framework is known as bloatware.

When I look at fat Yanks in the videos, fat policemen arresting fat idiots in supermarkets full of fat people, they have clearly all become used a different type of bloat. Just because you are used to it doesn't mean it is good in all circumstances. So, you have to accept it is a negative, say so and move on, don't cover it up by saying it's fine, we like it bloat.

You can't just wave away a negative like that. .NET is massive, bloated if you will, in comparison. You can chalk that win up to the languages that are slimmer. VB6 in this case.