[Cuis-dev] Dynabook and education

[ken.dickey at whidbey.com]

On 2020-06-17 10:00, Philip Bernhart wrote:
> "ken.dickey--- via Cuis-dev" <cuis-dev at lists.cuis.st> writes:
..
>> My questions are around the proper model to communicate with and the
>> support environment which I can explain and orient in.
>> 
>> As someone said "if you can afford to fail, you can do it in any
>> programming language.  We can't afford to fail".

> I don't understand what you mean by that train of thought.

Sorry.  I should have separated and supplied more context.  My brain 
spills over at times.

I was part of a project which did live failover for a cloud system.  
This could have been done in Lisp or Smalltalk.  We started with more 
Lisp folks, so used Common Lisp.  Similar runtime technologies.

We had a very sharp C++ hacker which we were bringing up to speed.  He 
was somewhat skeptical of dynamic languages.  We were doing pair 
programming.  First we wrote a test, then messaged the server -- failed. 
  OK, so then attached to the server runtime, wrote the code, re-ran the 
test.  Poked the server -- test passed.

Conversation followed:

"You can't do that!"

"What do you mean?"

"You didn't bring down the server.  You didn't recompile the code"

"Right.  The code _was_ dynamically compiled and loaded on the fly.  Our 
customers typically run a process for two or three years and do live 
failover when upgrading the hardware.  We require live update of the 
server process.  If you can afford to fail, you can do it in any 
programming language.  We can't afford to fail."


So I am very interested in code migration and live failover.  Not that I 
have all the answers.

What I was trying to say is that I want a welcoming environment with 
good tools and as much robustness as can do.  I would not like to make 
some highly complex artifact that claims robustness at the expense of 
losing good development tools or being too complex to explain to mere 
mortals.

I think that any discussion of goals (like "restful" systems and 
surviving hardware failures) should include a wider discussion about 
comprehensibility and tools.

I think that we are basically agreeing on this and I am just stating 
things badly.

Hey, communication takes practice.  I keep hoping to get better at it.

Thanks for calling this out.
-KenD