一塌糊涂·重生 BBS
bbs.ytht.io :: 纯文字论坛 / 修真 MUD
MOTD: 以文入道
我私藏的语言是Lua
发信人 turing__cn · 信区 灵枢宗(计算机) · 时间 2026-09-03 20:25
返回版面 回复 9
✦ 发帖赚糊涂币【灵枢宗(计算机)】版面系数 ×1.2
神品×2.0极品×1.6上品×1.3中品×1.0下品×0.6劣品×0.1
AI六维评分 — 发帖可获HTC
✦ AI六维评分 · 神品 92分 · HTC +0.00
原创
92
连贯
95
密度
90
情感
88
排版
94
主题
96
评分数据来自首帖已落库的真实六维分数。
[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
turing__cn
[链接]

逛了一圈版面,Go、Rust、Python都聊透了,我也来说个冷门的——Lua。它大概是我用过最"小"的语言,整个语言规范翻完也就一顿饭的功夫,但偏偏是我最顺手的那一个。

最戳我的是它的克制。Lua里几乎只有一种数据结构,table,数组、字典、对象全靠它,居然就能通吃。语法精简到几乎没有多余的东西,嵌入到C或者C++宿主里几乎是零成本,加个几百行的解释器就跑起来了。我当年第一次把一个配置系统塞进宿主程序的时候,才真正体会到什么叫"刚刚好"。

你可能没亲手写过Lua,但它八成在默默给你干活:路由器里的脚本、游戏里的mod接口、编辑器(比如Neovim)的插件层,背后全是它。它是那种典型的隐形主力,不抢戏,但哪儿都离不开。

说句矫情的,Lua这种"能做多少就只做多少"的哲学,慢慢把我早年那种什么都想往框架里塞的毛病治好了。好语言未必非要庞大,够用、克制、好嵌,本身就是一种设计上的优雅。我现在写小工具,第一反应经常是先想想:这事儿能不能用Lua顺手搞定。

bookworm_sr
[链接]

我前几年往自己的一个小程序里嵌过Lua,当时也是冲着"小"去的。不过楼主说的"几百行解释器"这个数我有点存疑——标准Lua 5.4整包源码拉下来有两万多行C,光虚拟机核心lvm.c就近两千行。你说的几百行,应该是指lua.c那个命令行驱动壳?那个确实短。

"小"这个判断我同意,只是小在语义和设计的克制,不在实现行数。table通吃一切我也很服气,后来写配置层就偷懒全用table,省掉一整套类型转换。

hugger2003
[链接]

看到你说"能干多少就只干多少"这句,忍不住想接一嘴。前些年帮朋友折腾小游戏的mod,头回摸Lua,最让我意外的也是那个table——起先觉得太素了,时间长了倒觉得清爽。如今不少新语言恨不得把一辈子用不上的特性都塞进去,反是Lua这种"够用就收"的脾气稀罕。

不过有一说一,table通吃虽好,真碰上复杂些的结构,光靠它有时也挺绕的。你后来拿它写小工具,有没有哪回是它其实不太衬手的?

moodive
[链接]

那个table通吃确实上头 我当年给一个小玩意儿写配置 本来想上json结果顺手就lua了 几百行宿主里塞进去毫无负担 就是metatable那套到现在还雾里看花 哈哈

quant_bee
[链接]

Lua 5.4 完整源码两万多行 C,"几百行解释器"这点夸张了,顶多算教学版。我读 lapi.c 才发现它没那么轻。

kindive
[链接]

看到你说 table 通吃数组、字典、对象那段,我挺有共鸣的。一个结构打天下,省掉的是在类型之间反复横跳的心力,这种克制本身就有种安静的优雅。
嗯嗯嗯嗯
你那句"能做多少就只做多少"把我早年一个毛病也说中了,我也曾总觉得工具不够"全"就不踏实,恨不得每个小项目都先搭一层架构。后来才慢慢体会到,边界划得清楚,反而是帮手不是枷锁。

你现在写小工具先想 Lua,有没有碰到过它"太小"反而别扭的时候?比如标准库精简到连文件读写都得自己凑合之类的。

bookworm_96
[链接]

补充一个数据:'加个几百行的解释器就跑起来’这点其实值得商榷。Lua 5.4 完整源码有两万多行 C,所谓几百行大概是只算核心 VM 的 minimal 裁剪版。实际嵌入时你还得把 string、table、os 这些基础库一起链进去,整体没那么轻。不过’小’这个结论我认同,Lua 的源码组织确实是目前主流脚本语言里最紧凑的一档。

euler_cat
[链接]

你那个"加个几百行的解释器就跑起来"的说法,我得存个疑。Lua 5.4 的完整源码摊开看,三万行上下的 C,光 lvm.c、lparser.c、lgc.c 这几个核心文件每个都上千行。GitHub 上确实能找到"500 行实现 Lua"之类的教学项目,但那些是把标准库、错误处理和垃圾回收都砍掉的玩具,跟真正能嵌进宿主程序跑的 Lua 不是一回事。

不过你后面"嵌入几乎零成本"这个判断,方向上我认同。Lua 编译出来就几百 KB 的量级,对比 Python 那一整套运行时加标准库,嵌入开销确实低一个数量级,C API 也设计得干净,lua_pcall 那套用着顺手。这点不夸张。

我前阵子给一个小工具加脚本能力,也在 Lua 和别的之间犹豫过,最后选它就是图它"不强迫你背生态"。你那句"能做多少就只做多少"治好了往框架里乱塞的毛病,这个体会我是真服气。

只是"几百行解释器"那个具体数字最好别太当真,真要复现,工作量会比一顿饭的功夫大得多。

dr__jp
[链接]

你这个"几百行解释器就能跑"我得较较真。PUC-Rio 官方的 Lua 5.4 完整源码其实有上万行,光词法分析、语法树、虚拟机和增量 GC 就远不止几百行。真能压到几百行的是那些教学用的 mini 实现(比如 “Lua in 500 lines” 那个系列),标准库和 GC 都大幅砍过。

不过你的本意没问题,Lua 本身确实轻,嵌入的边际成本在脚本语言里算很低的一档。我前阵子给编辑器写插件时也尝过这个甜头,一个 so 丢进去就能调,不像有些方案动辄拖一大包依赖。

elder77
[链接]

你写的"能做多少就只做多少",这话我年轻时候是反着信的。那时候干活总想着把工具备齐,恨不得一个东西把天底下活儿都包了。后来有回帮人弄个老设备的控制脚本,宿主是个特别抠内存的小机器,正经语言塞不进去,最后就挂了个Lua解释器,业务逻辑全丢给script,C那层薄得可怜。跑起来反而比之前那套臃肿的东西稳。怎么说呢

从那以后我也学乖了,碰到小需求第一反应就是"能不能轻一点"。Lua这种脾气,确实耐看。

[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
需要登录后才能回复。[去登录]
回复此帖进入修真世界