Terminal on Melabit

Goodbye dc, welcome luka: a new RPN calculator for the Terminal

Sat, 09 Aug 2025 06:00:00 +0000

The Reverse Polish Notation (RPN) is a method for performing calculations without the need for parentheses. RPN was popularized in the ’70s and ’80s by Hewlett-Packard (HP), that used it in all its scientific and financial calculators.

When using calculators from rival Texas-Instruments, which all relied on parentheses, it was easy to lose track of how many parentheses had been opened or closed, often forcing users to re-enter the entire expression from scratch. Those who used an RPN calculator didn’t have these problems, although they had to overcome a small initial learning curve to get used to the new notation.

Today, physical calculators are rarely used, and almost everyone prefers to use an app on their phone or computer. However, there are still some die-hard nerds who refuse to give in to the graphical interface and insist on using the Terminal. Why? For example, because it’s much easier to enter numbers and complex operations with a keyboard than to press the glass keys of a virtual calculator.

– Image generated by Google Gemini.

A bit of history

Poland gave us Nicolaus Copernicus, Fryderyk Chopin, Joseph Conrad, Marie Curie, Arthur Rubinstein, and Stanislaw Lem. But it also gave us Jan Lukasiewicz, a mathematical logician (and philosopher) who, about a hundred years ago, invented a mathematical notation that did not use parentheses.

In this Polish notation, all operation symbols ( \( + \), \( - \), \( \times \), \( / \) ) precede the numbers they apply to. The same applies more generally to mathematical functions, such as \( \sqrt{} \), \( \sin \), \( \cos \), \( \exp \) (operators) and the numbers or variables (operands) they act on.

For example, \( 3 + 4 \) is written in Polish notation as \( + \ 3 \ 4 \), while \( (5 + 2) \times (5 - 2) \) becomes \( \times + 5 \ 2 - 5 \ 2 \).

For many years, this remained just an odd idea, because the benefit of not using parentheses didn’t seem to outweigh the unusual and more difficult-to-read notation.

Then, in the late ’50s, John McCarthy brought back Polish (or prefix) notation for LISP, one of the most influential programming languages of all time,¹ developed with the goal of being applied to the development of programs in the field of nascent artificial intelligence.

In fact, prefix notation not only greatly simplified the implementation of the LISP interpreter, but also made it possible to represent both code and data in the same form, an invaluable feature for a language designed to make computers intelligent. But better not to digress.

Reverse Polish Notation

But the real breakthrough came by inverting the order between operands and operators, that is, by writing the numbers first and then the operations to be performed on them, so \( 3 + 4 \) becomes \( 3 \ 4 \ + \) and \( (5 + 2) \times (5 - 2) \) becomes \( \ 5 \ 2 + 5 \ 2 - \times \).

This Reverse Polish Notation (RPN) was discovered and rediscovered at least three times in twenty years, but it only became popular in the early ’60s when Friedrich Bauer, the inventor of the concept of stack and one of the developers of the ALGOL computer language, and Edsger Dijkstra, famous for solving the “shortest path problem” and for a thousand other things, took up the concept again, because it reduced access to memory, which at the time was scarce and slow, and ensured that all operations were performed within a well-defined memory area (the stack), that was therefore easier to manipulate.

The advantages of RPN for performing mathematical calculations were so evident that HP used it in practically all its scientific and financial calculators, at least until the early ’90s. The development of larger memories and much bigger displays made it possible to easily view and modify the entire entered operation – not just the last number entered – thus reducing the necessity of using RPN.

A calculator in the Terminal

Those who wish to use a traditional calculator in the macOS or Linux Terminal have an almost mandatory choice: bc, the basic calculator, that has been a part of UNIX since 1975, a full 50 years. The current version, available on Linux and macOS, has been completely rewritten, but the original was just an interface for dc (desk calculator), one of the oldest utilities present in UNIX and even older than the C language.

And dc was… an RPN calculator. A choice that confirmed HP’s intuition: RPN notation was more efficient and easier to implement, and therefore also ideal for the limited-resource computers of the ’70s.²

