Re: Editorial by Russell Jones/Attack on Gosub

[Mike Mitchell]

On Tue, 30 Jan 2001 00:19:39 -0500, "Steve Dee"
<Steve_Dee@md.prestige.net> wrote:

>
>ALL INKEY$ SEEKEQ
>BLOAD INP SEEKGE
>BOF INSERT SEEKGT
>BSAVE IOCTL SEG

[snip]

[yawn]

And you went to all this trouble just to find some reason to get rid
of GoSub? Jeez!

MM

[Dan Barclay]

On 30 Jan 2001 16:48:43 -0800, "Jason Kaczor"
<jkaczor@acoupleanerds.com> wrote:

>
>kylix_is@hotmail.com (Mike Mitchell) wrote:
>>>
>>>ALL INKEY$ SEEKEQ
>>>BLOAD INP SEEKGE
>>>BOF INSERT SEEKGT
>>>BSAVE IOCTL SEG
>>
>>[yawn]
>
>>And you went to all this trouble just to find some reason to >get rid of
>GoSub? Jeez!
>
>No. He is showing how the language has evolved. Face facts, VB has NEVER
>been "industry-standard-certified" BASIC.

What's that got to do with Language Stability?

>It lost that when it when to Windows.

Nope. First, it wasn't "industry-standard-certified" before it went
to Windows.

Secondly, when I took my apps to windows nearly everything but the UI
worked without change. Somewhere around 2 megs of common source at
the time as I recall. I even had it set up so that I could make
changes in the common files and to a rebuild in both DOS and Windows
against the same files.

>It is a VENDOR-designed language, tool and environment.

The issue is Language Stability. On that, the results count. Other
than UI code MS Basic has been pretty stable (with the exceptions
around VB1 and VB4 I have previously noted) regardless of the reason.

Stability is a feature and it's there or it's not. Whether it's
stable because it adheres to some outside standard or because it's
merely consistent with previous releases the bottom line is the same.

>If the VENDOR went out of business tomorrow, where would you be?

Since the target OS is of the same vendor, that seems to be a moot
point don't you think? In this particular case, I think the vendor is
in pretty good financial shape.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Jason Kaczor]

kylix_is@hotmail.com (Mike Mitchell) wrote:
>>
>>ALL INKEY$ SEEKEQ
>>BLOAD INP SEEKGE
>>BOF INSERT SEEKGT
>>BSAVE IOCTL SEG
>
>[yawn]

>And you went to all this trouble just to find some reason to >get rid of
GoSub? Jeez!

No. He is showing how the language has evolved. Face facts, VB has NEVER
been "industry-standard-certified" BASIC.

It lost that when it when to Windows.

It is a VENDOR-designed language, tool and environment.

If the VENDOR went out of business tomorrow, where would you be?

Would you complain about lack of support? That the language, tool and IDE
never got any more fixes/updates?

The choice ultimately comes down to: VENDOR tools/languages/IDE, or opensource
alternatives.

Choose a language that is designed and defined by an "international" comittee/consortium,
etc. C++, Ada, ECMAScript. Choose a toolset that is opensource and freely
available.

In my experience, you get what you pay for, in terms of productivity, reliability
and current product support.

>MM

Regards
Jason Kaczor

[Steve Dee]

> still didn't deserve to be summarily executed for being ancient. No
> one is *forcing* you or anyone else to use it!


Very true....and because I don't use it and other things along the same
line, my "port" to VB.NET is indeed an "upgrade" with little or no pain.

[Sheldon Rosenfeld]

Steve Dee <Steve_Dee@md.prestige.net> wrote in message
news:3a776bf6$1@news.devx.com...
> > still didn't deserve to be summarily executed for being ancient. No
> > one is *forcing* you or anyone else to use it!
>
>
> Very true....and because I don't use it and other things along the same
> line, my "port" to VB.NET is indeed an "upgrade" with little or no pain.
>

"MY" port? Unfortunately, MS should be concerning itself
with the other 2,999,999,999 developers too.

Sheldon

[Jason Kaczor]

"Dan Barclay" <dbarclay@ih2000.net> wrote in message
news:tule7tkpvfcn6daqhkrkltithml3oarhjm@4ax.com...
> >
> >No. He is showing how the language has evolved. Face facts, VB has NEVER
> >been "industry-standard-certified" BASIC.
>
> What's that got to do with Language Stability?

