Why VB 6.0??

Quote:

---

Originally Posted by WillAtwell

So I take it that you disagree with the restriction that was placed on VB6 about using apis?

No. If I was racing on foot then that would indicate that I was supposed to remain on foot. If I got on a bike I would be cheating and would get disqualified.

Who would enter a foot race of 1500 miles?

The point is that if you let one racer use a race car and force the other to run on foot in wooden shoes it is not a valid contest.

---

I'm not talking about racing on foot - THIS IS THE POINT.

Don't restrict yourself to racing on foot.

The contest is wide open - if you have another mode of transportation, use it if it helps.

Don't bother comparing the details of the transportation in a contest like this. Does a preference of nylon laces on running shoes matter if the contest allows the use of automobiles?

I don't care if one framework uses api's (either internally or externally). What I do care about at the end of the day is how much code I need to write and how much knowledge I need to have to write the code. I'm going to take the easiest way to get to the destination - every time.

Quote:

---

Originally Posted by Arjay

Again the point is missed.

---

That's my line!

Quote:

---

Originally Posted by Arjay

We are talking about a contest where the only rule is that you have to arrive at the destination and the one who arrives fastest is the winner.
How you get there is up to the contestent.

---

Does this mean that rather than tiling the image via code, I can tile an image in an image editor, and simply apply the results of it to the form at runtime?

Does this mean we should set X = 10 rather than incrementing it up to ten in a loop, and claim it is equivalent?

Quote:

---

Originally Posted by Arjay

I don't care if one framework uses api's (either internally or externally). What I do care about at the end of the day is how much code I need to write and how much knowledge I need to have to write the code. I'm going to take the easiest way to get to the destination - every time.

---

Don't you mean the way which results in the fastest execution? If so, then how do you know it's faster unless it also does the same work along the way?

No matter. I can see the last several posts are getting us no closer to what we want to know. We can post back and forth forever, but actual test results on a .net rewrite of my second code sample are still forthcoming.

Feel free to rewrite my second example in .net. As of yet, nobody has stepped up to the challenge.

There are all sorts of different comparisions. And they all indicate different things. (As I have said before).

The main reason I have taken the standpoint I have is, that if you were to port VB 6.0 to another platform (non-Windows), the API's are specific to Windows, and therefore any code which used the API's would not function on the new platform.

On the other hand, when .NET HAS been ported to other platforms, the entire framework is ported. So any C# or VB.NET program (that does not use PInvoke) WILL function on the new platform.

THe same principal applies even for upgrades. When a new version of an OS is released (and potentially at any Service Pack), new functions may be added (with the old ones still available).

If you coded in VB6.0 (using "declare") then you have to MODIFY YOUR PROGRAM.

If you coded in .NET, the new version of the framework can include these changes (this happened between 1.1 and 2.0 and again at 2.0 to 3.0). This means that your new program makes use of the new OS functions WITHOUT MODIFICATION (or even re-compilation!!!).

THIS IS A HUGE DIFFERENCE.

So the only way to factor this out is to restrict usage to those items that SHIP WITH the item being evaluated, and for VB6.0 this effectively eliminates the use of external API calls.

Okay I step out for the day, and the conversation goes to s***.

The whole point here is to compare the VB6 CORE to the VB.NET CORE..

I.E. the foot race, lets put two guy's at the start line, One uses 'Nike' trainers, the other 'Adidas' trainers. Now jumping onto a bike or into the car does not help us to see what pair or shoes are better..

This test is not about finding the fastest way to complete the given task, its not about best practice, it's about CORE speed. We want to see how does VB6 and .NET compare on identical methods, or near identical code..

@Wizbang: I'm a little busy, however i will be doing some code during the weekend to compare to the new VB6 Code..

@CPUWizard: You are right in saying using API's is not programming IN VB, Using API's is passing the task's back to the OS. However this subject is very touchy..

@Joeman: When writing a App in VB, using any external DLL, API, Library is not 'TRUE' VB code and is acctually a hybrid. If the DLL was written in C then your proggy is VB & C mix, Not 'True' VB..

@Arjay: If the point of this test was about getting the equivalent work done, then .NET won it hands down. However this same code, did not do the equivalent work, It did no work, it passed ALL the work to the OS.

Quote:

---

Originally Posted by TheCPUWizard

The main reason I have taken the standpoint I have is, that if you were to port VB 6.0 to another platform (non-Windows), the API's are specific to Windows, and therefore any code which used the API's would not function on the new platform.

On the other hand, when .NET HAS been ported to other platforms, the entire framework is ported. So any C# or VB.NET program (that does not use PInvoke) WILL function on the new platform.

---

