ROT: Rule Of Thumb Programming Language
Many problems we encounter in our lives we approach using rules of thumb that we’ve picked up. When we cook we all have our own rule of thumb for ingredient measurements. When we landscape there are craftsmen ways of getting around challenges. When you plant a garden, iron clothes, move to a new location… basically any of the non-technical, non-formal stuff we deal with in life we’re using some heuristic to get by without getting too bogged down on perfection.
Here is proposed a programming language for how we actually live. It’s not meant to solve math problems efficiently or make corporate software to optimize businesses or even give you specific, logically coherent applications. While you could do that with this language with enough effort, the goal of this language is to be interesting and help you get by with “good enough” so you can do more stuff, not one thing perfectly.
The language constructs are not static. Meaning: over time, as new heuristics come into existence, they will automatically be updated within the language. For example, a pinch is an ever evolving concept.
Note this is not an attempt to do Natural Language programming, it is meant to solve problems in a rule of thumb way.
I suspect this is a more useful approach than might be obvious.
- There is no right answer
- Exploration is primary
- Creating Interesting Things is always the goal
- Be useful, be easy to Just Start Trying Things
- Never the same program twice
- Learning Algorithms are primitive
- Programs will evolve “underneath” the programmer
Things One Might Want to Make with this language
A recipe generator that takes various raw ingredients and comes up with viable, tasty recipes
A Good Enough Data Analyzer for Finding Trends in commonly analyzed data
An OK way to organize shapes on a page
A simple music editor/maker
A 3D printing design studio
Wedding Planning App
What you probably wouldn’t want to do
Stock trading app
Mars Rover OS
Medicine delivery system
A Few Technical Notes
- The compiler and interpreter does a lot of work for the programmer. The language is intentionally ambiguous with things like numbers and comparisons.
- Programs will be highly non-deterministic. QA is more qualitative than quantitative.
- The language is meant to be very expressive and forgiving. The interpreter will just go with what it can.
- The idea of a working program will be very different than with other programming languages.
- Optimization is a more nuanced notion than speed or memory. It’s about Good Enough
The Language Details
- Imperative, Functional, and Symbolic approaches possible
- These work differently than in a more formal system. They have a non-deterministic element to them
- If…. Usually
- If…. Sometimes
- If…. possible
- If…. then
- random amount
- for a bit
- X could be a variety of internal and external events
- a while
- a little
- until X happens
- figure of speech
Operators and Built in Functions
- greater than
- less than
- basically equals
- usually greater than
- usually less than
- trial and error
- likely true
- close enough
- more interesting
- less interesting
- more chaotic
- less chaotic
- likely to exist
- stick together
Physics and Motion
- speed up
- slow down
Date and Time
- in the future
- not now
- in a while
(commonly measures or amounts without a deterministic value. these values change randomly within a threshold and are trained over time by the programmer and the executing device uniquely to them. so sharing a program with these values will change them slightly)
- a little
- a lot
- cup, quart, pint
- table, tea spoon
- inch, foot, yard
The overall language syntax resembles a mathematica or lisp type language. Very functional in nature to make it easier to string things together.
speed isNow (speedup [ThisThingImDoing, byALittle])
evals to: variable speed = 124mph
(probably [currentTemp, tomorrowTemp])
evals to Yes.
Originally published at docs.google.com.