Live data from Hacker News

Why Ruby is an acceptable Lisp (2005)

randomhacks.net

21–30 of 115 posts

Re: Why Ruby is an acceptable Lisp (2005)

#21
Author here. Let me explain where this article came from, since people keep digging it up every few years to discuss it. :-)

I spent some time during the late 90s learning all kinds of cool ways to use Lisp, courtesy of a couple Boston startups, including IS Robotics (now better known as iRobot). And I'd helped introduce Scheme to another employer. Scheme made it ridiculously easy to create domain-specific languages, but it was obviously a niche technology.

Around the same time, I'd heard Matz speak to a room full of Lisp hackers at the Lightweight Languages conference. He'd elegantly explained why Ruby was cool several years before Rails became widespread. But I don't think many of us understood what he was saying until later.

When I finally realized—thanks to Rails—that Ruby could mimic many of the most common Lisp metaprogramming tricks, I mentally kicked myself and wrote this blog post. There were a lot of great responses from other bloggers, too. My goal was to help make other people aware of some fun new possibilities.

Anyway, if anybody has any questions, I'll try to answer them later this evening when I'm back online. It's fun to remember when this stuff was so new.

Re: Why Ruby is an acceptable Lisp (2005)

#22

Tcl is a better lisp than Ruby. Homoiconic. Yield and tailcall make it easy to implement FP idioms. Macros available if needed.

...TCL doesn't have macros, it has fexprs, and uplevel. It also has no effective hygene mechanisms, and unless you want to use regex to parse the tree every time your function fires, you can't do the kinds of code transforms macros can.

Don't get me wrong, TCL is super cool, but it doesn't have quite the same powers as lisp. Although you are correct, it's a better lisp than ruby.

Re: Why Ruby is an acceptable Lisp (2005)

#24
> The most common use of LISP macros is to avoid typing lambda quite so much

LispWorks

    CL-USER 1 > (let ((n-macros 0) (n-with-macros 0) (with-macros nil))
                  (do-all-symbols (s (values n-macros n-with-macros))
                    (when (macro-function s)
                      (incf n-macros)
                      (let ((name (symbol-name s)))
                        (when (and name
                                   (> (length name) 4)
                                   (string-equal name "WITH" :start1 0 :end1 4))
                          (incf n-with-macros)
                          (push s with-macros))))))
    1186  ; macros
    182   ; with- macros

Note also that

    (with-slots (a b)
        foo
      (+ a b))

is not the same as:

    (call-with-slots foo
                     '(a b)
                     (lambda (a b) (+ a b)))

Re: Why Ruby is an acceptable Lisp (2005)

#25
post #19

I fail to see how it can be an acceptable Lisp when it lacks the AOT/JIT compilation as part of the standard toolchain and the development productivity of Common Lisp environments.

I don't have the love of CL development environments you do, but yeah, as a schemer, ruby's perf is kind of awful. We've got AOT, JIT, bytecode, and literally decades of research spend making these languages fast, and Ruby doesn't have that, or the hot code loading and quick iteration cycle that makes Lisp/Scheme realtime development so deliciously sweet.

To say nothing of our macro superpowers. But then, CLers still insist on on keeping the shotgun hovering over their foot, and insisting it's the only way to go about writing macros. Syntactic Closures and Implicit Renaming are both pretty cool. You guys should check them out.

Re: Why Ruby is an acceptable Lisp (2005)

