Cointime

扫码下载App
iOS & Android

"所有的黑客都去哪儿了?" + 一种讨论编程语言的方式

个人专家

我正在与朋友和同事谈论编程语言(蛮让人惊喜),这里是一个大致的语言框架。我将在这里分享它,希望你会觉得它有用,特别是因为我们曾经讨论过它们。然后我将用这个框架来说明,我们是基于小心和担惊受怕在公司环境中来谈论它们的。

当你比较语言时,你实际上在比较什么?

在拜访一个朋友的时候,他注意到我有一件Golang的衬衫,他告诉我他喜欢Golang,我告诉他我喜欢这件衬衫,但不太喜欢这种语言。他对稍后要 "谈论它 "感到很兴奋,晚饭后,我们瘫坐在沙发上,说:"好吧! 让我们谈论它!" 我想谈谈它的垃圾收集器(1,2),goroutines/channels是一个很不错的抽象,但我更喜欢BEAM的抽象,因为它允许Supervisors,以及谈论Golang对正确性非常宽松的方法......而他不想谈论任何这些。另一方面,他强调说他非常喜欢 "Go的开发者知道你所需要的只是一个for循环。有人把Scala带进了我的公司,我讨厌这种思维转变"。

这不是一次富有成效的谈话,我想我们都觉得我们没有重视对方关心的东西。当人们谈论他们喜欢或不喜欢的语言时,我把人们谈论的东西分成三大类,我称之为土壤、地表和大气层:

土壤是指在该语言中运行代码的属性。它的大部分是在代码实际运行时(基本性能特征,"它是二进制文件还是由 VM 解释",调度器和/或与多核/并行的关系,垃圾收集器),但更广泛的概括是 "一切不直接涉及 "社区 "的代码编辑,"所以我会涉及像构建时间和其工具的一些属性。所以我在Golang讨论中提出的东西是 "土壤",但也是:

  • 编译时间长的语言(Scala、Kotlin)与短的语言(Golang)。
  • Erlang有一个抢占式调度器,以及iolists + 字符串连接在引擎盖下的工作方式,意味着你可以呈现出末日的模板。

表面是人们在比较语言时通常会考虑的问题:功能! 源代码! 就是它是否有你最喜欢的循环结构(或者没有,按照 "只需要一个for循环")。语法,FFI,它支持哪些重码,其特定对象系统的语义。其他的例子有:

  • Less/Sass和CoffeeScript是纯粹的 "表面 "游戏:不涉及核心能力,但似乎是用纯粹的 "修复 "来扩展它们的次优表面。
  • "Ruby比Java好得多! 看看你如何在Java中打开一个文件(显示30行)与Ruby! (2行)"
  • MERN或MEAN堆栈的大部分吸引力在于 "它都是JavaScript/JSON",这意味着你可以减少需要学习的 "表面 "数量。
  • CSS-in-JS和Tailwind两边的强烈反应让人感觉到 "表面 "上的东西,尽管它们可以有 "土壤 "上的影响。

最后是大气层:这些东西不是语言或其代码,而是更广泛的社区。招聘,Stack Overflow的答案,GitHub上热门项目的星级数量,储存库中的包数。我再进一步,包括该社区的下游影响,例如,"该语言是否有VSCode插件和语言服务器 "似乎比其他的功能更多的是氛围:

  • 大多数 "你可以很容易地雇用React开发人员 "是完全脱离了对React作为一个框架的任何技术讨论。同上,Java,Python,Ruby,JS...
  • 一个语言的大部分文化: Elm和Clojure都有类似 "如果Evan/Rich认为你不应该拥有你想要的东西,你是否考虑过也许你是错的? 🙂"。Golang告诉你,你在十年前就想要泛型,这是个愚蠢的错误。Scala有所有这些愚蠢的戏剧。

对例外情况的简单说明:正如Hillel所说,"所有分类法都是坏的,句号"。在这里,"工具 "符合这三点:通常,工具(如语言服务器)的存在是一个社区的事情,但该工具的属性是非常 "土壤 "的,基于核心开发人员的决定,并对日常工作(如编译时间)或甚至部署后(如 "你能做事后调试吗?"--也是一种运行时的事情)有很大的下游影响。

另一个是 "静态类型"......我觉得这是表面的,但你可以说它是土壤。

总之,考虑到这一点,这里有一些观察结果!

这18个标志是 "Epic Stack "中 "It's time to Just Ship "的 "启动项目 "组成部分。但可以肯定的是,继续说 "只用TypeScript "会更简单。

讨论越往上越不具体

