Will VB.NET be more stable than VB6?

[Kunle Odutola]

Ted wrote:
>>> Dim runner As New Thread(AddressOf MyThreadProc)
>>> runner.Start()
>>
>> It is.
>
> I am sorry. To start a thread is very easy, you are correct.

Thanks for the ackowledgement Ted but, I already knew I was right (as was
Tom). His comments were about starting a thread (re-read his post if you
have any doubts).

> To write a multithreaded application, well once again you are WRONG!!!

Are you really suggesting that anyone in the thread claimed a two line code
segment was to be considered a useful app (multithreaded or not)?.

> Threading seems to be something that VB couldn't make easy enough for
> VB developers. I think it was stated earlier in this thread how hard
> it was to do threading in VB in the past.

In some versions of VB -- it was relatively easier to do in VB5 than V6 for
instance. Reagardless, VB has never really supported multithreading.

>>> Unfortunately it's not that easy. Now they are tracking down us old
>>> C++ dinosaurs to explain deadlock, race conditions, starvation,
>>> priortization, TLS, synchronization, and the list goes on.
>>
>> Which you learned from a book (or asked a friend or maybe in a
>> class) a while back right?.
>>
>
> Oh then I'll just throw some books their way. Unfortunately there
> are no books that were written with VB and threading in mind, that I
> know of.

Not suprising since most VB.NET books include material on multithreading
anyways. Try Doug Lea's book. It should be easy to apply the concepts to the
..NET platform.

> Unfortunately Kunle, I didn't learn from a book or even a
> class and I **** sure know I didn't learn it from a VB developer.

Your loss -- assuming you aren't lying through your teeth about not having
relied on a book/article or class for learning this topic (which I believe
you to be).

> I have had to learn through trial and error because quite frankly there
> are no good books on multithreading( the right way ) on the market.

You learned all about concurrency and multithreading through trial and
error. Really?. I believe you Ted. Really. No, no,...I mean REALLY!

As for books, just a couple from my shelf (the nearest ones as I can't be
bothered to get up):

Principle of Concurrent Programming by Ben-Ari -- printed in the 80's
Principle of Concurrent and Distributed Programming by Ben-Ari -- printed in
the 90's
http://stwww.weizmann.ac.il/G-CS/BENARI/

Structured Concurrent Programming with OS applications by Holt et al --
another from way back

Concurrent Programming with Java by Doug Lea -- very good for concurrent
programming patterns

And a few links too...

http://www.accu.org/bookreviews/publ...el_systems.htm
http://www.langer.camelot.de/Resourc...iThreading.htm

> Oh I am sorry we had a race condition that caused that line to go
> berzerk.

<*yawn*>

> Once again, thanks Kunle for your insight. I will go ahead now and
> update my resume to state that I now know multithreading in VB.NET.

Once you've learned multithreading Ted, applying the concepts to a new
system is [usually] a simple undertaking. It is certainly trivial for Java
and .NET.

Kunle

[Ted]

>Thanks for the ackowledgement Ted but, I already knew I was right (as was
>Tom). His comments were about starting a thread (re-read his post if you
>have any doubts).

Unfortunately I wasn't commenting on his post to begin with(re-read my post
if YOU have any doubts).

>Are you really suggesting that anyone in the thread claimed a two line code
>segment was to be considered a useful app (multithreaded or not)?.
I believe you came back with "It is".

>In some versions of VB -- it was relatively easier to do in VB5 than V6
for
>instance. Reagardless, VB has never really supported multithreading.

I'll put this in terms you will understand -- DGAS(don't give a ****).

>Not suprising since most VB.NET books include material on multithreading
>anyways. Try Doug Lea's book. It should be easy to apply the concepts to
the
>..NET platform.
Yes and I would be willing to wager 95% never mention when to use multithreading
or the dangers.

>Your loss -- assuming you aren't lying through your teeth about not having
>relied on a book/article or class for learning this topic (which I believe
>you to be).
Oh come on. I said I didn't learn from a book which was what you implied.
Believe me.

>You learned all about concurrency and multithreading through trial and
>error. Really?. I believe you Ted. Really. No, no,...I mean REALLY!

Again, DGAS.

>
>As for books, just a couple from my shelf (the nearest ones as I can't be
>bothered to get up):
>Principle of Concurrent Programming by Ben-Ari -- printed in the 80's
>Principle of Concurrent and Distributed Programming by Ben-Ari -- printed
in
>the 90's
>http://stwww.weizmann.ac.il/G-CS/BENARI/
>
>Structured Concurrent Programming with OS applications by Holt et al --
>another from way back

