C

bit fields -- they aren't well specified by the language and how they work is compiler dependent and architecture dependent. It's often hard to find where a particular symbol is defined in a large mass of code, esp. if that symbol is produced by a macro. Which reminds me... The preprocessor is a rather ugly hack, amenable to all sorts of abuse. lack of standard sized integers (remedied by uint*_t lately, but there is lots and lots of old code floating around out there with custom typedefs or #defines for DWORD, WORD, BYTE, etc.) Lack of something akin to Perl's cpan.org (would love to be wrong about that one.)

编辑: 在考虑C的CPAN时，我想……我该怎么称呼这样的东西，然后想到了“ccan”，然后谷歌了一下，我看到了这个: http://ccan.ozlabs.org/

不过，它似乎还处于起步阶段。

C#

c#最让人讨厌的是:

(1)事件具有对所有侦听器的强引用，从而防止了侦听事件的任何东西的垃圾收集。如果你想看到这造成的问题，只需在网上搜索所有试图通过创建某种“弱引用事件处理程序”来解决问题的人。

(2)在调用一个事件之前，需要检查它是否等于null，这似乎应该由语言来处理。

(3) XML序列化器无法读取/写入XML文件中的注释。在手工修改XML文件和用c#编写的工具修改XML文件的环境中，情况并不好。可以通过使用原始的XmlDocument来解决，但如果能够将其抽象到一个类中会更好。

(4)构建过程不允许您直接访问xsd文件之类的东西，相反，您需要一个中间步骤，即创建一个c#部分类。这也会导致XAML文件出现问题，有时需要重新构建两次才能使更改正确地通过。

(5)不支持CPU intrinsic，如MMX和SSE 1,2,3,4，因此这些有价值的CPU特性在运行c#应用程序时无法使用。

其他没有进入我的前5名:

(6)不能将字段标记为属性，所有属性必须从一开始就显式地实现:

目前有:

public class MyClass {
    private int someInt;

    public int SomeInt {
        get {
                return someInt;
        }
        set {
                someInt = value;
        }
    }
}

想

public class MyClass {
    [IsProperty(public, get, set)]
    private int someInt;
}

(7)不支持多个返回值，例如:

public int, string, double MyFunction()
{
    ....
    return x,y,z;
}


public void TestMyFunction()
{
    int x, string y, double z = MyFunction();
}

(8)不支持协变返回类型

我对泛型实现有一些不满，但我就此打住。我认为c#是一种很棒的语言，可以完成所有的GUI、网络和配置管道，并且是我的首选语言，可以以一种可以长期支持的方式快速启动和运行。

JavaScript

Every script is executed in a single global 'namespace'...something which you have to look out for when working with scripts from different sources If a variable is used but hasnt been defined before hand, it is considered a global variable Browser vendors making up standards as they please, making coding for us developers using such a beautiful language harder than it should be Case-Sensitivity - considering that there is no decent IDE for developing js with compile-time checking Workarounds (such as the use of hasOwnProperty method) to perform some, otherwise simple operations.

Python:

Too slow! list operations don't return the list, so you can't do list.append(4).append(5). (I mean a reference to the same list, not a copy). This is a minor gripe; it's only come up a few times. statements don't return values (if, print, while, for, etc). This is only a problem when dealing with lambdas. lambdas can only be one expression. There's no real need for this restriction, as they are equivalent to functions in every other way. What if I want a button press event which calls two functions? I'd need to create a named function to supply that functionality to an action listener, while doing "lambda: f1(); f2()" would not hurt. you can only put standard a-zA-Z_0-9 as names. Having functions like "true?" and "+" would be great. Of course, this could lead to terrible obfuscation, but I'm not saying we immediately rename all functions to "p@$%3". Which do you find clearer to read: "dec2bin" or "dec->bin"? ("store_results" or "storeResults") or "store-results"?

MEL(玛雅表达语言):

Single dimensions arrays: Forcing me to manually sync two or more lists, or use delimited strings to simulate more complex data structures. Naturally, they're immutable too. Single threaded and slow: Causing the entire Maya application to hang while it completes a task. Bonus points for not being able to kill long operations, instead having to close and re-open Maya. Script sourcing paths aren't recursive: Meaning every directory you want to store scripts in must all be added to the script path. No namespaces: Forcing the inconsistent use of naming conventions to make sure global procedures don't collide. Modal commands: Each command is modal, meaning the Create, Modify, and Query operations are all handled by setting flags. This also forced the developers to cause most of the commands to return arrays Inconsistent command style: Most array commands actually return arrays, but the Tokenize command has to take an array as a reference which it then populates, rather than spitting out an array. This among other inconsistencies.

这些以及其他几个原因是AutoDesk采用Python作为次要脚本语言的原因，这带来了其他一些令人讨厌的因素:

并不是所有的MEL命令都受支持:大多数都受支持，但有时您会发现自己不得不使用MEL()函数来执行一些任意代码。更糟糕的是，你不得不对它进行所有烦人的逃避。 继承了模态命令风格:必须使用相同的create=True, query=True, edit=True的东西。

C(好吧，这不是我最喜欢的，但当时还没人做过。)

套接字库语法。 没有函数重载。 c风格的字符串。 缓冲区溢出。 神秘的语法。我不知道有多少次我查到像atoi这样的东西，拍着我的额头，然后大喊“当然!”

编辑:如果我使用更多的库代码(就像我用套接字做的那样，但那些特别糟糕)，我可能会想出更多的库代码，但我已经觉得我选择C语言是在作弊。许多语言的存在只是为了取C语言的好的部分，取代坏的部分，这有点像在徒劳无益。