Today, RPN is no longer a choice forced by hardware limitations, but rather a choice driven largely by convenience. Once you’ve spent half an hour learning to use it, you discover that it’s really much more convenient to perform calculations with this notation than with the traditional algebraic notation.

And then, maybe, there’s also a certain pleasure in going against the flow: in a world where everyone conforms to the dictates of (real or presumed) social media influencers, using an RPN calculator becomes a way to stand out, to feel different, almost a declaration of intellectual independence.

dc is still available on Linux and macOS and can be used in the Terminal, but it’s quite a hassle, its fifty years clearly show. The results of the operations are not visible unless you explicitly print them on the screen with p. The stack isn’t visible either, unless you explicitly request it with f. Negative numbers are indicated with an underscore _ and not with the usual - sign, so that \( - 4 \) must be written as \( _4 \). And so on.

But starting (almost) today, there’s dc2, or rather, luka.

The 21st-century RPN calculator

Since a few weeks we have a new RPN calculator for the macOS and Linux Terminal, initially called dc2, in homage to the venerable, now over-50-year-old calculator.

However, dc2 sounded too much like a rewrite of the original, while this is a completely new project, written from scratch in C. It therefore deserved its own name, luka, in honor of Jan Lukasiewicz, the inventor of the Polish notation (see the box above).

Compared to dc, luka is truly from another century, and it shows as soon as you start trying it out. It’s interactive, it shows the content of the stack at all times, it has a history of the operations, variables, a concise but complete inline help, a crystal-clear manual page (if only there were many more like this!)

And luka is also made in Italy. At a time when national identity is exalted for mostly trivial reasons, it’s nice to see something that really deserves to be valued.

The program currently has a small bug related to the display of the history, but the author crunches code much faster than I write words, so it’s very likely the bug will be fixed ASAP (vacations permitting).

Evolution of the code

The development of dc2/luka has been incredibly fast. Behind the project is Davide Mastromatteo, known among his pen pals as @mastro35 and author of the excellent blog The Python Corner.

In just a few days, Davide went from version 0.1.0, which was perfectly functional but had a still-raw user interface,

to version 0.2.0, with a much clearer view of the stack, the ability to use degrees and radians, and to change the number representation format, as well as a more compact help.

Version 0.3.0 introduced the history of operations and a further revised help,

while version 0.4.0, which coincided with the program’s name change, brought us variables and several new keyboard commands, as can be seen in the first two images of this post.

Using luka

Installing luka on a Mac or Linux is a breeze, at least for those who use homebrew (and those who don’t should start doing so immediately)

brew install mastro35/homebrew-mastro35/luka

Otherwise, just download the latest release of the source code, unzip it, and run

make clean && make

from the Terminal, obviously after navigating to the directory that contains the source code.³

Needless to say, anyone who has make and a C compiler installed on Windows can also compile luka on that operating system.

I almost forgot: soon there will be packages for Linux, in both deb and rpm formats, and who knows, maybe also aur. Perhaps even an installer for Windows.

There’s little to add about using the calculator itself. Those familiar with RPN will feel right at home and quickly use luka’ to its full potential. Those who don’t know RPN might be tempted to try it, if only to try firsthand how much more convenient it can be to perform calculations with an RPN calculator compared to a traditional algebraic one.

There are countless guides to RPN, but unfortunately, they are all oriented toward explaining its use with a physical calculator, such as the now legendary vintage HPs, or with graphical emulators for Android or iOS.⁴

Compared to these guides, there are some differences to consider. The main one is that, lacking physical keys, luka (but also dc) requires you to press ENTER each time to insert a number or function. Some function names are also different, as are the commands for managing the stack or for saving and retrieving variables. For example, luka uses store and load for variables, while physical or emulated calculators generally use keys named STO and RCL (but if the author reads this post, maybe he will change them 😂). However, apart from these tiny details, the underlying logic doesn’t change.

