Brad Cox wrote:
> Its not a language's business to prevent users from writing "smelly" code.

I strongly disagree. Improvements in structure that higher-level
languages bring along have for the most part been about removing the
need for "smelly" code. (Ok, so perhaps goto wasn't referred to as
"smelly", but it stank nonetheless)

In the extreme case of this, I even like Java for its sandboxing
capabilities. No, not the security-wise ones, but the sandbox and
confindments that novice programmers can wallop around in like newborn
babies, but still enforce some structure (such as only one public class
per sourcefile etc). Sure, Ruby is alot more pragmatic, practical and
lax, but think you're talking perlish pragmatism here.  :-)

> Long argument lists are common in data initialization contexts, and
> misplaced commas a extremely common problem, that's actively
> manufactured by this rule.

I find long argument lists to be an abomination. A problem I fall into
much more frequently than missing a comma, is ordering and remembering
them all. The current way Ruby automagically makes a hash at the end may
not be the best solution, but I have spent more time on stupid mistakes
using libraries with many arguments (that didn't allow the hash variant)
than I do on finding back to the parse error of a missing comma, which
tends to be pretty accurately pointed out. (And no, the parse error
won't be lingering for a long time before it rears its ugly head if you
have thorough unittests.)

I'd also dare to go out on a bit of an extreme limb as to claim that the
non-keyword comma separation of arguments is a fundamental flaw of many
programming languages, for there is no linear, sequential structure at
work here, like with arrays(for which comma trailing is allowed). The
linearity is a throwback to compiler-feeding.

On the other hand, I'm also not fond of the "creative" diversity that
keyword arguments bring, where the ordering is completetly up to the
programmer. The possibility of leaving out optional parameters in the
middle of the argument list is neat. Perhaps it is false to say that
there is no linear structure in a method call. It might be closer to the
truth to claim that the argument list linearity often fails to map to
the "storytelling" linearity when there is alot of arguments. I'm not a
SmallTalker but here I think SmallTalk was onto something, with a
defined order of keywords that both separate and describe the arguments,
making a very readable story.

I can't say the same for:

>         @@instance = SomeClass.new(
>                 "127.0.0.1",
>                 8083,
>                 "hostname.com",
>                 blah,
>                 blah,
>                 whoops,
>         );

I just love how Ruby does the Right Thing in alot of cases here, (such
as File.open which is more readable than File.new) but it doesn't
currently extend into argument lists. When keyword argument design is
finalized, I prophetize it will.

(I cut this rant short here, as Dossy posted a reply that has the
remainder of what I had on mind, but alot shorter and neater than I
could write it.)

-- 
(\[ Kent Dahl ]/)_    _~_    __[ http://www.stud.ntnu.no/~kentda/ ]___/~
 ))\_student_/((  \__d L b__/  NTNU - graduate engineering - 4. year  )
( \__\_õüõß/__/ ) _)Industrial economics and technological management(
 \____/_öß\____/ (____engineering.discipline_=_Computer::Technology___)