Speaking of strings...

[Dave]

"Jason" <jason@hotmail.com> wrote:
>
>How did you do it in VB6? Create a form, add a button, double click on
the
>button and add some code.
>
>How do you do it in VB.NET? Create a form, add a button, double click on
>the button and add some code.
>
>Mike, it is EXACTLY the same conceptually. VB.NET adds a few more OO bells
>and whistles which help with writing those components you love. It also
>cleans up the language a bit - it's a bit more consistent now. And better
>garbage collection. But that is about it.
>
>If you program by creating forms, adding controls, and then writing code
>behind them, you will be right at home in Visual Studio.NET.
>
>Really. Without any more OO than you are using right now.

I think this is mostly right - I've converted a couple of small projects
from VB6 to VB.NET (during my retirement from this newsgroup) and I didn't
have to radically change my mindset (kinda OO, but not extremist). On the
other hand, I'm pissed that with the current condition of the Upgrade Wizard
I'm going to have to leave my large projects in VB6 - just little things
like the wizard randomly deleting a couple of lines of code here and there(!!!!).
Like most developers, I'll probably eventually abandon these to others when
I can't stand being further than a stone's throw from the leading edge.

And since my large projects is where I spend most of my time, until the wizard
is drastically improved I can only play with .NET.

[PWilmarth]

Of course, both of you are engaging in circular arguments, convinced that
only your particular point of view is correct, with neither one of you able
or willing to acknowledge that the other side may have some valid points.
The need to be right or to win has caused both of you to engage in personal
attacks just so you can claim victory. Rather than adopting a "win at all
costs" (or be right at all costs) mentality, you both could just "agree to
disagree" and move on.

[Jason]

"Dave" <dave_doknjas@yahoo.ca> wrote:
>On the
>other hand, I'm pissed that with the current condition of the Upgrade Wizard
>I'm going to have to leave my large projects in VB6 - just little things
>like the wizard randomly deleting a couple of lines of code here and there(!!!!).
>Like most developers, I'll probably eventually abandon these to others when
>I can't stand being further than a stone's throw from the leading edge.
>
>And since my large projects is where I spend most of my time, until the
wizard
>is drastically improved I can only play with .NET.

Yeah, and that is an argument where MM has a point. VB.NET is not backward
compatible with VB6, and there is no easy upgrade path. It is best, for
now, to think of them as entirely separate languages, kind of like C++ and
Java are separate languages despite the fact that they share syntactical
similarities.

I personally don't believe the upgrade wizard will ever provide an easy upgrade
solution, but Microsoft may prove me wrong yet. The upgrade wizard for version
1.1 is supposed to take in UserControls. Like I have said before, I will
believe it when I see it.

[Jason]

"PWilmarth" <PWilmarth80231@msn.com> wrote:
>
>Of course, both of you are engaging in circular arguments, convinced that
>only your particular point of view is correct, with neither one of you able
>or willing to acknowledge that the other side may have some valid points.
>The need to be right or to win has caused both of you to engage in personal
>attacks just so you can claim victory. Rather than adopting a "win at all
>costs" (or be right at all costs) mentality, you both could just "agree
to
>disagree" and move on.

I'd like to agree to disagree, but that isn't my style. Besides, I'd like
to enlighten Mike.

He thinks that if he uses modular programming style in VB, then he is doing
modular programming.

What I am trying to get him to understand is that when he uses objects, he
is doing a form of OO programming, even if he doesn't ever write a class
module.

Some people seem to have gotten the idea that I am 100% OOP and o% modular
programming. That is not the case. In fact, it doesn't work, unless you
happen to be programming Eiffel.

Almost all good OOP I have seen uses a lot of functions underneath. The
OO part is just to wrap the library in a way that makes it easier to understand
for end users. The object wrapper is there to encapsulate the nasty bits,
and sometimes to allow users to add their own customizations to the library.

The top level of code is almost always modular in nature. Even in Java,
you always enter the code through a static "main()" method (not part of an
object).

