I have to agree. Haskell is an elegant and expressive language, and I too believe it is better suited to the point-free style than is Clojure, or any lisp. The way Haskell auto-curries functions is very conducive to point-free.

Thanks for you dropping by.

drc

Very good exploration of the algebra of the code. It’s a good exercise.

I think this goes to show that Clojure is not so great for expressing point-free style. It is very hard to read your example and know what it does. It is expecially clear when compared to the simple fn based version you presented, which is extremely clear.

I use Haskell at work, and it is much better for point-free style since every application is partial application (so you don’t have to be explicit about it) and composition is a single infix character. Though Haskell has its own issues, for instance composition is limited to functions of one argument, and in this case repeat takes two!

Well, all languages have their tradeoffs. I think Haskell wins out on this one because the solution to this problem is just to use the exponentiation function itself. However, it is not too often where it gets in the way in Clojure.

Thanks again!

Eric

If you like this approach to thinking about programming, check out R.S. Bird’s Algebraic Identities for Program Calculation.

]]>My favorite part of your post is your exploration of the unique compositional properties of point-free code, and your extraction of ‘mult’. The “dynamic vs. lexical” scopes issue is nowhere in sight, because variables have been removed completely from the story! There is only one, very simple substitution rule – definitions expand to functions.

In most peoples’ minds, and in mine until I was exposed to John Backus’s ideas, “point-free” is synonymous with “pointless”. I think you prove here that this is not the case, deriving both reusable code and abstractions from the exercise.

Your mathematical destructuring of the problem reminds me a lot of the algebra that Backus derives as the basis for his Function Level paradigm, and this is the same paradigm that inspired my initial tweet.

I highly recommend checking out http://archive.org/details/JohnBack1987 and http://dl.acm.org/citation.cfm?id=21855.21859&coll=DL&dl=GUIDE&CFID=90748351&CFTOKEN=52866005. I think you’ll be amazed by how far Backus goes with some of the ideas you stumbled on in your own exploration!

]]>I guess somewhere I added inappropriate intermediate comps/partials.

But thanks to your reminder of systematic application of equational reasoning, I was able to “reduce” the above to the original (reduce * (repeat x y)) form :)

]]>+5 Insightful.

]]>You are most welcome. It did take some work, but it was also a lot of fun. I’m a bit of a puzzle junkie, and Project Euler is a superb collection.

‘Real’ programming, the kind we get paid to do, often involves challenges such as crushing time constraints, incomplete and changing specifications, legacy tools, and insane complexity due to reasons all too familiar. It is a pleasure to spend time in the place where mathematics and programming meet, where problems are crisply defined, and where I can choose my weapons. I was a functional programmer before it was hip, and I very much want to see functional programming become a dominant paradigm. If I can help someone to see that fp can be elegant, simple, and fun, I will be pleased. That’s why I put this together.

We are fortunate to live in a time when amazing tools such as Clojure, Leiningen, Marginalia, Mercurial, and Emacs are available for the asking. I am grateful to be the beneficiary of so much work by so many gifted individuals. I hope they too are having fun. And special thanks to Project Euler. You guys rock.

]]>Thanks for the kind words, I appreciate them.

Something that slipped by me was an absolute file path in problem 22, that should have been a relative path. This pointed out to me by @danieroux in a pull request. I have since corrected the path in the repo.

David

]]>