globals?

[Tom Leylan]

Where a VisualBasic assembly method or constant has a Framework
equivalant, a Visual Basic programmer has a choice. Use the VisualBasic
assembly method or constant, or use a Framework equivalent .

Exactly. You've summarized it perfectly. It's a choice and I simply
suggest (as I have to developers using other languages) that developers
stick to a style. And choose that style based upon (among other things)
longevity. "It's easy" or "it's shorter" or "I like it" are reasons but not
particularly good reasons. Perhaps even good enough reasons if one writes
code for one's own use or for their friends but not good enough when one
produces software in a commercial environment with a group of other
developers (and lots of other developers over time) that involves (sometimes
"huge") amounts of money.

It isn't that UCase() costs money but rather than every "difference" is a
potential cost of time and money. If UCase() was used everywhere that's one
thing but if some are UCase() and some are .ToUpper() it's just a little
messier than it has to be and seriously it is no faster, easier to read or
less likely to fail. There is no upside to the variety.

Maybe this choice shouldn`t have been given from the start of VB.Net ,
if it was the idea that we should abbandon the VB specific methods in
favor of the framework , however they did so there must be something good
in the VB namespace ...........

I don't see how it could be avoided, it is a compatibility feature and they
are often added to facilitate the transition. They aren't recommended
styles (per se) but they help so everything doesn't break on day one.
Technically they aren't needed but emotionally and sociologically they are.

Take care,
Tom

 

[Branco Medeiros]

Tom Leylan wrote (inline):

I will suggest it is "easy" but I'm doubtful that it is the "standard" or
(if it is at this point) that it will remain so.

http://msdn2.microsoft.com/en-us/library/7825002w(VS.80).aspx

I don't see in the article linked above nothing that recomends not
using modules or suggests that modules will be removed from the
language, as your phrasing seems to imply...

I'd like to caution the OP against modules. As the number of public
functions increases you'll tend to want to organize them in some way,
classes do this for you in a natural way.

Well, while this is true (the complexity growth of a program to the
point the programmer wanting to reorganize it, specially in the
presence of public functions), it doesn't seem to be an impediment to
using modules, I guess.

Sometimes, as the code evolves, I see the need to reorganize entire
classes: break them up, remove functionality, encapsulate things more
tightly, change accessibility of things, you name it. Interestlingly,
this happens much less with modules, because -- and this is just my
personal experience, mind you -- whenever I create a global method in
a module, the scope of the method seemed global to me right from the
start, and this "notion" of globality hardly changes throughout the
development proccess.

Perhaps as an exercise you could list (here) the names of 3 or 4 functions
which you might consider putting into a module. What are their names and
(if isn't obvious) what do they do?

<snip>

One of the first things I do when creating a new application is to
create a Test module, with methods that I can call from the immediate
window. While I could easily declare an abstract class for this, say a
Public NotInheritable Class Test, filled with shared methods, I don't
see the need: I'd be just duplicating -- and complicating -- the
functionality that modules provide.

As for the names of methods, it really depends on the nature of the
module -- yes, you can have more than one, and yes, you can use their
names as a way of organizing things, I guess you already knew that,
but, since you don't use modules at all, I thought it was worth
remarking. As I was saying, it would really depends on the nature of
the module, what global encapsulation it was meant to achieve.

But then, again, it's just a language feature, use it if you want.
What I don't really agree is a recomendation against its use without
some serious evidence that the feature is bad practice/a detriment of
readability/alien to the language/source of bugs/whatever...

Your argument against modules, as far as I've seen, is "don't use
modules because":

a) other languages don't use them -- which is simply not true; some
languages do have something similar to modules, such as C# (static
classes), Delphi (elements declared in the public interface of units),
C++ (elements declared in the global namespace), Python (ditto), and
the list goes on;

b) they're a legacy from the past. Well, what isn't? This is an
evolution/rewriting/addaptation/whatever of a previously existing
language, a few things were lost in the process, others were added,
others remained for compatibility purposes, and others were kept I
guess because they were just part of the language's identity. Now, for
the things that were kept for compatibility sake, there's always a
warning in the documentation and a recomendation of the correct way of
doing it in new code -- I don't see so for modules (maybe this is a
hint that modules were not left in the language just because of
compatibility with previous code);

c) Non-Vb coders will find it hard to understand their implication...

Well, I'm not a Java programmer and had a hard time understanding
inner classes, or "public static final" elements (aka consts). Guess
the creators of the language didn't have your consulting when they
created such elements, huh?

I'm not a Lisp programmer either, and I find this talking about "car",
"cdr" and "lambda" a complete mistery -- why these folks couldn't use
more mundane terms I ask you.

I *am* a Delphi programmer (at least I used to be) and to this day I'm
baffled by the rules of block declaration and the -- unique! -- use of
the ";" separator in certain contexts -- switch blocks and If...
then ... else blocks, just to name some.

I *am* a PHP programmer (now and then, I must say) and when reading
someone else's code I wonder whether it's assuming "register_globals"
or "magic_quotes_gpc" on or off, because it isn't stated anywhere. How
evident would this be for a non-PHP programmer (considering the impact
such settings have in the resulting computation)?

And the list could go on.

Long remark short, the allegation that modules are not "recognizable"
by coders of other languages is, I'm sorry to say, almost laughable,
please, don't make that claim again in public places, its forced
reasoning doesn't fit in the quality of your other posts (which, for
the records, I personally really enjoy).

d) "I personally don't see their need" -- well, you're entitled not
to, but that doesn't really make it a compelling argument;

d) "I'll fire you if you use them" -- now, *THAT* would be a good
argument, but only if you were talking to one of your employees, which
is not the case of the OP, I guess, or the majority of the readers of
the list... =))

Regards,

Branco.

 

[Cor Ligthert [MVP]]

Tom,

I forgot to answer you about the contracts and things like that. Try to read
something about Deterding, one of the major founders of the Royal Dutch
Shell and contracts. (Royal Dutch Shell is a Dutch oil trading company).

Cor

 

[Cor Ligthert [MVP]]

Tom,

I thouht that there is not by any one here discussed here about using Shared
methods or with the name as it has even before the C derived langues time
"Modules". (Please keep in mind that this is a VB.Net newsgroup and don't
write all the time about static. The keyword static has another meaning,
therefore keep it with VB.Net keywords because of you wrote yourself about
the strict use of the language ).

We discuss here if the use of a module is not in any way worse than using a
shared class. (And in my idea even better, therefore I don't see were your
latest message is pointing to).

Cor

 

[Branco Medeiros]

Tom Leylan wrote (in response to a post from Cor Lightert):

A language isn't made up of the word "one". Take some time off from
studying copyright law and study human languages. <snip>

Whoa!

He can "confess" all he wants. Maybe you can admit you're demonstrating how
language can be misinterpreted (from thefreedictionary.com)

con·fess (kn-fs)
v. con·fessed, con·fess·ing, con·fess·es

<snip>

As much as I can agree that Cor's postings are sometimes more than
cryptic, and aknowledge that the language used by this forum is
English, this is completely uncalled for, and makes me wonder how
would you do in a forum where Deutch or German was used, even if it
was to affirm something flat-out wrong (such as your "don't use
modules" preach).

I sympathize with Cor here -- even though I sometimes disagree with
him -- because it's evident that English isn't his primary -- or even
secondary -- language and yet he can most of the times convey an
understandable message (even if you have to perform some twists while
interpreting his writings), that one time or another provided
appropriate/good/to-the-point advice to others, when yours where
nowhere to be found. Again, I wonder how you'd perform in a foreign
environment.

Regards,

Branco.

 

[Tom Leylan]

Tom Leylan wrote (inline):

I don't see in the article linked above nothing that recomends not
using modules or suggests that modules will be removed from the
language, as your phrasing seems to imply...

Sorry about that I didn't intend to imply that they were going away. I'm
quite certain they aren't. I was challenging the term "standard". The
article does not mention modules being a standard it simply points out the
differences.

Sometimes, as the code evolves, I see the need to reorganize entire
classes: break them up, remove functionality, encapsulate things more
tightly, change accessibility of things, you name it. Interestlingly,
this happens much less with modules, because -- and this is just my
personal experience, mind you -- whenever I create a global method in
a module, the scope of the method seemed global to me right from the
start, and this "notion" of globality hardly changes throughout the
development proccess.

I don't doubt for a minute that everybody's methodology works. That's among
the main reasons why it is difficult to have discussions about best
practices. Each of us has settled in our current strategy based upon
problems they have encountered. Their solution worked and they tend to like
it.

One of the first things I do when creating a new application is to
create a Test module, with methods that I can call from the immediate
window. While I could easily declare an abstract class for this, say a
Public NotInheritable Class Test, filled with shared methods, I don't
see the need: I'd be just duplicating -- and complicating -- the
functionality that modules provide.

That works. I don't find it hard to create a test class (or multiple test
classes) so I don't create a Test module.

Well, I'm not a Java programmer and had a hard time understanding
inner classes, or "public static final" elements (aka consts). Guess
the creators of the language didn't have your consulting when they
created such elements, huh?

I don't recommend them because (more or less as you said) they are atypical.
If another language has a similar construct while maintaining a duplicate
language-neutral version of the exact same thing then I would recommend
against their use also. Importantly this has nothing to do with inner
classes. They were added because they are a good idea. If simultaneously
there was an inner module added in order to duplicate this functionality I
would have questioned the need for yet one more duplication.

The addition of partial classes is a good thing, the invention of partial
modules would sound (to me) like an attempt to fit language-neutral concepts
into a VB framework. It isn't that I don't think it is clever, it is only
that I don't see the point.

I'm not a Lisp programmer either, and I find this talking about "car",
"cdr" and "lambda" a complete mistery -- why these folks couldn't use
more mundane terms I ask you.

I would agree that car and cdr were poor choices. While I'm not happy
saying lambda too often the term existed within mathematics since the
1930's. I don't think it would unfair to conclude that the mystery of the
language has resulted in fewer people using the language. Had they known
people would be thrown off by the keywords perhaps they would have rethunk
it.

And the list could go on.

Long remark short, the allegation that modules are not "recognizable"
by coders of other languages is, I'm sorry to say, almost laughable,
please, don't make that claim again in public places, its forced
reasoning doesn't fit in the quality of your other posts (which, for
the records, I personally really enjoy).

Appreciate the compliment in there Seriously though it isn't because
cdr and car are odd words or Delphi has an inconsistency in the block
declaration. If they had "other more standard ways" of accomplishing such
things they yes I would say the use of cdr and car should be avoided. You
are pointing out language implementations for which there is no alternative.
I on the other hand am suggesting that stringvar.toupper() will be
recognized by any DotNet developer. At no point did I suggest that poorly
written PHP code should be understood by talented PHP developers and in my
opinion globally controlled environmental settings are (generally speaking)
a curse rather than an aid.

Try to think of it in these terms. If VB Version 1.0 had some function
named AllCaps() that was changed to UCase() in VB 3.0 would you suggest
keeping AllCaps() in the language? Would you say to developers who submit
code such as IF AllCaps( "mystring" ) = UCase( var ) that they are very good
or would you suggest they're needlessly complicating things? Might they
answer, if you don't know they are equivalent that is laughable? The point
is you know they are equivalent, you know the code will probably work but
there is in fact no "upside" to mixing the syntax. It may not add confusion
but it never adds clarity. I suggest that is does confuse some if for no
other reason than they spend a few minutes wondering if they are in fact
equal. To recap, if the framework supplies ToUpper() then UCase() isn't
such a great idea.

When LOCAL and STATIC variable scoping was introduced in Clipper 5.0 I
promptly removed every PUBLIC and PRIVATE declaration. Not a one remained
because the old scoping rules (while still operational) were inferior to the
new ones. The code became more stable and as a side benefit ran slightly
faster. Few dBASE programmers agreed pointing out that all their code used
PUBLIC and PRIVATE vars. They usually failed to mention how they catch the
majority of the errors at runtime (well after the software was released)
however.

I'm quite certain we won't agree but I'm not trying to persuade the firmly
entrenched, I am trying to dissuade those on the fence and those who have
not commited to a style as of yet. Perhaps they could be less of a "vb
programmer" and more of a "programmer who uses VB". I'm simply offering an
alternative "non-VBer" approach to software development. It will always
grate on the VB-ers a bit.

Tom

 

[Tom Leylan]

Tom,

I forgot to answer you about the contracts and things like that. Try to
read something about Deterding, one of the major founders of the Royal
Dutch Shell and contracts. (Royal Dutch Shell is a Dutch oil trading
company).

Why? What do you hope I might stumble upon?

Apparently he was forced out because he gave oil credit to the Nazis.
http://en.wikipedia.org/wiki/Henri_Deterding

Let me go buy a book, read it and get back to you on "Deterding and
contracts".

Oh I forgot, try to read something about Hans Reichenbach.

 

[Tom Leylan]

We discuss here if the use of a module is not in any way worse than using
a shared class. (And in my idea even better, therefore I don't see were
your latest message is pointing to).

It's pointing to your expressions that people here don't know where OOP came
from or what does or doesn't constitute an OOP construct. Am I the one
mentioning Deterding and giving an example of the number one in 4 or 5
languages?

If I use the word "static" rather than "shared" you're on me in a minute...
what would you have replied if I suggested (like you did) that you read a
book on Henri Deterding? I can't imagine but I know it wouldn't be "good
idea Tom".

Just use modules, continue to recommend to others that they use modules and
let me suggest to those same people that they don't use modules. What could
be wrong with a simple disagreement? Why is a module such a big deal to
you?

 

[Herfried K. Wagner [MVP]]

Cor: If you have a minute look up SmallTalk (if you don't think it is an
OO language then I don't know what to say) and you will see that it has
Class Methods aka "static methods". As does Ruby, as does Python as does
Java. I could check Simula too if you need it but is the developer of
SmallTalk wrong?

Nobody doubts that other programming langauges supporting OO contain static
methods. However, with static methods being not virtual in .NET, they
simply resemble modules. Would you consider a module as being present as an
OO construct?

 

[Branco Medeiros]

Tom Leylan wrote:

Try to think of it in these terms. If VB Version 1.0 had some function
named AllCaps() that was changed to UCase() in VB 3.0 would you suggest
keeping AllCaps() in the language? Would you say to developers who submit
code such as IF AllCaps( "mystring" ) = UCase( var ) that they are very good
or would you suggest they're needlessly complicating things?

Uh, nedlessly complicating things, I guess, because of the lack of
"symmetry", or consistency. If both methods were really simillar I'd
suggest the programmer sticked to one or the other, but not both.

But to me this isn't an accurate example. A more appropriate one would
be: if the language had an "AllCaps" method and in the next version a
String.GetValue.ToUpper() method became suddenly allowed because both
classes and class-methods were introduced in the language, and someone
came saying "don't use AllCaps because it has the same usage of
String.GetValue.ToUpper() and the latter is the preffered approach",
then I'd say "whoa, mister!, that's quite not true"... And when
someone asked me how to convert a string to upper case, I certainly
would suggest "AllCaps" as an easy, less verbose alternative.

See, I'm not saying "don't use Public NotInheritable classes with
shared methods". I'm saying "if you need public methods, a module is a
perfectly good place to put them, and it's a very regular idiom".

I dare to compare your point of view with mine, when I started coding
in C++ (but having a VB/Pascal/Delphi background). My first reaction
to the language was *what!? no properties?? how can one live without
them?". And sure, I managed to develop a property-like syntax for my C+
+ classes using templates, many years before MS or Borland added them.
=))

My brother -- a very seasoned C++ programmer without my VB/Delphi
background -- said "cool", but *never*, *ever* used the property
framework I so cleverly -- or so I thought -- designed. Guess what?
Neither did I. As I became more profficient with the language and its
quircks, er... features, the naivity of fighting the language's own
expression power and bringing alien structs to it just because they
fit so nice in other environments became evident.

So, to the relutant in accepting modules as valid constructs I'd say
"think of then as Public NotInheritable classes with shared methods,
with the mixed advantage that the elements of this 'class' are
publicly accessible without qualification, and with the definitive
advantage that it's easier to spot a module's purpose (a module has a
very definite purpose, while a Public NotInherited class can have
many, unless I follow its code and notice that all methods are shared,
and even then I may suspect that I'm missing something)". Uf. That's
what I'd say.

I'd like to add that I don't think that the existence of a ToUpper()
method in the String data type voids the use of UCase. As already
stated elsewhere, the ToUpper method will raise an exception if used
in an non-initialized string, while the UCase method will allways
succeed.

Therefore, instead of questioning the existence of UCase when the
framework give us Provasic er, ToUpper, I guess your questioning
should be "why use 'X = UCase(SomeString)' if you can use 'If
SomeString IsNot Nothing Then X = SomeString.ToUpper Else X =
String.Empty'?", and let the coder decide which one he/she preffered.

In other words, my opinion is that the existence of UCase is perfectly
valid and the coders I eventually coach or supervise may use it
without me raising but an eyebrow (that's not to say you'll find a
single occurrence of UCase in my code).

I'm quite certain we won't agree but I'm not trying to persuade the firmly
entrenched, I am trying to dissuade those on the fence and those who have
not commited to a style as of yet.

The same as me, pal, the same as me. ;-)

Regards,

Branco.

 

[Michel Posseth [MCP]]

Tom ,

If a programming team is made up of Visual Basic programmers and other .Net
language programmers it will generally be better for all programmers to use
Framework constants, rather than language specific constants, to make code
easier to read and maintain.

I fully concur with that....

but not good enough when one produces software in a commercial environment
with a group of other developers (and lots of other developers over time)
that involves (sometimes "huge") amounts of money.

Well i have worked and work currently for world market leaders in there kind
and believe me it is happening in your worst case scenario in practice
in these 2 company`s i dare to say that i am the most framework strict
programmer ( by the way i do use FCL code in my daily work , but this is
more a coincidence as i also code in C# and then it gets a habbit to try to
keep everything in the same style ) in my company .

