Roman and Editors

It's the story about how code editors I used influenced me. I feel it is important to share it and illustrate how important the journeys we have when using tools are. By the way, the story cannot be told without warm references to EMACS.

My First Keyboard

My first coding experience was not on a computer. It was some "famiclone" in the form of a keyboard, like this:

Mine was simpler, had more conventional controllers and no gun. But look! It had a keyboard and 2 types of BASIC programming language on a cartridge (G-Basic and F-Basic)! My first code editor was running on this strange thing.

Being 6-7 years old, I was doing some BASIC programming for fun, not even realizing how significantly it would influence my life. No persistent memory was provided, so any typed program was lost upon rebooting or switching the power off. I have no idea how many small programs I wrote were sacrificed in favor of criminal dramas my parents liked to watch on TV. Here is a picture to give you some vibes of my programs' archenemy from childhood:

I cannot remember how the editor looked like. But its appearance in my life made me an engineer.

How Turbo was your Pascal?

When I became slightly older, I got my first real computer. It was a Compaq with an Intel 386-family CPU assembled in 1989 - 1 year before my birthday. (Probably it still works; it worked when I checked 5 years ago!)

25 megahertz of power! Several megabytes of RAM and several dozen megabytes of HDD. MS DOS, Windows 3.1. On that machine I mostly used Turbo Pascal. It looked like this:

There was more advanced version of this editor and compiler: Borland Pascal. But my PC wasn't powerful enough to run it.

Some of Pascal's limitations were meaningless to me. So I found C++ courses, passed them and switched to Turbo C!

When my PC became more powerful, I switched to Borland C++ (same thing, but more advanced and resource-hungry).

This blue-yellow interface look will always have a special place in my heart. It has a visual identity and was pretty simple and straightforward to use. It was rewarding to explore almost every corner of this software, and the number of features was far from overwhelming.

I have no idea how I'd relate to those IDEs as a grown-up at that time. But for very young me those editors were inspiring. Famiclone ignited engineering passion in me; those blue-yellow IDEs made that fire stronger and brighter. Made it definitive.

Visual Studio led me to Linux

The next period was after elementary school and before high school.

I had to use Microsoft Visual Studio, because C++ was my main language. I remember that it was feature-bloated bullshit. It felt unlike a helper: you had to prove yourself worthy by going through a convoluted project setup process and not giving up. I remember I experimented with the Ogre 3D engine, and it was harder to set up that IDE than to understand the basics of the 3D engine!

It's no surprise that when I learned about the existence of Linux - I joined the cult. I learned slogans "Windows sucks!" and "Microsoft must die!" and embraced Linux a couple of years before high school. The decision was only natural after using Visual Studio.

I can easily imagine how someone decided to NOT become a software engineer after having a similar Visual Studio experience.

Anyway, I cannot call something that led me to Linux "just a tool". Yes, it was not only that editor's influence, but Visual Studio's influence was significant.

What I used in my early Linux years, I cannot clearly remember. Some standard editors for Gnome and KDE of that time. Kate, GEdit maybe. Nano when doing things in terminal.

I cannot say that some editor was special, otherwise I'd have related memories. The experience of a particular editor was insignificant against the background of the first Linux experience. I liked what I saw much more than things in the "Windows world". Not just particular editor - Linux changed me.

After something Debian-like, I used Slackware and Gentoo. I liked watching how the whole small world inside my PC would recompile for several hours. (In Gentoo at that time, it was the core idea - to compile and easily adjust software locally). I spent hours experimenting with compilation flags of the Linux kernel, breaking the system completely again and again.

And all of these activities were performed with very limited (or no) Internet access. People did things without constantly using search engines: they read manuals, used what they had at hand, and called a friend for advice. In such circumstances, shitty software was more devastating than nowadays (unlike in the past, today you can instantly search for solutions to common problems or delegate a fix to an LLM). And good software was more rewarding (because it was more significant that you could do a job without constantly asking a search engine or LLM for assistance).

From Vim to Atom

