A moderate view.

[Paul Mc]

G'day Kunle,

>You can't have it both ways. Some of your other comments suggest that you
>want VB to remain like it has been and now...


I have really just been playing at devils advocate - maybe I should make
my own stance clear. I support VB.Net, I have been going at it hammer and
tongs for these past couple of months and have come to love it. I have just
been trying to find ways to address some of the issues of the .Not camp.
I see that their points are valid, and critical to them. I think that if
we can thrash out some ways to adress some of these issues in a manner that
satisfies the .Not camp, and does not adversely affect the language, then
that is the best of all possible solutions.

Cheers,
Paul

[Kunle Odutola]

> I have really just been playing at devils advocate - maybe I should make
> my own stance clear. I support VB.Net, I have been going at it hammer and
> tongs for these past couple of months and have come to love it. I have
just
> been trying to find ways to address some of the issues of the .Not camp.
> I see that their points are valid, and critical to them. I think that if
> we can thrash out some ways to adress some of these issues in a manner
that
> satisfies the .Not camp, and does not adversely affect the language, then
> that is the best of all possible solutions.

Never a truer word said.

Kunle

[Paul Mc]

G'Day T.Hoskins.

>Paul, I really enjoyed reading your post.
Cheers. "8-)

>What most
>developers such as myself probably object to the most is the possibility
>of being forced to use the .NET platform and the "OO way" as their only

>technical solution to a business problem.

I do not think that it is entirely correct to bundle the .NET platform and
the "OO way" in the same basket - I see no reason why you cannot use .Net
without adopting full-scale OO methodology. True, in many ways VB.Net revolves
more around objects than was ever obvious before. That does not mean that
you are required to "Go OO" in your everyday programming. The normal bas
module still exists - it hasn't totally been replaced by class modules yet!
IMO, OO in .Net is much like classes/inteface implementation etc in VB6 -
You have the option of using it, or not. It is your choice.

>OOAD, UML, predictive/adaptive methodologies, design patterns, and all the
>other crap associated with OO development is not necessarily a better way
>of doing things. Just about everything OO development has to offer is just
>a rehash of what is already working for most folks. The truth is that OO
>development is not a silver bullet solution and for small projects it is
>definately overkill in my opinion.

I agree that much of that methodology would be overkill for small projects.
But again, it is not an absolute requirement - just as it was not an absolute
requirement when using classes in vb6.


>What I can't live with is the posibility that the OO way of doing things
>might well be my only choice.

I don't see it as any real danger. The choice will always exist, as I see
it.

Cheers,
Paul

[T. Hoskins]

Kunle,

Just a few comments on your response post. First, I think that all your statements
have merit, however, I am looking at OO from the newbie, independent developer,
and small company perspective. Much of what you wrote makes complete sense
if the person, team, or company has prior and extensive experience (something
that you mentioned in your post). Again, I am not knocking OO development
-- all that I am saying is that there is a steep learning curve and a cost
that comes with using OO technology that all parties must willing to pay
before it can/should be used on a project.

>I wouldn't use the success of OO projects as a yardstick to measure the
utility/usefulness/ROI of the OO paradigm.

Well, why not? If the project success rate isn't any better than current
methods being used then what exactly makes it a better paradigm?

>What is undeniable is that the OO abstraction - based as it is on the idea
>of a software system being a simulation of real worls systems - is more
>"natural" and enables a wider range of people to be able to participate
in
>the analysis, design, development and testing of software systems. The
l>anguage is the same through all the phases of development. Only the level
>of detail changes.

OO is more "natural" and better simulates the real world -- this is debateable.
OO development has been around since the 1960s. if it is such a great paradigm
great why didn't it become popular sooner?

>The success of individual projects is far more dependent on the abilities
and experience of the
>practitioners involved than it is on the problem solving abstractions
>employed. This applies equally to OO projects as it did to structured
>programming, ADT and all the other abstractions that predate OO.

It seems as if you agreeing with me. The abilities and experience of many
IT workers are still in non OO techniques, so, why should people and companies
be forced to change? Well, the answer seems to be that Microsoft and Sun
aren't giving you much of a choice in the matter.

