在你看来,你遇到过的最令人惊讶、最怪异、最奇怪或最“WTF”的语言特性是什么?
请每个回答只回答一个特征。
在你看来,你遇到过的最令人惊讶、最怪异、最奇怪或最“WTF”的语言特性是什么?
请每个回答只回答一个特征。
当前回答
在C语言中,数组可以像这样被索引:
a[10]
这很常见。
然而,鲜为人知的形式(真正有效!)是:
10[a]
这与上面的意思相同。
其他回答
PL/SQL允许将变量和函数名声明为关键字。下面是可编译的PL/SQL:
create or replace
function function
return number as
return number;
begin
function.return := 4;
return return;
end function;
/
这创建了一个名为function的函数。后:
SQL> select function from dual;
FUNCTION
----------
4
在JavaScript(和Java)中,你可以转义这样有趣的字符:
var mystring = "hello \"world\"";
如果你想把回车放到字符串中,那是不可能的。你必须像这样使用\n:
var mystring = "hello, \nworld";
这是正常的,也是意料之中的——至少对于一种编程语言来说。奇怪的是你也可以像这样转义一个实际的回车:
var mystring = "hello, \
world";
大约20年前,当我最后一次涉足腮腺炎时,实现有一些奇怪的局限性。当主机MUMPS变得越来越流行时,MUMPS传统上是一种自托管语言:计算机语言、操作系统和数据库在一个包中。
腮腺炎主要是关于它的数据库。本质上,这是一个巨大的多维哈希表,由B*树支持,可以快速访问。语言和数据库之间也没有任何障碍:如果您想在那里存储一些东西,只需在变量前面加上一个符号,表明它将被持久化到备份存储中。
另一方面,文件系统几乎不存在,对它的支持就更少了。我们唯一能做的就是把一个程序从文件中加载到内存中,然后把内存中的内容发送回文件。最好在加载前清空缓冲区,否则它会和之前的东西混在一起。
因此,考虑到它的自托管性质和极其恶劣的文件系统,人们可能会想知道这些程序是如何编辑的。事实上,编辑器是用MUMPS本身编写的——那么,编辑器如何在不重写自己的情况下将程序存储在内存中呢?
好吧,诀窍在于能够以源代码的形式执行变量的内容。然后,编辑器将自己加载到变量中,在变量中执行自己,清除内存,然后在内存中加载、保存和编辑文件,一直从变量中执行。
除此之外,所有命令都可以被缩短为它们的第一个字母(除了Z命令,缩短为两个字母,主要处理文件系统),还有一个奇怪的事实,比如IF (I)设置了一个变量,然后由ELSE (E)查询——当然,可以被任何介入的I或程序本身覆盖。转念一想,我觉得整个语言就是个垃圾。然而,它有一种奇怪的吸引力。
我有点纠结:
1;
在perl中,模块需要返回true。
INTERCAL可能是最奇怪的语言特征的最佳汇编。我个人最喜欢的是COMEFROM语句,它(几乎)与GOTO相反。
COMEFROM is roughly the opposite of GOTO in that it can take the execution state from any arbitrary point in code to a COMEFROM statement. The point in code where the state transfer happens is usually given as a parameter to COMEFROM. Whether the transfer happens before or after the instruction at the specified transfer point depends on the language used. Depending on the language used, multiple COMEFROMs referencing the same departure point may be invalid, be non-deterministic, be executed in some sort of defined priority, or even induce parallel or otherwise concurrent execution as seen in Threaded Intercal. A simple example of a "COMEFROM x" statement is a label x (which does not need to be physically located anywhere near its corresponding COMEFROM) that acts as a "trap door". When code execution reaches the label, control gets passed to the statement following the COMEFROM. The effect of this is primarily to make debugging (and understanding the control flow of the program) extremely difficult, since there is no indication near the label that control will mysteriously jump to another point of the program.