Clojure

Lack of built-in syntax for optional and keyword parameters in function definitions. Sure, you can add it easily enough, but that means library writers don't use it. Pervasive destructuring hasn't proven to be a good substitute yet Lack of method combination (before/after/around methods of the sort found in Common Lisp) Too much reliance on Java interop, e.g. there's no built-in file IO Sometimes I want static typing. This one isn't pure hate; I usually prefer dynamic, and attempts to mix the two have been largely unsatisfactory There's no built-in fast binary serialization format for the built-in data structures, though I hear people are working on it

Java

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

按最讨厌到最不讨厌的顺序排列。

1.) Backwards compatibility police. Yes backcompat is a strength but Perl 5 takes it too far. Now we don't really even get new features in our language without having to enable them explicitly. I'm much prefer the inverse, if a new feature causes a problem let me disable it or enforce old behavior. e.g. perl 5.10 added say I'd rather have no feature 'say' if I have my own say implemented than have to put use feature 'say'; or use 5.010; also if 5.8 worked but 5.10 didn't. I'd rather have use 5.008; to restrict my code to only use features available up to and including 5.8 if no use version; was defined then it should be defaulted to whatever version you're running, and a recommended practice of not to restrict it unless you have to.

2)。过度的样板。

#!/usr/bin/perl
use strict;
use warnings;
use utf8;
use autodie;
use English '-no_match_vars';
use 5.010;
package Package::Name;

BEGIN {
    Package::Name::VERSION = 0.1;
}

sub somesub {
    my $self = shift;
    my ( $param1, $param2 ) = @_;
}
1;

现在你可以开始编码了。这不会因为第一条而改变。当然也有一些捷径，比如使用common::sense;或者使用modern::perl;这将缩短上面的内容，你可能需要一些稍微不同的模块或pragma。但因为第一条，我们永远无法把它降低到。

#!/usr/bin/perl
package Package::Name 0.01;

sub somesub ( $param1, $param2 ) {
}

一些模块正在帮助这一点，在5.0.12中有新的包版本，它完全允许这种语法，尽管我认为它需要使用5.012;首先，和Method::签名，但它永远不会完全解决，(在语言)。

3)。糟糕的变量选择

吸吸文件

#!/usr/bin/perl
use strict;
use warnings;
open my $fh, "< foo" or die $!;
local $/; # enable localized slurp mode
my $content = <$fh>;
close $fh;

WTF是$!和美元/ ?重写为易读。

#!/usr/bin/perl
use strict;
use warnings;
use English '-no_match_vars';
open my $fh, "< foo" or die $ERRNO;
local $INPUT_RECORD_SEPARATOR; # enable localized slurp mode
my $content = <$fh>;
close $fh;

不要忘记，如果您不想受到性能影响，'-no_match_vars'必须存在。

不直接创建匿名标量怎么样?

#!/usr/bin/perl
my $scalar_ref = \do{ my $anon_scalar };

他们就不能想出点什么办法吗?

#!/usr/bin/perl
my $scalar_ref = <>;

哦，perl是线程不友好的，因为所有的变量(包括特殊的变量)默认是全局的。至少现在你可以使用我的$_;对其词法作用域，并对其他词使用local。

4.)非常难看的语法

MooseX::Declare是一个更好的语法。我也希望->被替换为。(个人喜好不太重要)

5)。太多的TIMTOWTDI或太多的最佳实践似乎你必须读3-5本书才能弄清楚你应该如何做事情。

6)。以前的(不再适用)。Un-sane版本。5.10.0有新功能5.10.1的新功能没有设定时间，直到下一个版本。现在是每年一次的特性发布，每季度更新一次。

7)。象牙塔视角。社区问题，似乎是许多开发者想要设置更高的准入门槛，并认为可以不尊重n00b(或任何不同意他们的人)。

8)。疯狂的版本号/字符串Perl有浮点版本号，它们很难看。开发人员不知道并不是所有的下游处理版本比较的方式都是一样的。不是语言问题

0.012 # simple
5.012001 # semantic 
4.101900 # time based + version (for multiple versions in a day)
0.035_002 # prerelease

所有有效版本的perl..我们就不能用…

0.12 # simple
5.12.1 # semantic
20100713 # time based (just use the date and be careful not to need to release more than 1 a day)
0.35-beta2 # prerelease

除了

9)。升级后没有明显的方法重新安装所有XS模块

那"我讨厌某些语言的五件事"清单呢?: 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.

Haskell:

空间泄漏——懒惰的默认代价——也许代价太高了? 甚至像head和tail这样的纯函数也会调用错误并引导您进入IO。 fail from Monad -带回MonadZero。 Num类-(+)应该在AdditiveGroup或类似的类型中。 那个单子不是一个应用程序。

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

我试着阅读其他所有的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()来实例化你的泛型对象，但是这个对象需要有一个默认构造函数。为什么不能指定一个签名，这样就不需要在还没有空构造函数的情况下创建空构造函数，而只使用已有的构造函数。