3 ms·

> 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

> 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.

bigdubs 12y ago
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)
- noblethrasher 12y ago
  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#.

bigdubs 12y ago

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)

noblethrasher 12y ago
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#.