我几年前使用的一个Fortran编译器有一个有趣的特性:(A)数字先存储在高字节;(b)数字按地址传递给子程序;(c)没有在编译时检查长度。

所以你可以写一个这样的程序:(如果我把语法弄乱了，请原谅。我已经很久没有写Fortran了。)

INTEGER*2 FUNCTION TIMESTWO (INTEGER*2 N)
RETURN N*2

... THEN CALL THIS SOMEWHERE WITH A LONG INTEGER ...

INTEGER*4 I, J

I=42
J=TIMESTWO(I)

J的最终值是…零!

为什么?因为传入的值是4个字节，但被调用的函数只查看前两个字节。由于前两个是0，它将0乘以2并返回它。然后将此返回值转换回四个字节。

当我第一次遇到它时，它非常神秘。几乎我传递给某些函数的每个数字都被解释为零!

Perl:

可以编写一个完全由标点符号组成的程序。

这是怎么回事?!

我喜欢在C中插入八进制值:

int values[8] = { 123, 154, 103, 310, 046, 806, 002, 970 };

因为我还没见过任何人提起它……RPG 2或3(报告程序生成器…又名火箭推进垃圾)是迄今为止我用过的最疯狂的语言。它几乎没有对程序流的控制(在文件顶部的Enter，在底部的Exit)，并且编程语句是基于使用固定字体在特定列中定义的字符定义的(想想PUNCH CARDS!!)

要真正做到FUBAR，你必须尝试用DYL-280编程。它将RPG流程和逻辑与COBOL语法结合在一起。

在这里查找RPG: wikipedia.org /wiki/IBM_RPG

DYL-280的示例:http://99-bottles-of-beer.net/language-dyl-280-224.html

大约在1977年，我在Lisp中添加了“format”函数，那时“printf”甚至还不存在(我是从与Unix相同的源:Multics复制的)。它一开始很无辜，但后来被一个接一个的特征填满了。当Guy Steele引入迭代和相关特性时，事情就失控了，这些特性被Common Lisp X3J13 ANSI标准所接受。下面的示例可以在Common Lisp The Language, 2nd Edition第22.3.3节中的表22-8中找到:

(defun print-xapping (xapping stream depth)
  (declare (ignore depth))
  (format stream
      "~:[{~;[~]~:{~S~:[->~S~;~*~]~:^ ~}~:[~; ~]~ ~{~S->~^ ~}~:[~; ~]~[~*~;->~S~;->~*~]~:[}~;]~]"
      (xectorp xapping)
      (do ((vp (xectorp xapping))
           (sp (finite-part-is-xetp xapping))
           (d (xapping-domain xapping) (cdr d))
           (r (xapping-range xapping) (cdr r))
           (z '() (cons (list (if vp (car r) (car d)) (or vp sp) (car r)) z)))
          ((null d) (reverse z)))
      (and (xapping-domain xapping)
           (or (xapping-exceptions xapping)
           (xapping-infinite xapping)))
      (xapping-exceptions xapping)
      (and (xapping-exceptions xapping)
           (xapping-infinite xapping))
      (ecase (xapping-infinite xapping)
        ((nil) 0)
        (:constant 1)
        (:universal 2))
      (xapping-default xapping)
      (xectorp xapping)))

其余的这些都没有令人震惊的Ruby触发器操作符:

p = proc {|a,b| a..b ? "yes" : "no" }

p[false,false]    => "no"
p[true,false]     => "yes"
p[false,false]    => "yes"   # ???
p[false,true]     => "yes"
p[false,false]    => "no"

是的，程序状态存储在解释器的解析树中。这就是为什么开发一个兼容的Ruby实现要花很长时间的原因。但是我原谅你，Ruby