• Advertisement
  • entries
    1212
  • comments
    1738
  • views
    1143711

sea prime to the sea

Sign in to follow this  

52 views

I have a confession to make. . .My name is John Hattan and I. . .. . .think C# is a good idea.

OK, lemme clarify. C# isn't a great idea, but the technology behind it has serious promise. Lemme explain.

Java was an idea who's time had come. It very successfully fixed a lot of flaws in its predecessor C++ that was keeping C++ from being useful in component-type applications. Java's interpreted nature eliminated a lot of the maintenance nightmares with C++, like the ability to actually make typesafe late-linked libraries without having to resort to a colossal patchwork kludge like COM. The fact that Java is interpreted also makes cross-platform executables a reality.

Java, however, has a giant flaw --the Java VM. The Java VM executes a language called overcomplicated OO assembly-looking Java hybrid byte-code sort of thing. Earlier efforts at making cross-platform executables used stuff like P-code or Forth and could execute via a very small quick-running stack-based interpreter that was easy to port to other platforms. The other big problem is that the Java VM is eternally married to the Java language. While that's not a glaring flaw, it would be nice to allow folks to be able to write code in the most appropriate language, be it C++, Eiffel, Java, or VB, and have it run cross-platform without having to port a new VM every time.

The whole C# bit evolved from MS's Common Language Runtime. This is a VM that isn't married to a particular language, and Visual Studio 7 will allow you to create apps in several languages (C++, C#, VB, and Java will ship with it, with Perl, Eiffel, and Python in the works) that'll run on this new VM. In theory, if this VM gets ported to other platforms, portability will be a reality for your executable, no matter what language you wrote it in. Another advantage is that the VM executes a fairly simple stack-oriented assembly, which can be executed at near-native speeds without stuff like JIT.

And yes, you can still compile C++ to native code, or you can even use a mix native-code C++ and VM C++ by putting a directive at the beginning of your functions. You lose portability, but you can keep the late-binding niceties.

As I see it, C# itself was a creature of necessity. MS got clobbered in court when they tried to enhance Java, so they either had to dump the idea of a CPP-like language that supports garbage collection and Java-esque late binding, or they could create their own. The new VS7 will support completely transparent interopability between interpreted C# and compiled C++, which is a good thing because as nice as folks claimed calling C++ from Java was, it was at best an ugly kludge.

A final Good Thing is that since the VB-style forms metaphor is supported in Visual Studio 7, it's available for all of its languages. That means that you get VB-style forms stuff with all of the supported languages. It's no great shakes for C++, as Borland Builder's had that capability for a while, but it would be cool to have it with a traditionally command-line-only language like Perl. That way I could write quickie file filters with a simple GUI front-end and Perl's text-handling abilities on the back-end. Nice.

It remains to be seen how much of this blue sky stuff will actually be as nice as it's presented, but it certainly does sound promising.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement