Visual Basic is Dead!

[Fernando A. Gómez F.]

ummm Ladies and Gentlemen, this is not a newsgroup for c# vs vb
discussions

But is a newsgroup for C# discussions, is it not? If not, I beg you a
pardon...

 

[Fernando A. Gómez F.]

Which is what made it the most popular Microsoft language ever, right?

Yep, but wasn't it the only MS language at the time?

Oh, I almost forgot: bite me.

(Flame on!)

Easy man, we're here to talk. Why did you have to go aggressive?

 

[Fernando A. Gómez F.]

....


I love lines like that. I wrote several apps in VB6 (for a former
employer) that are running fine today. I know because I still play
tennis with the old company once or twice a summer. They do exactly
what they were supposed to do and never crash and never leak memory.

So did I. I guess they still run, they did their purpose quite well. VB
had its market share, and it was designed for a specific purpose. In
particular, we used to create the front end in VB and back end
components in C++ with COM.

I once wrote a voice mail system in VB3 for a 12 step group that had
no money. It ran, 24 hours a day, 7 days a week, on a 40 mhz 386
system, no UPS, for 15 years. It used a third party tool called Visual
Voice from Stylus Innovations.

I remember that it took me about two hours to figure out how VV
worked, and about two weeks to write the app. I recently was asked to
do something similar, but the brilliantly simple Visual Voice is no
longer available. I investigated somethings offering the same TAPI
functionality with DotNet. Due to the wonderful "object oriented"
design, it is now much, much more complicated. There's a Phone object,
and a Call object, and oh, so much more. And, the cheaper version
doesn't allow you to issue a flash, so you can't do three-way calling
(that's how the old app would patch through to a volunteer).

The learning curve was staggering because the complexity was off the
charts. All to do the same stuff as VV did.

I work in DotNet, and have since version 1, so I'm well used to object
oriented technology. But it isn't always better and this was a clear
example to me.

Perhaps it was a bad design. At any rate, I agree that OO is not always
the better. Each paradigm has to be chosen according to the design goals
of the application involved.

I always laughed at guys like you, bemoaning how VB wasn't a real
language because it had a runtime. I guess C# isn't a real language
because it has this big runtime called DotNet.

Please, re-read my post. I never said it wasn't a real language, that
was your assumption. It was designed for specific tasks and under
specific conditions, as happens with any other language. The thing is,
it had all these hidden features and hacks that made the language
unclean and error-prone. Its paradigm was some kind of hybrid between
structured and OO, yet it didn't allowed truly OO design.

You can write apps with any language, and certainly each project must
choose the proper language and platform according to its design goals,
etc. I did that a long time ago, that's why I wrote VB6 code. And that's
why, when needed, I write VB.NET code (although I don't like its syntax,
which I consider too verbose). But that has nothing to do with language
characteristics, rather more with the framework and the programmer's
skills.

And as for that, from an OO perspective, VB6 lacked several features,
despite being marketed as an OO language. That is why I think VB6 sucked.

Best regards.

 

[Fernando A. Gómez F.]

I wonder why there should be the possibilty to shorten it.

Nobody said there should be one... IIUC, Neb said that VB was too
verbose (which I agree, but I guess that it is a matter of getting used
to). Rossum's reply implied that C# was also too verbose, just by adding
whitespace. The point of my post was to state that C# does not have to
be verbose, but that VB had to be verbose.

If only because that was one of the original primary design goals for
the language.

The way the
property is defined in VB allows for easy extension by adding new
statements to each accessor's body.
If I want to see the signatures only, I use the class view or object
browser instead.

Best regards.

 

[Herfried K. Wagner [MVP]]

Probably doable too in VbNet, the line:


public int WhatIsThat { get; set; }


***completely*** defines a perfectly working read/write propery, with
anonymous variable 'sustaining it', in C#, since version 3.5 of the
framework (if not before). It is not 'just' the signature. I don't see it
often used, though, in comparison with the long version., which uses an
explicit declaration of the local variable (the one capturing the 'value'
for the set definition and returning what get expect to return), and an
explicit statement for each get and set access.

Well, I never said that it's the signature only. I just mentioned that I
prefer the long version because it's easier to extend. The long version's
code skeleton is typically generated by a code snippet, including the
backing field.

 

[Nobody]

Yep, but wasn't it the only MS language at the time?

Nope, sure wasn't.

 

[Fernando A. Gómez F.]

Nope, sure wasn't.

Sorry I missed that. Which other languages had MS at the time?
Certainly, C++ is not a MS language... Perhaps you refer to J++?

Best regards.

 

[Branco]

[SNIP]>And having 3rd parties cast out off the Windows API is great,

considering the amount of trouble bad usage of said API and COM has
brought to us all in the years before .Net.

[SNIP]

No, it was mostly hackers and malware that caused the most persistent
problems that weren't already caused by defects in the API and COM
themselves  - and nearly all of the malware causing these problems got in
due to slack security settings that allowed the JavaScript, VBscript, &
ActiveX autoloaders to execute without the user's knowledge or consent.

Yes, but, then, not exactly (IMHO). It's true that the lack of
security in the OS allowed for a really fun ride for hackers, script
kiddies and their neighbour's dog, but the political development of
the Windows API, the different models it had (has) to support to
favour legacy compatibility, etc, well, it seems to me that that
allowed for a lot of damage also, due to friendly fire. I seem to
remember a nasty bug in the GetWindowText API caused by some clever
programmers using the window caption to pass (binary) data around
between running instances of their apps. Programmers (from big
companies like Adobe) went through hoops and jumps and twists to force
Windows behave according to their plans and then there were the
counter hoops and anti-jumps placed by MS to revert Windows back to
its (uh...) "correct" behavior (sorry for not providing factual
references, these are stories I remember reading in my long gone --
stolen, mind you -- MSDN Magazine collection *before* it was branded
"MSDN Magazine").

As for buggy software, no serious problems here. Back in 1999, I surveyed
nearly 500 software packages and less than twenty functioned substantially
as documented. Most didn't function at all, many were pretendware (GUI with
no other object code), and about 1 in 5 blue screened windows or crashed
Windows altogether if they were set to run on startup. The Windows 98SE
operating system that bore the full fury of these tests still runs to this
day, and is more stable than some WinXP and Vista systems.

