Languages, is popularity dominating engineering?

Dimiter_Popoff wrote:

[%X]

> I also do that - I mark it as "to test" (choice of words must have been
> made in some desperate moment....:-) ).

I never mark code "To Test" because I am able to test each fragment of code 
as soon as I have written it, so I know it will do as I intended very 
quickly. However, my development process will see the code (if meant for 
production) placed under close scrutiny and individual testing to determine 
that it meets all its stated requirements within the defined limits.

> If a single line, this is the sole comment, it is supposed to not
> survive the day.
> If more, I put a comment line "to test"  at the start and an
> "end to test" at the end.
> If I want to leave that code in the source I isolate it with a
> conditional line, like
>   ifeq 0
>   test code
>   endc
> Easy to switch on and off etc. Once or twice I threw away more than
> "to test" code; I felt bad about deleting it (had been rewritten though
> it was not that bad) so I left it after the "end" statement (so the
> compiler/assembler ignores it).... :D .
> 
> I wish I could say I have never found "to test" lines in code working
> and untouched for years though :-).

This sort of statement begs me to ask if you have looked at improving your 
development process.
 
> But my best was to dig deep down to the lowest system call level of
> something which did not work under some circumstances - on a system
> which had been working for years (may be 5, was about 15 years ago).
> After _some_ digging I located it- was an "RTS" (return from subroutine)
> line, comment on it being "until written" :D :D .

Which highlights a lack of robust enough review.

Systems I deal with are usually deeply embedded. I will be highly unlikely 
to see a product again during its operational lifetime (usually 25 years). 
It just has to work properly with minimal chance for maintenance access. For 
one project I am looking at at the moment, the cost of equipment retrieval 
would be a significant portion of £1 million. It would be a disaster to have 
such a retrieval performed for a fault in code that I cannot communicate 
with directly (by design).

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

On 31.12.2014 г. 12:30, Paul E Bennett wrote:
> Dimiter_Popoff wrote:
>
> [%X]
>
>> I also do that - I mark it as "to test" (choice of words must have been
>> made in some desperate moment....:-) ).
>
> I never mark code "To Test" because I am able to test each fragment of code
> as soon as I have written it, so I know it will do as I intended very
> quickly.

Well in the world I live in I have to test how things work sometimes.
To test if the hardware responds in the way I expect it to, to see how
execution times are influenced by this or that - on pipelined machines
you just have no other option but "to test" etc. etc.
The correct choice of words of course would have been "while debugging"
but many years ago I chose "to test" instead - and now I am used to
search for it etc.
If you have understood this as "code yet to be tested" you have
misunderstood it completely.

> However, my development process will see the code (if meant for
> production) placed under close scrutiny and individual testing to determine
> that it meets all its stated requirements within the defined limits.

So how do you deal with code you add to 5 or more years after you
wrote it. Say you add a new system call to the OS or new functionality
to an existing one.

>> If a single line, this is the sole comment, it is supposed to not
>> survive the day.
>> If more, I put a comment line "to test"  at the start and an
>> "end to test" at the end.
>> If I want to leave that code in the source I isolate it with a
>> conditional line, like
>>    ifeq 0
>>    test code
>>    endc
>> Easy to switch on and off etc. Once or twice I threw away more than
>> "to test" code; I felt bad about deleting it (had been rewritten though
>> it was not that bad) so I left it after the "end" statement (so the
>> compiler/assembler ignores it).... :D .
>>
>> I wish I could say I have never found "to test" lines in code working
>> and untouched for years though :-).
>
> This sort of statement begs me to ask if you have looked at improving your
> development process.

I have - and I would put the robustness of my code against anyones
any day you choose. But your statement is probably because of your
wrong interpretation of what my "to test" means, as explained above.

