🤓 So you're using a weird language 🧠

Tuesday, September 13, 2022 :: Tagged under: engineering. ⏰ 10 minutes.

🎵 The song for this post is I, Don Quixote from the musical Man of La Mancha, composed by Mitch Leigh and Joe Darion. 🎵

Looking through Bozhidar Batsov notate his first impressions of OCaml and him previously asking its users about their workflows after finding its REPL/interactivity story more limited than Clojure, I realised I have some experience with the statement "I'm gonna write a program using a weird language," I thought I'd write a few narratives and strategies.

For context: programming languages was where I first went from computing being a thing you could do to something you could love. When I stretched my brain and rewrote a program from C++ into Scheme, I saw one class of bugs disappear and a different class of them manifest (to say nothing of performance changes, extensibility…). I also read Beating the Averages and thought I could find that Special Language that would make programming feel as natural as acting did (spoiler, it didn't, but it was about the journey, man).

Examples of this skill are me doing Advent of Code twice with a different language every day (2016, 2021), writing a web app in Erlang, a static site generator in OCaml (which powers this blog), a Scrabble solver in C, Erlang, and Ruby, a Markov Twitter bot server in Go, and frankly too many shell and toy repos that I didn't bother to push up or list here.

Anyway, if you want to try something new, here are some thoughts I've got after doing this for over a decade.

First — set clear intentions, be aware of limitations

When I gave suggestions on blogging software nearly a decade ago, I said:

tef is one of many programmers to make the observation that if a problem is 90% social and 10% technical, programmers will spend most of their time trying to solve the technical portion of it.

Similarly, everything I'm going to say doesn't change the fact that the core challenge of blogging is writing consistently. At the end of the day, none of what follows matters if you don't want to write something from time to time, actually go on to write it, and stick with it. If you don't or won't enjoy writing for what it is, none of the features of the products below will change that.

Many of my friends have aspired to be novelists or screenwriters and formed strong opinions on MS Word vs. Scrivener vs. CeltX vs. Final Draft vs. WriteRoom, but at the end of the day, they didn't actually… write much.

Before you embark on your Project In A Weird Language, ask yourself:

• How much do I need this to actually ship or finish?

• Am I sharing this codebase with others who aren't weird language perverts like me, and just want to build/ship a thing?

If the answers to those are "a lot" and "yes," I strongly encourage you to pick Java (or Python, or Ruby, or JavaScript…). It'll take a lot of emotional weight off the project.

I'm the last person on Earth to tell someone to be patient, but if you actually want to ship a company's production code in Gleam or Crystal, I highly suggest you put up 2-4 small projects first (the Elixir project I introduced at Ramp was my 3rd one, not including my 4 major Erlang projects. Also, at this point, Elixir less weird than, like, Scala or Clojure IMO). That'll give you some sense of what playing this game actually looks like.

Now, the strategies

Okay, you're good? Psychologically comfortable? Ready to play? Here are some thoughts.

Browse less, search more

This is a Hillel Wayne phrase, which he writes about here. Most common langs have everything on Google and StackOverflow, most weird langs don't. Common questions won't have answers for you in byte-sized, copyable chunks.

However: almost every language has at least one hermit crazy enough to write deep, extensive docs on it. Read docs sequentially. Take your time. Put on a pot of coffee and spend an hour before getting right to the hacking. It feels slower, but it's actually a more efficient use of your time.

Often this is in the tool itself: Factor, with a built-in Help browser. Or Pharo, the same. Vim's documentation is fabulous, and nobody reads it.

Sometimes it's a great book! Deliberate reading of chapters from Real World OCaml or Learn You Some Erlang will do a lot more for you than trying to search for something fast.

Tolerance for weird errors

Note if you're going into more weird languages, you'll run into types of errors you almost certainly won't hit in the popular ones.

You'll get opaque error messages, especially if the language has invariants that aren't common in other environments (Rust's ownership checker is probably the most common example of "no analogue in a more common language," but this can also mean Mercury's determinism checks, or Pony's "reference guarantees"). To be clear: these parts are exactly why learning a new language is fun! This is what it costs to reap the reward of Perlis langauges (a language that changes how you think, from the quote: "A language that doesn’t affect the way you think about programming is not worth knowing.")

Additionally: you'll see segfaults from their compilers. You'll get errors as stack traces in the interpreter's language (tef: "DSLs are when you write code in one language and debug in another"). Your common tool of Googling the issue won't work for you here, don't be afraid when you see them, have some more of that coffee, dig into the source.

Look for the forums, ask questions

A large plurality of programmers learned most of what they know in isolation, and so don't view programming as a very social activity (guilty). That said, you can get much farther, much faster, if you leverage communities. OCaml has a great Discourse instance and Discord server, Elixir's got ElixirForum.

IMO, community is one place where Weird Langs outperform Big Langs. While there's no shortage of resources and communities for Python or Java or JavaScript programmers, it hardly feels cohesive; when people talk about "the OCaml community" they really do mean something a lot more singular. Folks at ElixirConf come back energized because you feel like you're part of a single greater thing instead of a fish in a school of thousands.

Combined with browsing, you'll also learn some norms of the language and how its community makes decisions. An example of this is Elm: for many people, this is either their favorite or least favorite thing about the language.

More than "typing source" — build the workflow, a project

I go over this in this post (and IMO this is great to do even in common langs): while you can start with "open text editor, write hello world, run", if your project has any life besides an Advent of Code problem, it's really worth the hours (yes, hours) to set up a Makefile (or whatever that language's build tool) that does some of the following:

• Builds incrementally
• Run tests
• Triggers a deploy, if applicable
• Run typechecks (if using a language with a bolted-on typechecker, like dialyzer, mypy, sorbet…)
• Clean directory of build artifacts
• Opens or reloads an interactive shell with the definitions loaded
• Runs a formatter

Additionally:

• Pick someone's project/directory structure if the language doesn't do this for you already
• Practice adding/removing external dependencies until you can do it easily
• Practice cloning the project from scratch and being able to repro it with minimal hassle

And set up your IDE or text editor:

• Connect to a language server to find bugs while you type.
• Autocomplete
• Snippets if there's boilerplate in the language (e.g. gen_server modules, or a shortcut for if err != nil { return err } for Go).
• Practice using "Jump to Definition/Jump to Declaration"
• Practice "Find usages"
• Practice a safe rename/delete

Now, all of this may not be available for your Weird Language. Part of the agony and ecstasy of writing, idk, Raku is realizing how little of this is discovered or available. Still, most languages have at least one weird nerd who has a vim plugin that's worth trying. Else, if you fall in love, you can be that weird nerd!

Culture of "idk run it" vs. "It's just a monoid in the category of endofunctors, what's the problem?"…

This one's a little harder to articulate, but — note that a lot of language communities have very different cultures on what "a good workflow" is, or what "sufficient information" looks like, try to detect it, and go with the grain rather than against it.

Per the first, look at the thread I linked at the top here of a Clojureist trying OCaml. Like the old joke "you can program C in any language," if you insist on a Clojure-like REPL experience in OCaml, you're gonna have a bad time. The biggest shift for me when I moved from Java/C++ codebases to Python ones professionally was was how much harder I had to test my code, since it was so easy to ship code that "looks right" but barfs on a weird input. In Python, no assumption is too small to be invalidated by weird shit happening at runtime. In other languages, you can have some assurances that Up will be Up and Down will be Down. This used to bother me and I got frustrated, now I just roll with it. "That's how Python does it," accept it and move on.

For my tastes, Python's libraries and documentation do not make up for this. An example: look at the docs of the Python requests library and try to answer the question "where can I get the hostname of the URL of the response?" On one hand, request's docs make firing requests very easy: the frontpage has an example you can copy, and the Quickstart has a few more examples. But what does the Response object have? Well you get a bunch of named fields, but no insight into what the structure of those named fields are. What exactly does raw return when it says "file-like object", and what are its properties? next returns a PreparedRequest, but the doc doesn't link to its definitions. The url field, is that an object, or a string? Is it easy to get the hostname from it? Does Response have a constructor or a factory if we need to mock it, or make one manually? I don't see one.

In Python, these are good docs. In Java, you can Javadoc any codebase and get richer, more actionable information. But it's just how these communities roll; roll with it.

But at least it's easy to get started! Let's contrast this with "I want to use Unicode" in OCaml (idk, emoji support). If you've familiarized yourself with opam (this… is not easy) you can run opam search unicode and get this list of options. Which do you install, and how do you use them?

uucd              --          Unicode character database decoder for OCaml
uucp              --          Unicode character properties for OCaml
uunf              --          Unicode text normalization for OCaml
uuseg             --          Unicode text segmentation for OCaml
uutf              1.0.3       Non-blocking streaming Unicode codec for OCaml
uuuu              --          Mapper of ISO-8859-* to Unicode

Clear as day, right?! But this is how OCaml rolls. The author of many of those libraries wants you to know "it's simple, actually," and links this Reddit comment:

Decoding utf-8 encoded strings can be done with uutf. If you need to segment unicode text, you can use uuseg. If you need to normalize it, there is uunf. If you need to inspect unicode properties (or uppercase or lowercase unicode texts) there is uucp.

Now I dare you to open all those pages in a new tab and click the Documentation link in them. Do you feel ready to add Unicode to your project this week? While I'm sure this is a Very Smart And Correct way to break all this down and that if I brewed several pots of coffee and read many, many docs, I'd be on my way.

And I will. Because that's just how this game is played in OCaml. Part of the joy of this game if finding shit like this. Roll with it!

…but ignore the language's culture wars.

Pay attention to community, but when it slows you down, just do whatever you want, man. If this is your 3rd or 4th major project in that language, then yes, consider forming Hard Opinions on whatever their culture war is. But until then, don't let Fun Narrative distract you from writing the program.

Examples:

• Haskellers will tell you not to use default Strings (or the default Prelude), and/or any combination of their favorite language extensions. They're all quite compelling, but just use strings if you want.

• Scala had something of a holy war over scalaz vs. cats. Honestly just ignore Scala entirely if you don't like mess, but if you have to, pick cats and go on with your life.

• OCaml has a split on how to do asynchronicity: Lwt or Async. Pick one, who cares.

• Elixir has several HTTP libraries: HTTPoison, Tesla, Mint, Finch, Mojito, hackney. Pick one, you're on the BEAM, you'll be fine.

Get it in your fingers, suffer the little stuff

In the spirit of "do things that don't scale," don't be afraid to do extremely micro projects (echo server) or toy programs that are absolutely, truly useless. 99 Problems. Advent of Code, Leetcode, Project Euler… none of these are anything but amusing, but a good way to get your feet wet at the smallest level of granularity. Real Programs can come later.

Awesome lists, koans, howistart

Okay, that's all cute narrative. Here are some actually practical tips:

• Almost every language has an "Awesome [x]" repo that contains a ton of links for popular libraries for all sorts of things. They fall out of date, but they're often a great place to go for, like, a calendar library or image processing. Here's an Awesome Erlang, for example.

• Many language have "koan" or "kata" repos with exercises and Makefiles that teach the various constructs gently. It's a great way to exercise the various features of the language more interactively. Here's one I used for Go several years ago, I'm not sure if it still works.

• Rosetta Code is a cute resource: it's got listing for how to do common operations in all sorts of languages. Especially cool for things like Advent of Code when you're like "I just want to read a file." At the very least, you can see examples of the language you're using.

• While I think it's not really up-to-date anymore, howistart was a great project, has old examples from previous languages and ecosystems, and is a good way to think about how you want to think of how you start. I've got a little checklist for OCaml projects now.

💆 Love and Loving ☺️ →

← 🎂 2022 Birthday party 🥳

Thanks for the read! Disagreed? Violent agreement!? Feel free to drop me a line at [email protected], or leave a comment below! I'd love to hear from you 😄