代码之家 › 专栏 › 技术社区 › Serafina Brocious

什么时候一门新语言才是适合这份工作的工具?

nemerle boo

Serafina Brocious · 技术社区 · 16 年前

很长一段时间以来,我一直在尝试不同的语言来找到我想要的功能集,但我一直找不到它。我有适合我的各种项目的语言,但我已经想出了这些语言的交集,允许我用一种语言完成99.9%的项目。我想要以下内容:

构建在.NET之上或具有.NET实现
在编译时和运行时对.NET运行时几乎没有依赖性(这一点很重要,因为其中一个主要用例是在嵌入式开发中,.NET运行时是完全自定义的)
有一个编译器为100%.NET代码,没有非托管依赖项
支持任意表达式嵌套(见下文)
支持自定义运算符定义
支持类型推理
优化尾调用
有明确的不变/可变的定义(很好——我喜欢这个,但没有它也能活下去)
支持用于强元编程的实际宏(绝对必须具有)

我使用过的主要两种语言是boo和nemerle,但我也使用过f_。

对Nemerle的主要抱怨是:编译器有可怕的错误报告,实现像地狱一样有缺陷(编译器和库),宏只能在函数内部或作为属性应用,而且依赖关系相当重(尽管还不足以破坏它)。
主要抱怨boo:没有任意表达式嵌套(dealbreaker),宏很难编写,没有自定义的操作符定义(潜在的dealbreaker)。
主要投诉F:语法不好,元编程难以理解,非免费许可证(Epic Dealbreaker)。

所以我越想,就越想发展自己的语言。

赞成的意见:

得到我想要的确切语法
得到一个周转时间,这将是一个非常快的速度;难以量化,但我不会惊讶地看到1.5倍的开发人员生产力,特别是由于测试基础设施,这可以使某些项目。
我可以很容易地将自定义功能添加到编译器中,以很好地使用我的运行时。
我得到了设计和工作的东西 确切地 我想要的方式——尽管这听起来像NIH,但这会让我的生活更轻松

欺骗:

除非它能得到普及,否则我将不得不承担维护的负担。我知道我至少可以让尼默尔人过来,因为我认为每个人都想要更专业的东西,但这需要一个村庄。
由于第一个骗局,我对在专业场合使用它很谨慎。也就是说,我已经在使用Nemerle并使用我自己的自定义修改编译器,因为它们根本没有很好地维护它。
如果它不受欢迎,那么寻找开发人员将更加困难,在某种程度上 Paul Graham 甚至不会宽恕。

因此,基于所有这些,一般的共识是什么——这是一个好主意还是一个坏主意?也许更有用的是,我错过了什么大的利弊吗?

编辑:忘记添加嵌套示例——下面是Nemerle中的一个例子:

def foo = 
    if(bar == 5)
        match(baz) { | "foo" => 1 | _ => 0 }
    else bar;

edit 2:假设代码存在,那么给出一个代码类型的例子是可以转换成这种语言的(仅S.Lott的答案就足以吓跑我不去做这件事)。该代码大量使用自定义语法(opcode、:=、QuoteBlock等)、表达式嵌套等。您可以在这里查看一个很好的示例: here .

10 回复 | 直到 12 年前

S.Lott 16 年前

不幸的是,没有关于失败语言的度量标准或故事。只是成功的语言。显然,失败的次数超过成功的次数。

这是基于什么?两个共同的经历。

一年一两次,我不得不忍受一个产品/语言/工具/框架的推销,它将彻底改变一切。我的答案在过去的20多年里一直是不变的。给我看一个需要支持的人,我的公司会支持他们的。就是这样。再也没有他们的消息了。比如说,我听说过25个。
每年有一两次,我必须与一个孤立技术的客户合作。在过去的某个时刻,一些聪明的编程人员构建了一个工具/框架/库/包,该工具/框架/库/包在内部用于多个项目。然后那个程序员走了。没有其他人能搞清楚这件事,他们希望我们替换/重写它。可悲的是,我们也弄不清楚,我们的建议是从头重写。他们抱怨说,他们的天才在几周内建立了一套应用程序,在Java/Python/VB/C语言中,我们不需要花上几个月的时间来重写这些应用程序。假设我已经写了大约25个这样的建议。

只有我一个顾问。

事实上,一个特别令人遗憾的情况是,一家公司的整个IT软件组合都是由一个聪明人用一种私人语言和工具编写的。他没有离开,但他已经意识到他的语言和工具已经落后于时代了——艺术的发展,他没有离开。

当然,这是一个意想不到的方向。他的语言和工具还可以,但世界已经开始采用关系数据库,而且他完全没有办法升级他的垃圾文件以摆脱平面文件。这是他没有预见到的。事实上,这是他不可能预见到的。[你不会掉进这个陷阱的,是吗?]

所以,我们谈过了。他用普通的旧vax fortran重新编写了很多应用程序(是的,这是很久以前的事了),并重新编写它以使用普通的旧关系SQL(当时是Ingres)。

经过一年的编码,他们的性能出现了问题。他们打电话给我,让我回顾一下他们在替换自制语言方面所做的一切。不幸的是,他们做了最糟糕的关系数据库设计。最坏的可能。他们把文件复制、合并、排序等等,然后使用SQL实现每个低级文件系统操作,复制左侧、右侧和中间的数据库行。