For my part, I tried in every way to make luka crash, and never succeeded. I tested it with factorials of absurdly large or small numbers, divided by zero, performed the infamous\( 0 / 0 \) and then asked to calculate the reciprocal of the result. But no matter what, luka always returned the correct result. In short, the quality is definitely there.

Conclusions

Trying luka costs nothing. It installs (and uninstalls) in a few seconds, works on macOS, Linux, and, for those who want, even on Windows. The results it produces are exact (and this is the most important thing). The developer is skilled and open to suggestions. In short, it’s an ideal tool for anyone who wants to perform calculations from the Terminal.

Sure, it’s a niche tool, aimed at a select group of sophisticated users who appreciate RPN notation and are not afraid of the Terminal. But that’s also what what gives it its unique charm.

And then, what about the beauty of seeing a program evolve before our very eyes, maybe even participating in its development with suggestions or criticisms?

And beyond that, there’s something special about watching a program evolve right before our eyes, especially when you can join the development with your own suggestions or feedback.

And one of the few languages, along with FORTRAN and COBOL, to still be alive and well. ↩︎
Not by chance, one of the most efficient programming languages ever is FORTH, which is based on a stack and uses RPN. ↩︎
What, you don’t even have make? Then hurry up and install homebrew! ↩︎
For iOS, I recommend without hesitation PCalc Lite or, even better, the full version Pcalc, which costsbout as much as a sandwich and a small bottle of water at a café. Alternatively, WP 34s, which manages to compact everything onto a single screen, or i41CX, perfect for those who once dreamed of having one. ↩︎

macOS Tahoe: where is my Terminal?

Tue, 08 Jul 2025 06:00:00 +0000

– Image generated by Google Gemini.

Take macOS Tahoe, updated to version 26.0 Developer Beta 2, and open the Terminal. Actually, don’t just open one Terminal; open two, three, four different Terminals, each in its own tab. More or less like this:

Now tell me: which is the active Terminal?

In order to answer you need to look closely. Only then you will notice that the title bar of the active Terminal has a slightly darker background and that the title itself is in bold.

Do the same with Sequoia, or any other previous version of macOS, and the Terminal in use will be apparent at first glance.

Actually, there is also a way to tell which Terminal is active in Tahoe, but it is counterintuitive and requires the use of the mouse. If you hover the mouse over the active tab, nothing changes visually,

while, when you move the mouse over an inactive tab, its background gets darker.

To many, it may seem like a minor detail, but the Terminal is an essential tool for interacting with the operating system at a low level. Those who use it can’t afford to waste time figuring out which panel is the right one, nor can they risk running a dangerous command in the wrong Terminal.

To give a practical example: for managing this blog, I use three different Terminal panels, each of which is dedicated to a specific task. In one panel, I work via ssh on a test site, which I use to check that everything works properly before uploading the blog to the live server. Since this is only a test environment, I’m accustomed to wiping everything out with the command rm -r *. I can do that without worry because I can tell at a glance that I’m in the right Terminal, without even reading. However, with Tahoe, I’ll have to change my habits because running that same command in the wrong Terminal could have catastrophic consequences.

Among all the inconsistencies in macOS Tahoe, this is perhaps the most baffling. And potentially the most dangerous.

At this point, one can’t help but wonder: do Apple’s developers actually use the products they create?

Apple, we have other problems: a look at macOS vintage bugs

Thu, 22 Feb 2024 06:00:00 +0000

– Image generated by Microsoft Designer AI.

In the last post, I described some very recent bugs present in Sonoma, the latest version of macOS.

The bugs reported here, however, have persisted across several versions of macOS, and it seems that Apple has no intention of fixing them or doesn’t even consider them to be bugs. These issues, unlike other reports, don’t occur under extreme conditions or after opening a zillion files but during completely normal use, which makes it even stranger that they’ve never been resolved.

The first two are more user interface inconsistencies, which are surprising given the almost obsessive attention Apple dedicates to the design details of its products.

