Java:

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

我偶尔会用我喜欢的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工作了……

Common Lisp

缺少提供更现代功能的标准库(套接字，线程，…) 是否可以使用映射到本机窗口系统的标准化UI Scheme将lambda表达式赋值给变量并将变量直接作为函数调用使用的能力看起来比APPLY for FUNCALL更整洁。我猜这是使用多个名称空间的副作用 标准化的库源代码级打包系统，以便可以从多个实现中轻松使用它们

我想知道强类型的口齿不清会是什么样子

C#

我对c#非常满意，但这两个真的让我很恼火:

Constructor-based initialization for immutable classes is less convenient, less intuitive (when you read the code you don't understand what you assign to what), has less IDE backing than inline object initialization. This makes you lean towards mutable classes inevitably. I know this has been mentioned before, but I strictly have problems with initialization syntax for immutable classes. switch is too verbose. Whenever I see a situation where a switch would be proper, I'm really inclined to use an if..else if.. just because it's more terse (~30% less typing). I think there should be no fallthrough for switch, break should be implied, and case should allow comma separated list of values.

Lua:

The built-in error system is absolutely horrendous You can implement a try-catch system by modifying the Lua interpreter; but it has no compatibility with the errors that are thrown by the built in functions. The fact they have __newindex instead of __setindex as the setter ... and __newindex is only fired when the key doesn't already exist. If it does, no metamethod is called at all. No good type comparison system. There's the type() function but it only handles the basic types (all tables are tables). It really needs to have a metamethod for type comparisons. I've implemented this before with an 'is' operator and a __type metamethod and it works really nicely. It's a bitch to define new keywords. You can do it, but the code inside Lua isn't well documented so it's kind of trial and error to find out how to get the result you want. This is a major issue when you want to implement the things I mentioned above yourself (not so much __setindex though, that's an easy modification). I can't use it in a web browser. Yeah not really a problem with the language itself, but damn, would I love to be able to use Lua instead of Javascript... :)

EL -表达式语言，${…}和#{…JSF 2.0 Facelets用于从底层Java代码中提取数据。

All the fun things, like method calls with parameters and annotation based naming is only present in the EL in Java EE 6 which is only available in Glassfish v3. It is a royal pain to 1) get the right jars for an earlier Servlet 2.5 container, and 2) getting them to work without interfering with any previous implementation available in the container. Having only an earlier version of JSF like 1.2, takes away the method calls and leave you to work with f:setPropertyActionListener - http://weblogs.java.net/blog/2009/07/22/say-sayonara-spal - which, trust me on this, is not very nice. The EL parser has no idea of where the snippet it is to parse and interpret came from, so you tend to give everything an id so you at least can identify which tag made it grumpy. Eclipse gives a warning at every EL method call as it is JSF 1.2. only too.