>I would simply note that this issues haven't affected the Java platform
in the slightest...

Would you mind explaining to me what this statement actually means?

>I beg to differ. Use Cases are about requirements. Class models are about
>domain analysis or logical design or implementation depending on the
>context. This are essentiall activities in *all* software development
>projects. You don't have to use those particular techniques but, you still
>have to complete the activities they represent.

Thanks, but I don't really need a lesson in OO technology. My point was that
OO is tough to do on your own. For example, discovering classes is not a
simple thing to do. As you know, the three most common approaches to uncovering
classes are: 1) brainstorm the classes in some type of facilitated session.
2) extract the nouns from uses cases. 3) hold a CRC session. For an individual
option 2 is the only alternative. I will stand by statement that writing
use cases, coming up with good classes, building models, etc. are really
team oriented activities.

Do you really have to complete the activities they represent? I think it
would be more appropriate to say, "you should complete the activities...".
Code and fix development is still the norm in this industry. I wonder how
many developers there really are out there in the world that can provide
womb-to-tomb OO solutions that include all the "necessary" artifacts. Have
you been trained in requirements engineering, UML, and use case writing --
I know that I haven't.

>Pragmatism is a quality found in all the best minds in software engineering.
>Since there is no silver bullet, you are free to determine just how much
of
>everything one learns or reads about is needed for your projects. You are
>also free to substitute techniques as you see fit if it works better than
>what Booch or Jacobson suggests you should do.

Well, the so called best minds in software engineering can't seem to agree
on anything not even what the term software engineer actually entails. By
pragmatism, I am assuming that what you saying is these people know that
much of what they write and lecture about is hardly ever put into practice
(not even by them) in the real world.

>OO when used effectively tackles maintanance quite elegantly IMO.
>Scalability is a design issue that has been tackles very effectively with
>infrastructural components such as MTS/COM+, MSMQ, HTTP, EJB, JMS, Stored
>procs etc...

Your statements still don't negate what my soap box speech was trying to
say.

[Bobby Newmark]

Perhaps Bertrand Meyer's relationship with MS has something to do with it?

http://www.eiffel.com/announcements/...sip/index.html

Bobby

"T. Hoskins" <thoskins@hotmail.com> wrote:
>
>Kunle,
>
>
>>The success of individual projects is far more dependent on the abilities
>and experience of the
>>practitioners involved than it is on the problem solving abstractions
>>employed. This applies equally to OO projects as it did to structured
>>programming, ADT and all the other abstractions that predate OO.
>
>It seems as if you agreeing with me. The abilities and experience of many
>IT workers are still in non OO techniques, so, why should people and companies
>be forced to change? Well, the answer seems to be that Microsoft and Sun
>aren't giving you much of a choice in the matter.
>

[Kunle Odutola]

"T. Hoskins" <thoskins@hotmail.com> wrote in message
news:3af6589d$1@news.devx.com...
>
> Kunle,
>
> Just a few comments on your response post. First, I think that all your
statements
> have merit, however, I am looking at OO from the newbie, independent
developer,
> and small company perspective. Much of what you wrote makes complete sense
> if the person, team, or company has prior and extensive experience
(something
> that you mentioned in your post). Again, I am not knocking OO development
> -- all that I am saying is that there is a steep learning curve and a cost
> that comes with using OO technology that all parties must willing to pay
> before it can/should be used on a project.

I have been all of those things - newbie, independent developer and small
company - in my time too. I chose to invest in myself, and now have a few
problem solving abstractions or paradigms in my toolkit that I can deploy
depending on the nature of the problem. If I can do it, so can anybody else.

Others are free to *choose* not to do the same of course. But it is better
if they learn enough to be able to make an informed decision about whether
to continue learning. There is a price to pay for everything, OO is no
different.

>
> >I wouldn't use the success of OO projects as a yardstick to measure the
> utility/usefulness/ROI of the OO paradigm.
>
> Well, why not? If the project success rate isn't any better than current
> methods being used then what exactly makes it a better paradigm?

