Related
I've been looking quite a bit at Mr. Skeet's blog on how to re-implement LINQ.
In particular, he states that the code:
var list = (from person in people
where person.FirstName.StartsWith("J")
orderby person.Age
select person.LastName)
.ToList();
is translated to methods that are extension methods that are provided by the LINQ library:
people.Where(person => person.FirstName.StartsWith("J"))
.OrderBy(person => person.Age)
.Select(person => person.LastName)
BY THE COMPILER.
My question is, how does one impress the bigwigs enough with a library to cause them to allow the language to change to support the library? Or were those words already reserved before LINQ came along?
Grab the Mono C# Compiler - it's open source and you can do whatever language modifications you want and which .net supports, e.g., use enums as generic constraints, create methods that return references to value types (public ref int Max(ref int x, ref int y) { if (x>y) return ref x; else return ref y; }), that have protected or internal visibility etc.
Of course, you are then creating an incompatible derivate of C#, but if you push it hard enough then people might like it.
The other option: Start a blog, come up with some really good use cases for it, possibly a sample implementation in a .net language or using a customized compiler, show what problem it solves and why this would be a big win that justifies the cost that goes into specifying, designing, developing, testing and documenting of the feature.
I highly doubt the compiler developers would implement syntax extensions for just any library. If you really wanted language-level integration, you could develop a pre-processor that transforms your custom syntax into valid C#. That's essentially what the compiler does with LINQ anyway (as you pointed out in your question).
Of course, you would lose things like auto-complete and syntax highlighting in Visual Studio, but that could be fixed with an extension.
Some languages allow to extend their syntax and semantics. The closest to C# is Nemerle (and it even supports a safe subset of C#, which you can, in turn, extend as you like), but the same can be done with almost any Lisp, for example. So, if you're using a language powerful enough, you don't need to "impress" anyone - any library can add new functionality to a language itself.
There were rumors that the next C# will provide some rudimentary metaprogramming support as well, but I could not find any specifics.
It is possible but it will be hard and they'll probably reimplement the idea to better fit their language constructs. The new async feature is similar to a library called AsyncEnumerator for example but they are building everything to better suit the language. The keywords for LINQ were not reserved in advance but they are contextual keywords meaning that there can be identifiers that match this keywords out of the LINQ context. When the compiler detects a LINQ construct it goes into LINQ mode where these keywords are actual reserved words.
I wrote some queries in C# using LINQ. After a while, I started using Haskell a little bit, which is a functional programming language (a not so popular one), and for me it seems that both of them are almost the same thing. But I am unsure about this. Please, if someone has used them more than me, could they tell me if they are almost the same thing regarding principles in programming ?
Also, could LINQ be considered functional programming ?
Thanks.
for me it seems that both of them are almost the same thing. But I am unsure about this. Please, if someone has used them more than me, could they tell me if they are almost the same thing regarding principles in programming ?
Yes, the design of LINQ query comprehensions was heavily influenced by the design of Haskell. Haskell expert Erik Meijer was on the C# language design committee when we designed LINQ; his insights were very valuable. (I joined the design team at the end of this process, so unfortunately I did not get to participate in all the interesting twists and turns the design went through over the years; it started being much more traditional OO than it ended up!)
If you've recently done a serious exploration into Haskell then you're probably becoming familiar with the idea of a monad. The LINQ syntax is designed specifically to make operations on the sequence monad feel natural, but in fact the implementation is more general; what C# calls "SelectMany" is a slightly modified form of the "Bind" operation on an arbitrary monad. You can actually use query comprehension with any monad, as my colleague Wes describes here, but doing so looks pretty weird and I recommend against it in production code.
Also, could LINQ be considered functional programming ?
Yes, LINQ is heavily influenced by ideas from functional programming. It is designed to treat functions as first-class objects, to emphasize calculation over side effects, and so on.
It may be worthwhile to take a look at Erik Meijer Lecture. Here's the description for it.
We kick off C9 Lectures with a journey
into the world of Functional
Programming with functional language
purist and high priest of the lambda
calculus, Dr. Erik Meijer (you can
thank Erik for many of the functional
constructs that have shown up in
languages like C# and VB.NET. When you
use LINQ, thank Erik in addition to
Anders).
It is true that C# has gained some aspects of functional programming. First and foremost is the lambda statement, implemented as an anonymous delegate. You now no longer need to define a method as belonging to an object, and you can define a method in a similar fashion as any other variable. This allows for many functional-type constructs:
var mult = (a,b)=>a*b;
var square = (a)=>Math.Pow(a,2);
var multandsquare = (a,b)=>square(mult(a,b));
//None of the above give a lick about what a and b really are, until...
multandsquare(5,3); //== 225
The basic paradigm of functional programming - that basically anything you can tell a computer to do can be told in terms of higher-order functions - can be applied to C# programs, especially now that C# actually has higher-order functions. The compiler will force you to have at least one class with at least one public main method (that's just how OO works), but from that point you can define pretty much everything only in terms of functions (def: a subclass of "methods" that take N parameters and produce 1 output without "side effects") instantiated as lambdas.
Linq does have some functional structure. Basically its method-chain paradigm is an example of monadic processing, which is how sequences of operations are structured through operation encapsulation in functional languages (and now in C#). Calling a Linq method on an IEnumerable returns another IEnumerable, which is really a different concrete class which contains a handle to the source Enumerable and some lambda to perform. You can replicate it in a functional language very simply; it's a tuple of the source (itself a tuple of the current element and everything else) and a function to perform that transforms the source tuple into the result, one element at a time (which in Linq, as it would be implemented in a functional language, is a nesting of some operation into a defined "rollup" function). Call a method that must produce an actual answer (a concrete typed result), and all these functions are evaluated sufficiently to produce the desired result.
Also could LINQ be considered
functional programming?
LINQ implies a functional style in that it resembles, for instance, a SQL select, which is read-only in principle. However, because the LINQ clauses in .NET are implemented by plain-old CLR routines, there is nothing to prevent LINQ expressions from modifying state.
Haskell, on the other hand, is a "pure" functional language, so expressions cannot modify global state. Although it is possible to perform IO and graphics operations, these are carried out using a very different idiom from anything in .NET — including F#, which lets you drop into a procedural style more or less transparently.
I am creating a scripting language to be used to create web pages, but don't know exactly where to begin.
I have a file that looks like this:
mylanguagename(main) {
OnLoad(protected) {
Display(img, text, link);
}
Canvas(public) {
Image img: "Images\my_image.png";
img.Name: "img";
img.Border: "None";
img.BackgroundColor: "Transparent";
img.Position: 10, 10;
Text text: "This is a multiline str#ning. The #n creates a new line.";
text.Name: text;
text.Position: 10, 25;
Link link: "Click here to enlarge img.";
link.Name: "link";
link.Position: 10, 60;
link.Event: link.Clicked;
}
link.Clicked(sender, link, protected) {
Image img: from Canvas.FindElement(img);
img.Size: 300, 300;
}
}
... and I need to be able to make that text above target the Windows Scripting Host. I know this can be done, because there used to be a lot of Docs on it around the net a while back, but I cannot seem to find them now.
Can somebody please help, or get me started in the right direction?
Thanks
You're making a domain-specific language which does not exist. You want to translate to another language. You will need a proper scanner and parser. You've probably been told to look at antlr. yacc/bison, or gold. What went wrong with that?
And as an FYI, it's a fun exercise to make new languages, but before you do for something like this, you might ask a good solid "why? What does my new language provide that I couldn't get any other (reasonable) way?"
The thing to understand about parsing and language creation is that writing a compiler/interpreter is primarily about a set of data transformations done to an input text.
Generally, from an input text you will first translate it into a series of tokens, each token representing a concept in your language or a literal value.
From the token stream, you will generally then create an intermediate structure, typically some kind of tree structure describing the code that was written.
This tree structure can then be validated or modified for various reasons, including optimization.
Once that's done, you'll typically write the tree out to some other form - assembly instructions or even a program in another language - in fact, the earliest versions of C++ wrote out straight C code, which were then compiled by a regular C compiler that had no knowledge of C++ at all. So while skipping the assembly generation step might seem like cheating, it has a long and proud tradition behind it :)
I deliberately haven't gotten into any suggestions for specific libraries, as understanding the overall process is probably much more important than choosing a specific parser technology, for instance. Whether you use lex/yacc or ANTLR or something else is pretty unimportant in the long run. They'll all (basically) work, and have all been used successfully in various projects.
Even doing your own parsing by hand isn't a bad idea, as it will help you to learn the patterns of how parsing is done, and so then using a parser generator will tend to make more sense rather than being a black box of voodoo.
Languages similar to C# are not easy to parse - there are some naturally left-recursive rules. So you have to use a parser generator that can deal with them properly. ANTLR fits well.
If PEG fits better, try this: http://www.meta-alternative.net/mbase.html
So you want to translate C# programs to JavaScript? Script# can do this for you.
Rather than write your own language and then run a translator to convert it into Javascript, why not extend Javascript to do what you want it to do?
Take a look at jQuery - it extends Javascript in many powerful ways with a very natural and fluent syntax. It's almost as good as having your own language. Take a look at the many extensions people have created for it too, especially jQuery UI.
Assuming you are really dedicated to do this, here is the way to go. This is normally what you should do: source -> SCANNER -> tokens -> PARSER -> syntax tree
1) Create a scanner/ parser to parse your language. You need to write a grammar to generate a parser that can scan/parse your syntax, to tokenize/validate them.
I think the easiest way here is to go with Irony, that'll make creating a parser quick and easy. Here is a good starting point
http://www.codeproject.com/KB/recipes/Irony.aspx
2) Build a syntax tree - In this case, I suggest you to build a simple XML representation instead of an actual syntax tree, so that you can later walk the XML representation of your DOM to spit out VB/Java Script. If your requirements are complex (like you want to compile it or so), you can create a DLR Expression Tree or use the Code DOM - but here I guess we are talking about a translator, and not about a compiler.
But hey wait - if it is not for educational purposes, consider representing your 'script' as an xml right from the beginning, so that you can avoid a scanner/parser in between, before spitting out some VB/Java script/Html out of that.
I don't wan to be rude... but why are you doing this?
Creating a parser for a regular language is a non-trivial task. Just don't do it.
Why don't you just use html, javascript and css (and jquery as someone above suggested)
If you don't know where to begin, then you probably don't have any experience of this kind and probably you don't have a good reason, why to do this.
I want to save you the pain. Forget it. It's probably a BAD IDEA!
M.
Check out Constructing Language Processors for Little Languages. It's a very good intro I believe. In fact I just consulted my copy 2 days ago when I was having trouble with my template language parser.
Use XML if at all possible. You don't want to fiddle with a lexer and parser by hand if you want this thing in production. I've made this mistake a few times. You end up supporting code that you really shouldn't be. It seems that your language is mainly a templating language. XML would work great there. Just as ASPX files are XML. Your server side blocks can be written in Javascript, modified if necessary. If this is a learning exercise then do it all by hand, by all means.
I think writing your own language is a great exercise. So is taking a college level compiler writing class. Good luck.
You obviously need machinery designed to translate langauges: parsing, tree building, pattern matching, target-language tree building, target-language prettyprinting.
You can try to do all of this with YACC (or equivalents), but you'll discover that parsing
is only a small part of a full translator. This means there's a lot more work
to do than just parsing, and that takes time and effort.
Our DMS Software Reengineering Toolkit is a commercial solution to building full translators for relatively modest costs.
If you want to do it on your own from the ground up as an exercise, that's fine. Just be prepared for the effort it really takes.
One last remark: designing a complete language is hard if you want to get a nice result.
Personally I think that every self-imposed challenge is good. I do agree with the other opinions that if what you want is a real solution to a real life problem, it's probably better to stick with proved solutions. However, if as you said yourself, you have an academic interest into solving this problem, then I encourage you to keep on. If this is the case, I might point a couple of tips to get you on the track.
Parsing is not really an easy task, that is way we take at least a semester of it. However, it can be learned. I would recommend starting with Terrence Parr's book on language implementation patterns. There are many great books about compiling and parsing, probably the most loved and hated been the Dragon Book.
This is pretty heavy stuff, but if you are really into this, and have the time, you should definitely take a look. This would be the Robisson Crusoe's "i'll make it all by myself approach". I have recently written an LR parser generator and it took me no more than a long weekend, but that after reading a lot and taking a full two-semesters course on compilers.
If you don't have the time or simply don't want to learn to make a parser "like men do", then you can always try a commercial or academic parser generator. ANTLR is just fine, but you have to learn its meta-language. Personally I think that Irony is a great tool, specially because it stays inside C# and you can take a look at the source code and learn for yourself. Since we are here, and I'm not trying to make any advertisement at all, I have posted a tiny tool in CodePlex that could be useful for this task. Take a look for yourself, it's open-source and free.
As a final tip, don't get scared if someone tells you it cannot be done. Parsing is a difficult theoretical problem but it's nothing that can't be learned, and it really is a great tool to have in your portfolio. I think it speaks very good of a developer that he can write an descent-recursive parser by hand, even if he never has to. If you want to pursuit this goal to its end, take a college-level compilers course, you'll thank me in a year.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
What in C#.NET makes it more suitable for some projects than VB.NET?
Performance?, Capabilities?, Libraries/Components?, Reputation?, Reliability? Maintainability?, Ease?
Basically anything C# can do, that is impossible using VB, or vice versa.
Things you just have to consider when choosing C#/VB for a project.
C# and VB are basically the same however there are some minor differences. Aside from the obvious grammar differences you have the following differences:
C# can call unsafe code
VB has optional parameters (Coming in C#4.0)
VB is easier to use when making late bound calls (Coming in C# 4.0) This and number make 2 make using VB to do office automation much cleaner.
VB has a bunch of "helper" functions and class like the My namespace; however, all of this are accessible to C#
VB is case insensitive
C#'s syntax follow a similar grammar to c and java, which make it a much more comfortable transition from those languages, where as VB can be more comfortable to VB users. As far performance, and libraries or components they are nearly identical.
As for which one to choose, unless you have a need to do unsafe operations, then choose the language which is most natural to you. After years of being a VB developer I loved not having to write If yadada then.....End If if (yadaya){....} saves my carpal tunnel a few extra keystrokes (Which can then be used on answering SO questions)
Edit
Just learned one more difference btw C# and VB is that VB supports filtered exceptions so you could something like this pseudo:
try
{
//do something that fails
}
catch(Exception ex when ArgumentException,
ArgumentNullException, FormatException)
{
//Only handle these three types
}
This should not be confused with the ability to do:
try
{
//something that fails
}
catch(ArgumentException)
{
//Log Error
}
catch(ArgumentNullException)
{
//Log Error
}
In this case you are going to handle the exceptions differently in the VB world you could define one piece of code to handle multiple types of Exceptions.
Edit
Some more differences.
VB's Is operator compares two objects to determine if they are the same it compiles to the CEQ IL instruction where as C# compiles to isinst IL. So the following are equivalent statements
c#
if (foo is FooObject){}
vb
If TypeOf foo is FooObject then
Also as mentioned in the comments and I wish I could see them to give you credit but C# doesn't have a like parameter. You need to use the RegEx class.
I think this blog post by Kathleen Dollard provides an excellent overview to the question:
What a C# Coder Should Know Before They Write VB
and her first advice is:
1) Get over the respect thing or quit
before you start. VB is a great
language.
Street cred among geeks.
(And don't pretend that's not important!)
Others have covered a lot of the differences - as has been said several times, they're nearly equivalent languages. A few differences which haven't been covered as far as I've seen:
VB9 has:
XML literals
Mutable anonymous types (urgh)
More LINQ support in the language (C# only covers a few operators)
A whole bunch of extra bits in the language which get compiled down to calls to the Microsoft.VisualBasic assembly. (C# prefers to be a small language with the weight of the .NET framework behind it.)
DateTime literals
C# 3 has:
Better support for lambda expressions: IIRC, you can't write a lambda expression with a block body in VB.
Iterator blocks.
Syntax for extension methods (instead of decorating the method with an attribute)
I suspect there is more, but I thought I'd just throw those into the mix.
When you hit a problem, you'll often be able to Google for a code sample that shows how to solve it in minutes. This is a significant factor in improving productivity. When I was working with Delphi, I had to convert code samples from C into Object Pascal - doable, but tedious, i.e. lots of friction. So don't underestimate the fact that...
The vast majority of .Net code samples are in C# !
In early versions of VB.NET, the difference was more obvious, however with the current version, there are no significant differences.
VB supports XML literals directly in code, which is not supported by C#. C# supports unsafe code and VB don't. Technically these two are the biggest differences. There are many small variations but they are not important. I like C# more because I think the syntax is much less bloated. It's easy to recognize the blocks of code instead of seeing a bunch of keywords, but that's a pure personal preference.
Choose the one you and your team are more familiar with.
VB.Net has a root namespace and C# has a default namespace which is not the same. Because when you have a root namespace in VB.Net it will always add that before the namespace.
For example: if you have a rootnamepsace in VB.Net named namespace1 and then you add this to your file.
Namespace namespace1
Public Class class1
End Class
End Namespace
then you will have to refer to it as namespace1.namespace1.class1
in C# if you have a default namespace called namespace1 and you this in your file.
namespace namespace1{
public class class1{}
}
Then you can still just refer to it as namespace1.class1
My favorite feature of C# that VB doesn't have is the yield statement. It lets you easily return an lazily evaluated IEnumerable from a method.
Here is an article that covers it: http://msdn.microsoft.com/en-us/magazine/cc163970.aspx
VB has a better feedback on errors. In C# you have to compile more often to get all the errors in your syntax.
The big advantage i see with C# is that the vast majority of open source projects, sample code and blog snippets are written in C#. Although it’s easy to convert these to VB.NET with tools (or your head) it is still a monotonous task for VB devs (like me).
Even if you write in VB.NET day to day, you will still need to be able to read C#
Technically, they share the same framework with same performance and memory characteristics and same type systems, so I find it hard to hard to split the two.
Most good developers should be able to shift between the two with a few days adjustment time.
My core frustaration lies with the hundreds of time I have written:
String lastName as String
and wondered why it never compiles!
In C# you can have more fine tuned control over events/delegates. But you rarely need this.
There are a lot more code examples for C#.
In VB.Net it is (a lot) easier to use late binding. For example to COM objects (in C# from version 4.0).
I use C# for 90% in my projects
I use VB.Net for interop to Excel, etc
As soon as I know F# better, I will probably use it for the parts that F# is better suited for.
Performance?
No difference, though VB historically uses a weird indexing in loops which means that you have to subtract 1 from the highest index most of the time:
For i = 0 To someArrayOrString.Length - 1 …
Though I doubt this impacts performance in any measurable way.
On the other hand, due to background compilation, VB actually compiles seemingly faster. Some people claim that this makes the IDE react sluggishly but I've never noticed that myself.
Capabilities?
In a few instances, C#'s yield statement is really useful. VB requires more manual work here. Also, lambdas are much better implemented in C#, especially syntactically. Consider these two statements:
Parallel.For(1, 10000, i => {
// Do something
});
versus
Parallel.For(1, 10000, Sub() _
' Do something '
End Sub)
Besides the fact that VB can't do this yet, and that a comment at this place is forbidden, it's just more clutter and generally a no-go.
Libraries/Components?
Identical.
Reputation?
Not important. “Street cred”? Sorry. Not a factor. Get over it, Nick.
Reliability?
Maintainability?
Ease?
More or less identical. I claim that VB is easier but that may be biased and in any way, it's only marginal.
As I understand it, there are differences between the languages though they are minimal. I would suggest working with the language that you/your developers would feel most comfortable with. If they already have VB experience then I'd suggest VB.Net/vice-versa.
Though I prefer the terse syntax of C# personally. :)
Since C# and VB.Net both compile into MSIL, both have nearly identical Performance, Capabilities, Libraries and Components. Reflection can deassemble MSIL code into either C# or VB.NET (or a number of other languages)
This basically leaves us with, C# looks a lot like Java and C++ which gives it more credibility.
I think Josh gave a good rollup on the language differences.
Tooling Support
There are however also differences in how Visual Studio handles these languages.
Code Snippets are easier to use from the C# editor and the refactoring is better also.
The VB-editor simplifies intellisense by not showing all options at all times.
I'm sure there are more things, but those are the ones that I as a C#'er (doing very little VB) have noticed.
Here is another point not yet covered in this trail:
Higher Degree of Employability + Better (more) Dev Resources
Now I don’t agree with this point of view however:
There are more C# dev shops that VB shops
Some backward c# employers will put you at a serious disadvantage if you are stronger with VB. So maybe C# is the better choice here.
On the flip side, when you go to hire people for your C# project, you will be able to attract more candidates to iterview and get better skills as a result – I don't think detail should be overlooked.
I have to say it's been my experience when using Google to search for examples or documentation that C# examples are of better quality than VB examples. This isn't to say that there aren't bad C# examples, but if you search for something like "dictionary drop down" adding C# will provide a better quality answer higher on the list.
This doesn't apply to examples that display both C# and VB code side by side.
for the moment VB.Net has a very poor implementation of lambda expressions. Meaning that you can't do the neat things that you can in C#. Well you can, but it needs a very ugly workaround in most cases.
This is solved in VB.Net 10.0.
Free from old cruft, array declaration in C# is not padded with extra element. VB.NET array is padded with extra element, so legacy VB6 code migration is easier.
C# is more consistent than VB.NET
Button1.Color() = Color.Red
Button1.Color = Color.Red
I can't give an answer when one student asked me when to use parenthesis on properties of VB.NET. It's hard to give an insightful reasoning for this kind of misfeature.
Consistency with instance and static members. VB.NET allows accessing static members on instance e.g. yarn.Sleep(1000), this is a misfeature. https://stackoverflow.com/questions/312419/language-features-you-should-never-use
Certainly there's the difference in general syntax, but what other critical distinctions exist? There are some differences, right?
The linked comparisons are very thorough, but as far as the main differences I would note the following:
C# has anonymous methodsVB has these now, too
C# has the yield keyword (iterator blocks)VB11 added this
VB supports implicit late binding (C# has explicit late binding now via the dynamic keyword)
VB supports XML literals
VB is case insensitive
More out-of-the-box code snippets for VB
More out-of-the-box refactoring tools for C#Visual Studio 2015 now provides the same refactoring tools for both VB and C#.
In general the things MS focuses on for each vary, because the two languages are targeted at very different audiences. This blog post has a good summary of the target audiences. It is probably a good idea to determine which audience you are in, because it will determine what kind of tools you'll get from Microsoft.
This topic has had a lot of face time since .Net 2.0 was released. See this Wikipedia article for a readable summary.
This may be considered syntax, but VB.NET is case insensitive while C# is case sensitive.
This is a very comprehensive reference.
Since I assume you can google, I don't think a link to more sites is what you are looking for.
My answer: Choose base on the history of your developers. C# is more JAVA like, and probably C++ like.
VB.NET was easier for VB programmers, but I guess that is no really an issue anymore sine there are no new .NET programmers coming from old VB.
My opinion is that VB is more productive then C#, it seems it is always ahead in terms of productivity tools (such as intelisense), and I would recommend vb over c# to someone that asks. Of course, someone that knows he prefers c# won't ask, and c# is probably the right choice for him.
Although the syntax sugar on C#3 has really pushed the bar forward, I must say some of the Linq to XML stuff in VB.Net seems quite nice and makes handling complex, deeply nested XML a little bit more tolerable. Just a little bit.
One glaring difference is in how they handle extension methods (Vb.Net actually allows something that C# doesn't - passing the type on which the extension method is being defined as ref): http://blog.gadodia.net/extension-methods-in-vbnet-and-c/
Apart from syntax not that much any more. They both compile to exactly the same IL, so you can compile something as VB and reflect it into C#.
Most of the apparent differences are syntactic sugar. For instance VB appears to support dynamic types, but really they're just as static as C#'s - the VB compiler figures them out.
Visual Studio behaves differently with VB than with C# - it hides lots of functionality but adds background compiling (great for small projects, resource hogging for large ones) and better snippet support.
With more and more compiler 'magic' in C#3 VB.Net has really fallen behind. The only thing VB now has that C# doesn't is the handles keyword - and that's of debatable benefit.
#Tom - that really useful, but a little out of date - VB.Net now supports XML docs too with '''
#Luke - VB.Net still doesn't have anon-methods, but does now support lambdas.
The biggest difference in my opinion is the ability to write unsafe code in C#.
Although VB.NET supports try...catch type exception handling, it still has something similar to VB6's ON ERROR. ON ERROR can be seriously abused, and in the vast majority of cases, try...catch is far better; but ON ERROR can be useful when handling COM time-out operations where the error can be trapped, decoded, and the final "try again" is a simple one line.
You can do the same with try...catch but the code is a lot messier.
This topic is briefly described at wikipedia and harding.
http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET
http://www.harding.edu/fmccown/vbnet_csharp_comparison.html
Just go through and make your notes on that.
When it gets to IL its all just bits. That case insensitivity is just a precompiler pass.
But the general consensus is, vb is more verbose.
If you can write c# why not save your eyes and hands and write the smaller amount of code to do the same thing.
One glaring difference is in how they handle extension methods (Vb.Net actually allows something that C# doesn't - passing the type on which the extension method is being defined as ref): http://blog.gadodia.net/extension-methods-in-vbnet-and-c/
Yes VB.NET fixed most of the VB6 problems and made it a proper OOP language - ie. Similar in abilities to C#. AlthougnI tend to prefer C#, I do find the old VB ON ERROR construct useful for handling COM interop timeouts. Something to use wisely though - ON ERROR is easily abused!!