Clojure的未来

2020-12-11 07:52:10

欢迎大家参加ThoughtWorks技术播客。我是您的一位定期房东Neal Ford,今天我和另一位我们的定期房东一起加入了...

丽贝卡·帕森斯(Rebecca Parsons)。我是ThoughtWorks技术播客的另一位定期主持人,我是首席技术官。尼尔,我爱你介绍我们的客人。

我很乐意这样做。这是我的长期朋友Stuart Halloway,他是Datomic的团队负责人,也是Nubank的杰出工程师,但他不仅在Datomic方面还参与Clojure。那只是他在Clojure生态系统中选择的工作,因为他参与了很长时间。当然,这正是我们今天播客的话题,关于Clojure,我和Rebecca是我的忠实粉丝。因此,我们非常欢迎Stuart Halloway。欢迎,斯图尔特。

对于那些没有关注Clojure生态系统中发生的事情的人来说,在过去的一年左右的时间里发生了一些非常有趣的事情,不一定要做语言,而是更多地讲语言。斯图(Stu),您想向我们简要介绍一下最近一段时间您的生活有何变化吗?

几个月前,Cognitect加入了Nubank公司家族,这是一段长期的合作关系。 Nubank曾是Clojure和Datomic在其业务中的早期倡导者,并在整个业务中对其进行了真正的标准化。就我们所知,他们至少建立了谈论它的人,他们建立了世界上最大的Clojure代码库之一。我看到的最后一个估计是270万行Clojure代码,其中有数百个用Clojure编写的微服务。确实,Nubank的Ed Wible和其他人回头看是从焦油纸开始的。他们查看了他们认为在软件开发中存在错误的地方,并且要解决一个非常大的问题。他们真的想使银行业务更容易访问,并将银行业务带到没有银行业务的公司,并且从巴西开始,但现在在许多其他地方。而且,他们不想随扩展规模而偶然发现复杂性。他们期望自己需要快速增长才能实现该行业的目标。他们选择Clojure作为战略选择,认为语言的简单性和稳定性将帮助他们做到这一点。

他们还参加了Clojure生态系统,在ClojureCons和其他会议上发表了讲话,而且当双方共享相同的DNA时,这些公司交易确实很棒。当你们在一起见面时,谈论您的工作方式,您想从事的工作以及您认为的困难问题,并且您拥有共同的愿景,那么就不会出现阻抗失配的情况。它不像是两家业务重叠的不同公司,但是除了他们试图从事的工作或类似的东西外,没有什么共同点。因此,这显然是匹配的。

可以证明我的工作并没有太大变化。在交易之前,我领导着Datomic团队和Clojure的提交者。交易完成后,我将领导Datomic小组和Clojure的提交者,现在有更多资源。因此,埃德(Ed)将其总结为与以前类似,但更是如此。特别是,Nubank并不希望改变我们的工作方式,因为我们的工作方式就是他们的赌注。因此,他们就像,只是做更多的事情,并向我们展示您如何做到这一点。很高兴看到他们是如何做到的,并且看到他们是如何工作的,以及他们如何采用Clojure的简单性核心概念,然后将其大规模复制出来,这样您就可以拥有600个, 700名软件开发人员在其中工作,并招募了没有该语言或软件开发背景的人员进行培训。因此,在这之前,我们是一家小公司,这让我们感到惊讶和大开眼界,他们看到了他们能够拥有的惊人增长和成功。

Warning: Can only detect less than 5000 characters

好吧,那是对的。与拉取请求分开,任何大量的更改……更改确实是一个危险的词。里奇(Rich)谈到了这一点,他将其分解成不同的词。有不间断的增强功能,不间断的版本。然后,以事物的名称命名,并使其具有其他含义。因此,您拥有一个函数,一个类或任何名称空间,这意味着在软件的某些特定发行版中有一些东西,然后,您决定不喜欢那是什么,等等。 ,则表示其他含义。人们一直在这样做。我们甚至有一个学科来跟踪整个事物的簇效率,这称为语义版本控制。我们要说,我们要打碎你。然后,我们掌握了告诉您如何打碎您的整个技术。"