I should have qualified my statement thus:
"I wouldn't use the success of any OO project(s) as a yardstick to measure
the benefits of OO technology without _also_ taking the OO ability and
experience of the practitioner(s) involved into consideration."

Raw projects success rates are better for OO than for previous paradigms as
it happens although you have to dig to find and make sense of the various
metrics and reports. People generally stopped asking for proof that OO works
many years ago...

http://dec.bournemouth.ac.uk/ESERG/bibliography.html

As for what makes it a "better" paradigm, I think I said....

> >What is undeniable is that the OO abstraction - based as it is on the
idea
> >of a software system being a simulation of real worls systems - is more
> >"natural" and enables a wider range of people to be able to participate
> in
> >the analysis, design, development and testing of software systems. The
> l>anguage is the same through all the phases of development. Only the
level
> >of detail changes.
>
> OO is more "natural" and better simulates the real world -- this is
debateable.
> OO development has been around since the 1960s. if it is such a great
paradigm
> great why didn't it become popular sooner?

Classes/objects in OO systems simulate real world entities and processes
using software artifacts. What's debatable about that?
OO took a long time to emerge from the labs as does all similarly complex
technologies. Just how long do you think the Internet had been around before
it was suddenly discovered big-time in the 90s? How about instant
messaging - anyone remember 'talk' on Unix? How about virtual development
platforms and GC?

I think they all appeared in the OO timeframe give ir take a few years...
<vbg>

> >The success of individual projects is far more dependent on the abilities
> and experience of the
> >practitioners involved than it is on the problem solving abstractions
> >employed. This applies equally to OO projects as it did to structured
> >programming, ADT and all the other abstractions that predate OO.
>
> It seems as if you agreeing with me. The abilities and experience of many
> IT workers are still in non OO techniques, so, why should people and
companies
> be forced to change? Well, the answer seems to be that Microsoft and Sun
> aren't giving you much of a choice in the matter.

You read that as "since many people are not OO, then the tools should be
non-OO".
I wrote it to mean "if you want to exploit OO (or any other abstraction)
effectively, you need to invest in training and get some experience using
the tools".
Incidentally no one is forced to change. VB.NET still has .bas modules.

Anyone that ignores OO (or other new ideas/tools/technologies) because they
are unfamiliar with it are in the wrong industry. A much more pragmatic (and
successful) approach is to learn about the new idea/tool/technology and then
make an _informed_ decision on it's utility. Change is the only constant...

> >I would simply note that this issues haven't affected the Java platform
> in the slightest...
>
> Would you mind explaining to me what this statement actually means?

In the original context of the statement, you suggested that MS's adoption
of .NET as the sole development platforms has issues that many customers may
be unwilling to accept. My comment simply brings to your attention the fact
that the .NET platform and the Java platform are very similar and those same
issues have had no real effect on the aggressive adoption of the Java
platform.

> >I beg to differ. Use Cases are about requirements. Class models are about
> >domain analysis or logical design or implementation depending on the
> >context. This are essentiall activities in *all* software development
> >projects. You don't have to use those particular techniques but, you
still
> >have to complete the activities they represent.
>
> Thanks, but I don't really need a lesson in OO technology. My point was
that
> OO is tough to do on your own. For example, discovering classes is not a
> simple thing to do. As you know, the three most common approaches to
uncovering
> classes are: 1) brainstorm the classes in some type of facilitated
session.
> 2) extract the nouns from uses cases. 3) hold a CRC session. For an
individual
> option 2 is the only alternative. I will stand by statement that writing
> use cases, coming up with good classes, building models, etc. are really
> team oriented activities.

Discovering requirements, undertaking analysis, creating a design and implem
enting the design as a piece of software are activities that you have to do
regardless of whether you employ OO techniques or not. Depending on the
size/nature of the problem and your knowledge of the problem domain, you may
or may not need a team to complete these activities.

When it comes to solving problems, the old adage "two heads are better than
one" applies to all abstractions equally. There isn't a requirement that you
must have more than one head involved however. Neither does OO force you to
have a team but you might work better in tandem with other people...

