spncrlkt/integrity-of-models.md

## integrity-of-models.md

      
    Raw
  

              integrity-of-models.md
            
          
INTEGRITY

ES6 Fiddle
Presentation

DEFINITIONS


the quality of being honest and having strong moral
principles; (moral uprightness?).


the state of being whole and undivided


2b) internal consistency or lack of corruption (in electronic data?)

UNPACKING DEFINITIONS


is somewhat objective + large value judgement.
Overall more subjective


is MOSTLY objective, with some subjectivity


depends on scope: e.g. a well-built house has integrity, though it is composite

2b) is the MOST objective

OPINIONS


INTERNALLY CONSISTENT LOOSELY DEFINED

Something like:

compatible with itself
not containing any logical contradictions
new information should fit in logically
latin: consistere (standing firm or stil)
early usage: consisting or composed of, compare to constituent
the sum of harmonious pieces


ASSUMPTION/FEELINGS

There's a strong link between simplicity and internal consistency.
Is it bidirectional? Correlated? Cause and Effect, and if so, which is cause? I dunno.
Integrity of a model: to what extent is this model internally consistent

CODE


// simple value assignment

let myName = "spencer";

assignment flow
<=
handle <= value


// Object literal assignment

let map = {
  key: "value"
}

// OR

let map = { key: "value" }

assignment flow
<=
'loose' assignment flow (no assignment operator therefore loose)
<=
handle <= value
( <= ( <= ))


map.key = "new value";

assignment flow
<=
handle <= value

let myNewVal = map.key = "new value";


DOUBLE assignment flow


<= SO VIVID <=


handle <= value


nesting/order of operations is preserved here between


object literal assignment and double assignment


( <= ( <= ))


const myFunc = (arg) => {
  line1;
  line2;
  line3;
 };


function def breaks assignment flow pattern!
( <= ( args => fnBody ))
results from imperative programming flowing (time word) or reading from top to bottom
we must have 'handles' for argument values near top (earliest) of function
also nice to have handle and argument list close together to help understanding function usage
QUESTION: any other operation work like this?


Alternatively, we could imagine a topsy-turvy world where flow goes from bottom to top

const myFunc = {
	line3;
	line2;
	line1;
} function (arg, arg2)


( handle <= ( body <= args )
realworld: this function argument assignment is fundamentally ingrained in devs
therefore almost never any confusion
handle(agrument, list) -- function usage
BUT: it breaks the model. The tradeoff is logical grouping of handle and argument list


BUG EXAMPLE

const dateTimeAndMore = {
  date: "today",
  time: "now"
};

const myLogger = (eventName, dateTime) => {
  const date = dateTime.date; 
  const time = dateTime.time;
  
  /* business logic (multiple other dates/times) */
  
  return `${eventName} happened @ ${date} @ ${time}`;
};

console.log(myLogger('myEvent', dateTimeAndMore));

DESTRUCTURING

const dateTimeAndMore = {
  date: "today",
  time: "now"
};

const myLogger = (eventName, dateTime) => {

   let {
     date,
     time
   } = dateTime;

  /* business logic (multiple other dates/times) */
  
  return `${eventName} happened @ ${date} @ ${time}`;
};

console.log(myLogger('myEvent', dateTimeAndMore));

HERE'S A NICE PIECE OF SHIT

/* OBJECT DESTRUCTURING THE EASY WAY */
const myLogger = (eventName, dateTime) => {

   let {
     occurDate: date,
     occurTime: time
   } = dateTime;
    
  occurDate = "MY" + occurDate;
  occurTime = "MY" + occurTime;
  
  return `${eventName} happened @ ${occurDate} @ ${occurTime}`;
};

console.log(myLogger('myEvent', dateTimeAndMore));

Why does this break?
What does this program do?
What should the error say?


OBJECTION OVERRULED!


You may say, this is a syntax error, ya just goofed it up
Lints fine, but hints could help point it out


CONCLUSIONS


Form (and consistently recall) a mental rule for handling object destructuring
I forecast that as long as this syntax stands, I will have to
remember this silly rule
I will most likely forget or remember wrongly this silly rule at some point
Even worse than forgetting it, I HAVE TO REMEMBER IT. FOREVER.
Else write goofy bugs
Model for assignment now includes exceptions (complexity)
AEIOU (and sometimes y)
I before E except after C
Guess we're gonna have to come up with a catchy mnemonic
OD syntax is easier, hands down.
Also, adds complexity to the system.


KISS? No, MISS!


Make it stupid simple
"The acronym was reportedly coined by Kelly Johnson, lead engineer at the Lockheed Skunk Works" -Wikipedia


MORAL

ABSOLUTELY CORRUPT MODELS CORRUPT ABSOLUTELY

EXTENDED EXAMPLE


Consider JS's falsy/truthy shitshow
TEST: name all falsy values
Mnemonics are: NO''FUN
WHY THE FUCK DO I NEED A MNEMONIC TO USE IF()


BONUS TEST YOU CAN PROBABLY INFER THE ANSWER TO:

let x = new Boolean(false);
if (x) {
  return "BORN 2 HUNT BUGS";
} else {
  return "UNTROUBLED SLEEP";
}

x t/f?
Does this matter? I dunno, does logic matter? /snark


MATH

Fewer axioms the better!

GEOMETRY


definitions + 4 / 5 axioms + arithmetic operations
everything falls out from there
calculate a really impressive thing
like pi to aribitrary precision (that was just invented by some guy in 250 BCE!)


CALCULUS


Arithmetic + Infinity = calculus (to handle change over time)
infinite series were used to calculate pi more easily
first recorded in india c. 1400 and 1500 CE, undiscovered in west for 100+ yrs
Who cares? Nerds like Newton, on using infinite series to calculate pi to 15 digits at 23 y.o.: "I am ashamed to tell you to how many figures I carried these computations, having no other business at the time"