Technical terms I didn’t understand, then decided to find out.

Slide 1

Slide 1 text

Technical terms I didn’t understand, then decided to ﬁnd out. @NikhilVerma #LondonJS

Slide 2

Slide 2 text

Nikhil Verma Core Team Lead Frontend Team @NikhilVerma

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Often times I got a bit lost when reading things online… 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

I collected these terms overtime and asked my colleagues to contribute. We came up with this list 6

Slide 7

Slide 7 text

imperative / declarative - call tree - cardinality - coersion - constraint solver - idempotence - covariant / invariant - dependency injection - dynamic scoping - idiomatic - function shadowing - generics - inference - lexical scope -  inversion of control - algebraic subtyping - implicit subtyping - type - control flow - semantics - side effects - state machine -   impedance mismatch - leaky abstraction - macro - meta languages - meta programming - monad - paradigm - parametric polymorphism -  nominal / structured typing - persistent identity - primitives - reconciler -   strongly / weakly typed - reflection - stack frame - syntactic sugar -   type soundness - tight or loose coupling - temporal dead zone - virtual structs - 7

Slide 8

Slide 8 text

Today we’ll talk about General Programming • imperative / declarative • idempotence • idiomatic • inversion of control • impedance mismatch Types • nominal / structured typing • strongly / weakly typed • type soundness 8

Slide 9

Slide 9 text

imperative / declarative 9

Slide 10

Slide 10 text

Part of “programming paradigms” Generally speaking • imperative - “You tell the machine exactly what to do” • declarative - “You tell the machine your expectations” https://en.wikipedia.org/wiki/Programming_paradigm 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

imperative function returnOdd(arr) { const odds = []; for (var i = 0; i < arr.length; i++) { const num = arr[i]; if (num % 2 !== 0) { odds.push(num); } } return odds; } 12

Slide 13

Slide 13 text

declarative function returnOdd(arr) { return arr.filter(num => num % 2 !== 0); } 13

Slide 14

Slide 14 text

Let’s look at something a bit different 14

Slide 15

Slide 15 text

imperative const selectedRecords = []; for (let idx = 0; idx < records.length; idx++) { if (selectedRecords.length === 10) { return selectedRecords; } if (records[idx].id < 100) { selectedRecords.push(records[idx]); } } return selectedRecords; 15

Slide 16

Slide 16 text

declarative SELECT * from records WHERE id < 100 LIMIT 10; 16

Slide 17

Slide 17 text

17 Imperative Declarative • Verbose • Explains how it works internally • Complete control over the flow of the code • Suitable where direct control of machine is priority • Terse • Inner functionality is abstracted away • Little control over how the code is executed • Suitable when human readability is priority

Slide 18

Slide 18 text

idempotence 18

Slide 19

Slide 19 text

idempotence Something which can be done several times without affecting the outcome. 5 * 1 = 5 5 * 1 * 1 = 5 5 * 1 * 1 * 1 = 5 5 * 1 * 1 * 1 * 1 = 5 5 * 1 * 1 * 1 * 1 * 1 = 5 https://en.wikipedia.org/wiki/Idempotence 19

Slide 20

Slide 20 text

idempotency in programming • Utility function being called • User clicking on a button to submit a form • What if it’s a payment form? • What if it’s a chat message? • Calling an API endpoint http://cloudingmine.com/idempotence-what-is-it-and-why-should-i-care/ 20

Slide 21

Slide 21 text

not idempotent class RegistrationPage extends React.Component { registerUser() { api.registerUser(this.state).then(this.navigateToApp); } render() { return ; } } 21

Slide 22

Slide 22 text

idempotent class RegistrationPage extends React.Component { registerUser() { if (this.isRegistering) { return; } this.isRegistering = true; api.registerUser(this.state).then(this.this.navigateToApp); } render() { return ; } } 22

Slide 23

Slide 23 text

What does it mean for you? Whenever writing code, consider if it should be idempotent or not. Often times it’s about keeping actions stateful. 23

Slide 24

Slide 24 text

idiomatic 24

Slide 25

Slide 25 text

idiomatic “Follow the conventions of the technology.” 25

Slide 26

Slide 26 text

not idiomatic function multiply(arr, number) { const newArr = []; for (var i = 0; i < arr.length; i++) { newArr.push(arr[i] * number); } return newArr; } 26

Slide 27

Slide 27 text

idiomatic function multiply(arr, number) { return arr.map(arrNum => arrNum * number); } 27

Slide 28

Slide 28 text

28 https://twitter.com/v8js/status/1040219491358179328

Slide 29

Slide 29 text

“The performance of Map is much better than Object to implement dictionaries when they contain a large amount of entries, which is usually what we have here. After testing this change in Facebook we've seen a ~20% reduction of the time to run all tests …” https://github.com/facebook/jest/pull/6960/files 29

Slide 30

Slide 30 text

So what does it mean for you? • Idiomatic code should be preferred • It will help others understand your code better. • It will help library authors and language maintainers to optimise for the most used cases • Idioms evolve! What was idiomatic a year ago might not be the same today. 30

