教学编程和形式方法

Question

这是一个奇怪的问题。我正在编写一本关于学习使用正式方法编程的书，我将把它定位到具有一些编程经验的人。我们的想法是让他们成为高素质的程序员。

基本符号将来自Dijkstra的Discipline of Programming，以及一些并发和通信扩展。

与EWD不同，我希望我的学生最终能够编写实际的可执行程序。这意味着在某些时候从EWD符号转换为其他语言。当我第一次开始正式编程时，我以C为目标，但你最终编写了大量的管道，加上处理指针的所有复杂性等.Ruby是一个明显可能的目标，如Scheme或Lisp。但也有各种函数语言;因为我对并发性特别感兴趣，所以Erlang似乎是一种可能性。

所以，最后，我的问题是：我应该用什么语言教我的读者定位他们正式开发的程序？

Answer 1

查理，

我一直将Dijkstra的杰作与编程模型联系起来，其中中心阶段由循环和数组占据。如果你坚持靠近Dijkstra（例如，计算最弱的前提条件），我认为你会发现函数式语言并不适合。在为循环和数组的命令式编程提供良好支持的流行语言中，Python可能带来最少的额外包袱。

这并不是说功能语言不适合正式方法 - 它们非常适合 - 但风格与Dijkstra完全不同。首选方法强调计算证明;请参阅理查德·伯德关于解决数独（这是沉重的事情）的论文或理查德·伯德和菲尔·瓦德勒的教科书。

对于并发性，它很大程度上依赖于你所信仰的并发模型（以及正式方法）.John Reppy的Concurrent ML是一个漂亮的消息传递模型。 Erlang也有一个很好的清洁限制模型。另一方面，使用锁和关键部分进行编程非常困难，在这种情况下，正式方法可能会带来更多好处。

可能对您的背景研究感兴趣的另外两个及时的评论：

• 我见过的唯一一位将Dijkstra的方法应用于实际系统的程序员是Greg Nelson，他在Modula-3工作。 （Greg和Mark Manasse一起写了Trestle窗口系统。） Modula-3是一种非常好的语言，Digital可以通过无耻和无能而死。 Greg有一篇关于Dijkstra微积分扩展的TOPLAS论文。

• Gerard Holzmann的建模语言SPIN直接基于Dijkstra的保护命令语言，它还支持并发。它的目的是模型检查，而不是编程，并且有一些特性，但与正式方法有很强的联系，能够模拟检查断言真的很棒。任何对正式方法感兴趣的人都想查看一下。

（编辑：这是Greg Nelson论文的链接，或者其中之一。 - CRM）

Answer 2

忽略明显的favorite programming language答案，我可以看到两个有用的答案：

一方面，您正在尝试演示假定为中级程序员的方法。如果您选择一种语言并将其作为您的书籍语言加以保护，您可能会疏远那些因某种原因而不喜欢该语言的潜在读者。由于您正在演示方法，因此您可以在语言中使用片段，这些语言恰好可以简明扼要地说明您的观点。例如，可用于演示RIIA的唯一语言可能是C ++，但是这种语言在展示如何执行源分析方面相当差。 Scheme是源分析的理想选择，但是没有为您提供很多选项来探索强类型的好处（和弱点）。使用多种语言。

另一方面，由于你主要是编程方法，我不完全确定你需要任何真正的语言。一个定义明确的符号同样好，并且强迫您的读者专注于您正在制作的点，而不是一种语言或其他语言的表面细节。

Answer 3

我在Lisp和Scheme上长大并且非常喜欢他们。我认为它们是从头开始学习的优秀语言。但是，我不确定有某些编程经验的人会采用这些语言。在标题中使用Scheme，你不会在亚马逊上获得大量的点击。 ：）

C＃是一门非常容易学习的语言，它具有您需要的所有基础知识，可以很快地深入了解并发等主题。它具有更多适用性，因为您也可以定位OO和Web概念。它也相当受欢迎，你会让公司为他们的员工支付总是有利于销售的书籍（“Be a Kick Ass C＃Programmer”在费用报销表上远远超过“现代Lisp中的并发”）。

F＃是一种有趣的语言。它具有Lisp或Scheme的功能之美（不是很好，但差不多），并且它为您提供了一些潜入OOP主题的能力，以及如果您想要提高性能，还可以使用.NET框架来获取UI内容。但是，现在，这是模糊不清的。

我不能和Ruby说话，所以我个人会咬紧牙关和C＃一起去。

Answer 4

老实说，我不能推荐Ruby。当我在商业世界中日常编程时，我非常喜欢它，当然比C或Java更多。但它的语义是如此不明确，以至于我不相信C的一半，尽管我可能花了几个小时争论一个声明，并咨询更厚的白皮书取代K＆amp; R，我出来了最后我相信如果我有一个符合标准的编译器（是的，我知道，我是一个梦想家，但在这里和我一起工作）我知道另一方面会发生什么。

Ruby在许多方面都很精彩，但就任何形式而言，twain永远不会满足。

我倾向于亲自投票支持Haskell，因为每次我转身时，我都惊讶于语言定义中所有内容的含义。 （虽然只有一年左右的时间，但我确信我甚至没有探索过Haskell 98的一半角落。）

我也理解Dikjstra与功能性的东西;回去和reading his papers他非常关注一个势在必行的世界;我没资格说他是否真的走错了路。也许我对他的写作有多么不满，就像他的想法一样。但它确实让他满意，那么使用Algol 60呢？

Answer 5

这是一个好主意。 我认为Scheme是一个很好的选择，因为它允许一个人实现（以库的形式）不同的抽象与最基本的必需品。 从方案转换为PVS（http://pvs.csl.sri.com/）

等验证系统也很容易

欢呼声

Answer 6

我认为你应该对自己用于本书的语言或熟练检查代码的人有一定的经验。

就个人而言，我使用Common Lisp，因为我熟悉它，它是实现任何概念的一种很好的语言。其他选项可能是Erlang，Haskell，Ruby或Python，甚至可能是一些ML方言。我对C系列（包括C＃和Java）有偏见，他们似乎坚持对概念的低级思考。

Answer 7

有不少大学使用Perfect Developer来教授正式方法（免责声明：我与此产品有关）。它围绕用于表达规范，数据细化和算法的语言构建。它有一个用于验证的自动定理证明器，以及一个可以生成C ++，C＃和Java的代码生成器。 PD的设计很大程度上受到“编程规则”的启发，然而我们发现这种符号对于大型系统来说相当不切实际，因此符号与Dijktra的分歧有所不同。