documentation is thoroughly hard
Documentation is good, so therefore more documentation must be better, right? A few examples where things may have gotten out of control.
more...
Documentation is good, so therefore more documentation must be better, right? A few examples where things may have gotten out of control.
more...
Why don’t unix commands have any vowels in the name? cp and mv are obviously devoweled standins for copy and move. But they’re less intuitive for new users. The user wants to copy a file. Why shouldn’t the name of the command be exactly the operation the user wants to perform?
What exactly does the user want to do? Instead of copying files, maybe I want to link two files. What does that mean? In unix, we have hard links and symbolic links. If I replace the “original” file, do I want the link to refer to the original file or the replacement? Or maybe what I mean by link two files is to combine two object files into an executable. Do we call that loading instead? ln is the name of a command, but link is the name of a concept. And sometimes the concept evolves over time. The linker is called ld because it used to be the loader. (I think.)
grep is a remarkably useful tool, but with a most unintuitive name. Why not call it find like Windows does? I want to find some text, I run find. So obvious. But some users may want to find files in the filesystem, not strings in a file. What command do they run? Probably locate.
There may be a great deal of historical accident in the names of commands (what if the inventors of awk had different initials?), but that doesn’t mean we can’t recognize the value of unique and precise identifiers.
The Solitaire cipher is perhaps the best known encryption algorithm implemented with a deck of cards. Ignoring security, it has a few drawbacks. It’s pretty complicated. I can never quite remember the rules. Sure, with practice it’s possible to memorize, but ideally we want something easy to teach. It’s also pretty slow. Even with practice, the shuffling and cutting manipulations take time.
more...
Unlike other languages which have one preferred means of signalling an error, C is a multi error paradigm language. Error handling styles in C can be organized into one of several distinct styles, such as popular or correct. Some examples of each.
more...
I have a chromebook which is quite nice for what it does. A dedicated browsing machine, fast and low maintenance. Alas, I am sometimes required to go outside, and worse yet talk to people, and even worster, show those people information. It is inconvenient to hand over my phone, no rotate it back, your other yaw, scroll a little, here, oh wait, let me unlock it again. I print such things on paper. Double alas, the chromebook makes this difficult.
more...
The New Yorker money issue, October 10. There’s some good articles about evolving, er, disrupting, business practices.
more...
Amazon started adding animations to selected books (Kindle in Motion, they call it). I figured I’d give it a try and read Off to Be the Wizard, by Scott Meyer of Basic Instructions fame. There’s not really much to animate here, only about one illustration per chapter, but now they dance back and forth.
more...
POSIX specifies that there is a ps utility to list processes, although it doesn’t describe how the command is implemented. In fact, it’s not possible to implement ps using only POSIX interfaces. However it’s implemented, it’s unlikely to use double buffering, which means on a sufficiently busy system, the results may be inconsistent. If lots of processes are being created and exited while ps runs, some of the output may be “before” and some “after”. Much like a game without vsync.
more...
Abstractions are nice when they help us gloss over seemingly unimportant details, but they also shape our perception of the underlying reality. Learning to work without abstractions can make it easier to switch between abstractions.
Consider the analogy of a photographer who takes pictures and an observer who views the results. Normally, they would both be standing upright. Everything lines up. Either the photographer may tilt their camera askew or the observer may tilt their head. If the picture is tilted, the upright viewer can probably make sense of it. Even tilt their own head to compensate. Or if the picture is straight, an observer with a neck cramp can still view it. But what happens if the camera is tilted left and the observer is tilted right? It doesn’t make any sense. Now the trees are growing upside down!
One can imagine writing code on a tilted monitor. It’s a little annoying at first, but eventually one learns to tilt their head to compensate and now their own code looks perfectly normal. Using a friend’s properly oriented monitor is a little cumbersome, but adequate. Using a monitor tilted in the opposite direction? Terrible! Horrendous! How can you call this code? All the loops are backwards and the control structures are inside out!
Having spent a few days learning a low level API that’s conveniently wrapped by a library, I wondered, what’s the point? I’m probably going to switch to a different library, er framework, in the future. Will this knowledge transfer? Yes, I think so. These are the API functions that all libraries use as well. They just apply their own slant. It can’t hurt to know what’s happening underneath. Is the knowledge of one framework directly transferable to another? That depends greatly on the compatibility of their tilt. If all I know is a left tilted world, those expectations may actually be a hindrance in a right tilted world.
When there’s more than one way to do things, it can be rewarding to relentlessly polish code, but this sometimes causes trouble later on. Boring code tends to have boring bugs, and since bugs are inevitable, this suggests we should prefer boring code.
more...