Dan's reason for wanting Language Stability is flawed.

[Jonathan Allen]

This clam is harsh, but honest. I believe I can show that Dan has not
seriously considered his position.

First the definition of language stability.

"Language refers to the core language of a development system as opposed to
the product itself. That is, the core syntax and behavior of written code.
Excluded from this term is functionality that changes in character with
operating system or platform context (many API functions and user interface
functions). That is not to say that Product Stability is not important, only
that the discussion here regards Language Stability"

"The end result of a stable language is that a Module from one release will
compile and run correctly in the next release provided only that the Module
is restricted to core functionality (no platform specific API's or UI but
otherwise any code in any Procedure)."

Now, the reason why it is important.

"Completed Code is an asset to the Application or Library Owner. The source
language is the container for that asset."

There is a fundamental flaw here. The code is an asset. However, code
depends on both the language and the API. If the API is changed, then the
code will not work. And thus, its value as an asset is lost.

In conclusion, his argument is flawed because he is only considering the
syntax of the language. In order to discuss code as an asset, the stability
of both the language and all its dependencies must be considered.


--
Jonathan Allen

[Jonathan West]

"Jonathan Allen" <greywolfghost@cox.net> wrote in message
news:3c89dd90@10.1.10.29...

> In conclusion, his argument is flawed because he is only considering the
> syntax of the language. In order to discuss code as an asset, the
stability
> of both the language and all its dependencies must be considered.

I don't agree with this statement. To take a simple example, when VBA-based
versions of Office were ported to the Mac, I didn't expect VBA code that
used Windows API calls would work when moved across.

The case is perhaps more arguable with optional components such as ADO.
However I would regard ADO as a platform component rather than a language
component, since it is equally available to several different languages.
However, if you wanted to extend the principles of LS to the effect of
changes in such components on the syntax of the source code in applications
that access them, I would have no particular difficulty with that concept.

However, since you have reached this point, what alternative suggestion do
you have? Specifically:

1. What do you think of as the purpose of Language Stability?

2. What processes would you regard as necessary and sufficient to achieve
that purpose?

Let's see if we can be proactive and forward-looking on the subject.

--
Regards
Jonathan West

[Jonathan Allen]

> I don't agree with this statement. To take a simple example, when
VBA-based
> versions of Office were ported to the Mac, I didn't expect VBA code that
> used Windows API calls would work when moved across.

Lets say you write a bunch of code in Windows Office. Your company then
switches to Mac Office.

The VBA langauge has not been changed. So acording to Dan's Language
Stability theory, your code still has a value.

Under my theory, you also have to looks at the code's dependancies. If your
code depends on something that doesn't exist in the new system, then it has
lost its value. That dependancy may be a Win32 API call, a COM component, or
just a feature in Windows Office that Mac Office doesn't have.

In order to maintain the value of your code as an asset, the language it is
written in as well as all its dependancies must be stable. Change any piece,
and the whole things falls apart.


> 1. What do you think of as the purpose of Language Stability?

By it self, all it does is reduce the need for retraining.

> 2. What processes would you regard as necessary and sufficient to achieve
> that purpose?

Retraining occus all the time, so I am not overly concerned with it.

***********************

As for code as an asset, there are two ways to protect it.

1. Everything, not just the core langauge, must be stable.

OR

2. Allow the old version to run side-by-side with the new version. Include
interoperability layers if necessary.

I perfer method 2, as method 1 locks us into bad choices.


--
Jonathan Allen


