Emojicode's last commit is dated August 2023 and its newest release is a 2020 beta

The last commit is from August 2023 and the newest release is a beta

Two dates describe how much history you are looking at. The default branch is master and its last push is dated 2023-08-07. The newest published release is 1.0 beta 2, from 2020-02-22, behind 1.0 beta 1 from July 2019 and a release named 0.9 from March 2019. So the release line stopped at a beta more than three years before the last commit, which tells you the state of the tree and the state of the releases are different things. The tag naming is inconsistent as well: two of the three tags carry a version prefix while the 0.9 tag does not, and its release title is written as 0.9.0 rather than 0.9. Anything that resolves versions by parsing tags has to cope with that.

The build asks for LLVM 7 and Python 3.5

The prerequisites are given with a note that the versions are recommendations rather than requirements, which softens the numbers without making them current. A C compiler at version 6 or 7, CMake at 3.5.1 or newer with Ninja preferred, LLVM 7, and Python 3.5.2 or newer for running the tests. Every one of those is old enough to have gone out of mainstream support, and CMake 3.5 predates most of the current tooling. On a current machine none of this is fatal, since all four still install, but you are being asked to reproduce a toolchain from a period rather than adopt one. The test runner being Python rather than a shell script also means the build has two language runtimes in it, one compiling and one verifying.

The install target is called magicinstall

The build sequence is five commands and one of them has an unusual name. After cloning and configuring with CMake and Ninja, the build is a bare invocation of the build tool, the tests are a second invocation with a tests target, and then there are two ways to get the result onto your machine:

ninja magicinstall

or to produce a proper package of binaries and headers instead, a dist target, with a note that creating a distribution archive means calling the distribution script directly rather than through the build tool. The two-word target name is memorable in a mildly unfortunate way for a project whose documentation example runs as an ordinary user, and it is worth knowing before you grep a build script for install. What the targets confirm is that this is a real compiler project with a real packaging story: a compiler, headers, a test suite and an archive format, built by an open-source build system rather than a bespoke script.

The container build targets an Ubuntu release that has been gone for years

A Dockerfile is provided, and the readme says which distribution it is built for: Ubuntu 18.04. That release left standard support in 2023, so the container is pinned to a base image that receives no updates, on a project whose last commit is from the same year. The build path inside the repository is under a directory named for the compiler family, and the image is built with a tag and that explicit file path rather than a default. Verification is done by running the image and letting the test suite run inside it, and then a shell is started with a local directory mounted so you can write a first program and run it against the freshly built compiler. The workflow is well thought out for the era it was written in, which is exactly the problem: none of the pins still receive fixes.

A link in the readme points at documentation for version 0.6

Small signals of an unmaintained readme accumulate. The header carries two link definitions that nothing visible in the document refers to: one badge definition pointing at a hosted continuous integration service, and one reference link pointing at a markdown file whose name carries the version 0.6 and whose path suggests a page about improving the language's syntax. A project sitting at 1.0 beta 2 linking contributors to 0.6-era syntax documentation is either leaving a useful historical page in place or has stopped updating the pointer, and there is no way to tell which from the readme. The chat badge points at a service that has since moved its communities to a different protocol, and the only guidance for keeping informed is a link to a social media account.

Installing means going to a website, and the readme is 200 words

The getting started section is three lines. It says the project is an open-source, high-level, multi-paradigm language consisting of emojis, lists the language features it provides, and then sends you to the project website to learn more about the language and how to install it. That is the whole installation story in the repository: no package name, no registry, no binary download, no command. The features list is short and specific, namely object orientation, optionals, generics and closures, all of which are described as language features rather than libraries. The tree shows where the implementation lives and it is a compiler project rather than a library: a compiler directory, a runtime directory, a sockets directory, a JSON directory, a distribution script, a standalone install script and a Python test runner at the root.

The licence summary names the patent grant and the trademark ban

The license section does something few projects do, which is to summarise the licence in plain language and label the summary as having no legal force. Four points: you may download, use, copy, publish and distribute it; you may create modified versions but may distribute them only on certain conditions; the licence includes a grant of patent rights and does not allow you to use any trademark, service mark, trade name or logo; and it comes with absolutely no warranty. The third point is the one to notice, because a language project with a logo and a name has something to protect beyond the code, and the Artistic 2.0 terms draw that line explicitly. The licence itself is the Artistic License 2.0, which the repository metadata also records.

Editorial conclusion

Emojicode is interesting as a language design exercise and as a demonstration that a compiler and runtime can be built for a syntax that is nothing but pictographs, since the object orientation, optionals, generics and closures are all implemented rather than borrowed, and the build is a conventional CMake and Ninja project. Two things to weigh before you plan anything on it. The default branch's last commit is dated 2023-08-07 and the newest published release is 1.0 beta 2 from 2020-02-22, so what you get is a snapshot rather than a moving target, and the tag naming is inconsistent across releases. And the toolchain it documents is old: LLVM 7, a C compiler around version 7, CMake from 2016 and Python 3.5 for the tests. It is a project to read and experiment with, not one to depend on.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes