我最喜欢的是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

Python:

Global Interpreter Lock - Dealing with this complicates parallel processing. Lambdas functions are a bit clunky. No built-in ordered-dictionary type. Depending on how Python is compiled, it can use either UCS-2 vs UCS-4 for the internal Unicode encoding, many string operators and iterators may have unexpected results for multi-byte characters that exceed the default width. String slicing and iteration depend on the bit width rather than checking and counting characters. (Most other programming languages do similar things as well and have similarly odd behavior with these characters.) There are inconsistencies surrounding GUI frameworks for Python.

Common Lisp:

关键词往往太啰嗦。 库支持是可怜的。 在希望更严格地处理内存的操作系统中不能很好地工作。 没有与操作系统交互的良好工具。 “循环”功能没有很好地定义，当然看起来也不像Lispy。

Scala是我最喜欢的语言。五件讨厌的事?容易:

Takes a long time to learn properly. I know you can write Scala as a 'better java'. That is what we used to say about C++ and C too. I agree this is an inevitable consequence of the deep ideas in the language. But still ... Methods vs. Functions: def f(x: Int) = x*x defines a method f, not a function f. Methods are not functions despite a lot of early Scala tutorial material blurring the distinction. The language tries to blur it too because if you supply a method in some places where a function is expected it is accepted. Do we have to have both methods and functions? Yes it is fundamental. But it was initially confusing to me. Composing classes or objects from mixins in the 'cake' pattern is prone to NPE's. e.g. trait X { val host: String; val url = "http://" + host } is a mixin that will NPE on instantiation, or not, depending on its position in the class declaration. The compiler could tell you if it will fail but doesn't. (In 2.7 anyway.) It is hard to diagnose the problem in complex inheritance graphs. Arrays in 2.8 rely on implicits to mesh with the main scala collection types. But implicits are not applied everywhere. An Array can be supplied where a Seq is expected. But an Option[Array] cannot be supplied where an Option[Seq] is expected. I know there are no completely 'right' ways to handle java Arrays. Type erasure. Enough said.

Common Lisp

conditions aren't classes (since classes came later), even though their interface is almost identical some of the names are just weird, e.g., flet / labels (only difference: scope), and defvar / defparameter (only difference: behavior when already defined), or any of the bit-twiddling functions (dpb, ldb, etc.) packages are ... really hard to get right -- every time I think I understand them, they don't do what I want built-in data structures and functions aren't as generic as they could be (e.g., why can't I define my own hash function portably?) multiple namespaces for functions, variables, etc. (I'm not opposed to this in principle, but CL made it too complex; Norvig has said he can't tell from the spec but there appear to be at least 7 namespaces)

Python

没有Django for Python 3。 静态类型。是的，动态类型是很棒的东西，但有时我确实想让它成为静态的。 正确的unicode支持(在Python 3中修复) Construtors命名。我讨厌代码中的所有这些下划线。 线程的效率不是很高