Rocksolid Light

Welcome to RetroBBS

mail  files  register  newsreader  groups  login

Message-ID:  

21 May, 2024: Computers section is temporarily disabled for maintenance. It will take several days before it's back.


computers / comp.arch.embedded / Re: (Semi-) formal methods

Re: (Semi-) formal methods

<s9a5h3$pj9$1@dont-email.me>

  copy mid

https://www.rocksolidbbs.com/computers/article-flat.php?id=489&group=comp.arch.embedded#489

  copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: blockedofcourse@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: (Semi-) formal methods
Date: Thu, 3 Jun 2021 01:56:53 -0700
Organization: A noiseless patient Spider
Lines: 229
Message-ID: <s9a5h3$pj9$1@dont-email.me>
References: <s7fara$f23$1@dont-email.me>
<167f224f71eaadb2$1$2112880$6edd646a@news.thecubenet.com>
<s7nk3b$d0m$1@dont-email.me>
<167f2f5a945a8023$1$2262039$72dd786b@news.thecubenet.com>
<s7o35m$sfi$1@dont-email.me>
<167f3814b72711a5$1$1356503$70dd7a6b@news.thecubenet.com>
<s7p79m$uim$1@dont-email.me>
<167f68816b02e386$1$1356503$70dd7a6b@news.thecubenet.com>
<s7qi0g$413$1@dont-email.me>
<1684a19157d3c812$1$2262039$72dd786b@news.thecubenet.com>
<s974lf$vm4$1@dont-email.me>
<1684c4474360859e$1$1356503$70dd7a6b@news.thecubenet.com>
<s98a13$ml4$1@dont-email.me>
<1684efaa7b1ce4b5$1$1356503$70dd7a6b@news.thecubenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 3 Jun 2021 08:57:08 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="3ebf8d3a0053be3e4198df3a5d13ddde";
logging-data="26217"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Kg6sIOBA9UBtXU3/S1PVC"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:+tfUO0PO4ytzFCWfTyCaWXsTHp0=
In-Reply-To: <1684efaa7b1ce4b5$1$1356503$70dd7a6b@news.thecubenet.com>
Content-Language: en-US
 by: Don Y - Thu, 3 Jun 2021 08:56 UTC

On 6/2/2021 6:54 PM, Clifford Heath wrote:
> On 3/6/21 2:01 am, Don Y wrote:
>> On 6/2/2021 5:39 AM, Clifford Heath wrote:
>>> No-one. Certainly not me. But you've said you're effectively retiring.
>>> To me that means you don't have to "deliver a result" any more.
>
>> OTOH, if "everyone" was expressing designs in some particular
>> structured form, then it would have value to THEM (and thus, to me)
>> if I invested the time to learn enough to be able to translate
>> my existing designs into such form.
>
> See my comment on SysML at the bottom.
>
>> My "legacy" is the products that I've defined and the people I've
>> influenced. I have no desire to immortalize myself in any of these
>> things; the *things* are the legacy, not my role in their creation.
>
> Good for you. You have my respect for your work.
>
> For myself, I feel that demonstrating *how* I worked is potentially more
> beneficial, even though many fewer people are directly impacted. I hold the
> principle that it is more beneficial to invent a better shovel than to dig
> another hole. So to talk with those few about *how* I did what I did (and to
> ruminate on how I might have done better) is a worthwhile activity. Not
> valuable to me of course, but to them and those who will benefit from the
> things they create.

I share my approaches with my colleagues -- but don't "evangelize".
They know that my "style" tends to evolve with each new project so,
possibly, they see every "discovery" as just a "latest fad"?

I let my work do the preaching. People reviewing it will likely be paying far
more attention to it than they would to an "opinion piece". And, it's
a /fait acomplis/, of sorts; there's no question as to whether it works
or how well it works -- it is concrete evidence of both.