而且不乏名字。当我起步时,Microsoft在过去的日子里处理了这个问题。当他们确定在函数周围没有正确的语义时,他们将创建一个新函数,并在其后加上两个后缀,或一个后缀EX。在几个地方,我不知道您是否还记得那些旧的Microsoft API,是否会做一些EX2 EX,随着时间的推移,他们制作了几个不同的版本。尽管看起来很愚蠢,但实际上比我们现在做的要好。即使对于新事物来说,新名称也不是一件令人敬畏的事情,我们还是要好得多。即使我们已经取了好名声,也必须加上后缀或类似的名称。

因此,Clojure只是……我们不这样做。我们并没有采用世界范围内的名称,而是发布了新版本的Clojure,使该名称有意义或有其他用途。而我在另一方面也有这种感觉。 Datomic使用了相当有限的一组开放源代码库,它们实际上是好的库,并且经过精心策划,但是它们没有这门学科。因此,我每年一次或更经常地遍历代码库,查找必须在XML库上放置安全补丁的地方,但是,哦,顺便说一句,它们也改变了这种含义。事情。因此,现在,您不能只获得安全补丁。您必须说,我要去做这种牛刮胡的工作,以跟踪发生了什么和发生了什么变化。"而且没有必要。根本不需要这样做。

好吧,正是这一点。那不是网站的工作方式。您不会使用Facebook的特定版本或...在内部,它可能是不同的版本,但是您要使用的名称(名称)的语义保持不变,因为您39;总是去同一个地方。您不必知道要使用哪个版本,因为它们完全隐藏在里面。

好吧,另一个很好的例子是现在有数百种Amazon Web服务。对于绝大多数内容,您编写了一个使用DynamoDB或S3的程序,您猜怎么着?从现在起10年前仍然可以使用。只是没有,哦,对不起。这是Dynamo。而且有一个新版本的Dynamo,特别是有一个新的库。但是旧的东西有用。 NI无穷大。我希望这种情况继续下去。我认为,亚马逊在这方面有很好的纪律。

嗯,这也是Clojure的标志之一。我知道Rich在创建Clojure时的目标之一就是创建一种在很长一段时间内都非常稳定的语言。这就是我认为Clojure的东西...我听到了很多有关人们从事相当老的Clojure项目的传闻,但是他们能够成功地构建它们,因为没有很多东西改变了。就您的观点而言,您没有刻意随时更改核心Clojure中事物的语义。

对。我写了第一本Clojure书,至今已有10多年的历史了,代码仍然可以运行。因此,其中的某些东西几乎不可能在现代Clojure程序中使用。在某些情况下,有些新功能可以更好地完成某些任务,或者更好地适合过去可能曾使用过某些功能的任务。因此,defstruct是一种语言构造的示例,该语言构造不经常使用,但是在那里。它不会在今天或明年中断您的程序。

好吧,作为语言设计师,这是一个挑战,要能够对您的某些早期选择的后果进行足够的思考以能够保持这一纪律。我知道这是我在Rich在不同语言生态系统中所处位置的其他人所听到的。如果您不小心,则可以做出一个很早的决定,实际上会抹去相当多的设计选择,除非您愿意引入这些重大更改。因此,这种深思熟虑进入了核心并真正在思考,这就是我想要做的,"并了解潜在的后果是什么,这使得设计好语言变得如此困难。而且没有那么多人擅长于此并且可以长期保持这种向后兼容性。

