Re: Writer's Uninformed Statements

[Rich]

John,

The author makes some uninformed statements:

"Procedural languages such as COBOL and VB are being rewritten for .NET to
be object-oriented. Teaching developers object-oriented programming is much
more of a stepping stone than understanding syntactical rules.

Languages such as COBOL or VB were never intended to be object-oriented."

Calling VB procedural is totally idiotic. VB was not "intended to be object-oriented?"
I guess he FORGOT VB is object based. To gain some credibility, he could
have pointed this out. This is yet another uniformed individual. I hope they
did not pay much for his "professional" opinion. :-)

Rich

--------------------------------------------------------------------------


"John Butler" <jrbutler@nospambtclick.com> wrote:
>Hi
>
>Came across this article today:
>http://www.theserverside.com/resourc...T/article.html
>
>It's written by a company, FOR Sun , but is fairly neutral (I thought),
>although I don't think the authors live up to the promises they make at
the
>beginning...
>
>If you're looking for a comparison, listing of pro's and con's etc between
>the J2EE platform and DotNet, then it is certainly worth a read.
>
>I'd be interested to hear what the various luminaries that hang out here
>think of it....
>
>Rgds
>John Butler
>
>
>

[Ted]

Forgive my VB ignorance once again, but how is VB object based? I would think
that component based and event driven would more sum up VB. Is that wrong?

"Rich" <nospam@nospamy.com> wrote:
>
>John,
>
>The author makes some uninformed statements:
>
>"Procedural languages such as COBOL and VB are being rewritten for .NET
to
>be object-oriented. Teaching developers object-oriented programming is much
>more of a stepping stone than understanding syntactical rules.
>
>Languages such as COBOL or VB were never intended to be object-oriented."
>
>Calling VB procedural is totally idiotic. VB was not "intended to be object-oriented?"
>I guess he FORGOT VB is object based. To gain some credibility, he could
>have pointed this out. This is yet another uniformed individual. I hope
they
>did not pay much for his "professional" opinion. :-)
>
>Rich
>
>--------------------------------------------------------------------------
>
>
>"John Butler" <jrbutler@nospambtclick.com> wrote:
>>Hi
>>
>>Came across this article today:
>>http://www.theserverside.com/resourc...T/article.html
>>
>>It's written by a company, FOR Sun , but is fairly neutral (I thought),
>>although I don't think the authors live up to the promises they make at
>the
>>beginning...
>>
>>If you're looking for a comparison, listing of pro's and con's etc between
>>the J2EE platform and DotNet, then it is certainly worth a read.
>>
>>I'd be interested to hear what the various luminaries that hang out here
>>think of it....
>>
>>Rgds
>>John Butler
>>
>>
>>
>

[Rich]

Ted,

I think you are getting some semantics confused. By stating a development
tool is object oriented or object based, I’m stating the features the tool’s
language provides.

The issue of a tool being component based is really a general term originally
used to describe the "ancient" VB development. It is probably still used
by some who have not kept up with VB's metamorphosis over the last seven
years.

In the old days, VB applications were hacked together with controls (VB intrinsic
and third party) and "glued" together with VB code to get it to "work." These
were generally small or medium one tier or two tiered applications. Much
of the code was thrown into the events on the form. Needless to say, this
design was flawed for many reasons.

Unfortunately, many people are still either unaware or ignore the fact VB
has developed into a very strong development tool for business applications.
It has been, for the last three versions, object based. There are actually
some companies out there successfully building solid object based applications.


By stating VB is object based, I am stating that VB language supports most
of the requirements to be object oriented. The classes (class modules) created
within VB meet all of the "traditional" criteria except for implementation
inheritance. Hence, it is called object based instead of object oriented.

Now, utilizing components is something different. This is done in Visual
C++, Delphi, Java, Visual Basic and many other tools. Very generally speaking,
they can be in the form of a DLL, ActiveX control, static library, VCL or
JavaBean. It is simply a way to utilize third party code or reuse internally
developed code. This has nothing to do with the development tool's language
features or capabilities.

Rich


-----------------------------------------------------------------------

"Ted" <TTarney@hotmail.com> wrote:
>
>Forgive my VB ignorance once again, but how is VB object based? I would
think
>that component based and event driven would more sum up VB. Is that wrong?

[Mike Mitchell]

On 1 Sep 2001 09:47:28 -0700, "Rich" <nomail@nomail.com> wrote:

>In the old days, VB applications were hacked together with controls (VB intrinsic
>and third party) and "glued" together with VB code to get it to "work." These
>were generally small or medium one tier or two tiered applications. Much
>of the code was thrown into the events on the form. Needless to say, this
>design was flawed for many reasons.

"Flawed"? I think you need to explain your complaints about it before
we start discussing "flaws", ecxept maybe the ones in your argument.

