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.
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
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?
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)
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
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.
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
… ] ] 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
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
--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
// 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 ]
45º send adjust vortex direction [ direction:direction ] in 80ms reverse-direction is 360º - direction send adjust vortex direction [ direction:reverse-direction ] in 115ms }
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
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
{ direction is 45º send adjust vortex direction [ direction:direction ] in 80ms rev-direction is 360º - direction send adjust vortex direction [ direction:rev-direction
{ 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
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
// 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 ]
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
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
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
adjustment is now 1ms adjustment-back is now 110% x distance + 5ms ~~~~~~~~~~~~~~~~~~~ \--- All expressions must be named COMPOUND EXPRESSIONS INCREASE DENSITY
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
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
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
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