On 6/1/2021 7:03 PM, Clifford Heath wrote:
> On 16/5/21 5:35 pm, Don Y wrote:
>> On 5/15/2021 6:41 PM, Clifford Heath wrote:
>>> On 16/5/21 5:26 am, Don Y wrote:
>>>> On 5/15/2021 3:54 AM, Clifford Heath wrote:
>>>>> On 15/5/21 7:10 pm, Don Y wrote:
>>>>>> Unfortunately, use in such a document is not suited for "general audiences"
>>>>>
>>>>> The goal of CQL is to make the formal model suitable for (and expressed in
>>>>> the language of) anyone generally familiar with the domain being modelled.
>>>>> Actually rationale is seldom needed. What is needed is an example of the
>>>>> scenario that is allowed or disallowed by each definition. The example is
>>>>> almost always an adequate rationalisation.
>>>>
>>>> I disagree. I find many cases where I need to resort to prose to
>>>> explain why THIS implementation choice is better than THAT.
>>>
>>> Yes, where that is needed, CQL provides context-notes too. In fact I select
>>> four specific categories of rationale ("so that", "because", "as opposed to"
>>> and "to avoid"), with optional annotations saying who agreed and when.
>>
>> I present my descriptions in "multimedia prose" so I can illustrate
>> (and animate) to better convey the intent.
>
> All that is needed is to allow the viewer to get to the "Aha!" moment where
> they see why the alternative will fail. Do whatever you have to do to achieve
> that, and you have your rationale. It will vary with the situation, and with
> the audience.

I've found that people tend to "lack imagination" when it comes to
things in which they aren't DEEPLY invested. They often fail to
see ("go looking for") aspects of a design that aren't superficially
obvious. This evidenced by how many folks only test their designs
with inputs they EXPECT to encounter (instead of imagining the larger
set of inputs *possible*).

So, I try to develop "interactions" that let the "reader" see what
I'm trying to illustrate -- and, then, coach them into pondering
"what ifs" that they've NOT likely imagined and show how those
win/fail in different alternatives.

With interactive presentations, I can literally tell them to "do X"
and know that (if they do), the presentation will clearly show
the issue that I would, otherwise, find tedious to explain in prose.

>>>>>> Again, why the resistance to adopting such a "codified" approach?
>>>>> Hubris, mostly. People genuinely don't see the need until enough
>>>>> experience has humbled them, and by then, their accumulated caution and
>>>>> tentativeness mean their industry sees them as dinosaurs.
>>>>
>>>> "Hubris" suggests overconfidence (in their abilities). I'm not sure
>>>> that's the case.
>>>>
>>>> I started looking for a "common ground" in which I could express my current
>>>> design when I "discovered" that, not only is there no such thing,
>>
>> You've missed the point. I was addressing the point that modeling, itself,
>> is relatively uncommon (at least in "these circles"). So, trying to find
>> some common subset that everyone (most practitioners) were using was
>> pointless.
>>
>> If no one speaks Esperanto, then it is foolish to present your documentation
>> *in* Esperanto!
>
> In relation to software, at least, every modeling language has been a private
> language shared only (or mainly) by systems architects. They're all Esperanto,
> of one kind or another. (ER diagramming has sometimes been useful, and
> occasionally even UML, but usually not)
>
> As such, it serves only for documenting the system *as designed*, and can

That's exactly my goal. I'm looking to "translate" my design into
form(s) that may be more easily recognizable -- to some "significant"
group of readers.

For example, one can design a grammar with totally /ad hoc/ methods.
But, presenting it a BNF goes a long way to clarifying it to "new
readers" -- regardless of how it came about (or was implemented).

> provide no help to a non-expert in identifying flaws where the result would not
> match the need (as opposed to not working correctly within its own frame of
> reference).

Different goal.

A "non-expert" reading the BNF of a grammar wouldn't be able to glean
much about how it *could* be implemented or inconsistencies in any
potential implementation. But, he *could* construct a valid sentence
with just that BNF (and not worry about how it gets parsed).

> Because "modelling" has always been subject to this failure, it is seen as a
> pointless exercise. Delivered software is likely to work "as designed" yet
> still mis-match the problem because the design was mis-targeted, whether it was
> modelled or was not.
>
> The solution to this is good modelling tools that can communicate to
> *everyone*, not just to programmers. And that's what I spent a decade trying to
> build.

You're trying to solve a different problem than I.

I agree with your points -- in *that* application domain.

>> When I approached my colleagues re: this topic, no one tried to
>> defend their current practices. I think they all realize they
>> *could* be doing things "better". This led to my contemplation of
>> why they *aren't* moving in those directions.
>
> It's easier to "stay in town" where it's comfortable, than to go exploring in
> the wilderness. It's wilderness because there is no adoption, and there's no
> adoption not because no-one has been there, but because they didn't build roads
> and towns there yet.

I don't think "ease" or "comfort" is the issue. Many of my colleagues
are involved with very novel designs and application domains. They
are almost always "treking in the wilderness".

But, they aren't likely to add additional uncertainty to their efforts
by tackling novel design techniques on top of a novel application
(or application domain). There's a limit as to how much "risk"
one can take on -- especially if you are answerable to "others"
(the folks who pay the bills).

I have historically taken on lots of "new experience" because it
was something I could fold into *my* time... I could decide to
"eat" the cost of learning a new technology "on my dime" as long
as I'd budgeted (timewise) to meat my completion estimates for
clients. *They* don't care if I move all of my development
tools to UN*X -- as long as they can support my completed
work with their *Windows* toolchains.

[I.e., I bear the cost of assuming both worlds work -- the UN*X
domain for me and the Windows domain for them]

But, others may see no point in moving to a different hosting
platform: "What's wrong with Windows?" Should I fault them for
"staying in town"?

>>> I know a number of companies that implement "10% time",
>> Yes, but 10% of 40 hours isn't a helluvalot of time.
>
> Half a day a week seems like quite a lot to me. If an employee doing that can't
> prove to me that they've discovered something worthy of a bigger investment,
> then I don't believe they have.

Four hours a week is nothing.

A colleague, many years ago, was assessing the effort for a particular
task. He made the off-hand comment: "You can't do ANYTHING in 8 hours!"
Which warranted a chuckle.

But, in hindsight, there's a sort of truism, there.

There are costs to starting and stopping activities. Folks who say
"10% of your time" are obviously TRACKING time. How much time am
I allotted to handle my daily correspondence (which may be distributed
across the day and not neatly bundled in a "lump")? How much time
for project meetings? How much time to browse trade magazines
to "keep current" with product offerings? Ditto published works?
Do I have a separate account to charge time to handle questions
from the manufacturing engineer re: my design? What if I need
to visit the toilet? Do I have an account against which to charge
my TIMEKEEPING time?

Four hours gets frittered away -- unless you start nickel and diming
your "real" projects with the time "lost" to these other incidentals.

Even with no one driving my time on a daily basis (self-employed),
it is still amazing how quickly a day "disappears". A piece of
test equipment needs repair/calibration/updating, ditto for a
piece of software, a battery in a UPS dies and a replacement needs
to be ordered -- and eventually installed. Etc.

Ever have your boss come to you and say, "The technician who has
been supporting the XYZ product -- that you designed -- has quit.
Will you take over the Final Test activities so manufacturing can
continue to ship product while we look to hire a replacement?
And, when we hire that replacement, will you train him on the
design and the process that you put in place? Of course, you
*still* have that upcoming deadline for the ABC product that
you are currently working on..."

> At one company, I spent 18 months trying to evangelise the business need for a
> new technology I'd envisaged. Eventually someone told my manager "just give him
> 2 weeks to prototype it!", and I did. The effect was astounding - the entire

How much progress would you have made if that 80 hours had been
doled out in 4 hour chunks -- over the course of 20 weeks? FIVE MONTHS?

Few places will let you "drop everything" for a day -- let alone a
week or two. And, if what you are pursuing will take even longer,
how likely for you to make REAL progress when that effort is
diluted over months (years?)

