Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Programming a Time Machine

Programming a Time Machine

An overview of the Timeline programming language with some backstory on how time travel works, along with thoughts about how to design a programming language and write clear code.

David Copeland

June 08, 2019
Tweet

More Decks by David Copeland

Other Decks in Technology

Transcript

  1. PROGRAMMING A TIME MACHINE WITH AN EVENT-BASED LANGUAGE THAT USES

    RISK-BASED TESTING DAVE COPELAND • @davetron5000
  2. OUR GOALS • Intro to time travel using the Timeline

    Programming Language • Understand Timeline's design decisions so you can apply them: • To your API or Library Designs • To your own programming languages • To the way you approach developer or user experience
  3. TIMELINE BASICS • An event-based programming language to program a

    one-time flight plan for a specific journey • Eschews unit tests for a risk-assessment based on Monte Carlo simulations • An extreme focus on observability - what will the program do? what did the program do?
  4. DRS NEIL BELL & CHRIS CLARKE • 10 years validating

    the approach • 5 more to make it practicable • Dr. Bell focused on hardware • Dr. Clarke on firmware & software • Result is the Time Space Manifold (TSM)
  5. ONE PROBLEM THE 2043 BAN ON NEURAL NETWORKS AND MACHINE

    LEARNING "Flags and offices" by 4nitsirk is licensed under CC BY-SA 2.0
  6. BUT REAFFIRMS THE REASON FOR THE BAN THE FIRST WAIVER

    IS GRANTED • A generalized pilot was created based on vast training data about our universe • First flight was a success, however the second was disasterous • Machine Learning algorithms are inherently incomprehensible and unpredictable • Impossible to explain the behavior observed • And therefore impossible to predict
  7. FORGET THE GENERAL AND FOCUS ON THE SPECIFIC - SOLVE

    THE PROBLEM IN FRONT OF US EACH TIME
  8. CONSEQUENCES • Instead of a general pilot, write a flight

    plan for each flight • Use a language that makes it obvious how the system will behave when flight happens • Use simulation instead of specification to understand the risks with a given flight plan • Produce comprehensive output about what actually happened.
  9. — Timeline's Core Value THE MOST IMPORTANT THING ABOUT A

    PROGRAM IS WHAT IT WILL DO. THE SECOND IS WHAT IT DID. ” “
  10. HELLO (AGAIN) TIMELINE on vortex established [] { send disconnect

    [] now } ALL CODE IS IN RESPONSE TO AN EVENT NO RETURN VALUES OR I/O - YOU CAN ONLY SEND EVENTS
  11. LET'S TRY IT > timeline plan.timeline Success..............98.00% Failure..............02.00% Hardware failure..........02.00%

    Failed connection..............01.23% Disconnect failed..............00.77% Seed: 98798798743 98% CHANCE EVERYTHING WORKS AS EXPECTED FUNNY STORY
  12. CHARTING A COURSE • A destination in space • A

    length of time to go back • The size and mass of what is traveling
  13. REMEMBER, THERE IS NO I/O—ONLY EVENTS on start [] {

    send trip details [ destination:[ ascension:60º23'42" declination:75º02'12" distance:384,402km duration:1,296,000s ] traveler:[ weight:90kg dimensions: [ width:1m height:2m depth:0.3m ] ] ] now } ICRF COORDINATE HOW FAR BACK CUBE THAT COMPLETELY ENCLOSES THE TRAVELER STANDARD LIBRARY - TRIGGERS THE VORTEX
  14. send trip details [ destination:[ … ] traveler:[ … ]

    ] now KEYWORD EVENT NAME WHEN TO TRIGGER THE EVENT PARAMS TO THE EVENT - NAMED
  15. destination:[ ascension:60º23'42" declination:75º02'12" distance:384,402km duration:1,296,000s ] BRACKETS ARE A CONSTRUCTOR

    THESE ARE TYPED LITERALS type Destination [ ascension:Angle declination:Angle distance:Distance duration:Time ]
  16. LANGUAGE CHOICES send trip details [ destination:[ … ] traveler:[

    … ] ] now send disconnect [] now ALWAYS USE BRACKETS - CONSISTENCY ALWAYS USE BRACKETS - CONSISTENCY ALSO, THEY ARE EASIER TO TYPE THAN PARENS NO NEED FOR QUOTES - IT'S OBVIOUS WHAT THE EVENT NAMES ARE
  17. LANGUAGE CHOICES destination:[ ascension:60º23'42" declination:75º02'12" distance:384,402km duration:1,296,000s ] LITERALS ARE

    TRUE LITERALS, NOT NUMBERS WE ASCRIBE MEANING TO - NO AMBIGUITY LARGE VALUES ARE EASY TO MISTYPE, SO WE REQUIRE COMMAS - THIS CODE IS FOR HUMANS 60º 23' 42" 1,296,000 S
  18. NOT "TDD" BUT "RDD" - RISK DRIVEN DEVELOPMENT WORKFLOW 1.

    Provide plan details 2. Simulate the plan 3. Assess the risk of failure 4. Add code only to reduce risk 5. When risk is acceptable - Go!
  19. LET'S SIMULATE OUR PLAN > timeline plan.timeline Success..............00.00% Failure.............100.00% Hardware

    failure..........01.23% Failed connection..............01.23% Large Object Collision....98.77% Known Object Collision..........90.45% unknown Object Collision........08.32%
  20. WHAT ARE WE COLLIDING WITH? > timeline -seed 98798798743 \

    --details="Known Object Collision" \ plan.timeline Success..............00.00% Failure.............100.00% Hardware failure..........01.23% Failed connection..............01.23% Large Object Collision....98.77% Known Object Collision..........90.45% Satellite 4F76......................90.45% collision at 86ms unknown Object Collision........08.32% 86MS INTO OUR JOURNEY, WE HIT A SATELLITE
  21. CONSULT THE STANDARD LIBRARY // Triggered when traveler enters the

    // vortex to start the trip on traveler entered [] {} // Trigger a change in the vortex heading send adjust vortex direction [ // angle relative to our // current heading direction:Angle ]
  22. SOME REAL CODE on traveler entered [] { direction is

    45º send adjust vortex direction [ direction:direction ] in 80ms reverse-direction is 360º - direction send adjust vortex direction [ direction:reverse-direction ] in 115ms }
  23. SOME REAL CODE on traveler entered [] { direction is

    45º send adjust vortex direction [ direction:direction ] in 80ms reverse-direction is 360º - direction send adjust vortex direction [ direction:reverse-direction ] in 115ms } "=" IS AMBIGUOUS, SO INSTEAD BE VERY CLEAR SINCE "-" IS DEFINED ON ANGLES, THE RESULT IS AN ANGLE DASHES ARE EASY TO TYPE AND EASY TO READ
  24. YOU CANNOT INLINE EXPRESSIONS on traveler entered [] { direction

    is 45º send adjust vortex direction [ direction:direction ] in 80ms send adjust vortex direction [ direction:360º - direction ] in 115ms
  25. YOU CANNOT INLINE EXPRESSIONS on traveler entered [] { direction

    is 45º send adjust vortex direction [ direction:direction ] in 80ms send adjust vortex direction [ direction:360º - direction ~~~~~~~~~~~~~~~~ \-- must be literal or variable ] in 115ms INLINING INCREASES DENSITY, WHICH REDUCES COMPREHENSIBILITY THIS ALSO FORCES ALL EXPRESSIONS TO HAVE NAMES
  26. VARIABLE NAMES MUST BE DEFINED WORDS on traveler entered []

    { direction is 45º send adjust vortex direction [ direction:direction ] in 80ms rev-direction is 360º - direction send adjust vortex direction [ direction:rev-direction
  27. VARIABLE NAMES MUST BE DEFINED WORDS on traveler entered []

    { direction is 45º send adjust vortex direction [ direction:direction ] in 80ms rev-direction is 360º - direction ~~~~~~~~~~~~~ \-- “rev” is not a word send adjust vortex direction [ direction:rev-direction ABBREVIATIONS OR NON- WORDS HURT COMPREHENSION. ALL VARIABLES MUST BE COMPRISED OF DEFINED WORDS YOU CAN ADD NEW WORDS TO THE DICTIONARY, BUT MUST DEFINE THEM
  28. HOW'S OUR PLAN LOOK NOW? > timeline plan.timeline Success..............62.00% Failure..............38.00%

    Hardware failure..........02.23% Failed connection..............01.23% Failed midstream...............01.00% Small Object Collision....34.70% Large Object Collision....01.07% SPACE IS FILLED WITH LOTS OF STUFF WE DON'T TRACK
  29. STANDARD LIBRARY AGAIN // ask for telemetry send ping []

    // When a ping detects an object ahead on collision imminent [ // How many ms ahead of us? distance:Time // Angle inside vortex position:Angle // cube that encompasses // the object's intersection dimensions:Dimension ]
  30. SEND A PING ONCE WE ENTER on traveler entered []

    { «previous code» send ping [] now }
  31. STANDARD LIBRARY YET AGAIN // Adjust our speed through the

    vortex send adjust vortex speed [ speed: Percent ]
  32. COMPLEX LOGIC 1. If the object is too close, slow

    down 2. Avoid the object 3. Correct our course 4. If we had to slow down, speed back up
  33. SAME ALGORITHM, MORE GENERAL adjustment is distance - 2ms adjustment-back

    is adjustment + 4ms direction is 180º + position « SLOWDOWN LOGIC TBD » send adjust vortex direction [ direction:direction ] in adjustment send adjust vortex direction [ direction:direction ] in adjustment-back send ping [] in adjustment-back
  34. SLOWING DOWN too-close? = distance < 10ms if too-close? {

    speed-adjustment is 90% speed-adjustment-back is 110% object-distance-after-speed-adjustment is speed-adjustment-back x distance adjustment is now 1ms adjustment-back is now object-distance-after-speed-adjustment + 5ms send adjust vortex speed [ speed:speed-adjustment ] now send adjust vortex speed [ speed:speed-adjustment-back ] in adjustment-back } else { do nothing } BOOLEANS ARE SPECIAL, SO THEY MUST END IN A "?" REASSIGNMENT IS ERROR- PRONE, SO MUST BE DONE EXPLICITLY BOTH CASES OF AN IF MUST BE HANDLED EXPLICITLY
  35. INLINE EXPRESSIONS IN CONTROL STATEMENTS? too-close? = distance < 10ms

    if distance < 10ms { speed-adjustment is 90% speed-adjustment-back is 110% « etc »
  36. ALL EXPRESSIONS MUST BE NAMED too-close? = distance < 10ms

    if distance < 10ms { ~~~~~~~~~~~~~~~ \--- must be literal or variable speed-adjustment is 90% speed-adjustment-back is 110% « etc » ALL EXPRESSIONS MUST BE NAMED, EVEN IN CONTROL STRUCTURES
  37. COMPOUND EXPRESSIONS - NOT ALLOWED object-distance-after-speed-adjustment is speed-adjustment-back x distance

    adjustment is now 1ms adjustment-back is now 110% x distance + 5ms ~~~~~~~~~~~~~~~~~~~ \--- All expressions must be named COMPOUND EXPRESSIONS INCREASE DENSITY
  38. HOW ABOUT NOW? > timeline plan.timeline Success..............95.00% Failure..............05.00% Hardware failure..........02.23%

    Failed connection..............01.23% Failed midstream...............01.00% Small Object Collision....01.70% Large Object Collision....01.07% 95% CHANCE SUCCESS + 1.23% CHANCE WE CAN'T CONNECT = 96.23% CHANCE OF NOT DYING 95% CHANCE SUCCESS + 1.23% CHANCE WE CAN'T CONNECT = 96.23% CHANCE OF NOT DYING CAN'T FIX THIS
  39. THE LAST 2.77% • Handling more edge cases requires a

    lot of complexity • Unit Tests could let us drive that • Early versions of Timeline supported unit testing… • …but it allowed the creation of complex code whose behavior could not be understood or explained • Instead, we focused on observability
  40. WHAT HAPPENS IN A FAILURE? > timeline plan.timeline \ --black-box-for="Small

    Object Collision" Success..............95.00% Failure..............05.00% Hardware failure..........02.23% Failed connection..............01.23% Failed midstream...............01.00% Small Object Collision....01.70% Large Object Collision....01.07% Black Box in: small-object-collision.blackbox
  41. THE BLACK BOX IS…DETAILED Time Trip Time Type Event Source

    Params 0 0 Trigger start TSM [] 1 0 Handle start plan.timeline:1 [] 2 0 Trigger trip details plan.timeline:2 [ … ] 3 0 Handle trip details TSM [] 5 0 Trigger vortex established TSM [] 6 0 Handle vortex established plan.timeline:5 [] 10 0 Trigger traveler entered TSM [] 11 0 Handle traveler entered plan.timeline:8 []
  42. THE BLACK BOX IS…DETAILED Time Trip Time Type Event Source

    Params 13 2 Schedule adjust vortex direction plan.timeline:10 [ direction: 45º ] 14 2 Schedule adjust vortex direction plan.timeline:14 [ direction: 315º ] … … … … … … 90 80 Trigger adjust vortex direction TSM [ direction: 45º ] 125 115 Trigger adjust vortex direction TSM [ direction: 315º ]
  43. THE BLACK BOX IS…DETAILED Time Trip Time Type Event Source

    Params 125 115 Trigger adjust vortex direction TSM [ direction: 315º ] 127 117 Trigger vortex adjusted TSM [] 128 118 Trigger collision TSM [ … ] WE ADJUSTED RIGHT INTO SPACE JUNK :(
  44. NEXT STEPS • Is this a risk we want to

    mitigate? ➡ Write code to try to mitigate it • Otherwise, decide if we want to go…or not • While testing gives assurance, risk assessment gives confidence
  45. — Timeline's Core Value THE MOST IMPORTANT THING ABOUT A

    PROGRAM IS WHAT IT WILL DO. THE SECOND IS WHAT IT DID. ” “
  46. TAKE AWAYS • Learn more about time travel and Timeline

    at timeline-lang.com • When designing APIs or languages, consider both the problem you are solving as well as what you value: • Timeline solves a very specific problem • Timeline values observability and predictability, so: • reduce density • require readability/comprehensibility • testing as simulation instead of verification