From: Lucian Mogosanu Date: Sun, 6 Nov 2016 17:02:02 +0000 (+0200) Subject: posts: 052, 053 X-Git-Tag: v0.9~4 X-Git-Url: https://git.mogosanu.ro/?a=commitdiff_plain;h=c82b73d4148ed91cd7b9eb4ec1df071900807e97;p=thetarpit.git posts: 052, 053 --- diff --git a/posts/y03/052-on-the-unambiguous-usefulness-of-tools.markdown b/posts/y03/052-on-the-unambiguous-usefulness-of-tools.markdown new file mode 100644 index 0000000..885e54f --- /dev/null +++ b/posts/y03/052-on-the-unambiguous-usefulness-of-tools.markdown @@ -0,0 +1,122 @@ +--- +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 diff --git a/posts/y03/053-i-wrote-a-blog.markdown b/posts/y03/053-i-wrote-a-blog.markdown new file mode 100644 index 0000000..4a78783 --- /dev/null +++ b/posts/y03/053-i-wrote-a-blog.markdown @@ -0,0 +1,107 @@ +--- +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