4 ms·

> I think she might have given up on programming a bit prematurely. The pendulum has obviously swung completely the other way with high level languages like Has

• 1123581321 13y ago
  I believe she worked on optimizers her entire career as a logician, scientist and manager rather than as an implementing programmer. http://www-03.ibm.com/ibm/history/witexhibit/wit_hall_allen.html http://www-03.ibm.com/ibm/history/witexhibit/wit_hall_allen.... http://amturing.acm.org/award_winners/allen_1012327.cfm http://amturing.acm.org/award_winners/allen_1012327.cfm
• habitue 13y ago
  > C compilers were optimizing long before Haskell Right, and they've come up with some excellent tricks too. But the reason she felt optimization wasn't going to progress as far is because C is a lower level language than some of the other languages out at the time, and there are necessarily less tricks you can do in a lower level language because you have to infer the intent of the programmer more, and rely on optimizing idioms etc, rather than optimizing actual constructs of the language. How does a compiler optimize a single "goto"? There isn't much it can do unless, for instance, it notices that the goto is found in an idiomatic pattern that results in a loop. Then it can make a decision whether to unroll the loop or not. If the language gives you the loop construct, it can skip the "recognize the idiom" step (and the associated risk of guessing wrong), and go right to optimizing loops. Similarly, in higher level languages than C, the programmer can express their intent more directly, and therefore the compiler can take less risks when guessing "Ah, I see what you're trying to do, here's the fastest assembly that accomplishes that"
  • waps 13y ago
    To convince C users why Haskell has the potential (but currently only potential) to optimize better, it is best to just point to one example that C can never hope to optimize : deforestation. http://book.realworldhaskell.org/read/profiling-and-optimization.html#id679430 http://book.realworldhaskell.org/read/profiling-and-optimiza... C will never be able to do that. Before optimization : the programmer requests a list to be created, fill it by calling functions and then passes the completed datastructure list (or tree) along to another function, which executes commands according to what the list contains. After optimization there is no more list. Instead the function the list is passed to will call a generated function that generates exactly the needed elements of the tree just-in-time. Result: no list, no memory (aside from 1 element on the stack), no allocation, no clearing of memory afterwards. Of course the downside is that it's very tempting (and encouraged) to write programs that don't contain these optimizations you'd have to do manually in C/Java/... and just have them run. What you'll miss as a Haskell programmer is that the program is effectively dependent on those optimizations for it's complexity (for example: optimized program is O(n), program as written is O(n^n). Then you insert what looks like a tiny change, say, sorting the list, which prevents optimization from happening and boom, your binary switches from O(n) to O(n^n). All tests will obviously pass, yet your boss is unlikely to be happy ... At this point it is extremely hard to figure out what just happened)