Positional Versus Named Parameters

"Would be really interested to read an example of positional parameters being better for the reader [than NamedParameters](with the explanation of why, of course). --LuxSpes

Definition:

  function Plot(xcoord: real, ycoord: real, zcoord: real, dotColor: string) {
    ...
  }
  // Assume this language accepts both positional and named calls

Compare:

  plot(23.3, 17.2, 32.5,"green");  
  plot(17.4, 55.0, 05.2,"red");
  plot(08.2, 53.8, 63.4,"red");

Versus:

  plot(xcoord=23.3, ycoord=17.2, zcoord=32.5, dotColor="green");
  plot(xcoord=17.4, ycoord=55.0, zcoord=05.2, dotColor="red");
  plot(xcoord=08.2, ycoord=53.8, zcoord=63.4, dotColor="red");

The first is a lot like reading a table, the second has repetitious clutter that makes the eye have to move more, at least my eyes. Your WetWare may differ. The second is even worse if each statement has to wrap, such as your OOP wikipedia example.

Well, I have to admit you can certainly misuse named parameters (as you did in this case), but when used well, it is always better that positional parameters, for example, in this case, you had to write a comment (that will easly go out of sync with the code as it evolves) to explain the parameters for your plot function, I would have done it like this:

  plot(x:23.3, y:17.2, z:32.5,color:"green");  
  plot(x:17.4, y:55.0, z:05.2,color:"red");
  plot(x:08.2, y:53.8, z:63.4,color:"red");

Now it is not overly verbose (as in your example) and it is reader friendly (no need to guess what the parameters are for, no need to add superfluous comment)

