A moderate view.


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 15 12311 ... LastLast
Results 1 to 15 of 215

Thread: A moderate view.

  1. #1
    Paul Mc Guest

    A moderate view.


    G'day all.

    Just thought that I would put my two cents worth out there - no doubt just
    to cop a hammering ;-)

    Regarding trends in recent discussion - ie with the pro-OO and OO-indifferent
    camps battling it out etc - is the implementation of the added OO capabilities
    in .Net truly the issue?

    If these OO features were implemented into the classic VB environment, I
    am sure the pro-OO camp would be cheering, the OO-indifferent camp would
    shrug, and there would be no real contention.

    Similarly, if the .Net rewrite of VB had taken place somehow without the
    additional OO stuff, some would be pleased, many would
    be displeased, and the situation would be pretty much same as what we have
    now - though I imagine with fewer.Net supporters.

    I think that the OO debate is to some extent obscuring things (of course
    that is not to say you shouldn't debate it -go ahead! - I am just trying
    to get myself clear about what is going on. Probably foolishly, I am doing
    this in public). The core issues as I see them are:

    1) The compatibilty issue - how difficult/possible/expensive will it be to
    move my current codebase up? Can I rely on code to work the same(ie True
    value, And)? Are the features I rely on still available(ie fixed length
    strings)?

    2)The knowledge investment issue. I think we can all say that we have invested
    signifiant time, resources, and effort into developing our skills with VB.
    Is this all wasted? Do I have to start again to move to .Net?

    3)The cost/benefit isue. Given the costs incurred because of the previous
    two points - what is the gain? Will those costs be recouped? How long will
    that take?

    From what I have seen, there is no denying that compatability is a real barrier
    in the sense that codebase upgrading is quite time-consuming, and in many
    cases must be thoroughly retested to be sure that it is still behaving in
    the expected (relied on!) fashion. Also features have been dropped, perhaps
    needlessly, perhaps not and this requires workarounds. Most damagingly of
    all familiar features have been left in but altered - this is the most dangerous
    change of all I think.

    The knowledge investment issue is also a barrier - IMO perhaps more significant
    than compatibility. In classic VB, given a problem to solve I usually have
    an instant glimmering of (one possible way) how to go about solving it -
    I know (to a certain extent) what VB can do, how to get it to do it, and
    what it cannot easily do without API etc (note: I am not making claims to
    be some master of VB - just to know my way around) I would guess that you
    all have some comparable feelings. .Net-wise, I have not had too much trouble
    getting a reasonable handle on most of the stuff that I have come across
    so far - but I am not nearly as competent in .Net as I am in classic VB.


    This all leads to the third issue, which is I think the true crux of the
    matter. Moving to .Net IS going to take time/effort/resources ie money. What
    are we going to get back out of it?

    I guess that this is where the "To OO or .Not to OO" debate comes into the
    picture. OO supporters (like myself) see the aditional OO capabilities as
    a large part of the "payback" of making the move. Those indifferent to OO
    obviously do not recieve this portion of the payback - the move is therefore
    that much less likely to be rewarding for them. (Of course, one could argue
    that there may be some flow-through from other object-designers work, but
    this would probably not swing things much).

    Then there is the web stuff. Personally I think it is great - I can imagine
    a hundred ways to put web services into use, and from what I have seen, ASP.Net
    seems to be fantastic (slightly off topic for VB I know, but many VB programmers
    are doing ASP also...).


    Additionally there is the unguessable payback of the CLF itself. I can of
    course see advantages in this (electric dreams of VB running on linux on
    top of a cross-platform CLR hee hee) - but this is at the moment pretty vague
    to me.


    Personally, as things stand in .Net Beta 1, I have to concede, to a degree,
    the points made by most of the .Net detractors. For many of them, the immediate
    disadvantages do outweigh the concrete advantages of the move. Similarly,
    the pro .Net camp has valid points. For many of them, the move is worth it
    - they see advantages that outweigh the disadvantages.

    So what are we left with? The VB community is fractured neatly, and acrimoniously,
    in half. The .Net detractors have valid points - and the most to fear. It
    looks as if .Net will be here to stay, and classic VB will eventually be
    dropped by MS. How can we (of course it will be MS not us personally doing
    it - but we should at least try and find, and argue for, a better common
    solution ) increase the payback - or decrease the cost - of .Net transition?
    I like, to an extent, one suggestion, the "Option vb6Compatibility". I don't
    know how possible that would be, and it would only adress part of the issue,
    but it is a constructive start.

    What else can we do? I am sure that between us we can find some answers,
    if we can get past the rather pointless sniping.

    Well there's my two cents. Fire away.

    Paul



  2. #2
    Stephen Goguen Guest

    Re: A moderate view.

    Of all the stupid posts, you dare challenge us to take a moderate
    stance on this issue!!! <no need to insert smilie>

    Seriously, nice post... I think a lot of us tried to sum it up like
    your
    post, but got off on a serious tangent.

    I hope your post generates a little discussion from both camps, so
    we can figure out how to address the compatability issues while
    not saccrificing the new design. Maybe we can begin to talk about all
    the other compatibility issues other then True = -1, Short Circuiting, etc,
    *and* how to address them.

    Steve

    > G'day all.
    >
    > Just thought that I would put my two cents worth out there - no doubt just
    > to cop a hammering ;-)
    >
    > Regarding trends in recent discussion - ie with the pro-OO and

    OO-indifferent
    > camps battling it out etc - is the implementation of the added OO

    capabilities
    > in .Net truly the issue?
    >
    > If these OO features were implemented into the classic VB environment, I
    > am sure the pro-OO camp would be cheering, the OO-indifferent camp would
    > shrug, and there would be no real contention.
    >
    > Similarly, if the .Net rewrite of VB had taken place somehow without the
    > additional OO stuff, some would be pleased, many would
    > be displeased, and the situation would be pretty much same as what we have
    > now - though I imagine with fewer.Net supporters.
    >
    > I think that the OO debate is to some extent obscuring things (of course
    > that is not to say you shouldn't debate it -go ahead! - I am just trying
    > to get myself clear about what is going on. Probably foolishly, I am doing
    > this in public). The core issues as I see them are:
    >
    > 1) The compatibilty issue - how difficult/possible/expensive will it be to
    > move my current codebase up? Can I rely on code to work the same(ie True
    > value, And)? Are the features I rely on still available(ie fixed length
    > strings)?
    >
    > 2)The knowledge investment issue. I think we can all say that we have

    invested
    > signifiant time, resources, and effort into developing our skills with VB.
    > Is this all wasted? Do I have to start again to move to .Net?
    >
    > 3)The cost/benefit isue. Given the costs incurred because of the previous
    > two points - what is the gain? Will those costs be recouped? How long will
    > that take?
    >
    > From what I have seen, there is no denying that compatability is a real

    barrier
    > in the sense that codebase upgrading is quite time-consuming, and in many
    > cases must be thoroughly retested to be sure that it is still behaving in
    > the expected (relied on!) fashion. Also features have been dropped,

    perhaps
    > needlessly, perhaps not and this requires workarounds. Most damagingly of
    > all familiar features have been left in but altered - this is the most

    dangerous
    > change of all I think.
    >
    > The knowledge investment issue is also a barrier - IMO perhaps more

    significant
    > than compatibility. In classic VB, given a problem to solve I usually have
    > an instant glimmering of (one possible way) how to go about solving it -
    > I know (to a certain extent) what VB can do, how to get it to do it, and
    > what it cannot easily do without API etc (note: I am not making claims to
    > be some master of VB - just to know my way around) I would guess that you
    > all have some comparable feelings. .Net-wise, I have not had too much

    trouble
    > getting a reasonable handle on most of the stuff that I have come across
    > so far - but I am not nearly as competent in .Net as I am in classic VB.
    >
    >
    > This all leads to the third issue, which is I think the true crux of the
    > matter. Moving to .Net IS going to take time/effort/resources ie money.

    What
    > are we going to get back out of it?
    >
    > I guess that this is where the "To OO or .Not to OO" debate comes into the
    > picture. OO supporters (like myself) see the aditional OO capabilities as
    > a large part of the "payback" of making the move. Those indifferent to OO
    > obviously do not recieve this portion of the payback - the move is

    therefore
    > that much less likely to be rewarding for them. (Of course, one could

    argue
    > that there may be some flow-through from other object-designers work, but
    > this would probably not swing things much).
    >
    > Then there is the web stuff. Personally I think it is great - I can

    imagine
    > a hundred ways to put web services into use, and from what I have seen,

    ASP.Net
    > seems to be fantastic (slightly off topic for VB I know, but many VB

    programmers
    > are doing ASP also...).
    >
    >
    > Additionally there is the unguessable payback of the CLF itself. I can of
    > course see advantages in this (electric dreams of VB running on linux on
    > top of a cross-platform CLR hee hee) - but this is at the moment pretty

    vague
    > to me.
    >
    >
    > Personally, as things stand in .Net Beta 1, I have to concede, to a

    degree,
    > the points made by most of the .Net detractors. For many of them, the

    immediate
    > disadvantages do outweigh the concrete advantages of the move. Similarly,
    > the pro .Net camp has valid points. For many of them, the move is worth it
    > - they see advantages that outweigh the disadvantages.
    >
    > So what are we left with? The VB community is fractured neatly, and

    acrimoniously,
    > in half. The .Net detractors have valid points - and the most to fear. It
    > looks as if .Net will be here to stay, and classic VB will eventually be
    > dropped by MS. How can we (of course it will be MS not us personally doing
    > it - but we should at least try and find, and argue for, a better common
    > solution ) increase the payback - or decrease the cost - of .Net

    transition?
    > I like, to an extent, one suggestion, the "Option vb6Compatibility". I

    don't
    > know how possible that would be, and it would only adress part of the

    issue,
    > but it is a constructive start.
    >
    > What else can we do? I am sure that between us we can find some answers,
    > if we can get past the rather pointless sniping.
    >
    > Well there's my two cents. Fire away.
    >
    > Paul
    >
    >




  3. #3
    Patrick Steele Guest

    Re: A moderate view.

    In article <3af2bbae$1@news.devx.com> (from Stephen Goguen
    <sgoguen@nospam.hormel.goeinc.com>),
    > Maybe we can begin to talk about all
    > the other compatibility issues other then True = -1, Short Circuiting, etc,
    > *and* how to address them.


    Don't you mean "AndAlso how to address them"...



    --
    Patrick Steele
    (psteele@ipdsolution.com)
    Lead Software Architect
    Image Process Design

  4. #4
    Jonathan West Guest

    Re: A moderate view.

    Hi Paul,

    I don't regard the "knowledge investment" issue as such a great one. 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++.

    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. It is
    rather an issue for companies faced with the prospect effectively of having
    to pay their programmers to write the same application again before they can
    proceed with further enhancement. This is a real cost to companies and might
    well be a reason for some of them to avoid an upgrade of their existing apps
    to .NET, and move elsewhere.

    It has been generally accepted in the VB world that upgrading the language
    will usually throw up some incompatibilities. Why this should be accepted is
    beyond me, since other languages such as C++ have largely avoided this.

    The key issue in the move from VB6 to VB.NET is how *much* incompatibility
    is caused, and whether it was all strictly necessary. Given that Microsoft
    is taking the opportunity with .NET to invent a whole new language C#, which
    they can make as modern as they like and completely free of the oddities
    necessary to maintain compatibility with old code, it seems that extreme
    attempts ought to be made to maintain backwards compatibility for the
    existing languages that will be on the .NET platform. With C++, they have
    done this. (I have heard that one of Microsoft's tests of their .NET C++
    compiler is whether it will successfully compile the code of Microsoft Word
    to IL.) As things stand, Microsoft hasn't taken the same care of VB, and
    this is why there has been so much screaming and shouting.

    The three rollbacks so far announced show that some features introduced into
    VB.NET beta 1 were not necessary either for compatibility with the platform
    or for interoperability with other languages. Much more could be done to
    improve compatibility without adversely affecting interop at all. 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.

    --
    Regards
    Jonathan West

    "Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
    news:3af1fb7a$1@news.devx.com...
    >
    > G'day all.
    >
    > Just thought that I would put my two cents worth out there - no doubt just
    > to cop a hammering ;-)
    >
    > Regarding trends in recent discussion - ie with the pro-OO and

    OO-indifferent
    > camps battling it out etc - is the implementation of the added OO

    capabilities
    > in .Net truly the issue?
    >
    > If these OO features were implemented into the classic VB environment, I
    > am sure the pro-OO camp would be cheering, the OO-indifferent camp would
    > shrug, and there would be no real contention.
    >
    > Similarly, if the .Net rewrite of VB had taken place somehow without the
    > additional OO stuff, some would be pleased, many would
    > be displeased, and the situation would be pretty much same as what we have
    > now - though I imagine with fewer.Net supporters.
    >
    > I think that the OO debate is to some extent obscuring things (of course
    > that is not to say you shouldn't debate it -go ahead! - I am just trying
    > to get myself clear about what is going on. Probably foolishly, I am doing
    > this in public). The core issues as I see them are:
    >
    > 1) The compatibilty issue - how difficult/possible/expensive will it be to
    > move my current codebase up? Can I rely on code to work the same(ie True
    > value, And)? Are the features I rely on still available(ie fixed length
    > strings)?
    >
    > 2)The knowledge investment issue. I think we can all say that we have

    invested
    > signifiant time, resources, and effort into developing our skills with VB.
    > Is this all wasted? Do I have to start again to move to .Net?
    >
    > 3)The cost/benefit isue. Given the costs incurred because of the previous
    > two points - what is the gain? Will those costs be recouped? How long will
    > that take?
    >
    > From what I have seen, there is no denying that compatability is a real

    barrier
    > in the sense that codebase upgrading is quite time-consuming, and in many
    > cases must be thoroughly retested to be sure that it is still behaving in
    > the expected (relied on!) fashion. Also features have been dropped,

    perhaps
    > needlessly, perhaps not and this requires workarounds. Most damagingly of
    > all familiar features have been left in but altered - this is the most

    dangerous
    > change of all I think.
    >
    > The knowledge investment issue is also a barrier - IMO perhaps more

    significant
    > than compatibility. In classic VB, given a problem to solve I usually have
    > an instant glimmering of (one possible way) how to go about solving it -
    > I know (to a certain extent) what VB can do, how to get it to do it, and
    > what it cannot easily do without API etc (note: I am not making claims to
    > be some master of VB - just to know my way around) I would guess that you
    > all have some comparable feelings. .Net-wise, I have not had too much

    trouble
    > getting a reasonable handle on most of the stuff that I have come across
    > so far - but I am not nearly as competent in .Net as I am in classic VB.
    >
    >
    > This all leads to the third issue, which is I think the true crux of the
    > matter. Moving to .Net IS going to take time/effort/resources ie money.

    What
    > are we going to get back out of it?
    >
    > I guess that this is where the "To OO or .Not to OO" debate comes into the
    > picture. OO supporters (like myself) see the aditional OO capabilities as
    > a large part of the "payback" of making the move. Those indifferent to OO
    > obviously do not recieve this portion of the payback - the move is

    therefore
    > that much less likely to be rewarding for them. (Of course, one could

    argue
    > that there may be some flow-through from other object-designers work, but
    > this would probably not swing things much).
    >
    > Then there is the web stuff. Personally I think it is great - I can

    imagine
    > a hundred ways to put web services into use, and from what I have seen,

    ASP.Net
    > seems to be fantastic (slightly off topic for VB I know, but many VB

    programmers
    > are doing ASP also...).
    >
    >
    > Additionally there is the unguessable payback of the CLF itself. I can of
    > course see advantages in this (electric dreams of VB running on linux on
    > top of a cross-platform CLR hee hee) - but this is at the moment pretty

    vague
    > to me.
    >
    >
    > Personally, as things stand in .Net Beta 1, I have to concede, to a

    degree,
    > the points made by most of the .Net detractors. For many of them, the

    immediate
    > disadvantages do outweigh the concrete advantages of the move. Similarly,
    > the pro .Net camp has valid points. For many of them, the move is worth it
    > - they see advantages that outweigh the disadvantages.
    >
    > So what are we left with? The VB community is fractured neatly, and

    acrimoniously,
    > in half. The .Net detractors have valid points - and the most to fear. It
    > looks as if .Net will be here to stay, and classic VB will eventually be
    > dropped by MS. How can we (of course it will be MS not us personally doing
    > it - but we should at least try and find, and argue for, a better common
    > solution ) increase the payback - or decrease the cost - of .Net

    transition?
    > I like, to an extent, one suggestion, the "Option vb6Compatibility". I

    don't
    > know how possible that would be, and it would only adress part of the

    issue,
    > but it is a constructive start.
    >
    > What else can we do? I am sure that between us we can find some answers,
    > if we can get past the rather pointless sniping.
    >
    > Well there's my two cents. Fire away.
    >
    > Paul
    >
    >



  5. #5
    Paul Mc Guest

    Re: A moderate view.


    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.

    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?

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

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


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

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

    Paul.


  6. #6
    T. Hoskins Guest

    Re: A moderate view.


    Paul, I really enjoyed reading your post.

    Although it is debateable how successful or better OO software development
    projects really are, the fact is that they are being done anyways. I really
    don't think that there are a lot of .NET detractors out there. 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.

    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.

    Personally, I find OO development techniques to be very elegant and sexy.
    However, I am not sure if most companies and their employees are really prepared
    to use what it has to offer. To me the introduction of the .NET platform
    as the only Microsoft development platform brings up a lot of issues (such
    as cost) that go way beyond the syntax of a particular programming language.

    I think what OO development and the .NET platform has to offer is a great
    thing for the industry and if all I had to do was write source code all day
    long I probably wouldn't be complaining. I can live with the possibility
    of having to abandon a large library of already written/tested/proven code.
    What I can't live with is the posibility that the OO way of doing things
    might well be my only choice. Don't get me wrong, I think that for medium-to-large
    sized software projects, that OO development is the way to go. However, I
    also think that many of the things that are associated with OO development
    are just too difficult or impractical to do on a small software project.
    Writing use cases, coming up with good classes, building models, etc. are
    really team oriented activities that require a lot of brainstorming.

    Personally, I think that hybrid languages such as C++ and VB as well as RAD
    development techniques will have a place in the software development community
    for a long time to come. Many VB developers currently don't work on team
    application development projects and fewer still will ever have the opportunity
    to do any type of enterprise-level development.

    [Unrelated soap box speech] If somehow emphasis on reducing the amount of
    time and cost it takes to develop software could be shifted more towards
    software quality issues such as maintenance and scalability (the two most
    costly issues for almost any organization) as well as to extensive employee
    training -- then perhaps many of the major problems facing this industry
    would eventually get better.

  7. #7
    Jonathan West Guest

    Re: A moderate view.

    Hi Paul,

    "Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
    news:3af4ab54$1@news.devx.com...
    >
    >
    > 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?"


    I think this is part of the point I was making about "necessary change".
    There is much necessary change in the move from basing VB on COM to basing
    it on .NET. As a result, some different ways of thinking ore going to be
    needed, and some old workarounds will either cease to be effective or cease
    to be relevant. Fine by me. No doubt new problems will be discovered for
    which new workarounds will get invented. Also no problem. All part of the
    learning experience.

    The difficulty with what you have said is more psychological. The complaint
    is being spoken from the point of view of "necessary change" and the issue
    of code migration, but it is getting misinterpreted (deliberately or not) as
    an unwillingness to attempt to learn new things.

    >
    > >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 this case, the programmer is his own management, and the management
    concerns I described apply to such a person. I can see it causing hardship
    to some independents as the value of the VB6 source depreciates.

    >
    >
    > >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'll accept your formulation of the phrase. Changing the Integer and Long
    definitions offers no functional advantage, and reduces the opportunity for
    code snippets to be pasted into VB.NET projects. By your formulation, the
    change creates no advantage. by mine its not necessary. I think we are using
    different forms of words to describe much the same concept.

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


    Well, yes and no. Once a language goes beyond version 1, it can never regain
    its purity and elegance of design, just as most houses never look very
    elegant once an extension has been built. You are always having to adapt and
    in some ways limit the new in order to maintain compatibility with the old.
    If you have an existing language into which people have made large
    investments of knowledge and source code, then there is always some degree
    of concern about bringing the old code and knowledge with you. It is only if
    you are creating a wholly new language that this consideration does not
    apply.

    With VB.NET, there is a difference of opinion in the industry as to whether,
    in beta 1, it is different enough to be considered to be a wholly new
    language. Beyond that, there is a further debate as to whether the language
    *ought* to be designed on the basis that it is a wholly new language. I have
    heard viewpoints expressed on all sides of that argument. For what its
    worth, my own view is that it ought not to be designed as if it is a new
    language, (C# can fill that role) and therefore the rollbacks announced by
    Microsoft are a small step in the right direction, but very many issues
    still remain to be fixed in order to tackle the changes that confer no
    advantage or inadequate advantage (unnecessary changes).


    --
    Regards
    Jonathan West


  8. #8
    Kunle Odutola Guest

    Re: A moderate view.


    "Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
    news:3af4ab54$1@news.devx.com...
    >
    > 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?


    I think it is quite fair to compare VB->VB.NET to VB->Any-other-language
    because ultimately, that is what we all did (or should have done) implicitly
    before deciding to follow whatever subset of the
    VB1->VB2->VB3->VB4->VB5->VB6 chain that applies. In this respect, VB.NET is
    no different as it still presents the natural upgrade to VB developers on
    the basis that converting to anything else is a much, more costly exercise
    and the returns may not be any more significant than VB.NET can offer.
    For those who offer RealBasic, TrueBasic etc as a better upgrade, remember
    that VB6 still exists and for the time being at least is still a better
    product than either (except on the cross-platform issue). That is why you
    chose VB6 over them previously isn't it?

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


    If you decide to go forward with MS, you have to learn about the .NET
    development and runtime platform. A new way of doing what you have done for
    years...

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


    She would have had to rewrite and retest them all for the VB3->VB4-32
    transition. This situation is no different.

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


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

    Kunle





  9. #9
    Kunle Odutola Guest

    Re: A moderate view.


    "T. Hoskins" <thoskins@hotmail.com> wrote in message
    news:3af5090d$1@news.devx.com...
    >
    > Paul, I really enjoyed reading your post.
    >
    > Although it is debateable how successful or better OO software development
    > projects really are, the fact is that they are being done anyways. I

    really
    > don't think that there are a lot of .NET detractors out there. 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 wouldn't use the success of OO projects as a yardstick to measure the
    utility/usefulness/ROI of the OO paradigm. 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.

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


    The is *no* silver bullet. All these comments apply equally to all other
    problem solving abstractions.

    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
    language is the same through all the phases of development. Only the level
    of detail changes.

    As for small projects, the size of a project is not a reliable indicator of
    the likely returns of employing OO techniques and technology to the project.
    The life time of the project and the possibility of reuse between this
    project and previous or subsequent projects is a better one. If for a small
    project you can build 70% (even 40%) of it entirely through reuse of
    existing source code, frameworks or components, would OO still be overkill?.

    > Personally, I find OO development techniques to be very elegant and sexy.
    > However, I am not sure if most companies and their employees are really

    prepared
    > to use what it has to offer. To me the introduction of the .NET platform
    > as the only Microsoft development platform brings up a lot of issues (such
    > as cost) that go way beyond the syntax of a particular programming

    language.

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

    > I think what OO development and the .NET platform has to offer is a great
    > thing for the industry and if all I had to do was write source code all

    day
    > long I probably wouldn't be complaining. I can live with the possibility
    > of having to abandon a large library of already written/tested/proven

    code.

    Not abandon. Refactor. You refactor the code into hopefully more reusable OO
    entities. Or you just invent an OO abstraction for reusing the non-OO code
    as it exists. You decide.

    > What I can't live with is the posibility that the OO way of doing things
    > might well be my only choice. Don't get me wrong, I think that for

    medium-to-large
    > sized software projects, that OO development is the way to go. However, I
    > also think that many of the things that are associated with OO development
    > are just too difficult or impractical to do on a small software project.
    > Writing use cases, coming up with good classes, building models, etc. are
    > really team oriented activities that require a lot of brainstorming.


    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.

    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.

    > [Unrelated soap box speech] If somehow emphasis on reducing the amount of
    > time and cost it takes to develop software could be shifted more towards
    > software quality issues such as maintenance and scalability (the two most
    > costly issues for almost any organization) as well as to extensive

    employee
    > training -- then perhaps many of the major problems facing this industry
    > would eventually get better.


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

    Kunle




  10. #10
    Mike Mitchell Guest

    Re: A moderate view.

    On Sat, 5 May 2001 16:26:42 +0100, "Jonathan West" <jwest@mvps.org>
    wrote:

    >I don't regard the "knowledge investment" issue as such a great one. Good
    >programmers are always learning new things, it's what makes them good
    >programmers.


    But the "always learning new things" part needs clarification. Yes, I
    learn new things in order to build upon what I already know about a
    subject, in order to broaden my experience of, and with, that subject,
    and in order to become a better and more productive exponent of it.
    There is no benefit to the subject matter I am dealing with if I learn
    new things unconnected with the subject. So, for example, if I am a
    programmer in language X, then learning more about the many facets of
    that language and how it interacts with the OS and how I might exploit
    all of its more arcane features, then I am making better use of what I
    already knew about X and thus the time spent on learning has huge
    benefits to me (it makes me more of an exponent), my employer (I
    produce greater productivity, enhanced product satisfaction, and
    increased profits), and my users (who experience a well-rounded
    product they can rely on to deliver what they expect, and more).

    However, by learning a completely different language, such as Y, I am
    diluting my experience and making it less useful, since my time is now
    spent between X and Y (assuming I am not giving up X for ever). Also,
    I am not bringing the knowledge won with X to learning Y, since Y is
    so different, I have to learn from scratch and attempting to re-use
    knowledge gained from X is actually more of a hindrance than a help,
    as it creates confusion which acts as a barrier to learning the other
    language.

    > Learning them in VB.NET is not so very much different from
    >learning them in VB6 or C++.
    >
    >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.


    You imply that programmers, like ladies (and men) of the night, only
    do it for the money. Yes, they get paid to write code, but real
    programmers are the ones who would write programs even if they didn't
    get paid, e.g. the free software movement. True programmers are those
    who are fascinated by computers and the way that they may be
    manipulated through a bunch of ones and zeroes. The money is an
    additional benefit of doing a very satisfying job. The 'programer' who
    is only doing it for the money is going to be an absolutely lousy
    programmer. Programming is akin to a calling, such as the kind of
    impetus that fires up the budding cleric or doctor.

    MM

  11. #11
    Mike Mitchell Guest

    Re: A moderate view.

    On 5 May 2001 18:39:32 -0700, "Paul Mc" <paulmc@nospam.thehub.com.au>
    wrote:

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


    Yes, no one can buy experience. I can go to the store and buy a carton
    of milk. This avoids my having to raise and nurture a cow, find a plot
    to put it on, and learn how to pull those teats. But in the case of a
    programming language (or a real language) there is no alternative but
    to obtain the plot, acquire a cow, and start squeezing. Experience is
    very costly to acquire, both in terms of the financial outlay and the
    amount of personal commitment it embodies. The .NET zealots will, I
    suppose, just write off all of this experience and the huge knowledge
    base it has wrought, like so much water under the bridge.

    MM

  12. #12
    Kunle Odutola Guest

    Re: A moderate view.


    "Mike Mitchell" <kylix_is@hotmail.com> wrote in message
    news:3af55cdf.2021920@news.devx.com...
    > On 5 May 2001 18:39:32 -0700, "Paul Mc" <paulmc@nospam.thehub.com.au>
    > wrote:


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

    >
    > Yes, no one can buy experience. I can go to the store and buy a carton
    > of milk. This avoids my having to raise and nurture a cow, find a plot
    > to put it on, and learn how to pull those teats. But in the case of a
    > programming language (or a real language) there is no alternative but
    > to obtain the plot, acquire a cow, and start squeezing.


    Not true. When you use the MsFlexGrid and myriad other controls in VB for
    instance, your are just buying the carton in a drugstore not any of the
    other stuff to do with animal farms in your analogy.

    In fact because you don't have to develop the hardware, OS, development
    tools and a zillion other things that you use as a developer, I'd say you
    were much better off than the guy with the carton of milk. And yes, since
    you already know it, the development many of these products was much easier
    because of the application of OO technology. In some case, the products only
    exist because of OO technology (the cost-to-build/benefit-from-product ratio
    thing).

    > Experience is
    > very costly to acquire, both in terms of the financial outlay and the
    > amount of personal commitment it embodies. The .NET zealots will, I
    > suppose, just write off all of this experience and the huge knowledge
    > base it has wrought, like so much water under the bridge.


    Yes, _some_ experience is costly to acquire. The comments about segments of
    ..NET adoptees doesn't deserve an answer frankly...

    Kunle




  13. #13
    Kunle Odutola Guest

    Re: A moderate view.


    "Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
    news:3af1fb7a$1@news.devx.com...
    >
    > G'day all.
    >
    > Just thought that I would put my two cents worth out there - no doubt just
    > to cop a hammering ;-)
    >
    > Regarding trends in recent discussion - ie with the pro-OO and

    OO-indifferent
    > camps battling it out etc - is the implementation of the added OO

    capabilities
    > in .Net truly the issue?


    This is but one of the many issues that different people have with the .NET
    experience. Note that by issue, I do not imply that is it a problem or even
    a negative thing, just that it is a feature that people have an [strong]
    opinion of.

    > If these OO features were implemented into the classic VB environment, I
    > am sure the pro-OO camp would be cheering, the OO-indifferent camp would
    > shrug, and there would be no real contention.


    VB was already an OO language. It's most glaring OO omission was white-box
    inheritance. All VB users already used it's OO features (perhaps incorrectly
    in some cases).

    > Similarly, if the .Net rewrite of VB had taken place somehow without the
    > additional OO stuff, some would be pleased, many would
    > be displeased, and the situation would be pretty much same as what we have
    > now - though I imagine with fewer.Net supporters.


    Many people for whom full OO support was a requirement would have found
    solace in C#. It wouldn't affect .NET adoption I believe, just VB.NET
    adoption.

    > I think that the OO debate is to some extent obscuring things (of course
    > that is not to say you shouldn't debate it -go ahead! - I am just trying
    > to get myself clear about what is going on. Probably foolishly, I am doing
    > this in public). The core issues as I see them are:
    >
    > 1) The compatibilty issue - how difficult/possible/expensive will it be to
    > move my current codebase up? Can I rely on code to work the same(ie True
    > value, And)? Are the features I rely on still available(ie fixed length
    > strings)?


    It is prudent to remember that there is no requirement to move current
    codebases. For the next release of VB, MS has effectively scrapped VB and
    re-written a new virtualized development platform that most agree is a good
    thing. It would be churlish to expect that with such a a redical re-write of
    the underlying development platform, everything will just work the same.
    Compare this to the VB3->VB4 upgrade and you'll see what I mean.

    Of course everyone agrees MS hasn't done the best job possible (or more to
    the point MS hasn't done it the way each individual would have done it)
    because of the myriad changes that there has been to the syntax and
    semantics of VB in VB.NET. I agree that some things are not what I expected
    but VB.NET is still definitely an evolution of VB and not a new language.

    >
    > 2)The knowledge investment issue. I think we can all say that we have

    invested
    > signifiant time, resources, and effort into developing our skills with VB.
    > Is this all wasted? Do I have to start again to move to .Net?


    No. VB.NET is recognisably an evolution of VB. There are new things to learn
    and old things to unlearn just like there as always been.
    You will have to learn about a new platform (and it's API) though. That is
    the price to be payed for access to .NET benefits.

    > 3)The cost/benefit isue. Given the costs incurred because of the previous
    > two points - what is the gain? Will those costs be recouped? How long will
    > that take?


    The gain?. Better productivity. Ability to write once and run on all Windows
    platforms (and possibly other platforms in future though I won't bet on
    this). Freedom to employ the language that offers the best problem solving
    abstraction rather than just the ones that I can integrate easily with VB.
    This is more the case for languages like Mercury, Haskell, ML, Scheme, Lisp,
    Prolog etc.

    Is it [likely to be] worth it?. Yes. I only answer for myself.

    > The knowledge investment issue is also a barrier - IMO perhaps more

    significant
    > than compatibility. In classic VB, given a problem to solve I usually have
    > an instant glimmering of (one possible way) how to go about solving it -
    > I know (to a certain extent) what VB can do, how to get it to do it, and
    > what it cannot easily do without API etc (note: I am not making claims to
    > be some master of VB - just to know my way around) I would guess that you
    > all have some comparable feelings. .Net-wise, I have not had too much

    trouble
    > getting a reasonable handle on most of the stuff that I have come across
    > so far - but I am not nearly as competent in .Net as I am in classic VB.


    Give yourself a chance, .NET has not even been formally released yet. Your
    mastery of the language and the platform will return in time as you become
    more familiar with .NET and VB.NET.

    > This all leads to the third issue, which is I think the true crux of the
    > matter. Moving to .Net IS going to take time/effort/resources ie money.

    What
    > are we going to get back out of it?


    See _my_ answer to Q3 above.

    > I guess that this is where the "To OO or .Not to OO" debate comes into the
    > picture. OO supporters (like myself) see the aditional OO capabilities as
    > a large part of the "payback" of making the move. Those indifferent to OO
    > obviously do not recieve this portion of the payback - the move is

    therefore
    > that much less likely to be rewarding for them. (Of course, one could

    argue
    > that there may be some flow-through from other object-designers work, but
    > this would probably not swing things much).


    All the MS languages on .NET were OO before they moved to the platform. VB
    was not a full OO language and that has now been fixed. That is a part of
    the payback but the addition of drop-dead gorgeous support for threading,
    COM+ object pooling, prevasive support for attribute-based development and
    deployment, full and easy access to the underlying platform, full parity
    with other .NET languages and the possibility of OS independence etc. are
    other paybacks. Note that much of these have nothing to do with OO per se

    > Then there is the web stuff. Personally I think it is great - I can

    imagine
    > a hundred ways to put web services into use, and from what I have seen,

    ASP.Net
    > seems to be fantastic (slightly off topic for VB I know, but many VB

    programmers
    > are doing ASP also...).


    ASP.NET and WebForms is the real crown in the "web stuff" as far as .NET is
    concerned for me. Web Services are just another nead idea in the toolbox
    HailStorm notwithstanding.

    > So what are we left with? The VB community is fractured neatly, and

    acrimoniously,
    > in half. The .Net detractors have valid points - and the most to fear. It
    > looks as if .Net will be here to stay, and classic VB will eventually be
    > dropped by MS. How can we (of course it will be MS not us personally doing
    > it - but we should at least try and find, and argue for, a better common
    > solution ) increase the payback - or decrease the cost - of .Net

    transition?
    > I like, to an extent, one suggestion, the "Option vb6Compatibility". I

    don't
    > know how possible that would be, and it would only adress part of the

    issue,
    > but it is a constructive start.


    I see we share a fondness for the idea of a VB.NET that can fully emulate
    VB6 syntax and semantics on demand. It is a nice idea, but realistically it
    ain't gonna happen. In that environment, I prefer a radical VB.NET because I
    always have my copy of VB6 for exisitng stuff.

    Kunle
    VB: To infinity or the dump...




  14. #14
    Mike Mitchell Guest

    Re: A moderate view.

    On Sun, 6 May 2001 16:31:27 +0100, "Kunle Odutola"
    <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:

    >> Yes, no one can buy experience. I can go to the store and buy a carton
    >> of milk. This avoids my having to raise and nurture a cow, find a plot
    >> to put it on, and learn how to pull those teats. But in the case of a
    >> programming language (or a real language) there is no alternative but
    >> to obtain the plot, acquire a cow, and start squeezing.

    >
    >Not true. When you use the MsFlexGrid and myriad other controls in VB for
    >instance, your are just buying the carton in a drugstore not any of the
    >other stuff to do with animal farms in your analogy.


    Yes, it is true. I wasn't talking about using MsFlexGrid, but learning
    a computer language. I wouldn't be able to use MsFlexGrid in any
    language until I had learned the language, as I would have no concept
    of the product and would not know how to hook it into my code, since
    there wouldn't be any code to hook it into.

    That said, I remind everyone how beneficial the use of these cartons
    of milk are. Plonk one on a form, fill in a few properties, put in a
    line or two in an event handler, and the app is done. If this is OOP,
    well, I just LOVE it to bits! How EASY it is to do that with classic
    VB.

    MM

  15. #15
    Kunle Odutola Guest

    Re: A moderate view.


    "Mike Mitchell" <kylix_is@hotmail.com> wrote in message
    news:3af59b77.18047718@news.devx.com...
    > On Sun, 6 May 2001 16:31:27 +0100, "Kunle Odutola"
    > <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:
    >
    > >> Yes, no one can buy experience. I can go to the store and buy a carton
    > >> of milk. This avoids my having to raise and nurture a cow, find a plot
    > >> to put it on, and learn how to pull those teats. But in the case of a
    > >> programming language (or a real language) there is no alternative but
    > >> to obtain the plot, acquire a cow, and start squeezing.

    > >
    > >Not true. When you use the MsFlexGrid and myriad other controls in VB for
    > >instance, your are just buying the carton in a drugstore not any of the
    > >other stuff to do with animal farms in your analogy.

    >
    > Yes, it is true. I wasn't talking about using MsFlexGrid, but learning
    > a computer language. I wouldn't be able to use MsFlexGrid in any
    > language until I had learned the language, as I would have no concept
    > of the product and would not know how to hook it into my code, since
    > there wouldn't be any code to hook it into.


    You need to learn a whole language to be able to use components like
    FlexGrid?
    Ahhh!. I can see the real problem now...

    Kunle



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center