Any suggestions on how I should approach this? Thanks.
Take a look at this VB to C# Comparison chart for some of the syntax and keyword differences.
I have to do this often - and my biggest hang-up is the semi-colon. Never fails that my first few days of writing VB after a longer stint of C# coding, the VB compiler is always barking at me for putting a semi-colon on every line of VB code.
Other than that, it shouldn't be too painful. If you're fluent in C#, moving to VB might be stressful for the first few days, but after that you should be smooth sailing.
Code converter tools come in handy to help you remember/learn/re-learn all of those odd syntax differences that you forget easily. The one I normally turn to first is http://converter.telerik.com/ - and if that won't do the trick, a quick google search for code converters will turn up a handful of other good ones.
Another pain point that I've had in the past too is Snippets. Snippets in C# rock - but in VB rock a bit less. Get to know the differences between those and life will be much easier. (Come on VB team - get that enter key working like the C# snippet team has it...)
A good C# to VB.NET converter will help.
Aside from revulsion and horror I recommend (from experience - ugh) to just start. Build a simple app. The magic is in the experience. It doesn't make sense until you have spent lots of time trying to figure out why something doesn't work.
I went the other way (VB to C#) and found the syntax to be so similar that the transition was painless. I can now pretty much program in either platform – thanks a lot to the IDE intellisense.
Take advantage of the "With" statement! One of my favorite parts of VB.NET.
It's not as difficult as it seems at first. Took me about a month from going strictly C++\C# to VB to get comfortable.
If you are familiar with programing you should just have to learn the syntax...why would anyone want to go from C# to VB? who knows :)
My first question would be 'Why?'. I'd like to think that you can pretty much get the same thing done with either C# or VB.Net. Given that it's managed code, why not just leave them as they are?
Let's just assume you have your reasons :)
1) There are a couple of tools that will do this (see http://www.developerfusion.com/tools/convert/csharp-to-vb/ for a sample).
2) The other option is to manually convert the code, compile, fix errors, and repeat. Painful.
It's a pretty straight-forward thing, actually. VB.Net is a perfectly good (if, imo, verbose) language with most of the expressiveness you've grown accustomed to in C#. Just be aware that certain specific keywords are different and that you've got a different background culture and you'll do fine.
You can also use a tool like CodeRush from DevExpress (no affiliation). The short-cut keys for any operation are the same for both languages and will produce the correct output for the language.
For example: key combo "mv" yields:
In C#
public void MethodName ()
{
}
In VB
Public Sub MethodName()
End Sub
Use XML literals and marvel how resentful fellow C# programmers suddenly are.
There were some useful articles in Visual Studio magazine back in Jan 2008.
What C# developers should know about VB
And for completeness: what VB developers should know about C#
Related
I’m trying to make CodeContracts in C# look more like statements so i need a tool that allows me substitute some code before the compiler sees it, if there is no way to do it i guess a Visual Studio plug in would help too.
Trying to fight the syntax of a language like C# is simply a bad idea. The tools you use will fight back with determination.
Just go with the flow and stop trying to swim against the current. You'll soon get used to the syntax and it will make sense to everyone else who works with the code.
You could always channel the code through a C++ preprocessor (like mcpp) before sending the code to the C# compiler. That would give you full power of C++ macros :)
I guess you could use a pre-build task to do that.
I use this approach in one project of mine (though it is not C#, but a quite different language, but I needed the C++ like macros).
What is wrong with the normal codecontracts ?
http://www.cauldwell.net/patrick/blog/CodeContracts.aspx
And
http://weblogs.asp.net/podwysocki/archive/2008/11/08/code-contracts-for-net-4-0-spec-comes-alive.aspx
What about expression trees?
first things first;
I am writing a little LUA-Ide in C#. The code execution is done by an Assembly named LuaInterface. The code-editing is done by a Scintilla-Port & the RAD / UI Interface is via the extensible IDesignSurfaceExt Visual Studio (one way code generation). File handling is provided by a little sql-lite-db used as a project-package-file.
So all in all i've got everything i need together...
The only problem unsolved is the parser / lexer for lua. I do not want to load & execute the code! I just want to parse the String containing the Lua code and get some information about it like function and global vars. I really don't want to write the parser completly myself... (I hate regex - I get the wrong all the time ^^)
Anybody got a link to a .net lua parser lying around?
Just to clarify - I only want to analyse the code at this point - I dont wnat to run it!
Thanks in advance!
Corelgott
Just for the record:
I went with a comibination of:
http://irony.codeplex.com/ - A Language implementation Kit that can be adapted to parse several languages. (Btw. this one got virtually no ducumentation what so ever... So code-comments no docs... but lots of fun...)
and a customized version of
http://luairony.codeplex.com/ - the Lua Syntax for irony (added some degree error tolerance)
But I gotta admin, both are pretty heavy stuff... and you kind of open up a box of new problems as well as lots of possibilities...
Cheers, Corelgott
This SO question's responses may be helpful.
Easiest way to parse a Lua datastructure in C# / .Net
Incomplete but:
http://luairony.codeplex.com/
This isn't quite what you're after, but maybe half of it can provide half the answer.
It converts Lua to C, by parsing the Lua to an AST. You could then extract the info you need from the AST. It's written in Lua, but you already know how to call that :)
Have look here: Lua recipes for LPeg
Maybe you can use one - otherwise I would look at using the extended BNF from the documentation.
I am looking to write an interpreted language in C#, where should I start? I know how I would do it using fun string parsing, but what is the correct way?
It can be a pretty difficult endeavour to do right.
If you don't have much knowledge in compiler theory you should probably first start reading about it.
Just using "fun string parsing", if I understand that term correctly, isn't going to get you very far at all.
The first basic step is to write your language grammar that defines the valid syntax for the language.
A tool like ANTLR will help you get the pieces together, but I would suggest reading the Dragon book as it is the canonical starting point to get up to speed on the subject.
If you want to build an interpreted language on .NET, the DLR is the way to go - check out Martin Maly's LOLCODE sample at http://www.iunknown.com/2007/11/lolcode-on-dlr.html
Edit: Here's another link with more information from Scott Hanselman: http://www.hanselman.com/blog/TheWeeklySourceCode11LOLCodeDLREdition.aspx
Checkout the Phoenix compiler from Microsoft. This will provide many of the tools you will need to build a compiler targeting native or managed environments. Among these tools us a optimizing back end.
I second Cycnus' suggestion on reading Aho Sethi and Ullman's "Dragon Book" (Wikipedia, Amazon).
RGR
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!!
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!!