That doesn't surprise me a bit, I had my fair share of non-working
commercial applications or the ones that subverted the system in such
a way as to drive it (and me) nuts.

I might add that third party software is much improved. Fully half of it
actually works these days and pretendware is much rarer than it was in the
90's. Nonetheless if buggy software caused the amount of grief you mention,
that clunky old Win98SE system of mine would be reduced to a smoking pile of
blue-screens by now. This is not the case.

<snip>

"Fully half of it actually works" is some statement! =)) It seems we
actually agree. Don't you think that having those bad programmers
working in a more "secure", "rich", "easier to learn" and "accessible"
environment (.Net) may produce better applications? In the meanwhile,
nothing would stop the real bad *ass* programmers from giving us
Proccess Explorer and similar (unmanaged, native, API based, etc)
shining apps.

Here in Brazil we have the expresion "Boi de piranha". It's how you
call the cow that is sent alone as bait to cross the river downstream
so it attracts all the piranhas (really, really bad fish) and allows
for the rest of the cattle to cross safelly upstream. To me .Net is a
boi de piranha for the general programmer. I consider myself a
reasonable to good programmer and I notice that I write better .Net
apps than I write "API based" apps (damn, I just realized I'm a
piranha!)

Best regards,

Branco.

 

[Branco]

mayayana wrote (responding to a post of mine):
Me:

And having 3rd parties cast out off the Windows API is great,
considering the amount of trouble bad usage of said API and COM has
brought to us all in the years before .Net.
Mayayana:
  I daresay that whole idea of "get the clowns
out of the API" is a good example of a cliche
that's been spread around, and that people have
picked up without really thinking about it. As the
marketing experts know, it's very easy to get
people to accept a premise by simply repeating
it over and over.

It's certainly a coincidence that this is repeated over and over and
also a cliché, besides being my educated opinion =)))

  When your anti-API statement is scrutinized it's really
a somewhat illogical thing for a programmer to say. It
amounts to saying, "I'm happy to be put into a sandbox
where I can't access the system if that helps to block
other people who don't know what they're doing."

Well, yes, nicelly put. Of course, nothing is really restraining me
from actually using tools that allowed me access to the API. So, yes,
its a choice I make and I hope others make too, so the guys who "don't
know what they're doing" (API-wise) can come to this bandwagon and
know a little better =D

  Beyond that there's a profound implication in
