Develop Reference

Integrating python and c#

I've decided to try and create a game before I finish studies. Searching around the net, I decided to create the basic game logic in python (for simplicity and quicker development time), and the actual I/O engine in c# (for better performance. specifically, I'm using Mono with the SFML library).
After coming to grips with both languages and IDEs, I've gotten stuck on integrating the two, which leads me to three questions (the most important one is the second):
a. which module should encapsulate the other? should the python game logic call the c# I/O for input and then update it for output, or should it be the other way around?
b. whatever the answer is, how can I do it? I haven't found any specific instructions on porting or integrating scripts or binaries in either language.
c. Will the calls between modules be significantly harmful for performance? If they will, should I just develop everything in in one language?
Thanks!

Sincerely, I would say C# is today gives you a lot of goods from Python. To quote Jon Skeet:
Do you know what I really like about dynamic languages such as Python, Ruby, and
Groovy? They suck away fluff from your code, leaving just the essence of it—the bits
that really do something. Tedious formality gives way to features such as generators,
lambda expressions, and list comprehensions.
The interesting thing is that few of the features that tend to give dynamic lan-
guages their lightweight feel have anything to do with being dynamic. Some do, of
course—duck typing, and some of the magic used in Active Record, for example—
but statically typed languages don't have to be clumsy and heavyweight.
And you can have dynamic typing too. That's a new project, I would use just C# here.

Have you considered IronPython? It's trivial to integrate and since it's working directly with .net the integration works very well.

How do I tune up my C# Skills, when I have spent the last decade coding in VB?

I started my career coding in C/C++ on a vax system, but got into a few contracts where it was all VB and then became a specialist in VB, then to VB.net. Now I am aspiring to work for Microsoft and it seems that every job they post is in C/C++/C# and I can barely read C# code, it looks like the most convoluted mess to me and the inline syntax almost hurts my feelings.
I am looking for positive, non-flaming, helpful suggestions on how to pick up C# skills again. Books..Labs..etc? I have been coding simple projects using Silverlight and C# to try and work it out but it is extremely frustrating since there are very few examples that I can find that illustrate what each code set looks like. I've Googled but have yet to find anything helpful other than channel9 labs and working through some of the example code/projects from mix10.
I am not looking for a shortcut, but a good solid skills understanding. I swear it is easier to translate English to Latin than VB to C#.

I personally would start by converting a VB.NET project into C#, having done VB.NET it wouldn't be difficult once you got started as they both use the same underlying CLR.
Doing it this way step by step, looking up how to convert each bit you don't understand, you'll soon end up teaching yourself C# based on you're knowledge of VB.NET and you'll see they're really not that much different!
I find them very similar now I know them both, they just have a habit of doing things 'slightly' differently.
Also, have a look at this wiki page for a summary comparison of VB.NET and C#, and check out the examples at the bottom to see some basic syntax comparisons that will give you a starting point for converting VB.NET into C#.

Since VB.NET and C# are both first-class object-oriented .NET languages that compile down to the nearly the same CIL code, I find it fairly easy to switch between the two. Most of the learning curve in .NET comes from learning the myriad APIs; syntax doesn't take terribly long to pick up.
I'd recommend a good book that focuses on the language of C# (that is, not a framework such as Winforms, Silverlight, or WPF). A book that I really liked was Illustrated C# 2008 by Daniel Solis. It's great at exposing the C# language from end to end. (NOTE: Although it says "Illustrated" in the title, it's not filled with lots of pretty pictures. "Illustrated" simply means that the author uses lots of helpful diagrams to explain concepts).
Also, I spent a good deal of time solving math problems at http://www.projecteuler.net in order to learn C#. It helps to have real problems to solve to learn a language and Project Euler offers problems that are small enough that you can still focus on learning different aspects of the language.

It's odd that you are having this difficulty if you can still remember anything about C. I have a similar background but I don't find C# hard to read at all.
Are you getting confused by LINQ or lambdas / anonymous methods? EDIT you say it's LINQ: here are some links for LINQ.
The LINQ syntax is different in VB from C# and there's not much help out there for the VB syntax. The MSDN 101 VB LINQ samples are good, and I also liked the coverage in the book Programming VB 2008.
Lambdas are a way of writing methods inline that might be the "inline syntax" you are referring to? In which case, just read up on them and try them out: you could try them out in C# or VB.Net.
There were some useful articles on differences between C# and VB.Net in Visual Studio magazine back in Jan 2008.
What VB developers should know about C#
And for completeness, What C# developers should know about VB
You might also be interested in the question "what's allowed in VB that is prohibited in C# (or vice versa)"
Full disclosure: the bottom part of this answer is copied almost unchanged from this question on converting C# knowledge to VB.Net

