Java:

没有过程编码，它编译成过程代码，所以让我使用它! 没有多重继承，试图用15,000个接口做同样的事情很糟糕。 约会课，我还需要多说吗。 我不能充分利用多态性。Java不会覆盖不同的参数类型来触发。 我想不出第五个原因，如果我知道，我会回来编辑这篇文章。

我最喜欢的是c#，但是已经有很多关于c#的答案了，所以我将选择我的下一个“最喜欢的”:

t - sql

The GO statement, and the fact that you need it for all manner of DDL/DML scripting, and the fact that it also breaks transaction semantics, making it far more difficult than it needs to be to write an atomic script, which you really need to have in order to upgrade a production database. Inconsistent semicolon semantics. 99% of the syntax doesn't need it, MERGE statement has to end with it, WITH statement has to begin with it... make up your mind! WITH CHECK CHECK / WITH NOCHECK CHECK. Uuuu-gly. Optional parameters in UDFs aren't really optional. Caller must specify DEFAULT (and don't even try using NULL instead). Compare to SPs where they are truly optional. "...may cause cycles or multiple cascade paths." HATE HATE HATE HATE HATE HATE HATE HATE HATE HATE HATE

C#

Lack of multiple dispatch based on the runtime type of the method arguments. dynamic should solve most of this, but it hasn't been released yet. Interface implementation is declarative not structural. I really like the way Google's Go language is doing types Making asynchronous method calls is really bulky (and I'm pretty sure all threads are OS threads, not lightweight threads) No macro system. I'm not talking about C-style macros here; I'm talking LISP/Scheme style macros Operators are static methods and their signatures are overly constrained (and you can't create new ones).

HyperTalk:

很久很久以前就死了 没有简单的赋值(你不能说a:= 3，你必须说把3放进a 没有嵌套函数 没有真正的数据结构，只有字符串。要创建“列表”，您可以使用itemDelimiter分隔项并手动转义它们。你也可以得到行和单词比如txt的第5行第2个单词

说句题外话，我认为HyperTalk最酷的独特功能之一是特殊的it变量:

ask "How many years old are you?"
answer "You are " & it*12 & " months old."

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、网络和配置管道，并且是我的首选语言，可以以一种可以长期支持的方式快速启动和运行。

TCL

这是我最喜欢的语言，几乎可以做任何事情。多年来，它已经(慢慢地，非常缓慢地)演变为解决大多数让我烦恼的事情。而且这门语言非常灵活，很容易实现语法来覆盖那些仍然困扰我的东西。但是语言中有一些东西是不能轻易改变的，只是打破了它的禅意:

Arrays (of the associative kind, what Perl calls hash) don't have proper value semantics. This makes them awkward to pass to and return from functions. Also, this means that they can't be nested. For this reason dicts (dictionaries) were invented but too late, the nice array access syntax: $array($foo) is now forever taken by stupid arrays for backwards compatibility. We're now stuck with: dict get $dict $foo which is much more verbose and to me feels less readable. No real closures. Though it can be emulated somewhat by globals or namespaces but that defeats the reason for closures in the first place. Although, I can't really see for now how closures can be implemented in a pure value semantics system. Teacup is hard to use and is not at all intuitive compared to all other repository tool out there. This is more ActiveState's fault than tcl-core and doesn't really break tcl's Zen when coding but it is still very annoying.