Some questions about VB.NET
tcarvin
done in VB6 or VB.NET. So I have a couple of questions to those of you who
have tried VB.NET.
First, is the current Beta stable enough to develop in? Are we likely to be
fighting the environment and language changes between betas, or has all that
be settled?
Second, the final release for VB.NET is fall of this year, right? Has anyone
heard anything to the contrary?
The last question is more of a feature question. Does VB.NET have an eqivilant
statement to CreateObject("CompName.ClassName")? Can you create arbitrary
objects given just its class name in String format?
Thanks for any insights!
Tom
Joe "Nuke Me Xemu" Foster
> We are starting a large project soon and I need to decide if it will be
> done in VB6 or VB.NET. So I have a couple of questions to those of you who
> have tried VB.NET.
>
> First, is the current Beta stable enough to develop in? Are we likely to be
> fighting the environment and language changes between betas, or has all that
> be settled?
The familiar debug capabilities have all gone buh-bye. Any changes you
make to the code while the program is running in the IDE will be ignored
until you stop and restart the program. Anything that implies otherwise
just causes an error. Beta 2 is supposedly "feature complete", but it's
still mutating faster than a Chernobyl game hen. Are you already familiar
with .NyET's nastier subleties, such as non-deterministic finalisation?
> Second, the final release for VB.NET is fall of this year, right? Has anyone
> heard anything to the contrary?
The "whisper date" seems to be 1st or 2nd quarter 2002.
> The last question is more of a feature question. Does VB.NET have an eqivilant
> statement to CreateObject("CompName.ClassName")? Can you create arbitrary
> objects given just its class name in String format?
I'd hope so. The documentation should be online at http://msdn.microsoft.com/
somewhere, though I've never been able to find where they're hiding the "VB7"
syntax reference, only the "C#" Java clone manuals.
--
Joe Foster <mailto:jfo...@ricochet.net> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
F. Haymes
I think that you need to wait at least 6 months after the final release for
the major bugs to be fix ( the ones that they did not find in testing).
Frank G. Haymes
tcarvin wrote in message ...
Lee Weiner
version) of VB.NET for a production application, you haven't been dealing with
MS products for very long. I personally won't use any MS product until SP3
(or SR3) is available. (Although Office97, SR1 was pretty stable.)
Lee Weiner
lee DOT weiner AT home DOT com
In article <cb08e2b1.0107...@posting.google.com>,
Larry Linson
developers who bleed. It's the teachers of teachers, the pundits, the
writers of add-ins, those who crave attention, and the dedicated masochist
who develop using a beta and hope (pray?) that the first release won't leave
them (not just bleeding but) spouting blood everywhere.
Given that everything in .NET is brand-new, there's no reason to believe it
will be any more stable and solid than, historically, other betas of massive
products have been (which is to say, not very stable and not very solid).
Some have suggested that Version 1 with a few Service Releases/Packs might
be suitable. Others have suggested that Version 2 or later would be a better
time to start using it, after the early adopters had done the bleeding,
found the errors, and there'd been time to get a substantial number of them
fixed.
In the interest of self-preservation, I think I'd tend to the latter view
more than the former. This is a truly ***MASSIVE*** undertaking.
"tcarvin" <NOtcar...@eudoramail.com> wrote in message
news:cb08e2b1.0107...@posting.google.com...
tcarvin
anyone's opinion. If we used VB.NET, the project will likely leave the design
stage in August/September. With a 6 month development cycle (which will
probably be a little longer knowing how things always seem to come up) I had
hoped that I could develop in the Beta 2, and by the time the product was done
the "real" VB.NET would be out (and with any luck SP1). I'm well aware of how
MS products tend to be when they first come out. But I also don't want to have
a new product with a 5 year life-cycle to be in VB6 if MS is going to jamming
VB.NET down our throats.
Thanks,
Tom
"Larry Linson" <larry....@ntpcug.org> wrote in message news:<fHQ27.2574$U45.7...@paloalto-snr1.gtei.net>...
Larry Linson
6 for "many years to come". I have not, repeat NOT, seen any specific date
mentioned. I, for one, believe The Boys and Girls in Redmond will support VB
6 not one nanosecond longer than they feel they have to. Some have quoted me
examples of products that _have_ been supported for years; I quote them
right back about support for VB/DOS.
If you believe there are features/functions in .NET that would be of
significant benefit, forge ahead. If you are just thinking about it because
it's the latest and greatest from Redmond, as many are, then I'd suggest you
wait -- not for SP1 or SP2, but at least for Version 2.
I've heard rumors of a Fall release for the initial version of Visual
Studio.NET, but rumors of a Fall release often dwindle away to a Spring or
Summer of the next year release, in actuality. It will, of course, be years
before the whole ".NET vision" is complete and released.
And, if the price I saw for BizTalk, min $2,500 - unlimited user license
$25,000, is typical of the ten (maybe more?) .NET servers, and you end up
needing all of them, that sounds like a $25,000 to $250,000 bite just for
.NET support on your server.
"tcarvin" <NOtcar...@eudoramail.com> wrote in message
news:cb08e2b1.01071...@posting.google.com...
Joseph T. Adams
If you feel you must develop for a platform that doesn't officially
exist yet, and is likely to change a LOT as it matures (if it takes
off at all), I would recommend considering one or more of the
languages that already are stable and in widespread use on the
Internet, rather than a brand-new language which *also* doesn't
officially exist yet. We have a lot to choose from that are known to
work on .NET: Java, C++, Python, Ruby, Perl, Smalltalk, and about a
dozen others. And with those languages you can take advantage of
whatever new things .NET has to offer (if any) without necessarily
being irrevocably tied to it if the hype doesn't pan out.
I have it on fairly good authority (a M$ sales rep for one of M$'
largest enterprise customers) that the VB.NET language is still
undergoing some significant changes, mostly to accommodate the
concerns of those of us who, like myself, want VB.NET to be as
compatible with VB as is possible within the new constraints imposed
by the CLR architecture. That is probably a good thing for the
billions of lines of legacy VB code out there, but it also means that
the initial release of VB.NET may not be as well-tested as it
otherwise would have been.
Joe
Larry Linson
saying what he thinks a particular client wants to hear -- aka "blowing
smoke". As far as I know, they recanted on only three items (as Joe Foster
said, "they plucked some low hanging fruit") that were the simplest things
to change that people had been screaming about: the limitation to only
zero-based arrays, accepting -1 as True, along with 1 which had been the
only True at the start, and one other that I forget. Not nearly enough to be
significant. They thought they could get by with tossing us a bone.
"Joseph T. Adams" <j...@apk.net> wrote in message
news:9iio9g$q80$1...@plonk.apk.net...
Joe "Nuke Me Xemu" Foster
> It may also mean that one cog in the Mighty Microsoft Marketing Machine is
> saying what he thinks a particular client wants to hear -- aka "blowing
> smoke". As far as I know, they recanted on only three items (as Joe Foster
> said, "they plucked some low hanging fruit") that were the simplest things
> to change that people had been screaming about: the limitation to only
> zero-based arrays, accepting -1 as True, along with 1 which had been the
> only True at the start, and one other that I forget. Not nearly enough to be
> significant. They thought they could get by with tossing us a bone.
Actually, I thought arrays would still be zero-based, unless you write a
wrapper class that won't otherwise act much like VB Classic arrays after
all, but you could specify the upper bound, not the number of elements.
So, something like Dim X(10) As Integer would get you an array with 11
elements, from 0 through 10. Of course, Integer is now 32-bit, so if you
want to use X to read a binary file written by a VB Classic program, use
the Vaseline, Luke...
--
Joe Foster <mailto:jfo...@ricochet.net> Got Thetans? <http://www.xenu.net/>
Larry Linson
accepted upper and lower limits and did all the translation and stuff.
That's the problem for me... when I ask for good reasons (e.g., how does it
make my job quicker or easier), all I get are "you _can_ develop much as you
do now", but sometimes you've got to write your own "Classic VB Classes",
which, of course, can't necessarily have the same names because those are
already pre-empted).
I'm afraid, so far, I'd rather write my own procedures or classes in VB6 to
make it behave any different way I want, than have to re-implement VB6 in
B-Flat, only with different keywords. That's a bigger job than re-creating
the Access bound-form/control features for unbound forms -- only because
there are so many differences in the new B-Flat language. Gee, I wish my
keyboard had a symbol close to the "flat" symbol in music. <G>
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:tkqm7nl...@corp.supernews.com...
Tom Shelton
then declare it as a Short (Int16). I know that breaks old code. And by
the way, they didn't really get rid of non-0 based arrays, that is just the
default. What they took away was the ability to specify it using the old To
syntax. Yes, I know option base 1 is gone, but you can always use the
System.Array.CreateInstance method to create an array with alternate bounds.
I really mean no disrespect, but VB.NET is really cool. It makes so many
things that used to be a pain in the butt easy, that I can't understand what
all the bitchen's about. There is going to be a transition period. All of
us probably will have legacy code to convert and apps to support, but
eventually once every thing is changed over this move is going to be good
for vb. And to be honest I am really pissed that microsoft gave in on the
things they did concede. The array declaration and the logical/bitwise
operator thing especially. And who gives a rats butt about the value of
TRUE. Geeze! Most languages (even basics) define it as 1. Why would it
make so much difference to anyone.
Tom Shelton
PS: Sorry, just had to vent a little. I really don't mean any offense by
anything said above.
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:tkqm7nl...@corp.supernews.com...
Joe "Nuke Me Xemu" Foster
> No offense, but you guys are really nit picking. If you want X to be 16-bit
> then declare it as a Short (Int16). I know that breaks old code. And by
> the way, they didn't really get rid of non-0 based arrays, that is just the
> default. What they took away was the ability to specify it using the old To
> syntax.
Not to mention the ability to pass the wrapped array to anything expecting
an array, like you can in VB Classic.
> Yes, I know option base 1 is gone, but you can always use the
> System.Array.CreateInstance method to create an array with alternate bounds.
> I really mean no disrespect, but VB.NET is really cool. It makes so many
> things that used to be a pain in the butt easy, that I can't understand what
> all the bitchen's about.
You'll rue the evisceration of deterministic finalization when you try to
do something non-trivial. The additional hoops Microsoft wants you to jump
through today to safely manage non-memory resources will get old fast.
> There is going to be a transition period. All of
> us probably will have legacy code to convert and apps to support, but
> eventually once every thing is changed over this move is going to be good
> for vb. And to be honest I am really pissed that microsoft gave in on the
> things they did concede.
I'm pissed that, since they were going to make essentially only one .NET
language anyway, they didn't go ahead with Cool and spend the effort they
wasted on B# on giving us VB7, instead of this C#-with-macros abomination:
Microsoft Visual Betrayal:
news://msnews.microsoft.com/3ACD45...@cluestick.org
Visual Basic 33 1/3: The Final Insult:
news://msnews.microsoft.com/3B2BE...@cluestick.org
> The array declaration and the logical/bitwise
> operator thing especially. And who gives a rats butt about the value of
> TRUE. Geeze! Most languages (even basics) define it as 1. Why would it
> make so much difference to anyone.
The value of True shouldn't make a difference, and it wouldn't, had IIf
been done right the first, second, third, fourth, fifth, or even sixth
time.
Tom Shelton
I am taking what you said into consideration, as well as the refrences you gave.
I'll probably want to make a couple of comments on them. Thanks for the info.
Tom Shelton
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:tku3ps8...@corp.supernews.com...
A. Clausen
> TRUE. Geeze! Most languages (even basics) define it as 1. Why would it
> make so much difference to anyone.
I give a rats butt about the value of True! Virtually every app and
utility I've written since QuickBASIC 4.5 has relied upon the notion
that True is simply non-zero. I've had nothing but pain with the Java
notion of true vs. false, which appears to be the way .NET is headed.
Tom Shelton
it was evaluating to 1 instead of -1 as in todays VB. I think that the reason
people are pissed is they took advatage of this and did things that the change
would of broken. So MS put it back.
Tom Shelton
"A. Clausen" <tech...@alberni.net> wrote in message
news:57e9d46d.01071...@posting.google.com...
Joe "Nuke Me Xemu" Foster
> Joe,
>
> I am taking what you said into consideration, as well as the refrences you gave.
> I'll probably want to make a couple of comments on them. Thanks for the info.
But wait, it gets worse! Garbage collection, and thus the finalization
of .NET objects, can be delayed for unpredictable lengths of time:
news://msnews.microsoft.com/OcD7U0ItAHA.2112@tkmsftngp05
The no-brainer response is "Just call .Dispose", right?
news://msnews.microsoft.com/O2PJBlErAHA.1988@tkmsftngp03
news://msnews.microsoft.com/MPG.15194c95e...@msnews.microsoft.com
news://msnews.microsoft.com/eMLH$hTtAHA.1912@tkmsftngp04
Now, "resource management" classes aren't just for things like files and
database connections, oh no! I use one for controlling the mouse pointer,
so I don't leave hourglasses hanging around, even if I totally screw the
pooch in an error handler or something. It's very simple: the Initialize
event saves the MousePointer, and the Terminate event puts it back. What
could go wrong?
What does this mean? Are we forever forced to choose between the timely
disposal of objects and being able to punt huge collections off into
never-never land so you can just get on with what you're doing? Hardly!
news://msnews.microsoft.com/u$HQRts7AHA.1360@tkmsftngp07
I've also been tinkering with what was supposed to be a quick hack to
get real object pooling in VB Classic, which is especially handy for
that pesky "thread per object" COM/ActiveX instancing model.
Does sticking with VB Classic mean giving up the speed benefits of new
features like StringBuilder? I don't think so, not when StringBuilder
appears to be doing something much like this internally anyway:
http://java.sun.com/products/jdk/1.1/docs/api/java.lang.StringBuffer.html
Oops! That's just what StringBuilder was cloned from. Here's a VB Classic
string hack test-rig which should show you comparable performance:
news://msnews.microsoft.com/OBQTklRyAHA.1848@tkmsftngp05
news://msnews.microsoft.com/OGFnr9eyAHA.1804@tkmsftngp02
Also see StrBldr.zip, a StringBuilder clone for VB, at www.mvps.org/vb/
http://www.mvps.org/vb/samples.htm#StrBldr
--
Joe Foster <mailto:jfo...@ricochet.net> Greed = God? <http://www.xenu.net/>
Larry Linson
arrays; they later restored at least part of the functionality they had not
included. They restored it because even the "omigawd this is so new it's got
to be good and it's all objectified just like my professors indoctrinated me
that computer languages should be" crowd screamed bloody murder about it.
Tom, they have taken the world's premier application development tool (VB
with some 6 million users, per comments by Microsofties) and turned it into
just another run-of-the-mill object-oriented language. It's not an
evolutionary change, and it's not beneficial to everyone. It's part of the
.NET assault on the huge, intergalactic-sized, server-centric distributed
applications. They are all done by the huge, intergalactic-sized
corporations (HISC) who, by virtue of their very size, represent "money
mines" for Microsoft and to whom Microsoft listens with the volume turned to
"high" because of that concentration of revenue. On the other hand, even
inside those HISCs, the poor little guy who's just happily churning out
deparmental applications never gets hear, just like the poor little guy
developers who develop single-user, standalone, straight client-server, and
simple web apps doesn't get heard by Microsoft. For both categories of
"little guy" developer, VB.NET is a VB.NET LOSS, not a VB.NET GAIN, as is
all the rest of .NET, too.
Know all the hype about XCOPY installs? Only true if the installed-upon
computer already has the proper .NET support installed. Easy to control for
a server-side app at which they are aiming; not so easy if you're writing
for distribution to a thousand unrelated, maybe unknown, desktops.
They updated C++ (C# is a new language too, just as is B-Flat, my personal
name for VB.NET) so that it could create .NET "managed" code that runs on
the CLR but also could still create unmanaged code that doesn't require the
CLR, but VB just didn't warrant the time and effort to do that. The C#
proponents are trying to convince everyone that C++ is dying, but much as we
dislike curly braces and cryptic code, it may get an infusion of VB refugees
who still want and need to write unmanaged code. Microsoft still has a need
to write quite a lot of unmanaged code, they do most of that in C/C++, and
IMNSHO that had to be a big factor in their decision not to dump classic
C/C++ just as they decided to dump classic VB.
"Tom Shelton" <t...@mtogden.com> wrote in message
news:QHx37.1887$hn6.8...@news.uswest.net...
Tom Shelton
Comments In Line:
"Larry Linson" <larry....@ntpcug.org> wrote in message
news:7LM37.1967$Lk1.4...@paloalto-snr1.gtei.net...
> I do believe you are in error. They _did_ eliminate everything but 0-based
> arrays; they later restored at least part of the functionality they had not
> included. They restored it because even the "omigawd this is so new it's got
> to be good and it's all objectified just like my professors indoctrinated me
> that computer languages should be" crowd screamed bloody murder about it.
Yes you can:
Option Strict
Imports System
Module modMain
Public Sub Main()
Dim OneDLength() As Integer = {20}
Dim OneDBounds() As Integer = {-1}
Dim OneDimmensionalArray As Array
Dim TwoDLengths() As Integer = {10, 12}
Dim TwoDBounds() As Integer = {-1, 20}
Dim TwoDimmensionalArray(,) As Short
' Lets initialize the one dimmensional array.
' Unfortunately, we have to use a generic array class
' for 1 dimmensional arrays. I can't seem to get it to cast into
' an actual type. (still working on this)
OneDimmensionalArray = Array.CreateInstance(GetType(Short), OneDLength,
OneDBounds)
' This doesn't work
' OneDimmensionalArray = CType(Array.CreateInstance(GetType(Short),
OneDLength, OneDBounds), Short())
' Lets Create Our Two Dimmensional Array
TwoDimmensionalArray = CType(Array.CreateInstance(GetType(Short), TwoDLengths,
TwoDBounds), Short(,))
PrintArrayInfo("OneDimmensionsalArray", OneDimmensionalArray)
PrintArrayInfo("TwoDimmensionsalArray", TwoDimmensionalArray)
End Sub
Private Sub PrintArrayInfo(arrayName As String, a As Array)
Dim i As Integer
Console.WriteLine("{0} Has {1} Dimmension(s)", arrayName, a.Rank)
For i = 0 To a.Rank - 1
Console.WriteLine("The Lower Bound Of Dimmension {0} Of {1} Is {2}", i+1,
arrayName, a.GetLowerBound(i))
Console.WriteLine("The Upper Bound Of Dimmension {0} Of {1} Is {2}", i+1,
arrayName, a.GetUpperBound(i))
Console.WriteLine("There Are {0} Elements In This Dimmension",
a.GetLength(i))
Console.WriteLine("")
Next i
End Sub
End Module
Yes, you have to jump through a couple of hoops to make it work - especially
with 1 dimmensional arrays. But, they are there, there just isn't a native
syntax for declaring them that way. And by the way, I saw a simmilar example
using Beta 1, so this functionality was not just added in Beta 2. It has always
been there.
> Tom, they have taken the world's premier application development tool (VB
> with some 6 million users, per comments by Microsofties) and turned it into
> just another run-of-the-mill object-oriented language. It's not an
> evolutionary change, and it's not beneficial to everyone. It's part of the
> .NET assault on the huge, intergalactic-sized, server-centric distributed
> applications. They are all done by the huge, intergalactic-sized
> corporations (HISC) who, by virtue of their very size, represent "money
> mines" for Microsoft and to whom Microsoft listens with the volume turned to
> "high" because of that concentration of revenue. On the other hand, even
> inside those HISCs, the poor little guy who's just happily churning out
> deparmental applications never gets hear, just like the poor little guy
> developers who develop single-user, standalone, straight client-server, and
> simple web apps doesn't get heard by Microsoft. For both categories of
> "little guy" developer, VB.NET is a VB.NET LOSS, not a VB.NET GAIN, as is
> all the rest of .NET, too.
Maybe, but I don't think so. I have several small utilities (just stuff for the
home pc) that I have been converting (for the learning experience), and most of
them have actually taken fewer lines of code to get the same functionality, and
too my way of thinking easier to program. Now, to be honest I had OOP drilled
into me for 4 years of college, and so for me it is a natural progression. I
can see that this may not be the case for some people. But, I believe most will
adapt.
> Know all the hype about XCOPY installs? Only true if the installed-upon
> computer already has the proper .NET support installed. Easy to control for
> a server-side app at which they are aiming; not so easy if you're writing
> for distribution to a thousand unrelated, maybe unknown, desktops.
Yeah, I know. But this has been the case for vb for a long time, so we
shouldn't have any trouble adapting to this (we'll just need to use a little
more room on our CD for distribuition)
> They updated C++ (C# is a new language too, just as is B-Flat, my personal
> name for VB.NET) so that it could create .NET "managed" code that runs on
> the CLR but also could still create unmanaged code that doesn't require the
> CLR, but VB just didn't warrant the time and effort to do that. The C#
> proponents are trying to convince everyone that C++ is dying, but much as we
> dislike curly braces and cryptic code, it may get an infusion of VB refugees
> who still want and need to write unmanaged code. Microsoft still has a need
> to write quite a lot of unmanaged code, they do most of that in C/C++, and
> IMNSHO that had to be a big factor in their decision not to dump classic
> C/C++ just as they decided to dump classic VB.
C++ is an existing standard. They can't very well change the language, all they
can do is add extensions. The C# people who say C++ is dead are up in the
night. It will be around for a long time to come. To be honest, I don't care
if VB.NET can't do unmanaged code. If and when the time comes that I need it,
I'll encapsulate it in a C# class, and bring it into my project. The only thing
that I wish had been implemented in VB.NET is unsigned math, and operator
overloading - there is always next time. I am still a little undecided on the
issue of "deterministic finalization", but the more I think about it the less of
an issue this seams to me. Objects in .NET are obviously heap based, so there
is no way other then implementing a refrence counting scheme (COM) to make this
happen. In C++, you only have this for stacked based objects - you have to be
responsible for your own clean up for heap allocated objects. This is the same
method that Java has been using forever, and Java has been quite successful in
the market place. It requires a different mindset and a little more
responsibilty on the part of the programmer, but overall GC as implemented in
.NET is much more efficient then refrence counting. The lack of "deterministic
finalization" is one of the biggest sources of bugs in C++ and are actually IMO,
much more difficult to deal with. VB.NET provides SEH in a form that makes this
relatively easy, by putting your clean up code inside of a Finally block, you
ensure that it will always happen no matter what the exit condition:
Dim o As ResourceObject
Try
o.DoStuffWithResource
Catch e As ResourceObjectException
' Do Stuff
Finally ' THIS WILL ALWAYS HAPPEN! NO MATTER WHAT
o.Dispose()
End Try
The only thing I wish they had a feature like C#'s using statement.
Tom Shelton
Larry Linson
> Yes, you have to jump through a couple of hoops to make it work -
especially
> with 1 dimmensional arrays. But, they are there, there just isn't a
native
> syntax for declaring them that way. And by the way, I saw a simmilar
example
> using Beta 1, so this functionality was not just added in Beta 2. It has
always
> been there.
What you wrote as a replacement for being able to declare an array with a
specific lower and upper bound, and determine at will what those are with
the UBound and LBound functions is not "jumping through a couple of hoops",
it is incredibly complicated, obscure, and intolerably more code. It takes a
wild stretch of my imagination to think that anyone would consider this an
acceptable substitute.
> Maybe, but I don't think so. I have several small utilities (just stuff
for the
> home pc) that I have been converting (for the learning experience), and
most of
> them have actually taken fewer lines of code to get the same
functionality, and
> too my way of thinking easier to program. Now, to be honest I had OOP
drilled
> into me for 4 years of college, and so for me it is a natural
progression. I
> can see that this may not be the case for some people. But, I believe
most will
> adapt.
I would imagine that most who had four years of OOP indoctrination will not
only adapt, but slobber gratefully to the language gods in Redmond. It is
those of The Great VB Unwashed for whom I grieve, the ones who didn't major
or minor in CS, who learned from a book, who taught themselves, so they
could do applications to assist in running their business, or who've
actually made the transition to working as a developer. According to
Microsoft's own research (business customers, I'd guess) 70%+ (not 60%, as
is often quoted) of VB applications don't have a class anywhere that wasn't
built in to the language (as Forms are, kinda?, classes).
They are _not_ of the opinion that "if it isn't OOP, it doesn't compute"
(During my mainframe incarnation, I had a respected colleague whose motto,
only a bit tongue in cheek, was "if it isn't watercooled, it doesn't
compute". At least then, none but the mightiest of mainframes was
watercooled. Both views are equally wrong.) They are, largely, of the
opinion that if they can't point their way to a friendly UI, and sprinkle
just a little code behind it to solve the business function and make the UI
work more-or-less smoothly, in a short time, with little fuss and bother,
"it doesn't compute".
> Yeah, I know. But this has been the case for vb for a long time, so we
> shouldn't have any trouble adapting to this (we'll just need to use a
little
> more room on our CD for distribuition)
That's absolutely not the case. You can, using one of the third-party
installer software packages, include appropriate .DLLs, so the user doesn't
have to have them pre-installed. I haven't been told that the .NET support
itself is XCOPY install... and if it is, it's a lot of XCOPYing. But what
you describe sounds amazingly like current installation CDs, not an XCOPY
install. Aren't you making the point for me that XCOPY install of your
B-Flat or C-Sharp application is a myth, because you'll have to include the
required version of .NET support?
> C++ is an existing standard. They can't very well change the language,
all they
> can do is add extensions. The C# people who say C++ is dead are up in the
> night. It will be around for a long time to come.
VB _was_ an existing de facto standard. It just happened to be proprietary
so that Microsoft could do anything they wanted to with the name... They
chose to apply it to a new and different language. You may not care about
compatibility -- it seems clear that is not one of your agenda issues -- but
there are many who do, and they feel (rightly so, IMNSHO) betrayed.
> To be honest, I don't care if VB.NET can't do unmanaged code. If and
> when the time comes that I need it, I'll encapsulate it in a C# class,
and
> bring it into my project.
You may not, but many do care. I hope that you are deliriously happy with
B-Flat, but I am puzzled why you, apparently competent in C++, would bother
with it. On the other hand, if you are talking about C#, rather than B-Flat,
it all makes better sense.
What most of my conversations/communications with .NET proponents always
seems to boil down to is that, if I devote the time and energy required to
learn the new language, that I can, if I am so stupid as to want to, with a
significant number of workarounds like the one you showed for non-zero based
Arrays and UBound and LBound, then I can do the same things that I do now,
only it'll take me more time and effort.
However, I'm not so dumb as to not realize that to use the new B-Flat or C#
languages _effectively_, I'll need to take the object view from
requirements, through design, and then be able to implement "the object
way". There's a good reason that Deborah Kurata, in her book, starts from
the beginning of a project viewing the requirements in terms of objects and
continues through... it is the only way to do an effective OOP application.
Tom Shelton
Again, comments inline
> What you wrote as a replacement for being able to declare an array with a
> specific lower and upper bound, and determine at will what those are with
> the UBound and LBound functions is not "jumping through a couple of
hoops",
> it is incredibly complicated, obscure, and intolerably more code. It takes
a
> wild stretch of my imagination to think that anyone would consider this an
> acceptable substitute.
What I wrote was to dispell the myth that seems to be floating around that
all arrays in VB.NET are 0 based. This is simply not the case. I am not
defending Microsoft's decision to take them out. I don't understand why
they did. Since the feature is obviously part of the framework there is no
reason they couldn't have wrapped this up in the syntax. I don't really
think that the amound of code involved is so objectionable to make it
unworkable. I understand that a lot of people based code on the ability to
declare arrays with a non zero lower bounds. This is a feature that I
personally almost never use, but all I'm saying is that if it is important
to you then there is a way to do it.
> I would imagine that most who had four years of OOP indoctrination will
not
> only adapt, but slobber gratefully to the language gods in Redmond. It is
> those of The Great VB Unwashed for whom I grieve, the ones who didn't
major
> or minor in CS, who learned from a book, who taught themselves, so they
> could do applications to assist in running their business, or who've
> actually made the transition to working as a developer. According to
> Microsoft's own research (business customers, I'd guess) 70%+ (not 60%, as
> is often quoted) of VB applications don't have a class anywhere that
wasn't
> built in to the language (as Forms are, kinda?, classes).
I agree to a point. The entry fee into VB programming gets a little steeper
with VB.NET, but IMHO the rewards went up proportionaltly. There is so much
more power in VB.NET compared to VB6. VB.NET means I will no longer have to
jump thorough hoops to add multiple threads to my application, to redirect a
programs standard input and output so that I can read and write to the
process, shell a program and wait for it to complete, create a console app,
or set an exit code.
> They are _not_ of the opinion that "if it isn't OOP, it doesn't compute"
> (During my mainframe incarnation, I had a respected colleague whose motto,
> only a bit tongue in cheek, was "if it isn't watercooled, it doesn't
> compute". At least then, none but the mightiest of mainframes was
> watercooled. Both views are equally wrong.) They are, largely, of the
> opinion that if they can't point their way to a friendly UI, and sprinkle
> just a little code behind it to solve the business function and make the
UI
> work more-or-less smoothly, in a short time, with little fuss and bother,
> "it doesn't compute".
Larry, I totaly agree with you on this. Sorry if I wasn't clear. No the
.NET framework is not a simple XCOPY. Though not based on COM, .NET uses
many COM classes to interact with the OS. Eventually, the frameworks are
supposed to be distributed with the OS, service packs, and IE. Eventually,
a .NET install may be a simple XCOPY, but I sort of doubt it.
> VB _was_ an existing de facto standard. It just happened to be proprietary
> so that Microsoft could do anything they wanted to with the name... They
> chose to apply it to a new and different language. You may not care about
> compatibility -- it seems clear that is not one of your agenda issues --
but
> there are many who do, and they feel (rightly so, IMNSHO) betrayed.
>
> > To be honest, I don't care if VB.NET can't do unmanaged code. If and
> > when the time comes that I need it, I'll encapsulate it in a C# class,
> and
> > bring it into my project.
>
> You may not, but many do care. I hope that you are deliriously happy with
> B-Flat, but I am puzzled why you, apparently competent in C++, would
bother
> with it. On the other hand, if you are talking about C#, rather than
B-Flat,
> it all makes better sense.
Because, my boss says I have to use VB :) (we have argued over this a couple
of times, but since he is paying my bills...). Actually, I do do some C/C++
at work, but strangly enough almost none of it is Windows programming. The
company I work for is primarily a Unix shop (SCO). I am really the
companies only full time Windows Developer, and they say for that I have to
use VB. I do sneak and write an odd component/dll now and again.
For my stuff at home, it depends. For most stuff I use VB, I have never
been a big fan of MFC and for simple utilities SDK programming is a little
bit of overkill. I plan on learning C#. I just felt that since I am
already familiar with VB, it would be a good jumping off point to learn the
frameworks. To force the issue, I try not to include the
Microsoft.VisualBasic namespace into my programs so that I'm forced to
search the frameworks for the appropriat classes.
And don't worry, I already am "deliriously happy" with .NET. I wish I had
it 6 months ago before I started my current project. The threading support
alone would have made it worth the changes. Your right, I personally am not
all that worried about compatability. For me, the conversion proccess isn't
going to be that big a deal. MS isn't discontinuing support of the current
VB or COM. All of my C++/VB dlls, I can still access from .NET. As time
goes on I can convert these as needed. The rest is the interfaces, which
should be fairly straight forward. I realize that many have a much larger
code base to deal with. But once again, nothing stops people from making
the change gradually.
> What most of my conversations/communications with .NET proponents always
> seems to boil down to is that, if I devote the time and energy required to
> learn the new language, that I can, if I am so stupid as to want to, with
a
> significant number of workarounds like the one you showed for non-zero
based
> Arrays and UBound and LBound, then I can do the same things that I do now,
> only it'll take me more time and effort.
>
> However, I'm not so dumb as to not realize that to use the new B-Flat or
C#
> languages _effectively_, I'll need to take the object view from
> requirements, through design, and then be able to implement "the object
> way". There's a good reason that Deborah Kurata, in her book, starts from
> the beginning of a project viewing the requirements in terms of objects
and
> continues through... it is the only way to do an effective OOP
application.
As I said, VB.NET is a new mindset. It requires the object way of thinking.
This is going to be a problem for a lot of current VB programmers. But what
choice do we have, really. You can either move forward with VB.NET or you
can move to another language - Delphi, C/C++ are about the only ones that
come to mind. You could do Java, but it is essentially the same as C#.
Tom Shelton
W.E. (Bill) Goodrich, PhD
"Tom Shelton" <t...@mtogden.com> writes:
> Larry,
> Again, comments inline
Likewise, with one exception:
What, exactly, do you see as the Unique Niche for VB? The Reason - or
Circumstances - for using VB rather than ANY other language? Others of
us have pointed to its utility for non-Programmers, either as
developers of q&d applications or as auditors/modifiers of otherwise
professionally produced code, but you seem to reject that.
> > What you wrote as a replacement for being able to declare an
> > array with a specific lower and upper bound, and determine at
> > will what those are with the UBound and LBound functions is not
> > "jumping through a couple of hoops", it is incredibly complicated,
> > obscure, and intolerably more code. It takes a wild stretch of my
> > imagination to think that anyone would consider this an acceptable
> > substitute.
> What I wrote was to dispell the myth that seems to be floating
> around that all arrays in VB.NET are 0 based.
That wasn't quite what had been said - in this group, at least.
[...]
> > I would imagine that most who had four years of OOP indoctrination
> > will not only adapt, but slobber gratefully to the language gods
> > in Redmond. It is those of The Great VB Unwashed for whom I grieve,
> > the ones who didn't major or minor in CS, who learned from a book,
> > who taught themselves, so they could do applications to assist in
> > running their business, or who've actually made the transition to
> > working as a developer. According to Microsoft's own research
> > (business customers, I'd guess) 70%+ (not 60%, as is often quoted)
> > of VB applications don't have a class anywhere that wasn't built in
> > to the language (as Forms are, kinda?, classes).
> I agree to a point. The entry fee into VB programming gets a little
> steeper with VB.NET, but IMHO the rewards went up proportionaltly.
> There is so much more power in VB.NET compared to VB6.
The same argument applies to C++: The entry fee is steeper than for
any form of BASIC (BEGINNER'S All-purpose Symbolic Instruction Code),
there is so much more power in C++ than in VB. But there is another
edge to that sword. Those who don't NEED the extra power are still
faced with that steep entry fee.
> VB.NET means I will no longer have to jump thorough hoops to add
> multiple threads to my application, to redirect a programs standard
> input and output so that I can read and write to the process, shell
> a program and wait for it to complete, create a console app, or set
> an exit code.
OTOH, you DO have to jump through hoops to do such formerly simple
things as defining an array with a non-zero base.
> > They are _not_ of the opinion that "if it isn't OOP, it doesn't
> > compute" (During my mainframe incarnation, I had a respected
> > colleague whose motto, only a bit tongue in cheek, was "if it
> > isn't watercooled, it doesn't compute". At least then, none but
> > the mightiest of mainframes was watercooled. Both views are
> > equally wrong.) They are, largely, of the opinion that if they
> > can't point their way to a friendly UI, and sprinkle just a little
> > code behind it to solve the business function and make the UI
> > work more-or-less smoothly, in a short time, with little fuss and
> > bother, "it doesn't compute".
> Larry, I totaly agree with you on this. Sorry if I wasn't clear.
> No the .NET framework is not a simple XCOPY. Though not based on
> COM, .NET uses many COM classes to interact with the OS. Eventually,
> the frameworks are supposed to be distributed with the OS, service
> packs, and IE.
That may change, with the legal proceedings. The entire .NET/XP
strategy is being called anti-competitive in relevant filings.
> Eventually, a .NET install may be a simple XCOPY, but I sort of
> doubt it.
Likewise.
> > VB _was_ an existing de facto standard. It just happened to be
> > proprietary so that Microsoft could do anything they wanted to
> > with the name... They chose to apply it to a new and different
> > language. You may not care about compatibility -- it seems clear
> > that is not one of your agenda issues -- but there are many who
> > do, and they feel (rightly so, IMNSHO) betrayed.
> > > To be honest, I don't care if VB.NET can't do unmanaged code.
> > > If and when the time comes that I need it, I'll encapsulate it
> > > in a C# class, and bring it into my project.
> > You may not, but many do care. I hope that you are deliriously
> > happy with B-Flat, but I am puzzled why you, apparently competent
> > in C++, would bother with it. On the other hand, if you are
> > talking about C#, rather than B-Flat, it all makes better sense.
> Because, my boss says I have to use VB :) (we have argued over this
> a couple of times, but since he is paying my bills...).
And other than pure fiat, what reasons/arguments did he advance? And
how do they mesh with the .NET changes?
And do you see .NET as a "workaround" to those arguments?
> Actually, I do do some C/C++ at work, but strangly enough almost
> none of it is Windows programming. The company I work for is
> primarily a Unix shop (SCO). I am really the companies only full
> time Windows Developer, and they say for that I have to use VB.
Again, why?
> I do sneak and write an odd component/dll now and again.
[...]
> And don't worry, I already am "deliriously happy" with .NET. I wish
> I had it 6 months ago before I started my current project. The
> threading support alone would have made it worth the changes. Your
> right, I personally am not all that worried about compatability.
> For me, the conversion proccess isn't going to be that big a deal.
> MS isn't discontinuing support of the current VB or COM.
Not yet - as far as they are willing to say. OTOH, they would be
foolish to say such a thing under the current (legal) circumstances.
> All of my C++/VB dlls, I can still access from .NET. As time goes
> on I can convert these as needed. The rest is the interfaces, which
> should be fairly straight forward. I realize that many have a much
> larger code base to deal with. But once again, nothing stops people
> from making the change gradually.
"Nothing" but business realities, economics, changes in M$ support
policies, etc. While nothing may stop people from "from making the
change gradually" in their personal, home-brewed code, there are many
things which can mandate an "all at once" conversion. And even when
they don't, such conversions cost significant time and money
(ESPECIALLY with such significant structural and functional changes to
the language).
> > What most of my conversations/communications with .NET proponents
> > always seems to boil down to is that, if I devote the time and
> > energy required to learn the new language, that I can, if I am so
> > stupid as to want to, with a significant number of workarounds
> > like the one you showed for non-zero based Arrays and UBound and
> > LBound, then I can do the same things that I do now, only it'll
> > take me more time and effort.
> > However, I'm not so dumb as to not realize that to use the new
> > B-Flat or C# languages _effectively_, I'll need to take the object
> > view from requirements, through design, and then be able to
> > implement "the object way". There's a good reason that Deborah
> > Kurata, in her book, starts from the beginning of a project
> > viewing the requirements in terms of objects and continues
> > through... it is the only way to do an effective OOP application.
> As I said, VB.NET is a new mindset. It requires the object way of
> thinking.
But to what end? Back to the question I started with: why does VB (in
that form) exist at all? Why use it rather than the more "professional"
languages?
The OOP "mindset" is not intuitive to those who have not gone through
the academic propaganda mill. The "Bastard Child of OO" which was/is
visible in VB6 and the like allows Larry's "Great VB Unwashed" to USE
a useful subset thereof without dropping their own professional
priorities in order to acquire the OOP mindset.
> This is going to be a problem for a lot of current VB programmers.
Especially those who are not really "VB programmers" as a profession,
but are other professionals (businessmen, scientists, technicians,
etc.) who use VB to create q&d one-shots. The ones who created most
of the 70%+ of VB code Larry cited.
> But what choice do we have, really. You can either move forward
> with VB.NET or you can move to another language - Delphi, C/C++ are
> about the only ones that come to mind.
Or create a significant market for a replacement BASIC RAD, making
M$ pay attention (as has happened in the past) or lose a significant
market to a competitor (as has also happened).
> You could do Java, but it is essentially the same as C#.
Java has its own niche, primarily 'net related. It is not all that
strong for isolated-platform applications.
> Tom Shelton
--
W.E. (Bill) Goodrich, PhD
*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * bgoo...@nyx.net bgoo...@netzero.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*
Tom Shelton
Comments inline
> What, exactly, do you see as the Unique Niche for VB? The Reason - or
> Circumstances - for using VB rather than ANY other language? Others of
> us have pointed to its utility for non-Programmers, either as
> developers of q&d applications or as auditors/modifiers of otherwise
> professionally produced code, but you seem to reject that.
>
I am not rejecting this. I know that many non-programmers make use of VB. But,
I believe that VB's biggest audience is the corporate developer. And that is
who MS is playing to in the "NEW and IMPROVED" VB. VB has been the perfect
language for quick DB interfaces, throw-away utilities, and client programs.
> That wasn't quite what had been said - in this group, at least.
Larry Linson - Some questions about VB.NET - "I do believe you are in error.
They _did_ eliminate everything but 0-based
arrays" ...
Joe Foster - Some questions about VB.NET - "Actually, I thought arrays would
still be zero-based, unless you write a
wrapper class that won't otherwise act much like VB Classic arrays after all,
but you could specify the upper bound, not the number of elements"
Those were two from this thread. To be honest, I am pretty new to this group.
I hang out mostly over on the microsoft groups, and believe me this has come up
a couple of times. You don't need a wrapper class, the functionality is built
into the native .NET array, VB just doesn't provide syntax to access this
feature.
> The same argument applies to C++: The entry fee is steeper than for
> any form of BASIC (BEGINNER'S All-purpose Symbolic Instruction Code),
> there is so much more power in C++ than in VB. But there is another
> edge to that sword. Those who don't NEED the extra power are still
> faced with that steep entry fee.
I think the biggest part of the learning curve with the VB.NET is not syntax,
but learning the framework on which it is built. It is quite extensive. If you
include the Microsoft.VisualBasic namespace, almost all of the old familar
functions are there, making the transition not as difficult.
> OTOH, you DO have to jump through hoops to do such formerly simple
> things as defining an array with a non-zero base.
True. This one instance doesn't bother me as much, because as stated earlier, I
almost never use this feature anyway. And I think the things made easier far
outway this one inconvienenceork In the course of my work and play, I use
several different languages (C/C++, Perl, PHP) all of which use 0 based arrays.
It is for me the natural way to work, so I don't often use this feature. I am
glad it is there though, when I do use it. That is why I wanted to see if this
could be done in .NET.
> > Eventually, a .NET install may be a simple XCOPY, but I sort of
> > doubt it.
>
> Likewise.
So, we all agree on this.
> > Because, my boss says I have to use VB :) (we have argued over this
> > a couple of times, but since he is paying my bills...).
>
> And other than pure fiat, what reasons/arguments did he advance? And
> how do they mesh with the .NET changes?
The biggest reason is developement time. Lets face it, under windows at least,
VB lets me put together a windows app fairly quickly as compared to using C++.
The other reasons are maintanence. I maybe the only full time Windows
programmer here, but there are others in the company that maintain windows
programms, and who know VB. It makes sense for them to make me use VB, because
if I left, my job could be taken over from with in without having to go outside
to find someone who is proffiecient with both C++ and windows.
> And do you see .NET as a "workaround" to those arguments?
Actually, yes. I think that for the most part, to a person who knows VB, then a
program, though structured a little differently, would still be maintainable by
someone not familar with VB.NET. In the mix I would get the features that make
me want to use C++, primarily the threading support, but having implementation
inheretance is a nice bonus.
> > Actually, I do do some C/C++ at work, but strangly enough almost
> > none of it is Windows programming. The company I work for is
> > primarily a Unix shop (SCO). I am really the companies only full
> > time Windows Developer, and they say for that I have to use VB.
>
> Again, why?
See above
> > > However, I'm not so dumb as to not realize that to use the new
> > > B-Flat or C# languages _effectively_, I'll need to take the object
> > > view from requirements, through design, and then be able to
> > > implement "the object way". There's a good reason that Deborah
> > > Kurata, in her book, starts from the beginning of a project
> > > viewing the requirements in terms of objects and continues
> > > through... it is the only way to do an effective OOP application.
>
> > As I said, VB.NET is a new mindset. It requires the object way of
> > thinking.
>
> But to what end? Back to the question I started with: why does VB (in
> that form) exist at all? Why use it rather than the more "professional"
> languages?
>
> The OOP "mindset" is not intuitive to those who have not gone through
> the academic propaganda mill. The "Bastard Child of OO" which was/is
> visible in VB6 and the like allows Larry's "Great VB Unwashed" to USE
> a useful subset thereof without dropping their own professional
> priorities in order to acquire the OOP mindset.
This one has made me think a little, and here is what I came up with. I think I
was wrong when I said that VB.NET requires a new way of thinking. In actuality,
it encourages a new way of thinking, but doesn't require it as C# does. With
the exception of the GUI, there is nothing that forces a VB.NET programmer to
use things like inheritance and classes. The forms thing can be generated by
the designer, and most of that is boiler plate type code. Your actuall
functionality can be done with out classes, just functions in a module. You can
pretty much just do what most people do anyway, use the built in objects, but
not create your own.
> > But what choice do we have, really. You can either move forward
> > with VB.NET or you can move to another language - Delphi, C/C++ are
> > about the only ones that come to mind.
>
> Or create a significant market for a replacement BASIC RAD, making
> M$ pay attention (as has happened in the past) or lose a significant
> market to a competitor (as has also happened).
>
> > You could do Java, but it is essentially the same as C#.
>
> Java has its own niche, primarily 'net related. It is not all that
> strong for isolated-platform applications.
I don't particularly like Java, don't get me wrong I like the Java syntax and
mindset, but if you have to write anything with a GUI - its a POS.
Tom Shelton
Larry Linson
> Those were two from this thread. To be honest, I am pretty new to this
group.
> I hang out mostly over on the microsoft groups, and believe me this has
come up
> a couple of times. You don't need a wrapper class, the functionality is
built
> into the native .NET array, VB just doesn't provide syntax to access this
> feature.
Given that we were discussing VB.NET, not the "native .NET common language
runtime", and "VB provides no syntax to access this feature", then as far as
I am concerned, VB.NET did limit you to zero-based arrays, short of the
clumsy, long, and (I am so bold as to say) rather obscure workaround you
posted.
APIs are in the native Windows functionality, and, with jumping through
(sometimes far fewer) hoops they can be used from VB6, but it would be
outrageous to claim that VB 6 had builtin API access.
Joseph T. Adams
: "Tom Shelton" wrote
: > Those were two from this thread. To be honest, I am pretty new to this
: group.
: > I hang out mostly over on the microsoft groups, and believe me this has
: come up
: > a couple of times. You don't need a wrapper class, the functionality is
: built
: > into the native .NET array, VB just doesn't provide syntax to access this
: > feature.
: Given that we were discussing VB.NET, not the "native .NET common language
: runtime", and "VB provides no syntax to access this feature", then as far as
: I am concerned, VB.NET did limit you to zero-based arrays, short of the
: clumsy, long, and (I am so bold as to say) rather obscure workaround you
: posted.
Just a nitpick - I agree with many of your other criticisms of
VB.Fred:
To someone accustomed to creating user-defined types and classes -
which VB has not only supported but encouraged for quite some time now
- creating your own arrays, dictionaries, and other data types that
behave the way you want is not that much work. Using them, at least
in a language that supports operator overloading (which I believe
VB.NET does), is not necessarily any more difficult than using the
built-in VB types. It may even be easier, because you can define the
API, rather than relying upon what Microsoft has provided.
It may be slower than using native types, but even that should not be
true given a decent optimizing compiler.
Joe
Tom Shelton
Tom Shelton
"Joseph T. Adams" <j...@apk.net> wrote in message
news:9ivm9q$bo6$1...@plonk.apk.net...
Larry Linson
> Unfortunately, VB.NET doesn't support operator overloading :(
B-Flat doesn't? Does C-Sharp? Or is that "a C++ thing"?
Tom Shelton
> runtime", and "VB provides no syntax to access this feature", then as far as
> I am concerned, VB.NET did limit you to zero-based arrays, short of the
> clumsy, long, and (I am so bold as to say) rather obscure workaround you
> posted.
True enough, VB.NET itself does not give you access to this feature, so I will
concede the point that VB.NET ITSELF does not allow the CREATION of non-zero
based arrays. But, they certainly can be created and used within the confines
of the underlying platform. I think VB.NET should continue to support the ...
To ... syntax, I'm not arguing that point. Since this is a feature of the
runtime, VB.NET should be able to wrap this up. I certainly wouldn't call this
an obscure feature of the native .NET runtime, though. This is a well
documented method of the base class for all arrays. Yes, it is certainly longer
and only slightly more clumsy (IMHO) in the declaration and creation, but after
that, there isn't any difference in how you access the members - UBound and
LBound still work on these arrays, but since these are methods of all arrays it
is actually slower to make the double function call (since LBound/Ubound will
simply call the array method). It is much more effiecient to do this:
Dim a() As Short = {1,2,3,4,5}
Console.WriteLine(a.GetLowerBound(0))
So, here is my point - What is simpler, I have a routine that uses a 1 based
array rather then zero based array, do I change my code to account for the
offset, or do I change my declaration, and add a couple of lines so that I can
just create the array with a 1 base? not as convienient as VB.CLASSIC, but very
do able, IMHO.
> APIs are in the native Windows functionality, and, with jumping through
> (sometimes far fewer) hoops they can be used from VB6, but it would be
> outrageous to claim that VB 6 had builtin API access.
It is not outrageous to claim any such thing! VB6 does have builtin API access
via the Declare syntax. The authors of the language purposely made it possible
to access the API directly. What makes you think that this isn't the case? In
.NET you have native access to almost all of the underling class libraries, so
they essentially are part of VB.NET, the trick is learning them well enough to
use them effectively. The same applies to the API from VB6.
Tom Shelton
Tom Shelton
the next VB.NET.
Tom Shelton
"Larry Linson" <larry....@ntpcug.org> wrote in message
news:vLJ47.2411$CQ4.3...@paloalto-snr1.gtei.net...
Joe "Nuke Me Xemu" Foster
> Yes, C# does support operator overloading. And rummor has it that this maybe in
> the next VB.NET.
Screw that. If we have to trash, rearchitect, and rewrite everything anyway,
why stick with Microsoft at all? We already know they screwed the pooch,
big time, as you can see in "Brian Harry"'s comments, among others:
http://www.mvps.org/vbnet/dev/vb7/vbdotnet_comments.htm
--
Joe Foster <mailto:jfo...@ricochet.net> Sacrament R2-45 <http://www.xenu.net/>
Tom Shelton
sure this will add fuel to the fire of the anti-.NET'ers
> "but after that, there isn't any difference in how you access the members"
This statement is untrue for 1 dimmensional arrays with Option Strict. When
using 1 dimmensional arrays with this option due to the fact that 1 dimmensional
arrays are latebound, you can not access the members directly - you can only
access them through the GetValue/SetValue method calls. An array of two or more
dimmensions, you can access them directly since these can be typed and there is
no late binding.
Larry, just so you know, you can declare an array in a single line:
Dim myArray(,) As Short = CType(Array.CreateInstance(GetType(Short), New
Integer() {5, 10}, New Integer() {-1, 20}), Short(,))
Or
Dim myArray() As Array = Array.CreateInstance(GetType(Short), New Integer()
{i*5}, New Integer() {-1 * i})
I am posting this because, I am trying to understand all points of view on this.
I don't want anyone to think I am a troll, just out to pick a fight, I am
interested in others opinions, even if I don't agree.
Tom Shelton
W.E. (Bill) Goodrich, PhD
"Tom Shelton" <to...@dakcs.com> writes:
> Bill,
> Comments inline
> > What, exactly, do you see as the Unique Niche for VB? The Reason - or
> > Circumstances - for using VB rather than ANY other language? Others of
> > us have pointed to its utility for non-Programmers, either as
> > developers of q&d applications or as auditors/modifiers of otherwise
> > professionally produced code, but you seem to reject that.
> I am not rejecting this. I know that many non-programmers make use
> of VB. But, I believe that VB's biggest audience is the corporate
> developer.
Not according to the numbers I saw (some time ago, admittedly) from M$.
The biggest audience is students. Second biggest IS corporate USERS,
but that class includes far more than "corporate developers". Like
Speedware and other 4GLs, VB gained corporate entry as a "power user"
tool - a way for executives, managers, etc. (and/or their assistants)
to get the results they needed without going to the professional
Development staff (and waiting weeks or months). Like those 4GLs, it
was billed as easy for a non-programmer to learn and use, but powerful
enough for use by the professional programmers. The Powers That Buy
were assured that non-programmers could come functionally up to speed
over the course of one or two 1/2 day workshops, so they started using
(and specifying) it.
> And that is who MS is playing to in the "NEW and IMPROVED" VB.
M$ is playing to the "professionals" (or rather, the subset thereof
that are strongly OOP oriented but unconcerned about certain
performance issues) at the expense of the students and non-pros
(executives, etc.) and the like - the "door openers".
> VB has been the perfect language for quick DB interfaces, throw-away
> utilities, and client programs.
And do the functional changes materially IMPROVE the environment for
such uses, or DETRACT therefrom? Or are they entirely neutral? It is
clear that most of the posters to such discussions here (including
myself) see the changes as detracting. The described "improvements"
seem primarily aimed outside of the functional areas you describe.
> > That wasn't quite what had been said - in this group, at least.
> Larry Linson - Some questions about VB.NET - "I do believe you are
> in error. They _did_ eliminate everything but 0-based arrays" ...
> Joe Foster - Some questions about VB.NET - "Actually, I thought
> arrays would still be zero-based, unless you write a wrapper class
> that won't otherwise act much like VB Classic arrays after all, but
> you could specify the upper bound, not the number of elements"
Both of which are somewhat different than "all arrays in VB.NET are 0
based". It is clear that they DID eliminate non-zero based arrays from
the SYNTAX of VB.NET.
> Those were two from this thread. To be honest, I am pretty new to
> this group. I hang out mostly over on the microsoft groups, and
> believe me this has come up a couple of times. You don't need a
> wrapper class, the functionality is built into the native .NET array,
> VB just doesn't provide syntax to access this feature.
There is a significant difference between describing VB as "supporting
full-screen, realtime animation" (which it doesn't) or as "supporting
memory allocation and management" (which it doesn't) and discussing the
fact that you can, with a bit of work, access API functions and the
like which, in turn, can support such activities. The former describes
alleged "native" features of the language. The latter doesn't.
> > The same argument applies to C++: The entry fee is steeper than for
> > any form of BASIC (BEGINNER'S All-purpose Symbolic Instruction Code),
> > there is so much more power in C++ than in VB. But there is another
> > edge to that sword. Those who don't NEED the extra power are still
> > faced with that steep entry fee.
> I think the biggest part of the learning curve with the VB.NET is
> not syntax, but learning the framework on which it is built.
For CURRENT VB programmers, or for complete neophytes? Or both?
> It is quite extensive. If you include the Microsoft.VisualBasic
> namespace, almost all of the old familar functions are there, making
> the transition not as difficult.
But still difficult. And again the question comes up: what does it buy
us? What does it buy the neophytes? What does that "steeper entry fee"
really buy for the producers of "quick DB interfaces, throw-away
utilities, and client programs"? Especially those who are not "OOP
for OOPs sake" fanatics? We know what it buys M$ - a lock into a
platform they intend to control and manipulate for their own benefit.
> > OTOH, you DO have to jump through hoops to do such formerly simple
> > things as defining an array with a non-zero base.
> True. This one instance doesn't bother me as much, because as
> stated earlier, I almost never use this feature anyway.
It is most often used to map the data structure to the relevant real
world data. Ledgers, inventories, etc. rarely start with item 0. For
those OTHER than professional programmers, base 1 arrays are more
intuitive.
> And I think the things made easier far outway this one
> inconvienenceork
I won't even ASK what a "inconvienenceork" is! <-;
Of the things which you feel are being made easier (such as threading),
which (if any) actually apply to "quick DB interfaces, throw-away
utilities, and client programs"?
> In the course of my work and play, I use several different languages
> (C/C++, Perl, PHP) all of which use 0 based arrays. It is for me the
> natural way to work, so I don't often use this feature.
But for non-programmers, it is not all that natural. Especially when
the program deals with something which is not 0 based in the first
place.
> I am glad it is there though, when I do use it. That is why I
> wanted to see if this could be done in .NET.
As Larry has mentioned, there is a difference between "can be done in
.NET" and "can be done easily in native VB.NET".
[...]
> > > Because, my boss says I have to use VB :) (we have argued over
> > > this a couple of times, but since he is paying my bills...).
> > And other than pure fiat, what reasons/arguments did he advance?
> > And how do they mesh with the .NET changes?
> The biggest reason is developement time. Lets face it, under
> windows at least, VB lets me put together a windows app fairly
> quickly as compared to using C++.
That rather depends on the nature and size of the app, and whether
you are comparing VB with C++ or VC++. Once you get beyond a man-month
or so in complexity, it tends to even out with VC++.
> The other reasons are maintanence. I maybe the only full time
> Windows programmer here, but there are others in the company that
> maintain windows programms, and who know VB. It makes sense for
> them to make me use VB, because if I left, my job could be taken
> over from with in without having to go outside to find someone who
> is proffiecient with both C++ and windows.
Which, in turn, is also a good argument against unnecessary migration
to something like .NET.
> > And do you see .NET as a "workaround" to those arguments?
> Actually, yes. I think that for the most part, to a person who
> knows VB, then a program, though structured a little differently,
> would still be maintainable by someone not familar with VB.NET.
But is that a risk your boss should be willing to take with mission
critical software?
> In the mix I would get the features that make me want to use C++,
> primarily the threading support, but having implementation
> inheretance is a nice bonus.
And a platform that required significant re-education of the other
windows maintainers. Not to mention one that will potentially require
a large (and possibly ongoing) investment on the part of the company.
[...]
> > > > However, I'm not so dumb as to not realize that to use the
> > > > new B-Flat or C# languages _effectively_, I'll need to take
> > > > the object view from requirements, through design, and then
> > > > be able to implement "the object way". There's a good reason
> > > > that Deborah Kurata, in her book, starts from the beginning
> > > > of a project viewing the requirements in terms of objects and
> > > > continues through... it is the only way to do an effective OOP
> > > > application.
> > > As I said, VB.NET is a new mindset. It requires the object way
> > > of thinking.
> > But to what end? Back to the question I started with: why does VB (in
> > that form) exist at all? Why use it rather than the more "professional"
> > languages?
> > The OOP "mindset" is not intuitive to those who have not gone through
> > the academic propaganda mill. The "Bastard Child of OO" which was/is
> > visible in VB6 and the like allows Larry's "Great VB Unwashed" to
> > USE a useful subset thereof without dropping their own professional
> > priorities in order to acquire the OOP mindset.
> This one has made me think a little, and here is what I came up with.
> I think I was wrong when I said that VB.NET requires a new way of
> thinking. In actuality, it encourages a new way of thinking, but
> doesn't require it as C# does.
Actually, you were more correct than you give yourself credit for. One
of the more troublesome aspects of .NET is the need to shift from the
mindset of writing what amounts to a stand-alone program to one of
creating what amounts to an elaborate macro or script for a very large,
expensive Framework. And as others have discussed (beaten to death?),
the syntax changes are troublesome as well.
> With the exception of the GUI, there is nothing that forces a
> VB.NET programmer to use things like inheritance and classes.
And the GUI is the primary selling point of VS in general, and VB
in particular.
> The forms thing can be generated by the designer, and most of that
> is boiler plate type code. Your actuall functionality can be done
> with out classes, just functions in a module. You can pretty much
> just do what most people do anyway, use the built in objects, but
> not create your own.
But that "pretty much" is a large part of the issue.
> > > But what choice do we have, really. You can either move forward
> > > with VB.NET or you can move to another language - Delphi, C/C++
> > > are about the only ones that come to mind.
> > Or create a significant market for a replacement BASIC RAD, making
> > M$ pay attention (as has happened in the past) or lose a significant
> > market to a competitor (as has also happened).
> > > You could do Java, but it is essentially the same as C#.
> > Java has its own niche, primarily 'net related. It is not all that
> > strong for isolated-platform applications.
> I don't particularly like Java, don't get me wrong I like the Java
> syntax and mindset, but if you have to write anything with a GUI -
> its a POS.
> Tom Shelton
--
Larry Linson
should I say "structs that used to be called something else") and calling
functions from within those APIs. I can do the same with functions in
third-party products. But that does not make them built in to VB, no matter
how much you'd like to represent them as being so.
For example, I used a good many functions from LEADTOOLS imaging, and from a
repackaged viewer demo of LEADTOOLS. Just because I could call those
functions from VB, and Access, for that matter, does not make them built in
to either VB or Access.
"Tom Shelton" <to...@dakcs.com> wrote in message
news:LUJ47.2814$A17.5...@news.uswest.net...
Larry Linson
> Larry, just so you know, you can declare an array in a single line:
> Dim myArray(,) As Short = CType(Array.CreateInstance(GetType(Short), New
> Integer() {5, 10}, New Integer() {-1, 20}), Short(,))
>
> Or
>
> Dim myArray() As Array = Array.CreateInstance(GetType(Short), New
Integer()
> {i*5}, New Integer() {-1 * i})
Tom, it's almost incredible to me that you can, with a straight face
(perhaps you are giggling behind your hand, and not keeping a straight face,
though) represent this as a satisfactory replacement. Just for comparison,
why don't you write down the VB6 counterpart? If you aren't too embarrassed,
post it alongside these "one liners".
And, if there is a benefit to me to doing it that way, please explain.
Looks obscure to me, looks like more typing, and looks like something that
will be Pure D Hell to maintain. The Boys and Girls in Redmond surely didn't
have goals of "short and sweet" this time around, did they?
Tom Shelton
> should I say "structs that used to be called something else") and calling
> functions from within those APIs. I can do the same with functions in
> third-party products. But that does not make them built in to VB, no
matter
> how much you'd like to represent them as being so.
>
> For example, I used a good many functions from LEADTOOLS imaging, and from
a
> repackaged viewer demo of LEADTOOLS. Just because I could call those
> functions from VB, and Access, for that matter, does not make them built
in
> to either VB or Access.
You said that VB does not have builtin access to the API. I am saying yes
it does. Maybe, you should define what you mean by builtin access. If you
mean that every API call is miraculously recognized by VB, then your right.
I, on the other hand, take it to mean that the language provides a syntax
for accessing external API's, which VB does via the declare statement, and
that is a built in construct (made even more flexible and powerful in .NET).
I take it you didn't like the change of the Type keyword to Structure.
Larry, there is a good reason for that one, it is a class in the runtime,
they had to change it to avoid conflicts. Really, that is a 2 minute search
and replace operation to change. You do realize that with the new
structures, we have the ability to create unions. This maybe an obscure
feature, but I can think of a couple of API calls it would have made easier
if VB6 supported unions!
I have one last thing to say about the array thing too. If you don't like
the replacement, don't use it. I am trying to understand this, I really am,
but I guess it is hard to feel hurt when a feature is removed that you
hardly ever used anyway. I know others did, I am only trying to help and at
least provide a work around if they feel so inclined to use it. Isn't that
what people have been doing for years with VB - I can't seem to find a way
to do X in the language.... Now, if I could only figure out how to make
those one dimmensional arrays early bound, I'd be all set.
Tom Shelton
Tom Shelton
I got my first copy of VB as a student. It was VB4, and it had only hit the
streets a few months before. I was a casual user of VB all the way until I
got my present job. I have VB5 at home, never really thought it was worth
the upgrade. I have been watching the news groups for a while now, and all
along their has been quite a lot of criticism about VB's lack of support for
free threading, inheritance, and strong type checking. Well we finally got
them, but it seems that they came in a form that no one expected.
Listen, I am a professional programmer who had 4 years of "OOP
indoctrination", so it is no wonder that I am pleased with the changes MS is
making. Most of my programs tend to be class based with very few standard
modules. I like this way of thinking, and programming. Believe me, I have
experience in both. The main portion of my company's product is written in
an obscure flavor of BASIC called IMS/BASIC. It is a port of the old IRIS
Business BASIC to Unix. It runs on SCO, AIX, Motorla, and Linux. I worked
in tech support for a year so I got to deal with this quite a bit (our
customers all have source code on their systems, and tech support does
real-time debugging and patching on customers systems via telnet or dialup
connections). So, I have worked in languages like IMS/BASIC where all
variables are global, and there is no concept of a function or scoping, very
non structured. I have worked in languages like C and Perl (well Perl can
be object oriented, but most code isn't written that way) that are very
procedural. I have worked with C++ and Java, and I much prefer the Object
way, so it is natural for me to be drawn to .NET. To be honest, my last
project as driven me to almost hate VB. We have been trying to develop a
predictive dialer, with a web driven interface. So, my part (the dialer)
has had to be "multithreaded". It has to act as a server to accept
connections to the web (basically acting as a web server), assign inbound
lines to remote dialer stations, and make calls on several lines at once.
This has been quite a challenge in VB6, to make this work efficiently and
share data across threads. If we had been using VB.NET, we may have given
up a small amount of performance, but I believe we would have cut the
development time significantly, just by having the threading a native part
of the language. We almost scrapped the VB version and were going to just
rewrite the whole thing in C++, but at the last minute I came up with a
solution to a couple of the issues we were facing and it looks like we will
be able to finish the project. The point is that all of the issues that we
faced, were primarily related to short comings in VB's support for
threading. Some of the problems required some pretty "ugly hacks" to make
it work. If it wasn't for Matt Curland's "Advanced Visual Basic 6" book,
there is no way we would have gotten the thing working. But, every one of
those issues would have been solved quite handily in VB.NET. So, to me a
few changes in language structure and syntax, are justified IF it results in
greater productivity. For me, I believe that will be the case in VB.NET,
but I can see that this may not be the case for others. I hope that this
isn't the case. I hope that VB stays strong, but if it doesn't there's
always C#!
Tom Shelton
"W.E. (Bill) Goodrich, PhD" <bgoo...@earthlink.net> wrote in message
news:3B53A576...@earthlink.net...
Larry Linson
> You said that VB does not have builtin access to the API. I am saying
yes
> it does. Maybe, you should define what you mean by builtin access. If
you
> mean that every API call is miraculously recognized by VB, then your
right.
> I, on the other hand, take it to mean that the language provides a syntax
> for accessing external API's, which VB does via the declare statement,
and
> that is a built in construct (made even more flexible and powerful in
.NET).
Yes, I do not consider that the ability to reference external functions
amounts to builtin API Access; obviously we differ on definition. Builtin
API access, to me, would imply support for their data "structures" or types,
maybe even some Intellisense as is available for other builtin functions. By
your definition, wouldn't VB6 have "builtin access to assembler language"
because it could access a properly packaged function written in assembler
language? My gawd, there's no limit to what you could say VB had "builtin
access" to.
> I take it you didn't like the change of the Type keyword to Structure.
> Larry, there is a good reason for that one, it is a class in the runtime,
> they had to change it to avoid conflicts. Really, that is a 2 minute
search
> and replace operation to change. You do realize that with the new
> structures, we have the ability to create unions. This maybe an obscure
> feature, but I can think of a couple of API calls it would have made
easier
> if VB6 supported unions!
I'm sorry, you have stated why they changed it, but you have not stated a
"good reason" for that change. BTW, _what's_ a class in the runtime, Struct,
or Type? Changing a perfectly good keyword for interlanguage compatibility
is not, IMNSHO, justifiable. On the other hand, I really suppose I ought not
to complain because I've already said that the total disregard for backward
compatibility and the vast majority of the VB6 user audience makes it a new
language altogether. And perhaps I would not, exceot to mourn the passing of
the worlds most popular application development tool, _if_ you and The Boys
And Girls in Redmond would stop insisting that this is just "the next
release of VB" and admit that, yes, it is a new language which has some of
the same heritage that VB did, and, yes, we expect you to damn well shut up
about compatibility, yes, we expect you to spend the time and effort to
learn the new language, yes, we expect you to move from the kind of
applications you've been doing and do the kind of applications we want done
with the new language.
> I have one last thing to say about the array thing too. If you don't
like
> the replacement, don't use it. I am trying to understand this, I really
am,
> but I guess it is hard to feel hurt when a feature is removed that you
> hardly ever used anyway. I know others did, I am only trying to help and
at
> least provide a work around if they feel so inclined to use it. Isn't
that
> what people have been doing for years with VB - I can't seem to find a
way
> to do X in the language.... Now, if I could only figure out how to make
> those one dimmensional arrays early bound, I'd be all set.
I'm sorry but I don't recall that I said that I hardly ever used that
feature. And, er, if I don't use the replacement, what _am_ I going to use
should my better judgement weaken and I decide to invest the time and effort
in learning this "thing" (trans, "object"; further trans, "object inheriting
from objects inheriting from objects ad infinitum).
But generalized, this may be the best advice you've offered so far. I
certainly have not a plan in the world to _use_ (that is, fire in anger in
paying work) B-Flat until at least Version 2. For all the praise being
heaped on it by its proponents, honest users admit that Beta 1 was full of
issues, Beta 2 does not have resolution for nearly all those issues, and you
can bet that release Version 1 is going to have it's share, as well. If it
were, in fact, merely a new version of VB, it might stabilize with a Service
Release or two or three, with it being actually a new product, don't expect
stability until Version 2 or 3 plus a Service Release or two.
That doesn't mean I'm not going to express my opinions on the subject in the
meanwhile.
Tom Shelton
> Yes, I do not consider that the ability to reference external functions
> amounts to builtin API Access; obviously we differ on definition. Builtin
> API access, to me, would imply support for their data "structures" or types,
> maybe even some Intellisense as is available for other builtin functions. By
> your definition, wouldn't VB6 have "builtin access to assembler language"
> because it could access a properly packaged function written in assembler
> language? My gawd, there's no limit to what you could say VB had "builtin
> access" to.
You do have access to properly packaged assembler routines. C/C++ compilers
generally allow inline assembler code, and there is no reason you can't write a
DLL in assembler, C, or C++ and access that routine from VB. I'm not sure what
you mean by types. There are very few Win32 API calls, that use such exotic
constructs as Unions. The biggest discrepancy I can think of with types, is the
difference between signed and unsigned, and generally, this only matters when
the number is going to be used in calculation or display. As for as
intellisense - once you create a declare statement in a module or bring it in
from a type library, you have intellisense. I suppose one could make the
argument, that there are certain restrictions on the type of functions that VB
can call, it is limited to functions using the stdcall calling convention, but
since almost every API call uses this method (at least Win32 API's) it is a moot
point, IMHO. And there are very good and stable work arounds for those few
times that you need to access a function that uses cdecl.
> I'm sorry, you have stated why they changed it, but you have not stated a
> "good reason" for that change. BTW, _what's_ a class in the runtime, Struct,
> or Type? Changing a perfectly good keyword for interlanguage compatibility
> is not, IMNSHO, justifiable. On the other hand, I really suppose I ought not
> to complain because I've already said that the total disregard for backward
> compatibility and the vast majority of the VB6 user audience makes it a new
> language altogether. And perhaps I would not, exceot to mourn the passing of
> the worlds most popular application development tool, _if_ you and The Boys
> And Girls in Redmond would stop insisting that this is just "the next
> release of VB" and admit that, yes, it is a new language which has some of
> the same heritage that VB did, and, yes, we expect you to damn well shut up
> about compatibility, yes, we expect you to spend the time and effort to
> learn the new language, yes, we expect you to move from the kind of
> applications you've been doing and do the kind of applications we want done
> with the new language.
The runtime class is Type and it is used quite extensively as arguments to many
of the conversion methods. It is a base class to all of the built in datatypes.
I probably would have prefered the word struct rather than structure, but maybe
they thought that was to C like :). And I think that is a good reason to change
the word. They designed the library as a generic set of classes and types so
that it could provide language inteop, I don't think the designers of that
library could make sure that every class name didn't conflict with another
languages keyword. Do you have a better name for the base class for all data
types?
Larry, I have never said this in the "next version of VB" as we know it. I
agree, that VB.NET is a different, though IMHO superiour, language then
VB.CLASSIC. But I wouldn't say theres been a "total disregard for backward
compatibility". Microsoft has provided a namespace, that provides much of the
same functionality. Yes there are compatability issues. It would be nice if it
was 100% backwards compatible, but I don't mind the changes that have been made
because, at least for me, they enhance overall productivity.
I don't think the biggest issues with the upgrade are so much the array thing,
or even the change of a few keywords. These to issues are IMHO fairly easy to
solve with a search and replace and some minor code reworking. I believe the
biggest, and probably the most significant changes are (these are the ones that
keep bitting me as I am learning the new VB), in no particular order:
1. Arguments default to pass ByVal rather then ByRef. This one hasn't been two
bad, because I have gotten into the habbit of declaring ByVal and ByRef
explicitly anyway, but I will admit it has bit me a couple of times when I
failed to follow my natural inclination.
2. Change of size of the data types. This one is probably my biggest
complaint. I am so used to a using Long when I want a 32 bit value, especially
in API calls, that this one has caused me to start using the more explicit names
of Int16, Int32, and Int64. I think that MS should have kept the familar names
the same size and added a Long Long or some other data type to handle the 64 bit
integer, or just removed the old data type names completely. At least by
removing them, it would have made it less confussing, especially after
programming in VB.CLASSIC all day and then playing with .NET at night.
3. Resource managment. The new GC model, precludes what has been dubbed
"determinisitc finalization". For most classes this isn't really an issue, but
for those few times when it is needed, it lays a little more responsibility at
the feet of the programmer then did previous versions. I understand there are
technical reasons why it is difficult to impossible for this to be solved by the
compiler, but it does add to VB a potential for a common bug in C/C++ and Java -
the resource leak. Yes, Java can also have this same problem if you allocate
resources not managed by the JVM. Not that VB.CLASSIC couldn't have this
problem under certain conditions either, but it did make for some nice clean
code in certain situations. I believe that this issue, more than any other will
be the biggest head ache (next to learning the framework) for new and current VB
programmers to deal with. C# has some syntactic suger to make the code a little
cleaner, but still doesn't solve the issue. Fortunately, I have some experience
with Java, so I feel somewhat, though not completely prepared for this one.
> I'm sorry but I don't recall that I said that I hardly ever used that
> feature. And, er, if I don't use the replacement, what _am_ I going to use
> should my better judgement weaken and I decide to invest the time and effort
> in learning this "thing" (trans, "object"; further trans, "object inheriting
> from objects inheriting from objects ad infinitum).
I didn't mean to imply you didn't use this feature. I meant I, not you, sorry
for the ambiguity. From your comment about inheritance here, I am getting the
feeling that you think this is a bad thing? I think inheritance, can be a bad
thing if over used. But, I also feel that it makes some things easier, and can
be a powerful tool. If you read most object oriented programming books, they
discourge inheritance, and encourage delegation (often described as the "has a"
relationship). This is something I have been using in VB for a long time, and
something I plan to continue to use, but I like the fact that I now have true
inheritance for those times that I feel it is warented.
> But generalized, this may be the best advice you've offered so far. I
> certainly have not a plan in the world to _use_ (that is, fire in anger in
> paying work) B-Flat until at least Version 2. For all the praise being
> heaped on it by its proponents, honest users admit that Beta 1 was full of
> issues, Beta 2 does not have resolution for nearly all those issues, and you
> can bet that release Version 1 is going to have it's share, as well. If it
> were, in fact, merely a new version of VB, it might stabilize with a Service
> Release or two or three, with it being actually a new product, don't expect
> stability until Version 2 or 3 plus a Service Release or two.
>
> That doesn't mean I'm not going to express my opinions on the subject in the
> meanwhile.
Please keep expressing them. I like this kind of disscussion.
The biggest problems I see for VB.NET for client side apps, is the lack of
distribution of the runtime. For a while, until it is integrated into the OS,
and has had time to become common, distribution is going to be sort of a pain.
The other problem is that the .NET frameworks lack of support for W95. There is
still quite a base of W95 machines, we have quite a few here even, and that will
somewhat limmit the market for a while. But, for the type of stuff I do at work
(all of my stuff is exclusively NT and W2K), it is absolutly a step forward.
I think MS realizes that this platform is not right for everyone. They say they
are going to continue to support VB.CLASSIC at least for a while, but it would
be nice if they could continue to develope it in tandem.
Tom Shelton
W.E. (Bill) Goodrich, PhD
"Tom Shelton" <t...@mtogden.com> writes:
> I have a few thoughts regarding your response:
> I got my first copy of VB as a student. It was VB4, and it had only
> hit the streets a few months before. I was a casual user of VB all the
> way until I got my present job.
And do you really think that would have happened if the "buy in" had
been steeper - say, about as steep as that for VC++?
> I have VB5 at home, never really thought it was worth the upgrade.
> I have been watching the news groups for a while now, and all along their
> has been quite a lot of criticism about VB's lack of support for
> free threading, inheritance, and strong type checking.
Actually, I haven't seen all that much of such criticism. And what I have
seen has seemed to come from the knee-jerk OOP sorts rather than from the
more common VB "working stiffs" or the like. Few people seem to have
actually been hampered by those lacks in working practice. Instead, the
complaints have largely come as part of "VB isn't OO enough" diatribes.
> Well we finally got them, but it seems that they came in a form that no
> one expected.
Not really. We got (in Beta) something that incidentally has those features
and is being CALLED a form of VB - rather a different matter.
> Listen, I am a professional programmer who had 4 years of "OOP
> indoctrination", so it is no wonder that I am pleased with the changes
> MS is making.
Just as Larry and I are professional programmers with decades of experience
before OO even came into existence. We have seen such academic fads come and
go, and the damage caused by unquestioning acceptance thereof. Our response
to changes like the .NET initiative is to look at the REAL effects rather
than the vaporous academic promises and the appeal to academic propriety.
And the real effects of the VB.NET change are not pretty.
Those of us with different backgrounds, activities, and foci will point to
different aspects of the change as "worse than others". For instance: the
top of my "disaster" list is the loss of the ability to compile to native
code, while that aspect barely makes some other people's lists. What to
you is an insignificant loss of performance (runs slower, takes more room,
etc.) is a killer for some of my apps. As is the inability to run under
W95 and earlier (the M$ "forced upgrade" strategy - if enough of the newer
apps and/or versions of current apps are incompatible with the older OS
version, users will spend money to upgrade to a newer OS version). OTOH, I
do not have tens of thousands of lines of legacy code that would need
updating.
Just as OO constructs like overloading constitute FUNDAMENTAL violations
of the earlier fad of "Structured Programming" (the tattered remnants of
which are still taught), the Next Great Academic Fad will likely trample
many of those cherished OOP constructs. An appeal to "it's better because
it does things the way *I* was told they should be done" can look pretty
shabby a way down the road, when the real effects are clear and the fad is
no longer current. One of the first parts I expect to see stomped into the
mud is the call for separation of function and implementation - it has
caused too many "unexpected" (unexpected, my Backside!) maintainence
problems.
> Most of my programs tend to be class based with very few standard
> modules.
And most of the ones I have written or encountered have been exactly the
opposite.
> I like this way of thinking, and programming. Believe me, I have
> experience in both.
So do we. But our experience with the non-OOP approaches is far more
extensive and deep, apparently.
> The main portion of my company's product is written in an obscure flavor
> of BASIC called IMS/BASIC.
For more than a decade, it was anything BUT "obscure". But that was before
your time, apparently.
> It is a port of the old IRIS Business BASIC to Unix. It runs on SCO,
> AIX, Motorla, and Linux. I worked in tech support for a year so I got
> to deal with this quite a bit (our customers all have source code on
> their systems, and tech support does real-time debugging and patching
> on customers systems via telnet or dialup connections). So, I have
> worked in languages like IMS/BASIC where all variables are global, and
> there is no concept of a function or scoping, very non structured.
And yet, miracle of miracles, that code has continued to run - even thrive -
after decades of use and modification. How could that POSSIBLY be? But that
brief experience does not seem to include any of the design and
implementation "thinking and programming" you allude to above. Did you
actually design and implement - from the ground up - any significantly
large and complex programs in that non-OO language, environment, and
methodology?
The "very non structured" comment is very funny, from a historical view.
Originally, the central value of Structured Programming was strict
determinism and the other aspects were primarily in support of that
value. OOP is anything BUT "strictly deterministic" in theory and
practice. In addition to the overloading problem, it violates the
central tenet of strict separation of code and data as well as a variety
of others.
> I have worked in languages like C and Perl (well Perl can be object
> oriented, but most code isn't written that way) that are very
> procedural.
I have worked in languages like Assembly, Fortran, COBOL, BASIC, ADA, and
a variety of others - ALL very procedural. And when you come down to it,
the "guts" of even the most OO program are procedural as well. The illusion
that it is otherwise is just that - an expensive, potentially damaging
illusion.
> I have worked with C++ and Java, and I much prefer the Object way, so
> it is natural for me to be drawn to .NET.
Unless and until your experience helps you to outgrow that academic fad.
> To be honest, my last
> project as driven me to almost hate VB. We have been trying to develop a
> predictive dialer, with a web driven interface. So, my part (the dialer)
> has had to be "multithreaded". It has to act as a server to accept
> connections to the web (basically acting as a web server),
And therein lies the trap - potentially thousands of dollars per year in
licensing fees to M$ when they define that function as a "server" function
under the licensing agreement. Or even a decision by M$ that the app will
not be allowed to run at all. While the .NET language changes are bad
enough, the "other side" of the .NET framework (such as the "server side")
is far worse.
> assign inbound lines to remote dialer stations, and make calls on several
> lines at once.
That does not seem to be particularly well suited to ANY variety of BASIC
that I have seen.
> This has been quite a challenge in VB6, to make this work efficiently and
> share data across threads. If we had been using VB.NET, we may have given
> up a small amount of performance, but I believe we would have cut the
> development time significantly, just by having the threading a native
> part of the language.
As long as you are playing the "If" game, wouldn't it have cut it even more
to have used VC++6 instead? If you had been using VB.NET, you would have
spent more time than you seem to realize fighting the instabilities and
inconsistencies of the Beta, only to produce a product with an uncertain
future.
> We almost scrapped the VB version and were going to just rewrite the
> whole thing in C++, but at the last minute I came up with a solution to
> a couple of the issues we were facing and it looks like we will
> be able to finish the project.
Congratulations! (seriously!) That sort of problem solving is why they
pay us the "big bucks".
> The point is that all of the issues that we faced, were primarily related
> to short comings in VB's support for threading.
In large part because you were working with a relatively stable tool (VB6)
with an even more stable infrastructure. The instabilities inherent in the
.NET framework in general and its VB "language" in particular should be
enough to warn any sane programmer away from making "professional" use of
them for years to come.
> Some of the problems required some pretty "ugly hacks" to make
> it work. If it wasn't for Matt Curland's "Advanced Visual Basic 6" book,
> there is no way we would have gotten the thing working. But, every one
> of those issues would have been solved quite handily in VB.NET.
And replaced by other, larger issues. For instance, no amount of "ugly
hacks" would be likely to allow it to run under W95.
> So, to me a few changes in language structure and syntax, are justified
> IF it results in greater productivity.
IF those were the ONLY changes, you might have some semblence of a point.
But the major changes to the infrastructure (the creation and mandate of
entire .NET framework) are a far greater issue.
> For me, I believe that will be the case in VB.NET,
ONLY when/where the .NET infrastructure is not an issue.
> but I can see that this may not be the case for others. I hope that
> this isn't the case. I hope that VB stays strong, but if it doesn't
> there's always C#!
Or more importantly, there are always non-M$ products that avoid the
entire .NET trap. And if M$ tries to impede their functioning, even a
Republican AG would find it difficult to resist the pressures for more
prosecution.
> Tom Shelton
One last note: If the "upfront" comments run more than about 4 lines,
it is a good idea to indicate which post/poster you are responding to
before making those comments. Personally, I prefer inline comments
for anything of substance.
W.E. (Bill) Goodrich, PhD
"Tom Shelton" <to...@dakcs.com> writes:
> Larry,
> > Yes, I do not consider that the ability to reference external
> > functions amounts to builtin API Access; obviously we differ on
> > definition. Builtin API access, to me, would imply support for
> > their data "structures" or types, maybe even some Intellisense as
> > is available for other builtin functions. By your definition,
> > wouldn't VB6 have "builtin access to assembler language" because
> > it could access a properly packaged function written in assembler
> > language? My gawd, there's no limit to what you could say VB had
> > "builtin access" to.
I fully agree with Larry. A generic "access to external code" is far
from being the same thing as direct support for some particular body
of functions.
> You do have access to properly packaged assembler routines. C/C++
> compilers generally allow inline assembler code,
But VB does not, which is the point.
> and there is no reason you can't write a DLL in assembler, C, or C++
> and access that routine from VB.
Which is not the same thing at all.
[...]
> > I'm sorry, you have stated why they changed it, but you have not
> > stated a "good reason" for that change. BTW, _what's_ a class in
> > the runtime, Struct, or Type? Changing a perfectly good keyword for
> > interlanguage compatibility is not, IMNSHO, justifiable.
[...]
> The runtime class is Type and it is used quite extensively as arguments
> to many of the conversion methods. It is a base class to all of the
> built in datatypes. I probably would have prefered the word struct
> rather than structure, but maybe they thought that was to C like :).
> And I think that is a good reason to change the word. They designed
> the library as a generic set of classes and types so that it could
> provide language inteop, I don't think the designers of that library
> could make sure that every class name didn't conflict with another
> languages keyword.
Why on Earth not? It's not as if they had dozens of languages to look
at - the VS suite (even the .NET version) is very limited. I consider
such an omission to be an act of professional malpractice.
> Do you have a better name for the base class for all data types?
BaseDataType, DataType, CommonDataStructure, or any of a thousand
others. There are no syntactic limitations which would preclude such
long compound names, and the base class AS SUCH should not be used all
that often in user-generated (read: not from M$) code.
> Larry, I have never said this in the "next version of VB" as we
> know it. I agree, that VB.NET is a different, though IMHO
> superiour,
And IMHO vastly (and potentially disastrously) inferior.
> language then VB.CLASSIC. But I wouldn't say theres been a "total
> disregard for backward compatibility". Microsoft has provided a
> namespace, that provides much of the same functionality.
But not such "minor" things as a compile to native code, or W95
compatibility.
In practice, that namespace appears to be little more than a PR ploy.
[...]
> I think MS realizes that this platform is not right for everyone.
> They say they are going to continue to support VB.CLASSIC at least
> for a while, but it would be nice if they could continue to develope
> it in tandem.
As I said before, it would be uncharacteristically foolish for them
to SAY anything else. But as we saw in the documents from the antitrust
case, what they SAY may have little to do with what they intend to DO.
Tom Shelton
Comments inline.
> > I got my first copy of VB as a student. It was VB4, and it had only
> > hit the streets a few months before. I was a casual user of VB all the
> > way until I got my present job.
>
> And do you really think that would have happened if the "buy in" had
> been steeper - say, about as steep as that for VC++?
I bought Borland Devloper Studio at the same time (contained Borland C++
4.52 and 5.0, and the ability to compile Java programs, and a bunch of there
database stuff). I have been working with C++ for about as long as I have
in VB. So, if I had at the time been inclined to by VC++ (I liked the
Borland environment better back then), I would have bought it.
> > I have VB5 at home, never really thought it was worth the upgrade.
> > I have been watching the news groups for a while now, and all along
their
> > has been quite a lot of criticism about VB's lack of support for
> > free threading, inheritance, and strong type checking.
>
> Actually, I haven't seen all that much of such criticism. And what I have
> seen has seemed to come from the knee-jerk OOP sorts rather than from the
> more common VB "working stiffs" or the like. Few people seem to have
> actually been hampered by those lacks in working practice. Instead, the
> complaints have largely come as part of "VB isn't OO enough" diatribes.
Listen, I wasn't one of the people laying down the "VB isn't OO enough"
criticism. I personally feel that the major feature lacking from VB's OO
is implementation inheritance, and that is a rather overused tool anyway.
It is nice to have in those few situations where it is warrented, but I
don't think it is necessary. Delegation, and Inteface inheritance are the
tools that are the most neccessary, IMHO, and VB supports these quite
nicely. My major complaints about VB, are it's lack of strong type
checking, and no support for free threading - neither of which have anything
to do with OO. I wasn't trying to say there was a constant barrage of
complaints, but these issues did come up quite frequently on those VB Wish
List posts.
> > Listen, I am a professional programmer who had 4 years of "OOP
> > indoctrination", so it is no wonder that I am pleased with the changes
> > MS is making.
>
> Just as Larry and I are professional programmers with decades of
experience
> before OO even came into existence. We have seen such academic fads come
and
> go, and the damage caused by unquestioning acceptance thereof. Our
response
> to changes like the .NET initiative is to look at the REAL effects rather
> than the vaporous academic promises and the appeal to academic propriety.
> And the real effects of the VB.NET change are not pretty.
I am not discounting your much greater experience. I realize that both of
you have been working in this proffession far longer than I have. I realize
that you have been around the block, so to speak. But, I would hardly call
OOP an "academic fad". I believe that OOP has proven it's worth in the
market place. Yes, OOP went through it's honymoon faze. But, overtime,
things have settled down and people have started using it more effectively.
> Those of us with different backgrounds, activities, and foci will point to
> different aspects of the change as "worse than others". For instance: the
> top of my "disaster" list is the loss of the ability to compile to native
> code, while that aspect barely makes some other people's lists. What to
> you is an insignificant loss of performance (runs slower, takes more room,
> etc.) is a killer for some of my apps. As is the inability to run under
> W95 and earlier (the M$ "forced upgrade" strategy - if enough of the newer
> apps and/or versions of current apps are incompatible with the older OS
> version, users will spend money to upgrade to a newer OS version). OTOH, I
> do not have tens of thousands of lines of legacy code that would need
> updating.
.NET code always gets compiled to native code at runtime, or install. I'm
sure you know this. Yes, VB doesn't have the option to compile directly to
native code, I believe only MC++ has this option, but it still gets compiled
to native code before execution. The JIT compile does result it some loss
of performance, since the compiler has to analyze and compile the code prior
to its run.
As I stated in another post to Larry, I also believe that the inability to
support W95 is going to slow down the use of .NET as a tool for client
programming. I believe, that it will best be suited to server side, and
those situations (such as mine) where your software can only run on specific
OS's. But, I believe that as the framework becomes more widely distributed
and more people upgrade this will change.
> > Most of my programs tend to be class based with very few standard
> > modules.
>
> And most of the ones I have written or encountered have been exactly the
> opposite.
This is a style difference that even VB.NET will support. You don't have to
organize your programms into objects if you don't want to.
> > It is a port of the old IRIS Business BASIC to Unix. It runs on SCO,
> > AIX, Motorla, and Linux. I worked in tech support for a year so I got
> > to deal with this quite a bit (our customers all have source code on
> > their systems, and tech support does real-time debugging and patching
> > on customers systems via telnet or dialup connections). So, I have
> > worked in languages like IMS/BASIC where all variables are global, and
> > there is no concept of a function or scoping, very non structured.
>
> And yet, miracle of miracles, that code has continued to run - even
thrive -
> after decades of use and modification. How could that POSSIBLY be? But
that
> brief experience does not seem to include any of the design and
> implementation "thinking and programming" you allude to above. Did you
> actually design and implement - from the ground up - any significantly
> large and complex programs in that non-OO language, environment, and
> methodology?
Yes it runs, and yes the company continues to grow. I am not even trying to
imply that OOP is the only way of thinking or programming.
And by the way, yes, I was and am still involved in the design and
implementation of large projects. The company I work for is a little unique
in the way they do buisness. Even in technical support, I was involved in
writting custom software for our customers. Most of us there are. And I
have since moved out of support to R&D. My primmary job is in developing
our windows based products, and as stated earlier, they make me use VB.
> The "very non structured" comment is very funny, from a historical view.
> Originally, the central value of Structured Programming was strict
> determinism and the other aspects were primarily in support of that
> value. OOP is anything BUT "strictly deterministic" in theory and
> practice. In addition to the overloading problem, it violates the
> central tenet of strict separation of code and data as well as a variety
> of others.
That is funny since OO, takes quite the opposite view. An object by
deffinition is the encapsulation of the data and the code that acts on that
data into a single unit. OOP is about managing complexity. It is all about
the Divide and Conquer stratagy of programming. I believe it works quite
well.
I don't understand what this overloading problem you keep refering to is. I
have never had a problem with it. Can you elaborate on this? Do you mean
method overloading, or operator overloading?
> That does not seem to be particularly well suited to ANY variety of BASIC
> that I have seen.
It's not. I tried to encourage the use of VC++ from the beggining. I was
actually hoping to not figure out how to make it work, but I couldn't in
good conscience just let the project fail after the number of hours I had
already put into the project, not to mention the other two developers
working on the web interface and the Unix programming.
> > This has been quite a challenge in VB6, to make this work efficiently
and
> > share data across threads. If we had been using VB.NET, we may have
given
> > up a small amount of performance, but I believe we would have cut the
> > development time significantly, just by having the threading a native
> > part of the language.
>
> As long as you are playing the "If" game, wouldn't it have cut it even
more
> to have used VC++6 instead? If you had been using VB.NET, you would have
> spent more time than you seem to realize fighting the instabilities and
> inconsistencies of the Beta, only to produce a product with an uncertain
> future.
See above for the VC++ response. Yeah I realize that there is instabilities
in the Beta. It is a Beta. That's why, though it was availabe, and we did
briefly disscuss it use, decided not to go the .NET route on this project.
Besides, our release date will be long before .NET is out of Beta. In the
future once the platform has had a chance to stabalize, decisions might be
different.
> > Some of the problems required some pretty "ugly hacks" to make
> > it work. If it wasn't for Matt Curland's "Advanced Visual Basic 6"
book,
> > there is no way we would have gotten the thing working. But, every one
> > of those issues would have been solved quite handily in VB.NET.
>
> And replaced by other, larger issues. For instance, no amount of "ugly
> hacks" would be likely to allow it to run under W95.
This, in my case is not a problem. The hardware and software we are working
with only runs on NT and W2K. This is commercial dialer equipment, not
something the W95 handles very well.
Tom Shelton
W.E. (Bill) Goodrich, PhD
"Tom Shelton" <t...@mtogden.com> writes:
> Bill,
> Comments inline.
Likewise.
> > > I got my first copy of VB as a student. It was VB4, and it had
> > > only hit the streets a few months before. I was a casual user
> > > of VB all the way until I got my present job.
> > And do you really think that would have happened if the "buy in"
> > had been steeper - say, about as steep as that for VC++?
> I bought Borland Devloper Studio at the same time (contained Borland
> C++ 4.52 and 5.0, and the ability to compile Java programs, and a
> bunch of there database stuff). I have been working with C++ for
> about as long as I have in VB. So, if I had at the time been
> inclined to by VC++ (I liked the Borland environment better back
> then), I would have bought it.
Which just goes to support my point: the steeper "buy in" is
counterproductive in terms of a major VB market: students.
> > > I have VB5 at home, never really thought it was worth the upgrade.
> > > I have been watching the news groups for a while now, and all
> > > along their has been quite a lot of criticism about VB's lack of
> > > support for free threading, inheritance, and strong type checking.
> > Actually, I haven't seen all that much of such criticism. And what
> > I have seen has seemed to come from the knee-jerk OOP sorts rather
> > than from the more common VB "working stiffs" or the like. Few
> > people seem to have actually been hampered by those lacks in
> > working practice. Instead, the complaints have largely come as part
> > of "VB isn't OO enough" diatribes.
> Listen, I wasn't one of the people laying down the "VB isn't OO enough"
> criticism.
I didn't say you were. The observation was historical, not personal.
[...]
> I wasn't trying to say there was a constant barrage of complaints,
> but these issues did come up quite frequently on those VB Wish List
> posts.
I tend to differentiate between "complaints/criticisms" and "items on
wish lists". There are "wish list items" I have commented on as well,
but they constitute "gee, it would be Even Better with..." comments
rather than criticisms or complaints about the lack thereof. And of
those posts/threads I have seen with the complaints in question AS
criticisms/complaints, virtually all have come as described.
> > > Listen, I am a professional programmer who had 4 years of "OOP
> > > indoctrination", so it is no wonder that I am pleased with the
> > > changes MS is making.
> > Just as Larry and I are professional programmers with decades of
> > experience before OO even came into existence. We have seen such
> > academic fads come and go, and the damage caused by unquestioning
> > acceptance thereof. Our response to changes like the .NET initiative
> > is to look at the REAL effects rather than the vaporous academic
> > promises and the appeal to academic propriety. And the real effects
> > of the VB.NET change are not pretty.
> I am not discounting your much greater experience.
I didn't say you were. I was merely following your lead by clarifying
"where we are coming from" for the benefit of other readers.
> I realize that both of you have been working in this proffession far
> longer than I have.
Have you seen our discussions of ancient technology? <-;
> I realize that you have been around the block, so to speak. But,
> I would hardly call OOP an "academic fad".
And having seen such things come and go in the past, I would - and
do - call it an academic fad. As do an increasing number of Academics.
> I believe that OOP has proven it's worth in the market place.
Not really. The best that can be said is that - unlike its Structured
Programming predecessor - it has not proven massively counterproductive
in major categories of programming.
> Yes, OOP went through it's honymoon faze. But, overtime, things have
> settled down and people have started using it more effectively.
People have used OOP oriented TOOLS over time - mostly because of the
academic fad and its effect on readily available programmers and
because they replaced earlier equivalent tools - but they have been
"using them more effectively" by learning how to use them to generate
old-fashioned heavily procedural software. The few aspects of OOP that
are really being used are those - such as modularity - that were around
and in widespread use for decades before OOP existed. And those aspects
will likely be just as much a part of the next academic fad, and the
one after that, and the one after that, and...
> > Those of us with different backgrounds, activities, and foci will
> > point to different aspects of the change as "worse than others".
> > For instance: the top of my "disaster" list is the loss of the
> > ability to compile to native code, while that aspect barely makes
> > some other people's lists. What to you is an insignificant loss of
> > performance (runs slower, takes more room, etc.) is a killer for
> > some of my apps. As is the inability to run under W95 and earlier
> > (the M$ "forced upgrade" strategy - if enough of the newer apps
> > and/or versions of current apps are incompatible with the older OS
> > version, users will spend money to upgrade to a newer OS version).
> > OTOH, I do not have tens of thousands of lines of legacy code that
> > would need updating.
> .NET code always gets compiled to native code at runtime, or install.
Which is the problem. Or rather the source of several of the problems.
I make heavy use of MY ability - as the developer - to compile the
program to native code. Currently (with a little "outside help"), I can
create a stand-alone "load and run" executable with no need for external
DLLs or the like. And in that way the code is completely stable,
irrespective of the versions of various other programs and libraries
used in the target system.
> I'm sure you know this.
Yes. And it is what I am protesting.
> Yes, VB doesn't have the option to compile directly to native code,
EXACTLY!!! And for my applications, that is a "killer" lack. The
fact that I CAN do so in VB6 is one of the factors which is likely to
keep me from EVER downgrading to .NET.
> I believe only MC++ has this option, but it still gets compiled
> to native code before execution. The JIT compile does result it
> some loss of performance,
And significant loss of program security, stability, and other aspects
of the development and delivery processes.
> since the compiler has to analyze and compile the code prior to its
> run.
Repeatedly. But unfortunately, the "analysis" is not necessarily
limited to the factors necessary for compilation. Nor are the results
of that analysis necessarily used ONLY for the compilation. M$ has
admitted an intention to use .NET for collection of business
intellegence - something completely unacceptable to many of my clients.
M$ has stated (through executives and other spokespersons) that it is
interested in changing the dominant software paradigm from the idea of
"buying" a program (in practice, a one-time licensing fee for lifetime
use) to that of "contracting for a service" (continuing periodic
payments for the ongoing ability to use the functionality). Behind all
the (largely empty) rhetoric about "support" is (according to company
documents) a focus on cash flow and power. And both .NET and XP are
designed to be significant parts of that attempted shift.
> As I stated in another post to Larry, I also believe that the
> inability to support W95 is going to slow down the use of .NET as
> a tool for client programming.
Among other things.
> I believe, that it will best be suited to server side,
Which is subject to literally thousands of dollars in additional
annual licensing fees and various restrictions. M$ makes no bones about
wanting to control the server side.
> and those situations (such as mine) where your software can only
> run on specific OS's. But, I believe that as the framework becomes
> more widely distributed and more people upgrade this will change.
That is what M$ apparently hopes.
> > > Most of my programs tend to be class based with very few standard
> > > modules.
> > And most of the ones I have written or encountered have been
> > exactly the opposite.
> This is a style difference that even VB.NET will support. You don't
> have to organize your programms into objects if you don't want to.
> > > It is a port of the old IRIS Business BASIC to Unix. It runs
> > > on SCO, AIX, Motorla, and Linux. I worked in tech support for
> > > a year so I got to deal with this quite a bit (our customers all
> > > have source code on their systems, and tech support does real-time
> > > debugging and patching on customers systems via telnet or dialup
> > > connections). So, I have worked in languages like IMS/BASIC
> > > where all variables are global, and there is no concept of a
> > > function or scoping, very non structured.
> > And yet, miracle of miracles, that code has continued to run -
> > even thrive - after decades of use and modification. How could
> > that POSSIBLY be? But that brief experience does not seem to
> > include any of the design and implementation "thinking and
> > programming" you allude to above. Did you actually design and
> > implement - from the ground up - any significantly large and
> > complex programs in that non-OO language, environment, and
> > methodology?
> Yes it runs, and yes the company continues to grow. I am not even
> trying to imply that OOP is the only way of thinking or programming.
Just that it is a "superior" one - a claim that I dispute.
> And by the way, yes, I was and am still involved in the design and
> implementation of large projects.
But that wasn't the central part of what I asked. I asked whether you
had designed and implemented - from the ground up - in IMS/BASIC while
using a completely non-OOP methodology. Not whether you had "been
involved in" design and implementation of large projects in other
languages.
> The company I work for is a little unique in the way they do buisness.
> Even in technical support, I was involved in writting custom software
> for our customers.
Large scale custom software (2500+ lines of BASIC code) or smaller,
specialized apps?
> Most of us there are. And I have since moved out of support to R&D.
> My primmary job is in developing our windows based products, and as
> stated earlier, they make me use VB.
> > The "very non structured" comment is very funny, from a historical
> > view. Originally, the central value of Structured Programming was
> > strict determinism and the other aspects were primarily in support
> > of that value. OOP is anything BUT "strictly deterministic" in
> > theory and practice. In addition to the overloading problem, it
> > violates the central tenet of strict separation of code and data
> > as well as a variety of others.
> That is funny since OO, takes quite the opposite view.
Which is exactly why it is so humorous to see such a vocal OO advocate
disparagingly describe some code as "very non structured".
> An object by deffinition is the encapsulation of the data and the
> code that acts on that data into a single unit.
Basically, the opposite of SP.
> OOP is about managing complexity.
So were '60s era "modular programming", the more recent "Structured
Programming", "Top Down" and "Bottom Up" design, the more general
"good programming practices" which spread across the decades in
question, etc.
Unfortunately, the reality is that all too often the OOP approach
actually increases the functional complexity of the program rather
than reducing it.
> It is all about the Divide and Conquer stratagy of programming.
So were the others.
> I believe it works quite well.
Yes, you very clearly do. But most of the real virtues you ascribe to
OOP are artifacts of the earlier practices of modularity and the like
(which OOP borrowed) rather than of "the encapsulation of the data and
the code that acts on that data into a single unit" (the element that
differentiates OOP).
> I don't understand what this overloading problem you keep refering
> to is.
The fact that it constitutes an EXTREME, fundamental violation of
Structured Programming.
> I have never had a problem with it. Can you elaborate on this?
It is only a problem in terms of the earlier academic fad of Structured
Programming.
> Do you mean method overloading, or operator overloading?
Both.
> > That does not seem to be particularly well suited to ANY variety
> > of BASIC that I have seen.
> It's not.
Which is part of the reason that it does not "play well" as a basis
for broad-brush complaints about VB6. And it plays even less well as
a basis for declaring the "superiority" of VB.NET - especially when
you try to dismiss the downside arguments.
> I tried to encourage the use of VC++ from the beggining. I was
> actually hoping to not figure out how to make it work,
Tsk, tsk! <-;
> but I couldn't in good conscience just let the project fail after
> the number of hours I had already put into the project, not to
> mention the other two developers working on the web interface and
> the Unix programming.
> > > This has been quite a challenge in VB6, to make this work
> > > efficiently and share data across threads. If we had been using
> > > VB.NET, we may have given up a small amount of performance, but
> > > I believe we would have cut the development time significantly,
> > > just by having the threading a native part of the language.
> > As long as you are playing the "If" game, wouldn't it have cut it
> > even more to have used VC++6 instead? If you had been using VB.NET,
> > you would have spent more time than you seem to realize fighting
> > the instabilities and inconsistencies of the Beta, only to produce
> > a product with an uncertain future.
> See above for the VC++ response.
The point was that you were playing the "if I coulda used what I
couldn't use" game, which applies to VC++ every bit as well as to .NET.
> Yeah I realize that there is instabilities in the Beta. It is a Beta.
> That's why, though it was availabe, and we did briefly disscuss it use,
> decided not to go the .NET route on this project. Besides, our release
> date will be long before .NET is out of Beta. In the future once the
> platform has had a chance to stabalize, decisions might be different.
But I suspect that those decisions will be strongly influenced - moreso
than you seem to anticipate - by Licensing and other financial and
security issues.
> > > Some of the problems required some pretty "ugly hacks" to make
> > > it work. If it wasn't for Matt Curland's "Advanced Visual Basic
> > > 6" book, there is no way we would have gotten the thing working.
> > > But, every one of those issues would have been solved quite
> > > handily in VB.NET.
> > And replaced by other, larger issues. For instance, no amount of
> > "ugly hacks" would be likely to allow it to run under W95.
> This, in my case is not a problem. The hardware and software we are
> working with only runs on NT and W2K. This is commercial dialer
> equipment, not something the W95 handles very well.
And thus likely to fall under the predatory M$ server licensing
policies.
> Tom Shelton
Joseph T. Adams
: Unfortunately, VB.NET doesn't support operator overloading :(
My mistake . . .I thought for some reason that it did.
That does make life a little more difficult.
Joe
Joe "Nuke Me Xemu" Foster
> Yes, you very clearly do. But most of the real virtues you ascribe to
> OOP are artifacts of the earlier practices of modularity and the like
> (which OOP borrowed) rather than of "the encapsulation of the data and
> the code that acts on that data into a single unit" (the element that
> differentiates OOP).
At least the OOPies are waking up to the fact that methods break
encapsulation. See Scott Meyer's article "How Non-Member Functions
Improve Encapsulation" in the Feb 2000 issue of "C/C++ Users Journal".
[Tom Sheldon wrote:]
> > I don't understand what this overloading problem you keep refering
> > to is.
>
> The fact that it constitutes an EXTREME, fundamental violation of
> Structured Programming.
Is that really so bad? After all, you said yourself that Structured
Programming has "proven massively counterproductive in major
categories of programming." At least overloading can be resolved at
compile-time. Even the IDE should be able to figure out which code
would be called.
--
Joe Foster <mailto:jfo...@ricochet.net> Got Thetans? <http://www.xenu.net/>
W.E. (Bill) Goodrich, PhD
> "W.E. (Bill) Goodrich, PhD" <bgoo...@earthlink.net> wrote in
> message <news:3B560BD0...@earthlink.net>...
> > Yes, you very clearly do. But most of the real virtues you
> > ascribe to OOP are artifacts of the earlier practices of
> > modularity and the like (which OOP borrowed) rather than of
> > "the encapsulation of the data and the code that acts on that
> > data into a single unit" (the element that differentiates OOP).
> At least the OOPies are waking up to the fact that methods break
> encapsulation. See Scott Meyer's article "How Non-Member Functions
> Improve Encapsulation" in the Feb 2000 issue of "C/C++ Users
> Journal".
Good article, overall.
> [Tom Sheldon wrote:]
> > > I don't understand what this overloading problem you keep
> > > refering to is.
> > The fact that it constitutes an EXTREME, fundamental violation of
> > Structured Programming.
> Is that really so bad?
Not at all. It is just relevant to evaluating the humor inherent in
a vocal OOP advocate deriding a body of code as "very non structured".
> After all, you said yourself that Structured Programming has
> "proven massively counterproductive in major categories of
> programming."
And as a result lost favor as an academic fad. What is left are a few
face-saving scraps which allow the earlier academics to avoid the
accusation of having taught/advocated TOTAL garbage. It will be
interesting to see which scraps of OOP serve a similar function in
a few years.
> At least overloading can be resolved at compile-time. Even the IDE
> should be able to figure out which code would be called.
Should. <-;
Harry Strybos
(people who agree with me are always fine people *grin*).
Lets look at what the "older" programs did:
1. Draw some stuff on a screen
2. Loop around waiting for some interaction from the user
3. Act on that interaction (keypress or mouseclick)
So...whats changed. If you look at the simple loop in 2, and write some code
within the loop to look for a key being pressed... when that key is pressed
we have a "Key_Pressed" Event. I can remember in PDS writing a Sub called
"Key_Pressed". So now, all that stuff is hidden, and Billy Gates tells us
this is a wonderfull thing. Further down the track Billy G gives us a
"Key_Pressed" object and now we become real programmers........Oh yes,
nearly forgot, multithreading...sorry, we aren't real programmers anymore,
until you get the next exiting episode. Come on, Mr Gates, multi-threading
is just a "mechanical" issue, a user should not have to be concerned so much
with that issue! Should be just a "native" property of a class.
Hell...all the ruckus about "inheritance". Never did see such a big need for
it myself, however, don't see that it would have been so difficult to
implement in VB.Normal (sorry Billy G...you are looking for the next R & D
budget but don't you have enought money yet?)
I am one of the "older" guys and have also seen the fads come and go. Having
a lot of the stuff hidden is really great and all that Visual stuff is great
also. Saddly, it has resulted in some dreadfull programming practises. I am
still constantly surprised to see so many, otherwise highly intelligent
young programmers, being drawn into the M$ technological "black whole". More
memory, more resources, forget the cost, fix it later, forget the user.
I believe Bill Gates made a remark along the lines of "what else do we do
with a 14 billion R & D budget". And so, along we are all drawn. Simple text
files worked so well, now we have to have XML......ok, must be better
because OOP is involved and because we get all these wonderful, and large
objects to play with.
VB 6.0 is a very good product and deserves to be supported and developed by
M$ for many years to come...7.0, 8.0 etc. My own work revolves around
corporate clients and VB has been brilliant in developing for that area.
Damn..and just when they were getting it right....VB.Net...back to square
one!!!!!
I have VB.Net running on one of my pcs and am not at all impressed. This is
a P3 1gig with 256meg ram and VB.Net runs like a pig (translate that to slow
and dirty) . I can understand how to get a program running, but can't
understand why I have to take such a retrograde step to accomplish what were
simple tasks in VB.Normal.
It is with great difficulty that am able to see VB.Net as the next step for
VB. I think M$ has got this terribly wrong. Go ahead, Billy Gates, develop
VB.Net, nothing wrong with that...but call it B#, VB.Not or whatever. Then
when you have finished with that, hopefully ther will be enough left of your
R & D budget to support your dedicated VB.Normal folks. We did make at least
one of those R & D budgets for you!
M$ could actually start with the bug that when you minimise VB, run some
other program, then maximize VB the IDE has become transparent! Or put just
one weeks worth for one programmer to fix the PDW etc, etc
VB has come a long way, and I don't really want to write my own menus again,
nor do I want to go back to all the code we had to write just to present
something meaningfull to the user. Even OOP is good. Classes are brilliant!
Give us VB 7.0 Billy Gates, not the new Redmond fantasy!
Cheers
"W.E. (Bill) Goodrich, PhD" <bgoo...@earthlink.net> wrote in message
news:3B5664B0...@earthlink.net...
Joe "Nuke Me Xemu" Foster
> In article <tlcnek7...@corp.supernews.com>,
> "Joe \"Nuke Me Xemu\" Foster" <j...@bftsi0.UUCP> writes:
>
> > "W.E. (Bill) Goodrich, PhD" <bgoo...@earthlink.net> wrote in
> > message <news:3B560BD0...@earthlink.net>...
>
> > > Yes, you very clearly do. But most of the real virtues you
> > > ascribe to OOP are artifacts of the earlier practices of
> > > modularity and the like (which OOP borrowed) rather than of
> > > "the encapsulation of the data and the code that acts on that
> > > data into a single unit" (the element that differentiates OOP).
>
> > At least the OOPies are waking up to the fact that methods break
> > encapsulation. See Scott Meyer's article "How Non-Member Functions
> > Improve Encapsulation" in the Feb 2000 issue of "C/C++ Users
> > Journal".
>
> Good article, overall.
And it's online! http://cuj.com/articles/2000/0002/0002c/0002c.htm
This should make it much easier to For Each Zealot In ObjectObsessed :
Zealot.Sees = vbRed : Next Zealot
> > [Tom Sheldon wrote:]
>
> > > > I don't understand what this overloading problem you keep
> > > > refering to is.
>
> > > The fact that it constitutes an EXTREME, fundamental violation of
> > > Structured Programming.
>
> > Is that really so bad?
>
> Not at all. It is just relevant to evaluating the humor inherent in
> a vocal OOP advocate deriding a body of code as "very non structured".
Perhaps we've misunderstood him. Maybe he's of the "Call Plain Old Modules
'Pure Stateless Classes' and Call it 'OOP'" school.
> > After all, you said yourself that Structured Programming has
> > "proven massively counterproductive in major categories of
> > programming."
>
> And as a result lost favor as an academic fad. What is left are a few
> face-saving scraps which allow the earlier academics to avoid the
> accusation of having taught/advocated TOTAL garbage. It will be
> interesting to see which scraps of OOP serve a similar function in
> a few years.
What were the categories, the ones in which OOP actually works well?
Yeah yeah, I /know/ that by admitting to not being the World's Leading
Expert in Absolutely Everything, I've just "outed" myself as a mere
macro-coding dilettante... =)
> > At least overloading can be resolved at compile-time. Even the IDE
> > should be able to figure out which code would be called.
>
> Should. <-;
Yeah, well, you can say that about anything and everything, can't you?
--
Joe Foster <mailto:jfo...@ricochet.net> Sign the Check! <http://www.xenu.net/>
Larry Linson
> I think MS realizes that this platform is not right for everyone. They
say they
> are going to continue to support VB.CLASSIC at least for a while, but it
would
> be nice if they could continue to develope it in tandem.
Yes, indeed, as there were rumors that VB 7.0, with full object-oriented
capabilities, was near completion when the development team were redirected
(as was all Microsoft) to the .NET initiative. It would seem that, if they
realized they might have millions of potential customers for it (at least
the authors of the, by Microsoft's own survey, 70% of VB applications which
do not contain a single user-written class), they could devote some time and
effort of a small team to finish and release it... comparable to C++ which
is being release with full backward compatibility (but C++ also includes the
ability to create .NET "managed" code as well as "unmanaged" code).
However, if you remember just how long and how well The Boys and Girls in
Redmond continued to support VB DOS, it might give you pause to carefully
consider how trusting you should be. If memory serves, support was
discontinued less than one year after initial release, and despite the fact
that quite a few loyal VB folk purchased it at not-inexpensive prices, no
Service Release or Service Pack was ever issued. I, fortunately, purchased
my copy used, so I only wasted US$50 when the DOS project did not develop as
it appeared certain it would when I chased down my copy.
Tom Shelton
> Yes, indeed, as there were rumors that VB 7.0, with full object-oriented
> capabilities, was near completion when the development team were redirected
> (as was all Microsoft) to the .NET initiative. It would seem that, if they
> realized they might have millions of potential customers for it (at least
> the authors of the, by Microsoft's own survey, 70% of VB applications which
> do not contain a single user-written class), they could devote some time and
> effort of a small team to finish and release it... comparable to C++ which
> is being release with full backward compatibility (but C++ also includes the
> ability to create .NET "managed" code as well as "unmanaged" code)
I have never found VB's current OO capabilities to bad. No inheritance, but
that is something that most of the time is a bad idea anyway. The problem, I
think is that since VB.CLASSIC is based on COM, they would need to add all of
these features to the underlying COM subsystem - this is something that I know
was in the works, but never materialized. I'm sure with the change of stratagy
MS has taken with .NET, this will never happen. It would be nice, but I
wouldn't hold my breath.
By the way, a VB.NET program can still be written with NO user defined classes.
VB.NET does not force you to create any classes. The designer, will generate a
class for your forms, but you don't have to create any - unless your not using
the IDE like me, then this is probably the one exception where you would need to
define a class. If you want, you can orginize your code into modules instead of
classes just like the old days. The difference is that you have more system
defined classes at your disposal.
> However, if you remember just how long and how well The Boys and Girls in
> Redmond continued to support VB DOS, it might give you pause to carefully
> consider how trusting you should be. If memory serves, support was
> discontinued less than one year after initial release, and despite the fact
> that quite a few loyal VB folk purchased it at not-inexpensive prices, no
> Service Release or Service Pack was ever issued. I, fortunately, purchased
> my copy used, so I only wasted US$50 when the DOS project did not develop as
> it appeared certain it would when I chased down my copy.
Of course, you could also argue that MS is still supporting VB4. That was
released in 1994 - 1995, making it 6 - 7 years old now, and still supported.
This is the one area I don't think MS can afford to lie in. They need the VB
developers to make .NET succesful. If they dumped support for VB.CLASSIC to
soon, they would have a major problem on their hands.
Tom Shelton
Tom Shelton
Bill,
> > I bought Borland Devloper Studio at the same time (contained Borland
> > C++ 4.52 and 5.0, and the ability to compile Java programs, and a
> > bunch of there database stuff). I have been working with C++ for
> > about as long as I have in VB. So, if I had at the time been
> > inclined to by VC++ (I liked the Borland environment better back
> > then), I would have bought it.
>
> Which just goes to support my point: the steeper "buy in" is
> counterproductive in terms of a major VB market: students.
I'm not sure what the point is. The change in VB.NET will probably not change
the student market one bit. Students buy VB because they have to, that's why I
bought mine. If and when schools start using VB.NET in their class work, they
will buy it. It will have no affect on the market.
Maybe I'm a little slow on the uptake here, can you please elaborate on what
your point is. I just want to understand what your saying so that I can decide
if I agree / don't agree.
> > I wasn't trying to say there was a constant barrage of complaints,
> > but these issues did come up quite frequently on those VB Wish List
> > posts.
>
> I tend to differentiate between "complaints/criticisms" and "items on
> wish lists". There are "wish list items" I have commented on as well,
> but they constitute "gee, it would be Even Better with..." comments
> rather than criticisms or complaints about the lack thereof. And of
> those posts/threads I have seen with the complaints in question AS
> criticisms/complaints, virtually all have come as described.
Fair enough. I'll grant you this one.
> > I realize that you have been around the block, so to speak. But,
> > I would hardly call OOP an "academic fad".
>
> And having seen such things come and go in the past, I would - and
> do - call it an academic fad. As do an increasing number of Academics.
Do you have any refrences for this. I am not arguing with you here, I just
can't find anything that implies this, and I am interested in these opinons.
Just because I think OO has worked for me, doesn't mean I'm so much of a "zelot"
that I'm not open to other ways of thinking.
> > I believe that OOP has proven it's worth in the market place.
>
> Not really. The best that can be said is that - unlike its Structured
> Programming predecessor - it has not proven massively counterproductive
> in major categories of programming.
Ahhh, ok.
> > Yes, OOP went through it's honymoon faze. But, overtime, things have
> > settled down and people have started using it more effectively.
>
> People have used OOP oriented TOOLS over time - mostly because of the
> academic fad and its effect on readily available programmers and
> because they replaced earlier equivalent tools - but they have been
> "using them more effectively" by learning how to use them to generate
> old-fashioned heavily procedural software. The few aspects of OOP that
> are really being used are those - such as modularity - that were around
> and in widespread use for decades before OOP existed. And those aspects
> will likely be just as much a part of the next academic fad, and the
> one after that, and the one after that, and...
I'm sure that many OO concepts existed before OOP. I think that OO was an
attempt to take the best ideas and put them into one model. I'm not saying that
OO is the end all, be all of programming. What I'm saying is that I find it to
be a highly productive way of viewing a project. By breaking my program into
descrete objects, I am better able to manage larger problems. Others milage may
very.
I haven't seen any refrence to this. Can you point me to a refrence?
> M$ has stated (through executives and other spokespersons) that it is
> interested in changing the dominant software paradigm from the idea of
> "buying" a program (in practice, a one-time licensing fee for lifetime
> use) to that of "contracting for a service" (continuing periodic
> payments for the ongoing ability to use the functionality). Behind all
> the (largely empty) rhetoric about "support" is (according to company
> documents) a focus on cash flow and power. And both .NET and XP are
> designed to be significant parts of that attempted shift.
I hope that this new software licensing scheme of MS's bites it, and fast! This
new software model, is another topic, and one I feel quite strongly about. I am
currently learning the .NET platform becasue I believe it will make me more
productive. Whether I use it in actual practice remains to be seen. It is this
issue that will keep away if they push forward with this. At this time I have
NO intention of upgrading to Windows XP, Office XP, or any other product
licensed via this new model, superior though it maybe. I have NO intention of
calling MS everytime I make hardware changes to MY system. I don't believe they
have any right to expect or recieve any information regarding MY hardware
prefrences / buying habbits.
As far as .NET, I am really waiting to see what happens with the open source
ports to other OS's. MS, won't be able to muck with these, or require any of
it's insane new licensing. If VS.NET has the same requirements, I definately
won't be using it either. That is why I'm using UltraEdit for all of my .NET
experiementing, this way I can become familiar with the command line compiler.
Yes, I have to code all my forms buy hand, but that isn't so bad once you get
used to it. I understand that the command line compilers will still be
available for free after the realease (could be wrong on this, but this is the
impression I got) so, I'll just continue using them if I have to. I am very
familar with command lines, being that I deal with Unix almost every day.
If the time comes, that I have to upgrad - it won't be to Windows XP. I'll load
up Linux and make the switch. If .NET goes cross platform, I'll just take my
code with me. If it doesn't there is always C++ and Java. I guess I should
reveal now that I am one of those VB guys who plans to "jump ship", and this is
the main reason. C#, not VB.NET, is the language that is going to other OS's
(well so is the jscript compiler) - so if I have to make the switch it will be
much eaiser to take C# code with me than VB.NET. For now, I'm sticking with
VB.NET to become familar with the frameworks, but with my C/C++/Java experience,
I don't anticipate the move to C# to be all that tramatic.
> > As I stated in another post to Larry, I also believe that the
> > inability to support W95 is going to slow down the use of .NET as
> > a tool for client programming.
>
> Among other things.
>
> > I believe, that it will best be suited to server side,
>
> Which is subject to literally thousands of dollars in additional
> annual licensing fees and various restrictions. M$ makes no bones about
> wanting to control the server side.
See above for MS licensing rant.
> > Yes it runs, and yes the company continues to grow. I am not even
> > trying to imply that OOP is the only way of thinking or programming.
>
> Just that it is a "superior" one - a claim that I dispute.
A difference of opinion that I see no way to resolve. I believe that for me,
OOP works best. But others milage may vary.
> > And by the way, yes, I was and am still involved in the design and
> > implementation of large projects.
>
> But that wasn't the central part of what I asked. I asked whether you
> had designed and implemented - from the ground up - in IMS/BASIC while
> using a completely non-OOP methodology. Not whether you had "been
> involved in" design and implementation of large projects in other
> languages.
Yes.
> > The company I work for is a little unique in the way they do buisness.
> > Even in technical support, I was involved in writting custom software
> > for our customers.
>
> Large scale custom software (2500+ lines of BASIC code) or smaller,
> specialized apps?
Both. Most are less then 1000 lines of code, but I have done 2 or 3 major
custom interfaces that had at least that many lines of code. All in vi - I
can't stand line numbers!
> > Most of us there are. And I have since moved out of support to R&D.
> > My primmary job is in developing our windows based products, and as
> > stated earlier, they make me use VB.
>
> > > The "very non structured" comment is very funny, from a historical
> > > view. Originally, the central value of Structured Programming was
> > > strict determinism and the other aspects were primarily in support
> > > of that value. OOP is anything BUT "strictly deterministic" in
> > > theory and practice. In addition to the overloading problem, it
> > > violates the central tenet of strict separation of code and data
> > > as well as a variety of others.
>
> > That is funny since OO, takes quite the opposite view.
>
> Which is exactly why it is so humorous to see such a vocal OO advocate
> disparagingly describe some code as "very non structured".
You should see the code! It would probably give you the shivers! Seriously,
I'm not tyring to sound like one of those OO elitests. I recognize that the
computing industry functioned quite well without OO techniques. But, I also
believe that used properly OO can bring benifits. For me the biggest benifit is
the ability to encapsulate functionality into one place - code reuse. This is
possible using modules, but I think is more logical organized into classes.
Admitedly, this is a personal prefrence.
Tom Shelton
W.E. (Bill) Goodrich, PhD
> "W.E. (Bill) Goodrich, PhD" <bgoo...@earthlink.net> wrote in
> message <news:3B5664B0...@earthlink.net>...
> > In article <tlcnek7...@corp.supernews.com>,
> > "Joe \"Nuke Me Xemu\" Foster" <j...@bftsi0.UUCP> writes:
> > > "W.E. (Bill) Goodrich, PhD" <bgoo...@earthlink.net> wrote in
> > > message <news:3B560BD0...@earthlink.net>...
> > > > Yes, you very clearly do. But most of the real virtues you
> > > > ascribe to OOP are artifacts of the earlier practices of
> > > > modularity and the like (which OOP borrowed) rather than of
> > > > "the encapsulation of the data and the code that acts on that
> > > > data into a single unit" (the element that differentiates OOP).
> > > At least the OOPies are waking up to the fact that methods break
> > > encapsulation. See Scott Meyer's article "How Non-Member Functions
> > > Improve Encapsulation" in the Feb 2000 issue of "C/C++ Users
> > > Journal".
> > Good article, overall.
> And it's online! http://cuj.com/articles/2000/0002/0002c/0002c.htm
> This should make it much easier to For Each Zealot In ObjectObsessed :
> Zealot.Sees = vbRed : Next Zealot
I wonder whether he was conscious of the extent to which his "point"
example showed the absurdity of some OO advocates arguments, however.
[...]
> > And as a result lost favor as an academic fad. What is left are
> > a few face-saving scraps which allow the earlier academics to
> > avoid the accusation of having taught/advocated TOTAL garbage.
> > It will be interesting to see which scraps of OOP serve a similar
> > function in a few years.
> What were the categories, the ones in which OOP actually works well?
AI, certain VERY dynamic simulations, and whiz-bang Academic
demonstrations. The sort of things in which you might have some possible
reason for maintaining the option of "transparently" turning a data
structure into a series of function calls.
> Yeah yeah, I /know/ that by admitting to not being the World's Leading
> Expert in Absolutely Everything, I've just "outed" myself as a mere
> macro-coding dilettante... =)
Yeh, well... even dilettantes can occasionally say SOMETHING
worthwhile. <-;
But that does bring up one element of the discussion. The "higher buy
in" will discourage adoption and use by dilettantes and the like.
Joe "Nuke Me Xemu" Foster
> I have never found VB's current OO capabilities to bad. No inheritance, but
> that is something that most of the time is a bad idea anyway. The problem, I
> think is that since VB.CLASSIC is based on COM, they would need to add all of
> these features to the underlying COM subsystem [snippage]
BZZT! That's crap, and you know it. Implementation inheritance no more
requires native support from COM than it does from the CPU. Sheridan's
now-abandoned ClassAssist add-in gave us implementation inheritance in
VB 4.0! No, all implementation inheritance in VB would require is the
ability to inspect arbitrary base class' interfaces, Implement them all,
and copy their vtables to avoid having to provide wrappers for methods
and properties not being overridden. An add-in can almost do all this
without requiring native support from VB, but some performance tricks
would be all but unavailable without some very scary hacking. McKinney's
_Hardcore VB_ touches on how to do this in its sections about writing
Collection classes:
http://www.mvps.org/vb/hardcore/html/stupidcodetricks.htm
(deep-link within http://www.mvps.org/vb/hardcore/ , itself a deep-link
within http://www.mvps.org/vb/ )
--
Joe Foster <mailto:jfo...@ricochet.net> Sacrament R2-45 <http://www.xenu.net/>
Tom Shelton
> BZZT! That's crap, and you know it. Implementation inheritance no more
> requires native support from COM than it does from the CPU. Sheridan's
> now-abandoned ClassAssist add-in gave us implementation inheritance in
> VB 4.0! No, all implementation inheritance in VB would require is the
> ability to inspect arbitrary base class' interfaces, Implement them all,
> and copy their vtables to avoid having to provide wrappers for methods
> and properties not being overridden. An add-in can almost do all this
> without requiring native support from VB, but some performance tricks
> would be all but unavailable without some very scary hacking. McKinney's
> _Hardcore VB_ touches on how to do this in its sections about writing
> Collection classes:
Yeah, I guess your right. I didn't really think a long those lines. I guess my
response was sort of a knee jerk reaction. But, my point is it isn't
inheritance that I find the most significant feature of the .NET platform, nice,
glad it's there, but probably won't get a whole lot of use from me except for
creating forms. The things I like most about .NET - VB or otherwise, is the
framework. My experience with it so far has been very positive. I have found
in converting my little utilites, that most of the times I have been tempted to
call an API call for something, the functionality was somewhere in the
framework. I find VB.NET to be much more flexible then the current VB. Yes, I
have a couple of gripes, and I have listed those in this thread, but overall, I
think it is much more powerful
I keep seeing the number 70% of all VB programs don't use any user defined
classes. I believe it, but you know what - moving to .NET doesn't mean you have
to write your own user defined classes (with the exception of your forms, in a
graphical app, and that code can mostly be generated automatically). If you
don't like to write your own classes then don't. I'm pretty sure that a
reasonably competent VB guy can come up to speed on this stuff fairly quickly.
I will admit, which I think is what people are trying to get from me, is that
yes, the newbie, or non-programmer type, might have a little harder time using
VB.NET. The framework is so big, and it is hard enough for newbies to search,
let alone understand, the documentation that, I will have to agree for the first
time, VB is not as easy to just pick up and go. But, I don't think VB.NET is
the only .NET language that this is true of. I find the syntax of VB.NET to be
very familar and easy to pick up, but I believe the hinderance to the newbie
will be the frameworks. I guess with the power comes a steeper entry fee. I am
not so sure this is a bad thing. I mean, this really has been one critisism of
VB.CLASSIC, any body can and does program in it. You know as well as I do that
there is probably a disproportainate amount of crappy VB.CLASSIC code out there.
I think with the steeper entry fee comes a deeper understanding of the language.
And maybe, I'm full of crap :).
I think the biggest issue with .NET is how well it is going to play to the
client side of things, and right now, I don't think things look so good there.
And, as much as I like it - .NET will be .NOT if MS continues with there
big-brotherish licensing schemes.
Tom Shelton
Larry Linson
> I keep seeing the number 70% of all VB programs don't use any user
defined
> classes. I believe it, but you know what - moving to .NET doesn't mean
you have
> to write your own user defined classes (with the exception of your forms,
in a
> graphical app, and that code can mostly be generated automatically). If
you
> don't like to write your own classes then don't.
That's from Microsoft's own survey of applications done by their customers.
I suspect it was mainly corporate customers, and thus the proportion of
"classless" apps is likely 'way low, because I'd bet there are even fewer
mom-and-pop-shop folk creating their own classes in their specialized
business software and fewer hobbyist programmers, too, than corporate
programmer types.
> I think the biggest issue with .NET is how well it is going to play to
the
> client side of things, and right now, I don't think things look so good
there.
> And, as much as I like it - .NET will be .NOT if MS continues with there
> big-brotherish licensing schemes.
Well, you see, except for the occasional little web site or web-enabled
database need that comes along, _everything_ I do is client-side. It is, for
example, a lot more comforting to know that your code is compiled to machine
language from whence it is very difficult to regenerate VB source than to
know it is sitting there in IL, for which a discompiler is included right in
the debugging tools. Whoo-eee!
> I mean, this really has been one critisism of VB.CLASSIC,
> any body can and does program in it. You know as well as
> I do that there is probably a disproportainate amount of
> crappy VB.CLASSIC code out there. I think with the steeper
> entry fee comes a deeper understanding of the language.
Yes, I've heard some complain about that -- usually people who thought they
were better than The Great VB Unwashed because they went into some college
or university or other as a weenie and came out as <blare of trumpets> ***
Computer Scientist ***, whereas those hoi polloi in The Great VB Unwashed
had never been exposed to The Halls of Acade.
As for me, I think it's great that someone who just needs to get some work
done can learn and use classic VB, and it's been proved over and over that
they can. Some will do what they need and that'll be the end of their career
except for a little maintenance and enhancement. Some have developed into
real, HTG, professional programmers.
On the other hand, you might be surprised just how much crappy code has been
written in about every computer language know, some of it by those very ***
Computer Scientists ***.
And, on the other other hand (everybody's got at least three, don't they?),
you might be surprised how much "crappy VB classic code" is successfully
doing the job for which Mom, or Pop, or their Jr. High School neighbor wrote
it for their little business. I don't begrudge them not hiring me to write
near-perfect code -- I couldn't get around to all the little Mom and Pop
shops and many of them couldn't afford my rates. But they can get my help
for free here in the newsgroup or at the user group meetings.
Larry Linson
> What I'm saying is that I find it to be a highly
> productive way of viewing a project. By breaking
> my program into descrete objects, I am better able
> to manage larger problems. Others milage may
> very.
An "object", in the OOP sense, is a piece of data and the things you can do
to/with it, packaged as one. It is, indeed, a way of looking at things. It
is not always the best way of looking at things, but it's not always the
worst either.
On the other hand, I have been breaking problems down into "components"
(nothing to do with COM) since the days when there were only Fortran and
Assembler, implementing them in modular fashion (e.g., subroutines), using
appropriate structure. I'm "down" on Structured Programming as Bill -- it
has its place. I forced myself to be a purist while learning and convincing
myself that you _could_ follow the rules of structure in every case I
encountered. Once I understood (grokked) it, then I could use it with good
judgement and knew when it was reasonable to violate the strict rules for
expediency -- like getting the hell out from several levels deep in
procedure/subroutines when an error made it impossible to continue, without
following the strict rule of returning from the one exit point and checking
an error flag at the twenty steps or so above where you were in the
hierarchy.
> > . . . And both .NET and XP are designed to be
> > significant parts of that attempted shift.
The .NET intitiative is Microsoft's thrust to increase market share in the
huge, enterprise, server-centric, thin-client web services market. That
market is the exclusive domain of the huge megacorps. Independent
contractors had best hope for a personnel shortage and be prepared to take
whatever crumbs the megacorps offer. If, as Microsoft, and most of their
enemies, too, hope, everything becomes web-centric, thin-client, the desktop
and LAN marketplace served by us "little guys" will evaporate.
> I hope that this new software licensing scheme of MS's bites it, and
fast! This
> new software model, is another topic, and one I feel quite strongly
about.
If you have any time and interest... visit http://www.ddpi.org. It's the
Desktop Database Productivity Initiative, a cross-platform, Open Source
project that began as the "Access Replacement Project" when many Access
developers felt that Access 2000's many developer issues indicated that
Microsoft had, or would soon, abandon them. The new licensing terms have
increased enthusiasm for a "replacement".
I don't know how you plan to work, Tom. Most of us at least started out
working for someone else, working on teams, working on large projects. And,
for me that was beneficial -- I was in the corporate environment for over 30
years before I retired. _Then_, having spent half my IBM career in their
Contract Services organization and already knowing that I liked that kind of
work, started my second career as an Independent Contractor. It's been a lot
more fun, but wouldn't have been back when I needed the security of a
regular paycheck to pay the bills and raise the kids. When you work for an
employer, they provide the software, and they also tell you what software
you are going to use (unless you want to change places of employment).
I think the chances of Linux making a significant impact on the desktop O/S
market in the near future are small. But there are some glimmers -- some
government agencies have made it their standard. It'll be interesting to see
if Microsoft's licensing changes (widely perceived as arrogance) give the
Linux desktop a boost.
W.E. (Bill) Goodrich, PhD
"Tom Shelton" <to...@dakcs.com> writes:
> Bill,
> > > I bought Borland Devloper Studio at the same time (contained
> > > Borland C++ 4.52 and 5.0, and the ability to compile Java
> > > programs, and a bunch of there database stuff). I have been
> > > working with C++ for about as long as I have in VB. So, if I
> > > had at the time been inclined to by VC++ (I liked the Borland
> > > environment better back then), I would have bought it.
> > Which just goes to support my point: the steeper "buy in" is
> > counterproductive in terms of a major VB market: students.
> I'm not sure what the point is. The change in VB.NET will probably
> not change the student market one bit.
Obviously, I disagree.
> Students buy VB because they have to, that's why I bought mine. If
> and when schools start using VB.NET in their class work, they will
> buy it. It will have no affect on the market.
Since its introduction (at Dartmouth) Way Back When, BASIC (in its
various forms) has been used in classrooms for one reason: negligible
learning curve. Instructors could get students "up and running" in
one or two class periods, and from then on concentrate on the nominal
subject matter of the course. At times when such a painless BASIC was
not available, the professors (and/or departments, in concert) have
moved to a "working language" (Fortran, C, C++, etc.) instead. Despite
its use in a few corporate settings, VB has never been considered such
a working language.
In addition, many students have been using the BASICs for quick and
easy creation of personal programs, games, and problem solutions. When
the "buy in" (time and/or money) has gotten too high, they have shifted
to the working languages for such uses as well.
> Maybe I'm a little slow on the uptake here, can you please elaborate
> on what your point is.
Beyond a certain (remarkably low) threshold, increases in upfront cost
(in terms of time and/or money) and/or difficulty of use have
historically caused a shift to other languages, with a corresponding
drop in Academic introduction and use of the relevant language/IDE.
There is no reason to believe that this time would be any different.
> I just want to understand what your saying so that I can decide
> if I agree / don't agree.
[...]
> > > I realize that you have been around the block, so to speak.
> > > But, I would hardly call OOP an "academic fad".
> > And having seen such things come and go in the past, I would -
> > and do - call it an academic fad. As do an increasing number of
> > Academics.
> Do you have any refrences for this.
Mostly personal conversations. OOP is the currently dominant academic
fad and there is no specific successor gaining ascendancy yet, so any
publication of such statements could - almost certainly would - cause
significant career problems for that Academic.
> I am not arguing with you here, I just can't find anything that
> implies this, and I am interested in these opinons.
Talk with the professors, etc. off the record, as a non-student.
> Just because I think OO has worked for me, doesn't mean I'm so much
> of a "zelot" that I'm not open to other ways of thinking.
Ok.
> > > I believe that OOP has proven it's worth in the market place.
> > Not really. The best that can be said is that - unlike its
> > Structured Programming predecessor - it has not proven massively
> > counterproductive in major categories of programming.
> Ahhh, ok.
> > > Yes, OOP went through it's honymoon faze. But, overtime, things
> > > have settled down and people have started using it more
> > > effectively.
> > People have used OOP oriented TOOLS over time - mostly because of
> > the academic fad and its effect on readily available programmers
> > and because they replaced earlier equivalent tools - but they have
> > been "using them more effectively" by learning how to use them to
> > generate old-fashioned heavily procedural software. The few
> > aspects of OOP that are really being used are those - such as
> > modularity - that were around and in widespread use for decades
> > before OOP existed. And those aspects will likely be just as much
> > a part of the next academic fad, and the one after that, and the
> > one after that, and...
> I'm sure that many OO concepts existed before OOP.
Back in the 1950s, I knew a man who adamantly argued that Moses, Noah,
et al were Christians. Of course, he also derided the Latin Mass, by
saying that "English was good enough for Jesus, so it's good enough
for me!".
It is interesting to see the concepts and practices which were in
widespread, successful use long before OO was conceptualized described
as OO concepts. Sadly, that appears to be exactly the way they are
being presented by the schools.
> I think that OO was an attempt to take the best ideas and put them
> into one model.
As a contemporary observer of - and marginal participant in - the
process, my view of it is rather less idealistic. The (temporary)
success of Structured Programming (and its Academic champions) was
largely tied to Big Iron and batch-type operations. But the paradigm
was not well suited to the smaller, more interactive systems that were
gaining popularity. And the younger, more ambitious Academics were not
happy to be under the thumbs of their more conservative "elders". The
vulnerability of the paradigm produced a corresponding vulnerability
in the Academics (and a potential for advancement and academic power
for anyone capable of exploiting those vulnerability). The newbies
couldn't just advocate dropping SP - they had to advocate moving
toward something NEW and different.
The first pass of the design was fairly easy. The pre-SP elements of
modularity, levels of detail, and scalable data structures were pretty
much timeless. Much of the rest of the definition came from playing
"opposites". The chief vulnerability of SP was its heavy emphasis on
process-driven execution, so the "new thing" was heavily geared to
support event-driven execution. The cardinal virtue of SP was rigid
formality, so NewThing was open and flexible. SP was slanted toward
Top Down design, so NewThing was slanted toward Bottom Up design. And
thus it went, selecting old, proven pieces based on their status as
polar opposites of those chosen by SP.
Now all they needed was a gimmick and a name. The gimmick was, as you
describe it, "the encapsulation of the data and the code that acts on
that data into a single unit". And with that, the name was easy.
And as had their predecessors, the now ascendant OOP advocates teach
the old pieces as OO concepts and practices, and their advantages as
OO virtues. Their examples tend to compare "good OO code" with old
fashioned, bad spaghetti code (which violates decades of good practice),
attributing the differences to OO rather than historic practice.
So no, I do not see it as "an attempt to take the best ideas and put
them into one model." I see it as a (successful) attempt to overthrow
the academic SP proponents, put "OOP" advocates in their places, and
maintain that power and authority. Bottom up is not inherently better
(or worse) than top down. There appears to be no practical advantage
to making procedure calls look like data structure references. And the
psychological data contradict the old claim that such a combination of
data and process is more intuitive than the old separation.
> I'm not saying that OO is the end all, be all of programming.
True.
> What I'm saying is that I find it to be a highly productive way of
> viewing a project.
And I am saying that most - if not all - of the advantage you are
attributing to OO are actually advantages of its uncredited
predecessors and habits with no intrinsic advantage.
> By breaking my program into descrete objects, I am better able to
> manage larger problems.
Or - you find that you are better able to manage larger problems by
breaking them into functional chunks and systematically implementing
each chunk? How much of that effectiveness is specifically due to "the
encapsulation of the data and the code that acts on that data into a
single unit" rather than the more general principles of chunking,
modularity, etc.?
> Others milage may very.
True.
[...]
> > > The JIT compile does result it some loss of performance,
> > And significant loss of program security, stability, and other
> > aspects of the development and delivery processes.
> > > since the compiler has to analyze and compile the code prior to
> > > its run.
> > Repeatedly. But unfortunately, the "analysis" is not necessarily
> > limited to the factors necessary for compilation. Nor are the
> > results of that analysis necessarily used ONLY for the compilation.
> > M$ has admitted an intention to use .NET for collection of business
> > intellegence - something completely unacceptable to many of my
> > clients.
> I haven't seen any refrence to this. Can you point me to a refrence?
Take a look at the last few months of various Ziff-Davis publications
and the like, such as Interactive Week.
[...]
> As far as .NET, I am really waiting to see what happens with the
> open source ports to other OS's. MS, won't be able to muck with
> these, or require any of it's insane new licensing.
Wrong. There is nothing about the LIMITED open source ploy that would
limit M$'s ability to impose such licensing conditions.
[...]
> Seriously, I'm not tyring to sound like one of those OO elitests.
> I recognize that the computing industry functioned quite well
> without OO techniques. But, I also believe that used properly OO
> can bring benifits. For me the biggest benifit is the ability to
> encapsulate functionality into one place - code reuse. This is
> possible using modules,
Not only possible, but common, effective practice for decades. Even
Structured Programming sounded that particular horn.
> but I think is more logical organized into classes.
How? While I could understand an aesthetic preference, "logical"
needs some specific basis.
> Admitedly, this is a personal prefrence.
> Tom Shelton
--
Tom Shelton
> > I think the biggest issue with .NET is how well it is going to play to
> the
> > client side of things, and right now, I don't think things look so good
> there.
> > And, as much as I like it - .NET will be .NOT if MS continues with there
> > big-brotherish licensing schemes.
>
> Well, you see, except for the occasional little web site or web-enabled
> database need that comes along, _everything_ I do is client-side. It is, for
> example, a lot more comforting to know that your code is compiled to machine
> language from whence it is very difficult to regenerate VB source than to
> know it is sitting there in IL, for which a discompiler is included right in
> the debugging tools. Whoo-eee!
I can understand your difficulties with VB.NET from the client side. I think
these problems will eventually be solved, but until then it is going to be a
little difficult mostly because of distribution issues, the lack of W95 support,
and as you mentioned the IL environment. I believe they need to let VB.NET and
other .NET languages have the option of compiling straight to native code, as
MC++.
But from my POV, these are not problems. I write proprietary software, which
runs on proprietary hardware. Our customers do not own that hardware, they
lease it. We have complete control of the OS environment, and the software
installed on it, so for me VB.NET is a very big gain in power and productivity.
> > I mean, this really has been one critisism of VB.CLASSIC,
> > any body can and does program in it. You know as well as
> > I do that there is probably a disproportainate amount of
> > crappy VB.CLASSIC code out there. I think with the steeper
> > entry fee comes a deeper understanding of the language.
>
> Yes, I've heard some complain about that -- usually people who thought they
> were better than The Great VB Unwashed because they went into some college
> or university or other as a weenie and came out as <blare of trumpets> ***
> Computer Scientist ***, whereas those hoi polloi in The Great VB Unwashed
> had never been exposed to The Halls of Acade.
I don't believe I am better than others, just because I went to school. To be
completely and utterly honest, almost nothing I learned in school applied to the
actual work place. I think the only thing I got from school was foot in the
door, and an introduction to project design with a little bit of problem solving
and pattern recognition skills. Usefull, but not anything you can't learn on
your own.
> As for me, I think it's great that someone who just needs to get some work
> done can learn and use classic VB, and it's been proved over and over that
> they can. Some will do what they need and that'll be the end of their career
> except for a little maintenance and enhancement. Some have developed into
> real, HTG, professional programmers.
I was only citing the critisim. This isn't one I really share. I am pointing
out though, that typically VB programmers are paid less then programmers of
other languages, and this is part of the reason. People believe that because
Aunt Martha can pick up a copy of VB, never having programmed before, and bang
out a faily decent little address book app, that VB is easy and therefore, VB
programmers don't deserve the same compensation as programmers of other
languages. This also contributes to it from the standpoint, that now that Aunt
Martha has created her address book app, she can call her self a VB programmer
and try to find a job, along with other 5, 999, 999 VB programmers.
> On the other hand, you might be surprised just how much crappy code has been
> written in about every computer language know, some of it by those very ***
> Computer Scientists ***.
No argument, I'm sure I have contributed myself on occasion :).
> And, on the other other hand (everybody's got at least three, don't they?),
> you might be surprised how much "crappy VB classic code" is successfully
> doing the job for which Mom, or Pop, or their Jr. High School neighbor wrote
> it for their little business. I don't begrudge them not hiring me to write
> near-perfect code -- I couldn't get around to all the little Mom and Pop
> shops and many of them couldn't afford my rates. But they can get my help
> for free here in the newsgroup or at the user group meetings.
That is the nice thing about VB, I will admit - it is very forgiving.
Tom Shelton
Joseph T. Adams
: I think the chances of Linux making a significant impact on the desktop O/S
: market in the near future are small.
Since Linux is free (in both the "free speech" and "free beer"
senses), it's hard to get a precise count of Linux desktop
installations.
However, most recent estimates I've seen put Linux in the #2 spot,
still a long way behind Windows, but far ahead of Apple, FreeBSD,
BeOS, and other contenders.
There are not yet as many popular games and special-purpose software
packages for Linux, but it does have everything else that most home
and desktop users need. It's also a great environment for developing
virtually any kind of software, *especially* the distributed, n-tier
applications for which Microsoft claims that .NET will someday become
a viable alternative.
I've used Linux as my primary desktop for nearly 3 years now, and
would never willingly work on a Windows box again if I had a choice.
(I do unfortunately need to maintain legacy VB code. Most of that
code will be rewritten using Java, but not necessarily right away.)
: But there are some glimmers -- some
: government agencies have made it their standard. It'll be interesting to see
: if Microsoft's licensing changes (widely perceived as arrogance) give the
: Linux desktop a boost.
Microsoft's arrogance probably is nothing new to anyone here, but it
certainly shows no signs of letting up. And it is starting to impact
both "Joe and Jane Average," and "John CIO," in ways that it
previously did not.
Joe
Joseph T. Adams
: Mostly personal conversations. OOP is the currently dominant academic
: fad and there is no specific successor gaining ascendancy yet, so any
: publication of such statements could - almost certainly would - cause
: significant career problems for that Academic.
I'm not so sure of that. There certainly looks to be a strong
resurgence of interest in functional languages such as Haskell, ML,
and even the venerable Lisp. I'm not yet familiar enough with any of
these to understand what the fuss is about. But even though I'm a
strong fan of OO for most of the kinds of work I do, I recognize that
it's not the perfect or best answer for every kind of problem, and
proponents of functional languages consider them far better suited for
the development of large and complex systems.
Joe
Larry Linson
> Since Linux is free (in both the "free speech" and "free beer"
> senses), it's hard to get a precise count of Linux desktop
> installations.
Agreed.
> However, most recent estimates I've seen put Linux in the #2 spot,
> still a long way behind Windows, but far ahead of Apple, FreeBSD,
> BeOS, and other contenders.
The _estimates_ I have seen put Linux penetration at about 2% of desktops,
either second to Windows or third behind Windows and various versons of
Apple's OS. I certainly would not be in a position to vouch for the accuracy
of those figures.
If all I was doing was for myself, I'd give Linux a try on my desktop (and,
if I get time and energy, may partition and do so, anyway). However, all the
paying work I do is for Windows, so it doesn't make a lot of sense to switch
just because I may be out of sorts with The Boys and Girls in Redmond over
some issues.
Clearly, I'd have more than a little time and energy to invest in
re-learning to do desktop development for Linux, which is obviously a
(comparatively-speaking) small market, and I'd really rather stick with the
desktop/client side than move to server-side where Linux has significantly
more penetration (clearly enough to warrant strong counter-attacks from the
US Pacific Northwest... "contaminates any intellectual property it touches",
S. Ballmer, referring to the GNU Public License).
Joseph T. Adams
: If all I was doing was for myself, I'd give Linux a try on my desktop (and,
: if I get time and energy, may partition and do so, anyway). However, all the
: paying work I do is for Windows, so it doesn't make a lot of sense to switch
: just because I may be out of sorts with The Boys and Girls in Redmond over
: some issues.
You can run both at the same time.
I try to avoid endorsing or recommending proprietary software
packages, but if you're interested in trying this, VMWare and Win4Lin
both offer Windows-on-Linux solutions. (VMWare allows the reverse as
well, although hardly anyone does it that way.)
: Clearly, I'd have more than a little time and energy to invest in
: re-learning to do desktop development for Linux, which is obviously a
: (comparatively-speaking) small market
There is indeed a learning curve for most people, but Linux is a
reimplementation of UNIX, so if you're familiar with any modern UNIX,
much of it will be instantly familiar. Also, the default
configurations of newer desktop environments like KDE and Gnome are
designed to be familiar to Windows users, so there is no crucial need
to learn an entirely different GUI.
As for being a small market, it is, but it is a fast-growing one as
well, and one that I believe contains many untapped opportunities at
present.
With the exception of VB, all the languages in widespread use on
Windows are available for Linux, usually for free, and the converse is
true too. Most Linux programming is done in C, Perl, Python, C++,
several LISP dialects, shell script, Java, and PHP. All these tools
have been ported to Windows also.
If you want to write code that will run on multiple platforms, there's
truly never been a time when this has been easier. It's still not
effortless, but it is possible. And the required effort to write
portable code will help you to support not only "non-mainstream"
platforms, but also different versions of Windows, which are not
always compatible with one another.
: and I'd really rather stick with the
: desktop/client side than move to server-side where Linux has significantly
: more penetration (clearly enough to warrant strong counter-attacks from the
: US Pacific Northwest... "contaminates any intellectual property it touches",
: S. Ballmer, referring to the GNU Public License).
How ironic that Microsoft itself releases some code under the GPL! :)
I mostly stopped getting requests for non-Web-based applications about
4 years ago. At that time, I realized that there would be many
advantages in learning to write server-side code. No one on the
client side knows or cares whether you're using Windows, Linux,
Solaris, or System 390 on the back end, or whether that code is
written using VB, Python, C++, Java, Perl, LISP, OCaml, or Intercal.
There are things about Web-based apps that I don't particularly like,
including the lack of interactivity and the hassles of dealing with
major (i.e. non-standards-compliant) browsers. But they have one
tremendous advantage over everything else: nearly everyone can run
them, without the hassles of a desktop install, and without major
client-side support hassles either.
Once you've persuaded a company to make its important applications
available on the Intranet, you're no longer tied to a particular
platform, language, or OS on the client side. You just need a
browser, and all platforms have that, and not just PCs, but all
Internet-capable devices (almost by definition, since in most people's
minds, Web == Internet).
More and more companies are realizing this, which is why server-side
platforms are growing more and more important.
Joe
Glev Zarriontal
>Larry Linson <larry....@ntpcug.org> wrote:
>
>: If all I was doing was for myself, I'd give Linux a try on my desktop (and,
>: if I get time and energy, may partition and do so, anyway). However, all the
>: paying work I do is for Windows, so it doesn't make a lot of sense to switch
>: just because I may be out of sorts with The Boys and Girls in Redmond over
>: some issues.
>
>You can run both at the same time.
Indeed you can. I am doing it now.(*1) I used Partition Magic 6 to
set up the partitions and boot via Boot Magic 6. Never had an easier
way to switch between different OS than this.
>
>I try to avoid endorsing or recommending proprietary software
>packages, but if you're interested in trying this, VMWare and Win4Lin
>both offer Windows-on-Linux solutions. (VMWare allows the reverse as
>well, although hardly anyone does it that way.)
Win4Lin requires you to install Linux first I thought. Then you
install Windows ?. Or do I have a different Linux to Win emulator in
mind?
>
>
>: Clearly, I'd have more than a little time and energy to invest in
>: re-learning to do desktop development for Linux, which is obviously a
>: (comparatively-speaking) small market
>
>There is indeed a learning curve for most people, but Linux is a
>reimplementation of UNIX, so if you're familiar with any modern UNIX,
>much of it will be instantly familiar. Also, the default
>configurations of newer desktop environments like KDE and Gnome are
>designed to be familiar to Windows users, so there is no crucial need
>to learn an entirely different GUI.
Agreed
>
>As for being a small market, it is, but it is a fast-growing one as
>well, and one that I believe contains many untapped opportunities at
>present.
>
>With the exception of VB, all the languages in widespread use on
>Windows are available for Linux, usually for free, and the converse is
>true too. Most Linux programming is done in C, Perl, Python, C++,
>several LISP dialects, shell script, Java, and PHP. All these tools
>have been ported to Windows also.
Maybe not as there are 2 Visual Basic like IDE in the works for use on
Linux based systems. I am keeping a careful track on both as I plan
to jump on board once they are more complete.
KBasic [ KDE based VB Clone ]
http://www.kbasic.org/1/home.php3
Gnome Basic [ Gnome based VB Clone ]
http://www.gnome.org/projects/gb/
>
>If you want to write code that will run on multiple platforms, there's
>truly never been a time when this has been easier. It's still not
>effortless, but it is possible. And the required effort to write
>portable code will help you to support not only "non-mainstream"
>platforms, but also different versions of Windows, which are not
>always compatible with one another.
>
As long as you do not try to use M$ Visual C++ anywhere in the mix.
MFC is strictly a M$ Windooze deal at this time AFAIK.
>
[snip]
>
>
>Once you've persuaded a company to make its important applications
>available on the Intranet, you're no longer tied to a particular
>platform, language, or OS on the client side. You just need a
>browser, and all platforms have that, and not just PCs, but all
>Internet-capable devices (almost by definition, since in most people's
>minds, Web == Internet).
I think it is more UseNet and FTP = Internet myself.
[snip]
>
>Joe
1: In case it matters, I am running Win98 as prime OS with Red Hat
Linux 7 as secondary.
Joe "Nuke Me Xemu" Foster
> On 22 Jul 2001 16:12:57 GMT, "Joseph T. Adams" <j...@apk.net> wrote:
>
> >Larry Linson <larry....@ntpcug.org> wrote:
> >With the exception of VB, all the languages in widespread use on
> >Windows are available for Linux, usually for free, and the converse is
> >true too. Most Linux programming is done in C, Perl, Python, C++,
> >several LISP dialects, shell script, Java, and PHP. All these tools
> >have been ported to Windows also.
>
> Maybe not as there are 2 Visual Basic like IDE in the works for use on
> Linux based systems. I am keeping a careful track on both as I plan
> to jump on board once they are more complete.
>
> KBasic [ KDE based VB Clone ]
> http://www.kbasic.org/1/home.php3
>
> Gnome Basic [ Gnome based VB Clone ]
> http://www.gnome.org/projects/gb/
Better track them *real* close, as Microsoft has stomped VB clones before.
> >If you want to write code that will run on multiple platforms, there's
> >truly never been a time when this has been easier. It's still not
> >effortless, but it is possible. And the required effort to write
> >portable code will help you to support not only "non-mainstream"
> >platforms, but also different versions of Windows, which are not
> >always compatible with one another.
> As long as you do not try to use M$ Visual C++ anywhere in the mix.
> MFC is strictly a M$ Windooze deal at this time AFAIK.
Really? I thought Microsoft's "partner" Mainsoft had yet to get the Black
Widow treatment... http://www.mainsoft.com/products/mainwin_howitworks.html
> >Once you've persuaded a company to make its important applications
> >available on the Intranet, you're no longer tied to a particular
> >platform, language, or OS on the client side. You just need a
> >browser, and all platforms have that, and not just PCs, but all
> >Internet-capable devices (almost by definition, since in most people's
> >minds, Web == Internet).
>
> I think it is more UseNet and FTP = Internet myself.
I think server-side development + remote users = totally boned. All the
morons who advocate thin-client computing should have to spend more time
with "mobile desktop" notebooks at 30 000 feet. The Future is not jailed
in a cube-farm.
--
Joe Foster <mailto:jfo...@ricochet.net> "Regged" again? <http://www.xenu.net/>
Glev Zarriontal
<j...@bftsi0.UUCP> wrote:
>"Glev Zarriontal" <glev.za...@verizon.net> wrote in message <news:784mltgjolelrhvc7...@4ax.com>...
>
[snip]
>>
>> Maybe not as there are 2 Visual Basic like IDE in the works for use on
>> Linux based systems. I am keeping a careful track on both as I plan
>> to jump on board once they are more complete.
>>
>> KBasic [ KDE based VB Clone ]
>> http://www.kbasic.org/1/home.php3
>>
>> Gnome Basic [ Gnome based VB Clone ]
>> http://www.gnome.org/projects/gb/
>
>Better track them *real* close, as Microsoft has stomped VB clones before.
I am sure they have. I think the fact they are both GPL and /or Open
Source should help increase survival chances.
>
>
>> As long as you do not try to use M$ Visual C++ anywhere in the mix.
>> MFC is strictly a M$ Windooze deal at this time AFAIK.
>
>Really? I thought Microsoft's "partner" Mainsoft had yet to get the Black
>Widow treatment... http://www.mainsoft.com/products/mainwin_howitworks.html
Well then, this is an interesting development. Previously, my info had
been write C++ via MFC to produce nice Windooze only code. That pretty
boy MFC could not run on anything else [ UNIX ( any flavor ) , Linux (
any flavor ), BSD, Solaris, BeOS, and ?? ] unchanged in any way.
Obviously someone has figured out a way to do the conversion. Is this
not why ANSI C++ exists to make truly portable C++ code that will work
with little or no modification among all OS platforms?
I do not call it very affordable for the average joe or jane
smoe though ( $2500 price tag ) . Thus while my previously statement
is no longer tactically true, it is still efficiently on target. I do
not know many individuals who write across different OS that can
afford a $2500 product. Corporations can afford this.
Even with this news, I will never learn Visual C++ as I do not wish to
be restricted to Micro$oft's version of C++. I would rather be
confined to Borland's or Watcom's version if I stick with any
corporation compared to something like FSF C++ or any GPL C++.
Call it a learned bias against Microsoft via first hand trial (*1) and
error of Visual C++.
>
[snip]
1: I had and tried (*2) Visual C++ 5 Pro. I found it extremely un
useful and counter productive IMO. This is in addition to being
unfriendly as all heck to use.
2: This was during round 3 of my "Find a C++ compiler with IDE I like
for Windooze" phase many moons ago.
Michael L. Smith
OmniBasic is runs on both Linux and Windows with no changes to the project
file in either direction. The IDE is identical on both systems. In other
words, write on either platform, compile the same project and run on either.
www.omnibasic.com
Joe "Nuke Me Xemu" Foster
Awright, who let the marketroids out of their recharging alcoves!?
> In article <784mltgjolelrhvc7...@4ax.com>, glev.za...@verizon.net wrote:
> >KBasic [ KDE based VB Clone ]
> >http://www.kbasic.org/1/home.php3
> >
> >Gnome Basic [ Gnome based VB Clone ]
> >http://www.gnome.org/projects/gb/
>
> OmniBasic is runs on both Linux and Windows with no changes to the project
> file in either direction. The IDE is identical on both systems. In other
> words, write on either platform, compile the same project and run on either.
> www.omnibasic.SPAM
But it can't trim newsgroup followups or stay out of my ISP's spam-trap,
eh? Perhaps XBasic might do a better job. http://xbasic.sourceforge.net/
--
Joe Foster <mailto:jfo...@ricochet.net> Greed = God? <http://www.xenu.net/>
Michael L. Smith
>"Michael L. Smith" <mls...@omnibasic.com> wrote in message
> <news:9jvg4...@enews3.newsguy.com>...
>
>Awright, who let the marketroids out of their recharging alcoves!?
>
>> In article <784mltgjolelrhvc7...@4ax.com>,
> glev.za...@verizon.net wrote:
>
>> >KBasic [ KDE based VB Clone ]
>> >http://www.kbasic.org/1/home.php3
>> >
>> >Gnome Basic [ Gnome based VB Clone ]
>> >http://www.gnome.org/projects/gb/
>>
>> OmniBasic is runs on both Linux and Windows with no changes to the project
>> file in either direction. The IDE is identical on both systems. In other
>> words, write on either platform, compile the same project and run on either.
>> www.omnibasic.SPAM
>
>But it can't trim newsgroup followups or stay out of my ISP's spam-trap,
>eh? Perhaps XBasic might do a better job. http://xbasic.sourceforge.net/
I thought my response was totally on subject. If a person is searching for a
solution to a problem, is it a sin to mention a product that was designed to
solve that problem? It is quite clear, by your mentioning an open source
product, that you don't mind dropping names. What you object to is free
enterprise and the free interchange if ideas.
>
Joe "Nuke Me Xemu" Foster
> In article <tm70k44...@corp.supernews.com>, "Joe \"Nuke Me Xemu\" Foster" <jfo...@ricochet.net> wrote:
> >"Michael L. Smith" <mls...@omnibasic.com> wrote in message
> > <news:9jvg4...@enews3.newsguy.com>...
> >> www.omnibasic.SPAM
> >
> >But it can't trim newsgroup followups or stay out of my ISP's spam-trap,
> >eh? Perhaps XBasic might do a better job. http://xbasic.sourceforge.net/
>
> I thought my response was totally on subject. If a person is searching for a
> solution to a problem, is it a sin to mention a product that was designed to
> solve that problem? It is quite clear, by your mentioning an open source
> product, that you don't mind dropping names. What you object to is free
> enterprise and the free interchange if ideas.
Perhaps it would help if you learned to read. It's not spam because it's
advertising, it's spam because you, or your fellow marketroids, had posted
the same damned advert repeatedly. I had to change the ".com" to ".spam"
in order to successfully post my original response, but SuperNews doesn't
auto-reject based on such keywords lightly, so go wrap *that* in the flag.
It is quite clear, by your continuing willful cluelessness, that you are
merely an intellectual inferior to even President-Select Dubya Bush.
Michael L. Smith
>"Michael L. Smith" <mls...@omnibasic.com> wrote in message
> <news:9k17e...@enews2.newsguy.com>...
>
>> In article <tm70k44...@corp.supernews.com>, "Joe \"Nuke Me Xemu\" Foster"
> <jfo...@ricochet.net> wrote:
>> >"Michael L. Smith" <mls...@omnibasic.com> wrote in message
>> > <news:9jvg4...@enews3.newsguy.com>...
>
>> >> www.omnibasic.SPAM
>> >
>> >But it can't trim newsgroup followups or stay out of my ISP's spam-trap,
>> >eh? Perhaps XBasic might do a better job. http://xbasic.sourceforge.net/
>>
>> I thought my response was totally on subject. If a person is searching for a
>> solution to a problem, is it a sin to mention a product that was designed to
>> solve that problem? It is quite clear, by your mentioning an open source
>> product, that you don't mind dropping names. What you object to is free
>> enterprise and the free interchange if ideas.
>
>Perhaps it would help if you learned to read. It's not spam because it's
>advertising, it's spam because you, or your fellow marketroids, had posted
>the same damned advert repeatedly. I had to change the ".com" to ".spam"
>in order to successfully post my original response, but SuperNews doesn't
>auto-reject based on such keywords lightly, so go wrap *that* in the flag.
>
>It is quite clear, by your continuing willful cluelessness, that you are
>merely an intellectual inferior to even President-Select Dubya Bush.
Learned to read what?
Some time ago, I instructed our sales department not to publish any additional
announcements on this group because Larry Linson <politely> pointed out that
such announcements belonged on the group designated for announcements.
Here is his response to our announcement:
-----------------------
USENET Newsgroup rules prohibit advertising of any kind in all newsgroups
except those whose charter permits it. The charter of
comp.lang.basic.visual.misc does not permit advertising. And, further, as
OmniBasic (good though it may be) is neither Visual Basic nor Visual
Basic-related, the post would be off-topic even if advertisments were
permitted.
At the same time that comp.lang.basic.visual.misc was created, there was
also created comp.lang.basic.visual.announce, a Visual Basic newsgroup
specifically intended for product announcements. Thank you for your
consideration in posting future product announcements there or elsewhere but
not posting any additional advertisements in comp.lang.basic.visual.misc.
Please note that none of the above prohibits mention of a product when it is
an appropriate answer to a technical question asked by another participant.
------------------------
It is under the auspices of his last paragraph that I believed my response was
not only appropriate, but maybe even helpful.
Your personal attack on me and my intelligence when you don't even know me
speaks volumes about your sense of fairness and decency.
>
Larry Linson
> Perhaps it would help if you learned to read.
Joe and Michael,
As you both know, I'm not an "arbiter" of anything, just a "designated
admonisher", but seems to me that this is mentioning a product as a valid
answer to a genuine technical question, and thus well within the USENET
rules and charter. I am not aware that the site having been inappropriately
used elsewhere would affect its proper use here. I'll have to admit that the
wording in my designated admonishment is my summarization, not directly
quoted from RFC's and the Charter, but I think it does summarize the intent
of both.
Joe "Nuke Me Xemu" Foster
> In article <tm8lkla...@corp.supernews.com>, "Joe \"Nuke Me Xemu\" Foster" <jfo...@ricochet.net> wrote:
> Learned to read what?
>
> Some time ago, I instructed our sales department not to publish any additional
> announcements on this group because Larry Linson <politely> pointed out that
> such announcements belonged on the group designated for announcements.
> Please note that none of the above prohibits mention of a product when it is
> an appropriate answer to a technical question asked by another participant.
> ------------------------
>
> It is under the auspices of his last paragraph that I believed my response was
> not only appropriate, but maybe even helpful.
The original version of my first reply contained only a gripe about the
inclusion of far too much quoted material for such a short reply. When
my ISP rejected the post because of the inclusion of a spammed URL, I
dug around a bit and discovered your other spamvertisements. You must
admit, XBasic <URL:http://xbasic.sourceforge.net/> did do a much better
job of staying out of my ISP's spam-trap than your OmniSpam's, yes?
> Your personal attack on me and my intelligence when you don't even know me
> speaks volumes about your sense of fairness and decency.
As opposed to your taking the high road yourself with this, hmmm?
"What you object to is free enterprise and the free interchange if ideas."
-- http://groups.google.com/groups?selm=9k17eu0sn4%40enews2.newsguy.com
Remember kidz, all commercial advertisements are considered Free Speech,
therefore, Mike/Michelle's continued spamming shall not be infringed,
especially to wildly inappropriate newsgroups such as comp.lang.c, right?
I guess since OmniSpam's just a front-end for a C compiler, that makes
it just as on-topic for comp.lang.c as, say, gnu FORTRAN?
http://www2.linuxjournal.com/cgi-bin/frames.pl/lj-issues/issue44/2075.html
$89 to $395 is quite a jump, no? Perhaps that's why you feel the need
to spam the newsgroups, unlike, say, CASLsoft?
Michael L. Smith
>"Michael L. Smith" <mls...@omnibasic.spam> wrote in message
> <news:9k232...@enews4.newsguy.com>...
>
>> In article <tm8lkla...@corp.supernews.com>, "Joe \"Nuke Me Xemu\" Foster"
> <jfo...@ricochet.net> wrote:
>
>> Learned to read what?
>>
>> Some time ago, I instructed our sales department not to publish any
> additional
>> announcements on this group because Larry Linson <politely> pointed out that
>> such announcements belonged on the group designated for announcements.
>
>> Please note that none of the above prohibits mention of a product when it is
>> an appropriate answer to a technical question asked by another participant.
>> ------------------------
>>
>> It is under the auspices of his last paragraph that I believed my response
> was
>> not only appropriate, but maybe even helpful.
>
>The original version of my first reply contained only a gripe about the
>inclusion of far too much quoted material for such a short reply. When
>my ISP rejected the post because of the inclusion of a spammed URL, I
>dug around a bit and discovered your other spamvertisements. You must
>admit, XBasic <URL:http://xbasic.sourceforge.net/> did do a much better
>job of staying out of my ISP's spam-trap than your OmniSpam's, yes?
My original post in this thread was merely to offer a technical suggestion (as
Mr. Larry Linson pointed out was totally appropriate) and have been since that
time the unfortunate recipient of your guile.
I acknowledge that I am at a distinct disadvanage in that I am attempting to
shame the shameless.
Since my original post, you have attacked me, my product, God, the President
of the United States, free enterprise, and the free exchange of ideas. Most
Marxists are more descrete in airing thier views.
I don't know who you think you are, but odds are you don't either.
Anyone can attack another person or entity with platitutes and rhetoric, but
it takes knowledge and perception to make an intelligent remark (either pro or
con). Flippant remarks are cheap and so are those who make them. Do you ever
get tired of hearing yourself?
I have looked at you reponses to other people on this newsgroup and was not
surprised to see that you have routinely treated others as you have treated
me. This is nothing to be proud of. You technical knowledge is average at best
while your insight into dealing with others is sadly lacking.
>
>> Your personal attack on me and my intelligence when you don't even know me
>> speaks volumes about your sense of fairness and decency.
>
>As opposed to your taking the high road yourself with this, hmmm?
At least you have the perception of taking the high road. This is to your
credit. Maybe you should try it. You might even like it.
>
>"What you object to is free enterprise and the free interchange if ideas."
>-- http://groups.google.com/groups?selm=9k17eu0sn4%40enews2.newsguy.com
>
>Remember kidz, all commercial advertisements are considered Free Speech,
>therefore, Mike/Michelle's continued spamming shall not be infringed,
>especially to wildly inappropriate newsgroups such as comp.lang.c, right?
I can provide you, or you may obtain on your own a formal definition of spam.
You will find that we don't qualify under that definition.
>
>I guess since OmniSpam's just a front-end for a C compiler, that makes
>it just as on-topic for comp.lang.c as, say, gnu FORTRAN?
You obviously have no knowedge of compiler architecture, so why pretend?
Calling our product OmniSpam is a cheap shot becoming only to a cheap person!
It is an unfortunate fact of our society that there are those who confuse
being a smart ass with being smart. If the shoe fits, wear it.
>
>http://www2.linuxjournal.com/cgi-bin/frames.pl/lj-issues/issue44/2075.html
>
>$89 to $395 is quite a jump, no? Perhaps that's why you feel the need
>to spam the newsgroups, unlike, say, CASLsoft?
If you invested two man years in R&D in a product that became the only true
multiplatform RAD in the world, would you raise the price?
Harry Strybos
Saddly, a few of the "loudest" people aka "owners?" of the NG seem to be so
impressed with themselves that they often miss their own hyprocisy. I
mean...how "of topic" do you guys get at times!!!
You get some really great people here as well. Look at Randy Birch...always
ready to lend a helping hand without any critisism. There are a number of
others that do that well also...sorry guys, can't remember all your names.
Larry (aka keeper of everyones morals), Joe (aka very self indulgent second
name, goes with the loud mouth) and Frank (never miss a chance at
sarcasm)....Lighten up a little. I don't like spam at all, but lets not get
"Sieg Heil" about it.
Merry Christmas
www.streemers.com.au
VB-Mate...useful VB add-in plus some free code
"Michael L. Smith" <mls...@omnibasic.com> wrote in message
news:9ka9p...@enews4.newsguy.com...
Joe "Nuke Me Xemu" Foster
> In article <tmep8js...@corp.supernews.com>, "Joe \"Nuke Me Xemu\" Foster" <jfo...@ricochet.net> wrote:
> >The original version of my first reply contained only a gripe about the
> >inclusion of far too much quoted material for such a short reply. When
> >my ISP rejected the post because of the inclusion of a spammed URL, I
> >dug around a bit and discovered your other spamvertisements. You must
> >admit, XBasic <URL:http://xbasic.sourceforge.net/> did do a much better
> >job of staying out of my ISP's spam-trap than your OmniSpam's, yes?
>
> My original post in this thread was merely to offer a technical suggestion (as
> Mr. Larry Linson pointed out was totally appropriate) and have been since that
> time the unfortunate recipient of your guile.
Trim your quotes, and none of this would have happened. Quit while you're
behind!
> I acknowledge that I am at a distinct disadvanage in that I am attempting to
> shame the shameless.
>
> Since my original post, you have attacked me, my product, God, the President
> of the United States, free enterprise, and the free exchange of ideas. Most
> Marxists are more descrete in airing thier views.
Good thing I'm not a Marxist, then. In this thread alone, I've mentioned
*two* commercial products, which are *not* advertized by spamming the NGs.
I guess I'll never be able to join the Communist Party now! <sob/> Anyway,
when did I attack God? Are you claiming God is on your side now? Perhaps
this is all according to a divine Plan, and it's your turn for a Job-job!
> I don't know who you think you are, but odds are you don't either.
I don't know who I think I am? Perhaps not. I'm sure you'd be more than
happy to tell me what to think, however.
> Anyone can attack another person or entity with platitutes and rhetoric, but
> it takes knowledge and perception to make an intelligent remark (either pro or
> con). Flippant remarks are cheap and so are those who make them. Do you ever
> get tired of hearing yourself?
No, since I don't have to sound anything out loud when writing or typing.
> I have looked at you reponses to other people on this newsgroup and was not
> surprised to see that you have routinely treated others as you have treated
> me. This is nothing to be proud of. You technical knowledge is average at best
> while your insight into dealing with others is sadly lacking.
Be specific about my deficiencies in technical knowledge. Please. Or is
that a shining example of this empty rhetoric stuff you're babbling about?
> >> Your personal attack on me and my intelligence when you don't even know me
> >> speaks volumes about your sense of fairness and decency.
> >
> >As opposed to your taking the high road yourself with this, hmmm?
>
> At least you have the perception of taking the high road. This is to your
> credit. Maybe you should try it. You might even like it.
Which "high road" is this, how high you can push your Briedbart Index
without actually getting spanked off the 'nets?
> >"What you object to is free enterprise and the free interchange if ideas."
> >-- http://groups.google.com/groups?selm=9k17eu0sn4%40enews2.newsguy.com
> >
> >Remember kidz, all commercial advertisements are considered Free Speech,
> >therefore, Mike/Michelle's continued spamming shall not be infringed,
> >especially to wildly inappropriate newsgroups such as comp.lang.c, right?
>
> I can provide you, or you may obtain on your own a formal definition of spam.
> You will find that we don't qualify under that definition.
Going for a BI=19.99999 over a 46 day sliding window, are you?
http://killfile.org/faqs/spam.html
> >I guess since OmniSpam's just a front-end for a C compiler, that makes
> >it just as on-topic for comp.lang.c as, say, gnu FORTRAN?
>
> You obviously have no knowedge of compiler architecture, so why pretend?
> Calling our product OmniSpam is a cheap shot becoming only to a cheap person!
> It is an unfortunate fact of our society that there are those who confuse
> being a smart ass with being smart. If the shoe fits, wear it.
No, I guess writing a few compilers and interpreters doesn't count, eh?
Those are nice example platitudes, by the way. When will we get to the
knowledgeable, perceptive, intelligent remarks, anytime soon?
> >http://www2.linuxjournal.com/cgi-bin/frames.pl/lj-issues/issue44/2075.html
> >
> >$89 to $395 is quite a jump, no? Perhaps that's why you feel the need
> >to spam the newsgroups, unlike, say, CASLsoft?
>
> If you invested two man years in R&D in a product that became the only true
> multiplatform RAD in the world, would you raise the price?
If people are avoiding it in droves, perhaps you need to lower the price
or improve the quality and value? Or do you obviously have no knowledge
of basic economics, so why pretend?
--
Joe Foster <mailto:jfo...@ricochet.net> "Regged" again? <http://www.xenu.net/>
Joe "Nuke Me Xemu" Foster
> Well said!!!
Compared to what President-Select Dumbya Bush spews, I quite agree.
> Saddly, a few of the "loudest" people aka "owners?" of the NG seem to be so
> impressed with themselves that they often miss their own hyprocisy. I
> mean...how "of topic" do you guys get at times!!!
Like "OmniSpam" Smith has posted more than four on-topic *lines* here.
> You get some really great people here as well. Look at Randy Birch...always
> ready to lend a helping hand without any critisism. There are a number of
> others that do that well also...sorry guys, can't remember all your names.
>
> Larry (aka keeper of everyones morals), Joe (aka very self indulgent second
Making fun of $cientology is self-indulgent? It's a public service!
> name, goes with the loud mouth) and Frank (never miss a chance at
> sarcasm)....Lighten up a little. I don't like spam at all, but lets not get
Sure, I'll "lighten up a little". Let me fetch my flamethrower...
> "Sieg Heil" about it.
Godwin alert! http://tuxedo.org/~esr/jargon/html/entry/Godwin's-Law.html
Of course, those who Don't Like Spam are:
a) Nazis
b) Marxists
c) shameless name droppers
c) anti-free enterprise
d) anti-free interchange if [sic] ideas
e) lacking fairness
f) lacking decency
g) against God
h) against the President-Select
i) not discrete [sic]
j) cheap
k) smart asses
l) dumb asses
m) not taking the high road, unlike you two, eh?
.
.
.
z) remembering what usually happens when spamrats aren't stomped ASAP
--
Joe Foster <mailto:jfo...@ricochet.net> On the cans? <http://www.xenu.net/>
Mike
Joe "Nuke Me Xemu" Foster <j...@bftsi0.UUCP> wrote in message
news:tmkqq8j...@corp.supernews.com...
> "Michael L. Smith" <mls...@omnibasic.com> wrote in message
<news:9ka9p...@enews4.newsguy.com>...
>
> > In article <tmep8js...@corp.supernews.com>, "Joe \"Nuke Me Xemu\"
Foster" <jfo...@ricochet.net> wrote:
>
> > >The original version of my first reply contained only a gripe about the
> > >inclusion of far too much quoted material for such a short reply.
<snip>> >.
> Trim your quotes, and none of this would have happened. Quit while you're
> behind!
Here is the actual response I made to which you refer to twice above.
Honestly, there is absolutely no quoted material in this response. Checking
the archives will bear this out. If over-quoting was your complaint, then
you were mistaken in that there was no quoting at all.
----------------------------------------------------------------------------
-----------------
(start)
OmniBasic is runs on both Linux and Windows with no changes to the project
file in either direction. The IDE is identical on both systems. In other
words, write on either platform, compile the same project and run on either.
www.omnibasic.com
(stop)
----------------------------------------------------------------------------
-----------------
If you really mean that "and none of this would have happened" above, you
owe me an apology since none of the origal response was quoted material at
all, but rather, a directed response.
<snip>
Anyway,
> when did I attack God? Are you claiming God is on your side now?
On some of your responses, your signature section said "God=greed?". I took
this as an acttack. If I misinterpreted this, I apologize. I never claimed
that God was on anyone's side.
<snip>
My only other remark concerns your reponse to Michael Williams and the
peashooter response contrasted to your treatment of myself. This is hard to
square with your remarks I quoted earlier in this response that "and none of
this would have happened" had I not over-quoted, when in fact, I had not
quoted at all.
In other words, if this great flood of "the milk of human kindness <g>"
from all sides was the result of a simple misunderstanding, perhaps we can
all learn from it.
Harry Strybos
--
www.streemers.com.au
VB-Mate...useful VB add-in plus some free code
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:tmkqqd8...@corp.supernews.com...
Larry Linson
> Joe...you really need a therapist
AOOGAH! AOOGAH! AOOGAH! (Sound of Klaxon)
Equine Census Alert! Equine Census Alert! Equine Census Alert!
Please notify the Equine Census Bureau if you spot the forequarters matching
the obvious equine hindquarters that posted the article above. An imbalance
in the count of forequarters and hindquarters is a serious problem for the
Equine Census Bureau.
Equine Census Alert! Equine Census Alert! Equine Census Alert!
AOOGAH! AOOGAH! AOOGAH! (Sound of Klaxon marking end of announcement)
Joe "Nuke Me Xemu" Foster
> Joe...you really need a therapist
Correction: I really need a therapist who won't run away screaming
Seriously, though, I can provide cites from either you or "OmniSpam" Smith
for each item in the list which you apparently prefer to think of as mere
crazy-talk.
--
Joe Foster <mailto:jfo...@ricochet.net> KrazyKookKultz! <http://www.xenu.net/>
Harry Strybos
abhor spam, just don't want it to become a "book burning" exercise.
Can we make peace?
Cheers
--
www.streemers.com.au
VB-Mate...useful VB add-in plus some free code
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:tmp6sh9...@corp.supernews.com...
Harry Strybos
>
> Equine Census Alert! Equine Census Alert! Equine Census Alert!
>
> Please notify the Equine Census Bureau if you spot the forequarters
matching
> the obvious equine hindquarters that posted the article above. An
imbalance
> in the count of forequarters and hindquarters is a serious problem for the
> Equine Census Bureau.
>
> Equine Census Alert! Equine Census Alert! Equine Census Alert!
>
> AOOGAH! AOOGAH! AOOGAH! (Sound of Klaxon marking end of announcement)
Actually, thats the sound of a clown...tsk...tsk, Larry, thought you were a
man of inteligence
Joe "Nuke Me Xemu" Foster
> OK, Joe, love a person with a good sense of humour. Just for the records, I
> abhor spam, just don't want it to become a "book burning" exercise.
Not even that classic by "Canker and Seagull" about how to Lose Money
Fast by spamming Usenet? Anyway, who'd want to burn books? Spammers are
much more entertaining once set aflame. Where *is* Smithee-poo, anyway?
> Can we make peace?
> Cheers
Sure! Just stay still, and I'll get bored and go away. Cheerleaders.NET
squeak much more enticingly anyway...
http://members.ricochet.net/~jfoster/looky/chomp-lo.jpg
--
Joe Foster <mailto:jfo...@ricochet.net> "Regged" again? <http://www.xenu.net/>
AndyCrick
"Joseph T. Adams" <j...@apk.net> wrote in message
news:9j536e$3sf$1...@plonk.apk.net...
> Tom Shelton <to...@dakcs.com> wrote:
> : Unfortunately, VB.NET doesn't support operator overloading :(
>
>
> My mistake . . .I thought for some reason that it did.
>
> That does make life a little more difficult.
>
>
> Joe
xganon
On behalf of the CLVBM newsgroup, please be advised that your post is
off-topic. This is a friendly reminder that CLVBM is a newsgroup
devoted to the discussion of Visual Basic, and nothing else. My
suggestion is for you to take your off-topic discussion to email, or
find some other newsgroup that is appropriate for your discussion.
Thank you.