A moderate view. - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 15 FirstFirst 123412 ... LastLast
Results 16 to 30 of 215

Thread: A moderate view.

  1. #16
    Paul Mc Guest

    Re: A moderate view.


    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



  2. #17
    Kunle Odutola Guest

    Re: A moderate view.

    > 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



  3. #18
    Paul Mc Guest

    Re: A moderate view.


    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

  4. #19
    T. Hoskins Guest

    Re: A moderate view.


    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.

  5. #20
    Bobby Newmark Guest

    Re: A moderate view.


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





  6. #21
    Kunle Odutola Guest

    Re: A moderate view.


    "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




  7. #22
    Tom Barnaby Guest

    Re: A moderate view.


    "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

  8. #23
    Jonathan West Guest

    Re: A moderate view.


    "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


  9. #24
    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...
    >
    > 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


  10. #25
    Mike Mitchell Guest

    Re: A moderate view.

    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

  11. #26
    Tom Barnaby Guest

    Re: A moderate view.


    "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

  12. #27
    Karl E. Peterson Guest

    Re: A moderate view.

    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



  13. #28
    Kunle Odutola Guest

    Re: A moderate view.


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



  14. #29
    Zane Thomas Guest

    Re: A moderate view.

    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

  15. #30
    Jonathan West Guest

    Re: A moderate view.


    "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


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