Re: Keyword Arguments

> Changed the arguments? Yes of course, reordered them? Not once, ever.

Still doesn't make it a red herring.

> How does keyword arguments help solve that problem?

It doesn't solve that problem, but then I don't think I said it did. Here's
the problems it solves:

  1. I have to order my arguments correctly
  2. I have no context for the values I'm passing
  3. I have to look at the method definition to understand what value goes
in what position

I can't tell you how it solves problems that I haven't said it solves.

> You'll never have to do it again either.

This is an entirely separate argument, but this doesn't help at all. I've
pointed this out a few times: Implementing syntax sugar like this only
makes things worse. By adding this on my own to my own Io implementation I
now run into two problems:

  1. My Io suddenly behaves differently from other people's Io. For
instance, code I use this in will not run on other Io interpretors without
first having them change and recompile their Io interpretor.
  2. Other implementations of Map literals are now barriers to entry for
projects. I will either have to conform to their implementation, for their
project only, or write an additional implementation of my own.

Saying "Io doesn't have Map literals" is not a another way of saying
"Please, give me another random way to implement Map literals on my own
project/library/interpretor."


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

> **
>
>
> On Saturday, 9 June, 2012 at 4:06 PM, Kurtis Rainbolt-Greene wrote:
>
>
>
> 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.
>
> Changed the arguments? Yes of course, reordered them? Not once, ever.
>
> >  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.
>
> Only if it's actually telling the truth. I've run into a lot of code that
> is named one thing when it does something entirely else. How does keyword
> arguments help solve that problem?
>
> 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.
>
> I'm pretty sure I already gave you a map literal over twitter, but just in
> case I didn't, here:
>
> OperatorTable addAssignOperator("=>", "atPut")
>
> curlyBrackets := method(
>   r := Map clone
>   call message arguments foreach(arg,
>     arg doInContext(r, call sender)
>   )
>   r
> )
>
> Toss that into a "MapLiteral.io" and place it in io/libs/iovm/io, rebuild
> Io and reinstall it. When you start Io up again, you'll be able to do this:
>
> { a => 42, b => 23 }
>
> And get back a Map instance, with a size of 2, containing both those keys
> associating those two values. You'll never have to do it again either.
>
>
> 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
>
>
>  
>



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