the changes brought by .Net's sandbox. The end result
of shutting off the real API is the transformation
of Windows from a platform to a service. The
security/stability issue is a red herring. (Remember,
the original idea was that an OS is a "platform"
that supports software by interfacing with the
hardware. It's important to distinguish between
needed security improvements on the one hand,
and radical redefiniton of the product on the other.)

I don't see the problem in Windows turning (evolving?) from platform
to service. That's actually what Windows -- and it's API -- allways
longed to be (IMHO). This role of providing a thin abstraction layer
between application and hardware was never played very well by Windows
since its inception, and I doubt it defines this OS as we know it.

 ...And speaking of cliches, what's with all the
badmouthing of COM? I don't mean just what you
said. I've heard derision of COM for years. But I don't
find any problems with it. It's been great for scripting.
And Windows itself is still extensively COM-oriented,
while being almost entirely free of .Net.

Yeah, I see your point, but don't get me wrong: I'm not bad mouthing
COM. My opinion is that COM was a fantastic breakthrough in
application interoperability, a really visionary and radical approach
(yes, there was CORBA, but COM actually *existed*, contrary to CORBA).
Trying to learn COM made me a better programmer, really =))

But COM for the masses had an intrinsic complexity that no tool
(besides VB) would easily circumvent (C++ smart pointers were
"discovered" too late in the game when there was a lot of damage
already done by programmers forgetting to call AddRef/Release
appropriately). Thus there were lots of badly written COM application
(or so the legend says). I remember that .Net exploded on our faces
just when COM was preparing to turn into COM+. For a few months MS' PR
was "COM+ this" and "COM+ that", "COM+ is the wave of the future", and
then *boom* there was .Net. It really seemed to me that a political
tour de force had ensued inside Microsoft and this new platform (lol
sorry, "service") got the upper hand, maybe because it provided
answers to COM "faillures" that outshone COM's benefits (DLL hell,
registry bloat, referene counting, anyone?)

The merit of .Net, in my opinion, is to provide this really rich and
*likable* environment (for a programmer such as myself) while it
allows the OS to continue its regular existence: as you notice,
Windows is vastly COM-based still.

 The "dependency" part is really relative, don't you aggree?

  Ultimately, sure. But a basic XP system is about 1GB.
.Net2 is about 88 MB unpacked, by my measure. As I
understand it, .Net3 is over 200 MB. It's adding some
25% to the OS. So where do you draw the line with
what's "relative"? Would you install a 2 MB Java program
if you knew it was going to require a 200-300MB VM?
I wouldn't.

I'd install Vista, which would change the contribution of disk usage
from the .Net libraries to mere 2% of the OS =)))

I'm just kidding of course. Or maybe not. Vista takes up 10GB of space
in a regular install, if I'm not mistaken. What drives us to install
such a monster? Even the slim and fat-free (yeah, right) XP seems huge
if we compare its 1GB (I'm trusting your numbers, here) to, say, a
functional Linux install that fits what? 100 MB? And then came World
of Warcraft. Damn, that thing alone is 15GB!!

   We're talking here about whether .Net is a sensible
choice for desktop software -- not just whether some
people will be agreeable to having the .Net runtime
installed. There are issues of bloat, security, possible
instability, etc. It's not just a question of how long it
takes to download the package.

  If the "relative" bloat of the runtime were not an issue
then .Net installers wouldn't be designed to sneak out
and download the runtime without even asking the person
installing the software.

  Then there's also the general unsuitability in the design
of .Net for Windows software. If you read Mark Russinovich's
piece from the link you'll see that his whole point is the same
point that I'm making. (And I suspect that most of the people
reading this also agree, and are probably using .Net not
for Windows software but rather are using it where
they might have formerly used Java -- server-side or for
producing corporate intranet web services.)

I'm using VB.Net to write corporate apps that are used in a daily
base. It replaced both VB6 and Delphi as the default development
platforms here, and suffocated to death (I really like this image,
considering the people involved) a movevement that wanted to migrate
all our development to Java. =))

