.NOT My Views

[Karl E. Peterson]

Using '+' to combine bitflags is not a "best practice" in VB.NET .

Jest checking... ;-)

 

[Roger Rabbit]

How many lines of VB6 code would it takes to do this? And what would that
nasty ass bit of code look like?

contents = My.Computer.FileSystem.ReadAllText("c:\mytextfile.txt")


RR

 

[Abubakar]

There shouldn't need to be! It should just work!

But if the move is from COM/Win32 to .NET. Do we still think it should just
work? Can it be that easy?

-Ab.

 

[Abubakar]

The whole idea of a high-level language is that its syntax can be made

relatively independent of its platform. To address different platforms you
modify the compiler, not the language!

Correct, but in this case the platform in question is just one and that is
..net and maybe they wanted visual basic to appear as #1 language (and i
remember them saying this #1-citizen-thing) and have a .net feel, which is
to have namespaces and classes, and everything being managed and so they
ended up with vb.net.

Hey thanks for writing about the history of version (breaking) changes.

-Ab.
http://joehacker.blogspot.com

 

[Ken Dopierala Jr.]

Sorry, sorry.

To any new programmers out there *always* use OR unless you know what you
are doing. In this case the code was ripped from a game programming API I
wrote in both VB6 and VB.Net. Unlike VB6, VB.Net addition & subtraction
operations are extremely fast. In fact, a quick search will point you to a
white paper showing that the VB.Net compiled runtime is faster in addition &
subtraction than not only VB6 but also C#, C++ (pick your flavor), and of
course Java *note this holds true for .Net 1.0 & 1.1 - I havn't tested 2.0
yet but I would imagine the C# & C++ compilers are now using the same
optimizations*. I ORed in VB6 because there is no net gain to using
addition, I added in VB.Net because the gain is quite substantial. While
the PlaySound API call won't benefit much, even in a loop, it is just a
force of habit I have to help my compiler along into creating the most
optimized runtime possible.

Of course the whole point of this is that codewise, calling API functions
requires no additional code in VB.Net and is actually easier and more
straight forward than in VB6. Ken.

 

[Karl E. Peterson]

Sorry, sorry.

To any new programmers out there *always* use OR unless you know what
you are doing. ^^^^^^

I feel like you misspelled "even if"... Hard to buy the rationale there, except in
*very* limited circumstances not at all like those demonstrated here.

Unlike VB6, VB.Net
addition & subtraction operations are extremely fast. In fact, a
quick search will point you to a white paper showing that the VB.Net
compiled runtime is faster in addition & subtraction than not only
VB6 but also C#, C++ (pick your flavor), and of course Java

And that sounds like a license violation against publishing benchmarks. Hmmm... ;-)

I really must wonder, though, how IL could possibly compete with ASM for such basic
operations. Smells rather fishy. This paper wasn't published by Microsoft, per
chance, was it?

While the PlaySound API call won't benefit much, even in a loop,

^^^^
And again, you seem to have misspelled "at all" -- HTH!

 

[Karl E. Peterson]

How many lines of VB6 code would it takes to do this? And what would
that nasty ass bit of code look like?

contents = My.Computer.FileSystem.ReadAllText("c:\mytextfile.txt")

If you don't know, why would you put yourself in the position of criticizing the
language in this thread? Isn't that one of the things your kind has most frequently
railed against?

 

[Kevin Provance]

See http://vb.mvps.org/vfred/unimess.asp for (deep) background. <

Wow. Very interesting. And for as serious as that issue must have been at
the time, it pales in comparison to the .NET mess. You'd think M$ had
learned their lesson the first time.

- Kev

 

[Rick Rothstein [MVP - Visual Basic]]

How many lines of VB6 code would it takes to do this? And what
would that

nasty ass bit of code look like?

contents =

My.Computer.FileSystem.ReadAllText("c:\mytextfile.txt")

If I understand its purpose, this is a VB6 solution...

Dim FileNum As Long
Dim Contents As String
FileNum = FreeFile
Open "c:\mytextfile.txt" For Binary As #FileNum
Contents = Space(LOF(FileNum))
Get #FileNum, , Contents
Close #FileNum

Rick

 

[Karl E. Peterson]

Wow. Very interesting. And for as serious as that issue must have
been at the time, it pales in comparison to the .NET mess. You'd
think M$ had learned their lesson the first time.

The problem seems to be one of institutional memory. The guys who *swore* they "got
it!" were gone by the time the later destruction was done.

"Need a new type of data? Create a new datatype!" Duh.

 

[mayayana]

