
Why Racket? Why Lisp? (2014) - dgellow
http://practicaltypography.com/why-racket-why-lisp.html
======
codeshaman
It's about a month since I've started seriously diving into lisp.

The last couple of weeks I've spent my days reading 'The joy of Clojure',
Structure and Interpretation of Computer programs, lots of tutorials and
documentation, playing around in the repl + experimenting with all kinds of
frameworks and libs in clojure (eg. Om).

I've spent today implementing the brainfuck interpreter in Racket.

I can't explain it, it's like something is calling me - 'learn lisp. now.'.

Given the amount of Lisp code read/written and the relative novelty of it, I'm
dreaming lisp code and the arguments to functions are actual physical things,
which are then mapped, reduced, recursed or expanded.

Literally, I think I'm going crazy.

I can fluently write x-platform C++, Javascript/CoffeeScript, Objective-C,
Java, Pascal, VB and everything in between.

But never have I experienced this kind of mental strain/obsession as I do now
with lisp.

But.

Seems like I'm not alone! Given the amount of lisp news lately on HN, I fell
like more and more people are going through what I'm going.

Seems like we here on HN follow a common mental pattern and suddenly
everyone's talking/learning lisp.

As interesting as learning lisp is, this 'group preference' thing is even more
interesting to observe.

~~~
vidarh
It's not so sudden. HN itself is written in a LISP [1], and Paul Graham's pre-
YC claim to fame was Viaweb, a store platform written in LISP that became
Yahoo Stores. This community has been above-average LISP friendly for a long
time.

LISP's also has a long history of popping up all over the place because they
are extremely implementation-friendly (if you want to write a simple language;
if you want to make things fast they get trickier, thought by no means
impossible) given the simple syntax.

So you'll also find a lot of people (like me) who don't really like LISPy
languages, but who still end up dabbling with related technologies
occasionally (my very-slowly-in-progress Ruby compiler uses s-expression
_syntax_ (though no LISP semantics to speak of) to express a tiny language to
implement some of the lower-level plumbing to bootstrap the Ruby core classes,
for example)

[1] [http://arclanguage.org/](http://arclanguage.org/)

~~~
Adlai
It's spelled 'Lisp'. There has been zero overlap between people writing "LISP"
and people writing lisp _code_ for about half a century.

~~~
juliangregorian
That's really overstating it, especially seeing as Lisp has barely existed for
half a century, and people like ESR call it "LISP" to this day.

~~~
na85
AFAIK the allcaps "LISP" fell out of favour in 1984 when Common Lisp was
introduced, and only the original Lisp implementation and Mac Lisp used the
allcaps name.

Much like Fortran (no longer FORTRAN), the acronyms became proper names in
their own right.

~~~
waterhouse
Someone pointed out that Common Lisp is case-insensitive by default, so really
they have no grounds to object to the name LISP. ;-)

~~~
Adlai
The CL _reader_ by default[1] converts unescaped characters to uppercase, but
only when parsing tokens. The CL _printer_ by default[2] converts everything
it prints to lowercase. CL _people_ seem to adopt these conventions as well,
although they have been known to :capitalize Lisp on occasion.

