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

What Pythonistas Think of Ruby

blog.peepcode.com

Post reply on HN
Print view View original

201–210 of 247 posts

Re: What Pythonistas Think of Ruby

#201

Post by KirinDave »

_pius wrote: post #199
KirinDave wrote: post #195

Earlier quoted context omitted.

> I think that part of the problem is that no one (whom I've seen, at least) has explained in a brief, easy to follow manner just what the Lisp macros get you beyond all of the parse tree manipulation, code generation, and "metaprogramming" you can already do with Ruby. Uh, the stuff you can do with ruby (short of the Ruby2Ruby parse tree generation) is incredibly limited compared to the arbitrary transforms that mac…

You're missing the point. 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 is fast enough" is a mantra you can foist off on people who haven't put up production systems on a Merb…

> 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 constraint propagation on a network of cells? You can make a macro that turns this into an operator in lisp. You can extract nearly any pattern out to the language and begin complex manipulations there.

Since you have a frame of reference I can use, let's talk about rails routes. Imagine if you could specify rails routes in a way at least as naturally as you do in ruby (albeit with more parenthesis, but with fewer line-noise symbols otherwise), but have this become the most efficient implementation of that specific routing table.

You get to have your cake (a syntax that is expressive and immediate) and eat it to (is transformed under the covers into the most optimal code for that task), with frosting (0 runtime penalty for this decision).

> Again, my point is that if you can't name a single real world benefit of macros over what's already in Ruby, then why should anyone care how fast they are?

I say "the language is extensible!" and you say "but what about the real world." Sir, I don't know how to get more real world than this. You use it a billion different ways all the time.

A simple example... I've been working a lot with the JodaTime library in clojure, and I got sick of having to work with the ponderous Java-centric method for building PeriodFormatters (for an example see: http://www.bestinclass.dk/index.php/2010/02/reddit-clone-in-...). So what I've done is write a macro in just a few lines of clojure that lets me say:

    (period-formatter days ("day" "days") " "
                      hours ":" minutes ":" seconds)
If that's not cleaner and more usable, I dunno what is. You only need to write one or two formatters (and typically you need a few) before the macro has "paid itself off" in temrs of line count. And to the underlying code at run time, this code and the code snippet for the formatter from my link are basically indistinguishable. There is 0 runtime cost to this abstraction, but a lot of read-time improvement.

Could you do this particular example in ruby? You could do it to some extent, yes. But not without some significant work. Note, for example, that the argument list to the macro needs to be checked for strings after lists of strings, as this case is not directly supported by the underlying formatter.

Re: What Pythonistas Think of Ruby

#202

Post by pavelludiq »

eru wrote: post #178
j_baker wrote: post #159

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.

How a python vs ruby thread turned in to Haskell vs Lisp argument i will never know. The essence of Haskell is that its a lazy statically typed functional language, the essence of lisp is that it treats code as data. There is NOTHING stopping someone from making a Haskell with lisp syntax, and calling that lisp, in fact i think there is such a thing. Code as data is such a powerful idea, it is independent of the underlying paradigm of the language, you can have an algol with lisp syntax and it would be lisp, you can have smalltalk with lisp syntax and it would be lisp. Code is data is the only lisp feature you can't take away from lisp, because if you add it to your language, you don't have a new language, you have a new lisp.

Thats why lispers are smug sometimes, they know that their language will change dramatically in the future to adapt to the new environment, its the source of lisps immortality, it is destined to be reinvented.

Re: What Pythonistas Think of Ruby

#203

Post by dkarl »

chromatic wrote: post #196
dkarl wrote: post #194

Earlier quoted context omitted.

That's a trite response. Complexity, power, and culture differ between languages. In Perl, people make a game out of doing as much in a single line as possible. Experts do things that are mystifying to a beginner. In Python, an expert would be expected to produce a solution that is comprehensible to a less-expert programmer, spanning however many lines as are necessary. It would be un-Pythonic to write code that a le…

> It would be un-Pythonic to write code that a less expert programmer couldn't understand. I assume you have syntactical concerns and syntactical concerns only in mind, as domain knowledge and local style and creative decisions are far more important for maintainability. Even so, I don't believe you. I've seen far too much Python code which uses decorators and generators and list comprehensions to believe that it's u…

The point is that as a Python programmer, even a casual one, I know what decorators and generators are and can look up how they work. I can pretty confidently expect to figure out what they mean in any case I need to.

And yeah, the language has arguably become less Pythonic as it caters to more expert programmers at the expense of less expert ones. From the beginning, there have been people who claimed that primitive, clear, inelegant code is worse than elegant, concise code that depends on extra language features. Usually that claim has been rejected, but as sometimes happens in politics, the people who care enough to influence the process are not always the people for whom the process is supposed to work. I see decorators as something of a Trojan horse through which Python became more of a language for me (a software developer who copes with, and sometimes even likes, C++) and less of a language for my customers (scientists and engineers). Which is tragic because there are plenty of languages for software developers and not enough languages for people who just need something stupidly simple yet powerful enough for all practical purposes.

Still, despite the erosion of its simplicity, Python stands out for its philosophy of simplicity and its adherence to it. There remains a gulf between a language that sounded a clarion call for simplicity and has slipped a little from its principles and a language that chose the red pill and dove down the rabbit hole basically for the sheer beautiful hell of it.

Re: What Pythonistas Think of Ruby

#204

Post by jrockway »

chromatic wrote: post #190
jrockway wrote: post #173

Earlier quoted context omitted.

I might be wrong, but I really can't mention any other group of people trolling Perl discussions. Everyone is out trolling the Perl discussions. PHP developers hate us, Java developers hate us, Ruby developers hate us, and Python developers hate us. I think this is funny, because we generally don't hate the other languages, we just embrace and extend their good ideas for Perl. (The Perl community has come up with a f…

> Moose is from Smalltalk and CL... ... and Perl 6.

Yes, you're right. Adding state to traits is definitely a Perl 6 innovation.

Re: What Pythonistas Think of Ruby

#205

Post by jrockway »

dkarl wrote: post #194
chromatic wrote: post #191

Earlier quoted context omitted.

> Perl is also for dedicated professionals who want a tool that rewards more study and practice with more and more power -- mastery of Perl is a never-ending road with a seemingly never-ending escalation of power and awesomeness. That sounds more like programming (which you can teach yourself in ten years) than any specific language.

That's a trite response. Complexity, power, and culture differ between languages. In Perl, people make a game out of doing as much in a single line as possible. Experts do things that are mystifying to a beginner. In Python, an expert would be expected to produce a solution that is comprehensible to a less-expert programmer, spanning however many lines as are necessary. It would be un-Pythonic to write code that a le…

In Perl, people make a game out of doing as much in a single line as possible.

Wrong. It's not 1995 anymore.

Experts do things that are mystifying to a beginner.

And this is a Perl thing? What I've found from listening to beginners is that they accuse every programmer of intentionally mistifying them. OO is too hard. Macros are too hard. Monads are too hard.

Unfortunately, the experienced programmers use these features because there is a significant productivity advantage in doing so. They don't use the features to intentionally confuse beginners. The good news is that the beginners can use these features too, as soon as they are willing to admit that maybe the experts aren't actually out to subtly screw them over.

In Python, an expert would be expected to produce a solution that is comprehensible to a less-expert programmer, spanning however many lines as are necessary. It would be un-Pythonic to write code that a less expert programmer couldn't understand.

.

Re: What Pythonistas Think of Ruby

#206

Post by dkarl »

jrockway wrote: post #205
dkarl wrote: post #194

Earlier quoted context omitted.

That's a trite response. Complexity, power, and culture differ between languages. In Perl, people make a game out of doing as much in a single line as possible. Experts do things that are mystifying to a beginner. In Python, an expert would be expected to produce a solution that is comprehensible to a less-expert programmer, spanning however many lines as are necessary. It would be un-Pythonic to write code that a le…

In Perl, people make a game out of doing as much in a single line as possible. Wrong. It's not 1995 anymore. Experts do things that are mystifying to a beginner. And this is a Perl thing? What I've found from listening to beginners is that they accuse every programmer of intentionally mistifying them. OO is too hard. Macros are too hard. Monads are too hard. Unfortunately, the experienced programmers use these featur…

I don't think you get that cultures differ, or that Perl one-liners capture something about the Perl culture. There's nothing wrong with the Perl culture, and the Perl language is well-suited to it. It's certainly different from the Python culture. Not only that, the "Python culture" in the sense of people who write about and influence Python is not synonymous with Python programmers, not by a long shot. Programmers are different -- "programmers are programmers" only if you define programmers fairly narrowly as professional programmers who measure their worth by their ability to use programming languages in the most elegant and powerful way possible.

Among software developers, Python programmers are of course keen to demonstrate that Python is just as awesome as other languages. That isn't really the point of Python, though. Python's value was never in how it served people who could afford to devote a lot of time to mastering it. You wouldn't judge a Prius by how fast Michael Schumacher could drive it around a track, would you?

There is a whole population of programmers out there who really don't give a damn about programming languages and who rightly don't invest a lot of time in mastering programming. They exist, they do important work, and Python's ability to serve them is important -- that's the bottom line and the truth, even if this audience isn't eager to hear it. People like that are sensitive to the difference between Ruby and Python, and they've mostly never seen decorators.

Re: What Pythonistas Think of Ruby

#207

Post by Confusion »

steveklabnik wrote: post #146
Confusion wrote: post #129

Earlier quoted context omitted.

Oh, come on. You're just disagreeing for effect here. I've never used Ruby but that snippet is clear as day. The hell it is. I find it quite confusing. I'll take the Python 2 solution anyday, which clearly seperates what is called from when it is called. One of the main problems with the 'my language is so flexible' approach is that inventing concise solutions becomes a goal in itself.

> which clearly seperates what is called from when it is called You're passing some code as an argument to a function. Many other languages do this. Do you hate Lisp and Haskell, too? Do you not use continuations in Python? Or callback functions?

If you pass a function as an argument to a function, you're still separating what from when: the function declaration shows what; the invocation of the function shows when. It doesn't matter whether it's

  def foo(f):
    f()
or

  (define (foo f) (f))
That has nothing to do with annotating a function to show it binds to some URL and is invoked when an HTTP GET request is received with that URL. I don't like having to scroll through a source file to discover such bindings and I actually prefer them to be defined at a separate place. In that sense, the Python 2 solution isn't good either and suffers from the same problem I described earlier: people try to be so concise that they loose sight of other goals.

Re: What Pythonistas Think of Ruby

#208

Post by artpop »

kscaldef wrote: post #182
mjw wrote: post #171

Earlier quoted context omitted.

I think in those contexts, DSL is more a description of how an API feels to use, than a precise technical categorisation.` Ergonomic distinctions are useful though, as is the distinction between declarative-style APIs and more imperative ones, which 'DSL' is often used to make.

I have yet to see a Ruby "DSL" that didn't feel like Ruby. That is, unless you.talk :like => "this"

haml, sass, cucumber...

Re: What Pythonistas Think of Ruby

#209

Post by chromatic »

dkarl wrote: post #203
chromatic wrote: post #196

Earlier quoted context omitted.

> It would be un-Pythonic to write code that a less expert programmer couldn't understand. I assume you have syntactical concerns and syntactical concerns only in mind, as domain knowledge and local style and creative decisions are far more important for maintainability. Even so, I don't believe you. I've seen far too much Python code which uses decorators and generators and list comprehensions to believe that it's u…

The point is that as a Python programmer, even a casual one, I know what decorators and generators are and can look up how they work. I can pretty confidently expect to figure out what they mean in any case I need to. And yeah, the language has arguably become less Pythonic as it caters to more expert programmers at the expense of less expert ones. From the beginning, there have been people who claimed that primitive…

> There remains a gulf between a language that sounded a clarion call for simplicity and has slipped a little from its principles and a language that chose the red pill and dove down the rabbit hole basically for the sheer beautiful hell of it.

I'm don't understand what the difference between Scheme circa 1975 and R6RS has to do with Python.

It's awfully circular to claim that Python is beautifully Pythonic despite that it's become less Pythonic even as it's adhered to its philosophy of simplicity. If anything, I'd think that a language that "reads like pseudocode!" to the uninitiated wouldn't require even casual programmers to look up syntactic elements in the documentation, the way some people talk about Python.

Re: What Pythonistas Think of Ruby

#210

Post by draegtun »

kscaldef wrote: post #182
mjw wrote: post #171

Earlier quoted context omitted.

I think in those contexts, DSL is more a description of how an API feels to use, than a precise technical categorisation.` Ergonomic distinctions are useful though, as is the distinction between declarative-style APIs and more imperative ones, which 'DSL' is often used to make.

I have yet to see a Ruby "DSL" that didn't feel like Ruby. That is, unless you.talk :like => "this"

I have yet to see a Ruby "DSL" that didn't feel like Ruby

There are some out there though, for eg. FancyRoutes: http://www.railsinside.com/plugins/252-fancyroutes-a-nicer-d...

Post reply on HN