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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
This is a list of blog-ish websites where I found insightful stuff
that I would like not to forget.
# [LispCast]
Eric Normand's musings on programming paradigms and their application,
with a soft spot for functional programming.
[When in doubt, refactor at the bottom]
: Quoting Sandi Metz:
> Duplication is far cheaper than the wrong abstraction.
The point being that blindly following the letter of the DRY law
can lead developers to add complexity to extracted functions
because "it almost does what I want; if I could add just one more
parameter to it…".
Normand and Metz encourage developers to "mechanically" extract
small pieces of logic; even if they are not re-usable, bundling
things together and naming them helps make the potential
abstractions more visible.
[Programming Paradigms and the Procedural Paradox]
: A discussion on our tendency to conflate *paradigms* with their
*features*; for example, when trying to answer "can this language
express that paradigm?", we often reduce the question to "does
this language possess those features?".
Normand wonders whether we do this because the procedural
paradigm's metaphor (a series of steps that each may contain any
number of sub-tasks) maps so well to its features (sequential
statements, subroutines) that it trained us to mix those up.
[LispCast]: https://lispcast.com/category/writing/
[When in doubt, refactor at the bottom]: https://lispcast.com/refactor-bottom/
[Programming Paradigms and the Procedural Paradox]: https://lispcast.com/procedural-paradox/
# [null program]
Chris Wellons's in-depth looks into a fairly wide range of programming
techniques and applications. The articles often come with
illustrative code samples, which are always broken down into
bite-sized chunks that are easy to grok.
Some recurring topics I enjoy reading about:
- GNU/Linux plumbing
- [Raw Linux Threads via System Calls]
- [Appending to a File from Multiple Processes]
- [A Magnetized Needle and a Steady Hand]
- C programming tricks
- [Global State: A Tale of Two Bad C APIs]
- [C Closures as a Library]
- [How to Write Portable C Without Complicating Your Build]
- [A Tutorial on Portable Makefiles]
- Algorithmics
- [Inspecting C's qsort Through Animation]
- [A Branchless UTF-8 Decoder]
- [Render Multimedia in Pure C]
- Emacs Lisp plumbing
- [Some Performance Advantages of Lexical Scope]
- [What's in an Emacs Lambda]
[null program]: http://nullprogram.com/index/
[Raw Linux Threads via System Calls]: https://nullprogram.com/blog/2015/05/15/
[Appending to a File from Multiple Processes]: https://nullprogram.com/blog/2016/08/03/
[A Magnetized Needle and a Steady Hand]: https://nullprogram.com/blog/2016/11/17/
[Global State: A Tale of Two Bad C APIs]: https://nullprogram.com/blog/2014/10/12/
[C Closures as a Library]: https://nullprogram.com/blog/2017/01/08/
[How to Write Portable C Without Complicating Your Build]: https://nullprogram.com/blog/2017/03/30/
[A Tutorial on Portable Makefiles]: https://nullprogram.com/blog/2017/08/20/
[Inspecting C's qsort Through Animation]: https://nullprogram.com/blog/2016/09/05/
[A Branchless UTF-8 Decoder]: https://nullprogram.com/blog/2017/10/06/
[Render Multimedia in Pure C]: https://nullprogram.com/blog/2017/11/03/
[Some Performance Advantages of Lexical Scope]: https://nullprogram.com/blog/2016/12/22/
[What's in an Emacs Lambda]: https://nullprogram.com/blog/2017/12/14/
# [Et tu, Cthulhu]
[A hash table re-hash]
: A benchmark of hash tables that manages to succinctly explain
common performance issues and tradeoffs with this data structure,
to show results across a wide range of implementations, and to
provide very understandable interepretations for those results.
[Et tu, Cthulhu]: https://hpjansson.org/blag/
[A hash table re-hash]: https://hpjansson.org/blag/2018/07/24/a-hash-table-re-hash/
# [Evanmiller.org]
I mostly only read the articles dealing with programming languages.
The down-to-earth commentary made me feel like the author both
appreciates the thought process that went into the design, and has
enough hindsight to find where that thought process fell short.
[A Taste of Rust]
: An overview of some of the language's features. Some comments
resonated particularly well with me, e.g. on nested functions:
> With other languages, I’m never quite sure where to put
> helper functions. I’m usually wary of factoring code into
> small, “beautiful” functions because I’m afraid they’ll end
> up under the couch cushions, or behind the radiator next to
> my car keys. With Rust, I can build up a kind of organic
> tree of function definitions, each scoped to the place where
> they’re actually going to be used, and promote them up the
> tree as they take on the Platonic form of Reusable Code.
[Evanmiller.org]: https://www.evanmiller.org/
[A Taste of Rust]: https://www.evanmiller.org/a-taste-of-rust.html
# [Bartosz Ciechanowski]
[Alpha Compositing]
: The good, bad and ugly of how we discretize colors, and
color-blending. With helpful interactive simulations.
[Bartosz Ciechanowski]: https://ciechanow.ski/
[Alpha Compositing]: https://ciechanow.ski/alpha-compositing/
# [Red Hat Developer]
[10 tips for reviewing code you don't like]
: The article could basically be included as-is in a [nonviolent
communication] textbook and renamed "application to code reviews".
AFAICT the underlying principle to all these tips is: scrub
judgmental statements out of your responses, and state your
concerns openly. Nobody should expect you to hold all the
answers; express your uncertainty, and let the submitter do the
work of convincing you (e.g. checking for performance regressions,
splitting patch series).
[Red Hat Developer]: https://developers.redhat.com/blog/
[10 tips for reviewing code you don't like]: https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like/
[nonviolent communication]: https://en.wikipedia.org/wiki/Nonviolent_Communication
# Motherfucking websites
:::: tags
- Web design
::::
Satirical websites fighting [web bloat] with minimalist designs.
- <https://motherfuckingwebsite.com/>
No style at all, content only.
- <http://bettermotherfuckingwebsite.com/>
Increased line spacing, bigger text, reduced line length.
- <https://evenbettermotherfucking.website/>
Less contrast, better fonts.
- <https://thebestmotherfuckingwebsite.co/>
Satire of the satire, to show that it's possible to be fancy
and stay lightweight.
- <https://thebestmotherfucking.website/>
Less contrast, better fonts.
- <https://bestmotherfucking.website/>
Use fonts the user already have, compress content.
- <https://perfectmotherfuckingwebsite.com/>
Think of internationalization
[web bloat]: https://idlewords.com/talks/website_obesity.htm
|