And yes i work currently on a millions dollars project

maybe i am just to flexible to believe both are good :-| practice

regards

Michel

 

[Cor Ligthert [MVP]]

Tom,

Just use modules, continue to recommend to others that they use modules
and let me suggest to those same people that they don't use modules. What
could be wrong with a simple disagreement? Why is a module such a big
deal to you?

There is only one real Dutch word used in real all languages of the world.

Some people have believed that the philosophies in that word was true.

That word is "Apartheid". I think there is not one Dutchman/woman proud on
that.

However it seems for me as the "Module" is handled like "non white" in the
program languages.

I seldom see another reason than that I have seen in this thread against it.
It is in my idea only based on prejudice and parroting.

For me the only sit in the bus for the "module" is not in the back.

Cor

 

[RobinS]

Tom,

There is only one real Dutch word used in real all languages of the
world.

Some people have believed that the philosophies in that word was true.

That word is "Apartheid". I think there is not one Dutchman/woman proud
on that.

However it seems for me as the "Module" is handled like "non white" in
the program languages.

I seldom see another reason than that I have seen in this thread against
it.
It is in my idea only based on prejudice and parroting.

For me the only sit in the bus for the "module" is not in the back.

Cor

I have to say, it's fairly entertaining how you guys could argue about
whether we should use Modules or Shared Classes, and end up comparing the
issue to one of the defining moments of the Civil Rights era in the United
States.