I bumped into a colleague from a previous employer some years after I'd
left. He mentioned that he'd taken on the manufacturing support for
one of my designs. (<shrug> "OK, someone had to do so!") He went on to
offer that he was initially overwhelmed at the complexity of the circuit.
Then, quickly added, "But once I realized HOW you did things, everything
was crystal clear!" No doubt because I tend to be very consistent in
how I approach a solution (understand what I've done in one place and it
directly translates into how I did something else, elsewhere).

I try to "coerce" people following up on my efforts to adopt the same
style -- by building mechanisms that make it easier to do things LIKE
I did than to have to build something from scratch. Sometimes there's
so much "structure" in my design that it makes it impractical to "lift"
it, intact, and use it in another application without a fair bit
of rework.

[My speech synthesizers are a perfect example of this. As they have
LOTS of "const" data driving their algorithms, they load that data
from the RDBMS at runtime. And, as the RDBMS may be updated some
time (hours, days, months?) later -- WHILE THEY ARE STILL RUNNING -- they
install a trigger in the RDBMS that effectively initiates an upcall
to the synthesizer whenever those table entries are altered.
("The data on which you rely has been altered -- by SOMETHING. When
it is convenient for you to do so, you may want to refresh your
local sense of that data...") As other folks likely don't have a
similar mechanism in their applications, all of the related code has
to be elided and the appropriate const data installed in the binary
(via the source).]

Whether any of this wears off, long term, is unknown. But, I do notice an
increased use of finite automata among my colleagues, more structure
(inefficiency?) in their code, more synchronous hardware designs, etc.
So, maybe they've "matured" on their own -- or, silently taken up
some of the design approaches that I've championed, over the years.

>> E.g., I am hoping that demonstrating how you can approach a (UI) design
>> differently can eliminate "ability-bias" in the way those interfaces
>> are designed.
>
> Without knowing anything about how you've done that, I suspect a lot of it was
> already studied in UIMS work and implemented in products like Apollo's "Dialog
> Manager" during the 1970s and 80s. We implemented many of these ideas (along
> with many of my own) in our startup product OpenUI in the 1990's... ideas which
> still haven't been widely adopted. Yes, novel user interface technology was the
> most productive decade of my life so far. There's plenty of room for
> improvement still!

Most "electronic" UI's tend to rely heavily on vision. And, some sort
of dexterity (to manipulate controls). There have been numerous (bad)
attempts to retrofit assistive technology interfaces to interfaces
originally designed for "able-bodied" users. But, this after-the-fact
approach tends to be readily apparent to anyone using same.

Imagine how you'd enter text with a sip-n-puff/mouth stick. Then,
step back and ask, "Why are we asking for TEXT, here? Is there some
other way to get the information we want without resorting to that
'obvious' implementation choice?"

For example, prior to bedtime (here, my current project), the
user needs to be apprised of anything that my system can't
AUTOMATICALLY "fix" on his behalf. (e.g., I can adjust the
thermostat without his intervention -- once I realize that he
is retiring; but, I can't turn off the stovetop if he forgot to
do so, earlier... or, close any open windows, etc.)

The "obvious" way to convey this information to the user (given
that there are MANY "things" that *could* potentially need
attention, even though few actually *will*) is to display a
graphic rendering of the floorplan with "red" highlights
in those areas that need attention. A user can then just glance
at such a display and assure himself that all is well (or,
discover WHAT needs attention).

This won't work for a blind user. And, an alternative "display"
might need to be available for someone confined to a wheelchair
(e.g., I've located three such "display panels" around the house...
intended for STANDING sighted users -- out of sight/reach of
anyone wheelchair bound).

Reading off a list of "issues" could work for a blind (but *hearing*)
user. But, what order to present that list -- given that the
user is likely NOT going to be taking "written" notes? Surely,
any FIXED order has significant downsides as it would suggest the
user visit those issues in the PHYSICAL order enumerated instead
of taking into account his present location.

And, as he's not consulting a VISUAL display panel, it's silly
to assume he is located near one!