>> But my best was to dig deep down to the lowest system call level of
>> something which did not work under some circumstances - on a system
>> which had been working for years (may be 5, was about 15 years ago).
>> After _some_ digging I located it- was an "RTS" (return from subroutine)
>> line, comment on it being "until written" :D :D .
>
> Which highlights a lack of robust enough review.

I would say it highlights the fact that we are talking about different
worlds.

> Systems I deal with are usually deeply embedded.

I call these "tiny software efforts" (a few hundreds of kilobytes
sources) which take up to 6 months of my time. I do not do many of
them but I have done several over the past 25 years; none of them
has ever malfunctioned because of its firmware, in fact I cannot
recall witnessing a COP watchdog reset occurrence on any of these.

The event I described was meant also to demonstrate why comments
are a necessity. Without that comment I would have had to look at
plenty of other code to grasp why the system call just returns
under these conditions; the "until written" showed me immediately
that I have left this for later, when I need it. I do not remember
exactly what it was, I think it was something in the file system,
may have had to do with setting the file position on certain
file types if my memory is correct on where it was, but it
was certainly nothing interfering with the proper work of the
system - until some application wanted to go exactly
there - which happened some 5 years later, my comment helped me
remember what and why and that was that.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

Hi Dimiter,

On 12/31/2014 6:23 AM, Dimiter_Popoff wrote:

[taken out of context...]

> The correct choice of words of course would have been "while debugging"
> but many years ago I chose "to test" instead - and now I am used to
> search for it etc.

I find this an extremely good discipline:  leaving explicit "marks"
in the code when you *know* you aren't finished with it.  Sure, "Unit"
and "Final Test" will eventually catch these things (*if* the test suites
are well built).  But, it is a big productivity enhancer to get in the
habit of leaving specific "tags" in your code as you are working on
it -- as a reminder/marker to come back to it later.

I.e., we *all* get pulled away from our work from time to time.
Whether it is to address some entirely different matter (boss has
an urgent project that needs your attention; washing machine is
leaking; etc.) *or* just a natural consequence of the development
process (you chase down some other aspect of the code and forget
that you've got unfinished business where you started!).

"XXX FIXME" is a common flag.  You can grep your source tree for
"FIXME" and quickly find all instances.  Historically, I've used my
initials to tag things that are "me-specific".  But, that also
causes lots of hits on notes that I'd tagged with them (on sources
shared with other developers... i.e., "ask Don for further details")

In *no* case should the string "FIXME" appear in sources at release
time -- a crude test to ensure you've not violated process!

Dimiter_Popoff wrote:

> On 31.12.2014 г. 12:30, Paul E Bennett wrote:
>> Dimiter_Popoff wrote:
>>
>> [%X]
>>
>>> I also do that - I mark it as "to test" (choice of words must have been
>>> made in some desperate moment....:-) ).
>>
>> I never mark code "To Test" because I am able to test each fragment of
>> code as soon as I have written it, so I know it will do as I intended
>> very quickly.
> 
> Well in the world I live in I have to test how things work sometimes.
> To test if the hardware responds in the way I expect it to, to see how
> execution times are influenced by this or that - on pipelined machines
> you just have no other option but "to test" etc. etc.
> The correct choice of words of course would have been "while debugging"
> but many years ago I chose "to test" instead - and now I am used to
> search for it etc.
> If you have understood this as "code yet to be tested" you have
> misunderstood it completely.

In which case I misunderstood your post. I had, in fact, read it as "code 
yet to be tested".

>> However, my development process will see the code (if meant for
>> production) placed under close scrutiny and individual testing to
>> determine that it meets all its stated requirements within the defined
>> limits.
> 
> So how do you deal with code you add to 5 or more years after you
> wrote it. Say you add a new system call to the OS or new functionality
> to an existing one.

With the types of systems I deal with, that is a very rare occurrence. More 
likely I shall be developing a completely new system based on the old specs 
with some new additions. I can re-use some code, but the code I re-use is 
from a library of former production grade code that is fully documented (and 
certified) on a "Component by Component" basis. This applies to the smallest 
portion through to the whole former application. Even in re-use we go 
through the certification procedures to ensure that the re-use is fully 
validated.

