10 ms·

(λove (print (eval (read))))

272 points by llambda 13y ago

jlarocco 13y ago
FYI, I didn't click the link to look at flower paintings, so I left. If you're trying to pull people into a tech article, it might help to start off with some text.
- zeckalpha 13y ago
  This isn't a blog per se. See: http://blog.fogus.me/2013/09/09/read-eval-print-%CE%BBove-v001-sakura/ http://blog.fogus.me/2013/09/09/read-eval-print-%CE%BBove-v0...
- cgag 13y ago
  Good riddance.
- chc 13y ago
  You shouldn't be so smug — you're the one missing out on something here.
- ryderm 13y ago
  I liked the painting and found that it added to the feeling the post was going for.
- fogus 13y ago
  Probably for the best -- I have a strong impression that you wouldn't like the rest either.
- reinhardt 13y ago
  Sorry you left, here's a more fitting article for you: https://news.ycombinator.com/item?id=6353957 https://news.ycombinator.com/item?id=6353957
- logjam 13y ago
  A Haiku for the Imperative Encountering the Sublime "It might help to start off with some text" HN comment text fades to gray Flower abides
- marshray 13y ago
  You did come off as smug, but I wish I could un-downvote you. HN should always be a place where we can give feedback on web design.
ludicast 13y ago
This really is a fantastic newsletter/post. Was excited to see it in my mailbox, and am enjoying it (taking some detours to look at the referenced articles).
abecedarius 13y ago
One nit: in T (object ...) doesn't create an anonymous class, it creates an object implementing the given operations, just as lambda creates a procedure. I agree that it's a lovely feature worth highlighting.
ingenter 13y ago
I really like how the very first link leads to "http://www-formal.stanford.edu/jmc/lisp20th.html)" http://www-formal.stanford.edu/jmc/lisp20th.html)" Truly, this is a Lisp article.
fogus 13y ago
Author here. The announcement with some preliminaries can be found at http://blog.fogus.me/2013/09/09/read-eval-print-%CE%BBove-v001-sakura/ http://blog.fogus.me/2013/09/09/read-eval-print-%CE%BBove-v0... Enjoy.
- weavie 13y ago
  Wow, fantastic. This is a real rabbit hole. Thankyou
- rbonvall 13y ago
  Hi fogus, I really enjoyed the article. I just want to point out a couple of typos: a) s/tern/term/ in footnote 9; b) in German nouns are always capitalized, so it should be "der Fluchtpunkt".
- billrobertson42 13y ago
  The link to McCarthy's paper is broken. It has a closing paren at the end.
- cormullion 13y ago
  A nice read - thanks! I'm seeing some odd characters (Safari on Mac Mountain Lion): “the Common Lisp way.�� It may be just me...
breckinloggins 13y ago
Can anyone here defend Lisp-2? Any time I read about it I seem to instinctively recoil in disgust. To me, the hygiene argument doesn't make up for the extra characters and loss of generality.
- kinghajj 13y ago
  It also encourages one to separate data and code, which is completely (in my mind) counter to Lisp's great achievement in combining the two.
- fogus 13y ago
  I won't argue for the aesthetics, but I am curious what you mean by "loss of generality."
  - breckinloggins 13y ago
    Perhaps that was worded wrong, but what I meant was the idea that you have names that map to things, and that you have an evaluation order for those things. So that if you see (foo a b c) and it isn't quoted, we know that foo will be resolved and evaluated, so will a, b, and c, and then the objects to which a, b, and c resolved will be applied to the object to which foo was resolved. So, if I then type (a foo b c), we get the same behavior with different object resolutions. And that should work everywhere, all the time.
- moomin 13y ago
  I have much the same reaction. My theory is that it comes from an extinct Lisp tribe. Those who think like that these days use different languages (Java?). We can only really hunt for someone who dates from that time and remembers what they were thinking. Maybe Richard Stallman? :)
- bmf 13y ago
  Richard Gabriel did a great write-up of the trade-offs during the ANSI Common Lisp standardization process: http://www.nhplace.com/kent/Papers/Technical-Issues.html http://www.nhplace.com/kent/Papers/Technical-Issues.html What I took away from it was that macros get more tricky to write when you have possible variable capture for functions, which we humans seem to be a little more blind to than for values. Item 18 contains the compatibility concerns for existing code, which the guys writing the standard seemed to think critical to keep the various vendors on board.
