@jessenoller has a great summary of concurrency in Python: http://jessenoller.com/2009/02/01/python-threads-and-the-glo...

The two worlds seem very similar.

The speed can be sorted as (in most cases): single-threaded code, single-threaded with GIL, single-threaded with fine locks.

As many others have said, changing syntax is really one of the most trivial parts for alternative implementations to keep up with when moving to new versions. That "hurt" hasn't been fixed because it doesn't really hurt very much...

Guido's take: http://www.artima.com/weblogs/viewpost.jsp?thread=147358

Arcieri's take: http://www.unlimitednovelty.com/2009/03/indentation-sensitiv...

It's not hard if we disallow statements, and make everything into an expression that returns a value -- something that Ruby does right. The value of a block of statements is just the value of the last statement in the block.

So, whether you call it a function, or a method, or a lambda, or a block, whitespace with multi-line expressions can be made to work.

The commonly-cited lambda-with-multiple-prints example, in CoffeeScript:

    count: ->
      print 'one'
      print 'two'
      print 'three'

http://pypi.python.org/pypi/withhacks/

Python itself does varying degrees of bytecode optimisation depending on which version you're using.

FLAMEBAIT -> FLAMEBAIT

Whether it is a good reason, and whether these considerations are sensible, is a separate discussion. Whichever way you put it: they exist and should be acknowledged.

As I sit here writing this, it strikes me that someone who's using these kinds of things to avoid learning Lisp is a lot like the Python newbie who's discovered the language and wanders on to comp.lang.python complaining about the syntactically significant indentation. As with most matters, I'm inclined to believe that Lisp's problem here is primarily a people problem rather than a technical problem.

The Python 3 version is using a function annotation.

In Python 2 or 3 you could use a context manager (with statement) to similar effect.

Oh, come on. You're just disagreeing for effect here.

I've never used Ruby but that snippet is clear as day.

The Python 3 snippet suggests to me that the output would be "/hi" though :)

  Oh, come on. You're just disagreeing for effect here.
  I've never used Ruby but that snippet is clear as day.

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?

  def foo(f):
    f()

  (define (foo f) (f))

    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

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.

> I doubt that we've used a disjoint set of web libraries,

I guess I mis-spoke slightly. I meant assigning a function to a route, because I consider that (in this case) it's an anonymous function to be an irrelevant detail. Basically, to me

    get "/hello", hello
    def hello
        puts "hello"
     end

Anyway, thanks for the discussion. We've apparently boiled it down to taste, so it's a good thing there are multiple languages, I guess.

It's unclear what "get" is. Is it a function? What does it return? My guess would be that it returns a function bound to the handler of a "/hi" url, but that's a guess.

And the block is bound to the uri given in the string, so your guess is correct.

It's also possible that one of the things in the article is the gotcha, flexible parenthesis. By convention, Rubyists tend to use parenthesis when defining functions, but not when calling them:

    def get(path, opts={}, &block)

    get "/hello" do

    get("hello") do

    Users.find_all_by_age(23).select {|user| user.first_name == "steve" }

Fair enough. Arguing over beauty is silly anyway, I just wanted to point out that the entire thing is entirely subjective.

> The Python 3 version is using a function annotation.

Thanks, checking out PEP 3107 now. I've always seen annotations done with the @annotation syntax like the Python 2 snippet has.

The @ syntax is for decorators. Different beast altogether.

I've used decorators to add attributes to function objects in several projects in the past -- you don't have to wrap the original.