First, what does "in the old days" mean? Like, yesterday was "the old
days"? Because I was using classic VB yesterday, and I'll probably use
it today as well. Hardly "the old days" when over three million
developers are using it, and many of them right this minute. This
situation will continue (shock, horror!) for years, as most classic VB
developers will not find even a minute of fun in the new VB.NET.

Second, "hacked together" implies you don't like the concept of RAD.
What is the key concept to take home from RAD? That's right, it's "R",
isn't it? Rapid. Productive. Fast. Profits! Pretty obvious to most
people - see "Rapid Transportation Systems", for example, or "Rapid
Response Teams". You wouldn't want to pay taxes for a "Lethargic
Response Team", would you? Classic VB is one of the few truly RAD
environments available. There is, I would argue, nothing quicker than
firing up VB1,2,3,4,5 or 6, selecting a control from the toolbox,
placing it on the form, and adding some event handling code. (Well, I
suppose shooting oneself in the foot is pretty quick, too.)

Now, I agree with your choice of words in "glue", although I suspect
you are using it in a pejorative sense, as you more obviously are when
we come to the part where we "get it to 'work'". You're obviously
assuming that it's happenstance that such an abortion as "old days" VB
could ever work, so the devs are continually trying their damndest to
make this happy event, er, happen.

"Much of the code was thrown into the events", you say, but what else
would the events have thrown at them? Apples? Dead rabbits? I would
rather you wrote that code was written in the event handlers, and
leave the throwing to the next ball game, where it makes more sense.

Finally, let me remind you, lest you forget the importance of VB's
role in bringing computing to the masses, that classic Visual Basic is
the lingua franca of modern computing. With VB, VBA, and VBScript it
is ubiquitous, powerful, accessible, and simple to understand and use
by vast millions of workers as they pursue their RAD dreams and
actually produce apps that work and do it very successfully without
OOP, UML, XML, and all the other bloated ballyhoo buzz words that are
sadly rife in computing nowadays.

Strange, isn't it, as you reflect upon the huge level of support there
is from developers and corporates for such a "flawed" design as
classic Visual Basic?

MM

[Gregor R. Peisker]

Hi Mike,

> Well, I suppose shooting oneself in the foot is pretty quick, too.

Exactly.

Regards,
Gregor

[Ted]

Mike,

I thought you might enjoy this article:
http://www.computerworld.com/cwi/sto...O63340,00.html

I would care to guess that your title is "NOT" Software Engineer? I would
also guess that due to your use of the "bloated ballyhoo buzz words" like
OOP and UML( and possibly patterns, but since you don't do OO and you write
VB you probably don't know about patterns ) that in your opinion, these "essential"
tools of a true SE are not needed? Hmmm. Well I guess RAD can take care
of all of that? I mean "R" is rapid. So that time honored tradition of
software engineering can go by the wayside. 3 months in a VB continuing
education class at some community college can make you a software engineer
these days anyway.

Well as you have said, VB did bring computing to the masses, and fortunately
for an SE like myself, a good majority of those in the masses( including
you ) will continue to be code monkeys and keep my salary continually rising.

Oh and by the way, do you really think that 3 million number is all "workers"?

>Finally, let me remind you, lest you forget the importance of VB's
>role in bringing computing to the masses, that classic Visual Basic is
>the lingua franca of modern computing. With VB, VBA, and VBScript it
>is ubiquitous, powerful, accessible, and simple to understand and use
>by vast millions of workers as they pursue their RAD dreams and
>actually produce apps that work and do it very successfully without
>OOP, UML, XML, and all the other bloated ballyhoo buzz words that are
>sadly rife in computing nowadays.
>
>Strange, isn't it, as you reflect upon the huge level of support there
>is from developers and corporates for such a "flawed" design as
>classic Visual Basic?

[Rich]

Mike,

Your rant was totally off. My statement was simply this. Once upon a time
VB (1-3) was NOT object based. Many people hacked together monolithic applications
with much of the code in events. These applications were not easily extended
or maintained. Anyone, including Rocky Lhotka, Deborah Kurata or myself who
has paid attention will admit object based application development is far
superior to the "throw the code in events" garbage. Please, point out the
flaw.

I suppose you thought I was ripping on VB 6. Again, you were WRONG. I was
pointing out how some "programmers" hacked things together in the past. I'm
assuming all professional programmers now know and use the object based features
of VB6. :-)

I think you missed the boat on RAD. Maybe, for your small applications, hacking
is the way. That is your choice. For me, I write medium to large applications,
which contain code, which is scalable, maintainable and reusable. Not one
offs.

As for code in events, that is a hack. Tons of code in the events. This is
the way I would expect a neophyte to write applications. There is no design.
Just hack it together. You know what I meant. There should be minimal code
in the events calling objects properties or methods.