> Do you really have to complete the activities they represent?

Yes you do _have_ to complete them. The definition of complete however is
entirely up to you. You would normally make a pragmatic decision as to when
you've done enough. This may be more or less than
<insert-favourite-OO-source> suggests or advocates.

> Well, the so called best minds in software engineering can't seem to agree
> on anything not even what the term software engineer actually entails. By
> pragmatism, I am assuming that what you saying is these people know that
> much of what they write and lecture about is hardly ever put into practice
> (not even by them) in the real world.

They don't have to agree. We are all different and so are the problems we
face. Being pragmatic means - find out what works best for you and the
problem you need to solve then, use it. Of course you shouldn't close
yourself off to new ideas that come along. OO may be just one of those
ideas...

> >OO when used effectively tackles maintanance quite elegantly IMO.
> >Scalability is a design issue that has been tackles very effectively with
> >infrastructural components such as MTS/COM+, MSMQ, HTTP, EJB, JMS, Stored
> >procs etc...
>
> Your statements still don't negate what my soap box speech was trying to
> say.

They weren't meant to negate your speech. Just offer another point of view
(my point of view) on the issues you raised in your soapbox.

Kunle

[Tom Barnaby]

"Jonathan West" <jwest@mvps.org> wrote:

Hi Jonathan:

