R
RobinS
Tom Shelton said:
Yes, I understood. I sometimes post vb code to the c# group, and mostly
just hope I don't *forget* the semicolons. ;-)
Robin
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Yes, I understood. I sometimes post vb code to the c# group, and mostly
just hope I don't *forget* the semicolons. ;-)
Robin
T
Tony Proctor
(sorry, my last post didn't include the full set of groups for this thread)
Yes, but then what if you have an implementation of a script language,
written in VB6, which in turn relies on the Variant data type (as do most
script languages). Since there is no native support for that data type, it
cannot easily be moved across Tom
There are good reasons for why you might end up in this situation:
'scripting' is a powerful tool that's also advocated by MSFT themselves. It
isn't just related to HTML generation. It can be used to express business
rules in XML content, for instance. In the COM world, there's only the
Scripting control, which may have been removed anyway, and which cannot be
embedded in server-side code. There's better support for scripting in the
..Net world, but that doesn't help with portability of existing code.
Tony Proctor
Yes, but then what if you have an implementation of a script language,
written in VB6, which in turn relies on the Variant data type (as do most
script languages). Since there is no native support for that data type, it
cannot easily be moved across Tom
There are good reasons for why you might end up in this situation:
'scripting' is a powerful tool that's also advocated by MSFT themselves. It
isn't just related to HTML generation. It can be used to express business
rules in XML content, for instance. In the COM world, there's only the
Scripting control, which may have been removed anyway, and which cannot be
embedded in server-side code. There's better support for scripting in the
..Net world, but that doesn't help with portability of existing code.
Tony Proctor
Tom Shelton said:["Followup-To:" header set to microsoft.public.dotnet.languages.vb.]
P
Paul Clement
¤ >
¤ > C# and Visual Basic.NET are completely different languages. They use
¤ > different operators, different
¤ > syntax and different statements and functions. The only thing they share
¤ > are the .NET Framework
¤ > libraries - extensions to their respective languages.
¤ >
¤
¤ Funny... that's what this guy says about the, so called, similarities in VB
¤ vs B#. The only thing they share are the letters "V" and "B" in their names.
¤
¤ VB6 Glass Ceiling
¤ http://www.ddj.com/dept/windows/184406274
Must be a C# developer. ;-)
The podcast doesn't seem to be functioning for me.
Paul
~~~~
Microsoft MVP (Visual Basic)
¤ > C# and Visual Basic.NET are completely different languages. They use
¤ > different operators, different
¤ > syntax and different statements and functions. The only thing they share
¤ > are the .NET Framework
¤ > libraries - extensions to their respective languages.
¤ >
¤
¤ Funny... that's what this guy says about the, so called, similarities in VB
¤ vs B#. The only thing they share are the letters "V" and "B" in their names.
¤
¤ VB6 Glass Ceiling
¤ http://www.ddj.com/dept/windows/184406274
Must be a C# developer. ;-)
The podcast doesn't seem to be functioning for me.
Paul
~~~~
Microsoft MVP (Visual Basic)
R
Robert Morley
Me either, on two different computers with completely different setups.
Rob
Rob
H
Herfried K. Wagner [MVP]
mayayana said:As an MVP you might have the consideration to
drop the VB groups from your post and keep it in
.Net. Most of the people here are here to discuss
VB6 code, not to count angels on the head of a
dotnet pin.
As the topic is related to both VB6 and VB.NET, I believe it's correct to
post them to both groups. BTW, I have a long Classic VB history and was an
avid supporter of the "VB.COM" petition.
S
Schmidt
LOL.C# and Visual Basic.NET are completely different languages...
So different, that the ICSharp-IDE can switch back and forth
between them on the fly.
Herfried IMO perfectly nailed the problem.
It's only about saving Code-Investments.
Could have lived well even with an "VB6-To-C#-Only"
Import-Tool, if it only would do its job right.
Olaf
P
Paul Clement
¤
¤
¤
¤ > The problem is that several of them refer to the "core language" (absent of language extensions)
¤ > only when it suits their argument. If you tell them that Microsoft has routinely broken code over
¤ > the years with changes to the language extensions then they'll chime on about how the "core
¤ > language" is what's truly important because it drives the "business logic" of their applications.
¤ > However, if you point out that over 90% of the core language is still intact, then they'll challenge
¤ > you run a Classic Visual Basic app through the upgrade wizard and then tell them that the
¤ > "languages" are the same.
¤
¤
¤ Considering the language's Statements and Functions make up the lion's share of
¤ the 'core language', I just did a quick tally of VB5 against VB 2005:
¤
¤ VB5 Net Both
¤ Statements 95 51 33
¤ Functions 140 128 116
¤
¤
¤ Of VB5's 95 statements, only 33 were also found as statements in VB2005.
¤ Of VB5's 140 functions, only 116 were found listed under functions for VB2005.
¤
¤ That makes for 149 out of 235 possible commands where you'd find they
¤ were the same. That was a rough count, but on the surface they appear to
¤ be only about 65% the same....
¤
¤ And that does not take into account the difference in methodology of typical
¤ VB code compared to VB2005, such as; Event handling, Variable declarations,
¤ creating Objects, and of course 'Deterministic Finalization'....
¤
¤ You have got to admit there is a significant gap when the simplest of programs
¤ need a complete rewrite to do the same task:
¤
¤ Private Sub Form_Load()
¤ AutoRedraw = True
¤ Print "Hello World"
¤ End Sub
I took a look at this and compared VB 6.0 to VB.NET. My numbers are rather different so I'm not sure
how you did the comparison. I omitted language extensions (e.g. Load, Unload, etc.)
Deterministic Finalization is not a language feature. Not sure what you're talking about when you
refer to event handling, variable declarations and creating objects. They all pretty much use the
same language statements, although syntax may be slightly different.
Total # of functions and statements present: 162 of 192. OK, so it's about 85%. I was off by a
little over %5. I guess that means they aren't as similar as I thought. ;-)
Functions:
VB 6.0 VB.NET
------ ------
Abs x
Array x
Asc x
Atn -
CallByName x
Choose x
Chr x
Command x
Cos x
CreateObject x
CurDir x
CvErr -
Date -
DateAdd x
DateDiff x
DatePart x
DateSerial x
Day x
DDB x
Dir x
DoEvents x
Environ x
EOF x
Error -
Exp x
FileAttr x
FileDateTime x
FileLen x
Filter -
Fix x
Format x
FormatCurrency x
FormatDateTime x
FormatNumber x
FormatPercent x
FreeFile x
FV x
GetAllSettings x
GetAttr x
GetAutoServerSettings -
GetObject x
GetSetting x
Hex x
Hour x
IIf x
Input x
InputBox x
InStr x
InStrRev x
Int x
IPmt x
IRR x
IsArray x
IsDate x
IsEmpty x
IsError x
IsMissing -
IsNull -
IsNumeric x
IsObject -
Join x
LBound x
LCase x
Left x
Len x
Loc x
LOF x
Log x
LTrim x
Mid x
Minute x
MIRR x
Month x
MonthName x
MsgBox x
Now x
NPer x
NPV x
Oct x
Partition x
Pmt x
PPmt x
PV x
QBColor x
Rate x
Replace x
RGB x
Right x
Rnd x
Round x
RTrim x
Second x
Seek x
Sgn -
Shell x
Sin x
SLN x
Space x
Spc x
Split x
Sqr -
Str x
StrComp x
StrConv x
Str x
StrReverse x
SYD x
Tab x
Tan x
Time -
Timer x
TimeSerial x
TimeValue x
Trim x
TypeName x
UBound x
UCase x
Val x
VarType x
WeekDay x
WeekDayName x
Year x
Total 110 of 122 present
Statements
VB 6.0 VB.NET
------ ------
AppActivate x
Beep x
Call -
ChDir x
ChDrive x
Close -
Const x
Date x
Declare x
DefType -
DeleteSetting x
Dim x
Do...Loop x
End x
Enum x
Erase x
Event x
Exit x
FileCopy x
For Each...Next x
Function x
Get -
GoSub...Return -
GoTo x
If...Then...Else x
Implements x
Input x
Kill x
Let -
Line Input -
Lock x
LSet x
Mid x
MkDir x
Name -
On Error x
On...GoSub or GoTo -
Open x
Option Base -
Option Compare x
Option Explicit x
Option Private -
Print x
Private x
Property x
Public x
Put -
RaiseEvent x
Randomize x
ReDim x
Rem x
Reset -
Resume x
RmDir x
RSet x
SaveSetting x
Seek x
Select Case x
SendKeys x
Set -
SetAttr x
Static x
Stop -
Sub x
Time -
Type -
While x
Width -
With x
Write x
Total 52 of 70 present
Paul
~~~~
Microsoft MVP (Visual Basic)
¤
¤
¤ > The problem is that several of them refer to the "core language" (absent of language extensions)
¤ > only when it suits their argument. If you tell them that Microsoft has routinely broken code over
¤ > the years with changes to the language extensions then they'll chime on about how the "core
¤ > language" is what's truly important because it drives the "business logic" of their applications.
¤ > However, if you point out that over 90% of the core language is still intact, then they'll challenge
¤ > you run a Classic Visual Basic app through the upgrade wizard and then tell them that the
¤ > "languages" are the same.
¤
¤
¤ Considering the language's Statements and Functions make up the lion's share of
¤ the 'core language', I just did a quick tally of VB5 against VB 2005:
¤
¤ VB5 Net Both
¤ Statements 95 51 33
¤ Functions 140 128 116
¤
¤
¤ Of VB5's 95 statements, only 33 were also found as statements in VB2005.
¤ Of VB5's 140 functions, only 116 were found listed under functions for VB2005.
¤
¤ That makes for 149 out of 235 possible commands where you'd find they
¤ were the same. That was a rough count, but on the surface they appear to
¤ be only about 65% the same....
¤
¤ And that does not take into account the difference in methodology of typical
¤ VB code compared to VB2005, such as; Event handling, Variable declarations,
¤ creating Objects, and of course 'Deterministic Finalization'....
¤
¤ You have got to admit there is a significant gap when the simplest of programs
¤ need a complete rewrite to do the same task:
¤
¤ Private Sub Form_Load()
¤ AutoRedraw = True
¤ Print "Hello World"
¤ End Sub
I took a look at this and compared VB 6.0 to VB.NET. My numbers are rather different so I'm not sure
how you did the comparison. I omitted language extensions (e.g. Load, Unload, etc.)
Deterministic Finalization is not a language feature. Not sure what you're talking about when you
refer to event handling, variable declarations and creating objects. They all pretty much use the
same language statements, although syntax may be slightly different.
Total # of functions and statements present: 162 of 192. OK, so it's about 85%. I was off by a
little over %5. I guess that means they aren't as similar as I thought. ;-)
Functions:
VB 6.0 VB.NET
------ ------
Abs x
Array x
Asc x
Atn -
CallByName x
Choose x
Chr x
Command x
Cos x
CreateObject x
CurDir x
CvErr -
Date -
DateAdd x
DateDiff x
DatePart x
DateSerial x
Day x
DDB x
Dir x
DoEvents x
Environ x
EOF x
Error -
Exp x
FileAttr x
FileDateTime x
FileLen x
Filter -
Fix x
Format x
FormatCurrency x
FormatDateTime x
FormatNumber x
FormatPercent x
FreeFile x
FV x
GetAllSettings x
GetAttr x
GetAutoServerSettings -
GetObject x
GetSetting x
Hex x
Hour x
IIf x
Input x
InputBox x
InStr x
InStrRev x
Int x
IPmt x
IRR x
IsArray x
IsDate x
IsEmpty x
IsError x
IsMissing -
IsNull -
IsNumeric x
IsObject -
Join x
LBound x
LCase x
Left x
Len x
Loc x
LOF x
Log x
LTrim x
Mid x
Minute x
MIRR x
Month x
MonthName x
MsgBox x
Now x
NPer x
NPV x
Oct x
Partition x
Pmt x
PPmt x
PV x
QBColor x
Rate x
Replace x
RGB x
Right x
Rnd x
Round x
RTrim x
Second x
Seek x
Sgn -
Shell x
Sin x
SLN x
Space x
Spc x
Split x
Sqr -
Str x
StrComp x
StrConv x
Str x
StrReverse x
SYD x
Tab x
Tan x
Time -
Timer x
TimeSerial x
TimeValue x
Trim x
TypeName x
UBound x
UCase x
Val x
VarType x
WeekDay x
WeekDayName x
Year x
Total 110 of 122 present
Statements
VB 6.0 VB.NET
------ ------
AppActivate x
Beep x
Call -
ChDir x
ChDrive x
Close -
Const x
Date x
Declare x
DefType -
DeleteSetting x
Dim x
Do...Loop x
End x
Enum x
Erase x
Event x
Exit x
FileCopy x
For Each...Next x
Function x
Get -
GoSub...Return -
GoTo x
If...Then...Else x
Implements x
Input x
Kill x
Let -
Line Input -
Lock x
LSet x
Mid x
MkDir x
Name -
On Error x
On...GoSub or GoTo -
Open x
Option Base -
Option Compare x
Option Explicit x
Option Private -
Print x
Private x
Property x
Public x
Put -
RaiseEvent x
Randomize x
ReDim x
Rem x
Reset -
Resume x
RmDir x
RSet x
SaveSetting x
Seek x
Select Case x
SendKeys x
Set -
SetAttr x
Static x
Stop -
Sub x
Time -
Type -
While x
Width -
With x
Write x
Total 52 of 70 present
Paul
~~~~
Microsoft MVP (Visual Basic)
P
Paul Clement
¤
¤ Newsbeitrag ¤
¤ > C# and Visual Basic.NET are completely different languages...
¤ LOL.
¤ So different, that the ICSharp-IDE can switch back and forth
¤ between them on the fly.
You mean it actually removes all that C# gobbledy-gook and inserts VB keywords and syntax so that it
will compile? That's pretty cool, but if the languages are so similar why would you have to do that?
Paul
~~~~
Microsoft MVP (Visual Basic)
¤ Newsbeitrag ¤
¤ > C# and Visual Basic.NET are completely different languages...
¤ LOL.
¤ So different, that the ICSharp-IDE can switch back and forth
¤ between them on the fly.
You mean it actually removes all that C# gobbledy-gook and inserts VB keywords and syntax so that it
will compile? That's pretty cool, but if the languages are so similar why would you have to do that?
Paul
~~~~
Microsoft MVP (Visual Basic)
L
Larry Serflaten
Paul Clement said:¤ Considering the language's Statements and Functions make up the lion's share of
¤ the 'core language', I just did a quick tally of VB5 against VB 2005: ....
¤ And that does not take into account the difference in methodology of typical
¤ VB code compared to VB2005, such as; Event handling, Variable declarations,
¤ creating Objects, and of course 'Deterministic Finalization'....
I took a look at this and compared VB 6.0 to VB.NET.
Good for you. I knew VB6 would be closer than VB5, but I have never used
VB6, so for me and others like me, the change is greater than those migrating
from VB6. While you might have a more valid position, comparing from the
most recent version, the point was that your 90% figure was not truely indicative
of the effort involved in making the move from one version to "the next".
Deterministic Finalization is not a language feature. Not sure what you're talking about when you
refer to event handling, variable declarations and creating objects. They all pretty much use the
same language statements, although syntax may be slightly different.
Now why are you trying to play dumb on not understanding a difference in
coding methodologies? Many expoused the use of control arrays in VB, how
do you implement them (with all their events) in VB.Net? Where is the Set
command to create and destroy objects? What is the byte size of a variable
declared as Integer or Long in VB, and what is it in VB.Net? What happened
to the age-old Open/Print/Close methods of using files?
All those things (plus others) have to be re-learned, and often re-written, to
be compatable with VB.Net. A discarding of old knowlege in favor of the
new conditions cannot be considered to be 'similar'. Thus regardless of
the direct comparison you can make of Functions and Statements, there
is the methodology factor that is going to widen the gap.
Total # of functions and statements present: 162 of 192. OK, so it's about 85%. I was off by a
little over %5. I guess that means they aren't as similar as I thought. ;-)
And there is nothing to be gained in pretending that they are similar.
The only people who have an interest in fostering that farcical idea are
the people trying to move developers from one product to another for
their own personal gain.
I am not saying that developers shouldn't look into VB.Net, I am
only concerned that the truth be told about the effort involved in making
the move. And, to MS's credit, I also support the creation of different
newsgroups to handle discussions on the 'different' topics.
LFS
P
Paul Clement
¤ > ¤ Considering the language's Statements and Functions make up the lion's share of
¤ > ¤ the 'core language', I just did a quick tally of VB5 against VB 2005:
¤ ...
¤ > ¤ And that does not take into account the difference in methodology of typical
¤ > ¤ VB code compared to VB2005, such as; Event handling, Variable declarations,
¤ > ¤ creating Objects, and of course 'Deterministic Finalization'....
¤
¤ > I took a look at this and compared VB 6.0 to VB.NET.
¤
¤ Good for you. I knew VB6 would be closer than VB5, but I have never used
¤ VB6, so for me and others like me, the change is greater than those migrating
¤ from VB6. While you might have a more valid position, comparing from the
¤ most recent version, the point was that your 90% figure was not truely indicative
¤ of the effort involved in making the move from one version to "the next".
But that wasn't my point. Regardless of the effort, which can be attributed to many things other
than the language itself, the Classic and .NET versions share a high percentage of the language
features. The only intention of my statement was to address the contention that they were completely
different languages.
This is flat out untrue.
¤
¤ > Deterministic Finalization is not a language feature. Not sure what you're talking about when you
¤ > refer to event handling, variable declarations and creating objects. They all pretty much use the
¤ > same language statements, although syntax may be slightly different.
¤
¤ Now why are you trying to play dumb on not understanding a difference in
¤ coding methodologies? Many expoused the use of control arrays in VB, how
¤ do you implement them (with all their events) in VB.Net? Where is the Set
¤ command to create and destroy objects? What is the byte size of a variable
¤ declared as Integer or Long in VB, and what is it in VB.Net? What happened
¤ to the age-old Open/Print/Close methods of using files?
¤
¤ All those things (plus others) have to be re-learned, and often re-written, to
¤ be compatable with VB.Net. A discarding of old knowlege in favor of the
¤ new conditions cannot be considered to be 'similar'. Thus regardless of
¤ the direct comparison you can make of Functions and Statements, there
¤ is the methodology factor that is going to widen the gap.
I think this has already been acknowledged. I'm certainly not dismissing it, but it's an extension
of the facts beyond my original point, which was not offered to convince people how easy it would be
to upgrade their applications.
¤
¤ > Total # of functions and statements present: 162 of 192. OK, so it's about 85%. I was off by a
¤ > little over %5. I guess that means they aren't as similar as I thought. ;-)
¤
¤ And there is nothing to be gained in pretending that they are similar.
¤ The only people who have an interest in fostering that farcical idea are
¤ the people trying to move developers from one product to another for
¤ their own personal gain.
Perhaps a difference in attitudes. You can take what you know about Classic Visual Basic and apply
it to Visual Basic.NET, and as evidenced by my post there is quite a bit to take with you, or, you
can remain where you are or abandon what you know for an alternative. Your choice.
In any event despite the differences I've managed to either port Classic code or use it via interop
with .NET. I'm not telling anyone it's easy and in many instances it may be quite difficult. But to
deny that's it's realistic or even possible doesn't really do anyone any good.
¤ I am not saying that developers shouldn't look into VB.Net, I am
¤ only concerned that the truth be told about the effort involved in making
¤ the move. And, to MS's credit, I also support the creation of different
¤ newsgroups to handle discussions on the 'different' topics.
I think developers should be allowed to decide for themselves. If you're interested in the truth
then please feel free to correct the statements coming from those who openly voice their disdain for
Visual Basic.NET.
Paul
~~~~
Microsoft MVP (Visual Basic)
¤ > ¤ the 'core language', I just did a quick tally of VB5 against VB 2005:
¤ ...
¤ > ¤ And that does not take into account the difference in methodology of typical
¤ > ¤ VB code compared to VB2005, such as; Event handling, Variable declarations,
¤ > ¤ creating Objects, and of course 'Deterministic Finalization'....
¤
¤ > I took a look at this and compared VB 6.0 to VB.NET.
¤
¤ Good for you. I knew VB6 would be closer than VB5, but I have never used
¤ VB6, so for me and others like me, the change is greater than those migrating
¤ from VB6. While you might have a more valid position, comparing from the
¤ most recent version, the point was that your 90% figure was not truely indicative
¤ of the effort involved in making the move from one version to "the next".
But that wasn't my point. Regardless of the effort, which can be attributed to many things other
than the language itself, the Classic and .NET versions share a high percentage of the language
features. The only intention of my statement was to address the contention that they were completely
different languages.
This is flat out untrue.
¤
¤ > Deterministic Finalization is not a language feature. Not sure what you're talking about when you
¤ > refer to event handling, variable declarations and creating objects. They all pretty much use the
¤ > same language statements, although syntax may be slightly different.
¤
¤ Now why are you trying to play dumb on not understanding a difference in
¤ coding methodologies? Many expoused the use of control arrays in VB, how
¤ do you implement them (with all their events) in VB.Net? Where is the Set
¤ command to create and destroy objects? What is the byte size of a variable
¤ declared as Integer or Long in VB, and what is it in VB.Net? What happened
¤ to the age-old Open/Print/Close methods of using files?
¤
¤ All those things (plus others) have to be re-learned, and often re-written, to
¤ be compatable with VB.Net. A discarding of old knowlege in favor of the
¤ new conditions cannot be considered to be 'similar'. Thus regardless of
¤ the direct comparison you can make of Functions and Statements, there
¤ is the methodology factor that is going to widen the gap.
I think this has already been acknowledged. I'm certainly not dismissing it, but it's an extension
of the facts beyond my original point, which was not offered to convince people how easy it would be
to upgrade their applications.
¤
¤ > Total # of functions and statements present: 162 of 192. OK, so it's about 85%. I was off by a
¤ > little over %5. I guess that means they aren't as similar as I thought. ;-)
¤
¤ And there is nothing to be gained in pretending that they are similar.
¤ The only people who have an interest in fostering that farcical idea are
¤ the people trying to move developers from one product to another for
¤ their own personal gain.
Perhaps a difference in attitudes. You can take what you know about Classic Visual Basic and apply
it to Visual Basic.NET, and as evidenced by my post there is quite a bit to take with you, or, you
can remain where you are or abandon what you know for an alternative. Your choice.
In any event despite the differences I've managed to either port Classic code or use it via interop
with .NET. I'm not telling anyone it's easy and in many instances it may be quite difficult. But to
deny that's it's realistic or even possible doesn't really do anyone any good.
¤ I am not saying that developers shouldn't look into VB.Net, I am
¤ only concerned that the truth be told about the effort involved in making
¤ the move. And, to MS's credit, I also support the creation of different
¤ newsgroups to handle discussions on the 'different' topics.
I think developers should be allowed to decide for themselves. If you're interested in the truth
then please feel free to correct the statements coming from those who openly voice their disdain for
Visual Basic.NET.
Paul
~~~~
Microsoft MVP (Visual Basic)
H
Herfried K. Wagner [MVP]
Paul Clement said:¤ > C# and Visual Basic.NET are completely different languages...
¤ LOL.
¤ So different, that the ICSharp-IDE can switch back and forth
¤ between them on the fly.
You mean it actually removes all that C# gobbledy-gook and inserts VB
keywords and syntax so that it
will compile? That's pretty cool, but if the languages are so similar why
would you have to do that?
Imagine the addition of a feature crucial for further development in a
future version of one of the two programming languages only. However, if
the languages are diverging, then conversion would not be as simple any
more. Imagine the whole bunch of code you'd have to write in the next
version of C# for dealing with XML which won't be necessary in VB because of
its built-in XML support.
J
J French
On Fri, 16 Feb 2007 13:34:44 -0600, "Larry Serflaten"
If it is anything like Delphi (and the small bits I've seen look
Delph-ish) then you can hook any Event to any object procedure
providing it has the right parameters - at design time or run time.
In Delphi I do that to create sort of Control Arrays on the fly, it is
actually quite handy.
A different approach, but I've created Control Arrays in Delphi.
Easy if writing from scratch, but probably a PITA if trying to convert
existing code.
Many expoused the use of control arrays in VB, how
do you implement them (with all their events) in VB.Net?
If it is anything like Delphi (and the small bits I've seen look
Delph-ish) then you can hook any Event to any object procedure
providing it has the right parameters - at design time or run time.
In Delphi I do that to create sort of Control Arrays on the fly, it is
actually quite handy.
A different approach, but I've created Control Arrays in Delphi.
Easy if writing from scratch, but probably a PITA if trying to convert
existing code.
S
Schmidt
You mean it actually removes all that C# gobbledy-gook
and inserts VB keywords and syntax so that it will compile?
That's pretty cool, but if the languages are so similar why
would you have to do that?
[talking about language-similarities]
You are talking about languages in a strict sense.
I'm talking about *understanding*.
People on planet C# don't even need a bablefish to
understand people on planet VB#.
For people on planet VB6, the bablefish (making
understanding possible) was lost - or yet has to be
found, whatever...
Olaf