"Jonathan West" <jwest@mvps.org> wrote in message
news:3c8b583f$1@10.1.10.29...
>
> "Jonathan Allen" <greywolfghost@cox.net> wrote in message
> news:3c89dd90@10.1.10.29...
>
> > In conclusion, his argument is flawed because he is only considering the
> > syntax of the language. In order to discuss code as an asset, the
> stability
> > of both the language and all its dependencies must be considered.
>
> I don't agree with this statement. To take a simple example, when
VBA-based
> versions of Office were ported to the Mac, I didn't expect VBA code that
> used Windows API calls would work when moved across.
>
> The case is perhaps more arguable with optional components such as ADO.
> However I would regard ADO as a platform component rather than a language
> component, since it is equally available to several different languages.
> However, if you wanted to extend the principles of LS to the effect of
> changes in such components on the syntax of the source code in
applications
> that access them, I would have no particular difficulty with that concept.
>
> However, since you have reached this point, what alternative suggestion do
> you have? Specifically:
>
> 1. What do you think of as the purpose of Language Stability?
>
> 2. What processes would you regard as necessary and sufficient to achieve
> that purpose?
>
> Let's see if we can be proactive and forward-looking on the subject.
>
> --
> Regards
> Jonathan West
>

[Larry Serflaten]

"Jonathan West" <jwest@mvps.org> wrote
> 1. What do you think of as the purpose of Language Stability?

What people talk about when they mention stability, is what I would call
Language Endurance. The ability a language to remain unchanged through
successive versions, adding only new items, and not changing from prior
performance. Language stability actually should be used (IMHO) within
a single version to denote that the commands provided perform exactly
the same way, whenever they are used. VB would not be stable because
of commands like Dir that are effected in their operation, on a global scale
and/or scope.

> 2. What processes would you regard as necessary and sufficient to achieve
> that purpose?

For LS, it is really pretty simple, provide detailed documentation that acurately
reflects the runtime behaviour of each command. No variation from the docs
is allowed, meaning the docs have to be complete and conclusive.

For LE, it is pretty well spelled out, no changes are allowed except to add more
functionality. But may be too rigid for languages that, in some cases, need to evolve.

>
> Let's see if we can be proactive and forward-looking on the subject.

It is rather hard to be optimistic in this field that has been dominated by MS, who
in normal practise, send out bug laden software. Then, they cover their asses by
lengthy EULAs in legal speak that essentially says the customer has to purchase the
media containing the software, but they do not own the software, nor is MS
responsible if there is anything wrong with the software. What other business or
manufacturer (industry) can get away with that?

LFS

[Jonathan Allen]

> Then, they cover their asses by
> lengthy EULAs in legal speak that essentially says the customer has to
purchase the
> media containing the software, but they do not own the software, nor is MS
> responsible if there is anything wrong with the software. What other
business or
> manufacturer (industry) can get away with that?

That is a different issue entirely, though definitely worth discussing.

--
Jonathan Allen


"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:3c8bc6ac@10.1.10.29...
> "Jonathan West" <jwest@mvps.org> wrote
> > 1. What do you think of as the purpose of Language Stability?
>
> What people talk about when they mention stability, is what I would call
> Language Endurance. The ability a language to remain unchanged through
> successive versions, adding only new items, and not changing from prior
> performance. Language stability actually should be used (IMHO) within
> a single version to denote that the commands provided perform exactly
> the same way, whenever they are used. VB would not be stable because
> of commands like Dir that are effected in their operation, on a global
scale
> and/or scope.
>
> > 2. What processes would you regard as necessary and sufficient to
achieve
> > that purpose?
>
> For LS, it is really pretty simple, provide detailed documentation that
acurately
> reflects the runtime behaviour of each command. No variation from the
docs
> is allowed, meaning the docs have to be complete and conclusive.
>
> For LE, it is pretty well spelled out, no changes are allowed except to
add more
> functionality. But may be too rigid for languages that, in some cases,
need to evolve.
>
> >
> > Let's see if we can be proactive and forward-looking on the subject.
>
> It is rather hard to be optimistic in this field that has been dominated
by MS, who
> in normal practise, send out bug laden software. Then, they cover their
asses by
> lengthy EULAs in legal speak that essentially says the customer has to
purchase the
> media containing the software, but they do not own the software, nor is MS
> responsible if there is anything wrong with the software. What other
business or
> manufacturer (industry) can get away with that?
>
> LFS
>
>
>

[Robert Lantry]

"Larry Serflaten" <serflaten@usinternet.com> wrote:

