最近研究 python 的一个小失落

@serial 你以为程序员就写应用？？真是坐井观天，整天写应用也不觉得烦。

我就告诉你，在数据（或者数据分析）领域，多数产品都不是软件成品而是报表，数据的分析结果。代码都是一次性的，这种情况下，你拿 C/C++/Java 去写一次性程序，每次都要建个项目你蛋不蛋疼？？性能差又怎么样，又不是给用户用，你就差那么点时间，急着去投胎嘛？？

@serial

[错误，听说过 Lisp 机吗？ Lisp 机败给了 C 机器，原因就是速度。 ]

那是以前，现在计算资源过剩，性能差又如何呢？？

别整天瞎 jb 谈性能瓶颈，别以为你那边整天需要高性能，就以为全球人民都需要高性能。你可以觉得你在高性能方面做的不错，但是大部分情况中你讨论的前提就不成立。你这就是把自己的需求当成所有人的需求。

多数情况并不是那么苛刻，需要的是开发效率，你还懂产品？？等你拿 C 语言写出来了，别人拿 Python 写的早就上市了。
软件开发就是要讲权衡，过度追求运行效率就是不对。

Lisp 机单纯是因为速度？？易读性差和生态不丰富也得背锅吧？？真是无知。

以上

@dzhou121 @LINEX @dzhou121

我们写的程序中 100 里大约有一个需要高性能，那么这一个就用别的语言写好了，剩下 99 个还是能用 Python 的。

LZ 的问题就是在于过度强调性能。它也说了性能和开发效率是个权衡，那么过度强调性能就当于过度忽视开发效率，这个就是作恶了。

况且现在是性能过剩的时代，要说性能瓶颈最好也要等摩尔定律失效个几年之后。所以黑生态差可以，黑开发效率差可以，黑性能就纯属为黑而黑了。

火药味很足，菜鸟只能看楼上谈笑风生，希望有一天也可以

@hanfeng3015 王垠的私货要引用也行，但别不到点上。顺便他是一向很鄙视 Python 的。

语言的“速度”，其实是一句空话——这倒是没错，不过原因是——“速度”是个向量。搭配不当的语病 fail fast 就行了。

“语言只负责描述一个程序，而程序运行的速度，其实绝大部分不取决于语言。它主要取决于 1)算法和 2)编译器或解释器的质量。”

这里的外行在于语言忽略了语言钦定的语义。把一个语言设计成编译器或解释器实现得无论如何不得不低效（否则就不算符合语言规范要求）是很容易的。

不过 Python 的“慢”主要并不是这个问题。例如， GIL 就不是 Python 的锅而是 CPython 的锅。

然而最主流的实现如此熟练地甩锅给用户且用户经常不得不接受，也从侧面体现出设计之外的辣鸡了。

另外一个情况是语言自身描述性能规格的时候，比如要求时序。这里就没必要展开了。

所谓“ Lisp ……代价”指的更像是 Lisp 自身的抽象的缺陷。不过王垠近年来似乎终于知道 Lisp machine 一条路走到黑到处都不能 O(1)了？

@pyufftj “你的”计算机，谢谢。

@wizardforcel 我以最终用户的身份鄙视你的观点。

别以为你那边不需要高性能，就以为全球人民都不需要高性能。事实是能论证清楚哪里不需要“高性能”的用户压根就没几个，更别提逗比开发者乱加中间层挥霍的能有多少了。或许你都没感觉到能耗也算是性能需求的一部分吧？

至于“多数情况”，根本哪壶不开提哪壶。服务器吞吐量厨惯了也就罢了，随便一个客户端应用还 yy 整个机器内存“不用白不用”，谁 tm 给你的胆把用户的宿主环境不当多任务系统看？

这种不经过大脑分析需求“性能过剩”论给我的计算环境添堵有很大的功劳。比如说，市面上常规手持设备就没有一个能面向最终用户指定任务保证响应的，谁的锅？