[1] [http://l1sp.org/cl/2.2](http://l1sp.org/cl/2.2)

[2] [http://l1sp.org/cl/*print-case*](http://l1sp.org/cl/*print-case*)

------
dang
"Paul Graham’s programming language Arc, a dialect of Lisp, was built on top
of Racket."

Since that statement occurs in a section about Racket languages, I should
probably clarify. Arc isn't technically a Racket language—that is, it doesn't
use any of Racket's facilities for defining new languages. It compiles to
Racket (and so you're all using it right now), but has its own distinct
implementation.

Historically, Arc wasn't built on top of Racket. I think pg may have started
on Common Lisp, then went to Scheme 48, Mz Scheme, and so on. Probably the
most accurate thing to say is that Arc was built in pg's head after years of
thinking about Lisp. It doesn't have a particularly close relationship to any
of those underlying platforms. Semantically it's closest to Common Lisp, but
don't tell pg I said that.

~~~
mbutterick
This is Matthew Butterick. I wrote “Why Racket? Why Lisp?”

As I allude there, Paul Graham’s writings about Lisp (mostly in Hackers &
Painters) helped persuade me to explore Lisp languages. (Those writings have
also persuaded many others.)

In particular, Arc's reliance on Racket persuaded me to take a serious look at
Racket. So leaving aside quibbles about what “on top of” means — is Clojure
not built “on top of” the JVM? Python “on top of” C? — Paul’s choice of Racket
was influential in my choice too. (As it has been for many others.)

As for software being “built in [one’s] head,” that seems facially true of any
software. The core thesis of “Beating the Averages” is that the tool you
choose to get it out of your head and into the world matters. Having now had
my own Lisp revelation, I not only buy Paul’s thesis, but I even think it
could be strengthened: Lisp permits the implementation of a whole category of
ideas that aren’t possible in other languages.

Moreover, Paul wrote that essay nearly 14 years ago. Since then, Lisps have
gotten somewhat more popular (Clojure has led the pack). But as I say in the
article, as a group, Lisps remain way behind the programming mainstream. So
ultimately, my goal is not to evangelize for Racket and exclude other Lisps. I
know Racket better because that’s what I use. But more people using all of
them would be a great thing.

~~~
ozten
I'm curious what data supports the idea that Lisps have gotten more popular.

The total number of developers who know a Lisp may have grown, but the total
population of developers is also rapidly growing.

Measured as a % of language popularity, I'd expect it is largely flat, despite
awesome mass-media efforts like Seibel's Practical Common Lisp
[http://www.gigamonkeys.com/book/](http://www.gigamonkeys.com/book/)

~~~
technomancy
How many conferences would you have seen ten years ago with a prominent lisp
showing? IIRC even the primary (at the time) ILC conference was only held
every other year.

These days with more regional conferences starting it's nearly in the
twenties, and attendance at Strange Loop (which has had lots of keynotes by
lispers) is several thousand and growing.

------
adregan
Previous discussion can be found here:
[https://news.ycombinator.com/item?id=8206038](https://news.ycombinator.com/item?id=8206038)

Have noticed quite a bit more buzz about Racket and Lisp very recently around
here. It's always been something I mean to explore.

~~~
s_kilk
We seem to be on a Racket buzz lately, and I like it. I feel more inspired to
dig further into Racket.

I'm already pretty good with Clojure, so can anyone who knows both languages
well comment on the ups and downs of learning Racket after learning Clojure?

~~~
luxbock
This is a blog post by technomancy, the original author of Leiningen,
exploring Racket as a new language:

[http://technomancy.us/175](http://technomancy.us/175)

EDIT: Wrong link. This one might be interesting as well so I've left it here:

[http://technomancy.us/169](http://technomancy.us/169)

~~~
technomancy
The TL;DR I would give is this: Clojure is preferable when doing server-side
performance-intensive software or in situations where its JVM library reach
provides a significant advantage. Racket is a lot nicer for client-side stuff
where you need a fast launch, lower memory profile, a GUI, or distributable
executables.

If you already have a solid development environment set up and have spent a
lot of time learning project management tools, you might have an easy enough
time getting started with Clojure, but getting started with Racket tooling is
easy even for children.

Clojure is a lot better out-of-the-box for FP, but Racket has third-party
tools (like Rackjure and fector) that do a lot to close the gap. On the other
hand, Racket has pattern matching out of the box which is really nice, but you
can get that in Clojure as well using external libraries. One problem that you
can't fix in a library is Clojure's omnipresent nil; Racket does a much better
job of ensuring sensible semantics in error conditions, partly due to the fact
that pattern-matching is built-in.

------
Scarbutt
How production ready or mature are Racket libs for creating CRUD web services?
skimming through the Racket website one can see Racket has the basics, a http
server and a library for interacting with databases like postgresql, as
someone relative new to programming/webdev, would I face to much "reinvent the
wheel" versus Clojure or Javascript?

~~~
mkozlows
Depends what you're doing. It doesn't have the depth of libraries of the JVM
or JS, so there'll be lots of "oh, can't use that technology" or "is this
3-year-old unmaintained library still going to work with Mongo?" moments.

------
AnimalMuppet
Why hasn't XML been matched to Lisp very much? I think it's because Lisp
programmers recoil in horror from XML. I mean, if you're already used to S
expressions, XML looks disgusting. As verbose as Java, and less expressive. So
I think most Lisp programmers look at XML and think "Ugh, don't get any of
_that_ on me..."

~~~
agumonkey
IIRC, it was Naggum that said the issue with XML is the useless distinction
between elements and attributes, leading to countless discussion, bikeshedding
etc etc instead of actually solving problems.

------
_djhrtmn
Has anyone tried to use Butterick's Pollen and written about it? The idea of
debugging your website with racket as you write markup and styles seemed
really interesting alternative to what I do; write styles, refresh, and then
refine the stylesheet by incrementally adding changes with the inspector and
then copying them to my stylesheet.

~~~
chipotle_coyote
I'm working on converting a fiction ebook to web-based with Pollen and may
later launch a fiction magazine using it, although I'm undecided about that
technology choice.

I think Pollen's biggest strength is that you can reprogram its markup -- as
its documentation puts it, you can attach behavior to tags. I haven't taken
much advantage of that yet, but you can do things like create a "TOC" tag that
builds a table of contents by inspecting child documents and looking for h1
tags (or looking for, say, "chapter" tags, which you've defined to expand to
"<h1 class='chapter'>"), or inspect the contents of paragraphs and subtly
shift the first line margin to the left if the first character is a quote mark
(which Butterick's _Practical Typography_ does). You could replicate some of
that with a template language that allows user-definable tags, but I don't
think you could do all of it.

Its biggest weakness, at least for me, has been finding a pleasant workflow.
Despite having a built-in web server it feels kind of clunky compared to other
static site generators. You're largely on your own for writing a deployment
script ("raco pollen clone" is not a valid substitute). The DrRacket IDE is
virtually a requirement for Racket programming, but it sucks teabags for
editing long prose documents; you'll likely find yourself working in one
editor for Racket language files and another for Pollen source. This isn't
necessarily a dealbreaker, but it's at the least annoying.

~~~
mbutterick
FWIW I go between DrRacket and Sublime Text as necessary. Sublime is of course
faster for typical writing & editing tasks. But when working on code-related
things, the DrRacket REPL is useful.

~~~
chipotle_coyote
That makes sense. I think I was using Sublime as well -- I experimented with
making the world's hackiest syntax highlighting file to show embedded Pollen
commands. (IIRC, Sublime was unamused with the notion of ".html.pmd" as a
single extension.)

------
spain
As someone who thinks Lisp is pretty cool and uses Emacs to study it and is
about 100 pages into SICP: I _still_ don't get it. Common Lisp macros went
entirely over my head too. A programmable programming language? Aren't all
languages like that? I've only been programming for a couple years so I'm
afraid I might not recognize the value of Lisp until I use more of the "less
powerful" alternatives.

~~~
Ironballs
The principal data structure of Lisp is a list which is written like this: (a
b c d). Like the article mentions, when you see Lisp code you're in fact
reading the same list syntax, only that, when the list itself is not quoted,
the "a" is evaluated as a function, which is why (+ 1 2) behaves the way it
does. If you quote the list by saying "'(a b c d)" then it is a list of
symbols, so "'(+ 1 2)" does nothing.

Hence, Lisp code is made of nested lists. When you think further about it, it
means that Lisp metaprogramming facilities may do things just with plain list
manipulation functions! So it's not about metaprogramming itself, it's that
it's incredibly _easy_. This is what people refer as "code as data" and
"homoiconicity" and so on.

------
yoanizer
I have a feeling people tend to over estimate the importance of language
choice. Might be just me though.

~~~
dang
Many people agree with you but I have the opposite view. Of course you can
write any program in any Turing complete language, but the programs people
_do_ write in a given language tend to have a family resemblance to one
another. Therefore if we want different kinds of programs we should have
different languages.

A given language makes certain ideas easier or harder to formulate, and thus
easier or harder to have in the first place. So the language constrains not
only how you think about your program, but what you think—and thus what the
program itself becomes.

Platforms, communities, and culture also help determine these things, but
they're not independent of the underlying language.

~~~
allemagne
Some have also said that the human language you speak has an effect on how you
think, but that's pretty controversial among linguists if not altogether
discredited.

I have no doubt the difference among human languages and programming languages
could be completely different, but is there any concrete example you could
give of an idea that is easier to express in one programming language than in
another?

~~~
dang
IMO the analogy to human languages is a distraction and best avoided, since
we're not able to say meaningful things about both.

> is there any concrete example you could give of an idea that is easier to
> express in one programming language than in another

Sure. Since this thread is about Lisps: writing code that works with other
code is an order of magnitude easier in Lisp. Therefore people tend to do it a
lot more.

------
mattnewton
I find all his digs at javascript funny since, at least the way I use it,
javascript is basically an ugly-looking scheme. Javascript is responsible for
my 'lisp enlightenment' with the language using first-class functions and
closures, and the wide variety of precompilers. It strikes me as fashionable
to hate on javascript.

Java on the other hand, now that's a horrible language ;) ;)

~~~
Scarbutt
Javascript isn't Scheme:
[http://journal.stuffwithstuff.com/2013/07/18/javascript-
isnt...](http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt-scheme/)

If Javascript were only an ugly looking scheme...

~~~
ozten
Sweet.js brings hygienic macros to JavaScript and follows directly from Scheme
R5RS mechanisms AFAICT.

~~~
samth
Actually, sweet.js is based almost entirely on various macro innovations
developed in Racket (such as the Honu approach to macros in languages without
parens).

------
nickbauman
I think the hardest thing for people to get for programming in Lisp is the
immutability. Once you get over that hump, everything is downhill. From the
outside, the parenthesis seem pedantic but it's completely superficial. You
will stop noticing them in a few hours, if not days.

~~~
mbrock
Are you perhaps coming from a Clojure perspective? Scheme is no more
inherently immutable than, say, JavaScript. Many Scheme programs I've seen use
mutation quite liberally. Immutability is a useful pattern in lots of
languages and situations, but Lisp per se doesn't particularly enforce it.

~~~
adrianm
Indeed. Common Lisp is similar with regard to the proliferation of mutation.

~~~
marijn
It in fact takes it to amusing extremes, allowing you to mutate even the
strings associated with symbols.

    
    
        (setf (char (symbol-name nil) 1) #\U)
    

(Though I guess that could be taken as being the same thing as doing
nonsensical pointer arithmetic in C -- you simply should know better.)

~~~
mbrock
I'd point out that Common Lisp, kind of like Smalltalk, is a highly dynamic
environment that has historically been used as an operating system in itself.
That's one reason why the system is so mutable—you don't want to have to
relaunch it even to modify core functionality.

~~~
adrianm
I actually don't view mutation in Common Lisp as a downside. I find writing
high performance (usually numerical, but sometimes not) code in Clojure to be
painfully obtuse compared to Common Lisp, but I love Clojure otherwise.
Writing highly optimized code can be quite elegant in Common Lisp, and I
appreciate that when the problem at hand calls for it.

------
wellpast
> What's in it for me? Expressiveness.

I appreciate the author's wanting a more explicit and practical answer to this
question, but I don't think his answer here ("expressiveness") does any better
job than the other explanations he criticizes.

> But [learning Lisp] also requires an investment of about 100–200 hours.
> That's asking too much.

No, it's not. That's how long it takes sometimes, or longer. Why do we all
expect answers and understanding to come so quickly and easily? It'd be a nice
world otherwise, but almost always enlightenment comes at a cost: patient
focus and study.

~~~
AnimalMuppet
Sure, that's true. But the problem is, there are dozens of things telling me
that, if I invest that kind of time in them, they'll pay me back. Which one(s)
should I pursue? In order to decide, I have to have some explanation of the
benefits that I can grasp (at least in the abstract) _before_ investing 100
hours. "Invest 100 hours and _then_ you'll see why you should have done so" is
not a sales pitch that will win with very many people.

~~~
marcosdumay
Why do you expect things that really improve your life to come with sales
pitches?

~~~
AnimalMuppet
People are usually eager to recommend things that they feel really improved
their life. If you, for example, read HN, you see "sales pitches" (in the
broad sense) all the time.

~~~
marcosdumay
Yes, that's true. But it's both naive, arrogant, and rude to require those
"sales pitches" to be good. At the end of the day, it's up to you to decide
what's better for you. If you try to outsource it, you'll discover that the
best sales pitches around are for dead-end technologies.

At the other side of it, people giving you those recommendations really have
no better way to explain it. PG has an well known essay about language power,
but even that isn't very precise. Some kinds of knowledge you really have to
know before you understand what they are good for.

------
j2438
I have so far stuck with Clojure instead of a Scheme primarily because of the
nice literal syntax for maps, sets, vectors, and regexes that Clojure
supports. I don't want to give that up and just use cons/car/cdr.

And also, last time I looked at Racket, it seemed very focused on academics. I
just wanted to write some simple Scheme in a .scm file and try it out (a
script), but I think I had to choose a language first (maybe a line at the top
of the file? Don't recall) --- the Racket ecosystem seemed off-putting.

~~~
Toenex
There are also some practical reasons to favour Clojure over Racket,
specifically if you work in Java shop. The inertia to move to Clojure but
remain on the JVM is going to be considerably lower than moving to whole new
infrastructure as would be the case with Racket (indeed the language
interoperability offered by the JVM was probably one reason why Scala gained
such ground). However, even with Clojure I'm going to get some damn funny
looks at the next code review.

~~~
j2438
Yes, I think one reason for Clojure's popularity is that it allows you to
escape Java while still remaining on the JVM and being able to interoperate
with your existing Java codebase.

That said, for a variety of reasons, I would actually prefer to not be tied to
the JVM.

------
Chris911
What is a good resource to learn Lisp for an advanced (non Lisp) programmer?
Most guides for most languages only cover declaration, simple functions and
tiny applications. I want something that quickly goes through the basics and
skips to advanced uses in bigger codebases.

~~~
mrottenkolber
Practical Common Lisp by Peter Seibel:

[http://www.gigamonkeys.com/book/](http://www.gigamonkeys.com/book/)

~~~
nemoniac
PCL is a good book but too wordy for my taste.

Paul Graham's ANSI Common Lisp will get an advanced programmer up to an
advanced level more quickly and efficiently.

[http://www.paulgraham.com/acl.html](http://www.paulgraham.com/acl.html)

~~~
mrottenkolber
I'd say both are essential, but PCL should be digested first (no need to read
every paragraph). On Lisp is IMHO a lambda power user guide and not a good
general introduction to CL.

~~~
nemoniac
Note that I recommended the book "ANSI Common Lisp" for an advanced (non Lisp)
programmer, not "On Lisp".

That aside, I agree with your description of On Lisp.

------
izietto
I love this site, it's so simple and beautiful

------
ims
> (x + (if is_true(): 1 else: 2)) [is invalid in Python] be­cause the if–else
> con­di­tional is a state­ment, and can only be used in cer­tain positions.

Point taken, but troll-mode pedantry: (x + (1 if is_true() else 2)) would be
valid :)

~~~
Xophmeister
...but, in that case, the `X if Y else Z` syntax is considered to be an
expression in Python. You can't, for example, omit the `else Z` part. In
Haskell -- again, in which everything's an expression -- conditionals are the
same, just written in the "normal" order: `if Y then X else Z`.

------
SeanLuke

        For more on the per­-
        ils of tax­ing reader
               pa­tience, see
                WHY DOES TY-
               POGRAPHY MAT-
                         TER
    

This quote, hyphenated as is, provides all sorts of opportunities for snark.
Instead I'll just note that it seems Pollen needs work. It's far too eager to
hyphenate; doesn't protrude hyphens, commas, etc.; and doesn't use TeX-style
paragraph-level optimization. Not being able to identify the bounds of
hyperlinks is also a strong source of irritation.

~~~
xrayspec
Where do you see this? On my machine it's not hyphenated

~~~
SeanLuke
Chrome, OS X. Hyphenated exactly as shown regardless of magnification.

------
omaranto
I'd be more interested in a "Why Pollen over Scribble?"...

------
PopsiclePete
How does Racket stack up against Clojure? I like some of the special extended
reader support for data structures, I dig the immutability, some of the
concurrency stuff....I don't think immutability/concurrency is that _typical_
for LISPs...for people who've tried both, which one do you prefer?

~~~
pmelendez
I think people tend to use Clojure more because it has the Java VM and
platform as support, which is a nice thing to have given its extension.

The .Net world has IronScheme which is very stable and interesting too.

------
wehadfun
is there a tl;dr. After about 45 secs of reading author did not answer why
racket or why lisp

~~~
nickbauman
It's simpler than using the language you're probably using now. I cannot think
of a higher praise for any design problem is that it's solved more simply with
Y than X.

~~~
qznc
Forth is even simpler.

------
10098
Don't waste your time with lisp. Learn lambda calculus and then see how these
ideas are applied in actually useful imperative programming languages.

~~~
evanspa
Pretty ironic you've been posting here for 4 years to a site built with a
language that's not useful.

~~~
10098
I'll believe that it's useful when unenlightened plebs like me start getting
money thrown at them for writing lisp code. So far the industry seems to
disagree with you about what's useful.

