1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
# Sandi Metz - Nothing is Something
:::: tags
- OOP
- Ruby
::::
Some insightful thoughts on OOP.
Clever examples of message-passing to get rid of conditionals.
Prefer composition with dependency injection to inheritance:
inheriting to override a method really means that the parent class had
a default "null" behaviour that can be injected explicitly.
Name the role, make an interface for it, and make classes that
implement each behaviour (the null one and the specialiazed one).
This will make it easier to compose specializations (i.e. save you
from multiple inheritance).
# Sandi Metz - Rules
:::: tags
- OOP
- Ruby
::::
Some theory-crafting on rule-following, then the actual rules, which
amount to
- small classes,
- tiny methods,
- few parameters.
At the 16-minute mark, an interesting interaction between Metz and a
programmer starting to apply these rules: the programmer wonders when
they will be able to understand the new application "the same way"
they understood the old one. I.e. will they ever reach a point where
they have a complete mental map of every interaction between every
object, the same way they used to have a complete mental map of the
old monolithic, sequential application?
Metz's response is that nope, this will never happen; they will "cease
to care" instead. In exchange, they will be able to make localized
changes without worrying about breaking the whole application.
# Fred George - The Secret Assumption of Agile
:::: tags
- Agile
- OOP
- programming methods
- project management
- training
::::
Advice on when to refactor:
- *after* design, *before* writing unit tests for the new stuff:
prepare ground for the addition to fit right in;
- *after* implementing the new behaviour, *before* integrating.
Goes over the usual code smells taught during the training he gives
(conditionals, getters & setters, class names ala "Manager", too many
instance variables)
Mentions a requirement for training **retention**: skills must be
applied within a month after receiving the training, otherwise the
rationale will be lost.
Questions:
- Does he know of open-source projects that showcase this style of
programming?
- Smalltalk, some NodeJS libraries
- Does he rely on naming conventions?
- Quite a lot.
# Josh Triplett - Intel and Rust - The Future of Systems Programming
:::: tags
- C
- Rust
- systems programming
::::
## Systems programming and C
Systems programming
: > Anything that isn't an app
Platforms for other programs to run on top of: kernels, VMs, even
web browsers.
Why did it take so long to move away from assembly for BIOS, firmware
and bootloaders, despite C being readily available?
- C had to have enough *compelling features* over assembly: "some
degree of type safety", more readable code…
- C had to provide **feature parity**: developers had to feel
confident that they wouldn't be missing features from assembly.
You could mostly do anything you did in C that you did in assemlby,
and you had an "escape hatch" (the `asm` directive).
The problems with C go beyond "buffer overflows".
> Memory safety is the bare minimum requirement these days.
**Usability and productivity go hand in hand with security:**
> The less code you need to write to accomplish something, the less
> chance you have of introducing bugs.
One doesn't have to reach very far to find languages with more
*compelling features* than what C offers. What does "parity with C"
entail, though?
## Rust
Rust started out as a safe and performant language for complex
applications, such as web browsers.
Key feature #1: automatic memory management **without** a garbage
collector.
(Adding Rust to a codebase is jokingly refered to as "Oxidation")
Key feature #2: safe concurrent programming.
### Parity with C
Rust can handle C functions, structures, unions and pointers.
Soon in stable Rust™: varargs, smaller binaries, robust inline
assembly (there already exist builtins for SIMD instructions),
bfloat16, more structure layout shenanigans.
|