What I see is: .Net is kind of fresh still, and it allowed a freedom
in development that really shines if compared to the alternatives. Is
there bloat? yeps, but this is good fat, not bad fat, and comes mostly
from new services and tools mayde available to you. Is there
instability? uh, I really hardly see it (there was a 3rd party app
once that failed to install with no elucidative message. I installed
the 3.0 redist -- the machine had only 2.0 -- and everything worked
without a glitch). Lack of security? In C# maybe. I suppose it's
easier to write a faulty app (security-wise) in C, unmanaged C++ or
unmanaged C# than to write a faulty managed .Net app (I may be wrong,
of course, we VB programmers once had a history of circumventing the
system).

Best regards,

Branco.

 

[Tim Roberts]

Sorry I missed that. Which other languages had MS at the time?
Certainly, C++ is not a MS language... Perhaps you refer to J++?

By that definition, Basic is definitely not a Microsoft language. It
predates Microsoft by a decade.

The only truly Microsoft language is C#.

 

[Mike]

By that definition, Basic is definitely not a Microsoft language. It
predates Microsoft by a decade.

The only truly Microsoft language is C#.

Good point, but isn't the analogy the same?

VB.NET is to BASIC, what
C# is to C++

C++ and BASIC aren't Microsoft invented but the mutations C# and
VB.NET are. No?

Maybe that is why SUN nips on potential mutation of JAVA by Microsoft
and sued them before it became their own. That is the reason
Microsoft is abandoning Java.NET - they can't control it.

--

 

[Bill Yanaire]

Does that mean my VB applications will stop working?


HA HA HA HA

 

[Jai Singh]

Per the decades old flame war whose smoke and flame still linger eternal in
our hearts and minds...

The reality is that no matter what the "reality" is or is not... VB, by its
very name, has always and will always, apparently, suffer from SEMANTIC
Discrimination, based solely upon its lowly, debased name... which no longer
adheres to its type descriptor.

Yet, to interject, C# is nothing but VB (in spirit and form (pun intended)).
It took the spirit and purpose of VB and wrapped it in {}. That's all. C#
is not a powerful, dangerous, low level language (save for unmanaged code
segments) - it's a nice, highly abstract language that is powerful because of
its abstraction (like VB 6 was) and that is a million miles away from message
pumps, unmanaged pointers, and hwnd of C based windows development.

The .NET Framework was a MAJOR advancement for VB and for VC++ programmers
who really wanted a simpler, VB like world to develop in... and wanted the
incredible real world gains that that provides.

VIVA LA GUERRA!

 

[Ben Voigt [C++ MVP]]

Per the decades old flame war whose smoke and flame still linger
eternal in our hearts and minds...

The reality is that no matter what the "reality" is or is not... VB,
by its very name, has always and will always, apparently, suffer from
SEMANTIC Discrimination, based solely upon its lowly, debased name...
which no longer adheres to its type descriptor.

Yet, to interject, C# is nothing but VB (in spirit and form (pun
intended)). It took the spirit and purpose of VB and wrapped it in
{}. That's all. C# is not a powerful, dangerous, low level language
(save for unmanaged code segments) - it's a nice, highly abstract
language that is powerful because of its abstraction (like VB 6 was)
and that is a million miles away from message pumps, unmanaged
pointers, and hwnd of C based windows development.

Unless you want to do something useful. In which case the HWNDs, message
dispatch loops, and everything else are right there waiting to bite the
unsuspecting C# programmer.

 

[Mike]

You have to admit, VB/NET people can certainly hold their own. They
know their place, enjoy it and don't let anyone tell them otherwise.

I was once in a $40M project with 36 or so people during a recession
where many engineers were transferred into the C/C++ OS/2 software
project to give them work. They struggled big time with C/C++ and
OS/2 GUI slowing the project with lots of newbie C/C++ bad coding and
just a terrible time in writing GUI programs. Then something
incredible happen - Microsoft came out with a killer app called Visual
Basic, along with Windows 3.0, MS split with IBM, dumped OS/2 and
because of VB, the project was reduce $15M with 20 people, many
overpaid C/C++ OS/2 consultant were let go, the engineers prospered,
RAD, component engineering and the project was completed. Never
forget that one (I helped decide the switch).

--

 

[Timothy Casey]

By that definition, Basic is definitely not a Microsoft language. It
predates Microsoft by a decade.

The only truly Microsoft language is C#.

[SNIP]

I doubt C# is a language unto itself. C# is simply another variation or
dialect of C, along with C+, C++ etc. (hence the affectation of 'C' with
modifier in the name).

