Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VB gurus no like VB.Net 2

Status
Not open for further replies.

SpiderBear6

Programmer
Sep 17, 2003
422
0
0
AU
I recently read an article which was discussing "the extreme lack of interest by experienced VB developers for VB.NET". It goes on to say...

"My concern is that VB.NET is failing. This worries me greatly, because I'm one of the many programmers who have built a successful career largely on programming in Visual Basic. Because VB.NET is the future of Visual Basic, if VB.NET fails, so will Visual Basic. If Visual Basic fails, so will the careers of many VB programmers."

I don't agree with this, cause VB and VB.Net while yes syntaxically they are very similar, they are miles apart in functionality.

And further, it says...

"VB6 is already a RAD language. VB.NET does not significantly improve on this."

Vb.Net may not vastly improve on this sure (there as some new nice points about it), but surely you can't say that there is no point moving to Vb.Net because of this.

"VB6 is far easier to learn than VB.NET. This is primarily because VB.NET is so object-oriented that the numerous VB programmers with hobbyist or power-user backgrounds have considerable trouble learning it."

Sure Vb.Net is so object-oriented, but that's a good thing. It would probably do the "hobbyist or power-user" good to start learning to program this way. Their programs may not be as buggy and hopefully they would stop putting all of the code (business logic and all) in the forms.

"VB6 has better performance. After two years, I've concluded that VB.NET programs don't perform any better once they've started up and they take far longer to start up than VB6 programs."

This is an interesting point. One of the main claim to fames of Vb.Net (and the .net languages) is that they perform better. The Just-In-Time compile is a pain because it can take a while (only the first time) but that's what the users remember and forever brand it a slow app.

"In addition, VB.NET programs require a far more powerful PC than do VB6 programs just to run at all."

This I agree with, but it will be good when the new versions of Windows come out because they will include the .net framework.

"VB.NET is so large that a working programmer does not have the time to learn it."

I don't agree with this... I don't think VB.Net is that hard to learn once you grasp a few basic concepts. So this also means that a working programmer should forget about ever learning something new because it may take them a while? If that were the case, we would all still be writing COBOL.

"VB.NET is missing some critical components, such as a decent grid, a masked edit control, and so on."

What's wrong with the datagrid? It's not bad once you get used to it. The built in controls are far better than those of VB6. There are standard third party controls I always get when I use VB6 - TrueDBGrid being one of them.

"The overwhelming memory requirements of the .NET Framework make it impractical to use the VB6 ActiveX components because that would just increase the already large memory requirement."

So use .Net components.

"The considerable system requirements of .NET programs are a stumbling block in its adoption.
The advantages added to VB.NET mainly help advanced programmers. For example, inheritance is not useful to the many VB programmers who are unacquainted with object-oriented programming and don't write classes. Ending DLL Hell is useless to a programmer who has never written a DLL in VB."


This letter appears to be written by a VB programmer who has never written a class module in his life.

"VB.NET is not the language VB programmers wanted. It is the language that C++ programmers felt VB should be."

It's closer to the language I wanted, than VB6 is and I am a VB programmer.

Do other people share this view? I have been a VB programmer for years and have only just moved over to Vb.Net - am part way through my MCAD. I still write programs in VB 6 though.

Anyone like to share their views?

The whole letter can be read at:


:)
 
Having been writing code since the late 70's ( mostly with various versions of Basic, along with assembly and machine code), I am now using VB6. I have not yet seen any reason to change to NET.

Sure, VB6 isn't completly OO, but it's good enough for what I want to do.

I feel that they could have fixed the things that needed to be fixed in VB without essentially making a whole new language.

Not to mention that NET "broke" a few of the things that I can do with VB6, and doesn't replace them.

Also, it still didn't fix ( in my opinion ) the biggest fault that VB6 had, which is the inability to compile an EXE that will run without *any* external files needed. (Although I've recently heard of a product that will make a VB6 program do exactly that, but I have not yet checked it out... )

If my old tools still get the job done and do it well, what's the reason to swap over to new tools that don't really improve the situation and in some cases, make it more difficult?