我觉得在讨论语言属性时,"土壤 "往往是相当具体的(例如Rust与C++程序的一般性能、内存安全),"表面 "是更多的感觉,但仍然在现实的某个地方接地(BEAM语言可以有监督者,因为OTP和不可变性,Go程序不能;但这对你程序的安全和最终业务影响的意义很难衡量)。而 "大气层 "问题则是极其基于感觉的: "你不能雇用FP开发人员!" (你真的试过吗?我所知道的几乎每家FP商店都不难找到爱好者,而且根据Python paradox,他们往往相当优秀......) "没有库支持!" (大多数repos都有一个很棒的repos集合,你具体需要什么?)。

我并不是说大气层问题不重要,只是我认为它们是最难限定影响的问题。你可以量化,比如说,npm有n个软件包,Cargo有m个,但是这些数字对于一个长期存在的、有商业效率的代码库来说意味着什么?你可以从HackerRank或Leetcode或Greenhouse或GitHub Jobs等来源估算出有多少Java开发者和Scala开发者,但这个数字如何转化为为你的具体公司寻找杰出人才?你今年要招聘......30000人吗?除非是一个原始的 "机构 "问题(而大多数公司,更难的是找到合适的机构),否则这和你有多大关系?

这让我很沮丧,因为我觉得...

目前的想法是 "不惜一切代价营造气氛!"

我的计算机事业在晚期才成熟。那是一个非常不同的时代:人们更多的选择了技术。Twitter在使用Ruby on Rails时遇到了困难,所以他们尝试了一种有前途的新语言:Scala。Heroku投资了Erlang,还有一个叫WhatsApp的小信息应用程序也是如此。2006年,ITA软件公司获得了1亿美元的资金,尽管他们只有10年的历史,而且是用Common Lisp编写的(他们在2010年以7亿美元的现金卖给了谷歌。这在当时很令人印象深刻;Instagram直到2012年才有了打破行业的10亿美元收购)。

今天,我们害怕做任何不属于JavaScript、Java、Python或Ruby的事情。我有一种感觉,从现在起的10年里,将只有JS。我们都读过那篇关于 "创新代币 "的优秀的麦金利文章,我们决定做一个避开地板的人而不是打破天花板的人。工程部的领导从恐惧和规避风险的地方出发,而不是乐观和相信他们的团队。所有的c̶o̶w̶b̶o̶y̶s̶黑客都去哪里了?

是的,使用一种奇特的技术可能会花费一个创新代币,但就像生活中的许多事情一样,创新代币完全是编造出来的,这就像谈论你在某一年可以给你的配偶的有限数量的 "爱情代币"。我想提供一个不同的框架:也许减少你的创新代币的最大方法是有一个小小的想象力。想象一下,在你挑选了你的技术栈之后,收到一袋代币。挑选一个伟大的、合适的、不属于四大技术之一的技术,你必须伸手到袋子里去花一个代币,但你看到你的袋子里还有6个;当你挑选一个无聊的技术时,你没有立即花任何钱,但袋子里只有3个。

在这里可以看到:快乐的工程师们正在享用由信任他们的首席技术官赠送的创新代币。来自《虎口》中的晚餐场景。

学习一种语言很难吗?

人们经常以相当高尚的方式谈论伟大的工程团队(以及他们想建立和工作的团队)。如果你有这种感觉,请举手:

  • 我更喜欢和优秀的软件工程师一起工作,他们不会把自己的身份与特定的语言或技术联系在一起(例如,比起自称为“Ruby 开发人员”或“JS 开发人员”的人,我更喜欢优秀的黑客。)
  • 我喜欢的队友是那些理解技术背后的概念的人,而不是把技术等同于整个堆栈(例如,"数据库 "对这个人来说并不仅仅意味着 "Oracle "或 "Mongo",一个理解BOM和DOM的人与 "Svelte "不同)。
  • 我希望团队中的这种人能够接触到多种技术,可以清楚地权衡它们之间的关系,并且能够理解和使用新技术。

就像平等住房权一样,在理论上,几乎所有接受调查的人都同意一套中立陈述的积极理想。也和平等住房权一样,不知何故,当需要对这些理想进行实践或投票时,结果并不一致。事实证明,许多工程团队完全可以雇用 "Java开发者",但如果你给他们看一些Python,他们就会大汗淋漓;雇用的人不能有效地阐述各种技术栈之间的权衡;雇用的人如果被要求花一周的时间来掌握新的东西,反而会抱怨和争论使用一些在未来几年都是次优的产品。

这里有一个有趣的问题:就像住房权利一样,为什么人们在头脑中有一种感觉,但在实际投票时却忘记了这些感觉?我在后面会更多地谈及这个问题(关于技术案例)。但是,花点时间思考一下你理想中的工程团队,然后思考一下你已经建立的或正在建立的团队,想想他们可能在哪些方面有所不同,以及为什么。"你带着你拥有的军队去打仗,而不是带着你想要的军队。" 是的,但是为什么?你建立了,而且正在建立这支队伍!

