memory-leaks

Still reachable: lots of words in many pages.
git clone https://git.kevinlegouguec.net/memory-leaks
Log | Files | Refs | README | LICENSE

talks.md (6154B)


      1 # Sandi Metz - Nothing is Something
      2 
      3 :::: tags
      4 - OOP
      5 - Ruby
      6 ::::
      7 
      8 Some insightful thoughts on OOP.
      9 
     10 Clever examples of message-passing to get rid of conditionals.
     11 
     12 Prefer composition with dependency injection to inheritance:
     13 inheriting to override a method really means that the parent class had
     14 a default "null" behaviour that can be injected explicitly.
     15 
     16 Name the role, make an interface for it, and make classes that
     17 implement each behaviour (the null one and the specialized one).  This
     18 will make it easier to compose specializations (i.e. save you from
     19 multiple inheritance).
     20 
     21 
     22 # Sandi Metz - Rules
     23 
     24 :::: tags
     25 - OOP
     26 - Ruby
     27 ::::
     28 
     29 Some theory-crafting on rule-following, then the actual rules, which
     30 amount to
     31 
     32 - small classes,
     33 - tiny methods,
     34 - few parameters.
     35 
     36 At the 16-minute mark, an interesting interaction between Metz and a
     37 programmer starting to apply these rules: the programmer wonders when
     38 they will be able to understand the new application "the same way"
     39 they understood the old one.  I.e. will they ever reach a point where
     40 they have a complete mental map of every interaction between every
     41 object, the same way they used to have a complete mental map of the
     42 old monolithic, sequential application?
     43 
     44 Metz's response is that nope, this will never happen; they will "cease
     45 to care" instead.  In exchange, they will be able to make localized
     46 changes without worrying about breaking the whole application.
     47 
     48 
     49 # Fred George - The Secret Assumption of Agile
     50 
     51 :::: tags
     52 - Agile
     53 - OOP
     54 - programming methods
     55 - project management
     56 - training
     57 ::::
     58 
     59 Advice on when to refactor:
     60 
     61 - *after* design, *before* writing unit tests for the new stuff:
     62   prepare ground for the addition to fit right in;
     63 
     64 - *after* implementing the new behaviour, *before* integrating.
     65 
     66 Goes over the usual code smells taught during the training he gives
     67 (conditionals, getters & setters, class names ala "Manager", too many
     68 instance variables).
     69 
     70 Mentions a requirement for training **retention**: skills must be
     71 applied within a month after receiving the training, otherwise the
     72 rationale will be lost.
     73 
     74 Questions:
     75 
     76 - Does he know of open-source projects that showcase this style of
     77   programming?
     78     - Smalltalk, some NodeJS libraries.
     79 
     80 - Does he rely on naming conventions?
     81     - Quite a lot.
     82 
     83 
     84 # Josh Triplett - Intel and Rust - The Future of Systems Programming
     85 
     86 :::: tags
     87 - C
     88 - Rust
     89 - systems programming
     90 ::::
     91 
     92 ## Systems programming and C
     93 
     94 Systems programming
     95 :   > Anything that isn't an app
     96 
     97     Platforms for other programs to run on top of: kernels, VMs, even
     98     web browsers.
     99 
    100 Why did it take so long to move away from assembly for BIOS, firmware
    101 and bootloaders, despite C being readily available?
    102 
    103 - C had to have enough *compelling features* over assembly: "some
    104   degree of type safety", more readable code…
    105 - C had to provide **feature parity**: developers had to feel
    106   confident that they wouldn't be missing features from assembly.
    107 
    108 You could mostly do anything you did in C that you did in assemlby,
    109 and you had an "escape hatch" (the `asm` directive).
    110 
    111 The problems with C go beyond "buffer overflows".
    112 
    113 > Memory safety is the bare minimum requirement these days.
    114 
    115 **Usability and productivity go hand in hand with security:**
    116 
    117 > The less code you need to write to accomplish something, the less
    118 > chance you have of introducing bugs.
    119 
    120 One doesn't have to reach very far to find languages with more
    121 *compelling features* than what C offers.  What does "parity with C"
    122 entail, though?
    123 
    124 ## Rust
    125 
    126 Rust started out as a safe and performant language for complex
    127 applications, such as web browsers.
    128 
    129 Key feature #1: automatic memory management **without** a garbage
    130 collector.
    131 
    132 (Adding Rust to a codebase is jokingly refered to as "Oxidation")
    133 
    134 Key feature #2: safe concurrent programming.
    135 
    136 ### Parity with C
    137 
    138 Rust can handle C functions, structures, unions and pointers.
    139 
    140 Soon in stable Rust™: varargs, smaller binaries, robust inline
    141 assembly (there already exist builtins for SIMD instructions),
    142 bfloat16, more structure layout shenanigans.
    143 
    144 
    145 # Bryan Cantrill - Oral Tradition in Software Engineering
    146 
    147 :::: tags
    148 - C
    149 - History
    150 - UNIX
    151 ::::
    152 
    153 "Oral tradition" as in "educational stories we pass down for
    154 generations", not necessarily actually oral.
    155 
    156 - USENET's "[Story of Mel]" is one of our oldest enduring "tales".
    157 
    158 - Cantrill attributes the scarcity of 80s and 90s lore to the "deeply
    159   proprietary" culture of the era.
    160     - Though he does manage to squeeze in an emotional reading of a
    161       Hemingway parody called "[The Bug Count Also Rises]".
    162 
    163         > Many days he stood for a long time and watched the rain and
    164         > the shuttles and drank his double-tall mochas.  With the
    165         > mochas he was strong.
    166 
    167         > […]
    168 
    169         > They sat silently for awhile, then he asked Michaels, “I
    170         > need you to triage for me.”
    171 
    172         > Michaels looked down. “I don't do that anymore,” he said.
    173 
    174 - The 00s introduced a new era, where re-telling a story became as
    175   simple as sharing the link to a video.
    176 
    177 - Even without exploring the Internet, our own source bases are
    178   "pulsing with narrative".
    179 
    180 - Ends with a historical survey of UNIX lore buried in the codebase.
    181     - To Roger Faulkner suggesting asking Dennis Ritchie to settle the
    182       debate on why C lacks a logical XOR:
    183 
    184         > … You can *ask* The Lord?
    185 
    186       (Spoiler: to Cantrill's dismay, it was intentional, because such
    187       an operator could not short-circuit, and "`(A!=0) ^ (B!=0)`
    188       isn't that much worse to write", though I personally find it
    189       less *legible* than `A ^^ B`.)
    190 
    191       The point to the otherwise entertaining story being: *people are
    192       going to care about your intent*.  Younger generations yearn to
    193       understand what's going on and how they can perpetuate their
    194       forebears's legacy.
    195 
    196       (… They also need enough context to evaluate how valuable this
    197       legacy truly is.)
    198 
    199         > I really cared about what Dennis thought! (… Before I knew
    200         > he was wrong.)
    201 
    202 [Story of Mel]: https://en.wikipedia.org/wiki/The_Story_of_Mel
    203 [The Bug Count Also Rises]: http://www.workpump.com/bugcount/bugcount.html