Like I said in a different thread, "They get my VB6 when they pry it from my cold dead hands!"

Robert
 
That's one reason I went to Delphi, TheVampire.

It offered me:

* A sane language syntax.

* RAD development capabilities almost as strong as VB.

* Few of the threading limitations of VB.

* The ability to create "clean" EXEs and DLLs.

You can use external runtime libraries or you can pick and choose from a more granular runtime library set and compile them in.

I've worked in C/C++ from time to time, but have never forgiven K&R for this monstrosity. Don't like it, probably never will. Just one of those personal biases: I'll write Fortran before any C-based language, given any choice whatsoever.

That said, I can appreciate where C fits into the scheme of things. It makes a good attempt at a compromise between machine-level languages and high-level languages, but the syntax blows chunks. The only thing uglier (to me) is APL and LISP.
 
What exactly do you mean by clean EXEs and DLLs? If you have the framework installed, then you only need your exe and any dlls you have created for your app to run.

What did VB.Net break, that you could do in VB6?

 
Well, my comment was in regard to creating EXEs and DLLs that do not require a large VB-style runtime.

My guess at what Robert was saying is that VB cannot do this, you always need to ensure that the appropriate VB runtime is deployed.

One reason .Net development is lagging for some applications is the very limited deployment of the Framework. Out of 14 machines here running Windows of various editions, only a Win 2003 Server box even has it installed. It's a pig!
 
Yeah 28 Meg is a bit. Why is it not running on the other 13 machines? Is the 28 Meg the only reason?
 
ThunderBear6, I simply don't need it on those machines. The only reason it is present on the Win 2003 Server box is because you can't remove it, plus I am working on an evaluation of Windows SharePoint Services (that was moved to .Net in this incarnation of SharePoint Team Services).

For a good late-night, sleep-deprived rant about OOP see thread329-674347 and scroll toward the end.
 
I think I may have missed a point. You said that "One reason .Net development is lagging for some applications is the very limited deployment of the Framework". What's wrong with just running the setup of the framework on a machine? I wouldn't have said that because it's not already on a machine, that that is lagging development. If that were the case, then the VB6 runtime files would lag development. Granted that the VB6 runtime is heaps smaller than the .NET Framework.
 
I think you have it there in a nutshell ThunderBear6. The size of the Framework keeps people from deploying it. Even if you distribute your code via physical media (CDs, DVDs) you're looking at long install times plus making the user reboot - something most applications haven't required since Win2K.

But it would be nice to have some idea what fraction of machines are .Net-ready today. Maybe this isn't a big deal anymore for the majority of target systems out there. I know I only have it on one machine here, it seemed to slow things down too much so I uninstalled it. It also balloons to much larger than 28M when installed.
 
True... I guess Microsoft are making it as cr@ppy as possible now so that when the new version of Windows (workstation) comes out, they will market the cr@p out of the fact that the OS has the .Net framework built in. (and of course everyone will think.. wow must upgrade to that).
:)
 
Ideally, nothing should have to depend on a runtime, framework or anything else.

Say you have a company with 1000 users, each of whom is using a number of .NET applications. You need to roll out a new application to a few hundred of them. Problem is, the new app depends on a new release of the .NET framework. The new framework, however, breaks some older .NET applications, so you can't deploy the new app until those older apps have been recoded as well.

Sound familiar?


Jeff
If your mind is too open your brains will fall out...
 
This is more of a mistake on MS's side than a mistake in the theory. The whole idea behind the Framework (and the JRE for java, and the Python interpreter, etc) is to provide a layer between the compiled interpretor code and the machine level (and dependant) side. The idea being write once, run anywhere. In all fairness I have to say this has probably been implemented the worst with .Net. Although this may be simply because I have yet to see a framework come out for anythiing besides Windows...not to mention the backwards compatibility isues the Framework has with itself (what are they thinking?).

