Live data from Hacker News

Why Ruby is an acceptable Lisp (2005)

randomhacks.net

31–40 of 115 posts

Re: Why Ruby is an acceptable Lisp (2005)

#31
post #6

Earlier quoted context omitted.

I missed the original postings so it's nice to see this for the first time. That would be difficult if HN didn't allow reposts. Though I can understand if I had seen it already.

That's actually a good point. On a sidenote, I get a weird feeling from HN's simple UI/UX. On one hand, it feels like the old CLI machines that put the focus on "content" - kinda like "do one thing and do it right". On the other hand, reading all the comments, getting notified for replies on comments, etc. is really hard. In this day and age, one would wonder if HN really hates JS (well, except for the upvote button)…

I get some weird enjoyment out of this site not having any modern features and little to no JavaScript, even though I'm a JavaScript developer by trade and open source.

Re: Why Ruby is an acceptable Lisp (2005)

#32
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…

I hardly have used Lisp besides Emacs Lisp and Clojure, but as a language geek I do have my collection of Lisp related stuff, mainly Xerox PARC, Lisp Machines and commercial CL environments.

Scheme also has environments like DrRaket, even if the language now has moved beyond its Scheme origins.

Re: Why Ruby is an acceptable Lisp (2005)

#33
>But, for the sake of argument, I'd like to boil them down to two things:

> LISP is a dense functional language. > LISP has programmatic macros.

First of these is wrong and second is just picking something from feature list without any concern of practicality.

When someone writes Lisp as LISP and speaks about functional programming, I get the feeling that the author has not programmed with Lisp outside school (or knows only Scheme). Using toy examples don't help.

There is also problem with treating Lisp as a single entity. It's like Treating C++ and JavaScript as the same language because their syntax looks similar to someone who is not actually programming with them.

There are at least two major "schools" of lisp. Traditional Lisp style with Common Lisp as it's main representative, another being Emacs Lisp. The another is Scheme & Clojure camp that goes towards different goals.

Re: Why Ruby is an acceptable Lisp (2005)

#34
post #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, b…

That's a bit needlessly insulting, but the line in the article about Lisp being functional is telling: Most lisps are emphatically not functional, by any definition. Some of it was kind of right, though: Markabye, in particular, looks like the classic lisp HTML generator macro.

And hey, most of my Scheme code barely has any macros (so call my idioms a decade out of date, we have a macro system equivalent to CL's, and I've never felt much need to use it. And yes, most Schemes do have a CL-equivalent macro system, it's just nonstandard), and I still love lisp.

Lisp has many, many, many, cool advantages, but I still think never having to worry about syntax or indenting style is the greatest one: people underestimate just how much the little things matter. :-)

Re: Why Ruby is an acceptable Lisp (2005)

#35
post #6

Earlier quoted context omitted.

I missed the original postings so it's nice to see this for the first time. That would be difficult if HN didn't allow reposts. Though I can understand if I had seen it already.

That's actually a good point. On a sidenote, I get a weird feeling from HN's simple UI/UX. On one hand, it feels like the old CLI machines that put the focus on "content" - kinda like "do one thing and do it right". On the other hand, reading all the comments, getting notified for replies on comments, etc. is really hard. In this day and age, one would wonder if HN really hates JS (well, except for the upvote button)…

"It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."

Re: Why Ruby is an acceptable Lisp (2005)

#36

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.

Do you know about the sugar package? Sugar implements real lisp macros.

http://wiki.tcl.tk/11155

Re: Why Ruby is an acceptable Lisp (2005)

#37
post #16

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

Wish more people understood this about tcl

Tcl was what made possible one of the best startups I had the privilege to be part of.

They had a Rails like stack in the first .com wave, but implemented in a mix of Tcl, Apache and C.

Re: Why Ruby is an acceptable Lisp (2005)

#38
post #33

>But, for the sake of argument, I'd like to boil them down to two things: > LISP is a dense functional language. > LISP has programmatic macros. First of these is wrong and second is just picking something from feature list without any concern of practicality. When someone writes Lisp as LISP and speaks about functional programming, I get the feeling that the author has not programmed with Lisp outside school (or kno…

[deleted]

Re: Why Ruby is an acceptable Lisp (2005)

#39
post #33

>But, for the sake of argument, I'd like to boil them down to two things: > LISP is a dense functional language. > LISP has programmatic macros. First of these is wrong and second is just picking something from feature list without any concern of practicality. When someone writes Lisp as LISP and speaks about functional programming, I get the feeling that the author has not programmed with Lisp outside school (or kno…

I agree regarding this mischaracterization of Lisp, but have to laugh as you mischaracterize Scheme. Lisps are excellent at adapting to programming paradigms. Scheme is often used academically in a functional style, but if you want to go full-on procedural or OO, we're just as good as Common Lisp. Okay, maybe we're not quite as good as CLOS, but we're not as far off as you'd think.

Also, most Schemes are way more traditional than Clojure. And no, Racket isn't Scheme.

Re: Why Ruby is an acceptable Lisp (2005)

#40
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…

The software done by these guys is pretty significant and manages a few of the European train systems.

http://www.siscog.com

Post reply on HN