前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >再见Python,你好Julia!

再见Python,你好Julia!

作者头像
代码医生工作室
发布于 2020-06-29 03:38:56
发布于 2020-06-29 03:38:56
7770
举报
文章被收录于专栏:相约机器人相约机器人

作者 | Rhea Moutafis

译者 | 王强

策划&编辑 | 刘燕

Python 仍然非常流行。但是,如果你现在开始学习 Julia,它将来可能就是你的头等舱船票。

本文最初发布于 towards data science 博客,经原作者授权由 InfoQ 中文站翻译并分享。

看到这个标题请不要误会我的意思。Python 依旧大受欢迎,其热度是由计算机科学家、数据科学家和 AI 专家组成的坚如磐石的社区撑起来的。

但如果你曾与这些人坐下来聊过天,你也会知道他们对 Python 的缺陷有多大怨言。速度缓慢,需要过多的测试,就算做过了测试也会冒出来运行时错误……让人头疼的事情实在太多了。

这就是为什么越来越多的程序员开始采用其他语言的原因所在——其中最优秀的替代品包括 Julia、Go 和 Rust。Julia 非常适合数学和技术任务,而 Go 很擅长模块化程序,Rust 则是系统编程的首选。

由于数据科学家和 AI 专家需要处理许多数学问题,因此在他们眼中 Julia 是赢家。就算是在最苛刻的对比条件下,Julia 也具有很多 Python 无法比拟的优势。

Python 的禅意与 Julia 的贪婪

人们之所以要创建一种新的编程语言,是因为他们既想保留旧语言的长处,又要修复其中的缺陷。

正是基于这种理念,Guido van Rossum 在 1980 年代后期创建了 Python,作为 ABC 的改进和替代。后者作为编程语言而言过于追求完美了——它如此死板,教学起来很容易,但在现实生活中却很难使用。