As for VB's role, I have been using VB for over eight years each and every
day for eight hours a day or more. The "Ruby VB" was an excellent start.
It was never intended to last as long as it did. It had a great run. Now,
it is off to VB.NET. This is the future. You can like it or not.

Rich

---------------------------------------------------------------------------

kylix_is@hotmail.com (Mike Mitchell) wrote:
>On 1 Sep 2001 09:47:28 -0700, "Rich" <nomail@nomail.com> wrote:
>
>>In the old days, VB applications were hacked together with controls (VB
intrinsic
>>and third party) and "glued" together with VB code to get it to "work."
These
>>were generally small or medium one tier or two tiered applications. Much
>>of the code was thrown into the events on the form. Needless to say, this
>>design was flawed for many reasons.
>
>"Flawed"? I think you need to explain your complaints about it before
>we start discussing "flaws", ecxept maybe the ones in your argument.
>
>First, what does "in the old days" mean? Like, yesterday was "the old
>days"? Because I was using classic VB yesterday, and I'll probably use
>it today as well. Hardly "the old days" when over three million
>developers are using it, and many of them right this minute. This
>situation will continue (shock, horror!) for years, as most classic VB
>developers will not find even a minute of fun in the new VB.NET.
>
>Second, "hacked together" implies you don't like the concept of RAD.
>What is the key concept to take home from RAD? That's right, it's "R",
>isn't it? Rapid. Productive. Fast. Profits! Pretty obvious to most
>people - see "Rapid Transportation Systems", for example, or "Rapid
>Response Teams". You wouldn't want to pay taxes for a "Lethargic
>Response Team", would you? Classic VB is one of the few truly RAD
>environments available. There is, I would argue, nothing quicker than
>firing up VB1,2,3,4,5 or 6, selecting a control from the toolbox,
>placing it on the form, and adding some event handling code. (Well, I
>suppose shooting oneself in the foot is pretty quick, too.)
>
>Now, I agree with your choice of words in "glue", although I suspect
>you are using it in a pejorative sense, as you more obviously are when
>we come to the part where we "get it to 'work'". You're obviously
>assuming that it's happenstance that such an abortion as "old days" VB
>could ever work, so the devs are continually trying their damndest to
>make this happy event, er, happen.
>
>"Much of the code was thrown into the events", you say, but what else
>would the events have thrown at them? Apples? Dead rabbits? I would
>rather you wrote that code was written in the event handlers, and
>leave the throwing to the next ball game, where it makes more sense.
>
>Finally, let me remind you, lest you forget the importance of VB's
>role in bringing computing to the masses, that classic Visual Basic is
>the lingua franca of modern computing. With VB, VBA, and VBScript it
>is ubiquitous, powerful, accessible, and simple to understand and use
>by vast millions of workers as they pursue their RAD dreams and
>actually produce apps that work and do it very successfully without
>OOP, UML, XML, and all the other bloated ballyhoo buzz words that are
>sadly rife in computing nowadays.
>
>Strange, isn't it, as you reflect upon the huge level of support there
>is from developers and corporates for such a "flawed" design as
>classic Visual Basic?
>
>MM
>

[Larry Linson]

"Rich" <nomail@nomail.com> wrote:

> Your rant was totally off. My statement was simply this.
> Once upon a time VB (1-3) was NOT object based. Many
> people hacked together monolithic applications with
> much of the code in events. These applications were not
> easily extended or maintained.

From version 1, VB has been "object based". For example, controls were objects
with properties, and controls and forms had events (of course, maybe in your
definition, events aren't associated with objects, but they seemed to be
in the eyes of the developers of all versions of VB). The versions you described
simply did not support the developer creating his/her own class modules.


> Anyone, including Rocky
> Lhotka, Deborah Kurata or myself who has paid attention
> will admit object based application development is far
> superior to the "throw the code in events" garbage.

Deborah Kurata has, as long as I have known of her, been an _advocate_, in
fact, a strong advocate, of using Objects. Yet, you say "admit", as though
that admission had been wrung out of her _grudgingly_. Rocky and you, I don't
know about, but if you say you have "paid attention", I suppose you must
have, though you don't make it clear to _what_ you paid attention.

On the other hand, there are a good many who have, in fact, "paid attention"
but who aren't convinced that creating applications which aren't necessarily
based on putting just about everything in developer-created class modules
is bad practice and amounts to "throw code in events garbage". There have
always been standard modules available (from VB1 on) into which more widely-used,
even globally-used, procedures and variables can be placed. And, in general,
even in RAD applications, I've seen those used appropriately.

It is the events that fire in response to actions of various kinds and where
some code, perhaps little, perhaps more, must be put in classic VB, even...
I stress _even_... in applications making extensive use of class modules,
if the application is to respond to those actions.

> Please, point out the flaw.