My first proper exposure to Vim was in high school. It was an editor many of us used during software engineering classes; we connected to a server over SSH and edited C source files there. No fancy Vim plugins or setups; it was a simple time: having syntax highlighting was cool enough.

For those who wanted more, Vimscript was the way. I disliked Vimscript, found it ugly and weird. I still dislike it, but less. No serious criticism here, just personal taste.

I took fairly standard paths afterward.

I tried JetBrains software. Too Java, too heavy. It often felt like a Range Rover on a bike lane.

I remember Sublime Editor's popularity spike. Sublime was nice, but not as good as my next pick: Atom. I really liked Atom and spent a lot of time with it.

I think Atom was my first step toward the Personal Development Environment approach: instead of learning the ways of existing IDEs, you build your own IDE-like environment adjusted to your needs and, most probably, unusable for anyone except you. Atom's influence was a continuation of the transformation triggered by Linux: I saw (and still see) my Linux and coding environment as a way to express myself and feel at "home" in an environment I built myself from building blocks provided by the open-source community. With Windows/MacOS and common IDEs, it was like a home built by someone else that I merely bought or rented.

Or, in a more poetical way:

How should a warrior see thy sword? As a disposable tool or as a continuation of thyself?

Atom spirit is still alive!

By the way, did you know that the Atom editor gave birth to Electron? Electron was even called Atom Shell at the beginning. Ironically, VSCode was built by Microsoft on the same foundation as Atom. Over time, VSCode gained more popularity. I cannot remember whether it was Microsoft's marketing power or whether VSCode was really better than Atom back then.

I also used VSCode a lot over the years, but it didn't click with me after all. It worked, but was clunky in an unsatisfying way.

Then Microsoft bought GitHub. I was sad about GitHub being bought by Microsoft. It led to the official sunset of Atom and its very promising successor - X-Ray. X-Ray was designed to solve problems I had with Atom and VSCode. I was excited to read their articles about a better editor architecture and how they planned to overcome performance and extensibility problems. But Microsoft silently cancelled it and forced people to use VSCode.

By the way, X-Ray was recently reborn as Zed Editor. For the things it can already do, it feels superior to VSCode. At least from the perspective of an occasional user and based on what my colleagues tell me about it. VSCode today feels more like a marketing tool for Microsoft's current business needs rather than an editor "by engineers, for engineers". Zed feels just right. Maybe too much AI, but it's too early to say if it's a bad sign or just a pragmatic consideration of the audience.

Love Letter to EMACS

After Atom and some time with VSCode, my EMACS era began. I like the joke that EMACS stands for "Editor for Middle-Aged Computer Scientists", a really good explanation of EMACS' "vibe". This joke was part of my personal identity as an engineer. EMACS was also clunky, but (unlike VSCode) in a satisfying way. I learned a lot from it. A lot. No. A LOT! Much more than I anticipated from a configurable editor.

Have you expected your editor to have an integrated psychotherapist? Not as a plugin, as a part of the standard distribution. Pretty hilarious, by the way. (And it was implemented decades ago).

I think that it is what we often lose by following "productivity cults". Really good engineering tools and projects are not just about solving problems, but also about a unique journey, sharing unique knowledge, unique experience, unique perception perspective: having an adventure that prepares you for more challenging and exciting adventures. It's true both for those who develop software and those who use it.

Being old and reflecting on your life, I doubt you will remember how you delivered one more important feature for one more important customer. Or how you installed and configured one more plugin for one more code editor. Unless something personal and subjectively important is involved. Something that is necessary to create a meaningful memory and fill that eternal emptiness we are all fighting with. Many of us spend more than half of our lives "doing work on a job"; therefore, it must not be empty and meaningless. I believe that being a grown-up was never about doing what someone told you to do; that's what children are expected to do. It was always about the responsibility of building your life in a meaningful way.

Why should anyone pick meaningless adventures then?

EMACS was my meaningful adventure for more than 5 years. Sometimes I tried to return back to VSCode or to something else that "just works". Because EMACS is fun and rewarding, but maintaining it is also a burden. But it was too late for me. I was already irreversibly hooked on the Personal Development Environment idea.

