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

那"我讨厌某些语言的五件事"清单呢?: D

把橙色涂成红色并不能让它成为苹果。

当设计一种语言时，设计者通常会考虑它的用途。用它做一些完全不同的事情是可以的，但是当它不起作用时抱怨是愚蠢的。Python。我相信总有一天会有人用Python代码创建exe工具。你到底为什么要这么做?不要误解我的意思，这样做很好，但没有任何用处。所以别再抱怨了!

一个设计良好的项目很可能包含来自多种语言的代码。这并不是说你不能只用一种语言完成一个项目。有些项目可能完全在您所使用的任何语言的能力范围内。

4-你是用木腿站着吗?

The platform can be a large influence of what the language can do. With nowadays garbage collectors, or well even pascals early attempt at "garbage collection", can aid in memory fade (maybe malloc more ram??). Computers are faster and so of course, we expect more out of our languages. And quite frankly, we probably should. However, there is a huge price to pay for the convenience of the compiler to create hash tables or strings or a variety of other concepts. These things may not be inherit to the platform of which they are used. To say they are easy to include to a language just tells me you may not have a leg to stand on.

3-到底是谁的错?

Bugs. You know. I love bugs. Why do I love bugs. Because it means I get to keep my job. Without bugs, there would be many closed pizza shops. However, users hate bugs. But here is a little splash of cold water. Every bug is the programmers fault. Not the language's. A language with such a strict syntax that would significantly reduce how many bugs were possible to generated would be a completely useless language. It's abilities could probably be counted on one hand. You want flexibility or power? You've got bugs. Why? Because you're not perfect, and you make mistakes. Take a really identifiable example in C:

int a[10];
for (int idx = 0; idx < 15; idx++) a[idx] = 10;

我们都知道会发生什么。然而，也许我们中的一些人没有意识到…这种功能是非常有益的。这取决于你在做什么。缓冲区溢出是该功能的代价。上面的代码。如果我真的把它公之于众。这是再一次. .和我一起说。“我的错”。不是C，因为你允许我这么做。

2-我们不应该把它放进回收站吗?

It's very easy to point at a feature in a language we don't understand because we don't use it often and call it stupid. Complain that it's there etc. Goto's always entertain me. People always complain about goto's being in a language. Yet I bet your last program included a type of goto. If you have ever used a break or a continue, you've used a goto. That's what it is. Granted, it's a "safe" goto, but it is what it is. Goto's have their uses. Whether "implicit" gotos like continue or break are used or explicit gotos (using the actual keyword "goto" for whatever language). Not that language developers are flawless, but typically... if functionality has existed since the dawn of time (for that language). Likely that aspect is a defining quality of that language. Meaning.. it's being used and likely is not hanging around because of backwards compatibility. It's being used today. As in 5 minutes ago. And used properly. Well.. arguably someone is using it improperly as well, but that relates to #3 on my list.

1. -一切都是客体。

Ok.. this one is really a subset of #2. But this is by far the most annoying complaint I see in hate lists. Not everything is an object. There are a great many of concepts that do not belong or need to be objects. Putting things where they don't belong is just ugly and can decrease efficiency of a program. Sure. Maybe not much depending on the language. This also relates to #5. This means... yes. Global are ok. Functions as apposed to static methods are ok. Combining OO programming with global functions is ok. Now.. that doesn't mean we should all go out and "free" our code from it's object models either. When designing a section of code or a whole project, what happens behind the scenes should be considered when putting it together. Not only where that concept lives and many other factors. Why wrap global functions within classes or name space concepts if it serves no purpose? Take static member variables. That greatly amuses me because.. well..Depending on the language and implementation of course, but generally speaking, you just declared a global. Yes, there are some reasons to wrap these non-OO concepts in OO wrappers. One of course being self documenting code. That can make sense. So.. like I say. Don't go out and "free" your code. But any good modern language will have a global concept outside of it's OO modeling. Yes I'm specifically meaning to point out that an OO programming language without a global concept most likely has a serious design flaw. Again though.. depends on the intention and design of the language so I'm not attempting to pick on any specific language and there are far too many to analyze right here. Anywho, Consider where the code should live and be the most effective. Adding a bunch of flare to something which doesn't add functionality or support just wears down the keyboard faster. It doesn't do anybody any good. Well.. unless you like brownie points from the person who probably incorrectly taught you that everything is an object.

In short, programming isn't just mindlessly tapping on the keyboard. There are a lot of design considerations to any project. I know it's cliche, but you have to look at it from every angle. Even with nowadays type-safe languages. You don't just chuck code out and expect it to work well. Sure.. it may work, but it may not be the right way to go about it. Overall, pick the language and format that is best suited for the specific job AND the environment. But no language takes away the thought behind it. If you're not thinking.. you're just typing.

我偶尔会用我喜欢的PHP，而Python会用得太多。

No namespace; everything is in a kind of very big namespace which is hell in bigger environments Lack of standards when it comes to functions: array functions take a needle as a first argument, haystack as second (see array_search). String functions often take the haystack first, needle second (see strpos). Other functions just use different naming schemes: bin2hex, strtolower, cal_to_jd Some functions have weird return values, out of what is normal: This forces you to have a third variable declared out of nowhere while PHP could efficiently interpret an empty array as false with its type juggling. There are near no other functions doing the same. $var = preg_match_all('/regexp/', $str, $ret); echo $var; //outputs the number of matches print_r($ret); //outputs the matches as an array The language (until PHP6) does its best to respect a near-retarded backward compatibility, making it carry bad practices and functions around when not needed (see mysql_escape_string vs. mysql_real_escape_string). The language evolved from a templating language to a full-backend one. This means anybody can output anything when they want, and it gets abused. You end up with template engines for a templating language... It sucks at importing files. You have 4 different ways to do it (include, include_once, require, require_once), they are all slow, very slow. In fact the whole language is slow. At least, pretty slower than python (even with a framework) and RoR from what I gather.

不过，我仍然喜欢PHP。这是网页开发的电锯:你想要一个小型到中型网站的速度非常快，并确保任何人都可以托管它(尽管配置可能不同)?PHP就在那里，它无处不在，只需要5分钟就可以安装一个完整的LAMP或WAMP堆栈。好吧，我现在要回去用Python工作了……

PHP:

人们永远无法确定某些几乎常见的扩展在所有web服务器上都可用。 试图成为未来的一切(goto，闭包，…) 对于没有经验的用户有很多安全风险 更多的操作符重载会很好 所有不学习如何使它正常工作的可怜的程序员，给它一个坏名声

尽管如此，PHP是(脚本)语言。: -)

c#(好吧，我猜一部分是VisualStudio IDE):

No covariance (yet), like Class<D> cannot be used in place of Class<B> even though type D derives from type B. Graphic designers don't support generic based inheritance (or inheritance from abstract classes), even though the inheritance itself works just fine if you work around the designer problems by adding extra inheritance levels just so designers always see concrete non-generic variants of your code. No constructor inheritance No constructors in where clauses of generic type parameters VisualStudio seems to have a tendency to mysteriously check out files (like project files and/or unit test definitions) when opening a solution, even though the files do not seem to actually get altered.

如果你明天再问我，可能会有不同的名单。即使协方差和设计师的麻烦将在我的前5名，直到他们被解决(随着方差添加到c# 4.0，这似乎已经发生了至少一个…)

C++:

缺乏象征意义。 过度迷恋C语言的兼容性。 极其复杂的预处理器。 模板错误几乎是不可理解的。 没有垃圾回收。