Another unfortunate statement. You see, my college textbooks went back to
the FSU bookstore. Didn't need them then and haven't a need for them now.
I now buy my books by reputable industry experts not some kook teacher.
I am assuming this author is an instructor that you had to kiss his *** to
get your 'A' in school?

>Concurrent Programming with Java by Doug Lea -- very good for concurrent
>programming patterns
Good for concurrent programming, hmm you can read the title?

Here's a link for you:
http://www.accu.org/cgi-bin/accu/rvo...&file=c000307a

This says get Java Threads. Hmm. I have that, it's a POS. Worthless. Garbage.
I believe the comment was that it was better than average. Average is crap
when it comes to books on this topic.

>http://www.accu.org/bookreviews/publ...el_systems.htm
>http://www.langer.camelot.de/Resourc...iThreading.htm

>Once you've learned multithreading Ted, applying the concepts to a new
>system is [usually] a simple undertaking. It is certainly trivial for Java
>and .NET.

Once again you continue to amaze me. The idea is about learning multithreading.
Before you move to something as simple as Java and .NET threading you are
assuming people already knew threading to begin with. And you should read
the post that I was replying to.

Now leave me alone dumbass.

[Mike Mitchell]

On 24 Sep 2002 18:08:59 -0700, "Ted" <ttt@ttt.net> wrote:

> And I really hate to agree with him.

Ah, well. Everyone hates to agree with me, Ted! It's like when you
have to agree with mom when she tells you to go to bed 'cos you've got
school tomorrow.

MM

[Mike Mitchell]

On Wed, 25 Sep 2002 08:58:20 -0600, "Tom Shelton" <toms@dakcs.com>
wrote:

>........... Have you seen the
>code necessary to make a thread work in VB6? It is actually easier in
>VB5...

Have you heard about all those hundreds of thousands of classic VB
apps that echewed threads? Eleven years of fantastic development from
over three million developers, yet suddenly threads are the be all and
end all! Man, we gotta have threads! Our apps ain't done till all the
threads run! Hey, sugar, cain't come out tonite! Gotta sync some
threads...
....and then there was OOP! (Omigod...)

MM

[Kunle Odutola]

Ted wrote:

> Unfortunately I wasn't commenting on his post to begin with(re-read
> my post if YOU have any doubts).