EMACS gives you unparalleled opportunities of self-expression. Just check how many things people built as plugins. Check how different those things are! They range from a simple editing helper to a mail client.

EMACS Lisp taught me some Lisp. I understood Lisp macros and why people love them. I understood why people love Lisp. I was captivated by the language structure and how universal s-expressions are. I saw how far a configurable editor can go and why some call EMACS an OS, not just an editor. I have a lot of memories of how I shared this knowledge and emotions with others, how I was (and am) constantly excited by the beauty of ideas I found there. EMACS helped me create precious memories through contributing to meaningful connections and discussions with other people.

Also, EMACS is more influential than a stranger may think. It's not very common knowledge, but did you know that Ruby was significantly inspired by EMACS Lisp? Read those slides keeping in mind that we're talking about an editor. Fascinating!

Elixir, my favorite language, has much more in common with Lisp than with Ruby. I'd even say that Elixir has almost nothing from Ruby, with the exception of things that are already common to both Ruby and Lisp. And some cosmetic syntax choices: e.g., do ... end blocks instead of { ... }. Moreover, like Erlang (the foundation of Elixir), EMACS is very old software that is still relevant. Both of them are over 30 years old!

Think about it. How powerful must the ideas be, and how much effort from talented people must be involved, for the software to still be relevant. Not like COBOL (god save anyone who has to work with it), but like it's actually better than many modern alternatives. What magic allows this software to evolve without falling apart?

That makes using EMACS interesting. Its documentation contains a lot of historical context. Its architecture is not perfect, but it survived for so many decades.

Using EMACS sometimes feels like observing a collectively made cross-generational piece of art.

The same can be said about Erlang. And, with some excuses, the same can be said about Elixir.

From EMACS to NeoVim

I started with EMACS distributions. Not the vanilla one or a custom config. Spacemacs was my first.

Then I tried to make a custom config, then switched to DOOM Emacs (highly, highly recommended!).

Then I switched to a custom config again. I tried to make my own "configuration framework" and used ones made by other developers. The time I spent with EMACS distributions and IDEs like JetBrains taught me what is possible to achieve, and then, in custom EMACS configs, I replicated the things I really needed and adjusted them to my taste.

You may notice that both distributions are Vim-friendly: both of them can be used with Vim keybindings. There is even a joke: "EMACS is a good OS, but a bad editor". I was (and am) in total agreement. To deal with it, the community "reimplemented" Vim for EMACS and called it Evil. I never used EMACS with its vanilla keybindings. I used each distribution in Vim mode. I started each custom configuration with Evil.

Many times I thought:

Why not just use Vim directly then? It also has a lot of plugins. It also has history.

Each time I was repelled by Vimscript. It felt so inferior and ugly in comparison to EMACS Lisp. Each time I jumped back to EMACS.

My custom EMACS configurations were far from perfection. Some trivial things weren't automated enough for years. I believe that for every second I gained from the conveniences of a custom setup, I lost due to imperfections in the same setup. No regrets. The point is the journey and what I feel every time I start my editor. Convenient and tasteless tools cannot bring you that joy of living.

With all that love and appreciation, with all the cool things I learned from EMACS Lisp, I still cannot say that I am really good at writing and reading Lisp. I know how insanely efficient Lisp editing can be. But an EMACS config was not sufficient to create enough desire to learn these ways. Only to try them a bit and be impressed.

I tried to learn and use Clojure; I've read a lot of docs and was fascinated by the language design. Learning some Clojure improved my instinct for eloquence. Unfortunately, Clojure is "too JVM" so I cannot force myself to start actively using it. When JVM parts began, Clojure's eloquence was usually impaired. And I made all those explorations because my editor was built on top of a Lisp interpreter.

Then NeoVim emerged. Over time, it achieved impressive Lua adoption. Then Lua became the main configuration language for NeoVim users and plugin authors. Then I found Neogit - a plugin repeating the awesome EMACS' Magit that was one of my main "vendor locks" as an EMACS user. And I decided to give NeoVim a try.

Vi is More Than an Editor

I started my NeoVim adoption with a custom config, skipping distributions like LazyVim on screenshot below:

