差异&编程范式之间的相似之处
过去 4 年我一直从事开发人员工作，之前的 4 年是在大学学习软件开发。在我从事这个行业的 4 年里，我用 VB6 做了一些工作（这是一个笑话），但大部分都是用 C#/ASP.NET 完成的。在此期间，我已经从“对象感知”过程范例转向面向对象范例。
最近，我对其他编程范例感到好奇，所以我想我应该向其他开发人员询问他们对相似性和相似性的看法。这些范式之间的差异，特别是 OOP 之间的差异？在面向对象编程中，我发现非常关注概念之间的关系和逻辑交互。对于其他范式，你必须采用什么思维框架？
I've been working as a developer for the past 4 years, with the 4 years previous to that studying software development in college. In my 4 years in the industry I've done some work in VB6 (which was a joke), but most of it has been in C#/ASP.NET. During this time, I've moved from an "object-aware" procedural paradigm to an object-oriented paradigm.
Lately I've been curious about other programming paradigms out there, so I thought I'd ask other developers their opinions on the similarities & differences between these paradigms, specifically to OOP? In OOP, I find that there's a strong focus on the relationships and logical interactions between concepts. What are the mind frames you have to be in for the other paradigms?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
迄今为止，对编程范式的最佳解释可以在 Peter van Roy 的著作中找到。特别是在计算机编程的概念、技术和模型一书中作者：Peter Van Roy 和 Seif Haridi。 （这是配套 wiki。）CTM 使用 多范式分布式Oz编程语言介绍所有主要的编程范式。
Peter van Roy 还制作了这张令人惊叹的海报，展示了 34 个主要范式及其关系和立场各种轴。这张海报基本上是 CTM 的一个令人难以置信的压缩版本。对该海报的更全面解释包含在文章傻瓜式编程范式：每个程序员都知道的内容中《应该知道》 作为 G. Assayag 和 A. Gerzso 编辑的《计算机音乐的新计算范式》一书的一章出现。
另一本演示了几种主要编程范例的好书是 计算机程序的结构和解释，作者：Harold Abelson 和 Gerald Jay Sussman。几十年来，本书一直是 MIT CS101 的基础。 由 Abelson 和 Sussman 亲自教授的课程在 Hewlett 的企业培训中录制-帕卡德，1986 年。
CTM 和 SICP 之间的主要区别在于，CTM 使用支持它们的语言（主要是 Distributed Oz，但也有一些其他语言）演示了大多数主要范例。 SICP OTOH 通过使用本身不支持它们的语言（Scheme 的子集）实现来演示它们。看到用十几行代码实现面向对象真是太棒了。
您可以找到视频录制和课程材料来自麻省理工学院 OpenCourseWare 网站上的 2005 年春季课程。 麻省理工学院短暂的 ArsDigita 大学项目的另一段课程录音。 SICP 也在其他大学教授，事实上它正在伯克利教授现在。
就我个人而言，我自己的经验是，真正理解一种编程范式
，理想情况下，您将使用一种将范式发挥到极致的语言。在多范式语言中，很容易“欺骗”并退回到您更熟悉的范式。并且只有在像Scheme这样专门为这种编程设计的语言中才真正可能使用范式作为库。例如，学习 Java 中的惰性函数式编程并不是一个好主意，尽管有相关的库。
以下是我最喜欢的一些内容：
By far the best explanations of programming paradigms are found in Peter van Roy's works. Especially in the book Concepts, Techniques, and Models of Computer Programming by Peter Van Roy and Seif Haridi. (Here's the companion wiki.) CTM uses the multi-paradigm Distributed Oz programming language to introduce all the major programming paradigms.
Peter van Roy also made this amazing poster that shows the 34 major paradigms and their relations and positions on various axis. The poster is basically an incredibly compressed version of CTM. A more thorough explanation of that poster is contained in the article Programming Paradigms for Dummies: What Every Programmer Should Know which appeared as a chapter in the book New Computational Paradigms for Computer Music, edited by G. Assayag and A. Gerzso.
Another great book that demonstrates several major programming paradigms is Structure and Interpretation of Computer Programs by Harold Abelson and Gerald Jay Sussman. This book was the basis of MIT's CS101 for several decades. A course taught by Abelson and Sussman themselves was recorded at a corporate training for Hewlett-Packard in 1986.
The main difference between CTM and SICP is that CTM demonstrates most major paradigms using a language that supports them (mostly Distributed Oz, but also some others). SICP OTOH demonstrates them by implementing them in a language that does not support them natively (a subset of Scheme). Seeing Object-Orientation implemented in a dozen or so lines of code is friggin' awesome.
You can find video recordings and course materials from the Spring 2005 course on MIT's OpenCourseWare website. Another recording of the course from MIT's short-lived ArsDigita University project. SICP has also been taught at other universities, in fact it is being taught at Berkley right now.
On a personal note, my own experience has been that really understanding a programming paradigm is only possible
Ideally, you would use a language which takes the paradigm to the extreme. In multi-paradigm languages, it is much too easy to "cheat" and fall back on a paradigm that you are more comfortable with. And using a paradigm as a library is only really possible in languages like Scheme which are specifically designed for this kind of programming. Learning lazy functional programming in Java, for example, is not a good idea, although there are libraries for that.
Here's some of my favorites:
我的看法是：
Here's my take:
好吧此链接试图解释我过去使用过的东西二十年。
我提到它是因为它被证明是有用的，而且我认为它可以作为一个范例，因为要使用它，你需要以特定的方式思考。
你必须思考的不同方式是，在分析问题时，你不是问存在什么对象以及发生什么操作，而是从整体需求开始，然后问需要说什么？
，您选择或设计一种特定于领域的语言（DSL），并用该语言陈述您的问题。
该链接解释了一种用于描述动态变化的对话框用户界面的特定语言。它的实现取决于特定的控制结构，即差分执行。它所实现的是源代码数量级的减少，编码错误的可能性也更少。这些节省下来的钱可以用来让用户界面变得更加复杂。
对于其他类型的问题，其他控制结构也是合适的，但通过精心选择的 DSL 工作的概念是常见的方法，使源代码更小、更容易修改、更不容易出错。
我认为函数式编程和面向对象编程的范式最好通过确定它们最能表达的问题类型来评估。通常这些范式只是成为潮流并被吹捧为包治百病的灵丹妙药，而不是根据它们解决的问题空间对它们进行分类。
Well this link tries to explain something I've used over the last two decades.
I mention it because it's provably useful and I think it counts as a paradigm, because to use it you need to think in a particular way.
The different way you have to think is that when analyzing a problem, rather than asking what objects there are and what actions take place, you start with the overall requirements and ask What Needs to be Said?
From that, you choose or design a domain-specific-language (DSL), and state your problem in that language.
That link explains a particular language for describing dynamically changing dialog user interfaces. Its implementation depends on a particular control structure, Differential Execution. What it accomplishes is an order of magnitude reduction in source code, with fewer chances for coding errors. Those savings can then be spent in making the UI more sophisticated.
For other kinds of problems, other control structures are appropriate, but the concept of working through a well-chosen DSL, making source code much smaller, more easily modified, and less error-prone, is the common approach.
I think the paradigms of functional programming and OOP are best evaluated by identifying the types of problems for which they are the best expression. Often these paradigms simply become bandwagons and are touted as cure-alls, rather than classifying them by the problem spaces they address.