为什么编程语言〇〇没有流行起来?

最近,我对 Lisp 和 Smalltalk 等较早的编程语言很感兴趣。当你触摸它时,它非常有趣。有时我会想,但我不能说它很受欢迎。

例如,代表编程的流行TIOBE指数不过也不能说排名高,那些语言就是编程语言的历史。在此期间,我学到了一些东西,但我对此了解不多。很多人都这么说。

如果你搜索 Quora,“为什么 Lisp 没有接管?”或答案“为什么 Smalltalk 没有被广泛使用?”你会找到答案的。

当我阅读有关每种编程语言的论述、实际使用它并解开它的历史时,我想出了一些我想总结的东西。挺有诗意的

目前流行和不流行的编程语言的区别是

自互联网出现以来,是否设计了编程语言?

我是这么想的。
这篇文章是关于较老的语言,哪些更容易成长:Rust、Nim、Zig 等较新的语言?这不是一篇需要考虑的文章。

软件开发时间表

下面的年表从“编程语言”、“源代码管理系统”、“包管理系统”、“专门针对编程语言的包管理系统”和“互联网的历史”五个角度进行总结。

流行っている・流行っていないプログラミング言語に関する1つの考察

有一天,我看到一个说法,“编程语言没有优劣之分。不需要高难度的编程,软件开发只需剪切和粘贴库就足够了。重要的是有多少库可以使用。”这个论述不是我的,但有一些部分我曾经同意。我想。诚然,近期节目的“难点”往往会被包起来,而且往往是通过图书馆来打的,会获得多少用户,业务又将如何转机? PMF怎么做?这就像,与其投资技术,重要的是改进 UX 并高速转换构建和报废,以便快速看到用户的反应。这是不久前发生的事情。我就是这么想的。

好吧,作为一名工程师,我不确定这是否正确,但是支持这种论述的可能是大量的库,它不就是一种允许您搜索库的机制吗?我想。于是,“图书馆管理/包管理系统是什么时候做的?”这个问题就诞生了。
CPAN,也就是Perl的包管理,很有名,不过好像在那之前有个东西叫CTAN。这是一个排版的 TeX 包管理系统。第一个版本是在 1992 年。
之后,我开始关注 Debian 系列的 dpkg 和 apt 以及 Cent 系列的 rpm 和 yum 的流程。 1994 年 dpkg,1998 年 apt。 rpm 是 1997 年,yum 是 1999 年。这就是我的理解。

这周围第一个包管理系统集中在 1990 年代。这就是我开始明白的。

之后,我探索了特定语言的图书馆管理。用于 Java 的 Maven 或用于 Ruby 的 gem。对于 Python,我尽可能地搜索了我能想到的东西,比如 easy_install。
然后,1990 年以后创建的语言有很多特定语言的包管理系统,而 1990 年之前创建的语言很少有特定语言的包管理系统。这就是我开始明白的。
在以这种方式讨论了特定于语言的包管理系统之后,我们终于探索了“源代码管理系统”。虽然它与源代码管理系统略有不同,但在“共享源代码”的背景下提到了 1971 年制定的 FTP。专门用于源代码控制的经典系统包括SCCS该系统创建于 1972 年。 CVS 是在 1990 年创建的,而 SVN 是在 2000 年创建的,如果它是一个众所周知的系统的话。 2005年前后,由于围绕 BitKeeper 和 Linux 的冲突,Linus 开始制作 Git.大约在那个时候,SVN 和 CVS 等集中式源代码管理系统对分布式系统越来越感兴趣,并且还创建了 Mercurial (2005) 和 Bazaar (2007)。如您所见,主要是在 2005 年之后,分布式源代码管理成为主流。
在我继续调查的过程中,1990 年左右的时代发生了一些事情。这就是我开始明白的。那是什么?考虑到互联网普及假名。那就是我所想的。 1982 年,4.3BSD 在操作系统级别实现了 TCP/IP。但是,此时的 BSD需要 AT&T 许可证看起来。 1991 年 CERN 发布了第一个网页。之后,1994 年发布了 Linux 1.0,这是一个获得许可的免费 Unix,1995 年出售了带有 TCP/IP 和 Internet Explorer 的 Windows 95。我认为互联网从这个时候开始在日本传播开来。

学习一门经典编程语言的印象

一开始我开始学习Lisp,保罗格雷厄姆在 Lisp 上正在阅读Paul Graham 是 Yahoo! 原型的创造者和销售者。读完后,我想用 Lisp 编写一个 REST API,并做了一些研究,但我不知道如何安装该库。不,我明白了,但我不知道首先有什么样的图书馆。如果您认为可以像 npm 一样轻松安装它,那似乎并非如此。根据维基百科

由于易于实现,Lisp 产生了如此多的方言。宏允许我们扩展语法结构本身,所以在某种意义上,我们甚至可以说每个用户都有一个方言。从 1970 年代到 1980 年代,有两个主流,MACLISP 和 Interlisp,它们影响了后来的 Lisp 方言。

Lisp 似乎稍后会被 ANSI 标准化,但根据处理系统的不同,似乎有一些怪癖。我开始想,“所以 Lisp,甚至可能是包管理,由于处理系统的方言,可重用性很低,所以它不是一个可以重用此类库的文化领域......?”。

