Re: Keyword Arguments

On Saturday, 9 June, 2012 at 3:42 PM, Kurtis Rainbolt-Greene wrote:
>    
> That's an interesting example, but I'm not sure if I'd consider it backing up your claim. Consider this counter example:
>  
>     if(1 == 1, print "Yep, that's right", print "Nope, that's wrong")  
>     if(condition: 1 == 1, true: print "Yep, that's right", false: print "Nope, that's wrong")
>  
> But that's a poor example since if is a very easy function to remember and you only end up taking space by using keywords on that method. This is why I love that Ruby 2.0 keywords are entirely optional, and basically replace the passing of a Hash as a single argument.  
>  
> Here's something that's actually used out in the wild:
>  
>     def render(view, formats = ["html"], cache = false)
>       # logic here
>     end
>  
>     render("show", ["json", "html", "xml"], true)
>     render(view: "show", formats: ["json", "html", "xml"], cache: true)
>  
>  
> In the non-keyword form I have no idea what "true" means. What am I toggling on? Or am I letting the method know it needs to return something? You can't possibly gleam any information about it because there's no context. In the latter example I know exactly what I'm doing. More importantly I wont have any bugs should I refactor to:  
>  
>     def render(view, cache = false, formats = ["html"])
>       # logic here
>     end
>  
>  
>  
>  
>  
>  

As someone who writes code for a living, I cannot remember a single instance in the last 24 years I've had to do this. So I consider this a red herring.
> I should also point out that "Teaching people who have no exposure to programming would be easier" can't be true if the cognitive load is higher, instead of lower.
You'll note that I said the higher cognitive load was on the fact that there are precedence rules for message sends in Smalltalk, as opposed to a language like Io where there is only one precedence rule — Messages preceding other messages are guaranteed to be evaluated before the first message following is evaluated. I explicitly noted that it doesn't reduce cognitive load, you still have to learn the API and its keywords even if they do help at first glance. You can never exactly be sure something does what it says though without reading its associated documentation, or source code. Whose to say that cache keyword wasn't left over from some previous version, and isn't used anymore, or has been repurposed and not renamed? This is far more likely than shuffling of positions; i.e., I've seen this happen in real code.

Regards,

Jeremy Tregunna