DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 4 of 18 FirstFirst ... 2345614 ... LastLast
Results 46 to 60 of 261

Thread: Another Language

  1. #46
    John Hilliar Guest

    Re: Another Language


    Check out tbred.com "Business Basic " it's been evolving since the 1980's

  2. #47
    Phil Weber Guest

    Re: Another Language

    > How do you think the concept of "namespaces" is going
    > to go down with classic VB'ers who just want an easy life
    > without unnecessary complexities?


    Mike: "Classic VBers" are already affected by namespaces: they must either
    avoid using objects or methods with the same name within the same scope, or
    they must specify the library (a.k.a. "namespace") containing the object
    they wish to reference.

    For example, try adding references to both ADO and DAO to a single project.
    Now, declare a DAO Recordset object. The fact that you must write "Dim rs As
    DAO.Recordset" rather than simply "Dim rs As Recordset" is namespaces in
    action.
    ---
    Phil Weber



  3. #48
    Rich Guest

    Re: Another Language


    "Rob Teixeira" <RobTeixeira@@msn.com> wrote:
    <SNIP>
    >Yeah. Wow! Unlike VB, it even runs on that OS that has less than 5% market
    >share!
    >
    >>There is one catch. The last time
    >>I looked, you must develop on the Mac.

    >
    >Oh, it *only* runs on that OS that has less than 5% market share...

    </SNIP>


    No, it does NOT "*only*" run on the Mac. You must DEVELOP applications on
    the Mac. It RUNS on Windows and Mac. Let me see, between Windows and the
    Mac, you easily reach 90% of the market. It is still more than VB 6. Also,
    it is 90% more than you can reach from C# and VB.NET's 0%. :-)

    <SNIP>
    >Hm, looks strangely like VB.NET's OO capabilities.

    </SNIP>

    No, it is the other way around. This product is shipping. You can build production
    applications with it now, not next year!


    Rich


  4. #49
    Rich Guest

    Re: Another Language


    "Rich" <nomail@nomail.com> wrote:

    </SNIP>
    No, it does NOT "*only*" run on the Mac. You must DEVELOP applications on
    the Mac. It RUNS on Windows and Mac. Let me see, between Windows and the
    Mac, you easily reach 90% of the market. It is still more than VB 6. Also,
    it is 90% more than you can reach from C# and VB.NET's 0%. :-)
    </SNIP>

    Let me clarify the statement, "It RUNS on Windows and Mac." By it, I am referring
    to the applications generated by REALBasic. I am not referring to the IDE,
    which runs on the Mac only.

    Rich

  5. #50
    Zane Thomas Guest

    Re: Another Language

    On Tue, 1 May 2001 13:11:13 -0700, "Sjoerd Verweij"
    <nospam.sjoerd@sjoerd.org> wrote:

    >> It's so typical of you, to go back and forth between standards of evidence
    >> depending upon the 'point' you're hoping to make. It's such blatant
    >> intellectual dishonesty which has me branding you a fool.

    >
    >What, just that?


    Heh, yeah actually. That's exactly the sort of inconsistency I watch out
    for - when I see it I conclude that the person in question is
    fundamentally dishonest.

    ---
    Ice Z - Straight Outta Redmond

  6. #51
    Zane Thomas Guest

    Re: Another Language

    On Thu, 3 May 2001 01:56:27 +0100, "David Bayley"
    <davidb@aebacus.another.spam.filter.com> wrote:

    >Mitchell.Sucks is what namespaces are about.


    LOL!


    ---
    Ice Z - Straight Outta Redmond

  7. #52
    Zane Thomas Guest

    Re: Another Language

    On Wed, 02 May 2001 20:50:13 GMT, kylix_is@hotmail.com (Mike Mitchell)
    wrote:

    > How do you think the concept of
    >"namespaces" is going to go down with classic VB'ers who just want an
    >easy life without unnecessary complexities?


    You mean people who have been using Thing1.Text and Thing2.Text for years
    without difficulty?


    ---
    Ice Z - Straight Outta Redmond

  8. #53
    Larry Linson Guest

    Re: Another Language


    Well, well, it seems we have yet another self-important "elitist" who can't
    win an argument with facts, but only by attempting to ridicule and denigrate
    the most common, by far, classes of application: standalone and straight
    client server, and those who choose to create them.

    You'll notice that I don't deny (and haven't denied in any of my posts) the
    existence of nor the need for the intergalactic-wide distributed applications
    that you seem to think are all there is, or all that's needed. Of course
    they're needed; but they aren't _everything_ and they aren't a new invention.
    They're nothing but extensions of the kind of distributed applications I
    was doing from the 1950s on... in the 1950s, it was SAGE Air Defense; in
    the 1960s, the space program; in the 1970s and 1980s, credit card authorization
    systems.

    If you don't have valid answers to them, you'd do best to hold your tongue
    instead of making yourself look foolish by trying to insult those who raise
    valid issues or claiming that their issues aren't important, just because
    it happens that their issues aren't important to _you_. When I was a lad,
    that attitude was called "self-centered", as well as "uncivil"; I don't think
    it's any different now.


    "Jon Ogden" <jon@ogdenco.net> wrote:

    . . .

    >Well, some of us are working in the real world of today not of 1994. Our
    >employers are not interested in us continuing to program the same way we

    did
    >for Win16- and, by the way, if you use VB6, you're using objects all over
    >the place - you must have figured that out?


    I said, in this very thread, I was happy to use the objects built in to the
    language and in third-party libraries. VB and Access have been object-based
    ever since I started using Version 1 of each of them. Did you not read, not
    understand, or just choose to ignore my comment because you thought you could
    make me appear stupid?

    And, by the way, I've been working in "the real world of today" not just
    since 1994, but since the 1950s, but I always understood that "the real world
    of today" encompassed a great deal more than the few things that I might
    be working on at any given time -- a realization you seem not to have arrived
    at.

    >Why should anyone try? If I understand you correctly, you have said that
    >you are happy with VB3. So have a ball. There's no need for us to rain

    on
    >your parade. Just stop raining on ours.


    Someone _was_ trying to convince me and I was responding. You obviously did
    not understand me correctly, but "understood" what you'd like me to have
    said. It would appear, also, that you are not willing to have dissenting
    voices raised. I am, unfortunately, too small a voice to have much effect
    on your parade, but if it were up to me, "rain" is not what I'd do on it.

    What _I_ would like is for Microsoft to give "parity" with C++ to VB... provide
    a continuing ability to produce unmanaged code with the classic VB, as they
    are providing that ability with classic C++, _and_ give you the "managed"
    code with the new features you think you need. It takes a pretty long stretch
    of my imagination to consider that "raining on your parade".

  9. #54
    Larry Linson Guest

    Re: Another Language


    I did, nor said, nothing of the sort... I said that I did not, and I do not,
    doubt Zane's enthusiasm. What I did was postulate that someone in his position,
    even if they were not enthusiastic as Zane is, would have to be _supportive_
    of the product on which their products and services are based.

    I'll have to agree that he's head and shoulders (and maybe a lot more) above
    twits like you who twist what people have said to something they can argue
    against, but I do think Zane, like you, is dismissive of valid issues. But,
    FYI, I have communicated privately with Zane on that and other perceptions
    of some of his posts -- details of which are none of your business.

    And, by the way, he's smart enough, brash enough, and tough enough to defend
    himself if he thinks he needs defending.

    "Jon Ogden" <jon@ogdenco.net> wrote:
    >
    >"Larry Linson" <larry.linson@ntpcug.org> wrote in message
    >news:3aecd664$1@news.devx.com...
    >
    >>For example, I do not, for a moment, doubt Zane's enthusiasm,
    >> but considering the business that Mabry is in, would he not have to be

    at
    >> least supportive even if he had some serious reservations?

    >
    >Since Zane is too bright for you to dare to argue with him regarding the
    >technical capabilities of .NET,
    >and he's too successful for you to dare to suggest that your judgment
    >regarding the future is better than his,
    >you decide to suggest that he must be a greedy liar?
    >
    >And this is shortly after you tch-tch over the way .NET proponents deprecate
    >those who do not agree with them.
    >
    >



  10. #55
    Kunle Odutola Guest

    Re: Another Language


    "Steven Bell" <sbell@momentiumtech.com> wrote in message
    news:3aed9ba3$1@news.devx.com...
    >
    > My point on the so-called "re-taking" of the exams; is that you have to

    learn
    > a new language AND then retake an exam(s).


    Would you rather take the exam without studying for it?
    I'm not sure I understand the problem here...

    > The upgrade path for "legacy" code is bad at best. So, who pays for that?
    > My clients? I don't think so. So, who pays for it? Me? Do I take it
    > on the nose as a "cost-of-doing-business" expense? I don't think so, but
    > I guess I have to.


    Existing code doesn't have to be "upgraded" since VB6 is still available and
    it still works. If you (or your clients) decide to make a business decision
    on whether to upgrade the existing code to VB.NET, the cost/benefits of
    doing so would drive your eventual decision. Same for a decision to move to
    Delphi, Java, Perl....

    > The point: if I have re-write/learn a new paradigm (let me re-emphasize

    this
    > takes money out of my pocket with the idea of gambling to put it back in),
    > what keeps me from jumping to a tried-and-true standard language? Java?
    > Geez, even, gag, Dephi? (Sorry, had trouble spitting that last word out)


    The cost of moving to VB.NET is less than the cost of moving to Java,
    Delphi, C# or any other obvious upgrade path. The real gamble isn't the
    syntatic/semantic differences in VB6 and VB.NET but whether you believe in
    ..NET's future. Java is the obvious option here but you also mentioned
    Delphi/Kylix and I am sure thare may be others depending on your individual
    criteria.

    So do you believe in .NET ?

    > The upgrade wizard is a joke. Re-writing sections of code that were

    upgradeable
    > from v.3 to 4 to 5 to 6 are not upgradeable to 7.


    No pain, no gain. Sorry but that is what this boils down to ultimately
    (unless MSFT can be persuaded to include an Option VB6Compatibility mode
    into VB.NET)

    > BTW, where I feel we do agree is that the value of the entire MCP/MCSD

    program
    > is very much in question. There are so many boot camps, collages, etc.

    churning
    > out MCSD's these days that it no longer gives people a leg up. Not worth
    > the time and money (which for me are the same).


    I don't think MCSD is any more relevant or irrelevant compared to the Java
    certification programmes and other such programmes. I think they are useful
    (especially for beginners) but I value actual experience over
    qualifications.

    > Of interest. I, and several others, have moved off the Intradev world to
    > Macromedia products. Also, in the process, is an examination of IBM's

    Websphere
    > as a replacement to IIS 5.x (even though it is a Java animal).


    Dreamweaver/UltraDev are solid products IMO. If they work better for you
    them by all means use them. WebSphere though is a different kettle of fish.
    It is getting better but, it is no IIS5 replacement (it will work quite well
    with IIS though). There isn't a single Java webserver that compares
    favourably to IIS5 IMHO.

    > The upshot of all this rhetoric, though, is that I, and other long-time VB
    > developers I know, are now looking seriously at Java. Good-bye VB. I'm
    > afraid that I agree with Bruce McKinney. It was a good hack. It made me
    > a lot of money. It's time to move on.


    The Java phenomenom is part of the reason for the radical upgrade that .NET
    and VB.NET represent compared to what came before from MS. Apart from the
    existence of ports of the Java platform on multiple OSes, Java now has
    obvious advantages over the .NET platform (except perhaps WinForms & code
    security/obsfucation).

    Given the additional cost of upgrading from VB to Java (as opposed to
    VB-to-VB.NET), the choice of platform would have to be made on issues other
    than syntatic/semantic differences IMO.

    Kunle




  11. #56
    Kunle Odutola Guest

    Re: Another Language


    "Larry Linson" <larry.linson@ntpcug.org> wrote in message
    news:3aecb389$1@news.devx.com...
    >
    > Gee, it's amazing to me that the proponents of VB.NET seem to be able only
    > to deprecate those who aren't thrilled with it, but not to explain _how_
    > it is better for, or makes it easier to develop, standalone and

    client-server
    > applications. But, I agree with the statement that it _does_ address

    standalone
    > applications, client-server, and browser-server applications, in its way.
    > (So do a goodly list of other tools, see below for some that I opted not
    > to use in the past.)


    VB.NET is better primarily because of the .NET patform that it is built
    upon. The virtues of such a virtual platform has been the driving force
    behind the success of VB, Smalltalk and more recently Java to name a few
    tools. In years gone by, the virtual platform that VB applications ran on
    was proprietary and inaccessible to developers outside MS. It was also
    limited in many important respects and some of those limitations were due to
    it's direct reliance on some of the standard Windows platform plumbing such
    as COM.

    I am loathe to repeat MS marketing and/or technical info on the .NET
    platform that states _why_ .NET may be better for you. SO please see the
    ..NET docs for more on that topic.

    > It certainly doesn't provide the compiled code that was such a terrific

    thing
    > not long ago when Microsoft got around to it,


    Pre-compiled (i.e. pre-jitted) assemblies are to make an appearance I
    believe...

    > Prior to 1991, I _was_ involved with Enterprise-wide, some

    international-in-scope,
    > distributed applications of enormous magnitude, even before IBM introduced
    > the PC (without a single "object" in any of those, FYI). But, after I

    retired
    > from IBM, I was quite happy to solve a different class of business

    problems
    > and I was quite happy to have tools like 'classic VB' and Access that

    would
    > let me solve them with a minimum of fuss and bother.
    >
    > I'll say it again, because it's true: Microsoft has taken the most popular
    > and successful Development Tool of all time and turned it into just

    another
    > object-oriented language. If I'd wanted to develop standalone and client
    > applications in an object-oriented language, there were a plethora

    available.
    > But, I didn't opt for Delphi, I didn't opt for C++ Builder, I didn't opt
    > for JBuilder, for Pascal, for C++, or one of the others.


    VB has been [partially] object-oriented since VB4. Are you saying the
    addition of whitebox inheritance is such a bad thing that it has effectively
    killed VB ?
    <g>

    Kunle




  12. #57
    Kunle Odutola Guest

    Re: Another Language

    > >- and, by the way, if you use VB6, you're using objects all over
    > >the place - you must have figured that out?

    >
    > *Those* kind of objects I love to bits. Whack an object on to a form,
    > fill in the properties, bingo! That'll be 99,999 bucks, please,
    > guv'nor!


    *Cough*, *cough*, Ahem...those are _components_ not objects.
    CBD (Component-based Development) is somewhat complementary to OO
    development but isn't the same thing.

    > Hey! Perhaps I was really an OOP programmer all along!!


    Only if you used the OO features of VB - classes, interface inheritance
    (kludgy) etc...

    Kunle




  13. #58
    Larry Linson Guest

    Re: Another Language


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

    > VB has been [partially] object-oriented since VB4. Are you saying the
    > addition of whitebox inheritance is such a bad thing that it has
    > effectively killed VB ? <g>


    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". Had Microsoft chosen to give VB parity with
    C++, that is, maintaining compatibility and the ability to create unmanaged
    code, as well as compatibility with the new, and the ability to create managed
    code, I'd be happy as the proverbial pig in mud.

    I am one of those who's not anti-OO, because I think it's useful in some
    (code-intensive) environments, and even sometimes when the environment isn't
    quite so code-intensive. I am one, however, who knows that OO is not the
    basic requirement for any and all computing, and that requiring it can make
    development of simple, straightforward apps more complex.

    I do, also, disagree with your statement that the "objects" in VB (and, I
    suppose, my favorite DBMS, Access) are only "components". To the extent that
    objects actually differ from components, they are objects. I've always considered
    both to be object-based and those are the objects I am happy to use; but
    I avoid, if possible, having to write classes to implement my own objects.
    Perhaps I am not enough of a purist, but objects that have properties I can
    set and get, and methods that I can execute seem to me to be "objects".

  14. #59
    Rob Teixeira Guest

    Re: Another Language


    "Larry Linson" <larry.linson@ntpcug.org> wrote:
    >
    >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.
    In truth, I find it to be the other way around. I've done hundreds of things
    in the .NET beta I wasn't able to do, or wasn't able to easily do, in VB
    (which has nothing to do with OOP). The issue is that it requires a little
    thought and a little udnerstanding. This is where the lurning curve and code
    restructuring comes into play. If someone isn't willing to put some time
    into learning VB.NET, they're not going to get anything out of it. With all
    the advantages I see in VB, I'm gald in a sense that the "VB as we have known
    it" is dead. VB.NET is certainly a lot cleaner and so is the code I have
    to write. So far, I haven't written a single line in the .NET beta that I
    would consider a "hack". In classic VB, I've written entire libraries to
    "hack" at something that wasn't doable by VB natively.

    >Had Microsoft chosen to give VB parity with
    >C++, that is, maintaining compatibility and the ability to create unmanaged
    >code, as well as compatibility with the new, and the ability to create managed
    >code, I'd be happy as the proverbial pig in mud.


    Been there. That was my opinion last autumn. I didn't like the fact that
    we couldn't do unmanaged code in VB.NET. But the more I play with it, the
    more I think managed code is indeed the future. Feel free to disagree, but
    I'm beginning to feel quite comfortable with it.
    Also, consider that VB.NET is far superior to VB6 in terms of it's ability
    to interoperate with unmanaged code from other languages.

    >I am one of those who's not anti-OO, because I think it's useful in some
    >(code-intensive) environments, and even sometimes when the environment isn't
    >quite so code-intensive. I am one, however, who knows that OO is not the
    >basic requirement for any and all computing, and that requiring it can make
    >development of simple, straightforward apps more complex.


    It is not a requirement, it is a programming paradigm. Procedural programming
    is not a requirement for all computing either. You can still write code at
    the instructional level (assembly), but you choose not to because procedural
    programming is more convenient. The same applies to OOP.
    However, I disagree that OO makes simple apps more complex. Take a simple
    windows program. Without the nice Form and Button objects that VB gives you,
    you'd have to write somwhere around 120 lines of procedural code just to
    pop up a functional window with a button and some text.
    But even without UI issues, OOP can still solve simple problems easier. For
    example, I once gave my class the choice of two simple programs to write
    for an assignment (about 150 lines of code). They were allowed to use OOP
    or not as they saw fit. Since a portion of the students were coming from
    an intro to C class, and were therefore more comfortable with procedural
    programming, they chose to do it that way. However, the OOP code was consistantly
    around 3/4 the size of the procedural code, and much cleaner to look at.
    The procedural programs were bogged down with things like extraneous Select
    statements where the OO version used polymorphism to streamline this type
    of code instead.

    I think the biggest rift between OO mentality and Procedural mentality is
    best viewed by the phenomenon explained in the book Code Complete. There
    were a few cute analogies, but the point is that there's a big misconception
    that productivity is only achieved when you are heads-down coding. Procedural
    programming gives you the illusion of moving faster since the design phase
    is typically smaller. There's actually no reason for this time to be any
    smaller, but most often, the design phase for procedural programming has
    gaping holes in it.

    I can't remember the name of the book, but it explained things pretty well.
    I'll see if I can find it again. It was a large consulting company that did
    a comprehensive study based on around 45 different metrics on projects during
    a three year period to analyze the "real" differences between OOP and Procedural
    programming.

    What they found taking a 5-phase lifecycle (analysis, design, implementation,
    testing, and maintenance - we can safely ignore deployment since it has little
    or nothing to do with the application code) was the following:

    The analysis phase has little to do with code. You are analyzing the problem
    and identifying its concrete elements for the most part. You then need to
    identify possible solutions. In the design phase, you plan how to implement
    the solution. The implementation phase is the actual coding. The testing
    phase revolves mostly around QA and user acceptance tests. And finally maintenance
    is fixing lingering bugs and making modifications after release to keep the
    program going forward.

    The analysis phase is slightly different for procedural vs. OO programming.
    Their finding was that OO took up on average 125% of the time on analysis
    that procedural programs took. The findings also indicated that the analysis
    for OO code was consistantly more complete than the procedural code, which
    is attributed to the methods used for analyzing OO projects. Code Complete
    cites several sources, that show studies where the cost of identifying and
    fixing problems were 5 to 25 times more expensive (in time and money) once
    you get to the implementation phase, which is where procedural programs typically
    do this.

    The design phase is where the payoff starts for OO programs. This is because
    the abstraction that OOP is based on, allows the design to be very closely
    tied in to the analysis. This quite different from the procedural approach,
    where the design has to be dramatically "translated" from the analysis. Also,
    it was found that the object decomposition was much better than the functional
    decomposition, in both the speed of the process and the completeness of the
    process. Overall, OO design took up only 80-90% of the time procedural design
    took.

    The OO implementation phase for OO programs took on average 90% of the time
    that the procedural programs took. Again, this is because the OO abstraction
    closely mirrors both design and analysis. The total lines of code were always
    less in the OO programs, on average between 70% to 90% of the total number
    of lines in procedural programs. The code was more naturally documented and
    cleaner, since the encapsulation of the data-functions made it very easy
    to identify where any particular piece of code should be, and what it works
    with. And the code was more robust, since there is no way to inadvertantly
    change well-encapsulated data when it shouldn't be changed. They also identified
    that more efficiency was possible, since in some projects, some resources
    had to be retrained to use OOP techniques. Had they been experienced, the
    process would have been faster.

    Testing was HUGE payback. Testing for OO projects was only 60% of the time
    for procedural projects. This is because as bugs were found, they were fixed
    in well-encapsulated entities. This prevents most changes from inadvertantly
    rippling throughout a project, causing entire regression tests to be performed
    less frequently. Another factor is what we already talked about - the design
    was already more robust before we even got to the implementation.

    Finally, the BIG payback. Maintenance on OO projects were only 25-50% of
    the time needed to maintain procedural programs. Again, this is due to encapsulation,
    more robust design, and abstraction. Compenents are more naturally reusable,
    which also added to the maintenance benefit.

    So at this point, you may be thinking this only applies to large projects.
    But from personal experience, I see it happen in almost all projects or any
    size. Let's say you have a tiny program that only takes five hours to complete.
    You still go through all the phases. It's just that most of the phases are
    simple thought processes and/or a bit of scribbling on paper as opposed to
    months of documentation. So if it takes you 20 minutes total to analyze the
    problem throughout the processes, an OO aproach would make you think about
    it for an extra 5 minutes. You'd spend quite a bit of time mapping out the
    functions you would need, even if it's all in your head as you code. With
    an OO aproach, on the other hand, the design would naturally flow from the
    analysis, making it a much simpler process. In the end, you can save yourself
    a good half hour or so.
    The biggest payback in small programs is the smaller number of bugs, and
    code that could take half the time to update when someone asks for a change
    later.

    It's all a matter of perspective. Look at it this way: decades ago, all programs
    were created at the instructional level. The only way to organize your program
    was to group instructions in reusable macros (**IF** your compiler/language
    even allowed it).
    Slowly, people started transitioning to procedural programming because it
    organized the code much better, and made programming more efficient and bug
    free. Because of that, you were able to write bigger and more complex programs.
    The instructional die-hards swore by their methods, which they claimed was
    "real" programming and "closer to the metal". But in the end, procedural
    won, because it was the natural evolution that was necessary to keep the
    industry going.
    OOP is the same thing all over again. Decades from now, it'll be something
    new.

    >I do, also, disagree with your statement that the "objects" in VB (and,

    I
    >suppose, my favorite DBMS, Access) are only "components". To the extent

    that
    >objects actually differ from components, they are objects. I've always considered
    >both to be object-based


    You totally lost me here. "Component" is a high-level name for both reusable
    objects and reusable object groups/libraries.

    >and those are the objects I am happy to use; but
    >I avoid, if possible, having to write classes to implement my own objects.


    You always have two sides to OOP - the service side (providing the classes
    the objects come from), and consumer side (using those classes).
    Doing either or both constitutes OOP.

    >Perhaps I am not enough of a purist, but objects that have properties I

    can
    >set and get, and methods that I can execute seem to me to be "objects".


    Actually, the definition of an "object" is an entity that encapsulates related
    data (properies) and functions (methods). There is no other kind of object
    (in programming terms) that I know of.

    -Rob

  15. #60
    Larry Linson Guest

    Re: Another Language


    "Rob Teixeira" wrote <the most reasoned and factual response I've seen in
    this forum, and probably in any discussion of .NET and its impact>

    Rob,

    Thanks for your polite and cogent reply, addressing issues.

    By you definition, then, I am a happy consumer of OO programming. I didn't
    really consider VB and Access to be "OO", but "Object-Based", and, as I said,
    I've been happy to use the objects provided by the product, by custom controls
    when necessary, and by third-party libraries. I guess I'll have to adjust
    my thinking... it'll take some "getting used to" to say that I am "an object-oriented
    programmer, consumer side". <G>

    I certainly am neither opposed, nor would I want to replace with procedural
    code, the object provided by Windows, the products, custom controls, and
    libraries. It's only when the changes to the product (appear to me to) force
    me to create my own classes and objects in order to get good use (not just
    best use) out of it.

    And after all, at the very lowest level, you have to write procedural code
    to _use_ the objects, so even the proponents of object orientation are procedural
    programmers, too. Even the ones who say "procedural programming" in the tone
    of voice that normally you'd reserve for the rags that had served at the
    pet's bathroom for months and you'd only want to pick up on the other end
    of a long stick.

    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. I view, too,
    the (rather drastic, IMNSHO) changes to VB to transform it into VB.NET as
    a part of the overall .NET. That starts VB.NET out with a strike against
    it, in my eyes. Frankly, I am not in agreement with the goal of software
    as a service, done server-side, by the big guys. That's because I am one
    of the little guys, these days. All my business in the past ten years has
    been standalone applications on the desktop or straight client-server applications
    on a LAN or WAN.

    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.

    Thanks again for a polite, reasoned, and rational response. Your comments
    may be what convince me to give VB.NET a try rather than just skipping it
    entirely.




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