(And all of these reasons not to move to .Net don't even
address the common complaints, such as the issue
of easily decompiled code and poor speed, the
problem of continual changes that require new, giant
runtimes, and the question of how .Net will weather
the changes of Avalon, WinFX, etc.

This makes little sense complaining about an OS thats not even been
commercially released as reason not to switch over to a development platform
that been in use for around 5 years.

You mean referring to Avalon and WinFX?
My point there was that it's a lot of work to
make a transition to a new language, yet .Net's
future doesn't seem clear. In Joel Spolsky's
article that someone linked to,
(http://www.joelonsoftware.com/articles/APIWar.html )
he seems to imply
that Avalon may obsolete .Net "Win Forms". And
he characterizes Avalon/WinFX as a second major
break with foregoing standards:

"And if you're developing a Windows GUI app today using Microsoft's
"official" latest-and-greatest Windows programming environment, WinForms,
you're going to have to start over again in two years to support Longhorn
and Avalon. Which explains why WinForms is completely stillborn. "

Hanging around "here" is actually a dotnet newsgroup. Its odd that you
should come to one and complain that there are so many pro dotNetters on
board.

My mistake. It's actually both. This thread is posting
to a VB6 group and a .Net group simultaneously. But
I wrote the last post before realizing that. The VB6 group
has been active with two similar threads this week, and
I thought this was a third. There's almost always a riled
.Netter around whenever a .Net criticism is posted in
the VB6 group. This week it's a character going by the
name of "Michael C." who's been dropping by periodically to
post inspired arguments along the lines of ".Net rules
and your grandmother wears army boots."

 

[Ken Dopierala Jr.]

You can always tell when Karl gets paranoid. He starts to knock your
spelling. Your "even if" doesn't exactly fit, but I'll give you a mulligan
Karl, I can tell you are stressed. ;-}

As for the benchmarking, don't complain to me Karl. I didn't write it and I
didn't link it. Even if I had I doubt any Microsoft lawyers would be
beating down my door. I also didn't mention ASM or inline ASM and neither
did the benchmarks. But if you were to take things to the extremes I'm sure
you could beat the times with good old GWBasic and a few peeks & pokes.
Couldn't reference much memory but you could definitely loop faster.

The rationale is pretty plain. Games require speed, speed requires
optimization, compilers require you to know what is going on behind the
scenes to help them optimize. Build on top of APIs like WIN32, Fastgraph,
and FMod and you'll pull out all the stops to achieve the best frame rate
and smoothest game play possible. Plus, it's just fun to create the
tightest code. At least it is for me. But I spose that if you chose the
wrong tech path 5 years ago and pigeon-holed both yourself and your clients
then you have a good reason to sweat.

But don't sweat it Karl...you could always become a spelling teacher! ;-}

Good luck! Ken.

 

[Karl E. Peterson]

Clearly, .not. And, given that one of the main designers of VB#
considers platform changes a prime time for "cleaning up" the
language, it would be a suckers bet to put money (aka: code) on the
line betting that it wouldn't happen again (again).

Heh, well, clearly these guys aren't liberal arts (history, eg) majors!

 

[alpine]

Wow. Very interesting. And for as serious as that issue must have been at
the time, it pales in comparison to the .NET mess. You'd think M$ had
learned their lesson the first time.

Clearly, .not. And, given that one of the main designers of VB#
considers platform changes a prime time for "cleaning up" the
language, it would be a suckers bet to put money (aka: code) on the
line betting that it wouldn't happen again (again).

Bryan
_______________________________
Bryan Stafford
New Vision Software
newvision_don'(e-mail address removed)

 

[Ralph]

The problem seems to be one of institutional memory. The guys who *swore* they "got
it!" were gone by the time the later destruction was done.

"Need a new type of data? Create a new datatype!" Duh.

In 1999 and 2000 prior to the release of .net, MS was farming out a ton of
work on VB and associated technologies to outside consulting firms and
reducing in-house staff in these areas. At the time I thought it was
strange, but assumed it was to release more people for W2K and the big
Security push. VB contacts were disappearing right and left.

Talk about having one's head in the sand. <g>

-ralph

 

[Karl E. Peterson]

You can always tell when Karl gets paranoid. He starts to knock your
spelling. Your "even if" doesn't exactly fit, but I'll give you a
mulligan Karl, I can tell you are stressed. ;-}

Heheheh... Taken in good spirit. Cool.

As for the benchmarking, don't complain to me Karl. I didn't write
it and I didn't link it.

I'm not complaining, really. Just wondering aloud why one might be inclined to
believe it. If you do have a link, though, I'd be curious to look. On the face of
it, the claim seems absurd.

Even if I had I doubt any Microsoft lawyers
would be beating down my door.

I also didn't mention ASM or inline
ASM and neither did the benchmarks.

But, that's what VB6 and C++ compile to, so you did if only by implication. (I mean,
the benchmark wasn't comparing execution speeds within the IDE, was it?)

