Lisp Koans by Google | Hacker News Reader

Lisp Koans by Google

github.com

125 pointsjuanfatas30 comments

This is mildly interesting coming out of google because I thought lisp wasn't a google-approved language.

(Yes, there are other projects on github in non-approved languages, but they appear mostly to allow 3rd party interop with google services. The educational nature of this project puts it in a slightly different category.)

Lisp became a "language internally used by Google" when Google purchased ITA with a Lisp code-base so large and Lisp-only staff so large, that it is unlikely that it will ever be rewritten or that the staff will be retrained to use Java.

ITA had a small staff, and was not Lisp-only. They were hiring people to do Java work >5 years ago.

To be clear: This is a random googler's open source project, not anything official from Google.

The only reason it's part of the Google org is so that they didn't have to pay for a private project for staging.

Normally, in situations like this, they are supposed to have a disclaimer in the README that points out it's not official google anything (to avoid exactly the confusion that seems to have occurred here).

By default, Google holds the copyright to open-source projects released by Googlers. There's a review process for transferring copyright to the individual, but you don't have to go through it just to release something.

edit: See previous comments from DannyBee and cdibona here: https://news.ycombinator.com/item?id=4051325

Yes. The fact that we own some code doesn't mean it's officially supported. It just means we try to maintain accurate info.

I actually want to simply eliminate the copyright notices since they are legally pointless, but any time we've done it at scale it just generates lots of questions about ownership, even with clear info in README files, etc.

As someone eyeing SICP with previous programming experience should I do SICP first and then do these koans? How big is the difference between Scheme and Common Lisp?

Big enough that you might get confused in subtle and obvious ways.

I would go with "How to design programs" - looks at the beginning to be siplistic, but it gives a lot of understanding about lisp like languages.

Then I would go with SCIP and then Koans.

I am treating lisps as a kind of mind game (I dont like crosswords :) so I do Lisp) since I cannot use it for everyday job so from my point of view Scheme and Lisp are not very different. There is different approach to things like mutable state and other more advanced concepts, but basics are the same.

If you want to have at least an illusion of learning Lisp that can catch up one day, learn Clojure. Or go with Scheme's ugly duckling son - JavaScript. :)

A course (lightly)based on HtDP is also starting in Coursera in a few days- https://www.coursera.org/course/programdesign. It uses Racket and the first two weeks of videos are already up so you can preview them.

The first two weeks' lectures are already up.

I love Lisp->crosswords idea.

SICP [2nd edition] is flat out just a more readable book than HtDP [first print edition, second edition is not in print but looks to be significantly improved].

As textbooks, it may be a bit of a different story, the tone of SICP is certainly cockier. There's less acknowledgement that mathematics is just domain knowledge within the context of an introductory "computer science" course. Then again, HtDP had two decades of experience with SICP upon which to draw. It also has the practical advantage of assuming that students had high levels of access to computers capable of running Lisp. That wasn't the case in the late 1970's and early 80's (or even the late 80's and mid 90's).

While CL and scheme are both lisp dialects, they are quite different. Just to make a pair of examples, CL has two separate namespaces for variables and functions, scheme only one; scheme has guaranteed tail call optimization (which is used often to solve problems recursively), CL depends on implementations. To do these koans I would first go through Practical Common Lisp by Seibel http://www.gigamonkeys.com/book/

The optimization of tail-call optimization is converting some recursive procedure descriptions into iterative processes. A recursive procedure description may instead describe a necessarily recursive process. The difference between descriptions and the procedures they produce is one of the issues covered in SICP - most explicitly by Ableson in one of the videos.

If you're already a programmer, you should probably read Paul Graham's On Lisp. It's a technical book, written by an advocate but before he became a VC or took up writing on woolly topics like the relationship of programming to painting.

You dont do SICP to "learn Lisp", you do SICP to learn fundamental programming principles. SICP just happens to use Scheme because one of the authors of SICP was also one of the authors of Scheme. The difference between Scheme and Lisp is big enough to justify them having different names and Scheme not being "just another dialect of Lisp".

The problem with Scheme is not the language, the problem is that the ecosystem is so hopelessly balkanized, that it is useless for practical purposes and nobody uses it for anything interesting except for teaching of SICP. You have tiny standards covering only base language constructs, and everything else is left to implementations of which 1001 different one exists and each implements the same stuff in a different, incompatible way, so there is no code portability. So an large number of Scheme users, instead of developing interesting and useful _new_ libraries, instead rewrite 1001 different implementations and 1001 different manuals covering the same area. If you write something and tell me you wrote it in Scheme, the first thing I'd have to ask is "Which one?" because your code will not run on the 1000 remaining ones. The scheme ecosystem is the prime example of code non-reuse, of the NIH syndrome and waste of man-decades of effort, so while the language itself is nice for teaching, the existing worst-practices are examples of what _not_ to do.

SICP doesn't 'just happen' to use Scheme; the simple language from a well-chosen combination of powerful mechanisms is the kind of thing they're teaching you to design. The medium is part of the message. (Yes, you can solve the problems using another language; I used XLisp.)

On 'dialects of Lisp': it used to be standard for very different Lisp-family languages to be called that, while nowadays someone will always contradict you if you do. It seems more of a social change than a technical one to me. (I first noticed it among Common Lispers after the AI winter.)

I know someone impressive doing real work with Scheme (though I recommended they try Lua). I don't know whether you're right about the Scheme ecosystem, as I've been elsewhere the last 15 years.

Maybe Racket is closing this gap.

>In test-driven development the mantra has always been, red, green, refactor. Write a failing test and run it (red), make the test pass (green), then refactor it (that is look at the code and see if you can make it any better. In this case you will need to run the koan and see it fail (red), make the test pass (green), then take a moment and reflect upon the test to see what it is teaching you and improve the code to better communicate its intent (refactor).

While the above was quoted from the Ruby koans, I would have thought a Lisp author would have corrected the unbalanced parentheses. Am I unusual in finding unbalanced parentheses in English text very distracting? It must be something like my borderline OCD.

Heh. Fixed.

Other functional language koans:

* https://github.com/functional-koans/clojure-koans

* https://github.com/HaskVan/HaskellKoans

* https://github.com/rubbish/scala-koans

Other interpreted language koans:

* https://github.com/bittersweetryan/ColdFusion-Koans

* https://github.com/matyb/java-koans

* https://github.com/liammclennan/JavaScript-Koans

* https://github.com/midpeter444/mybatis-koans (In Java, but for the library MyBatis 3)

* https://github.com/kikito/lua_missions

* https://github.com/forcedotcom/PerlKoans