• 0

VB.net Or Not VB.net


Question

Hi i have been thinking about doing something constructive with the time i spend on the computer, so i was thinking of learning to code in a visual basic enviroment, today i seen a educational licence for VB.net which i could take advantage of as iam in education the only problem is i dont know if i should use VB.net or VB 6.0 as this is a great offer.

Richman

Link to comment
Share on other sites

25 answers to this question

Recommended Posts

  • 0
Can code/projects be inported into .net?

Richman

584785642[/snapback]

What kind of Code/Projects? VB.NET has a vb6->vb.net converter, but it's not really something you'd ever want to use.

Link to comment
Share on other sites

  • 0
.Net... It's the direction the world is headed in.

584785410[/snapback]

The Microsoft world! I myself am not fond of .Net. Why?

-The .Net framework is huge.

-.Net applications are slow. It seems as if Java applications are faster.

-.Net applications can not be run on other older versions of Windows.

These are the major reasons I am not fond of .Net. I have learned C# and have made several applications with it. I rather code my applications in C or C++. This way I don't need to worry about the framework or slower applications. :alien:

Link to comment
Share on other sites

  • 0
The Microsoft world! I myself am not fond of .Net. Why?

-The .Net framework is huge.

-.Net applications are slow. It seems as if Java applications are faster.

-.Net applications can not be run on other older versions of Windows.

These are the major reasons I am not fond of .Net. I have learned C# and have made several applications with it. I rather code my applications in C or C++. This way I don't need to worry about the framework or slower applications.  :alien:

584787328[/snapback]

1. true... but overtime, it will no longer matter 20MB isn't that big in a broadband world

2. BS. Plain and simple. Initially, yes, a .NET app will load slower because it is compiling to machine code on the fly. After JIT compilation, it should run as fast as any other app, sometimes faster.

3. Yes it can. .NET can be run on Win 98 and above machines. If you're concerned about 95 and below, then you're correct.

Link to comment
Share on other sites

  • 0
2. BS. Plain and simple. Initially, yes, a .NET app will load slower because it is compiling to machine code on the fly. After JIT compilation, it should run as fast as any other app, sometimes faster.

584787567[/snapback]

I'd just like to add to that point. You can also "pre-JIT" your code so it won't need to be compiled on the fly the first time you use it. That negates any worries about speed you may have.

Edited by karmakillernz
Link to comment
Share on other sites

  • 0
I'd just like to add to that point. You can also "pre-JIT" your code so it won't need to be compiled on the fly the first time you use it. That negates any worries about speed you may have.

584787916[/snapback]

I'd like to know how you do that :huh:

Link to comment
Share on other sites

  • 0
I'd just like to add to that point. You can also "pre-JIT" your code so it won't need to be compiled on the fly the first time you use it. That negates any worries about speed you may have.

584787916[/snapback]

Yeah, i heard, aren't you basically pre-JITing for a specific CPU set though? Like the app would be constrained to running on x86 only i think, cause i remember i asked about it before hand, due to the slow startup time at initially of a .NET app.

Link to comment
Share on other sites

  • 0

Sorry, I didn't make myself entirely clear. :p

What I was talking about was Install-time code generation which basically compiles the whole lot from the start instead of each piece as it uses it.

The runtime supplies another mode of compilation called install-time code generation. The install-time code generation mode converts MSIL to native code just as the regular JIT compiler does, but it converts larger units of code at a time, storing the resulting native code for use when the assembly is subsequently loaded and run. When using install-time code generation, the entire assembly that is being installed is converted into native code, taking into account what is known about other assemblies that are already installed. The resulting file loads and starts more quickly than it would have if it were being converted to native code by the standard JIT option.

Source

Link to comment
Share on other sites

  • 0