Sigh (for full link
http://www.digitalcentury.com/encyclo/update/BASIC.html):

===================================================================
In 1974, just as kits to build personal computers were hitting the market,
the American National Standards Institute (ANSI) recognized a need for a
standard BASIC language. A committee began work on creating a standard for
minimal BASIC, to be followed by one for a full version called Standard
BASIC. Unfortunately for the language, the PC revolution began before the
standard for full BASIC could be developed. BASIC could be used on small
systems such as PCs, and before early PC operating systems were developed
(CP/M and DOS), writing programs with BASIC was the only method for PC users
to develop programs that would run on their computers. As new PCs were
introduced over the next few years, each one had its own BASIC, just enough
different from all others so programs written on one could not be run on
another.
In addition to the Microsoft and Eubanks versions of BASIC, many others were
being written, including Radio Shack Level 1 BASIC, Apple Integer BASIC,
RMBASIC, Better BASIC. Gee-Whiz (GW) BASIC, QuickBASIC, and Professional
BASIC. By the early to mid-1980s, several hundred versions of BASIC were
being used. It had evolved into one language with dozens of dialects and
offshoots. These differences, in such important elements as vocabulary,
grammar, and limits, were significant enough that moving a program from one
dialect to another required that it be rewritten. Because Microsoft BASIC
was on more than 50 types of PCs, it became the de facto standard.

ANSI had released its standard for minimal BASIC; however the PC revolution
and indecision by the committee delayed work on what would eventually be
called Standard BASIC. As PC memory quickly grew and demand for greater
language capability increased, the BASIC language evolved - independent of
any standard. The result was that at a time when computer users needed a
common language, all they had were multiple, incompatible versions of BASIC.

Kemeny and Kurtz had gone on to other things and were not actively involved
in the maintenance of BASIC. In 1983, they used a PC for the first time and
were surprised at ".how terrible were the crude 'street' versions [of BASIC]
that high school and college students all over the country had to use."
Appalled at what had happened to their language, Kurtz became chairman of
the ANSI Standard BASIC committee, and in 1984, he and Kemeny introduced
their own version, called True BASIC.

In 1985, they released their book Back to BASIC. But perhaps the subtitle of
the book says more about their reasons for writing the book than anything
else - The History, Corruption, and Future of the Language. Through the ANSI
committee, their introduction of True BASIC, and the book, they wanted to
set their language back on track and purge it of the elements that had taken
away from the original eight goals that guided them in its creation.

In 1988, 14 years after beginning the task, ANSI finally issued Standard
BASIC. It included multi-character variable names, structured statements,
machine-independent graphics, user-defined functions and subroutines, and a
matrix package.

===================================================================

Unfortunately I don't want to pay the money to get the PDF's from ANSI for
the "Full Basic" specification.

Only when something is a "public standard" can you expect it to be stable.
Vendors "innovate".

> Nope. First, it wasn't "industry-standard-certified" before it went
> to Windows.

Correct.

> Secondly, when I took my apps to windows nearly everything but the UI
> worked without change. Somewhere around 2 megs of common source at
> the time as I recall. I even had it set up so that I could make
> changes in the common files and to a rebuild in both DOS and Windows
> against the same files.

Did you still use DOS-based "hooks" to get file information, or the Windows
API.?

I'm sure youhad everything abstracted, your common source had known inputs,
and
known outputs. Meaning that if the INTERNAL implementation changed, your
code
would still work fine.

> The issue is Language Stability. On that, the results count. Other
> than UI code MS Basic has been pretty stable (with the exceptions
> around VB1 and VB4 I have previously noted) regardless of the reason.

<re-quote>
It had evolved into one language with dozens of dialects and offshoots.
These differences, in such important elements as vocabulary, grammar, and
limits, were significant enough that moving a program from one dialect to
another required that it be rewritten.
</re-quote>

Sure, they also say MS Basic became the defacto standard.

If Microsoft never claimed their BASIC was standards-compliant, they DO NOT
have to comply.

> Stability is a feature and it's there or it's not. Whether it's
> stable because it adheres to some outside standard or because it's
> merely consistent with previous releases the bottom line is the same.

So, you never answered my questions. Where is Clarion? PowerBuilder?
LotusScript? Asymetrix Toolbook? Dylan? PowerObjects? Enterprise
Developer? AppWare? Visual AppBuilder?

1993 - ANSI releases the X3J4.1 technical report -- the first-draft proposal
for (gulp) object-oriented COBOL. The standard is expected to be finalized
in 1997.

1995 - In February , ISO accepts the 1995 revision of the Ada language.
Called Ada 95, it includes OOP features and support for real-time systems.

Gee, why hasn't they caught on, their stable, right?

What about the languages that ARE stable, and standardized?

Well C++ definately see's it's use under Windows. COBOL? Ada? Smalltalk?
ANSI Forth? http://www.forth.com

> Since the target OS is of the same vendor, that seems to be a moot
> point don't you think? In this particular case, I think the vendor is
> in pretty good financial shape.

Yep, very good prospects with it's upcoming and newly released products.

> Dan
> Language Stability is a *feature* I wish VB had!

You will be wishing, hoping and dreaming for quite awhile.

Unless MS hands the reigns over to a standards body, it's their language.
If they've never "claimed" compliance, why should they start now, in 2001?

Ultimately MS does not answer to it's customers, former customers or
competitors. It answers to it's shareholders.

What have the shareholders seen in recent years?
- diminishing "mindshare", both on Operating System (Linux), and development
(Java) levels
- an ugly court battle with Sun over "innovating" Java. Sure, WinForms and
J/Direct were great idea's, but they removed RMI, JNI.
- an ugly court battle with Uncle Sam, that may just impact the Operating
System.

Investors have got to be wondering, if IBM is doing more exciting things
than Microsoft, where should I put my money.

..NET is a direction change. It is a new platform.

[James D. Foxall]

Hey Mike,

What about:

Option AllowGoSub = False

Everyone could have it their way...

--

James D. Foxall
Microsoft Certified Solution Developer
Vice President - Tigerpaw Software (MCSP) www.tigerpawsoftware.com

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message
news:3a77575f.17819763@news.devx.com...
> On Mon, 29 Jan 2001 22:44:04 -0500, "Steve Dee"
> <Steve_Dee@md.prestige.net> wrote:
>
> >Sure it was...did the speed alone mean it was a good thing? I think
> >not....and it was more than likely a jmp/ret pair. But if you wanted
pure
> >speed with jmp/ret, why not DO it in Assembler? As I recall, you have
done
> >many routines in ASM for just that reason.
> >
>
> That's right! Why simplify when you can obfuscate? Of COURSE most
> anything could have been done in assembly language, but you're
> incriminating the humble GoSub with far more than it deserves. It
> wasn't used for speed, it was used for structure - in the days when
> precious few other constructs were available. Why can't you just
> accept that GoSub has been around for years, does a perfectly adequate
> job in the right hands, has largely been superseded by functions, but
> still didn't deserve to be summarily executed for being ancient. No
> one is *forcing* you or anyone else to use it!
>
> MM
>

[Dan Barclay]

On Wed, 31 Jan 2001 07:37:48 -0700, "Jason Kaczor"
<jkaczor@acoupleanerds.com> wrote:

<snip>
>> Secondly, when I took my apps to windows nearly everything but the UI
>> worked without change. Somewhere around 2 megs of common source at
>> the time as I recall. I even had it set up so that I could make
>> changes in the common files and to a rebuild in both DOS and Windows
>> against the same files.
>
>Did you still use DOS-based "hooks" to get file information, or the Windows
>API.?
>
>I'm sure youhad everything abstracted, your common source had known inputs,
>and
>known outputs. Meaning that if the INTERNAL implementation changed, your
>code
>would still work fine.

I had wrappers around things that were clearly environment dependent.
Most were my own, but I gradually moved to 3rd partys for generic
stuff (Crescent, Microhelp may they RIP).

>> The issue is Language Stability. On that, the results count. Other
>> than UI code MS Basic has been pretty stable (with the exceptions
>> around VB1 and VB4 I have previously noted) regardless of the reason.
>
><re-quote>
>It had evolved into one language with dozens of dialects and offshoots.
>These differences, in such important elements as vocabulary, grammar, and
>limits, were significant enough that moving a program from one dialect to
>another required that it be rewritten.
></re-quote>

Regardless of what the article said, there was a (fairly) stable core
within the MS implementations.

>Sure, they also say MS Basic became the defacto standard.

Yup. For that to be recognized, there had to be some syntax and
behavior that was called "MS Basic" don't you think?


>If Microsoft never claimed their BASIC was standards-compliant, they DO NOT
>have to comply.

Absolutely correct.

>> Stability is a feature and it's there or it's not. Whether it's
>> stable because it adheres to some outside standard or because it's
>> merely consistent with previous releases the bottom line is the same.
>
>So, you never answered my questions. Where is Clarion? PowerBuilder?
>LotusScript? Asymetrix Toolbook? Dylan? PowerObjects? Enterprise
>Developer? AppWare? Visual AppBuilder?

Beats me. Same place as OS/2 I guess. Never went there.

>1993 - ANSI releases the X3J4.1 technical report -- the first-draft proposal
>for (gulp) object-oriented COBOL. The standard is expected to be finalized
>in 1997.

I'm not a Cobol er, but that should be interesting.

>1995 - In February , ISO accepts the 1995 revision of the Ada language.
>Called Ada 95, it includes OOP features and support for real-time systems.
>
>Gee, why hasn't they caught on, their stable, right?

Dunno if they're stable or not. I would guess they are. That doesn't
*make* it a market success. Language Stability is just an important
feature.

>What about the languages that ARE stable, and standardized?
>
>Well C++ definately see's it's use under Windows. COBOL? Ada? Smalltalk?
>ANSI Forth? http://www.forth.com

Forth? The first write-only language. Not me.

>> Since the target OS is of the same vendor, that seems to be a moot
>> point don't you think? In this particular case, I think the vendor is
>> in pretty good financial shape.
>
>Yep, very good prospects with it's upcoming and newly released products.
>
>> Dan
>> Language Stability is a *feature* I wish VB had!
>
>You will be wishing, hoping and dreaming for quite awhile.

Or looking for it. I wish I didn't have to look.

>Unless MS hands the reigns over to a standards body, it's their language.
>If they've never "claimed" compliance, why should they start now, in 2001?

Marketplace perhaps? If they expect us to use the products for real
applications (having lives of more than 5 years) you need version to
version stability.

>Ultimately MS does not answer to it's customers, former customers or
>competitors. It answers to it's shareholders.

True enough.

>
>What have the shareholders seen in recent years?
>- diminishing "mindshare", both on Operating System (Linux), and development
>(Java) levels
>- an ugly court battle with Sun over "innovating" Java. Sure, WinForms and
>J/Direct were great idea's, but they removed RMI, JNI.
>- an ugly court battle with Uncle Sam, that may just impact the Operating
>System.
>
>Investors have got to be wondering, if IBM is doing more exciting things
>than Microsoft, where should I put my money.

True. But then, some of IBM's problems started in the '60's and 70's
when they went from "get the customer what he needs" to "sell the
customer what we've designed".

>.NET is a direction change. It is a new platform.

Change is good. Err... well, *improvement* is good.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Vlad Ivanov]

