Re: Keyword Arguments

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