这个问题来自于对过去50年左右计算领域各种进展的评论。
其他一些与会者请我把这个问题作为一个问题向整个论坛提出。
这里的基本思想不是抨击事物的现状,而是试图理解提出基本新思想和原则的过程。
我认为我们在大多数计算领域都需要真正的新想法,我想知道最近已经完成的任何重要而有力的想法。如果我们真的找不到他们,那么我们应该问“为什么?”和“我们应该做什么?”
这个问题来自于对过去50年左右计算领域各种进展的评论。
其他一些与会者请我把这个问题作为一个问题向整个论坛提出。
这里的基本思想不是抨击事物的现状,而是试图理解提出基本新思想和原则的过程。
我认为我们在大多数计算领域都需要真正的新想法,我想知道最近已经完成的任何重要而有力的想法。如果我们真的找不到他们,那么我们应该问“为什么?”和“我们应该做什么?”
当前回答
受保护的内存。在保护内存之前,如果你的程序犯了错误,你可以在任何地方开始执行代码——实际上总是挂起整个机器。没错,重启时间到了!
硬件成本低。我的第一台电脑在1978年花了500美元——这在当时是一笔巨款。降低成本让每个人的办公桌上都有了电脑。
其他回答
我认为这些答案的部分问题是,它们要么没有得到充分的研究,要么是在尝试一种新的实现或一些已经看到重大“改进”的技术。然而,这并不是一项重大发明。例如,任何关于函数式编程或面向对象编程的讨论都是失败的;这些想法在大多数SO参与者出生之前就已经流传了。
这是一个消极的结果,作为一个“基础创新”很奇怪,但我认为适用,因为它开辟了新的研究领域,关闭了无用的领域。
分配共识的不可能性:2001年PODC影响力论文奖
We assumed that the main value of our impossibility result was to close off unproductive lines of research on trying to find fault-tolerant consensus algorithms. But much to our surprise, it opened up entirely new lines of research. There has been analysis of exactly what assumptions about the distributed system model are needed for the impossibility proof. Many related distributed problems to which the proof also applies have been found, together with seemingly similar problems which do have solutions. Eventually a long line of research developed in which primitives were classified based on their ability to implement wait-free fault-tolerant consensus.
互联网。
就是这样。
我没有资格在一般意义上回答这个问题,但仅限于计算机编程?并不多。
为什么?我思考这个问题已经有一段时间了,我认为我们缺少两样东西:历史感和客观评价我们所创造的一切的方法。并非所有情况都是这样,但大体上是这样。
For history, I think it's just something not emphasized enough in popular writing or computer science programs. Take language features, for example. A canonical source might be HOPL, but it's definitely not common knowledge among programmers to be able to mark the point in time or in which language a feature like GC or closures first appeared. And of course after that there's knowledge of progression over time: how has OOP changed since Simula? Compare and contrast our sense of history with that of other fields like maybe political science or philosophy.
至于判断,这确实是我们寻求成功的客观衡量标准的失败。给定foobar,它以什么可衡量的方式改进了编程行为中的某些方面,其中foobar是任何设计模式,敏捷方法,TDD等等。我们有没有试过测量这个?我们到底想测量什么?正确性,程序员的生产力,代码的易读性等等?如何?软件工程确实应该着手解决这些问题,但我还没有看到。
用于人机交互的触摸屏和体感界面。
例如:
pda、iPhone或任天堂DS的触屏 运动感应,任天堂Wii控制器或(在较小程度上)Playstation 3的SixAxis控制器。
唯一的问题是…这些技术真的是80后吗?