Slide 31

Slide 31 text

inversion of control 31

Slide 32

Slide 32 text

inversion of control In the simplest terms: • traditional flow of control - “I want these items!” • inversion of control - “Give me those items!” https://en.wikipedia.org/wiki/Inversion_of_control 32

Slide 33

Slide 33 text

An example of inversion of control in JS 33 callbacks!

Slide 34

Slide 34 text

callbacks // MyCode.js fetch(API_ENDPOINT) .then(data => data.json()) .then(handleResponse); // “I will send you the API response” function handleResponse(apiResponse) { // “Give me the apiResponse” // do something with the response } // MyTest.js const response = { ...mockResponse }; handleResponse(response); 34

Slide 35

Slide 35 text

dependency injection 35

Slide 36

Slide 36 text

no dependency injected import api from './api'; export class Session { loginUser() { api.loginUser().then(this.doSomething); } } 36

Slide 37

Slide 37 text

dependency injection export class Session { constructor(api) { super(); this.api = api; } loginUser() { this.api.loginUser().then(this.doSomething); } } 37

Slide 38

Slide 38 text

dependency injection // Easier to mock API import mockApi from './mockApi'; const session = new Session(mockApi); session.loginUser(); // Easier to reuse import myCustomAPI from './myCustomAPI'; const session = new Session(myCustomAPI); session.loginUser(); 38

Slide 39

Slide 39 text

a component example 39

Slide 40

Slide 40 text

no dependency injected import BackButton from './BackButton'; function NavigationBar({ hasBack }) { return (

{ hasBack ? : null } {/* rest of the implementation */}

); } 40

Slide 41

Slide 41 text

dependency injected component function NavigationBar({ leftSlot }) { return (

{ leftSlot ? leftSlot : null } {/* rest of the implementation */}

); } import BackButton from './BackButton'; } /> 41

Slide 42

Slide 42 text

dependency injected component import BackButton from './BackButton'; } /> 42

Slide 43

Slide 43 text

dependency injected component import CloseButton from './CloseButton'; } /> 43

Slide 44

Slide 44 text

dependency injected component import TestButton from './TestButton'; } /> 44

Slide 45

Slide 45 text

So what does it mean for you? Inversion of control techniques can make your code: • Modular • Testable • Reusable • Flexible Consider if you should use it when writing your code. 45

Slide 46

Slide 46 text

impedance mismatch 46

Slide 47

Slide 47 text

impedance mismatch In simple terms it is a mismatch between what you want and what you have. e.g. 1. You want to render the name and online status of a user. 2. But those things lie on different APIs and in different formats. 3. So you must fetch both and assemble a final result together. https://devblogs.microsoft.com/oldnewthing/20180123-00/?p=97865 https://haacked.com/archive/2004/06/15/impedance-mismatch.aspx/ 47

Slide 48

Slide 48 text

high impedance mismatch Promise.all([ api.get(GET_PERSON_PROFILE, { userId: '1234' }), api.get(GET_PERSON_STATUS, { userId: '1234' }) ]).then(([ personProfile, personStatus ]) => { this.setState({ name: personProfile.data.name, isOnline: personStatus.data.status === 'ONLINE' }); }); 48

Slide 49

Slide 49 text

low impedance mismatch api.get(GET_USER, { userId: '1234', fields: ['name', 'isOnline'] }) .then(({ name, status }) => { this.setState({ name, isOnline }); }); 49

Slide 50

Slide 50 text

GraphQL query HeroNameAndFriends { hero { name friends { name } } } https://graphql.org/learn/queries/#operation-name 50 { "data": { "hero": { "name": "R2-D2", "friends": [ { "name": "Luke Skywalker" }, { "name": "Han Solo" } ] } } }

Slide 51

Slide 51 text

So what does it mean for me? • Impedance mismatch happens because of the nature of server/client technologies used. • We should strive to lower the impedance mismatch because it makes us efficient. https://overreacted.io/making-setinterval-declarative-with-react-hooks/ - Our “impedance mismatch” is not between Databases and Objects. It is between the React programming model and the imperative setInterval API. 51

Slide 52

Slide 52 text

nominal / structured typing 52

Slide 53

Slide 53 text

nominal / structured typing In general terms: • nominal - “validate this type based on it’s name” • structured - “validate this type based on it’s shape” https://en.wikipedia.org/wiki/Nominative_and_structural_type_systems 53

Slide 54

Slide 54 text

nominal typing class Foo { method(input: string): number { ... } } class Bar { method(input: string): number { ... } } let foo: Foo = new Bar(); // ERROR!! 54

Slide 55

Slide 55 text

structured typing class Foo { method(input: string): number { ... } } class Bar { method(input: string): number { ... } } let foo: Foo = new Bar(); // OKAY!! TypeScript example 55

Slide 56

Slide 56 text

