Hacker News Reader

Comment by SchwKatze | Hacker News Reader

Lua is the SQLite of program languages, absolutely blast

While I enjoy Lua, clean, elegant, and entirely too reasonable, Tcl is undoubtedly the SQLite of programming languages.

https://www.tcl-lang.org/community/tcl2017/assets/talk93/Pap...

It's because Tcl, like SQLite, operates on a peculiar metaphysical principle: everything is a string until proven otherwise, and even then, it's probably still a string.

Also, D. Richard Happ, who we owe thanks for SQLite, was and perhaps still sits on the TCL Board (I may be wrong about that, but Happ holds significance in the TCL community).

In my mind:

Tcl is the quietly supportive roommate who keeps making coffee and feeding LISP-like functionality until the world finally notices its genius.

Lua sits across the table, sipping espresso with a faintly amused expression, wondering how everyone got so emotionally entangled with their configuration files.

Didn't the string stuff get improved in the last few years to be a lot more performant?

I think TCL does an opaque thing, everything "is" a string, but if you don't use it as a string, it's actually stored in some optimized format. Then it converts back to a string on demand

I still prefer Lua personally. Their type system is easy for me to understand

TCL 9 brought some welcome string improvements, and things run faster overall. But in my case, it's hard to say how well that's actually played out, partly because I haven't done the work to find out. My TCL scripts and apps work well enough to allow me to be lazy about them.

Performance is up, but so is my inertia. So while TCL 9 could be transformative, for now it remains a white paper I've skimmed, not a revolution I've implemented.

Lua is one of the easiest configuration file formats I've had the pleasure of working with. Readable. Has comments. Variables. Conditionals.

Everyone (including me): "oh no, no, you don't want a full Turing complete language in your configuration file format"

Also Everyone: generating their configuration files with every bespoke templating language dreamed of by gods and men, with other Turing complete languages.

It's a security issue. Configs are user interfaces. Devs generating configs is irrelevant.

Indeed - it would depend greatly one's workflow and threat model.

You could solve this with a capabilities permissions system. That way the config files can be written in the same language but have configured permissions that are different from the rest of the programming language. So you could restrict the config files from resources like threads, evaling source, making network requests and whatnot. Come to think of it you could even probably section off parts of the language behind capabilties such that the config files could be configured to be a not-Turing complete subset of the language.

Lua started as a config language.

*Hipp

Lua is the glue when sh/bash doesn't suffice.

Lua is simple and elegant, and I much prefer it to Tcl.

Lua is in games and in LuaTeX, and when you have the choice of embedding a LISP, a FORTH or Lua in a larger application, it is often the most maintainable, runtime-efficient and low-memory footprint option of all.

If you embed Lua you also get Fennel (almost LISP) support for free.

> Lua is the glue when sh/bash doesn't suffice.

I enjoy Lua and use it professionally, but when bash (and AWK) don't suffice, the glue is Perl. Because it has pipes which you can use to connect the output of one command to the input of another, or to a file.

People don't normally embed FORTH in a larger application.

What would be the SQLite's equivalent to indexing starting from 1, not 0? Off the top of my head I can't think of anything that would go so much against the grain.

For me it's case insensitive LIKE.

column types are more like guidelines than rules

DuckDB is the mother of them all. It is waaaay more capable than SQLite, and embeds SQLite for those who need 100% compatibility for some workloads.

nice LoL

Reply on news.ycombinator.com