TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Can Programming Be Liberated From The Von Neumann Style? (1977) [pdf]

64 点作者 jw2013大约 11 年前

8 条评论

slacka大约 11 年前
While we have achieved greatness with the Von Neumann evolutionary line, now that the Mhz free lunch is ending, it’s time for us to recognize that its sequential nature is holding us back. There are still many branches of Computer Science that researchers and industry have barely explored. We need to reevaluate these other branches like Functional and Dataflow programming.<p>Ivan Sutherland explains it best when he says that concurrency is not fundamentally hard. The problem is that we constraining ourselves to the fundamentally sequential Von Neumann architecture. <a href="https://www.youtube.com/watch?v=jR9pAaQlVRc#t=267" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=jR9pAaQlVRc#t=267</a>
评论 #7671885 未加载
评论 #7672252 未加载
评论 #7672206 未加载
cheepin大约 11 年前
I feel like &quot;industry&quot; doesn&#x27;t really want functional style programming to take over. Languages like OCaml provide really great speed while having also utilizing a relatively high abstraction level, while Lisp may not have as much speed but it takes your brain on a journey to another dimension.<p>However, in practice, people seem to just want &quot;C with Lambdas&quot; languages like Go.
评论 #7671875 未加载
评论 #7671824 未加载
评论 #7671804 未加载
评论 #7671932 未加载
评论 #7672118 未加载
signa11大约 11 年前
i would rather have a mix-n-match of different paradigms based on the task at hand. here is something that works best with an imperative style so let&#x27;s just use it, for something over-there functional style is best suited, rule-based stuff will be exactly right in this instance, let&#x27;s use that etc. etc.<p>if you have not seen sussman&#x27;s 2011 strange-loop talk &quot;We Really Don’t Know How to Compute!&quot;, please do, it is quite enlightening (whatever that means)
评论 #7671926 未加载
评论 #7671866 未加载
picktheorem大约 11 年前
a note on Haskell&#x27;s failure to liberate us from imperative IO, with a view towards frp:<p><a href="http://conal.net/blog/posts/can-functional-programming-be-liberated-from-the-von-neumann-paradigm" rel="nofollow">http:&#x2F;&#x2F;conal.net&#x2F;blog&#x2F;posts&#x2F;can-functional-programming-be-li...</a>
stiff大约 11 年前
It is funny how this paper like the writings of Dijkstra is widely cherished, while its attitude and conclusions simultaneously are completely ignored. Seems to me that people simply really like to complain about the current state of the matter, how dirty programming is and how everything is inelegant just to get back to churning code a minute later using exactly the style criticized.<p>People like Backus and Dijkstra really wanted to prove theorems about programs and do formal derivations like they were used to do in mathematics, that&#x27;s practically all they cared for, as far as their writings go. The &quot;liberation&quot; is in fact an act of bondage, an attempt to limit programming techniques to a narrow range to try to get all the noble benefits of mathematics, which is a priori assumed to be the best way to go about reasoning. It&#x27;s really ironic in the case of Dijkstra, who writes about how people cannot appreciate &quot;radical&quot; novelties and instead keep old mental habits, and then proceeds to argue how programming is just a branch of mathematics.<p>I wonder how many people who mention those papers as cornerstones of CS actually prove their programs correct on a daily basis or derive them from &quot;axioms&quot;. I actually think many people in the formal methods camp had a very narrow and limited vision of what programming is and what it will be become, and as a result turned out to be very much wrong about the importance of proofs in programming. Some of them actually admitted it:<p><a href="http://www.gwern.net/docs/1996-hoare.pdf" rel="nofollow">http:&#x2F;&#x2F;www.gwern.net&#x2F;docs&#x2F;1996-hoare.pdf</a><p>In the end, reducing all programming to formal manipulations of this kind turned out to be as successful as the ideas of axiomatization of biology. Formal methods are useful in mission-critical software, functional programming penetrated mainstream languages and is interesting in its own right, but even its proponents hardly go about writing programs the way Backus imagined; mathematical theories of programming turned out to be very limited and yield poor crops compared to the mathematical theories that turned out to be successful, hardly any new insights over what was found earlier by dabbling were found, and that is that. I love math, but it seems that programming, like biology, is actually richer than math in some sense. Consider the example Peter Norvig gives in &quot;Coders at work&quot;: how do you prove Google is correct? You immediately run into issues with the very notion of correctness, not everything can be convincingly formalized to the last detail, and we build more and more of those &quot;fuzzy&quot; systems, just consider the rise of machine learning and data mining in the last years.<p>I see no reason to go around pretending programming didn&#x27;t live up to the noble vision of the ancient masters. The masters were frequently wrong (no shame for they were pioneers of the field and nothing was known), and we simply moved on.
评论 #7672381 未加载
评论 #7672495 未加载
chubot大约 11 年前
<i>You know when toddlers try to put a round peg in a square hole? that&#x27;s how it feels using functional programming in a turing-machine-like CPU. It just don&#x27;t fit.</i><p>Yup, I agree. Functional languages failed in part because they modelled the machine poorly (Richard Gabriel has some reflections on Lisp in this area).<p>But the funny thing is that hardware has changed! Imperative programming languages are now the square peg in the round hole :)<p>Multicore machines are going to elaborate lengths to maintain the illusion of a uniform address space. But if we programmed with message passing and heterogeneous processes, then our programs would have more mechanical sympathy for the machine.<p>Shared memory and locks are basically the result of not wanting to disturb too much source code when converting from a single-threaded to a concurrent&#x2F;parallel program. But it results in poor performance and scalability, not to mention untestable and unmaintainable programs. You can look at the evolution of multicore scalability in the Linux and FreeBSD kernels, or Python and Ruby GILs (coarse grained locks in a Turing machine model), for examples of this.<p>The other thing that has changed is that our hardware is distributed (not just clusters, but also client-server). Networks are fundamentally unreliable, and that means that idempotency of subprograms is a very important property. Idempotency is of course a word from the same area of mathematics that functional programming comes from (abstract algebra).<p>The other algebraic property that is important in distributed systems is commutativity. This basically has to do with physics[1]. Commuter[2] is a nice project which addresses commutativity in interface design.<p>It&#x27;s not an accident that MapReduce and all the newer big data frameworks are based on the model of functional programming. They are using the imperative model at the scale of a single machine, where its appropriate, but the functional model at the scale of the cluster, so subprograms can be retried and executed in any order.<p>The alternative to explicitly thinking about these properties in your program design is to (only) use slow state machine protocols like Paxos. You could naively apply this transformation to your sequential programs, but you will be making very poor use of the hardware. There is a reason that they are only used for very small bits of state in distributed systems.<p>tl;dr Distributed systems (multicore included) are not Turing machines. I see a lot of bugs that are a result of people in the imperative mindset not understanding this.<p>[1] <a href="http://scholar.google.com/scholar?cluster=4892527405117123487&amp;hl=en&amp;as_sdt=0,5&amp;sciodt=0,5" rel="nofollow">http:&#x2F;&#x2F;scholar.google.com&#x2F;scholar?cluster=489252740511712348...</a> [2] <a href="http://pdos.csail.mit.edu/commuter/" rel="nofollow">http:&#x2F;&#x2F;pdos.csail.mit.edu&#x2F;commuter&#x2F;</a>
评论 #7672394 未加载
评论 #7672270 未加载
MarkPNeyer大约 11 年前
the von neumann architecture is the internal combustion engine of computing. we&#x27;ve made it do some pretty amazing stuff, but it&#x27;d be awesome to try something new.
评论 #7672222 未加载
stevesun21大约 11 年前
If you cannot write code with immutability, then don&#x27;t try to blame the programming language you are writing has no functional programming feature.