V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
adspe
V2EX  ›  程序员

你们怎么看待Lua这门语言。

  •  
  •   adspe ·
    alivelee · 2013-01-08 22:00:06 +08:00 · 8790 次点击
    这是一个创建于 4374 天前的主题,其中的信息可能已经有所发展或是发生改变。
    前景如何。难度如何。
    38 条回复    1970-01-01 08:00:00 +08:00
    luin
        1
    luin  
       2013-01-08 22:16:13 +08:00
    太好学了以至于学的时候没考虑前景如何。
    Kymair
        2
    Kymair  
       2013-01-08 22:20:06 +08:00
    据说是非常出色的嵌入语言。云风当时选它作为大话西游之类的嵌入语言的时候魔兽世界还没出来呢,也可谓英雄所见略同了 XD
    可以看看云风 Lua相关的文章 http://blog.codingnow.com/eo/luaoeeeaeau/
    adspe
        3
    adspe  
    OP
       2013-01-08 22:24:39 +08:00
    @Kymair Lua是不是很快
    wang2191195
        4
    wang2191195  
       2013-01-08 22:28:13 +08:00
    与C语言相配合 如虎添翼~
    for4
        6
    for4  
       2013-01-08 23:14:28 +08:00
    短小精悍
    没深入过, 语法我不喜欢
    kran
        7
    kran  
       2013-01-08 23:18:19 +08:00
    学了之后,随时都想用它
    iZr
        8
    iZr  
       2013-01-08 23:36:35 +08:00 via iPad
    用《太囧了的话说》 你就是一朵奇葩阿
    liuhang0077
        9
    liuhang0077  
       2013-01-08 23:40:25 +08:00   ❤️ 1
    @adspe 求头像大图
    adspe
        10
    adspe  
    OP
       2013-01-09 06:11:39 +08:00
    @liuhang0077 我自己都找不到了。
    dndx
        11
    dndx  
       2013-01-09 07:32:36 +08:00
    快速,稳定。

    但是第三方 Library 不多,大多数情况下还是嵌入到 C 中或者作为胶水语言。
    middleware
        12
    middleware  
       2013-01-09 09:15:49 +08:00   ❤️ 1
    Lua 必将统治世界。
    高级语言能做什么?最适合的就是胶水。那就做最好的胶水。
    搞一个大的标准库怎么样?那样 C API 就变成了标准库维护者的私有 API。就无法成为好的胶水。
    胶水怎么了?Adobe Photoshop Lightroom 有 60% 是 Lua 这个胶水。
    Lisp 牛吧?Lua 和 Lisp 相比仅仅缺少 macro 和 full-continuation(但是 Lua 有 one-time semi-continuation)。
    smilebaby
        13
    smilebaby  
       2013-01-09 10:04:11 +08:00
    最大的问题 : 无异常处理 无面向对象的封装 用起来是比较痛苦的
    voojiankun
        14
    voojiankun  
       2013-01-09 10:46:30 +08:00
    当初玩mysql proxy的时候,写过一段时间,现在忘干净了
    clino
        15
    clino  
       2013-01-09 11:08:34 +08:00
    @smilebaby 这两个其实不是太大问题,做到和一般异常处理类似效果是可以的,面向对象的封装也很容易,但是面向对象因为没有标准推荐的做法,会有很多种变种,这个有时候会比较糟糕

    lua的优势还是在于效率和嵌入式
    drazen15
        16
    drazen15  
       2013-01-09 13:08:54 +08:00
    middleware
        17
    middleware  
       2013-01-09 13:19:32 +08:00
    @smilebaby Lua 的 prototype-based OO 比 JavaScript 实现的更简洁,但功能相当甚至更强。在 Lua 里,只要把所有资源置于 GC 之下(写好 __gc metamethod),lua_error() 就是 exception。而且对于支持 multi-return-value 的语言来说,exception 不是什么必要的东西,甚至不是什么好东西(Go 语言也同意这个观点)。
    liuhang0077
        19
    liuhang0077  
       2013-01-09 13:45:06 +08:00
    @drazen15
    @bombless

    非常感谢二位 感谢已发送。
    clowwindy
        20
    clowwindy  
       2013-01-09 13:54:28 +08:00
    用 C 实现不变的东西,用 lua 实现易变的东西,完美结合。
    adspe
        21
    adspe  
    OP
       2013-01-09 18:23:18 +08:00
    @liuhang0077 看到链接想起来好像是minitokyo上的。
    adspe
        22
    adspe  
    OP
       2013-01-09 18:24:02 +08:00
    @middleware Lua和JS比起来优势有多大。
    LazyZhu
        23
    LazyZhu  
       2013-01-09 19:37:55 +08:00
    @clowwindy
    特别是 luajit2 的出现后 :)
    darasion
        24
    darasion  
       2013-01-09 20:31:44 +08:00
    撸 哇 语言,玩游戏用的。
    middleware
        25
    middleware  
       2013-01-10 09:54:11 +08:00
    @adspe

    JavaScript 的优势在于在 browser 上的成熟度(Lua 有以 JS 为目标的 VM 可以运行在 browser 上,不过成熟度自然没有 native JS 高)。

    从语言角度说,JS 有的功能和 expressiveness,Lua 全都有,而且是用更 elegant 的方式设计和实现的。能嵌入到任何 app 中(Lua VM 没有 ANSI C 之外的东西,没有太多的宏,没有全局变量,不会劫持 message-loop 和 main(),所以完全不会污染现有代码)。

    孰强孰劣?
    flied
        26
    flied  
       2013-01-10 10:18:43 +08:00
    迅雷7的UI引擎是lua写的,嗯嗯,而且是开源的。
    clino
        27
    clino  
       2013-01-10 10:21:03 +08:00
    @middleware 很多时候不是哪个技术好就能胜出的
    middleware
        28
    middleware  
       2013-01-10 10:30:17 +08:00
    @clino 所以呢?难道技术好反而变成不能胜出的充分条件了?我列出 Lua 的优势,当然是在各种 context 下考虑的。其中 non-browser 环境下可以说 JavaScript 没有什么显著优势。
    54dev
        29
    54dev  
       2013-01-10 10:31:39 +08:00
    今天晚上有特么的哪个女的要跟你走啊。
    BigZ
        30
    BigZ  
       2013-01-10 17:34:00 +08:00
    @middleware js的优势在于简单:语法简单;不需要ide;不需要编译,随写随用

    这也是nodejs选择用js来开发的一个原因
    BigZ
        31
    BigZ  
       2013-01-10 17:35:52 +08:00
    这个世界上没有童话

    lisp诞生了超过40年还这么小众,java这么主流,米国这样强大,都是有原因的
    middleware
        32
    middleware  
       2013-01-10 17:43:14 +08:00
    @BigZ 所以呢?Lua 没有这些优点吗?Lua 诞生了多少年?而且它是从哪个国家诞生的?以 Lua 的年龄和发源地能取得今天的流行度,不能说明一些问题吗?
    ant_sz
        33
    ant_sz  
       2013-01-10 17:49:25 +08:00
    Lua 从一开始设计出来就是用作其他语言编写的程序的扩展语言的

    用来做配置文件,实现flexible的脚本逻辑等很方便。
    比如魔兽争霸和其他很多游戏都用他作为游戏关卡设置和控制的脚本,而主程序核心仍然是其他语言。

    实际上一直以来Lua的主要解释器不过是用来测试Lua的,更主要Lua提供了多种语言的比如说C的调用库。使得其可以极其方便的与其他语言进行交互。

    我想说每个语言都有自己的应用范围,没有哪种语言是可以一统天下的。 Lua 有自己特色和目标,在自己的领域表现的非常好,是有强大的生命力的。
    middleware
        34
    middleware  
       2013-01-10 17:52:27 +08:00
    我也不想说 Lua 能包打天下,只是说明各种语言它们的流行度的来源。比如 JavaScript,它的语言本身设计很差(相对的,当然和编译语言相比要轻量),流行度主要来自 browser 环境的成熟度(node.js 也是借用了这一点)。

    了解了渊源,大家可以自行判断前景。
    adspe
        35
    adspe  
    OP
       2013-01-10 18:18:43 +08:00
    @middleware 这个有体会。
    middleware
        36
    middleware  
       2013-01-10 21:13:29 +08:00
    @adspe Lua 不是最快的。不过它有一个冠军。Lua 算是用 ANSI C 实现的最快的 VM。其它 VM/JIT 多少要用到一些编译器扩展或者汇编。所以在高度跨平台的项目中 Lua 是不错的。而且在使用编译器扩展和汇编的前提下,LuaJIT 是非常快的实现。
    muxi
        37
    muxi  
       2013-01-10 21:19:04 +08:00
    非常支持 @middleware 的说法,最近一直在寻找一种能够高效利用CPU可以在web领域做RPC后端的语言,Lua在我的测试中确实表现出色,虽然跟Go比起来性能稍微有些慢,但是比起Go的语法,我更喜欢Lua,至少看着爽,现在纠结是用Lua还是用Go来写开始写原型,纠结于Go的学习曲线和过于简单的库
    middleware
        38
    middleware  
       2013-01-10 21:31:43 +08:00
    @muxi 其实我觉得大规模项目还是用静态类型语言做比较好。不过,写软件至少要写两遍,第一遍是把自己的想法快速的落到 code 上,第二遍是把 code 改成别人能看懂的。动态语言适合第一步,静态语言适合第二步。

    不过当今软件开发的难点是:动态语言的 code 不是那么容易就能改写成静态语言的。所以我们都在凑合:要么爽在第一步,但是项目越大越发愁;要么慢在第一步,但是项目大了不会失控。不好说 Lua 完全解决了这个问题,但是我觉得它的 C API 至少向正确的方向走了一步。

    Go 是静态语言,它也是用来更好的完成第二步的。至于第一步的衔接如何我不太清楚。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1004 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 22:26 · PVG 06:26 · LAX 14:26 · JFK 17:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.