I agree with this, but wouldn't I likely know ahead of time if I'm going to be porting it? So let's just say for the sake of argument, that the examples I posted are not intended to be ported to any other platform. Since windows seems to have such a large market share anyway, I figure I can focus my efforts there, giving up a few extra customers in favor of an app that is more appealing, because I can get that added performance using API. If my app is better optimized, that'll bring in more sales too. Besides that, if I'm using VB6, then by default I'm not porting (though there's Mono and other stuff out there to make it possible, not to mention RealBasic, which imports VB6 code, and is portable).

Just the same, I am planning to put together an example of something which just runs some time-intensive algorithm or something like that. Maybe even just a big loop. But first I want to see the .net rewrite of my second example. No sense uploading a bunch of stuff nobody is willing to test.

Quote:

---

Originally Posted by GremlinSA

The whole point here is to compare the VB6 CORE to the VB.NET CORE

---

As the starter of the thread, dont I get any input in what MY intentions were for starting it??? :confused: :confused: :confused: :confused: :confused: :confused: :confused: :confused:

At best, "core speed" is a 4th order concern. Even when I am doing "true real time" (Missle Guidance, Ion Beam Control, etc), as long as the code runs fast enough to meet the specification (+ a safety margin), then I do NOT do anything to optimize the performance.

What has kept my company in business since 1984 (and having used nearly EVERY language/platform combination over that time) is being able to write the most COST effective code. This means reliability, maintainable, and ease of development.

Now if it could be shown that VB.NET has significant (orders of magnitude) performance issues over VB 6.0 then it would potentially indicate that it would not be a "good choice" for many situations. However, this is not the case. In fact, the performance article I am writing (links previously posted to a partial first draft) show that (properly used) VB.NET can and does achieve performance metrics suprisingly close to native C++.

Since mearusring development effort between people working remotely and asynchronously is virtually impossible, the best one can typically do is to use an approximation of code complexity. In general a larger more complex program took longer to write than a (much) shorter counterpart. Also when person Y has to maintain code written by person X, the size of the program can roughly correleate to the amount of time Y will have to spend analyzing the program before there is good understanding.

Along the same lines, using multiple technologies is indicative of a program being "more complex". If I were to poll 25 "super expert VB6.0 developers", I am sure that all of them would have used external API's to some degree. If I then asked them to list the top 20 they used, I am equally confident that there would be some calls that some of the other developers had never even heard of.

If I have a custom program that uses (arbitrarily) 50 API calls, I will almost certainly have to engage multiple "expert VB 6.0" programmers (who individually know 100% of VB 6.0 itself.

On the other hand, if I have a program written in .NET, and have 1 person who knows 100% of .NET, then that ONE person will have a working knowledge in everything used in the program.

Now I am the first to admit, that finding someone who has actually studied the Framework libraries from start to finish is difficult. It took me about 2 years (part time) to go through EVERY class in 1.x, about 9 months for 2.0, and about 3 months for 3.5.

I agree that this subject is "touchy" and does raise peoples emotions. I also enjor vigorous (informed) debate. But I do find it very fustrating (and anoying) when people pontificate on a subject (not just .NET or even computers) when they have not personally made a detailed study of the subject.

Quote:

---

Originally Posted by GremlinSA

This test is not about finding the fastest way to complete the given task, its not about best practice, it's about CORE speed. We want to see how does VB6 and .NET compare on identical methods, or near identical code..

@Arjay: If the point of this test was about getting the equivalent work done, then .NET won it hands down. However this same code, did not do the equivalent work, It did no work, it passed ALL the work to the OS.

---

Very succinctly put.

Quote:

---

Originally Posted by Arjay

I don't care if one framework uses api's (either internally or externally). What I do care about at the end of the day is how much code I need to write and how much knowledge I need to have to write the code. I'm going to take the easiest way to get to the destination - every time.

---

(Emphasis added)
If you had Two people with NOT knowledge of VB (and flavor), .NET (any language), or WINDOWS....


Person #1
You go to a class where they teach you EVERYTHING about VB6.0. This would obviously include the usage of "declare" statements, but it would be a different course that taught you all about the Windows API's (and even more courses for other API's, possible by different training organizations)

Person #2
You go to a class where they teach you EVERYTHING about .NET (using only VB.NET s the programming language - no mention of C#, C++/CLI, etc)


Now you have a requirement for a custom program. You need to quickly, you need it to be very reliable. And you need it to meet some (fairly tight) performance specifications....

Which developer would you choose????

Quote:

---

Originally Posted by TheCPUWizard

As the starter of the thread, dont I get any input in what MY intentions were for starting it??? :confused: :confused: :confused: :confused:

---

Sorry this is the part of the thread that Wizbang and myself hijacked, when it came to point of Speed comparison.. ;) :p :wave:

Quote:

---

Originally Posted by TheCPUWizard

At best, "core speed" is a 4th order concern. Even when I am doing "true real time" (Missle Guidance, Ion Beam Control, etc), as long as the code runs fast enough to meet the specification (+ a safety margin), then I do NOT do anything to optimize the performance.

What has kept my company in business since 1984 (and having used nearly EVERY language/platform combination over that time) is being able to write the most COST effective code. This means reliability, maintainable, and ease of development.

---

Fine for you, and your business. I'm glad you've got a model that works for you. But again it isn't about cost here, nor ease of development, but it IS about comparing performance. That is one of the issues raised in response to your question of why VB6. So yes, expect the code posted to do more than just get by, since it is performance which is being compared.

Quote:

---

Originally Posted by TheCPUWizard

If I have a custom program that uses (arbitrarily) 50 API calls, I will almost certainly have to engage multiple "expert VB 6.0" programmers (who individually know 100% of VB 6.0 itself.

---

That is assumption, not fact. Plus you aren't going to know how many API calls (nor which ones) the program will use until it's completed.

Quote:

---

Originally Posted by TheCPUWizard

On the other hand, if I have a program written in .NET, and have 1 person who knows 100% of .NET, then that ONE person will have a working knowledge in everything used in the program.

Now I am the first to admit, that finding someone who has actually studied the Framework libraries from start to finish is difficult. It took me about 2 years (part time) to go through EVERY class in 1.x, about 9 months for 2.0, and about 3 months for 3.5.

---

I'm sure you still look things up from time to time, just like a VB6 programmer who uses API. Just like any programmer, period. With experience, the time it takes to refresh one's memory, or look something up is probably greatly reduced.

Quote:

---

Originally Posted by WizBang

Fine for you, and your business. I'm glad you've got a model that works for you. But again it isn't about cost here, nor ease of development, but it IS about comparing performance.

---

No the question was WHY.

Quote:

---

That is one of the issues raised in response to your question of why VB6. So yes, expect the code posted to do more than just get by, since it is performance which is being compared.

---

Performance is one metric out of many. And it really only matters at the "external" level. Consider a button click. The tightest specification I have ever seen for a response time is 100mS. So if one program takes 200mS and another takes 75mS it matters. But if one takes 75mS and another takes 7.5mS the difference is unimportant.

Quote:

---

That is assumption, not fact. Plus you aren't going to know how many API calls (nor which ones) the program will use until it's completed.

---

To some degree. But it is NOT a "wild guess" or arbitrary. If you have read my posts on other threads, I am a fig fane of re-use and of "isolation". As a result I have a set of VB6.0 classes in my archives that mbodied all of the API calls that I used over a 5+ year period of developing in VB. After excluding "speciality" cases (eg wrappers for a specific custom device), I countes 137 distinct API calls. I then looked at 4 projects that happened to still be online (each needed maintenance in the past 6 months). The number of distinct API invokactions ranger from 37 to 71.

Quote:

---

I'm sure you still look things up from time to time, just like a VB6 programmer who uses API. Just like any programmer, period. With experience, the time it takes to refresh one's memory, or look something up is probably greatly reduced.

---

I happen to have near eidetic memory (especially for technology, but lousy at names.. :eek: ). Clients will often contact me about details of a program I did well over a decade ago, and I can still recall the specific classes and methods. But it is not about how I or any other developer happens to work.

What I would use as an indicator in this area (for this topic), is how many times do you have to uses something outside the IDE (after all the "I" is for integrated) to get the information you use.

Quote:

---

Originally Posted by GremlinSA

Sorry this is the part of the thread that Wizbang and myself hijacked, when it came to point of Speed comparison.. ;) :p :wave:

---

Not a problem as long as it is recognized that performance
(including different sets of "usable technology") is simply one of many things that should make up an answer to "Why?"

And, as I posted a few minutes ago, that the impact of performance differences is used as the qualifying value and not the "raw" performance.

If I had $1 for every embedded system I have seen where a DEDICATED system has been written using obtuse had to understand (often buggy) code in the name of "performance", only to find that the main loop spends 30% of the time running the code...followed by a "sleep" that counts for the remainder of the time. :eek: :eek:

Quote:

---

Originally Posted by TheCPUWizard

Not a problem as long as it is recognized that performance (including different sets of "usable technology") is simply one of many things that should make up an answer to "Why?"

---

Sure, And it truly is, there are many aspects to this question, and also a lot more answers than available in the poll.

We just trying to expand a little on some of the reasons given, offer some proof, debunk some assumptions.

Quote:

---

Originally Posted by GremlinSA

Sure, And it truly is, there are many aspects to this question, and also a lot more answers than available in the poll.

We just trying to expand a little on some of the reasons given, offer some proof, debunk some assumptions.

---

Complete agreement here :wave: :wave: :wave: :wave:

I should have added two more (I dont think I can go back now, and even if I did, the results would already be skewed) choice of:

1) There is a TECHNICAL reason I continue to use my licensed (but unsupported) VB 6.0

2)There is a BUSINESS reason I continue to use my licensed (but unsupported) VB 6.0

The reason why you use the .net is because it works for you. Fine, but it won't work for all of us. Now let's not forget about security in the business field again. TheCpuWizard promised some sort of article or post on how to protect the exe.