And if it makes you feel any better, Cor, most people think of South Africa
when they think of apartheid, rather than Holland, despite the origin.

When I think of Holland, I think of canals, windmills, tulips, beautiful
countryside, and those horribly uncomfortable-looking (but attractive)
wooden clogs. Although I've never had the pleasure of a visit, one of my
best friends' family is from Holland, and I have the souvenirs to prove it.
;-)

Robin S.

 

[AMDRIT]

Cor,

It seems to me that I said the preferred way to do this was to use a class
and not modules and not that this way was better. Singleton must be a word
used in VB, since I learned that word from MS while discovering the new
changes in VS 2002. According to wikipedia, my complicated example is a
singleton http://en.wikipedia.org/wiki/Singleton_pattern.

Cobal programmers questioned how classes where better than procedural
programming too. "Better" is a relative term, and you should be cautious
when throwing that out there. Better, in my view, is how it relates to the
user base. Better, in my view, is how free of bugs my solutions are.

I tell you, I miss VB 5/6 and still toy with it on little things. The
poster asked for the easiest way to do something he has always done, which
is still to use a module. The reason I replied was to share what I thought
everyone else was doing. Apparently, I was wrong. Either way, there is a
group of thought that suggests we not use modules as freely as before, and
to wrap functionality up in classes. My.Settings in the VB world is a prime
example of this statement.

 

