
(λove (print (eval (read)))) - llambda
http://readevalprintlove.fogus.me/#
======
reikonomusha
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-...](http://gigamonkeys.wordpress.com/2011/10/17/end-of-the-line-for-
code-quarterly/)

~~~
brudgers
Lisp's literary cannon, like R&B, cop shows, and Buddhist monk anecdotes has a
traditional forms. The love song is foremost among them - and the newsletter's
title is more than fair warning.

In the end, any piece may be dead to a reader, but writing without passion
will almost certainly be stillborn.

~~~
lutusp
> Lisp's literary cannon ...

A firearm that shoots books? Or did you by chance mean "canon"?

[http://dictionary.reference.com/browse/canon](http://dictionary.reference.com/browse/canon)
: "the body of rules, principles, or standards accepted as axiomatic and
universally binding in a field of study or art"

[http://dictionary.reference.com/browse/cannon](http://dictionary.reference.com/browse/cannon)
: "a mounted gun for firing heavy projectiles; a gun, howitzer, or mortar"

~~~
brudgers
A device useful for firing up small caliber pendants?

~~~
lutusp
> A device useful for firing up small caliber pendants?

Did you mean pedants by chance?

[http://dictionary.reference.com/browse/pedant](http://dictionary.reference.com/browse/pedant)
: "a person who makes an excessive or inappropriate display of learning."

[http://dictionary.reference.com/browse/pendant?s=t](http://dictionary.reference.com/browse/pendant?s=t)
: "a hanging ornament, as an earring or the main piece suspended from a
necklace."

~~~
brudgers
Fires soft balls, to.

~~~
lutusp
Did you by chance mean "too"?

~~~
eitally
Thanks for the LMAO IRL, guys. This was the funniest exchange I've read in a
couple of days (including on reddit. :P )

~~~
lutusp
You're most ... welcome (bows from the waist). :)

------
keppy
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
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
> ensure_conforms_to(int)

Why int? What about adding floats? complex numbers? rationals? quaternions?
matrices? dimensional quantities? etc. etc. etc.

~~~
breckinloggins
That was, of course, just an example. I'm also assuming that any "real" type
system implemented this way would do this with something like typeclasses or
higher kinds or something else.

The larger point is that baked-in type system see the word "int" as a type,
but what that's hiding is the higher abstraction: that what we're really doing
is specifying a function which should be run when determining the validity of
the program.

~~~
lisper
But that was exactly my point: what IS this "higher abstraction" to which you
allude? What are you actually advocating here? Typeclasses? Sequent calculus?
Something else? Details matter.

~~~
breckinloggins
I'm advocating something that typeclasses, sequent calculus, contracts, etc.
could be built on. Sure, the language may have some standard libraries that
would do much the same things that these do in other languages, but those
libraries could be improved, removed, or replaced by the programmer.

What exactly is the _point_ of a type system? I think there are really two big
ones: program verification and metadata tagging. To simplify, the former is
why Haskellers love types, and the latter seems to be the main reason that
F#'s type providers exist (and why C# programmers love creating lots of little
types rather than using typeless object literals a la Ruby).

Intellisense is an incredibly seductive thing, and many programmers in the
enterprise world would argue that any language that can't show you that little
"box" after you press Ctrl+Space is dead on arrival.

But both of those things are a subset of the things you COULD do if the phases
of compilation were in your control. Maybe you want a function that says
"throw an error at compile time if someone uses this deprecated parameter on
this API call", or maybe you'd like to have a function where if you call it
with a hard-coded URL, the program fails at compile time if the URL can't be
reached.

These are obviously a bit silly, but the point is that, to many of us,
WHENEVER a compiler is doing something with our AST, that should be fully
exposed and not a black box. Another example: why is Idris[1] its own
language? Why isn't it just a Haskell library? Granted that also gets into
programmable syntax and editor support thereof, but that's part of my larger
point as well.

[1] [http://www.idris-lang.org/](http://www.idris-lang.org/)

~~~
tel
One reason why Idris is its own language is that you can't just lie dependent
types atop a language---that's the whole point, the types interact with the
values and the values the types. This blurs the boundary between compiler
phases.

Sometimes you get type erasure, but for really interesting programs to arise
(the kind that I'm sure Idris is aiming at, though I don't know for certain)
you really want to operate in that blurry divide.

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

Enjoy.

~~~
rbonvall
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".

------
breckinloggins
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.

~~~
pcwalton
Erik Naggum had an impassioned defense of Lisp-2:
[https://groups.google.com/forum/#!msg/comp.lang.lisp/04rR3_j...](https://groups.google.com/forum/#!msg/comp.lang.lisp/04rR3_jcuyY/cc6P0ECzU3QJ)

I don't buy it, but I can understand the reasoning.

~~~
moomin
I find the reasoning specious. In particular, files and programs are the same
in MS-DOS and Unix. You can, for instance, ls the ls command or cat the cat
command. He's also completely ignoring the superiority of the file system's
namespacing (by directory) to just having two global buckets like in elisp.

The execute bit comparison is especially specious. If I try to execute a non-
executable file, it fails. It doesn't go look for an executable file with the
same name. Same as if I try to invoke 0 in Clojure. e.g. (0)

He's right that the symbol resolution of the first entry has different rules
but ignores the fact that the shell isn't very good at higher order commands.
Which is probably okay for a shell but not much use for a modern programming
language.

Finally, he's right that multiple namespaces are a good idea, but that's
Accepted Truth these days. It's just that we think namespacing should be under
the control of the dev, not dependent on the type of the variable.

~~~
Theriac25
> In particular, files and programs are the same in MS-DOS and Unix. You can,
> for instance, ls the ls command or cat the cat command.

Uh, no you cant:

    
    
      $ ls ls
      ls: cannot access ls: No such file or directory
      $ cat cat
      cat: cat: No such file or directory

~~~
euccastro

        $ ls $(which ls)
        $ cat $(which cat)

~~~
vseloved
looks just like (funcall #'funcall ... ;)

~~~
Avshalom
Its more like

    
    
      ls /bin/ls
    

you can simply cat cat or ls ls by cd-ing to /bin first... with the caveat
that some distros have moved them to /usr/bin or somewhere, hence the 'which'

~~~
moomin
Exactly. File systems resemble modern namespaces, not namespacing by type. You
can put an executable and a data file in the same directory, or not. Your
choice.

------
ingenter
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.

------
ludicast
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
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.

------
fosap
Would a homoiconic Haskell be a lisp?

~~~
breckinloggins
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
_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.

------
tel
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
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
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.

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

------
rcb
Great job, fogus. Thank you so much.

------
seanschade
@fogus this is brilliant! thanks for sharing.

------
Gonzih
This is sweeeet, thank you, fogus!

------
jlarocco
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.

~~~
fogus
Probably for the best -- I have a strong impression that you wouldn't like the
rest either.