The scrollbar for the list of purchased apps in the App Store is partially hidden by the window title and only appears after scrolling through a certain number of apps (the exact number depends on the total apps in the list—if there are many, you’ll have to scroll quite a bit to see the scrollbar).
The same thing happens on the App Store home page when you move the mouse to the top of the window, causing the title to appear. However, since this page contains fewer elements, part of the scrollbar remains visible.

This one, however, is an old bug related to Terminal.

I’ve configured System Settings > Desktop & Dock so that the Prefer tabs when opening documents option is always active. This way, every time I open a new window in applications that support this feature (including Terminal), macOS creates a new tab instead of a new window.

But if I’m using Terminal with a custom configuration (e.g., mine is set to 120 columns x 40 rows) and I select the menu option New Window with a profile of a different size (e.g., the default of 80 columns x 24 rows), a new tab is indeed created, but the entire Terminal changes size to match the profile just chosen.

This might even be a deliberate design choice. However, it contrasts with what happens when the Prefer tabs when opening documents option is only active in full-screen mode, where the new tab adopts the size of the existing one.

To be fair, it was worse in High Sierra: every time a new tab was opened, Terminal would lose a row. Fortunately, this bug was fixed in the next version of macOS.

For me, who always uses the Align to Grid option in Finder windows, organizes file icons visually in a logical order (at least for me), and often leaves empty spaces, this next bug is a major nuisance.

Until El Capitan, if I moved icons in a folder below the bottom edge of the window, Finder kept their order intact, leaving a blank space where the icons were originally located. Starting with Sierra, however, the bottom edge of the Finder window became a sort of impenetrable barrier, causing icons dragged below it to “bounce” back to the top of the window, leaving the bottom empty.

To avoid this, you have to drag the icons while holding the CMD (⌘) key, which in theory bypasses the grid alignment, but then you’ll need to manually restore their order afterward.

This final gem, undoubtedly my favorite macOS bug, isn’t just an annoyance, it’s a royal pain in the neck.

Just like with documents, I organize applications visually, grouping them by type and usage frequency, aligning the icons to Finder’s virtual grid.

As a result, I place all pre-installed Apple apps (Pages, Numbers, Keynote, Xcode, iMovie, GarageBand, etc.) at the top of the Applications folder, followed by office tools (Office 365, LibreOffice, PDF managers), communication apps (Teams, Webex, Skype), browsers, and remote access apps. Further down are apps specific to my work—note-taking, code editing, image editing—and at the bottom, utilities for monitoring Mac temperature, managing the clipboard, unzipping files, recording the screen, and occasionally running an antivirus scan (MalwareBytes).¹

This organization allows me to quickly locate the app I need, as I know exactly where it should be even if I don’t remember its name.²

Unfortunately, for several macOS versions now, every time I update the OS, app icons are always reordered alphabetically. Since alphabetical order is the default for the Applications folder, most users don’t notice this. But for those like me, who prefer custom order, it means having to reorganize everything after every update.

Why do I consider this a bug and not a feature? The reason is simple: Finder allows different sorting options for any folder—alphabetically, by date, by size, by type—and also lets you align items to a grid or leave them unordered. So why should the Applications folder behave differently?

Are there technical reasons for this decision? Under normal use, the Applications folder can be customized like any other Finder folder, so why should Finder reset customizations after every OS update, even minor ones?

In my humble opinion, this issue, along with the one mentioned above, is tied to a problem with the pesky .DS_Store files that manage each Finder folder’s configuration. The file format is more secretive than Area 51.

If anyone from Apple’s development team is reading this, could you spare an hour to fix these bugs? It shouldn’t be too difficult—please take a look, a loyal user would be grateful.

The ability to organize apps and documents visually is one of macOS’s features that makes me prefer it over Linux or—horror!—Windows, where this workflow simply doesn’t exist. ↩︎
On the Mac I’m using to write this, I have 148 installed apps, which, for my habits, isn’t even that many. Remembering all their names isn’t for me, so I’ve never used alphabetical sorting or apps like Alfred and the like. ↩︎