Re: Keyword Arguments

On Jun 10, 2012, at 4:08 AM, James Burgess wrote:

> Hi Jan-Paul,
>  I use io in a real, shipping, you pay money for it program so my interest in it is perhaps a little different than your own but it's sad you had to receive that response. It just makes makes me think of this:
> 

Huh, so you are that mysterious person that uses Io at Pixar ^^, to bad that blog post disappeared I'd really love to read it :D

> http://www.youtube.com/watch?v=uz2jbCJXkpA
> 
> :-)
> 
> I recall keyword args have coming up before several times in the forums and on IRC and it's descended into a morass each time.
> 

And thanks for the condolences but luckily I did't get caught between the fronts, I just saw the escalation after I had written my response ^^ (seems like you mixed 2 mails :))

>  Do I like them? yeah I guess so. Do I think it's an important language feature, not really. I think it's probably better if your editor knows how to tell you what each arg is, that makes positional/named argument moot anyway. You're editor can show you all sorts of contextual information, maybe it's better it take on that problem not the language? I'm not sure, I've written code with vi for 25 years so my opinions are biased.
> 

I totally agree on your remarks though, while I like keyword args as well, they are usually a sign of to many parameters.
Objective-c for example seems to encounter this problem rather frequently, I've seen a twitter post lately with a two line 10 args method invocation ^^°
But tools are definitely the way to go (be it a vim plugin ;)).

Cheers,
Jan

> Cheers,
> 
> - James
> 
> 
> 
> 
> 
> On Jun 9, 2012, at 4:22 PM, Kurtis Rainbolt-Greene wrote:
> 
>> Thanks for the discussion Jeremy, but I don't think there's much else for me to say. I tried to be civil, but you make things difficult when you continually use the phrase "red herring" incorrectly as a means of dismissing my argument. It also doesn't help that your fallback seems to be attacking me and I'm just not up for that kind of thing. Good luck.
>> 
>> 
>> Still open to others ideas on the original topic.
>> 
>> On Sat, Jun 9, 2012 at 6:10 PM, Jeremy Tregunna <[email protected]> wrote:
>>  
>> 
>> On Saturday, 9 June, 2012 at 4:48 PM, Kurtis Rainbolt-Greene wrote:
>>>  
>>> > Changed the arguments? Yes of course, reordered them? Not once, ever.
>>> 
>>> Still doesn't make it a red herring.
>> 
>> Then we should agree to disagree on this point and move on.
>>> > 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
>> 
>> If you aren't doing this already, I don't think you have what it takes to be a programmer. Following instruction is part of problem solving, which is at the core of software development. 
>>>   2. I have no context for the values I'm passing
>> 
>> You seem to think that I advocate many argument messages, which I don't. I've been very public on this list and others quite to the contrary. So much so that my language Acute, has a syntactic extension to Io (Jan-Paul was actually the one who wrote the parser support for it) that explicitly forbids multiple arguments. In these cases, it's a non-issue. If you can't make complex methods that require more than 2 arguments, you're probably design ing your programs wrong. I'm not saying you can reduce everything to a one arg send, but I think if you're doing more than that, you probably are being lazy and not building a proper data structure to pass in. 
>>>   3. I have to look at the method definition to understand what value goes in what position
>> 
>> Not necessarily, you could also look at the docs. Either way, you have to look at one or the other to know what the keywords are. I don't see how it differs. It's the same cognitive load, in different places. Again, red herring. 
>>> I can't tell you how it solves problems that I haven't said it solves.
>> 
>> I didn't claim you said it solved those problems, but given some of your other assertions, I figure d it was worth asking. 
>>> 
>>> > 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.
>> 
>> Then include your extension along side your program, problem solved. They'll get your version for your objects, and everyone's happy. 
>>>   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.
>> 
>> No you don't, you expect a Map object, and you use the Map APIs internally. The lexer translates the literal into a valid series of message sends (specifically, a curlyBrackets message send, which returns a Map). Other implementations of Map literals would also return a Map object conceivably (otherwise they're doing it wrong), so again, it's a non-issue.
>>> 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."
>> 
>> We've already had this argument, to which you stormed away all pissed. Let 's not do it again. 
>> 
>> Regards,
>> 
>> Jeremy Tregunna
>> 
>> 
>> 
>> 
>> -- 
>> Kurtis Rainbolt-Greene, Hacker
>> Difference Engineers, LLC
>> 643 Magazine St. #102
>> New Orleans, LA 70130
>> 
>> 
>