Zachary W. Huang

Home Projects Blog Guides Resume

Tools That Make You Feel Empowered

May 14, 2024

Recently, I discovered Typst, which is essentially a LaTeX\LaTeX alternative that is intended to be easier to both learn and use. I had heard about it previously but never intended to try it.

I would consider myself reasonably well-versed with LaTeX, but to be honest, I always found it a bit finicky and hard to use. Sure, it provided really nice math formatting, but if I needed to write up a math solution, it was usually faster for me to simply handwrite it using my iPad. Meanwhile, if I needed to type up something like a lab report, I would usually reach for Google Docs because it was just easier to use. As a result, I found LaTeX to be in a sort of middle ground, and so I ended up avoiding it unless I really needed it.

So when I found Typst again, I realized that it might be the perfect tool for me. My academic term was starting, and I figured I might as well give it a shot.

Typst

What I found was that Typst was an absolute joy to use.

I made this on my second day of using Typst

I was genuinely shocked at how easy it was to learn the Typst language and start using it proficiently. In only three or four days, I had learned enough to produce documents that I thought looked good.

Personally, I found that the Typst markup language made total sense — it “just worked”. In my opinion, it’s like Markdown supercharged with a simple scripting language. The idea is simple: anything wrapped in [ ] is “content”, anything wrapped in $ $ is math, and anything prefixed with a # is code. If you want to define your own components, just define a function that takes a “body” and returns content.

Look how easy this is!

The syntax then helps you out in small but useful ways. You can pass a “body” into a function by just appending a content block to the end of the function, which naturally separates the parameters of a function from the content that it acts on. In addition, you can use set and show rules to easily modify parameters throughout the rest of the document.

The tooling is super simple: just run typst compile example.typ to compile a pdf file or typst watch example.typ to get live reloading (with extremely fast incremental compile times). No random .aux and .log files cluttering up your directory, no more incomprehensible error messages, and no more futzing around with make and entr to get “live-reloading at home”. The documentation is also fantastic: all of the standard library functions/components are well documented (though I would like some more guides/recipe-type tutorials).

But of course, Typst still has its faults. It’s extremely new, so the ecosystem is nowhere near as developed as LaTeX, though there are a few packages attempting to reach feature parity with LaTeX classics (like Cetz for Tikz and Unify for Siunitx). This also means that there isn’t as much support online, unlike the thousands of Stackoverflow posts explaining how to solve common issues with LaTeX. There are also some weird quirks, like requiring (deprecated, might I add) Sublime Text file formats to add custom syntaxes/themes.

However, I’m really not trying to compare Typst and LaTeX in terms of features. I would guess that anything that can be done in Typst can definitely be done in LaTeX, and vice versa. The point is that Typst felt so much better to use. After learning the language, I genuinely wanted to typeset all of my documents and make everything look good — I didn’t really feel this with LaTeX. I would really only use LaTeX if the ends justified the means, but with Typst, it was so ergonomic that all of the ends were justified. It was like the world of typesetting had been unlocked to me, and I could do anything I wanted.

Doing my chemistry homework in Typst. The code is here.

Empowering Tools

Ok, enough about Typst. What it really got me thinking about was tools that are “empowering” — tools that make you feel like the sky is the limit and are genuinely enjoyable to use. I brainstormed a little and came up with tools that I’ve found to be empowering.

Svelte

One of the first things I thought of was Svelte. I realized that my experience with Typst was actually quite similar to when I first started using Svelte. At a high level, Svelte “supercharges” HTML, JavaScript, and CSS in a similar way to Typst, and it integrates scripting/reactivity into webpages in a way that makes a lot of sense to me. I’m not the biggest fan of web development, but Svelte at least made a big enough impact on me that I chose to use it for this website (and I will likely choose it for any personal web app I make in the future).

Like Typst, Svelte has amazing documentation, builds quickly (thanks to Vite), and is just generally easy to learn and become proficient with (at least in my experience).

For example, here is how I generate the blogroll on my website.

<script>
  let blogroll = [
    // ...
  ]
</script>

<h1>Blogroll</h1>