When dealing with new and un-tried hardware I have prototyping code that is 
at a reasonable standard but not considered for production quality code. 
This code is used to gain better information about the hardware interface 
and ensure that the full details and behaviour are known and documented. 
This document then becomes the specification, fully reviewed and HAZOP'd to 
ensure that the requirements comply with the quality needed to proceed to 
coding. Generating production code from here (or deciding to use library 
code) will be fairly straight-forward complete with appropriate guards and 
assertions in place.

[%X]

>>> I wish I could say I have never found "to test" lines in code working
>>> and untouched for years though :-).
>>
>> This sort of statement begs me to ask if you have looked at improving
>> your development process.
> 
> I have - and I would put the robustness of my code against anyones
> any day you choose. But your statement is probably because of your
> wrong interpretation of what my "to test" means, as explained above.

I think we are clear on my misunderstanding of your post now.
 
>>> But my best was to dig deep down to the lowest system call level of
>>> something which did not work under some circumstances - on a system
>>> which had been working for years (may be 5, was about 15 years ago).
>>> After _some_ digging I located it- was an "RTS" (return from subroutine)
>>> line, comment on it being "until written" :D :D .
>>
>> Which highlights a lack of robust enough review.
> 
> I would say it highlights the fact that we are talking about different
> worlds.

Probably. My world is that of "Safety Critical Systems", usually in quite 
harsh environments. 
 
>> Systems I deal with are usually deeply embedded.
> 
> I call these "tiny software efforts" (a few hundreds of kilobytes
> sources) which take up to 6 months of my time. I do not do many of
> them but I have done several over the past 25 years; none of them
> has ever malfunctioned because of its firmware, in fact I cannot
> recall witnessing a COP watchdog reset occurrence on any of these.

In which case we have similar in-use experiences.
 
> The event I described was meant also to demonstrate why comments
> are a necessity. Without that comment I would have had to look at
> plenty of other code to grasp why the system call just returns
> under these conditions; the "until written" showed me immediately
> that I have left this for later, when I need it. I do not remember
> exactly what it was, I think it was something in the file system,
> may have had to do with setting the file position on certain
> file types if my memory is correct on where it was, but it
> was certainly nothing interfering with the proper work of the
> system - until some application wanted to go exactly
> there - which happened some 5 years later, my comment helped me
> remember what and why and that was that.

On the necessity for comments we are in full agreement. My source code 
includes the statement of requirements for each and every sub-routine, 
written before the code is generated. The review performs Fagan Style Static 
Inspection, Functional Testing with 100% logical path coverage and Limits 
Testing (this latter testing regime is real stress testing of the sub-
routine featuring beyond specification input stimuli). In my development 
process I am aiming at the "Correct by Construction" goal that is beyond 
CMMI Level 5.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

