Ruby有许多与速度相关的缺陷，但我并不讨厌它们。它也有社区传福音过度的缺陷，但这并没有真正困扰我。以下是我最讨厌的:

Closures (blocks) have 4 different creation syntaxes, and none of them are optimal. The elegant syntax is incomplete and ambiguous with hashes, and the full syntax is ugly. The community tends to be against real documentation, favoring ‘read the code’. I find this childish and lazy. Metaprogramming abuse, particularly in libraries, makes bugs a nightmare to track down. On a related note, pervasive metaprogramming makes a comprehensive IDE difficult, if not impossible, to make. The way block passing to functions is done is silly. There is no reason blocks should be passed outside the parameter list, or have odd special syntax to access (yield). I am of the opinion that blocks should have been given a less ambiguous syntax (or hashes could have used different delimiters; perhaps <> rather than {}), and passing as parameters to methods should have been just like all other parameters. object.method(1, {|a| a.bar}, "blah") These oddities, like the block must be the last parameter passed and passing more than one block is different with longer syntax, really annoy me.

Erlang

没有静态推断 就像在哈斯凯尔发现的一样。这 会导致运行时错误和一个 有认真写代码还是使用 透析器(1)发现 差异。动态类型是 慢的:也被认为是慢的; 与C、Java等语言相比，它几乎是未知的; 的lists(3)模块有时相当精简 我缺少用于列表处理的有用函数 (就像在数据。例如Haskell中的List); 让我在每句话的结尾都加上 在从句中，和。最后是后者。

C#

Reference types are nullable by default; in-language null keyword is untyped. Lack of discriminated unions Exceptions as default, non-exceptional error handling method - there's not much of an alternative. archaic switch statement syntax and limitations Needless distinction between constructors + static methods Static methods can't be part of an interface Lack of by-shape interface implementation rather than explicit interface implementation - leading to numerous language design hacks such as the linq query syntax, foreach, collection & object initializers -- none of which can be flexibly reused. For example, the object initializer syntax may be nice, but plays poorly with immutable objects. Cannot inherit "interface" of a class independently of implementation - leading to code duplications and overarchitected code that provides interfaces, abstract base classes, a few common implementations, and no way to pick and choose the bits of each to use. Also; leads to too many code that's tightly coupled to a particular implementation since it's common to explicitly refer to the implementation type rather than an interface. Cannot multiply inherit via composition since a classes "interface" is tightly coupled to it's implementation; effectively lack of mixins. The above limitations of interfaces lead to a proliferation of virtually identical interfaces that don't overlap naturally in any kind of type hierarchy. IComparable vs. IEquatable vs. IComparable<T> vs object.Equals vs. operator == etc. etc. By extension, making a custom type that satisfies all these things is a lot more work than necessary (in particular for collection classes). Obviously, the language designers realize this, hence the various workarounds for things like linq, foreach and collection initializers which work by-shape rather than by-interface. Redundant use of parentheses and braces rather than layout-is-structure. Return values can be ignored, limiting the effectiveness of type inference. Enums aren't a normal type and can't have methods. Also, enum values aren't typesafe and may be initialized to 0 despite not having a 0 value. Mixing metaphors by lumping flag and non-flag enums together. Lack of proper value type support. Value types can't be inherited, have different constructor semantics, and perform poorly due to CLR limitations. Also, confusing semantics regarding value types: some values are really values (and can't be modified), and others are really non-aliased, non-null references (variables). This gets particularly confusing with regards to the next issue: Semantic distinction between fields and properties, particularly in conjunction with lack of mutability modifier (ala C++'s const) Can't specialize generics Cannot provide default generic type parameters (e.g. factory generics) lack of typedef makes generics a pain to use (using is a limited but good-to-know substitute!) Can't genericize over things other than types (e.g. functions, plain values, or names). This means you can't do something like make a generic implementation of a dependancy property leading to, well, nasty implementations of things like dependancy properties and the overuse of code-snippets and poorly readable code as a result. Limited capability to specify generic type requirements e.g. generic sum method that takes both int, double and a bigint (without tricky and often slow hacks). An interface method implementation or virtual method override cannot return a more specific type or accept a more general type; i.e. limited co/contravariance support even in C# 4.

Java

已检查的异常 类型擦除 缺少操作符重载(例如BigInteger/BigDecimal) 缺少regexp/date/duration /复杂文字 对不可变性的支持很差

我讨厌内梅尔的五个方面:

局部函数不能让步 编译lambda的能力有时取决于它是否内联 元组的值/引用类型语义不一致 数组下标和类型参数之间偶尔会出现歧义 缺乏普遍采用

C#

Cannot create a reference (var &t = struct) No local scope destructors (IDispose comes close but its not the same) ToString, i almost dislike that every object has it but it turns out i dislike everything using it like string.format does. I rather have things that accepts a certain type (like ints, floats, text, chars only). So instead of passing in any object i need to pass in something with a implicit typecast or interface. I ended up writing something like this to safely escape text for html which worked great. Cannot use a virtual typecast (blah)obj; does not work if obj does not inherit/has an interface of blah. Simple workaround is to supply an interface with a convert function. Has no local creation. Instead of writing var o = new Item(); i would like to write (something like) Item o() (with an automatic dispose if it has one).