Dan's reason for wanting Language Stability is flawed.


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 11 of 11

Thread: Dan's reason for wanting Language Stability is flawed.

  1. #1
    Jonathan Allen Guest

    Dan's reason for wanting Language Stability is flawed.

    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





  2. #2
    Jonathan West Guest

    Re: Dan's reason for wanting Language Stability is flawed.


    "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


  3. #3
    Jonathan Allen Guest

    Re: Dan's reason for wanting Language Stability is flawed.

    > 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
    >




  4. #4
    Larry Serflaten Guest

    Re: Dan's reason for wanting Language Stability is flawed.

    "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




  5. #5
    Jonathan Allen Guest

    Re: Dan's reason for wanting Language Stability is flawed.

    > 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
    >
    >
    >




  6. #6
    Robert Lantry Guest

    Re: Dan's reason for wanting Language Stability is flawed.


    "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



  7. #7
    Jonathan West Guest

    Re: Dan's reason for wanting Language Stability is flawed.


    "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


  8. #8
    Jonathan West Guest

    Re: Dan's reason for wanting Language Stability is flawed.


    "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



  9. #9
    Zane Thomas [.NET MVP] Guest

    Re: Dan's reason for wanting Language Stability is flawed.

    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.

  10. #10
    Dan Barclay Guest

    Re: Dan's reason for wanting Language Stability is flawed.

    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)

  11. #11
    Mike Mitchell Guest

    Re: Dan's reason for wanting Language Stability is flawed.

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center