structured typing class Foo { method(input: string): number { ... } } class Bar { method(input: string): boolean { ... } } let foo: Foo = new Bar(); // ERROR!! 56

Slide 57

Slide 57 text

Is structured typing better? 57

Slide 58

Slide 58 text

class Student { id: string; constructor(id: string) { this.id = id; } delete() { /* delete this.id */ } } class Teacher { id: string; constructor(id: string) { this.id = id; } delete() { /* delete this.id */ } } // In this file let teacher = new Teacher('5'); // In some other file function deleteStudent(student: Student): void { student.delete(); } deleteStudent(teacher); // Whoops! 58

Slide 59

Slide 59 text

59 Nominal Structured • Rigidity • Simplicity • Flexibility • Complexity https://github.com/Microsoft/TypeScript/issues/202#issuecomment-329914167 https://flow.org/en/docs/lang/nominal-structural/ One language can have both nominal and structural typing! e.g. in Flow Classes are nominal but objects are structured

Slide 60

Slide 60 text

strongly / weakly typed 60

Slide 61

Slide 61 text

strongly / loosely typed 61

Slide 62

Slide 62 text

strongly / loosely typed In simple terms, ”strongly typed languages have stricter type checks compared to loosely typed languages.” https://en.wikipedia.org/wiki/Strong_and_weak_typing 62

Slide 63

Slide 63 text

Things which determine strong/loose • Implicit type conversions • Static type-checking • Dynamic type-checking https://en.wikipedia.org/wiki/Strong_and_weak_typing#Definitions_of_%22strong%22_or_%22weak%22 63

Slide 64

Slide 64 text

implicit type conversion var num = 5; var str = '6'; var obj = {}; var sum = num + str; // "56" var minus = num - str; // -1 var mult = num * str; // 30 var objSum = obj + sum; // "[object Object]56" var objMult = obj * num; // NaN 64

Slide 65

Slide 65 text

static type checking var num = 5; var str = '6'; var obj = {}; var sum = num + str; // "56" var minus = num - str; // TYPE ERROR var mult = num * str; // TYPE ERROR var objSum = obj + num; // TYPE ERROR var objMult = obj * num; // TYPE ERROR 65

Slide 66

Slide 66 text

dynamic type checking var item = 'str'; console.log(`${item}_hello`); // "str_hello" item = NaN; if (isNaN(item)) { console.log('NaN!'); // "NaN!" } item = { hello: 'world' } console.log(typeof item); // object 66

Slide 67

Slide 67 text

67 Strongly Typed Loosely Typed • Strictness • Favour errors at compile time • Typically more boilerplate (*) • Flexibility • Favour errors at runtime • Typically less boilerplate * Languages with good type inference can still remain terse (e.g. ReasonML) https://en.wikipedia.org/wiki/Type_system#Static_and_dynamic_type_checking_in_practice

Slide 68

Slide 68 text

type soundness 68

Slide 69

Slide 69 text

What is type soundness? Type soundness is the guarantee of a language that a “given type will always be the same at runtime.” 69

Slide 70

Slide 70 text

TypeScript (not sound) function addInteger(arr: Array): Array { return arr.concat(3); } const strings: Array = ['foo', 'bar']; addInteger(strings); TS Playground 70

Slide 71

Slide 71 text

Reason (sound) let addInteger = (arr) => Array.append(arr, [| 4 |]); let strings: array(string) = [| "foo", "bar" |]; addInteger(strings); ReasonML Playground 71

Slide 72

Slide 72 text

Wait, why would any typed language want to be unsound? 72

Slide 73

Slide 73 text

Soundness isn’t always the end-goal https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals 73

Slide 74

Slide 74 text

Soundness vs Unsoundness 74

Slide 75

Slide 75 text

Soundness vs Completeness 75

Slide 76

Slide 76 text

76 Soundness Completeness “Any code that can be typed is valid” • Rigidity • If the code compiles it will not fail at runtime “Any code that is valid can be typed” • Flexibility • If the code compiles it can fail at runtime https://en.wikipedia.org/wiki/Soundness https://en.wikipedia.org/wiki/Completeness_(logic) https://news.ycombinator.com/item?id=16780068

Slide 77

Slide 77 text

What I learnt General Programming • imperative / declarative - “Telling the machine / expecting results” • idempotence - “Can be done many times without effecting the outcome” • idiomatic - “Follow the conventions of the technology.” • inversion of control - “Give me those dependencies” • impedance mismatch - “What you want vs what you have” Types • nominal / structured typing - “Validate based on name / structure” • strongly / loosely typed - “Stricter checks / relaxed checks” • type soundness - “Guarantee that a type will remain the same always” 77

Slide 78

Slide 78 text

How I went about learning them 1. Started with Wikipedia 2. Googled for articles or blog posts 3. Find out experts in the field and read about what they 4. Searched Twitter/Hacker News for those terms and followed the discussion thread 5. Search, Rinse and Repeat 78

Slide 79

Slide 79 text

Thank you for listening! 79 DM me if you have any feedback @NikhilVerma