Buy "Head first C#" and enjoy yourself coding. It is the best book (according to me and a few others) on the market learning C#.

Scott Hanselman posts a regular column of his blog called the "Weekly Source Code", which is made of source code -- generally C# --- which you can learn from by reading.

My first choice is that given by W69rdy: convert some project you've already done in VB to C#.
Second, I would skim the C# documentation, or an online source like that suggested by James, at least once a day looking for something you don't understand. Perhaps something as simple as a language keyword you don't recognize. Then write something that uses it: even something as simple as a small snippet.

If you are looking for a quick read and tutorial, this one will work. I agree with #TechNeilogy and #W69rdy that converting a program from VB.NET to C# will help with understanding the similiarities and differences between the languarges.
I converted a VB.NET Windows service to a C# Windows service and it helped greatly with trying to learn C#.

I was a VB .NET programmer as well. I found that using Jetbrain's Resharper Visual Studio plug-in really helped my learning curve. I was initially converting/optimizing a VB .NET project into C# and I found the coding assistance tools really helpful. Most of the time, I was just trying to find the C# equivalent so code completion usually put me in the right direction.

I've also recently been moving to C# from VB - I've found this converter invaluable as a learning tool when you don't know a bit of C# syntax but you can write it in VB.

You should start with some C# tutorials in internet to understand the how to work with c#, then read a book with maximum 300 pages.
After that you can start the converting from VB to C#. It is not difficult.
Good luck.

I use both vb.net and c# at work. Sometimes in the same project even. Honestly, when you switch back and forth, after the first couple misplaced or missing ; or Dim's, it's pretty easy to jump between the two. The rest of the stuff (class modifiers, event handlers, etc.) is only a quick google away.

The only way you are really going to make the step across, is to just make the step across and run with it!
Sure, check out a basic tutorial or read a guide on C# to learn the syntax basics, but then you need to find a reasonably simple, self-contained project to get stuck into. If you know some of the .NET framework (which you presumably do), then the jump won't actually be that great. Obviously, don't pick a vast, complex, mission-critical system to start with!
In fact, although my current project is my first c# project, I can't believe I didn't make the switch earlier. Apart from enjoying C#, I'm also finding it easier because I'm finding there are more good quality examples around.