#26
For a 2005 article, this is totally awesome, as well as that Steve Yegge response. But in 2016, it's hard for me not to get excited about what's seeming like Clojure's upward trajectory into the mainstream and want to jump on board 100%. To paraphrase Rich Hickey, Lisp and immutable functional programming totally rock, and the JVM and Javascript just reach (ClojureScript). As our systems get bigger and more quality is demanded from our software, it'd be so cool if we could get behind this as a standard, in all the growing technology fields -- web and mobile (Om.next for React and React Native), big data, AI/machine learning, Dockerization/containerization and even decentralized stuff (Pelle Braendgaard's Cloth library for Ethereum is a start, and I was just talking with some awesome people in the Clojure Slack channel working on Boot tasks for IPFS, and soon the Golem Network project will be launched which will be super dope). Hell, even designers can start designing in Clojure now. It's just Simple, and as the community grows, rallying behind it is only going to get Easier. People were raving with React Native about how JavaScript developers could now all the sudden start coding mobile apps. How cool would it be if there was just one awesome language, the one true immutable functional Lisp, where everybody in tech could understand each other and collaborate? I genuinely think this is Lisp's revenge (shoutout David Nolen!).

It's been tough for me as a new developer to learn this stuff without nearly as many resources as there are in the Python and Ruby communities for beginners, but there's no question this is the (near-term) future. Plus, a lot of that stuff just complects everything anyways and doesn't have to apply anymore (read: mutable state, no Value on Values).

Let's keep it Lispy. ;)

Re: Why Ruby is an acceptable Lisp (2005)

#27
This is a pretty bad article. The part that makes Lisp unique is hardly lambdas (every language has them, even Javascript), or being functional, but rather stuff like homoiconicity (and therefore macros). And once one scrolls down to that part, it's full of ignorant statements like "the most common use of LISP macros is to avoid typing lambda quite so much". It demonstrates a fundamental misunderstanding of macros, because they're executed at the compilation step, before the program is run. It's a zero-cost abstraction (wrt performance). Not that anyone writing in Ruby cares about that.

Look at this example from the article:

(defmacro with-each-natural-number (n expr) `(each-natural-number (lambda (,n) ,expr)))

It assumes that the programmer already wrote a function each-natural-number that does the required functionality when another function is passed into it. That's the Ruby way, because it only has functions, not macros. A good Lisp programmer would never write such inefficient code. Why create a local function here when you can easily write a macro that expands into a loop with expr as its body?

So, indeed, if you write in Lisp as if it were Ruby, then Ruby is an acceptable Lisp. If you write in Lisp as it's supposed to be written, then Ruby is ridiculously restrictive, and slow.

Re: Why Ruby is an acceptable Lisp (2005)

#28
post #20

I'm glad to see this, and even more interested that it was written in 2005. I've read lots of rants about how awesome Lisp is supposed to be from Paul Graham and Steve Yegge and all. But I never see anything significant being written in it or using it, so I haven't felt all that tempted to try learning it. Meanwhile, I've been using Ruby for a while, and the metaprogramming capabilities are pretty cool. It sounds a l…

FWIW Elixir has first class macros that go way beyond Ruby's metaprogramming, so you may want to try that.

Re: Why Ruby is an acceptable Lisp (2005)

#29
post #3

Earlier quoted context omitted.

I just checked your links and gotta admit, you're right. Although, still I don't see why this has been posted "three" times before! I think HN should add a URL checker in the submit page.

I don't see why this has been posted "three" times before Posts that are over a year old can be reposted. It's a way to get a fresh perspective on ideas.

Maybe an URL checker would implicitly discourage reposts by warning about them.

If the URL checker were to present itself as a helpful aid for reposts ("You might want to use this title like the other 3 posters have used: X") it might avoid that result.

Re: Why Ruby is an acceptable Lisp (2005)

#30

A classic. Should have (2005) in the title. Previously on HN: https://news.ycombinator.com/item?id=416589 and https://news.ycombinator.com/item?id=825809 And a follow-up: https://news.ycombinator.com/item?id=2279453

I don't think this article is as great as a lot of people do. Most of this should be obvious to anyone using ruby, nowadays. It might have been great at the time, but I don't think so much now.

But then again I thought "The Meme Hustler" was rubbish (well, actually, I think the reasoning would have been okay, but I thought the premise was totally, utterly, removed from reality), so I think it's safe to say me and Steve have a different taste in articles.

Post reply on HN