<div class="flex flex-col mt-2">
{#each blogroll as post}
  <a class="flex-initial" href={post.href}>{post.title}</a>
{/each}
</div>

(Ok, this is not the greatest example, because you can do this in pretty much any HTML templating framework, but the point is that easy things can be done easily, and prior knowledge of HTML/CSS/JS allow you to learn Svelte very quickly)

Note: as I was writing this, I had to deal with some annoying errors with MDsveX (which is otherwise a great library), but I’ll chalk that up to web development being annoying in general rather than Svelte itself.

Vim/Neovim

There’s a lot to say about vim/neovim (which I will now refer to as *vim), and I want to write more about it in the future, but I’ll just put down some of my thoughts here.

Unlike the examples I mentioned above, *vim definitely is not easy to learn. I started using it probably around 4 years ago, and I still learn something new about it once every few weeks. However, it is probably the single most useful tool that I use for coding. It makes writing and editing code way faster and efficiently than if I weren’t using *vim. It might be hard to imagine if you haven’t learned *vim, but it genuinely makes every other text editor feel slow and clunky in comparison.

It’s just so much easier to press o or O to start a new line then to move your cursor, click past the end of a line, and press enter. It’s easier to to type ci" to change the contents of a string than to move your cursor, select the contents (being careful not to go past the quotes), and type something new. And it’s easier to type veS) to add parentheses around a word (using vim-surround) then to click in front of a word, type (, click to the end of the word, and then type ). These are just a few out of hundreds of examples I could give in which *vim makes it easier to do something than to use your mouse as you would in other text editors. The difference might sound small, but the overhead of editing goes down significantly, and all of these shortcuts make it possible to edit code at the speed of thought, not just at the rate you can switch from your keyboard to your mouse.

In addition, there are a number of useful plugins I use that add things like autocomplete, LSP, etc along with useful key bindings for quickly navigating files and performing common operations like adding/changing/deleting “surrounding” characters like parentheses, brackets, and quotes. I’m still learning new commands and updating my config as I grow and evolve as a programmer. Being able to define custom keybindings and macros means that I can customize *vim and truly make it “mine”, which is something you probably can’t do (or at least not to the same extent) with 99% percent of software tools out there.

Using a *vim macro to write a Python function that returns if an integer is even or not (please don't actually do this)

Common Lisp

I suppose this one is more subjective, but one of the reasons I find Common Lisp such an interesting programming language is because it feels empowering. I’ve written about Common Lisp before, but essentially, I feel that this language gives you the tools that you need to create anything, all on your own. Yes, Turing-completeness means that you can use any programming language to implement anything you could in another, but again, the difference is in feel — the abstractions that Common Lisp provides (mainly macros) allow you to define a language internal to your project and build up a system from scratch in the most efficient/effective way you can think of. In addition, the Common Lisp REPL allows you to debug programs in real time, modifying and re-compiling code while the program is still running, which is super cool in my opinion.

I’ll just leave you with some examples of interesting programs people have written in Common Lisp:

  • Coalton: a statically typed functional programming embedded in Common Lisp (think ML/Haskell)
  • Quilc: a compiler for Quil, a programming language used to develop quantum circuits and programs
  • Nyxt: a powerful, extensible, keyboard-driven web browser
  • Maxima: an open-source computer algebra system
  • Sketch: a graphical environment for making electronic art/visuals/games inspired by Processing
  • Trial: a game engine that has been used to make commercial indie games

In addition, as far as I can tell, all of these projects are maintained by a relatively small number of contributors. It’s my hypothesis that the empowering nature of Common Lisp is what allows for these (extremely nontrivial) projects to even exist, given the small teams behind them.

Conclusion

If it isn’t already clear, this is a very subjective blog post, with a lot of mentions of how things “feel”. To be honest, I don’t even have a clear definition of “empowering”, but I think that in more slightly more objective terms, these types of tools tend to satisfy at least a couple of the following:

  • makes difficult things easy, and makes easy things easier
  • is easy to learn but does not limit you to only simple tasks
  • is used for very practical purposes
  • has stellar documentation
  • is composable, e.g. provides its own sort of “language”

Have any examples of tools you find empowering? Agree or disagree with this blog post? Feel free to contact me!

RSS icon github logo linkedin logo

Zachary W. Huang © 2021-2024