But when you program a Form in VB, even VB6, you are doing OO programming.
The Form is an Object (or class - it has Initialize, Terminate, and a lifetime).
It contains controls (a "has-a" relationship, not an "is-a" relationship).
The form receives polymorphic callbacks for events on both the controls
and the Form, and they are handled by Event Handlers. Every form has, optionally,
additional public and private members that contain different data between
instances of the form.

This is OO programming. In fact, I think VB6 has a very nice OO model.
Very clean, very much like writing a normal BAS module. Not complete, by
any definition, but it has a lot of functionality.

I've been saying in many of my posts that Mike has some valid points. The
top level of any program in VB is going to look more MP and less OOP if it
is programmed well. But the libraries you use to implement that top level
are far easier to consume if they have a well written object model.

Compare any of the ActiveX libraries from Microsoft to the APIs of what they
wrap. If we had to do everything in VB6 without those object wrappers, development
would be a lot more time consuming.

All I have been saying all along is that OO has a place, and OO tools can
be very useful if applied and used correctly. All I have heard from Bill
and Mike is that "modular programming" has always been superior to OO, and
they want nothing to do with it.

And what I am telling them is that if they are using VB6, they are doing
OO whether they like it or not (and seeing it as useful and intuitive), even
if they never create a class.

[Dave]

"Jason" <jason@hotmail.com> wrote:
>
>I personally don't believe the upgrade wizard will ever provide an easy
upgrade
>solution, but Microsoft may prove me wrong yet. The upgrade wizard for
version
>1.1 is supposed to take in UserControls. Like I have said before, I will
>believe it when I see it.

Yeah. BYW, have you seen the abortion the wizard makes of control arrays?
Yuk!! It was far cleaner to fix them in VB6 (via truly dynamic control creation
and 1 class to subclass a single control instance) and then run the wizard.
Kinda makes you wonder about how little VB was understood by those programming
the wizard (since they also could have taken the clean approach).

[PWilmarth]

Your answer is rational and reasonable, but remember, the game Mike is playing
is to refuse to acknowledge any valid points that you have. Don't know if
you have ever watched the debates on MSNBC or CNBC. They argue for the sake
of arguing. Doesn't matter if the other side has valid points. If he (or
Bill) acknowledge your arguments as valid, the game is over.

[Ed Courtenay]

"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
news:3DAC3F63.473FDCE8@netzero.net...
> <snip/>
>
> Here is a brief list I gave in another post:
>
> 1) It is simpler.
>

Possibly, but not necessarily a good thing. Overall, OO is not inheritantly
difficult either.

> 2) It is closer to the way people normally think, and is therefore
> more intuitive.
>

I disagree. I find OO based design much more natural than plain Modular
development.

> 3) It is closer to the way computers operate, and generally creates
> less unnecessary overhead.
>

So? Write your code in hex if you want to get down to the metal.

> 4) It is closer to the realities of most problem domains.
>

Not in any large scale developments that I've worked on; invariably OO
design has been able to model the 'real-world' problem at a much closer
level.

> 5) It avoids all of the problems inherent in class related OO
> constructs (inheritance, overloading, etc.).
>

Operator overloading can be a thorny issue; if used correctly it's a boon,
if not it's a problem I'll grant you. However, it can make for very natural
code;

Point p = new Point(1, 2);
Point q = new Point(4, 5);
Point r = p + q;

When you change the *meaning* of the overloaded operator, then you cause
problems and lead to code obfuscation.

> 6) It avoids problems caused by confusion between data access and
> code execution.
>

What confusion?

> 7) It concentrates the code for a given function in one place, and
> limits the potential range and scope of unwanted side effects
> from changes to that code.
>

It also makes that function large and unwieldy, prone to error and difficult
to manage. As for limiting the potential range and scope of unwanted side
effects, I'll think of a decent rebuff when I pick myself off the floor and
stop laughing.

> 8) It is easier to maintain and upgrade by people other than the
> original designer(s) and programmer(s).
>

Doubtful in my experience. The clear hierachy present in OO designs make it
easier for me to find my way through a colleagues code, not the other way
around. The most likely problem faced with by a developer charged with
maintaining and updating someone elses code is obfusation, badly named
variables and monolithic programming stuctures.

