Pretty darn good translation, from the looks of it! Thanks Michael.
"Michael C#" <xyz@abcdef.com> wrote in message
news:NkQke.199$HP1.35@fe08.lga...[color=blue]
> Here's a rough translation (I did my best, chalk up minor mistakes to
> artistic license... major ones to ignorance. Please forgive if I didn't
> get it quite right) :)
> IMO, this article
> [
http://www.codeproject.com/useritems...pVersusVB.asp] is shaped by
> unfounded prejudices and based upon implications that are "off-track". I
> went through the trouble to thoroughly study and comment on the points
> made in "Propagation Of Culture in NET":
> | 1. VB by default allows support for late binding. Although it can be
> | turned off with "Option strict", the culture is such that it's usually
> | left on. This leads to numerous difficult to catch errors. C# binding
> | is always early.
>
> This has no foundation. In the professional field most developers work
> with 'option Strict on'. If 'option Strict' is switched off, then usually
> from technical considerations, it is to access a COM object model
> approximatley like the one in [MS] Office. Here, a useful secondary(?)
> functional characteristic is called a disadvantage.
>
> | 2. VB still supports the old "On error goto" construct. This leads to
> | sloppy or non-existent error handling. C# supports only the superior
> | try.catch error handling.
>
> Why does the existence of one additional error handling construct lead to
> sloppier or non-existent error handling? VB.NET supports the superior
> C#-style 'try...catch[...finally]' with ' Try...Catch...Finally'. In error
> handling, VB.NET is superior to C#, since it makes a different construct
> available, which covers a better diversity of applications.
>
> | 3. VB supports optional parameters. Although VB developers often
> | list this as an advantage, it is a disadvantage because the use of
> | optional parameters weakens the contract between the caller and
> | the method, allowing the developer to slacken his analysis and get
> | away with it until bugs creep in. [note: C# param array construct is
> | not the same as optional params]
>
> Again this is not correct. VB supports optional parameters as a
> secondary(?) functional characteristic. Sometimes within implementations
> optional parameters prove useful. Don't forget there is also the
> "Overloads Hell". You can compare the overloads of 'MessageBox.Show' with
> 'MsgBox', with the former one must scroll through numerous overloading
> pages, until you find the correct one, whereas you will find only one
> signature form with 'MsgBox' with several optional parameters. It is not
> disputed that overloaded, in some cases is advisable. Instead of using
> too many overloaded methods, however, optional parameters with their own,
> more appropriate and more specific names are also provided. In no case
> there is only one ideal solution.
>
> | 4. VB supports the legacy VB functions, with reference to Microsoft.
> | VisualBasic.dll. Many of these functions are slow and they should all
> | be avoided in favor of the .NET framework. However many VB programmers
> | still use them. In new VB projects, this dangerous namespace is
> included
> | by default.
>
> There are no recommendations on the part of Microsoft not to use
> functionality from "Microsoft.VisualBasic.dll".
> "Microsoft.VisualBasic.dll" can be seen as "language extension" of VB.NET
> and is just as sensible/clear(?) as 'using' in C#. The namespace
> 'Microsoft.VisualBasic' is in no way "dangerous", even if some of the
> functions are somewhat slower than those of the .NET Framework, some of
> the functions in this namespace are not provided at all in the .NET
> Framework (mathematics of finance, 'Left', 'right', 'fixed', 'Split' with
> character sequences as disconnecting switches, etc...) and/or these
> functions are faster than those of the .NET Framework.
>
> | 5. VB allows implementation of interfaces with methods of different
> | names, making it confusing and difficult to find the implementation. C#
> | does not.
>
> Due to the explicit implementation syntax of VB.NET ('Implements') it is
> obvious which method of the class implements which interface method. In C
> # this is not obvious, since the definition (?) of a method does not say
> whether it was implemented as a method of an interface or established as
> new.
>
> | 6. VB supports background compilation. While this speeds the
> development
> | cycle for small projects, it slows down the IDE in large projects,
> contributing
> | at least in part to the culture tending to gravitate toward small
> projects.
>
> That applied unfortunately to VB.NET 2002, in version 2003 the situation
> was substantially corrected. In VB it will probably still give some
> improvements in regard to the speed of the background compiling to
> [VB.NET] 2005. If necessary, re-referencing projects (clean reference) can
> also give an improvement.
>
> | 7. C# namespaces are managed in way that makes programmers aware
> | of namespaces and their importance. VB namespaces are managed in a
> | way that hides them from the programmers by default. Careful attention
> | to namespace management is a fundamental tenet of strong application
> | design and its importance cannot be overestimated.
>
> Using namespaces in VB.NET exactly the same as in C# prevents absolutely
> nothing.
>
> An unprofessional (?) developer will write bad code in both C# and VB.NET,
> a good developer can write good code in in both programming languages.
> Optional operators of a programming language are an advantage if they
> support the professional user in his/her work. They are not bad, because
> a fool does not know to use them correctly.
>
> Translated from post by M S Herfried K. Wagner, M V P
>
> "Earl" <brikshoe@newsgroups.nospam> wrote in message
> news:%23ci9L$KYFHA.4000@TK2MSFTNGP10.phx.gbl...[color=green]
>> How about translating the entire post!?
>>
>> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
>> news:u2kAjJUXFHA.1240@TK2MSFTNGP14.phx.gbl...[color=darkred]
>>> Cor,
>>>
>>> "Cor Ligthert" <notmyfirstname@planet.nl> schrieb:
>>>>>> Der Artikel ist geprägt von m.E. unzutreffenden Vorurteilen und
>>>>>> darauf
>>>>>> basierenden, ebenso inrichtigen Implikationen.
>>>>
>>>> The article is lard by m.E. with not realistic bias and gives therefore
>>>> the same results.
>>>
>>> "m.E." = "IMO".
>>>
>>> ;-)
>>>
>>> --
>>> M S Herfried K. Wagner
>>> M V P <URL:http://dotnet.mvps.org/>
>>> V B <URL:http://classicvb.org/petition/>[/color]
>>
>>[/color]
>
>[/color]
