Welcome to yet another episode of my daily HN scrolling session, scrambling for some "intellectually stimulating" posts.
Today i decided to pick the #33169030th post : "Lite: A lightweight text editor written in Lua". Why? I have been researching the very field of text editing software since early 2018. But for some reason I still can't make a single native, lightweight text editor, ever. Of course I'm really curious how other people tacked this problem. I kinda give up because handling low-level, hardware-facing, C/C++ code is real hard.
# "Lightweight"?
First things first, i want to verify their claim whether this app is truly a "lightweight" text editor or not. I downloaded it on their github pages.
A single .exe file, 2,49 MB. No installation needed. To open a folder / document, you just need to drag-and-drop it directly into the active window. It feels like Sublime Text so much, but it really has faster startup loading time than Sublime Text (albeit little bit slower against the original notepad.exe). Quite impressive.
# Lua
The last time I touched some Lua code is when I fixed some bugs on Wikipedia's templating system. For some reason too, Wikipedia uses Lua.
But, why they decided to use Lua? What's so special with Lua anyway?
Let's start with the history of Lua. It all started with a scripting language used to input some petroleum-related data into a simulator then output it into a specialized report.
The engineers at Petrobras needed to prepare input data files for numerical simulators several times a day. In early 1992, Petrobras asked Tecgraf to create at least a dozen graphical front-ends for this kind of data entry. Tecgraf designed DEL (“data-entry language”), a simple declarative language to describe each data-entry task. Tecgraf also started working on PGM, a configurable report generator for lithology profiles, also for Petrobras. The team decided that the best way to configure PGM was through a specialized description language called SOL.
PGM would soon require support for procedural programming to allow the creation of more sophisticated layouts, and SOL would have to be extended. At the same time, the users had requested more power from DEL. DEL also needed further descriptive facilities for programming its user interface.
Around mid-1993, Tecgraf concluded that the two languages could be replaced by a single more powerful language, which they decided to design and implement. Thus the Lua team was born.
-- Roberto Ierusalimschy, et al "The Evolution of Lua"
Remember that the main perks of scripting language is that you can describe the high-level goal quickly and easily without being bothered with small inconsequential pedantic details. Cue to my own words, several paragraphs ago :
" I kinda give up because handling low-level, hardware-facing, C/C++ code is real hard."
Maybe, this very problem could be solved by switching into Lua? Perhaps..
Writing a game in C or C++, you find yourself trying to work with the subtleties of the system rather than just implementing your ideas. Lua allows for "clean" dirty-style coding. Offer your C/C++-interfaces to lua and 'script' their usage via the Lua-scripting language. If you want to change the behaviour/logic of your application, you just have to change the code in the Lua-script without the need to recompile the whole application.
-- Stack Overflow "Example usage where Lua fits much better than C/C++?"
# Simple DirectMedia Layer
Okay. Lua. I get it. But I strongly believe that a mere "language" still can't solve the low-level interfacing problem alone. You still need a bunch of low level library that interacts with OS kernel to do that. Let's see the source code.
To be honest, I still don't know what is the usual project structure of Lua-based project. But somehow I see main.c files over there. Let's open it :
1#include <stdio.h>
2#include <stdlib.h>
3#include <SDL.h>
4#include "api/api.h"
5#include "rencache.h"
6#include "renderer.h"
It seems that the only 3rd party library that this project uses is SDL.h : Simple DirectMedia Layer.
Simple DirectMedia Layer : A development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D. SDL is written in C, works natively with C++, and there are bindings available for several other languages, including C# and Python.
Whoa. Multi-platform library that provides low-level access to most of hardware? Pretty cool. Why i never heard about it before.
Let's take a deep dive into its history.
Sam Lantinga created the library in 1998 while working for Loki Software. He got the idea while porting a Windows application to Macintosh. He then used SDL to port Doom to BeOS.
-- Wikipedia
What were the most significant changes to SDL as a result of using the library for the game ports?
We're adding multi-threading event handling to SDL, and added autoconf support, but for the most part it was unchanged. There are more plans for the future though, including adding joystick support and OpenGL support.
So essentially, SDL will become an all-purpose low-level gaming library.
Yep :-)
-- Linux.com (November 11, 1999) The Sam Lantinga Interview
In short, someone in the past want to participate in one of the earliest DOOM port meme in existence, so he created a library that provides low level access to audio, keyboard, mouse, joystick and graphics hardware in the process. Whoa, cool.
# Conclusion
So what's the "secret sauce" behind the lightweight-ness of this app? Probably the low level C + SDL library usage. Lua is added for even more quicker development time because we all know that doing it entirely on low-level C is quite a headache.