3 ms·
Looks like he was wrong on the Lisp front then. But actually all your examples kind of strengthen one of the points of the article (for me). That is that of we
by discreteevent 13y ago
Looks like he was wrong on the Lisp front then. But actually all your examples kind of strengthen one of the points of the article (for me). That is that of we want to get things done, make a difference, then we should be focusing on applied maths and not the lambda calculus and category theory. Only a very few people are needed to focus on those things. For the rest of us a focus on those things means taking our eye off the ball to the detriment of what we work on (as an industry).
I like your point about the blog posts. If you want to find out how to really make things they're often not where it's at.
- lispm 13y agoHaving better programming tools is a useful goal. Writing applications is another one. Not all applications need advanced maths, though. In many Lisp applications many different kinds of maths have been necessary and used. All kinds of symbolic and numeric mathematics have been used. But Lisp has been also a topic of study and research - as it is also an application of symbolic mathematics. See for example Chaitin, The Limits of Mathematics. https://www.cs.auckland.ac.nz/~chaitin/lm.html https://www.cs.auckland.ac.nz/~chaitin/lm.html or the research on Scheme: http://library.readscheme.org http://library.readscheme.org .
- sixbrx 13y agoI couldn't disagree more strongly. I think systems built on the lambda calculus are building nothing less than a new form of constructive mathematics, taking it squarely out of philosophy and into the realm of practicality. Theorem provers will only get stronger, and they will change a lot about how mathematics is done. I do finite element methods myself, and Rust has helped a lot in writing allocation-free code (meaning allocation-up-front really), and it has benefited a lot from functional/induction-centric languages.