HyperTalk:

很久很久以前就死了 没有简单的赋值(你不能说a:= 3，你必须说把3放进a 没有嵌套函数 没有真正的数据结构，只有字符串。要创建“列表”，您可以使用itemDelimiter分隔项并手动转义它们。你也可以得到行和单词比如txt的第5行第2个单词

说句题外话，我认为HyperTalk最酷的独特功能之一是特殊的it变量:

ask "How many years old are you?"
answer "You are " & it*12 & " months old."

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

C#

Lack of multiple dispatch based on the runtime type of the method arguments. dynamic should solve most of this, but it hasn't been released yet. Interface implementation is declarative not structural. I really like the way Google's Go language is doing types Making asynchronous method calls is really bulky (and I'm pretty sure all threads are OS threads, not lightweight threads) No macro system. I'm not talking about C-style macros here; I'm talking LISP/Scheme style macros Operators are static methods and their signatures are overly constrained (and you can't create new ones).

经过一些思考后重写了这篇文章…

虽然我喜欢PHP，但我讨厌它的五个方面(排名不分先后):

内置函数中的命名和参数顺序不一致。 面向对象的数组方法多亏了SPL，但遗憾的是还没有字符串。 PHP本身没有真正的并发，只有通过托管web服务器的多处理 没有像JavaScript那样的异步调用 只能通过扩展进行操作码缓存。不是很糟糕，只是有点烦人。

这些是令我烦恼的语言特性(或缺乏)，但更大的问题是这些与人/社区相关的东西:

事实上，很多使用PHP的人，对编程和良好实践一无所知，从而产生了非常混乱的代码。JavaScript也有同样的问题。 大量的教程/书籍传授了非常糟糕的做法和风格。这可能是第三条的主要原因。 它的坏名声主要是因为第三条和第四条。

VBA(因为你认为你的语言不好)

Whitespace inside a line is rigidly enforced. Statements just end, and require a " _" to break to the next line, but not every line can be broken. No ++,--,+=,-= statements. Seriously? Arrays can begin at any index, not just 0. Some types (i.e.: fixed-point "Decimal" value) must be subtypes of Variant, and aren't available as their own type. != and <>. "=" is used as both comparator and assigning, instead of splitting into "=" and "==". "Option Explicit". UI hasn't been updated since 2000. Office2k7 didn't upgrade to VB.NET Most object models are non-sensical and overly verbose.

TCL

这是我最喜欢的语言，几乎可以做任何事情。多年来，它已经(慢慢地，非常缓慢地)演变为解决大多数让我烦恼的事情。而且这门语言非常灵活，很容易实现语法来覆盖那些仍然困扰我的东西。但是语言中有一些东西是不能轻易改变的，只是打破了它的禅意:

Arrays (of the associative kind, what Perl calls hash) don't have proper value semantics. This makes them awkward to pass to and return from functions. Also, this means that they can't be nested. For this reason dicts (dictionaries) were invented but too late, the nice array access syntax: $array($foo) is now forever taken by stupid arrays for backwards compatibility. We're now stuck with: dict get $dict $foo which is much more verbose and to me feels less readable. No real closures. Though it can be emulated somewhat by globals or namespaces but that defeats the reason for closures in the first place. Although, I can't really see for now how closures can be implemented in a pure value semantics system. Teacup is hard to use and is not at all intuitive compared to all other repository tool out there. This is more ActiveState's fault than tcl-core and doesn't really break tcl's Zen when coding but it is still very annoying.