Keyword Arguments: Ruby, Clojure, Common Lisp

More like "how Ruby and Clojure don't really support keyword arguments". Unless you can do something like:<p><pre><code> &#62;&#62;&#62; def foo(a,b): ... print a,b ... &#62;&#62;&#62; foo(b=1,a=2) 2 1 </code></pre> then you don't support keyword arguments, you just have some hack for stuffing parameters into a hash. In fact, MacRuby had to add syntax to Ruby[1] in order to be able to represent Objective C keyword arguments.<p>[1] <a href="http://www.macruby.org/documentation/rubycocoa-to-macruby.html" rel="nofollow">http://www.macruby.org/documentation/rubycocoa-to-macruby.ht...</a>

Isn't being able to give functions as a default keyword argument more or less obvious when functions are first-class objects instead of it being insane? It's something that I use several times in any decent sized project.<p>For my bot for the current Google AI challenge I use A* pathfinding and one of the keyword args is the function for getting a node's neighbours.

Ruby has a penchant for giving you more than enough rope to hang yourself on, and "Ruby keyword arguments" are no different. I've seen them used in the wild. It's horrendous.<p>The code I had to update was poorly written, but the functions with "keyword arguments" were practically incomprehensible _because I didn't even know what their parameters were_. Furthermore, the interactions between these "keyword arguments" wasn't documented anywhere. Sometimes supplying one keyword demanded that another keyword also be supplied, less the function quietly fails.<p>Finally, there's no way to make a "keyword argument" a required argument. Every function I saw with keyword arguments was littered with "bar = foo.key?(:bar) ? foo[:bar] : default_value" or "throw Exception if not foo.key?(:bar)"<p>Don't use hashes as a replacement for argument lists in Ruby. Hack the Ruby source and add real keyword arguments.<p>edit: added another example

He spends a lot of time on the syntactic ambiguities of keyword arguments in Ruby when calling without parens. I understand how that's annoying, but how hard would it be to just put the parentheses back? He seems to be making a mountain of a molehill on that point.

A 2000 words article on keyword arguments which fails to mention any of Python, Objective-C and Smalltalk?

I've never found a situation where keyword arguments are a better choice than setters. Setters are dynamic, you can override their implementation. Keyword args only let you override the method that receives them, which provides less granularity and leads to duplication (assuming there is more than one method that accepts a shared arg).

quote: Positional arguments require mentally lining up the 7th argument in your function call with the 7th argument in the function signature, and so on.<p>If your function has 7 arguments, consider refactoring