相反,Python 非常实用。你可以在"Python 的禅意"这篇文章(https://www.python.org/dev/peps/pep-0020/)中看到这一点,这篇文章反映了创建者的意图:

美丽胜于丑陋。显式胜于隐式。简单胜于复杂。复杂胜于繁复。扁平胜于嵌套。稀疏胜于密集。可读性很重要。特殊情况还不足以打破规则。而实用性胜于纯度。[……]

Python 仍然保留了 ABC 的那些良好特性:例如可读性、简单性和对初学者友好的优点。但是 Python 比 ABC 更加健壮,并且更适合现实生活。

ABC 为 Python 铺平了道路,后者又为 Julia 指明了方向

从同样的角度来看,Julia 的创造者们也希望保留其他语言的优点,而摒弃它们的缺点。但是 Julia 的志向更为远大:与其只取代一种语言,不如让所有语言都成为手下败将。

Julia 的创造者是这样说的:

我们很贪心:我们想要更多。 我们需要一种具有自由许可的开源语言。我们希望有 C 的性能和 Ruby 的动态性。我们需要一种同调的语言,具有像 Lisp 这样的真实宏命令,但又有类似 Matlab 这样熟悉又明显的数学符号。我们想要的语言应该像 Python 一样适合常规编程,又像 R 一样适合统计用途,像 Perl 一样能自然地处理字符串处理,也能像 Matlab 一样成为线性代数的强大工具,还能像 Shell 一样擅长将程序粘合起来。这种语言要非常简单易学,却又能打动最专业的程序员。我们希望它是交互式的,希望它是编译的。

Julia 希望将当下存在的所有优势都融合在一起,同时还不能为了这些优势做出牺牲,引入其他语言中的那些缺陷。尽管 Julia 是一门年轻的语言,但它已经实现了创造者设定的许多目标。

让 Julia 的开发人员着迷的优势

多用途

从简单的机器学习应用程序到规模庞大的超级计算机仿真应用,Julia 无所不能。在某种程度上来说,Python 也可以做到这一点——但 Python 是逐渐走进各个领域的。

相比之下,Julia 的多用途能力是天生的,从零开始打造而成。

速度

Julia 的创造者希望创建一种与 C 一样快的语言——但他们的成品速度甚至比 C 更快。尽管近年来 Python 加速起来变得容易许多,但是它的性能依旧与 Julia 相去甚远。

2017 年,Julia 甚至加入了 Petaflop 俱乐部——这是一个小型编程语言俱乐部,其中的成员都能实现超过千万亿次每秒的峰值计算性能。除了 Julia,目前只有 C、C++ 和 Fortran 是这个俱乐部的成员。

社区

历经 30 多年的发展,Python 已经建立起了一个庞大的支持社区。随便哪个与 Python 相关的问题,你都只需要谷歌一下就能得到答案。

相比之下,Julia 的社区非常小巧。虽然这意味着你可能需要深入挖掘才能找到答案,但你可能会一次又一次遇到同样的伙伴。这样一来,程序员之间甚至可能发展出超越纯粹利益关系的友谊。

代码转换

你甚至不需要了解任何 Julia 命令也能使用 Julia 编程。你不仅可以在 Julia 中使用 Python 和 C 代码,甚至可以在 Python 中使用 Julia。不用说,这样一来,开发人员就能轻松修补自己 Python 代码的缺陷。或者在学习 Julia 的过程中依旧保持生产力水平。

库仍然是 Python 的强项。

这是 Python 的强项之一——它的库数量庞大且维护良好。Julia 没有那么多库可用,用户还抱怨说现有的那点库维护得也不够好。

但是,当你考虑到 Julia 是一门非常年轻的语言,并且资源相当有限,你就会意识到它现有的库数量已经相当惊人了。Julia 库的数量还在增长,此外它还可以与 C 和 Fortran 中的库交互,以处理图表之类的任务。

动态和静态类型

Python 是 100%动态类型的。这意味着程序将在运行时确定变量是浮点数还是整数。

尽管这对初学者来说非常友好,但它也引入了许多潜在的错误。这意味着你需要在所有可能的场景中测试 Python 代码——这个过程相当笨拙,需要花费大量时间。

由于 Julia 创作者也希望它易于学习,因此 Julia 完全支持动态类型。但与 Python 不同的是,你可以根据需要引入静态类型——比如 C 或 Fortran 中的那些形式。

这可以为你节省大量时间:你可以在需要的任何地方指定类型,用不着再绞尽脑汁逃避 测试 了。

数据:投资潜力股的意义

在 StackOverflow 上标记为 Julia(左)和 Python(右)的问题数量。

尽管所有这些优点听起来都很不错,但请务必注意,与 Python 相比 Julia 依然是个新生儿。

一个相当不错的度量标准是 StackOverflow 上的问题数量:目前,Python 被标记的问题数量比 Julia 多二十倍!

这并不意味着 Julia 不受欢迎——自然,它需要一些时间才能被程序员广泛采用。

考虑一下——你是否真的想用另一种语言编写所有代码?不,你宁愿在将来的项目中尝试一种新语言。正因如此,每种编程语言在发布和广泛采用之间都会存在很长的时滞。

但是,如果你现在就采用它(这很容易,因为 Julia 允许大量的语言转换),那么你就是在投资未来。当越来越多的人开始采用 Julia 时,你已经获得了丰富的经验,足以成为指导他们的老手。另外,随着越来越多的 Python 代码被 Julia 取代,你的代码也会更加持久。

是时候向 Julia 表达一些爱意了。

底线:试试 Julia,让它成为你的优势

四十年前,人工智能不过是一种小众玩物。那时的业界和投资者并不信任它,与它相关的许多技术都笨拙且难以使用。但当时就了解它的那些人成为了今天的大牛——市场对大牛的需求如此火热,以至于他们的薪水足以匹敌 NFL 球员。

同样,Julia 现在也还是很小众。但随着它的发展,那些早日采用它的人们会成为最大的赢家。

我并不是说,如果你现在就选择 Julia,就一定可以在十年内赚到很多钱。但这样做的话,你是在为自己创造机遇。

想想看,市场上的大多数程序员的简历上都带有 Python 的字样。在接下来的几年中,我们将在就业市场上看到数量更多的 Python 程序员。但是,如果企业对 Python 的需求衰退,Python 程序员的比例也会下降。起初这种趋势是很缓慢的,但也是不可逆转的。

另一方面,如果你可以把 Julia 纳入自己的简历,就会取得真正的优势。因为不客气地说,你与其他 Python 程序员又有何不同呢?区别是很小的。但即使在三年之后,市场上也不会有那么多的 Julia 程序员。

有了 Julia 的技能,你不仅可以证明自己对编程的兴趣超出了职位需求,还能让人知道你渴望学习,并且对程序员这项事业有着更深刻的理解。换句话说,你很适合这份工作。

你和其他 Julia 程序员一样,可能是未来的编程明星,并且你们很清楚这一点。或者,正如 Julia 的创造者在 2012 年所说的那样:

即使我们意识到我们的贪婪实在无可救药,我们仍然希望拥有所有这一切。大约两年半之前,我们开始着手创建我们的贪婪语言。它还不完整,但是时候发布 1.0 版本了——我们创建的语言称为 Julia。它已经满足了我们 90%的苛刻要求,现在它需要其他人的苛刻要求来进一步塑造和完善。因此,如果你也是一位贪婪、疯狂、要求苛刻的程序员,我们希望你尝试一下。

Python 仍然非常流行。但是,如果你现在开始学习 Julia,它将来可能就是你的头等舱船票。从这个层面来说:再见 Python,你好 Julia!

作者介绍

Rhea Moutafis,正在攻读“暗物质物理学”博士学位,他热爱艺术、音乐和美好的事物。

原文链接:

https://towardsdatascience.com/bye-bye-python-hello-julia-9230bff0df62

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-06-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 相约机器人 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
设计模式六大原则(一)----单一职责原则
就一个类而言,应该仅有一个引起它变化的原因。应该只有一个职责。如果一个类有一个以上的职责,这些职责就耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这会导致脆弱的设计。当一个职责发生变化时,可能会影响其它的职责。另外,多个职责耦合在一起,会影响复用性。想要避免这种现象的发生,就要尽可能的遵守单一职责原则。
用户7798898
2021/06/10
3.7K0
【设计模式】学习笔记(一)——基本概念和设计原则
设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。 使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样。
鸡先生
2022/10/29
3590
【设计模式】学习笔记(一)——基本概念和设计原则
单一职责原则
座右铭 :There should never be more than one reason for a class to change. 应当有且仅有一个原因引起类的变更。。。意思就是不管干啥,我都只干一件事,你叫我去买菜,我就只买菜,叫我顺便去倒垃圾就不干了,就这么拽
LieBrother
2019/04/02
3730
单一职责原则
单一职责原则
单一职责原则的英文是 Single Responsibility Principle,缩写为 SRP。一个类或者模块只负责完成一个职责(或者功能)。
Yuyy
2022/09/21
4990
设计模式—— 一:单一职责原则
单一职责原则的英文名称是Single Responsibility Principle,简称是SRP。
三分恶
2020/07/16
5230
如何使用单一职责原则
类的职责也不是越单一越好,还是要考虑扩展性、可读性等,所有设计原则的目的瓯都市为了实现代码高内聚、低耦合,提高代码的复用性、可读性、可维护性。
十毛
2022/01/12
2030
设计原则之单一职责
上述就违反了单一职责原则,对于不同的交通工具,代码逻辑完全耦合在一起,我们无论修改那一类的交通工具,都会影响其他两种数据
止术
2020/09/15
2460
【设计模式】软件设计七大原则 ( 单一职责原则 | 代码示例 )
单一职责优点 : 提高 类的 可读性 , 提高 系统的 可维护性 , 降低 类的复杂度 , 降低 变更引起的风险 ;
韩曙亮
2023/03/29
4460
单一职责原则(Single Responsibility Principle,SRP)
1 简介 1.1 定义 不要存在多于一个导致类变更的原因。该原则备受争议,争议之处在于对职责的定义,什么是类的职责?怎么划分类的职责? 1.2 特点 一个类/接口/方法只负责一项职责。 1.3 优点
JavaEdge
2021/02/22
6340
单一职责原则
本系列文章从场景代码入手,通过代码review指出当前存在的问题,然后思考改进,最后进行提炼总结,即通过”代码-问题-改进-总结“的方式学习编程模式,感受思考的乐趣,To be a better coder.
数据小冰
2022/08/15
3290
单一职责原则
设计模式六大原则(一)--单一职责原则
单一职责原则是设计模式六大原则之一,强调一个类应该仅有一个引起它变化的原因,即每个类应仅负责一项职责。本文通过详细探讨单一职责原则的定义、实现方式、优缺点及其适用场景,揭示了其在软件设计中的核心地位。通过类的拆分、接口设计和方法提炼等策略,单一职责原则有助于降低类的复杂度,提高代码的可读性、可维护性和可扩展性。尽管过度应用可能导致类的数量增加和系统复杂性提升,但其在大型项目和复杂系统中的长期效益显著。
小白的大数据之旅
2024/11/20
2220
设计模式六大原则(一)--单一职责原则
10年+ .NET Coder 心语 ── 单一职责原则的思维:为什么你的代码总在"牵一发而动全身"
在编程的世界里,面向对象设计(Object-Oriented Design, OOD)就像盖房子时打下的地基,决定了一个系统是否稳固、耐用。而在众多设计原则中,单一职责原则(Single Responsibility Principle, SRP) 无疑是那块最坚实的基石。它不仅指导我们如何编写清晰的代码,还在某种程度上映射了生活中处理复杂问题的智慧。
AI.NET 极客圈
2025/05/27
560
10年+ .NET Coder 心语 ── 单一职责原则的思维:为什么你的代码总在"牵一发而动全身"
小谈设计模式(4)—单一职责原则
主要对目前市面上常见的23种设计模式进行逐一分析和总结,希望有兴趣的小伙伴们可以看一下,会持续更新的。希望各位可以监督我,我们一起学习进步,加油,各位。
学编程的小程
2023/10/11
3110
小谈设计模式(4)—单一职责原则
面象对象设计6大原则之一:单一职责原则
单一职责原则(SRP),The Single Responsibility Principle 定义 一个类的修改只能有一个被修改的原因。 通俗地讲,就是一个类只能负责一个职责,修改一个类不能影响到别的功能,也就是说只有一个导致该类被修改的原因。我们写代码的都知道尽量要做到低耦合、高内聚的特性,单一职责原则正是保证了类与类之间的低耦合性。一个类如果承担过多的职责,就会有很多原因来导致这个类的被修改,就有很大可能性影响到别的功能。 单一职责原则,看起来是一个非常简单的原则,但真正实践起来也并非易事,因为职
Java技术栈
2018/03/30
4930
单一职责原则(SRP):代码设计的黄金法则
在软件工程中,有许多设计原则和准则,用于帮助我们编写更清晰、更可维护的代码。其中之一是"单一职责原则",它是代码设计的黄金法则之一,也是面向对象编程的基石之一。在本文中,我们将深入研究单一职责原则,详细解释它的含义,并提供示例代码来说明如何应用这一原则。
coderidea
2023/11/13
7090
单一职责原则(SRP):代码设计的黄金法则
PHP面向对象五大原则之单一职责原则(SRP)详解
本文实例讲述了PHP面向对象五大原则之单一职责原则(SRP)。分享给大家供大家参考,具体如下:
用户8660814
2021/07/13
4130
java设计模式1,单一职责原则
单一职责原则(SRP:Single responsibility principle)又称单一功能原则,面向对象五个基本原则(SOLID)之一。它规定一个类应该只有一个发生变化的原因。该原则由罗伯特·C·马丁(Robert C. Martin)于《敏捷软件开发:原则、模式与实践》一书中给出的。马丁表示此原则是基于汤姆·狄马克(Tom DeMarco)和Meilir Page-Jones的著作中的内聚性原则发展出的。 所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变,那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。
全栈程序员站长
2022/11/17
3180
java设计模式1,单一职责原则
设计原则之单一职责原则(SRP)
单一职责原则是最重要的设计原则,也是最抽象的设计原则。小到函数,大到平台的设计,都可以使用单一职责原则来指导。也正因为它的抽象性,没有一个统一的规则,不同的人即使是设计同一个功能,所划分的函数、类也都是不相同的。
Dylan Liu
2019/07/01
9440
设计模式|理解单一职责原则
很早想总结一些关于设计模式的文章了,回头看一下几年前写的代码,简直不忍直视。也能理解,毕竟当初校招选择测试岗位也是为了逃避“写代码”嘛,但是谁能想到,当下测试行业大环境,不会编程的测试简直无法生存。亏我的思想觉悟比较高,认识到编程的重要性后就狂补了一些开发“基础”,例如Java、spring mvc这些知识,不能说专业吧,最起码也是运用自如,能实现自己的ideas。
互联网金融打杂
2022/08/01
2500
设计模式|理解单一职责原则
设计模式(一):单一职责原则
单一职责原则为我们提供了一个编写程序的思想,要求我们在编写类,抽象类,接口时,要使其功能职责单一,将导致其变更的因素缩减到最少。如果一个类的职责过多,则多个职责耦合在一起,那么就会有多个因素导致这个类发生变化,并且一个职责的变化可能会影响到其他的职责,不利于可重用性。
xujjj
2019/06/28
8690
设计模式(一):单一职责原则
推荐阅读
相关推荐
设计模式六大原则(一)----单一职责原则
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档