I may be starting a new job which requires VB.NET but I am a C# developer and even though I may be able to understand the code, writing it from scratch seems to be a hassle for me for a while.
There are C#>VB.NET converter out there (online) and where you paste your C# code and it converts it into VB.NET code. My question is whether there is any person who experienced this and whether it is a good temp solution or I am gonna experience so much difficulties with that? Do they convert good?
And probably I am gonna run the codes on Asp.net.
An example converter: http://www.developerfusion.com/tools/convert/csharp-to-vb/
Thanks in advance.
Don't use converters - learn VB.NET and the differences between its syntax and C#.
There is a very good comparison cheat sheet here to get you started.
In practice, you will find that most of the time you are interacting with familiar .NET objects in the same way and you only have some syntax differences (though generics and delegate syntax are such a pain that one tends to shy away from them).
Microsoft has stated that they are trying to bring both language to feature parity, so anything you can do in C#, you should be able to do with VB.NET (with minor differences normally).
Update - don't forget that compiled code (in assemblies) should work identically in both languages (assuming CLS compliance), so you could write a library in C# for use with VB.NET and vice versa.
You can try the Telerik Code Converter
That being said, it would be a valuable exercise to convert the code manually. You'll gain a good amount of experience by doing a manual conversion and you'll learn some of the key differences between the 2 languages that may help you going forward.
I'd say your code will work, but you'll miss some special features for which there is no C# equivalent and which would make your code fit better with the language. Some examples:
In C#, you assign event handlers with +=, which will be translated to AddHandler. In VB, however, it's much more common to use WithEvents instance variables. This is especially relevant for ASP.NET, where C# often uses the AutoEventWireup feature, which done in VB through WithEvents instead.
In C#, you access XML through LINQ to XML method calls, which will be translated to the matching method calls in VB. However, in VB, it's more natural to use the integrated language support for XML.
This is good for converting the bulk of your code, but it's not a total solution. One thing you will have issues with is the converter knowing what to do with C#'s indexer brackets ([]) vs. method parentheses (()). VB uses parenthesis for indexers and methods and there's no way for it to know which to use.
I've gone through conversion hell with these things and finally decided that they were just too much trouble and that it was much easier to just convert it by hand. I come from a VB background, so this wasn't a huge deal for me.
For what you want to do, though, you need to learn VB.NET syntax. Writing everything in C# and converting it to VB.NET is not a good, long-term solution. You will eventually have to learn VB.NET. Your manager(s) will not be keen to the fact that you're not learning the core fundamentals of the language you were hire to program in.
Don't do it... There are converters, but you will find that once you learn the key differences that you will be fine. You will interact with the .NET libraries in the same way so much of the programming will be the same.
I just changed jobs recently and went the opposite direction. I'm glad I took the time to learn C#. Major dividends in the end and you'll be more versatile.
Related
I need to write a translator for vbscript to c#. What would be the basic steps invloved to translate using ANTLR? I am not very clear about whether to use grammar (lexer/parser? file or stringtemplate or AST or all.
Suggestions?
Thanks in advance.
Is this really possible?
I'm "translating" (read: rewriting) a MS Access/VBA application since two years to C# and found out that even the online available converters (like this one which is more VB.NET, but anyway) fails at most basic conversions.
So my assumption until now is that there are way too much kind of constructs that are simply not translatable from VBScript to C#.
See What kinds of patterns could I enforce on the code to make it easier to translate to another programming language?
The easiest way to translate VBScript to C# would be using VB.NET as an intermediate step. VBScript is very similar to VB.NET (there are some differences though), so all you need to do is copy-paste your code in a new solution in Visual Studio. After you make a few changes, the code will be able to compile.
You can leave it at that (you can call the resulting DLL from your C# code), but even if you don't want to do that, converting VB.NET to C# is trivial. You can even decompile your resulting DLL/EXE (although this will lead to some loss of information) or use any online VB.NET to C# converter.
I've been offered to be dispensed of classes in computer science in college, as the teacher noticed I obviously knew the introduction to coding. I'm extremely fluent in C# and with most programming concepts, so the exam shouldn't be so hard. I can also code in other languages such as C++, C, Lua, PHP, VB, etc.
I'm not caring about passing or not, my point is rather that this exam will be my only grade for the term. Therefore I'd like to get it right.
Let's assume I have ~2 weeks to prepare, I'd like to know where to start from. I obviously don't need to learn any concept (i.e. what is a variable, how to use classes, what is inheritance, etc.), since these are the same in most languages (or in that case, C# and Java).
I'd assume I have to get familiar with the slight syntax changes (string -> String, bool -> boolean) and system differences (i.e. Scanner for input, imports vs usings).
I've found the following page for most syntax changes:
http://it.toolbox.com/blogs/codesharp/java-for-c-developers-21248
From what I know, the test will variables and values, basic operators, logical structures (i.e. if/else, for, while), functions and structs. As far as I can remember, classes aren't seen this term.
I was interested in knowing what tips the S/O community could give me. Thanks in advance!
Well, first it really depends on the difficulty of your exam. You could have an exam on general POO in java or on more specific points, like generics, Collections, Threads.
And a thing you need to see, it the way the inheritance works in java. Methods inheritance isn't really working the same way.
Resources :
A comparison of Microsoft's C# programming language to Sun Microsystems' Java programming language
This is just one of many examples, yet one of the biggest for me was creating getters/setters in Java compared to C#. C# has very nice shortcuts which you are probably use to.
Public string ExampleString { get; set; }
With Java you have to create methods instead.
private string _exampleString;
public string getExampleString()
{
return _exampleString;
}
public void setExampleString(string exampleString)
{
_exampleString = exampleString;
}
This is fundamentally the same way C# handles it, but you do not have the shortcut in Java. Ultimately to learn and get use to the differences your going to have to bite the bullet and write quite a few test programs. Especially if you need to know/understand Java UI, such as swing. Which I had to write my final project in swing when I took Java in school.
Code in Java? Sounds easy, but it is, basically try doing a few "basic" things in java, IE make a linked list, some data structures.
Try to code in Java, create something simple that you have already created in C# and than come to SO if you have any questions or queries and learn from the answers. I would suggest practicing would be of great help.
To get the feeling of programming in the language I would suggest Project Euler, which requires you to write solutions to smallish programming problems.
The best way to learn is to write programs, and you need to practice a lot to prepare.
If you are allowed to use eclipse or netbeans as part of the evaluation then the most important thing you could do is get used to using those tools. Either of those could have you coding productively in Java within the hour because they will advise you on syntax issues and give you lists of choices so you don't have to look things up so often.
For instance, what is the method to grab a sub-chunk of a string. If you have an object of class "String" and hit strObject.(ctrl-space) it will give you a list of all the methods on string along with the parameter numbers and types. Oh and it will give you all the docs for this method as well.
If not, I'd get used to the JDK description on the Java website, you'll be using it more than Java syntax itself.
As for the Syntax, Java is pretty straight-forward. If you are coding in a GUI it will probably just fix your syntax for you.
If it's an in-class written (non-code) test, you may have to get used to some little differences like public/protected/private/package indications (package is the trickiest).
Code some stuff, use Eclipse.
NB: Generics are hell in Java. Using a library that is "generified" correctly is simple, but coding generic classes and methods are often rather intense.
My company is tossing around the idea of using the Entity Framework when it comes out with .NET 4. We are currently a VB.NET shop, but have some interest in switching to C#.
Is there any major arguments for or against such a move?
Does EF with C# hold any advantages in performance, coding ease, etc over VB.NET?
Thanks for your thoughts/opinions!
I actually have an irrational dislike for vb.net if im honest, i much prefer c# syntax, but there is no compelling reasons to switch. They both compile to IL, with very subtle differences and both are equally capable.
I would imagine that the most compelling reason to switch might be that it is easier to find and recruit high quality c# developers than it is vb.
I always say stick to what you are good at. If there is a large learning curve from vb.net to C# it may be risky. I was a vb.net programmer but moved to C#, I didn't find it all that difficult. But if you are working on some robust software that needs daily changes / fixes you may want to stick what you are good at (in this case VB.net).
Here is a nice comparison between both languages.
When you are comparing both languages for the entity framework you won't find much of a difference. If you prefer public sub with matching end subs (more wordy and verbose) then use vb.net. If you like { } and less wordiness then prefer C#.
I hate to tell people not to learn C# because I'll be quite honest, I wish I would of changed from VB.net to C# a long time ago. I like the cryptic like syntax because I have a C/C++ background. I had to deal with VB.net for a while due to some internal applications. So it's preference and you'll probably be quick to implement everything in vb.net. But if your company is willing to let you guys learn a new language and invest in your knowledge then I say go for C# all the way.
I think your biggest issue is not in the difference in performance or capability. I think it will come down to documentation. MSDN will probably provide features in both languages, but the majority of the blog posts, etc will be in c#. These posts may offer real world guidance on best practices, tips and tricks and a host of other information that you will lean on in your development practice and most will be in c#.
With .NET 4.0, VB.NET and C# have the exact same functionality. The only real difference is the syntax. Before 4.0 that was not the case as there were a number of minor differences. However Microsoft has made a push to make the languages the same. Which is going to occur with the release of 4.0.
One of the most compelling differences for me is that C# generally has a more concise syntax. This manifests itself especially with lambda expressions. Although VB.Net now has the same functionality, I find the VB.Net syntax way too verbose.
E.g., if you use the LINQ 'Fluent API' syntax:
C#
var addresses = _users
.Where(u => u.Name == "scott")
.Select(u => u.Address)
Admittedly, the syntax can be a little weird at first, but as soon as you're used to it this actually becomes very readable. Compare this with VB.Net:
Dim addresses = _users _
.Where(Function(u) As Boolean
return u.Name = "scott"
End Function) _
.Select(Function(u) as Address
Return u.Address
End Function)
EDIT:
Apparently I was misinformed...
The above code is only valid in VB10 (where they added multiline lambda statements), but can be written more concisely as follows:
Dim addresses = users _
.Where(Function(u) u.Name = "scott") _
.Select(Function(u) u.Address)
Apart from the ugly underscores and the Function keyword instead of the =>, this is mostly the same. Still prefer the C# syntax though ;-)
If you are primarily a VB programmer, C# can be confusing; all those arcane braces instead of a nice verbose "End Sub"!
For the most part, the languages are otherwise equivalent; both compile to essentially the same IL (although there are occasional differences) and are thus equally performant (for the most part).
Bottom line: it's preference. I prefer C#. You may not.
No substantial differences, and now more than ever VB.NET and C# are going to be kept in sync so it really comes down to your (or your company) preference.
Depends on the team you are working with and the skillbase.
C# is the way to go in my opinion. I can code in both, but much rather C#. The .Net world seems to revolve around C#. I think you're company will find more C# coders out there that are better skilled than you would find VB.net coders.
I think either language will work. I prefer c# only because their is more documentation out there in c#.
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.
I've been working with C# and more generally the .Net framework for a couple of years now. I often heard about the similarity between C# & the Java language and would like to learn more about the second one.
Have you got any specific advice to learn Java when coming from C# ?
Any common errors a C# programmer would do when starting Java ?
Any documentation showing the habits you can keep and the ones you must change (still in a C# to Java optic, so something a bit more specific then a C# vs Java comparison) ?
Well, while C# and Java are superficially alike there are a number of small differences that might bite you. Generally I think the opposite direction—going from Java to C#—is less problematic. This is mainly due to C# being a more complex language so you might find many simplifications from common Java patterns but the other way around might be a little painful.
Things to look out for (partial list, not guaranteed to be exhaustive):
Different ...
Naming conventions. In Java only type names start with a capital letter (i. e. PascalCase), everything else uses camelCase. Not very hard to adhere to, though.
Also interfaces generally don't start with I. On the other hand you have to implement them with a different keyword. Doesn't really help in the middle of the code, though.
Class library :-)
While obvious, this has been the thing I spent most time on when learning a language. When dealing with a known paradigm the syntax differences are quickly sorted out, but getting to know the standard library / class library / framework takes some time in some cases :-)
Patterns. Well, not quite, it's still the same stuff. But C# supports some patterns at the language level, while you still have to implement them yourself in Java. No events, but the Observer pattern (very prevalent in Swing—whenever you see a Listener, you know what to do :-))
Exception handling. Java has so-called checked exceptions which means that an exception must either be caught or declared upwards. Usually this means that you have
catch (SomeException ex) {
ex.printStackTrace();
}
pretty often in your code1 :-)
Types. While .NET has normal objects and value types, they both are objects and support methods, properties, &c. Java has a dichotomy of primitive types, such as int, float, char, &c. and classes such as String. Doesn't matter much since they implemented auto-boxing, but sometimes it's still annoying to wrap int in Integer.
Polymorphism: All Java methods are virtual by default whereas c# methods are not.
Minor syntactic differences.
foreach (a in b) → for (a : b)
Different access keywords. Things like internal and protected internal don't exist. But unqualified members are visible to other classes in the same package (sort of internal, but then again not quite).
String comparison isn't done with == in Java. You have to use .equals(). While in C# == on strings is value equality, in Java == is always reference equality.
No ...
Properties. In Java this is generally done with the Foo getFoo()/void setFoo(Foo foo) pattern which C# generates silently behind your back when using properties but you have to do it explicitly in Java. Generally, to keep the language itself simpler many things in Java are just conventions. Still, most of the time you're better off adhering to them :-)
Operator overloading. Deemed a hazard to the righteous programmer they weren't implemented for fear of abuse. Don't need them too often anyway, not even in C#, but sometimes they are nice and then you're missing something.
Indexers. You always have to access list items through myList.get(5) instead of the array-like syntax myList[5]. Just a mild inconvenience, though.
LINQ (though there exist implementations2 but it's not as nicely integrated), or lambda functions3 (no delegates anyway, but anonymous classes), extension methods, or partial classes (yes, that's a painful one when dealing with Swing, unless you're very disciplined), and a few more things.
Multidimensional arrays. You can use jagged arrays (arrays of arrays), buttrue multidimensionality isn't there.
Generics are compile-time only, at runtime only Objects remain. Also wildcards in generics can be hard to resolve sometimes when the compiler complains about all of the four ? in your generics having different types. (Though to be fair: That was a case where I would have needed type information at runtime anyway so I reverted back to Objects).
General advice: Grab a friend with Java experience and let him glance over your code. While he probably can't tell you everything you should take care of when you directly ask him that question, he can spot strange things in code just fine and notify you of that. This has greatly helped me learning Java (although I learned Java first and then C#, so it might be different).
1 Yes, I know many catch blocks look different, but still, this is probably the archetypical one and not even that rare.
2 Quaere, JaQue, JaQu, Querydsl
3 There's lambdaj, though. Thanks for pointing that out, Esko.
I honestly think the biggest hurdle for many C# developers trying to learn Java is learning a new IDE. Visual Studio is great, and when you're coding in C# for a long period of time, you get used to it. When having to move over to Eclipse or Netbeans, you suddenly feel lost. How do I set a breakpoint? Where's the immediate window? How do I create a windows app? etc etc... I know this sounds crazy, but I'm telling you, people get very attached to their IDE's and have a tough time getting used to new ones...
Languages themselves are pretty similar, sans few keywords and Java lacking some features C# programmers got used to (properties, using, reified (non-type-erased) generics).
The main problem here is knowledge of frameworks, of which there are thousands for Java.
The main language is fine. Getting to know the libraries will be one thing which takes time. If you're doing web-applications, there is a LOT to learn... equivalent technologies to WCF and ASP.net.
You don't say what kind of area you work in... desktop, server, or web-server?
Biggest difference between C# and Java : In Java, all methods are virtual. Hence the reason why tools such as NUnit and such came from the Java world.
To be honest, if you're a competent C# programmer I don't believe there's much you do need to know apart from packaging and deployment of applications.
Here's a good link http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp
The biggest thing you need to learn is how to Greenspun C#'s functional style features in Java. For example, you can expect to make a lot of interfaces with only one method to get around Java's lack of lambda functions and delegates.
I honestly recommend Java in a Nutshell. Most Java/any_other_lang introduction books are for totally novice readers explaining the concept of a loop for pages and recursion for a chapter... You can start writing Java programs within two days with this book. Of course it will take you a long time to understand what is going on under the hood and how to use all the available framework. But once the language itself is mastered, it is easy to get along even with google only resources.
Although, this is the other way around, I found the following link to be quite useful for comparing Java and C#.
C# From a Java Developer's Perspective
I made a transition from Java to C# and back to Java again. I think syntactically they are very similar and most of the trouble I had was learning the .NET APIs and learning how to use them effectively. Many times I was using 'syntactic sugar', writing my code as if it was in Java and then translating it to C#. I spent a lot of time on Microsoft's website reading and learning about the APIs which was a huge help.
Unmanaged languages notwithstanding, is F# really better than C# for implementing math? And if that's the case, why?
I think most of the important points were already mentioned by someone else:
F# lets you solve problems in a way mathematicians think about them
Thanks to higher-order functions, you can use simpler concepts to solve difficult problems
Everything is immutable by default, which makes the program easier to understand (and also easier to parallelize)
It is definitely true that you can use some of the F# concepts in C# 3.0, but there are limitations. You cannot use any recursive computations (because C# doesn't have tail-recursion) and this is how you write primitive computations in functional/mathematical way. Also, writing complex higher order functions (that take other functions as arguments) in C# is difficult, because you have to write types explicitly (while in F#, types are inferred, but also automatically generalized, so you don't have to explicitly make a function generic).
Also, I think the following point from Marc Gravell isn't a valid objection:
From a maintenance angle, I'm of the view that suitably named properties etc are easier to use (over full life-cycle) than tuples and head/tail lists, but that might just be me.
This is of course true. However, the great thing about F# is that you can start writing the program using tuples & head/tail lists and later in the development process turn it into a program that uses .NET IEnumerables and types with properties (and that's how I believe typical F# programmer works*). Tuples etc. and F# interactive development tools give you a great way to quickly prototype solutions (and when doing something mathematical, this is essential because most of the development is just experimenting when you're looking for the best solution). Once you have the prototype, you can use simple source code transformations to wrap the code inisde an F# type (which can also be used from C# as an ordinary class). F# also gives you a lot of ways to optimize the code later in terms of performance.
This gives you the benefits of easy to use langauges (e.g. Python), which many people use for prototyping phase. However, you don't have to rewrite the whole program later once you're done with prototyping using an efficient language (e.g. C++ or perhaps C#), because F# is both "easy to use" and "efficient" and you can fluently switch between these two styles.
(*) I also use this style in my functional programming book.
F# has many enormous benefits over C# in the context of mathematical programs:
F# interactive sessions let you run code on-the-fly to obtain results immediately and even visualize them, without having to build and execute a complete application.
F# supports some features that can provide massive performance improvements in the context of mathematics. Most notably, the combination of inline and higher-order functions allow mathematical code to be elegantly factored without adversely affecting performance. C# cannot express this.
F# supports some features that make it possible to implement mathematical concepts far more naturally than can be obtained in C#. For example, tail calls make it much easier to implement recurrence relations simply and reliably. C# cannot express this either.
Mathematical problems often require the use of more sophisticated data structures and algorithms. Expressing complicated solutions is vastly easier with F# compared to C#.
If you would like a case study, I converted an implementation of QR decomposition over System.Double from 2kLOC of C#. The F# was only 100 lines of code, runs over 10× faster and is generalized over the type of number so it works not only on float32, float and System.Numerics.Complex but can even be applied to symbolic matrices to obtain symbolic results!
FWIW, I write books on this subject as well as commercial software.
F# supports units of measure, which can be very useful for math work.
I'm from a maths background, and have looked at F#, but I still prefer C# for most purposes. There are a couple of things that F# makes easier, but in general I still prefer C# by a large margin.
Some of the touted F# benefits (immutability, higher-order functions, etc) can still be done in C# (using delegates etc for the latter). This is even more apparent when using C# 3.0 with lambda support, which makes it very easy and expressive to declare functional code.
From a maintenance angle, I'm of the view that suitably named properties etc are easier to use (over full life-cycle) than tuples and head/tail lists, but that might just be me.
One of the areas where C# lets itself down for maths is in generics and their support for operators. So I spend some time addressing this ;-p My results are available in MiscUtil, with overview here.
This post looks like it might be relevant: http://fsharpnews.blogspot.com/2007/05/ffts-again.html
Also: C# / F# Performance comparison
The biggest advantage for pure math is what PerpetualCoder said, F# looks more like a math problem so it's going to be easier for a mathematician to write. It reminded me a lot of MATLAB when I looked at it.
I am not sure if its better or worse but there is certainly a difference in the approach. Static languages over specify how a problem will be solved. Functional languages like F# or Haskell do not do that and are more tailored at how a mathematician would solve a particular problem. Then you have books like this that tout python to be good at it. If you are talking from a performance point of view nothing can beat C. If you are talking from libraries I believe Functional Langauges (F# and the likes), Fortan (yes its not dead yet), Python have excellent libraries for math.
One of the great advantages of functional languages is the fact they they can run on multi-processor or multi-core systems, in parallel without requiring you to change any code.
That means you can speed up your algorithms by simply adding cores.