我也认为这很有帮助,在这种情况下,这可能只是运气,但这并不是里奇的第一个牛仔竞技表演。正如我所做的那样,Rich提出了在C语言家族中使用可变的面向对象语言进行工作的想法。因此,C,C ++,Java和C#。而且他对表达能力,尤其是表达能力,越来越感到沮丧。或者缺乏表达能力以及使用这些语言大规模构建的事物的脆弱性,以及它们在处理变更和并发方面遇到的麻烦。因此,他查看了其他多种语言,并且喜欢Lisp家族和Common Lisp中的某些语言,尤其是喜欢的语言,发现他无法获得这些东西。因此,这就是保罗·格雷厄姆(Paul Graham)遇到的同样的问题。您可以用它来构建某些东西,并且可以在一段时间内成功完成,然后有人说,我们必须将其重写为我们在此处运行的东西。

因此,在Clojure之前,Rich曾为将Lisps与JVM结合而作过几次努力。所以,也许所有的错误都在那里,丽贝卡,所以我们不必了解它们。然后,另一件事就是对平台的强调,Rich不想构建有史以来最出色的学术语言。他想建立一种可以使用的语言,在那里他使用Java和C#来构建生产系统。因此,它最初是设计为在JVM和CLR上运行。然后,Rich将精力重新投入了JVM。然后,自Clojure最初发行以来,其他人都选择了备份。因此,现在您在CLR上有了Clojure。显然,您具有ClojureScript编译JavaScript,这是我们在一开始就开始和领导的,但是现在主要由David Nolan和其他人领导在Cognitect之外。然后,其他各种方言和人们正在做的事情,例如用Clojure编写shell脚本的babashka等等。

可能无法解决这个问题,但是您可以将稳定性归因于Rich的设计理念,但是您要归因于Lisp?例如,如果他选择了一种基于C的语言,那么您是否可以像Lisp一样强加某种固有的某种稳定性,使其变得更容易或更具有执行这种能力的能力?

这是一个很好的问题。我认为,只要有意愿,您就可以在任何地方拥有这种稳定性。 JVM在实现稳定性方面做得很好。布赖恩·格茨(Brian Goetz)和其他人在这里所做的出色工作要比Clojure保持稳定的时间更长。但是有一些优点。而且最大的优点是……尽管您可能也可以通过其他方式获得Lisp,但我认为Lisp很有帮助,因为Clojure中的结构非常通用,因此很少。因此,您不必管理表面积。

这就是OO的实践错误,这是错误的,到处都是特定的。您可以坐下来构建任何东西,而不必使用通用的东西(例如,我有列表,地图和结构),而是创建一个类。并教会初学者,为此做一个具体的课程,为此做一个具体的课程,为另一件事做一个具体的课程。而且您几乎永远都不要那样做。当您制作这些具体的东西时,您正在设计一个新的抽象。而且,大多数时候我们在工作时,我们并不是在设计新的抽象。我们要用已经存在的抽象来组装拼图,除非您在面向对象的程序中进行组装,否则您必须到处放置适配器,因为这些拼图都不适合其他拼图,因为它们39;全部都是定制的。所以,我认为那是...

但这仅意味着您可以创建更多的对象和类。这有什么问题?因为它全部由类和对象组成。因此,您可以创建越来越多的东西。

对于程序员来说,这绝对是充分的雇用行为,我们以此方式进行构建。而且我认为这需要对复杂性和痛苦的敏感性和敏感性。这是我们作为程序员所面临的挑战之一……我想我们大多数编写代码的人,真正有趣的事情之一就是在您实际键入代码时进入流程状态。我喜欢那个。而且我可以记得,几十年来,抬头仰望着四个山露,八个小时之后,就一直处于这种令人敬畏的流动状态,那很好。我认为我们应该寻求工作流。我认为,过上幸福生活的一个关键要素就是找到这种流动。但是,也可以花大量的时间来构建这种复杂的流程,然后再进行攀爬,因为可以通过构建简单的流程来完成。进入这种流动状态与您是否完成了出色的设计工作以及在继续构建事物时是否一直专注于设计完全正交。

对。或朝着以后才发现的方向发展。但是您可能就那样走了。作为设计师,我仍然要努力解决的一件事就是...的包......即使他们有好主意,但

......