>media containing the software, but they do not own the software, nor is
MS
>responsible if there is anything wrong with the software. What other business
or
>manufacturer (industry) can get away with that?
>
>LFS

Yikes! Not to put too fine a point on it, but have you ever worked with
or for a goverment agency? How about a government contractor? :P

[Jonathan West]

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:3c8bc6ac@10.1.10.29...
> "Jonathan West" <jwest@mvps.org> wrote
> > 1. What do you think of as the purpose of Language Stability?
>
> What people talk about when they mention stability, is what I would call
> Language Endurance. The ability a language to remain unchanged through
> successive versions, adding only new items, and not changing from prior
> performance.

Well, today, we are talking about what you describe as Language Endurance,
and everyone else is using the term Language Stability for.

>Language stability actually should be used (IMHO) within
> a single version to denote that the commands provided perform exactly
> the same way, whenever they are used. VB would not be stable because
> of commands like Dir that are effected in their operation, on a global
scale
> and/or scope.

We can talk about global effect of functions and unintentional coupling
between routines another time. You might want to start a fresh thread on
this. It's a worthwhile topic.

>
> > 2. What processes would you regard as necessary and sufficient to
achieve
> > that purpose?
>
> For LE, it is pretty well spelled out, no changes are allowed except to
add more
> functionality. But may be too rigid for languages that, in some cases,
need to evolve.

The interesting thing is that you are describing a position that is actually
more rigid than Dan's proposals. Dan's proposals at least allow
functionality to be dropped under certain defined circumstances.

--
Regards
Jonathan West

[Jonathan West]

"Jonathan Allen" <greywolfghost@cox.net> wrote in message
news:3c8bc4ee$1@10.1.10.29...
> > I don't agree with this statement. To take a simple example, when
> VBA-based
> > versions of Office were ported to the Mac, I didn't expect VBA code that
> > used Windows API calls would work when moved across.
>
> Lets say you write a bunch of code in Windows Office. Your company then
> switches to Mac Office.
>
> The VBA langauge has not been changed. So acording to Dan's Language
> Stability theory, your code still has a value.

The value of the code depends on the extent to which it will run without
modification in Mac Office.

>
> Under my theory, you also have to looks at the code's dependancies. If
your
> code depends on something that doesn't exist in the new system, then it
has
> lost its value. That dependancy may be a Win32 API call, a COM component,
or
> just a feature in Windows Office that Mac Office doesn't have.
>
> In order to maintain the value of your code as an asset, the language it
is
> written in as well as all its dependancies must be stable. Change any
piece,
> and the whole things falls apart.

Well, it depends on how much of the code is affected. It's not an
all-or-nothing question. If only a small part of the code makes use of a
specific API feature, than only the value of that small part is affected. If
a core language component changes, such that the behaviour of all your code
can no longer be relied on, then the value of all the code is affected.

Of course, the extent to which the value of a company's code is affected by
a change depends on what their application does, and what coding choices
have been made by the programmers when writing it.

The problem from the point of view of the language designers is that there
is no way of knowing which unforeseen ways of using the language become
popular.
>
>
> > 1. What do you think of as the purpose of Language Stability?
>
> By it self, all it does is reduce the need for retraining.

Retraining? That is all?

Do you think that the effort involved in rewriting applications (or parts
thereof) to behave correctly in a new version of a language has a cost?

Does the avoidance of that cost give rise to an expression of value in the
code?

>
> > 2. What processes would you regard as necessary and sufficient to
achieve
> > that purpose?
>
> Retraining occus all the time, so I am not overly concerned with it.
>
> ***********************
>
> As for code as an asset, there are two ways to protect it.
>
> 1. Everything, not just the core langauge, must be stable.
>
> OR
>
> 2. Allow the old version to run side-by-side with the new version. Include
> interoperability layers if necessary.
>
> I perfer method 2, as method 1 locks us into bad choices.

Method 2 is simply a way of describing the possibility that a new language
can exist alongside an old one. It doesn't say anything about the stability
of the old language.

