Crowdin is a localization software for developers and teams creating multilingual products. Integrate Crowdin with your repo and other tools to automatically present new strings to translators. Receive translations as merge requests, so you can integrate them into your product. Release multilingual apps, games, websites, and help docs faster.
No spreadsheets, no text copy-pasting.
200+ integrations, including GitHub, GitLab, Android Studio, and API.
Order translations in Crowdin or invite your translation team.
Productivity and context features to ensure the quality of translations.
Start a free trial
🏗️ Projects
Recently open sourced by Stripe, Markdoc is a powerful, flexible, Markdown-based authoring framework and toolchain for creating custom documentation sites and experiences. Markdoc powers stripe.com/docs
language: TypeScript, stars: 2985, issues: 5, last commit: May 12, 2022
repo: github.com/markdoc/markdoc
site: markdoc.io
Twine is a tool for telling interactive, nonlinear stories. You don't need to write any code to create a simple story with Twine, but you can extend your stories with variables, conditional logic, images, CSS, and JavaScript when you're ready.
language: TypeScript, stars: 967, issues: 315, last commit: May 11, 2022
repo: github.com/klembot/twinejs
site: twinery.org
clayoven is a beautiful static site generator with a carefully curated set of features aimed at math-heavy sites. It has been built at a glacial pace, over a period of nine years and is small. 700 lines of well-written and well-documented Ruby!
language: Ruby, stars: 307, issues: 0, last commit: April 04, 2022
repo: github.com/artagnon/clayoven
demo: artagnon.com/scratch
Hey Ram! Thanks for joining us! Let’s start with your background. Where are you from, how did you learn to program, where have you worked in the past, and what languages or frameworks do you like?
Thank you for having me. I was born in India, and my early childhood was dominated by tinkering with electronics, chemicals, wood, and aluminum. I grew up as a voracious reader, and recall finishing off all the books in my local library by high school. Although a Windows 3.1 computer had arrived at my house in primary school, in ~1995, I didn’t have internet until late middle school. Prior to the internet, I had a short stint of gaming on Windows, and writing some poor programs in Visual Studio. Perhaps my first notable program was a DirectX 3D car-racing game, that I’d somehow written by stitching together fragments of code off tutorials on the internet. By the time I was in high school, I’d switched to Linux, and was learning C with GCC’s help.
As I was quite talented at Physics in high school, I decided to pursue a Masters in Physics at the Indian Institute of Technology, Kharagpur. Whilst there, I honed my skills as a programmer in the ample free time I had; perhaps the most notable piece of software I authored there was phoenixfs, a versioning filesystem modeled after git. Over the course of five years in Kharagpur, I ended up doing two Summer of Code projects with the git community.
I left India shortly after my first Masters, and decided to pursue a second Masters at Columbia University in the City of New York, in Computer Engineering this time. I didn’t take too much interest in the theoretical courses, and focused on the project-based courses: Operating Systems and Compilers. In the first, I wrote a round-robin scheduler for the Linux kernel, and in the second, rhine-ml, my very first compiler
I joined MathWorks to work on the MATLAB compiler after Columbia, and spent a good two and a half years there, writing compiler middle-end transforms. By my second year at MathWorks, I’d become quite good at C++. I did a couple of short stints in startups, including some exploratory work in Haskell and Coq.
I moved to Paris almost three years ago, where I currently reside. During my first year, I wrote Coq at Institut de Recherche en Informatique et Automation (Inria), and am currently finishing up my third Masters in pure mathematics.
I don’t have any strong opinions on programming languages, and realize that each of them come with a history, an audience and use case they target, and a set of trade-offs. For the last two and a half years, I have been collaborating with a friend on bonak, which is written in Coq. Coq is over thirty years old, and is a very strange language in many ways. Despite my rich experience with software, I’d probably classify myself as an amateur in Coq.
Perhaps it would be prudent to write a few words on Coq. I developed a childish fascination for it pretty early on after casually looking through Chilpala’s Certified Programming with Dependent Types, although I didn’t have any particular use cases in mind. I did have the opportunity to use it in industry to verify a distributed consensus protocol for a blockchain backend I’d built. My employer wasn’t thrilled about my choice to go with Coq, and eventually rewrote my proof in Idris after my departure, for ease of understanding. Since it was a distributed systems problem, I will admit that I investigated TLA+, albeit quite half-heartedly, as TLA+ didn’t seem like a real language. Although Coq can be used to verify the correctness of software, and CompCert is usually heralded as a landmark achievement, it can also be used to do research in type theory and logic (à la bonak). Although Lean is supposedly better at formalizing pure mathematics, I personally find it a little immature and lacking in expressivity.
Why did you decide to archive rhine-ml?
Yes, it’s a pleasant lisp frontend, packed with very nice features, uses LLVM as its backend, and had a few contributors at one point. However, the code was written in a terrible rush, in order to meet the deadline for the course submission, and it’s quite a mess as a result. I realized that this mess couldn’t be cleaned up without a complete rewrite, and therefore archived it.
What is the earliest memory you have of being excited by mathematics?
My childhood memories of studying mathematics are all pretty sour: I’d make a lot of mistakes in elementary computations, and have always struggled with math exams. Historically speaking, I’ve had a much better relationship with computers, where I had the freedom to make mistakes, get it checked by a compiler, iterate, and perfect my art.
In late 2016, I had the opportunity to work with the Integer Set Library, authored by Sven Verdooleage, whilst laying the foundation for polyhedral loop optimizations at MathWorks. By this point, I had become very good at writing software, and was looking for a bigger challenge; my development routine consisted of churning out C++ for four days a week, and getting it checked by clang on Friday, fixing the few silly mistakes I’d made. It suffices to say that I relished the purity and elegance of ISL, and had started casually browsing seminal works in mathematics.
Shortly after my encounter with ISL, one of my friends, who is a mathematician, pointed me to Jacob Lurie’s works. When I had a look at his work, I set my hair on fire and ran around the house like a lunatic. Over time, I formed a plan to leave the US, move to Europe, to study his work in leisure. Over my remaining years in the US, I carefully worked through all the prerequisites, starting from scratch.
Has mathematics helped you in becoming a better programmer?
This is a common question, albeit one that is not so easy to answer. My mathematical journey did indeed start off with learning category theory in the context of Haskell. Although it can barely be classified as math, I would point the audience to Bartosz Milewski’s Category Theory for Programmers, which evolved from a set of articles and video lectures into a book. However, the mathematics I study today is far removed from that; as I hinted earlier, I study the theory of ∞-categories, which was developed, in part, by Lurie. Indeed, even the first chapter of his first book, Higher Topos Theory, requires the reader to have the mathematical maturity of a senior graduate-level mathematician. I currently study his third book, Spectral Algebraic Geometry, along with the theory of algebraic operads, and my field can be loosely described as “derived deformation theory”. Friends, who are mathematicians in other fields, often joke about how vacuously abstract my field is. It would perhaps be prudent to note that I’m not a very good mathematician, and make a lot of mistakes to this day; however, I enjoy doing math with my advisor, and hope to establish a fruitful long-term collaboration with him.
All my mathematical work is pen-and-paper work, and in my opinion, software is far too primitive to even fathom any meaningful formalization. Perhaps one could imagine a connection between the work I do on bonak, and the correctness of software, but with pure mathematics that bears no relationship to machines, one is often left pondering this question.
Perhaps the most satisfying I can supply on the subject would be the following. Writing code is an art that requires high discipline, excellent commutation skills, and being good at abstraction. I can unambiguously say that studying mathematics has improved my mind by orders of magnitude. Reading good fiction on an everyday basis has improved my language and communication skills. Working on bonak has improved my understanding of dependent types, and my skills at writing elementary proofs using its tactic language. These activities are all free-standing and an integral part of my life: none of them are a means to an end.
What have you been listening to lately?
Contemporary jazz in general, but a lot of Keith Jarrett lately. My favorite albums are La Scala (1997), Sun Bear Concerts (1978), and Nude Ants (1980).
I studied jazz before switching to computer science. Do you play an instrument?
Very nice! Unfortunately, I do not play a musical instrument, although I did rent a saxophone at one point and practice for a short time, until my neighbors started complaining about the noise. Perhaps I’ll try again in a few years.
Why was clayoven started?
clayoven was born ~nine years ago, out of my annoyance with the inelegance and short lives of static site generators. My goal was to write something simple, that would be trivial to maintain in the long term, and most importantly, something personal: nearly all of clayoven’s features are unique and well thought-out. clayoven is easily the simplest piece of software I’ve authored: frankly, there hasn’t been one technical challenge.
All things said over the course of its nine-year lifetime, I’m elated with the way clayoven has turned out, and I see a bright future for it.
If you plan to continue developing clayoven, where do you see the project heading next?
I don’t have any aggressive development goals for clayoven. As clayoven is highly maintainable, and powers my personal webpage, I foresee it living over the course of my human lifetime. Web standards might evolve, Ruby might get some new features, new static site generators may be born while old ones die; clayoven, and my personal webpage will still be around, moving at a slow and sustainable pace.
My personal policy for adding features to clayoven is to first think about every new idea that comes to mind for a few weeks. Then, make a decisive change to clayoven, and continue updating my website. All features are heavily need-based; I ask myself the following questions:
What is the smallest incremental feature I can implement to add significant value to my website?
Does the feature go against the grain of the design of clayoven?
Is the feature possible to implement elegantly?
Where do you see open-source heading next?
All pieces of software have a finite lifetime; there will always be fresh programming languages, and new pieces of software, new communities, that users and developers will prefer over the old ones. Perhaps the tragedy of wide public exposure, but a lot of software written these days seems to target a wide audience. There is nothing inherently wrong with simple, well-written, niche software. To give you one example, here’s a lesser-known gem: QBE.
We’re currently in the age where the development of mammoth open source projects like LLVM, Linux, and Rust are primarily funded by corporations. It’s unfashionable for a corporation to be non-open-source-friendly these days. Meanwhile, much smaller projects are developed in the developers’ free time, and they’re not compensated for it, except maybe in the form of small donations. This perhaps explains why these projects try to target a large audience: the luster of writing code in one’s free time is to build some kind of portfolio to showcase, when looking for prospective employers.
I don’t think much of the economic or social balance of the nature of open source is going to drastically change in the future. Perhaps smaller corporations will find it within their budgets to fund indie developers of little open source projects that they use, but I hope this isn’t wishful thinking. sr.ht has taken off recently, and it charges a small fee to host git repositories: there are some really cute pieces of software hosted there, and I hope to see more.
I’ve never heard of sr.ht before. Where did you first hear of it?
Unfortunately, I don't have a good answer to this: I might have found a link to a sr.ht project on lobste.rs, or someone on IRC might have linked Lagrange, which is a browser for gemini; there are quite a few gemini-related projects on sr.ht.
Do you have any suggestions for someone trying to make their first contribution to an open-source project?
The first step is to find a piece of software you use on an everyday basis; a piece of software that you’re fond of. Every open-source community is different: find out if the community developing the software is to your taste, and gradually establish a long-term relationship with the people there. Always assume good intent, and be nice to everyone on the discussion forum.
I could tell you about the git community, with whom I had a four-year long relationship, starting 2010. git is a wonderful piece of software, and the community is a very old-school benevolent dictatorship. It’s mostly written in C89 with a strange indentation style, and they never break backward compatibility. Everyone interacts on a public plain-text mailing list, where all patches are sent and reviewed, and the review process is very stringent. One of my first patches to git was a documentation patch to git-blame, and I recall having to do sixteen (!) iterations of the patch before it was finally accepted. Perhaps some will judge this experience as being unpleasant; personally, I felt highly rewarded for my work, as many of the features I was either directly or indirectly responsible for are used by millions of people everyday. To tersely put what I learnt by working with the community, I’d say it was high discipline, perfectionism, and excellent communication.
Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!
Leave a comment
Interested in sponsoring the newsletter or know of any cool projects or interesting developers you want us to interview? Reach out at console.substack@gmail.com or mention us @ConsoleWeekly!
