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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Computers are made of metal, not category theory

80 点作者 stakent超过 10 年前

24 条评论

exDM69超过 10 年前
If you take a look at how the GHC Haskell compiler (A &quot;Sufficiently Smart Compiler(tm)&quot; in my opinion) works, for example, it is not naively pushing allocating objects, creating thunks and emitting trampoline code.<p>Instead, it analyzes the program structures from graphs and emits rather efficient machine code in the end. Not too dissimilar from what your native code emitting C compiler does.<p>If you look at the machine code for something as &quot;stupid&quot; as the Haskell example below, the output object code does not resemble the semantics of the source program at all. (it&#x27;s not quite as efficient as the same from a C compiler, but still proves a point)<p><pre><code> foreign export ccall fac :: Int -&gt; Int fac :: Int -&gt; Int fac n = foldl (*) 1 . take n $ [1..] </code></pre> Compiler and programming language research is a very important topic that yields real performance benefits as well as better programmer productivity. That includes using Category theory to reason about program correctness.<p>If you&#x27;re interested in how the Haskell compiler works, &quot;Implementation of Functional Programming languages&quot; is a good (albeit a bit outdated) starting point. The whole book is freely available here: <a href="http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/" rel="nofollow">http:&#x2F;&#x2F;research.microsoft.com&#x2F;en-us&#x2F;um&#x2F;people&#x2F;simonpj&#x2F;papers...</a><p>I do agree with the title a bit, though. Some of our computer programming environments are just ridiculously slow. Being slow also means &quot;consumes a lot of power&quot; which is important when more and more computers are powered by batteries.
评论 #8395466 未加载
评论 #8396168 未加载
评论 #8395441 未加载
评论 #8395712 未加载
评论 #8395633 未加载
评论 #8395391 未加载
评论 #8396399 未加载
nine_k超过 10 年前
Aircraft are made of metal, not fluid dynamics. Rockets are made of metal, not ballistics equations. Nuclear bombs are made of metal, not quantum theory.<p>Well, metal <i>is</i> important, but to put it to any use other than very naïve fiddling with it, good abstractions are indispensable.<p>Flamebait titles, on the other hand, don&#x27;t help it the smallest bit.
dxbydt超过 10 年前
When you first wrote about how hadoop is a waste of time if you don&#x27;t have multi-TB worth of data (<a href="http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html" rel="nofollow">http:&#x2F;&#x2F;www.chrisstucchio.com&#x2F;blog&#x2F;2013&#x2F;hadoop_hatred.html</a> ), I thought that was classic linkbait. And then I actually started seeing real benefits of not doing map-reduce for smaller datasets ( small = 1GB-1TB) &amp; just sticking to plain old scala ( poso as opposed to pojo :) Similarly, this article seems linkbait on the surface but makes a lot of sense if you do anything performance intensive. I recently tried implementing a multi layer neural net in Scala - I eventually ended up rewriting your mappers as while loops &amp; introduce some mutables, because at some point, all this FP prettiness is nice but not very performant. It looks good as textbook code for toy examples, but takes too long to execute. Am still a huge fan of FP, but nowadays I don&#x27;t mind the occasional side effect &amp; sprinkling some vars around tight loops. Its just much faster, &amp; sometimes that is important too.
评论 #8403339 未加载
rollo超过 10 年前
What I took from this post, is that we should keep working on compilers. They could provably optimize away most of the performance issues and move us closer to doing category theory instead of dealing with the metal.
评论 #8395163 未加载
评论 #8394988 未加载
dons超过 10 年前
Title is misleading. This is about some Scala microbenchmarks. There is no CT or metal here.
chriswarbo超过 10 年前
The metal is also made of category theory:<p><a href="http://conal.net/blog/posts/circuits-as-a-bicartesian-closed-category" rel="nofollow">http:&#x2F;&#x2F;conal.net&#x2F;blog&#x2F;posts&#x2F;circuits-as-a-bicartesian-closed...</a>
chriswarbo超过 10 年前
Related links:<p>Cost semantics <a href="http://lambda-the-ultimate.org/node/5021" rel="nofollow">http:&#x2F;&#x2F;lambda-the-ultimate.org&#x2F;node&#x2F;5021</a><p>Recent efforts to bring together &quot;logical&quot; CS (lambda calculus, type theory, etc.) and &quot;combinatorial&quot; CS (machine models, big-O, etc.) <a href="http://existentialtype.wordpress.com/2014/09/28/structure-and-efficiency-of-computer-programs/" rel="nofollow">http:&#x2F;&#x2F;existentialtype.wordpress.com&#x2F;2014&#x2F;09&#x2F;28&#x2F;structure-an...</a>
yzzxy超过 10 年前
I&#x27;m no expert on these matters, but it seems a bit ridiculous to call out entire swaths of the programming&#x2F;computer science world while referencing the JVM as a benchmark.
评论 #8394971 未加载
评论 #8394856 未加载
cantankerous超过 10 年前
Good read. Minor quibble: I&#x27;m not sure calling Julia a functional language is really a fair statement. Yes it&#x27;s LISP-like, but if you want to go there, Ruby is a LISP-like language in the same ways Julia is. I don&#x27;t really encounter many folks making the claim that Ruby is a functional language.
评论 #8395394 未加载
minimax超过 10 年前
The most important thing here is to measure. Always measure. It doesn&#x27;t matter what you think is going to be fast or not. The combination of super smart (or not so smart) compilers, multi-level hierarchal caches, pipelining, branch (mis)prediction, etc means you can&#x27;t just look at a piece of code in a high level language and know how fast it will be. You always have to run the code and measure how long it takes. For anything where you really care about latency, measure.
评论 #8395505 未加载
kyllo超过 10 年前
Computers are metal but programming languages are for humans. The purpose of functional abstractions is primarily to help humans produce correct code, not necessarily to optimize for speed. Referentially transparent functions, immutable data and type checking are meant to provide guarantees that reduce complexity, make a program easier to reason about and help stop the programmer from introducing costly and dangerous bugs. It doesn&#x27;t matter how fast your &quot;fugly imperative code&quot; is, if it&#x27;s incorrect. And the lesson we&#x27;ve learned the hard way over and over again is that humans are just not smart enough to reliably write correct fugly imperative code.
评论 #8395973 未加载
chriswarbo超过 10 年前
Quick question: when the article calls a pair of mutually-recursive functions &quot;corecursive&quot;, is this a commonly-used meaning of the term, or just a mistake (since they&#x27;re certainly not corecursive in the coinductive sense)
评论 #8395522 未加载
Rusky超过 10 年前
Computers <i>are</i> &quot;made of metal&quot;, and category theory does often lead far away from that reality. But that doesn&#x27;t mean function calls are slow, or that we need Sufficiently Smart Compilers just to use map efficiently.<p>What it means is that abstractions should be designed with both the use and the implementation in mind. One way to do that is &quot;zero-cost abstractions&quot; a la C++, where the abstractions are pretty minimal. Another way is things like stream fusion and tco, where it&#x27;s easy to accidentally stray out of the efficiently representable subset.<p>But there are a lot of ways to get abstractions that are both higher-level and &quot;zero-cost&quot; (generating the code you would have if you hadn&#x27;t used them). For example, Python generators and C# iterators (coroutine-looking functions internally transformed into state machines) look a lot like Haskell higher-order functions but the benefits of laziness and stream fusion and tco are just built into the abstraction, rather than optimizations that may or may not happen, depending on the language&#x2F;compiler. They also turn out to be more flexible, since the iterator state is reified.<p>Another example is entity-component systems in game engines. You still get a nice abstraction of game-world objects composed from behaviors, like you might see in an OO hierarchy, but the cache behavior is vastly improved and the behaviors are again more flexible.
mrwilliamchang超过 10 年前
Love the title.<p>A more common mistake I notice people making is writing code that makes more memory allocations than necessary.<p><pre><code> # Bad: Makes an extra instantiation of a list with 1 in # it which then needs to be read x = set([1]) # Good x = set() x.add(1) </code></pre> Overall, I think it is important to remember that when you write a program that every step translates to a set of operations. And this applies to all kinds of programming, not just functional programming.
评论 #8397383 未加载
sitharus超过 10 年前
When I started programming it was ZX Spectrum BASIC. No abstractions other than some symbols. Then I moved on to Perl, then PHP and eventually C# - all increasing abstraction from the hardware, but all mutable state and based off how hardware works.<p>Recently I&#x27;ve started moving on to F# and Haskell, and it&#x27;s really opened my eyes.<p>While computers keep getting faster the humans who input the programs do not. While programming is about getting a computer to do things the most important part is making it do what you want it to to. Anything that helps humans reason about what the computer will do - rather than exactly how - is a good thing in my book.
sklogic超过 10 年前
Stalin and MLton are sufficiently smart. Probably too smart in some cases.
ffn超过 10 年前
One can just as easily make the counter-argument people understand theory, not computer instructions. So the cleaner and more functional your code is, the easier (and faster) it becomes for other people to build on top of &#x2F; around it.<p>But that counter-argument only works given that the current application requires tons of people of work on your code. Just as the article&#x27;s argument works only if you actually need to squeeze out those extra ms on your 1 machine.<p>My only take away from this is &quot;use the right tools for the right job&quot;.
mcguire超过 10 年前
I&#x27;m a little confused: the author is speaking of &quot;metal&quot; but isn&#x27;t writing assembly.<p>(And I&#x27;m a little snarky today.)
Tloewald超过 10 年前
Surely the point is to use an effective language (for your particular definition of effective) and then optimize based on performance testing. Otherwise you lose time writing fast low level code that doesn&#x27;t need to be fast or low level, and possibly never get to the important stuff.
评论 #8396156 未加载
serve_yay超过 10 年前
Well, OK. I have never seen anyone argue that functional programming is beneficial for performance reasons.
评论 #8396127 未加载
评论 #8395934 未加载
tlarkworthy超过 10 年前
silicon is not really metal[1], it&#x27;s rock. It&#x27;s the most abundant element on earth &amp; the universe, which I find interesting. Most of our planet and universe could be turned into a giant computer.<p>[1] it&#x27;s a metaloid
评论 #8396689 未加载
dschiptsov超过 10 年前
<p><pre><code> - There is nothing absolute in the world. - Metal rails are.</code></pre>
jcromartie超过 10 年前
He keeps using the word &quot;pointer&quot; ...
bkeroack超过 10 年前
&quot;No, don&#x27;t take away my beautiful abstractions!&quot;