The only language I can trace back to Microsoft is RTF (1987). RTF can be
structured two ways. One uses group hierarchies to define non-overlapping
format zones and results in a structure identical to that of the style of
SGML that uses the generic closure tag; </>. In RTF this is replaced by the
closing curly brace: }. Interestingly, SGML also has another structure
identical to the inline (potentially overlapping) flag system used in RTF
when the group hierarchy is not used. RTF's equivalent of block elements are
deployed with the same structure as that used in IBM's GML, which is the
root for SGML. RTF may well use different control characters, but in terms
of structure it is closer to a SGML and GML than HTML. Nevertheless, RTF,
having its own vocabulary, is much more a language unto itself than is the #
variant of C.

Much of what we consider "new" on PCs has already been done on mainframes
and minicomputers. Honeywell had DDR memory in minicomputers decades before
it was "new" in PCs and some of the decades old 1Gb SSDs used in older ICBMs
are *still* much faster than the brand "new" SSDs made for the PC market.
Macros were used to describe classes before the word 'macro' was
systematically misused to promote MS Office's reinvention of what was once
known as "master mode". Master mode was the first attempt at laying a
foundation for SaaS, once again back in the mainframe days, and once again
master mode was discredited spectacularly decades before malware authors
used the exact same techniques to exploit Office "macro" functionality. In
fact, the same techniques for information theft are still used via
JavaScript, VBScript, ActiveX, XAML, & .NET components served up to the
client as applications disguised as documents.

Relational databases have not changed since the 1970's - only the
programming interface has changed. Hierarchical databases are still plagued
by the same fragmentation issues now as they were when writers like Kroenke
(1977) outlined the methods and conundrums of data storage. Database
normalisation dates back to Codd (1970), and although Goveran & Date (1994)
are credited with the Orthogonal Design principle, the concept of functional
dependence discussed by authors like Kroenke (1977) is not dissimilar.

Basic was first designed and put to use at Dartmouth College by John Kemeny
and Thomas Kurtz in 1964. However as most of the original vocabulary of
Basic continues in Visual Basic, then VB is likewise an evolved dialect of
Basic (in much the same way that Standard Italian is an evolved dialect of
Latin - probably with overlap of variations of local dialect thrown in for
broader accessibility). The world's first IDE came with Dartmouth Basic, as
Basic was not intended to be simply a beginner's programming language but to
serve as an example of the cost savings offered by a little versatility and
simplified UI. This focus on simplicity is probably why Basic remained the
most versatile programming language. In time, console IDE evolved into
keyboard-based IDEs, such as Maestro I of the 1970's and then the graphic
IDE or CASE emerged in 1982 with GraphiText, followed by DesignAid; the
first to support a wide range of structured analysis and design
methodologies.

Then there is the broken paradigm (not the hippy symbol for establishment
perspective, but the real linguistic animal). Human language structures are
verb oriented, whereas modifications like that of Basic into VB have shifted
the fundamental structural orientation from verb oriented to noun oriented.
This makes separation and identification of subject and object vastly
simpler and more consistent than the more variable verb oriented
expressions. OOP was known decades ago as State Driven Programming and has
quite a long history. It was MIT that originally smashed the paradigm with
PDP-1, shortly followed by Daal & Nygaard's Simula 67 in the 1960's, which
interestingly also had the first 'garbage collection' functionality.

I think that VB will probably evolve into the programming equivalent of
"English" because it is used more often in reliable communications regarding
programming methods. VB already has demonstrable roots in GML, SGML,
Dartmouth Basic, PDP-1, Simula 67, & DesignAid, with influences hailing from
C (multilevel programming), Pascal (string assembly systems), etc. Only dead
languages like Latin and Esperanto are pretty. Popular languages are always
'bastardised' and anything but eloquent because it is that flexibility,
which makes a language most accessible to the broadest possible demographic;
and accessibility is the lifeblood of language.

 

[Mike]

> [Snip]

Good show Timothy. Very good recollection of related computer history.

I think that VB will probably evolve into the programming equivalent of
"English" because it is used more often in reliable communications
regarding programming methods.

+1, BASIC dialect will most likely remain with us for a very long
time. I keep thinking "Maybe" we should switch our embedded server
langager to V8 (Google Javascript dialect used in Chrome), but we use
the basic BASIC dialect for marketing reasons - most people understand it.