对于我在这篇文章中的所有主张,你可能会惊讶地发现,我相信要想成为一门优秀的语言,需要多年的时间。这不仅仅是语法,还有土壤和大气层:常见的错误流和如何发现它们,footguns,工具,库生态系统,文化。我有一堆学习新语言的技巧,尤其是奇怪的语言,你甚至会注意到即使那篇文章以 please please 开头,在向你的公司介绍其中一个之前请小心。

那么,为什么我在这里为 "Going For It "提出所有这些论点呢?因为我认为,在有经验的导师在场的情况下,只需要几天,也许一两个星期,开发人员就能把一种新语言的速度提高到足够的水平,特别是在强制性的代码审查下。这听起来可能很荒谬,但根据我的观察...

...大多数人对Boring Stacks大家的选择不甚了解。另外,他们也不会归纳总结!

我所接触的大多数Python开发的情况是,他们甚至对Python都不太了解。他们无法阐明何时以及如何使用abc与仅仅从object继承,或者为什么你可能喜欢namedtuple而不是dataclasses。他们不会知道 import x.y.z 会导入 x/__init__.py 和 x/y/__init__.py 以及 x/y/z.py (或者 x/y/z/__init__.py)。他们不能告诉你GIL是谁,或者为什么你不应该 def send_emails(list_of_recipients, bccs=[]): 。这个游戏在谈论JavaScript时特别有趣 😉

大多数开发者对他们所使用的工具的理解有很大差距。这也没关系。但是,但是关于“纯粹的大气层”论点的事情,比如“雇用具有 [X] 经验的人更容易”,根据我的观察,他们的经验并不一定有那么深,那些认为自己在雇用这些语言的熟练使用者的人是在欺骗自己。在我工作过的7家公司中,许多人的水平都只能说是 "足够"。

培训不是免费的,但它是每个开发人员的固定成本,特别是对于熟练的导师,可能比你想象的要少。我觉得2-4天的固定培训费用极不可能低于超线性构建时间+管理1000个Sidekiq或Celery队列的费用,而你本可以直接选择Go。

另一件事:这些技术人员实际上并没有实现标准化。我曾在4家使用Flask的公司工作过;没有一家公司有可比的应用结构或使用相同的插件(是的,微框架!)。"只要使用React",但有一段时间,是 "使用状态管理器或不使用状态管理器(Redux)",然后是 "使用hooks或不使用hooks",然后是 "使用CSS-in-JS或其他东西(和/或BEM,或现在,Tailwind)"。我工作过的每家公司都建立了自己的设计系统和/或组件库,有自己奇怪的调用约定。我工作过的两家React公司的测试方式都不一样,也没有关于其资产管道或JS转换选项的可转让知识。

xkcd漫画,最初的标题是一个男人把数学搞得一团糟,一个观察者说 "哇,你的数学真烂",然后观察一个女人把数学搞得一团糟,说 "哇,女人的数学真烂" 漫画经过编辑,改为显示Python公司倒闭,有人说 "哇,创业公司真难",一个Erlang公司倒闭,说 "哇,因为他们选择Erlang"

怀着对原作的热爱。

为什么我们在 "不惜一切代价的氛围下"?

这些可能可以单独写成博文,但这篇已经够长了,所以我就列出一些诱饵,也许以后再跟进:

十年来的0%和愚蠢的资金使科技变得愚蠢;"VC科技公司 "成为了一个剧本。初创企业曾经是狂野西部,VC被期望为0,因为赌注是如此愚蠢和巨大。天马行空的创造者在那里更受欢迎。随着时间的推移,"风险投资 "保留了这个名字,并试图保持Big Bets的牛仔品牌,但在实践中变得更类似于定期投资,而风险投资支持的技术发展了一个预期常规回报的剧本。车库乐队中可能拥有“果汁”的朋克被获得音乐学位的干净利落的工作室音乐家所取代。这导致了风险厌恶和对 "无聊 "的迷恋。

传统的商业和资本文化的注入,传统上是为头脑简单的人、无聊的人和没有想象力的人服务。看看机场的商业书籍:它们往往是相当脑残的。就像《The Rude Press》发生的事情,前卫的媒体 "仅仅 "盈利,看着Twitter上的蓝色支票舔着嘴唇,认为我们可以用人工智能取代电视编剧(或者在Midjourney文本字段中输入 "hot cyberpunk",他们就成为了一个完整的艺术家);随着科技越来越成功,我们在商业游戏中得到了更多的一类人,他们对创造者和他们的表达感到不舒服,并希望相信你可以用已知的、可控的、无风险的过程创造一些惊人的和创新。