面对横竖都是被坑的局面，用户能怎么办？把生态推倒全部自己撸一遍？开玩喜呢。

市场手段效果不显著，那么除了对付 dssq 见一次打死一次以外就没有效的通用解法了。

@FrankHB

常规手持设备的“故意连锁唤醒和故意驻留内存”和我说的“为了开发效率牺牲一些运行效率”是两回事，不要偷换概念，因为你知道我说的是哪一种。

啥叫“服务器厨惯了”？？我不否认服务器需要考虑性能，但普遍做法不是把应用往死里整，而是负载均衡，即把应用做成可扩展的，之后垒机器就行了。这个做法跟 LZ 是背道而驰的。

LZ 的做法唯一有用武之地的情况就是实时系统--需要快速响应的系统，可这种一般用于科考或救援。这种算不上多数情况就不用我说了吧 。在搞互联网的圈子里说 python 不适合这种环境，这是在逗我？？

另外， LZ 使用 lisp 不火 python 火的论据，是否也说明性能在以前重要，现在不是那么重要了？？（手动滑稽）

@wizardforcel 我看到你要提的合理性就是工程上需要 trade off 以及性能需求不总是第一位的，这点很简单，不用那么漏洞百出的论调来复杂化和削弱可信性。

我旗帜鲜明地反对的是不分析性能需求的外延就主张放弃性能。只要能保证按照约定的质量按时交付，对性能吹毛求疵好歹对最终用户没有损害；而不仔细分析拿性能当妥协，很难保证不损害用户（本来理当享有）的利益。一家两家这样做没什么问题，但当这样成为业界主流时，不兼职开发的用户就只能挨宰了。这显然不是应该提倡的情形。

注意分析清楚保证没有 false negative 的性能缺陷实际上几乎总是很困难的（换句话说，即便是约定清楚了指标，你也不太可能让性能恰好降低到符合要求而腾出资源让位给其它需求），所以优先强调性能是一种保守（尽管可能低效以及同样反智）的工程策略。

这种主张有一些庸俗版本的说法，其中有不止一个问题。比如说，“计算资源过剩”——同时忽略了背景以及不同计算资源基本上很难全面过剩（真全过剩了用户算是一定意义上活该）的事实。

“服务器”的问题你刚好理解反了。我的意思是服务器（准确地说也不是所有服务器）常常恰好不关心某一种“性能”，所以写惯了服务器应用的开发者往往在这里少根筋。

具体说来，像 Web 服务器应用，同样是性能需求，吞吐量通常远远重要于交互操作的响应。这使得使用 STW 的 GC 作为一种优化是可以被接受的。但是有些人基于某些理由不顾性能需求的差异，就 yy 这样的场景同样适合于其它领域，把选型策略无条件上升到方法学；甚至不惜直接代替用户决策来保证系统可用性。

当然，大部分客户端的响应其实也并不是非常高，分时系统是可以接受的。但是实际用起来如何呢？当市面上主流产品没法保证不堆硬件就不损害日常体验，是不是反省是谁该给原则错误买单了？

嗯，上面婊的是 Java ；用户熟悉的代表坑货是 Android+OOM killer 。

不过考虑到语言内建 GC 的流行，大部分没有考虑清楚适用范围的语言在这里都难逃其咎。和这个主题直接相关的是， Python 从原则上（想做通用领域语言，想“简单”）就很不擅长应对这点，加上实现的实际表现也不咋地，所以成为靶子也不奇怪。

注意，这里说的是 Python ，不是“互联网的” Python 。 Python 从来就不是互联网行业专用的 DSL 。否则，一开始就没必要讨论了。

Lisp 当然有另外的槽点，不过和这里的话题比较无关就是了（至少 Lisp 不存在一种大规模的主流实现能拉到那么多仇恨）。

Talk is cheap, show me your github. @serial

论计数功底, 不论阵营 @serial @FrankHB 牛逼, 其他的都是垃圾

