DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 5 of 18 FirstFirst ... 3456715 ... LastLast
Results 61 to 75 of 261

Thread: Another Language

  1. #61
    Kunle Odutola Guest

    Re: Another Language

    > Perhaps my perspective is skewed, but I view the .NET initiative as a step
    > in the progression from "desktop applications" to "software as a service"
    > provided [mostly | only ] by the big guys via the Internet.


    This is the result of MS's [intentionally] skewed marketing of .NET to date.
    There is nothing inherently "web-servicey" about .NET although it makes
    creating such systems much easier than anything that came before and since.
    The .NET platform currently has one outstanding issue IMO with stand-alone
    application development - code security. It is all too easy to decompile the
    intermediate MSIL language into original source code on the platform. I
    eagerly await code obsfucators or whatever mechanism MS has for dealing with
    this issue...

    > Someone said, you should move to VB.NET if you "believe in .NET" -- that
    > sounds suspiciously as if some have adopted it as a religion, just as some
    > seem to have adopted "Object Oriented" as a religion. Perhaps that is why
    > it is so rare to see a response such as yours that deals with the issues.


    I would be that someone and I stand by the statement. .NET isn't a religion.
    It is MS's new virtualized development and runtime platform. The .NET
    platform and it's framework libraries form the the basis of the capabilities
    exposed by all the languages that exist on top of it. If you don't believe
    that the platform would succeed, you may not want to invest scarce resources
    in learning to use any of the development tools that are tied to the
    platform - including VB.NET.

    OO isn't a religion either. It is an approach to thinking about, designing,
    implementing and testing software systems that has been used succcessfully
    in the mainstream for over a decade now. For many, many problems (especially
    complex problems), OO is your friend but for trivial one-off systems, you
    may or may not get as much milegae out of OO.

    Kunle




  2. #62
    Karl E. Peterson Guest

    Re: Another Language

    Hi Rob --

    > >Certainly not, but the emphasis on making this a new object-oriented language
    > >to suit the Object-Obsessed, with no regard to compatibility has certainly
    > >killed "VB as we have known it".

    >
    > Yep, there are compatibility issues. But I think that most people are afraid
    > of things they preceive can't be done in .NET.


    What brought you to that conclusion?

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





  3. #63
    Larry Linson Guest

    Re: Another Language


    "Kunle Odutola" <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:

    > . . . I would be that someone and I stand by the statement. .NET
    > isn't a religion. . . .
    > OO isn't a religion either . . .


    I agree entirely, and I didn't say either _is_ a religion. I said that some
    have adopted each as a religion -- there's a significant difference.
    "Religious fervor" is understandable, although some might say not necessarily
    desirable, about someone's actual religion; it indicates poor judugement
    when "religious fervor" replaces technical discussion about technical matters.
    I remember the "religious wars" over computer languages in the late 1950s
    and early 1960s -- they made enemies whose enmity lasted longer than the
    languages they had championed, many of which are now only footnotes to computer
    history.

    > implementing and testing software systems that has been used
    > succcessfully in the mainstream for over a decade now.


    I agree. I also point out that I can say the same thing for procedural programming,
    but I can multiply the "over a decade" to "half a century". And, although
    I have no "hard facts", I seriously doubt that there is a significant difference
    in the success and failure rates of the projects using the two approaches.
    I am unaware of significant studies proving so, as there have been about
    other aspects of the development process.

    > For many, many problems (especially complex problems), OO is your
    > friend but for trivial one-off systems, you may or may not get as
    > much milegae out of OO.


    I agree that OO can be helpful, particularly in complex, code-intensive environments,
    but you have again fallen into the mode of denigrating and trivializing the
    "opposition".

    There are many non-trivial applications that need none of "their own" OO,
    as opposed to using the objects provided by the tools (native, as VB, or
    custom controls or libraries) -- and I've said, over and over, that I am
    perfectly happy to use those. I've even written a few classes, to learn the
    process, and for some (unusual for my applications) code-intensive areas
    in applications. But, just because my applications are not brim-full of,
    and bullging at the seams, with my own classes and objects does not mean
    they are non-trivial.

    The software involved in getting men to the moon, was certainly "one-off"
    (if by "one-off", you mean "unique"), but it was decidedly non-trivial, and,
    none of it that I observed (which was more than a little) was OO. The software
    that held Soviet manned bombers at bay from the US and Canada for many years
    starting in the 1950s, while less complex, was decidedly non-trivial and
    none of it was OO, though some if it was "modular" (and "modular programming
    was the predecessor of OO, at least in a sense). I strongly suspect you could
    say the same of the Soviet software that 'held US and Canadian manned bombers
    at bay' during that same period, and, well, it's open to discussion whether
    either country's leadership was at any point near enough insanity to actually
    have launched such an attack, but the point is, that the software was non-OO
    and non-trivial. There are plenty of other examples. And, I'll agree that
    there are plenty of examples of successful, complex applications created
    with the OO approach, as well.

    My point is that neither "side" in this argument is in a position to make
    a valid claim "my way or the highway" or "if you don't do it my way, it doesn't
    compute". Except, of course, the .NET developers and the .NET language developers,
    aka The Boys and Girls in Redmond. Only time, I think, will tell whether
    they have built a mighty rocket that will catapult them to new heights of
    greatness or whether they have shot themselves in the foot or more tender
    places. I'm not rushing to sell my Microsoft stock, but I'm not straining
    my broker's capacity ordering more, either!

  4. #64
    Kunle Odutola Guest

    Re: Another Language


    "Larry Linson" <larry.linson@ntpcug.org> wrote in message
    news:3af71d81$1@news.devx.com...
    >
    > "Kunle Odutola" <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:


    >
    > > . . . I would be that someone and I stand by the statement. .NET
    > > isn't a religion. . . .
    > > OO isn't a religion either . . .

    >
    > I agree entirely, and I didn't say either _is_ a religion.


    Good, so let's cut to the chase.

    > > implementing and testing software systems that has been used
    > > succcessfully in the mainstream for over a decade now.

    >
    > I agree. I also point out that I can say the same thing for procedural

    programming,
    > but I can multiply the "over a decade" to "half a century". And, although
    > I have no "hard facts", I seriously doubt that there is a significant

    difference
    > in the success and failure rates of the projects using the two approaches.
    > I am unaware of significant studies proving so, as there have been about
    > other aspects of the development process.


    I have seen a few of the "hard facts" and the results are open to
    interpretation. On a personal note, I found that I could build more complex
    systems with OO than I was able to do before with less risk. Other people's
    mileage may vary.

    The general level of complexity we deal with today in software development
    is much larger than it was in previous years and decades. If we can deal
    with more complex problems but still have success rates at least as good as
    we have always had, then that is better in my books. Not just the same.

    OO is harder to learn and use properly than what went before. Many have not
    being able (or willing) to fully make the leap and many probably never will.
    OO's love child Component Based Development - in which the unit of reuse is
    much larger and functional than a simple class or classes - allows everyone
    to benefit from OO without getting their hands dirty. You can (re)use OO
    products from partially OO-fied tools such as classic VB. The next step for
    VB is to _also_ support people who would like to build fully OO solutions,
    not just use other people's components.

    > > For many, many problems (especially complex problems), OO is your
    > > friend but for trivial one-off systems, you may or may not get as
    > > much milegae out of OO.

    >
    > I agree that OO can be helpful, particularly in complex, code-intensive

    environments,
    > but you have again fallen into the mode of denigrating and trivializing

    the
    > "opposition".


    OO is helpful in many problem solving situations. I do not denigrate the
    opposition but merely point out that the return on investment in OO is
    _better_ for larger systems with long lives.

    > There are many non-trivial applications that need none of "their own" OO,
    > as opposed to using the objects provided by the tools (native, as VB, or
    > custom controls or libraries) -- and I've said, over and over, that I am
    > perfectly happy to use those. I've even written a few classes, to learn

    the
    > process, and for some (unusual for my applications) code-intensive areas
    > in applications. But, just because my applications are not brim-full of,
    > and bullging at the seams, with my own classes and objects does not mean
    > they are non-trivial.


    By your admission your systems use OO (indirectly through component reuse).
    I can understand that you don't want to build components, just use them.
    Other users like myself want the ability to be able to (re)use components as
    well as build them using the full gamut of OO features. VB.NET and the .NET
    platform supports us both I believe.

    > The software involved in getting men to the moon, was certainly "one-off"
    > (if by "one-off", you mean "unique"), but it was decidedly non-trivial,

    and,

    I downloaded the source code for early Unixes and C compilers from some site
    on the internet a while back and was struck by just how "simple" they seemed
    to me. Of course I could _not_ have written it when the original developers
    did but, I guess that today, many graduates would have written more complex
    compilers and maybe even OSes as part of their course. That's progress and,
    that is why comparing raw success figures across decades usually is missing
    the point - unless you take a whole lot of other issues into account.

    > My point is that neither "side" in this argument is in a position to make
    > a valid claim "my way or the highway" or "if you don't do it my way, it

    doesn't
    > compute". Except, of course, the .NET developers and the .NET language

    developers,
    > aka The Boys and Girls in Redmond. Only time, I think, will tell whether
    > they have built a mighty rocket that will catapult them to new heights of
    > greatness or whether they have shot themselves in the foot or more tender
    > places. I'm not rushing to sell my Microsoft stock, but I'm not straining
    > my broker's capacity ordering more, either!


    I don't see myself as a "side" in an argument. We are all expressing
    opinions on a range of issues and I hope that at the end of it all, we would
    all have learned a little something that would be of benefit...

    Kunle




  5. #65
    Mike Mitchell Guest

    Re: Another Language

    On Tue, 8 May 2001 00:26:36 +0100, "Kunle Odutola"
    <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:

    >OO is harder to learn and use properly than what went before.


    Exactly. And this is why the millions of VB programmers who have never
    written a class will not suddenly discover a hitherto untapped
    interest for learning OOP. They will just say, well, many of them
    will: "Why make it harder when it already worked the easy way?" Add a
    few expletives directed Seattle-wards, and that sums up the general
    rejection that I believe VB.NET will receive from the overwhelming
    mass of VB programmers.

    They (we) have been using six different versions of classic VB since
    1991, plus VBA and VBScript, and we have produced millions upon
    millions of lines of code. And now, suddenly, those millions upon
    millions of LOC are dead, deceased, obsolete - unless they are
    rewritten the VB.NET way. Even contemplating such a mammoth task
    beggars belief, it is so utterly ridiculous.

    But, people in the VB.NET camp say, you can leave those millions upon
    millions of LOC in VB6. "VB6 WILL BE AROUND FOR SOME TIME..." they
    opine. But how long is "long"? When Microsoft state on the web site:
    "Microsoft Visual Basic.NET is the next version of Microsoft Visual
    Basic..." Some of those millions of LOC will represent long-term
    projects which are maybe only half-way through to completion. Of they
    have been completed, tested, and now they are settling in for, say, a
    five year minimum usage duration with bug fixes and enhancements,
    their mentors fully expecting a backward-compatibleVB7 and a VB8.
    These may have been five, ten or twenty man-year projects, but the
    VB.NET evangelists have only two choices to offer us: Leave them in
    VB6; or port them to VB.NET. The former is going to be unacceptable to
    many IT managers, who want to be able to tell their bean counters,
    liability insurers, clients and other interested parties that the
    projects are being produced with a fully-supported programming
    language, not a legacy product. But the latter 'solution' (of porting)
    is going to be so tremendously costly that it won't seem like a viable
    alternative either. Result? Total impasse. And a whole bunch of people
    so utterly pissed off with Microsoft that they will move heaven and
    earth before committing to using yet another 'big idea' (namely
    VB.NET) from the Redmond 'think' tank.

    MM

  6. #66
    Kunle Odutola Guest

    Re: Another Language


    "Mike Mitchell" <kylix_is@hotmail.com> wrote in message
    news:3af86faa.9848500@news.devx.com...
    > On Tue, 8 May 2001 00:26:36 +0100, "Kunle Odutola"
    > <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:
    >
    > >OO is harder to learn and use properly than what went before.

    >
    > Exactly. And this is why the millions of VB programmers who have never
    > written a class will not suddenly discover a hitherto untapped
    > interest for learning OOP.


    I am intrigued (but not surprised) that this was the only fragment of my
    mail that you chose to reply to.

    Mike, the only reason that many millions can throw a few controls on a form,
    wire them up with some event "glue" code and end up with great looking,
    functional apps in VB without "writing a class" as you said is that someone
    else took the plunge, learnt OO and did all the hard work of writing those
    magical components and classes that the millions use.

    I can't see the problem in empowering VB so that both the consumers of the
    OO components and classes as well as the producers can do all their work
    using VB.

    <<<SNIP>>>

    As for the rest of the article, "VB6 continues to exist for those
    unable/unwilling to learn VB.NET"
    And yes, VB6 probably has no more than a couple of years left. I actually
    wonder if VB6 applications would still run on Windows 2004+?
    <g>

    Kunle




  7. #67
    Phil Weber Guest

    Re: Another Language

    > The millions of VB programmers who have never written
    > a class will not suddenly discover a hitherto untapped
    > interest for learning OOP. They will just say, well, many
    > of them will: "Why make it harder when it already worked
    > the easy way?"


    Mike: You seem to be under the impression that VB.NET *requires* developers
    to design and create classes. That is incorrect: you can use .BAS modules to
    create procedural apps in VB.NET just as you've been able to in prior
    versions of VB. Had you bothered to actually install and experiment with
    VB.NET, you would have known this.

    And VB, the syntax itself, hasn't changed that much either: with a few
    notable exceptions (e.g., GoSub, Wend, As Any, etc.), the language we've
    come to know and love is alive and well. For example, is the following code
    "Classic VB" or VB.NET?:

    Sub Main()
    Dim I As Integer
    Dim Items(9) As String
    ' Populate Items() array with text
    For I = 0 To UBound(Items)
    Items(I) = "Item " & CStr(I)
    Next
    End Sub

    Can't tell? That's because the code runs identically under all versions of
    VB. So much for the alleged "new language."

    What *has* changed significantly is the library of objects upon which our
    programs rely. Rather than the proprietary objects and functions in the VB
    runtime and forms package, we're now faced with the .NET Framework. It *is*
    different, but it's far more powerful, language-neutral, and potentially
    cross-platform. Rather than think of the Framework as a new language, I
    prefer to think of it as a new set of components. You seem to have had
    little trouble learning the ins and outs of the third-party components you
    use; I'm sure you could get up to speed with the .NET Framework with a
    comparable level of effort.
    ---
    Phil Weber



  8. #68
    Phil Weber Guest

    Re: Another Language

    > It all boils down to one thing: Learning a new language.

    Steven: Actually, it doesn't. See my reply to Mike Mitchell elsewhere in
    this thread: VB, the language, is largely intact. It boils down to learning
    a new set of components, which most VB developers have been doing for a long
    while. The only real difference here is that developers weren't given a
    choice, and the library of objects to learn is large and somewhat
    intimidating.
    ---
    Phil Weber



  9. #69
    Bob Butler Guest

    Re: Another Language

    "Phil Weber" <pweber@devx.com> wrote in message
    news:3af8d826$1@news.devx.com...
    <cut>
    > For example, is the following code
    > "Classic VB" or VB.NET?:
    >
    > Sub Main()
    > Dim I As Integer
    > Dim Items(9) As String
    > ' Populate Items() array with text
    > For I = 0 To UBound(Items)
    > Items(I) = "Item " & CStr(I)
    > Next
    > End Sub
    >
    > Can't tell? That's because the code runs identically under all versions of
    > VB. So much for the alleged "new language."


    But it isn't totally identical. Udner VB6 that code is limited to 32767
    items while under VB.Net the limit is much larger. In that particular code
    snippet the difference may not matter much but in others the difference
    between 32-bit Integers and 16-bit Integers could be important. It's thst
    redefining of existing keywords that is the biggest issue I have with
    VB.Net.




  10. #70
    Patrick Steele Guest

    Re: Another Language

    In article <3af94721@news.devx.com> (from Bob Butler
    <butlerbob@earthlink.net>),
    > But it isn't totally identical. Udner VB6 that code is limited to 32767
    > items while under VB.Net the limit is much larger.


    True. But syntactically, it is identical and works under all versions
    of VB.

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

  11. #71
    Jonathan West Guest

    Re: Another Language


    >
    > And VB, the syntax itself, hasn't changed that much either: with a few
    > notable exceptions (e.g., GoSub, Wend, As Any, etc.), the language we've
    > come to know and love is alive and well. For example, is the following

    code
    > "Classic VB" or VB.NET?:
    >
    > Sub Main()
    > Dim I As Integer
    > Dim Items(9) As String
    > ' Populate Items() array with text
    > For I = 0 To UBound(Items)
    > Items(I) = "Item " & CStr(I)
    > Next
    > End Sub
    >
    > Can't tell? That's because the code runs identically under all versions of
    > VB. So much for the alleged "new language."


    Hi Phil,

    for this specific example, where you don't approach the limits of the old
    Integer size, then clearly you are correct, it works just the same in both
    languages.

    However, there are cases where you are relying on passing a value in a
    specific type to another program or to an API call where this does matter,
    and it is all too easy to forget to set thing to Integer (as they must be if
    you don't want to crash & burn) where previously they were Long.

    Also, there are cases where you want to restect a value to an Integer size,
    and the code has been designed so that an exception is thrown when you get
    on overflow error, and where the use of this behaviour is an intended part
    of the program operation. It will be messed up if the Integer suddenly
    becomes 32-bit instead of 16.

    Of these two scenarios, I regard the API call to be by far the more common
    and important.

    There simply wasn't any *need* to redefine the Integer keyword. There is no
    shortage of keywords. The Int16, Int32 and Int64 keywords exist as synonyms.
    There is no need for the point of compatibility with th CLR. 16 buts are 16
    bits whether the language calls them Short or Integer. Integer has been
    changed to 32-bit simply because somebody remembered from an old copy of K&R
    that (in C) the Integer type is the natural word length of the machine, and
    took that to be holy writ.


    --
    Regards
    Jonathan West - Word MVP
    MultiLinker - Automated generation of hyperlinks in Word
    Conversion to PDF & HTML
    http://www.multilinker.com
    Word FAQs at http://www.multilinker.com/wordfaq
    Please post any follow-up in the newsgroup. I do not reply to Word questions
    by email



  12. #72
    Phil Weber Guest

    Re: Another Language

    > There simply wasn't any *need* to redefine the Integer
    > keyword.


    Jonathan/Bob: OK, granted, the Integer and Long data types are larger in
    VB.NET. I'm not arguing whether or not that change is a good thing. My point
    is that VB.NET is hardly a "new language." For most VB programmers, new or
    experienced, learning the VB.NET syntax will be no more difficult than
    learning that of VB6.
    ---
    Phil Weber



  13. #73
    Jonathan West Guest

    Re: Another Language


    "Phil Weber" <pweber@devx.com> wrote in message
    news:3af95b2d@news.devx.com...
    > > There simply wasn't any *need* to redefine the Integer
    > > keyword.

    >
    > Jonathan/Bob: OK, granted, the Integer and Long data types are larger in
    > VB.NET. I'm not arguing whether or not that change is a good thing. My

    point
    > is that VB.NET is hardly a "new language." For most VB programmers, new or
    > experienced, learning the VB.NET syntax will be no more difficult than
    > learning that of VB6.


    I agree with that. Personally, I haven't ever suggested that the learning
    process for VB.NET is a major issue. The code migration process is.

    Also to some extent, during the transitional times, if you are working in
    both languages for different projects, or working on VB.NET and Office VBA,
    then there it may be a bit more common to introduce bugs into code because
    you have momentarily forgotten which keyword means what in which language.
    Avoiding keyword redefinition greatly reduces the risk of such problems.
    That is a straightforward programmer productivity issue which means
    potentially affects project timescales and costs.

    --
    Regards
    Jonathan West


  14. #74
    Kunle Odutola Guest

    Re: Another Language


    "Jonathan West" <jwest@mvps.org> wrote in message
    news:3af9616d@news.devx.com...
    >
    > "Phil Weber" <pweber@devx.com> wrote in message
    > news:3af95b2d@news.devx.com...
    > > > There simply wasn't any *need* to redefine the Integer
    > > > keyword.

    > >
    > > Jonathan/Bob: OK, granted, the Integer and Long data types are larger in
    > > VB.NET. I'm not arguing whether or not that change is a good thing. My

    > point
    > > is that VB.NET is hardly a "new language." For most VB programmers, new

    or
    > > experienced, learning the VB.NET syntax will be no more difficult than
    > > learning that of VB6.

    >
    > I agree with that. Personally, I haven't ever suggested that the learning
    > process for VB.NET is a major issue. The code migration process is.
    >
    > Also to some extent, during the transitional times, if you are working in
    > both languages for different projects, or working on VB.NET and Office

    VBA,
    > then there it may be a bit more common to introduce bugs into code because
    > you have momentarily forgotten which keyword means what in which language.
    > Avoiding keyword redefinition greatly reduces the risk of such problems.
    > That is a straightforward programmer productivity issue which means
    > potentially affects project timescales and costs.


    I find that unit testing handles these scenarios quite nicely -
    ptoductivity, schedule, quality, bugs etc.
    I recommend VBUnit and NUnit for VB.NET (and other .NET languages).

    I can see how the differences can cause be a pain though.

    Kunle



  15. #75
    Bob Butler Guest

    Re: Another Language

    "Phil Weber" <pweber@devx.com> wrote in message
    news:3af95b2d@news.devx.com...
    > > There simply wasn't any *need* to redefine the Integer
    > > keyword.

    >
    > Jonathan/Bob: OK, granted, the Integer and Long data types are larger in
    > VB.NET. I'm not arguing whether or not that change is a good thing. My

    point
    > is that VB.NET is hardly a "new language." For most VB programmers, new or
    > experienced, learning the VB.NET syntax will be no more difficult than
    > learning that of VB6.


    Yes, your point is well taken. Unfortunately it's not the "old language"
    either, it just looks like it in many ways.
    I see these pointless inconsistencies as causing a lot of headaches over the
    next few years since the same syntax will behave differently when compiled
    in different versions.




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