Hacker News Reader

Comment by dang | Hacker News Reader

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

View on HN

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.

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/

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.

I couldn't agree more!

Good discussion of the advantages of Arc versus Racket. http://stackoverflow.com/questions/8555440/the-advantage-of-...

"I wish they had implemented Arc as a Racket module language since then you could actually develop in DRracket, debug, and make executables."

That discussion doesn't seem very good to me, though there are some nice examples of Arc's notation at the bottom.

Our own kogir actually worked for a while on implementing Arc as a Racket language. It would have some advantages, especially around tooling. However, like all such platforms, Racket has a sweet spot (what's easy to build on top of it), and the further your semantics are from there, the harder it quickly gets. Redefining how null, true/false, lists, and macros work—as Arc does, relative to Racket—is not how a language platform is meant to be used! You end up fighting with it in a way that loses most of the advantages, and the difficulty seems to grow asymptotically as you approach 100%.

What you want instead is to stay in the sweet spot and let the underlying platform nudge the new language in all the directions that are easy to implement. The same is true of building transpilers—it's an order of magnitude easier when you can piggyback on the semantics of the underlying language. But this is not an option if your source language has already been defined elsewhere.

I think you're assuming that a language built that way would have to adopt Racket's underlying meanings for things, probably because Arc is, in the grand scheme of things, pretty close to Racket. But because Arc makes some fairly fundamental decisions that are different than Racket (such as how macros work), you can't keep those the same -- Arc macros can't be just Racket macros.

However, just because Arc can't be a layer of macros on top of Racket, that doesn't mean that the language can't be implemented as a Racket language. There are Racket language implementations of Algol 60, Python, and JavaScript, all of which are very different from Racket, more so than Arc is. And those implementations get the tooling benefits that Arc today misses.

It's easier to write a simple interpreter than a compiler, and Arc's current implementation seems to be working well for you, so far be it from me to tell you how to run your project. But certainly it could be implemented as a Racket language, no matter how far away it is.

Hmmm. The syntax stuff could easily be implemented using macros. I like using rackjure by Greg Hendershott:

http://www.greghendershott.com/rackjure/

Adding the if statements wouldn't be too much fuzz.

MZ Scheme was a precursor to Racket. Same people, AFAIK same core codebase.

http://docs.racket-lang.org/mzscheme

I think it compiled to MzScheme first.

MzScheme came comparatively late. Here is a post from when it was Scheme48 and after it was Common Lisp:

http://www.reddit.com/r/programming/comments/bstl/arc_lisp_d...

A friend told me he used to track developments in Arc by noticing when pg had switched mailing lists. :)

Reply on news.ycombinator.com