tel 13y ago
This was a great first print and has made me quite interested in taking a look at Land of Lisp sometime. ... But instead I think I'm more likely to take a look at that T manual.
- breckinloggins 13y ago
  The Land of Lisp is a fantastic book. Absolutely fantastic. I am not a Common Lisp fan AT ALL, but if you want to learn Lisp without feeling like you're trying to gain admission to some Hacker Buddhist Monastery high in the mountains where a bearded guy named Master Foo may just condemn you forever to Visual Basic if you so much as ask the wrong question, then it's a great start. :)
  - James_Duval 13y ago
    What I really found helpful was learning Racket. Common Lisp is a little less straight-forward and a little more complex, so Racket is awesome for learning the patterns you'll use to program with. I'm starting to move into Common Lisp now, because it has more useful tools and libraries available for making 'proper' programming easier.
keppy 13y ago
Shen/Qi was the first Fluchtpunktish lisp I ever spent time with, and I had not used any typing system outside of Typed Racket and some other hand-made implementations. I remember being amazed that the Shen type system isn't more widely used across more domains. Once you start using it, you feel like the type problem is 'solved' in Shen. The author is right on about this language offering something special--Shen is one of those addictive hammers that you will want to hit all the nails with. More importantly it's a type system that can be used in conjunction with existing systems or even implemented in a different language. A good test for how powerful a new means of abstraction actually is, is to try using it outside of its original implementation.
- breckinloggins 13y ago
  I agree. In my opinion the whole notion of a baked-in "type system" is silly. Type systems themselves aren't silly, but including one in the language proper seems to be stopping at the wrong abstraction. Let's say we see: int add_two(int a, int b) We're so used to seeing those "ints" as types, but why? There's a better abstraction here, mainly one of: ensure_conforms_to(int) add_two(ensure_conforms_to(int, a), ensure_conforms_to(int, b)) I'm not arguing for that horrific syntax, I'm saying that type systems are just another part of your program running at a separate time. There's a LOT more you can do with that concept than just enforcing and deducing the tags and acceptable conversions that go with values. Contracts, powerful dispatch mechanisms, ad-hoc optimization strategies, complex lambda cube stuff like dependent types... all of these things can be served with the right abstraction. And there is no reason that your editors, documentation browsers, code completion engines, syntax highlighters, debuggers, and every other part of your environment can't use it! Shen seems to get that.
  - lisper 13y ago
    > ensure_conforms_to(int) Why int? What about adding floats? complex numbers? rationals? quaternions? matrices? dimensional quantities? etc. etc. etc.
    - breckinloggins 13y ago
