这个问题来自于对过去50年左右计算领域各种进展的评论。
其他一些与会者请我把这个问题作为一个问题向整个论坛提出。
这里的基本思想不是抨击事物的现状,而是试图理解提出基本新思想和原则的过程。
我认为我们在大多数计算领域都需要真正的新想法,我想知道最近已经完成的任何重要而有力的想法。如果我们真的找不到他们,那么我们应该问“为什么?”和“我们应该做什么?”
这个问题来自于对过去50年左右计算领域各种进展的评论。
其他一些与会者请我把这个问题作为一个问题向整个论坛提出。
这里的基本思想不是抨击事物的现状,而是试图理解提出基本新思想和原则的过程。
我认为我们在大多数计算领域都需要真正的新想法,我想知道最近已经完成的任何重要而有力的想法。如果我们真的找不到他们,那么我们应该问“为什么?”和“我们应该做什么?”
当前回答
我喜欢把它叫做互联网
其他回答
即时消息已经出现很长时间了(60年中后期),但是IRC在1988年之前还没有出现。
除此之外,视频通讯(比如,Windows Live Messenger,或Skype,或……)确实改变了我们的沟通方式;)而且是最近才出现的。
<修改> (见VideoConferencing: 1968, alt text http://wpcontent.answers.com/wikipedia/en/thumb/6/64/On_Line_System_Videoconferencing_FJCC_1968.jpg/180px-On_Line_System_Videoconferencing_FJCC_1968.jpg,正如Alan Kay自己在评论中指出的那样:
请再次查看恩格尔巴特在1968年演示的内容(包括实时视频聊天和屏幕共享)。低,猜测真的没有查东西管用。这就是为什么大多数人对事物的发明时间做不充分的假设。)
把它放在我的脸上;),这是理所当然的。
注意:那个时代的“网络摄像头”(视频设置)并不是为普通的客厅设计的;)
> < /修正
[…继续回答:]
网络摄像头替代文本http://wpcontent.answers.com/wikipedia/commons/thumb/c/c5/Logitech_Quickcam_Pro_4000.jpg/180px-Logitech_Quickcam_Pro_4000.jpg的推广也有帮助(始于1991年,第一个这样的摄像头,称为CoffeeCam,是针对剑桥大学计算机科学系的特洛伊房间咖啡壶)。
所以:80后:2 / 3:IRC和网络摄像头。
更好的用户界面。
今天的用户界面仍然很糟糕。我指的不是小的方面,而是大的、基本的方面。我不禁注意到,即使是最好的程序也仍然有一些接口,这些接口要么极其复杂,要么需要以其他方式进行大量的抽象思考,而且无法达到传统的非软件工具的易用性。
诚然,这是由于软件可以比传统工具做更多的事情。但这不是接受现状的理由。此外,大多数软件都做得不好。
In general, applications still lack a certain “just works” feeling are too much oriented by what can be done, rather than what should be done. One point that has been raised time and again, and that is still not solved, is the point of saving. Applications crash, destroying hours of work. I have the habit of pressing Ctrl+S every few seconds (of course, this no longer works in web applications). Why do I have to do this? It's mind-numbingly stupid. This is clearly a task for automation. Of course, the application also has to save a diff for every modification I make (basically an infinite undo list) in case I make an error.
解决这个问题其实并不难。在每个应用程序中都很难实现它,因为没有好的API可以做到这一点。编程工具和库必须显著改进,才能在所有平台和程序上轻松实现这些工作,适用于所有具有任意备份存储且不需要用户交互的文件格式。但在我们最终开始编写“好的”应用程序而不仅仅是足够的应用程序之前,这是必要的一步。
I believe that Apple currently approximates the “just works” feeling best in some regards. Take for example their newest version of iPhoto which features a face recognition that automatically groups photos by people appearing in them. That is a classical task that the user does not want to do manually and doesn't understand why the computer doesn't do it automatically. And even iPhoto is still a very long way from a good UI, since said feature still requires ultimate confirmation by the user (for each photo!), since the face recognition engine isn't perfect.
我没有资格在一般意义上回答这个问题,但仅限于计算机编程?并不多。
为什么?我思考这个问题已经有一段时间了,我认为我们缺少两样东西:历史感和客观评价我们所创造的一切的方法。并非所有情况都是这样,但大体上是这样。
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等等。我们有没有试过测量这个?我们到底想测量什么?正确性,程序员的生产力,代码的易读性等等?如何?软件工程确实应该着手解决这些问题,但我还没有看到。
收缩包装软件
在1980年以前,软件大多是专门编写的。如果你经营一家企业,想要计算机化,你通常会有一台计算机、编译器和数据库,然后自己写东西。业务软件通常是为适应业务实践而编写的。这并不是说没有固定的软件(我在1980年之前使用SPSS),但这不是常态,我看到的往往是基础设施和研究软件。
现在,你可以去电脑商店,在货架上找到经营小生意所需的一切。它的设计并不是为了无缝地适应您曾经拥有的任何实践,但是一旦您学会或多或少地按照它的工作流程工作,它就会很好地工作。像SAP和仁科(PeopleSoft)这样的大企业比过去更接近于收缩包装。
这并不是一个彻底的突破,但在1980年之后,有一个非常明确的转变,从昂贵的定制软件到低成本的现成软件,灵活性从软件转移到业务流程。
它还影响了软件的经济性。定制软件解决方案可以盈利,但无法规模化。你只能向一个客户收取这么多钱,你不能把同样的东西卖给多个客户。使用收缩包装软件,你可以卖出很多很多相同的东西,在一个非常大的销售基础上摊销开发成本。(你必须提供支持,但这是有限度的。就当这是销售软件的边际成本吧。)
Theoretically, where there are big winners from a change, there are going to be losers. So far, the business of software has kept expanding, so that as areas become commoditized other areas open up. This is likely to come to an end sometime, and moderately talented developers will find themselves in a real crunch, unable to work for the big boys and crowded out of the market. (This presumably happens for other fields; I suspect the demand for accountants is much smaller than it would be without QuickBooks and the like.)