No, It is not acceptable.
Why Ruby is an acceptable Lisp (2005)
71–80 of 115 posts
Re: Why Ruby is an acceptable Lisp (2005)
#72I'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…
Macros, arbitrary syntax transformation in macros, and object system as powerful as CLOS, and the ability to comfortably use almost any paradigm. It's not always useful, but you'll be thankful when it is.
> Macros
I don't want my teammates writing macros. When the whole programming community constantly talks about situations within regular, more expressive languages (with syntax) like Python et al, where teammates look at each others code and are baffled ... I struggle to see a scenario where inventing syntax through macros is a good idea, and won't make that situation so much worse.
> arbitrary syntax transformation in macros
See above.
> object system as powerful as CLOS
If I wanted object systems, there are plenty of options that don't involve so many parens, and do involve far more expressive syntax than lisps offer.
> and the ability to comfortably use almost any paradigm
I kinda want my team to pick a set of known paradigms. This is not an advantage. I've never used a modern programming language and thought 'this lacks paradigms, if only I could let my team invent some, that none of us will understand 6 months from now'.
> It's not always useful, but you'll be thankful when it is.
From what you've said, I won't. I'll just be upset my teammates invented their own language with macros and whatever paradigms they chose to use that day.
The lisp 'trade-off' (homoiconicity over expressive syntax) just seems like it's looking for power in the wrong places. Power like that is more often bad than good.
Re: Why Ruby is an acceptable Lisp (2005)
#73A 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 Ste…
I don't actually know how I feel about the contents of this article, but it _did_ generate a lot of lively discussion and made a lot of people think. So in that regard, I feel that it's a success.
Re: Why Ruby is an acceptable Lisp (2005)
#74Earlier quoted context omitted.
Macros, arbitrary syntax transformation in macros, and object system as powerful as CLOS, and the ability to comfortably use almost any paradigm. It's not always useful, but you'll be thankful when it is.
> Macros I don't want my teammates writing macros. When the whole programming community constantly talks about situations within regular, more expressive languages (with syntax) like Python et al, where teammates look at each others code and are baffled ... I struggle to see a scenario where inventing syntax through macros is a good idea, and won't make that situation so much worse. > arbitrary syntax transformation…
GPP asked what lisp's got that Ruby doesn't. I told him. Lisp isn't the end-all be-all. If you can't trust your teammates, than maybe you shouldn't be using Lisp. But keep in mind that you can write INTERCAL in any language. Lisp just makes it easier, because Lisp does its best not to limit you.
Besides, who would invent their own language in macros for no reason?
Also, the syntax is one of the best parts about Lisp. It's agressively regular, so you'll never have to worry about screwups or ambiguity. And with readtables, the syntax can be more expressive than you might think. Although you did set the standards pretty low...
Re: Why Ruby is an acceptable Lisp (2005)
#75Earlier quoted context omitted.
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 Ste…
I don't actually know how I feel about the contents of this article, but it _did_ generate a lot of lively discussion and made a lot of people think. So in that regard, I feel that it's a success.
Fair 'nuff. That is a major benefit. Steve Yegge's response is way more interesting than the article itself.
Re: Why Ruby is an acceptable Lisp (2005)
#76Earlier quoted context omitted.
Macros, arbitrary syntax transformation in macros, and object system as powerful as CLOS, and the ability to comfortably use almost any paradigm. It's not always useful, but you'll be thankful when it is.
> Macros I don't want my teammates writing macros. When the whole programming community constantly talks about situations within regular, more expressive languages (with syntax) like Python et al, where teammates look at each others code and are baffled ... I struggle to see a scenario where inventing syntax through macros is a good idea, and won't make that situation so much worse. > arbitrary syntax transformation…
On large team Lisp projects, you don't have every individual person arbitrarily invent their own idiosyncratic abstractions. The project as a whole has a common set of abstractions that fit the domain, which are designed and modified the way you would design the abstractions regardless of the language and programming paradigm you're using. Macros are a language tool that lets you build abstractions, in some cases imo allowing better abstractions than would be possible without macros, most often ones simulated somewhat clunkily with OO features (or something godawful like C++ template metaprogramming). But if you have a large team project you still need an actually functioning team, common abstractions, project management, documentation, code review, the usual stuff. Successful large Lisp projects of course do all that.
I don't see a meaningful difference here between Lisp and, say, C++. If you have a dysfunctional team writing C++, full of cowboy programmers who invent their own idiosyncratic abstractions without coordinating with anyone, the fact that C++ doesn't have proper macros doesn't really meaningfully limit the resulting damage. What stops it from happening in functional teams isn't that C++ the language prevents it from happening, but that the team has some kind of working process that allows them to successfully write code as a team.
Re: Why Ruby is an acceptable Lisp (2005)
#771) "Ruby is a denser functional language than Lisp"
Lisp is a regular, explicit language. It does not strive for micro-density, but rather tends to achieve macro-density by allowing more expressive abstraction and transformation in the larger componentry of your projects. Its regularity around parenthetical s-expressions is the source of its expressive power.
Things like "(+ (aref x 3) 4)" are larger than "x[3]+4", but the operations and source code representation in Lisp are directly accessible to matching and transformation without having to go through extra rigmarole to deal with classes of AST node objects or whatever. This makes the usefulness of these features immediately accessible for everybody, and useful for quick utility, not just major undertakings.
2) "Ruby gives you about 80% of what you want from macros"
I'm sorry, but this section is simply ignorant of what Lisp macros are for. Simple syntactic sugar is obviously possible with macros, but certainly not its major use. Providing abstract constructs that require custom code generation, creating lower-level boilerplate (like auto-creation of introspective data structures and customized support functions), and wrapping custom behavior around inline scopes are the primary uses I've seen and used. Ruby can do a little of it, but I see no "80% of what you want" there.
3) "Ruby's libraries, community, and momentum are good"
Quicklisp was created after this article was written, and has been a godsend to the community. Lisp tends to develop a very roll-your-own culture because of its quick accessibility of creating abstractions, but the ease at which you can publish & reach for libraries with QL has brought a lot of cultural shift towards reuse. There are a ton of both esoteric and practical libraries out there, and common libraries for threading, networking, OS interaction, etc, are the common case now (and actually have been for quite a while before Quicklisp as well).
There's tons of interoperating flexibility because the language provides a huge baseline (especially its object system), so it doesn't all need to lock into an on-top-of-Lisp infrastructure that would constrain the programmer's options. It's a good time to be in Common Lisp.
Re: Why Ruby is an acceptable Lisp (2005)
#78Earlier quoted context omitted.
Wish more people understood this about tcl
Maybe this is meta (the wish) :-) I remember tcl in the early 90s then it disappeared from my radar, mostly web and mobile apps. Honest question: is it still relevant in some application area?
Hah yeah I realized that meta joke after I posted
Re: Why Ruby is an acceptable Lisp (2005)
#79Earlier quoted context omitted.
> Macros I don't want my teammates writing macros. When the whole programming community constantly talks about situations within regular, more expressive languages (with syntax) like Python et al, where teammates look at each others code and are baffled ... I struggle to see a scenario where inventing syntax through macros is a good idea, and won't make that situation so much worse. > arbitrary syntax transformation…
On large team Lisp projects, you don't have every individual person arbitrarily invent their own idiosyncratic abstractions. The project as a whole has a common set of abstractions that fit the domain, which are designed and modified the way you would design the abstractions regardless of the language and programming paradigm you're using. Macros are a language tool that lets you build abstractions, in some cases imo…
> 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 understandable for the next person that touches it.
> I don't see a meaningful difference here between Lisp and, say, C++.
Agree :) (joke)
> If you have a dysfunctional team writing C++, full of cowboy programmers
At no point am I suggesting we can save ourselves from cowboys ...
> What stops it from happening in functional teams isn't that [...] the language prevents it from happening, but that the team has some kind of working process that allows them to successfully write code as a team.
But people are arguing 'the whole point' of lisps is that you can be free to do this, and that this justifies the 'paren-crazy', syntax-less language trade-off, and I'm yet to see any justification it's necessary to allow this at all.
What I'm saying is that all the lispy parens give you are footguns and all you're saying is that good teams don't use those guns. Well then why give them the guns at all. Why not give them a language with decent syntax instead.
Re: Why Ruby is an acceptable Lisp (2005)
#80Earlier quoted context omitted.
> Macros I don't want my teammates writing macros. When the whole programming community constantly talks about situations within regular, more expressive languages (with syntax) like Python et al, where teammates look at each others code and are baffled ... I struggle to see a scenario where inventing syntax through macros is a good idea, and won't make that situation so much worse. > arbitrary syntax transformation…
GPP asked what lisp's got that Ruby doesn't. I told him. Lisp isn't the end-all be-all. If you can't trust your teammates, than maybe you shouldn't be using Lisp. But keep in mind that you can write INTERCAL in any language. Lisp just makes it easier, because Lisp does its best not to limit you. Besides, who would invent their own language in macros for no reason? Also, the syntax is one of the best parts about Lisp.…
> Also, the syntax is one of the best parts about Lisp.
I think you're in the minority there. I would hope most people agree that Lisp 'sacrifices syntax in the name of homoiconicity'.
If not, then we have different definitions of syntax and I'm not sure any discussion on that is likely to go anywhere.