rcb 13y ago
Great job, fogus. Thank you so much.
fosap 13y ago
Would a homoiconic Haskell be a lisp?
- breckinloggins 13y ago
  Many languages claim to be "lisps" for various reasons, and there's always someone who disagrees. Also, what exactly do you mean by "homoiconic"? People love this word because it sounds fancy and marks them as someone who geeks out on programming, but the fact is that this word is, if not ambiguous, at least prone to abuse. Let me give a specific example. The new language Julia has a macro system and Julia's designers claim that the language is homoiconic. Is it? It has a way to quote expressions such that a + b is just the result of a + b whereas :(a + b) returns the expression tree for a + b. This can then be modified, eval'd, and otherwise sliced and diced. But what does that expression tree look like? When you print it in Julia, you get something like: head: call args: [0] symbol(:+) [1] symbol(:a) [2] symbol(:b) type: any Question: does that look like a normal snippet of Julia code you could paste into your test editor and eval? No. The "real" syntax for that code is something like: {:call, {:+, :a, :b}, Any} (Julia-ish pseudocode, not precise) In any event, while you CAN write a Julia program using the literal syntax for the data structures that represent Julia programs, people usually don't do that. So what does homoiconic mean? Does it mean that you can get to the data structure representing your code and then manipulate it at will? Or does it mean that PLUS the fact that programs in your language always take exactly the form of the data structure that represents that code? If the former, then a lot of languages (including C# with its expression trees) can claim to be partially or fully homoiconic. If the latter, then the list is much smaller. So would a homoiconic Haskell be a lisp? I think what you'd end up with after taking things far enough wouldn't be Haskell at all. It'd be a lisp with a REALLY good type system. After all, things like monads and morphisms and applicative functors aren't Haskell, they're mathematics.
  - chongli 13y ago
    Also, what exactly do you mean by "homoiconic"? Yeah, the word is admittedly a bit problematic. If one wanted to be overly pedantic, any language with strings might be called homoiconic. The better answer is to ask how commonly-used are the data structures for storing the expressions. What makes Lisp so powerful is that these data structures are lists and lists are used all the time; this enables a large amount of code sharing between macros and regular functions. Now this makes it very straightforward to evaluate the usefulness of Julia's claim of homoiconicity: how often would you expect to use the data structures Julia uses to represent its expression trees? If the answer is not very often, then the language suffers for it because you're going to have to write special-purpose code for macros instead of reusing the libraries you'd use anyway.
reikonomusha 13y ago
Here is my brief review of the articles as a whole. As a little background, I've been writing Lisp professionally for a while at many companies, both start ups and top-tier tech companies. I like writing about Lisp[1], and have been so far as to write blog posts ranging from why parentheses are a good thing to what kinds of data types Common Lisp has. I think there is still a place for writing about Lisp, but I don't think this e-zine accomplished the task to make it interesting. Lisp unfortunately attracts a lot of fluff writing. Writing about how wonderful, deep, rich, or sophisticated it is. Writing about how it completely blows one's mind and takes you to this baroque, fluid land of programming literacy. I must admit that I've even been sucked into the vortex at a point in my Lisp career. Then there are particular topics that get rehashed over and over again: what makes a Lisp? which is the best Lisp? which is the most practical? lisp-1 vs. lisp-2? was r6rs a failure? why are macros so great? why does Lisp subsume every programming language ever? I found in this e-zine—whose title I can't repeat without bloating the paragraphs I write—that I didn't really gain anything after reading it all. What did I learn about T? I just learned that it was some language with interesting concepts, backed up with a paltry offering of examples. What did I learn about Apple? To me, it seemed like an opinion: Since Apple isn't doing wacky Lisp things, it no longer is catering to those with ideas. (This is something I disagree with.) Regarding topics, I also found this e-zine to be somewhat haphazard in its arrangement. Maybe it's just the visual layout, but the topics didn't really flow, and it read more like a long blog post with randomly selected topics interjected with philosophical ideas about categorization. I have a hard time really seeing, after reading, who this e-zine is for. It doesn't seem like it'd interest the general programming enthusiast, because it's just about a class of languages that few people actually use. It constantly shows code and uses jargon that the general programmer probably isn't accustomed with. It barely seems to appeal to veteran Lisp programmers because there's little depth and lots of the aforementioned fluff. The only group I can think it appeals to are people who have casually brushed next to Lisp at a previous time and wish to be re-injected with a shot of apparent beauty and mysticism they once saw, but never had time time or patience to fully reach. My suggestion for future articles: Instead of trying to talk about all Lisps all the time, and talk about beaten-to-death topics that pop up on Usenet everyday, talk about something more technical and be comprehensive. What is something really interesting about Common Lisp? Though not exactly in the format I'd have for a magazine article, I wrote about "linear random access sequences" in Lisp here: http://symbo1ics.com/blog/?p=1845 http://symbo1ics.com/blog/?p=1845 What about an overview of how the object system in T works? How about examples of how Lisp has solved problems in the industry that people don't know about (i.e., people know about ITA, the space probe, Jak & Dexter game, etc. because they're the examples that continue to propagate)? How about where Lisp falls short? Lisp is a language that was ahead of its time, but there are language features now that seem beyond Lisp's grasp. Where has it failed? All in all, I was somewhat disappointed, especially given the well qualified and articulate author. I think there's potential, but I don't think Read-Eval-Print-Love has successfully converged to what it should or could be. I do wish Code Quarterly[2] was successful. Fogus even seemed to contribute to it with an interview with Rich Hickey. But, as outlined here[3], there wasn't enough motivation from the writers to make it successful. [1] http://symbo1ics.com/blog/?cat=10 http://symbo1ics.com/blog/?cat=10 [2] http://www.codequarterly.com/ http://www.codequarterly.com/ [3] http://gigamonkeys.wordpress.com/2011/10/17/end-of-the-line-for-code-quarterly/ http://gigamonkeys.wordpress.com/2011/10/17/end-of-the-line-...
kenbot 13y ago
Title should have been (-> read eval print λove) :)
seanschade 13y ago
@fogus this is brilliant! thanks for sharing.
Gonzih 13y ago
This is sweeeet, thank you, fogus!

272 points by llambda 13y ago

FYI, I didn't click the link to look at flower paintings, so I left. If you're trying to pull people into a tech article, it might help to start off with some text.

zeckalpha 13y ago
This isn't a blog per se. See: http://blog.fogus.me/2013/09/09/read-eval-print-%CE%BBove-v001-sakura/ http://blog.fogus.me/2013/09/09/read-eval-print-%CE%BBove-v0...
cgag 13y ago
Good riddance.
chc 13y ago
You shouldn't be so smug — you're the one missing out on something here.
ryderm 13y ago
I liked the painting and found that it added to the feeling the post was going for.
fogus 13y ago
Probably for the best -- I have a strong impression that you wouldn't like the rest either.
reinhardt 13y ago
Sorry you left, here's a more fitting article for you: https://news.ycombinator.com/item?id=6353957 https://news.ycombinator.com/item?id=6353957
logjam 13y ago
A Haiku for the Imperative Encountering the Sublime "It might help to start off with some text" HN comment text fades to gray Flower abides
marshray 13y ago
You did come off as smug, but I wish I could un-downvote you. HN should always be a place where we can give feedback on web design.

ludicast 13y ago

This really is a fantastic newsletter/post. Was excited to see it in my mailbox, and am enjoying it (taking some detours to look at the referenced articles).

abecedarius 13y ago

One nit: in T (object ...) doesn't create an anonymous class, it creates an object implementing the given operations, just as lambda creates a procedure. I agree that it's a lovely feature worth highlighting.

ingenter 13y ago

I really like how the very first link leads to "http://www-formal.stanford.edu/jmc/lisp20th.html)" http://www-formal.stanford.edu/jmc/lisp20th.html)" Truly, this is a Lisp article.

fogus 13y ago

Author here. The announcement with some preliminaries can be found at http://blog.fogus.me/2013/09/09/read-eval-print-%CE%BBove-v001-sakura/ http://blog.fogus.me/2013/09/09/read-eval-print-%CE%BBove-v0... Enjoy.

weavie 13y ago
Wow, fantastic. This is a real rabbit hole. Thankyou
rbonvall 13y ago
Hi fogus, I really enjoyed the article. I just want to point out a couple of typos: a) s/tern/term/ in footnote 9; b) in German nouns are always capitalized, so it should be "der Fluchtpunkt".
billrobertson42 13y ago
The link to McCarthy's paper is broken. It has a closing paren at the end.
cormullion 13y ago
A nice read - thanks! I'm seeing some odd characters (Safari on Mac Mountain Lion): “the Common Lisp way.�� It may be just me...