Oh god, James, you speak my mind. I will go one step further and write up
what Microsoft needs to do, so that they can just cut & paste it.

(Place this in Language Reference)------------------------

GoSub construct will be removed in the next version (for the reasons, goto
news.devx.com). To allow you to migrate your code that uses it, it is still
functioning in this release. By default GoSub is not allowed by the
compiler. To enable it, place the following in the Declarations section of
your code module:

Option AllowGoSub = True


(Place this in help file for GoSub)-------------------------

GoSub construct will be removed in the next version (for the reasons, goto
news.devx.com). To allow you to migrate your code that uses it, it is still
functioning in this release. By default GoSub is not allowed by the
compiler. To enable it, place the following in the Declarations section of
your code module:

Option AllowGoSub = True

(Place this in What's New document)


GoSub construct will be removed in the next version (for the reasons, goto
news.devx.com). To allow you to migrate your code that uses it, it is still
functioning in this release. By default GoSub is not allowed by the
compiler. To enable it, place the following in the Declarations section of
your code module:

Option AllowGoSub = True

-----------------------------------------------------------

And repeat the same for the other incompatibilities.




"James D. Foxall" <jamesf@tigerpawsoftware.com> wrote in message
news:3a782d94$1@news.devx.com...
> Hey Mike,
>
> What about:
>
> Option AllowGoSub = False
>
> Everyone could have it their way...
>
> --
>
> James D. Foxall
> Microsoft Certified Solution Developer
> Vice President - Tigerpaw Software (MCSP) www.tigerpawsoftware.com
>
> "Mike Mitchell" <kylix_is@hotmail.com> wrote in message
> news:3a77575f.17819763@news.devx.com...
> > On Mon, 29 Jan 2001 22:44:04 -0500, "Steve Dee"
> > <Steve_Dee@md.prestige.net> wrote:
> >
> > >Sure it was...did the speed alone mean it was a good thing? I think
> > >not....and it was more than likely a jmp/ret pair. But if you wanted
> pure
> > >speed with jmp/ret, why not DO it in Assembler? As I recall, you have
> done
> > >many routines in ASM for just that reason.
> > >
> >
> > That's right! Why simplify when you can obfuscate? Of COURSE most
> > anything could have been done in assembly language, but you're
> > incriminating the humble GoSub with far more than it deserves. It
> > wasn't used for speed, it was used for structure - in the days when
> > precious few other constructs were available. Why can't you just
> > accept that GoSub has been around for years, does a perfectly adequate
> > job in the right hands, has largely been superseded by functions, but
> > still didn't deserve to be summarily executed for being ancient. No
> > one is *forcing* you or anyone else to use it!
> >
> > MM
> >
>
>

[Sheldon Rosenfeld]

Vlad Ivanov <vivanov@polarisconsulting.com> wrote in message
news:3a7848a0$1@news.devx.com...
>
> (Place this in Language Reference)------------------------
>
> GoSub construct will be removed in the next version (for the reasons, goto
> news.devx.com).


You're outta here! You used a "goto"

Sheldon

[Jason Kaczor]

Dan Barclay <dbarclay@ih2000.net> wrote:
>
>I had wrappers around things that were clearly environment
>dependent. Most were my own, but I gradually moved to 3rd
>partys for generic stuff (Crescent, Microhelp may they RIP).

Chuckle, been there. One employer made the mistake of buying every third-party
VB3 VBX on the market. Then the team of 12 would pick whichever "pretty-toolbox-icon"
they liked best.

Now that was not "productive" during the move to VB4.

By now, I would assume you have classes that wrap the "environment dependant"
code. They have clearly defined interfaces, and you could simply re-direct
appropriate calls to .NET framework classes internally (assuming they exist,
grin...)

>Regardless of what the article said, there was a (fairly)
>stable core within the MS implementations.

I will be honest, never touched MS Basic until it became VB. Did some TSR80,
but in DOS I mostly used Turbo Pascal.

>Yup. For that to be recognized, there had to be some syntax and
>behavior that was called "MS Basic" don't you think?

But, it hasn't been MS Basic for a decade now. It's "Visual Basic", TM-Microsoft.

>>So, you never answered my questions. Where is Clarion?
>>PowerBuilder? LotusScript? Asymetrix Toolbook? Dylan?
>>PowerObjects? Enterprise Developer? AppWare? Visual AppBuilder?
>
>Beats me. Same place as OS/2 I guess. Never went there.

But what about the people who did? What about their growing pains? Language
changes? All of those tools "purport" to support RAD 4/5GL languages, IDE's
and technologies, to make building modern applications easier, faster and
"more reliable".

VB kicked the pants off them in the marketplace. Some may still exist, some
may never have had "syntax changes", but most are dead. (There were a few
Borland "visual" windows tools, but I cannot recall the names, and searching
didn't locate anything)

I certainly didn't go most of those places either, but I have been on a few
wild strange trips: Delphi, OS/2, BeOS, Newton, etc. When Newton died, because
Apple decided to change direction, what happened to existing clients such
as; Police forces, US Dept. of Defence, Medical centers, etc?

When IBM decided to no longer support a commercial OS/2, what happened to
those folks, their code-bases? Their stability?
(I'm sure IBM still supports it's OS/2 finance & banking customers)

>>1993 - ANSI releases the X3J4.1 technical report -- the first-
>>draft proposal for (gulp) object-oriented COBOL. The standard
>>is expected to be finalized in 1997.
>
>I'm not a Cobol er, but that should be interesting.

Well, I don't know if the Fujitsu COBOL.NET will be compliant. That would
be interesting to say the least, if COBOL.NET was fully ANSI compliant.
There - stability & .NET wow! Let's all switch!

>Dunno if they're stable or not. I would guess they are. That
>doesn't *make* it a market success. Language Stability is just
>an important feature.

Correct. But what does the market want? Tools to get the job done in a
better fashion. That entails innovation, not stability. If the market thought
like that, why would it "embrace" Java? After all, C++ code simply won't
recompile into a Java-byte-code class. Java took the "stable" C++, and innovated.
The market responded.

Ultimately we will see whether the VB market responds, or is alienated.
I hope Microsoft bone's up the migration wizard, after all I've heard rumours
that JUMP *may* even "translate" calls to Java JDK classes to .NET framework
classes.

IF they do that for Java, but not for VB, they are asking for class-action
lawsuits.

Another alternative is to "fix" up the compatibility layer. Personally,
I think the migration tool is the best option, rather than bloat-up the framework,
syntax parser, etc. with code that will only be used to PORT an individual
project ONCE, migrate it intelligently.

>Forth? The first write-only language. Not me.

But it's stable. IMO you cannot have a language that is controlled by a
vendor that is truly stable.

Name one-vendor designed language (not based on ANSI/ISO/ECMA standards)
that has been completely syntax-stable for 15+ years.

>>> Dan
>>> Language Stability is a *feature* I wish VB had!
>>
>>You will be wishing, hoping and dreaming for quite awhile.
>
>Or looking for it. I wish I didn't have to look.

Unfortunately, unless you switch to C++, COBOL, Forth, Ada you will be looking,
and looking.

While *innovation* from Microsoft is a truly over-used phrase, that's what
they are attempting to do.

>Marketplace perhaps? If they expect us to use the products for
>real applications (having lives of more than 5 years) you need
>version to version stability.

I don't expect an application written for Win32 to fully take advantage of
Win64 when it arrives. My clients wouldn't either. What about Win128?
etc, etc, etc. Hmm, what about the many vendor compilers that STILL don't
take advantage of the Intel MMX instruction-set? Or AMD's? They've been
out for 4-5 years now, even for non-games, they can boost application speed...
But apps written without them continue to function on P4, P5 CPU's, just
not at optimum speed, or with maximum features.

Unless MS drops support for Win32 applications under Win64-128-256, a compiled
VB6 app will continue to work fine. OTOH, If Intel's 64-bit CPU (or 128,
or whatever) simply doesn't execute 32-bit code, whose fault is that? Microsofts?

We come back to two camps: Server-side, Client-side.

Server-side applications can be kept "monolithic", sand-bagged, using "older,
deprecated" tools for as long as they continue to perform their original
function. At some point, a new system is either purchased, or written, but
almost never is there expected full RE-USE of older code. Server-side VB6
COM+/MTS/MSMQ type apps will continue to function fine. Need .NET communication,
interoperability with newer servers? Use the VB6 SOAP toolkit, add a SOAP
"interface" to your VB6 app, and wham...

Client-side applications satisfy users directly. They have to have the latest
UI, connectivity, robustness features that the market demands. Iterative
development is great, you can add features via COM, ActiveX... Up to a point...
Then the beast will begin to collapse under it's own weight... When a new
user-interface paradigm is introduced for a new platform, only the new tools
will truly take advantage of it. The market is viscous, if you don't provide
the experience the users want, they will move on. If a competitor has used
the lasted RAD/OOP tools to "build-from-scratch" a better product, perhaps
you should have done the same...

Switch to Delphi. Object Pascal is robust, and hasn't truly changed since
v.1.0. Even with the Kylix product, it's the same syntax.

But no multiple inheritence. C++ has it, essentially Borland controls the
"Object Pascal" standard. IF they decided to add that feature, and break
class frameworks, that would be THEIR choice.

You are correct, the market will decide. "for the first time, the future
seemed uncertain"...

It's "interesting times". Myself, I almost gave Microsoft up for dead.
Firmly headed over to "Java-camp", **** I got my company certified as an
official "Sun Developer".

Honestly, the Java camp is pretty jaded as well. I *think* there may be
a good number that try .NET (VB or C#), and like it.

****, I noticed a post from "open-source-hacker-wizard-Gnome-HelixCode-Ximian-guru"
Miguel de Icaza asking questions about getting the .NET platform working.
(Albeit under an emulated Windows, I *think*)...

*Personally* I think there will be migration both ways. Some customers will
be "fed" up, and buy into Suns "proprietary-non-standardized" Java world.
Others from Java will try something with a little better "price-performance"
ratio. (Sure Java is free, but when it comes to speed, you gets whats you
pays fer...)

****, with SOAP, both camps can interoperate just fine.

>True. But then, some of IBM's problems started in the '60's
>and 70's when they went from "get the customer what he needs"
>to "sell the customer what we've designed".

Yep. The "browser" is a necessary part of the OS... Well, I agree, having
a browser is great in an OS. But as "Jean-Luis Gasse" of Be stated; "we
have a browser too, look I can delete it with one click"...

Personally I like the "File Explorer/Web integration", I like the "web folders"
(which use the open WebDAV protocol), I like HTML desktops, and folder views.

It IS innovative. Windows 2000 w/Browser integration is a helluva lot closer
to Xanadu than Nelson ever made it.

>Change is good. Err... well, *improvement* is good.

Of course, at what expense. It's a cliche, but sometimes you have to "break"
the "old mold". Be had to throw-out binary application-compatibility in
it's move from v.3.0 to 4.0 for the Intel platform. Con: Apps compiled for
v.3 broke, apps compiled for v.4 gained as much as a 100% performance increase.

Maintaining compatibility for compatibilitys' sake is like hooking an "anchor
and chain" around your neck, and going for a swim. OS/2? A better "Windows
than Windows", a better "DOS than DOS", except if you wrote the native OS/2
API's, you could do many amazing things. But no one did. And eventually
Win32 broke the "better Windows than Windows" promise. By that time, who
wanted "crufty" of Win3.1 apps running under a 32-bit OS/2? No-one, everyone
wanted the latest Win32 apps... In the meantime, almost no-one wrote OS/2
apps... ****, it was fully 16-bit DOS/Windows compatible... where is it
now?

>Dan
>Language Stability is a *feature* I wish VB had!
> (#6)

Regards
Jason Kaczor

[Zane Thomas]

On Wed, 31 Jan 2001 07:37:48 -0700, "Jason Kaczor"
<jkaczor@acoupleanerds.com> wrote:

>ANSI Forth? http://www.forth.com

LOL!!!

Hey, I wrote the first version of forth which ran on a 68000. Anyone want
a .net version? ROFLMAO!


---
Ice Z - Straight Outta Redmond

[James D. Foxall]

Choice is good. Fair warning is good.

Choice and fair warning? oh baby!

--

James D. Foxall
Microsoft Certified Solution Developer

"Vlad Ivanov" <vivanov@polarisconsulting.com> wrote in message
news:3a7848a0$1@news.devx.com...
> Oh god, James, you speak my mind. I will go one step further and write up
> what Microsoft needs to do, so that they can just cut & paste it.
>
> (Place this in Language Reference)------------------------
>
> GoSub construct will be removed in the next version (for the reasons, goto
> news.devx.com). To allow you to migrate your code that uses it, it is
still
> functioning in this release. By default GoSub is not allowed by the
> compiler. To enable it, place the following in the Declarations section of
> your code module:
>
> Option AllowGoSub = True
>
>
> (Place this in help file for GoSub)-------------------------
>
> GoSub construct will be removed in the next version (for the reasons, goto
> news.devx.com). To allow you to migrate your code that uses it, it is
still
> functioning in this release. By default GoSub is not allowed by the
> compiler. To enable it, place the following in the Declarations section of
> your code module:
>
> Option AllowGoSub = True
>
> (Place this in What's New document)
>
>
> GoSub construct will be removed in the next version (for the reasons, goto
> news.devx.com). To allow you to migrate your code that uses it, it is
still
> functioning in this release. By default GoSub is not allowed by the
> compiler. To enable it, place the following in the Declarations section of
> your code module:
>
> Option AllowGoSub = True
>
> -----------------------------------------------------------
>
> And repeat the same for the other incompatibilities.
>
>
>
>
> "James D. Foxall" <jamesf@tigerpawsoftware.com> wrote in message
> news:3a782d94$1@news.devx.com...
> > Hey Mike,
> >
> > What about:
> >
> > Option AllowGoSub = False
> >
> > Everyone could have it their way...
> >
> > --
> >
> > James D. Foxall
> > Microsoft Certified Solution Developer
> > Vice President - Tigerpaw Software (MCSP) www.tigerpawsoftware.com
> >
> > "Mike Mitchell" <kylix_is@hotmail.com> wrote in message
> > news:3a77575f.17819763@news.devx.com...
> > > On Mon, 29 Jan 2001 22:44:04 -0500, "Steve Dee"
> > > <Steve_Dee@md.prestige.net> wrote:
> > >
> > > >Sure it was...did the speed alone mean it was a good thing? I think
> > > >not....and it was more than likely a jmp/ret pair. But if you wanted
> > pure
> > > >speed with jmp/ret, why not DO it in Assembler? As I recall, you
have
> > done
> > > >many routines in ASM for just that reason.
> > > >
> > >
> > > That's right! Why simplify when you can obfuscate? Of COURSE most
> > > anything could have been done in assembly language, but you're
> > > incriminating the humble GoSub with far more than it deserves. It
> > > wasn't used for speed, it was used for structure - in the days when
> > > precious few other constructs were available. Why can't you just
> > > accept that GoSub has been around for years, does a perfectly adequate
> > > job in the right hands, has largely been superseded by functions, but
> > > still didn't deserve to be summarily executed for being ancient. No
> > > one is *forcing* you or anyone else to use it!
> > >
> > > MM
> > >
> >
> >
>
>

[Dan Barclay]

On 31 Jan 2001 09:40:45 -0800, "Jason Kaczor"
<jkaczor@acoupleanerds.com> wrote:

>
>Dan Barclay <dbarclay@ih2000.net> wrote:
>>
>>I had wrappers around things that were clearly environment
>>dependent. Most were my own, but I gradually moved to 3rd
>>partys for generic stuff (Crescent, Microhelp may they RIP).
>
>Chuckle, been there. One employer made the mistake of buying every third-party
>VB3 VBX on the market. Then the team of 12 would pick whichever "pretty-toolbox-icon"
>they liked best.

LOL! Well, when I use 3rd party stuff I try like **** to have a Plan
B. Fortunately I was doing that even back then. I had the source
and/or knew how to do it myself. You can't get a programmer like Jim
Mack or Ethan Winer for what I paid for the libs they've written.

>Now that was not "productive" during the move to VB4.

VB4 is something I did some work in, but never had the guts to ship
anything of any importance in. As far as 3rd party libs go, maybe you
haven't kept up with Jim and Stamina.

>By now, I would assume you have classes that wrap the "environment dependant"
>code. They have clearly defined interfaces, and you could simply re-direct
>appropriate calls to .NET framework classes internally (assuming they exist,
>grin...)

I have classes, but Subs and Functions are the wrappers. After all,
most of the things you're wrapping are functions. Sometimes I use the
wrappers *in* classes.

But, like so many other VB programmers, most of my code is code.
Classes are handy when I need them, just like GoSubs.

>>Regardless of what the article said, there was a (fairly)
>>stable core within the MS implementations.
>
>I will be honest, never touched MS Basic until it became VB. Did some TSR80,
>but in DOS I mostly used Turbo Pascal.

You would be surprised to find that most (non-i/o) code fragments from
TRS and CP/M would compile and work fine. Much of it still would.

>>Yup. For that to be recognized, there had to be some syntax and
>>behavior that was called "MS Basic" don't you think?
>
>But, it hasn't been MS Basic for a decade now. It's "Visual Basic", TM-Microsoft.

VB is MS Basic based, and that is the core of the language itself.
Visual Basic is just a product that uses that language (as was IBM
Basic, TRS, QuickBasic, etc).

>>>So, you never answered my questions. Where is Clarion?
>>>PowerBuilder? LotusScript? Asymetrix Toolbook? Dylan?
>>>PowerObjects? Enterprise Developer? AppWare? Visual AppBuilder?
>>
>>Beats me. Same place as OS/2 I guess. Never went there.
>
>But what about the people who did? What about their growing pains? Language
>changes? All of those tools "purport" to support RAD 4/5GL languages, IDE's
>and technologies, to make building modern applications easier, faster and
>"more reliable".

Growing pains? Growing? Huh? Ya lost me there.

>VB kicked the pants off them in the marketplace. Some may still exist, some
>may never have had "syntax changes", but most are dead. (There were a few
>Borland "visual" windows tools, but I cannot recall the names, and searching
>didn't locate anything)

Right. That's the point. They're dead, they don't have the growing
pains. That is a marketing issue... and it's something I keep in mind
as I look for what to use besides VB. MSVC is certainly stable, but
it's unclear if it'll be migrated with .net to other platforms for
component building. C# is likely stable since the runtime lib is on
it. Then there are the other vendors (.net and non.net). I'd rather
be spending my time on the apps than re-evaluating tools.

>I certainly didn't go most of those places either, but I have been on a few
>wild strange trips: Delphi, OS/2, BeOS, Newton, etc. When Newton died, because
>Apple decided to change direction, what happened to existing clients such
>as; Police forces, US Dept. of Defence, Medical centers, etc?

Read up on OS/2, never went there. We've got Delphi here and just
upgraded to re-evaluate. I don't do Apple.

>When IBM decided to no longer support a commercial OS/2, what happened to
>those folks, their code-bases? Their stability?
>(I'm sure IBM still supports it's OS/2 finance & banking customers)

They did for quite some time, probably still do. I lost track of them
but occasionally came across OS/2 nests.

>>>1993 - ANSI releases the X3J4.1 technical report -- the first-
>>>draft proposal for (gulp) object-oriented COBOL. The standard
>>>is expected to be finalized in 1997.
>>
>>I'm not a Cobol er, but that should be interesting.
>
>Well, I don't know if the Fujitsu COBOL.NET will be compliant. That would
>be interesting to say the least, if COBOL.NET was fully ANSI compliant.
>There - stability & .NET wow! Let's all switch!

What a concept! Might be worth a look actually.

>>Dunno if they're stable or not. I would guess they are. That
>>doesn't *make* it a market success. Language Stability is just
>>an important feature.
>
>Correct. But what does the market want? Tools to get the job done in a
>better fashion. That entails innovation, not stability. If the market thought
>like that, why would it "embrace" Java? After all, C++ code simply won't
>recompile into a Java-byte-code class. Java took the "stable" C++, and innovated.
> The market responded.

Well, at least part of the market wants Language Stability. I'd guess
that there is also a good part of the market that *thinks* they don't
need it and won't care because they're starting on new projects. That
is, until the rug gets pulled out from under them again in a couple of
years.

>Ultimately we will see whether the VB market responds, or is alienated.
>I hope Microsoft bone's up the migration wizard, after all I've heard rumours
>that JUMP *may* even "translate" calls to Java JDK classes to .NET framework
>classes.

So far it doesn't sound too good. I'd be really surprised if they can
get a wizard that would emit translated code that behaved the way the
original code did. Then I'd be astounded if that code were
maintainable or even readable.

>IF they do that for Java, but not for VB, they are asking for class-action
>lawsuits.

Well, in this country you can sue about anything. I don't think that
would be successful. But, what they're doing to developers (unless
they fix it) will be *long* remembered in the marketplace.

>Another alternative is to "fix" up the compatibility layer. Personally,
>I think the migration tool is the best option, rather than bloat-up the framework,
>syntax parser, etc. with code that will only be used to PORT an individual
>project ONCE, migrate it intelligently.

The "right thing" to do is to take the existing (relatively new) VB5/6
compiler and have it emit .net IL instead of MSVS IL. No need to
bloat anything.

>>Forth? The first write-only language. Not me.
>
>But it's stable. IMO you cannot have a language that is controlled by a
>vendor that is truly stable.

True, unless the market demands it. So, you don't think C# will be
stable either? They've submitted it to standards, but if they weren't
writing the RTL in it would you bet your business on its stability?

>Name one-vendor designed language (not based on ANSI/ISO/ECMA standards)
>that has been completely syntax-stable for 15+ years.

Take out the "completely", put in a couple of "oops", and I can name
one. At least until now there was MS Basic.

<snip>
>While *innovation* from Microsoft is a truly over-used phrase, that's what
>they are attempting to do.

I think the innovation is great. But, most of the language changes in
VB.net are gratuitous... they have nothing to do with the .net
innovations.

>>Marketplace perhaps? If they expect us to use the products for
>>real applications (having lives of more than 5 years) you need
>>version to version stability.
>
>I don't expect an application written for Win32 to fully take advantage of
>Win64 when it arrives. My clients wouldn't either. What about Win128?

The exe won't take full advantage of new environments, but you're
thinking like a programmer.

The app *owner* wants a job done. An app he bought or had built is
expected to do that. For mission critical functions, the app is
expected to do that until the business goes under.

The owner has paid for the functionality to be built and stored in
source code. Nearly all of that functionality is still going to be
required, even when new features are added. It is a corporate asset.

To the owner, the "application" is not the current version EXE. It's
the function provided.

>etc, etc, etc. Hmm, what about the many vendor compilers that STILL don't
>take advantage of the Intel MMX instruction-set? Or AMD's? They've been
>out for 4-5 years now, even for non-games, they can boost application speed...
> But apps written without them continue to function on P4, P5 CPU's, just
>not at optimum speed, or with maximum features.

Well, if you'd take the source code and recompile it the compiler
would (hopefully) optimize for those things.

>Unless MS drops support for Win32 applications under Win64-128-256, a compiled
>VB6 app will continue to work fine. OTOH, If Intel's 64-bit CPU (or 128,
>or whatever) simply doesn't execute 32-bit code, whose fault is that? Microsofts?

Have you tried to sell VB3 apps lately? DOS? Mine still work fine
(as do my DOS apps). Think there may be a parallel here (assuming
..net succeeds)?

>We come back to two camps: Server-side, Client-side.
>
<snip>

In the market I'm in, heavy client is the way to go. Dotnet
supposedly allows you to go either way. Too bad it doesn't have VB.

>Switch to Delphi. Object Pascal is robust, and hasn't truly changed since
>v.1.0. Even with the Kylix product, it's the same syntax.

Looking at it (again). Fortunately I don't have to move this week.

<snip>
>****, with SOAP, both camps can interoperate just fine.

Yup. I used to say "buy memory stock". Now I say "buy bandwidth
stock".

<snip>

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Mark Burns]

"Zane Thomas" <zane@mabry.com> wrote in message
news:3b284fdc.1361729531@news.devx.com...
> On Wed, 31 Jan 2001 07:37:48 -0700, "Jason Kaczor"
> <jkaczor@acoupleanerds.com> wrote:
>
> >ANSI Forth? http://www.forth.com
>
> LOL!!!
>
> Hey, I wrote the first version of forth which ran on a 68000. Anyone want
> a .net version? ROFLMAO!

Heh...and I used to operate a Data General Eclipse-generation machine that
had Forth as it's only installed language, and all the applications _and the
OS itself - including the crontroller device drivers_ were all written in
Forth! <all together now: EEEEWwwww!> I was the guy who got to "decomission"
that machine...but that machine was running from the late '60s/early '70s
into the mid 1980s...with some serious custom-developed graphical, mapping &
FM applications <oh, guess what we/I migrated all those apps/data/databases
to...? PCs...w/AutoCAD 2.5/2.6...and dBase...>