> 9) It is practical to do in most languages, from Assembly up.
>

Why have OO languages been developed then? Why have they proved so popular?
Are we being brainwashed, or have we actually proved to ourselves that this
is a viable method of development?

> <snip/>

[Mike Mitchell]

On 15 Oct 2002 18:23:19 -0700, "Jason" <jason@hotmail.com> wrote:

>I personally don't believe the upgrade wizard will ever provide an easy upgrade
>solution, but Microsoft may prove me wrong yet. The upgrade wizard for version
>1.1 is supposed to take in UserControls. Like I have said before, I will
>believe it when I see it.

I repeat, the converter/wizard/updater, call it what you will, should
have been *the* most important feature of VB.Net after the actual
language itself was produced. By (a) scrapping backward compatibility,
and (b) not providing a 99.9% useful converter, Microsoft basically
implied they'd given up on traditional VB programmers. Either that, or
Microsoft thought that traditional VB programmers were already 100%
converted to Java-based thinking.

Imagine the outcry if a word processor were introduced that could not
read any previous documents of any kind, not even by importing or
filtering or whatever process!

MM

[Mike Mitchell]

On 15 Oct 2002 19:25:27 -0700, "Dave" <dave_doknjas@yahoo.ca> wrote:

>Yeah. BYW, have you seen the abortion the wizard makes of control arrays?
>Yuk!! It was far cleaner to fix them in VB6 (via truly dynamic control creation
>and 1 class to subclass a single control instance) and then run the wizard.
>Kinda makes you wonder about how little VB was understood by those programming
>the wizard (since they also could have taken the clean approach).

Yes, where there are so many disparities between classic Visual Basic
and VB.Net, there will be conversion situations which are ambiguous.
But this is where a good wizard would prompt the user with different
conversion scenarios, with paybacks and obstacles, then allowing the
user to make a decision. Thus, the wizard could even learn by example,
thereby exhibiting some rudimentary form of AI.

MM

[Mike Mitchell]

On Wed, 16 Oct 2002 09:13:32 +0100, "Ed Courtenay"
<replace-this-with-my-first-name@edcourtenay.co.uk> wrote:

>Why have OO languages been developed then? Why have they proved so popular?
>Are we being brainwashed, or have we actually proved to ourselves that this
>is a viable method of development?

Prove to others, not just yourselves! I'm still waiting for meaningful
ways of measuring productivity so that the supposed benefits of OOP
can be shown to be actual and not just brainwashing.

MM

[Mike Mitchell]

On 15 Oct 2002 12:59:15 -0700, "PWilmarth" <pwilmarth80231@msn.com>
wrote:

>If, as you imply, OOP is not the solution, but part of the problem, then what
>would you suggest as a solution?

We get to keep *our* preferred tools and are not fobbed off with
something we don't want. It's all about choice. For decades, anyone
who really wanted to produce software following OOP principles could
have done so. They didn't need Microsoft to take away classic VB in
order to permit them to do it.

>Using analagies to other professions is all very well and good, but none
>of them live in a perfect world either. To cite your example of the general
>practitioner, even a good general practitioner has to know something about
>about cardiology, as well as oncology, hematology, orthopedics, obstretrics,
>pharmacology, nutrition, neurology, dermatology, toxicology, emergency medicine,
>etc, etc. He (or she) doesn't need to be an expert in each of these areas,
>but needs to at least have enough fundamental knowledge of each area in order
>to know when a specialist in each of these areas is required. Each one of
>these specialists has their own paradigm, and you might get a different solution
>to a given problem, depending on who you ask.

Yeah, and I know enough about OOP in order for me to write the
mandatory classes needed when I develop a VB5/6 add-in. If I needed to
know more, I'd find out. Just like the doc.

>You write very lengthy dissertations about the weaknesses of OOP as a methodology,
>but, Mike, in your dream world, how would you like to see things done? And
>how are you moving your profession in that direction?

