这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
从长远来看，开源软件的成本更高
对于常规的业务公司来说，开源看起来是免费的，但隐藏着成本。
当你考虑到质量的不一致性，可变的可用性和UI/UX，互操作性和标准的困难，增加的配置，相关的培训和支持需求的增加，开源的总拥有成本要比商业产品高得多。
精通技术的程序员类型接受开源的解放并与之一起运行;他们“得到它”，可以采用它，并定制它，以满足他们的目的。另一方面，主要是非技术性的，但需要软件来运行他们的办公室、网络和网站的企业正在冒着痛苦的风险，并在时间损失、生产力和(最终)支持费用方面付出沉重的代价，以及/或一起放弃实验的成本。
其他回答
原始数据类型是不成熟的优化。
有些语言只使用一种数据类型，即标量，它们做得很好。其他语言就没有这么幸运了。开发人员只是把“int”和“double”扔进去，因为他们必须写一些东西。
What's important is not how big the data types are, but what the data is used for. If you have a day of the month variable, it doesn't matter much if it's signed or unsigned, or whether it's char, short, int, long, long long, float, double, or long double. It does matter that it's a day of the month, and not a month, or day of week, or whatever. See Joel's column on making things that are wrong look wrong; Hungarian notation as originally proposed was a Good Idea. As used in practice, it's mostly useless, because it says the wrong thing.
可用性问题从来不是用户的错。
当某些用户做了一些团队中所有人都认为“只是一件愚蠢的事情”时，我无法计算问题出现的频率。像“为什么有人要这么做?”或者“为什么他不做XYZ”这样的短语经常出现。
尽管许多人已经厌倦了听我说:如果一个现实生活中的用户试图做一些事情，要么没有工作，导致一些错误或导致意想不到的行为，那么这可能是任何人的错，而不是用户的错!
请注意，我不是指那些故意滥用软件的人。我指的是软件的假定目标组。
设计模式对优秀设计的伤害大于帮助。
IMO软件设计，尤其是优秀的软件设计，变化太大，无法在模式中有意义地捕捉，特别是在人们实际能记住的少量模式中——而且它们太抽象，人们实际上只能记住少数几个。所以他们帮不上什么忙。
另一方面，太多的人迷恋于这个概念，并试图在所有地方应用模式——通常，在生成的代码中，你无法在所有(完全没有意义的)单例和抽象工厂之间找到实际的设计。
我坚信非托管代码不值得这么麻烦。与查找内存泄漏相关的额外维护性开销(即使是最好的程序员偶尔也会引入这种开销)远远超过从c++这样的语言获得的性能。如果Java, c#等不能得到你需要的性能，买更多的机器。
(未命名)元组是邪恶的
如果您使用元组作为具有唯一含义的多个对象的容器，请改用类。 如果您使用它们来保存几个应该通过索引访问的对象，请使用列表。 如果您使用它们从一个方法中返回多个值，请使用Out参数(这需要您的语言支持引用传递) 如果这是代码混淆策略的一部分，那就继续使用它们!
我看到人们使用元组只是因为他们懒得给他们的对象命名。API的用户将被迫基于无意义的索引(而不是有用的名称)访问元组中的项。
