I agree on the origin of keyword lists but they do have a useufl property - the same key can appear multiple times. That's why they're right for varargs - because nothing stops the user using the same argument multiple times and sometimes (rarely) that makes for a good API.
Keyword arguments also encourage overly general functions that try to do everything, and there's a performance cost to that (such functions tend to include a mini arg parser and dispatch mechanism), and it's a wash on documentation, since looking up how to use such a function really isn't any harder than looking up which of a number of functions to use.
What makes ME sad is no keyword arguments. Helper/wrapper functions either get an annoying and difficult-to-grok-at-glance associative-array for it's params (bad), or a huge list of rarely-used parameters (worse), or a huge set of wrapper functions to set their own paramters (even worse), or outright duplicated functions for similar-but-not-quite tasks (worst).
This happens to me while producing something like a jqGrid, or other javascript/html hybrid stuff that need a few extra options sometimes.
Django/Python? No problem! Just use the keywords you need.
(More Info: The difference between a single associative param standing in for keywords arguments, or a huge list of regular arguments is a choice in complexity/readability IN the function vs. calling it.
For the single dictionary approach, you lost the built-in parameter defaults nicety, which means you need to handle the case of a missing parameter manually. This kind of sucks, especially if you hate seeing PHP Notices during development (which kill JSON/XML output anyway). This makes your function often twice as big (or more) than it needs to be.
For the other approach, you wind up with calling
foo("","","","real value", true, true, 2, false, false, "option I want");*
which just about invites all sorts of hard-to-find bugs, and you have to look at the function definition every time you want to change an option. Also, it's flat-out rude if you aren't the one calling the function.)
Keyword and optional arguments (seen in e.g. Python, Bash with --flags, and OCaml) are my favorite language superpower. They make code more self-documenting and let you add add optional behaviors to functions. This makes it really easy to make concise, highly usable APIs.
it's certainly a little syntactically ugly. I'd much prefer it if functions were first-class and I could write something like "widgets.any? can_frobnicate?" or "any widgets can_frobnicate?".
My (arc-like) lisp dialect has pervasive python-style keyword args, which I find makes code easier to read. See, for example, https://github.com/akkartik/wart/blob/master/063http-get.wts.... Tokens starting with a ':' are keyword args. Removing them doesn't change program behavior.
You don't have to use them, but I find inserting the odd keyword arg makes things much easier to read.
You could lose the quotes around strings, but you'd still have the commas.
Maybe start with lisp and just add {key: value key2: value2} syntax for tables? It'd be useful to get ruby-style keyword args for free, at least.
I spend a lot of time thinking about keyword args because I've been working on a lisp interpreter that supports them. Here's a webserver that is nice to read because of a crucial keyword arg (it starts with a colon):
reply