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

91–100 of 115 posts

Re: Why Ruby is an acceptable Lisp (2005)

#91

Post by feelsboutlisps »

ordu wrote: post #84
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…

> in languages like Python, with syntax built-in, people build large apps without ever doing this, making their code far more understandable for the next person that touches it. No. Lack of macros makes code bigger, more error prone and harder to understand. When I use something like cl-ppcre:do-register-groups, this one word hides all the loop orginization, and underlines meaning of local variables which are bound t…

> 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 use SQL syntax as part of lisp

Eugh, why would I want SQL interspersed with my lisp.

> [...] gl:with-primitives, which hides glBegin(...); [...] Note, it not just hides, it makes impossible to forget glEnd.

Python has 'with' statements and 'context managers' that do this (make sure some cleanup happens). [1]

> Macros makes life easier [...] such a convinient way to make an abstractions

They might make life easier for the person writing them in the short term. And I can see how when you find a really solid case for a macro and document it well, open source it etc, it can be broadly useful, but then why not add that case to the damn language. Instead you open the floodgates to everyone in your team writing macros that aren't widely understood.

> Otherwise no one would use it.

A lot of people avoid them like the plague in all other languages.

> but nevertheless lisp nostalgia will last forever.

Maybe that's all it is though.

[1] https://docs.python.org/2/reference/compound_stmts.html#the-...

Re: Why Ruby is an acceptable Lisp (2005)

#92

Post by qwertyuiop924 »

aidenn0 wrote: post #88
nilved wrote: post #83

Earlier quoted context omitted.

How are conses in Clojure different from those in Scheme? Is it the implementation? Because the API seems the exact same to me.

Not a Clojure developer but, IIRC, Clojure doesn't have conses, but rather the function cons creates a seq. A Seq in Clojure is immutable and (usually) lazy, which is nothing like what CONS makes in lisp (a mutable pair that is the basis for building singly-linked lists). Note that linked-lists are only a good data structure in fairly narrow contexts (e.g. shared structure, certain types of mutation you can do). Sinc…

However, conses can be used for other types of structures as well.

Re: Why Ruby is an acceptable Lisp (2005)

#93

Post by qwertyuiop924 »

aidenn0 wrote: post #87
DigitalJack wrote: post #60

Earlier quoted context omitted.

As a clojure fan, I agree about conses. It's rare to use something like that. Personally I'm happy equality doesn't work like common lisp. See here for a post explaining equality in CL: http://eli.thegreenplace.net/2004/08/08/equality-in-lisp It's old and I don't use common lisp, so please correct me or the post if needed. I've tried to get into lisp numerous times. Clojure was the one that clicked for me. I can't sa…

Yes, CL has old and useless functions. There is zero need to ever use SETQ for example. SETF is a pure superset of SETQ's functionality. For other examples, I don't know that I've seen a serious use of PROGV or PROG in this century either. Most experienced lisp programmers never use EQ, since EQL is more well designed, and the overhead is either negligible or nonexistent. Yes it's annoying that EQUAL doesn't recurse…

SETQ has to exist, because it is the primitive SETF is based upon. EQ is tremendously useful for testing identity (which is kind of its job...), and conveys intent (although I mostly use Scheme, where eq? is a lot nicer). And Scheme's macros don't have to be super complicated. explicit rename, implicit rename, and syntactic closure macro systems are almost as simple as CL macros.

Re: Why Ruby is an acceptable Lisp (2005)

#94

Post by zodiac »

aidenn0 wrote: post #88
nilved wrote: post #83

Earlier quoted context omitted.

How are conses in Clojure different from those in Scheme? Is it the implementation? Because the API seems the exact same to me.

Not a Clojure developer but, IIRC, Clojure doesn't have conses, but rather the function cons creates a seq. A Seq in Clojure is immutable and (usually) lazy, which is nothing like what CONS makes in lisp (a mutable pair that is the basis for building singly-linked lists). Note that linked-lists are only a good data structure in fairly narrow contexts (e.g. shared structure, certain types of mutation you can do). Sinc…

Didn't racket also make the decision to make cons create immutable lists (and using mcons for mutable lists)?

Re: Why Ruby is an acceptable Lisp (2005)

#95

Post by ufmace »

mnemonicsloth wrote: post #48
ufmace wrote: 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…