breckinloggins 13y ago

Can anyone here defend Lisp-2? Any time I read about it I seem to instinctively recoil in disgust. To me, the hygiene argument doesn't make up for the extra characters and loss of generality.

kinghajj 13y ago
It also encourages one to separate data and code, which is completely (in my mind) counter to Lisp's great achievement in combining the two.
fogus 13y ago
I won't argue for the aesthetics, but I am curious what you mean by "loss of generality."
- breckinloggins 13y ago
  Perhaps that was worded wrong, but what I meant was the idea that you have names that map to things, and that you have an evaluation order for those things. So that if you see (foo a b c) and it isn't quoted, we know that foo will be resolved and evaluated, so will a, b, and c, and then the objects to which a, b, and c resolved will be applied to the object to which foo was resolved. So, if I then type (a foo b c), we get the same behavior with different object resolutions. And that should work everywhere, all the time.
moomin 13y ago
I have much the same reaction. My theory is that it comes from an extinct Lisp tribe. Those who think like that these days use different languages (Java?). We can only really hunt for someone who dates from that time and remembers what they were thinking. Maybe Richard Stallman? :)
bmf 13y ago
Richard Gabriel did a great write-up of the trade-offs during the ANSI Common Lisp standardization process: http://www.nhplace.com/kent/Papers/Technical-Issues.html http://www.nhplace.com/kent/Papers/Technical-Issues.html What I took away from it was that macros get more tricky to write when you have possible variable capture for functions, which we humans seem to be a little more blind to than for values. Item 18 contains the compatibility concerns for existing code, which the guys writing the standard seemed to think critical to keep the various vendors on board.

tel 13y ago

