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.
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
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?
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)
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
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.
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
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
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 ]
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
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
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!
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
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 ]
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 }
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
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
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
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
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
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
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 ]
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
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
INLINE EXPRESSIONS IN CONTROL STATEMENTS? too-close? = distance < 10ms if distance < 10ms { speed-adjustment is 90% speed-adjustment-back is 110% « etc »
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
COMPOUND EXPRESSIONS object-distance-after-speed-adjustment is speed-adjustment-back x distance adjustment is now 1ms adjustment-back is now 110% x distance + 5ms
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
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
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
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
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 :(
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
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
davetron5000
oracle4engineer
shohata
interu
mixi_engineers
globis_gdp
miyake
tacck
hikiroku
takemikami
mii3king
nearme_tech
optim
marcelosomers
thoeni
paulrobertlloyd
bluesmoon
jasonvnalue
cassininazir
cherdarchuk
chrisshort
zenorocha
akosma
hursman
jnunemaker