V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
jtn007
V2EX  ›  程序员

各位猿类们如何看待语法糖?

  •  
  •   jtn007 ·
    Neo-J · 2013-11-18 10:10:55 +08:00 · 16760 次点击
    这是一个创建于 4018 天前的主题,其中的信息可能已经有所发展或是发生改变。
    语法糖很多时候的确能让代码看起来,写起来更加舒服,但是有时却会降低一些程序的运行效率。这个社区里大多都不是C,C++这种底层的更多追求运行速度的猿们吧?不知道大家怎么看?
    40 条回复    1970-01-01 08:00:00 +08:00
    Keyes
        1
    Keyes  
       2013-11-18 10:25:53 +08:00   ❤️ 2
    C/CPP/ASM一样可以写出高效率又好看的语法的吧,这个不存在,数学算法的代码在我看来再好看也不好看……

    现在和同事协作主攻Python,可读性还是放在第一位,至于效率嘛……不违反大原则(比如存储、IO资源滥用等)的情况下,语言效率可以放在最后一位,卡住程序的永远是IO而不是语言效率
    jtn007
        2
    jtn007  
    OP
       2013-11-18 10:35:10 +08:00
    @Keyes 我感觉是不是在硬件不断快速升级的时代,除了实时性特别强的一些代码,是不是都是可读性和敏捷开发大行其道?
    2thetop
        3
    2thetop  
       2013-11-18 10:48:02 +08:00
    语法姓糖,甜到哀伤。
    seeker
        4
    seeker  
       2013-11-18 10:53:18 +08:00
    我理解语法糖的目的与高级语言的目的差不多,让代码写起来方便简介易懂。
    ceclinux
        5
    ceclinux  
       2013-11-18 11:16:26 +08:00   ❤️ 3
    原来还有一种东西叫语法糖,有种东西叫语法盐
    angelface
        6
    angelface  
       2013-11-18 11:18:32 +08:00   ❤️ 1
    C里的a[i]和i[a]应该也是个语法糖吧,c[][]应该也是,我觉得和速度没什么关系。
    9hills
        7
    9hills  
       2013-11-18 11:23:16 +08:00   ❤️ 1
    我怎么觉得 语法糖 一般是降低了程序的可读性来换取效率啊,不管是写程序的效率还是程序运行的效率
    Keyes
        8
    Keyes  
       2013-11-18 11:23:38 +08:00   ❤️ 2
    @jtn007 什么是敏捷开发我不懂……协作的话在我这边可读性肯定是放在第一位,无论任何语言。当然这也不是一棒子打死的,还要看小团队的默契程度,几个人水平相当,写代码的方式和想法都差不多,就算不考虑什么语法糖也能看得懂想得到,那就可以用一些技巧或高级特性简化代码

    比如,我团队里的同事PYTHON水平都差不多,达到了了解PYTHON大部分特性的程度,我要实现一个取100以内可以被2整除的自然数列表:

    >>> s_list = filter(lambda x:not x%2, xrange(0, 100))
    >>> print s_list
    一行就搞定了

    反之,如果团队里有刚刚了解编程的,为了尽量能让他读懂,我会这样写:
    >>> s_list = []
    >>> for i in range(0, 100):
    >>> if i % 2 == 0:
    >>> s_list.append(i)
    >>> print s_list

    这样不高级特性,不用说xrange和range有什么区别,不用说lambda和filter是什么东西,随便有点编程基础的人都可以大致猜到这段代码的功能

    要说这两种方式有多大的语言效率影响?我想实际应用中如果不是大量频繁使用是可以忽略的

    不知道我举例的意思能不能说清楚我想表达的,大概就是说,要不要考虑语法,还是要看与你协作人的各项特征(当然别人也会迁就你,如果他考虑到这点的话)
    zhujinliang
        9
    zhujinliang  
       2013-11-18 12:01:55 +08:00   ❤️ 1
    如果是我了解原理的语法糖,当然该用就用了,没有把握的不会用。
    我印象中没有说哪个语法糖会牺牲效率,语法糖只是代码替换,按理说你不用语法糖一样需要通过相同的过程来实现。

    C语言上都会用#define造一个语法糖,如果算的话。。。
    aisk
        10
    aisk  
       2013-11-18 12:03:46 +08:00   ❤️ 1
    @Keyes 花一下午时间把lambda和filter搞懂不是更好吗?
    ispinfx
        11
    ispinfx  
       2013-11-18 12:09:00 +08:00   ❤️ 1
    @Keyes 花一下午时间把lambda和filter搞懂不是更好吗?

    -----------------------------------------------
    +1
    seeker
        12
    seeker  
       2013-11-18 12:16:08 +08:00   ❤️ 1
    效率跟语法糖的实现有关系。大部分语法糖不会影响效率,特别是编译型语言,语法糖在编译器就转化掉了,运行时根本不知道你是是否使用了语法糖。
    FrankFang128
        13
    FrankFang128  
       2013-11-18 12:30:30 +08:00 via Android
    性能恐惧症,得治。
    jtn007
        14
    jtn007  
    OP
       2013-11-18 12:35:29 +08:00
    @FrankFang128 哈哈,其实我倒还好,主要是我和小伙伴们讨论一道题时有感而发,我是提倡代码简洁优雅的,小伙伴给我提O(n)~~
    Keyes
        15
    Keyes  
       2013-11-18 13:14:32 +08:00   ❤️ 1
    @aisk
    @ispinfx

    别人学习,是要给别人时间的,每个人的性格、学习方式不一样也会造成差距。而且我这更倾向于需求导向,先想怎么解决需求、理清业务流程,然后尝试做DEMO,再说你往后能怎么优化提高,语言特性有时候显得并不是那么重要,团队大家都是绑在一起的

    PS:一点拙见,并非绝对……
    sandtears
        16
    sandtears  
       2013-11-18 13:37:14 +08:00
    囧... 我不喜欢语法糖,因为会降低可读性... 我有强迫症,写代码尽量带注释
    viator42
        17
    viator42  
       2013-11-18 14:28:38 +08:00
    有就尽量用,既然出现了这种写法肯定和这种语言的特性有关,像a[][]已经是约定俗成的了不用反而很奇怪.
    python的for in语句和java的iterator迭代器应该也算语法糖
    tioover
        18
    tioover  
       2013-11-18 15:26:20 +08:00
    a.__add__(b)
    nil
        19
    nil  
       2013-11-18 16:25:18 +08:00
    语法糖和性能应该没什么关系吧,语言的性能应该考虑虚拟机VS原生,虚拟机性能,静态类型VS动态类型,面向对象语义是发送消息还是函数调用神马的~

    至于编码的话,感觉还是语法单位越少越好吧,map reduce之类的应该是支持第一类函数的结果,随便学学,代码易读性的提升不是一点半点啊~ 不支持第一类函数的语言没法做这种抽象,应该可以认为比较弱吧~
    darasion
        20
    darasion  
       2013-11-18 16:51:54 +08:00
    知道有这么回事,然后选一种最通用的,一直用下去。
    luikore
        21
    luikore  
       2013-11-18 16:59:32 +08:00
    语法糖和易读性不是正相关也不是负相关, 和性能也是没什么关系.
    要求"不能用语法糖"就像要求写字要让文盲能看懂差不多.
    jtn007
        22
    jtn007  
    OP
       2013-11-18 17:01:01 +08:00
    @nil
    @luikore 恩,受教了,谢谢
    josephshen
        23
    josephshen  
       2013-11-18 17:04:55 +08:00
    我喜欢吃糖,虽然有着蛀牙的风险
    csslayer
        24
    csslayer  
       2013-11-18 17:05:33 +08:00
    语法糖不应该和性能有关系,如果因为不同语法实现相同功能而导致了运行时的不同,那就不能算作语法糖了。
    Golevka
        25
    Golevka  
       2013-11-18 21:13:31 +08:00
    许多编程语言的设计/实现都从一个功能高度正交的core language开始, core language拥有整个语言的[全部]表达能力, 但是直接用core language写代码实在是太卧槽了于是我们还需要做一些语法糖出来让撸代码更快乐些. 所以许多语言的编译过程都有一个叫做desugar的阶段, 目的就是把带糖衣的语法变换成更容易处理的core language.

    综上所述, 语法糖是好东西. 它在不增加语言本质复杂度的同时提升了语言的可用性.
    hahastudio
        26
    hahastudio  
       2013-11-18 22:07:51 +08:00
    @Keyes 话说
    s_list = [i for i in xrange(100) if i % 2 == 0]
    不是更好懂一些= =
    zongpo
        27
    zongpo  
       2013-11-19 08:39:51 +08:00
    喜欢甜甜的语法糖
    liushuaikobe
        28
    liushuaikobe  
       2013-11-19 09:17:05 +08:00
    @hahastudio
    +1
    这样写不能同意更多,100没必要用xrange
    @Keyes 花一下午时间把lambda和filter搞懂不是更好吗?
    mengzhuo
        29
    mengzhuo  
       2013-11-19 09:21:24 +08:00
    > 比如,我团队里的同事PYTHON水平都差不多,达到了了解PYTHON大部分特性的程度,我要实现一个
    > 取100以内可以被2整除的自然数列表:
    >
    > >>> s_list = filter(lambda x:not x%2, xrange(0, 100))
    > >>> print s_list
    > 一行就搞定了

    其实再快都不如列式推导,匿名函数+filter,再cache都不行。
    ifilter也是不错的选择
    -----------------------------------
    In [6]: %%timeit
    s_list = filter(lambda x:not x%2, xrange(0, 100))
    ...:
    10000 loops, best of 3: 38.4 µs per loop

    In [7]: %%timeit
    ...: s_list = [x for x in xrange(0, 100) if not x%2]
    ...:
    10000 loops, best of 3: 22.6 µs per loop

    In [8]: from itertools import ifilter

    In [9]: %%timeit
    s_list = ifilter(lambda x:not x%2, xrange(0, 100))
    ...:
    1000000 loops, best of 3: 1.36 µs per loop

    至于ls的运算符重载,显然已经踏入黑魔法的范畴了……
    zava
        30
    zava  
       2013-11-19 09:22:12 +08:00   ❤️ 1
    从某种程度上讲,C、C++不都是汇编的语法糖吗?汇编不都是二进制的语法糖吗?
    fwee
        31
    fwee  
       2013-11-19 10:30:15 +08:00
    除非直接写机器码,要不都是语法糖
    unionx
        32
    unionx  
       2013-11-19 11:10:56 +08:00
    计算机科学里并没有“语法糖”这个定义
    proudduck
        33
    proudduck  
       2013-11-19 12:00:20 +08:00
    @2thetop 哈哈哈哈哈,杀马特滚粗
    Foredoomed
        34
    Foredoomed  
       2013-11-19 12:22:26 +08:00
    看你的审美了,比如Ruby里的Object.new和python里的new Object()
    raymanyoung
        35
    raymanyoung  
       2013-11-19 13:35:18 +08:00   ❤️ 1
    一般来说需要编译的语言都会在编译的时候把语法糖转换一次,就是说执行上来讲并没有任何区别。至于解释性语言就要具体问题具体分析了。不过个人意见是大部分时候还是以代码的可读性为优先度,可读性和模块化好的话,针对瓶颈代码单独优化都可以。
    tywtyw2002
        36
    tywtyw2002  
       2013-11-19 14:39:15 +08:00
    @mengzhuo 像你所写的类似的python编程技巧,哪些书里面有介绍这些的呢?
    我写python写了一段时间,但是感觉这类的高级用法都没接触过。
    mengzhuo
        37
    mengzhuo  
       2013-11-19 14:59:52 +08:00
    @tywtyw2002 这根本不算技巧……O‘Relly家的Python cookbook,我觉得任何一本教程都有吧……
    tywtyw2002
        38
    tywtyw2002  
       2013-11-19 15:01:29 +08:00
    @mengzhuo ok,我在仔细读读,我记得以前读得时候基本没有看到 filter,lambda语法唐之类的东西
    Keyes
        39
    Keyes  
       2013-11-19 17:18:20 +08:00
    @mengzhuo
    @liushuaikobe
    @hahastudio

    这例子不是说代码的“数学”。。。是说写代码的“语文”。。。
    suspended
        40
    suspended  
       2013-11-19 22:44:11 +08:00   ❤️ 1
    @Keyes

    python 真是难懂,看看我大ruby:

    C:\>irb
    irb(main):001:0> (0..100).select {|i| i%2 == 0}
    => [0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 4
    0, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 8
    0, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100]

    irb(main):002:0> 0.step(100,2).to_a
    => [0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 4
    0, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 8
    0, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100]
    irb(main):003:0>

    两种都是一行,而且不懂ruby的猿也能秒懂。
    ps: 我读书的时候0 还不是自然数...
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1885 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 16:33 · PVG 00:33 · LAX 08:33 · JFK 11:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.