But if you were to take things
to the extremes I'm sure you could beat the times with good old
GWBasic and a few peeks & pokes. Couldn't reference much memory but
you could definitely loop faster.

The rationale is pretty plain. Games require speed, speed requires
optimization, compilers require you to know what is going on behind
the scenes to help them optimize. Build on top of APIs like WIN32,
Fastgraph, and FMod and you'll pull out all the stops to achieve the
best frame rate and smoothest game play possible. Plus, it's just
fun to create the tightest code. At least it is for me.

Oh, don't get me wrong! I over-optimize all the time, too. It's a trap I've come to
(at least try) recognize before I spin too many needless cycles. You seem to have
taken me a bit more seriously than I was taking myself?

Later... Karl

 

[Someone]

My view of this thread or any similar thread:

http://www.thegardenhelper.com/catmouse.gif

Not a useful thing to do, been there done that.

 

[Roger Rabbit]

My kind? Get a grip Karl. Its just a newsgroup thread.

It was a rhetorical question not meant to illicit a "how-to" response but
rather to demonstrate how simple developing in a .Net environment has
become..."out of the box".

RR

 

[Kevin Provance]

I toyed with .FRED here and there and honestly, I would prefer to write a
few lines of solid VB classic code then to have to remember
My.Computer.Drives.Folder.Files.This.That.TheOtherThing.etc. to acheive one
goal. Even with Intellisense it's still basically (no pun intended) a
completely different syntax for which would require endless poking and
proding in the Object Browser (if .NOT even has one) just to make sure I'm
"doing it right".

Besides, I think the VB Classic MVP's have it right...by the time I tortured
myself into learning all that new syntax, M$ will replace .NET with
something else that will break my code yet a second time. I have better
things to do than to re-learn everything I've ever known because M$ thinks
that's what it is our best interest. Unfortunately for myself, I'm one of
those people who doles out second chances on a very limited basis when my
trust has been deliberately stomped on and thrown away like an empty old
paint can. <g>

- Kev

 

[Stefan Berglund]

oh ok, now its clear. I thought everyone from vb6 wanted to stick to win32.

Some of us do. What's wrong with Win32?
Underneath your .Net classes, somewhere, is
an equivalent to Win32 level.

Is it not possible in vb.net to write desktop applications like vb6?

Not very. It strikes me that this point just doesn't
seem to come up in the minds of most .Net users.
If it were not for Microsoft's strategy and tactics then
it would not even occur to anyone to discuss VB vs.
.Net. They're not for the same thing. This whole argument
is happening out of context.


For one good explanation of why .Net doesn't fit well
on the Desktop see Mark Russinovich's article:
http://www.sysinternals.com/blog/2005/04/coming-net-world-im-scared.html
]

My own situation: I taught myself VB, starting
out leaning heavily on OCXs and gradually
learned better, leaner coding. I write "shareware".
I don't make a lot of money at it but I enjoy coding
and I like making something that's useful to others.
My main program is an HTML and script editor
that's quick, light, free of dependencies (other
than the VB6 runtime) and has an installer of
about 800 KB. To my mind it's progress to cut
out the OCX middleman where that's feasible.
VB6 gives me the ability to do that, while still providing
easy methods where and when I want them.

What do I get if I move to .Net? First I lose
about half of my potential customer base right
off the bat, because dial-up users are not going to
download 25 MB runtimes and 12MB specialty
programs. Then I lose another 25% because many
people won't deal with the added complexity of
needing to download and install a runtime. I also lose
any ability to write for Windows 95. So now I've
got maybe 20% of my possible base left.

Beyond that, I'm
getting back into the bloat and inefficiency of objects
that are twice- or thrice-removed from the API. Why
would I want to do that? I like using the API. I like
using Windows. I don't want to be led gradually to some
sort of future X-Box/Vista crap hybrid that won't let me
access the system directly.

(And all of these reasons not to move to .Net don't even
address the common complaints, such as the issue
of easily decompiled code and poor speed, the
problem of continual changes that require new, giant
runtimes, and the question of how .Net will weather
the changes of Avalon, WinFX, etc. The thing is already
in its third rendition and now MS has plans for more
big changes with Vista.)

To my mind it borders on bizarre that so many people
using .Net keep hanging around here like religious
converts (or maybe MS plants) doing a .Net sales
pitch. I wish that people would try to just think for
themselves a bit, do what's best for their own case,
and not worry so much about what everyone else
is up to.

To anyone who says that the Desktop is old
hat and that I should be thinking about web-based
software: Maybe you're right, maybe you're not. Either
way, I have no intention of following such a path using
Microsoft software.

Well said and Ditto!