Welcome to MSDN Blogs Sign in | Join | Help

Craig Skibo's WebLog

Sorry I can't answer the phone right now, I am outside feeding yogurt to the clowns.
Parlez vous .NET?

So today I was reading up on a development community website, and I ran across one of the classic arguments that will ultimately erupt when two or more Windows developers get together: which is the better language, VB, C# or Managed C++. These arguments always make me chuckle a bit, because with the .NET Framework it does not make much of a difference which language you choose since it all gets compiled down to IL

 

That discussion did remind me of an idea I had at one time, and if any of you adventurous developers feel like stealing the idea and implementing it yourself, then by all means steal away. Why do you need to select one language over another, why can’t you use all of them? I can create a HTML file, and use different languages within that page. For example, I could use JScript and VB Script at the same time, as so:

 

<html>

      <body>

            <script language="jscript">

                  alert("Hello");

            </script>

            <script language="vbscript">

                  msgbox "Hello"

            </script>

      </body>

</html>

 

Why can’t I do the same with VB.NET, C#, or managed C++? For instance, why can’t I start Visual Studio, create a blank project, and enter code such as this:

 

<code language="VBNet">

Public Class Class1

      Sub Function1()

            System.Windows.Forms.MessageBox.Show("Hello from VB")

      End Sub

End Class

</code>

<code language="CSharp">

public class Class2

{

      static string s = “abc”;

      public void Function2()

      {

            System.Windows.Forms.MessageBox.Show("Hello from C#");

      }

}

</code>

<code language="MCPP">

public __gc class Class3

{

public:

      void Function3()

      {

            System::Windows::Forms::MessageBox::Show(S"Hello from managed C++");

            System::Windows::Forms::MessageBox::Show(Class2::s);

      }

};

</code>

 

There are ways of doing something like this with current technology. I could create three separate projects, add project to project references, and call across the different assemblies. But then I need to build three separate projects, create, package, and install three separate DLLs. I could also create net modules, but then again, you would have three separate DLLs.

 

This new model has some other benefits. How many times have you found a sample function that would work perfectly for your code? If you selected one language (suppose C++) but the sample code is in another language (for example VB .NET), then you need to translate the code into the other language. That is not too tough if the code is small, but if it is a few hundred, or even a few thousand lines, you would spend more time translating than writing it from scratch (and even cause a number of bugs while doing it).  Not only does it enable better code sharing, but it also allows better team development. It will allow all the developers in your group to put all their code in one project, and use whatever language they want to use without the code being scattered about.

 

This has not been completely thought through though (say that three times fast). For example, how does Function3 access the static variable s declared within Class2? Cross-language data access is not allowed in the HTML version, either, so this is not something new. The compilers today are type safe, and if the compiler cannot find the type of variable s, then how can it compile? And why should each function be declared in separate classes? Why can’t you declare a class, and have Function1, Function2, and Function3 within the same class, but use different languages? I didn’t say it would be easy, or even work with the current technology, only that I think it would be an easier way of developing.

Posted: Friday, September 26, 2003 2:33 PM by CraigSkibo

Comments

MartinJ said:

Something like this could be done using an intermediate compilation. C has had this interesting thing where comiling and linking are two separate steps. It would be nice to have something like this in .net. Your source code parts would compile into separate object files. This would then get linked together into a final IL assembly. Another side effect would be embedded libraries. I know a couple of us on GDN have argued for this ability. I seem to use the same set of methods in almost every project (build and return a new database connection as a public static property). It would be nice to not have to type this in, or add the same source code to every project. Just add the code to a library and have it get included in a default list of libraries to search through.
# September 26, 2003 2:46 PM

Dan Smith said:

I don't think this is the same as the problem you're talking about, but it would be a nice step along the path: in Visual Studio, get rid of the idea of a "C# project" vs. a "VB project". A managed project can compile C#, VB, J# or MC++ (based on file extension or an attribute in the .proj file). This would at least achive much of the "code reuse" goal w/o needing separate assemblies. Can't this already be done with the command-line tools? (that's why I said I don't think it's the same problem you're talking about - it's an IDE issue, not a CLR/compiler issue).
# September 26, 2003 3:59 PM

