--- /dev/null
+---
+postid: '052'
+title: On the unambiguous usefulness of tools (in software and elsewhere)
+date: November 5, 2016
+author: Lucian Mogoșanu
+tags: tech
+---
+
+In [one of my previous essays][software-engineering] I mentioned this
+rare property of software, of being "unambiguously useful".
+
+This property applies -- or it very often doesn't -- to all things. For
+example hammers are unambiguously useful, as they can be *used for*
+driving nails into stuff. Phones are unambiguously useful because they
+can be *used for* talking over long distances. And so forth.
+
+Tools on the other hand may be used in contexts where they are clearly
+not useful, or where their usefulness is otherwise unclear. For example
+it doesn't really make sense to drive an automobile in overcrowded towns
+where the traffic is high, where walking could be at least as
+efficient. Computers by themselves are for example not useful in any
+unambiguous way: they may be used for one purpose or another depending
+on their performance and/or the software they have installed, but they
+may also be used for completely irrational, anti-economical purposes, as
+the [market-driven monkeys][google-stupid] often do.
+
+In computing the "tool-based approach" can sometimes be a particularly
+harmful beast[^1]. Nevermind that CAD[^2] tools haven't helped bring
+anything new to fields such as, say, architecture. The number of tools
+available to solve (often general-purpose) problems in computers has
+exploded, often without any real positive impact on the fields they're
+used in[^3]. This would not be by itself a problem if it weren't for
+those naïve wielders who think that the tool will solve all their
+problems, and who come to rely on the tool more than on the funny thing
+between their shoulders. But given this context, we can indeed say that
+tools may be not merely unproductive, but also counterproductive; and
+not merely useless, but also harmful.
+
+So now that we know for sure that this ambiguity of usefulness is
+prevalent throughout the various areas of technology, we can fortunately
+draw from the examples above to define more precisely what it means for
+a tool to be "unambiguously useful". I happen to think that the
+following is a very good criterion for judging the usefulness of tools,
+in software and in general:
+
+**Tools are unambiguously useful if and only if they are used to replace
+human labour, and not the human mind.**
+
+For example a pocket calculator is unambiguously useful because it can
+do all that basic arithmetics faster and less error prone than you; it's
+however not meant to replace your knowledge of basic
+arithmetics. Compilers and interpreters are useful because they can
+automatically translate programs from a convenient[^4] level of
+abstraction to machine code. Operating systems[^5] provide users with a
+minimal set of tools to help the user automate tasks that would normally
+take a lot of time to perform.
+
+As a counter-example, tools that aim to automatically find bugs in
+computer software are usually not unambiguously useful, although they
+might seem to be. While they may be successful at their task, they may
+also encourage their users to express intellectual laziness by yielding
+only dry results, without any improvement in the understanding of the
+root cause of said bugs[^6]. The same can be said about automated spell
+checkers in the hands of the functionally illiterate.
+
+So in general tools are unambiguously useful if they help you do the
+same stupid[^7] shit you normally do, but with significantly less
+effort.
+
+[^1]: Or, as ol' Dijkstra would say, "tool-based software(-based)
+ engineering considered harmful".
+
+[^2]: Computer-assisted, or Computer-aided Design.
+
+[^3]: Take programming languages for example. We nowadays have languages
+ (Coq, Isabelle/HOL, Agda, etc.) that allow programmers to
+ mechanically verify the correctness of their implementations with
+ respect to some specification. How many programs do you know that
+ are even partially implemented this way? I can name a few, but only
+ a very few.
+
+ Take Integrated Development Environments (IDEs) as another
+ example. There is no doubt about the fact that they often come with
+ very useful features, but is there any qualitative measure of their
+ help in improving software? I'll leave this thought experiment to
+ the reader.
+
+[^4]: Although "convenient" is definitely *not* an unambiguous
+ description. Going too high or too low up or down the abstraction
+ ladder can be a bullet in the foot,
+ [depending on][software-engineering-iii] what you're implementing.
+
+[^5]: By which I mean professional operating systems, not Windows, or
+ whatever people use nowadays for gaming.
+
+ Y'know, the ones with the nasty command-line shells and whatnot.
+
+[^6]: This is inherent in the definition of "computer bugs". Analysis
+ tools may detect simple bugs such as buffer overflows, but they will
+ never be able to help the programmer to properly code buffer
+ overflow-free software in the future, while buffer overflows are the
+ main cause of some of the nasty security bugs in the 2010s.
+
+ Meanwhile there are classes of bugs, such as semantic bugs, that can
+ only be detected through thorough testing or other methods such as
+ formal verification. In short, they demand intellectual resources
+ and huge chunks of attention, which are the scarcest things out
+ there. Ain't nobody got time fo' that, unfortunately.
+
+[^7]: Do not, I repeat, do *not* dismiss this as mere claptrap. If
+ anything, the goal of artificial intelligence is of a purely
+ philosophical nature. With all the fancy AI algorithms, we still
+ don't understand precisely why some of the tasks that seem so simple
+ to us are mind-blowingly hard to program into a computer.
+
+ AI and "cognitive science" will advance beyond snake oil by finding
+ the answers to such questions, not by turning people into
+ [statistical models][google-stupid]. But I repeat myself.
+
+[software-engineering]: /posts/y02/03c-the-myth-of-software-engineering.html
+[google-stupid]: /posts/y02/046-google-is-making-you-stupid.html
+[software-engineering-iii]: /posts/y03/04e-the-myth-of-software-engineering-iii.html
--- /dev/null
+---
+postid: '053'
+title: I wrote a blog.
+date: November 6, 2016
+author: Lucian Mogoșanu
+tags: meta
+---
+
+As [previously promised][new-tar-pit], the new Tar Pit[^1] is almost
+done. It's not quite there yet, and considering the usual pace of the
+blog's affairs, it might take a month or two before it goes online --
+besides, the non-technical reader will experience virtually zero change
+in reading experience; so I dare guess that this news isn't even that
+interesting. However, I wrote a blog! and despite this development
+having begun before the initial announcement, and despite its duration
+of a few additional months, it has all gone in perfect accordance to the
+initial plan.
+
+Given all this, and moreover, given this rare occasion of working with
+sane tools[^2] I feel compelled to share my experience with the reader
+and do some post-design examination on the topic.
+
+First of all, the Tar Pit Lisp Blog Scaffolding (LBS) is based upon a
+fundamental data structure, which I have at some point uninspiredly
+decided to name `blist`[^3]. A `blist` is conceptually very similar to a
+dynamic symbol table, that is, a binding between a name and a
+value. Almost everything from blog posts to templates to tags are
+representable as `blist` objects, and thus all that the LBS needs to do
+is convert source objects such as Markdown files or [CL-WHO][cl-who]
+templates into this intermediate representation, and then forth into the
+target representation, which in our case happens to be plain ol' HTML.
+
+This approach has the advantage of uniformity: metadata (e.g. post
+identifiers, the author(s), the date of publication) as well as the
+actual data (e.g. post content) are all represented using the name-value
+associations within a particular unit, e.g. a post or a page. Given
+this, the blog programmer is left with no option but[^4] to manipulate
+`blist`s as he or she wishes, for example by translating the body from
+Markdown to HTML or generating a whole new body based on existing
+metadata, such as for creating lists of references.
+
+The heavy lifting is of course still done by CL-WHO and Pandoc, with
+some help from [CL-PPCRE][cl-ppcre] and some other useful bits which
+help keep the whole castle in one place. And despite the system's
+heterogeneity, the design is anything but a mash-up of arbitrary tools.
+
+As far as development effort goes, I believe the whole thing took much
+less than fifty hours of implementation put together, plus around ten
+hours of thinking and reading the imported libraries. In fact most of
+the time went into learning Common Lisp[^5], debugging and testing being
+a close second and actual writing and refactoring occupying a third
+place.
+
+The close-to-final result is publicly available on [GitHub][github] --
+for now on a separate branch, but I expect it to converge towards the
+master as soon as I deem it to be ready for use in production. And make
+no mistake, "ready for use in production" is equivalent to "done", not
+unlike Roman aqueducts, the Great Wall of China and Shakespeare's works
+are "done"[^6]. And when it's here, you'll see it -- soon!
+
+[^1]: Tarp it!
+
+[^2]: Who ever had the impudence to state that
+ [software sucks][software-engineering-ii]?
+
+ As a matter of fact, making software that doesn't suck isn't
+ difficult. It only requires doing engineering for a clear purpose,
+ or rather, stemming from a cause worthy of consideration, rather
+ than coding for the sake of code; and it requires accepting that the
+ only true [freedom][freedom-is-slavery] derives from understanding,
+ that is, reading the code, rather than from mindless `import
+ universe` statements; and it also requires a very specific mindset
+ that makes all the difference between profession and mere
+ circle-jerking.
+
+ Not difficult at all...
+
+[^3]: I can't say I remember exactly why I gave it this name. It is
+ certainly a sort of unordered list addressable by arbitrary
+ identifiers, which makes it in fact a dictionary, which makes the
+ current hash table-based implementation quite well-suited to the
+ task.
+
+[^4]: Paradoxically!
+
+[^5]: By which I mean exactly Common Lisp, not a style of programming,
+ not macros, not algorithms and not design patterns, although each of
+ these subjects must be understood in order to fit everything in
+ head. On the other hand the fact that so many programming systems
+ copied Common Lisp makes it easy to recognize certain patterns in
+ their pure form.
+
+[^6]: But Lucian, your blog is nowhere near the technical and artistic
+ innovation blah-blah-yadda!
+
+ ... or not unlike how a bowl of stew is done, m'kay? A given
+ artifact does not have to be novel nor in any way special in order
+ to be "done"; more so that nowadays' vast majority of software is in
+ the vast majority of cases anything but done, to everyone's chagrin.
+
+[new-tar-pit]: /posts/y03/050-the-new-tarpit.html
+[software-engineering-ii]: /posts/y02/049-the-myth-of-software-engineering-ii.html
+[software-engineering-iii]: /posts/y03/04e-the-myth-of-software-engineering-iii.html
+[freedom-is-slavery]: /posts/y03/04f-freedom-is-slavery.html
+[cl-who]: http://weitz.de/cl-who/
+[cl-ppcre]: http://weitz.de/cl-ppcre/
+[github]: https://github.com/spyked/thetarpit.org
projects / thetarpit.git / commitdiff