I donate ~10 hours weekly to local non-profits. That's "a day"
in my eyes -- as it takes time to get TO anyplace and "charging"
travel time to the "donation" seems disingenuous. Still, with
8+ hours available IN A SOLID BLOCK, it is amazing how little
progress I can make on whatever "goals" I've laid out for that
day.

E.g., I refurbished electric wheelchairs at one place. I can
do this in *about* 10 man-hours. So, surely, one or two "visits"?

Nope. More like four, on average. Even neglecting time spent
eating, toilet, "resting", etc. there are just too many other
activities clamoring for my time:

"An 18-wheeler just pulled in. Can you help unload it?"
(do you know how much effort there is in unloading such
a beast? imagine with *a* helper; imagine with NO helper!)

"The guy who drives the forklift is out on a delivery. Could
you move these four Gaylords into the warehouse for us?"
(of course, they are waiting for it to happen NOW, not once you
come to a convenient breaking point in your activities)

"The internet is down. Can you figure out if the problem is
on site or if we have to call our provider?"
(likewise waiting -- who's job IS this, anyway?)

"A gentleman from XYZ Industries is here. They are thinking
of becoming a sponsor. Could you give him a tour?"
(Really? With all this grease on my hands and face???)

Now, remember, this is *MY* time. My *DONATED* time. (like those
"4 hours" RESERVED for *you*?). I can elect to be a ball-buster
and simply decline all of these requests. (can you decline the
request from Manufacturing?) Or, I can postpone MY planned activities
and try to address these more immediate needs. With *ideal*
timekeeping, this would still increase the cost of doing what "I want".

Or, I can take work home and hope to make progress on it
when THOSE distractions aren't around. (i.e., SOMEONE is
waiting for that wheelchair and, as justifiable as my
"excuses" might seem, they are inconvenienced by the delay)

> company (110 people) dropped everything else they were doing to work on
> producing a new product based on my idea. That product brought in well over a
> hundred million dollars over the next decade.
>
>>> I look forward to hearing of your experiences with TLA+, Alloy, or CQL.
>>> I promise that it will be worth your effort.
>>
>> It's unlikely that I will try any of them! This is my last "electronics"
>> project (50 years in a field seems like "enough"; time to pursue OTHER
>> interests!)
>
> And that is why I'm sometimes reluctant to engage in these conversations with
> you, Don. You're the one asking "why does nobody try this", but even now you

You've misread my intent. I am not ACCUSING anyone. Rather, I am trying to
see how people have AVOIDED "doing this". How are folks designing products if
they aren't writing specifications, modeling behaviors, quantifying market
requirements, etc.? (if they ARE doing those things, then WHICH are they
doing??)

My *hope* was that there would be Concensus on how to explain (even if /ex
post factum/) designs so that I could massage *my* "explanation" into a
comparable form. I have no interest in revisiting the design process,
just looking for a way to explain them in a context that others MIGHT
easily understand.

> have time to explore (without the demands of delivering a result), you're

Who says I don't have to "deliver a result"?

> unwilling to do more than talk about that.

Who says I've not "ventured into the uncharted wilderness"?

I've explored alternative technologies to support universal access to my
application -- blind, deaf, ambulatory compromised, cognitive impairment,
etc. I've had to research the prevalence of these to understand the
sizes of the affected populations. And, the other demographics
related to them (e.g., blind-from-birth has different skillsets than
blind-from-diabetic-retinopathy; a naive assumption of one or the
other will likely lead to a suboptimal solution)

I've created an entirely different way of building applications that
aren't "pre-biased" to a particular set of user abilities, abstracting
the concept of "display" away from visual mechanisms without burdening
the actual application developers with having to understand the different
UI modalities. Can you use that new-fangled thermostat on your wall
with your eyes closed? While seated in a wheelchair? Without the use
of your ARMS/hands?

I've explored four different speech synthesizer technologies -- implementing
one of each -- and tried to quantifiably "evaluate" each of them (despite a
complete lack of objective criteria "in the industry"). I've examined other
"foreign" languages with an eye towards seeing how they could (by someone else)
eventually be supported in the framework that I've designed.