However, we have also been moving back and forth and closer towards
interpreted languages, dynamic programming, auto construction and
execution is once again becoming feasible. The Hardware speeds pretty
much flatten out. That has always been the ultimate direction, it
came, it went, and languages like JavaScript and Prototyping methods,
along with other symbolic conceptual methods is bringing back the
basic ideas.

It will be the code (of course, it has to start somewhere), that will
be able to analyze a requirement, need, a "GAP", then code it and
executed it. Half the beauty of the smart IDE is just that,
auto-generation of code that links the different ideas.

On the practical side, The MS VB design team need to focus on the idea
that people have matured and can compress their coding and since
VB.NET does compile to the same footprint as C++/CLR and C#, they
will/have attract many C/C++ developers. Not necessarily to switch,
but to use VB.NET mode. It will be a mistake to believe that just
because the RAD (GUI designing) is now also available for C++ and C#,
that this would be enough to move everyone to C/C++/C#. No, big time
marketing mistake.

--

 

[Axel]

Unless you want to do something useful. In which case the HWNDs, message
dispatch loops, and everything else are right there waiting to bite the
unsuspecting C# programmer.

Well that's what I we read the Petzold for back in the 90s! I remember
porting image processing software from DOS (32bit with DOS4GW) to Win16
to Win32s to Win95/98, remember "thunking" and 32 bit extenders? And
always fighting with the stack limitations - but for visual image
processing there wasn't really much choice but C++ and assembler.

We've come a long way but since then but I recall no problems with a
properly managed message loop, in fact I always thought that was one of
the enjoyable things to debug... When I had to move to VB in my new job
(because nobody there want to support C) I first hated it, but you get
used to most of the limitations - as long as you don't have to deal with
other people's code.

Now its fast forward to post 2008 and luckily our customers prefer C#, I
had no problems with switching to that, found it a lot easier than
dealing with C++ and ATL; definitely don't want to go back to VB. My
favorite feature of C# is tight scoping, to me } means a lot more than
END. Also explicit casting is so much nicer - VB used to often trap one
(especially with DateTime types) by doing oblique type conversions,
often resulting in garbled data.

PeekMessage, anyone?

Axel

 

[Axel]

Unless you want to do something useful. In which case the HWNDs, message
dispatch loops, and everything else are right there waiting to bite the
unsuspecting C# programmer.

Well that's what I we read the Petzold for back in the 90s! I remember
porting image processing software from DOS (32bit with DOS4GW) to Win16
to Win32s to Win95/98, remember "thunking" and 32 bit extenders? And
always fighting with the stack limitations - but for visual image
processing there wasn't really much choice but C++ and assembler. "So
little time, so many pixels."

We've come a long way but since then but I recall no problems with a
properly managed message loop, in fact I always thought that was one of
the enjoyable things to debug... When I had to move to VB in my new job
(because nobody there want to support C) I first hated it, but you get
used to most of the limitations - as long as you don't have to deal with
other people's code.

Now its fast forward to post 2008 and luckily our customers prefer C#, I
had no problems with switching to that, found it a lot easier than
dealing with C++ and ATL; definitely don't want to go back to VB. My
favorite feature of C# is tight scoping, to me } means a lot more than
END. Also explicit casting is so much nicer - VB used to often trap one
(especially with DateTime types) by doing oblique type conversions,
often resulting in garbled data.

PeekMessage, anyone?

Axel

 

[Martin H.]

Hello Axel,

Also explicit casting is so much nicer - VB used to often trap one
(especially with DateTime types) by doing oblique type conversions,
often resulting in garbled data.

You can set VB.NET to strict, so if you cast implicitly you will receive
an error from the compiler.

PeekMessage, anyone?

SYS64738
READY.

I like BASIC dialects better than C dialects as the source code is
easier to read. And with the .NET framework underneath it does not
really matter which language you use as they all target the same framework.

There are quite some things in C# where I really wonder...
For example: Why cant you use variables with a "switch" statement?
In VB.NET you can use variables with "Select Case" statement. Or indexed
properties: A property is nothing but a function. Why can't I use
parameters with it? In my opinion, MS should take the good features of
the VS languages and make them available to the other languages. It
should really make no difference which language you use. But all the
languages have their own set of features which maybe the other languages
don't support (completely - as for case sensitive variables in VB.NET).

Best regards,

Martin