Why all .NET
languages are born equal
.NET compilers generate
platform-independent pseudo-code rather than machine code. This pseudo-code,
known as Intermediate Language (or IL), is conceptually similar to VB's
p-code, which might sound as a step backwards, until you realize that IL code
can theoretically run on different CPU and operating systems, provided that a
.NET runtime and a .NET framework is available for that platform (Figure 2).
For the time being Microsoft has announced a CLR only for Windows operating
systems (CE, 9x/ME, NT/2000), but they don't exclude a porting to other
An important difference with
traditional compiled code is that p-code IL isn't really interpreted - as
the VB's p-code is, - rather it is Just In Time compiled
(or JITted) into native code when the application runs, and is
optimized for the CPU on which the application is running.
The JIT process tends to slow down
application loading but Microsoft is implementing several optimizing
techniques to minimize this problem. Moreover, they announced a JIT
version that saves compile results on disk and therefore speeds up
following executions. There will be also a light version (EconoJIT) that
compiles one procedure at a time, discarding the native code after each
execution (this version has been designed for CE-based systems with fewer
resources and memory).
At present, .NET applications run
slower than Win32 ones, but Microsoft claims that the release versions of
.NET languages will outperform existing Win32 languages, thanks to a
tighter integration of the .NET framework with the operating system.
code is compiled into IL p-code
and executed by the Common Language Runtime.
Say goodbye to
Broad and large, the VB programming model
remains the same, except for the syntax changes: you still work with forms, the
toolbox, properties and events (Figure 1).
You shouldn't be cheated into believing
that nothing has changed, though: .NET is the evolution of COM technology and
will eventually replace it. Of course, the transition will be gradual and the
time you invest today on COM won't be wasted: .NET and COM components are 100%
compatible and can interoperate. This means that all COM concepts such
interfaces, classes and components still exist and have the same fundamental
role than ever, even though they are implemented on a different infrastructure:
before you had OLEAUT32.DLL, now you work with the CLR.
Things are different for MTS/COM+:
component services such transactions, object pooling, and queuing are fully
integrated and accessible from within VB.NET. In the long run, CLR will replace
COM+ services too, though.
Same runtime, same libraries, and same
p-code: Visual Basic is at the same level as other languages, but is this true
also as far as performance is involved? Yes, it is. Before .NET advent, VB's bad
reputation was mainly due to slow execution, but now things are changed. With a
correctly designed and implemented compiler , apps will run at the same speed,
regardless of which languages they are written in. More specifically, VB.NET is
as fast as C# on the average, and the two compilers are structured in the same
Several developers consider C# as the .NET
language for excellence. What has C# that VB.NET hasn't? In my opinion, the only
extra-features that are really relevant in .NET are operator overloading, and unsigned
Some tasks are out of reach for VB.NET,
but this isn't really important for most programmers. With VB.NET, for instance,
you can finally develop Windows NT/2000 services, in a surprisingly effortless
Finally, keep in mind that is always
possible to combine C# and VB code.. The two languages are equivalent and there
aren't many important reasons to consider either one better than the other. You
might want to learn C#, however, if you want to better understand all the
examples and the documentation about the framework's more advanced features.
The next version of VB will have a lot of changes: VB.NET
is finally a first-class, fully object oriented language. At the same time it's
also more difficult to use, and requiresmore familiarity with object-oriented
programming and design concepts. It's important to not get carried away and deal
wotj the changeover cautiously, and then you'll have a new language and