>The
>diversity should be a positive advantage to Microsoft, in that they then
>have, all sitting on the same platform, a language traditionally used for
>shrinkwarp applications, operating systems and controls (C++), an thoroghly
>modern language for new applications (C#) and a RAD tool able to bring a
>large amount of code onto the .NET platform (VB). That would seem to be
the
>best of all worlds.

Why must the only modern language be based on the hideous syntax of C?

How about a thoroughly modern RAD language for new applications without curly
brackets, case sensitivity, and other "illogical syntax" (per Stroustrup)
inherited from C?

That's where I saw VB.NET heading with Beta1 and it was going to be awesome.
Now, due to the rollbacks, we are getting something in-between. You will
still pay a hefty cost to upgrade, yet Classic VB baggage like bitwise operation
of And/Or will remain and ugly keywords like AndAlso/OrElse will scream "HACK!"
for years to come.


Tom Barnaby
www.intertech-inc.com

[Jonathan West]

"Tom Barnaby" <tbarnaby@intertech-inc.com> wrote in message
news:3af72c51$1@news.devx.com...
>
> "Jonathan West" <jwest@mvps.org> wrote:
>
> Hi Jonathan:
>
> >The
> >diversity should be a positive advantage to Microsoft, in that they then
> >have, all sitting on the same platform, a language traditionally used for
> >shrinkwarp applications, operating systems and controls (C++), an
thoroghly
> >modern language for new applications (C#) and a RAD tool able to bring a
> >large amount of code onto the .NET platform (VB). That would seem to be
> the
> >best of all worlds.
>
> Why must the only modern language be based on the hideous syntax of C?

No reason at all.

>
> How about a thoroughly modern RAD language for new applications without
curly
> brackets, case sensitivity, and other "illogical syntax" (per Stroustrup)
> inherited from C?

Sounds like a good idea. Perhaps you'd like to invent one.

>
> That's where I saw VB.NET heading with Beta1 and it was going to be
awesome.

That's fine, so long as a decision is made that it isn't something that is
expected to be used to upgrade existing applications. In that case, it could
be called "Visual Fred" and a separate VB7 upgrade provided on the.NET
platform. This would be an excellent solution, and is what Rob Bovey was
advocating in his recent VBPJ article. It has just one drawback, that
Microsoft isn't going for it!


> Now, due to the rollbacks, we are getting something in-between. You will
> still pay a hefty cost to upgrade, yet Classic VB baggage like bitwise
operation
> of And/Or will remain and ugly keywords like AndAlso/OrElse will scream
"HACK!"
> for years to come.

Of course it will. Similar hacks will come along with C# versions 2, 3 & 4.
That's pretty much an inevitable consequence of extending a language through
several versions while maintaining backwards compatibility. It can be
minimised (though not eliminated) by careful design of the original language
and sensitivity about the addition of features. That sensitivity isn't
something that VB has greatly benefitted from in upgrades.


--
Regards
Jonathan West

[Jonathan West]

Hi Paul,

"Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
news:3af4ab54$1@news.devx.com...
>
> G'day Jonathan,
>
> >Good
> >programmers are always learning new things, it's what makes them good
> >programmers. Learning them in VB.NET is not so very much different from
> >learning them in VB6 or C++.
>
> I agree with you to an extent. I certainly think that transitioning from
> VB to VB.NET is far easier than from VB to, say, C++. But I also see the
> change from VB to VB.NET as a lot more effort than, say, VB5 to VB6. I
guess
> I may have phrased it badly, but the point that I was attempting to make
> was that this transition will be significantly more expensive than with
any
> previous version of VB. We need to be clear on what we are going to get
back
> from it.

I agree with that.

>
> Also, I don't think it is quite fair to compare to compare a VB
programmer
> learning VB.Net, with learning C++. Most of us have been doing VB for
years
> - why should any new version be such a radical learning curve that it can
> be likened to learning a completely different language? Is it unreasonable
> to expect those years of experience to be directly applicable to any new
> version?

There's two parts to a programmer's experience (particularly a *good*
programmer's experience)

1. Experience at the techniques of problem solving. This is largely
langauge-independent, and allows a programmer to write good code in any
langauge that he is passingly familiar with

2. Experience of the hacks and workarounds of a specific langauge. This will
become obsolete to a lesser or greater extent with every version change. It
happens to be greater with the VB6-VB.NET change than it was with thew
VB5-VB6 change.

Of the two types of experience, I rate #1 as the more important, and is not
much affected by a choice of language.

>
> One last point, I agree that good programmers are always learning new
things
> - much of what I have seen posted seems to be asking "Why do I have to
learn
> a new way to do something I have known how to do for years, and that has
> always worked just fine?"

That's not what I have seen. To my eyes, the complaint has more been "Why is
the language changing such that I have to rewrite my existing code before I
can start adding the benefits of .NET to my existing applications?"

In other words, the complaint is not about having to learn something new, it
is about having to rewrite something that works.

>
> >The compatibility issue is a much bigger one. Not so much for
>programmers
> -
> >they'll get paid to write code whether it is new code or a rewrite.
>
> In many cases, this is true. But what about the self-employed programmer
> who relies on his/her large library of already written/tested/proven code
> to maintain profit margins? What incentive to move to .Net then, when all
> of that trusted code would need to be rewritten/tested/proven?

In such a case, the programmer is his own management, and the management
concerns I described would apply.

>
>
> >The key issue in the move from VB6 to VB.NET is how *much*
incompatibility
> >is caused, and whether it was all strictly necessary.
>
> Personally, I am not as worried about whether it was "strictly necessary",
> as how much advantage it creates. If there was a change made that was not,
> strictly, necessary, but that resulted in some definable advantage for the
> language, I would probably accept that. That is of course purely a
personal
> view though - I can see that many believe differently.

I think we are using different terms to describe essentially the same thing.
I'm using "not strictly necessary" pretty much where you are using "gives no
definable advantage". There are changes which have been made which give no
advantage in terms of making code easier to write or faster to run, and
which in my view ought not to have been made. Changing Integer to 32-bit is
a particular case in point.

>
> >an thoroghly modern language for new applications (C#) and a RAD tool
>able
> to bring a large amount of code onto the .NET >platform (VB). That >would
> seem to be the best of all worlds.
>
> Agreed. However, I certainly don't want VB to be ported only because it
can
> bring a lot of existing code in. I want VB to be able to operate as a
thoroughly
> modern language too.

That can be done, perhaps not to quite the degree of perfection that is
possible in principle with a wholly new language. It is a matter of choosing
to *extend* the language with new features implemented in new keywords and
constructions, as opposed to *changing* the meaning and operation of the
existing ones.


--
Regards
Jonathan West

[Mike Mitchell]

On Tue, 8 May 2001 10:42:35 +0200, "Jonathan West" <jwest@mvps.org>
wrote:

>platform. This would be an excellent solution, and is what Rob Bovey was
>advocating in his recent VBPJ article. It has just one drawback, that
>Microsoft isn't going for it!

Not yet, they're not. But maybe they will....

MM

[Tom Barnaby]

"Jonathan West" <jwest@mvps.org> wrote:
>
>> How about a thoroughly modern RAD language for new applications without
>curly
>> brackets, case sensitivity, and other "illogical syntax" (per Stroustrup)
>> inherited from C?
>
>Sounds like a good idea. Perhaps you'd like to invent one.
>

LOL. Don't need to. Its already invented and called VB.NET Beta 1.

Zane posted before the rollbacks suggesting that if there was a market for
Classic VB in .NET (aka VB7) then someone would create one. The irony of
your suggestion is not lost on me now.

>>
>> That's where I saw VB.NET heading with Beta1 and it was going to be
>awesome.
>
>That's fine, so long as a decision is made that it isn't something that
is
>expected to be used to upgrade existing applications. In that case, it could
>be called "Visual Fred" and a separate VB7 upgrade provided on the.NET
>platform. This would be an excellent solution, and is what Rob Bovey was
>advocating in his recent VBPJ article. It has just one drawback, that
>Microsoft isn't going for it!
>

That is a shame. Many here have advocated that as a solution. And I think
it is the best compromise.

Tom Barnaby
www.intertech-inc.com

[Karl E. Peterson]

Hi Tom --

> Zane posted before the rollbacks suggesting that if there was a market for
> Classic VB in .NET (aka VB7) then someone would create one.

Cute as that sounds, it's very unlikely to happen. Microsoft *firmly* maintains
control over anyone producing a language with enough similarity to VB in order to be
considered interoperable.

Later... Karl
--
http://www.mvps.org/vb

[Kunle Odutola]

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:3af875d5@news.devx.com...
> Hi Tom --
>
> > Zane posted before the rollbacks suggesting that if there was a market
for
> > Classic VB in .NET (aka VB7) then someone would create one.
>
> Cute as that sounds, it's very unlikely to happen. Microsoft *firmly*
maintains
> control over anyone producing a language with enough similarity to VB in
order to be
> considered interoperable.

Microsoft *can't* actually. You can build a VB clone-ish if you so wish as
long as you don't call it VB.
MS has built too many clones itself (i.e. competing products) to be able to
win such a case.

Kunle

Disclaimer: I ain't no lawyer...

[Zane Thomas]

On 8 May 2001 15:38:16 -0700, "Tom Barnaby" <tbarnaby@intertech-inc.com>
wrote:

>Zane posted before the rollbacks suggesting that if there was a market for
>Classic VB in .NET (aka VB7) then someone would create one.

Actually what I proposed was somewhat simpler, something like: Since so
many people here (Hi Dan!) think that dos basic was good enough and is
still good enough, that porting some antique version should be good
enough. It should be easy to port such a thing onto .net - Bill's first
version of basic would be an easy weekend's work for any competent
programmer. And look what it did for him. :-)


---
Ice Z - Straight Outta Redmond

[Jonathan West]

"Tom Barnaby" <tbarnaby@intertech-inc.com> wrote in message
news:3af87558@news.devx.com...
>
> "Jonathan West" <jwest@mvps.org> wrote:
> >
> >> How about a thoroughly modern RAD language for new applications without
> >curly
> >> brackets, case sensitivity, and other "illogical syntax" (per
Stroustrup)
> >> inherited from C?
> >
> >Sounds like a good idea. Perhaps you'd like to invent one.
> >
>
> LOL. Don't need to. Its already invented and called VB.NET Beta 1.
>
> Zane posted before the rollbacks suggesting that if there was a market for
> Classic VB in .NET (aka VB7) then someone would create one. The irony of
> your suggestion is not lost on me now.

Nice to see that you are getting it now :-)


--
Regards
Jonathan West