Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Ruby is an acceptable Lisp (2005)

randomhacks.net

Post reply on HN
Print view View original

101–110 of 115 posts

Re: Why Ruby is an acceptable Lisp (2005)

#101

Post by lispm »

fiddlerwoaroof wrote: post #99
Grue3 wrote: 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…

Actually, that example is fairly idiomatic, it's called the "call-with" style. From Google's Common Lisp style guide ( https://google.github.io/styleguide/lispguide.xml#Macros ): You should follow the so-called CALL-WITH style when it applies. This style is explained at length in http://random-state.net/log/3390120648.html. The general principle is that the macro is strictly limited to processing the syntax, and as m…

> when it applies

One of the problems here is that the function does get an anonymous function passed. That means the function can provide dynamic scope via constructs like CATCH, LET with dynamic bindings, UNWIND-PROTECT, and so on. But it can't rewrite any code in the passed function.

This can only be done in a macro.

Re: Why Ruby is an acceptable Lisp (2005)

#102

Post by white-flame »

feelsboutlisps wrote: post #90
white-flame wrote: post #89

Earlier quoted context omitted.

In the case of code that works with code, rich syntax is a problem, not a solution. Getting rid of tons of syntax is not a sacrifice at all, when you're wrapping, transforming, and/or generating code. And as I've stated elsewhere, the fact that you can do this now so easily means it opens up that power for quick little inline tools, where in most other languages that sort of thing is reserved for major undertakings.…

> Getting rid of tons of syntax is not a sacrifice at all Getting rid of syntax that usefully expresses common cases absolutely is a sacrifice. What was that Turing tar pit thing about making things of interest easy? Lisp is powerful, but its lack of syntax makes it inexpressive. > It also eliminates many syntactic bugs How so? > makes searching & editing code easier for humans I disagree, code that lacks basic synta…

Here's the fundamental problem: Not just humans read & write code. Our code also reads & writes our code. If you optimize for the nebulous "human" case, you end up walling off the possibility of having your software join your programming team.

Yet, humans can easily learn both styles. Whatever non-Lisp language you pick is as equally ununderstandable gobbledegook to non-programmers as Lisp. Even COBOL or SQL are way too explicit and finnicky for untrained, non-technical users to write complex applications. There's no difference in technical human understanding barriers between heavily magic-syntax'd code or explicit regular AST-like code. All it is is how used you are to one thing and not the other. (Rich Hickey's notion of the subjective "easy", as opposed to "simple")

Because most languages have traded off for the human-only case, having code writing code isn't even on the radar for most people. Write a few tightly-entwined code generators, and you'll start to see the barriers you hit. Full integration of these concepts opens up completely new productivity and clarity for both you the programmer, and your programming-assisting code, without any difficulties besides the programmer's arbitrary syntactic preference.

Re: Why Ruby is an acceptable Lisp (2005)

#103

Post by ekidd »

contingencies wrote: post #86
ekidd wrote: post #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,…

Interesting article and thanks for chiming back in. I also discovered and enjoyed the metaprogramming features of ruby perhaps 5+ years ago. As I've been learning it recently, can I ask if you have any particular take on lua ? To me, it feels a bit paired back, more purist, smaller core/libraries than ruby , but also drawing from the same tradition - ie. lua 's tables/functions equate well to lisp's lists/S-expressio…

Lua looks like a nice language, but I've never really tried it. The Lua JITs are really impressive.

Metaprogramming is a pretty widespread feature these days. Even Rust, for example, has both Scheme-style rewrite-rule macros, and (unstable) programmatic macros, for example.

Re: Why Ruby is an acceptable Lisp (2005)

#104

Post by feelsboutlisps »

qwertyuiop924 wrote: post #96
feelsboutlisps wrote: post #91

Earlier quoted context omitted.

> No. Lack of macros makes code bigger, more error prone and harder to understand. I mean, that's provably not true. Or at least not provably true. Let's me throw out at alternative statement: Macros make code harder to understand. > When I use something like cl-ppcre:do-register-groups, this one word hides all the loop orginization You don't need a lisp to hide things. > Or cl-sql:select, which allows programmer to…

So python's got a with statement. What of it didn't? Well then, you're screwed. Hope you like calling file.close(). If lisp didn't have a with statement, you could add one yourself. And if scheme didn't have a with statement... well, you could always add one, but before dynamic-wind got added, it could break if you weren't careful. Some things you can't just patch in. Anyways, now you'll say, "but python does have a…

> But that was just an example: there are things python will never have that you can add to lisp yourself.

I don't want to. I want a language that has sensible norms.

> As for your theory that macros make code harder to understand, you don't have any proof. In fact, you have negative proof,

Do I?

> as there's plenty of logic,

What logic? Show me. I simply don't believe you, as it's not provable.

> good programming practice

Still not proof. I believe the opposite, that it's not good programming practice to use macros.

> and individual cases indicating that careful use of macros can make code easier to understand.

So anecdotal evidence, not proof.

You have no more proof than I have. My personal experience is that in most mainstream languages, the most common arguments are over invention of frameworks/libs vs using existing ones, and those devs certainly would not be happy having macros thrown in the mix.

Re: Why Ruby is an acceptable Lisp (2005)

#105

Post by feelsboutlisps »

qwertyuiop924 wrote: post #81
feelsboutlisps wrote: post #79

Earlier quoted context omitted.

> Macros are a language tool that lets you build abstractions, in some cases imo allowing better abstractions than would be possible without macros I guess 'better' is the operative word I question here. You're creating syntax that no-one has seen before. How is that a good thing? Meanwhile in languages like Python, with syntax built-in, people build large apps without ever doing this, making their code far more unde…

No, what he's saying is that a good team knows when to use the guns, and how to aim them. A good OO team knows how to layer their types, how to relate them, and when to stop. A good asm team knows how to handle nonlocal jumps, when to use them and when not to. Every paradigm has its guns. You're just paying extra attention to the lisp ones.

> You're just paying extra attention to the lisp ones.

Because people in this thread are attempting to put-forward lisps' macros (and writing code as an AST) as some big win, without acknowledging that it comes with a massive cost. Lisp-y, inexpressive, paren-soup syntax. I'm saying myself (and presumably many others else lisps would be more popular) don't buy the trade-off.

If you like it, and your team like it then great. But don't act like it's definitely win-win, and people who choose not to use lisps just haven't achieved enlightenment yet.

Re: Why Ruby is an acceptable Lisp (2005)

#106

Post by qwertyuiop924 »

feelsboutlisps wrote: post #104
qwertyuiop924 wrote: post #96

Earlier quoted context omitted.

So python's got a with statement. What of it didn't? Well then, you're screwed. Hope you like calling file.close(). If lisp didn't have a with statement, you could add one yourself. And if scheme didn't have a with statement... well, you could always add one, but before dynamic-wind got added, it could break if you weren't careful. Some things you can't just patch in. Anyways, now you'll say, "but python does have a…

> But that was just an example: there are things python will never have that you can add to lisp yourself. I don't want to. I want a language that has sensible norms. > As for your theory that macros make code harder to understand, you don't have any proof. In fact, you have negative proof, Do I? > as there's plenty of logic, What logic? Show me. I simply don't believe you, as it's not provable. > good programming pr…

Lisp has sensible norms: Unlike you, however, we acknowledge that what may be a sensible norm for one situation isn't for another.

As for it not being good programming practice to use macros, it isn't good practice to use them excessively. However, they can be used to make your code much clearer. Here's the reasoning (no, it's not proof, you're right on that front, but it's better than what you've got, which is just your opinion, AFAICT):

The larger a codebase grows, the more likely it becomes to contain bugs. The most common way to decrease the size of the codebase is to abstract away common idioms, only express them in one place, and reference that from other parts of your program. This is what functions and objects do. However, some idioms are incapable of being expressed as functions or objects. These idioms must be repeated over and over again, and often result in insidious bugs when somebody gets them subtly wrong. Macros allow you to capture those idioms and express them once, eliminating bugs. They also make the code easier to understand, by abstracting away complex logic.

So, if you really think macros are bad, than what's wrong with that line of thinking?

Re: Why Ruby is an acceptable Lisp (2005)

#107

Post by qwertyuiop924 »

feelsboutlisps wrote: post #105
qwertyuiop924 wrote: post #81

Earlier quoted context omitted.

No, what he's saying is that a good team knows when to use the guns, and how to aim them. A good OO team knows how to layer their types, how to relate them, and when to stop. A good asm team knows how to handle nonlocal jumps, when to use them and when not to. Every paradigm has its guns. You're just paying extra attention to the lisp ones.

> You're just paying extra attention to the lisp ones. Because people in this thread are attempting to put-forward lisps' macros (and writing code as an AST) as some big win, without acknowledging that it comes with a massive cost. Lisp-y, inexpressive, paren-soup syntax. I'm saying myself (and presumably many others else lisps would be more popular) don't buy the trade-off. If you like it, and your team like it then…

I never said you haven't acheived enlightenment...

But Lisp's syntax is actually pretty expressive and nice, once you get used to it, IMHO. You continually deny this, and while you're free to disagree (many do), you continually argue that the mine and other's opinions are Bad and Wrong. I find this frustrating.

Re: Why Ruby is an acceptable Lisp (2005)

#108

Post by _delirium »

feelsboutlisps wrote: post #105
qwertyuiop924 wrote: post #81

Earlier quoted context omitted.

No, what he's saying is that a good team knows when to use the guns, and how to aim them. A good OO team knows how to layer their types, how to relate them, and when to stop. A good asm team knows how to handle nonlocal jumps, when to use them and when not to. Every paradigm has its guns. You're just paying extra attention to the lisp ones.

> You're just paying extra attention to the lisp ones. Because people in this thread are attempting to put-forward lisps' macros (and writing code as an AST) as some big win, without acknowledging that it comes with a massive cost. Lisp-y, inexpressive, paren-soup syntax. I'm saying myself (and presumably many others else lisps would be more popular) don't buy the trade-off. If you like it, and your team like it then…

This feels like it's fallen back into a more boring criticism: you just don't like Lisp's syntax. Ok, fine, everyone has a criticism about every other programming language's syntax. Maybe I hate Python's mandatory indentation. These kinds of criticisms are not really the most interesting ones though.

Re: Why Ruby is an acceptable Lisp (2005)

#109

Post by fiddlerwoaroof »

lispm wrote: post #101
fiddlerwoaroof wrote: post #99

Earlier quoted context omitted.

Actually, that example is fairly idiomatic, it's called the "call-with" style. From Google's Common Lisp style guide ( https://google.github.io/styleguide/lispguide.xml#Macros ): You should follow the so-called CALL-WITH style when it applies. This style is explained at length in http://random-state.net/log/3390120648.html. The general principle is that the macro is strictly limited to processing the syntax, and as m…

> when it applies One of the problems here is that the function does get an anonymous function passed. That means the function can provide dynamic scope via constructs like CATCH, LET with dynamic bindings, UNWIND-PROTECT, and so on. But it can't rewrite any code in the passed function. This can only be done in a macro.

Fair enough, I was just responding to this:

> 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?

The nice thing about the call-with style is that it makes it easier to redefine your macro's functionality without recompiling all the call sites.

Re: Why Ruby is an acceptable Lisp (2005)

#110

Post by feelsboutlisps »

_delirium wrote: post #108
feelsboutlisps wrote: post #105

Earlier quoted context omitted.

> You're just paying extra attention to the lisp ones. Because people in this thread are attempting to put-forward lisps' macros (and writing code as an AST) as some big win, without acknowledging that it comes with a massive cost. Lisp-y, inexpressive, paren-soup syntax. I'm saying myself (and presumably many others else lisps would be more popular) don't buy the trade-off. If you like it, and your team like it then…

This feels like it's fallen back into a more boring criticism: you just don't like Lisp's syntax. Ok, fine, everyone has a criticism about every other programming language's syntax. Maybe I hate Python's mandatory indentation. These kinds of criticisms are not really the most interesting ones though.

I don't think you can put those things on the same scale. I think it's telling that you dismiss Lisp's syntax like it's unimportant rather than acknowledging that it's the several hundred lb elephant in the room whenever it comes to talking about lisps.

What I'm arguing is that Lispers say that all the parens and lack of other, more expressive constructs are worth it because you get macros. I'm arguing that's a bad trade-off, because 1. that's a big sacrifice, 2. macros aren't a win.

Post reply on HN