Re: Keyword Arguments

You've never refactored your code before in a way that changed the
arguments in your method? Fine, ok, I might be able to see that happening,
but that doesn't make it a red herring. My point is in no way misleading
nor is it distracting from the issue brought up. It's a fact that with
keyword arguments like described reordering the arguments in the method
definition wont affect the method call, regardless of if you think that's
good or not.

>  I explicitly noted that it doesn't reduce cognitive load

Having argument context without looking up the method definition is
explicitly a reduction in cognitive load and effort. Yes, most of the time
you will still need to look at the method. Keyword arguments simply reduce
the need to continually look up the arguments of a method and in many cases
make methods self-explanatory (see previous render example).

You're absolutely right though, that Io doesn't have any syntactic concept
that would fit keyword arguments. I would attribute this largely to not
having a Map literal.

On Sat, Jun 9, 2012 at 4:51 PM, Jeremy Tregunna <[email protected]>wrote:

> **
>
>
> 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
>
>  
>



-- 
Kurtis Rainbolt-Greene, Hacker
Difference Engineers, LLC
643 Magazine St. #102
New Orleans, LA 70130