The way I'd like to see things done is, they should get easier, they
should build upon the ideas inherent in Alan Cooper's design as the
Father of Visual Basic, they should involve the *computer* much more
by using AI, they should enable ordinary workers and members of the
public to write software, as QuickBASIC/VB uniquely made a start in
doing, they should be "open" in the sense that no proprietary
manufacturer should be allowed to arbitrarily consign a widely used
product to the trash.

How am I moving "my profession" along? Like eating an elephant - one
byte at a time!

MM

[iGadget]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:l3cqqu8g3psupciaea87cgvbno124bd966@4ax.com...
> On Wed, 16 Oct 2002 09:13:32 +0100, "Ed Courtenay"
> <replace-this-with-my-first-name@edcourtenay.co.uk> wrote:
>
> >Why have OO languages been developed then? Why have they proved so
popular?
> >Are we being brainwashed, or have we actually proved to ourselves that
this
> >is a viable method of development?
>
> Prove to others, not just yourselves! I'm still waiting for meaningful
> ways of measuring productivity so that the supposed benefits of OOP
> can be shown to be actual and not just brainwashing.

All of these arguments are pointless if you assume programming languages are
only there to solve your particular line of work.
I wrote a database app to query and report questionnaire results for a
company recently, and most of it was procedural. It didn't really benefit
from my writing any objects, although they were present in the reporting
tool I linked to.
I am now working on a structured questionnaire designer with hierarchical
structures of sections, groups, and questions, with reusable sections lots
of question structures that all differ slightly. An OO language is perfect
for this situation.

Perhaps, in your line of work, you don't have many requirements for OO
coding, in which case you can either use VB6 or probably get away with
procedural coding in VB.NET.
Arguing about whether OO is efficient, viable, or whatever is pointless. It
does have its uses, and is perfect for many tasks, but unnecessary for
others.

You want something to argue about in the mainstream software development
world?
Justify why Rational managed to sell millions of copies of Rose to
companies? I think the idea behind UML is excellent, and class and sequence
diagrams are great (although I still struggle to do them), but Rational's
methodologies are the biggest load of bollocks I have ever seen.
Conversation I overheard between a business analyst and a Rational trainer
at one bank I was at:
"So, how many 'scenarios' should we write for each Use Case?"
"About 20"
"And how big would you expect each one to be?"
"Oh, about 10pages..."
This was when the business analyst decided to leave and get a cup of coffee
for the rest of the week...

Cheers,
iGadget

[Paul Clement]

On Wed, 16 Oct 2002 10:27:41 +0100, Mike Mitchell <kylix_is@yahoo.co.uk> wrote:

¤ On Wed, 16 Oct 2002 09:13:32 +0100, "Ed Courtenay"
¤ <replace-this-with-my-first-name@edcourtenay.co.uk> wrote:
¤
¤ >Why have OO languages been developed then? Why have they proved so popular?
¤ >Are we being brainwashed, or have we actually proved to ourselves that this
¤ >is a viable method of development?
¤
¤ Prove to others, not just yourselves! I'm still waiting for meaningful
¤ ways of measuring productivity so that the supposed benefits of OOP
¤ can be shown to be actual and not just brainwashing.

It's really very simple. If it's not your style and you don't feel there is a productivity benefit,
then don't use it. Continue to code as you did before. Nobody is forcing you to implement the
concepts in your applications.


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

[W.E. (Bill) Goodrich, PhD]

In article <3dac4a73$1@10.1.10.29>,
"Jason" <jason@hotmail.com> writes:

> >It would take a good sized book to fully explain modular programming,
> >though I have covered some of the highlights from time to time.

> Then it is neither simple nor intuitive. It takes about 3 or 4
> chapters to explain OO in the context of the .NET implementation.

Yet more of your word games and tactical illiteracy, I see. Do you
seriously expect anyone here to be stupid enough to fail to see the
significant difference between "fully explain" and "explain in the
context of the .NET implementation"? Just how stupid do you think your
fellow cheerleaders are? Willfully blind, yes. Stupid - especially
THAT stupid - no.

