C++

编写一个简单的代码片段要花很多时间。 对于(std::vector::const_iterator iter =[…] Vector.remove()不移除。 Vector.push_front()不存在。 头文件 没有λ 如果至少有一个虚函数，则没有自动空虚析构函数。

第一个帖子，所以对我放松点:)…很棒的社区网站，顺便说一句!

我试着阅读其他所有的c#回复，这样我的回复就不会重叠了

c#……排名不分先后:

1) switch语句中的case没有fallthrough。如果没有转机……为什么必须显式的类型中断;呢?这只是弱智和令人困惑，因为它意味着没有休息的能力;!!

2)不能在子作用域中声明同名变量，但可以声明与类变量同名的变量?要么都允许，要么都不允许。否则，就没有意义了。

3)函数中没有可选/默认参数

4) finally{}中的异常应该隐式地捕捉每一行。或者至少，只有NullReferenceException异常。例如，在访问数据库后，应该总是清理。所以，finally块应该看起来像这样:

finally
{
  if(par1 != null)
    par1.Dispose();
  if(comm != null)
    comm.Dispose();
  if(conn != null)
    conn.Dispose();
}

如果可以写成这样，就会简洁得多:

finally
{
    par1.Dispose();
    comm.Dispose();
    conn.Dispose();
}

但是，不……你必须检查你是否正在访问一个空对象，否则它可能会从finally块抛出一个NullReferenceException。谁真的需要finally块中的异常呢?

5)泛型:你可以指定new()来实例化你的泛型对象，但是这个对象需要有一个默认构造函数。为什么不能指定一个签名，这样就不需要在还没有空构造函数的情况下创建空构造函数，而只使用已有的构造函数。

Ruby。

Strange scoping rules - variables, constants, and methods each behave differently from each other. The rules change also depending on which keyword you used to create a closure. Or on whether you're in a class, eigenclass, object, module, or module's self. Then there's instance_eval, which changes the rules to a different set of rules. And they change again when a module is "included" or "extended", which themselves do different things to scope. And some sets of rules can't be emulated by metaprogramming, so you have to use eval. Unless you're on ruby 1.9, where all of this is different. Namespacing is basically useless. If you have Foo::File, then the stdlib File is probably broken for all of Foo. require statement is broken. If two files require eachother, the behavior of those files can change dramatically depending on which is loaded first from elsewhere. libraries change APIs dramatically and suddenly, so you have to require specific minor revision numbers of all of your dependencies. For every single ruby application on your system. The rubygems package system overrides "require" rather than putting files in the search path - because why use a system when you can replace it?

Python:

我仍然是python的一般用户，所以我的抱怨可能只是知识的锁或误用。欢迎提出意见。我很喜欢这门语言。

Poor thread support and GIL. If you'd like to take use of multicore platform, most of the python programmers would probably recommend multiprocessing or some sort, don't use threading. It wouldn't give you the performance you are expecting. property only for instance variable. _class_var = property(classmethod(some_method)) just wouldn't work. How can I get a property wrapped class variable? no access control. All access controls are syntax mangling. Like private is __private, protect is _protected, etc... And hope that everyone programs python follows the naming convention. Come on, we can do better than that. I agree the python philosophy of being simple and clear syntax but some simple and clear syntax not being supported seems lock of good judgement, in my opinion. Such as, a++, ++a, a-- and --a, self-de/increment, what's wrong with those? foo = (a > b ? a : b) unary operation, what's wrong with those? (I know py2.6 has something similar introduced, but given the massive support of almost every other language for those simple syntax, why reinventing the wheel? why not just follow the best practice? Shouldn't a good thing just keep in its good "form"?) Program to interface. Python has no interface or abstract class concept (py3k has something called abc), everything is concrete. Providing an "interface" or "abstract" keyword to build class skeleton and guard class inheritance and extension wouldn't be a bad idea I think. It helps on top-down design. Currently, I just have to fill the each of methods with NotImplementedError, quite a tedious job. I have to add this. version less than 3.x has str and unicode types. This is a true nightmare. It makes ascii and non-ascii/unicode mixing most likely to fail (bad, bad)

我看到人们抱怨速度。我不明白。它是一种解释语言，代码直到运行时才编译成机器代码，这就是它的本质。你不能比较解释语言和编译语言的速度。据我所知，在解释/脚本语言中，python并不慢。

Common Lisp:

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

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.