最近Stack Overflow上有一群讨厌perl的人,所以我想我应该把我的“关于你最喜欢的语言你讨厌的五件事”的问题带到Stack Overflow上。拿你最喜欢的语言来说,告诉我你讨厌它的五件事。这些可能只是让你烦恼的事情,承认的设计缺陷,公认的性能问题,或任何其他类别。你只需要讨厌它,它必须是你最喜欢的语言。

不要拿它和其他语言比较,也不要谈论你已经讨厌的语言。不要用你最喜欢的语言谈论你喜欢的事情。我只是想听到你讨厌但能容忍的东西,这样你就可以使用所有其他的东西,我想听到你希望别人使用的语言。

每当有人试图把他们最喜欢的语言强加给我时,我就会问这个问题,有时是面试问题。如果有人找不出他最喜欢的工具的5个缺点,那他对它还不够了解,不能提倡它,也不能利用它赚大钱。他还没有在足够多的不同情况下使用它来充分探索它。他把它作为一种文化或宗教来倡导,这意味着如果我不选择他最喜欢的技术,我就错了。

我不在乎你用什么语言。不想使用特定的语言?那就不要。你通过尽职调查做出了明智的选择,但仍然没有使用它?好吧。有时正确的答案是“你有一个强大的编程团队,有良好的实践和丰富的Bar经验。改成Foo是愚蠢的。”


This is a good question for code reviews too. People who really know a codebase will have all sorts of suggestions for it, and those who don't know it so well have non-specific complaints. I ask things like "If you could start over on this project, what would you do differently?" In this fantasy land, users and programmers get to complain about anything and everything they don't like. "I want a better interface", "I want to separate the model from the view", "I'd use this module instead of this other one", "I'd rename this set of methods", or whatever they really don't like about the current situation. That's how I get a handle on how much a particular developer knows about the codebase. It's also a clue about how much of the programmer's ego is tied up in what he's telling me.

憎恨并不是衡量人们了解多少的唯一尺度,但我发现它是一个相当不错的尺度。他们讨厌的事情也让我知道他们对这个话题的思考有多好。


当前回答

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.

其他回答

length属性很容易与length()函数混淆;请改用size() 在选择器字符串中插入变量的语法('" +$。Month + "')臭死了 $(event.currentTarget)并不总是适用于冒泡和捕获 属性语法("[class='foot']")在选择器语法(".foot")不返回任何结果的地方起作用 包含选择器([class~=done])有时会在JavaScript (this.className.search("done") > 0)工作时失败

我讨厌Java的五个方面:

没有一级函数。 没有类型推断。 缺乏理智的默认值在eg图形。 NullPointerException不包含更多关于什么是null的信息。 毫无意义的“可配置”框架/服务提供者接口/工厂类/依赖注入系统的激增。可配置性几乎从未使用过,严重违反了DRY,代码的大小增加了四倍,易读性减少了一半。

我知道,我应该试试Scala。

Python

慢 我终于习惯了打印语句,现在有了这个打印函数??(py3k) 从来没有得到py2exe或cxFreeze工作 不标准化(轻微挑剔) 递归深度只有100 (iirc)

C#

我的大部分抱怨都与假设c++约定自动成为c#的最佳选择有关

Class接口中不允许静态。这仍然是课程的一部分。为什么它不能成为界面的一部分?我不得不想出这么愚蠢的变通办法。 区分大小写。我知道在这一点上它会破坏遗留的应用程序,但为什么不区分大小写不是一开始的规则

对于。net的好处之一(不是c#特有的)

编译器不够聪明。在。net 3中。X,编译器可以找出“var”在编译时,为什么不其他常见的优化?我们都知道string和StringBuilder / immutable和mutable的区别。为什么编译器不为你转换它在很多情况下,显然StringBuilder比多个connect .s更好?我相信在默认情况下,编译器可以为我们做大量的其他优化(带有否决选项),并为我们节省大量的时间。

D

we have in operator, but no !in operator? dynamic array 'length' property - ya canna do array.length += 512; no exit statement - as in python's sys.exit(), etc. Sure, you can call C's exit, but unflushed output don't get flushed associative array literals + string literals suck string literals found as is inside an associative array literal are interpreted as static, thus this char[][char[]] hash = ["hello":"world","goodbye":"angels"]; doesn't work without some extra casting due to different length string literals despite a. I didn't ask it to be interpreted as static arrays b. static arrays aren't allowed in associative arrays anyways cyclic dependencies disallowed (want to port that java lib? Have fun redesigning the class hierarchy)

谁帮我检查一下;不确定它们是否都有意义。