HN user
I love dash; I've been using it for years.
A small wishlist:
- ClojureDocs: http://clojuredocs.org/
- Hoogle integration: http://www.haskell.org/hoogle/
- BroPages: http://bropages.org/
I do this sort of thing sporadically in my free time too... it's still good to go back and do stuff smarter when you learn better rather than accepting whatever they taught you in CS101 as the end of the story.
Given the guys programming in Javascript and not using arbitrary precision arithmetic, he's always using 64 bits and representing his numbers as floating point, so I don't think you are reasoning correctly about the asympototic complexity here. I mean, if you really want to argue this, then to quote Leibniz: "Calculemus!"
The javascript solution presented does everything in O(n) arithmetic operations, and the SICP way does it in O(ln(n)) arithmetic operations (actually, there are a lot of ways to do it in O(ln(n)) operations).
Why not try to implement the iterative O(ln(n)) Fibonacci from SICP (Ex 1.19), rather than the old O(n) one? Or the Matrix exponentiation solution (he'd probably want to implement iterative matrix exponentiation too... doesn't look like he knows clearly how to do this)? https://en.wikipedia.org/wiki/Fibonacci_number#Matrix_form
If you like doing this sort of thing, there are a million little CS problems like this codewars.com
One cool feature of the site is that you can vote on solutions; this lets you see a lot of neat solutions to problems, and learn a lot about how to write clean code.
There are a couple of GCD algorithms that have better asymptotic performance than Euclid's (an old one is due to Knuth): http://www.ams.org/journals/mcom/2008-77-261/S0025-5718-07-0...
I'm surprised the author didn't implement the binary gcd, however, although it has the same big-O as Euclid: https://en.wikipedia.org/wiki/Binary_GCD_algorithm
Not corecursive, but here's the SICP O(ln(n)) algorithm:
fibonacci = fib 1 0 0 1
where
fib a b p q n
| n == 0 = b
| even n = fib a b p' q' (n `div` 2)
| otherwise = fib a' b' p q (n - 1)
where
p' = p*p + q*q
q' = 2*p*q + q*q
a' = a*q + b*q + a*p
b' = b*p + a*qFunctional Programming is a vast subject.
I've really never needed an abstraction for semigroups, monoids, meet-semi-lattices, monads, comonads, arrows or catamorpisms in Clojure, Common Lisp, Scheme, or Hy.
These concepts become more relevant when I program Haskell, Agda, Isabelle/HOL, or Coq.
I'd say a stronger analogy can be made between reading MacLane's Catagories for the Working Mathematician and reading Hoyte's Let Over Lambda; you really only need to read a little bit of these books to get the core concepts. That being said, depending on what sort of functional programming you're doing, a strong background in category theory or meta-programming can enabling (or not).
Well, frankly you can get along not knowing the "Gang of Four" design patterns and write Java. By the same token, you don't need to know about iterables and comprehensions to write Python, smart pointers to write C++, Graph theory to use a Graph database, macros to write LISP, etc.
By analogy, you don't need to know abstract algebra and category theory to write Haskell. But as in the other cases, knowing helps.
It's a long road from "gee, I changed something, better copy everything" to something as good as FFTW or ATLAS.
CUDA implementations of FFTs and matrix operations are faster than both FFTW and ATLAS, and they are neither sequential nor functional.
CUDA, C, and Haskell all have domains they typically outperform one another. The math vs. simulation divide sketched in this blog post is more an expression of the author's own psychology more than anything else.
Why should I learn Haskell?
http://stackoverflow.com/questions/1604790/what-is-haskell-a...
For my own 2-cents, once I learned QuickCheck[1] and Parsec[2], I found myself slowly rewriting them for every language I program in.
Will it help me professionally?
Speaking as another professional, probably not.
I love Haskell, but my colleagues can't deal with it. They can't write it. They don't know functional programming. And to be entirely honest, they will never understand Monoids, Monads, or macro-hacking.
...Help me being a better programmer?
Maybe. If you like already like to think of software axiomatically, then yes, it will make you will make you think of software more conceptually.
But honestly, getting javascript, ruby and go under your belt will also make you think differently about software, and those are more practical languages.
[1] http://en.wikipedia.org/wiki/QuickCheck [2] http://www.haskell.org/haskellwiki/Parsec
Microsoft's relationship with linux is actually a bit more complicated. It was a top 5 [1] contributor to the linux kernel in 2011 and a top 20 [2] contributor in 2012. The reason here is because linux virtualization is a big deal for Microsoft Azure.
Although the rational here is fairly clear: having good linux support for Azure helps Microsoft sell its cloud service. Having good linux support for Microsoft filesystems helps people move away.
[1] http://www.zdnet.com/blog/open-source/top-five-linux-contrib...
[2] http://www.geekwire.com/2012/surprise-microsoft-list-top-lin...
Albert-Laszlo Barabasi talked about this sort of fear a few years ago in his boot Bursts[1]. He figured Google would be the one to do it. Even with dropouts occurring when someone goes into a bus, people's movements tend to have low entropy[2]. Since most people's movements follow pretty predictable routines, over time the system can learn to predict most people's positions given noisy data.
It might not work well for criminals trying to avoid being seen by arial cameras during the day, hiding out away from their usual haunts and obscuring their faces. It will probably be a big win for marketing data analytics firms.
[1] http://www.amazon.com/Bursts-Patterns-Everything-mail-Crusad...
[2] http://www.barabasilab.com/pubs/CCNR-ALB_Publications/201002...