At that time, I only had a C/C++ compiler that I didn't know how to use (because I had no internet and no standard library / STL docs). The MSDN library that was preloaded in the cd was an eye opener, and the visual components made it easy to experiment.
I would probably work in a restaurant today, if it wasn't for that cd.
Then the start up went bust and I was back to C++ before any newer version of VB came out. They really got reusable components right. I've never had an experience since where there is such a huge jump in productivity with a new technology.
I absolutely loved the language, coming from a Java/C++ education in college.
Then, my next job, it was a mix of VB.NET, PHP, and C# (custom software shop). I did all three and decided that C# was where I wanted to be. I simply found that VB.NET was too "wordy" with all of the "If/End If" and "Get/End Get" and "List(of Foo)". I just found it easier to follow with if(eq){}, Get{}, and List<Foo>.
Simply one's own taste, I suppose.
I got my first serious code written in VB6. It is the first IDE that I bought with my own hard earned money as a kid and it was great. I still dream of a day when there is a language/framework that makes development that easy again.
I also find it interesting now how much of the professional IDE features that Visual Studio Community Edition opens up for free to students and non-profits and open source enthusiasts.
It's easy to look back with nostalgia at our own paths (mine was QBASIC, [saved up for] VB3, with dalliances into things like DJGPP, then a lot of HTML, PHP, and very early era JS), but let's not overlook that we live in an interesting era with interesting new paths (Small Basic, Squeak, Python, modern JS, etc).
My biggest dream is the ability to have a cross platform Mobile App/Web App ecosystem. Something that you can use from any device with a virtually equal experience. Not so easy at the moment, especially for things that need to be charged for... app store fees are way to big in my opinion. /rant
That led me into considering Computer Science over Civil Engineering in college and have been programming ever since :)
What did you build back then?
(it's awesome)
Design-wise, this is well justified hate - I stress "design-wise".
In the bigger picture, the ease of the framework attracted plenty of unqualified masses, therefore there is surely lots of people with a painful past of VB6 applications maintenance.
Of course I don't want to detract from VB6, as at the same time, it made very simple (or as simple as possible) for almost anybody to create applications - I'm not aware of any other language/framework which accomplished this.
I'm also glad they keep that product alive, because in addition to the many positive aspects meantioned in the comments it makes sure that the CLR evolution takes into consideration the aspects needed for a more broad variety of languages.
#TrollsArePeopleToo :-)
So while the world has some cool stuff that it might not otherwise I'm not sure the world is better off for it.
I would donate many beers if they halted all VB work and put those guys and gals on F#!
For example, VB Select Case and C# switch work nothing like each other.
There's so much truth in this.
Telerik has a online conversion tool[1] you can us, which can batch convert entire code-bases. But a 1-to-1 straight conversion cannot be done with 100% accuracy, and the tool will tell you everywhere it struggles to figure out the right C# equivalent for the corresponding VB.Net code.
I've used this tool in the past to "eliminate" the last remnants of VB-code in our organization. And when you do a job like that, on that scale, you definitely notice the differences.
A quick list of things you can expect to cause troubles (from memory and may not be 100% accurate):
- The difference in VB global/C# static semantics.
- The (default & overuse) of late-binding in a typical VB codebase. (While that wasn't an option for me back then, this can now be overcome by using "dynamic" everywhere, but that's hardly idiomatic C#)
- VB Modules can cause issues.
- For a full conversion, you'll typically have to rewrite all code using the functions and operands only found in the Microsoft.VisualBasic namespace. Not all these have straight up C#/BCL replacements.
Etc etc.
For being superficially so similar, a conversion job is actually much more work than you would typically imagine.
The rest of your points all sound like bad practice anyway so hopefully people are already avoiding them.
Welcome to the real world. I can tell you're new here :)
I just started typing this list off the top of my head and every time I typed something out I could think of one more thing. And these are just the ones I remember, so they're probably the ones that were annoying to work around in the compiler.
Companies generally spend a lot more money maintaining legacy code than they do creating new code.
At this point anything written in VB of any flavor is legacy. But it still needs to be supported. And as long as that is true, Microsoft has reason to support it.
From a management point of view, it means throwing away a large amount of money and then spending more money to replace the old code base, accompanied by the usual risk of whooshing deadlines and all that.
To a programmer it might be easy to see that a rewrite will save the company money in the long run, that can be difficult to sell.
Another big feature is code layout being more compact and consistent than in C# codebases.
But what's the real purpose of VB today? No matter how you look at it, either C# is just as easy as VB.net or VB.Net is just as complicated as C#. It seems just wordier and redundant.
Regarding VB, the language is used by many people whose main occupation is not software development, and even for those doing software there are many who find C# or similar looking languages aren't a panacea (I do, and have around 15 years of C# experience).
In some cases VB is also less redundant than C#, it has better type inference for example.
I'm sure plenty of pascal/delphi developers are also fine without C#.
You should understand that other languages than C/C++/C# make different syntax choices, and it is not hurting C# in anyways that such language exist and prosper.
Note that I had a lot of prejudice against VB but I came back from that perspective, and in the meantime, I feel additions to C# language push it in territory where the syntax is getting really noisy / clumsy (I've picked up F# so I use that it as a metric).
But VB.NET never really seemed to have a point. Why develop a backwards-incompatible language with all the warts of VB? If it was originally much more closely compatible with VB6, you probably still wouldn't be stuck with VB6 code in 2017. And if it didn't try to be so but not quite VB6-like, it would make for better beginners and financial systems language.
I think the sneering is more driven by the sorts of people that think that programming shouldn't be easy/accessible to the untrained masses. There seems to be a lot of coding elitism/machismo/masochism out there.
The untrained masses have a way into getting hooked on tools that are harder but offer no benefit compared to many other stuff available around. It is very easy to hate those tools.
Having been a teacher's assistant on courses the answer is very clearly and emphatically: Yes.
It's easy to discount the accessibility of a syntax when you are already at the top of the learning curve, but the Algol family will always be tougher to teach/learn than the BASIC family. Punctuation is harder than you think. (Aside: partly why I think JavaScript is actually the easiest to teach in the Algol-inspired family for the benefit of having optional semicolons alone.)
«Or that any of those is less accessible than VB6?»
That's not an anecdote I have first hand experience with. I think there are a lot of cranky VB6 developers that sneer that VB.NET is worse and so much harder than VB6, but my gut tells me that that may be more the relative learning curve/gap in moving from VB6 to VB14. I don't think it is anywhere near as representative of the accessibility of learning VB14 as a first language. (I also think the more important question is the accessibility of moving from Office VBA to VB14, as it still seems for a lot of disciplines Office VBA is the most important first step towards programming.)
«The untrained masses have a way into getting hooked on tools that are harder but offer no benefit compared to many other stuff available around.»
I'm not sure what you are getting at here. I don't think VB.NET is any "harder" than C# and while VB.NET might not offer "more benefit" than C# (assuming you discount syntax/accessibility entirely as a benefit), it certainly is no worse than C# as a tool for a person to use.
It was not clear by the comment, but I was not talking about VB.Net. This one is no worse than C# or Java, and I also don't see many people stuck on it.
That phrase applies much more to VB6 (even more in the day), and some others like PHP, or, going out of the generic domain MathLab (that used to suck, a lot, but doesn't anymore), and VBA.
As I remember it, there were lots of angry VB6 developers when Microsoft discontinued the "old" VB and told them to migrate to VB.Net. I vaguely remember there was some kind of online petition (although it was a long time ago, my memory might be playing tricks on me).
[0] https://visualstudio.uservoice.com/forums/121579-visual-stud...
VBA 6 is exactly the same language as VB 6, with the same IDE. VBA 7 (the current version) adds some new types to support 64-bit mode.
(I'm currently maintaining a bunch of VBA code in a third-party application that uses it for scripting.)
It wasn't quite "open the site in the new IDE and fix all the squiggly underlined bits" but that was a substantial part of the mechanical effort.
Starting from nothing? Skip VB.Net and start with C# (assuming you're set on the CLR). Starting from VB6 and a novice programmer? VB.Net has advantages over C#, IMO.
It is by the way an act of cruelty from Microsoft to only provide office users with a 20 year old language that hasn't been updated since the end of the 90s... What happened to VSTA??
Office has support for multiple languages, not just VBA. The three that spring to mind are JavaScript, M and DAX.
http://stackoverflow.com/a/40727011
Also, if you don't mind using 3rd party solutions, you've got other options:
The side perk that I can relatively easily convert to C# later if I have to is there. But yeah, as much as I've worked in C style languages before, I find VB much more comfortable.
I used VB6 for all my Windows applications when my alternative was to use C++ + MFC or Win32 which was significantly more difficult. There was an actual advantage. Today, there is no advantage whatsoever.
(I agree that VB6 is a relic of the past that is no longer a viable programming platform.)
Well, other people in accounting borrowed the book and built more and more features into this program, and created a couple other similar programs.
At no time did they consider 'maybe we should bring some real programmers into this' or re-write any of the code, and now they're stuck on this code and they have 4 'very bad' programmers working on it. It's a huge buggy mess with every bad programming practice you can think of.
There's a reason for the sneering. One of those I've virtually completely rewritten in C# and the code base is now like 30% of the TLOC. Not because of the language, but because of the type of programmer who started a new project in VB.Net in the last 5 years.
For all intents and purposes the languages are virtually interchangeable, though C# is generally more succinct and somehow "better" to me. I don't even really think about it when switching between the two.
UK projects, for reference, where .Net has always penetrated further than Java.
I also still get an inordinate amount of calls because my linked in profile list VB.net asking to 'upgrade' a project from VB.Net to C#. Then again, the salesforce offers I get too... Ugh, much worse than VB.Net.
Allowing it to evolve on it's own, rather than being C#'s ugly little brother.
But I can't argue with the fact that it did do it's job for a long time. And I've learned to not underestimate the value of something that is known to work.
It might have "Basic" in it's name but the complexity of smashing old-school VB syntax and semantics with .NET syntax and semantics has not made for a very beginner friendly language. It's more complex than C# (excluding some of the newest C# features). It's just painted over with a more English syntax to appear beginner friendly.
The one thing in my opinion that has been preserved from VB6 and is dangerous as ambiguous semantically is the following:
Dim x as Integer
For i = 1 to 10
Dim x as integer
x += 1
Next
That to me is unintuitive.
Basically you answered your own question. VB.NET has all the same features as C#, evolved over the same time, but VB.NET has a bunch of additional "crap" held over from a language and environment that it isn't compatible with anymore. That's how it's more complex.
You didn't even consider in your example that you declare variables with the keyword "Dim". Do you even know why? It's meaning has almost been lost to history and makes little sense for what it's used for now.
In fact even before type inference I always thought that Dim was a better idea. It was kind of absurd to be forced to write your type twice.
Dim D as New Dictionary(Of String, String)
Dictionary<string, string> D = new Dictionary<string, string>();Var means variable.
In VB6/VBA, the Dim New syntax actually had different semantics; it would create the instance on first access instead of when the Dim statement was executed. It also had the fun side-effect that setting the variable to Nothing would destroy the instance but anytime you accessed that variable it would just create a new one. Irrelevant now, I guess, but still a nice bit of trivia.
var d = new Dictionary<string, string>();
`Dim`, a poorly worded keyword by today's standards, is a perfect example of the kind of leftover crap that C# doesn't have today that VB still does have.
"Try VB.Net, the perfect language choice for stroke victims."
All joking aside, VB.NET has solved a lot of problems for companies.