Live data from Hacker News

What Pythonistas Think of Ruby

blog.peepcode.com

231–240 of 247 posts

Re: What Pythonistas Think of Ruby

#231

Earlier quoted context omitted.

As a non lisp programmer, it is hard for me to automatically see what is going on in a lisp program because of mismatched " ' " and a lot of parenthesis. I believe this is one of his points. When I was learning python, or ruby, for that matter ( I use both! ) I never felt like I had no idea what was going on in the code even before I learned the languages.

Should this really be so surprising, though? Lisp is based on a different model of computation than Python and Ruby. You can't follow non-trivial C code without understanding pointers, or Prolog without understanding unification. Syntax aside, the semantics of Python are intended to be unsurprising to people with a conventional programming background. I don't have any practical experience with Ruby, but it looks like…

> I don't have any practical experience with Ruby, but it looks like a mishmash of Smalltalk and Perl to me

Those are, I think, probably the two most influential sources of inspiration for how the language is put together, in terms of the actual end result.

Re: What Pythonistas Think of Ruby

#232
post #177

Earlier quoted context omitted.

I should probably try to learn lisp. I primarily use emacs, so it would make a lot of sense. Some of the ruby/rails stuff out there for emacs really isn't very good.

Emacs lisp is handy for toying around with the editor, but it's a horrible Lisp. It does not even have lexical scoping. You are much better off in terms of entertainment (through learning interesting stuff) with e.g. PLT Scheme or perhaps Arc. (My comment about pure languages above was meant to highlight the joys of Clean and Haskell. Curry may also be worth a look. And Prolog, if you dare.)

> You are much better off in terms of entertainment (through learning interesting stuff) with e.g. PLT Scheme or perhaps Arc.

. . . but if you want to actually use a LISP for practical programming, and you start out with any Scheme, you're going to have to follow that up by learning another (non-Scheme) LISP. You might as well just start out with Common Lisp and be done with it.

Judging by my experience, Scheme is not a language one should set out to learn so much as a language one should learn as a side-effect of going through a book like SICP or The Little Schemer. Trying to do anything "real" with Scheme is an exercise in frustration, especially if you want it to be portable across Scheme versions, since the biggest names in Scheme implementations appear to be entirely uninterested in library portability except where "portable" means "Well, we can use it, and don't care whether you can."

Scheme itself is an excellent language, though. Too bad that, alone, is not enough.

Re: What Pythonistas Think of Ruby

#233
post #98
post #26

Earlier quoted context omitted.

I wholeheartedly agree that all languages should be judged on the quality of their libraries and implementation, as well as the success of the projects implemented on top of them. Ruby and Python have a pretty good track record there. One of the themes of Gary's talk was that Ruby is more expressive/flexible than Python, and lisp was thrown into the discussion as sort of a "gold standard" of expressiveness/flexibilit…

> I wish Python just had some kind of anonymous function syntax that was more rich than lambdas A lot of people keep saying this, including the article author, and I'm having trouble understanding why. Lambdas are for "one-liners", functions are for more-liners. Any time you want to write multiple lines in a lambda it's trivial to make it a named function. def listSomeTable(name): print name.center(40, "=") def getWe…

> Lambdas are for "one-liners", functions are for more-liners.

The problem, though, is that this is entirely a Python conceit. It is in no way, shape, or form any kind of programming truism. In fact, taking a more principles-oriented approach, a named function is really just a special case of a lambda. I think this may be one of those things that using a LISP (such as Scheme or Common Lisp) helps people realize.

This:

    (define (foo n)
      ( . . . ))
. . . is just syntax sugar for this:

    (define foo
      (lambda (n)
        ( . . . )))
The fact that the syntax sugar is all many languages expose to the programmer doesn't change that fact, and the one-line restriction on "lambdas" in Python seems quite arbitrary.

Re: What Pythonistas Think of Ruby

#234
post #177

Earlier quoted context omitted.

Emacs lisp is handy for toying around with the editor, but it's a horrible Lisp. It does not even have lexical scoping. You are much better off in terms of entertainment (through learning interesting stuff) with e.g. PLT Scheme or perhaps Arc. (My comment about pure languages above was meant to highlight the joys of Clean and Haskell. Curry may also be worth a look. And Prolog, if you dare.)

> You are much better off in terms of entertainment (through learning interesting stuff) with e.g. PLT Scheme or perhaps Arc. . . . but if you want to actually use a LISP for practical programming, and you start out with any Scheme, you're going to have to follow that up by learning another (non-Scheme) LISP. You might as well just start out with Common Lisp and be done with it. Judging by my experience, Scheme is no…

What happened to the library situation in Common Lisp? Your comment looks like it improved since the last time I checked. That would be nice. (Though I fear Common Lisp is still too ugly for me to enjoy it. Perhaps some reader macro magic could rectify the situation. ;o)

Re: What Pythonistas Think of Ruby

#235
post #234

Earlier quoted context omitted.

> You are much better off in terms of entertainment (through learning interesting stuff) with e.g. PLT Scheme or perhaps Arc. . . . but if you want to actually use a LISP for practical programming, and you start out with any Scheme, you're going to have to follow that up by learning another (non-Scheme) LISP. You might as well just start out with Common Lisp and be done with it. Judging by my experience, Scheme is no…

What happened to the library situation in Common Lisp? Your comment looks like it improved since the last time I checked. That would be nice. (Though I fear Common Lisp is still too ugly for me to enjoy it. Perhaps some reader macro magic could rectify the situation. ;o)

I don't know if the library situation is good in Common Lisp. It's just enough worse in Scheme that it's kind of ridiculous to consider actually using it for other than academic purposes.

Re: What Pythonistas Think of Ruby

#236
post #177

Earlier quoted context omitted.

I should probably try to learn lisp. I primarily use emacs, so it would make a lot of sense. Some of the ruby/rails stuff out there for emacs really isn't very good.

Emacs lisp is handy for toying around with the editor, but it's a horrible Lisp. It does not even have lexical scoping. You are much better off in terms of entertainment (through learning interesting stuff) with e.g. PLT Scheme or perhaps Arc. (My comment about pure languages above was meant to highlight the joys of Clean and Haskell. Curry may also be worth a look. And Prolog, if you dare.)

I'd say that learning Scheme is more likely to convey what's interesting about Lisp, and there is quite a bit of great programming literature associated with Scheme. I'm not sure if it's easier to learn CL after Scheme or vice versa, though.

I still haven't done anything with Prolog past using it for prototyping, but it has some really cool ideas, and I hope to have a good excuse to play with it more soon. (And it, too, has some great books.)

Re: What Pythonistas Think of Ruby

#237
post #178

Earlier quoted context omitted.

You do Haskell don't you? :-)

Yes, and Clean. I just like to counter those smug Lispians. Lisp has nice syntax, but the underlying semantics is nothing to write home about any longer. Add tail call optimization to Python (and perhaps continuations) and you have something similar to Scheme modulo syntax.

[deleted]

Re: What Pythonistas Think of Ruby

#238

Earlier quoted context omitted.

> Nothing in your sarcastic "Uh ..." missive makes me or anyone else care about the features you just named. Yes, I know Ruby doesn't have True Lisp Macros. The point is, why should I care? What real-world problem can I not solve elegantly in Ruby because it lacks this language feature? It allows for the creation of real Domain Specific Languages and the real extension of lisp for a given problem domain. Do you need…

> It allows for the creation of real Domain Specific Languages and the real extension of lisp for a given problem domain. I think the problem was that until now you weren't giving any examples that explained how Common Lisp macros were giving one any greater ability to do this sort of thing than Ruby. One could say "Ruby allows for the creation of real Domain Specific Languages and the real extension of Ruby for a gi…

> Also . . . I totally understand the desire to keep (non-earth-shattering) performance differences out of the discussion. After all, one doesn't use Ruby to write realtime systems in the first place. The performance of its implementations is simply not impressive. If I've chosen to use Ruby for something, I've already thought about the performance implications and decided that the performance penalties of Ruby as compared with something like C (or even Perl) are not limiting factors for the particular task I choose to tackle. As such, it makes sense to say "Please tell me about the syntactic and semantic value of Lisp macros, rather than the performance benefits of a Lisp implementation over a Ruby implementation."

Well also Lisp macros are more comprehensive. Ruby can only make DSLs that look mostly like Ruby. In Lisp, you can literally drop in a new parser if you really want to. In fact, the default PLT Scheme DrScheme distribution has an Algol implementation that is basically a macro set (with some special features).

This allows you to inject whole new programming paradigms into your code. If you need a special kind of OO, you can easily create it. This is actually incredibly-hard-borderline-impossible to do in Ruby. Especially when you get into anaphora injection and complex closure manipualtion.