Perhaps you need to re-read your own post (and the code snippet copied from
Tom's post).

>> Are you really suggesting that anyone in the thread claimed a two
>> line code segment was to be considered a useful app (multithreaded
>> or not)?.
> I believe you came back with "It is".

"It is" -- as in it is all you need to start a thread.

>> Not suprising since most VB.NET books include material on
>> multithreading anyways. Try Doug Lea's book. It should be easy to
>> apply the concepts to
> the
>> ..NET platform.
> Yes and I would be willing to wager 95% never mention when to use
> multithreading or the dangers.

Hope you can afford whatever it is you've just lost on that wager.

>> Your loss -- assuming you aren't lying through your teeth about not
>> having relied on a book/article or class for learning this topic
>> (which I believe you to be).
> Oh come on. I said I didn't learn from a book which was what you
> implied. Believe me.

Re-read my comments. [I did add "article" which I missed before.]

>> As for books, just a couple from my shelf (the nearest ones as I
>> can't be bothered to get up):
>> Principle of Concurrent Programming by Ben-Ari -- printed in the 80's
>> Principle of Concurrent and Distributed Programming by Ben-Ari --
>> printed
> in
>> the 90's
>> http://stwww.weizmann.ac.il/G-CS/BENARI/
>>
>> Structured Concurrent Programming with OS applications by Holt et al
>> -- another from way back
>
> Another unfortunate statement. You see, my college textbooks went
> back to the FSU bookstore. Didn't need them then and haven't a need
> for them now. I now buy my books by reputable industry experts not
> some kook teacher. I am assuming this author is an instructor that
> you had to kiss his *** to get your 'A' in school?

<*yawn*>

I take it you now acknowledge the existence of good books on the subject.
You claimed there weren't any.

>> Concurrent Programming with Java by Doug Lea -- very good for
>> concurrent programming patterns
> Good for concurrent programming, hmm you can read the title?

I said "very good for concurrent programming *patterns*", Ted. Not all such
books deal with patterns explicitly or clearly.

> Here's a link for you:
>
http://www.accu.org/cgi-bin/accu/rvo...ystems&file=c0
00307a
>
> This says get Java Threads. Hmm. I have that, it's a POS.

It says "get Java Threads if you can't (or don't want to) afford this". The
book is rated "Highly Recommended".

> Worthless. Garbage. I believe the comment was that it was better
> than average. Average is crap when it comes to books on this topic.

The comment is that it is "(much) better than average". I believe this is
due to basing it on Java.

>> http://www.accu.org/bookreviews/publ...el_systems.htm
>> http://www.langer.camelot.de/Resourc...iThreading.htm
>
>> Once you've learned multithreading Ted, applying the concepts to a
>> new system is [usually] a simple undertaking. It is certainly
>> trivial for Java and .NET.
>
> Once again you continue to amaze me. The idea is about learning
> multithreading. Before you move to something as simple as Java and
> .NET threading you are assuming people already knew threading to
> begin with. And you should read the post that I was replying to.

BTW, I didn't mean to imply you don't know multithreading (I don't know if
you do or not). I meant:

"Once a person has learned multithreading Ted, applying the......"

Incidentally, what in your opinion is missing from the threading model in
..NET and Java that makes books/literature/classes that target these
platforms unsuitable for learning multithreading?

> Now leave me alone dumbass.

<*yawn*>

Kunle

[Jason]

Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
>On 24 Sep 2002 18:08:59 -0700, "Ted" <ttt@ttt.net> wrote:
>
>> And I really hate to agree with him.
>
>Ah, well. Everyone hates to agree with me, Ted! It's like when you
>have to agree with mom when she tells you to go to bed 'cos you've got
>school tomorrow.
>
>MM

Yeah, but the difference is that mom usually has a valid point to make, and
it is based on years of actual experience. With you, it is more like those
psychics who make 1,000 outlandish predictions for the coming year and then
gloat when one of them comes true.

[Jason]

Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
>On 24 Sep 2002 02:43:37 -0700, Rune Bivrin <rune@bivrin.com> wrote:
>
>>Mike Mitchell <kylix_is@yahoo.co.uk> wrote in
>>news:l6d0pus56dpp3v7ii34jcm6m1lkkv0ihch@4ax.com:
>>
>>> 'Course, this ignores fact that VB devs "got by" for years without
>>> worrying about threads, even managing to produce one or two useful
>>> apps in the process...
>>>
>>> MM
>>
>>So have COBOL programmers for decades. What's your point?
>
>Better ask the .Netizens! They're the ones who keep talking up the
>threads issue.
>
>MM

Mike, just because YOU don't understand why threads are important, or why
inheritance is important, or why a host of other new things are important,
does not mean they are not important. It just means you don't understand
why they are important.

The people out here who are happiest about having threads are not those that
"theoretically" think it might be a good idea to write everything using threads.
And by the way, it's not a good idea.

Threads have limited use on the client. Actually, there are some very good
things you can do in a limited number of specific applications on the client.
Servicing a socket connection that has multiple sinks and sources comes
to mind. But for the most part, people will continue to write their client
apps fully single threaded (or won't use threads outside of what the .NET
framework already provides, transparently).

On the server, though, it is a different story. Most apps that have to deal
with 10,000 users simultaneously, or even 100, need some degree of multithreading.
In this respect, Java kicks VB6 in the seat of the pants. VB.NET can hold
its own against Java, allowing you to create new threads, or, in the more
common case, allowing you to create objects that can be consumed in a free-threaded
environment (thread-safe).

[Jason]

"Eddie Burdak" <eburdak@pilatus-aircraft.com> wrote:
>Dan,
>
>Dan Barclay wrote:
>
>Some minor points.
>
>>> VB6, and all its predecessors, were so tied in to Windows that any
>>> major change to Windows broke the language.
>>
>> You have *got* to be kidding!
>
>Bugger I missed that one. I wonder what major changes he was referring
>to. My one and only VB3 Database program developed on a Win 3.1
>machine runs very happily under 95, NT4 and XP. 98 and Me it wasn't
>tried on as the wife gave up the librabry - NT3 and XP because someone
>else took it up again.My non Database applications worked happily on
>everything from 3.1 and upwards.
>
>Perhaps he may be referring to use of the Win API- I could imagine
>that causing some grief.

I used VB3 (ported to VB4 16) to develop commercial industrial tester applications.
The interfaces to the equipment were VBX. There was no upgrade path.

Device drivers we had written for custom software no longer worked either.
These tied in to libraries that were tied to 16-bit windows.

Yes, with simple applications that worked entirely in the VB sandbox, and
for which Microsoft supplied all the components, the upgrade was possible.
Ugly, but possible. With VB.NET, you don't even get ugly.

[Jason]

Michael Bennett <mikey0131@mac.com> wrote:
>In article <3d8e8c8e$1@10.1.10.29>, jason@hotmail.com says...
>> Hey, even C++ can't move to .NET without breaking compatibility.
>Are you sure about this?
>I read in CUJ that if you don't violate the One Definition Rule C++
>compiles fine with the /CLR switch
>Not a C/C++ programmer so I can't personally verify this.
>
>Michael

C++ code in .NET is inherently unsafe code (pointers and all), so you aren't
really using .NET the way it is meant to be used. If you DO use the extensions
to C++, it no longer fits the standard. Weird set of compromises.

Microsoft COULD have allowed VB6 to run in .NET the same way. The VB compiler
is, after all, just the C++ compiler warmed over. But it would require the
.NET runtime as well as the VBRUN600.DLL, it would probably run more slowly
than natively VB6, and it would start up more slowly. And you would lose
most of the functionality of .NET by using it.

[Jason]

"Eddie Burdak" <eburdak@pilatus-aircraft.com> wrote:
>Jason,
>
><Mega snip .. sorry>
>
>> What happens when another paradigm shift comes along (like
>16-bit --> 32-bit
>> --> JIT)??? Hey, even C++ can't move to .NET without breaking
>> compatibility. The next big paradigm shift will probably break
>> backward compatibility as well. Nothing you can do about it, since
>> no one knows what the new ideas will be, so they can't plan for
>them.
>>
>> When will that be? 5 years? 10 years? Who knows? But I do
>believe
>> that as long as .NET exists, VB.NET will be supported, enhanced, and
>> backward compatible.
>
>And there's the crux. In 10 years the code gets broken again. It makes
>languages like COBOL and FORTRAN look good. Perhaps the hard core
>routines needs to be written in these languages and compiled to DLL's
>and the new .NEXT thingy used just as a front end.
>
>Eddie

COBOL works in .NET, and I think there is a FORTRAN compiler too. Java is
probably better from an OO point of view, and the J# implementation is very
capable.

Personally, I believe that C# has a lot of staying power. It combines everything
Microsoft learned from J++ and VB into one language, and some new stuff too.


I do not believe that C#, and likewise VB.NET, are like VB6. I look at VB6
and see a language that is kludged together from spare parts over a decade,
where no one ever took the time to fix what was broken. I see a language
that is tied to one operating system, built heavily around the strengths
and weaknesses of COM. I see a language that is under such a heavy load
of legacy that it can no longer adapt to even the tiniest change.

FORTRAN has a lot of legacy, but is not tied to an OS.

Same with COBOL.

Neither language is particularly pretty, and there are better choices.

Java has remained stable over a long time, and if you choose the right subset
(and it is a fairly broad subset, given the open source framework), your
program will run on .NET or any Java JVM.

C# is a good language. What I mean by good is that (1)it is not tied to
any operating system, by design, and (2)it is a clean, new design based on
thoroughly modern concepts. If you stick to the ECMA standard language elements
and syntax, you can write your core routines in C# and be fairly certain
they will still be viable 10 years from now, and run on Unix and other OSs.

VB.NET is also a fairly good language, though it has not been submitted to
ECMA. I am a little less certain of its stability over time, but I don't
see any reason why this language would ever be superceded by something like
FORTRAN or COBOL. I can see lots of reasons why you might prefer FORTRAN
or COBOL over VB6 for long-term viability, but not VB.NET.

Even so, Mono has a VB.NET compiler in the works. So the language is probably
here to stay.

Remember, the emphasis for VB, up until now, has never been the language.
It has always been about the GUI builder and the components, and automating
repetitive tasks. Makeing things simple enough so even a moron could be
at least a little productive with the tool. But they never really got around
to addressing the fact that there were serious limitations in the language
if you just happened to be a very good programmer. And they never got around
to cleaning up the language (until now) so that it was reasonably consistent
throughout.

But the good news is that if you DO have legacy libraries in VB6, you can
count on Microsoft to support the product for at least the next 10 years.
Small consolation to those seeking an upgrade path, but there are some architectural
decisions in VB6 that just can't be fixed. Sorry. So that kind of dooms
the language.

[Jason]

"Vlad Ivanov" <vb.@127.0.0.1> wrote:
>
>Thanks for pointing out to me the true evil source of horrible problems
that
>warranted ****ing up the language so much as to make all my codebase absolute
>to the point of forcing me to reconsider vendors.
>
>There was ofcourse the possible route of gradually upgrading a popular and
>powerful language through careful redesign, deprecation and such. By why
>beat around the bush, right? Evil such as this listed here needs radical
>measures.
>

I guess I should stick to the really evil stuff, such as:

The code is inherently unsafe, making it unsuitable for .NET.
The garbage collection schemes don't match.
Forms engines and components aren't even close, and need to be destroyed
and forgotten.
Empty, Null, Nothing, 0.
Variant Arrays versus Safe Arrays.
Varying support for Type.
Global Multiuse objects and all the problems there.
That nasty, kludgey ActiveX Control thing.
Degree in rocket science required to use most Windows APIs.
The fact that you have to use Windows APIs a lot to accomplish things that
should have been fixed long ago. Like try making your own Collection.
The menu editor and object model, unsuitable for anything but the simplest
of apps.

Speaking of reconsidering vendors, until .NET came out, I was trying every
way I could to drop VB6!

[Dan Barclay]

On 25 Sep 2002 15:56:43 -0700, "Jason" <jason@hotmail.com> wrote:

>
>"Eddie Burdak" <eburdak@pilatus-aircraft.com> wrote:
>>Dan,
>>
>>Dan Barclay wrote:
>>
>>Some minor points.
>>
>>>> VB6, and all its predecessors, were so tied in to Windows that any
>>>> major change to Windows broke the language.
>>>
>>> You have *got* to be kidding!
>>
>>Bugger I missed that one. I wonder what major changes he was referring
>>to. My one and only VB3 Database program developed on a Win 3.1
>>machine runs very happily under 95, NT4 and XP. 98 and Me it wasn't
>>tried on as the wife gave up the librabry - NT3 and XP because someone
>>else took it up again.My non Database applications worked happily on
>>everything from 3.1 and upwards.
>>
>>Perhaps he may be referring to use of the Win API- I could imagine
>>that causing some grief.
>
>I used VB3 (ported to VB4 16) to develop commercial industrial tester applications.
> The interfaces to the equipment were VBX. There was no upgrade path.

I used VB3 for a commercial platform application having to interface
to custom hardware and host interfaces only available in 16bit DLL's.
You call across the interface, wrapping in VB4/16COM if necessary,
until the interfaces are available in your "current native"
environment. If you've wrapped these interface calls in a single
wrapper function it's a piece of cake.

Before that we had to connect to custom hardware and network
interfaces in DOS. We went through the same process when we moved to
Windows, wrote some of the old hardware code ourselves, and put it in
our (existing) wrappers. No big deal so long as the rest of your
code doesn't have to be rewritten.

Compared to rewriting core business libraries, this issue is trivial.
I've been down that road many times. ****, we've *still* got
customers that are tied to a particular communications process who's
only access is via a 16bit DLL. FWIW, it's the *only* valid use I've
found for VB4/16, but it's damned important.

>Device drivers we had written for custom software no longer worked either.
> These tied in to libraries that were tied to 16-bit windows.
>
>Yes, with simple applications that worked entirely in the VB sandbox, and
>for which Microsoft supplied all the components, the upgrade was possible.
> Ugly, but possible. With VB.NET, you don't even get ugly.

With VB.Net you do it exactly the same way you did it last time.
Instead of VBX's call 'em COM or OCX's. You call across the
interface. If the custom software is under your control you can
rewrite it when you get time, if it's not then you're at the mercy of
the vendor and have to wait until they provide a native solution. In
the interim, you access it the same way you access anything else
across the boundary.

Dan
Language Stability is a *feature* I wish VB had!
(#6)
Error 51
Error 3
Error 9
....

[Dan Barclay]

On 25 Sep 2002 16:21:48 -0700, "Jason" <jason@hotmail.com> wrote:

>I look at VB6
>and see a language that is kludged together from spare parts over a decade,
>where no one ever took the time to fix what was broken. I see a language
>that is tied to one operating system, built heavily around the strengths
>and weaknesses of COM. I see a language that is under such a heavy load
>of legacy that it can no longer adapt to even the tiniest change.

It's unfortunate that you have no friggin' idea what you're talking
about. The core Basic language was valid from early implementations
and most of it was unchanged. Many code fragments from CP/M versions
still worked and almost all *could* work if they hadn't broken things
(completely unrelated to platforms) along the way.

So, you believe VBClassic was under a heavy load of legacy... as
opposed to COBOL or FORTRAN?

ROTFLMAO! Your insight simply astounds me!

>FORTRAN has a lot of legacy, but is not tied to an OS.

Nor is Basic. Basic is the *language*, VB is a *product* that
happened to use Basic.

>Same with COBOL.

Same for Basic.

>Neither language is particularly pretty, and there are better choices.

Basic is not a better choice. They keep breaking code. COBOL or
FORTRAN would be far better for applications expected to have long
lives.

<snip>
>Remember, the emphasis for VB, up until now, has never been the language.
> It has always been about the GUI builder and the components, and automating
>repetitive tasks. Makeing things simple enough so even a moron could be
>at least a little productive with the tool. But they never really got around
>to addressing the fact that there were serious limitations in the language
>if you just happened to be a very good programmer. And they never got around
>to cleaning up the language (until now) so that it was reasonably consistent
>throughout.

What a load of crap. Basic (the language) went through very serious
upgrading in late DOS versions, before there was a GUI at all.

>But the good news is that if you DO have legacy libraries in VB6, you can
>count on Microsoft to support the product for at least the next 10 years.

LOL! How do you define "library"?? When you get through with that,
maybe you'd want to define "support".

What do you do with a library, if not create new or extended
applications with it? Perhaps you're thinking about abandoning legacy
*applications* as opposed to libraries.

Libraries are a business asset.

> Small consolation to those seeking an upgrade path, but there are some architectural
>decisions in VB6 that just can't be fixed. Sorry. So that kind of dooms
>the language.

The architecture had essentially *nothing* to do with the changes to
Basic with VB.Net. Ask the VB dev team if you don't want to believe
me. They decided to make a few minor "cleanup" changes and it simply
got out of hand.

You're spinning an elegant story, but it's simply wrong.

Dan
Language Stability is a *feature* I wish VB had!
(#6)
Error 51
Error 3
Error 9
....

[Dan Barclay]

Jason, you're embarrassing yourself.

On 25 Sep 2002 16:33:53 -0700, "Jason" <jason@hotmail.com> wrote:

>
>"Vlad Ivanov" <vb.@127.0.0.1> wrote:
>>
>>Thanks for pointing out to me the true evil source of horrible problems
>that
>>warranted ****ing up the language so much as to make all my codebase absolute
>>to the point of forcing me to reconsider vendors.
>>
>>There was ofcourse the possible route of gradually upgrading a popular and
>>powerful language through careful redesign, deprecation and such. By why
>>beat around the bush, right? Evil such as this listed here needs radical
>>measures.
>>
>
>I guess I should stick to the really evil stuff, such as:
>
>The code is inherently unsafe, making it unsuitable for .NET.

Basic was the *only* safe language, until VB.net. Basic has had
"managed code" since CP/M versions. You had to make explicit low
level calls to get outside it.

>The garbage collection schemes don't match.

Garbage collection schemes, and how they work, aren't important. The
important point of garbage collection is that it works, not how it
works.

>Forms engines and components aren't even close, and need to be destroyed
>and forgotten.

***?

>Empty, Null, Nothing, 0.
>Variant Arrays versus Safe Arrays.
>Varying support for Type.
>Global Multiuse objects and all the problems there.
>That nasty, kludgey ActiveX Control thing.
>Degree in rocket science required to use most Windows APIs.
>The fact that you have to use Windows APIs a lot to accomplish things that
>should have been fixed long ago. Like try making your own Collection.
>The menu editor and object model, unsuitable for anything but the simplest
>of apps.

Yada, yada, yada. Man, you're clueless. Have you even done any
serious work with this stuff? Sheesh.

Dan
Language Stability is a *feature* I wish VB had!
(#6)
Error 51
Error 3
Error 9
....

[Jason]

Dan Barclay <Dan@MVPs.org> wrote:
>Yada, yada, yada. Man, you're clueless. Have you even done any
>serious work with this stuff? Sheesh.
>
>Dan
>Language Stability is a *feature* I wish VB had!
> (#6)
>Error 51
>Error 3
>Error 9
>....

I'm clueless as to why you think I am clueless. Yes, I have done serious
work. In fact, I still use VB6 regularly. There are some great things about
it, but there are also some serious limitations, and numerous bad design
decisions.

There are reasons why the number of VB job postings is far below that of
Java. There are reasons why Java is used in Computer Science classes, and
VB is not. Get your head out of the sand and take a look around. The programming
world is evolving, and VB-classic cannot do so any more. It is a dinosaur
in a mammal's world.