But then, it has the MS name, so it will get more traffic than it would otherwise. I'd honestly be hapier moving to Python, but it doesn't have the MS name and hype. But I'm much happier with VB.Net than VB6. I recently wrote something involving objects that had collections of children who in turn had collections of children. Instead of writing complex functions to add them to treeviews and refresh the treeview and etc I simply user TreeViewNode's as their parent classes and then made sure to set the mybase.text everytime the key for the objects changed. No unnecessary refresh routines and as I added and deleted from the collecitons they would add and delete from the tree on the screen. Much easier in VB.Net than it would have been in VB6.

[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:
 
Tarwn have you looked at Mono yet? Getting there, slowly but surely.


Someday they'll figure out how to make web pages too. View that site at 1024x768 or lower for an all-too-common phenomenon. At least they didn't chop off the text at the left or right margins, only overlayed their primary navigation.
 
Yep, I had known there were some independant projects working on Framework and there are actually a couple IDE's that I have eard of that allow you to build .Net app's.
The reason I said this was the worst implementation of the three is because unlike .Net the group that created one set of interpretors created many interpretors for several OS's.

One good thing that they did with .Net is allow tie-ins for other languages to be integrated in. There are several languages out there now that have/had little or nothing to do with MS but have .Net versions (*python for instance, though it was more a prrof of concept than anything functional).

Don't get me wrong, in an overall manner I like .Net, theres just many things I think they could have approached better. Like it might be nice to be able to install the framework during an install...right now you can install 1.0 using a custom bootstrapper, but that method doesn't tend to work with 1.1 (at least not without going to another company's install package product).

[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:
 
Personally, after having spent many years with VB6, VB.Net looks really neat. However the biggest grudge I have against VB.Net is it's incompatibility with Win95 and some OSs needs a one time large download in order to run it, doesn't score high marks in ease of distribution.

Anyway, I've since moved on to Delphi. The only regret I have with this is the regret of not having moved sooner. Delphi rocks!
 
Having never actually used Delphi, I can't say too much. The only few problems I can see with Delphi is that it doesn't seem to have the large support mechanism that languages such as Vb.Net have. The other problem (which may or may not become a problem) is how it will handle the .Net framework on Windows machines when the framework gets incorporated into Windows. But I guess they will release a new version of Delphi if the demand is there. Can't say I know many programmers that develop in Delphi though.

:)

--------------------------------------
"We are star-stuff. We are the universe made manifest trying to figure itself out."
-- Delenn in Babylon 5 - "A Distant Star"
 
Lemur, many VB programmers that move to Delphi say the same thing. I use delphi too and am very happy with it.

SpiderBear
Delphi 8 (Delphi.NET) came out a couple of weeks ago, and the main advantage it has over VB.NET is that you can easily convert Win32 applications written in Delphi to .NET

As I understand it, doing the same with VB apps is considerably harder.

you say:
The only few problems I can see with Delphi is that it doesn't seem to have the large support mechanism that languages such as Vb.Net have.

What do you mean?

Tracey
Remember... True happiness is not getting what you want...

Its wanting what you have got!
 
Thanks Tracey... I didn't realise there was a Delphi.Net.

Moving VB6 apps to VB.Net depends a lot on how the VB6 app was written in the first place. If it was designed as object oriented, then there are not too many changes, mainly syntax. There is a wizard which will migrate a VB6 project to VB.Net (doesn't do too bad a job - most of the time).

Microsoft examples are mostly Vb.Net or C#. I think if Microsoft are going to release languages they should at least put the code examples in as many of them as they can.

I have never had the opportunity to use Delphi. All of my clients have always wanted VB or C++ (or the .Net equivalents.) Delphi is based on Pascal isn't it? If it is, then it would be alright in my books.

Does Delphi.Net use Visual Studio.Net as it's IDE?

Cheers :)



--------------------------------------
"We are star-stuff. We are the universe made manifest trying to figure itself out."
-- Delenn in Babylon 5 - "A Distant Star"
 
Spider

Yes Delphi is Pascal based code. Borland have developed Borland Delphi.NET, which is a Delphi IDE, although i understand it emulates VS.NET in its look. It is my understanding that Borland are the first non-M$ company to provide a .NET environment.

You can take a sneak peak at
(i'm still waiting for my copy)






Tracey
Remember... True happiness is not getting what you want...

Its wanting what you have got!
 
One thing to remember is that MS is developing .NET with ALL programmers in mind.

I'm not just talking about VB programmers compared to C++ programmers compared to cobol programmers. I'm talking about finacial application programers compared embedded sytems programmers to fuzzy logic business app programmers.

Just like students of mine in VB used to ask why they had to learn about MSMQ or developing ActiveX controls when their job isn't about that I would point out that the courses where not designed for YOUR job. They where designed for your job and everyone elses.

One thing .Net means to me is that finally language is realatively meaningless. Personally I'm learning C# and VB.NET. The thing now is that I know that I can do the same thing in both languages. So basically the languages bridge the language capability gap. I'm not having a big issue because I know C++. I agree with many of the changes. I also know where some things where hyped up as so great because you couldn't do it with VB. Like Try Catch. Something I was used to in C++ and yea it was/is nice but I could design VB6 error handling to perform in much the same manner if I wanted. to.

If you say "I don't need all this" I'm sory but pull your head out and look at what the rest of the world wants. If you don't need it all then stick with VB. Don't whine you want a better VB but then whine about what you get.

As for the requirement of the framework think about the big picture agian. Tarwn points out that .Net isn't about MS. .Net is about a open framework to build cross platform compatible applications on. I'm assured that my VB.Net app using only the .Net Framework will run on a MS box, A HP Unix box, a Solaris box, as AS400, IBM4090e, my mobile phone (well not my mobile phone but one day). For this they have to have a base line. What does this mean in concept is that sure if you only have 1 program developed in it the frame work is huge. But who has only one application running on their pc? No one. The more programs you have installed the more efficient the framework becomes. Sure I can statically link in libraries to a C++ program but think about the redunancy when I get a few hundred applications and DLLs all with the same code statically linked in.

As far as incompalibility with win95....please. Let me bring up the fact that java is not runnable on my C64 without major changes. Difference is the same. We need to get off this "everything must be backward compatible" If a client asked me to write an app that run on a 95 box I'll use a language and environment of that time. I can tell you the VB6 programs I write these days won't run on 95 without a fairly large install. But if you really wanted to then you can write your apps in ASP.NET and WAM it might even be able to be used by my C64. Sure let the old systems run on the new machines....don't expect new systems to work in reverse.

To one of the first comments about bad VB programmers I compleatly agree. There are TONS of them out there. As others have pointed out its largely because of the way VB is in the first place. Highly accessible. This promotes alot of self taught guru's that really don't expand beyond their own tunnel vision. Don't get me wrong. I'm 100% self taught in every language I've ever programmed in besides Pascal and COBOL and the list of languages is LONG. Nothing wrong with self taught programers but you have to have the drive and abition to learn all you can.

Will VB.Net make C++ programmers look better on them because the language is essentially the same as C++.Net? Nope, Majority of C coders that slag vb as a language probably still will. The differense to me is that now the decision to go with VB turns from the capability vb and access to developers to more just how many .Net developers of a given flavor I can get.

Basically at the end of the day if you say to yourself "Why should I learn something new. I don't need any of these features" then you are setting yourself up for a fall because you are not looking to the future. If you are stuck in the here and now constantly or even worse stuck in yesterday then you will never advance. Mean while everyone moves on and before you know it you are a foxpro 2.5 developer stuck maintianing systems writen 10 years waiting for the apps to be canned.

I used to goto courses for languages to pick instructors brains. I would already know what the course was teaching thus could concintrate on getting ideas from the instructors. In one VB 3 class there was a gentleman sitting next to me saying that "SQL and RDBMSs where stupid. Why not just use flat files. I've been using them on mainframes for almost 20 years fine" I didn't even try to agrue, just felt sorry to see someone refuse to pull their head out and move on with the times. That gentleman has done one of 3 things since then
1) Retire/retrenched
2) Still maintaining 30 year old code
3) Finally pulled his head out.

Which option is for you?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top