More on Visual J#.Net - Page 4


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 4 of 5 FirstFirst ... 2345 LastLast
Results 46 to 60 of 65

Thread: More on Visual J#.Net

  1. #46
    Jason Guest

    Re: More on Visual J#.Net


    >What's your solution for people who have 20+ passwords or 50+ passwords to


    >remember?


    Well obviously no one can remember that many passwords. If you are ONLY
    trying to protect from outside threats only, all the developers and admins
    can share a password which can be used all over the place. Yeah, it doesn't
    sit well with me either, but people do it.

    If you have locked server room, there is no reason not to have the passwords
    printed somewhere in the server room. That limits access as well, and ensures
    that if one password is compromised, they won't all necessarily be. Of course,
    don't store the passwords on a networked computer!

    At some point, you have to allow a certain small group of people to be totally
    trusted with the system. An attack from within that group would be devastating.

    The other, obvious solution is to give each user a domain password, then
    they only have to remember one!


  2. #47
    Mike Mitchell Guest

    Re: More on Visual J#.Net

    On 16 Oct 2001 17:24:34 -0700, "Jason"
    <jason@creative_nospam_corp.com> wrote:

    >Even better, you are doing online aircraft maintenance manuals. There is
    >a problem in the field that requires a small fix on the server, but until
    >you do it, no one can fix a 737. Of course, if you take down the server,
    >all the manuals for 757s and 777s are down too. There are passengers on
    >the concourse waiting for a lightbulb to be replaced on a 737, and it can't
    >be done until the mechanic can check off all the steps of the procedure,
    >and his manual is broken. But if you take down the server, all repairs on
    >all planes all over the world will stop for a period of at least 15 minutes,
    >maybe longer. And God forbid you should have to do a reboot, because there
    >are another half dozen services running off that same server that are completely
    >mission critical to the airline.


    If I might disturb your Armageddon reveries for a moment, I have a
    question: What do the airlines do at the moment? They haven't got .NET
    yet, and yet, miraculously, they all appear to be functioning
    normally, as are all the other businesses without .NET. How amazing is
    that!

    MM

  3. #48
    Mike Mitchell Guest

    Re: More on Visual J#.Net

    On 17 Oct 2001 11:15:16 -0700, "Jason"
    <jason@creative_nospam_corp.com> wrote:

    >You are saying, then, that if I have 500 computers, I should be required
    >to go to each computer with a CD and install and configure the software at
    >the console? Just so I understand where you are coming from. You think
    >that, aside from passing information around, computers should otherwise be
    >completely isolated from the internet, and no programs should be passed around
    >or installed over a network. Is that correct?


    Very security conscious organisations like banks and insurance
    companies have been upgrading their software for years (yawn) and
    their systems just work. I doubt if they're going to be using
    Microsoft software very much, though, for any of the mission-critical
    stuff, like people's privacy and security of their bank accounts. And
    they probably don't need to update nearly so often as you make out
    would be required. Again it sounds to me that your whole justification
    for .NET looks like a solution in search of a problem.

    MM

  4. #49
    Mike Mitchell Guest

    Re: More on Visual J#.Net

    On 16 Oct 2001 16:58:33 -0700, "Jason"
    <jason@creative_nospam_corp.com> wrote:

    >Well, except for VB6, they are backwards compatible.


    "except for VB6" is a very big exception in my book! In fact, it's the
    key exception. I wouldn't be here if it wasn't for the death of VB6.
    Do you think I would give a toss about C, or C++, or C#? It's because
    Microsoft is canning classic VB that I am here, no other reason.

    >(a) If you cannot adapt, you should get out of this business. This won't
    >be the last time you will have to do it.


    Oh, so why won't the C-ers need to adapt? They are being given C#,
    which is much more like what they have been used to, whereas VB
    programmers are expected to learn practically a new language. Why is
    there one rule for the C-ers and no rules for us? And don't forget
    that there were a number of people inside Microsoft who WANTED to
    deliver a true VB7, but they were overruled. I often wonder where,
    exactly, BillG stands on this. Did he really welcome VB.NET with open
    arms when he first was shown it? Will he adapt or will he hanker back
    to the days of true Microsoft Basic/QuickBASIC/PDS/VB-DOS/VB1-6, all
    genuine RAD systems in their time? He must have deleted VB6 off his
    machine by now if he is a true convert to the VB.NET cause. After all,
    why would he need classic VB any more if you're telling us VB.NET will
    do things that even C or VB couldn't do?

    >(b) If you cannot figure out OO from the stuff VB already has in it, you
    >should get out of this business. OO is very important when dealing with
    >complexity, and programs are getting more complex, not simpler.


    That's the problem. They are getting more complex because the tools
    are becoming more complex. If you make the tools easy to use by hiding
    the complexity (as classic VB does very nicely), then your apps will
    also be less complex and less buggy, you will be more productive, and
    can concentrate more on your designs instead of doing debugging grunt
    work to get the thing just to run without bringing the system down, as
    most far less productive C/C++ programmers have to do all the time
    while they battle with their complexities.

    >(c) You can always maintain the old VB6 code in a DLL.


    Not without a lot of work you can't.

    >>...But VB.NET is such a gigantic step backwards in
    >>furthering RAD technology that it leaves me gasping for breath over
    >>the sheer chutzpah of Microsoft for foisting such a cumbersome chimera
    >>on to the world of business...

    >
    >Actually, Microsoft went so far the other way with VB6, hiding as much of
    >the complexity as possible, that it was often more difficult to get things
    >done. Now they have put together a complete framework that you can use from
    >any .NET language. You get the full power of Windows instead of the dumbed-down
    >version, but you also get a lot of help from the Visual Studio tools.


    You're right, they *did* hide the complexity. It's what I just said a
    few minutes ago. But why did this make it more difficult to "get
    things done"? What things? Are you telling me that the huge armies of
    VB(A) users who never wrote a class ever found it difficult to produce
    what they wanted with VB? On the contrary, they welcomed VB with open
    arms *because* it wasn't complex and because everything else *was*.
    You seem to think that the only kinds of application needed to be
    written are vast multi-faceted monolithic programs used by thousands,
    where the truth is that VB fills the niche for the many hundreds of
    thousands of small to medium-sized apps that all companies around the
    world keep needing day after day, week in, week out, year after year.
    There will *always* be a need for a tool like classic VB, and VB.NET
    ain't it. Not for those three million 'ordinary' users. What are they
    going to do when they don't understand OOP and you, typically,
    simplistically tell them to "get out of the business"? What right do
    you have to just cut off their air supply if they've got wives and
    families to support and maybe have been gainfully employed for years
    by knowing VB(A)? Okay, so you'll respond by saying it's not you who's
    doing to them, it's Microsoft. But you are not in any way, it seems,
    the slightest bit embarrassed for suggesting new careers to people,
    when it's not even their fault that their tool is being taken away. I
    suppose you'd say if they can't cut the mustard then it's the dole
    office for 'em! What a selfish view of life that is. What a way to win
    friends and influence people, huh?

    >To me, it looks simpler to do a good program with the .NET stuff than it
    >would be with VB6. VB6 has become a twisted maze of weird rules and exceptions
    >to those rules, with some not-quite-there-yet features and some things that
    >have needed an overhaul for years. For new programmers, it is actually easier
    >to learn a language like Java than it is to learn VB, because the language
    >has so many weird features. Java is a clean language, and VB needed cleaning
    >up really badly. Of course, building a GUI is easier in VB, but then building
    >a GUI in .NET is just as easy, and the resulting code is a lot cleaner.


    Sure, VB may have needed cleaning up, but that's not what they did.
    They just reinvented a new language that kinda looks like it could be
    Basic. There was/is a huge amount of life left in the "true" Basic
    model of programming. Just look at all the good things Microsoft *did*
    do with VB over the years. To me it just seemed to get better and
    better (with the exception of 16-bit VB4). So that shows that they
    could have continued to improve classic VB indefinitely. However, they
    saw .NET instead and visions of controlling the internet, and so VB
    had to die because how would they sell the idea of all-encompassing
    .NET while extolling the virtues of traditional VB? It couldn't be
    done. The marketing gals would have had a fit if they had been
    expected to continue 'selling' both incompatible versions.

    >Hey, I've got an idea...instead of hating .NET because it is put out by the
    >evil Microsoft empire, just try it out. If you don't like it, hey, it was
    >free in the first place. Or maybe you are afraid you will really like it
    >a lot... :-P


    No.

    MM

  5. #50
    Zane Thomas Guest

    Re: More on Visual J#.Net

    On Wed, 17 Oct 2001 21:26:22 GMT, kylix_is@hotmail.com (Mike Mitchell)
    wrote:

    >Oh, so why won't the C-ers need to adapt? They are being given C#,
    >which is much more like what they have been used to


    Oh baloney Mike! As usual, when it comes to technical information, you
    don't know what you're talking about.

    C# bears a superficial resemblance to the original c language, however
    there are huge changes all over the place. There are no include files, no
    unsafe casts, no pointers (except in code marked unsafe) ... and of course
    there is no stdlib - having been replaced with the entirely new framework
    class libraries.

    And c# bears even less resemblance to c++ which is what most of us "c-ers"
    have been using for the past many years.

    There's a learning-curve for c# which is at least as significant as the
    learning curve for vb.net (coming from vb6). And a curve well worth
    getting over (for both vb and c++ programmers). I've written *lots* of
    code with c# now and it, along with the vs.net ide, is the most productive
    programming environment I've ever used - and yes, I've used VB too.

    Run along Mike, you don't know what you're talking about.


    --
    The nice thing about standards is that
    there are so many of them to choose from.

  6. #51
    Mike Mitchell Guest

    Re: More on Visual J#.Net

    On Wed, 17 Oct 2001 21:39:16 GMT, zane@mabry.com (Zane Thomas) wrote:

    >On Wed, 17 Oct 2001 21:26:22 GMT, kylix_is@hotmail.com (Mike Mitchell)
    >wrote:
    >
    >>Oh, so why won't the C-ers need to adapt? They are being given C#,
    >>which is much more like what they have been used to

    >
    >Oh baloney Mike! As usual, when it comes to technical information, you
    >don't know what you're talking about.


    Okay, then, hand on heart (it's on your left), and say that C# is not
    less different to C/C++ programmers than VB.NET is to VB programmers.

    >
    >C# bears a superficial resemblance to the original c language, however
    >there are huge changes all over the place. There are no include files, no
    >unsafe casts, no pointers (except in code marked unsafe) ... and of course
    >there is no stdlib - having been replaced with the entirely new framework
    >class libraries.


    No pointers makes it actually less complex than C/C++! And what might
    look superficial to you looks pretty much like an identical twin to
    me. Compare VB.NET to classic VB and, well, there are hardly any
    similarities - except that both are obviously written in a form of
    English. How much work do you suppose a typical C/C++ programmer is
    going to have in porting an app to C# compared with the kind of
    mountain VB programmers will have to climb to convert theirs?

    >
    >And c# bears even less resemblance to c++ which is what most of us "c-ers"
    >have been using for the past many years.


    Huh! Double colons! Huh!

    >There's a learning-curve for c# which is at least as significant as the
    >learning curve for vb.net (coming from vb6). And a curve well worth
    >getting over (for both vb and c++ programmers). I've written *lots* of
    >code with c# now and it, along with the vs.net ide, is the most productive
    >programming environment I've ever used - and yes, I've used VB too.


    I don't believe you. About the learning curve bit, that is. (I stopped
    reading after that.)

    >
    >Run along Mike, you don't know what you're talking about.


    Well, you seem to find the need to respond, so you obviously
    understand it.

    MM

  7. #52
    Ronald Laeremans [MSFT] Guest

    Re: More on Visual J#.Net

    The difference between C# and C++ is significantly bigger than the
    difference between VB 6 and VB 7. It is hard to quantify differences between
    languages and environments, but I would definitely say several times bigger.

    -Ronald-

    "Mike Mitchell" <kylix_is@hotmail.com> wrote in message
    news:3bce01d1.12071339@news.devx.com...
    > On Wed, 17 Oct 2001 21:39:16 GMT, zane@mabry.com (Zane Thomas) wrote:
    > Okay, then, hand on heart (it's on your left), and say that C# is not
    > less different to C/C++ programmers than VB.NET is to VB programmers.





  8. #53
    W.E. (Bill) Goodrich, PhD Guest

    Re: More on Visual J#.Net

    In article <3bcdcab4@news.devx.com>,
    "Jason" <jason@creative_nospam_corp.com> writes:

    > >Nonsense. Unless you are constantly (several times a day) changing
    > >the password, anything less than a 20 character randomized password
    > >can be practically cracked by someone willing to expend the
    > >resources. And if you do change them that often, you make the job of
    > >the system programmers virtually impossible.


    > A 20 character randomized password using single case alphanumerics
    > encodes about 61 bits of information, which is not hackable without
    > a lot of resources.


    Say, those available to a government or a multimillionaire with
    government connections?

    > But even an 8 character password encodes more than 40 bits of
    > information, which, until recently, was the maximum key size for
    > encryption the US government considered exportable.


    Because they knew they could break such passwords fairly quickly, and
    wanted access to the world's confidential information. But that is an
    entirely different issue.

    > 40 bits is not impossible to break if you have the hash code, but
    > pretty secure otherwise.


    For personal use, perhaps. But not for access to the "Central Nervous
    System" of a major target (such as a prominent company).

    > >No you don't. For legitimate changes it is ADVISABLE to do so, but
    > >there is no OS mechanism which enforces any such requirement.


    [irrelevant metaphor snipped]

    > In the organizations I work with, there is a change control process
    > in place, and you HAVE to publish code to test before you publish to
    > production. Well, again, you don't have to. You could choose to be
    > fired instead.


    Which is an entirely irrelevant threat to the kinds of malicious
    individuals I described (with the possible exception of SOME of the
    "disgruntled employees").

    > The fact that the operating system does not mandate this is
    > irrelevant.


    On the contrary - the fact that the operating system does not mandate
    such steps is extremely relevant to the question of whether such
    "company procedures" offer ANY protection - or even any perception of
    protection - from deliberate, malicious installation of unauthorized
    code by unauthorized individuals. And as you just admitted, they offer
    no such "protection" - real or perceived.

    > The operating system also does not mandate that you feed it only
    > bug-free code.


    Again, that is entirely irrelevant to the issue of real and perceived
    vulnerability to malicious tampering.

    > >There is no such thing as a single,
    > >monolithic, absolute security measure. Security is achieved by a
    > >combination of measures, each of which impedes some unauthorized
    > >actions. The fact that any single element does not confer ABSOLUTE
    > >security is irrelevant to the impact of that element on the overall
    > >security of the system. Measures like requiring physical access to
    > >the hardware and taking the hardware off line in order to make any
    > >operational change are not absolute barriers to malicious change,
    > >but they each increase security somewhat in combination with other
    > >measures. And each can be modified to increase their potential
    > >impact, such as by locking the "computer room" (thus making access
    > >to the hardware more difficult). And removing those barriers
    > >decreases security in the same way.


    > And locking down a single DLL that I have to recompile and update
    > by taking down the service helps my security how?


    By requiring physical access to the system. Didn't you even read the
    paragraph you just quoted?

    But your artificially narrow focus on the "single DLL" ignores the
    issue at hand. The issue was the impact of "transparent changes" to
    ANY operational file (NOT just a "single DLL") on real and perceived
    system vulnerability to malicious modification. And especially the
    impact of a process for making such changes remotely.

    As to the issue of having to "recompile" the file you are changing,
    that is simply another of the unfortunate aspects of the .NET
    approach.

    > The original post was implying that the fact that IIS locks down a
    > custom DLL might be some sort of security measure.


    Nope. That inferrence came entirely from your own fertile imagination.
    Your (as you later admitted) unrealistic example of a DLL with a "bad
    bug" was addressed as a subset of the files covered in your statement:

    : If I had .NET, I could EASILY make the program update itself from
    : the web with no intervention by anyone.

    (the statement of yours that I quoted IMMEDIATELY before my response)
    The issue is not your Bad Bug DLL. Nor is it your IIS Lock. It is your
    ability to "EASILY make the program update itself from the web with no
    intervention by anyone." The issue is "the program" rather than your
    single, locked DLL.

    > >Nonsense. It is not a "complete" form of security in and of itself,
    > >but it is a very effective element of both perceived and real
    > >security. One of the biggest parts of that is the fact that it
    > >requires physical access to the hardware (which, as you have
    > >pointed out, is not the case with your "easier" .NET "updates").
    > >Another is the fact that a system going down for some period of
    > >time - even a brief one - is far more likely to be noticed than
    > >your "zero-impact installation."


    > Man, you are right! You had better tell Sun all about this before
    > it is too late! Obviously, Java services have this same problem,


    Not entirely. They do have such an OPTION, but it can be (and often
    is) easily disabled. And Sun is aware of the security implications
    (real and perceived), as shown by the number and variety of statements
    they have made about them.

    > and Sun needs to redesign Java so that it requires a compilation or
    > nobody is ever going to consider it for secure applications again!


    Not at all. Just keep the option to disable remote changes to
    operational files.

    > What were those people thinking???


    That it should be an option rather than a central element of their
    marketing and technical strategy.

    > Have you seen the Java stuff that automatically updates Java apps
    > on your machine - right over the web?


    Seen - and disabled long since.

    > And all this time I thought Sun was big on security... ;-)


    They are - which is why it is so easy to disable such remote updates.

    > >That is not the issue. But I do find it interesting that you keep
    > >trying to reduce the potential changes to nothing more than
    > >"rewriting a DLL". The increased vulnerability extends to all of
    > >the modules.


    > Exactly, so getting back to the point of the *original post* and
    > my response, why the heck does the fact that IIS locks down one DLL
    > confer any security at all?


    The "original post" (to which you initially responded) said nothing
    about DLLs or IIS. Your response - the part to which I replied at
    some length, starting this subthread) - said:

    : If I had .NET, I could EASILY make the program update itself from
    : the web with no intervention by anyone.

    And THAT is the issue at hand - not your IIS locked DLL.

    > It is an annoyance, not something you can rely on to provide any
    > measure of security, as the original post had implied.


    My original post stated that the security issue was your ability to
    change "the program" from the web with no intervention by anyone.
    Your attempt to shift the issue to the IIS lock is a complete red
    herring.

    > As far as I am concerned, you can put the changes on a floppy, walk
    > it over to the target machine, and drop the files there.


    Which is a far cry from your original statement. And less of a security
    issue (real and perceived).

    > That is plenty secure, don't ya think?


    Depending on the physical security of the target machine. But certainly
    more secure than your "from the web" scenario.

    > But in no case do I want to HAVE TO SHUT DOWN THE IIS SERVICE to do
    > the install.


    Yes, you have made that personal desire quite clear. But are you the
    only one whose desire counts? Are you in a position to make the
    decision for the entire company, irrespective of the impact on real
    and perceived security?

    > That is what the original post was about.


    Your original post was about Max's question:

    : What can .NET do, that could not be acomplished with ActiveX/COM
    : components written in C++ and callable from VB?

    And adderssed a number of issues. My response specifically addressed
    your statement:

    : If I had .NET, I could EASILY make the program update itself from
    : the web with no intervention by anyone.

    And the impact thereof on real and perceived system security.

    > >So companies shouldn't even TRY to increase their system security?
    > >I'm sure Corporate America will find that a relief. NOT. Any system
    > >that is designed to allow - even encourage - remote changes to its
    > >operational software should be viewed as a significant security risk
    > >and treated accordingly. And any system that allows such an update
    > >without direct, affirmative operator intervention is even more of a
    > >risk. Code Red (both) and Nimda exploited such openings, and future
    > >attacks are no less likely to.


    > You are saying, then, that if I have 500 computers, I should be
    > required to go to each computer with a CD and install and configure
    > the software at the console?


    That rather depends on the natures of the systems and their
    interconnections. And on the importance your company ascribes to the
    security and integrety of the systems. If your computers are just
    connected to an inranet which, in turn, is completely isolated from
    outside connections (dial-in lines, internet gateways, etc.), then
    your "zero-impact installation" might - with additional safeguards -
    be workable. Another reasonable compromise might require an affirmative
    validation (such as a one-shot acceptance password) from "someone" at
    each of those 500 machines before the relevant machine is "updated".

    > Just so I understand where you are coming from.


    Ok.

    > You think that, aside from passing information around, computers
    > should otherwise be completely isolated from the internet, and no
    > programs should be passed around or installed over a network. Is
    > that correct?


    Almost. I am saying that for most systems (including consumer systems),
    such programs should only be passed around or installed in a manner
    which is affirmatively controlled by the recipient, rather than
    transparent to the recipient. Especially over the internet or any
    internet-connected intranet. That the capability of "invisible updates"
    creates both a perception and a reality of increased vulnerability to
    malicious modification of the target system.

    > In some cases, this is the correct way to do things. I don't agree
    > that it is the solution in all cases, particularly because it costs
    > a lot of manpower and red tape to maintain such a system.


    As opposed to that needed for a recovery from a long-undetected
    malicious change to the system?

    > For many purposes, a really good password mechanism provides enough
    > security to keep password hacks at bay indefinitely.


    That rather depends on the nature of the password hack.

    > Other types of hacks can be successful, and I would not connect a
    > computer containing nuclear secrets to the internet no matter how
    > good the security appeared to be!


    How about the computers controlling patient records and (slightly
    indirectly) medication instructions at a large hospital? Those
    managing the primary databases of a large financial services company?
    Those controlling major electrical generation facilities (nuclear or
    otherwise) - or just the major power distribution grids? The Air
    Traffic Control systems? Criminal Justice records?

    --

    W.E. (Bill) Goodrich, PhD

    *-----------------------*--------------------------------------------*
    * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    * * *
    * Without Aversive * ctgcentral@earthlink.net *
    * Behavior Modification * Creative Technology Group *
    * or Drugs * PO Box 286 *
    * * Englewood, CO 80151-0286 *
    *-----------------------*--------------------------------------------*

  9. #54
    Zane Thomas Guest

    Re: More on Visual J#.Net

    On Wed, 17 Oct 2001 22:20:25 GMT, kylix_is@hotmail.com (Mike Mitchell)
    wrote:

    >I don't believe you.


    Big deal.


    --
    The nice thing about standards is that
    there are so many of them to choose from.

  10. #55
    Michael Bennett Guest

    Re: More on Visual J#.Net

    In article <3bcdcab4@news.devx.com>, jason@creative_nospam_corp.com
    says...
    <snip debate with Troll>
    Doesn't .Net have a security context which controls what assemblies can
    run under what circumstances?
    Isn't this applicable to remote installations?
    Isn't this security mechanism based on a 128 bit GUID?
    Isn't Mr. Goodrich's *perception* problem based mostly on MSFT's
    previous bad press for IIS and not .NET.

    Michael

  11. #56
    Tom Shelton Guest

    Re: More on Visual J#.Net


    Mike Mitchell

    [snip]

    > Okay, then, hand on heart (it's on your left), and say that C# is not
    > less different to C/C++ programmers than VB.NET is to VB programmers.


    Obviously you have never written any code in C++ or C#, or you would realize
    that this very true. Don't get me wrong there are some syntactic and
    feature overlaps, but C# is far and away farther from C++ than VB.NET is
    from VB.

    [snip - other obvious nonsense from someone who doesn't know what he is
    talking about]

    Tom Shelton



  12. #57
    Jason Guest

    Re: More on Visual J#.Net


    >Obviously you have never written any code in C++ or C#, or you would realize
    >that this very true. Don't get me wrong there are some syntactic and
    >feature overlaps, but C# is far and away farther from C++ than VB.NET is
    >from VB.
    >
    >[snip - other obvious nonsense from someone who doesn't know what he is
    >talking about]
    >
    >Tom Shelton



    For that matter, there are a lot more similarities between VB6 and Java than
    there are similarities between C++ and Java. VB and Java are pointerless,
    they both have a form of automatic garbage collection, and they both hide
    the complexities of the underlying operating system, making it difficult
    to get to the metal. Both languages are aimed at "higher-level" software,
    not device drivers or software that requires extremely fast operation or
    real time.

    Just because the syntax of a language is derived from C does not mean it
    is anything like C.

    I would make the same argument for C#. Although it has been extended to
    allow pointers in certain circumstances, everything else about the way you
    develop software is a lot more like VB than it is like C++. You just get
    new features like threading and inheritance added into your bag of tricks.

    So if you already know VB, it should be easy for you to learn C#. It isn't
    a difficult language, and it is the most powerful commercial language I have
    seen to date.

    Or, Mike, you can just sit around and tell stories about how you used to
    have to program VB in 6 feet of snow and become a crotchety old geezer.
    As far as I can tell, you are the only one who is still complaining. The
    rest of us are actually very happy that we are getting such an improved set
    of development tools.

  13. #58
    Mike Mitchell Guest

    Re: More on Visual J#.Net

    On 18 Oct 2001 11:50:17 -0700, "Jason"
    <jason@creative_nospam_corp.com> wrote:

    >Or, Mike, you can just sit around and tell stories about how you used to
    >have to program VB in 6 feet of snow and become a crotchety old geezer.
    >As far as I can tell, you are the only one who is still complaining. The
    >rest of us are actually very happy that we are getting such an improved set
    >of development tools.


    Sorry, Jason, but others have already tried this tack and it won't
    work! You can make me out to be a fool, a geezer, or whatever, I
    really don't care what names you give me. But I know what I see and I
    know what Microsoft has done to classic VB.

    MM

  14. #59
    Jay Glynn Guest

    Re: More on Visual J#.Net


    >really don't care what names you give me. But I know what I see and I
    >know what Microsoft has done to classic VB.


    Yeah, they finally fixed it ;-).


  15. #60
    jr Guest

    Re: More on Visual J#.Net


    Would you like some cheese with that whine?

    I use a wide variety of languages, both compiled and scripted, to perform
    the development work I do, including C++, Java, Javascript, and VB6. Much
    of my work includes XML parsing and XSL Transforms, and we have put MSXML3
    to good use in our company, calling it from all of the previously mentioned
    languages. I feel like I have a good grasp on the pros/cons of developing
    in different environments.

    While I am a VB'er at heart (in fact, I find great enjoyment in teaching
    community programming classes using VB), I am anxiously looking forward to
    C#. I have been frustrated at times with the limitations that VB places
    on a developer who needs to get down under the covers, or because of the
    things that are near impossible to do with VB (i.e. ISAPI filters/extensions).
    Nevertheless, the advantage of RAD in VB has kept me in the VB6 IDE most
    of the time.

    I'm looking forward to being able to more seamlessly use the language most
    appropriate for the task at hand in .NET. Change doesn't bother me - it
    was quite a bit of culture shock when I switched from ANSI C++ to VB, but
    once I was used to it, I was converted. Now, with the advent of .NET, I'm
    a convert from the start. Rapid Development will now be within the grasp
    of my "C-er" friends, and increased power/flexibility will be within my hands,
    even if I bury my head in the sand and only use VB.NET.

    However, I'm sure I will take some time to experiment with all that .NET
    has to offer, to find the set of tools I am most productive with. I am sure
    I won't be very productive if I rigidly defend my old, forgotten VB kingdom,
    and pine away for the passing of VB6. It had it's time, but now, it's time
    to go.


    kylix_is@hotmail.com (Mike Mitchell) wrote:
    >On 16 Oct 2001 16:58:33 -0700, "Jason"
    ><jason@creative_nospam_corp.com> wrote:
    >
    >>Well, except for VB6, they are backwards compatible.

    >
    >"except for VB6" is a very big exception in my book! In fact, it's the
    >key exception. I wouldn't be here if it wasn't for the death of VB6.
    >Do you think I would give a toss about C, or C++, or C#? It's because
    >Microsoft is canning classic VB that I am here, no other reason.
    >
    >>(a) If you cannot adapt, you should get out of this business. This won't
    >>be the last time you will have to do it.

    >
    >Oh, so why won't the C-ers need to adapt? They are being given C#,
    >which is much more like what they have been used to, whereas VB
    >programmers are expected to learn practically a new language. Why is
    >there one rule for the C-ers and no rules for us? And don't forget
    >that there were a number of people inside Microsoft who WANTED to
    >deliver a true VB7, but they were overruled. I often wonder where,
    >exactly, BillG stands on this. Did he really welcome VB.NET with open
    >arms when he first was shown it? Will he adapt or will he hanker back
    >to the days of true Microsoft Basic/QuickBASIC/PDS/VB-DOS/VB1-6, all
    >genuine RAD systems in their time? He must have deleted VB6 off his
    >machine by now if he is a true convert to the VB.NET cause. After all,
    >why would he need classic VB any more if you're telling us VB.NET will
    >do things that even C or VB couldn't do?
    >
    >>(b) If you cannot figure out OO from the stuff VB already has in it, you
    >>should get out of this business. OO is very important when dealing with
    >>complexity, and programs are getting more complex, not simpler.

    >
    >That's the problem. They are getting more complex because the tools
    >are becoming more complex. If you make the tools easy to use by hiding
    >the complexity (as classic VB does very nicely), then your apps will
    >also be less complex and less buggy, you will be more productive, and
    >can concentrate more on your designs instead of doing debugging grunt
    >work to get the thing just to run without bringing the system down, as
    >most far less productive C/C++ programmers have to do all the time
    >while they battle with their complexities.
    >
    >>(c) You can always maintain the old VB6 code in a DLL.

    >
    >Not without a lot of work you can't.
    >
    >>>...But VB.NET is such a gigantic step backwards in
    >>>furthering RAD technology that it leaves me gasping for breath over
    >>>the sheer chutzpah of Microsoft for foisting such a cumbersome chimera
    >>>on to the world of business...

    >>
    >>Actually, Microsoft went so far the other way with VB6, hiding as much

    of
    >>the complexity as possible, that it was often more difficult to get things
    >>done. Now they have put together a complete framework that you can use

    from
    >>any .NET language. You get the full power of Windows instead of the dumbed-down
    >>version, but you also get a lot of help from the Visual Studio tools.


    >
    >You're right, they *did* hide the complexity. It's what I just said a
    >few minutes ago. But why did this make it more difficult to "get
    >things done"? What things? Are you telling me that the huge armies of
    >VB(A) users who never wrote a class ever found it difficult to produce
    >what they wanted with VB? On the contrary, they welcomed VB with open
    >arms *because* it wasn't complex and because everything else *was*.
    >You seem to think that the only kinds of application needed to be
    >written are vast multi-faceted monolithic programs used by thousands,
    >where the truth is that VB fills the niche for the many hundreds of
    >thousands of small to medium-sized apps that all companies around the
    >world keep needing day after day, week in, week out, year after year.
    >There will *always* be a need for a tool like classic VB, and VB.NET
    >ain't it. Not for those three million 'ordinary' users. What are they
    >going to do when they don't understand OOP and you, typically,
    >simplistically tell them to "get out of the business"? What right do
    >you have to just cut off their air supply if they've got wives and
    >families to support and maybe have been gainfully employed for years
    >by knowing VB(A)? Okay, so you'll respond by saying it's not you who's
    >doing to them, it's Microsoft. But you are not in any way, it seems,
    >the slightest bit embarrassed for suggesting new careers to people,
    >when it's not even their fault that their tool is being taken away. I
    >suppose you'd say if they can't cut the mustard then it's the dole
    >office for 'em! What a selfish view of life that is. What a way to win
    >friends and influence people, huh?
    >
    >>To me, it looks simpler to do a good program with the .NET stuff than it
    >>would be with VB6. VB6 has become a twisted maze of weird rules and exceptions
    >>to those rules, with some not-quite-there-yet features and some things

    that
    >>have needed an overhaul for years. For new programmers, it is actually

    easier
    >>to learn a language like Java than it is to learn VB, because the language
    >>has so many weird features. Java is a clean language, and VB needed cleaning
    >>up really badly. Of course, building a GUI is easier in VB, but then building
    >>a GUI in .NET is just as easy, and the resulting code is a lot cleaner.

    >
    >Sure, VB may have needed cleaning up, but that's not what they did.
    >They just reinvented a new language that kinda looks like it could be
    >Basic. There was/is a huge amount of life left in the "true" Basic
    >model of programming. Just look at all the good things Microsoft *did*
    >do with VB over the years. To me it just seemed to get better and
    >better (with the exception of 16-bit VB4). So that shows that they
    >could have continued to improve classic VB indefinitely. However, they
    >saw .NET instead and visions of controlling the internet, and so VB
    >had to die because how would they sell the idea of all-encompassing
    >.NET while extolling the virtues of traditional VB? It couldn't be
    >done. The marketing gals would have had a fit if they had been
    >expected to continue 'selling' both incompatible versions.
    >
    >>Hey, I've got an idea...instead of hating .NET because it is put out by

    the
    >>evil Microsoft empire, just try it out. If you don't like it, hey, it

    was
    >>free in the first place. Or maybe you are afraid you will really like

    it
    >>a lot... :-P

    >
    >No.
    >
    >MM



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