@GeekGao

你写过 Spark 吗？ 我写过。你用过 PySpark 吗？ 我用过。

别给我再贴你没用过没写过的东西。你就是个 bullshit 。

@wizardforcel

恰恰相反， Lisp 的价值就是可读。 Lisp 的语法就是语法树，(* (+ (- 1 2) 3) 4) 。这种语法对机器非常有利，机器可以更容易的生成“人工智能”代码。但是，根据摩尔定律，硬件的性能提升每年才一倍，要达到这种分析和生成，还要等到猴年马月。

@serial
> 我现在让你写个 web servie ，进行日志分析任务。要求提供分布式存储、观看任务状态的消息队列、实时客户端回馈。你给我用 python 设计设计来。
>
> 请问，我该用哪些 python 库可以实现。我的要求高了，我这是一个认真的项目，你给我的库必须是工程级别，经过认真测试应用的，而不是某个菜鸟凭着兴趣爱好摸索的一些实验品。我要求满足：至少每秒处理五千次读请求数、每秒处理一千次写请求数。（这个要求不高吧，顶多算分布式环境入门级别）

这些很简单的，而且业界都有开源的工业化组件了，有这些问题说明没有接触过工业化的 Python 编程吧。。

@serial 你贴的测试没有什么意义， Python 在 CPU 密集型应用上的性能比 C/C++要慢几十倍这是常识。你的问题在于：

1.不会有人傻到用 Python 去写 CPU-intensive 应用（除非那个人只会 Python ）。

2.多数 web 场景下 CPython 解释器的性能不是明显瓶颈，有大量的时间耗在 I/O 上（这个做过 profile 不可能不知道），要不然为什么 Erlang 在个别服务器端领域莫名其妙火起来了？尤其在 Gevent 、 Celery 这类东西出来之后，高并发场景下 Python 已经被大大续命了。我司（某二线互联网）的自定义错误页跳转是我组用 Python 写的， C30k 以内客户端都能有满意的响应时间。个别小功能依赖 CPU 时我们的方法是用 C 写这个模块。

接触 C50k 、 C100k 级别项目的人是少数，我接触过极个别因 CPython 性能太烂而不得不换语言的场景都是跟启动线程的速度太慢有关。

@serial 这么多天过去了，老子都懒得理你了，你还跟我逼逼。我只好粗口相待了，你个傻缺， asshole 大神。

这种技术贴下还有水军啊： https://study.congcong.us/member/loohawe/replies
V2 站的某些人真是有趣！

@FrankHB

你这句话反过来理解就是“你反对不分析性能需求的外延就主张某种语言性能差”。再一次打了 LZ 的脸。

服务器的例子中，由于 python 虽然计方面性能差， io 还说的过去，所以他们并不关心计算性能。但是，吞吐量算不算性能的一部分？？ LZ 拿个跑分，也就是只能反应计算性能的东西说 python 性能差，但为什么它在 io 密集的应用中运行得好好的？？在逗我？？

最后， python 声称是通用语言，所以你就认为它在每个领域都要工作得很好？？根本就没有通用的语言，即使是那些自己声称的。 python 在互联网中够用，数据科学中也够用，不够用的地方换其他语言就得了。

@alexapollo 然而远程 io 的瓶颈是最大的，光跑得快有啥用？？都得跟那儿卡着。😂😂😂

@loohawe 上大号撕逼是基本法。

@serial

[恰恰相反， Lisp 的价值就是可读。 Lisp 的语法就是语法树，(* (+ (- 1 2) 3) 4) 。这种语法对机器非常有利，机器可以更容易的生成“人工智能”代码。]

函数调用表达式和前缀表达式具有相同的优势，比如 mul(add(sub(1, 2), 3), 4) ，它同样也对机器有利。而且函数在几乎所有编程语言里都是这个写法。

@GeekGao

怎么举报这个傻 B