I'm confused !!! - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 2 FirstFirst 12
Results 16 to 25 of 25

Thread: I'm confused !!!

  1. #16
    John Butler Guest

    Re: I'm confused !!!


    "Kent" <kp@kp.org> wrote in message news:3e52f01d$1@tnews.web.devx.com...
    > These are my own opinions, many people agree others do not.
    >
    > Kent


    Sure don't. Use C# and VB.NET for a while, and you'll quickly see some of
    the differences. For me, VB.NET is more user friendly, the intelli-sense and
    immediate syntax checking, as well as the comfort of using familiar syntax
    are immediate differentiators.

    It sounds like you're speaking acedemically, without really having spent
    serious time trying to build apps in either language. From the outside it
    might all look similar, but the "feel" is different enough for me to be much
    happier using VB.NET.

    I don't expect to convince you or anyone else, this isn't one of those
    issues one can describe neatly. Until you have a deadline and are pressed to
    deliver a project using the tool, you won't really get into it enough to
    push either language until you know the differences. I've pushed VB.NET hard
    enough now to have seen where C# _can_ be better, but those cases have
    really been in exceptional circumstances....and way beyond the limit imposed
    by VB6 vs C++.

    rgds
    John Butler



  2. #17
    blob Guest

    Re: I'm confused !!!


    Jesus "H" christ pyle, you have got to be kidding me.

    "John Butler" <jrbutle@sickOfSpam.net> wrote:
    >
    >"Kent" <kp@kp.org> wrote in message news:3e52f01d$1@tnews.web.devx.com...
    >> These are my own opinions, many people agree others do not.
    >>
    >> Kent

    >
    >Sure don't. Use C# and VB.NET for a while, and you'll quickly see some of
    >the differences. For me, VB.NET is more user friendly, the intelli-sense

    and
    >immediate syntax checking, as well as the comfort of using familiar syntax
    >are immediate differentiators.

    What the **** does that have to do with the goddamn language? That is an
    IDE thing. Don't be comin here talking about the language man. It's all
    about convenience. If C# had the same type, wait I mean the IDE for C#.
    Sorry.

    >
    >It sounds like you're speaking acedemically, without really having spent
    >serious time trying to build apps in either language. From the outside it
    >might all look similar, but the "feel" is different enough for me to be

    much
    >happier using VB.NET.

    Again, you are equating ease of use(the IDE) with the language. Do the same
    thing in notepad and tell us about intellisense and syntax checking. You
    VB guys have never had to deal with command line builds and builds done in
    batch files so quit yer *****in.

    >
    >I don't expect to convince you or anyone else, this isn't one of those
    >issues one can describe neatly. Until you have a deadline and are pressed

    to
    >deliver a project using the tool,

    That's right, it's the tool, just ask my wife. If she's really horny right
    now and wants a quicky, she could care less about how I do it, just get it
    done. That's VB.



  3. #18
    Guest

    Re: I'm confused !!!


    As a long time VB6/Office developer, I empathize. But .NET is a much better
    way of doing things than either COM or Office of VB. Reasons why I like .net:
    1. .NET is much faster, take for instance a file indexer I wrote in .net
    - indexed 10,00 files and executed 10,000 SQL statements in less than a minute.
    With Access/VB6, it took 10+ minutes (Using FileSystemObject vs. .Net native
    classes).
    2. .NET has a much better way of organizing classes than either Java or VB,
    instead of searching your hard drive, most classes you will normally use
    are in a well organized class framework.
    3. End of dll ****. Multiple versions of dlls can be stored in the central
    GAC, each application's assembly is configured with the version of the dll,
    not just the dll so it calls the correct one. Alternatively you can store
    the dll locally in the application path, like in the dark ages of DOS.No
    server registrations to worry about.
    4. Improvements to VB6, VB.NET is a full OOP language, though missing a couple
    of neat features that C# has such as operator overloading, VB.NET can finally
    take advantage of true inheritance and polymorphism.
    5. VS.NET - once you get the hang of it, VS.NET is a far superior IDE than
    the Visual 6 Studio or Java's Studio One.
    6. Comparisions to Java, it's true that MS took a lot of great ideas from
    Java, you can see them all over the place but then again Java took a lot
    from C++. The big difference is that .NET's performance screams over Java
    in desktop applications (web server/app servers are debatable). Another thing
    I don't like about Java is it's classes have been pieced together over the
    years and are showing their age. Also programming the IDE is an exercise
    in futility. Most developers would be much more productive with VS.NET.
    Good Luck,
    Al


    "Kent" <kp@kp.org> wrote:
    >
    >Colin,
    >
    >Welcome to the new world. You cannot yet use .Net components from office.
    >
    >The story does not get any better I'm afraid, because you'll see that you
    >cannot just drop in your old VB6 code and compile it under VB.Net. Backward
    >compatibility is lost. This may or may not be an issue for you. For your
    >own sake I hope it is not.
    >
    >Microsoft has apparently decided that the old COM based way of doing things
    >is evil and has decided to pull the rug out from under us with this Java
    >like platform called .Net. It is more like Java and less like VB. You

    get
    >a Virtual Machine which is called the .Net runtime, which is capable of

    using
    >any .Net langauge. If you take the time to do some research, you will find
    >that even though the .Net runtime allows you to use different languages,
    >all of the languages are very similar and there is no clear advantage to
    >using one over the other. They all have pretty much the same strengths

    and
    >weaknesses. Since the new language C# has been submitted to the ECMA as
    >a standard and all of the .Net libraries are written in C#, it seems to

    be
    >the clear choice to use for .Net development rather than VB which has a

    track
    >record of being broken by Microsoft.
    >
    >One could also argue that since parts of .Net are derived from Microsoft's
    >old Java (Visual J++) technology, that Java would be a good choice to use
    >rather than .Net. By creating .Net Microsoft validated Java as a platform.
    > .Net is however not WORA like Java is. The entire .Net strategy is questionable
    >in my own opinion, since it is restricted to the Windows OS.
    >
    >Kent
    >
    >"cgts" <vb.@127.0.0.1> wrote:
    >>
    >>There was a time when I was a gun programmer in upto VB6 and C++ 6. I

    am
    >>wanting to get back into it after a long stay and was looking at beginning
    >>again in .NET (C++, VB Etc.) I had a bt of a play today at making a DLL
    >>in VB and one in C++ and they worked fine in a .NET test app. But when

    >I
    >>tried to use the DLL from Excel or Access 2000 they won't reference the

    >DLL.
    >> Error is incomaptible resource or similar.
    >>
    >>Does this mean that there is no backward compatibilty between .NET and

    previous
    >>apps. Or am I missing a page.
    >>
    >>I hope there is something wrong with what I am doing cos I just ordered

    >.NET
    >>programme
    >>
    >>Someone please explain in very simple terms the pro's and con's of .NET
    >>
    >>Kind Regards
    >>
    >>Colin



  4. #19
    Kent Guest

    Re: I'm confused !!!


    <vb.@127.0.0.1> wrote:
    >
    >As a long time VB6/Office developer, I empathize. But .NET is a much better
    >way of doing things than either COM or Office of VB. Reasons why I like

    .net:
    >1. .NET is much faster, take for instance a file indexer I wrote in .net
    >- indexed 10,00 files and executed 10,000 SQL statements in less than a

    minute.
    >With Access/VB6, it took 10+ minutes (Using FileSystemObject vs. .Net native
    >classes).


    .Net is not going to make SQL server any faster... sorry.

    >2. .NET has a much better way of organizing classes than either Java or

    VB,
    >instead of searching your hard drive, most classes you will normally use
    >are in a well organized class framework.


    I hate GACUtil. It reminds me too much of Regedit32.exe. Gotta disagree
    it's pretty easy to manage application Jar files if you know how to do it.

    >3. End of dll ****. Multiple versions of dlls can be stored in the central
    >GAC, each application's assembly is configured with the version of the dll,
    >not just the dll so it calls the correct one. Alternatively you can store
    >the dll locally in the application path, like in the dark ages of DOS.No
    >server registrations to worry about.


    Microsoft created DLL ****. It's about time the put an end to it. You do
    have the GAC to worry about now though.

    >4. Improvements to VB6, VB.NET is a full OOP language, though missing a

    couple
    >of neat features that C# has such as operator overloading, VB.NET can finally
    >take advantage of true inheritance and polymorphism.


    OOP languages have been around for along time. If OO was so important you
    could have used an OOP language.

    >5. VS.NET - once you get the hang of it, VS.NET is a far superior IDE than
    >the Visual 6 Studio or Java's Studio One.


    Not true at all. It's very slow and even slower when debugging. IntelliJ
    Idea puts VS.Net to shame. Eclipse is ok and Net Beans sucks. There are
    dozens of IDEs for Java. While there may be more than one .Net IDE you don't
    have as many choices.

    >6. Comparisions to Java, it's true that MS took a lot of great ideas from
    >Java, you can see them all over the place but then again Java took a lot
    >from C++. The big difference is that .NET's performance screams over Java
    >in desktop applications (web server/app servers are debatable). Another

    thing
    >I don't like about Java is it's classes have been pieced together over the
    >years and are showing their age. Also programming the IDE is an exercise
    >in futility. Most developers would be much more productive with VS.NET.
    >Good Luck,
    >Al

    .Net performance is not superior to Java except on the client side. If a
    fast UI is important, then you have options like SWT which uses native widgets
    just like .Net does.

    To sum it up. .Net has nothing on Java, which is why M$ is trying so hard
    to kill it off.

    Kent

  5. #20
    Patrick Troughton Guest

    Re: I'm confused !!!


    Hi Kent,

    "Kent" <kp@kp.org> wrote:
    >
    ><vb.@127.0.0.1> wrote:
    >>
    >>1. .NET is much faster, take for instance a file indexer I wrote in .net
    >>- indexed 10,00 files and executed 10,000 SQL statements in less than a

    >minute.
    >>With Access/VB6, it took 10+ minutes (Using FileSystemObject vs. .Net native
    >>classes).

    >
    >.Net is not going to make SQL server any faster... sorry.


    Wrong again, Kent, on two counts....

    First, ADO.NET's SqlClient data provider uses TDS (tabular data stream),
    SQL Server's native data transfer protocol whereas ADO runs on top of OLE
    DB. ADO.NET is faster than ADO when hitting SQL Server. This isn't just theory,
    either. At my company, we actually did performance testing a year ago and
    ADO.NET ran 25% to 100% faster than ADO.

    Second, the next version of SQL Server will have the .NET CLR integrated
    directly into the product which will allow you to write stored procedures
    in VB.NET.

    /Pat
    ----------------
    Show me the XML.
    ----------------

  6. #21
    John Butler Guest

    Re: I'm confused !!!


    "Patrick Troughton" <Patrick@Troughton.com> wrote in message
    news:3e5c0b1b$1@tnews.web.devx.com...
    > Wrong again, Kent, on two counts....
    >
    > First, ADO.NET's SqlClient data provider uses TDS (tabular data stream),
    > SQL Server's native data transfer protocol whereas ADO runs on top of OLE
    > DB. ADO.NET is faster than ADO when hitting SQL Server. This isn't just

    theory,
    > either. At my company, we actually did performance testing a year ago and
    > ADO.NET ran 25% to 100% faster than ADO.


    I second this. SQL server performance is waaay faster in .NET. This is what
    I'm talking about when I've suggested you should try it in the real world.
    You'd be pleasantly surprised.

    rgds
    John

    > Second, the next version of SQL Server will have the .NET CLR integrated
    > directly into the product which will allow you to write stored procedures
    > in VB.NET.


    I have my doubts about how well this will work....but if it does...cool. I
    hate T-SQL...Hopefully it won't introduce an overhead. Writing clever stored
    procedures is always a great way of wringing out perfomance increases....

    Rgds
    John Butler




  7. #22
    Patrick Troughton Guest

    Re: I'm confused !!!


    Hi John,

    "John Butler" <jrbutle@sickOfSpam.net> wrote:
    >
    >> Second, the next version of SQL Server will have the .NET CLR integrated
    >> directly into the product which will allow you to write stored procedures
    >> in VB.NET.

    >
    >I have my doubts about how well this will work....but if it does...cool.

    I
    >hate T-SQL...Hopefully it won't introduce an overhead. Writing clever stored
    >procedures is always a great way of wringing out perfomance increases....


    As I understand it, it should run even faster because your VB.NET code will
    be running in-process.

    /Pat
    ----------------
    Show me the XML.
    ----------------

  8. #23
    Jens Guest

    Re: I'm confused !!!


    > > Second, the next version of SQL Server will have the .NET CLR integrated
    > > directly into the product which will allow you to write stored

    procedures
    > > in VB.NET.

    >
    > I have my doubts about how well this will work....but if it does...cool. I
    > hate T-SQL...Hopefully it won't introduce an overhead. Writing clever

    stored
    > procedures is always a great way of wringing out perfomance increases....


    At an MS developers conference I went to last week, they actually said that
    the real advantage would be that SQL Server would act as a .NET host so your
    code could run In Process with the DB.

    Jens



  9. #24
    Patrick Troughton Guest

    Re: I'm confused !!!


    Hi Michael,

    "Michael D. Kersey" <mdkersey@hal-pc.org> wrote:
    >So when the program has a fatal error the database process crashes? Good
    >feature to add; and one consistent with Microsoft's software tool
    >strategy.


    Huh? You honestly think that an error in a .NET stored procedure is going
    to bring down the whole server? Does an error in a T-SQL stored procedure
    bring down the whole database now? Jeez....

    >Sounds like a reverse C-section, i.e., putting the baby back in after
    >it's grown. Will the mother of all databases survive? Will VBaby.NET
    >punch his way out? Tune in tomorrow for the gory details...


    Sounds like you're looking for any reason to be critical...even if it doesn't
    make any sense.

    >Good Luck,


    No, you're the one who needs the luck.

    /Pat
    ----------------
    Show me the XML.
    ----------------

  10. #25
    Patrick Troughton Guest

    Re: I'm confused !!!


    Hi Michael,

    Wrong again. .NET was designed from the beginning to work with SQL Server.
    But there's no point in arguing since Yukon is currently in beta and there's
    no way to definatively prove it one way or another. How about we revisit
    this topic after Yukon is released? We'll see who has egg on their face then.
    <G>

    /Pat
    ----------------
    Show me the XML.
    ----------------

    "Michael D. Kersey" <mdkersey@hal-pc.org> wrote:
    >Patrick Troughton wrote:
    >> Huh? You honestly think that an error in a .NET stored procedure is going
    >> to bring down the whole server?

    >
    >Yes. Because .NET is designed to run under an operating system as a set
    >of processes. It is NOT designed to run inside the process of a database
    >server.
    >
    >> Does an error in a T-SQL stored procedure
    >> bring down the whole database now?

    >
    >Usually not. And that is precisely because T-SQL, from it's inception,
    >was designed to run inside the database environment. T-SQL has certain
    >limitations because of that design: those limitations exist to prevent
    >it from killing the DB server. Writing such code is difficult. Ask the
    >people who originally wrote SQL Server - Sybase. They'll tell you how
    >difficult it is.
    >
    >> Sounds like you're looking for any reason to be critical...even if it

    doesn't
    >> make any sense.

    >
    >Perhaps you will study computer science someday, learn what a process
    >is, how it is implemented on various systems, and how problems occur.
    >Until then you cannot understand but can only argue angrily from
    >ignorance.
    >
    >Good Luck,
    >Michael D. Kersey
    >
    >"It's impossible to hold a reasonable conversation with someone whose IQ
    >is 30 points below your own."
    >- Cabin Amio



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