工程管理和领导文化成为现实;人们成为围绕 "无聊 "的群居动物。在过去的十年中,我们看到了技术管理阶层和其思想领袖的崛起。来自其他领域的没有技术知识的经理人做得不好,但被提升到管理层的工程师也是如此。我们需要的是一种隐藏的、第三种东西。很多影响都来自于权威性的发言,即使叙述还没有确定;在这个社区里最受欢迎的打雪仗是Manager READMEs(支持或反对)。尽管有很多保证专业的声音,我观察到工程领导力在实践中也是一条曲折的道路(在这里读到的Brandur的优秀短文)。我认为 "无聊 "在某些时候是一个很好的策略,但本着作为 "房间里的成年人 "的精神,我认为它作为一种普遍的好东西而被人们所接受,而且这类管理人员蜂拥而至

最新的、最简单的方法就是恐惧未知。关于 "大气层的成本/效益是最重要的 "的有趣的事情是,它们是最难具体化的:我觉得我所推崇的晚期时代曾经是关于 "地表 "的,而且同样是令人疯狂的模糊。函数式程序员在没有证据的情况下坚持认为他们的程序是更正确的。动态类型的人在没有证据的情况下坚持认为他们的程序没有那么正确。我想我们也在玩同样的游戏,即诉诸于感觉,但在十年前,随着CS入学率的提高,boot camp,Stack Overflow,GitHub,以及文本编辑的进步(语言服务器,VSCode的单一文化),我们不能谈论大气层,所以我们尽可能地往上爬。

意思是:一如既往,是对领导工程团队的恐怖的应对方法。你在海上,许多人的生计在你的掌握中,虽然你很确定你知道如何读懂星星,但这是连续第二个星期的阴天;你开始变得迷信。你更倾向于相信冷静的专业人士的权威声音。你会在你能控制的事情上减少风险,因为你太害怕你不能控制的事情。

(附注:你们中的更多人需要在艺术领域工作一段时间😉)

关于这些观点,我还有很多想法(有一百万种方法可以把异国技术搞砸,说了这么多,大多数人都不应该这样做;另外,"无聊 "已经拯救了很多公司。但我保证过会有火药味!)。

  • 经验之谈:在与别人谈论技术时,考虑一下:这是一个土壤、地表或大气层的对话?一起决定你想进行哪种对话,以及你所选择的层的局限性,因为如果你不这样做,很容易就会把对方说漏了。
  • 重新评估你所认为的技术之间的 "边界"。React真的只是到处都是React吗?例如,如果你的团队使用Retool,这不也是一个可编程的接口,带有各种附加技术,可以访问你的生产数据存储?为什么添加Retool比Java服务更容易?并且认为学习Retool的 "训练时间 "很繁重吗?
    另一个有趣的思考例子:你是否认为构建原生手机应用而不是React Native、Flutter或LiveView Native是如此危险?为什么会有这样的不同呢?
  • 技术选择不会对你公司的成功负最终责任。但它肯定会决定你的道路是什么样子的,说 "技术不重要 "是个错误。Bleacher Report在一次移植后,从150台Ruby服务器变成了5台("可能是过度配置")Elixir服务器。像JVM、BEAM或Go这样具有适当并发性的语言不需要Sidekiq或Celery队列和额外的工作人员。BEAM的抢占式调度器意味着你不会像Lyft在Python中处理的那样持续且烦人的问题,或者可能会在Node的 "事件循环但在单核 "中困扰你。培训不是免费的(让我再说一遍:它不是免费的!),但有些技术是特意为高效而建造的,而有些技术的扩展则是非常糟糕。
  • 重新考虑所有技术领域的 "圣牛",一般来说。微服务并不是不可避免的(考虑FB的Blue App、Dropbox、YouTube、Instagram:都是单体应用)。PHP是过去十年的笑柄,但它为Slack和Lyft提供了多年的支持,Hack仍然在运行Facebook。"云服务是更好的",但Stack Overflow的数据和流量比你多得多,而且在9台机器上运行。WhatsApp 在进行手动裸机部署时以 19b 美元的价格被收购。

而且:如果条件合适,你的团队有足够的热情,你可以在一个不是JS、Ruby、Python、Java的技术栈中运行。

此外:

  • 花点时间问问自己:对于我最喜欢的技术,我不知道什么?如果我知道了,会有哪些东西被解锁?
  • 你和/或你的团队可以进行哪些培训或练习来提高你所使用的技术栈的水平?
评论

所有评论

推荐阅读