问题标签 [paradigms]

我想创建不同类型的流程，在这些流程中，代理相互交互。我想用一种特殊的语言来描述（定义、形式化）代理之间的交互过程。换句话说，我想提供一个代理可以以某种方式相互交互的环境，并且我想使用适合这种方式的编程语言来描述交互方式。有这样的语言吗？

为了更具体和不那么抽象，我们可以将代理视为网站的用户。网站的发展取决于用户的行动（用户有一定的行动自由）。用户可以做什么以及他们的行为会发生什么应该用语言来描述。

我一次又一次地听到这个，我试图理解和验证 FP 和 OO 是正交的想法。

首先，两个概念正交是什么意思？

FP 尽可能鼓励不变性和纯洁性，而 OO 似乎是为状态和突变而构建的——命令式编程的稍微组织化的版本？我意识到对象可以是不可变的，但 OO 似乎暗示着我的状态/改变。

他们似乎是对立的。这如何影响它们的正交性？

像 Scala 这样的语言可以很容易地同时进行 OO 和 FP，这会影响这两种方法的正交性吗？

我有一个函数，我需要为我调用的另一个程序生成不同的输出字符串，具体取决于它想要的类型。

基本上，被调用的程序需要一个命令行参数来告诉它调用的类型。

很高兴我在 SO 上找到了关于如何检查变量类型的答案。但我注意到人们也提出了反对意见，即检查类型背叛了“非面向对象”的设计。那么，是否有其他方式，可以推测为更“面向对象”的方式来处理此问题而无需显式检查类型？

我现在的代码是这样的：

效果很好，但我只是想知道是否有一些我不知道的技术。

我不是语言专家，但我最近开始研究语言并试图了解主要概念和“他们的”语言。这类似于关于书籍的另一个问题。那么首先，主要的编程语言概念是什么，例如

• 结构化的
• 程序
• 面向对象
• 面向对象 - 基于原型（例如 Java Script）
• 函数式（例如 Haskell）
• 面向逻辑的（例如 Prolog）
• 元（如果它是一个纯粹的概念？）
• 基于堆栈（例如 Forth）
• 基于数学/面向数组（例如 APL）
• 声明性的
• 连接（例如 PostScript）
• （绝对不完整的清单...）

其次，为了更好地理解这些概念，最自然、最纯粹基于/实现其核心概念的编程语言是什么？

• 例如，Java 是 OO，但它不是一个很好的例子，因为由于原子，它不是纯 OO。
• Lisp 是一种众所周知的函数式语言，但它是多范式的，所以它不是纯粹的。但是 Lisp 可能是“基于列表”的纯粹实现（如果它算作概念的话）。
• 是否存在结构化（没有 GOTO）但不是程序性的语言？（可能是 XSLT v1.x）

谁能给我解释一下

1. 什么是面向数据的编程？
2. 面向数据的编程和函数式编程是一样的吗？
3. 面向数据编程与面向对象编程有何不同？
4. 在什么情况下我们会选择面向数据的编程语言而不是面向对象的编程语言？

当我想跟踪活动连接时，最好将它们保存到链表中还是直接保存到索引将代表连接 ID 的某个数组中？我想防止可能的竞争条件问题，例如：

• 列表中的连接数很大
• 有人开始搜索列表末尾的连接
• 同时，在搜索过程中，连接断开

我最近买了Programming Scala，并且一直在阅读它。语言绝对不是我所期望的！具体来说，它似乎实现了我所知道的几乎所有编程语言的想法，在 Lisp 宏和 Haskell 的类型级副作用隔离之外。

坦率地说，这让我有些不知所措。虽然我认为有这么多工具可供我使用是件好事，但我真的只是在 JVM 上寻找一种强类型的函数式语言。我想我可能会以这种方式使用 Scala，但我想如果我与任何库交互或浏览其他任何人的代码，我会遇到很多这种高级（对我而言）OOP 东西——特征和“对象层次结构”线性化”，所有这些抽象和压倒一切的业务、单例、包和伴随对象、隐式转换……更不用说各种语法快捷方式和糖了。

人们常常哀叹程序员试图将一种语言的风格硬塞到另一种语言中，这有很多很好的理由。但并非所有语言都像 Scala 那样具有多范式，所以也许它的社区有不同的看法？例如，在 F# 中，似乎在编程风格和使用多少 OOP 方面存在一些余地。但是仅仅从阅读中我不确定这对 Scala 是否也是一个好的哲学。

更有经验的 Scala 程序员可以在这里帮助我吗？为清楚起见进行编辑：基本上，我可以安全地仅（或大部分）使用 Scala 的 FP 功能，而不必担心其高级 OOP 方面吗？

对不起，漫无边际的问题！

这是一个更理论的问题，而不是特定的场景：

假设，我们有一个这样的简化表格方案：

items包含一些基本数据，item_data每个项目的附加属性rel_items设置不同项目之间的树关系。有不同类型的项目（由字段表示items.item_type），其中存储了不同的字段item_data，例如：狗、猫、老鼠。

如果我们有一些更大的查询，其中包含一些连接和连词（例如获取项目及其父项目与其他项目有一些条件等），与将所有不同类型的项目拆分到单独的表（dog，cat, mouse) 而不是将它们合并成一个？

如果我们将它们全部保存在一个基本项目表中，创建视图（狗、猫、鼠标）会以某种方式影响性能吗？

编辑（如下评论）：我认为“物种”、“家养宠物”等是 item_types。每种类型都有不同的属性。使用基本 item 表和 item_data 表的目的是拥有一个基本的“对象”并根据需要将尽可能多的属性附加到它们，而无需修改数据库方案。例如，我不知道应用程序中会有多少动物以及它们有什么属性，所以我想到了一个不需要每次用户创建新动物时都更改的数据库方案。

Web 开发中的“约定优于配置”范式有什么好处？有没有坚持下去没有意义的情况？

谢谢

假设我有一些 HTML 页面和一个相应的 CSS 文件。我想为某些元素添加圆角。我想在每个其他部分交替背景颜色。我想为每个部分标题添加悬停状态。依此类推-我一直在造型，造型和造型。

在我看来，存在三个极端，它涉及按类、按 id 和按层次结构在标记上分配 CSS 规则的“谁、什么、何时、何地、为什么以及如何”。

极端 #1：每个样式规则都基于一个 ID。

极端 #2：每个样式规则都基于一个类。

极端 #3：每个样式规则都基于 DOM 层次结构。

显然，前端 Web 开发的禅宗将包括类重用与独特规则与层次结构的健康平衡，因为这三个极端中的任何一个都会对浏览器性能、可维护性和代码大小造成严重破坏。我认为。还是我错了？如何判断何时需要新.class的，或者您想要应用的样式规则可以安全地插入现有定义中？什么时候两个#id规则足够相似以至于您应该将通用代码提取到一个类中？你什么时候“分叉”一个类（有时你保留原来的，并为所有偏离情况添加派生（OOP 术语中的“渗透”），而其他时候将通用规则推到几个不相交的偏离中的每一个 - 显然这取决于偏差本身的性质（即涉及的规则数量）。是否有使用纯等级规则的情况？

问题：是否有管理此类辩论的经验法则？您的经验和/或建议是什么？是否有关于该主题的好文章、资源、书籍、讲座（“技术谈话”风格视频的奖励积分）或其他可用内容？我想让讨论以几个关键点为基础（尽管欢迎任何评论），没有特别的顺序：

• 可维护性（易于阅读、修改和添加代码）
• 干燥（不要重复自己）
• 时间效率（加载时间；渐进式渲染）
• 空间效率（标记和相关样式的组合大小）