I don't mean this patronisingly, but the answer is to simply start coding in C#!
There are plenty of books, resources, training CDs (check out AppDev.com for some great video based training) but nothing compares to just coding for real-life problems!
(And I agree with a previous comment about converting a recent project to C#.)
"That which we learn to do, we learn by doing" Aristotle

About "GUI in C# and code in C++"

First of all, until now, all my programming education, has been targeted to console applications, just like everyone who starts learning C and C++. (the 2 languages i know)
Now, i want to jump to the nice graphical World.
So, I am exploring Windows Forms, i have already got many headaches trying to understand the language that it uses (quite diferent from native C++), but i managed to do a couple of things like using textbox and buttons.
Well, the thing is, i have read in many places that, in order to avoid headaches trying to code winforms in C++, i'd better "Build the GUI in C#, because it's way easier, and the logic, and code in C++". And that is my question, i don't understand that statement, at all.
What is that supposed to mean?
Also, it's C# THAT similar to C++, as to affirm that statement? Cause, if C# was too diferent to C++, i would have to learn the whole C# language
hope you understand my doubt.
PD : Sry about my bad english.

Joan, while it is certainly possible to develop an applications Front End in C# and the logic in C++ I believe it to be a huge waste of effort to do it this way since you only complicate yourself for no real benefit since you can code both things in the same language.
C# has many advantages over C++ and I personally use mostly C#, but I can clearly see many programmers who love C++.
Now going into your question regarding the similarities between C++ and C# the answer is yes and no. Yes in the sense that C#'s syntax is clearly derived from C++. Many things like ifs and for loops are written exactly the same, so if you know how to write an if in C++ you can write it in C#.
The difference (and a critical one that is) lies in the way the languages work. C++ is an strictly compiled language (it goes from C++ code to machine code). C# is an interpreted language (it goes from c# to MSIL and during runtime to machine code). In C# you can't use pointer arithmetic without explicitly allowing, in C++ you can (and will) use pointer arithmetic. C# has garbage collection, C++ does not.
In the end, as I said in the first paragraph you can use both languages to build an application, but it would be highly complicated. My advise to you is to learn a bit of C# and then decide which language you would prefer to build your GUI application. But don't believe even for a second that C++ can't be used to build a front-end since there are a myriad of frameworks for that. One I remember from the top of my head is Qt.
Another option for you is to use "C++/CLI" which is a flavor of C++ which can use the .NET Framework (the same framework C# uses)
EDIT: Thanks Jerry for pointing out that Managed C++ is obsolete and that C++/CLI is the one!

C# has braces, semicolons, and uses the concept of classes. It has "C derived" syntax, but otherwise is very dissimilar to C++. Java is really the precursor to C#, not C++.
You can build application GUIs using C#, and then use various methods of calling into C++ (such as P/Invoke). Unless you are using lots of existing libraries, or looking for absolute performance, its going to be a headache.
If you are looking for examples of modern Windows GUIs using C++, take a look at the Hilo example program.

It is not very difficult to switch to a new language. The few keywords you would have to learn are not the issue. What costs most energy if to get used to the new environment and class libraries. That is probably what you mean and it is true, you'll need some time.
Now coming to the split GUI in C# and code in C++, then you'll have to make all bindings and marshalling of parameters if there are buffers and strings for example. I don't think this would make your life any easier. Interfacing with native Dlls can become some pain. However if you use third party dlls and have already a large working codebase you could try to compile the logic code with /clr enabled. This generates a DLL that can be used from within .NET directly.
NOTE: WinForms is now out-of-date for new applications, consider using WPF instead. It scales nicely, but the learning curve might be steep for newcomers.

Please note that you have native C++ and C++/CLI, the first one is the one you have learned, but the second one is the one you will need to use if you want to combine it with a C# GUI. However, I would suggest you to stay away from C++/CLI because this will cause a lot of confusion if you don't have a solid ground in C++, C# and .NET.
The reason that you can't use the native C++ is because C# is a managed language, so you will either have to find another GUI that fits with C++ or you will have to go C# for everything. For more information about managed see the environment part of Difference between C++ and C#, the article will also provide you with a good comparison between both.

Well, this aint a direct answer but hope it will help you. Since you stated that, you are just started and you want C++ combined with GUI, I suggest you to take a look at Qt. IMO I found C++ and GUI made easy in Qt. Also it's good too.

Although it's not a direct response to the question you're asking, I'd first caution that WinForms are already basically a dead-end, so for new code you'd be much better off avoiding them. If you're going to do a GUI in .NET, the currently preferred choice is WPF.
Some people find C# an easier way to do a GUI. It's definitely true that Microsoft provides considerably more in the way of Wizards and such to do it with little or no coding if you use .NET for the job. Other people (especially those with more experience doing so) can produce a GUI in C++ just quickly (or even a little more so) using C++ instead.
Mixing languages like this can work well in relatively large projects where you have completely separate teams of people working on the different parts. For smaller projects where the same people typically work on both parts, the difference in syntax is at just about the worst possible level -- not enough different to really shift gears and think differently, but still enough different that you can't plan on just typing things and having any hope of them compiling. All in all, you're usually a lot better off picking one language and sticking to it.

Develop in C# but deliver in VB.NET

We are an team that are dedicated C#, and will start with an new project, there the customer really wants it in VB.NET.
Are there a bad choice to do the development in C# and then convert it and deliver in VB.NET.
Are there any tools that will make this easier to us than any simple converter?

I wouldn't recommend using a converter for a whole project. They're OK for code snippets and perhaps a class at a stretch, but even with two languages like C# and VB.NET based on a common runtime there'll be things that can't be converted.
As I see it you have the following choices:
Convince the customer that writing the application in C# is for the best - it's the language you know and you'll be able to deliver a higher quality product in a shorter time.
Write it in VB.NET, but point out that it will take longer to deliver.
Don't take the project. I'm assuming that this is not an option, but I'm including it for completeness.

Each language has its unique features and specialties. It is an illusion to believe that code written in C# can seamlessly be converted to VB.net. If you do automatic conversion, you'll have to fix it manually afterwards (because it is unlikely that your project will compile) and it will have poor quality, look bad and not be optimized.

I think it is a bad idea to rely on automatic conversion if your customer wants a solution in VB.NET. The code written by an automatic converter will often use a bad coding style for that language - even if the end result is the same.
It might be OK to use an automatic conversion tool occasionally to aid the development process if you are unsure of the exact VB syntax for a C# construct. You should check the result of the conversion is a best practice in VB.NET and not just copy and paste converted code without reading it. Conversion tools can make errors or produce ugly code that a human programmer would not write. Code committed to the project should be reviewed, preferably by one of the team members with the most experience in VB.NET.
You should strive to use the best practices for VB.NET so that your customer can easily understand and maintain your code.
If you feel that your team is unable to complete the project to a high quality in VB.NET then as ChrisF mentions you might want to consider:
Declining the project.
Convincing the customer to accept a high quality C# solution instead of a low quality VB.NET solution.
Alternatively you could try to gain the competences in VB.NET you are currently missing. Some examples of ways to approach this:
Attending courses on VB.NET so you at least know the basics.
Buying and reading books about programming in VB.NET.
Employing a new team member with VB.NET experience.
Using a consultant in the initial phases to help start your project and review code until your team is able to produce high quality VB.NET code on its own.
Attempting a smaller project in VB.NET first to gain some experience.

Are there any tools?
Kind of. I don't like any of them, as they don't look "trustworthy", but you can try your luck:
http://www.developerfusion.com/tools/convert/csharp-to-vb/
http://www.carlosag.net/Tools/CodeTranslator/
http://converter.telerik.com/
Would I recommend simply translating VB to C# ?
No. Because you're forced to trust in a converter. VB really, really isn't that much of a stretch from C#. If you are doing simple things, it should be pretty easy.

Regardless of your reasoning, it is possible to do this. Use RedGate's reflector http://www.red-gate.com/products/reflector/ and Denis Bauer's disassembler http://www.denisbauer.com/NETTools/FileDisassembler.aspx. You can pick your language, and the code that comes out, while not exactly what you coded, should compile back to the same IL.

You can decompile your C# binaries with JustDecompile export it as VB.net project, load the project file in VS and build.
This, however, does not usually work out of the box as you may have to fix some minor issues like:
Anonymous Types
Indexers
reimplement "unsafe" code
As you can adjust your (existing) C# test project to test the converted project along with your original implementation.
After fixing that you have the advantage to know your VB builds and runs well, which cannot be guaranteed by any automatic converter.

What Are The Advantages/Disadvantages of Using Both VB.Net and C# In The Workplace?

At a colleague's workplace, a decision is trying to be made about whether to use both languages in the workplace or to standardize on one? There are some VB.Net developers and some C# developers.
What advantages or disadvantages would there be to using both or to using one?
Edit: To clarify this question, the question is not asking the advantages of one over the other, rather what are the advantages/disadvantage of standardizing on both languages versus standardizing on one.
For instance, one point could be that C#/VB.Net may have more third party tools available and hence it may make sense to standardize all developers on that language.

We should probably put on our Reality Glasses for this discussion. It's not just Syntactic Sugar going on here.
You will find that you can write code very quickly in Visual Basic.NET. That is largely due to some features that it has that C# does not yet provide: namely, the My namespace, which provides a plethora of functionality that C# developers have to frequently code by hand. (And that's a damned shame, if you ask me.)
I code in both languages every day. Coding event handlers for forms in Visual Basic is a snap, and it's VERY obvious what methods handle which events. It's not always as clear in C#. On the other hand, you can't always be as explicit in Visual Basic as you want to be, because Visual Basic does so much of the work for you. C# has the advantage of just getting the heck out of your way, and letting you get down to the nuts and bolts. Quite often, that's extremely liberating.
VB will let you invoke static/shared methods on an object instance. C# won't. You'll learn that the hard way when you try to port your code. C# will complain about unreachable code; VB doesn't care one way or the other.
But under the hood, when you get right down to it, it's all .NET. It all compiles down to MSIL. There will be minor differences. Visual Basic, for example, doesn't care about the case-sensitivity of names, where C# does. And the big gotcha there is that the CLR does as well. You'll realize that when you try to use reflection. Does that mean you shouldn't use VB? Nope. Just make sure you case things consistently -- especially your namespaces. (Namespace "My" and namespace "my" are two completely different namespaces to C# and the CLR, but they're the same to VB.)
Choose the language that makes you most productive, that reduces ramp-up time and maintenance costs. You may find that that means working with both languages. (We do!)
EDIT TO ADDRESS OP'S EDIT:
Refactoring tools are available for both languages.
Automated unit testing tools are equally applicable.
3rd party controls are going to be available for both languages because they're compiled down to MSIL.
Now, for IDE productivity tools, the one thing that C# has at this time that VB doesn't is StyleCop. That may change soon (and I hope it does), but I don't view it as a roadblock by any stretch of the imagination.

This is personal experience mixed with workplace lore:
VB.NET is capable of being little more nimble, compared to C#, because there isn't a standards committee (except for any that may exist at Microsoft).
Most of the Google-able code hackery out there is done in C#, and most of the best resource books provide code samples in C# only.
VB.NET is tainted with a history of VB being accessible to even the most incapable of developers. This is unfair, imho, because VB.NET is much more a "real" language. But the taint isn't going to be washed away any time soon, and "real" programmers still generally despise it.
As for real life - I code in my own time in C# and VB.NET at work. I believe that because so much of the code one writes for .NET is calls against the framework objects, the differences are actually quite small. If you can declare variables in both languages you're 80% to being portable. If you understand the framework, the syntax of the languages is a small obstacle.
EDIT to directly answer your question: We happily use both (though mainly VB.NET) and haven't ever had any problems. We use Visual Studio which allows us to pretty freely mix code files/assemblies. I would encourage you not to limit to a single language - I think some diversity is good for the brain.

My workplace had traditionally been a VB.Net shop, but a decision was made a couple years ago to switch to C#. This happened mostly because the VB developers had either left or moved into other positions and most of the new hires preferred C#. We still have a large legacy VB.Net code base, but all new development is being done in C#.
I don't think there's a strong technical reason to choose one language over the other, as they are pretty equivalent in functionality, but I do feel there are some valid reasons to choose one type of developer over the other. While I believe VB and C# are equal, there's is the unfortunate perception that C# developers are better than VB developers. While there is some justification for this, it's overblown. (It was more applicable in the C++/VB days.) That said, the perception exists. This does cause some talented developers to avoid and bash VB (though they usually do so from ignorance). I do think it's harder to hire developers into a VB shop than visa versa, because a C# developer will often balk at the idea of having to use VB, but VB developers usually aren't as opposed to using C#. There is one significant disadvantage to choosing C# over VB and that's that C# developers generally get paid more.
In my experience, the best developers welcome using both languages. The more languages you know, the better.

After tracking your question for a little bit and noting your edit, I have to wonder if you're fishing a little bit...
Either way, I think it's fairly obvious that at least the latest third-party tools favor C#. I, like the other responders, code VB for work and prefer C# for other development. I have definitely noticed that the documentation for many third-party addins/plugins and in some cases the products themselves favor C#. ReSharper, even though 4.5 has better VB support, is still vastly more comprehensive when using C#. And other frameworks, like Fluent NHibernate, don't support VB at all. So for tooling, especially when considering late-breaking stuff, I believe that C# wins. Not to mention the fact that C# got a few new features in 3.0 that won't be available until VB 10 makes a wide release.
I still agree whole-heartedly with the others; if you can do it in C#, you can do it in VB. It's all the same CLR, in the end.

I'd say given that there are "some VB.NET developers and some C# developers," there really is very little benefit to forcing everyone to use one language. Frankly even a VB.NET developer who's never looked at C# should be able to read C# code with no more than a brief introduction to the syntax, assuming he/she has a reasonable understanding of the .NET framework; and a C# developer should be able to do the same with VB.NET.
(I should also add: this is assuming everyone has access to a development environment in which the .NET languages can co-exist harmoniously -- e.g., VS2005, VS2008, etc., as opposed to one of the Express Editions, which as far as I know don't allow multi-language solutions.)

Don't fall for the "most examples / books are written for C#". Working out how to apply a C# example to VB.NET is trivial -- you'll have more trouble trying to understand what the moron who wrote the example / book is trying to do and what their hideous coding (un)convention is all about than you will mentally flipping C# syntax to VB syntax.
Also I'd say don't worry about whether you hire C# or VB.NET programmers: if they are any good at all then they won't have a problem with reading / writing both languages.
We use both here, and after a little resistance from some (we were using C++ before) have settled down fine. As I had predicted, the hardest thing for our team was (and probably still is) the conversion from MFC to .NET, not the language used to access the libraries.
FWIW our main split is VB.NET for UI code, and C# for backend / database / computation code.

C# and VB.net are the same with a different syntax. You can convert from C# to VB.net and back very easily.
VB.net does have a few extra advantages that C# does not, such as inline XML.
Most places have C# because its the more popular language.

I started out as a VB developer so naturally I migrated to VB.Net when I first worked with .Net. In fact my first .Net application was made in VB.Net too. But I tried out C# and found myself liking it better in a matter of weeks.
So I made some of that app in C# (some libraries) and it didn't hurt me. Now though I hate going back to the older VB.Net code and working on it. I really wish I could change it all to C# somehow.
That's not going to happen.
So what I am telling you here is, irrelevant of what language you choose (VB/C#) stick to it. Don't do mixed language development unless you have a compelling reason I can't think of yet :)

The advantage of standardizing on a single language is that basically everyone will have 1/2 as much to learn. I think it's better to spend the time learning more features of .NET, within a single language, rather than learning 1/2 the features in both.
As far as hiring goes, it does not really restrict you as a good VB or C# programmer should be able to switch to the other language without difficulty (or else they aren't really a good programmer :)