FORTRAN并不是一个真正的WTF时刻，而更像是一个“为什么我需要输入所有这些垃圾时刻”

IF(12 .gt. 11) THEN
 // Do some magic
ENDIF

“.gt.”在我玩这门语言的时候把我弄糊涂了，直到我意识到它是“>”符号。哦，我多喜欢不学生物，不用天天接触这些垃圾

英语中的虚拟语气。

等等，你是说编程语言吗?然后在C中使用(宏)绕过宏()的预处理器#定义。例如，如果有人使用#define free(…)，(free)(…)将与free(…)不同。

在c#中: A = cond ?B: c; 如果“b”和“c”是“赋值不兼容”，你永远不会得到结果，即使“a”是对象。 它是ms中最常用和最愚蠢的实现运算符。有关比较，请参阅D语言中的实现(关于类型推断的注意)。

我为客户端编写了一种编程语言(用于实验驱动定制硬件)，其中包含一些定制类型(Curl, Circuit，…)，每种类型只有2个值。它们可以隐式地转换为布尔值，但是(在客户机的请求下)可以在运行时更改此类类型常量的确切布尔值。

例如: Curl类型有2个可能的值:CW和CCW(顺时针和逆时针)。在运行时，你可以通过一个简单的赋值语句改变布尔值:

ccw := true

所以你可以改变所有这些类型值的布尔值。

在c++中，“虚”MI(多重继承)允许“菱形”类层次结构“工作”，这让我觉得奇怪和讨厌。

A:基类，例如:“对象” B, C:两者都(实际上或不是)源于对象和 D:起源于B和C

问题:“正常”继承导致D是2种不明确的A。“虚拟”MI将B的A和C的A折叠为一个共享基对象A。

所以，即使你的车轮是一个对象，你的左前轮是一个车轮，你的汽车继承了四种车轮，你的汽车仍然只是一种具有虚拟MI的对象。否则，你的汽车不是一个对象，而是4个车轮对象。

这是一种奖励糟糕的类设计、惩罚编译器编写者的语言特性，并让您在运行时怀疑对象到底在哪里——以及是否有任何虚拟MI行李放错了地方。

如果在类层次结构中确实需要菱形模式，可以使用常规MI和委托给单个A基的“AProxy”来完成。

A:基类，例如:“对象” AProxy:基类，与其他A绑定的构造 B:源自A C:来源于AProxy D:源自B和C(在构造时将B的A传递给C的AProxy)

对于那些真正喜欢diamond MI的人来说，这需要做更多的工作，而我们其他人则可以安心地使用一组更易于处理的语言特性。

这让我惊艳

#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
            _-_-_-_
       _-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
       _-_-_-_-_-_-_-_
           _-_-_-_
}