I believe the benefits of MSIL and the JIT far out-weigh the downsite of "I have to wait a second before my applicaton loads up." If all code was managed, we would have a lot less computer problems (e.g. viruses wouldn't be able to do anything, no buffer-overflow errors, etc...) Hopefully Longhorn will be a step in the right direction.

Link to comment
Share on other sites

  • 0
I believe the benefits of MSIL and the JIT far out-weigh the downsite of "I have to wait a second before my applicaton loads up." If all code was managed, we would have a lot less computer problems (e.g. viruses wouldn't be able to do anything, no buffer-overflow errors, etc...) Hopefully Longhorn will be a step in the right direction.

584788612[/snapback]

But the question is, when it comes time for enterprise scale applications, would manage code's performance deplete?

Link to comment
Share on other sites

  • 0

VB.NET and C# take it both in a same time, you will save some time. VB is out of the Enterprise and Web development and if you wish to develop Win32 desktop apps, then it's better to do it in C++, anyway in 95% of the cases the VB.NET or the C# will do the best job. Strongly advise you to consider ASP.NET you can use VB.NET and C# as well as many other .NET compatible languages.

Link to comment
Share on other sites

  • 0

Well in terms of Programming VB.NET for enterprise applications, i remember reading an article about it being bad if you intend to program any large scaled apps in VB.NET using the VS.NET IDE, primarily because of the way the IDE works, background compilation will slow things down when the project expands and grows larger.

Link to comment
Share on other sites

  • 0
Well in terms of Programming VB.NET for enterprise applications, i remember reading an article about it being bad if you intend to program any large scaled apps in VB.NET using the VS.NET IDE, primarily because of the way the IDE works, background compilation will slow things down when the project expands and grows larger.

584789739[/snapback]

Link?

From personal experience, I'd have to say that .NET is excellent for enterprise apps. What is large scale? Number of users? What the app does? Number of devs working on it?

Link to comment
Share on other sites

  • 0
Well in terms of Programming VB.NET for enterprise applications, i remember reading an article about it being bad if you intend to program any large scaled apps in VB.NET using the VS.NET IDE, primarily because of the way the IDE works, background compilation will slow things down when the project expands and grows larger.

584789739[/snapback]

Although I'm sure VB.net has some higher overhead when it comes to the IDE, and is probablly not the best language to use for an enterprise application, it all compiles down to MSIL in the end.

Link to comment
Share on other sites

  • 0
Although I'm sure VB.net has some higher overhead when it comes to the IDE, and is probablly not the best language to use for an enterprise application, it all compiles down to MSIL in the end.

584790602[/snapback]

What would make a language not fit for enterprise apps?

The only reason I ask is that there are still companies running, quite successfully, on big iron and COBOL. I've never thought COBOL, nor VB, was a lovely language, but it doesn't remove it's ability to be effective in the hands of a good programmer.

Link to comment
Share on other sites

  • 0
What would make a language not fit for enterprise apps?

The only reason I ask is that there are still companies running, quite successfully, on big iron and COBOL. I've never thought COBOL, nor VB, was a lovely language, but it doesn't remove it's ability to be effective in the hands of a good programmer.

584792527[/snapback]

I guess that came out the wrong way :p

Performance wise it'll perform basically the same (a few simple tests have been done which shows VB.net generates slighly less efficient MSIL, but it's basically the same).

What I mean is that if you have a program in C#, it's extremely easy to convert it to VB.net (strict -> not so strict is easy). However, VB.net to C# is basically impossible (not so strict -> strict can cause problems).

Not to mention there are a lot of programmers coming from the C++/Java way, who pick up C# faster than VB.net.

Either could be used in an enterprise situation. However, I always lean towards the C# side :p

Link to comment
Share on other sites

  • 0
Link?

From personal experience, I'd have to say that .NET is excellent for enterprise apps. What is large scale? Number of users? What the app does? Number of devs working on it?

584790415[/snapback]

Oh ooo ooo one second i'll find it, i'm just merely re-stating what the person said, it was from an MS Employee i think, Don something... haha but yeah, i only read about it because i had to do a mini report on the IDE and had to find some bad aspects of it.

Well i found the dudes name Don Box, lol but here's blog archive is too big too search, but i also found a another link here:

http://blogs.msdn.com/csharpfaq/archive/20...3/11/87816.aspx

Quoted : "The VB.NET part of Visual Studio .NET compiles your code in the background. While this is considered an advantage for small projects, people creating very large projects have found that the IDE slows down considerably as the project gets larger. "

Link to comment
Share on other sites

  • 0
I guess that came out the wrong way :p

Performance wise it'll perform basically the same (a few simple tests have been done which shows VB.net generates slighly less efficient MSIL, but it's basically the same).

What I mean is that if you have a program in C#, it's extremely easy to convert it to VB.net (strict -> not so strict is easy). However, VB.net to C# is basically impossible (not so strict -> strict can cause problems).

Not to mention there are a lot of programmers coming from the C++/Java way, who pick up C# faster than VB.net.

Either could be used in an enterprise situation. However, I always lean towards the C# side :p

584793838[/snapback]

lol, coming from VB.NET then to Java then to Java to C# was funny, haha, C# as obvious to all is very similar syntax wise to Java, so that's one advantage, but i do get mixed up in between the two, like in C# i never realised accessing an ArrayList's elements would still be using the brackets, as oppose to using the get(index) method in Java.

Link to comment
Share on other sites

  • 0
Oh ooo ooo one second i'll find it, i'm just merely re-stating what the person said, it was from an MS Employee i think, Don something... haha but yeah, i only read about it because i had to do a mini report on the IDE and had to find some bad aspects of it.

Well i found the dudes name Don Box, lol but here's blog archive is too big too search, but i also found a another link here:

http://blogs.msdn.com/csharpfaq/archive/20...3/11/87816.aspx

Quoted : "The VB.NET part of Visual Studio .NET compiles your code in the background. While this is considered an advantage for small projects, people creating very large projects have found that the IDE slows down considerably as the project gets larger. "

584794273[/snapback]

I trust Mr. Box. He's an amazing intellect.

Is this still the case with 2003? I googled and found people complaining only about 2002.

Link to comment
Share on other sites

  • 0
I trust Mr. Box. He's an amazing intellect.

Is this still the case with 2003? I googled and found people complaining only about 2002.

584796016[/snapback]

Yeah it's in fact still the case for 2003, i can't find the article sorry but i can clearly remember someone actually reporting it to the VS team about it, the response was, there was no direct fix because something about the way it was implemented is too deep down to have a fix for this sluggishness when the application gets larger and larger, and Don mentioned when in terms of larger, a hundred classes or so, because of the background compilation. It's most probably an addressed issue in Whidbey and i hope they fixed it :)

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.