接下来,我开始学习 Smalltalk。 Smalltalk 简介可在 Ogis 研究所获得重新介绍面向对象非常好。 Smalltalk 几乎完全以 GUI 为前提,开发环境本身被设计成一种操作系统。
作为我兴趣的一部分,我如何为此进行分布式开发?你如何进行版本控制?我有一个问题。 Smalltalk区的源码管理比较特别,这个特别的特性在这个里面总结的很好“使用 Pharo Smalltalk 进行源代码管理 - 如何管理 Pharo Smalltalk 源代码”是。根据上面的文章,看来要等到 2012 年的 FileTree 才能在 github 上相对容易地管理 Smalltalk 源代码,因为它的特殊性。

流行っている・流行っていないプログラミング言語に関する1つの考察

另外,使用 MCZ 是传统的包管理,代码复用很困难,比如仓库服务器不堪重负,依赖解析不起作用(需要手动解决)。然后我就想着用一个库作为爱好,也有类似的故事,不过和 Lisp 的故事是一样的,因为很少有包管理,所以不知道可以用什么样的库。我什至不知道如何安装它。这就是 Smalltalk 发生的事情。

另一种经典的语言和代码可重用性是维基百科的外壳脚本列有以下描述:

还有跨平台兼容性问题。 Perl 的作者 Larry Wall 有句名言:“移植 shell 本身比移植 shell 脚本更容易。”

如您所见,经典语言 shell 脚本难以移植(≈ 可重用性低)。
(不过英文维基百科上并没有参考,所以Larry Wall是否真的说过是值得怀疑的。)

互联网和编程语言

使用当今的技术,创建 Lisp 非常容易。我,用 Python 编写的 Lisp 解释器一天之内就完成了。
你可以在 Smalltalk 中这样说,“吹嘘不使用 Smalltalk”幻灯片中指出。

流行っている・流行っていないプログラミング言語に関する1つの考察

在 Smalltalk 的情况下,只有五个保留字,nil、true、false、self 和 super,而在 Lisp 的情况下,所有的语法结构都是 S 表达式,只有大约 20 个保留字(包括 SpecialForms)是。 (纯 LISP 大约 9)
所以基础很容易制作。像这样门槛低的话,处理系统就会蜂拥而至,相互处理系统的兼容性就会很困难。
此外,在小型实现中针对短代码时,模块独立性不像现在那么严格,命名空间和包装等概念往往很弱。这方面也类似于与环境紧密耦合的shell脚本移植性差的问题。

然而,随着互联网的出现,源代码的流动性急剧增加,对易于复用的模块提出了需求。因此,在互联网时代之前设计的编程语言,模块的复用性低,无法在互联网时代发挥积极作用。结果,没有创建包管理系统(它也是一门最初不适合创建包管理的编程语言),并且退出了主流。另一方面,在互联网之后设计的编程语言被设计成模块的高复用性,因此创建了包管理系统,实现了与互联网的共同发展。你可以这样说。我想。

然而,这个理论并不能解释所有的编程语言,尽管缺乏主要语言的包管理系统,但仍然使用 C/C++ 语言。一种理论是apt、yum等负责包管理。你不能这么说吗?有一个地方。

概括

  • 互联网前编程语言
    • 规范本身很简单,处理系统容易不堪重负。
    • 由于流动性低,我自己写的比例很高。因此,首选与环境紧密耦合且编写速度快的编程语言。
    • 模块可重用性低。
  • Internet 的普及增加了源代码的流动性。
  • 使用其他人制造的模块的社会压力已经增加。
  • 编程语言模块的可重用性变得很重要。
  • 互联网普及后的编程语言是
    • 设计时强调模块的可重用性。
    • 互联网使图书馆可用。
    • 通常用于包管理系统。

所以,

自互联网出现以来,是否已经设计了编程语言?
= 编程语言中模块的可重用性和独立性是否得到维护?

然而,这不就是现在的“流行和冷门编程语言之间的分界线”吗?这是假设。

想法

过去,我参与了一个私人维护 npm 注册表的项目。在那个时候,公共 npm 注册表中的模块和私有 npm 注册表中的模块共存是一种麻烦。我有一个想法。我已经不太记得这个过程了,但我记得有必要摆弄 npm 配置,而且我无法用单一的 npm install 感觉安装它。这可能是因为 npm 的模块管理设计是集中式的,并且一开始并不真正针对分散式管理。我想。
我自己是在 2017 年左右开始接触 Go 的,但一开始包管理是 glide,然后是 dep,最后确定了当前标准的 go mod,但 Go That 是一个相当形象(虽然我不知道细节)这里有许多波折。在这种情况下,Go 最终选择的样式是 import "github.com/gin-gonic/gin" 这样的设计,我开始认为库本身的管理是分散的。
最近,由于互联网,人们的行为发生了变化。有一个方面,但我想知道它是否也在编程语言的设计中。这是我认为的一项调查。


原创声明:本文系作者授权爱码网发表,未经许可,不得转载;

原文地址:https://www.likecs.com/show-308623262.html

相关文章:

  • 2021-09-26
  • 2021-05-05
  • 2022-01-18
  • 2021-11-06
  • 2022-12-23
  • 2021-05-26
猜你喜欢
  • 2021-12-24
  • 2021-06-08
  • 2021-09-12
  • 2021-08-16
  • 2021-09-21
  • 2022-12-23
  • 2021-11-30
相关资源
相似解决方案