[AMDRIT]

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]

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....

You should (I believe) be very cautious when attempting psychoanalysis on
people on newsgroups. I have no "hostility" towards VB it is a
dispassionate scientific view of the situation. I should be able to not
believe in Bigfoot without that being labeled as hostile to ape-like
creatures. I don't recall posting anything about a preference to "C-like"
languages and mentioned specifically that case-sensitive languages can be
problematic (from a productivity standpoint.) That said there is nothing
"C-like" about using object.method() syntax as we use it in VB.Net all the
time.

I know little about the Sather language but look what I find in a Sather
tutorial:

"Early versions of Sather used a conventional 'until...loop...end' statement
much like other languages. This made Sather susceptible to bugs that afflict
looping constructs. Code which controls loop iteration is known for tricky
"fencepost errors" (incorrect initialization or termination). Traditional
iteration constructs also require the internal implementation details of
data structures to be exposed when iterating over their elements."

They recognized from a scientific view (no hostility it is their language of
choice after all) that there was "design flaw".

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".

I appreciate your reasoned comments but surely one of the measures of
languages (and things in general) is the ability to make (and detect)
mistakes. Language constructs

From Wikipedia: "Weak typing allows a value of one type to be treated as
another, for example treating a string as a number.[11] This can
occasionally be useful, but it can also cause bugs; such languages are often
termed unsafe. C, C++, and most assembly languages are often described as
weakly typed."