In only the parts which I have quoted here, there are several. First flaw:
stating that VB 1-3 were not "object-based". Second flaw: trying to give
the impression that DK had to be "convinced" that object is better and implying
that she "admitted" that was the case rather than the actual case which is
that she has long "advocated" object-orientation. Third flaw: trying to give
the impression that anyone who has "paid attention" will "admit" that object-oriented
is always better. Fourth flaw: denigrating the utility of events and implying
that "throwing code into events" is "garbage".

It has, of course, been possible to create applications that were "garbage"
with every version of VB (and assembler, and Fortran, and C of all flavors,
and Pascal, and ...); whether or not you're a bettin' man, you can safely
wager your future salary that it will be possible to do so in future versions,
as well.

[Rich]

Larry,

>First flaw: stating that VB 1-3 were not "object-based".

You are confusing objects and components(VBXs and ActiveX controls). Components
are not the same as VB class modules. VB being object based is a semantic
used to describe the VB language class module capabilities. The VB language
is not a 100% pure object oriented language. As I said before, it is missing
implementation inheritance. Hence, the object-oriented purists would not
consider it object oriented. Many would say it is object based. Since this
was added in VB 4, one could not say VB 1-3 is object based. "Flaw" refuted.


>Second flaw: trying to give the impression that DK had to be "convinced"
that object is better and implying >that she "admitted" that was the case
rather than the actual case which is>that she has long "advocated" object-orientation.


I guess you missed my point. I was attempting to be diplomatic. I did not
want to say, "Here is what the experts say, if you do not believe them your
are an idiot." "Flaw" refuted.

Third flaw: trying to give >the impression that anyone who has "paid attention"
will "admit" that object-oriented
>is always better.

When I said, "paid attention" I meant anyone who has kept up with the object-based
capabilities added in VB. It was hard to miss. :-)

For an application of any size, it is almost always better. In a rare occasion
one may want to functionally decompose to increase performance. Sometimes
this works, sometimes it does not increase performance. Whether or not the
performance is increased, maintainability is decreased. "Flaw" refuted.


>Fourth flaw: denigrating the utility of events and implying
>that "throwing code into events" is "garbage".

Again, using solid OOD always leads to maintainable, reusable and extensible
applications. Believe it or not. Enough said. "Flaw" refuted.



Rich
---------------------------------------------------------------------------

"Larry Linson" <larry.linson@ntpcug.org> wrote:
>
>"Rich" <nomail@nomail.com> wrote:
>
> > Your rant was totally off. My statement was simply this.
> > Once upon a time VB (1-3) was NOT object based. Many
> > people hacked together monolithic applications with
> > much of the code in events. These applications were not
> > easily extended or maintained.
>
>From version 1, VB has been "object based". For example, controls were objects
>with properties, and controls and forms had events (of course, maybe in
your
>definition, events aren't associated with objects, but they seemed to be
>in the eyes of the developers of all versions of VB). The versions you described
>simply did not support the developer creating his/her own class modules.
>
>
> > Anyone, including Rocky
> > Lhotka, Deborah Kurata or myself who has paid attention
> > will admit object based application development is far
> > superior to the "throw the code in events" garbage.
>
>Deborah Kurata has, as long as I have known of her, been an _advocate_,
in
>fact, a strong advocate, of using Objects. Yet, you say "admit", as though
>that admission had been wrung out of her _grudgingly_. Rocky and you, I
don't
>know about, but if you say you have "paid attention", I suppose you must
>have, though you don't make it clear to _what_ you paid attention.
>
>On the other hand, there are a good many who have, in fact, "paid attention"
>but who aren't convinced that creating applications which aren't necessarily
>based on putting just about everything in developer-created class modules
>is bad practice and amounts to "throw code in events garbage". There have
>always been standard modules available (from VB1 on) into which more widely-used,
>even globally-used, procedures and variables can be placed. And, in general,
>even in RAD applications, I've seen those used appropriately.
>
>It is the events that fire in response to actions of various kinds and where
>some code, perhaps little, perhaps more, must be put in classic VB, even...
>I stress _even_... in applications making extensive use of class modules,
>if the application is to respond to those actions.
>
> > Please, point out the flaw.
>
>In only the parts which I have quoted here, there are several. First flaw:
>stating that VB 1-3 were not "object-based". Second flaw: trying to give
>the impression that DK had to be "convinced" that object is better and implying
>that she "admitted" that was the case rather than the actual case which
is
>that she has long "advocated" object-orientation. Third flaw: trying to
give
>the impression that anyone who has "paid attention" will "admit" that object-oriented
>is always better. Fourth flaw: denigrating the utility of events and implying
>that "throwing code into events" is "garbage".
>
>It has, of course, been possible to create applications that were "garbage"
>with every version of VB (and assembler, and Fortran, and C of all flavors,
>and Pascal, and ...); whether or not you're a bettin' man, you can safely
>wager your future salary that it will be possible to do so in future versions,
>as well.
>
>

