Re: globals?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Tom,

You belabor your points here, which points to some hostility towards VB.
You may not use VB.Net in the "old" VB ways, you may like the C-Like
languages. You do have to give it up to the VB folks though, there is more
code written there than....

VB allows folks to make poor decisions, turn off option explicit, make heavy
use of variants. VB affords both shortcuts and the long way to do things.
This doesn't make VB a bad language, this demonstrates lack of experience in
VB Developers. One of the purposes of these forums is to clarify how we
would do things when providing assistance and demonstrate "a better way".

Many of you out there, while providing sample or psuedo code, often do so in
the most hap-hazzard way. It's a wonder that we continually improve our
code at all. This is not simple a VB issue, this pertains to all languages.

As a developer, when you come across an "time sensative" project, you
assess, take stock, and otherwise form a opion of the state of the code and
what is left to be done. If there are things in there that are just bad,
you document them as issues/obstacles and move on. Either it is important
to your employer or it is not. You may not like it, but it is, as always,
what it is.

Isolating the VB Runtime Library because you don't like it is a perogative
and not the mindset of all other C-Like developers. There are benefits to
that library. As will all things, moderation and diligence are key. You
may not like the wonderful language of VB, many of us don't like the
confusing cryptic world of C. We either adapt or get lost in a bubble.

Compromise is what is required here. We each have differing terms,
keywords, syntax and philosophies. Neither purest group is going away, and
the homoginists have no choice. Modules work, static/shared works. No one
way is more right in general. In the workplace, a simple standards document
should resolve contention. In the worldplace, each should know of the
little nuances that cuase this thread to be so active and heated.


"Tom Leylan" <tleylan@xxxxxxxxxx> wrote in message
news:eEIQSIlQHHA.3444@xxxxxxxxxxxxxxxxxxxxxxx
"Herfried K. Wagner [MVP]" <hirf-spam-me-here@xxxxxx> wrote in message
news:uKSo6qjQHHA.1016@xxxxxxxxxxxxxxxxxxxxxxx

I don't think this is actually true. Many programming langauges
targetting .NET or providing access to the .NET Framework come with their
own libraries (Delphi.NET, J#, VB.NET, C++/CLI, ...) and/or contain
language-specific statements which are common to the langauge (VB.NET,
Eiffel.NET, ...).

While I used to know Delphi fairly well I know next to nothing about
Delphi.Net. A quick check confirms however that modifications were made
to the language (I notice that adjustments were made by SmallTalk to
accomodate their .Net implementation as well). I'll assume (without
actually searching) that Eiffel has done the same. The basic thread among
these changes is that modifications were made to conform to the DotNet
model and not to something called the C# model.

Clearly as in the case of VB there is a concern for all existing code.
Nobody is completely unaware of the need to migrate software and
developers. Do these developers all gather an say how dumb VB is because
it doesn't have a Foo() function? I hope not but it is of course
possible. If they did wouldn't you reply "but we can write such a
function if we need it"?

Striving to be different for no apparent benefit is the problem. Where
a funny hat if that is the VB-er's goal.

VB had its function library already when C# didn't exist at all, so this
point is not valid.

BASIC had functionality long before Visual Basic existed but we don't need
to retain "everything" when moving forward. Languages evolve... humans no
longer need a tail, it isn't "sad" that we no longer have one and it
wouldn't be "cool" if we did. We don't need a tail and VB doesn't need
UCase(). Visual FoxPro doesn't need four ways to comment code. All this
legacy stuff gets in the way.

Make it "maintaining differences for no apparent benefit" then. Again we
will not agree and you don't have to change your coding style for my
benefit.




.

Relevant Pages

  • Re: globals?
    ... which points to some hostility towards VB. ... You may not use VB.Net in the "old" VB ways, you may like the C-Like ... languages and mentioned specifically that case-sensitive languages can be ... and not the mindset of all other C-Like developers. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Win 7 virtual store question (with Access 2003)
    ... "development tools", now, rather than programming languages. ... they've done anything to make it more useable for the clients I still ... Microsoft Office Access MVP ... many Access developers have moved on to other specializations. ...
    (comp.databases.ms-access)
  • Re: What is wrong with Ada?
    ... The discipline that Ada requires is at odds with the ... I also think Adaists are an evolutionary step beyond those who program ... Immediate gratification developers have the potential to ... effects of dangerous languages and haphazard techniques. ...
    (comp.lang.ada)
  • Re: Toward a 21st century Forth
    ... Forth started out with the convenience of scripting languages. ... Forth also filled the niche of portable assembler. ... C has so many developers and so much money -- ...
    (comp.lang.forth)
  • Re: VB vs C# vs C++ vs J#
    ... finding answers to problems -or- learning how to do something. ... VB.NET - I suspect because VB.NET developers are typically not the types to ... go into deeper subject matter. ... It will make you a more valuable developer to be solid in both languages. ...
    (microsoft.public.dotnet.framework.aspnet)