Python方法声明中的显式self是糟糕的设计选择。

方法调用有语法糖，但声明没有。这是一个有漏洞的抽象(故意的!)，会导致令人讨厌的错误，包括运行时错误，在报告的参数数量中明显少了一个错误。

c++是有史以来最糟糕的编程语言之一。

它具有委员会设计的所有特征——它不能很好地完成任何给定的工作，而且某些工作(如面向对象)做得很糟糕。它有一种“厨房水槽”的绝望，不会消失。

它是学习编程的可怕的“第一语言”。你(从语言中)得不到优雅，得不到帮助。取而代之的是陷阱和雷区(内存管理、模板等)。

它不是一种学习面向对象概念的好语言。它表现为“带有类包装器的C”，而不是一种合适的OO语言。

我可以继续讲下去，但现在就讲到这里。我从来不喜欢用c++编程，虽然我是在FORTRAN上“磨砺”的，但我完全喜欢用C编程。我仍然认为C是最伟大的“经典”语言之一。在我看来，c++肯定不是这样的。

欢呼,

-R

EDIT: To respond to the comments on teaching C++. You can teach C++ in two ways - either teaching it as C "on steroids" (start with variables, conditions, loops, etc), or teaching it as a pure "OO" language (start with classes, methods, etc). You can find teaching texts that use one or other of these approaches. I prefer the latter approach (OO first) as it does emphasize the capabilities of C++ as an OO language (which was the original design emphasis of C++). If you want to teach C++ "as C", then I think you should teach C, not C++.

但就我的经验而言，c++作为第一语言的问题在于，这门语言太大了，无法在一个学期内教授，而且大多数“介绍”文本试图涵盖所有内容。在“第一语言”课程中涵盖所有主题是不可能的。在我看来，你至少要把它分成两个学期，然后它就不再是“第一语言”了。

我确实教c++，但只是作为一种“新语言”——也就是说，你必须精通一些先前的“纯”语言(不是脚本或宏)，然后才能注册这门课程。在我看来，c++是一种很好的“第二语言”。

-R

另一个编辑:(对康拉德)

I do not at all agree that C++ "is superior in every way" to C. I spent years coding C programs for microcontrollers and other embedded applications. The C compilers for these devices are highly optimized, often producing code as good as hand-coded assembler. When you move to C++, you gain a tremendous overhead imposed by the compiler in order to manage language features you may not use. In embedded applications, you gain little by adding classes and such, IMO. What you need is tight, clean code. You can write it in C++, but then you're really just writing C, and the C compilers are more optimized in these applications.

I wrote a MIDI engine, first in C, later in C++ (at the vendor's request) for an embedded controller (sound card). In the end, to meet the performance requirements (MIDI timings, etc) we had to revert to pure C for all of the core code. We were able to use C++ for the high-level code, and having classes was very sweet - but we needed C to get the performance at the lower level. The C code was an order of magnitude faster than the C++ code, but hand coded assembler was only slightly faster than the compiled C code. This was back in the early 1990s, just to place the events properly.

-R

全局变量和/或单例变量本身并不邪恶

我来自更多的系统管理员，shell, Perl(和我的“真正的”编程)，PHP类型的背景;去年我被派去做Java开发工作。

单身是邪恶的。全球人太邪恶了，他们甚至不被允许。然而，Java有像AOP这样的东西，现在还有各种“依赖注入”框架(我们使用谷歌Guice)。AOP就不是这样了，但是DI的东西肯定会给你什么?全局变量。啊,谢谢。

观点:开发者应该测试自己的代码

我曾经见过太多的垃圾交付给测试，但实际上并没有修复问题中的bug，导致了沟通开销，并助长了不负责任的实践。

代码布局很重要

也许双括号位置的细节应该保持纯粹的宗教争论-但这并不意味着所有的布局风格都是平等的，或者根本没有客观因素!

问题在于布局的超级规则，即:“保持一致”，尽管听起来不错，但被许多人用作拐杖，从不尝试看看他们的默认风格是否可以改进——而且，这甚至无关紧要。

几年前，我正在学习快速阅读技术，我学到的一些东西是关于眼睛如何在“固定”中获取信息，如何最优地扫描页面，以及潜意识中拾取上下文的作用，这让我思考如何将其应用到代码中——尤其是在编写代码时牢记它。

它使我形成了一种本质上倾向于柱状的样式，在可能的情况下对标识符进行逻辑分组和对齐(特别是我严格要求每个方法参数都在自己的行上)。然而，与一成不变的长柱结构相比，以块为单位改变结构实际上是有益的，这样你最终会得到眼睛可以在一个固定装置中接受的矩形岛屿——即使你没有有意识地阅读每个字符。

最终的结果是，一旦你习惯了它(通常需要1-3天)，它就会变得赏心悦目，更容易理解，对眼睛和大脑的负担也更少，因为它的布局方式更容易接受。

几乎无一例外，我邀请的每个尝试这种风格的人(包括我自己)一开始都说，“啊，我讨厌它!”，但过了一两天就说，“我喜欢它——我发现很难不回头用这种方式重写我所有的旧东西!”

我一直希望有时间做更多的对照实验，以收集足够的证据来写一篇论文，但一直忙于其他事情。然而，这似乎是一个向那些对有争议的技术感兴趣的人提及它的好机会:-)

(编辑)

我终于抽出时间把这件事写在博客上(在“意义”阶段停留了很多年之后):第一部分，第二部分，第三部分。

软件架构师/设计人员被高估了

作为一名开发人员，我讨厌软件架构师这个概念。他们基本上不再全职编码，阅读杂志和文章，然后告诉你如何设计软件。只有那些真正以全职编写软件为生的人才应该这样做。我不在乎5年前你在成为架构师之前是不是世界上最好的程序员，你的观点对我来说毫无用处。

这有争议吗?

编辑(澄清一下):我认为大多数软件架构师都是出色的业务分析师(与客户交谈，编写需求，测试等)，我只是认为他们在设计软件方面没有一席之地，无论是高级的还是其他的。