Presumably, by this principle, you would have no difficulty with the idea
that for instance, Microsoft might decide for VB.NET 2.0 that the InStr
function should be changed, so that it returns the number of characters to
the left of the start of the found string, and returns an error if the
search string is not found. Also, the Start parameter should be optional and
zero-based, and so should be moved in the order of parameters after the two
strings, to match the format of InStrRev. After all, everything should be
zero referenced, and it is not clean design to use a return value of zero
indicate an
exception condition. Microsoft would decide InStrRev should also be made
zero-based in the same way. After all, it would clean up the language to
eliminate the anomaly of two such similar functions operating in different
ways.

Almost all of your code would need to be revisited after such a change.

If I understand you correctly, as you can run VB.NET 2.0 alongside VB.NET
1.0, you would regard such a change as being of little account from a
language stability point of view - you can always retrain.

Is this what you meant?

--
Regards
Jonathan West

[Zane Thomas [.NET MVP]]

On Sat, 9 Mar 2002 02:06:50 -0800, "Jonathan Allen"
<greywolfghost@cox.net> wrote:

>This clam is harsh

But will it make good chowder?


--
When freedom is outlawed
only outlaws will be free.

[Dan Barclay]

On Sat, 9 Mar 2002 02:06:50 -0800, "Jonathan Allen"
<greywolfghost@cox.net> wrote:

>This clam is harsh, but honest. I believe I can show that Dan has not
>seriously considered his position.

Yes, I have seriously considered it. The whole issue is a difficult
concept to explain assuming folks don't just "get it" on their own.

>"Completed Code is an asset to the Application or Library Owner. The source
>language is the container for that asset."

Do you look at it some other way?

>There is a fundamental flaw here. The code is an asset. However, code
>depends on both the language and the API. If the API is changed, then the
>code will not work. And thus, its value as an asset is lost.

Huh? Where did I say that? In fact, I said:

"Code that can be isolated from the outside world, in theory, need
never be changed once it is written and tested. Functionality
requiring access to the “outside world” (including user interfaces, OS
interfaces, etc.) is provided with wrapper functions containing
interface code such that even significant platform changes are managed
by replacing only the interface wrappers."

That is, if you need to do something that requires an API call, you do
that with your own function. When the API changes you just change the
wrapper function.

>In conclusion, his argument is flawed because he is only considering the
>syntax of the language. In order to discuss code as an asset, the stability
>of both the language and all its dependencies must be considered.

You have a good point here regarding *overall* compatibility and I
don't want to detract from it. At the same time the paper I wrote
explicitly restricted the discussion to Language Stability (LS) as
opposed to overall Product Stability. LS is most critical simply
because you can't have Product Stability without LS but I did not
intend to imply that Product Stability was not important. If I left
that impression I will correct it.

Perhaps some discussion is appropriate on Product Stability.
Certainly it would help me to have it as well. Still, without a
stable language it has no meaning.

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

[Mike Mitchell]

On Sun, 10 Mar 2002 15:05:30 -0600, "Larry Serflaten"
<serflaten@usinternet.com> wrote:

> What other business or
>manufacturer (industry) can get away with that?

I don't think they or other software producers will be permitted to
get away with it for much longer. It is ludicrous that software be
treated in such cavalier a fashion when all other industries are
regulated to the hilt. And as more and more software of dubious
parentage finds its way into handhelds, tablets, and your fridge, all
places where a bug could be actually fatal to users -- think GPS and
the alligators in Florida -- think GPS and the schoolkids led astray
on an expedition -- think smart drug dispensers that dispense a little
too much (or little) -- think the bike that suddenly disengages its
chain when you're nearing 40 mph downhill -- once people really start
using software in a wider spread of everyday apps, they'll start to
ask questions about what the vendors actually deem themselves to be
responsible for if more than absolutely nothing.

Then government will step in and regulate. It's going to happen, and
probably within the next five years. If it doesn't, the world will be
full of half-finished, buggy, unreliable software. Oops, sorry! That's
what it's like already!

MM