This was a great first print and has made me quite interested in taking a look at Land of Lisp sometime. ... But instead I think I'm more likely to take a look at that T manual.

breckinloggins 13y ago
The Land of Lisp is a fantastic book. Absolutely fantastic. I am not a Common Lisp fan AT ALL, but if you want to learn Lisp without feeling like you're trying to gain admission to some Hacker Buddhist Monastery high in the mountains where a bearded guy named Master Foo may just condemn you forever to Visual Basic if you so much as ask the wrong question, then it's a great start. :)
- James_Duval 13y ago
  What I really found helpful was learning Racket. Common Lisp is a little less straight-forward and a little more complex, so Racket is awesome for learning the patterns you'll use to program with. I'm starting to move into Common Lisp now, because it has more useful tools and libraries available for making 'proper' programming easier.

keppy 13y ago

Shen/Qi was the first Fluchtpunktish lisp I ever spent time with, and I had not used any typing system outside of Typed Racket and some other hand-made implementations. I remember being amazed that the Shen type system isn't more widely used across more domains. Once you start using it, you feel like the type problem is 'solved' in Shen. The author is right on about this language offering something special--Shen is one of those addictive hammers that you will want to hit all the nails with. More importantly it's a type system that can be used in conjunction with existing systems or even implemented in a different language. A good test for how powerful a new means of abstraction actually is, is to try using it outside of its original implementation.

breckinloggins 13y ago
I agree. In my opinion the whole notion of a baked-in "type system" is silly. Type systems themselves aren't silly, but including one in the language proper seems to be stopping at the wrong abstraction. Let's say we see: int add_two(int a, int b) We're so used to seeing those "ints" as types, but why? There's a better abstraction here, mainly one of: ensure_conforms_to(int) add_two(ensure_conforms_to(int, a), ensure_conforms_to(int, b)) I'm not arguing for that horrific syntax, I'm saying that type systems are just another part of your program running at a separate time. There's a LOT more you can do with that concept than just enforcing and deducing the tags and acceptable conversions that go with values. Contracts, powerful dispatch mechanisms, ad-hoc optimization strategies, complex lambda cube stuff like dependent types... all of these things can be served with the right abstraction. And there is no reason that your editors, documentation browsers, code completion engines, syntax highlighters, debuggers, and every other part of your environment can't use it! Shen seems to get that.
- lisper 13y ago
  > ensure_conforms_to(int) Why int? What about adding floats? complex numbers? rationals? quaternions? matrices? dimensional quantities? etc. etc. etc.
  - breckinloggins 13y ago

rcb 13y ago

Great job, fogus. Thank you so much.

fosap 13y ago

Would a homoiconic Haskell be a lisp?