The basics of modular programming are very simple and intuitive. A
"how to do modular programming in VB6" explanation could be done in
a single chapter. But the issue wasn't "explain it in the context of
VB", it was "fully explain it in a way that could be understood by a
self proclaimed semi illiterate". While a "Modular Programming for
Dummies" explanation (with apologies to IDG Books) would take an
entire book, the equivalent "OOP for Dummies" book would be much
larger.

> >Your
> >own demonstrated ignorance on the subject of modular programming says
> >sad things about your education and experience. And I would hardly
> >call Scott Meyers' piece an "obscure academic article."

> It sure looked academic to me.

That says very sad things about you.

> Did I use the word obscure? I don't know that for a fact.

And you are too crippled to look at the article you were citing? In
particular, to look at the quotation you chose to delete? Your exact
words were:

: And don't just post some obscure academic articles that don't tell
^^^^^^^
: anyone anything - actually explain what you are talking about.

Yes, you DID use the word obscure. It is one thing for you to claim
that you lack the vocabulary to understand my posts. It is quite
another to claim that you can't even read your own statements - even
when they are quoted back to you word for word.

> But the article - if I remember correctly - was not written in a way
> that made it all that useful to me.

More tactical illiteracy, I see.

> Sounded more like a thesis paper.

More like an "engineering journal" article (which it was) than an
Academic paper (much less thesis). Its focus is practical, and its
tone is informative. Your claimed inability to understand such
articles says very sad things about your education and experience.


> *************************

> On another point, we are talking about things in the context of VB6
> and VB.NET here, right?

It's a little to try and play THAT brain dead game. No, we are most
certainly NOT just talking about things in the context of VB and
VB.NET here. YOU have not been doing so - one of your first examples
was from Java, and you have repeatedly cited that and other languages.
As have I. When we have been discussing MP and OOP as such, it has
been in the broader context of the modalities rather than in the
narrow context of a particular language or two.

Of course, if you now admit that you are unable to do so, that says a
lot about the nature of your previous posts. And you.

> I mean, when you say "Modular Programming," you are referring to
> something you can do in VB6 and not some new concept for which a
> language still needs to be written.

Not only tactical illiteracy, but a claimed ignorance of the history
of the field as well? Modular Programming has been around for the
better part of half a century (as I have already mentioned), does not
need any specialized languages (as I have repeatedly mentioned), and
constitutes a significant portion of the basis (and accounts for much
of the claimed benefits) of both OOP and the earlier SSP (as I have
mentioned a number of times). It has also been the modality
responsible for the most stable and robust software available in most
fields - software which has survived decades of use, in many cases.

The claimed ignorance in that question goes a long way toward
explaining many of your nonsensical arguments in this newsgroup.

--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*

[Jason]

"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
>Not only tactical illiteracy, but a claimed ignorance of the history
>of the field as well? Modular Programming has been around for the
>better part of half a century (as I have already mentioned), does not
>need any specialized languages (as I have repeatedly mentioned), and
>constitutes a significant portion of the basis (and accounts for much
>of the claimed benefits) of both OOP and the earlier SSP (as I have
>mentioned a number of times). It has also been the modality
>responsible for the most stable and robust software available in most
>fields - software which has survived decades of use, in many cases.
>
>The claimed ignorance in that question goes a long way toward
>explaining many of your nonsensical arguments in this newsgroup.

Yuh know, I am trying not to post negatively, and to try to understand your
point of view. And you still post an insult in every other sentence. But
every OTHER sentence is providing some information, so I will try to deal
with that.

Simply put, how do you reconcile the fact that forms, controls, and ActiveX
DLLs are all OO-based (without inheritance, granted), in the context of modular
programming in VB?

What I mean is, there are a number of programs that are written in C that
are still around, and these programs are strictly MP. But with VB, you can't
write more than about 10 lines of code without using some sort of object.

What I am trying to understand here is, are you for "strict" MP, or MP that
makes use of object libraries others have written, or do the object libraries
in VB somehow fall under the MP umbrella, so they are not actually object
libraries at all?