One of the main reasons for switching to NeoVim was responsiveness. Unlike Vim, EMACS is not "blazing fast". Even with ~40 plugins, NeoVim is significantly more responsive and loads much faster than EMACS without any custom config and plugins.

It's nearly impossible to beat EMACS in terms of impact on a user. But Vim is pretty close. EMACS is "centralized" - one editor, big ecosystem, etc. Vim is a different phenomenon; it's more "decentralized". Almost any popular editor has Vim-mode. A lot of engineering-related web apps have a toggle to enable Vim-like editing (e.g., Obsidian). NeoVim appeared as a faster-moving, more modern fork of Vim. You can even use NeoVim in VSCode. Helix appeared as an attempt to rebuild Vim from scratch and modernize it even more. Evil turns EMACS into Vim; Vim keybindings are available for many EMACS plugins. Zed is proud of their Vim/Helix mode implementation.

Do you see the pattern?

Vi is more than an editor. It's a very successful idea of keyboard-driven modal editing.

As shown, this idea replicates itself in many forms. From this perspective, I haven't changed "the editor I use"; I only switched my favorite editor idea implementation. I was curious to try Lua for something serious, to feel what it's like to write in Lua. Now, I will definitely use Lua as an embedded language in one of my pet projects.

Each time I type text in Vim mode, I feel... a bit of supremacy. Mwahaha! Yep, it's slightly narcissistic. But let me keep my small daily guilty pleasures! It helps me to go through the day.

Will I stay with NeoVim forever? No. I definitely will try new things over the years. Maybe I will spend some time using Zed. Maybe I will switch to Helix. Or return to EMACS. The goal stays the same: to have a journey that makes my engineering life more fulfilling, satisfying and interesting.

Nothing is "just a tool"

I told this story with an intention. To share that tools have a huge influence on us. We do not just use tools; any tool we use affects how we see, think, and feel about the world and our goals.

I have an Nespresso coffee machine. Like this one:

It's convenient. I press a button - I get coffee. When my previous Nespresso machine broke, I mostly felt inconvenience and a bit of sadness. When I drink coffee - it's just "not a bad coffee". Enjoyable, elevates mood.

Then, look at this thing I obtained recently: a Kamira coffee maker.

Zero electronic parts, no indicators. Not expensive (under 100 EUR). Custom engraving is possible. It can explode and kill you if you use it in terribly wrong ways (e.g., by breaking all safety rules). It works with any common heating source. It took me a dozen attempts over several days before I learned how to get a proper creamy lungo out of it.

Each time, the result is slightly different. Each time I brew, I may notice some small detail, some way of improving the next brew. The process requires concentration and proper heat control; it's a meditation, a way to unwind your brain before returning to your current deeds. Sometimes I fail, discard the coffee-looking mess I made, and start from scratch. The device's design is more than 20 years old and I believe it will still be functional for decades (if not centuries).

When I drink a lungo or an espresso made with this machine - it's a much more fulfilling experience. When I make lungo in such a way for my partner - it makes her feel warmer emotions than if I pressed a button on a Nespresso machine for her.

Pressing a button on a Nespresso machine is skipping almost all the journey and going straight to the result. The tool that I use for making coffee influences how I enjoy the coffee. The right tool gives the ritual a deeper meaning. Coffee made with Kamira is more significant than "just coffee".

It doesn't mean that each tool you use should be like this. It may lead to cognitive overload, maybe. But I believe that things that are personally important are subjects for being more meaningful.

I know that I will have more significant and precious memories related to Kamira than to pressing a button on a Nespresso machine. The same goes for tools we use for engineering: editors, CLI helpers, LLMs, programming languages, etc. All of them not only solve problems for us, but also change us significantly. I believe the following are important questions:

How have the tools you use or used in the past changed you? Aren't they "make me coffee buttons" that fast-forward your life and skip all the meaningful journeys? Will they create memories that stay, memories that matter?

I will remember this lungo cup. I had no better photo of it, but it's the first proper creamy lungo I made with Kamira. I made it on the day I finished this article. It makes me willing to remember it, not fast-forward to the next cup of coffee.