You seemed to agree with me in general that positional and named both have their place. That was my original point. -t
I have to admit that is correct they both have their place, but positional is poisonous alone... I guess then I should formulate the following rule proposal: Positional is fine only if used to avoid DontRepeatYourself violations and only as long as local headers are mandatory. --LuxSpes
As far as your examples, most parameter names are not going to be single characters like "x". Your alternative is fine when they are short, but the vast majority of the time they are not short names. This is why my named-parameter version used a bit longer names. And often the user of parameter/column names doesn't have the option of choosing the name. -t
Well, if your example is not representative of the vast majority of real cases, then you should have presented a different example ;-) --LuxSpes
Technically, I presented somewhat longer formal names, such as "xcoord" instead of "x". The comment was a reference-only quick-note. I suggest you change your examples to reflect that.
But actually, you planted the seeds for the doom of your own example by writing that comment ;-), showing that your example was unnecessarily contrived (you wrote long names to gratuitously complicate things, instead of presenting an example that actually required long names). If you do not like your own example, you should write another one. Remember, I am the guy that thinks named parameters are always better, I am not supposed to help you probe me wrong. :-P --LuxSpes
As far as the comment, the formal definitions are still there. The comment is merely a quick-reference guide. (I've since removed the comment because because I added the function def.) -t
No, the formal definition is not there, if I delete the comment, I have no way to know if plot(23.3, 17.2, 32.5,"green") means x:23.3, y:17.2, z:32.5,color:"green" or y:23.3, x:17.2, z:32.5,color:"green" or weight:23.3, size:17.2, temperature:32.5,name:"green" --LuxSpes
I meant in the actual source code, including the function/method definition, which I didn't include, but probably should have.
Well, you did not, and since what we are arguing about here is the convenience for the reader of the code, and since needing to open another file to find out what the parameters mean is less convenient that being able to see it right there where they are used... that means named parameters are more convenient for the reader (specially since in real world scenarios, different functions from different files may be called in succession, which means the reader would need to go an open several different files to better understand the meaning of the parameters. All this, in my opinion, validates my previous rule proposal. Do you agree with it? I believe it should satisfy both of us (it shows that positional parameters are useful to avoid violations of DontRepeatYourself, but it also shows that unless named parameters are used close and to control the positional ones, the reader will be in an less convenient situation)
My rule of thumb said that the more often a function is called, the more readability benefits from positional parameters. Yes, there may be some initial overhead to looking up the definition, but the savings from easier reading of the bulk makes up for it past a quantity point. Once you know what the parameter positions are, it's easier to read positional than named in general, at least for my WetWare. In other words, the time saved and errors reduced by improved readability economically outweighs the cost of going to the reference source once a quantity threshold is passed. One weighs these trade-offs when designing interfaces. -t
These kinds of decisions are not that different from chores such as laundry: do you have separate baskets for each color type (lights and darks), or do you just have one big basket and separate them when you actually do the laundry? -t

Now, if this were to be inserted in Rel as "PlotPoints":

 INSERT PlotPoints RELATION {
       TUPLE {x 23.3, y 17.2, z 32.5,color "green"},
       TUPLE {x 17.4, y 55.0, z 05.2,color "red"},
       TUPLE {x 08.2, y 53.8, z 63.4,color "red"}
 }

I think it does not look bad, but I would be willing to accept a named/positional compromise as the one offered by AlphoraDataphor:

 insert table {
       row(x 23.3, y 17.2, z 32.5,color "green"),
       row(  17.4,   55.0,   05.2,      "red"),
       row(  08.2,   53.8,   63.4,      "red")
 } into PlotPoints

where the first row must (no way around it, as SQL unmaintainable insert) use named parameters and the others can be positional --LuxSpes

[In TutorialDee, named parameters can be implemented as, for example:]

 operator plot(t tuple {x rational, y rational, z rational, color char})
   ...
 end operator;

[...and invoked thusly:]

 plot(tuple {x 23.3, y 17.2, z 32.5, color "green"});
 plot(tuple {x 17.4, y 55.0, z 05.2, color "red"});

I'd like to see syntax along the lines of:

 {table (x    y     z     color  ):
        (23.3 12.7  32.5  "green")
        (17.4 55.0   5.2  "red"  ) 
        ( 8.2 53.8  63.4  "red"  )
 }

The need for repeating labels in each row bothers me. I also would favor avoiding commas.

[That's essentially SQL's INSERT syntax sans commas. With four attributes it's fine. With forty attributes, or fourteen-hundred attributes, it can be a nightmare to find a missing attribute value. Repeating labels are sometimes tedious if you're manually entering queries and code, but are a godsend when debugging generated code.]
If you're automating the code generation, I suggest also that you automate certain elements of the debugging.
[Sure. But repeated labels are a godsend when you're debugging the debugging code. Ah, but I should automate certain elements of the debugging code debugging. And so on... *stack overflow* :-) Point taken, though.]

Or better yet, we need to develop TableOrientedProgramming so that we can represent as tables stuff that's best represented as tables and as code stuff best represented as code, such as Boolean expressions; and make it easier to mix and match tables and code than formal BigIron DB's currently allow. I've seen the mountain top, but can quite reach it yet. The future development tools will look like Eclipse had wild threesome steamy monkey sex with a spreadsheet and Oracle, and all 3 had a kid together. --top

An anonymous table such as the one described above is suitable as an element of a query (i.e. an insert, or a difference, or an initialization), which might be emitted by other code, albeit likely with variables instead of hard numbers. It is unclear to me how TOP would avoid need for such. Anyhow, I'd rather avoid another pissing match between our hobby horses. We agree that effective integration with external services - including databases - is a fine idea for the future of software development. But beyond that our visions diverge quite wildly.

To get what you want, it should be clear that some kind of TableBrowser is a better tool than text because one doesn't have to diddle with alignment and spacing and quotes (if using strings). The down-side is that table browsers are not integrated into code editors, requiring going back and forth. (In the future, they will be, when IT society wakes up from the dark-ages of text-centric programming and sees the light.) --top

Let's put the above in a slightly different context that includes the "variables instead of hard numbers" I mentioned above:

 define queryElementBuilder A B C = 
   {table (x    y     z     color  ):
          (A    12.7  32.5  "green")
          (17.4 B     5.2   "red"  ) 
          ( 8.2 53.8  C     "red"  )
   }

Now, obviously this is contrived. Realistically, if the expression were part of a query or code, almost every element would end up including variables. Anyhow, please explain how I'd fit this into a TableBrowser.

We have a choice: either we assume values in the table are used as is, or they are variables unless indicated otherwise. With the first, you don't need to specify quotes, but some kind of variable indicator, such as PHP-style $foo may be necessary. Or you put quotes around string values, in which case it's close to what you'd key in as text. Maybe the choice can be a programmer option per mini-table so that one can do the least amount of typing and/or conserve screen space based on the usage pattern of that part of the code. -top

So you're suggesting we just browse tables with embedded free variables and other expressions? I suppose you could make it happen, even support 'jump to declaration' options and such given enough integration between the TableBrowser and the IntegratedDevelopmentEnvironment, but I do not believe such integration would be simple. Lexical context produces a tight coupling between the above table and the code in which it is embedded, and would be even tighter if I allowed expressions such as foo(B). It seems to me that a TableBrowser is a tool better applied for the cases where large blocks of data used by code are maintained independently from the code, or at least with much looser coupling to it.

I believe it's possible and practical. However, it would indeed likely require a complex GUI to become sufficiently competitive to steal mind-share from text-based coding, and that's probably why it has yet to be explored in depth. Making a new textual language is relatively simple and there are common tools for doing such; not so for a TableBrowser with code integration. Like I said in other topics, it's time to evolve beyond (just) text. -t

See ExBaseRant for context

MarchTen