I've explored haptic technologies, gesture recognition, braille transcription,
etc. (How does a blind person tell if a particular port on a network switch
is seeing any activity? How does a nonverbal user indicate a desire to
perform a particular action? How does a user confined to a wheelchair
access a particular appliance? How do you alert a deaf user to an
"event" -- like a fire, doorbell, timer on the microwave oven expiring,
laundry being done?)

I've spent days in an electric wheelchair to experience what it's
like to have my mobility *constrained* (!) by the device that is
intended to enhance it. And, how tedious it is to have to remember
everything that I need to do *in* the kitchen WHILE I am *in*
the kitchen -- as having to *return* to the kitchen is a chore!
"Did I turn *off* the oven? Can I afford to gamble on that or
should I drag myself out of bed, crawl back into the wheelchair
and check it for myself?"

I've developed a front-end preprocessor to add additional syntax to
"standard C" to facilitate seamless support for distributed applications.
I've explored and developed my own IDL and compiler to back that. I've
included support for interface versioning so a running app can persist
with connections to a version X server while a newly launched app can
take advantage of version Y on that same server)

I've evaluated the consequences of various "scripting languages" on
the abilities of these varied users (try "reading" your code to a
blind man; see how easily that blind man can write code of his own!
Amazing just how many punctuation marks there are! :> )

I've adopted a policy of replacing "const" members in applications
with dynamically loaded data from an RDBMS. And, created mechanisms
to allow for the associated contents of that RDBMS to be updated and
merged, live, with the 24/7/365 applications that are using them.

I've replaced the notion of a persistent store with that of a
persistent DBMS. I've had to understand how that DBMS could
potentially fail and how it's maintenance could be automated
(cuz you don't have a DBA on hand in every household!)

I've developed a decomposed RTOS that supports seamless distribution,
redundancy, timeliness constraints, capabilities, disjoint namespaces,
process migration, etc.

I've implemented a distributed, synchronized clock (so code executing
on different nodes can know the relative order of their activities).

I've 22 hardware designs to support the various portions of the system.
I've had to select components with an eye towards manufacturability
and cost containment -- not just MY money but the monies that users
would eventually have to pay.

Each is PoE powered (so I need to know how to design a PD and a PSE).
I've run the 4500 ft of CAT5e to support these devices -- in a
preexisting home without basement or attic). I've figured out how to
"hide" the devices so they don't make the place look like a tech eye-sore.

I've had to consider how a malicious adversary could compromise portions
of that system and still keep it operating (within the reduced capacity
available). (What happens if I put a Tesla coil to a port in YOUR
network switch?? What happens if I disassemble a piece of kit
that you have "outside"/accessible and use it as a beachhead to
compromise your system? What if you invite me to spend a weekend
in your spare bedroom with that "unprotected" network drop by the bed?)

I've built an AI that screens telephone calls based on observations
of the "user's" responses to those calls. And, "learns" to
recognize the voices of callers so it need not rely on easily
fudgeable identifiers like CID.

I've built a doorbell that recognizes visitors and gates their access
to my property.

I've built a "stealth" server that allows access from The Internet
without disclosing its presence to malicious probes.

All of these are "wilderness" areas. All of them took time to research,
implement and evaluate.

So, I guess I have a different idea of "having time to explore" than
you do! And, a greater emphasis in having a real solution to a real
problem than an esoteric "technique" that *might* apply to future
problems. Your time is your own -- as is mine. Do what you think
"adds value" to your expenditure of same (you only have to answer to
yourself!)

This is why I don't post, here -- too few people have any real
pertinent experience to comment, knowledgeably, on the issues or
potential solutions. It's an "imagined" problem (or, one that
they want to think won't affect them, personally). Maybe they'll
be "lucky" and develop some of these "constraints" on their
abilities and gain first-hand USER experience, that way! *Hoping*
that someone else will solve their problems (and chagrined to
discover the solution is not forthcoming) :-/