在我看来,函数式编程是一件很好的事情。它消除了状态,并使得代码在并行运行时更容易自动化。
许多最初学习命令式编程风格的程序员发现学习函数式编程非常困难,因为它非常不同。我开始想知道,如果程序员最先学习函数式编程,会不会很难开始学习命令式编程。这似乎不会像另一种方式那样难,所以我认为如果更多的程序员最先学习函数式编程,那就是一件好事。
那么,我的问题是,应该在学校首先教授函数式编程而不是命令式编程,如果是这样,为什么开始使用它不更常见?
在我看来,函数式编程是一件很好的事情。它消除了状态,并使得代码在并行运行时更容易自动化。
许多最初学习命令式编程风格的程序员发现学习函数式编程非常困难,因为它非常不同。我开始想知道,如果程序员最先学习函数式编程,会不会很难开始学习命令式编程。这似乎不会像另一种方式那样难,所以我认为如果更多的程序员最先学习函数式编程,那就是一件好事。
那么,我的问题是,应该在学校首先教授函数式编程而不是命令式编程,如果是这样,为什么开始使用它不更常见?
实际上,一些学校已经采取了这种方式。在我的学校 (哥本哈根大学),他们在第一个学期里先教授SML作为编程入门,然后再教授Java作为面向对象编程入门。
我认为这种方式非常有效,而且我同意你的观点,这比反过来学习更好。 对于那些不是程序员的人来说,函数式编程相当直观。它与我们在高中或之前所学的数学更加契合,因此那些尚未接触命令式编程的人通常可以轻松掌握。
事实上,有一个趋势是,那些刚开始学习编程的人比那些已经学习了Java或C ++的人更快地学会了SML。
大多数函数式语言的开发环境较差,需要广泛的编程知识才能使用。虽然这种情况正在变得越来越不成立,但我们离Haskell的Visual Studio还有很远的路要走。
对于大多数函数式语言而言,GUI工具包和库都较差。在屏幕上显示内容并奖励学生非常重要,因为这可以吸引他们的注意力。
自学编程者出于历史原因倾向于选择命令式/OO语言。这是因为在他们年少时BASIC语言很流行,在他们青少年时代最喜欢的游戏可能是用C或C++编写的等等。
函数式编程语言的简单资源和教程难以获得。比较一下Code Project上C#示例与Lisp���例的数量即可看出:请记住,Lisp已经存在了5倍以上的时间。
可能存在一种心智份额问题,因为大多数教师/教授可能也是先学习了命令式编程风格。
此外,我猜想有更丰富的可用于教授命令式编程风格的工具。
我只能假设这是因为面向对象编程似乎是一个受欢迎的流行词/风格,所以学校坚持使用它。
我从一开始就学习了面向对象设计,最近我自学了函数式编程风格,我可以看到它有其优势。
编辑:下面的内容反映了原标题,"为什么函数式编程不在学校教授",学校有老师,没有教授。学校老师不会自己编写教科书。
老师们可以购买教材的教科书公司是最大的问题所在。这些教科书公司往往追捧“下一个大事”,几年前是面向对象编程(OOP)。函数式编程已经被忽视了。许多老师不能或者不允许在没有教科书的情况下教授课程,因此课程选择通常遵循来自大型供应商的教科书的可用性。
命令式编程的清晰控制流非常适合在教学环境中实现和分析算法。面向对象编程是对此的方便扩展,因此自然而然地被最常使用。另一方面,函数式编程(任何类型的声明式编程)是一个完全独立的范式,需要一整套新的考虑因素(包括性能等),其中许多更容易通过先理解命令式编程来进行可视化。毕竟,最终归结为一种命令式语言。
对于学校的课程来说,这必须有一个历史角度(显露了我的年龄)。当我开始学习时,只需要学习函数式编程。
但是抛开这个不谈,你必须从某个地方开始,所以其中之一必须是第一个。如果你从命令式开始,那么在学习函数式时会发现有些东西不在那里,你必须习惯以不同的方式进行操作。如果你从函数式开始,然后转向命令式,你将需要习惯学习新的概念/结构,并记住它们的使用方法。
无论何时进行编程,你都在尝试解决一个问题。拥有两者作为工具箱中的选择,可以更好地解决手头的问题。这就是为什么我认为最好从命令式开始,然后再学习函数式:如果你发现自己需要的东西不在那里,那就意味着选择了错误的工具来解决问题。
除此之外,我认为这是一个难以决定的问题。
我刚参加了一个由Bootstrap的开发者(一份目前由公民学校运营的编程课程)主持的演讲。他似乎认为函数式编程风格为代数提供了更好的背景,因为它涉及到函数作为过程和对象的概念(具有自己的属性)。当然,声明式编程语言也可以拥有一级函数,但重点并不在于此。
个人认为先教授函数式编程是值得的。声明式方法在数学课上就很早被教授了,所以函数式编程提供了一些声明式编程所没有的新概念。我同意以上帖子中许多人的观点,即“太难”的说法是个误解,已经被证明是可以做到的。