A friendlier presentation would inform him of the items needing
addressing in relationship to his current location (so, your
implementation should determine that before creating a presentation).
And, as he likely can access that information without being
present in a fixed location (which you can determine by HOW he
is accessing it -- via a fixed "display AUDIO station" or via
a wireless PORTABLE earpiece), you should "bundle" the items
needing attention into groups and summarize the AREAS needing
attention and rely on the user to move to an area that he finds
convenient, before expanding on the report that you have
for THAT area.

And, you wouldn't want to bother *either* user with "conditions"
that you've grown to know are "normal" for THEIR usage (e.g.,
we sleep with windows open most of the year so don't alarm on
those issues).

You can't effectively "bolt on" this sort of interface to
one that was originally designed for sighted users; it's a
significant chore (and would have to be done for EVERY
"visual presentation) which means it simply doesn't get done.

Or, is done in some kludgey manner ("Let's let the user
scan the visual display and INSPECT each area...")

The developer who thinks in visual terms won't even consider
these other options in the design of his implementation.

And, an implementation that expects to tackle it with
*explicit*, developer defined mechanisms like:

case (interface_type) {
visual =>
video->display(annotated_floor_plan());
audible =>
audio->display(list_problem_areas());
haptic =>
haptic->display(problems());
* =>
// panic
}

just invites folks to skimp on some implementations ("interface_types")
as well as omit those that they can't sort out (easily) at design time.

> It's good to explore "new" territory, but it's also good to firstly plan the
> journey by studying the prior art - just in case it's not new territory after all.
>
>> I have no desire to go on a "speaking circuit" to
>> pitch the approach. Few people will actually see/interact with
>> my end result.
>
> I did the speaking circuit for a few years, and I think that might be enough
> for me. I don't have the motivation to become an industry fashionista (which is
> all that most such people are). However, the result is that hundreds of people
> are implementing some of my ideas and spreading them to other people,
> especially in Europe.

A different set of motivation. I like building "things" that solve problems
for "real people" (everyone KNOWS developers are UNREAL! :> ). I don't
have the patience to "school" anyone -- even if done with a light touch.
My attitude is, instead, "This is what I did. Have a look for yourself.
I've got more interesting things to pursue..."

["Education" is neverending; what do you do when the NEXT guy comes
along and expresses an interest? Do you spent the time required to
educate (and persuade!) him? And, the one after that? Schematics,
specs, manuals, source code are my proxies for those activities.
"You're going to HAVE to understand at least some of those media
if you're going to do this sort of work, so have at it!"]

I made the mistake of letting a local builder see what I was doing
with the house... explaining how it is intended to address disabilities
(both present and evolved) to allow occupants to exist independantly
for "longer". He just saw it as a way to add $X (X being a relatively
large number) to the sales price of his so-equipped homes -- instead
of truly appreciating what I was trying to achieve. After hounding
me for months ("Is it done, yet?"), I finally stopped taking his calls.

"Here's an IDEA. You are free to find someone to exploit that idea
ON YOUR SCHEDULE AND AT YOUR PROFIT MARGIN. But, *I* am not interested."

>> No, that's all part of *THIS* project. Note the sheer number of "new"
>> techniques/technologies that I listed. Then, tell me I have no desire to
>> explore!
>
> Ok, fair enough! Formal methods are probably a step too far. You might get some
> benefit from a brief look at SysML, which I believe is very closely aligned to
> your needs. I believe SysML v2.0 was released just today.

I'll look at it but still suspect the fact that there was no outcry
of "Yeah, we ALL use SysML!" is a testament to its value, to *me*
(or the folks I expect will be reading my documentation).

If, for example, I was looking for a way to describe a piece of
"hardware", I'd seriously consider Verilog or VHDL -- instead of
(or in addition to) a "plain old schematic". But, that because
I know there is a sizeable population of "hardware" designers
who'd be familiar with such an expression. I'd certainly not
present a series of photomicrographs -- despite being a more
*exact* representation of the actual implementation! It simply
would fly over the heads of the intended audience.

Thanks for the input!

SubjectRepliesAuthor
o Re: (Semi-) formal methods

By: Clifford Heath on Wed, 2 Jun 2021

5Clifford Heath
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor