Elia Scotto

A conversation between two human beings

Fri, 24 Jul 2026 13:34:50 GMT

import QuoteBack from "../../components/QuoteBack.astro";

Here is Kurt Vonnegut telling his brother to show his experimental art in public and to use his face, because “pictures are famous for their humanness, and not for their pictureness”.

Frequently, when I open a book for the first time, I encounter a new author. I need to know something about them: where and when they lived, what they looked like, what they did besides writing, and what else they wrote. I need to have an idea of the kind of person who is going to tell me a story, because understanding a book often requires me to ask why the author wrote it. What was their purpose?

It’s a bit the same when I read an article on a blog or look at an open-source project. I want to know the human behind it and read something brief about the author.

Tom is right. At a time when the internet is filling up with artificial content, it is even more important to put ourselves out there rather than remain anonymous. Show that you are real, and give others a reason to trust you before asking for their attention.

Introducing a new format

Fri, 24 Jul 2026 13:30:48 GMT

I decided to add a new section for short notes that don’t deserve an entire post.

I’ll mostly use it to share thoughts and interesting links, the kind of content that usually works well on social media. Since I don’t use socials much, I’d rather save those things here, where I have full control over them.

I’ve also updated the RSS feed page, splitting the content into multiple feeds. I’ll add a new one that includes these notes as well, for the most devoted readers.

One Tool to Read Them All

Thu, 23 Jul 2026 00:00:00 GMT

Reading some of the feedback on my recent article about reading more books made me realise how much the tools we use influence the way we read. One observation in the article was about replacing the time spent on your phone with a book and making your phone look boring to help you do that. It’s easy to pick up a phone and scroll, so it should be easy to use it to read more. So why don’t people use it to read books? Because a phone is a pocket computer designed to distract users, a book is a boring technology designed to focus their attention.

I’m satisfied with the tools I have for reading books. Unfortunately, I can’t say the same for reading online. After all these years, I still haven’t found a single tool that brings together content discovery, following, reading, and exploring a website’s archive.

My wish for a perfect online reading experience starts with discovering content. I want to find interesting material to read, and since time is always limited, I want it to be filtered according to my interests and ranked in a transparent way that I can directly influence. Then, when I find a good article, I want a good interface to consume it. Since the reading experience varies from one website to another, I want a clean interface designed to keep me focused. I also want to be able to highlight passages and take notes, to help me remember and make reading more rewarding. I’d like a way to keep track of the blogs I follow and get notified when they publish new content. Lastly, I want a tool that treats older content as relevant as newer content. A tool that doesn’t force me to prioritise the latest article.

This last point is really important to me, since I haven’t found anything yet that tries to solve this problem. Relevant content can be found in the entire archive of a blog, not just in the latest posts. Just as I reach for old books considered classics because they have stood the test of time, I often find articles published years ago still relevant. But to discover those articles, I have to rely on other people’s recommendations or hope that the website I’m visiting has an archive page. Without either, old content could stay buried forever on the web.

Most of the tools and platforms we use are designed to show content sorted by publication date, as if it has to be fresh to be worthwhile. And it’s not always an algorithmic decision. Often, it’s simply how the technology has been designed. For how I like to read, the date is just one of the factors that contributes to the value of an article. In some fields, I might prioritise recent content. In others, I’d prefer something that has remained relevant for years, since time can be a sign that an idea has held up. I would like a boring technology that makes reading online a more focused activity, where content is valuable regardless of its novelty. A tool that doesn’t force design decisions or hide content behind algorithmic selection.

Discovery

The most common solution to fix the discoverability problem is the feed. It’s the algorithm that decides what content users see on the social media platforms. It helps people find information relevant to their interests and tailor the platform to their needs. The issue is that users have no control over the algorithms. They don’t know why certain content is shown to them, and they cannot directly influence the choice.

One system I’ve found effective is link aggregators, because they rely on simpler algorithms and usually have a clear interface. I mostly use Hacker News to find new blogs and relevant content in the tech fields. The most interesting articles are ranked daily by the community, where I can contribute directly with my votes and join discussions using the comment system. But when I have to find content unrelated to technology, I don’t have a valid alternative. I have to resort to social-media, video platforms, search engines, hoping that they will do a good job at choosing what I’m looking for.

Following

The concept of feeds was already used to deliver content before social media. RSS feeds have been used to follow websites and blogs since the 2000s. Users can subscribe to a website by adding its feed to an RSS reader and get notified whenever something new is published. The main distinction from social media algorithms is that RSS feeds are not a content discovery mechanism, but a subscription system. Users control which publications they subscribe to, rather than relying on algorithms controlled by platforms.

What I like about RSS is that it keeps track of the blogs I follow, but beyond that the experience is inconsistent: some feeds contain full articles, others only previews, some include years of archives, and others just the most recent posts. On top of that, RSS readers are designed to prioritise new content, emphasising unread counts and showing the newest articles first. Using RSS feeds might free us from the algorithms, but not from the persistent feeling that we need to keep up with whatever is new.

RSS apps let users read articles without distractions. But in doing so, readers may never visit the authors’ websites. They might miss features not available in the RSS reader, and their visits might not count for the website’s analytics. Over time, this can end up giving authors less incentive to improve the reading experience on their websites.

Reading

To improve my reading experience, I rely on read-it-later apps. Instapaper is my favourite so far. It offers a clean and consistent interface across different websites, with useful features like highlights and notes. I’ve saved hundreds of articles over the years, and it’s quite handy to save an article on the desktop and read it later on the tablet or the phone. It works by grabbing the page I’m visiting right now, so if I can read it, Instapaper can likely read it too. The problem is that it does not contribute to content discovery, or following either, since it doesn’t track updates or notify me when new content appears, or help me find more content.

Centralised platforms

Some startups tried to address all the challenges together, creating publishing platforms on the web. One example is Substack, which offers most of the tools needed to write, to read, to find content and even allows users to escape the algorithmic feed trap with personalised newsletters. That said, the price that readers and writers have to pay for the platform is giving up control over the space where they put the content.

If all online content gets centralised on a single platform, users will become dependent on it, having to accept whatever product decisions the company might make. There would also be less individuality than there is on the small web, where bloggers and passionate people customise their own websites, potentially controlling every single detail of them. Finally, the incentives these platforms create still push authors to constantly produce new content rather than focus on creating something refined and durable. They still have algorithmic feeds and email marketing that make new content more important by design.

For now, my online reading remains scattered through many apps and platforms. However, I imagined a solution that has the potential to unify a few of the components of reading online discussed above. It does not have to be another platform or app, but rather something that we all already use to access the internet; the browser.

Centralised platforms tried to solve the integration problem by putting all the content into a single interconnected system, which is exactly what the web already does. And the web also already partially solved content discovery, since search engines, social media, recommendation platforms and link aggregators are already playing a part. The solution in this case is not to look at the web itself, but observe the problem one layer up. It has to live in the interface we use to access the web. The browser is the layer that sits between readers and independent websites. Modern browsers render pages perfectly, integrate bookmarks, can grab RSS instantly, and most of them already integrate a reading mode for articles. Connecting these components together is the key to creating a perfect tool to read online, without removing the website itself from the experience. A browser could let me follow a website directly, notify me when it publishes something new, give me a clean place to read it, and let me browse the entire archive without treating the newest articles as inherently more important.

We saw a recent wave of new browsers that mostly offered UI makeovers on top of existing engines (Blink and Webkit). Maybe a differentiator for the next browser, instead of improving usability or privacy, might be to help people to follow and read more valuable content online.

Curious to hear your thoughts.

A Road to Lisp: Which Lisp

Fri, 17 Jul 2026 00:00:00 GMT

Most programming languages evolve as a single language. Python, Java, Javascript, C++, have new versions and standards, multiple implementations, but they still remain the same language. C and C++ can be compiled with GCC or Clang, Python can be compiled with CPython or PyPy, the same JavaScript runs in both Firefox and Chrome, and Java programs can run on JVM or GraalVM.

Lisp is not like that.

The Wikipedia page lists more than 20 different dialects, which means there are many variations to choose from. That’s because Lisp is a family of programming languages. They share the same fundamental syntax but differ in their operators, semantics, standard libraries, and language capabilities.

One of the main concerns Lisp beginners have is which dialect to learn first. I see this question frequently asked in online forums. The answer is that the dialect matters, but not as much as a beginner might think. Learning Lisp is about learning a new type of programming. A new way of thinking about problems using code. You will learn the fundamental concepts with any dialect. Then, once you have learned one, it will be relatively easy to switch to another.

I will briefly present the most relevant dialects that are actively used and maintained. I’ll try to highlight their strengths and weaknesses to help you overcome your indecision and pick one to start your Lisp journey.

If you are a beginner, many of the concepts in this article might be completely new to you. Don’t worry too much about them yet. When I was a beginner, I found many of these concepts fascinating and they pushed me to learn more about the Lisp world.

Common Lisp

Abbreviated as CL, it is the most mature and comprehensive of all Lisp dialects. It’s considered the old-school Lisp, since the language — I will call it a language from now on — was standardised in 1994 with a formal ANSI specification. Thanks to this standardisation, there are multiple implementations of Common Lisp targeting different platforms and use cases.

The most famous implementation is SBCL, which compiles directly to native code. It is fast, open-source, and compatible with modern hardware. With it, well-written Common Lisp code can achieve performance comparable to C and Rust. Because SBCL optimises heavily, it compiles a bit more slowly than other implementations but generates some of the fastest code in the Lisp family.

When I said above that Common Lisp is the most comprehensive dialect, I meant that it offers the broadest set of features among all Lisps. It provides a large amount of functionality out of the box, much of it defined directly in the standard. For example, CL has functions for controlling compilation and evaluation from within the language itself (COMPILE, LOAD, EVAL, COMPILE-FILE, and others). This means that I can use these functions in my code or at the REPL to tell the Lisp process to compile a function, load a file, or evaluate some code. CL also provides DISASSEMBLE, which lets you inspect the machine code generated for a compiled function.

Common Lisp has a condition and restart system, which is one of the most powerful way I ever saw to debug and inspect programs. If a condition occurs during execution, the Lisp process might stop and let you inspect the state of the program and its variables at that point in time. You can then choose to restart the program and maybe retry the operation, or ignore the condition and continue execution. This is also possible because the Common Lisp REPL is deeply integrated with the running system. If your program fails on a remote server, you can connect to its REPL and inspect the live process to understand what went wrong.

Common Lisp supports all major programming paradigms, like functional, imperative, metaprogramming, and object-oriented programming. It offers one of the most advanced object systems, called CLOS, which supports features such as multiple dispatch and generic functions. This makes OOP more flexible than in common object-oriented languages such as Java or C++. It is also worth noting that Common Lisp is dynamically typed but has a rich and expressive type system with optional type declarations.

Standardisation means that the language is stable. The ANSI Common Lisp from 1994 is still the one in use today. Because of it, lispers rarely fall victim to backward incompatibility, and old Common Lisp code often still runs perfectly today. For example, if you go through old Lisp books such as PAIP by Peter Norvig, published in 1991, you’ll find that much of the code still runs on modern implementations. With Common Lisp, you encounter far fewer of the incompatibilities typical of languages like Ruby and Python. Even Common Lisp libraries that haven’t been updated recently will often still run fine on your system because they don’t need to be continually adapted to new versions of the language.

Common Lisp lacks some conveniences that have become common in newer languages, such as concise literals for a wider variety of data structures, persistent immutable collections, lazy sequences and built-in general-purpose pattern matching. Common Lisp was designed in the 1980s by consolidating several existing Lisp dialects into a single language. Its designers chose to retain much of the syntax and patterns of those older dialects, making sure that existing Lisp programmers could adopt the language without having to learn a completely new syntax.

Common Lisp doesn’t have a central direction or corporate sponsor. The community is relatively small and spread across several implementations, projects and communication channels. It’s mostly made up of volunteers who help keep the language alive. It can be a bit difficult to find guides and help: tutorials are often either too simple or too advanced, and documentation is not always easy to find.

It’s currently used in quantum computing at Rigetti Computing, and has been used at Grammarly for its core grammar service and also powers Google Flight Search. Worth mentioning is Kandria, an open-source video game released on Steam and written entirely in Common Lisp.

An interesting fact: Paul Graham originally wrote HackerNews in a custom Lisp dialect called Arc, based on Racket. Today, Daniel Gackle (@dang) reimplemented it in Clarc, a Common Lisp implementation of Arc that runs on SBCL^1, serving around 10 million pages per day.

Where Common Lisp shines

CL compiles to native code on all major operating systems and can achieve fast execution, at the cost of slightly slower startup times, so it’s great for long-running processes. It offers one of the most powerful REPLs among Lisp dialects and can be considered, despite its steep learning curve, one of the fastest languages for writing solid software in a short time.

CL shines when you need to do research and prototyping with quick iterations, as in quantum computing, or when the specifications aren’t fully defined yet and change frequently, requiring the software to adapt quickly, as in startups. Paul Graham wrote a famous and inspiring article about how Common Lisp helped his internet startup beat the competition.

Learning resources

A good starting point is A Road to Common Lisp by Steve Losh, which inspired me to write this series. One of the most accessible books for beginners is Practical Common Lisp by Peter Seibel, which is available entirely online. It’s the best introduction to the language I’ve read, as the most important concepts are neatly separated into chapters. A more playful introduction is Land of Lisp, which uses funny characters and comics to teach programming through games. A more advanced book that I enjoyed is On Lisp by Paul Graham, which is entirely dedicated to macros.

The best IDE support for CL is Emacs + Sly/Slime (Doom already has support for it) or Vim + VLime. A weaker alternative is VSCode + Alive.

One of the best resources for beginners is The Common Lisp Cookbook, which has many up-to-date tutorials. For references and libraries, the Awesome-CL list is worth a look. I also printed my own copy of the Common Lisp Quick Reference booklet, which can be faster than finding information in the CL HyperSpec.

Clojure

Rich Hickey created it during a sabbatical year, frustrated by clients refusing to let him use Common Lisp instead of Java and C# because they were concerned about compatibility and maintenance issues. So he decided to write a new Lisp language targeting the JVM, allowing it to access everything the Java ecosystem had built over decades and making it a practical language from the start. The deal is that Clojure provides the language, while the host platform — the JVM — provides the runtime.

Clojure compiles directly to JVM bytecode, which means it’s compatible with any codebase that runs on the JVM (Java, Kotlin, Scala). This compatibility means that Clojure can coexist with other JVM languages in the same codebase, use Java libraries directly, and access all the features the JVM offers, such as OS portability, garbage collection, a fast and optimised runtime, and so on.

Rich Hickey chose to target the JVM so that he didn't have to reinvent the wheel and build a new compiler for Clojure from scratch. Instead, he focused his efforts on reading research papers on language design and data structures, bringing some of the newest and most effective ideas into the language.

The language at its core is composed of pure functions operating on immutable data structures. Instead of making mutable objects the primary way to represent changing state, it provides explicit mechanisms such as atoms, refs and agents for managing change. This design choice makes Clojure a functional programming language. It supports object-oriented programming, but replaces class-based inheritance with abstractions such as protocols and multimethods. Also the syntax is more modern than Common Lisp’s, with richer literals, destructuring, and overall more compact code.

Clojure also comes with several new features. Its persistent data structures use structural sharing, making immutable updates efficient. It also uses lazy sequences, which allow computations to be performed only when their results are needed. It has strong support for concurrency through constructs such as atoms, refs, agents and futures, and provides records and custom data types when more structured data is needed. EDN (Extensible Data Notation) offers a simple extensible data format based on Clojure’s literals, a better lispy alternative to JSON, YAML and similar. Clojure doesn't have types, but clojure.spec can be used to describe, validate and generate data without introducing a static type system, useful in large applications.

Rich Hickey designed Clojure with the intention of prioritising stability, similar to what standardisation did for Common Lisp. Even though the language is actively developed, you don’t need to expect major deprecations when updating to a newer version, since the maintainers preserve backwards compatibility and mostly add new features through core libraries.

Since Clojure is designed to be hosted on other platforms, it can be ported to other runtimes, like the JavaScript engine that runs in your browser. ClojureScript is a Clojure compiler that targets JavaScript rather than the JVM, so the same language can run on both the server and the browser. This means that Clojure can be used as a full-stack language.

The JVM integration is great, but it comes with some trade-offs. Error messages are contaminated with a lot of Java implementation details and aren’t always self-explanatory, so stack traces are not necessarily helpful when debugging issues. Java profilers like YourKit are compatible, but even there you will see a lot of Java classes, and it can be hard to map them back to the code you wrote.

In general you don’t need to know Java to learn Clojure. I didn’t know Java when I started and never had substantial problems because of that. However, knowing how to tweak the JVM can be helpful when doing performance tuning on the server.

The community around Clojure is small but active and happy to help newcomers pick up the language quickly. It’s known as Clojurians and mostly hangs out on Slack, where you can also collaborate on open-source projects and find job opportunities.

Clojure is actively used by companies and startups around the world, and it’s probably the most widely used Lisp in production. Some big names include Nubank (one of the largest fintech companies in Latin America), which acquired Cognitect (the main sponsor of Clojure’s development), as well as Walmart, Netflix, Apple, Salesforce, Amazon, Cisco, and Grammarly.

Where Clojure shines

Clojure shines in large software systems where the workload consists of a lot of data processing, or more broadly, anywhere you might previously have picked Java. Code can be written and tested quickly through continuous iteration thanks to the REPL, making the language suitable for delivering reliable solutions in less time. Its immutable design helps eliminate some of the hardest concurrency bugs, while its functional orientation guides programmers towards writing programs as a series of data transformations.

Clojure is great in fields where operations need to happen quickly and often involve processing large sets of data, such as finance and trading. It’s also great for startups solving domain-specific problems with complex logic, since the language’s extensibility allows it to be modelled around the problem.

Learning resources

To give Clojure a try, you might want to check out Try Clojure, then solve some exercises like the Clojure Koans, followed by 4Clojure for more advanced stuff.

The official website offers some of the most curated material you can find, with great explanations of all the core features and the motivations behind the design choices that make the language special. Clojure also has one of the best documentation websites I’ve ever found for a language. All the core library functions come with docstrings, and the community has added usage examples, so you can quickly grasp what each function does.

The best pitch for the language is Clojure Distilled. It’s probably one of the shortest explanations of what Clojure has to offer.

After the release of Clojure, Rich Hickey became famous for a series of talks about software design, in which he shared his deep expertise in fundamental topics like simplicity in software design, state and time, databases, concurrency, and language design. Some of his best talks — Simple Made Easy, The Value of Values, Hammock-Driven Development, Are We There Yet?, and Design, Composition, and Performance. I highly recommend spending some time watching them, whether you choose Clojure or not.

Some good books are Clojure for the Brave and True by Daniel Higginbotham, which is free to read online and good for beginners. The one I bought is The Joy of Clojure, which is recommended for programmers who come from OOP languages like Java.

For editors, VSCode has Calva, a complete and rich extension for Clojure. If you use Emacs you can use Cider, plus there are extensions available for most editors/IDEs.

Racket

Racket is a modern dialect descended of Scheme. While other Scheme dialects are generally small languages, Racket has evolved into a fully featured language with its own unique features.

The code is compiled on every major platform and the language has been used in a lot of fields to create web applications, graphical interfaces, database integrations and mostly to quickly develop tools with graphics.

Racket is language-oriented, which means it’s designed for creating new programming languages. Every source file begins with #lang, which defines the language used by that module. You can create entirely new languages with their own syntax and semantics, while still using the Racket ecosystem underneath. Other Lisp dialects can easily build DSLs, but they are tied to Lisp. Racket advances the concept by making it easy to define completely new languages, without requiring them to use Lisp syntax.

Racket also comes with a wide range of features. It includes libraries for cross-platform GUIs, web servers, concurrency and parallelism, regular expressions, pattern matching, classes and objects, and an FFI for calling C code. Its package manager is integrated into the ecosystem, and a large collection of libraries is immediately available. Compared with other Lisp dialects, there is generally less setup required before you can start building something substantial.

Racket offers an advanced macro system, providing the same kind of macro support as other dialects, plus hygienic macros. Hygienic means that identifiers introduced by a macro don’t accidentally capture those in the surrounding code. This makes macros safer to write, especially for beginners, that don’t have to rely on gensym like in the other dialects.

Static typing is supported with Typed Racket, a typed variant of the language that lets programmers add type annotations and have their code checked before execution. Typed and untyped Racket modules can also work together, so typing can be introduced where it is useful without requiring an entire program to be rewritten.

Even though Racket comes from the Scheme tradition and has strong functional programming roots, it supports multiple paradigms. Programs can be written using imperative programming, objects and classes, functional techniques, and metaprogramming.

The language installation comes with DrRacket, a great IDE with everything ready to use the language, available on all major platforms. It combines an editor, REPL, and debugger, in a single programming environment for writing and testing Racket code.

The main downsides are its small ecosystem and limited use in the industry. There are fewer libraries, projects and jobs compared to more popular languages. Performance and deployment can also be weaker points, especially compared with other compiled dialects.

Where Racket shines

Racket shines when designing new programming languages, building compilers and interpreters, or experimenting with new language features. This makes it particularly popular in computer science education and university research. Also, since it’s language-oriented, it’s a great choice when a program needs to provide a simple DSL, for example for customisation, without forcing the user to use a Lisp dialect.

Racket is ideal for prototyping, scripting, and projects where having a comprehensive set of libraries and development tools immediately available is important. It’s worth noting that other dialects offer GUI support through external libraries and wrappers, while in Racket it is available out of the box.

Learning Resources

Racket has a rich website with a lot of helpful information. Important resources for beginners include Quick: An Introduction to Racket with Pictures and The Racket Guide, which is the complete guide to the language. Also worth mentioning is Beautiful Racket by Matthew Butterick, a visually curated guide to the language written by a passionate contributor. If you’re looking to write a compiler, check out this course using Racket.

The best resource available for Scheme is SICP, also known as the Wizard Book. It’s not only about Lisp, but it’s a great book for learning the fundamentals of programming and programming languages. It’s also worth mentioning a rather unusual book, The Little Schemer, which consists of a long series of questions that forces the reader to think before looking at the answer on the page.

Special Mention

Elisp

Elisp is a specialised dialect that’s part of Emacs and is used to customise the editor. It’s an old Lisp dialect that comes with quite a few limitations, but it’s probably one of the best practical uses I’ve ever found for Lisp, beyond using it as a general-purpose programming language. It’s used to customise and extend the functionality of Emacs, since much of the editor itself is written in Elisp. By evaluating Elisp code inside it, you can change how Emacs looks and behaves in real time, without requiring a reload.

Learning resources

An Introduction to Programming in Emacs Lisp is freely available online. Another useful resource is Emacs Lisp Elements by Protesilaos Stavrou, an active Emacs contributor and advocate.

Syntax comparison

We can use a simple instruction interpreter to show some of the syntactic differences between the dialects.

(defun calculate (instructions)
  (loop with result = 0
        for (operation value) in instructions
        do (setf result
                 (case operation
                   (add      (+ result value))
                   (subtract (- result value))
                   (multiply (* result value))))
        finally (return result)))

(calculate '((add 5) (multiply 3) (subtract 4))) ;; => 11

In Common Lisp, I used the LOOP macro to iterate over and destructure each instruction, then perform the operation by updating local state. Notice that it carries an accumulator (result) through the sequence, essentially doing the same job as a reduce.

(defn calculate [instructions]
  (reduce
    (fn [result [operation value]]
      (case operation
        :add      (+ result value)
        :subtract (- result value)
        :multiply (* result value)))
    0
    instructions))

(calculate [[:add 5] [:multiply 3] [:subtract 4]]) ;; => 11

In Clojure, I used a reduction over the sequence of instructions. Notice that it doesn’t use or update any local state, since the reduction uses immutable accumulation. I also used some syntax that is specific to Clojure, such as vectors [] and keywords like :add, and destructured the contents of each vector with [operation value].

(define (calculate instructions)
  (for/fold ([result 0])
            ([instruction (in-list instructions)])
    (match instruction
      [(list 'add value)
       (+ result value)]
      [(list 'subtract value)
       (- result value)]
      [(list 'multiply value)
       (* result value)])))

(calculate '((add 5) (multiply 3) (subtract 4))) ;; => 11

In Racket, we use for/fold to iterate over the instructions while carrying the result from one iteration to the next. We also use pattern matching with match to destructure each instruction and identify the operation at the same time. For example, (list 'add value) matches a two-element list whose first element is the symbol add and binds the second element to value.

Which one to pick?

To summarise the above:

Clojure gives you modern syntax, functional programming and immutable data structures, great tooling and libraries, an almost drop-in replacement for Java, a full-stack language, a strong community, and maybe even a job.
Common Lisp gives you native compilation, high performance, the most powerful REPLs, multi-paradigm programming, and a stable, battle-tested language.
Racket gives you a feature rich language, a great IDE for beginners, a cross-platform GUI, a powerful platform for building new languages and DSLs, easily approachable for students.
Elisp gives you the ability to extend and customise Emacs.

For most programmers looking for a practical and elegant Lisp they could use professionally, Clojure is probably the safest first choice.

If you want to experience the traditional Lisp development model at its fullest, you want native compilation without rely on JVM, an exceptionally interactive environment and a huge language, choose Common Lisp.

If you are a computer science student, interested in compilers and programming-language design, or if you need a quick way to write tools or need an easy way to use a cross-platform GUI, choose Racket. This is probably the easiest to start with between the dialects.

If you have any questions of feedback, please send me an email.

Confessions of an emigrant

Wed, 15 Jul 2026 00:00:00 GMT

Today at 3 pm I officially became an Australian citizen. I felt it was a formality, since I already had a permanent residency. But when I was sitting in the city hall, together with others that were receiving the citizenship as well, I reflected about the last few years I spent abroad and what it actually means being an emigrant. Looking back at my past, it seemed obvious that, sooner or later, I would have moved to another country.

It all started in the early years of my adulthood, when I had the chance to fly to and work in Silicon Valley three times. During that period, I also moved to Turin to study at the university, in a much bigger city than the small town where I grew up. Something started changing in me back then. I appreciated the new level of freedom that I gained by leaving my parents' house, and I developed a certain thirst for what I believed the rest of the world had to offer. The thought of a future in my small town, seeing the same places, facing the same issues, having my entire family around all the time, and the feeling that certain things there were too slow to change, was frightening me. I didn’t want to feel stuck in that place.

Also I wanted to be challenged, I wanted to confront difficulties and experience new surroundings. I believe there are few experiences as eye-opening as living for months, or even better, years, in another country.

I wasn't sure where or how I would move, but I knew I could find a way if I truly wanted to. On Facebook I can still see the groups I joined at the time to get a genuine, unspoiled insight into what life was like in different cities: “Italians in London”, “Italians in Valencia”, “Italians in Berkeley”, “Italians in Amsterdam”, “Italians in Dublin”. I was naive. I was trying to find something familiar that would soften the culture shock I knew would hit me once I stepped out of my comfort zone. I was trying to play it safe, not knowing what to expect.

In those Facebook groups I still see many compatriots every day who ask what life is like there, how much it costs to live, whether there are enough jobs, and whether it's worth moving their entire family to the other side of the world. I can see my younger self in their worries and their hope for a different future. They don’t know yet what emigrating really means.

What I also find in those groups is the constant clash between those who defend their home country and those who criticise it, praising how much better their lives abroad are. This might seem like a typical social media interaction, but I think there's another side to the story that people are overlooking. When you move abroad, you're expected to do better, to build a better life. Otherwise, why would you do it?

It's a sort of unspoken expectation that every emigrant has to live up to, especially when interacting with people from back home. You don't move abroad to live a life worse than the one you had at home. You have to “make it”, whatever that means. You can't really talk about your struggles, the loneliness, the career setbacks, the sense of cultural isolation. Is not that simple to say that you miss what you left behind. Many emigrants end up hiding the reality of life abroad. They wear a mask to live up to the expectations of their family, friends, and the compatriots they left behind. They no longer live at home, they abandoned the land. The everyday problems of their compatriots are no longer theirs. They are in a liminal space between two countries, no longer physically present in one, but not yet belonging to the other.

The truth is that life abroad is never easy, nor is it necessarily better than what we had at home. The job situation can be a rollercoaster. It wasn't easy to tell my parents that I was picking fruit when, just a few months earlier, I had a high paying office job. It took me a while to get back to my original career, and in the meantime I had to work in less pleasant jobs where I was overqualified or overworked. I had to fill those gaps on my CV with something, because recruiters don’t care about immigration policies. Australia is a welcoming country, and its people are kind and generally open-minded, but I still feel like an immigrant every day. I had to adjust how I speak and behave, and I’m still working on softening my accent in order to fit in. I still carry the contradiction of being someone who “made it” back home while still being perpetually viewed as an outsider in my new country.

I have missed important moments in the lives of the people I care about. My sister had a child, and I am not there to watch my nephew grow up. My school friends are getting married, and I’m not there to celebrate with them. I will not share some of their happiest moments, and they will not share mine. One day, my parents might fall seriously ill, and I might not be there when they need me most. These are costs I had to be willing to accept.

The culture that shaped my childhood cannot be found overseas. I can join a small community of expatriates, buy imported products and spend time cooking a nice meal. I can find book in my language, teach my kids Italian while we visit my relatives. But I know it will be hard to transmit the same culture. Whatever home was for me cannot be bought online or shipped overseas in boxes. If I want to feel it again, I have to go back to it.

I've had the opportunity to meet several emigrants in my life, mostly Italians like me, because we tend to gravitate towards one another, as if our shared culture acted like a magnet. Some of them returned to Italy after years of living overseas because they never found a reason strong enough to stay. Some of them kept moving from country to country before eventually returning to Italy when the right opportunity arose. Some people built a life abroad, advancing their careers and starting a family, while others are still trying to figure out where they belong. It's impossible to predict what life abroad will be like for someone else, or how well they'll cope with its challenges.

After all this, one last confession, one that's usually hard for an immigrant to admit. No matter how successful you become, how much money you make, or how much your life improves by moving overseas, there will always be moments when you feel a sense of regret, when you'll be tempted to reply to those people on Facebook and tell them, “No. Don’t leave. It’s not worth it.” Then those moments pass, and life goes back to normal. They are simply part of choosing one life over another.

Today, becoming an Australian citizen made that choice feel more permanent than ever. I don't know whether Australia will ever feel like home in exactly the same way Italy does, and perhaps it doesn't have to.

And now it's time for me to celebrate. For the occasion, I'll have a chicken parmi with gravy. Wish me luck.

How to read more books

Sun, 12 Jul 2026 00:00:00 GMT

I've read roughly a book a week for a few years, and I can tell you it's doable. I didn't always read this much. When I started, I read fewer than ten volumes per year, but making it a goal made me switch gears and achieve what I once thought was impossible. I want to explain what I did to become a prolific reader, and what I learned in the process, so that, with a bit of effort, you can do it too. I promise, it will be worth it.

First of all, you don't have to make time to read. What you need to do is read every single time you are not doing something else. In today's world, most people pick up their phones as soon as they get a moment of inactivity. Serious readers pick up their books instead. So an effective way is to replace the time you spend in front of a screen, like PCs, smartphones, and TVs, with time spent reading a book.

This is probably the most difficult part. I had to remove all social media and streaming apps from my iPhone. I removed Instagram, YouTube, Facebook, etc. When I started, I found myself picking up the phone and immediately noticing that something was missing, since the only things left to do were to check the weather and read boring emails. After a few days my brain started remapping itself, and I felt less pressure to immediately reach for my phone as soon as I had nothing to do. I also wear a cheap analogue watch so I can check the time on my wrist and I don't have to reach for my phone.

Once you remove these distractions from your smartphone, you might find yourself a bit uncomfortable with having nothing to occupy your mind for ten minutes. This is the perfect time to boost your reading habit. You need to make sure you always have a book with you everywhere you go. I usually read a few pages as soon as I wake up, and do the same before falling asleep. I read while cooking lunch or dinner, or while eating breakfast. I love using public transport, especially trains, because I get time to read while someone else is driving for me.[^1] I always have a book with me when I go out with my partner, even if I don't usually end up reading it. If she has to run an errand and I have to wait, I don't waste time with nothing to read. I have become good at walking my dog while reading — I even got complimented for that by a stranger — and I make sure I never go to the bathroom without a book.

“I love the smell of book ink in the morning.” — Umberto Eco

Carrying a book wherever I go can become problematic, depending on its size. The best solution I have found is to use an ebook reader. They are thin devices that can fit in a pocket and are able to store hundreds of books. For a reader, an ebook reader might be one of the best inventions ever, considering how expensive books have been throughout history and how difficult they have always been to carry around. Ebooks, by contrast, are cheap. Moreover, you can have a backlight for reading in the dark — it doesn't strain the eyes — and you can highlight text, take notes and get definitions for words. However, it's not really a replacement for a book. After a while, always reading on an ebook reader feels like reading the same book, even if the story changes. I like to alternate digital books and physical ones, and I always prefer paperbacks since they are easier to carry around and cheaper to buy.

I tend to read multiple books at the same time, since having only a single option can be boring. Sometimes I get so into a book that I put the others on pause because the story is taking up all my attention, but in general I like to have a few books that I read in parallel. I generally mix fiction and non-fiction to have a broader choice.

What to read is a difficult question. I once read a phrase somewhere that puts it quite well: “read what you like until you like to read.” My suggestion is to read broadly, changing genres and subjects, because there are well-written books in every genre. Varying the topics can expose you to different perspectives. And sooner or later, you will understand which genres you like more.

“It is foolish to think that you have to read all the books you buy, as it is foolish to criticize those who buy more books than they will ever be able to read. It would be like saying that you should use all the cutlery or glasses or screwdrivers or drill bits you bought before buying new ones.” — Umberto Eco

Another secret is to not be scared of quitting books. I definitely start way more books than I finish. But I don't consider an unfinished book a failure or a bad book. I think that certain books require the right time to be fully appreciated. So if I don't finish a book today, I might try reading it again in the future. I still remember having abandoned Siddhartha by Herman Hesse at least three times after the first few pages, before finally finishing it and considering it one of the most formative books of my life. Somehow I wasn't ready for it the first time, and I had to wait for the right moment to fully understand it. Also, I believe there are way more bad books out there than good books. If you feel that you are not enjoying a book, it feels boring and makes you think you are wasting your time, just close it and move on. I have closed books by authors that I loved, because they weren't as good as the rest of their work.

If you are a serious reader, you need a library with physical books. So try to stack copies of books on your shelves for later. When I buy new books, it is mostly because I need a specific one I cannot find otherwise, or because I want to support local independent bookshops. However, I generally buy more used books than new ones. I usually find them in the book section of used stores, at markets, book fairs, and sometimes in the book boxes that I find around the city.[^2]

An effective method to push yourself to read more is to set some goals. You can pick a reasonable number of books for the month or the year and try to reach it. Tracking progress is a well-known trick used to form new habits. Goodreads, for example, has what's called the Reading Challenge, which helps you keep track of how many books you read in a year. I found it motivating to put in the effort to stay on track with the number I wanted to read. However, counting the volumes is not a healthy way of reading. It's much better to read great books and take the right amount of time to understand and reflect on them rather than rushing to finish books just to increase the final count. You need to enjoy the process and get a good outcome from your reading.

Writing a review is also a great method to make a book stick in your memory. Taking highlights and notes while you're reading is a good thing, but revisiting them alongside your thoughts in a written document is something different. Reviewing books is a great way to become better at understanding what the messages contained in the books are and what the key elements of the story are. In addition, if you like writing, it's a good reason to practise.

One of the duties of a serious reader is to find what to read next. I always have a long list of books to read, but I don't stick to it all the time. I like to be immersed in something new and discover new authors or genres. I usually use two things: Goodreads and YouTube. The first one helps me form an idea of a book before I get to reading it, thanks to reviews and comments from people I follow. YouTube, on the other hand, is great for listening to book reviews to get recommendations. There are many great channels out there, and I watch quite a few of them. One of my favourites in English is Better Than Food, which has reviewed books for more than a decade.

What inspired me to try to read more was this video, where Max Joseph explains that becoming a serial reader is just a matter of making a daily habit of reading a few pages, with surprisingly good results. Also, Ryan Holiday — a famous author — has recently published a good guide on how to read more books with his own tips and tricks.

One last recommendation: avoid hacks. Avoid speed reading. And don't try to force yourself to increase your reading speed. It will come naturally the more you read. Avoid summaries and summary services. It might be okay to use them after you read a book to make sure you didn't miss some parts, but reading a summary does not equal reading a book. Avoid audiobooks too. Big corporations want to grab your attention by trying to market audiobooks as books for busy people, but don't fall into the trap. A book is just boring black text on a white page because that's how it's meant to be consumed, and it requires your full attention. Listening to audio while cooking or cleaning or whatever you do is not the same thing; you are not fully focused on the content. Also, reading is faster than listening, so use your time wisely.

[^1]: I consider driving a huge waste of time. Sometimes it can be fun and adventurous, but I think life is too short to drive to work every day. [^2]: In Australia, some people put a wooden box with a door in their front yard and fill it with books, so that everyone passing by can pick one up or leave their own books for other readers.

Blog Engines I've Used

Sat, 11 Jul 2026 00:00:00 GMT

Since I got my first internet connection as a kid, I’ve spent more time setting up new blogs than actually writing them. It’s not surprising. Configuring the platform and adding features was the whole point, the fun part. Writing never interested me at the time, perhaps because I never felt the urgency to express myself and didn’t have anything relevant to say.

I’ve always used self-hosted solutions and learned the advantages and tradeoffs of using them, so I will summarise here each blog and platform I have used. I might not know much about writing a blog, but I’m sure I know a thing or two about the platforms that make a blog possible.

WordPress

This was the first blog I opened many years ago, and I believe I wrote it in Italian. I was mostly translating some guides from English, or reposting tutorials taken from other blogs or forums. I got a few readers and comments, but it was never a serious project.

WordPress has been the main CMS for a lot of websites for decades, and still today power 40% of the web. In 2006-2008 the community around it was active, and a lot of plugins and themes were released, since PHP, the language that WordPress uses, it’s easy to learn and quick to be productive with. Plenty of guides were available, so creating a blog at the time was a matter of installing WordPress, connecting to the hosting space via FTP using FileZilla, and then connecting a MySQL database to it.

In those years, the LAMP stack (Linux, Apache, MySQL, PHP) was the foundational architecture used by most websites and communities, so it wasn’t surprising that WordPress got so much traction. There were so many plugins and themes that it didn’t take much to put a decent website online. Besides my own blog, I had to install and configure WordPress websites for other people, and every time things went smoothly enough. Even when I had to do some small customisations to a theme, it was quite quick to do, considering that I never learned PHP and my changes were done by guessing and testing.

The CMS that WordPress offers is top notch; I’ve never found one as good since. The editor is decent and includes an instant preview of the articles and theme changes. It’s so easy to use that even your noob uncle who needed a website was able to put one together with images without having to call you over for help.

Also, the plugin library that WordPress offers is large, and the plugin quality is quite decent. Most website owners at the time were worried about SEO, and it was just a matter of installing the right plugins to make sure the website was picked up by Google with the right keywords.

Since WordPress workes with a database, it offers simple integration to add comments to a website, with the Akismet spam filter plugin and other nice features like user login and Gravatar integration.

The main problem with WordPress is that by supporting so many features it became a huge monster, far more than what’s really needed for a simple blog. I started abandoning WordPress when Markdown became popular and static websites had their Renaissance.

Jekyll

After PHP came the Ruby era in 2008. Tom Preston-Werner, after releasing GitHub (written in Ruby) in April, got tired of having to deal with a database in WordPress to host a simple blog and decided to write a new blog engine called Jekyll, also in Ruby.

Jekyll is much simpler to configure and to understand what is happening inside the blog. A new project consists of a configuration file and a folder structure. Posts are simple Markdown files, and the styles use SASS, which at the time was more advanced than plain CSS. The pages are composed of layouts and smaller reusable components. For rendering the pages, Jekyll uses the Liquid template engine, which allow the use of variables, conditionals, and loops alongside normal HTML tags. When my blog was ready to be served, I just needed to run the CLI command to build the project, and the compiled website was saved into the output directory.

Jekyll is a platform that mostly targets blogs. There are many plugins available that extended what is possible to put into posts and how the content is indexed. Plus, GitHub got popular and enabled the possibility to host a website directly on their platform. So publishing with Jekyll is a matter of pushing the updates to the repo, and the continuous integration would then run the build and serve the output directory.

Jekyll served my needs for a longer period than any other platform. It was minimalist compared to WordPress and, in a way, made the components of a blog much more visible and in the hands of the developers, since most files were HTML, Markdown, and SCSS.

Then Ruby lost its momentum and got a bit out of fashion. I have to admit that at the time I didn’t know Ruby well, and a few times when I wanted to change some plugins I ended up not doing it because of the language barrier. I didn’t abandon Jekyll because of that, but because the community itself got a bit smaller and less vibrant, probably because a part of it migrated to other platforms (or stopped blogging).

Org mode publish

When I learned Emacs, I discovered the most advanced file format integration with an editor: org. If you don’t know it, think of it as a more powerful Markdown with a series of shortcuts and extensions that make editing really fast and transform a directory of files into a perfect organisational system for your personal information.

Org comes with a publishing management system, which is a way to export a series of org files into HTML, with certain output configurations for directories and templating. It’s a static site generator that converts org files to HTML, similar to what Jekyll was doing with .md files. Once the project is configured with some Elisp code, saving a file in Emacs and running a command was enough for publishing changes to my Org-mode blog.

Since org is an advanced file format, the publishing came with some nice features too, like title links, dates, and automatic sitemap generation.

The difficulty is that org publish is more a system for converting files rather than producing a blog. So features like layouts, SASS for stylesheets, RSS feeds, a public folder for static files, they all needed a special Elisp configuration to be written and maintained.

It didn’t take me long to adapt some Elisp code to fit my project, but after making a few changes to the directory structure, every time the build was failing and I had to debug what was happening. It wasn’t ideal. Plus, features like image compression or integrating a search would have been hard to implement.

So, as usually happens with complex configurable systems, after having fun customising the whole setup, I got bored, since org publish wasn’t really what I would consider practical for a personal blog. Just my personal taste.

11ty

I finally found a static site generator written entirely in JS, so I wrote my blog in 11ty. It’s another pretty good system for creating static websites.

I found it a bit tricky to find official documentation for certain features, but I was able to integrate and customise my blog exactly how I wanted and write the plugins I needed in quite a short time.

Honestly, I don’t have much to say about 11ty. It’s a good alternative to Jekyll, and it uses Javascript, so if you know the language it becomes easy to customise. It’s actively supported and used on the web, so I recommend checking it out if you are looking for a blog platform.

What got me a bit frustrated is that I ended up having a large JS file with all the configuration required, and when I had to change some structure in my blog — for example, adding support for Italian/English translations to certain articles — the configuration file got a bit bloated.

Astro

Astro is probably the definitive static site generator I’m using today. This blog moved from 11ty to Astro without even being noticeable, and I’ve used it in a few other projects where I needed a static site generator. I’ve even tried using DecapCMS with it, so that a friend was able to write pages and add images directly by pushing to the GitHub repo, avoiding the need for a database.

Astro has pretty much all I want for a blog: asset optimisation, partial hydration with islands, advanced templating, and variable support. Also, Astro uses single-file components to define pages, so that HTML, JS, and CSS that share the same scope are placed in a single file, like Vue does. Pretty neat, and it makes the code easy to organise and reuse. It also extensible using Javascript and offers an high level of customisation and a set of libraries to integrate more features.

What I look for now

After all this, here's what I now consider essential for a blog engine:

support for Markdown, since I write everything in Obsidian
sensible defaults for common features like RSS and asset optimisation
a healthy plugin ecosystem for when I need to extend things
easy customisation

I hope Astro stays around for a long time. I'd rather not migrate again and instead spend that time on what actually matters: the writing.

On Running and Murakami

Fri, 10 Jul 2026 00:00:00 GMT

I’ve been a runner for more than ten years. I started running a few times a week during university because it’s a sport that fits me well. It only requires a good pair of running shoes, it’s not time-consuming, and it can be done everywhere and in any season.

I’ve always been a long distance runner, and most of my runs have been around an hour long. I always find it engaging to go for a long run, where I can distract my mind from the focus of the day. This frequently helps me find new ideas and inspiration, just like I did for this article.

Recently I’ve started running every day, but for a shorter amount of time. The physical benefits remain the same. Two things made me change my habit: first, research suggests that shorter daily run are more beneficial for the well-being, reduce the risk of injuries, and allow the body to adapt gradually. Second, it takes less time. In a busy life, taking 30 minutes a day for your body and mind is not much, while one hour can become more of a burden.

The second thing I mention when I talk about running, after describing what type of runner I am, is the type of shoes. I currently run with the Wave Rider 28, which I bought from the Mizuno store in Kyoto, Japan. I’ve tried other common brands, and while there are differences for the pros, for a casual runner like me they are negligible — and Mizuno are good shoes. I chose them because they are the shoes that the writer Haruki Murakami uses.

Haruki Murakami is the most famous Japanese author alive today. He has written multiple bestsellers that have been translated into more than 50 languages worldwide and have inspired several movies. Other than being a successful author, he’s a long distance marathon runner and wrote about his experience with running in a book called “What I Talk About When I Talk About Running”.

Before dedicating himself entirely to writing, Murakami ran a jazz cafe in Tokyo with his wife, where he spent his days preparing cocktails, selecting music to play, and reading books. While it might seem like an easy job, he was working for 12 hours every day while smoking almost 60 cigarettes due to stress. Then one day, while watching a local baseball match, he had the realisation that he wanted to write fiction. Against the advice of his close friends, he sold the cafe and moved to the countryside with his wife, where he could have the calm environment needed to focus. While dedicating himself to writing, thanks also to some positive feedback received for his early stories, he discovered that sitting at a table for long hours every day wasn’t good for his health. So at 33, he quit smoking and decided that he would go for a run every single morning before immersing himself in writing.

Since then, Murakami has never stopped running, participating in more than 30 marathons around the world, including ultramarathons and triathlons. In the book, he explains the entire process that transformed him from a complete beginner to a long endurance runner. His secret was running every single day, mentioning that consistency was the key to his success.

Murakami has run for most of his life and wrote novels professionally for a long time. In the book, he explains the loose correlation between the two: the fact that both are activities done in solitude and that both require, other than a bit of talent, constant training to be sustainable over a long period. Writing is not easy. It requires sitting at a table alone, immersed in a long and deep thinking flow into imagination and memory. It’s a task that requires concentration and can sometimes be so intense that it becomes exhausting.

The book mixes the two experiences that Murakami had, describing that what he learned is that the key ingredients to engage in these activities are focus, endurance, and the patience needed to persist while waiting for the results to come.

I didn't start running because somebody asked me to become a runner. Just like I didn't become a novelist because someone asked me to. One day, out of the blue, I wanted to write a novel. And one day, out of the blue, I started to run-simply because I wanted to. I've always done whatever I felt like doing in life. People may try to stop me, and convince me I'm wrong, but I won't change. — Haruki Murakami

In the West, we tend to associate authors with a status, almost as if they are celebrities and rockstars. In recent decades, we saw the rise of literary artistic personas that romanticised drinking, taking drugs, and burning out young. Think Burroughs, Hunter S. Thompson, Bukowski, Bret Easton Ellis, or David Foster Wallace. They all made these themes central to their productions.

Murakami is a different kind of writer. Instead of drinking, smoking, abusing substances, and promoting an unhealthy lifestyle, he followed a strict diet, did endurance training, and committed himself to a self-imposed discipline to seriously carry out his duties. He promoted a life dedicated to running and the craft of writing, honouring his commitments while constantly training his persistence and resilience. This choice resembles the life of ancient samurais, the Japanese warriors with a high moral code and self-control. If you’ve ever been interested in Japan, you will notice that the attitude that samurais had toward their duty still persists in today’s life of Japanese salarymen. The country is famously renowned for the perfection they put into their crafts and their dedication to work, which comes from the culture of imposing strict discipline on themselves in order to challenge their own limits.

Pain is inevitable. Suffering is optional. — Haruki Murakami

There’s a quiet rebellion in choosing Murakami over Bukowski as a way of life. Our Western culture too often normalises burnout and, instead of condemning substance abuse, subtly encourages it. The power that comes from disciplining ourselves and restraining our desires in pursuit of a higher goal is what allows us to simply show up every day and do the work, whether that means running or writing. The point of these activities, in the end, is to prove to ourself that we are capable of enduring, and of moving forward, every single day.

A road to Lisp: Why Lisp

Thu, 09 Jul 2026 00:00:00 GMT

The question that most programmers face when seeing some Lisp code for the first time is, without doubt, “what the hell is this?”. I asked myself the same thing when I first read its unconventional syntax: all those parentheses, the weird indentation, and who thought to use the first argument of format to print to stdout?

(defun flip-coin-for-real ()
  (<= (random 100) 80))

(defun hello-lisp ()
  (write-line "What is your name?")
  (let ((name (read-line))
	    (learn-it (if (flip-coin-for-real)
		              "should"
		              "should not")))
    (format t "Hello, ~A.~%" name)
    (format t "The Oracle said... you ~A learn Lisp!~%" learn-it)))

After getting comfortable reading code with so many parentheses, I had to learn how to use packages and symbols, how to create new projects and import libraries, how to use the REPL, and how to use conditions and restarts. Most importantly, I had to switch to a new way of thinking when constructing algorithms.

The Lisp journey has a steep learning curve compared to most common languages. But it can also unlock skills that those languages never will. Why? Because in Lisp you can do things that are not possible in other languages. Lisp enables new possibilities and allows algorithms to take different shapes, giving the programmer more power and flexibility.

Paul Graham coined the term Blub paradox to explain why it is difficult for programmers who have only used less powerful languages to understand the power of Lisp. In short, it’s because they are missing the concepts needed to perceive what is lacking in those languages and the advantage Lisp has over them. Louis Armstrong said something similar about jazz:

If you have to ask what jazz is, you'll never know. — Louis Armstrong.

In this article, I'll explain a few features that show why this special language is worth learning. It's not an easy path, and to truly grasp its power you'll need to use Lisp yourself. And even if you don’t end up using Lisp, you will gain a different perspective on what programming languages can do.

Lisp is going to make you a better programmer because it changes the way you think about problems using code. To be more specific, it will teach you an approach that is not possible with other programming languages. You will be able to program Lisp itself and thus adapt the language you use to the problems you are solving. Using Lisp, you will learn to grow the language toward your problem, then write the program in that language.

Extensibility

Lisp is extensible within itself. Experts — called lispers — commonly refer to it as the programmable programming language[^1]. Not only will you write code for your programs, but you can write code that extends Lisp itself.

This is possible thanks to the macro operator. If you've used macros before in languages like C, Rust, or Swift, don’t expect the same thing. Those macros are primarily a way to eliminate boilerplate or generate repetitive code. Beyond that, macros in Lisp allow you to create new constructs that become part of the language itself.

They are one of the hardest features to master for Lisp programmers, so I won't try to teach you how to use them or how they work here. I just want to give you a taste of what they do. For example, C programmers might want to use the while operator to define a simple loop. Common Lisp does not provide it, so the programmer can write a macro and add it to the language.

(defmacro while (condition &body body)
  `(loop while ,condition do
     (progn ,@body)))

The new while macro executes a series of instructions (the body) for as long as the condition is true. It uses loop, which is itself a macro used to write complex iterations (notice that it uses a while symbol as well). progn is a special form that takes multiple expressions, runs them in order, and returns the result of the last one.

Instead of writing (loop while ... do (progn ...)), we can use the new while operator, shortening the code and making it similar to C. We just extended the language available to us.

(let ((counter 3))
  (while (> counter 0)
    (print counter)
    (decf counter)))

;; 3
;; 2
;; 1

The beginner might not grasp what is really magical here, since, other than the unique syntax, defmacro looks pretty similar to defun, which was used in the first code example to define new functions.

To better understand the difference between the two, let’s define a new while as a function, then call it.

(defun fake-while (condition body)
  (loop while condition do
    (funcall body)))
    
(let ((counter 3))
  (fake-while (> counter 0) 
	(progn
	  (print counter)
	  (decf counter))))

loop is the same macro we used before; funcall calls the function received as the first parameter, in this case body. Try to execute the code above in a Common Lisp REPL. You will receive a condition of type error, similar to this: The value 2 is not of type FUNCTION.

This happens because the arguments to fake-while are evaluated immediately. (< x 3) evaluates to t -- true. Because progn is a function, its arguments are evaluated. (print counter) prints 3, and (decf counter) returns 2. Since progn returns the value of its last expression, body becomes 2. So fake-while receives t as its first argument and 2 as its second, not a block of code. It will enter the while since the condition is true, and then funcall expects body to be the function to be called, but body is the value 2. This raises the condition above. The code executed by the compiler is the one below. (funcall 2) raises the condition.

(loop while t
	  do (funcall 2))

The macro while defined earlier works because it keeps the arguments — condition and body — intact, without evaluating them until needed. We can inspect the transformation that a macro operates in the REPL. This transformation is called expansion. macroexpand is a special Lisp command we can use to expand code.

CL-USER> (macroexpand-1 '(while (> counter 0) (print counter) (decf counter)))
(LOOP WHILE (> COUNTER 0)
      DO (PROGN (PRINT COUNTER) (DECF COUNTER)))

The code returned from the macro expansion is the one received and executed by the compiler. We can see that this time the while macro preserved the arguments so they will be executed together with the rest of the code.

A macro, unlike a function, does not evaluate the arguments in advance. Instead, it treats them as pure data. This is possible because (almost) everything you see in Lisp is made of lists. They are the main data structure, and they are used to write code.

It’s lists all the way down

Programs in Lisp are composed of a series of symbolic expressions (abbreviated s-expr). Expression is a mathematical term meaning anything that evaluates to a value; symbolic means that expressions are created using values and symbols.

An s-expression is one of two things:

an atom, which is a unit of data (a number, a string, a symbol, etc)
a list, which is a collection of elements that can be atoms or other lists

1           ;; An atom number
"hello"     ;; An atom string
'(1 "y" :c) ;; A list of atoms (a number, a string, a keyword)
(+ 1 2)     ;; A list composed of a symbol (plus) and two numbers

Lisp means LISt Processing, so the purpose of the language is to process the series of instructions expressed as lists that compose the program.

Since lists are used both as the main data structure and to write the code, we can extract an interesting property of the language. In Lisp, code-as-data means that both code and data are expressed using lists. This property is called homoiconicity.

CL-USER> (+ 1 2)
3
CL-USER> '(+ 1 2)
(+ 1 2)

I’ve used two lists with the same content; the only difference is that I put ' in front of the second one, but the output is different. The first list is treated as code. It gets evaluated, and specifically the symbol + maps to a function that performs the sum of the arguments. Lisp uses what’s called Polish notation, where the function name is the first element of the list and what follows are the arguments. So instead of writing print("hello"), we write (print "hello"), moving the function name inside the parentheses. The output is 3, which is the result of the code execution.

The second list is treated as data. ' is an operator that tells the interpreter not to evaluate the following list and keep it as manipulable data. The output is the same list, not evaluated.

The subtle distinction between code and data is what makes macros possible. We can manipulate code as we manipulate data. By transforming the source code, we are able to write programs that write programs, a capability other languages have spent decades trying to imitate.

Extending the language means that by creating new constructs that are more expressive for your program's specific scope, you can make your code more concise. Repetitive boilerplate code can be replaced with custom macros to shorten the code and save time. New control structures can be created to control resource access and the evaluation of forms. Macros can generate code, improve performance, and, most importantly, create new syntactic abstractions that are easier to use to hide complex and error-prone code.

A live system

Lisp is not only a programming language, it's a live system. To clarify this point, let’s start with how different the workflow is between Lisp and other languages.

With other languages, you open the project in the editor and start writing code. The first thing a lisper does is start a Lisp process, attach it to the REPL, and then load the project into that process.

The Read-Eval-Print Loop is an interactive environment used to evaluate code and immediately see the result. It's a window into the Lisp living process that is currently running your program.

In other languages, once you change the code, you have to stop and compile it, then run the project to observe, test, and debug the changes. If something's wrong, you go back to the write-compile-run-debug cycle.

Instead, a lisper continuously evaluates code in the running process and observes the output directly in the REPL, since the Lisp process is the running program. Every single function can be immediately tested in the REPL as a single unit of code, as well as any other action useful for development, such as querying a database, inspecting variables, or debugging.

A Lisp process is usually kept alive for weeks on end since there is no need to stop it. It can stay attached to the REPL in the editor for as long as needed. New functions, macros, and variables are continuously defined and redefined, a process called binding within an internal memory called the environment. This particular workflow even has a name: REPL-driven development. This is a real killer feature. It has been available in Lisp since its invention in the 60s, and it has been imitated by other languages (where possible), like many other Lisp original features.

Does the word hot-reloading tell you anything? I’ve been lucky since I started my career working with web frontends, where the JavaScript code of the app is hot-reloaded with every hard refresh of the page. And thanks to modern tools, I now only need to save a file and the webpage will automatically refresh itself with the new changes. Under the hood, hot-reloading means there is a process watching the files, recompiling the modules that changed, and a websocket connection is used to inject the changes silently into the page. But not all software stacks are that lucky. Some backend frameworks still require recompilation, the situation is mixed for desktop and mobile development, and low-level languages require full compilation every time.

In Lisp, hot-reloading is not a separate tool or technique. It comes for free when evaluating code in the live environment. Every time I redefine a symbol, it picks up the new definition, whether it’s a function, data, or a macro. I don’t need to stop and compile, run tests separately, or use some special debugger. Everything comes automatically by evaluating in the REPL. A good analogy is that programming in Lisp is like evolving a program rather than constructing it. Once a new Lisp process has started and code gets evaluated into it, that system will become the program itself.

Lisp allows you to approach programming in a new way. You can evolve the programs while writing them, and at the same time, as discussed before, evolve the language to your needs. A Lisp CAD program has evolved by turning Lisp into a language that writes CAD programs. A high-frequency trading system has evolved with a language adapted to write similar trading systems. This is the nature of Lisp, and it offers many advantages.

Extensible software

This is something probably even less known, but the two features explained above (language extensibility and the Lisp live system) allow you to easily create extensible software.

We're used to desktop programs being extensible mainly through plugins, such as in text editors, or sometimes through scripting languages for customization, as in game modding. These solutions usually work well, but they require programmers to design and maintain an entire system for extensibility, and they require users to learn a specific set of APIs to write plugins or extensions. In Lisp, this comes almost for free.

While extending the language, lispers write macros to encapsulate actions and make code easy to reuse. In doing so, beyond just creating new symbols, they are effectively writing a DSL, a domain-specific language for the program. When lispers need to make their software extensible, all they need to do is let users use the DSL they've created.

To understand this concept, let’s look at some use case scenarios. I wrote a custom CMS server for clients’ websites. I wrote some macros for generating webpages server-side.

(html
  (:h1 "Lorem Ipsum")
  (:p "Dolor sit " (:b "amet") "."))

I can expose the same DSL I’ve written internally to the users so they can write their own views and customise their CMS instance.

;; A user can write dynamic pages using the full power of Lisp
(let ((user-name "Alice")
      (items '("Apples" "Bananas" "Oranges")))
  (html
    (:h1 (format nil "Welcome back, ~A!" user-name))
    (:ul (dolist (item items)
           (html (:li item))))))

Notice how the html macro seamlessly integrates with Lisp's variables (user-name), loops (dolist), and string formatting (format). In a traditional templating language, you'd need to learn a separate syntax with special brackets like {{ user_name }} or {% for %}. In Lisp, you don't need a new language since you just use Lisp itself to build your templates.

This integration means your DSL inherits all the power of Lisp: conditionals, recursion, higher-order functions, and even the ability to debug your templates step-by-step in the REPL.

Another scenario: I wrote a math software where users can write formulas and the program renders them on a Cartesian graph. So I wrote a DSL to write math and draw. I can expose a small subset of the language to users so they can draw directly without having to use math formulas.

(graph
  (:curve (lambda (x) (* x x)) 0 0)     ; plot y = x²
  (:point 0 0))                         ; mark the origin

With this DSL, users can draw complex mathematical functions with minimal code. Since it's just Lisp, they can use variables, define helper functions, or even generate multiple curves in a loop. This gives the users a clean interface while leaving the complex rendering code safely hidden away.

This technique for extending programs has been used successfully. AutoCAD uses AutoLISP to automate repeating tasks and create complex geometries. Emacs is the most extensible text editor that has ever existed on this planet, and most of it is implemented in its own Lisp dialect in order to make it infinitely expandable. There's a running joke that hardcore Emacs users never have to leave the editor because it already contains everything they would ever need. In fact, Emacs has been extended to be a PDF reader, a web browser, an email client, an RSS reader, a terminal multiplexer, a Git client, a music player, a chat client, a spreadsheet, an IRC client, and even a window manager for your entire desktop, all thanks to using Lisp under the hood[^2].

The most powerful programming language is Lisp. If you don't know Lisp, you don't know what it means for a programming language to be powerful and elegant. Once you learn Lisp, you will see what is lacking in most other languages. — R. M. Stallman creator of GCC, Emacs, the GNU project.

So why Lisp (or when)

A lot of people have argued that one day in the future there would be a time for Lisp. A time where it becomes popular, almost the default language, when the majority of programmers will come to appreciate what a fantastic experience it is to work with it. A time when Lisp would be taught at universities all over the world so companies would have no issues finding lispers, and engineers would become unafraid of incompatibility or performance issues. Programmers would joyfully spend their days using REPL-driven development, and most of the software we use would become extensible using variations of a single language.

This time never happened, and probably never will.

Still, Lisp has survived from the 60s, becoming the second oldest programming language still in use after Fortran. So many languages were inspired by it, and so many languages are still being created, missing some of the features that helped Lisp survive. So even if there isn't a time for Lisp, that doesn't mean it's not a powerful language worth knowing.

Better programmers than me have said that it's hard to justify Lisp's use by picking a single feature among its extensibility, its interactive environment, the REPL, and a lot of other features we haven't touched yet. It is the combination of all of them that makes Lisp programming what it is.

So get ready to learn what the most powerful programming language truly is.

[^1]: This quote belongs to John Foderaro, co-founder of Franz Lisp. [^2]: To be fair, some people argue that Emacs is "a great operating system, lacking only a decent editor".

Blogging

Wed, 08 Jul 2026 00:00:00 GMT

In the next month I will be less busy than usual, and to not get too lazy I decided to commit to publishing one article a day. The goals I’m working toward are becoming more persistent in finishing the tasks I choose to do, and improving my writing abilities, especially in English. So a post every day seems like a good excuse to practice and move towards those goals.

This challenge will definitely push me out of my comfort zone. I’m not that skilled at writing blog posts, and to be honest not even at writing in general. Also most of the writing I’ve done previously was in my native language, Italian, so a bit of English workout is waiting for me. Two other challenges are: finding interesting topics to write about every day, and my writing speed. To help me overcome the first one, being less busy will give me more time to think freely and use my imagination, plus I have a few saved article drafts that I can use. My writing speed is probably the hardest one. It directly relates to the quality of my writing, and for a beginner it’s worth spending time polishing each draft rather than writing a lot. But I'm 32, and it's time to find a faster way to improve, even if it means producing less refined content. In any case, the speed is probably where I hope to see some progress at the end of this experiment.

How will I know if this challenge has been successful? I don’t really have any metrics available other than basic web analytics. I would say that what matters the most is to commit every day and try not to go a single day without publishing. Then in a month I will be able to check the progress in the archive page and count the days I missed.

Some blogging principles

Blogging is one of the best tools that writers have. Everything can go on a blog, from cooking and cat photos, to long essays about the meaning of nearly everything. While it's comforting that nothing is off-topic, it also means I need to decide what belongs on my blog. What are my principles for writing here?

I put down a few guidelines that I want to follow:

One core idea per post. This comes naturally since a post should be an idea or an opinion condensed in a small space. The hard part is sticking to the topic and not letting the discourse go in multiple directions. Having a short amount of time will also force me to keep my ideas small — I always tend to think too big.
Be concise. This is more about the form than the content. People don’t have an infinite amount of time to spend reading a random post, so the more I can condense information while keeping a good rhythm, the better the result will be. A good technique is to quickly write a raw draft first, then do the polishing later, cutting the unnecessary and rewriting the parts that are unclear.
Keep it mine. I believe that good writing is personal, bad writing is anonymous. There are no rules for good or bad writing on a blog, but the posts I appreciate more are the ones that give a perspective, an opinion, or more in general that tell a personal story. A personal blog should be a diary, a conversation with the reader. So in my posts I will put my real thoughts, not trying to be fair or even right.
Write manually. This should be obvious, otherwise why put so much effort in it? Recent algorithms can put together a decent post and with a few tweaks I bet it can resemble something written by a human. We live in a strange time where machine-generated content is sprawling all over the web, with or without humans behind it. I see generated articles, generated comments on social media, generated images and code all over the place. I don’t like it and I don’t want to collaborate. Writing is like a muscle, it needs proper constant training to grow. Keeping a blog is a gym for the modern writer, so write it manually or don’t write it at all. Writing is one of the most effective ways to organise your thoughts in a cohesive way. Paraphrasing Paul Graham, if you delegate this process entirely to the machine, not only you never learn how to write, but you lose one of the best ways that helps you think better.
Be positive. To write angry rants, complain that everything is shit, that we deserve better without taking any action, it’s easy. It really is. But it has consequences. Look at how overexposure to media generates stress and anxiety in people and fuel anger and depression. The hard task here is to write interesting content using a positive attitude. I don’t like the forced optimism culture, too often delivered with large smiles, because I don’t feel it’s authentic, I don’t feel it really comes from a genuine place, but from the stakes involved or ideology. Instead, I like genuine positive thinking, which comes from putting content into the world with the intention of making it a little more interesting, useful, or thoughtful than before.

Enough rambling about blogging for today. A new article is already boiling. Wish me luck.

Junky - William S. Burroughs

Fri, 23 Jan 2026 00:00:00 GMT

Junky è un libro affascinante che tratta di un tema singolare in letteratura; la vita di un dipendente dall’eroina. William Burroughs decide di raccontare in prima persona — nonostante usi uno pseudonimo — perché lui stesso è stato dipendente dalla sostanza per quasi tutta la vita. Junky è stato il suo primo successo, ed ha elevato Burroughs a capostipite della beat generation, la corrente letteraria americana di metà secolo scorso, basata su una forte ribellione artistica e sessuale accompagnata da un consumo smoderato di droghe.

La storia si svolge a metà degli anni 40 in America, ed è di fatto la biografia della dipendenza di Burroughs, anche se i fatti narrati non sono tutti totalmente reali. Cosa passa nella mente di un tossico? Come pensa? Qual’è il vocabolario che usa e quali sono le sue unità di misura? Il libro è fenomenale nel raccontare la quotidianità di un eroinomane, sempre alla ricerca della sostanza, o di soldi, sempre a fare attenzione di non esser “pizzicato” dalla polizia. Più che una successione di eventi, il racconto è un viaggio interiore. Le pagine contengono i pensieri quotidiani di un tossicodipendente accompagnati dalla cronaca minuziosa dei suoi frequenti abusi, delle astinenze e le successive ricadute.

Junky è un viaggio scandito da continui spostamenti tra città e nazioni, per sfuggire a possibili arresti, da frequenti visite ai dottori per ottenere prescrizioni per la morfina, dallo spaccio per guadagnare soldi e poter mantenere la dipendenza, ma soprattutto dal costante bisogno quotidiano di eroina. Dalle pagine traspare il vero significato della dipendenza, che prima che esser fisica è soprattutto mentale. Il pensiero di trovare la sostanza diventa il motore sia della storia che della vita di chi, come Burroughs, ne è schiavo. Tutte le pagine non parlano d’altro che di eroina, trasformando il racconto nel diario intimo di un tossico.

La dipendenza viene continuamente interrotta. Una volta al protagonista manca l’eroina, un altra volta sceglie di disintossicarsi e si rivolge a una clinica, un altra ancora finisce in cella. Ogni volta è scabroso il racconto dei dolori fisici che prova quando al suo corpo viene a mancare la dose. Parliamo di febbre, nausea, insonnia, diarrea, dolori diffusi, soprattutto alla spina dorsale, quest’ultimo chiamato in gergo “la scimmia sulla schiena” — uno dei titoli alternativi con cui in Italia è uscito il romanzo. Sono paragrafi raccapriccianti e snervanti, dove spesso il protagonista è costretto ad assumere dosi di altre sostanze per calmare i dolori e compensare lo sbilanciamento chimico. Quando Burroughs si trova in astinenza si rivolge ad altre sostanze, principalmente alcool e erba, ma anche oppiacei vari, cocaina, barbiturici, addirittura prova il peyote messicano, per riuscire a calmare il bisogno di eroina. La cosa più triste di tutte sono le continue ricadute, che perdurano fino alla fine del romanzo. Burroughs non riesce mai a smettere per più di un paio di mesi, che incontra qualcuno che gli offre una nuova dose. Lui non riesce a trattenersi, si fa, e in un attimo si ritrova intrappolato nel solito ciclo distruttivo.

I personaggi nella storia appaiono e scompaiono. Di solito sono clienti o amici che coprono un ruolo per la durata di qualche pagina, poi Burroughs si sposta, cambia città, finisce in cella, e tutto ricomincia da capo con nuovi personaggi, nuovi prezzi, ma identiche sostanze. Le persone più vicine a lui, come la moglie, vengono menzionate raramente, quasi fossero degli intoppi insignificanti davanti all’enorme soddisfazione che prova quando si inietta l’eroina. Eppure la moglie non esita a definirlo noioso e patetico quando intuisce che sta per ricadere nella dipendenza.

Infinte Burroughs nel romanzo non critica direttamente la droga, anzi promuove l’eroina a stile di vita fin dall’introduzione. Nel libro non incoraggia il lettore a farne uso, anzi sembra quasi voglia ridimensionare la propria dipendenza. Parla spesso di vari parametri, come il numero di mesi e di iniezioni quotidiane, quasi a dire che la sua non è una dipendenza tale da dover esser ritenuta grave — una tipica auto-riflessione da tossico. La critica all’eroina fuoriesce dal racconto. Non si può che provare pena per i dolori che soffre il protagonista quando è in astinenza, per la continua lotta nella ricerca di una nuova dose, per il terrore costante di essere scoperto e incarcerato per spaccio, ma più di tutto per la continua ossessione per la droga che occupa la sua mente. Per un junky l'intera vita ruota attorno all'eroina: persino il risveglio viene dominato dal bisogno della dose, senza la quale la normalità resta irraggiungibile.

The question is frequently asked: Why does a man become a drug addict?
The answer is that he usually does not intend to become an addict. You don’t wake up one morning and decide to be a drug addict. It takes at least three months’ shooting twice a day to get any habit at all. And you don’t really know what junk sickness is until you have had several habits. It took me almost six months to get my first habit, and then the withdrawal symptoms were mild. I think it no exaggeration to say it takes about a year and several hundred injections to make an addict.
The questions, of course, could be asked: Why did you ever try narcotics? Why did you continue using it long enough to become an addict? You become a narcotics addict because you do not have strong motivations in the other direction. Junk wins by default. I tried it as a matter of curiosity. I drifted along taking shots when I could score. I ended up hooked. Most addicts I have talked to report a similar experience. They did not start using drugs for any reason they can remember. They just drifted along until they got hooked. If you have never been addicted, you can have no clear idea what it means to need junk with the addict’s special need. You don’t decide to be an addict. One morning you wake up sick and you’re an addict.

Liture, How I Manage My Reading Notes

Wed, 17 Dec 2025 00:00:00 GMT

Useful software often comes out of frustration. When a programmer finds themselves wondering about a tool or a library that doesn’t exist yet, they may decide to write it. At least, they know it would be useful for one user, themself, not to mention the fun of coding. In my case, I needed an easy way to navigate my ebook notes, and all I could find were subscription based services that didn’t fit my casual use. This is how Liture started.

“Readers eat books. Film eats viewers.” — The Wave in the Mind, Ursula K. Le Guin

One of the advantages of physical books is that we can write on the margins. That text filling the white space that the page offers has a name, marginalia, and it’s the old analog way to make that book copy feel ours. By writing on it we can enrich the text with our thoughts, and also highlight our favourite passages as well as the most crucial one to help us revise our reading later on. I tend to use a pencil, a ruler, and some coloured tags attached in the margin for quickly jumping to the best parts in the future.

A lot of great writers in the past have used marginalia. Some of their book copies are still preserved, online we can see photos of the annotations made by names like Herman Melville, William Blake, Mark Twain, Jane Austen, Sylvia Plath, Jack Kerouac. I know that Vladimir Nabokov used to draw maps and object, since some of the original pages were printed on his posthumous book Lectures on Literature, like his annotated copy of Franz Kafka’s Metamorphosis. David Foster Wallace became famous for his heavy use of margin annotations. Some of his copies of Cormac McCarthy and Don DeLillo, filled with various notes, numbers and drawings, are kept exposed at the University of Texas in Austin.

I've read far more books recently than I did a few years ago, and I do most of my readings with an ebook reader. I love printed books. I miss the feeling that touching paper gives, the visual feedback of the progress, the different style for covers and typography used for each book. I still buy physical copies and often second-hand, but I prefer to read in Italian[^1], my original language, and since I'm in Australia, far from Italian bookshops and I don’t want to pollute the planet with my hobbies, I mostly read digital books.

I also have the habit of highlighting in books and sometimes taking annotations, which it's easy using an e-reader. Soon my collection of quotes and notes had grown. For some books, like 21 Lessons for the 21st Century, I had to print my highlights to review them, filling around 15 pages, and then re-highlight the most important parts. Even if I find paper more effective for focus reading than digital text, I become frustrated every time I had to review my highlights and notes from an ebook, since I couldn't find a way to access that data.

I use a Kobo reader and all the content that the user generates is stored inside the device. Export is not officially supported. A few years ago I started maintaining a python script that extracts highlights and notes in different formats, but with a lot of notes it stopped being practical. I needed a way to search my highlights and notes, to save my favourite quotes, to see them grouped by author and book. Also highlighting as well as typing on an e-reader is not that precise, the devices are usually quite slow to respond, so I ended up having a lot of errors and imperfection to fix. I want to edit my content, and also add new notes to enrich it. I needed a new kind of software for this.

Annotations on ebooks should mimic those on physical books; they have to be easily accessible and preserved. Keeping them stored inside devices in proprietary formats is dangerous. They can easily get lost. I started thinking that some of my book notes matter as much as photos of my past, they’re a part of my reading experience and I want to keep them for the future.

Kobo, Kindle, Apple Books, none of them facilitates exporting highlights and notes outside of their own platform, no common format exists for that. That’s where Liture comes helpful. It’s a desktop app to import and manage notes and highlights from the main three book platforms. The user can search and edit content, save the favourite items, and also manually add new authors, books, and notes. No cloud or subscriptions, free for all platforms. I’m using it to keep importing new highlights every time I sync my Kobo on my mac, and the content is automatically stored in a SQLite file that I regularly backup.

“There must be something in books, something we can't imagine, to make a woman stay in a burning house; there must be something there. You don't stay for nothing.” — Fahrenheit 451, Ray Bradbury

I think there’s a lot of potential for great software for readers, and still a lot to do. Big tech companies disregard reading and prefer to focus on more lucrative content, so readers are usually left with old platforms, not frequently updated, missing modern features, and often with incompatible formats. But it's not all lost. Some groups of passionate readers are awakening and trying to fix the situation building new platforms and apps. I would like to do my part releasing Liture. Enjoy and make good use of it!

[^1]: I tell others that I prefer Italian because I find the language generally more expressive than English, but in reality it’s because I fear I might forget it one day. So I read in Italian to keep the language from rusting in my head.

Quel che resta del giorno - Kazuo Ishiguro

Fri, 26 Sep 2025 00:00:00 GMT

La sera è ciò che resta del giorno, come la vecchiaia è ciò che ti resta della vita. Il protagonista dell’opera di Kazuo Ishiguro uscita nel 1989, è un maggiordomo oramai anziano che decide di intraprendere un viaggio, sia fisico guidando la sua auto nelle campagne del sud-ovest dell’Inghilterra, sia nella sua memoria, ripercorrendo scene della sua carriera presso la dimora Darlington. Quel che resta del giorno è stato il primo successo dello scrittore inglese, grazie al quale vinse il Booker Prize che gli permise di esser riconosciuto a livello internazionale, anche grazie alla trasposizione cinematografica con Anthony Hopkins come attore protagonista.

Stevens interpretato da Anthony Hopkins nel 1993

Stevens è un maggiordomo a capo del servizio nella residenza di un lord inglese chiamato Darlington. Dopo la morte del padrone, la residenza omonima passa in mano a un magnate americano Mr Faraday, che nonostante i tagli del personale, necessita di buoni servitori al suo servizio. Stevens decide quindi di prendersi qualche giorno di vacanza per andare a trovare una sua conoscenza che anni prima aveva servito a Darlington hall, Miss Kenton, e convincerla a riprendere il suo vecchio ruolo. Il viaggio in auto lo porta attraverso i panorami della campagna inglese dove si trova a riflettere in una serie di flashback che raccontano episodi della sua carriera con lord Darlington. In queste memorie si intrecciano più trame, come il contesto storico del racconto, descritto tramite la partecipazione politica del lord nelle fasi preliminari della seconda guerra mondiale e la sua decisione di appoggiare l’operato della Germania, oltre che vari avvenimenti che riguardano i personaggi che soggiornano a Darlington hall.

“La sera è la parte più bella della giornata. Hai concluso una giornata di lavoro e adesso puoi sederti ed essere felice. Ecco come la vedo io. Domandate a chiunque e vedrete che vi diranno tutti la stessa cosa. La sera è la parte più bella della giornata.” — Stevens

Il racconto è in prima persona dal punto di vista del maggiordomo, un espediente utile a Ishiguro per narrare vari avvenimenti, come le cerimonie formali tra rappresentanti politici di varie nazioni che avvengono nella residenza, attraverso gli occhi — e le orecchie — di un maggiordomo. Stevens riporta solamente porzioni di conversazioni, battute di personaggi e piccoli incidenti che gli sono rimasti nella memoria, i quali vengono lasciati al lettore come pezzi di un puzzle da comporre per comprendere ciò che non viene direttamente narrato. Il nascondere gli eventi e rivelarli solo in parte durante la narrazione è uno dei tratti caratteristici dello stile di Ishiguro, che ho ritrovato anche nel suo romanzo successivo Non lasciarmi. Oltre a questa unicità, in entrambi i romanzi i protagonisti prendono parte a una storia d’amore che, sebbene ordinaria, è anche inconclusiva. Infatti anche in Quel che resta del giorno, scopriamo che i sentimenti di Miss Kenton per Stevens, in qualche modo si intuiscono dai flashback ma vengono rivelati del tutto nel finale, vengono totalmente ignorati dal maggiordomo. Stevens è profondamente convinto che esista una precisa nozione di grandezza riferita alla professione del maggiordomo. Nonostante la definizione non appaia mai univoca nel libro ma sempre frammentaria, si può ricostruire che essa consista nel reputare onorevole il servire il proprio lord al meglio delle proprie possibilità, ripudiando qualsiasi comportamento inadatto o giudizio sugli avvenimenti nella residenza, oltre che mostrandosi sempre in atteggiamento sobrio e disponibile a qualsiasi richiesta. Stevens intende chiaramente dimostrare a se stesso di poter essere un grande maggiordomo, nonostante non si reputi tale, ed è per questo che decide di non dar corda ai sentimenti di Miss Kenton, sarebbero per lui solo una distrazione inopportuna.

Le capacità narrative di Ishiguro sono eccezionali. Per esempio in una scena, di per se secondaria ma che nel contesto della storia assume un’importanza centrale, Stevens sta leggendo un libro e Miss Kenton gli si avvicina cercando di rubarglielo di mano per scoprire cosa stesse leggendo. Ella vorrebbe fare con quel gesto una qualche breccia nella barriera professionale che ancora li divide e cercare di andare oltre la formalità dei loro discorsi, sempre diretti al servizio della casa e alle nuove disposizioni da attuare. Stevens si rifiuta fermamente, invitandola molto educatamente a non violare i suoi momenti di riposo. Miss Kenton infatti scopre giocosamente che Stevens stava leggendo una banale storia d’amore, ma il maggiordomo mette subito a freno la curiosità della domestica spiegandole che per adempire al meglio al suo ruolo è richiesto leggere, anche romanzi, per poter adottare sempre il vocabolario più adatto ad ogni conversazione. La scena evocativa mostra quanto Stevens sia capace di dedicarsi al suo ruolo, al punto da reprimere i suoi sentimenti e non distinguere più la sua vita privata dal lavoro.

In entrambi i romanzi che ho letto dell’autore, mi sono ritrovato a pormi delle domande non banali. Esse emergono dalle pagine e non vengono mai poste direttamente, siccome i personaggi finiscono per ritrovarsi in situazioni ambigue e moralmente complesse. È una delle specialità dello stile narrativo di Kazuo Ishiguro. Mentre in Non lasciarmi mi ero posto domande sui quali debbano essere i limiti della scienza, in questo libro è impossibile non domandarsi quali siano i limiti nella dedizione al proprio lavoro. Non si tratta di puro stacanovismo, ma piuttosto di chiedersi la fede incondizionata che ha Stevens per il proprio padrone, al punto da sopprimere qualsiasi dubbio, giudizio o addirittura sentimento perché in contrasto con i requisiti per essere un grande maggiordomo, sia giustificata. Più di trent’anni dall’uscita del libro, è ovvio che quel tipo di mentalità è oramai antiquata, allo stesso modo di tutte le riflessioni che Stevens fa a favore di lasciare le decisioni fondamentali per il futuro del paese ad un gruppo di leader, perché a suo dire loro sanno quello che fanno meglio di chiunque altro. Da queste riflessioni emergono le differenze tra il vecchio modo di pensare di inizio secolo scorso, in cui si credeva che un uomo avesse un ruolo assegnatogli nella società e l’unica cosa che dovesse fare e svolgerlo al meglio, senza occuparsi di faccende complesse fuori dalla sua portata, in contrasto con l’uomo moderno, che da importanza all’educazione personale, e si sente libero sia di scegliere la propria strada nella vita, sia di poter esprimere opinioni e preferenze su eventi e decisioni che non lo riguardano direttamente. Miss Kenton nel racconto la pensa diversamente da Stevens, non crede che il suo ruolo definisca la sua intera vita. Sceglie l’unica via liberatoria che ha a disposizione, e decide di sposarsi, provando a costruirsi una famiglia, e smettendo così di essere alle dipendenze altrui. Anche se le cose alla fine non le sono andate per il meglio, ha scelto di esercitare la sua libertà provando a crearsi una vita diversa, rinunciando a dedicare tutta se stessa al ruolo di domestica. Stevens nel finale si rende conto di aver sprecato gran parte della sua vita inseguendo un ideale inconclusivo, e ha il rimpianto di non aver scelto per se un’altra strada per evitare la solitudine alla fine dei suoi giorni.

Leggendo alcune interviste sul romanzo, Ishiguro ha dichiarato essersi documentato a dovere e di aver addirittura letto dei manuali inglesi sui maggiordomi di inizio secolo, che spiegavano le procedure corrette per organizzare il servizio e intrattenere gli ospiti. Dopo mesi di ricerca l’autore ha prodotto la prima bozza del romanzo in un solo mese, chiudendosi in nel suo studio a scrivere anche per tredici ore al giorno, per ridurre al minimo qualsiasi influenza esterna sulla sua immaginazione e concentrarsi solamente sulla scrittura della storia che aveva in mente. Durante questa immersione nel processo creativo, Ishiguro ha detto di aver appositamente evitato di riscrivere o correggere le bozze, ma solo di essersi annotato le successive modifiche da apportare una volta concluso l’intero racconto. Mi vien da pensare che Ishiguro, oltre che a costringere se stesso a scrivere, volesse tentare di avvicinarsi il più possibile alla quella dedizione assoluta al proprio lavoro descritta nel romanzo, così da caratterizzare al meglio Stevens tramite le sensazioni che provava durante tutte quelle ore di intensa produzione.

A simple Common Lisp web app

Wed, 30 Apr 2025 00:00:00 GMT

One of the drawbacks I’ve found when dealing with Common Lisp is the lack of documentation available. Too often, I find published libraries without an explanation of how they are meant to be used or only partially documented, and I need to dig into the source code to understand what they do and to see all the functions available. Even though reading source code is a proven technique to improve one's grasp of a programming language, most other systems come with extensively documented libraries, something appreciated by beginners and a factor that often contributes to a language's popularity.

In my opinion, this lack of good documentation is one of the reasons Common Lisp is often seen as challenging for beginners, which makes it harder for the language to become popular.

Some time ago, when I looked for guidance on writing a generic web app, I was surprised by the absence of a quickstart page to help me set up a simple server—something the Python community has provided for Flask for many years.

“The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)” A drunk dev on reddit

So I put together a short tutorial on how to build a simple web app in Common Lisp, inspired by the Clojure tutorial written for Luminus. The goal is to write a guestbook demo, involving template rendering, connecting to a database to run queries, and exposing routes to the webpage.

To follow the tutorial, you need a Common Lisp implementation, like SBCL, with Quicklisp, the dependency manager. I also recommend having a REPL integrated with your IDE, like SLY for Emacs or Alive for VSCode.

I’ll use more modern CL libraries that have an interface similar to other languages, so it might be a bit easier to follow along.

The server

First things first, I created a new Common Lisp project. To do that with a simple boilerplate, I loaded cl-project in the environment and called the function make-project with a path and a name for the project.

> (ql:quickload :cl-project)
To load "cl-project":
  Load 1 ASDF system:
    cl-project
; Loading "cl-project"
..
(:CL-PROJECT)

> (cl-project:make-project #P"~/guestbook/" :name "guestbook")
writing ~/guestbook/guestbook.asd
writing ~/guestbook/README.org
writing ~/guestbook/README.markdown
writing ~/guestbook/.gitignore
writing ~/guestbook/src/main.lisp
writing ~/guestbook/tests/main.lisp
T

Then I ran this command to let Quicklisp know where my new project is located.

> (pushnew #P"~/guestbook/" asdf:*central-registry* :test #'equal)

I declared the required libraries in the :depends-on property so that Quicklisp would download them from the repo and load them into the environment.

(defsystem "guestbook"
  :version "0.0.1"
  :license "MIT"
  :depends-on (:alexandria        ;; utils
               :uiop
               :cl-ppcre          ;; regex library
               :cl-syntax-annot   ;; for @export annotation
               :clack             ;; Web libraries
               :lack
               :caveman2          ;; Web framework
               :djula             ;; Template engine
               :cl-dbi)           ;; Database
  :components ((:module "src"
                :components
                ((:file "config") ;; files into src/
                 (:file "db")
                 (:file "web")
                 (:file "core"))))

Now, inside src/core.lisp (I renamed the file from main to core) I added two new functions, to start and stop the server, which will be helpful to use from the REPL.

(defvar *server* nil)

(defparameter *app*
  (lack:builder
	  (:static
      :path (lambda (path)
              (if (ppcre:scan 
                    "^(?:/images/|/css/|/js/|/robot\\.txt$|/favicon\\.ico$)" 
                    path)
                  path
                  nil))
      :root *static-directory*)
  ;; Additional middlewares
    guestbook.web:*web*))

@export
(defun start (&rest args
              &key
                (server :hunchentoot)
                (port 3210)
                (debug nil)
              &allow-other-keys)
  "Starts the server."
  (when *server*
    (restart-case (error "Server is already running.")
      (restart-server ()
        :report "Restart the server."
        (stop))))

  (setf *server* (apply #'clack:clackup *app*
                   :server server
                   :port port
                   :debug debug
                   args))
  (format t "Server started"))

@export
(defun stop ()
  "Stops the server."
  (when *server*
    (clack:stop *server*)
    (format t "Server stopped")
    (setf *server* nil)))

*server* contains the server instance and is defined as a variable since we will need to redefine it. *app* is the web application wrapped with a layer by Lack. start and stop instantiate the server with some logging, or raise errors if the action is not successful.

Lack and Clack are the two libraries I used to wrap the web application. The first one allows to define a series of middlewares in the server; for example, I used :static to tell the server where to find all the static assets in the project, inside the directory pointed to by *static-directory*. Other middlewares are available, like logging, managing sessions or providing authentication features. Clack instead is an abstraction layer for the server that provides some parameters to customise it, for example, to quickly swap which server to use between development mode (hunchentoot) and production (woo).

(unless (null *server*)
    (restart-case (error "Server is already running.")
      (restart-server ()
        :report "Restart the server."
        (stop))))

In this portion of the code, I defined a restart action for the debugger. The Common Lisp debugger always has RETRY and ABORT actions for every exception raised. By declaring a restart-case, we are signalling an error and adding custom choices to the ones offered by default by the debugger. The new option I added is called restart-server and, if selected, it first (stop)s the server and then restarts the operation, so the function runs again without raising an error. It’s a smart way to interact with the REPL and improve the developer experience using the language directly.

More on conditions and restart here and here.

At the top of src/core.lisp I set the package definition and some initialisation function calls.

(in-package :cl-user)
(defpackage guestbook.core
  (:use :cl)
  (:import-from :guestbook.config
                :*static-directory*))
(in-package :guestbook.core)

(syntax:use-syntax :annot)

(syntax:use-syntax :annot), from the package cl-syntax-annot, allows us to use some special decoration notation at the top of the function. At the top of start and stop I added an @export tag, which tells the compiler that a function is exported by the package.

Configuration

I put the configuration parameters for the app into a config file; there are better ways, but they’re not necessary for a project this simple.

@export
(defparameter *application-root* 
  (asdf:system-source-directory :guestbook))
@export
(defparameter *static-directory* 
  (merge-pathnames #P"static/" *application-root*))
@export
(defparameter *template-directory* 
  (merge-pathnames #P"templates/" *application-root*))

@export
(defvar *config*
  `(:databases 
      ((:maindb :sqlite3 
        :database-name ,(namestring (merge-pathnames "guestbook.sqlite"
                                                     *application-root*))))
    :schema-file "db/schema.sql"))

The variable *config* needs a specific format to be used with cl-dbi, which is the library that I used to interface with the database. In a real application, it would be good to differentiate between dev and prod mode with different configurations used, for example to point to different databases or to use a different server with Clack.

Database

I created a new file in db/schema.sql and put the SQL code to create a message table.

CREATE TABLE message (
    id       INTEGER PRIMARY KEY AUTOINCREMENT,
    username VARCHAR(50) NOT NULL,
    ts       DATETIME NOT NULL,
    content  TEXT NOT NULL
);

Then I ran sqlite3 guestbook.sqlite --init db/schema.sql from the terminal to create and initialise a new database in the project root.

(in-package :cl-user)
(defpackage guestbook.db
  (:use :cl)
  (:import-from :guestbook.config
                :*config*
                :*application-root*))
(in-package :guestbook.db)

(syntax:use-syntax :annot)

(defun connection-settings (&optional (db :maindb))
  (cdr (assoc db (getf *config* :databases))))

@export
(defun db (&optional (db :maindb))
	"Returns a cached database connection for DB (defaults to :maindb). 
  Uses `connection-settings` and `dbi:connect-cached`. 
	
	Usage: (db) or (db :testdb)"
  (apply #'dbi:connect-cached (connection-settings db)))

@export
(defvar *connection* nil)

@export
(defmacro with-connection (conn &body body)
  "Executes BODY with *CONNECTION* dynamically bound to CONN.
CONN should be a database connection object, typically from `db`.

Usage: (with-connection (db :maindb)
         (dbi:do-sql *connection* \"SELECT * FROM users\"))"
  `(let ((*connection* ,conn))
     (unless *connection*
       (error "Database connection cannot be NIL"))
     ,@body))

This is the first macro of the project. It’s a simple wrapper that provides a new variable *connection* to use inside the body. It raises an error if the conn value that we passed is not initialised. The function db instead returns a valid connection, cached automatically by the library.

Then I defined some functions to perform CRUD operations on the database. format-timestamp converts a universal timestamp value into a readable date-time string.

(defun format-timestamp (universal-time)
  "Converts a universal time value into a human-readable timestamp string,
formatted as 'YYYY-MM-DD HH:MM:SS'."
  (multiple-value-bind (sec min hour day month year)
      (decode-universal-time universal-time)
    (format nil "~4,'0D-~2,'0D-~2,'0D ~2,'0D:~2,'0D:~2,'0D" year month day hour min sec)))

(defun add-message (name message)
  "Inserts a new message into the database with the given NAME and MESSAGE content."
  (with-connection (db)
    (let ((sql "INSERT INTO message (username, ts, content) VALUES (?, ?, ?)")
          (ts (get-universal-time)))
      (dbi:do-sql *connection* sql (list name ts message)))))


(defun delete-message (id)
  "Deletes the message with the given ID from the database."
  (with-connection (db)
    (let ((sql "DELETE FROM message WHERE id = ?"))
      (dbi:do-sql *connection* sql (list id)))))


(defun get-all-messages ()
  "Retrieves all messages from the database, ordered by timestamp descending.
Timestamps are formatted as human-readable strings."
  (with-connection (db)
    (let* ((sql "SELECT * FROM message ORDER BY ts DESC")
           (messages (dbi:fetch-all
                      (dbi:execute
                       (dbi:prepare *connection* sql)))))
      (mapcar (lambda (row)
                (setf (getf row :|ts|) (format-timestamp (getf row :|ts|)))
                row)
              messages))))

The Web App

Finally we can create the web application which I put inside src/web.lisp. It’s a bit longer then the other files so I will break it into chunks.

(in-package :cl-user)
(defpackage guestbook.web
  (:use :cl
        :caveman2)
  (:import-from :guestbook.config
                :*template-directory*)
  (:import-from :guestbook.db
                :add-message
                :delete-message
                :get-all-messages)
  (:export :*web*))
(in-package :guestbook.web)

(defclass <web> (<app>) ())
(defvar *web* (make-instance '<web>))
(clear-routing-rules *web*)

The web framework I am using is called Caveman, developed by Eitaro Fukamachi, who is a very prolific lisper and the author of multiple libraries that I am using, including Lack, Clack, and cl-dbi, all having great integration with each other. <app> is a class defined by the web framework, and I am extending it and instantiating it in *web*. clear-routing-rules is a function inherited from Ningle, another web framework, which clears the route associations inside the web app instance.

Templates

Our web app needs to render some static templates with data, and to do that there’s a great library called djula, which allows us to use most of the same tags and filters that Django exposes in its template engine.

I’m not going to include the templates source here for space reasons, in the repository they're in the templates/ folder.

(djula:add-template-directory *template-directory*)

(defun render (template-path &optional env)
  "Renders a Djula template from TEMPLATE-PATH.
ENV is an optional plist of variables passed to the template."
  (apply #'djula:render-template*
         (djula:compile-template* (princ-to-string template-path))
         nil
         env))

The first function call tells djula where to find the templates in the project. render is a function that receives a template path as a parameter and compiles the template for better performance.

Routes

To allow users to perform CRUD operations, we need to expose a few routes to be called by the web frontend. There are two ways to define routes in Caveman, but this one seems a bit clearer to me than using annotations. defroute is a macro that receives the route path, some parameters like :method and eventually some arguments, and then defines the body to handle the request. Inside the body, we can access the request object via *request* and extract data from it using, for example, the function request-body-parameters.

The routes are self-descriptive. / renders index.html, passing all the messages from the db; /message handles POST requests and inserts the message in the database if the parameters conform; and /message/delete deletes a message.

(defroute "/" ()
  (render #P"index.html"
          (list :messages (get-all-messages))))


(defroute ("/message" :method :POST) ()
  (let* ((body-params (request-body-parameters *request*))
         (name-param (assoc "name" body-params :test #'string=))
         (message-param (assoc "message" body-params :test #'string=)))
    (if (and (consp name-param) (consp message-param))
      (add-message (cdr name-param)
                   (cdr message-param))
      (format t "Missing body parameters: received ~A~%" body-params)))
  (redirect "/"))


(defroute ("/message/delete" :method :POST) ()
  (let* ((body-params (request-body-parameters *request*))
         (id-param (assoc "id" body-params :test #'string=)))
    (if (consp id-param)
        (let ((id (ignore-errors (parse-integer (cdr id-param)))))
          (when id
            (delete-message id)))
        (format t "Missing id parameter.")))
  (redirect "/"))

I also added another function, which defines a method on the web app class. on-exception is a generic function called when an exception occurs in the web application. This method is specific on the parameter type, since it will run only if the exception has code 404 — not found — and in that case I return a specific custom template.

(defmethod on-exception ((app <web>) (code (eql 404)))
  (declare (ignore app code))
  (render #P"404.html"))

Run the demo

Now I can load the project into the environment with Quicklisp.

> (ql:quickload :guestbook)
To load "guestbook":
  Load 1 ASDF system:
    guestbook
; Loading "guestbook"
......................
(:GUESTBOOK)
CL-USER>

Then I can start the server and point my browser to 127.0.0.1:3210.

> (guestbook.core:start)
Hunchentoot server is started.
Listening on 127.0.0.1:3210.
Server started

I can send messages that get saved with a timestamp and then delete them. Pretty simple.

Reducing boilerplate

Lisp became popular for a series of reasons, and one of the most cited is its ability to reduce boilerplate thanks to the metaprogramming capabilities of the language. Lisp hackers are proud of being able to code solutions faster and do exploratory programming, reducing the size of the code they need to write to reach a solution.

When comparing the lines-of-code count of my Common Lisp guestbook against the Python-Flask version, the latter seems quicker and simpler to write — 36 lines of Python vs. 229 of Lisp. Lisp’s strength is its ability to model itself according to the problem the developer is solving. In this case, I am dealing with a simple guestbook demo, so it may not be strictly necessary, but to present the language better I will try to reduce the size of the program by hiding some code and configuration.

First, let’s have a look at the new guestbook app, written in my new custom web framework called flashcl: 29 LOC, properly formatted and stripped of all comments, and not too hard to read.

(in-package :cl-user)
(defpackage guestbook.core
  (:use :cl :flashcl))
(in-package :guestbook.core)

(init-flashcl :sqlite3 "guestbook.sqlite")

(defmodel message
  ((username :col-type (:varchar 50) :accessor message-username)
   (content  :col-type  :text        :accessor message-content)))

(defroute "/" ()
  (render #P"index.html" (list :messages (db-all 'message))))

(defroute ("/message" :method :POST) ()
  (let ((name (form-param "name"))
        (message (form-param "message")))
    (if (and name message (> (length name) 0) (> (length message) 0))
      (db-add (make-instance 'message :username name :content message))
      (format t "Missing body parameters: received ~A~%" (body-params))))
  (redirect "/"))

(defroute ("/message/delete/:id" :method :POST) (&key id)
  (if id
    (let ((id (ignore-errors (parse-integer id))))
      (when id
        (db-delete (db-find 'message id)))
      (format t "Missing id parameter.")))
  (redirect "/"))

Where did start go? It is now part of the flashcl framework, so it’s imported in the package. Here’s the usage reference.

;; --- Run the Application ---
;; Call run-app function from your REPL or add it here to run on load.
;; Call stop-app to stop the server.
;;
;; Example: (guestook::run-app) or just (run-app) inside the package.
;; (run-app :port 5000 :server :hunchentoot)

Then I slightly modified the template delete button to point to the correct route with the id parameter.

I'm going to show just some the new code that I added to write flashcl. I mostly merged the old code in a new file trying to make it as reusable as I could for other web projects, since it's possible to define new database models and routes quickly, with support for static files and templates. I used mito, another library from Eitaro Fukamachi, which is an ORM that works well with SQLite.

First I imported the library and exported only what’s needed by the user.

(defpackage :flashcl
  (:use #:cl)
  (:import-from #:caveman2
                #:defroute
                #:redirect
                #:*request*
                #:*response*)
  (:import-from #:lack.request
                #:request-parameters)
  (:import-from #:mito
                #:dao-table-class ; Re-export metaclass for use in defmodel
                #:connect-toplevel
                #:ensure-table-exists
                #:select-dao
                #:find-dao
                #:delete-dao
                #:insert-dao)
  (:export ;; Setup
          #:init-flashcl
          ;; App Definition
          #:flashcl-app ;; Variable holding the app instance
          #:defmodel
          ;; Routing & Request/Response
          #:defroute
          #:form-param
          #:render ;; Re-export caveman's render (or wrap it)
          #:redirect ;; Re-export caveman's redirect
          ;; Database
          #:db-all
          #:db-add
          #:db-find
          #:db-delete
          #:dao-table-class ;; Re-export metaclass
          ;; Running
          #:run-app
          #:stop-app))

Then I wrote an initialisation function similar to Flask’s, which sets various variables and creates a new instance of the Caveman webapp.

(defun init-flashcl (db-type db-path &optional (template-dir "templates")
                                               (static-dir "static"))
  "Initializes Flashcl environment. Sets DB/Template paths, connects DB."
  (setf *database-path* (get-absolute-path db-path))
  (setf *static-directory* (get-absolute-path static-dir))

  ;; Set Djula's template directory
  (djula:add-template-directory (get-absolute-path template-dir))
  (format t "Set template directory as ~A~%" (get-absolute-path template-dir))

  ;; Connect to SQLite database
  (handler-case (connect-toplevel db-type :database-name *database-path*)
    (error (c)
      (format *error-output* "~&Error connecting to database ~A: ~A~%" *database-path* c)))

  ;; Define the Caveman2 app instance here
  (setf flashcl-app (make-instance 'caveman2:<app>)))

To make it easy to define a new database model for the application, hiding the mito library, I created a macro that ensures the table gets created correctly. mito automatically adds a few fields to the table definition, like id and created_at or updated_at, so we don't have to worry about them.

(defmacro defmodel (name slots &rest options)
  "Defines a Mito DAO class and ensures its table exists.
   Example: (flashcl:defmodel comment
              ((name :col-type (:varchar 20))
               (comment :col-type :text)))"
  (let ((class-options options)
        (table-name (string-downcase name))) ; Use singular name by default
    
    ;; Add table name inference if not present
    (unless (find :table-name options :key #'car)
      (push `(:table-name ,table-name) class-options))

    `(progn
      (defclass ,name ()
        ,slots
        (:metaclass mito:dao-table-class)
        ,@class-options)
      ;; Ensure table exists after class definition
      ;; Note: This runs at compile/load time when defmodel is processed.
      ;; Ensure DB is connected before loading code using defmodel.
      (handler-case (ensure-table-exists ',name)
        (error (c)
          (format *error-output* "~&Warning: Could not ensure table for ~A (DB might not be connected yet?): ~A~%" ',name c)))
      ;; Return the class name
      ',name)))

Then I added some database helpers to perform a few CRUD actions on the db.

(defun db-all (class-name)
  "Selects all records for the given model class."
  (select-dao class-name))

(defun db-find (class-name id)
  "Finds a model instance by ID."
  (find-dao class-name :id id))

(defun db-add (instance)
  "Inserts a model instance into the database."
  (insert-dao instance))

(defun db-delete (instance)
  "Deletes a model instance from the database."
  (delete-dao instance))

Conclusions

To recap, in this tutorial I used some of the latest libraries in Common Lisp to create a simple guestbook webapp. Then I wrote a simple reusable wrapper to make our code more concise, aiming to challenge the Flask framework in Python. The full source code of the two versions it's here and here.

Ultimately I would like to give my opinion on using Common Lisp to write a web server. Common Lisp shines when dealing with low-level tasks like small systems programming or performing intensive computation at scale. When these complex systems need to communicate with the outside world, perhaps via an API, writing a server is the correct way and Common Lisp is capable of delivering that.

But despite the fact that the language is easily adaptable and comes with performant server libraries (Hunchentoot and Woo), I would say that there are better alternatives for developing generic modern web apps. Hot reloading is now a feature present in many web frameworks, and Common Lisp is not really shining for being ergonomic, nor does it come with many built-ins. Clojure, by contrast, is a modern Lisp dialect with great web frameworks, nice documentation and tons of stable libraries. I would definitely choose the latter for a fresh web project, since with CL I get the feeling that I would end up having to write more code than I should to add custom features and middlewares.

I would like to give a shout-out to Alive, which is the only Common Lisp extension for VSCode that implements the REPL with features similar to what SLIME and SLY bring to Emacs. The extension is still under development and not yet a full replacement for Emacs, especially during debugging, but it has great features and a lot of potential to introduce Common Lisp to newcomers, thanks to the VSCode web interface.

Feel free to email me if you have any questions, recommendations, or even complaints.

Le parole di Nabokov

Tue, 11 Mar 2025 00:00:00 GMT

La mia opinione è che Nabokov non lo si legge per la trama. Ogni suo lavoro è una produzione artistica, uno studio meticoloso della prosa che lascia che i lettori sensibili all’estetica, ammaliati dal ritmo della sua scrittura. Nabokov sfida il lettore spingendolo al limite della sua conoscenza semantica, portando vocaboli poco comuni fuori dal loro contesto, trasformando il testo in un gioco stilistico che affascina ma, che al tempo stesso, scatena un complesso d’inferiorità, quando ci si rende conto che una qualità del genere è quantomeno ineguagliabile.

Avendo di recente riletto il suo capolavoro Lolita (ne ho anche scritto una recensione) mi sono appuntato le parole di cui non conoscevo il significato, o di cui non ero del tutto certo, e ho deciso di riportarle in questo articolo con una breve definizione. L’invito a leggere Nabokov è sottinteso.

Per conoscere e capire l’uomo dietro l’elegante scandalo che fu il romanzo, ho guardato How do you solve a problem like Lolita? — in italiano, come si risolve un problema come Lolita? —, un documentario prodotto dalla BBC riguardo al libro. Nabokov nacque in una facoltosa famiglia della nobiltà russa, cosa che gli permise di vivere in condizioni privilegiate durante la giovinezza, e grazie alla quale ottenne accesso alla cultura internazionale. Imparò il francese e l’inglese — si dice abbia iniziato a leggere e scrivere in inglese prima che in russo —, e si dedicò a riempire quaderni di poesie romantiche durante l’adolescenza. Con la rivoluzione russa, l’intera famiglia fu costretta a scappare e Nabokov decise di trasferisci a Cambridge per studiare letteratura francese al Trinity College. Successivamente seguì il padre a Berlino, dove divenne famoso tra gli emigrati russi come scrittore e poeta, nonostante alcune difficoltà economiche. Con l’aumentare dell’antisemitismo in Germania precedente allo scoppio della guerra, decise di trasferirsi con la moglie Vera a Parigi, per poi qualche anno più tardi muoversi negli Stati Uniti, a Manhattan, avendo ottenuto un ruolo come entomologo al museo di storia naturale di New York. L’anno dopo divenne professore di letteratura e girò diversi college americani finendo la sua carriera alla Cornell University, dov’è alcune sue brillanti lezioni vennero raccolte in dei libri, il più famoso dei quali è Lezioni di letteratura. Le opere che composte negli Stati Uniti, tutte scritte in inglese, lo resero celebre a livello internazionale. Le più famose; Lolita, Fuoco pallido e Pnin.

Oltre a essere un professore poliglotta, e un autore di talento, Nabokov era un appassionato di farfalle. Studiò e catalogò diverse specie, scrisse articoli per addetti ai lavori, e finì addirittura per curare una collezione di lepidotteri presso il Museo di Zoologia Comparata dell’Università di Harvard. Nel documentario hanno intervistato un responsabile del museo che ha confermato come Nabokov non fosse un appassionato alle prime armi, ma un preciso catalogatore di specie di farfalle. Egli, fece diversi viaggi nel mondo dedicandosi alla ricerca di specie rare, e creò una serie di illustrazioni delle farfalle che studiava. Cos’hanno in comune le farfalle e la scrittura? In apparenza nulla. Ma se pensiamo allo studio minuzioso dei particolari che hanno in comune le due attività, capiamo che dedizione e precisione sono requisiti essenziali per entrambe. Che il minuzioso studio dei colori dei lepidotteri possa aver contribuito alla precisa scelta delle parole e del tono nelle sue storie? Non lo sappiamo con certezza. Ciò di cui abbiamo invece testimonianza grazie ad alcune interviste è che gli anni passati da Nabokov come entomologo ad Harvard siano stati tra i migliori della sua vita.

Tra le due passioni, quella che noi comuni lettori possiamo apprezzare è la scrittura, nell’eleganza della sua prosa, nel ritmo musicale e cadenzato, nella scelta accurata di ogni vocabolo. Il protagonista di Lolita è un professore di letteratura francese in America — coincidenze? — con cattive intenzioni, ma di farfalle alate nel romanzo nemmeno l’ombra.

Ecco la lista delle parole per me difficili trovate in Lolita.

Chaperon: Donna, per lo più anziana, che un tempo accompagnava una giovane nubile di buona famiglia ai ricevimenti e nei viaggi, per salvaguardarne la rispettabilità.

Marleniforme: A forma rotonda e bombata, simile a una mela Marlene, tipica del Sud-Tirolo.

“D’un tratto la mano di Lo scivolò nella mia, e all’insaputa del nostro chaperon io strinsi e accarezzai e avvinghiai quella zampetta ardente per tutto il tragitto. Le pinne del naso marleniforme della guidatrice erano lucide, avendo perduto o consumato la loro razione di cipria…”

Bistrate: Tinte, oscurate, scurite con il bistro, uba polvere colorante naturale bruno-scura, costituita da idrato di manganese, usata nei colori a olio o ad acquerello.

Chador: Lungo velo nero, indossato dalle donne islamiche conformemente alla tradizione religiosa. Parola di origine persiana.

Voluttà: Il piacere intenso e predominante che si prova nella soddisfazione degli impulsi e dei desideri sessuali

Eclettico: Chi, nell’arte o nella scienza, non segue un determinato sistema o indirizzo, ma sceglie e armonizza i principi che ritiene migliori.

Reptazione: Modo di locomozione caratteristico di molti animali, sia invertebrati che vertebrati (in molti rettili, in particolare i serpenti), per cui il corpo striscia sul suolo e non è sollevato sugli arti, che mancano o sono rudimentali.

Gibboso: Che porta una gobba.

Cicaleccio: Il cicalare di più persone insieme; chiacchierio frivolo.

Solipsizzata: Immersa in una visione solipsistica, isolata nella propria soggettività, come se tutto il resto fosse irrilevante o inaccessibile.

Abbarbicato: Radicato saldamente.

Preprandiale: Che precede il pranzo.

“Io non progettavo di sposare la povera Charlotte per poi eliminarla in un modo volgare, ripugnante e pericoloso, come metterle cinque compresse di bicloruro di mercurio nello sherry preprandiale o qualcosa del genere…”

Farmacopeico: Che si riferisce alla farmacopea, ovvero l'insieme ufficiale di norme riguardanti la preparazione, il controllo e l’uso dei farmaci.

Nevralgica: Pervasa da un malessere acuto, come il dolore lungo il decorso di un nervo.

Blusa: Camiciotto di tela usato dagli operai e dai pittori durante il lavoro.

Canuto: Dai capelli bianchi.

Rotocalco: Periodico, rivista.

Scriminatura: La linea che segna la spartizione dei capelli.

Serica: Di seta, simile alla seta o legato alla seta.

Mefitici: Che hanno odore fetido, irrespirabile, malsano.

Smargiasseria: Chi si vanta di qualità che non ha e di poter fare cose di cui non è capace.

Enfia: Rigonfia, tumefatta.

Berciava: Urlava sguaiatamente.

Nerboruto: Muscoloso, vigoroso, robusto.

Umbratile: Ombreggiato, ombroso.

Incartapecorita: Che ha assunto, per decrepitezza, aspetto e consistenza paragonabile alla cartapecora; raggrinzito, rugoso.

Muliebre: Della donna, relativo alla donna, con riferimento alle sue qualità, alla dignità del suo ruolo.

Esecrabili: Meritevoli di condanna.

Bilioso: Pieno di bile, e per estensione irritabile, collerico.

Azzimato: Adornato, abbellito con molta cura.

Dedalogia: Lo studio e alla teoria dei labirinti o delle strutture complesse e intricate.

Logomanzia: Pratica divinatoria che si basa sull'interpretazione di parole, frasi o suoni per prevedere il futuro o ottenere risposte

“Aveva letto molto. Sapeva il francese. Era versato in dedalogia e logomanzia.”

Ondinista: Chi crede o pratica la culto delle ondine, figure mitologiche legate all'acqua, spesso rappresentate come spiriti o divinità acquatiche simili a ninfe.

H. P. Lovecraft - Michel Houellebecq

Thu, 24 Oct 2024 00:00:00 GMT

I found a new literary genre with which I feel particularly aligned: biographies of writers written by other writers. By calling it "new," I don't mean it's an emerging trend, but rather a type of novel whose evocative power I had never experienced before. I started with Philip Dick's science fiction when I read the book about him by Emmanuel Carrère, which I liked so much that it made me passionate about both writers. Now, thanks to Michel Houellebecq's biography of H. P. Lovecraft, which I just finished, I cannot wait to dive into the renowned Necronomicon, also known as the Book of the Dead.

Houellebecq's work is not a complete account of the author's life, like Carrère's work on Dick, but rather an analysis of the most significant events of his existence, which, in Lovecraft's case, are quite few. From a young age, he read horror novels and developed a great passion for Edgar Allan Poe, to the point of starting to write stories himself. He had a "nervous" breakdown just as he reached adulthood, which forced him to withdraw from university and lock himself up at home for several years, during which time he did nothing but read. He came from a once-wealthy family that had fallen into ruin, and after the death of his parents, he found himself with a small inheritance, just enough to live without having to work. Lovecraft devoted himself entirely to writing, sending his stories to publishers without asking for payment. He engaged in hundreds of correspondences and managed to create a small circle of admirers of his works. He married an attractive woman, but the initially happy marriage fell apart after a few years due to financial instability and the lack of a steady job—Lovecraft found no stable employment in New York. He returned alone to Providence, to the family residence, and spent his final years in poverty with his sister, working as a ghostwriter and writing his best works. He died of cancer at 46, practically destitute. Success came too late, but when it came, it was magnificent.

"The one thing I never do is sit down and seize a pen with the deliberate intention of writing a story. Nothing but hack work ever comes of that. The only stories I write are those whose central ideas, pictures, and moods occur to me spontaneously.” — H. P. Lovecraft

Lovecraft appeared to be a bland, calm, and reserved individual, but in reality, he led a double life. In his horror stories, his vivid imagination was inspired by the deep hatred he felt for the inept bureaucrats who couldn’t give him an honest job, for the Black people who infested New York like monsters, and for a society so complex and deeply flawed that it made him feel like a misfit and a failure. Lovecraft was a misanthrope who spent much of his life as a recluse, writing horror stories. His upper-class bourgeois upbringing had taught him to despise not only money but also all classes or races that weren’t up to his standards. In New York, his hatred and disgust for the people of color who crowded the city grew, something he wasn’t accustomed to, coming from the provinces. When he returned home, these experiences of hatred that overwhelmed him became the source of inspiration for his terrifying and monstrous stories, where the protagonists, usually white and refined scholars, are cruelly attacked without any hope of salvation.

“Reading Lovecraft offers a paradoxical relief to all those who, for one reason or another, have come to feel a genuine aversion to life in all its forms.” — Michel Houellebecq

In New York, Lovecraft sought work, responding to hundreds of ads and attending hundreds of interviews, only to meet with complete failure. Not finding work made him increasingly disillusioned with life, precisely at the moment when he had married the only woman who had ever loved him, with whom he had imagined a "normal" future together, and perhaps a family. The job market rejected him because he lacked the skills and experience, even though he had an academic education and intellectual abilities above the norm. To him, his inadequacy remained a mystery. I want to quote here an excerpt from a circular he sent to multiple employers: "The concept that a cultured and intelligent person could not quickly acquire any skill in a field slightly outside their habits seems to me at least naive; however, a series of recent events has unequivocally demonstrated to me how widespread this superstition is." The elegance with which he highlights the irrational stupidity of these employers is remarkable. They don’t see individual potential unless it is certified by some kind of institution.

“Howard Phillips Lovecraft serves as an example for anyone who wishes to fail in life and, eventually, succeed in art.” — Michel Houellebecq

Lovecraft failed in life, but succeeded in writing. Houellebecq didn’t choose Lovecraft just because his stories fascinated him as a boy. He chose Lovecraft because, like him he doesn’t feel part of this world, like him he harbors a deep anger toward a society that doesn’t understand him, and both choose to fight it through literature. One thing I like about biographies written by good writers is when they include personal references in the story. In Carrère's case, the allusions to himself are more explicit, while in Houellebecq’s book, knowing today the future themes of his literary production, we can see the conclusions about Lovecraft’s work, expressed with intense passion, as veiled allusions to the feelings the two writers share. Houellebecq writes about Lovecraft because he recognizes in him the same fate, the same force that will push him to make his life a work of art through dissident literature.

“Writers of the fantastic are generally reactionaries, simply because they are particularly, or one might say professionally, conscious of the existence of Evil.” — Michel Houellebecq

This short essay on Lovecraft’s work and life offers a glimpse into his psychology that we couldn’t capture through the reading of his books alone. Houellebecq, as a fervent admirer, offers us a suggestive analysis capable of making us feel both pity and respect for the writer from Providence, while encouraging us, through Lovecraft’s exemplary work, to also oppose the hostility of modern life toward true artists.

“Therein lies the deep secret of Lovecraft's genius, and the pure source of his poetry: he succeeded in transforming his disgust for life into active hostility. To offer an alternative to life in all its forms, to build a permanent opposition, a permanent remedy to life: this is the highest mission of the poet. This mission Howard Phillips Lovecraft accomplished.” — Michel Houellebecq

The very fitting cover of this English edition deserves a mention, unfortunately abandoned in subsequent ones. With about sixty years between them, the two artists are united by the inner malaise that drives them to want to take a stand, with their work, against the world and against life itself.

Primer - Shane Carruth

Tue, 20 Aug 2024 00:00:00 GMT

As a first movie on the blog I decided to review perhaps my all-time favorite title: Primer, the 2004 debut film by Shane Carruth. It’s a psychological science-fiction film in which the two protagonists find themselves confronting the ability to travel through time.

The movie was an independent project that succeeded for several reasons, including the choice not to use special effects — a rare thing for a sci-fi movie — and the fact that Carruth did everything on his own. He wrote the script, composed the soundtrack, directed the movie, produced it, filmed it by renting a film camera, and acted as the lead. If that wasn’t enough, the entire project was accomplished on a budget of just $7,000 (in 2004), with friends and family recruited as actors. Filming was so tough for Carruth that he considered quitting multiple times, and it took him two years to complete the post-production. Carruth, a mathematician who worked as a programmer, was inspired by his academic passion for imagining and writing screenplays. A passion that, luckily for us, he decided to pursue to the end, partly financing the project with his savings.

What fascinated me most about the movie is its complex and simultaneously thrilling plot, which requires the viewer to watch the movie multiple times to fully appreciate it.

Primer is about two American engineers, Abe and Aaron, who build a strange machine in the garage, having gathered the necessary funding from acquaintances. It’s a device the size of a pillow inserted into a box, capable of creating an energy field through an electronic circuit connected to an argon tank. After several failed attempts, the two engineers discover that the machine can make whatever enters its field travel through time. Realizing the potential, they decide to build a human-sized version of it and use it to go back in time to trade stocks and easily make money, knowing the future market valuations.

The machine works ingeniously, or rather, exactly as one might expect such a device to function. When something enters the field generated by the machine, it travels back to the moment when the machine was first turned on. For example, if a person turns on the machine in the morning and decides to enter in the evening, it means they will travel back in time to the morning. Time travel means moving in a space-time continuum, which means the past is a portion formed by a certain time and space within our reality. Therefore, in the film, it is revealed that when you travel through time, two versions of you exist during the interval you traveled, one unaware version that will eventually enter the machine to disappear, and one aware version that has already experienced everything. Every time the machine is used, a new timeline is created in which two individuals coexist for a certain period.

One of the most memorable scenes in the movie is when Abe and Aaron see a copy of Abe enter the garage holding a gas cylinder, and following him, they discover that the copy disappears by entering the machine; from that moment on, only one Abe will live in the present.

If the mechanism isn’t clear, that’s normal; not many grasp it the first time they watch the movie. Fortunately, some enthusiasts on YouTube have created video explanations with timelines that help clarify what really happens in the movie.

Initially, the plan devised by the two engineers to make quick money works, as they buy and sell stocks using their knowledge of the future market trends. The problem arises when the two realize they can do more than just bet by traveling through time. From here on, the plot of the movie becomes more complicated, with the characters making several time travels, leading to physical damage like sudden blood loss from the ears or a degradation of writing abilities. The viewer ends up losing count of how many trips the characters make, eventually wondering if some scenes they’re watching have already happened before.

Primer is a movie that plays with logic through its scenes, leaving the viewer the task of reconstructing a linear plot based on what they’ve seen and imagining the existence of missing scenes. Indeed, the plot appears chaotic, with some scenes that don’t seem to follow a linearity or where unexplained things happen if it’s unclear what’s going on. This is because the characters are traveling through time and altering reality. What seems like confusion turns out to be Carruth’s intention to leave elements unresolved, a sort of stylistic signature that he will repeat in his subsequent work. The entire script, Carruth revealed, was adapted to the limited budget he had, demonstrating that you don’t need large capital to make an intriguing and complex movie, just intellect and motivation.

What fascinates about the movie’s plot is how it presents a much more realistic time travel scenario compared to other works on the same theme. Most stories use time machines that allow characters to go back in history or move forward into the future, developing the plot around the paradoxes that time travel might create. For example, what would happen if, by going back in time, someone altered the course of events preventing their own birth?

Several scientists have spoken out about the impossibility of humans traveling through time, even though science admits the theoretical possibility. But what if time travel didn’t mean going back hundreds or thousands of years? In Primer, the machine allows you to travel back in time only to the moment it was first turned on. This eliminates the possibility of going back in history and leaves open the chance that this type of travel might become feasible in the future.

The plot of Primer plays with logical paradoxes where the characters, unknowingly, alter the sequence of events, creating multiple versions of themselves that coexist permanently in reality. Aaron and Abe gas their copies and lock them in storage rooms, try to prevent Mr. Granger from using the machine, and end up reliving the same scenes multiple times. Aaron even records an audio description of what happened in the future and what is about to happen to his own copy, trying to prevent new alterations to reality. Aaron’s recording becomes the background voice that Carruth inserts into the film to provide more context to the story, which begins with a phone call. What would we think if we received a recorded phone call from ourselves that we don’t remember, describing exactly what’s about to happen? Would we believe it?

Primer is the story of how using technology without fully considering the risks can have disastrous consequences. A sci-fi retelling of the myth of Icarus.

Beautiful star - Yukio Mishima

Fri, 09 Aug 2024 00:00:00 GMT

This is a 1962 work by Yukio Mishima, Japan's greatest author of the last century, and falls within his most mature period. The plot initially tells the story of an unusual Japanese family, the Ōsugi, who discover they have alien origins. Witnessing various UFO sightings, the family members agree not to reveal their extraterrestrial nature, avoiding unwanted attention. Each family member comes from a different planet, and each begins to internalize their alien identity, associating various aspects of their character with their home planet. The daughter, Akiko, comes from Venus and is therefore exceptionally beautiful, while her brother, Kazuo, comes from Mercury, making him a young man full of hope in the eyes of others. Each family member feels special, different from the "terrestrial" humans living around them. This uniqueness, however, eventually makes the father feel responsible towards the planet that hosts them. Their mission becomes one of bringing peace to Earth through concrete actions, such as writing letters to the Soviet Prime Minister asking him to abandon nuclear weapons, or intervening at the Association of Friends of the Universe to report UFO sightings and information on extraterrestrial activities. From here on, the characters reveal rather human traits. For example, they will witness new UFO sightings and signals from space, Akiko will become pregnant with a playboy's child, and a group of frustrated adults, led by an unbalanced university professor, will discover the family's secret and show up at their doorstep.

In the final chapters, a discussion emerges regarding one of the novel's themes: what must be done to save a planet dominated by individualistic humans who only think about material pleasures. On one hand, there are three frustrated men who see salvation in the total destruction of humanity through nuclear weapons. They have no real plan, but superficially discuss why humanity is full of flaws and therefore should not be saved. These men are motivated by resentment born from deep-seated disillusionments in their lives, whether towards women who have always rejected and snubbed them, or towards anyone who is not their beloved family, whom they love and constantly remind their companions they intend to save from the massacre. On the other hand, there is the father, Jūichirō Ōsugi, who agrees with the three men that humanity is not headed in the right direction, especially due to the risk of nuclear conflict that could destroy the planet. However, unlike the group, the father wants to save the planet and feels that his goal, as an extraterrestrial being, is to help humans avoid making mistakes.The book's conclusion focuses on the father's reflection on his unfulfilled life and the vain sacrifice he made to communicate the dangers that humanity faced if it continued to be reckless.

Throughout the plot, between UFOs and philosophical discussions on how humans and aliens perceive time differently, Mishima inserts historical references that dominated the political scene of those years, such as Kennedy's America and Khrushchev's Soviet Union. The three men in the story consider themselves aliens, superior beings capable of knowing and deciding the fate of humanity, and would not hesitate to listen to their irrational side if they were in front of the button that could launch a nuclear attack. Who gives permission to certain individuals to press that button? When our leaders wage wars and launch bombs on civilians, do they feel like superior beings, extraterrestrials, or simply egoistic and power-hungry humans? Fortunately, the unbalanced individuals in the book do not have the power to destroy humanity, because they would not hesitate to do so for frivolous reasons. The question that arises from the long discussion between the men and the father is: if we had that button in front of us, how would we behave?

The story stems from the fear of nuclear conflict that dominated the Cold War era, where a reckless behavior by a single country could have ruined the beauty of our planet forever.

Mishima also includes the theme of the meaning of death, which is so important in his works that it drove him to seek a glorious end for himself. In this book, death is a symbol that puts all humans on the same level. Even those who consider themselves aliens cannot escape a terrestrial event that can strip away the veil and reveal the fragile human side of the characters. The father of the family, terrestrial like the others, would perhaps be willing to die to save the planet from destruction and reveal to humans how to make the Earth a wonderful star. This gives rise to a reflection on life rather than death. What is its meaning? What do we live for? Where can we find meaning within it without relying on religious justifications? An important reflection that catches civilization in a dark period where leaders seem to have forgotten the true value of human life.

Time Out of Joint - Philip K. Dick

Wed, 31 Jul 2024 00:00:00 GMT

Published in 1959, Time Out of Joint is a science fiction novel by Philip K. Dick. The protagonist is Ragle Gumm, a man who lives with his sister Margo's family and makes a living by answering a daily quiz called “Where Will the Little Green Man Appear?” published in a newspaper. The game consists of a large grid where Ragle have to guess in which square the little green man will appear in each day. Ragle is the undisputed champion of the contest, an extraordinary result achieved thanks to his ability to quickly identify patterns that lead him to the solution.

The mystery in the novel begins when Vic, the husband of Ragle's sister Margo, goes to the bathroom in his house during a poker game and tries to pull a chain hanging from the ceiling to turn on the light. He discovers that the chain does not exist but that there is a switch on the wall to turn on the light. From this event, the reality in which the novel is set begins to falter, raising doubts among the characters, who continue the story in a climax of shocking revelations.

Following Philip Dick's narrative style, the characters are minimally characterized, the setting is a 1950s American town, and the protagonists are fearful of the threats of those years, such as the atomic conflict. The entire story serves as a backdrop for the science fiction theater that Dick stages, creating a suspense that keeps readers glued to the pages.

One last curiosity is that the plot of The Truman Show, a 1998 film, was inspired by the novel. But in the book case, it's not about a TV show.

Spoilers ahead.

The references in this story are diverse. Dick tried a new formula for the novel’s plot, compared to his previous works: everyone knows except the protagonist. In fact, more than halfway through the work, it becomes apparent that the reality constructed around Ragle's life is fictitious. When he escapes from the town, the protagonist discovers he is more famous than he thought, even though he doubted himself because, still unmarried, he lived at his sister's house. Ragle, by solving the green man competition in a newspaper, is the one who helps discover where the enemy missiles will fall. Unknowingly, he is an essential part of the defense project, and the government uses his sophisticated analyses to protect the planet. What Ragle does in life is extremely useful to humanity, engaged in an interplanetary war, only he couldn’t realize it before.

Thanks to the biography of Philip Dick curated by Emmanuel Carrère titled I Am Alive and You Are Dead, we discover that Ragle is actually Dick’s alter ego, who spent his days writing science fiction books for children to barely make a living, instead of dedicating himself to greater works he hoped to write one day. Ragle dedicates himself to finding the position of the green man, and the green men were precisely the beings that appeared in the science fiction booklets published in the 1950s, considered minor literature at the time, not worthy of standalone volumes. Ragle solves competitions about green men, Dick writes stories about green men; both follow a passion instead of engaging in real work like responsible adults as society wants them to.

The episode of the cord, mentioned above, is a real event in Dick's life. As his biographer Carrère says, while normal people when something unexpected happens say: "How strange," and don't think about it anymore, Dick kept thinking about it and wondering if there were any hidden meanings. The chain he remembered being in the bathroom could have been some part of his memory that was compromised, a past memory that, for some reason, now reappeared; a glitch in reality, we would say today.

What matters to us is that Dick did an extraordinary job of writing down these delusional obsessions that made him famous. Whether he was right or wrong, we still cannot know with absolute certainty; maybe we are really living in a simulation. Dick always thought of himself as a "chosen one", someone who saw reality differently, and had the need to communicate it to us. He, unlike Ragle, knew, while everyone else was in the dark.

Rust 101

Wed, 10 Apr 2024 00:00:00 GMT

I’ve recently had the chance to try Rust for a project and it has been a surprising pleasant experience. Rust is a modern language and I felt quire familiar with it in a few days. It has a simple and effective design and thanks to that, it gets frequently mentioned as a successor to old low level languages C like. Rust is fast and, in a lot of benchmarks, the compiled code performance is comparable to C and C++. I don’t have experience yet with other similar low-level languages as Nim or Zig but I believe that there’s a reason why Rust got extremely popular in the last few years.

In this article I’ll write down a quick overview of the most important concept that I found make Rust a different and more evolved language compared to it’s predecessor. The Rust documentation is really well written with a lot of example and it will allow you to use the language in a very short time.

Memory Safety

Rust is a memory safe language which means that it’s design prevent the programmer to do operation that could provoke memory faults and crashes of the program. If you ever wrote C or C++ you know what kind of bugs I’m talking about. This kind of problems are hard to spot and debug and in complex programs, it gets easy to use an already free memory or to forget to free one.

There have been two main ways to manage program memory. One is letting the memory management in the hands of the programmer (as C, C++), and the other is using a Garbage Collector that will clean the unused allocated memory portions for you (as Lisp, Java, Python, JS). Manually freeing the memory can get complicated with large and complex programs, and automatic garbage collection can slow down your execution at random, and it’s not that easy to control.

Rust bring a different approach; writing programs that are actually memory safe by design. It does that by not exposing the memory management functions, without using an external tool to do the job. It introduces the concept of ownership, a set of rules that check your code at compile time to prevent you to do operations that break the ownership of a variable.

Ownership

This are the ownership rules:

Each value in Rust has an owner.
There can only be one owner at a time.
When the owner goes out of scope, the value will be dropped.

let s1 = String::from("hello"); // s1 is the owner of the String
let s2 = s1; // s2 becomes the new owner, and s1 is invalidated
println!("{}, world!", s1); // This will cause a compile-time error because s1 is no longer valid

The previous code will not compile. The compiler would even give you suggestion to what caused the error: error[E0382]: borrow of moved value: s1. One may think that the string s1 should still be there, but in reality Rust already called drop on the string structure, deallocating the memory segment and making it no longer valid.

Rust is getting in the way of the programmer for a good reasons; following this rules will prevent problems with memory deallocation, like forgetting to deallocate something, accessing a resource already deallocated, or double freeing a variable. In exchange, Rust is enforcing some patterns and providing some data structure to solve all ownership problems. The following is a useful schema I found on reddit, that quickly points you to which data structure is better to use for each scenario (T is the generic data type).

Borrowing

Borrowing is a mechanism that allows you to create references to data owned by another variable, enabling multiple parts of your code to access and potentially modify the same data without transferring ownership.

fn main() {
    let mut s = String::from("hello");

    change(&mut s);
}

fn change(some_string: &mut String) {
    some_string.push_str(", world");
}

In the code above, I've just created an mutable reference to a String object, and passed it to a function that modify the string. This behaviour it's called borrowing, since we borrow the value, and then give it back to the caller when finished using it.

In Rust, we cannot borrow as mutable variable more than once. This restriction of preventing multiple mutable references to the same data, helps preventing data races at compile time.

Structs and objects

Rust allows the creation of custom data types using struct and enum. A struct is between a C struct and a C++ class. It can be used as object and have access to self, but it’s missing a full support for inheritance.

struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn new(w: u32, h: u32) -> Rectangle {
        Rectangle {
            width: w,
            height: h,
        }
    }

    fn area(&self) -> f64 {
        (self.width * self.height) as f64
    }
}

fn main() {
    let mut rect = Rectangle::new(3, 4);
    println!("Area: {}", rect.area());
}

A new struct Rectangle has been defined, with a simple area method which access the property using the reference to itself.

When a new struct is defined inside a file, it can be encapsulated simply by avoiding the use of pub on the methods. This way, they will not be visible from outside but still accessible from inside.

Traits

Polymorphism can be pefrormed by defining a Trait which adds the possibility to have shared behaviour between structures.

trait Area {
    fn area(&self) -> f64;
}

impl Area for Circle {
    fn area(&self) -> f64 {
        std::f64::consts::PI * self.radius * self.radius
    }
}

Here I've defined a trait Area which every shape struct can implement in it’s own way. The trait it’s only the function signature, with parameters and expected return type.

Enum

Enum are just a way of define a set of values that a variable of that type can take. It’s similar to struct in the sense that accept the use of impl with custom methods and traits.

enum Animal {
    Bird,
    Insect,
    Fish,
    Mammal,
}

Pattern matching

Pattern matching is a construct that is essential in the Rust design. It allows to automatically match the value of a variable using it’s possible states, similar to the statement case in other languages. I use the operator match that receives the variable and give the possibility to execute code when a value is matching.

impl Animal {
    fn can_fly(&self) -> bool {
        match self {
            Animal::Bird => true,
            Animal::Insect => true,
            _ => false, // Covers Fish and Mammal
        }
    }
}

For example, here it's matching all the possible states that a variable of type Animal can have. The option _ is a catch-all pattern, representing all the other possible states that the variable can take.

Result and Option

Two enumerated types that are part of the Rust standard library are Result and Option. They’re values used to deal with errors that need to be managed and potentially absent values. To access the value, the pattern matching method shown above is required.

Result is used in case a function may fail and there's a need to grab the exception and handle it. Rust allows functions to throw errors and then catch them from the caller by performing a match on the function's returned value.

use std::fs::File;
use std::io;

fn read_file(path: &str) -> Result<String, io::Error> {
    let file = File::open(path)?;
    let mut contents = String::new();
    file.read_to_string(&mut contents)?;
    Ok(contents)
}

fn main() {
    match read_file("example.txt") {
        Ok(contents) => println!("File contents: {}", contents),
        Err(error) => println!("Error reading file: {}", error),
    }
}

? is a special operator in Rust that allows to return the error directly, saving you the boilerplate of writing another match.

Option instead is used to return an optional value, since Rust doesn’t have the concept of null (and no Null Pointer Exception).

fn find_first_even(numbers: &[i32]) -> Option<i32> {
    for num in numbers {
        if num % 2 == 0 {
            return Some(*num);
        }
    }
    None
}

fn main() {
    let numbers = vec![1, 3, 5, 7, 8];
    match find_first_even(&numbers) {
        Some(even) => println!("First even number: {}", even),
        None => println!("No even numbers found"),
    }
}

Functional

Rust took closures and iterators from functional programming. It's easy to write inline functions and iterate over array with the set of functions available for functional programming.

let numbers = vec![1, 2, 3, 4, 5];
let doubled: Vec<_> = numbers.iter().map(|x| { x * 2 }).collect();

In the code above I'm using map over a list of numbers, and running the lambda function |x| x * 2 on it, in fact creating a closure. If you need to add the possibility to add iteraction support to a struct, you would need to implement the Iterator trait, as shown in the docs

Analyzer

rust-analyzer is what is going to help you understanding Rust and the patterns that the language is guiding you to use. When integrated inside your favourite editor (I’m using Zed right now), you will see warning and errors generated directly when saving a file.

Let’s try to analyse some broken code

fn main() {
    let s1 = String::from("hello");
    let s2 = s1;
    println!("{}", s1);
}

Why is this code broken?

error[E0382]: borrow of moved value: `s1`
  --> src/main.rs:4:20
   |
65 |     let s1 = String::from("hello");
   |         -- move occurs because `s1` has type `String`, which does not implement the `Copy` trait
66 |     let s2 = s1;
   |              -- value moved here
67 |     println!("{}", s1);
   |                    ^^ value borrowed here after move
   |
   = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value if the performance cost is acceptable
   |
66 |     let s2 = s1.clone();
   |                ++++++++

Rust is telling that when the code does s2 = s1, it moves the value s1 so it cannot be used anymore in the println call. A solution is to clone s1 into s2 so it will then have two independent instances of the string. Pretty handy to find a quick solution, especially for beginners. The Rust team did a great job for creating high quality error messages to guide the user to find a solution.

Macros

Rust supports different types of macros: declarative and procedural. Macro helps extending the language by removing boilerplate code and even extending programs with external code (e.g. plugins).

Declarative macros are called like functions, they just append ! to their name.

#[macro_export]
macro_rules! vec {
    ( $( $x:expr ),* ) => {
        {
            let mut temp_vec = Vec::new();
            $(
                temp_vec.push($x);
            )*
            temp_vec
        }
    };
}

let v = vec![1, 2, 3, 4]; // Creates a new vec inline

My suggestion is to avoid using macros and always prefer functions where possible. Macros are hard to understand, maintain and document when they get complex.

Cargo and packages

cargo is the official package manager for Rust. It downloads the dependencies and keep track of the Rust version the project is supporting. It can be used for all the task related to the project, like running, building it, generating the documentations, etc. The package registry is crates.io which counts more than 140K packages as today.

Tests

Rust provides a test framework directly in the language which supports both unit and integration tests. cargo test is how to run all the tests for a project.

This is a unit test example, included in the same file of the function implementation.

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        let result = 2 + 2;
        assert_eq!(result, 4);
    }
}

When to use Rust

Rust got really popular in the last few years, but it's not a solution for all coding problems, nor a suitable alternative for all cases. When performance is a requirement, instead of using C or C++, Rust can provide much nicer usability and ergonomics, since it's nearly as fast as C but definitely safer, and the choice will pay off in the long run. Big companies have started adopting Rust effectively with great results and enough performance gains in critical parts of their applications to justify the choice.

Humankind - Rutger Bregman

Sat, 06 Apr 2024 00:00:00 GMT

Humankind (in italiano "Una nuova storia (non cinica) dell'umanità") è stata una lettura che mi ha sconvolto. Consiglio di astenersi dal leggerlo a chi vuole rimanere fedele a vecchie ideologie del secolo scorso, perché questo libro potrebbe far cambiare radicalmente idea sul genere umano e sulla società che abbiamo creato negli ultimi secoli. Se anche voi, come me, dopo aver letto Sapiens di Harari, avete pensato che le recenti scoperte scientifiche confermino l'idea che l'essere umano sia per natura egoista, cinico e perverso, Humankind vi farà cambiare opinione. Il libro inizia mettendo in discussione il dogma che l'uomo sia per natura egoista, fondandosi sulle opere di pensatori come Machiavelli, Hobbes, Nietzsche, Freud, Dawkins e molti altri che hanno diffuso questa convinzione in Occidente. Questo mito viene sfatato dall'autore, che usa le ultime ricerche scientifiche per smentire le prove che sono state usate nella storia per sostenere la vecchia ideologia.

Rutger Bregman, filosofo e giornalista olandese classe '88, torna agli inizi del XVIII secolo quando Hobbes, in Inghilterra, credeva che l'uomo nasca cattivo ed egoista e la società sia ciò che lo salva dai suoi istinti bestiali. Mentre nello stesso periodo in Francia, Rousseau era convinto del contrario, ossia che per istinto l'uomo è buono e che la civiltà moderna lo abbia invece danneggiato. Il libro si pone di dare una risposta alla domanda su quale delle due idee contenga la verità, facendo una ricerca che parte dall'evoluzione umana, e ripercorre le tappe che hanno preceduto l'evento che ha dato inizio alla storia della nostra civiltà: la privatizzazione dei terreni. L'autore argomenta, con molti esempi anche recenti, che quell'evento è stata la fonte di molti problemi che ancora oggi affliggono l'uomo, tra cui spicca l'egoismo generato dalla disuguaglianza tra chi possedeva molto e chi nulla.

"A meno di tre anni, i bambini dividono equamente una torta; a sei anni, preferiscono buttarne via una parte piuttosto che dare a uno solo una fetta più grande." - Rutger Bregman

La risposta che dà Bregman è chiara. L'uomo è un animale altamente sociale, evoluto per essere compassionevole con i membri della sua specie; è in grado di ottenere enormi vantaggi applicando questo comportamento, tra i quali spicca l'abilità di apprendere rapidamente dagli altri. Questo è il fattore che ha fatto sì che l'homo sapiens sia stato in grado di sopravvivere e di diffondersi al posto delle altre specie di ominidi. A quanto pare homo homini lupus è stato un errore grossolano perpetrato per secoli.

"Per il 95 per cento della nostra storia abbiamo vissuto in un mondo relativamente pacifico ed egualitario. Ci siamo evoluti per collaborare e prenderci cura gli uni degli altri." - Rutger Bregman

Come mai l'uomo ha accettato di passare da vivere un'esistenza da cacciatore-raccoglitore a vivere stabilmente coltivando la terra? Come mai abbiamo accettato la civiltà e idee come il denaro? Cosa rende alcune persone più capaci a comandare rispetto agli altri? Sono molte le domande a cui il libro si pone, evitando risposte ciniche e guardando in modo oggettivo ai risultati delle ricerche scientifiche degli ultimi anni. Bregman in molti casi racconta di aver creduto in prima persona a idee sbagliate, anche a causa di intellettuali odierni come Noah Harari, Malcolm Gladwell e Richard Dawkins, i quali, pur avendo scritto bestseller, non hanno sempre verificato in maniera approfondita la validità delle fonti da cui hanno attinto.

"Dagli studi psicologici, infatti, risulta che chi si sente impotente è più insicuro; esita prima di esprimere la propria opinione; in un gruppo, si fa più piccolo. Si sente più stupido di quanto sia in realtà. Sono sentimenti che ai potenti fanno comodo. Persone che dubitano di se stesse non si ribellano." - Rutger Bregman

La cosa più notevole del libro, oltre alle sorprendenti conclusioni che ribaltano il pensiero dominante sulla specie umana, è la consapevolezza costante che inculca nel lettore che l'uomo è un animale buono. Concetti come la fiducia reciproca, l'imparzialità, il coraggio, la generosità e la compassione per gli altri, sono stati fin dall'inizio dei secoli elementi fondamentali per l'evoluzione dell'uomo e, conclude Bregman, devono tornare a essere priorità nella nostra vita.

"Come la maggior parte di noi diventerebbe vegetariana all'istante se dovesse macellare da sé una mucca, così la maggior parte dei soldati diventa obiettore di coscienza appena il nemico si avvicina troppo." - Rutger Bregman

Nella seconda parte, il libro racconta di casi in cui sono stati usati degli approcci fuori dal comune, in campi come la gestione aziendale, l'istruzione, la politica e gli istituti penitenziari. Essi diventano esempi e strategie concrete e attuabili per migliorare una società globale che tutti concordano non stia oggi lavorando nell'interesse dell'umanità. Humankind è stato uno di quei libri che tengono incollati e mi ha fatto venire voglia di far sapere a tutti ciò che rivela. È una visione diversa e più positiva di simili autori di bestseller - forse per questo l'autore non viene invitato spesso a parlare con i "big" del presente. "È possibile cambiare il presente, ecco perché farlo e da dove potremmo partire", questo è il tema del libro. Bregman è molto convincente, scrive molto bene e ha idee uniche da cui partire per ragionare su come potremmo cambiare il sistema in cui viviamo, partendo dal basso. Ci vuole coraggio per andare contro alle ideologie che dominano i nostri tempi. Consigliato.

"Quelle che noi chiamiamo le "pietre miliari della civiltà" – l'invenzione del denaro, della scrittura e della giustizia – furono, in origine, le pietre miliari dell'oppressione." - Rutger Bregman

Un indovino mi disse - Tiziano Terzani

Wed, 03 Apr 2024 00:00:00 GMT

Un indovino mi disse, racconta il viaggio che Tiziano Terzani compì attraverso l’Asia all’inizio degli anni novanta, evitando gli aerei per sfuggire alla morte, come gli era stato suggerito di fare da un veggente. Con la scusa di consultare gli indovini più rinomati in tutti i paesi in cui si ferma, Terzani mostra i cambiamenti che il continente ha subito negli ultimi anni a causa della ricerca smodata di modernità. Molte città si stavano trasformando da paradisi di pace e tranquillità in metropoli occidentali, i colletti bianchi e l’abbigliamento alla moda stavano sostituendo gli abiti tradizionali e i sandali, mentre grattacieli sorgevano in pochi mesi al posto di luoghi sacri e giardini centenari. Terzani intuisce le conseguenze che una corsa sconsiderata al progresso avrebbe lasciato su un continente antico come l’Asia e sulla sua popolazione inadeguata al cambiamento; la scomparsa delle culture e delle tradizioni, lo sfruttamento del lavoro e delle risorse naturali, il turismo aggressivo che avrebbe rovinato l’unicità e la sacralità di molti luoghi rendendoli uguali a qualsiasi altra attrazione nel resto del mondo. Secondo Terzani, l’Asia avrebbe presto perso quella magia che la rendeva speciale.

"Tutti corrono, ma verso dove? Perché? Molti sentono che questo correre non ci si addice e che ci fa perdere tanti vecchi piaceri." - Tiziano Terzani

Nel viaggio avventuroso tra i molteplici paesi del continente, Terzani viene a contatto con diverse persone che include nel racconto; venditori mongoli con il vizio del vino, dittatori che gestiscono traffici di droga, benefattori e studiosi che lo spronano e lo aiutano nella sua ricerca degli indovini. Sono soprattutto le parole dei veggenti che risaltano tra le pagine del libro, alcuni facevano previsioni strampalate, mentre altri, ricevendo data e ora di nascita, erano in grado di descrivere in modo sorprendente il passato e il futuro di chi li consultava. Terzani riporta le parti essenziali di queste conversazioni, farcendole sempre con la giusta dose di scetticismo che ci si aspetta da un giornalista europeo. L'autore dimostra inoltre di avere una mente aperta, al punto da riuscire a comprendere cambiamenti politici complessi, come il motivo per cui la Malesia si fosse aggrappata a sostenere un nuovo fondamentalismo islamico per porre un freno all’invasione del materialismo cinese. Il reportage del viaggio è ricco di aneddoti e di riferimenti ad altri autori le cui opere lo accompagnano sui treni e sulle navi che prende. Terzani parla della sua vita privata e della sua famiglia, e inserisce riferimenti alla sua carriera e alla scelta di abbandonare un posto fisso stabile e remunerato per ottenere la libertà di poter viaggiare dove gli piaceva. Come gli dicono molti gli indovini, “non diventerà ricco, ma farà successo”, e che era molto “fortunato”. Che avesse dubbi in merito, poco importa; il libro ha oggi superato le 800 mila copie e credo di poterlo aggiungere alla mia lista di opere che mi hanno lasciato un segno.

"Dopo il Medioevo del materialismo, l’umanità dovrà ricominciare a mettere altri valori nella propria esistenza." - Tiziano Terzani

Tutti corrono, ma verso dove? Terzani non parla solo della corsa al progresso o della corsa al successo, ma anche di quanto vanno di corsa i turisti. Arrivano in massa sugli aerei e in due settimane pretendono di viaggiare in tre paesi diversi e vivere tutte le esperienze possibili, vedere tutte le attrazioni disponibi, scattare centinaia di inutili foto per mostrare a tutti che anche loro si possono permettere di viaggiare. All’apparenza non c’è nulla di male; chi dice che non si può prendere un aereo per andare ovunque nel mondo? Esistono tanti servizi fatti apposta per questo, come B&B, tour operator, viaggi last-minute, è così che viaggiano tutti. La verità è semplicemente che il turismo di massa è diventata un'altra manifestazione del consumismo. È irrealistico pretendere di conoscere un paese e la sua tradizione in soli dieci giorni di viaggio, soprattutto se tutto è già stato organizzato. Si tende a visitare le principali attrazioni turistiche, vivendo un'esperienza superficiale. Non si riesce a comprendere appieno la vita quotidiana e il pensiero degli abitanti locali, né ci si avvicina (e forse neanche si desidera farlo) alla vera diversità culturale che si trova al di là delle immagini condivise sui social media. Terzani, nel libro, viene a conoscenza di molte curiosità proprio perché sceglie di usare treni e navi, dove è costretto a condividere il viaggio, ricevendo in regalo del tempo per parlare con le persone che incontra. Tutto questo in aereo non accade perché si attende in areoporti affollati, circondati da negozi che vendono di tutto, e spesso non si tende a condividere

I paesi ricchi dispongono di organizzazioni che promuovono la tutela del territorio come risorsa per il futuro, mentre nei paesi poveri i viaggiatori devono confrontarsi con gli effetti distruttivi che il turismo di massa ha prodotto. Chi crede di fare del bene portando denaro nei paesi poveri, in realtà finisce per arricchire solo una piccola parte della popolazione, accentuando una disuguaglianza che, prima dell’arrivo della modernità e del capitalismo totalitario, era meno evidente. Erano tutti più poveri e, allo stesso tempo, più ricchi: così li descrive Terzani. Molti dei paesi orientali presenti nel libro hanno una storia e una mentalità uniche, e prima del cambiamento moderno alla popolazione non interessavano sviluppo e progresso. La modernità è stata imposta, la popolazione indottrinata, e molti luoghi storici e sacri hanno finito per perdere il loro fascino. Presto ci si accorgerà del valore perduto di una natura intatta e incontaminata di cui molti paesi del terzo mondo disponevano gratuitamente.

Lolita - Vladimir Nabokov

Sun, 04 Feb 2024 00:00:00 GMT

Alla domanda su cos’è che rende un libro un successo, Ken Follett ha risposto che il fattore chiave è la capacità dello scrittore di far condividere al lettore le emozioni che vivono i personaggi. Per questo motivo Lolita è da considerarsi uno dei romanzi più importanti del XX secolo. Perché farci immergere nella mente di un pedofilo, e farci provare emozioni come empatia, pena, rabbia, per un protagonista maledetto, è una delle fatiche più ardue che un scrittore possa compiere. E se ciò non fosse abbastanza, pensate a quanto coraggio possa servire per pubblicare un libro del genere.

Se pensiamo per un attimo alle storie più macabre che conosciamo, è probabile che ci vengano in mente soggetti come tossicodipendenti, assassini, truffatori e traditori. E se il narratore è stato abile, siamo riusciti a instaurare una connessione emotiva con le vicende di questi personaggi. Nessuno però, prima di Lolita, aveva rotto il tabù della sessualità tra un uomo adulto e una ragazzina agli inizi dell’adolescenza. Non a caso il libro fu più volte rifiutato dagli editori americani, per poi essere pubblicato a Parigi da una casa editrice di romanzi erotici. Lolita venne respinto - causa possibili censure - allo stesso modo in cui vennero scartate le opere di Proust, Joyce, Hemingway, che una volta ripescate divennero dei capolavori pubblicati ancora oggi. Lolita aveva sollevato una questione morale per gli editori. Non era solo un libro osceno: spingeva la trasgressione ben oltre ciò che la società americana degli anni Cinquanta, conservatrice e puritana, era disposta a tollerare.

Il racconto è la confessione dei crimini commessi da Humbert Humbert, mentre si trova in una cella carceraria in attesa di giudizio per omicidio e pedofilia. Nabokov scelse di raccontare in prima persona per creare un resoconto dei fatti realistico, al punto che in alcuni momenti il narratore e lo scrittore paiono sovrapporsi. La scrittura è raffinata, artistica, nitida, e combacia con il profilo del protagonista professore universitario, risaltando le sue ossessioni e il suo spirito romantico -- a suo modo. Perché tra i sentimenti che appaiono nel libro, spicca soprattuto l’amore. Un amore perverso, frutto di un capriccio non esaudito in gioventù, sfociato col tempo in un desiderio morboso per le giovani ragazzine che rispettano certi standard - che Humbert chiama ninfette. Quando incontra Dolores, la sua Lolita, rivede in lei i tratti dell’adolescente di cui si era invaghito anni prima. Lolita gli appare così perfetta da voler far di lei la sua ninfetta, era l'occasione che aspettava, un vero dono del destino.

“Devi capire che il viaggiatore incantato, posseduto da una ninfetta e a lei asservito, sta, per così dire, oltre la felicità. Nulla al mondo, infatti, dà tanta beatitudine quanto accarezzare una ninfetta.” — Vladimir Nabokov

Un amore folle, nocivo, e non corrisposto, rende Humbert cieco di fronte ai disagi patiti dalla ragazzina per i continui abusi, i ricatti e le menzogne da lui perpetrati. Un amore distruttivo nel quale tutte le persone coinvolte finiscono per esserne danneggiate. All’inizio del romanzo, Humbert sembra quasi simpatico con la sua ironia forbita, ma quando la narrazione entra nel vivo, gradualmente la figura si sgretola e capiamo che i suoi non sono solamente dei capricci sentimentali; Humbert sarebbe disposto a tutto per avere Lolita tutta per se. Diventa quindi un personaggio snob che giudica chiunque incontri, cinico quando mente alla ragazzina in cambio di favori sessuali, e comprandole qualsiasi cosa desidera quando lei prova a ribellarsi al gioco perverso in cui lui l’ha condotta, abusando dell’innocenza di lei.

“Sapevo di essermi innamorato di Lolita per sempre; ma sapevo anche che lei non sarebbe stata per sempre Lolita” — Vladimir Nabokov

Il libro non cade nella descrizione di scene erotiche; Nabokov non cercava lo scandalo per ottenere fama e vendere copie. L’anatomia della ragazzina è abbozzata con dei dettagli innocenti che il protagonista annota nella sua mente. È una tecnica che aveva già sperimentato in precedenza in altre sue opere, come Una risata nel buio, dove una giovane e attraente ragazza porta alla rovina un adulto facoltoso ma sprovveduto. Non è la prima volta che Nabokov affronta una storia d’amore travagliata, con differenze d’età tra gli amanti. L’idea stessa di Lolita, ci racconta Nabokov, era nata molti anni prima e più volte tentò di abbozzare la storia e per poco non ne distrusse i manoscritti. Lolita, nella storia, diventa qualcosa in più dell’oggetto del desiderio. Come suggerisce Stefano Bartezzaghi in un intervista su Rai Cultura, Nabokov fa si che Lolita giochi il ruolo della madeleine per Humbert Humbert, perché riesce a fargli riscoprire l’amore perduto in gioventù. Il concetto di memoria nel libro venne sicuramente influenzato dagli scritti di Proust, tanté che Nabokov tenne tenne delle lezioni sullo scrittore francese quand'era professore di lettere in America.

Il compito più difficile nel leggere Lolita è interpretarne il significato. Nabokov, nella postfazione, afferma che il libro non ha nessuna morale ma che l’unico scopo sia quello di provocare nel lettore ciò che chiama la “voluttà estetica”, ossia entrare in contatto con altri stati dell’essere dove l’arte è la norma. Anche se lo scrittore abbia ideato la trama senza appropriargli un significato, non implica che il testo sia privo di senso. Il protagonista vive in America nell’epoca del trionfo capitalista del dopoguerra, in cui l’ideologia dominante affermava che il verso e ultimo scopo della vita è quello di soddisfare i propri desideri. In Humbert riecheggia questo pensiero, tramite la figura di un uomo egocentrico e poco empatico. Forse possiamo trovare un senso in questo racconto degli impulsi fisiologici di un pervertito, quello di leggere i desideri nascosti della società perbene del tempo. A questo proposito, nel documentario della BBC del 2009 How Do You Solve A Problem Like Lolita?, Stephen Smith, ripercorrendo i luoghi in Nabokov aveva vissuto, parla di come lo scrittore, quando era ancora in Russia, componeva racconti e poesie d’amore. Lolita invece appartiene ad un Nabokov oramai maturo; l’amore diventa un sentimento corrotto e perverso, forse inconsapevolmente contaminato dai cambiamenti culturali avvenuti nel tempo.

Lolita's incipit

Wed, 20 Dec 2023 00:00:00 GMT

“Lolita, light of my life, fire of my loins. My sin, my soul. Lo-lee-ta: the tip of the tongue taking a trip of three steps down the palate to tap, at three, on the teeth. Lo. Lee. Ta. She was Lo, plain Lo, in the morning, standing four feet ten in one sock. She was Lola in slacks. She was Dolly at school. She was Dolores on the dotted line. But in my arms she was always Lolita.” — Vladimir Nabokov

We will need writers who can remember freedom

Wed, 13 Dec 2023 00:00:00 GMT

I just wanted to share this speech by Ursula K. LeGuin (1929 - 2018). It expresses a point of view that inspires hope in literature as a way to imagine alternative worlds to the one we live in today. Art has the power of not having to submit to anyone's will other than its creator. And literature will lose this advantage that sets it apart from the rest of entertainment if it's used merely as a product to make money.

“Hard times are coming, when we’ll be wanting the voices of writers who can see alternatives to how we live now, can see through our fear-stricken society and its obsessive technologies to other ways of being, and even imagine real grounds for hope. We’ll need writers who can remember freedom — poets, visionaries — realists of a larger reality.” — U. K. Le Guin

Transcript available here.

Common Lisp data structures

Tue, 12 Dec 2023 00:00:00 GMT

Quick reference for the main data structures in Common Lisp. The code has been tested using SBCL.

Some good rules for Common Lisp that I found say:

Use the appropriate data structure for the situation.
Favor iteration over recursion. Recursion is good for recursive data structures.

List

Lists are used when you need to store a sequence of elements. It supports different data types. They are particularly useful when you need to perform operations that involve recursion or iteration.

Key points: ordered, flexible size, efficient for traversal, slow for random access

;; Declaration
cl-user> (defparameter *list* '(1 2 3 4))
*list*
cl-user> (list 1 2 3 4) ; alternative
(1 2 3 4)

;; Access
cl-user> (nth 3 *list*) ; not performant for long lists
4 (3 bits, #x4, #o4, #b100)
cl-user> (first *list*)
1 (1 bit, #x1, #o1, #b1)

;; Adding
cl-user> (push '0 *list*)
(0 1 2 3 4)

;; Deleting
cl-user> (setf *list* (remove 1 *list*))
(0 2 3 4)

Association list - alist

Association lists are lists, implemented using cons cells, which are used to store key-value pairs where the key is a symbol. They are slower than hash-tables for large amount of data.

Key points: key-value pairs, simple structure, inefficient for large datasets

;; Declaration
cl-user> (defparameter *alist* '((:a . 1) (:b . 2)))
*alist*

;; Access
cl-user> (assoc :a *alist*)
(A . 1)
cl-user> (cdr (assoc :a *alist*))
1

;; Adding
cl-user> (push '(:c . 3) *alist*)
((C . 3) (A . 1) (B . 2))

;; Deleting
cl-user> (setf *alist* (remove :c *alist* :key #'car))
((A . 1) (B . 2))

Property list - plist

Property are used when you need to store key-value pairs and the keys are symbols. They are simpler than hash tables and association lists but can be slower for large amounts of data.

Key points: key-value pairs, lightweight, inefficient for large datasets

;; Declaration
cl-user> (defparameter *plist* '(:key1 value1 :key2 value2))
*plist*

;; Access
cl-user> (getf *plist* :key1)
value1

;; Adding
cl-user> (setf (getf *plist* :new-key) 'new-value)
new-value

;; Deleting
cl-user> (remf *plist* :key1)
t
cl-user> *plist*
(:new-key new-value :key2 value2)

Hash table

Hash tables store key-value pairs and provide efficient lookup and storage. They are highly efficient for large datasets.

Key points: key-value pairs, fast lookups, mutable

;; Declaration
cl-user> (defparameter *hash-table* (make-hash-table))
*hash-table*

;; Adding
cl-user> (setf (gethash 'key1 *hash-table*) 'value1)
value1

;; Access
cl-user> (gethash 'key1 *hash-table*)
value1

;; Deleting
cl-user> (remhash 'key1 *hash-table*)
t

Array

Arrays are multidimensional data structures that hold elements accessible by indices. Arrays are faster than lists for random access, but slower for operations that involve adding or removing elements. Arrays have a fixed size upon creation, but they can be resized using adjust-array.

Key points: multidimensional, fixed size, efficient access by index

;; Declaration
cl-user> (defparameter *array* (make-array 4 :initial-contents '(1 2 3 4)))
*array*

;; Access
cl-user> (aref *array* 2)
3

;; Modifying
cl-user> (setf (aref *array* 1) 5)
5

;; Extending/Shrinking
cl-user> (setf *array* (adjust-array *array* 6 :initial-element 0))
#(1 5 3 4 0 0)

;; Deleting
;; To delete elements, consider creating a new array without the unwanted elements.

Vector

A vector is a one-dimensional array. Vectors are similar to arrays but can dynamically grow and shrink using functions like vector-push and vector-pop. Vectors are particularly useful when you need a sequence that can change size dynamically.

Key points: one-dimensional, dynamic size, efficient access by index

;; Declaration
cl-user> (defparameter *vector* #(1 2 3 4))
*vector*

;; Access
cl-user> (elt *vector* 0)
1

;; Modifying
cl-user> (setf (elt *vector* 3) 5)
5

;; Adding elements
cl-user> (vector-push-extend 6 *vector*)
4
cl-user> *vector*
#(1 2 3 5 6)

;; Removing elements
cl-user> (vector-pop *vector*)
6
cl-user> *vector*
#(1 2 3 5)

;; Converting to a list
cl-user> (coerce *vector* 'list)
(1 2 3 5)

;; Shrinking/Extending
cl-user> (setf (fill-pointer *vector*) 2)
2
cl-user> *vector*
#(1 2)

;; Push extending
cl-user> (vector-push-extend 7 *vector*)
2
cl-user> *vector*
#(1 2 7)

Structure

Structures are user-defined data structures created using defstruct, allowing the grouping of different data types together.

Key points: user-defined, structured, efficient access

;; Declaration
cl-user> (defstruct person name age)
person

;; Creating
cl-user> (make-person :name 'Alice :age 30)
#S(PERSON :NAME ALICE :AGE 30)

cl-user> (defvar *person* (make-person :name 'Bob :age 25))
*PERSON*

;; Access
cl-user> (person-name *person*)
BOB

;; Modifying
cl-user> (setf (person-age *person*) 40)
40

;; Deleting
cl-user> (makunbound '*person*)
*PERSON*

References

How to add a Clojure REPL to a web page

Fri, 24 Mar 2023 00:00:00 GMT

One of the advantages of working with Clojure is that it can be used on top of the JVM as well as in the browser. This is possible thanks to the Clojurescript compiler, which takes your .cljs files and turns them into optimized Javascript with the help of the Google Closure compiler, ready to be embedded into a webpage. Since Clojurescript translate Clojure code to Javascript, in theory, it should be possible to run Clojurescript directly in the browser, since Javascript interpreter is exposed to the user.

I got inspired after experimenting with a cool project to present the Haskell language called Try Haskell, which allows to run Haskell in the browser. It made me thinking about how I could replicate it using Clojure, so that users can type in a REPL on a web page. I started searching for a way to embed a working Clojure REPL in a small web app and this is what I found. There are various way to achieve this. The old method was using the self-hosted cljs compiler, but there's a simpler approach. Thanks to SCI, the Small Clojure Interpreter is now possible to write and execute Clojurescript code on top of Javascript; this means it can be executed in the browser.

The simplest way to try it is to add the library via CDN. Just include Scittle library, same as SCI but loaded with a script tag into a webpage. It doesn't need any additional library or Clojurescript.

<script
  type="text/javascript"
  src="https://cdn.jsdelivr.net/npm/scittle@0.5.14/dist/scittle.js"
></script>

Then you can write your Clojure code into a script tag, or load a clojurescript file.

<script type="application/x-scittle">
  (println "Hello Wolrd")
</script>
<!-- or -->
<script src="app.cljs" type="application/x-scittle"></script>

For the rest of the tutorial, I'll be using SCI so the library get's loaded via Clojurescript. Refer to SCI docs to learn how to do it.

You can try the Clojure REPL with a tutorial at TryClojure.org.

SCI

The core of the app is the integration of SCI. It essentially provide a way to safely evaluate the strings that the user input in the REPL. I said "safe" since it creates a sandboxed environment where we can run our code. The Clojure interpreter runs directly in the browser's JavaScript engine, offering the same functionalities of the developer console.

We can create a SCI context by using the function sci/init with some initialization options.

(ns app.sci
  (:require [sci.core :as sci]))
   
(defonce context (atom (sci/init init-opts)))

I'm, using an atom since it lets me add options during execution by updating the context, as shown in the following function.

(defn extend-ctx
  "Extend default sci context merging `opts`."
  [opts]
  (reset! context (sci/merge-opts @context opts)))

I set a custom print function, by changing the default binding of print-fn for sci.

(defn set-print-fn
  "Setup a custom `print-fn` for sci."
  [f]
  (sci/alter-var-root sci/print-fn (constantly f)))

I created a wrapper around eval-string* for better error management. The error/error-handler function prints errors to console along with the stacktrace. This is the core function of the app: SCI evaluates a string and returns the output of the execution.

(defn eval-string
  "Evaluate `source` using the sci interpreter and return its output.
   If an error occurs during evaluation, raise an exception."
  [source]
  (try (sci/eval-string* @context source)
       (catch :default e
         (error/error-handler e (:src context))
         (let [sci-error? (isa? (:type (ex-data e)) :sci/error)]
           (throw (if sci-error?
                    (or (ex-cause e) e)
                    e))))))

REPL

I created a custom function write-repl!, to print the evaluation output. It appends the value to a vector that stores the output history.

(ns app.repl.core
  (:require [reagent.core :as r]
            [app.sci :as sci]))
  
(defonce repl-history (r/atom []))
  
(defn- write-repl!
  "Append `s` to the REPL history.
  Optional keyword `k` to use as a type."
  ([s]
   (write-repl! s :output))
  ([s k]
   (swap! repl-history conj {:type k :value s})))

(sci/set-print-fn (fn [s] (write-repl! s)))

I extended the context by adding a few functions to the user default namespace. This functions can be called in the REPL, and they're able to interact with the webpage. For example changing some environment variables like prompt symbol color, the current user name, or interacting with the tutorial steps.

(sci/extend-ctx
 {:namespaces {'user {'start start-tutorial
                      'clear clear-repl
                      'restart restart-tutorial
                      'my-name set-name
                      'next-step inc-step!
                      'prev-step dec-step!
                      'set-step (when DEBUG set-step)
                      'set-prompt set-prompt
                      'more (fn [] true)
                      'help print-help}}})

For example the clear-repl function resets the history to an empty vector, returning nil.

(defn clear-repl []
  (reset! repl-history [])
  nil)

All the Clojurescript code is evaluated using eval-string. The typical way to do this is when the user press "Enter" in the REPL HTML input element, but we can also use it to import an entire namespace.

;; Import `repl` namespace helper functions 
(sci/eval-string "(require '[clojure.repl :refer :all])")

Colophon

I released TryClojure more than a year ago but I didn't write any content on how I made it. It's a frontend-only app served by Netlify, with no backend since all the code runs in the browser. I've used a few libraries to build the app. The build process is managed with shadow-cljs, I've used Tailwind for styles, and Reagent for creating UI components.

The missing ClojureScript re-frame Quick Start Tutorial

Sat, 18 Mar 2023 00:00:00 GMT

Re-frame lacks a quick start guide, so this is my attempt to create one, including a TodoMVC tutorial.

When I discovered Clojurescript and started to play around with it, the first library that I used was Reagent. Essentially, it's a wrapper around React, allowing us to write components as Clojurescript functions and instead of JSX, using vectors and keywords[^helix] for the syntax. It has been pretty easy to start with, since I already known how React works and I was comfortable with the Clojure syntax. Like its parent library, it's basically offers a way to define reusable component, with internal state and props received from the parent components.

Since React and Reagent are UI libraries, the application state management is left to the programmer, and that's where something like re-frame comes handy. It implements a model, view, update paradigm using Reagent under the hood, and help separating the state management (model, update) from the UI components (view). The library is similar to Redux having a single central store for state and unidirectional data flow.

The problem I found with re-frame, although it's actually a simple library, is that the documentation doesn't provide a quick start page like Reagent. Instead, it only offers a long, detailed explanation (which is still a recommended reading for fully comprehend how to architecture large apps). If you're already familiar with similar paradigms, a quick guide would be enough to get started with it.

;; Importing the library
(:require [re-frame.core :as rf])

App-db

The entire application state is saved inside a Reagent version of a single Clojure atom called app-db. It's just a map, initially empty, similar to the following one.

(def app-db ; will be called db from now on 
  {})

Re-frame stores the app state in a single source of truth, which, like all Clojure data structures, is immutable and updated using pure functions. This pattern makes state management flow simple to understand, ensures changes in state are predictable, and makes debugging easier.

This is a great explanation on how app-db works, directly from the re-frame README:

at any one time, the value in app-db is the result of performing a reduce over the entire collection of events dispatched in the app up until that time. The combining function for this reduce is the set of registered event handlers.

Re-frame progress in time applying the event handler functions to the previous state of the app. This means that the collection of events is replay-able from the beginning of time, step by step; a dream for debugging an app. To achieve this, it's important that all the event handlers are pure functions (without side-effects).

Dispatch

To modify the user name value inside the app state, one needs to dispatch a new event. So, simply call the dispatch function with a vector containing the event name :user/update-name and the new value for the user name.

(rf/dispatch [:user/update-name new-user-name])

The dispatch function sends the event in the re-frame event-loop for async processing. It can be used from anywhere in the application, so in this case it would most likely happen in a reaction to a click event on a "Save" button.

Events

Now, it's necessary to define a new re-frame event handler using reg-event-db which updates the user name inside the app db. The event handler function receives the current state (db) and the triggering event as arguments. The event is a vector containing the event name (as a keyword) and the parameters.

(rf/reg-event-db
  :user/update-name
  (fn [db [event-kw new-user-name]]
    (assoc-in db [:user :name] new-user-name)))

Now our app-db will look like the following:

{:user {:name "admin"}}

An event handler should be a pure function which returns a new version of the db, only based on its input parameters and the previous state of the app. Again, it should be free from side-effects. A function is considered pure if a given input maps to the same output all the time.

Subscriptions

To show the user name inside a component, create a re-frame subscription called :user/name that extract the value of :name relative to the current :user in the state.

(rf/reg-sub
  :user/name
  (fn [db query-v]
    (get-in db [:user :name]])))

The handler function receives the app-db and query-v as parameters. query-v is the vector supplied to the subscription. In this case above, it's quite simple, and it's not using it. It's just doing an extraction of a value from the state.

The new subscription can be connected to a Reagent component using subscribe, which accepts a vector where the first element is the name of the subscription, and the rest other possible parameters.

(defn user-name []
  ;; Returns an atom that needs to be dereferenced
  (let [username @(rf/subscribe [:user/name])]
    [:h1 username]))

Now every time the value of [:user :name] changes in the db, the related subscription function will re-run, and the new value will be propagated to the views depending on them, updating the Reagent component. We don't have to care about state management if the component mount/refresh because it's all delegated to re-frame. No more large props cascade, no context/provider pattern. A single map contains the entire app state that refreshes the view when gets updated.

Re-frame is implementing a pattern called unidirectional data flow, where the application state can only be modified with dispatched actions. These actions trigger event handler functions that update the state. Than, the changes propagate consistently throughout the application. There is only one way to update the view. As a result, our view is a deterministic function of the data, making the data flow more predictable.

Subscriptions are not only used as extractors but they can also compute derived data from other subscriptions. For example, the user name can be returned in uppercase or lowercase.

(rf/reg-sub
  :user/name-uppercase
  ;; signals function
  (fn [query-v]
    (rf/subscribe [:user/name]))
  ;; computation function
  (fn [username query-v]
    (string/upper-case username)))
    
(rf/reg-sub
  :user/name-lowercase
  (fn [query-v]
    (rf/subscribe [:user/name]))
  (fn [username query-v]
    (string/lower-case username)))

In this case our subscription recevies two functions:

A signals function that returns one or more subscriptions. It can return either a single signal, a vector of signals, or a map where the values are the signals.
A computation function that takes the input values provided by the signals function, supplied as the first argument, and produces a new derived value, which will be the output of the node.

Another subscription that receives a parameter can be created easily.

(rf/reg-sub
  :user/name-prefix-case
  (fn [[_ prefix str-case]]
    (case str-case     ; don't get confused
      :upper (rf/subscribe [:user/name-uppercase])
      :lower (rf/subscribe [:user/name-lowercase])
      (rf/subscribe [:user/name])))
  (fn [username [_ prefix str-case]]
    (str prefix ": " username)))

And it would be invoked as:

(rf/subscribe [:user/name-prefix-case "Username" :lower])

Co-Effects

In case something else is required, other than update the state, such as storing data asynchronously, the event handler need to cause side effects. To do this the previous handler defined with reg-event-db must be replaced with reg-event-fx. When to use one or the other? reg-event-db when only updating the state, reg-event-fx when side effects are needed (mostly defined with :fx); The latter can be seen as a wrapper of the former. Why using a separate function for side-effects? Because our event handler functions have to be pure, to keep the ability to have the state update history as a sequence of changes over time.

In the following code, we replaced the event handler to return a map with :db as the new app state and :fx a vector telling re-frame to dispatch asynchronously another event :user/save-asynch that would save the new user name somewhere like in the database with a server call.

(rf/reg-event-fx
  :user/update-name
  (fn [{db :db} [_ new-user-name_]] ; 1st arg is coeffects, which contains the db
    {:db (assoc-in db [:user :name] new-user-name)
     :fx [[:dispatch [:user/save-asynch]]]}))

:dispatch is a built-in effect used to dispatch a single event. One can even create new custom effects, that are performing side-effects, after the app state ad been updated. This one will show an annoying alert to the user.

(rf/reg-fx
  :alert
  (fn [s] (js/alert s))

To use it, modify the map returned before:

{:db (assoc-in db [:user :name] new-user-name)
 :fx [[:dispatch [:user/save-asynch]]
      (when (> (count new-user-name) 10)
        [:alert "What a long name!"])]

TodoMVC tutorial

For the one of you, like me, who prefer learning with a practical examples, here's a working example of TodoMVC created with Reagent and re-frame.

First I initialized the app-db state with empty values using a new event handler called :initialize-db, which returns a new :db set the initial state of the app.

(rf/reg-event-fx
 :initialize-db
 (fn [_ _]
   {:db {:todo {:items {} :filter :all}}}))

In the app initialization, I dispatched the event synchronously to set the initial state, blocking the event loop. This call must run only once during app loading.

(rf/dispatch-sync [:initialize-db])

I access both the items and the filter with two subscriptions that simply extract the values.

(rf/reg-sub
 :todo/items
 (fn [db _]
   (get-in db [:todo :items])))

(rf/reg-sub
 :todo/filter
 (fn [db _]
   (get-in db [:todo :filter])))

An item is a map composed as {:id uuid :content text :active true}, while the filter is a keyword that accepts [:active :completed :all] as value.

When the user presses Enter on the todo input, the Reagent component adds a item to the collection using the following event handler. It accepts a non-empty string as a parameter.

(rf/reg-event-db
 :todo/add-item
 (fn [db [_ text]]
   (let [id (js/crypto.randomUUID)]
     (if (not (string/blank? text))
       (assoc-in db [:todo :items id] 
                 {:id id :content text :active true})
       db))))
       
;; Usage 
;; (rf/dispatch [:todo/add-item "write a re-frame tutorial"])

I defined other simple actions for todo items.

(rf/reg-event-db
 :todo/remove-item
 (fn [db [_ id]]
   (update-in db [:todo :items] dissoc id)))

(rf/reg-event-db
 :todo/toggle-item
 (fn [db [_ id]]
   (update-in db [:todo :items id :active] not)))

(rf/reg-event-db
  :todo/set-item-content
  (fn [db [_ id text]]
    (assoc-in db [:todo :items id :content] text)))

I defined a similar action for setting the filter content (without performing a value check).

(rf/reg-event-db
 :todo/set-filter
 (fn [db [_ filter-value]]
   (assoc-in db [:todo :filter] filter-value)))
   
;; Usage 
;; (rf/dispatch [:todo/set-filter :completed])

At this point, I'm able to add/remove/toggle items, update the content, and set a new filter. The next step is defining a new subscription that returns a filtered list of items. When the user clicks one of the filters in the UI, the list of items will be automatically filtered.

(rf/reg-sub
 :todo/visible-items
 :<- [:todo/items] ; syntactic sugar for the signal function
 :<- [:todo/filter] 
 (fn [[items todo-filter] _]
   (when (and (map? items) (keyword? todo-filter))
    (let [filter-fn (case todo-filter
                      :active    :active
                      :completed (complement :active)
                      :all       identity)]
      (filter filter-fn (vals items))))))

Another computed subscription is the count of active items left.

(rf/reg-sub
 :todo/active-items-count
 :<- [:todo/items]
 (fn [items _]
   (-> (filter :active (vals items))
       (count))))

What's left to complete the TodoMVC features are two actions: clearing the completed items and toggling all of them. We need two new event handlers to work on the list of items, either removing the ones that are completed or changing the state of all of them.

(rf/reg-event-db
 :todo/clear-completed
 (fn [db _]
   (let [items         (get-in db [:todo :items])
         ;; Extract active items ids and remove them from the items map
         cleaned-items (->> (vals items)
                            (filter (complement :active))
                            (map :id)
                            (reduce dissoc items))]
     (assoc-in db [:todo :items] cleaned-items))))

(rf/reg-event-db
  :todo/toggle-all
  (fn [db _]
    (let [items         (get-in db [:todo :items])
          ;; Is there any active item?
          active        (not-every? (complement :active) (vals items))
          ;; Set toggles as completed or not, updating the items object
          updated-items (reduce (fn [acc id]
                                  (assoc-in acc [id :active] (not active)))
                                items
                                (keys items))]
      (assoc-in db [:todo :items] updated-items))))

You can explore the entire source code in app.cljs after opening the sandbox.

Extra - Debugging re-frame

As React provide it's own Developer Tools with a Chrome extension, re-frame offers some integrated dashboards as libraries like re-frame-10x or re-frisk that are capable to provide a UI to explore the application state, show the events history and even navigate back in time reversing the app state to previous versions. Not bad!

[^helix]: An alternative library which supports the modern way to write React functional components is called Helix.