他陷入了对完美语言的个人幻想之中,以至于无法适应一种相对普遍、普遍的新技术。

nlaq 16 年前

我说去吧。

不管天气如何,这将是一次很棒的体验。
如果您使它编译到IL,那么您就不必担心不能用C重新使用已编译的程序集。#
如果你相信你对以上列出的语言有合理的抱怨,那么很可能很多人会像你一样思考。当然,对于每1000个感兴趣的人,可能会有1个人愿意帮助你维护它——但这总是风险所在。

但有几点需要注意:

在开发之前,先在Stone中获取您的语言规范。确保所有的语言功能都是在动手之前就解决的——即使是你将来可能只想要的东西。在我看来,C正慢慢陷入“哦,再多一个语言扩展”的陷阱,这将导致其最终的厄运。
一定要优化它。我不知道你已经知道了什么;但是如果你不知道,那就学习;)没有人会想要一种语法很好但运行速度和IE的javascript实现一样慢的语言。

好运:D

17 of 26 16 年前

当我在90年代初开始我的职业生涯时,似乎每个人都在开发自己的内部语言。我的第一个三这些工作都是在做这件事的公司中完成的。一家公司甚至开发了自己的操作系统!

根据经验,我认为这是个坏主意,原因如下:

1)除了基于语言本身的代码之外,您还将花时间调试语言本身。
2)您雇佣的任何开发人员都需要通过语言的学习曲线。
3)很难吸引和留住开发人员,因为使用专有语言工作是某人职业生涯的死胡同。

我离开这三个职位的主要原因是因为他们有专有的语言,你会注意到没有多少公司会走这条路。

另一个我会提出的论点是,大多数语言都有整个团队,他们的全职工作就是开发语言。也许你会是一个例外,但是如果你能通过兼职的语言工作来达到这种发展水平,我会非常惊讶的。

NN_ 13 年前

对Nemerle的主要投诉: 编译器有可怕的错误报告, 这个实现是错误的。 (编译器和库),宏只能应用于函数内部或者作为属性,这是公平的严重依赖(尽管不是足以让它成为交易破坏者)。

我看你的文章两年多前就写好了。我建议你今天试试尼默尔语。编译器是稳定的。今天没有阻止程序错误。 vs集成有很多改进,也有夏普开发集成。

如果你给它一个机会,你不会失望的。

Marcin 16 年前

永远不要发展自己的语言。

开发自己的语言是一个愚蠢的陷阱,更糟糕的是,它会限制你的想象力所能提供的东西,同时要求你同时制定出自己的开发环境和正在编写的实际程序。

如果你是拉里·沃尔(Larry Wall)、awk的人,或者是致力于测试编程边界的大量人员的一部分,那么这种情况就不太适用了。如果你属于这些类别中的任何一个,你不需要我的建议,但我强烈怀疑你的目标是一个没有适合任务的编程语言和完成任务的人的特点的利基。

Vinko Vrsalovic 16 年前

如果你和你看起来一样聪明(很可能),我的建议是先做语言的设计,在上面重复几次,问一些你信任的智能编程语言相关社区的聪明人关于你提出的具体设计,然后做出决定。

例如,在创建设计的过程中,您可能会意识到,只要对Nemerle进行一次快速的黑客攻击,就可以满足您的所有需求。很多事情都可以在认真考虑一个问题时发生,最终的解决方案可能不是您在开始项目时真正想到的。

最坏的情况是,你会坚持实际实现设计,但到那时,你会让它经过验证、阅读和成熟,并且你会非常确定这是一条很好的道路。

一条相关的建议,从小处入手,只需定义您绝对需要的特性,然后在它们的基础上进行构建,以获得其余的特性。

dbr 16 年前

写你自己的语言不是一个容易的项目。尤其是在任何一种“专业环境”中使用。

这是一个 巨大的 大量的工作,我怀疑你是否能写出你自己的语言,是否还能写出任何使用它的大项目——你将花费很长时间来添加你需要的功能,修复错误,以及通用语言设计。

我愿意 强烈地 建议您选择一种最接近您想要的语言,并扩展它以满足您的需要。这永远不会是你想要的,但是与你花在写自己的语言上的时间相比,我认为这是一个小小的妥协。

John Nilsson 16 年前

scala有一个.NET编译器。但我不知道这件事的情况。它是scala世界中的二等公民(更关注于JVM)。但是,采用.NET编译器而不是从头开始创建一种新语言可能是一个很好的交易。

scala在元编程部门atm中有点弱。元编程的需求可能会因为其他语言特性而有所减少。在任何情况下,我不认为任何人会难过,如果你要实现它的元编程特性。此外,还有一个编译器插件基础设施正在开发中。

leppie 16 年前

我认为大多数语言永远不适合所有的账单。

你可能想结合你最喜欢的两种语言(在我的例子中是c和 Scheme )一起使用。

从专业的角度来看,这可能不是一个好主意。

sepang 16 年前

听到一些你觉得用现有语言做不到的事情会很有趣。你在做什么样的项目不能在C中完成?

我只是古玩!