Making It Better: ASP.NET with Visual Basic 14(blogs.msdn.com)
blogs.msdn.com
Making It Better: ASP.NET with Visual Basic 14
http://blogs.msdn.com/b/webdev/archive/2015/04/23/making-it-better-asp-net-with-visual-basic-14.aspx
6 comments
It is unclear to me why msft is still investing in VB.net. C# is a better mainline language; F# is a better bleeding edge language. VB.net seems like a holdover from the ASP days, and honestly is riddled with issues (no differentiation between assignment and equality, it's 2015 btw).
Because a lot of businesses have codebases in VB. My company moved to C# for new development long ago, but we still have maybe 20% of our codebase in VB. It's not worth the time it would take to convert it, so it stays in VB. It's nice that Microsoft continues to support VB for companies like mine where being required to move to C# would cause a lot of problems for us.
I can see why VB is used in large codebases for legacy apps. What I don't understand is continuing to work on the language and releasing v14 with improvements. That's just encouraging legacy code to stay the way it is, albeit with some new sugar.
Take binary. Open in IL Spy, switch language to C#. Done.
And lose all code comments, revision control history, etc. Not to mention the risk of doing that on a large scale.
I've done this before on a large scale (vb=>c#). You don't lose revision control history, thats still in the history for the previous file. If you're doing things in vb that can't be done in c# (there are a few things), you're writing bad code.
The risk is greater in using bad technology / having legacy code.
The risk is greater in using bad technology / having legacy code.
You can use telerik converter. It's free and it works pretty well. http://converter.telerik.com
> no differentiation between assignment and equality, it's 2015 btw
F# has about as much differentiation between assignment and equality as VB, although it is nicer in F#.
====================
Now, I haven't used VB in almost 10 years, and have programmed in C# and F# for about a decade (even before F# was included in VS). But, once you get past the verbosity, VB is actually a slightly more powerful language than C# (my most favored language).
VB has more query comprehension operators.
VB has a more elegant way of wiring up events using the `Handles` keyword.
VB has XML literals. Once nice trick is that you can use them to simulate better string interpolation.
VB has a more robust way of handling exceptions (though C# will gain this in the next version).
VB allows you to use automatic type propagation ("type inference") with lambda expressions. Not that big of a deal, but coming from F#, I'm always slightly annoyed that I can't use `var` with lambdas in C#.
VB's `Select..Case` is more powerful than C#'s `switch`
The `Like` operator.
String concatenation via the "&" is nicer in VB
Late binding is nicer in VB (though arguably more powerful in C# 4+).
I prefer C#'s way of doing overload resolution (start with the most derived class first), but some of my colleagues have exploited VB's method of overload resolution (consider all methods in the inheritance hierarchy at once) to create some elegant code. I've been meaning to investigate it.
F# has about as much differentiation between assignment and equality as VB, although it is nicer in F#.
====================
Now, I haven't used VB in almost 10 years, and have programmed in C# and F# for about a decade (even before F# was included in VS). But, once you get past the verbosity, VB is actually a slightly more powerful language than C# (my most favored language).
VB has more query comprehension operators.
VB has a more elegant way of wiring up events using the `Handles` keyword.
VB has XML literals. Once nice trick is that you can use them to simulate better string interpolation.
VB has a more robust way of handling exceptions (though C# will gain this in the next version).
VB allows you to use automatic type propagation ("type inference") with lambda expressions. Not that big of a deal, but coming from F#, I'm always slightly annoyed that I can't use `var` with lambdas in C#.
VB's `Select..Case` is more powerful than C#'s `switch`
The `Like` operator.
String concatenation via the "&" is nicer in VB
Late binding is nicer in VB (though arguably more powerful in C# 4+).
I prefer C#'s way of doing overload resolution (start with the most derived class first), but some of my colleagues have exploited VB's method of overload resolution (consider all methods in the inheritance hierarchy at once) to create some elegant code. I've been meaning to investigate it.
vb is not a more powerful language than c#. c# exposes more core features of the clr than vb, which is a more fair basis for "power". richter didn't write "clr via vb", if you want more clues to this. it has a lot of what i would call terrible language design bolted onto an already bad language.
key things in c# not found in vb: unsafe blocks and pointer manipulation, partial interfaces, @ strings (multi-line string declarations), checked/unchecked arithmetic, multiple conditionals in for loops, the coalesce operator.
c# will generally be faster for numeric computing because of unchecked arithmetic by default.
problems with vb: having a case insensitive language is a nightmare. type coercion is a terrible idea and leads to weird bugs. the Is operator in vb is very confusing to its c# counterpart. properties as reference is a nightmare for bugs, similarly if you're going to have a prop with a parameter just use a method.
re your list:
`handles` and += event are the same underlying IL. honestly i prefer += (and -= to unhook), it's a weird dissociation to have the event wiring away from declaration.
xml literals are cool if you're using xml a lot, which not many people are these days. It's weird to have that as a language level priority vs. leaving it to libraries.
the lambda inference is a feature not a bug; it's because they could map to func, predicate or action with a similar generic signature (and wildly different intrinsics)
key things in c# not found in vb: unsafe blocks and pointer manipulation, partial interfaces, @ strings (multi-line string declarations), checked/unchecked arithmetic, multiple conditionals in for loops, the coalesce operator.
c# will generally be faster for numeric computing because of unchecked arithmetic by default.
problems with vb: having a case insensitive language is a nightmare. type coercion is a terrible idea and leads to weird bugs. the Is operator in vb is very confusing to its c# counterpart. properties as reference is a nightmare for bugs, similarly if you're going to have a prop with a parameter just use a method.
re your list:
`handles` and += event are the same underlying IL. honestly i prefer += (and -= to unhook), it's a weird dissociation to have the event wiring away from declaration.
xml literals are cool if you're using xml a lot, which not many people are these days. It's weird to have that as a language level priority vs. leaving it to libraries.
the lambda inference is a feature not a bug; it's because they could map to func, predicate or action with a similar generic signature (and wildly different intrinsics)
I probably could have been more clear, but by "power" I was talking about the abstractions afforded by the language. C# also exposes more CLR features than F#, yet it usually clear and uncontroversial when someone says that F# is more powerful than C#; I've never heard people talk about power in terms of performance.
But, it's not like C# ever afforded a strict superset of CLR features: until recently, VB exposed exception filters while C# did not, and that is arguably a more important feature in day-to-day programming than pointers and unsigned integers.
I also forgot to mention that VB's lambda expressions are more powerful because they can contain iterators.
Now, don't misunderstand me: I love, love, love C#. After grokking Haskell's type classes (and Scala's traits), I even slightly prefer C# over F# since the former can more easily simulate those features. But, lets not pretend that VB didn't ever having any significant advantages over C# for day-to-day programming. Even today, VB is probably a nicer environment for Ruby and Python programmers than C#.
But, it's not like C# ever afforded a strict superset of CLR features: until recently, VB exposed exception filters while C# did not, and that is arguably a more important feature in day-to-day programming than pointers and unsigned integers.
I also forgot to mention that VB's lambda expressions are more powerful because they can contain iterators.
Now, don't misunderstand me: I love, love, love C#. After grokking Haskell's type classes (and Scala's traits), I even slightly prefer C# over F# since the former can more easily simulate those features. But, lets not pretend that VB didn't ever having any significant advantages over C# for day-to-day programming. Even today, VB is probably a nicer environment for Ruby and Python programmers than C#.
By what criteria are C# and F# better than VB.Net? VB is more readable (not operator, inherits and implements keywords, etc), is functional, dynamic, compiles to the same byte code, and has useful features the other two don't (e.g. project-level imports). It's a lot easier for people with a Basic or Pascal background to use than either of the other two.
Are the only things going for C# and F# that they're your favourite languages? What makes your story more compelling than someone who likes VB.Net more than the others?
Are the only things going for C# and F# that they're your favourite languages? What makes your story more compelling than someone who likes VB.Net more than the others?
What I don't like about VB.NET is that it makes knowledge of what namespace you are in very difficult to determine. Such a basic and integral part of the structure of large programs is a huge failure, IMO.
I've programmed VB3 to VB6 and then when .NET arrived, I unfortunately had to do a few large apps in VB.NET. Let this fucking dog die. There's nothing worthwhile in this language. MS originally was not planning on bringing the retardedness in VB into .NET (I had access to pre-releases of it and message boards where VB.NET was being discussed). A bunch of whiny cunts who no longer matter in the world of programming at all, bitched and moaned about the poor VB programmers who would be soooo confused, that MS conceded to their demands.
I think the best BASIC version is vbScript. It has the cleanest syntax of all programming languages and is very simple. I wish they would make something like Node.JS but width vbScript. Promises could look like this:
CALL asyncFunction THEN callback
And make it easier to compile libraries and modules for it.
CALL asyncFunction THEN callback
And make it easier to compile libraries and modules for it.
I had to check to see if this was a new account and you were just trolling. Not convinced you're still now. ;)
Admittedly I started with ASP (classic) back in the day with VBScript. But that's precisely the reason I won't ever touch it again. I only see it now in legacy sites and it is horrible to have to touch, imho that is.
Admittedly I started with ASP (classic) back in the day with VBScript. But that's precisely the reason I won't ever touch it again. I only see it now in legacy sites and it is horrible to have to touch, imho that is.
I've also seen some messy code in ASP-classic. But most is just stupidly simple. And I like stupidly simple code. You can read and understand vbScript code faster then you can enjoy a text fiction. You can pick up a random guy/girl on the street and have him/her write vbScript within minutes.
It's a stupid little language, but still very high level. And can get things done.
[deleted]
Please, for the love of god. Take Visual Basic outside and put a bullet through its head. Why anyone would choose VB over C# is beyond my wildest comprehension.
There are many very large legacy code bases that sit in many flavours of VB that aren't cost effective to rewrite or migrate. I manage several such products. This provides them a continued way forward with updated features.
MS wouldn't still be investing in it if they weren't seeing uptake on the product, even if it may not be the first choice among some developers.
MS wouldn't still be investing in it if they weren't seeing uptake on the product, even if it may not be the first choice among some developers.
Why would you want to do that? When I was a student, I had this little old car that never let me down. Then I made money and bought a new car. The old car was still running fine, and another poor student wanted a car, so I gave it to him for free. He said if the car is still running he would give it to another poor student in 3 years. He did.
If I would have taken my car to the junk yard, what good would it have done?
If I would have taken my car to the junk yard, what good would it have done?
Irrelevant analogy. The financial cost of choosing C# over VB is zero.
For the same reason anyone would choose C# over F# (also beyond my comprehension) ;)
The difference in power and safety between VB.NET, Java, and C# is minimal. Meanwhile, F# is leagues ahead. These days I see someone using C# who looks down on Java or VB.NET as a sibling laughing at their identical twin.
The difference in power and safety between VB.NET, Java, and C# is minimal. Meanwhile, F# is leagues ahead. These days I see someone using C# who looks down on Java or VB.NET as a sibling laughing at their identical twin.