Craig said:

Both of these are close to what I was going after, they are not as fined grained as being able to group different languages into one project, but it still would go a long way. Being able to genrate something similar to C++ libs, or have one project that allows you to combine multiple langs and each file is compiled individually would be great. Another way of combining these concepts would to use the new partial classes construct. I am not sure which languages are going to support them, but if you could write part of a class named abc using C#, another part in VB, and yet another in MC++, all within one project, think how easy team development would be...
# September 26, 2003 4:16 PM

Mike Dimmick said:

It's a shame AL.EXE doesn't have the ability to link together two modules compiled in different languages into a single loadable (i.e. DLL or EXE) assembly. Currently the only way to do this is to run ILDASM on each module, then run ILASM on the resulting files.
# October 1, 2003 11:12 AM

David Kean said:

I think it would be a bad thing to allow this, I can just imagine some my colleagues actually utilising this and causing a maintenance nightmare. I think rather allow assemblies to be written in multiple languages, just work on make the converters between each of the languages better.
# October 12, 2003 1:00 AM

Jose Gonzalez said:

How about this.... using System; using System.Collections; using System.Text; using System.Xml; using System.IO; using CSToVBLib; namespace VBC { /// <summary> /// Converts a .vbc file to .vb /// </summary> public class VBC { public static void Main() { // The output buffer StringBuilder objBuffer = new StringBuilder(); // From the VB Resource Kit, see GotDotNet CSToVBLib.Translator c_Trans = new Translator(); // The input parser XmlDocument c_Code = new XmlDocument(); // Get the .vbc file c_Code.Load(Directory.GetCurrentDirectory() + @"\source.vbc"); // Convert each node foreach (XmlNode c_Node in c_Code.ChildNodes) { // Get the code string sCode = c_Node.InnerText; // The VB conversion for the code string sVB = null; try { // Convert C# to VB sVB = c_Trans.TranslateString(sCode); } catch { } finally { // If errors, assume VB code already! if (sVB.IndexOf("ToDo: Error") != -1) sVB = null; } // Conversion took place? if (sVB == null) { // Nope, use original objBuffer.Append(sCode); } else { // Yes, use converted! objBuffer.Append(sVB); } // Just in case objBuffer.Append("\r\n"); } // Open output FileStream objStream = new FileStream(Directory.GetCurrentDirectory() + @"\source.vb", FileMode.CreateNew); BinaryWriter objWriter = new BinaryWriter(objStream); // Write objWriter.Write(objBuffer.ToString()); objWriter.Flush(); objWriter.Close(); // Instead of writing it out... Compile it! } } } Using as input: <base> <code> Public Class Class1 Sub Function1() System.Windows.Forms.MessageBox.Show("Hello from VB") End Sub End Class </code> <code> public class Class2 { static string s = "abc"; public void Function2() { System.Windows.Forms.MessageBox.Show("Hello from C#"); } } </code> </base>
# October 13, 2003 9:20 PM

Fabián said:

( http://riosur.net )´Lexico, an OOPL in spanish for students operate and use .net framework and dlls produced by other .net languages. Example: incluya "System.Windows.Forms" clase ventana {derivada_de "System.Windows.Forms.Form" publicos: mensajes: ventana copie "Este es el título de mi primera ventana: Oct.24.03" en ventana.text }
# October 24, 2003 10:57 AM

Anonymous said:

That all three languages compile to IL doesn't doesn't answer the question of which one is better.
# October 28, 2003 4:05 PM

Blue Streak said:

This would be great if you had a script engine for the .NET Framework and have it run like Windows Script Host (WSH).  Then define a XML file similar to WSF file and run it like the above example.

I think there are a few .NET script engine out there in some open source sites.

# November 14, 2007 10:53 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

  
Enter Code Here: Required

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker