Re: Keyword Arguments

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] (mailto:[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
>