More on the definition of "boundary object"
The very first episode of Oddly Influenced was about Star & Griesemer's idea of "boundary objects." That's proven to be a fairly hard concept to pin down, and I did at best an average job. Fortunately, I'm rereading Étienne Wenger's book Communities of Practice to
marick 2 Jan 2023 • 4 min read
Tinkerable software and Mastodon
More than 20 years ago, I wrote an editorial proposing what I called tinkerable software. We expect houses to be tinkerable: ordinary people, not the original builders, can modify them in both small and large ways. Even those who don't want to tinker expect
marick 29 Dec 2022 • 3 min read
Mastodon, quote boosts, dread, and the science fiction of A. Bertram Chandler
(The above is what's called, in Mastodon land, a "CW", which used to mean "content warning" but is now often referred to as a "content wrapper": i.e., the subject line. You have been warned, or wrapped, about what I will now subject you
This is an addendum to podcast episode 20 on Orr's Talking About Machines, about copier repair technicians. Orr uses Levi-Strauss's idea of "bricolage" as a way of talking about what makes a good copier repair tech. Broadly, bricolage is the process of rummaging through
Two lessons from learning to fly gliders
Many years ago, I learned to fly gliders (sailplanes, airplanes but without the complicated engine bits). I learned two contradictory lessons that have stayed with me. Don't just do something, sit there Since gliders don't have engines, something has to pull them into the
Scientific peer review compared to pull request peer review
@Migueldeicaza pointed to an article titled "The rise and fall of peer review", which argues that the current method of scientific peer review is relatively recent (it only became common in the 1960s) and hasn't worked out. The problems are fairly well-known: peer review
Addendum to "What got left out of software patterns"
In response to "What got left out of software design patterns," Joel Tosi asked what Alexander got wrong in Notes on the Synthesis of Form. To answer, I think it worthwhile to quote Alexander's "Preface to the paperback edition" in full. All emphasis is
What got left out of software design patterns
For some years around the early '90s, I was a regular attendee in Ralph Johnson's software reading group. As such, I had a ringside seat to the development of design patterns. We read and discussed at least selections of the three seminal books by
Cross-discipline education: a question based on copier repair techs and copier users
In Orr's ethnography of photocopier repair techs (https://www.goodreads.com/book/show/20081966-talking-about-machines), he discusses how techs have to educate copier users to produce good bug reports - that is, descriptions of problems useful to the techs in diagnosing the underlying problem. I'm
What if legibility/formalism is not the driver Scott and I think it is?
In episode 17 and episode 18, I discuss Scott's Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed. Scott puts a lot of the blame on people's love of formalized systems (and the closely related concept of "legibility"). Fair
Abstract There's a big set of non-software books that have inspired software people to change the way they develop software. Sometimes those changes have rippled out to many other developers. But the effects are second-order: people adopt changes in practice without knowing the odd
marick 2 May 2022 • 2 min read
When the Elixir parser sees quote do: content, it produces a 3-tuple of the form {:quote, metadata, [[do: content]]}. Marick takes a deep breath. :quote is a special form that takes the abstract syntax tree content (which represents Elixir code) and turns it into
The last post looked mainly at the different binding maps that are created and used during bytecode generation. This post looks at the syntax trees that are parsed from Elixir text, then delivered to the bytecode generator.
The How of Macros 1: Elixir compilation
As Abraham Lincoln did not say: those who like this sort of thing (details of programming language implementation) will find this the sort of thing they like.
marick 3 Jul 2021 • 10 min read
Macrofunology 4: atoms and function names
Because previous posts looked at function-defining macros that supported the same structure as def, they could ignore the difference between names and atoms. This post will discuss cases where the difference matters. TL;DR: When creating a function name from an explicit :atom, make
marick 2 Jun 2021 • 4 min read
Macrofunology 3: guard expressions
The gotcha: in quoted text, guards wrap the head (function name and arglist), so they require special-case code.
marick 29 May 2021 • 2 min read
Macrofunology 2: wrapping bodies, dissecting arglists
Any def contains a head (the function's name and argument list) and a body (what comes after the do). This post shows how to build a macro that takes the same structure but uses a part of the argument list to wrap code around
Macrofunology 1: module structure
This series of posts is about macros that expand into Elixir def expressions. That is, they expand into definitions of functions that get "attached" to a containing module. Such macros are not wildly more complicated than normal Elixir macros, but there are some subtleties
Custom assertions with ExUnit
Any unit testing library makes it easy to build your own custom assertions on top of the base assertions: just write functions. Often, though, you lose important information like appropriate line numbers, output that highlights structure differences, and so on. ExUnit makes it fairly
marick 27 Apr 2021 • 7 min read
Code for comparing TDD to Property-Based Testing
Hillel Wayne [https://twitter.com/hillelogram/] gave an example problem [https://gist.github.com/hwayne/e5a65b48ab50a2285de47cfc11fc955f]. The idea, as I understood it, was for people to solve it via property-based testing (PBT) or test-driven design and see what the differences were. In particular, I'm
marick 20 Apr 2021 • 14 min read
Tabular tests in Elixir
I recently read Aleksandr Skobelev [https://twitter.com/ilowry]'s nice "Fundamentals of Optimal Code Style." [https://optimal-codestyle.github.io/] I like that he uses principles of human perception – how the eye tracks things, how humans read – to produce his suggestions for style. And
Where do properties come from?
A not-infrequent response to my skeptical essay [https://www.crustofcode.com/a-reluctant-rebuttal/] on property-based-testing (PBT) is that I left out an important benefit: it makes you think about properties. (I think "invariant" would be a more precise word, but I'll stick with the standard