Re: Keyword Arguments

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

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.



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

> **
>
>
> Sure, consider the Smalltalk method ifTrue:ifFalse:
>
> You can't reverse those, since the selector is of course, ifTrue:ifFalse:
> You also have to remember their names. They fall out of band with the
> arguments. If for instance, you could run like this:
>
> c == 42 ifTrue([Transcript show('c is 42')]) ifFalse([Transcript show('c
> isn''t 42')])
>
> In this case, one assumes that ifTrue and ifFalse are separate, you need
> to remember their names. It's not immediately obvious to a new user if the
> Smalltalk syntax:
>
> c == 42 ifTrue: [Transcript show: 'c is 42'] ifFalse: [Transcript show: 'c
> isn''t 42'].
>
> That ifTrue and ifFalse are separate messages. Yes you'll learn this as
> you learn the APIs. Likewise, I can't write this:
>
> c == 42 ifFalse: [ … ] ifTrue: [ … ].
>
> As this would be a separate method (or potentially two methods).
>
> There's no substitute for learning the APIs and conventions of the
> language you're using, this very true and the real question, but while
> infix syntax seems like it is (and actually is) easier to conceptualize
> what's going on, where the line boundaries are as to what combination of
> keywords are methods and which aren't, are not immediately clear without
> backtrack. In a syntax like Io, you don't run into this problem.
>
> (c == 42) ifTrue("foo") ifFalse("bar")
>
> is 8 message sends (yes 8), but it's immediately clear where the
> boundaries are.
>
> Teaching people who have no exposure to programming would be easier, since
> they don't expect these arbitrary distinction points right away, and by the
> time they do expect them, they already know the rules. It makes it easy.
> This is also kind of why I think Smalltalk's syntax turned off other
> developers with experience in languages like ALGOL, C, Fortran, and other
> such languages. They already know the rules around function calls, and
> immediately look for those patterns. It becomes muscle memory. So when the
> code is presented in a way that is not immediately obvious, and there's
> more than one or at most two simple rules to learn (see concatenate
> languages for an example of what I'm talking about), I think it puts
> experienced developers off.
>
> Regards,
>
> Jeremy Tregunna
>
> On Saturday, 9 June, 2012 at 2:36 PM, Kurtis Rainbolt-Greene wrote:
>
>
>
> Jeremy, you bring up a good point, but I wonder if you have anything to
> back up:
>
> > Even if you didn't, you'd still have to remember their names, which
> again doesn't reduce any cognitive load
>
> I'd be interested on any data on this, because it directly contradicts the
> experience I've had teaching people to program.
>
> On Sat, Jun 9, 2012 at 2:31 PM, Jeremy Tregunna <[email protected]>wrote:
>
> **
>
>
> This discussion goes back many years, and Steve's always said something
> along these lines:
>
> Tell me how this parses:
>
> a: b c d: e: f
>
> Smalltalk had 3 precedence rules for message sends that you had to
> remember. I stipulate that there's a higher cognitive load on remembering
> those, and you don't really reduce any cognitive load with a smalltalk
> style keyword args because you still have to remember the position of the
> arguments. Even if you didn't, you'd still have to remember their names,
> which again doesn't reduce any cognitive load.
>
> While learning the precedence rules doesn't take long, and I generally
> like the smalltalk syntax more than I do s-expressions or m-expressions, I
> don't think their benefits outweigh their cost. Reducing cognitive load
> should be the goal of any language designer.
>
> Th at said, you'd have to invent new syntax to support this kind of
> system. You'd also end up building your own runtime on top of Io to support
> the way your messages work, and this would involve a lot of proxies which
> can mess with the way the system is going to work.
>
> A case in point of Io mapping to keyword arguments is in the Objective-C
> bridge, at least now : is an identifier so your idea is possible. But yes,
> you'd definitely have to invent all the stuff you want.
>
> Regards,
>
> Jeremy Tregunna
>
> On Saturday, 9 June, 2012 at 1:22 PM, Kurtis Rainbolt-Greene wrote:
>
>
>
> One of the cool things about SmallTalk, and other languages including
> Ruby in v2, was the keyword argument syntax sugar (pseudo-code):
>
> define help(title, keywords, options)
> # Logic Here
> end
>
> Then you could call a function like so:
>
> help("this is the title", ["thing", "thang", "thong"], {"format"
> => "ascii"})
>
> Or with keyword arguments:
>
> help(title: "this is title", keywords: ["thing", "thang",
> "thong"], options: {"format" => "ascii"})
> help(options: {"format" => "ascii"}, title: "this is title")
>
> The second version is where the real advantage comes in: Being able to
> have unordered arguments. It reduces refactor problems that are solely
> in the realm of order of arguments.
>
> It also helps people learn the concept of arguments faster ("Oh, these
> map to these!").
>
> Brings me to the question: How would you implement this in Io? Not
> just code wise, but syntax. Since Io has no Map literals you might
> have to invent some new syntax concepts.
>
> --
> 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
>
>
>   
>



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