LLVM is a collection of compiler toolchain that allows you to target any instruction set from any source-level programming language. Once the source code has been lowered to LLVM IR, the LLVM toolchain can easily handle the tasks of optimization and emitting assembly code for all the supported architecture.

I was always planning to migrate the samlang backend to LLVM since Apple announced that future Macs would be running on ARM chips and I want the ability to run compiled samlang code natively. Such a plan finally came true this winter when I was stuck in Ithaca having nothing else to do.

A lot has changed since my last blog post on my effort to make samlang run in browsers. The samlang demo site has been merged into the samlang documentation site as a demo tab. In addition, samlang can now emit optimized JavaScript code as its second target language. However, the most exciting changes come from a complete overhaul of the codebase: rewriting samlang in TypeScript.

Background#

samlang is my favorite and most sophisticated side project. It is a functional programming language with an optimizing compiler that targets the X86 instruction set and a language server that can provide type query and autocompletion.

The compiler and the language server was written in Kotlin and compiled to JVM bytecode. It's worth noting that Kotlin has multiplatform support and can compile any Kotlin code into JVM bytecode and JavaScript with a single codebase. Therefore, it's theoretically possible to create a samlang build that can run in browsers.

The reality is always harsher than the theory. It takes a significant effort of refactoring to make this happen. In this blog post, I will explain these efforts and some of the tricky design decisions I made along the way.

Almost a year ago, I started to perform developer lead responsibilities at Cornell DTI. My first major task was to grade part of developers at the end of the spring 2019 semester. A few days ago, I just finished grading all developers for their performance in the spring 2020 semester, wrapping up almost a year of work.

I came into the position thinking that developer lead has the easiest issues to deal with. I still believe this statement is true for me. However, I didn't realize that the easiest issues are still issues of a complex system full of Byzantine faults. Easy DevOps issues become exponentially harder to deal with when there is a people factor. Just like software engineering, sometimes it's all about compromises.

Therefore, I decided to write this blog post as both a reflection for myself and as documentation for future leads.

In the year of 2016, a school in Shanghai celebrated its 20th founding anniversary. Beyond this ceremony in December, its high school division students have made record-breaking college admission success: Engineering school admission in Ivy League had finally invalidated the 0 success rate record, and there was a student that made it into Columbia University after several years of hiatus.

However, compared to later years, it was quite an insignificant year, at least to the high school division. A year later, it would celebrate its 10th anniversary since it started the IBDP program. The college admission record in the next year also completely overshined the year of 2016. There were a few miniscale crises, but none of them had caused widespread dissent over a long period. Those small crises tend to be remembered less than a week. Yet, these events started to manifest themselves as symptoms of a larger problem, which might eventually lead to a spontaneous online protest that is beyond the imagination of school administrators.

Let's start with something small.

Implement autocomplete in 79 lines of code. Actually, it's not that easy.

Without the infrastructure discussed in this post, that code snippet mentioned here is useless.

I will walk through my journey to implement autocomplete in this blog post, using my programming language samlang as an example.

Following the lead of React and JavaScript god Dan Abramov, I decided to also publish my decade in review blog post.

I want to clarify that I intend to present the following content as plain facts. I will talk about the facts that certain events happened, and the facts that I thought and reacted to certain events in certain ways. You should treat them as a totally ordered set of boring logs rather than definitive guidance to something.

(To be friendlier to not-so-technical readers, I italicized all the technical jokes that are not essential to understand the story.)

In the last article The Road to Better Engineering, I promised that there will be a new post about my recent website re-architecturing effort. In the past week, I am working to gradually transform the website monorepo into a repository with latest technologies and reliable automation. At the time of writing this article, the transformation is complete and the repository has reached a state that I am mostly satisfied with.

The Start#

About three years ago, a student club welcomes the largest influx of new members in its entire existence. It is considered as a milestone: it’s a de facto recognition that it’s becoming prominent. By that time, its product covers over 40% of the student base and the club is the place for future software engineers to go. The former president of the club publicly celebrated this, and he was thinking about how the club can continue to move fast without any overhead of bureaucracy.

If you have read my blog post before, you know what had happened. Beneath the promising sign of future prosperity, there were huge risks: the main product already hit the upper bound of the user count; the engineering team was not well-trained by the former president; more importantly, the codebase was in a hell state.

That club is called Computerization and that dumb former president was me.

Background#

In the last summer, I developed my first programming language SAMPL. Measured against my technical skills at that time, it was a clear success. I was able to implement an interpreter and a compiler for a self-designed functional programming language with only the knowledge to implement an interpreter for a toy language in Cornell CS 3110. I was particularly proud of the module system and generics in that language.