Nice article. One correction: python does have 'yield'.
What Pythonistas Think of Ruby
211–220 of 247 posts
Re: What Pythonistas Think of Ruby
#212Re: What Pythonistas Think of Ruby
#213Earlier quoted context omitted.
> 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 scro…
The Ruby code is not an annotation. It's very close to passing an anonymous function to a function. The definition of get is
def get(path, opts={}, &block)
# Defining a `GET` handler also automatically defines
# a `HEAD` handler.
def get(path, opts={}, &block)
conditions = @conditions.dup
route('GET', path, opts, &block)
@conditions = conditions
route('HEAD', path, opts, &block)
end
Re: What Pythonistas Think of Ruby
#214Earlier quoted context omitted.
I like the choice of image--a king snake. Looks venomous, but is harmless.
The caption says San Pueblan Milksnake, but still.
Milk Snakes are a kind of King Snake. I had way too much time on my hands with Time Life's "Reptiles" hardcover when I was little...
The poisonous snake the stripes are thought to mimic:
http://minuet.dance.ohio-state.edu/~gallo54/images/words/sna...
Re: What Pythonistas Think of Ruby
#215Earlier quoted context omitted.
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 scro…
The Ruby code is not an annotation. It's very close to passing an anonymous function to a function. The definition of get is def get(path, opts={}, &block) See that &block? Here's the actual source of get: # Defining a `GET` handler also automatically defines # a `HEAD` handler. def get(path, opts={}, &block) conditions = @conditions.dup route('GET', path, opts, &block) @conditions = conditions route('HEAD', path, op…
The Ruby code is not an annotation.
Which is exactly the problem: it should be, because it is meta-information about when the function is supposed to be called. It's not a good idea to wrap that into a function, together with the code that is supposed to be executed, because you are mixing two completely different kinds of information into some new function. This code is being too clever for it's own good: it condenses information so far that you are forced to think harder about what each piece means. I consider this is one of the main dangers of languages like Ruby: it's proponents lose sight of the fact that they are coming full circle, back to writing code that's so clever that no one in the future will understand it.
every web library I've used has worked this way.
I doubt that we've used a disjoint set of web libraries, so my only answer can be: no, they haven't worked that way. Most libraries map paths to named functions separately from implementing the functions.
Conciseness is not an ultimate goal; in fact, it is rather the opposite, as those that suffered under the clever C hacks of others will tell you. To paraphrase Santanyana: people have forgotten the past and are repeating it.
Re: What Pythonistas Think of Ruby
#216Earlier quoted context omitted.
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 unde…
Oh, I did not want to create a `versus' argument. Please pardon me, if I did.
Re: What Pythonistas Think of Ruby
#217A main take away point: Ruby is better for writing DSLs (which is what I am doing for one customer right now)
Scala is awesome for writing DSLs allowing things that I wouldn't even know how to start in Ruby. (granted, my Ruby-Fu is sub-par so the fault likely lies with me).
http://blog.fogus.me/2009/03/26/baysick-a-scala-dsl-implemen...
Re: What Pythonistas Think of Ruby
#218Earlier quoted context omitted.
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...
Really? That's the example you want to use. First thing I see on that page:
get / 'orders' >> :orders > :index
with route / :slug / 'order' >> :orders do
get > :show
put > :update
end
get {'item_images' => :controller} / :image > :show
Re: What Pythonistas Think of Ruby
#219Earlier quoted context omitted.
The prototypical ruby case would be: def some_method(x, &block) yield x end then to call it: some_method "hey" { |v| print v } That might not look like much, but it allows you to create methods that can extend the language expressively and then use them without extra crufty syntax or sigils obstructing their meaning.
> some_method "hey" { |v| print v } I'm sure ruby is great once you're initiated, but despite >10 years of programming and having learned basic, c, pascal, lisp, java, c++, python, perl, bash, php and javascript, I have no idea what code does. Don't mean to harsh, just an observation.
I made that method absurdly generic, how about:
get "/hi" do |url|
print url
end
?Re: What Pythonistas Think of Ruby
#220Earlier quoted context omitted.
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…
> 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 given problem domain," with only a slight alteration in what one considers "real". As such, saying something like "Ruby doesn't give you real foo" doesn't tell anyone anything about what CL gives you that Ruby doesn't.
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."
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.