> You did, however, get into a little more explanation this time, which is good. I just wanted to point out that your disbelief at the notion that someone didn't achieve enlightenment based on your previous comment seems a bit unwarranted.

I had the same reaction this morning when a teenager asked me, "Okay so I get pointers. I get what they are. But they don't see good for anything in the real world." If you find this offensive or dismissive, I apologize. I am simply saying that I think you and I are operating at entirely different levels of abstraction, and bridging that gap is difficult for me.

Re: What Pythonistas Think of Ruby

#239
post #223

Earlier quoted context omitted.

> Nothing in your sarcastic "Uh ..." missive makes me or anyone else care about the features you just named. Yes, I know Ruby doesn't have True Lisp Macros. The point is, why should I care? What real-world problem can I not solve elegantly in Ruby because it lacks this language feature? It allows for the creation of real Domain Specific Languages and the real extension of lisp for a given problem domain. Do you need…

Thanks Dave. What I'm hearing (and feel free to correct me) is that the gain over Ruby is not as much about additional expressiveness as it is about providing this expressiveness with equivalent performance to that of in-built language operators. That's fair. I've used Lisp quite a bit (in fact, I did almost all of my first significant programming in Scheme) and even with that background, I've never bought the claim…

> I've used Lisp quite a bit (in fact, I did almost all of my first significant programming in Scheme) and even with that background, I've never bought the claim that Lisp gives you some huge practical syntactical/semantic gain over Ruby's already extremely expressive and extensible syntax. I guess I was hoping to be swayed.

Ruby's syntax is hardly extensible at all. All you're doing is changing the default scope with instance_eval and producing objects with the right intermediate behaviors. You can make some neat little DSLs with this trick, but it's not a real extension to the language.

For example try making the classic anaphoric if in ruby. Can't be done without resulting to cheap excuses like "Well it's a block argument."

It also frustrates me that people have thousands of objections to the pros people put forward for lisp, but no real objections except for an argument about parenthesis that's not even really true anymore. Prefix notion maybe? Oh no your arithmetic is slightly jumbled, everything else is exactly as you use it.

Re: What Pythonistas Think of Ruby

#240
post #223

Earlier quoted context omitted.

Thanks Dave. What I'm hearing (and feel free to correct me) is that the gain over Ruby is not as much about additional expressiveness as it is about providing this expressiveness with equivalent performance to that of in-built language operators. That's fair. I've used Lisp quite a bit (in fact, I did almost all of my first significant programming in Scheme) and even with that background, I've never bought the claim…

> I've used Lisp quite a bit (in fact, I did almost all of my first significant programming in Scheme) and even with that background, I've never bought the claim that Lisp gives you some huge practical syntactical/semantic gain over Ruby's already extremely expressive and extensible syntax. I guess I was hoping to be swayed. Ruby's syntax is hardly extensible at all. All you're doing is changing the default scope wit…

Ruby's syntax is hardly extensible at all. All you're doing is changing the default scope with instance_eval and producing objects with the right intermediate behaviors. You can make some neat little DSLs with this trick, but it's not a real extension to the language.

Whatever. The fact is that in Ruby you can easily write a DSL that looks as if it was custom rolled for the domain and task at hand. In fact, you can do it so transparently that people begin learning the DSL without learning Ruby (cf. Rails). If that doesn't mean Ruby's syntax is extensible, I don't know what does. (And, yes, I get the difference between Ruby's implementation of DSL support and True Lisp Macros; it's just unclear that the difference matters in any significant semantic way.)

I thought we were past trying to praise Lisp's features over Ruby's simply by calling Lisp's "real" (where "real" means exactly the same as Lisp's down to the backquotes and preprocessor). That argument is tautological: no language could ever possibly measure up to Lisp with that kind of criteria.

For example try making the classic anaphoric if in ruby. Can't be done without resulting to cheap excuses like "Well it's a block argument."

Raganwald et al seem to have managed just fine.

http://github.com/raganwald/homoiconic/blob/master/2009-09-2...

And deriding the brackets is just as meaningless as someone deriding the parentheses in Lisp. Speaking of which:

It also frustrates me that people have thousands of objections to the pros people put forward for lisp, but no real objections except for an argument about parenthesis that's not even really true anymore. Prefix notion maybe? Oh no your arithmetic is slightly jumbled, everything else is exactly as you use it.

Not my issue. Heck, I like Lisp! That said, I think Lisp evangelists are failing to make a case for it over, say, Ruby for precisely the reasons discussed ad nauseam in this thread.

Post reply on HN