Here is something you may wish to read on Empirical Studies of Programmers:
http://books.google.com/books?id=ss...sig=wdxumjsQ7vkjfc88VqwqSqNVzTs#PRA1-PA138,M1

And here is a note about "Design by Contract":
http://archive.eiffel.com/doc/manuals/technology/contract/

If an automobile manufacturer made a car where the wheels fell off but
suggested that the driver should "be careful so this doesn't happen" we
would all (I have to believe) laugh.

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.

Quoted from the eiffel document above:

"When quality is pursued, productivity follows"
(Quoted in Carlo Ghezzi, Dino Mandrioli and Mehdi Jazayeri,
SoftwareEngineering, Prentice Hall 1991.)

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.

I have no idea why you categorize me as a "C-like" developer who may not
like the wonderful language of VB but loves the cryptic world of C. Perhaps
you had something to write and you need somebody to use as an excuse?

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.

I'm not completely unaware of tradeoffs but while "one way" may be no more
right you must admit that a number of ways are better than a number of
alternatives. If that were not the case why would anybody post "how about
this way" when replying to people's coding questions here? Aren't they
suggesting a better alternative?

Seriously if you get the chance read the documents concerning the "causes"
of errors and recognize that I'm not anti-VB I am anti-bugs that cause
systems to fail, money to be lost and in the worst case, people to die.

