10.1A Progress 4GL Handbook, by John Sadd and Shared Variables - Forum - OpenEdge Development - Progress Community

10.1A Progress 4GL Handbook, by John Sadd and Shared Variables

 Forum

10.1A Progress 4GL Handbook, by John Sadd and Shared Variables

  • I'm skimming John Sadd's OE 4GL handlebook "expert series" (http://www.psdn.com/library/entry.jspa?categoryID=239&externalID=474) and came across this reference on page 14-24:

    The traditional Progress programming technique of using SHARED variables

    Shared variables are a technology fraught with dangers and has long since been obsoleted by other, better technologies in the ABL.

    Why are they still being discussed in any way other than for historical reference?

  • There are almost certainly two or three factors involved in things like this persisting in the documentation.

    One is that a lot of the documentation was written a long time ago when awareness of some best practice standards was not nearly as widely understood as it is today ... not that they are universally understood even now. For any given release, there is substantial work required to update and add new documentation to cover new features, so it is not surprising that there isn't a lot of resources available for going back to material that hasn't changed to see if it can be improved. This is unfortunate in many ways because the code examples in particular often convey approaches which are not best practice, which certainly doesn't help people who are learning the language.

    Another factor is that a set of best practice standards is not well established and universally agreed upon. If there was a Strunk and White for ABL, there would be a reference point, but that doesn't exist. To you and I and a bunch of other people, shared variables are anathema, but there are still a lot of folks out there who think they are perfectly OK ... after all, it a "traditional Progress programming technique".

    And, another factor I think is that PSC seems to be very conscious of the fact that there are a lot of people who are not out at the leading edge, especially if they are sitting on million line bodies of existing code. Since they want to incorporate those people, there is a pattern of saying that one can use OO or not use OO, one can use PDS or one can not use PDS, etc. They don't want to make people feel like they have to change what they are doing in order to move to the latest release. I don't think this pitch is quite clearly focused, however. To be sure, it should be clear to people that they can move to the latest release and it just works. This has long been one of PSC's great strengths and the failure of people to keep moving forward has certainly turned into one of PSC's biggest PITAs. And, clearly they should be provided with guidance on how to make old code and new code work together, something which I think is a bit weak in the current documentation. But, there also should be good guidance in best practices with new features (and what not to use in old features). My impression of the people doing the development on the OO stuff is that they actually have a pretty clear vision, even a bit religious at times. But, this doesn't seem to be making it out in to the examples.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • One is that a lot of the documentation was written a

    long time ago when awareness of some best practice

    standards was not nearly as widely understood as it

    is today ... not that they are universally understood

    even now. For any given release, there is

    substantial work required to update and add new

    documentation to cover new features, so it is not

    surprising that there isn't a lot of resources

    available for going back to material that hasn't

    changed to see if it can be improved.

    I can go with that a few releases, but sooner or later the docs need to be gone over, updated, and cleaned up.

    Another factor is that a set of best practice

    standards is not well established and universally

    agreed upon.

    I personally don't get hung up and worry about "best practice" - there's lots different ways to skin a cat, depending on the variations of what a coder's trying to accomplish, personal quirks, etc. There should be a number of different examples showing different ways to accomplish a given goal, with a description of each one's strengths and shortcomings.

    However - something as outdated as shared variables should be termed "obsolete", "legacy" or something to convey that it's an old way of doing thins. Certainly not "traditional." If going-way-back developers want to use them fine, but they should be moving to other technologies. One doesn't want new developers getting the idea that SVs are anything other than carry-overs from much prior versions of the language.

    To you and I and a bunch of other people, shared

    variables are anathema, but there are still a lot of

    folks out there who think they are perfectly OK ...

    after all, it is a "traditional Progress programming

    technique".

    And so is using include files in lieu of .p's and super procedures, defining multiple static queries as opposed to using dynamic query specifications and the like.

    "Traditional" ways of doing things need to be replaced when better ways of doing things come along.

    And, another factor I think is that PSC seems to be

    very conscious of the fact that there are a lot of

    people who are not out at the leading edge,

    especially if they are sitting on million line bodies

    of existing code.

    They may not be running fully-leading-edge code, but if they're running 10.1 systems, the runtime is leading edge, which means they can use newer, better ways of doing thing. Users should be encouraged to move to more recent, better ways of doing things rather than perpetuating older, obsolete techniques. And the best way to do that is to (a) make it easy for them to do so in the language, and (b) update the docs to point them in that direction.

    To be sure, it should be clear to people that

    they can move to the latest release and it

    just works. This has long been one of PSC's

    great strengths and the failure of people to

    keep moving forward has certainly turned into

    one of PSC's biggest PITAs.

    If it was easier for legacy developers to move things forward, maybe they would.

    And, clearly they should be provided with guidance

    on how to make old code and new code work together,

    something which I think is a bit weak in the current

    documentation.

    Agreed.

    But, there also should be good guidance in best

    practices with new features (and what not to use

    in old features).

    I'd like to see better guidance in how to easily do things now that used to be rather difficult to accomplish in prior versions.

    But, this doesn't seem to be making it out in to the examples.

    Which is unfortunate.

    Tim Kuehn

  • I can go with that a few releases, but sooner or later the docs need to be

    gone over, updated, and cleaned up.

    I agree with you that it is an important goal, but I also recognize that it is not an easy one. If someone on the outside were to go through and make a list of all the bad examples, then it might be manageable to respond to those, but fixing them internally means that someone has to do the scan who would recognize a bad example.

    There should be a number of different examples showing different ways to

    accomplish a given goal, with a description of each one's strengths and

    shortcomings.

    I'm always a fan of showing more options and explaining why one would make choices, but the specific example this thread started with is definitely a best practices issue ... well, or a worst practices issue.

    Wouldn't it be interesting to have a new, separate best practices manual? That might lessen the need to fix all the old stuff.

    And so is using include files in lieu of .p's and super procedures

    Oh, you mean like all of the OERA code examples?

    "Traditional" ways of doing things need to be replaced when better ways of

    doing things come along.

    Like having OERA examples using .cls?

    And the best way to do that is to (a) make it easy for them to do so in the

    language, and (b) update the docs to point them in that direction.

    Which I think includes guidance on how to use .cls in the context of a .p application, which is why I did the whitepaper and code example on how to use a .cls file to replace a session superprocedure which is found at http://www.cintegrity.com/downloads.html ... the doc is full of references about how SPs are like objects, but is missing this piece on how to actually do it.

    If it was easier for legacy developers to move things forward, maybe they would.

    This, to me, is one of the very interesting challenges facing PSC.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Continuing the "Shared" thread - why is the "shared" concept being carried forward with new language elements? For instance, DEFINE [NEW ] DATASET ... and the like?

    This is one place where PSC should not be consistent with other language elements in the ABL.

  • So maybe we should be documenting "worst practices" instead of "best practices"? Just joking, but it is something we've considered.

    The problem is, as long as we do support something, we want to support it consistently. And you think we hear it about continuing old conventions, you should hear what happens when we don't! Some people report it as a critical bug even if we didn't intend to do it!

    Of course, that's one of the balancing points of being in the software game. The solution that's been in my head for awhile is to let users indicate what things in the syntax they don't want to support, sort of a reverse reserved keyword kind of thing.

  • So maybe we should be documenting "worst practices"

    instead of "best practices"?

    I would submit that at the very least archaic outdated methods should not be discussed as "traditional" but "deprecated" or "when nothing better was available".

    >Just joking, but it is

    >something we've considered.

    Not in the 10.1 docs though.

    The problem is, as long as we do support something,

    we want to support it consistently. And you think we

    hear it about continuing old conventions, you should

    hear what happens when we don't! Some people report

    it as a critical bug even if we didn't intend to do

    it!

    I think shared anything should go away as a dangerous, outdated technique. I can understand existing "shared" support remaining in the language, but adding support for shared "stuff" in new technology like PDS???

    Other methods (like "choose") have been deprecated by PSC, but nothing's been suggested to replace it.

    So it's not like PSC hasn't marked things as deprecated before.

  • I agree with you guys on shared variables.

    But in a broader sense, isn't it a good thing Progress is a multi-paradigm language ?

    Take for example, PROMPT-FOR which as I understand is also being deprecated. I'd still like to write REPEAT: PROMPT-FOR, script like programs if I wanted to.

  • Being able to use 'deprecated' langauge elements is one thing. But obsolete if not dangerous techniques shouldn't be listed as examples of how to work with the product's current technology when there are better and safer ways to accomplish the same thing.

  • While I am a great fan of consistency ... a scan of PEG history for the word orthogonal will yield a number of posts on this point ... I think there is an opportunity as the language evolves to find approprate places to move forward.

    We all understand why PSC has chosen to support historical syntax in later versions. That policy has its cost, of course, and I'm not sure that it has entirely fulfilled its purpose, as witness the large number of sites (vast majority?) who remain running on older releases. Nevertheless, we understand.

    But, when moving into new areas, like OO, there is no need to support historical code because there is no historical code. And, there is an opportunity to provide guidance toward good usage. There is no reason to allow for a shared object, especially if you provide guidance for what it is that one does to gain the effect of "shared" without the use of shared. Not only does that provide the programmer new to this area with guidance in the right usage pattern, but it will help to educate him or her on how he or she might rework older code.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Supporting a structure because one knows that it is in wide use doesn't mean that one can't also designate it as deprecated. PSC has certainly done that with some language elements which were (and are) in wide use and I see no reason why shared shouldn't be added to that list.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • It is important to continue to support existing code, at least for a significant period.

    That does not make it a virtue to guide people toward usage which we now recognize as undesireable.

    I know that PSC feels it necessary to "comfort" people who are used to procedural code that it is still a valid paradigm, but that doesn't mean that every verb or modifier needs to be called good.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Of course, that's one of the balancing points of

    being in the software game. The solution that's been

    in my head for awhile is to let users indicate what

    things in the syntax they don't want to support, sort

    of a reverse reserved keyword kind of thing.

    I think developers would like a more expressive grammar for new code constructs like the OO-environment instead of disabling keywords. The new cls-extension was a great possibility to transparantly link cls-sources to a new compiler... I can imagine a file extension that doesn't allow GUI-statements other than tracing.

  • So when is the compiler going to start throwing warnings for deprecated features?

    --
    Tom Bascom
    tom@wss.com

  • Myself, I think having the compiler throw non-fatal warnings would be a bad idea. It would cause people with some code bases to avoid upgrading and it would break a lot of automated build processes. The compiler should be silent unless there is something fatal or a good reason to expect that the code will not perform as intended (like moving colon position).

    We have ProLint for telling us things like the use of deprecated features. Then one gets the warning when one is ready to do something about it.

    What would really be clever would be for PSC to invest in ProRefactor so that it provided a set of rewrite rules for deprecated features.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com