breckinloggins 13y ago
Many languages claim to be "lisps" for various reasons, and there's always someone who disagrees. Also, what exactly do you mean by "homoiconic"? People love this word because it sounds fancy and marks them as someone who geeks out on programming, but the fact is that this word is, if not ambiguous, at least prone to abuse. Let me give a specific example. The new language Julia has a macro system and Julia's designers claim that the language is homoiconic. Is it? It has a way to quote expressions such that a + b is just the result of a + b whereas :(a + b) returns the expression tree for a + b. This can then be modified, eval'd, and otherwise sliced and diced. But what does that expression tree look like? When you print it in Julia, you get something like: head: call args: [0] symbol(:+) [1] symbol(:a) [2] symbol(:b) type: any Question: does that look like a normal snippet of Julia code you could paste into your test editor and eval? No. The "real" syntax for that code is something like: {:call, {:+, :a, :b}, Any} (Julia-ish pseudocode, not precise) In any event, while you CAN write a Julia program using the literal syntax for the data structures that represent Julia programs, people usually don't do that. So what does homoiconic mean? Does it mean that you can get to the data structure representing your code and then manipulate it at will? Or does it mean that PLUS the fact that programs in your language always take exactly the form of the data structure that represents that code? If the former, then a lot of languages (including C# with its expression trees) can claim to be partially or fully homoiconic. If the latter, then the list is much smaller. So would a homoiconic Haskell be a lisp? I think what you'd end up with after taking things far enough wouldn't be Haskell at all. It'd be a lisp with a REALLY good type system. After all, things like monads and morphisms and applicative functors aren't Haskell, they're mathematics.
- chongli 13y ago
  Also, what exactly do you mean by "homoiconic"? Yeah, the word is admittedly a bit problematic. If one wanted to be overly pedantic, any language with strings might be called homoiconic. The better answer is to ask how commonly-used are the data structures for storing the expressions. What makes Lisp so powerful is that these data structures are lists and lists are used all the time; this enables a large amount of code sharing between macros and regular functions. Now this makes it very straightforward to evaluate the usefulness of Julia's claim of homoiconicity: how often would you expect to use the data structures Julia uses to represent its expression trees? If the answer is not very often, then the language suffers for it because you're going to have to write special-purpose code for macros instead of reusing the libraries you'd use anyway.

reikonomusha 13y ago

Here is my brief review of the articles as a whole. As a little background, I've been writing Lisp professionally for a while at many companies, both start ups and top-tier tech companies. I like writing about Lisp[1], and have been so far as to write blog posts ranging from why parentheses are a good thing to what kinds of data types Common Lisp has. I think there is still a place for writing about Lisp, but I don't think this e-zine accomplished the task to make it interesting. Lisp unfortunately attracts a lot of fluff writing. Writing about how wonderful, deep, rich, or sophisticated it is. Writing about how it completely blows one's mind and takes you to this baroque, fluid land of programming literacy. I must admit that I've even been sucked into the vortex at a point in my Lisp career. Then there are particular topics that get rehashed over and over again: what makes a Lisp? which is the best Lisp? which is the most practical? lisp-1 vs. lisp-2? was r6rs a failure? why are macros so great? why does Lisp subsume every programming language ever? I found in this e-zine—whose title I can't repeat without bloating the paragraphs I write—that I didn't really gain anything after reading it all. What did I learn about T? I just learned that it was some language with interesting concepts, backed up with a paltry offering of examples. What did I learn about Apple? To me, it seemed like an opinion: Since Apple isn't doing wacky Lisp things, it no longer is catering to those with ideas. (This is something I disagree with.) Regarding topics, I also found this e-zine to be somewhat haphazard in its arrangement. Maybe it's just the visual layout, but the topics didn't really flow, and it read more like a long blog post with randomly selected topics interjected with philosophical ideas about categorization. I have a hard time really seeing, after reading, who this e-zine is for. It doesn't seem like it'd interest the general programming enthusiast, because it's just about a class of languages that few people actually use. It constantly shows code and uses jargon that the general programmer probably isn't accustomed with. It barely seems to appeal to veteran Lisp programmers because there's little depth and lots of the aforementioned fluff. The only group I can think it appeals to are people who have casually brushed next to Lisp at a previous time and wish to be re-injected with a shot of apparent beauty and mysticism they once saw, but never had time time or patience to fully reach. My suggestion for future articles: Instead of trying to talk about all Lisps all the time, and talk about beaten-to-death topics that pop up on Usenet everyday, talk about something more technical and be comprehensive. What is something really interesting about Common Lisp? Though not exactly in the format I'd have for a magazine article, I wrote about "linear random access sequences" in Lisp here: http://symbo1ics.com/blog/?p=1845 http://symbo1ics.com/blog/?p=1845 What about an overview of how the object system in T works? How about examples of how Lisp has solved problems in the industry that people don't know about (i.e., people know about ITA, the space probe, Jak & Dexter game, etc. because they're the examples that continue to propagate)? How about where Lisp falls short? Lisp is a language that was ahead of its time, but there are language features now that seem beyond Lisp's grasp. Where has it failed? All in all, I was somewhat disappointed, especially given the well qualified and articulate author. I think there's potential, but I don't think Read-Eval-Print-Love has successfully converged to what it should or could be. I do wish Code Quarterly[2] was successful. Fogus even seemed to contribute to it with an interview with Rich Hickey. But, as outlined here[3], there wasn't enough motivation from the writers to make it successful. [1] http://symbo1ics.com/blog/?cat=10 http://symbo1ics.com/blog/?cat=10 [2] http://www.codequarterly.com/ http://www.codequarterly.com/ [3] http://gigamonkeys.wordpress.com/2011/10/17/end-of-the-line-for-code-quarterly/ http://gigamonkeys.wordpress.com/2011/10/17/end-of-the-line-...

kenbot 13y ago

Title should have been (-> read eval print λove) :)

seanschade 13y ago

@fogus this is brilliant! thanks for sharing.

Gonzih 13y ago

This is sweeeet, thank you, fogus!