On 01/01/15 02:52, Don Y wrote:
> Hi Dimiter,
>
> On 12/31/2014 6:23 AM, Dimiter_Popoff wrote:
>
> [taken out of context...]
>
>> The correct choice of words of course would have been "while debugging"
>> but many years ago I chose "to test" instead - and now I am used to
>> search for it etc.
>
> I find this an extremely good discipline:  leaving explicit "marks"
> in the code when you *know* you aren't finished with it.  Sure, "Unit"
> and "Final Test" will eventually catch these things (*if* the test suites
> are well built).  But, it is a big productivity enhancer to get in the
> habit of leaving specific "tags" in your code as you are working on
> it -- as a reminder/marker to come back to it later.
>
> I.e., we *all* get pulled away from our work from time to time.
> Whether it is to address some entirely different matter (boss has
> an urgent project that needs your attention; washing machine is
> leaking; etc.) *or* just a natural consequence of the development
> process (you chase down some other aspect of the code and forget
> that you've got unfinished business where you started!).
>
> "XXX FIXME" is a common flag.

It doesn't matter what flag you use, as long as you check it.

But really, a thorough test system should create every situation where 
an assertion fails, and you should also use a "test_pending" assertion 
that reports any pending (incomplete) implementation in your test 
report, the same way you should report tests that are currently known to 
be failing (fix_pending in the test itself).

Comments in the code are a poor substitute for contingencies reported in 
the test results.

Hi Clifford,

On 12/31/2014 11:14 PM, Clifford Heath wrote:
> On 01/01/15 02:52, Don Y wrote:
>> On 12/31/2014 6:23 AM, Dimiter_Popoff wrote:
>>
>> [taken out of context...]
>>
>>> The correct choice of words of course would have been "while debugging"
>>> but many years ago I chose "to test" instead - and now I am used to
>>> search for it etc.
>>
>> I find this an extremely good discipline:  leaving explicit "marks"
>> in the code when you *know* you aren't finished with it.  Sure, "Unit"
>> and "Final Test" will eventually catch these things (*if* the test suites
>> are well built).  But, it is a big productivity enhancer to get in the
>> habit of leaving specific "tags" in your code as you are working on
>> it -- as a reminder/marker to come back to it later.
>>
>> I.e., we *all* get pulled away from our work from time to time.
>> Whether it is to address some entirely different matter (boss has
>> an urgent project that needs your attention; washing machine is
>> leaking; etc.) *or* just a natural consequence of the development
>> process (you chase down some other aspect of the code and forget
>> that you've got unfinished business where you started!).
>>
>> "XXX FIXME" is a common flag.
>
> It doesn't matter what flag you use, as long as you check it.

... withing reason.  E.g., "XXX" has proven to be a *lousy* flag, IME.
It appears in too many other instances "legitimately".  OTOH, "FIXME"
only seems to have application to indicate something that "needs to
be fixed".

> But really, a thorough test system should create every situation where an
> assertion fails, and you should also use a "test_pending" assertion that
> reports any pending (incomplete) implementation in your test report, the same
> way you should report tests that are currently known to be failing (fix_pending
> in the test itself).
>
> Comments in the code are a poor substitute for contingencies reported in the
> test results.

Note that "FIXME" doesn't imply that the code is broken or will fail the
functional tests!  It could indicate the commentary for some portion of
code needs to be cleaned up.  Or, the code itself may be "ugly".  Or,
the algorithm chosen is less than ideal for the circumstances -- with
undesirable time/space costs.  Or, the tag may appear in a "disabled"
code stanza.  Yet, none of these things preclude passing an exhaustive
test suite!

E.g., my gesture recognizer has many such instances scattered throughout
it (though it's not released code so "that's OK"  :> ).  Places where
I can exploit some specific knowledge to short-cut large portions of an
"equivalent" algorithm (but haven't yet had time to implement).

However, IMO, it is "bad form" to release code with such "notes" in it.
It's as if you've not truly "finished", yet.

(OTOH, it is surprising how often you encounter this in released sources!)

On Friday, December 26, 2014 2:18:15 AM UTC-5, Don Y wrote:
> Hi Ed,
> 
[] 
> <grin>  Trust me, my memory is *not* significantly above average!  :>  At
> this point in my career, I'm approaching the "Kelly Bundy" point (i.e., every
> new datum forces an old one *out*!)

I'm there too!
> 
> OTOH, I don't need to leave notes to tell me how a binary search works!
> But, I *may* need a note to explain why I chose that search algorithm
> for *this* data set instead of another approach.  That sort of detail
> is likely *not* evident "in the code" but, rather, "in the application".

Yes
> 
[]
> 
> > what information will I need if I have to fix a problem in the code 6 months
> > from now? That's what drives the comments.
> >
> > If I would need that information, then I am sure another maintenance
> > programmer will need it even more!
> 
> But, then you're assuming another maintenance programmer will *start* with
> the same level of familiarity with the algorithm, purpose, etc. that *you*
> bring BACK to it.

True.
[]
> 
> E.g., any application-specific knowledge isn't likely to magically come
> with that new set of eyes.  Nor are *you* guaranteed to remember it some
> time later -- even though it seems second-nature to you *now* (because of
> your overexposure to it).

Exactly. I think that is what I said.
> 
> Writing good/effective comments is tough because you want to avoid
> saying something "obvious" -- yet *ensure* you say everything that's
> *necessary*.  An *objective* judgement call is required of you despite
> your very *subjective* experience with the subject matter:  "What would
> SOMEONE ELSE consider as 'necessary'?"
>
This is exactly the crux of the matter. 

> One of the most sickening feelings (to me) is looking at some of *my*
> code and wondering "why the hell is it written THIS way?"  (i.e., when
> there are obviously *better* ways to have done it!).
> 
I do that almost regularly. It seems a consequence of experience.

[]
> 
> [OTOH, the choice of "naive/trivial" search algorithm may merit some
> explanation:  "Why are you doing this so LAMELY when there are more
> effective ways of doing it?"  Ans:  look at the number of templates
> involved; what are you going to *save*?  what will that *cost* you??]
> 
> As I've said, "software engineering" is really missing a tool/mechanism
> to more effectively "explain" what it is trying to do.  Either a more
> expressive language (we've seen countless attempts at this and none seem
> to really hit the mark -- in an application-domain neutral way!) *or*
> a way of easily augmenting "code" with "description/explanation".
> 
> The question then becomes:  what do you do while we're waiting for that
> "solution"?

Yes. I don't know what the solution is. We can for now only try to be smart about our comment habits.

One thing I realized is that outside documentation is still so limited. but that is another topic.

I think Don we really are on the same page.

On Saturday, December 27, 2014 12:28:24 AM UTC-5, Paul Rubin wrote:
> Ed Prochak <edprochak@gmail.com> writes:
> >> A few years ago there was a company seeking PDP-11 assembler competent
> >> person to maintain and train new persons for their spent fuel rod
> >> basin until 2050.
> > BUT if I was looking at that job, one of my first actions would be to
> > present a migration plan to newer hardware/software.... Or at least
> > asking: why are you running such an ancient system?
> 
> They run those PDP-11's because the amount of regulatory approval and
> pain needed to change even the slightest part of a nuclear reactor
> installation would be much more expensive than keeping the 11's running
> until the reactor is decomissioned in 2050.

A strong answer in this case.

 I have seen others not having such good answers,
 including cases of "we never thought of that."

But even that case, the hardware will be another 35 years older!
 I think a good case can be made that just parts availability will
 increase risk of staying with that hardware over the costs of
 certificating new hardware and software.
Otherwise, I hope they have a large stock of spares!

Whether the higher ups agree is another question, but I would
consider it my responsibility to present the alternatives.

Hi Ed,

On 1/4/2015 2:01 PM, Ed Prochak wrote:

>> As I've said, "software engineering" is really missing a tool/mechanism to
>> more effectively "explain" what it is trying to do.  Either a more
>> expressive language (we've seen countless attempts at this and none seem
>> to really hit the mark -- in an application-domain neutral way!) *or* a
>> way of easily augmenting "code" with "description/explanation".
>>
>> The question then becomes:  what do you do while we're waiting for that
>> "solution"?
>
> Yes. I don't know what the solution is. We can for now only try to be smart
> about our comment habits.

But that only extends to the point at which the code leaves *your* (our)
hands!  The next mutton-head can make all your efforts for naught (e.g.,
REMOVING your comments from the code in lieu of having to UPDATE them to
reflect his/her changes).

I *expect* (hysterical raisons) folks to be lazy and not disciplined enough
to keep documentation up to snuff.  So, I've tried hard to make the "easy
path" the "right path" for those folks.  I.e., so that it is easier for them to
fit within the framework I've laid out than to circumvent it (which leads to
its inevitable deterioration).

E.g., the test-to-sound rules in two of my speech synthesizers are basically
simple pattern matching algorithms:  *this* combination of letters leads to
*these* sounds.  Hysterically, these sounds were represented by combinations
of ASCII letters (because the special symbology of the phonetic alphabets
were not available).

So, vowels might be encoded like "AY", "OW", "IY", "UW", etc.

To someone not "skilled in the art", it is way too easy to misread these
graphemes and subconsciously translate them into the WRONG sounds.  For
example, "hay" (i.e., dead grass) is phonetically "HH EY".  By contrast,
the phonetic representation "HH AY" is "Hi!" (or high).

Rather than risk someone making a "careless error" in marking up the
code -- or, failing to update the commentary accordingly -- I have
taken an approach that makes it very hard for folks to modify the
rule encodings (it's not a trivial process due to the efficiency
required of the algorithms).

Instead, I have a *document* that describes the algorithm and enumerates
the rules (large tables).  In those rules, each sound is represented by a
special "phonetic" symbol (this is potentially ambiguous as there are many
symbologies developed over the years to represent specific sounds).
So, that "AY" really appears as an 'ai' glyph... where the two "letters"
are crammed together in much the same way you would see "ae" in the
spelling of encyclopAEdia; the "HH" as 'h'; the "EY" as 'e'; "OY" as
a small caps IC rotated 180 degrees; etc.

The point of this is to remind the reader (who is also the guy opting
to hack the code!) that these aren't "letters" but "sounds".  Additionally,
examples of each sound in "common English" words are presented.  And, finally,
actual *recordings* of the sounds from the synthesizer.  I.e., THIS symbol
makes THAT sound!

The developer updates the tables in this (~50pp) document using the symbols
that are present in the document.  *THEN*, a tool that I wrote extracts the
tables from the document and builds the "include" file for the executable.

Of course, there is no guarantee that the future developer will NOT change the
algorithm and fail to update all of the PROSE in the document.  But, if he
changes the algorithm so that the encoding of the ruleset is altered, he'll
have to rewrite the tool that parses the document as well.  At that level
of involvement, he would probably opt to just discard the document entirely
and develop some alternative scheme ("Hey!  Let's use 'AY' for the 'eye' sound,
and 'EY' for the 'ay' sound, and...")

My point:  make it easy for folks to make changes that remain consistent
with the documentation and discourage them from those changes that would
result in the comments being invalidated (or elided!)

> One thing I realized is that outside documentation is still so limited. but
> that is another topic.
>
> I think Don we really are on the same page.

Which is why I elided so much of your response, here.  I really don't see a
GOOD answer.  All the effort "spent" on novelty languages over the last 50
years with very little result in terms of embedding semantic content in
the languages developed in a "humanistic" way...  :<

On Fri, 26 Dec 2014 21:28:21 -0800, Paul Rubin
<no.email@nospam.invalid> wrote:

>Ed Prochak <edprochak@gmail.com> writes:
>>> A few years ago there was a company seeking PDP-11 assembler competent
>>> person to maintain and train new persons for their spent fuel rod
>>> basin until 2050.
>> BUT if I was looking at that job, one of my first actions would be to
>> present a migration plan to newer hardware/software.... Or at least
>> asking: why are you running such an ancient system?
>
>They run those PDP-11's because the amount of regulatory approval and
>pain needed to change even the slightest part of a nuclear reactor
>installation would be much more expensive than keeping the 11's running
>until the reactor is decomissioned in 2050.

In practice, it makes sense to recertify upgraded new systems every 20
years if your intention is to run the plant for 40-100 years.
Especially the RoHS makes maintaining a spare part inventory quite
hard.