[Bob O`Bob]

Larry Linson wrote:
> "Rich" <nomail@nomail.com> wrote:
>
> > Your rant was totally off. My statement was simply this.
> > Once upon a time VB (1-3) was NOT object based. Many
> > people hacked together monolithic applications with
> > much of the code in events. These applications were not
> > easily extended or maintained.
>
> From version 1, VB has been "object based". For example, controls were objects
> with properties, and controls and forms had events (of course, maybe in your
> definition, events aren't associated with objects, but they seemed to be
> in the eyes of the developers of all versions of VB). The versions you described
> simply did not support the developer creating his/her own class modules.


No, it did, sort of ... forms actually were already classes, and could be used as such.

I once implemented a design (from 'CRC' cards) in VB3 using a significant number of
form types which were never shown. But they had initialize and destruct events,
properties of controls could act as properties of the object, and I built a fairly
robust set of textbox change event handlers to act as methods.

Performance was (as predicted) miserable.
But the point of RAD was driven home quite dramatically.


Bob
--
Life makes SO much less sense when you're sane.

[Craig Burkett]

> >First flaw: stating that VB 1-3 were not "object-based".
>
> You are confusing objects and components(VBXs and ActiveX controls).
Components
> are not the same as VB class modules. VB being object based is a semantic
> used to describe the VB language class module capabilities. The VB
language
> is not a 100% pure object oriented language. As I said before, it is
missing
> implementation inheritance. Hence, the object-oriented purists would not
> consider it object oriented. Many would say it is object based. Since this
> was added in VB 4, one could not say VB 1-3 is object based. "Flaw"
refuted.
>
VB 1-3 were object based. The definition of an object is an instantiated
class correct? There is nothing in OOP that states how that class is
supposed to be defined. It is only an abstract concept. And believe it or
not - at least since VB2 - a form was a way for a VB programmer to
encapsulate code in an object. This is because you actually could
instantiate a seperate instance of the form and assign it to a variable.

Dim objMyForm As Form1

Set objMyForm = New Form1

'These wind up being two different instances of the same form
objMyForm.Show
Form1.Show

The only problem at this point is that the developer could not define custom
methods or properties for the form. I personally overcame this limitation
by employing windows messaging to pass in or send values to and from other
form objects (using Spyworks). I would submit that the Form was a crude
form of a class at this stage of VB's life cycle.

With each subsequent version of VB (4-6) more object oriented features were
added. Starting with version 5 polymorphism was introduced to VB. This was
the feature that made VB completely object oriented, it was just more
involved to implement. This is accomplished through the concept known as
"Delegation". Frankly, I do not believe "implementation inheritance" is
required for a language to achieve the ballyhooed status of being "object
oriented". I believe the only required elements are "encapsulation" and
"polymorphism". "Implementation inheritance" (just as "Delegation" is one)
is just a means for achieving polymorphism. So a good CASE tool
implementing UML can be used to generate code in any language which supports
these two concepts. Remember, even the early C++ environments were only
translators. They would translate the C++ code to C code and then compiled.

> >Second flaw: trying to give the impression that DK had to be "convinced"
> that object is better and implying >that she "admitted" that was the case
> rather than the actual case which is>that she has long "advocated"
object-orientation.

Frankly, I knew Deborah Kurata from Compuserve and she did not give me the
impression of being a well informed Computer Science expert. She didn't
even know how to implement a linked list using VB3. So basically I just see
her as an author who takes other ptrogrammers ideas and claim them for her
own.

>
> For an application of any size, it is almost always better. In a rare
occasion
> one may want to functionally decompose to increase performance. Sometimes
> this works, sometimes it does not increase performance. Whether or not the
> performance is increased, maintainability is decreased. "Flaw" refuted.
>
Oh I don't know about that. I think structured programming (as defined by
Dykstra) was more than sufficient for creating large systems. However it
did require a great deal of discipline to not take shortcuts to the
implementation of the system. As a matter of fact I believe OOP is an
extension of structured and helps to enforce the rules as laid out by
Dykstra.

>
> Again, using solid OOD always leads to maintainable, reusable and
extensible
> applications. Believe it or not. Enough said. "Flaw" refuted.
>
I can't believe this was even typed. Yes OOD (or OOAD) reduces the
introduction of errors into the design of a system it does not always lead
to the goals you expoused. I have seen many failed attempts at OOAD.
However, as long as we learn from those failures that's ok.

--
JMHO,
Craig Burkett MSCS
"A VB Developer since its coming out party"
"An OO VB Developer since VB4"

"Rich" <nomail@nomail.com> wrote in message news:3b93001d$1@news.devx.com...
>
> Larry,
>
> >First flaw: stating that VB 1-3 were not "object-based".
>
> You are confusing objects and components(VBXs and ActiveX controls).
Components
> are not the same as VB class modules. VB being object based is a semantic
> used to describe the VB language class module capabilities. The VB
language
> is not a 100% pure object oriented language. As I said before, it is
missing
> implementation inheritance. Hence, the object-oriented purists would not
> consider it object oriented. Many would say it is object based. Since this
> was added in VB 4, one could not say VB 1-3 is object based. "Flaw"
refuted.
>
>
> >Second flaw: trying to give the impression that DK had to be "convinced"
> that object is better and implying >that she "admitted" that was the case
> rather than the actual case which is>that she has long "advocated"
object-orientation.
>
>
> I guess you missed my point. I was attempting to be diplomatic. I did not
> want to say, "Here is what the experts say, if you do not believe them
your
> are an idiot." "Flaw" refuted.
>
> Third flaw: trying to give >the impression that anyone who has "paid
attention"
> will "admit" that object-oriented
> >is always better.
>
> When I said, "paid attention" I meant anyone who has kept up with the
object-based
> capabilities added in VB. It was hard to miss. :-)
>
> For an application of any size, it is almost always better. In a rare
occasion
> one may want to functionally decompose to increase performance. Sometimes
> this works, sometimes it does not increase performance. Whether or not the
> performance is increased, maintainability is decreased. "Flaw" refuted.
>
>
> >Fourth flaw: denigrating the utility of events and implying
> >that "throwing code into events" is "garbage".
>
> Again, using solid OOD always leads to maintainable, reusable and
extensible
> applications. Believe it or not. Enough said. "Flaw" refuted.
>
>
>
> Rich
> --------------------------------------------------------------------------
-

[Mike Mitchell]

On 2 Sep 2001 17:08:31 -0700, "Rich" <nomail@nomail.com> wrote:

>Your rant was totally off. My statement was simply this. Once upon a time
>VB (1-3) was NOT object based.

Please explain how firing up VB6 and placing a control on a form with
some code "thrown" into the events is any different from doing exactly
the same thing in VB1. That's right, it isn't in anyway different.
It's the SAME. That is, there is NOTHING different fundamentally
between VB1 and VB6. I and 2,999,999 other VB programmers got hooked
on VB because it allowed us to create Windows programs without the
huge learning curve and pain of C. That simple truth has held good for
ten years. No amount of bells and whistles in VB6 will change it. VB
*is* the shortest route there is to a Windows app. What's more,
corporates all over the world love VB. They see it as their salvation
for implementing changes in the business quickly and reliably. Instead
of a three-month turnaround in other language disciplines they are
used to a one-day or one-week turnaround in VB. I know the C coders
don't like it; they're miffed, understandably, that VB should enjoy
such a lot of icing on the cake, but it's their choice if they don't
want to be more productive by dumbing down to a "toy" language.

VB.NET on the other hand is so full of bells and whistles you can
barely see the player any more. The thing needs a framework many times
larger than any of the VB1/2/3/4/5/6 packages did. You cannot just
fire up VB.NET, create an app, then give it to someone else on the
offchance they may have the framework. This, however, is what you CAN
do very easily with VB. It's a given that your "someone else" will
have a version of Windows that will run your app, and the most they'll
need, if they haven't already got it, is the VB runtime, a measly
megabyte or so.

You can witter on about "objects", and "object-based" till the cows
come home, but millions of VB users couldn't care less. They see VB,
as I do, as a kind of graphics package in which you "paint" your app
on a "canvas", and then "animate" it by adding event handling code.
The fact that I do not need to know about trigonometry, geometry,
algebra and other arcane stuff to produce a graphics creation is just
as valid in my use of VB.

But in VB.NET the underbelly of the language is now exposed. No longer
is it sufficient for a programmer just to use it. They have to
understand how the intestines fit in the underbelly. We are now
expected to be our own butchers. VB.Halal, anybody?

> Many people hacked together monolithic applications
>with much of the code in events. These applications were not easily extended
>or maintained. Anyone, including Rocky Lhotka, Deborah Kurata or myself who
>has paid attention will admit object based application development is far
>superior to the "throw the code in events" garbage. Please, point out the
>flaw.

The flaw here is your assertion that those "monolithic" applications
were neither easily extended nor maintainable. Your assertion that an
app which does not follow object-based principles is not easily
extendible or maintainable is a flawed assertion. Surely the holy
grail of object-based development is software reuse? Otherwise, how do
you become more productive? And yet, as we all know, despite the hype
of the last five years since OOP was rediscovered, reuse is an elusive
goal most people have yet to attain. I would argue that a
well-designed "monolithic" app has more chance of promoting software
reuse by dint of procedure libraries which can easily be decoupled and
used in many other apps. In fact, the components I use in VB are only
a minor deviation from that concept, which is probably why I like VB
so much. I can buy for a few hundred dollars or less a "library" of
components about whose underbelly I know absolutely zilch and that's
great! I can re-use software (in the form of "component" libraries) in
many different apps. So, if I'm using professionally-written
components and they have been already "re-used" (i.e. tested) by many
thousands of other customers before I buy my copy, surely I am
enjoying optimum reuse? I place my control on a form and throw some
code at the events. Job done. And very productively.

Question: At what point does a monolithic app become monolithic? I
believe you chose the word "monolithic" without really savouring its
meaning in terms of computer applications. Do you want "monolithic" to
mean "procedural" by any chance?

Another question: If you are so sure that object-based VB.NET is
better than the classic VB people are actually using, how do you think
those VB users now will be persuaded over to VB.NET? I mean, let's
look at its selling points:

- more complex
- needs a huge framework
- is still proprietary
- only available along with C#, C++ etc etc
- not backward compatible
- needs more memory
- won't run on Windows 95
- etc etc

I mean, which one of those features do you think will be the killer
which will cause swarms of willing VB developers to rush to the shops
on D Day?

>I suppose you thought I was ripping on VB 6. Again, you were WRONG. I was
>pointing out how some "programmers" hacked things together in the past. I'm
>assuming all professional programmers now know and use the object based features
>of VB6. :-)

Your assumption is misplaced since 70% of VB applications don't use
objects in the way you mean and contain no classes. Huge numbers of VB
devs have never written a class and will never write one. Why do you
think there are now rumours that Microsoft may be dumbing down VB.NET
in future versions? Could it be that they fear it's too complex for
ordinary users to contemplate or comprehend? Ah, but it's the ordinary
users wot pays the bills, not the relatively small number of purists
to whom a deliverable is less important than how it gets written.

>I think you missed the boat on RAD. Maybe, for your small applications, hacking
>is the way. That is your choice. For me, I write medium to large applications,
>which contain code, which is scalable, maintainable and reusable. Not one
>offs.

Again, it depends on where a "small" app becomes a "monolithic" one.
If our "small" apps can feature in 25% of annual income for a
multi-billion dollar international company, well, I'll happily accept
"small" as an accolade, thanks!

>As for code in events, that is a hack. Tons of code in the events. This is
>the way I would expect a neophyte to write applications. There is no design.
>Just hack it together. You know what I meant. There should be minimal code
>in the events calling objects properties or methods.

Or procedures and functions.

>As for VB's role, I have been using VB for over eight years each and every
>day for eight hours a day or more. The "Ruby VB" was an excellent start.
>It was never intended to last as long as it did. It had a great run. Now,
>it is off to VB.NET. This is the future. You can like it or not.

I think you're jumping the gun here by predicting the future even
before Microsoft have released the product. I think I'd prefer to wait
and see first. Meanwhile, there are other products and avenues to
explore, none of which chooses the "monolithic" Microsoft proprietary
route. That I do like!

MM

[Mike Mitchell]

On 2 Sep 2001 20:59:25 -0700, "Rich" <nomail@nomail.com> wrote:

>I guess you missed my point. I was attempting to be diplomatic. I did not
>want to say, "Here is what the experts say, if you do not believe them your
>are an idiot." "Flaw" refuted.

Many experts once said what a good idea eugenics was.

First, choose your experts!

MM

[Mike Mitchell]

On 2 Sep 2001 20:59:25 -0700, "Rich" <nomail@nomail.com> wrote:

>Again, using solid OOD always leads to maintainable, reusable and extensible
>applications.

Evidence?

MM

[Ian R]

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message
news:3b94a4ab.10708110@news.devx.com...
>
> VB.NET on the other hand is so full of bells and whistles you can
> barely see the player any more. The thing needs a framework many times
> larger than any of the VB1/2/3/4/5/6 packages did. You cannot just
> fire up VB.NET, create an app, then give it to someone else on the
> offchance they may have the framework. This, however, is what you CAN
> do very easily with VB. It's a given that your "someone else" will
> have a version of Windows that will run your app, and the most they'll
> need, if they haven't already got it, is the VB runtime, a measly
> megabyte or so.
>

No Mike, perhaps *you* can't "see the players any more". A lot of others
can. If you don't need or want all the "extra features" don't use them. With
a few exceptions you can still write pretty much the same VB6 code. As far
as the framework goes, you're being deliberately thick again. We've gone
through this before. All languages need some type of runtime and/or support
files. Try using some of the tools you have for a change, like Depends and
you'll soon find out that your "measly megabyte" isn't so "measly". If
you're writing simple "Hello World" apps as you apparently do, it'll
probally run as is, anything larger and you'll probally need the entire
distribution.

> You can witter on about "objects", and "object-based" till the cows
> come home, but millions of VB users couldn't care less. They see VB,

And millions of others do care.

> as I do, as a kind of graphics package in which you "paint" your app
> on a "canvas", and then "animate" it by adding event handling code.
> The fact that I do not need to know about trigonometry, geometry,
> algebra and other arcane stuff to produce a graphics creation is just
> as valid in my use of VB.
>
> But in VB.NET the underbelly of the language is now exposed. No longer
> is it sufficient for a programmer just to use it. They have to
> understand how the intestines fit in the underbelly. We are now
> expected to be our own butchers. VB.Halal, anybody?
>

The framework exposes a lot of things for those that need it. For those who
don't, and want a simple drag and drop [insert control here] onto form then
double click and type a couple of line of code type of approach, VB.NET does
that as well. The new form object alone has numerous new properties that
eliminate a lot of code that needed to be done in VB6. Heck, even *you* can
use it.

>
> you become more productive? And yet, as we all know, despite the hype
> of the last five years since OOP was rediscovered, reuse is an elusive
> goal most people have yet to attain. I would argue that a

That has nothing to do with OOP. It like anything, including procedural
code, can be abused. For those who do understand it, it can make development
easier, faster and more scaleable.

> so much. I can buy for a few hundred dollars or less a "library" of
> components about whose underbelly I know absolutely zilch and that's
> great! I can re-use software (in the form of "component" libraries) in
> many different apps. So, if I'm using professionally-written
> components and they have been already "re-used" (i.e. tested) by many
> thousands of other customers before I buy my copy, surely I am
> enjoying optimum reuse? I place my control on a form and throw some
> code at the events. Job done. And very productively.
>

You're using a form of OOP whether you like it or not. Which just shows that
either you're extremely thick or extremely stubborn.

>
> Another question: If you are so sure that object-based VB.NET is
> better than the classic VB people are actually using, how do you think
> those VB users now will be persuaded over to VB.NET? I mean, let's
> look at its selling points:
>
> - more complex

In your mind perhaps. But then again I get the impression you find a form
with one button fairly complex.

> - needs a huge framework

14 meg as opposed to VB6's 8 meg. Considering some of the installation
benefits like XCOPY installs, side by side versioning etc, I think the
slight difference is worth it.

> - is still proprietary

Earth to Mike. So is VB6 et al.

> - only available along with C#, C++ etc etc

What does that have to do with anything ? You're grasping at straws again
Mike. If you don't want to use the other languages then don't.

> - not backward compatible

Not fully backwards compatible you mean. I've ported a number of my VB6
projects over to .NET and with the exception of a few things I had to
change, it runs fine. If you're coding in a PDS style or just simply a lazy
*** programmer then yes you'll probally run into problems.

> - needs more memory

Requires about the same. Might help if you actually tried some of this stuff
before you started passing hot air.

> - won't run on Windows 95

Windows 95 will be obsolete by the end of this year. Most business's have
either already upgraded or will have by the time .NET gets released. Most
new PC's ship with Windows ME or Windows 2000 and have been for the past
year or so. The transition to .NET won't happen overnight so for the few
Windows 95 diehards you can still develop in VB6, C++, Delphi or whatever.

> - etc etc

Care to be more specific on that one or is that too much for you ?

>
> Your assumption is misplaced since 70% of VB applications don't use
> objects in the way you mean and contain no classes. Huge numbers of VB

All VB apps use objects. Think about it.
If 70% of VB developers don't use classes that's fine. That means there's
30% who do and need a language that supports it. If the other 70% don't,
then they don't have to use it just because the language supports it.

> devs have never written a class and will never write one. Why do you
> think there are now rumours that Microsoft may be dumbing down VB.NET
> in future versions? Could it be that they fear it's too complex for
> ordinary users to contemplate or comprehend? Ah, but it's the ordinary

They're not "dumbing down" VB.NET. They're adding features to C#.

> users wot pays the bills, not the relatively small number of purists
> to whom a deliverable is less important than how it gets written.

You obviously don't do code maintenance.

>
> I think you're jumping the gun here by predicting the future even
> before Microsoft have released the product. I think I'd prefer to wait

Considering it's Microsoft that's backing it and actually using it, it's
pretty safe bet.

> and see first. Meanwhile, there are other products and avenues to
> explore, none of which chooses the "monolithic" Microsoft proprietary
> route. That I do like!
>

HP is buying Compaq. That makes them the biggest PC maker. Does that mean
you won't be using any hardware from them because they're "Monolithic" ?
VB1-6 is proprietary,Delphi is proprietary, Kylix is proprietary, PowerBasic
is proprietary. The code you develop at your company (assuming that you
actually do development) is proprietary. If you don't like Microsoft for
whatever reason, that's your right but don't knock what you don't understand
much less tried. Finished that book yet ?