More on Visual J#.Net - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 5 FirstFirst 1234 ... LastLast
Results 16 to 30 of 65

Thread: More on Visual J#.Net

  1. #16
    Gary Nelson Guest

    Re: More on Visual J#.Net

    max,

    > I am having a hard time learning the .NET CL because the online help, MSDN
    > is the best example of bloatware that I have ever come across.



    MS has never been very good on documentation. I remember when they brought
    out far strings with PDS 7.0, none of the samples on how to call assembler
    worked. Not only did they not work, the whole philosophy was wrong. I took
    me a couple of weeks to figure it out on my own.

    Now I'm trying to get up to speed with XML and the documentation is
    absolutely diabolical. Its as though they through bits and pieces of a giant
    puzzle at you and you have to spend hours and hours trying to figure how
    they all fit together.

    Gary



  2. #17
    max caber Guest

    Re: More on Visual J#.Net


    Jason wrote,
    "There are simply things that Microsoft needed to be able to do that traditional
    VB and C++ programming could not touch."

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

  3. #18
    Joe \Nuke Me Xemu\ Foster Guest

    Re: More on Visual J#.Net

    "max caber" <maxcaber@yahoo.com> wrote in message <news:3bc87d7d$1@news.devx.com>...

    > Jason wrote,
    > "There are simply things that Microsoft needed to be able to do that traditional
    > VB and C++ programming could not touch."
    >
    > What can .NET do, that could not be acomplished with ActiveX/COM components
    > written in C++ and callable from VB?


    Cut off Borland's air supply? If the timelines posted here are correct,
    Delphi had finally acquired decent COM support when Microsoft decided on
    a way to Cool them down.

    --
    Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  4. #19
    Sean Scally Guest

    Re: More on Visual J#.Net



    Hey, and along those lines, what can ActiveX/COM components written in C++
    and callable from VB do that could not be accomplished by several thousand
    metric tons of Assembly??

    Throw away that power screwdriver, boys!! I've got a penny!!

    -Sean-

    "max caber" <maxcaber@yahoo.com> wrote:
    >What can .NET do, that could not be acomplished with ActiveX/COM components
    >written in C++ and callable from VB?
    >Max



  5. #20
    Jason Guest

    Re: More on Visual J#.Net


    >So how do you intend to convince the three million classic VB
    >programmers to dump their religion overnight and become converted to
    >another faith. For that's what it amounts to. You'd have more luck
    >converting them to Pascal. Oh, wait a mo, that's what many are gonna
    >be doing anyways!


    It was already happening. VB6 is a good "hack" language, and believe me,
    I am a "hard-core" VB programmer from way back. But when you try to do ANYTHING
    with a statically-compiled language for server side code, you have to shut
    down the web service to change the code! This is simply unacceptable. That
    is why Java has made such huge inroads into server systems - it is dynamically
    compiled, and a Java program (correctly written) can be upgraded in place
    while the application is running. This is also possible with .NET.

    I am not going to miss the VB3 menu editor, or the fact that I had to write
    my own subclassing and hooking libraries, or the clumsy use of Longs as pointers,
    or the treatment of arrays as "SafeArrays" or Variants, or the fact that
    there is no straightforward way to tell if an array is initialized...

    Okay, enough of that.

    I think the reason you are enamored with VB6 is that you don't know how much
    better the new stuff is going to be. The .NET runtime is just too different
    from VB6 to do a good translation though. Well, I think that is true. VB6
    has been long-in-the-tooth for some time now, and there are just too many
    compromises in the language to even discuss.

    What are the best things about VB6, the things that made it so successful
    for so long?

    Well, IMHO:

    For the most part, no pointers - more stable code.
    The GUI builder - comfortable and easy!
    Lots of libraries for the users.

    Now we are facing .NET. It has the same philosophy, no pointers, a great
    GUI builder (looks like VB6 to me), and lots and lots and lots of libraries
    for users. Only, this time it looks like they have gone many steps beyond
    where VB is today, and even beyond the libraries available in Java (the GUI
    libraries were always better, but the other libraries were badly needed).
    They have also added garbage collection, which helps even more with preventing
    memory leaks with little overhead.

    Yeah, I think when VB programmers realize the advantages of the .NET platform,
    they will be in a mad rush to learn the new stuff. VB6 is nice and all,
    but there is a new God on the block. :-)

  6. #21
    Sean Scally Guest

    Re: More on Visual J#.Net



    I'm afraid that if you're trying to preach .NET to Mike, you're wasting your
    time. He can't claim ignorance any more, as much as his opinions may prove
    to the contrary. No, unfortunately, he knows all this and hates .NET anyways,
    because nothing new is ever good.

    -Sean-

    "Jason" <jason@creative_nospam_corp.com> wrote:
    >
    >>So how do you intend to convince the three million classic VB
    >>programmers to dump their religion overnight and become converted to
    >>another faith. For that's what it amounts to. You'd have more luck
    >>converting them to Pascal. Oh, wait a mo, that's what many are gonna
    >>be doing anyways!

    >
    >It was already happening. VB6 is a good "hack" language, and believe me,
    >I am a "hard-core" VB programmer from way back. But when you try to do

    ANYTHING
    >with a statically-compiled language for server side code, you have to shut
    >down the web service to change the code! This is simply unacceptable.

    That
    >is why Java has made such huge inroads into server systems - it is dynamically
    >compiled, and a Java program (correctly written) can be upgraded in place
    >while the application is running. This is also possible with .NET.
    >
    >I am not going to miss the VB3 menu editor, or the fact that I had to write
    >my own subclassing and hooking libraries, or the clumsy use of Longs as

    pointers,
    >or the treatment of arrays as "SafeArrays" or Variants, or the fact that
    >there is no straightforward way to tell if an array is initialized...
    >
    >Okay, enough of that.
    >
    >I think the reason you are enamored with VB6 is that you don't know how

    much
    >better the new stuff is going to be. The .NET runtime is just too different
    >from VB6 to do a good translation though. Well, I think that is true.

    VB6
    >has been long-in-the-tooth for some time now, and there are just too many
    >compromises in the language to even discuss.
    >
    >What are the best things about VB6, the things that made it so successful
    >for so long?
    >
    >Well, IMHO:
    >
    >For the most part, no pointers - more stable code.
    >The GUI builder - comfortable and easy!
    >Lots of libraries for the users.
    >
    >Now we are facing .NET. It has the same philosophy, no pointers, a great
    >GUI builder (looks like VB6 to me), and lots and lots and lots of libraries
    >for users. Only, this time it looks like they have gone many steps beyond
    >where VB is today, and even beyond the libraries available in Java (the

    GUI
    >libraries were always better, but the other libraries were badly needed).
    > They have also added garbage collection, which helps even more with preventing
    >memory leaks with little overhead.
    >
    >Yeah, I think when VB programmers realize the advantages of the .NET platform,
    >they will be in a mad rush to learn the new stuff. VB6 is nice and all,
    >but there is a new God on the block. :-)



  7. #22
    Jason Guest

    Re: More on Visual J#.Net


    >Now I'm trying to get up to speed with XML and the documentation is
    >absolutely diabolical. Its as though they through bits and pieces of a giant
    >puzzle at you and you have to spend hours and hours trying to figure how
    >they all fit together.


    Don't blame Microsoft for this one! This is because of standards committees.
    They wanted XML to be capable of replacing SGML, which is a whole lot more
    complex and a lot slower to parse than XML. The result is a very complex
    standard.

    The good news is that for most things, you only need to use a small subset
    of the complete standard. The SAX and DOM parsers take care of all the details
    for you, so you don't have to write a parser from scratch.

    The one thing that you will have to get a good grasp of is the concept of
    "recursive-descendant" parsing. An XML document is a big tree, and you need
    to understand some recursive programming in order to manipulate it.

    Good luck!

  8. #23
    Jason Guest

    Re: More on Visual J#.Net


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


    Well, what if you are calling a DLL from IIS, and you need to change the
    behavior immediately because there is some bad bug, and you can't take down
    the service which has a lock on the DLL...

    .NET can do this. You can run two versions of the same assembly in the same
    process space, and you can add new versions or entirely new assemblies without
    shutting down the process. This is the TRUE meaning of a "zero-impact installation."

    You can also have different versions of the same assembly running on the
    same machine, where two different applications need the different versions.
    COM makes this difficult because it relies on the registry. .NET makes
    it really, really easy to do this.

    These are things that you CANNOT do without a JIT-compiled language, and
    they are absolutely essential to Microsoft unless they want to let Sun completely
    dominate the web server and services marketspace.

    Managed code is very important from the perspective of the web developer.
    And heck, I have had more people complain over the last year that they had
    to run an INSTALLATION program to upgrade their clients...that happens when
    the guy is a SysAdmin and has to do this on 500 machines without SMS. If
    I had .NET, I could EASILY make the program update itself from the web with
    no intervention by anyone.

    .NET is a BIG DEAL.

  9. #24
    Jason Guest

    Re: More on Visual J#.Net


    >Hey, and along those lines, what can ActiveX/COM components written in C++
    >and callable from VB do that could not be accomplished by several thousand
    >metric tons of Assembly??
    >
    >Throw away that power screwdriver, boys!! I've got a penny!!
    >
    >-Sean-
    >
    >"max caber" <maxcaber@yahoo.com> wrote:
    >>What can .NET do, that could not be acomplished with ActiveX/COM components
    >>written in C++ and callable from VB?
    >>Max


    No, really, Max's question was a valid one. VB6 is still a useful tool,
    and will be for years down the road. I will be supporting a lot of VB6 code
    I have written over the last couple of years, until customers are willing
    to pay to have it rewritten (usually for business-logic reasons, not because
    they want a new technology that does the same thing).

    The thing is, the .NET platform can do a few things that SIMPLY CANNOT BE
    DONE BY C++ OR VB. It's kind of like the difference between JScript and
    C. In JScript, which is an interpreted language, you can create a string
    that contains code and evaluate it directly. No muss, no fuss. In C, you
    would have to write the code to a file, compile it, and then run it in a
    new process, but your new process would not have access to all the variables
    in the original process. If you have ever worked with TCL/TK, you have done
    this sort of thing a lot!

    Interpreted code can be a lot more expressive than a statically compiled
    language is capable of being. The price you pay is that interpreted code
    is 10 to 100 times slower than compiled code (depending on the language).

    The idea of a JIT-compiler is revolutionary in this industry. It gives you
    90% of the speed of a true optimizing compiler, but it also allows you to
    bring in new code dynamically at run time like an interpreter. It may be
    a little more involved in the current languages like VB.NET and C#, but it
    does not have to be (.NET supports JITted JScript, after all!).

    THICK CLIENT PROGRAMMERS, READ!

    OKAY, think of this...

    Remember VBA? You drop it into your application, and it lets programmers
    use VB to customize a document. But it was kind of targeted to a certain
    type of application, and you had to pay royalties...

    So you use the Script control. That lets programmers use interpreted JScript
    or VBScript to customize your app, but there is no design environment and
    debugging is abysmal...

    Now consider .NET. You allow your application to dynamically load .NET assemblies.
    They can get into your application through a set of public interfaces that
    you have defined explicitly for this purpose. You can also prevent them
    from running "unsafe" code, so you know they won't be able to cause any GPFs.

    Think of the advantages! Your program was written for .NET in C#, maybe.
    Your users can use VS7 to create a customized assembly for your application,
    so they can add whatever macros and wizards they want to. They might use
    VB.NET or Cobol#, it does not matter to you. They can even use C#, the same
    language you used to create the application, to write macros for the application!


    Are you excited yet? VBA is a thing of the past! The Microsoft Script control
    is a thing of the past! And all the macros are JIT-compiled, so they run
    at the full speed of a compiled language!

    Just by writing your application for .NET and providing the right hooks,
    you can let users customize the application in any language .NET supports!
    Now if that does not excite you, I really don't know what else I can say.
    :-)


  10. #25
    Rob Teixeira Guest

    Re: More on Visual J#.Net


    "Jason" <jason@creative_nospam_corp.com> wrote:
    >
    >Are you excited yet? VBA is a thing of the past! The Microsoft Script

    control
    >is a thing of the past! And all the macros are JIT-compiled, so they run
    >at the full speed of a compiled language!
    >
    >Just by writing your application for .NET and providing the right hooks,
    >you can let users customize the application in any language .NET supports!
    > Now if that does not excite you, I really don't know what else I can say.
    > :-)
    >


    Actually, VBA is alive and kicking. You can download the beta for VSA.NET
    (visual studio for applications - slight name change).
    However, you are right that the script control is no longer necessary. The
    code dom and generators are built into the framework bundle you get with
    VS.NET. There are some nice samples in MSDN on how to hook into it.
    Of course, VSA does have it's advanatages - like a really nice GUI and debugger.
    The other nice thing is that you don't have to "provide the right hooks".
    VSA will be able to utilize any CLR-compliant .NET class.

    And lastly, yeah, it is exciting. Specially since you can also provide a
    way for users to customize code running on a web application, in much the
    same way they could write macros for Word or Excel - in addition to all the
    great new features available to "macros", since they are now for all the
    most part, not different from the actual development language product.

    -Rob

  11. #26
    max caber Guest

    Re: More on Visual J#.Net


    "Jason" <jason@creative_nospam_corp.com> wrote:

    "Well, what if you are calling a DLL from IIS, and you need to change the
    behavior immediately because there is some bad bug, and you can't take down
    the service which has a lock on the DLL..."

    I am quite aware of this quirk with IIS and COM, and love Servlets/JSP for
    that reason. But correct me if I am wrong, I think I remember getting around
    that problem by running my .dlls in MTS.

    However, since I have experienced the XML serialization with .NET and Chanels/Formatters
    used for remoting, I am really starting to like .NET. Now if someone would
    just develop a tree like object browser to document that big API, I would
    really be sold.
    Max


  12. #27
    Phil Weber Guest

    Re: More on Visual J#.Net

    > Now if someone would just develop a tree like object browser
    > to document that big API, I would really be sold.


    Max: Check this out:

    http://www.gotdotnet.com/team/windowsforms/
    WindowsFormsCodingHero3_11_01.aspx

    (URL must be pasted into browser as single line.)
    ---
    Phil Weber



  13. #28
    Gunnar Syren Guest

    Re: More on Visual J#.Net

    Hopefully the majority of them understands that it's not a religion, it's a
    tool. And when a new tool comes out they'll look at it, actually try it, and
    perhaps determine that it's a better tool and that it will help them do a
    better job in the long run. Some will determine it's not, and will either
    keep using their old tool as long as it's working, or move to another tool.
    But a few will just plain whine and say "I won't try it because I don't like
    it"...

    /Gunnar

    "Mike Mitchell" <kylix_is@hotmail.com> wrote in message
    news:3bc754a5.448161@news.devx.com...
    > On 11 Oct 2001 15:46:35 -0700, "Jason"
    > <jason@creative_nospam_corp.com> wrote:
    >
    > >There are simply things that Microsoft needed to be able to do that

    traditional
    > >VB and C++ programming could not touch. That is why .NET is here, that

    is
    > >why Microsoft bet the company on it, and that is why it will still be

    here
    > >when VB6 is a memory and C++ is only used by metalheads for ring 0

    programming.
    >
    > So how do you intend to convince the three million classic VB
    > programmers to dump their religion overnight and become converted to
    > another faith. For that's what it amounts to. You'd have more luck
    > converting them to Pascal. Oh, wait a mo, that's what many are gonna
    > be doing anyways!
    >
    > MM




  14. #29
    Jason Guest

    Re: More on Visual J#.Net


    >Actually, VBA is alive and kicking. You can download the beta for VSA.NET
    >(visual studio for applications - slight name change).
    >However, you are right that the script control is no longer necessary. The
    >code dom and generators are built into the framework bundle you get with
    >VS.NET. There are some nice samples in MSDN on how to hook into it.
    >Of course, VSA does have it's advanatages - like a really nice GUI and debugger.
    >The other nice thing is that you don't have to "provide the right hooks".
    >VSA will be able to utilize any CLR-compliant .NET class.
    >
    >And lastly, yeah, it is exciting. Specially since you can also provide a
    >way for users to customize code running on a web application, in much the
    >same way they could write macros for Word or Excel - in addition to all

    the
    >great new features available to "macros", since they are now for all the
    >most part, not different from the actual development language product.
    >
    >-Rob



    Yeah, I finally got a chance to read the latest Visual Studio Magazine last
    night and saw the insert. Well, that solves the problem of having all your
    users set up with Visual Studio! Of course, it is probably the exact same
    code repackaged and with a different licensing agreement...

    It's nice to see that Microsoft is already thinking about specific solutions
    along this vein. However, if you are willing to do a little more programming,
    all the tools are available in the .NET framework to compile and dynamically
    load the classes yourself, without even using VSA!

  15. #30
    W.E. (Bill) Goodrich, PhD Guest

    Re: More on Visual J#.Net

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

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


    > Well, what if you are calling a DLL from IIS,


    ....which is more of an IIS issue than a VB6/VB.NET issue...

    > and you need to change the behavior immediately because there is
    > some bad bug, and you can't take down the service which has a lock
    > on the DLL...


    Why would you want to allow the bad bug to continue running through
    the transition period?

    > NET can do this. You can run two versions of the same assembly in
    > the same process space, and you can add new versions or entirely
    > new assemblies without shutting down the process. This is the TRUE
    > meaning of a "zero-impact installation."


    [...]

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


    And it is also a very large problem, in that it creates both the
    perception and the reality of a chance that somebody malicious can use
    the same mechanism to induce a "bad bug". The perception is important
    in the current (and forseeable) business climate, with worries about
    cyberterrorism, sabotage, and the like. The reality is that password
    protection is a limited barrier - one which Micro$oft has had problems
    with in the past.

    The big threat (perceived and real) is not the "crash immediately and
    spectacularly" scenario (which is bad enough), but less obvious
    changes to transactions and other business records. If undetected long
    enough, such attacks can destroy even major corporations. Aside from
    the more obvious fund diversions, there are such possibilities as
    creating the "records" of illegal transactions, tax violations, etc.

    The threat need not come over the internet (although the setup allows
    it). Operatives and opportunists within the facilities (including
    contractors, maintainence and security personnel, etc. as well as
    disgruntled employees and the like) can use the mechanism with much
    less risk of detection. The "take the system down to install"
    requirement starts looking like a security measure in such a climate.

    > NET is a BIG DEAL.


    But not necessarily a good deal.

    --

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

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