I don't know ruby, so I can't answer your question directly. But I can ask you one: why not just learn a lisp? You don't have to learn a whole language to know what makes people like it. Working at it for a week or two, in you free time, would probably be enough for you to settle the question permanently. Lisp doesn't have to be a search for nirvana.

Maybe one of these days... I've been spending what time I have for learning completely different languages on Haskell, and I haven't messed with that in a while either.

Re: Why Ruby is an acceptable Lisp (2005)

#96

Post by qwertyuiop924 »

feelsboutlisps wrote: post #91
ordu wrote: post #84

Earlier quoted context omitted.

> in languages like Python, with syntax built-in, people build large apps without ever doing this, making their code far more understandable for the next person that touches it. No. Lack of macros makes code bigger, more error prone and harder to understand. When I use something like cl-ppcre:do-register-groups, this one word hides all the loop orginization, and underlines meaning of local variables which are bound t…

> 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 with statement!" But that was just an example: there are things python will never have that you can add to lisp yourself. Like multimethod dispatch and generics, anaphoric operators, lazy module loading, pattern matching, ADTs, regex literals (with readtables), non-deterministic operators (the classic amb/assert operators, for concisely expressing searching a list (although they're admittedly more toys than anything else)), and a full-on looping construct that allows for awk-style record processing of arbitrarily typed records from arbitrary sources (field splitting is handled by other functions). And that's just a few examples I came across. There are dozens of others.

That would never all be added to the language: there's way too much, and it's too specialized.

As for your theory that macros make code harder to understand, you don't have any proof. In fact, you have negative proof, as there's plenty of logic, good programming practice, and individual cases indicating that careful use of macros can make code easier to understand.

Re: Why Ruby is an acceptable Lisp (2005)

#97

Post by qwertyuiop924 »

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…

if your teammates are careful, and don't go overboard on macros, than their code will be just as readable as it would be in any language. But that's true of any feature. s/macros/(splitting the program into functions|using gotos|building a class hierarchy)/. You can write INTERCAL in any language.

And you keep talking like it's a tradeoff. For you, it may be. But for many of us who write Lisp, the paren-laden syntax is actually enjoyable: it's unambiguous, easy to write so long as the parens match up, and easy to read if you've indented it properly. And if you've got a half-decent editor, it'll indent and match parens for you. With Emacs and paredit, it's even nicer than many other languages: you'll be flinging sexprs around before you know it :-D.

Futhermore, you seem to think 90% of Lisp is macros: in fact, I hardly ever write them. I'm glad they're there when I need them, but when I don't, I write perfectly ordinary code just like anybody else, except that it's more pleasant to write because there's faster iteration, better tooling for manipulating code, and a nice, regular syntax that lets me forget about it, so I can focus on the parts of my code that matter, and get s#!t done.

Re: Why Ruby is an acceptable Lisp (2005)

#98

Post by qwertyuiop924 »

zodiac wrote: post #94
aidenn0 wrote: post #88

Earlier quoted context omitted.

Not a Clojure developer but, IIRC, Clojure doesn't have conses, but rather the function cons creates a seq. A Seq in Clojure is immutable and (usually) lazy, which is nothing like what CONS makes in lisp (a mutable pair that is the basis for building singly-linked lists). Note that linked-lists are only a good data structure in fairly narrow contexts (e.g. shared structure, certain types of mutation you can do). Sinc…

Didn't racket also make the decision to make cons create immutable lists (and using mcons for mutable lists)?

But that's not what Clojure did. In clojure, cons cells aren't cons cells: they're a cell that can point to a sequence of some type, and contain a pointer to arbitrary data. They also do not make up lists, and have weird equality rules.

Racket's conses are merely immutable.

Re: Why Ruby is an acceptable Lisp (2005)

#99

Post by fiddlerwoaroof »

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 much of the semantics as
  possible is kept in normal functions. Therefore, a macro
  WITH-FOO is often limited to generating a call to an
  auxiliary function CALL-WITH-FOO with arguments deduced
  from the macro arguments. Macro &body arguments are
  typically wrapped into a lambda expression of which they
  become the body, which is passed as one of the arguments of
  the auxiliary function.

Re: Why Ruby is an acceptable Lisp (2005)

#100

Post by fiddlerwoaroof »

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…

Here's the referred to article: http://web.archive.org/web/20160412082050/http://random-stat...
Post reply on HN