gpt4 book ai didi

boo - 什么时候一种新语言是适合这项工作的工具?

转载 作者:行者123 更新时间:2023-12-03 21:04:54 24 4
gpt4 key购买 nike

很长一段时间以来,我一直在尝试不同的语言来找到我想要的功能集,但我一直无法找到它。我的语言非常适合我的各种项目,但我提出了这些语言的交集,这将使我能够用一种语言完成 99.9% 的项目。我想要以下内容:

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

  • 我主要使用的两种语言是 Boo 和 Nemerle,但我也使用过 F#。

    对 Nemerle 的主要提示:编译器有可怕的错误报告,实现是 hell 般的错误(编译器和库),宏只能在函数内部或作为属性应用,并且依赖关系相当严重(尽管还不够破坏者)。
    对 Boo 的主要提示:没有任意表达式嵌套(dealbreaker),宏难以编写,没有自定义运算符定义(潜在的 dealbreaker)。
    对 F# 的主要提示:难看的语法、难以理解的元编程、非自由许可证(史诗般的交易破坏者)。

    所以我想得越多,我就越想开发自己的语言。

    优点:
  • 得到我想要的确切语法
  • 获得更快的周转时间;很难量化,但看到 1.5 倍的开发人员生产力我不会感到惊讶,特别是由于测试基础设施可以为某些项目启用
  • 我可以轻松地向编译器添加自定义功能,以便与我的运行时完美配合
  • 我得到了完全按照我想要的方式设计和工作的东西——尽管这听起来像 NIH,但这会让我的生活更轻松

  • 缺点:
  • 除非它能够流行起来,否则我将被维护的负担所困。我知道我至少可以让 Nemerle 人过来,因为我认为每个人都想要更专业的东西,但这需要一个村庄。
  • 由于第一个骗局,我对在专业环境中使用它持谨慎态度。也就是说,我已经在使用 Nemerle 并使用我自己的自定义修改编译器,因为他们根本没有很好地维护它。
  • 如果它没有得到普及,寻找开发者将变得更加困难,以至于 Paul Graham甚至可能不会宽恕。

  • 所以基于所有这些,普遍的共识是什么——这是一个好主意还是一个坏主意?也许更有帮助的是,我是否错过了任何重大的利弊?

    编辑:忘记添加嵌套示例——这是 Nemerle 的一个案例:
    def foo = 
    if(bar == 5)
    match(baz) { | "foo" => 1 | _ => 0 }
    else bar;

    编辑#2:认为如果存在将转换为这种语言的代码类型的示例,这不会有什么坏处(仅 S. Lott 的回答可能足以吓跑我不要这样做)。该代码大量使用了自定义语法(操作码、:=、quoteblock 等)、表达式嵌套等。您可以在此处查看一个很好的示例: here .

    最佳答案

    可悲的是,没有关于失败语言的指标或故事。只是成功的语言。显然,失败的次数多于成功的次数。

    我有什么依据?两个共同的经历。

  • 一年一次或两次,我必须忍受一个绝对改变一切的产品/语言/工具/框架的推销。在过去 20 年左右的时间里,我的回答一直保持不变。告诉我需要支持的人,我的公司会支持他们。就是这样。再也不会收到他们的消息了。假设我已经听过其中的 25 个。
  • 每年一次或两次,我必须与一个拥有孤儿技术的客户一起工作。在过去的某个时候,一些聪明的编程构建了一个工具/框架/库/包,在内部用于多个项目。然后那个程序员离开了。没有人能弄清楚那该死的东西,他们希望我们替换/重写它。可悲的是,我们也无法弄清楚,我们的建议是从头开始重写。他们提示说,他们的天才在几周内就构建了一组应用程序,我们用 Java/Python/VB/C# 重写它们不能花费我们几个月的时间。假设我已经写了 25 个左右的此类提案。

  • 那只是我,一位顾问。

    确实,一个特别悲哀的情况是,一家公司的整个 IT 软件组合都是由一个聪明人编写的,他使用私有(private)语言和工具。他没有离开,但他意识到他的语言和工具集已经远远落后于时代——最先进的技术已经在进步,而他没有。

    而这一举动——当然——是在一个意想不到的方向上。他的语言和工具还可以,但世界已经开始采用关系数据库,他绝对没有办法升级他的垃圾以远离平面文件。这是他没有预料到的。的确,这是他无法预料的事情。 【你不会掉进这个陷阱吧?】

    所以,我们谈了。他用 Plain-Old VAX Fortran 重写了很多应用程序(是的,这是很久以前的事了。)他重写了它以使用简单的老式关系 SQL 东西(当时是 Ingres。)

    经过一年的编码,他们遇到了性能问题。他们调用我,回顾他们在替换自制语言方面所做的所有伟大工作。可悲的是,他们做了最糟糕的关系数据库设计。最坏的可能。他们进行了文件复制、合并、排序等等,并使用 SQL 实现了每个低级文件系统操作,将数据库行左、右和中心复制。

    他深陷于自己对完美语言的私有(private)愿景中,无法适应一种相对普遍、无处不在的新技术。

    关于boo - 什么时候一种新语言是适合这项工作的工具?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/193941/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com