C++

太容易随机破坏内存并创建几乎不可能找到的错误(尽管Valgrind在修复这个问题上走了很长的路)。 模板错误消息。 在使用模板时，很容易将所有内容都包含在一个文件中，然后进行愚蠢的编译。 标准库在现代是一个笑话(默认情况下仍然没有线程或网络?) 大量令人讨厌的C语言(特别是所有在short/int/unsigned/等之间的转换)。

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

Perl 5:

All the really good stuff nowadays seems to require mod_perl, which has low availability everywhere I want to go. Some really incredible functionality can be encapsulated in modules, but what is under the hood is often fragile or frightening: source filters, typeglobs, whatever Moose is doing... DateTime is brilliant but still made some very bad design decisions (not returning a stopwatch duration when subtracting two DateTime objects) Dual-lifed modules in core and on CPAN still cause conflicts module authors still put interactive stuff in their module configuration scripts so that they can't be automatically installed

Perl

Mixed use of sigils my @array = ( 1, 2, 3 ); my $array = [ 4, 5, 6 ]; my $one = $array[0]; # not @array[0], you would get the length instead my $four = $array->[0]; # definitely not $array[0] my( $two, $three ) = @array[1,2]; my( $five, $six ) = @$array[1,2]; # coerce to array first my $length_a = @array; my $length_s = @$array; my $ref_a = \@array; my $ref_s = $array; For example none of these are the same: $array[0] # First element of @array @array[0] # Slice of only the First element of @array %array[0] # Syntax error $array->[0] # First element of an array referenced by $array @array->[0] # Deprecated first element of @array %array->[0] # Invalid reference $array{0} # Element of %array referenced by string '0' @array{0} # Slice of only one element of %array referenced by string '0' %array{0} # Syntax error $array->{0} # Element of a hash referenced by $array @array->{0} # Invalid reference %array->{0} # Deprecated Element of %array referenced by string '0' In Perl6 it is written: my @array = ( 1, 2, 3 ); my $array = [ 4, 5, 6 ]; my $one = @array[0]; my $four = $array[0]; # $array.[0] my( $two, $three ) = @array[1,2]; my( $five, $six ) = $array[1,2]; my $length_a = @array.length; my $length_s = $array.length; my $ref_a = @array; my $ref_s = $array; Lack of true OO package my_object; # fake constructor sub new{ bless {}, $_[0] } # fake properties/attributes sub var_a{ my $self = shift @_; $self->{'var_a'} = $_[0] if @_; $self->{'var_a'} } In Perl6 it is written: class Dog is Mammal { has $.name = "fido"; has $.tail is rw; has @.legs; has $!brain; method doit ($a, $b, $c) { ... } ... } Poorly designed regex features /(?=regexp)/; # look ahead /(?<=fixed-regexp)/; # look behind /(?!regexp)/; # negative look ahead /(?<!fixed-regexp)/; # negative look behind /(?>regexp)/; # independent sub expression /(capture)/; # simple capture /(?:don't capture)/; # non-capturing group /(?<name>regexp)/; # named capture /[A-Z]/; # character class /[^A-Z]/; # inverted character class # '-' would have to be the first or last element in # the character class to include it in the match # without escaping it /(?(condition)yes-regexp)/; /(?(condition)yes-regexp|no-regexp)/; /\b\s*\b/; # almost matches Perl6's <ws> /(?{ print "hi\n" })/; # run perl code In Perl6 it is written: / <?before pattern> /; # lookahead / <?after pattern> /; # lookbehind / regexp :: pattern /; # backtracking control / ( capture ) /; # simple capture / $<name>=[ regexp ] /; # named capture / [ don't capture ] /; # non-capturing group / <[A..Z]> /; # character class / <-[A..Z]> /; # inverted character class # you don't generally use '.' in a character class anyway / <ws> /; # Smart whitespace match / { say 'hi' } /; # run perl code Lack of multiple dispatch sub f( int $i ){ ... } # err sub f( float $i ){ ... } # err sub f($){ ... } # occasionally useful In Perl6 it is written: multi sub f( int $i ){ ... } multi sub f( num $i ){ ... } multi sub f( $i where $i == 0 ){ ... } multi sub f( $i ){ ... } # everything else Poor Operator overloading package my_object; use overload '+' => \&add, ... ; In Perl6 it is written: multi sub infix:<+> (Us $us, Them $them) | (Them $them, Us $us) { ... }

Python:

速度 静态分析(缺乏) 匿名函数仅限于一个表达式

JavaScript:

The Object prototype can be modified. Every single object in your program gets new properties, and something probably breaks. All objects are hash maps, but it's difficult to safely use them as such. In particular, if one of your keys happens to be __proto__, you're in trouble. No object closure at function reference time. In fact, no object closure at all -- instead, this is set whenever a function is called with object notation or the new operator. Results in much confusion, particularly when creating event callbacks, because this isn't set to what the programmer expects. Corollary: calling a function without object notation or the new operator results in this being set equal to the global object, resulting in much breakage. Addition operator overloaded to also perform string concatenation, despite the two operations being fundamentally different. Results in pain when a value you expect to be a number is in fact a string. == and != operators perform type coercion. Comparisons between different types involve a list of rules that no mortal can remember in full. This is mitigated by the existence of === and !== operators. Both null and undefined exist, with subtly different, yet redundant meanings. Why? Weird syntax for setting up prototype chains. parseInt(s) expects a C-style number, so treats values with leading zeroes as octal, etc. You can at least parseInt(s, 10) but the default behaviour is confusing. No block scope. Can declare the same variable more than once. Can use a variable without declaring it, in which case it's global and probably breaks your program. with { }. Really difficult to document with JavaDoc like tools.