I think newsgroups (even the technical ones) are better suited
(unfortunately) to postings of "we're #1" and "those C-types are dopes" but
I have always held out hope that professionals might gather and discuss
(without bias) some of the subtler points of application development. It's
tough but it isn't impossible.

I also think this thread has about expired... it will be back again in time
as it is one of those subjects that recurs periodically. The newsgroup
archives are filled with messages conveying the gist of both your posting
and my reply.

Take care.

 

[Michel Posseth [MCP]]

Tom,

As i said before i really enjoyed reading your postings regarding this
subject

and this was good for a big laugh ( i guess my neighbours heard that one )

I should be able to not believe in Bigfoot without that being labeled as
hostile to ape-like creatures.

But indeed , it is just an opinion and with VB we have a choice so you can
choose to code strict by certain rules to OOP or not to OOP to code by FCL
or by language keywords or even mix them up , and we may all have a
different opinion about it .

Wich one is the right one ?? i don`t really know as it is something of
personal preferences i guess what is good in your situation might be bad for
someone elses

Just my thoughts .....

regards

Michel

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....

You should (I believe) be very cautious when attempting psychoanalysis on
people on newsgroups. I have no "hostility" towards VB it is a
dispassionate scientific view of the situation. I should be able to not
believe in Bigfoot without that being labeled as hostile to ape-like
creatures. I don't recall posting anything about a preference to "C-like"
languages and mentioned specifically that case-sensitive languages can be
problematic (from a productivity standpoint.) That said there is nothing
"C-like" about using object.method() syntax as we use it in VB.Net all the
time.

I know little about the Sather language but look what I find in a Sather
tutorial:

"Early versions of Sather used a conventional 'until...loop...end'
statement much like other languages. This made Sather susceptible to bugs
that afflict looping constructs. Code which controls loop iteration is
known for tricky "fencepost errors" (incorrect initialization or
termination). Traditional iteration constructs also require the internal
implementation details of data structures to be exposed when iterating
over their elements."

They recognized from a scientific view (no hostility it is their language
of choice after all) that there was "design flaw".

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".

I appreciate your reasoned comments but surely one of the measures of
languages (and things in general) is the ability to make (and detect)
mistakes. Language constructs

From Wikipedia: "Weak typing allows a value of one type to be treated as
another, for example treating a string as a number.[11] This can
occasionally be useful, but it can also cause bugs; such languages are
often termed unsafe. C, C++, and most assembly languages are often
described as weakly typed."

Here is something you may wish to read on Empirical Studies of
Programmers:
http://books.google.com/books?id=ss...sig=wdxumjsQ7vkjfc88VqwqSqNVzTs#PRA1-PA138,M1

And here is a note about "Design by Contract":
http://archive.eiffel.com/doc/manuals/technology/contract/

If an automobile manufacturer made a car where the wheels fell off but
suggested that the driver should "be careful so this doesn't happen" we
would all (I have to believe) laugh.

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.

Quoted from the eiffel document above:

"When quality is pursued, productivity follows"
(Quoted in Carlo Ghezzi, Dino Mandrioli and Mehdi Jazayeri,
SoftwareEngineering, Prentice Hall 1991.)

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.

I have no idea why you categorize me as a "C-like" developer who may not
like the wonderful language of VB but loves the cryptic world of C.
Perhaps you had something to write and you need somebody to use as an
excuse?

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.

I'm not completely unaware of tradeoffs but while "one way" may be no more
right you must admit that a number of ways are better than a number of
alternatives. If that were not the case why would anybody post "how about
this way" when replying to people's coding questions here? Aren't they
suggesting a better alternative?

Seriously if you get the chance read the documents concerning the "causes"
of errors and recognize that I'm not anti-VB I am anti-bugs that cause
systems to fail, money to be lost and in the worst case, people to die.

I think newsgroups (even the technical ones) are better suited
(unfortunately) to postings of "we're #1" and "those C-types are dopes"
but I have always held out hope that professionals might gather and
discuss (without bias) some of the subtler points of application
development. It's tough but it isn't impossible.

I also think this thread has about expired... it will be back again in
time as it is one of those subjects that recurs periodically. The
newsgroup archives are filled with messages conveying the gist of both
your posting and my reply.

Take care.