Date: Mon, 8 Jul 2019 17:07:42 +0100
On Mon, 8 Jul 2019, 12:40 Barry Revzin via Std-Proposals, <
std-proposals_at_[hidden]> wrote:
> I find the word choice here really puzzling. Lazy? "Just as unusable"?
>
Oh it's definitely usable, especially when you're in a scripting scenario
or doing something you're only going to use in one or two ways.
But it's also definitely lazy, and it lends itself to much harder to
maintain code in the long run. I don't wish to tear pandas and matplotlib
apart, as they're maintained by better developers than myself - but the
read_csv is still a bad interface. The constructor is a large mash of
options that apply to different stages up the chain from raw input to a
properly parsed and typed structure. How easy is it to add a new type of
data source? What if you want to be able to switch between different types
of source but with a consistent output structure? Suddenly the very usable
interface becomes a burden (and more often than not I have seen these
wrapped with OO interfaces to make them usable in a flexible environment).
Sure those interfaces are friendly. At first. Or, perhaps better stated,
they're very flexible when you only have one use for them.
The reason we say multi-argument functions are anti-patterns in C++ is
> precisely because you cannot possibly get the arguments right. Because you
> can't name them.
>
And along with that comes structure. Parameters are rarely independent and
having well defined entry points without ambiguity is a defense against
bugs. That's my take anyway.
And like, strong typing (or opaque typedefs) is just not at all a solution
> for named parameters.
>
It is not, alone, a solution. I'm not saying that each parameter should
have a different type (that would be insane), but they often carry meaning
that the type system is perfect for. You don't take the sin() of a double,
you take it of an angle which we may merely choose to represent as a
double. That's the difference between "do what I mean" and "do it how I say
to do it".
But again, this is down to preference. People should be able to code
however they want to and make APIs however they want to, and I'm generally
pro named parameters so long as the cons are aired. For me the biggest is:
originally non-breaking changes now become breaking, and devs need to be
given enough notice to get their interfaces in order.
std-proposals_at_[hidden]> wrote:
> I find the word choice here really puzzling. Lazy? "Just as unusable"?
>
Oh it's definitely usable, especially when you're in a scripting scenario
or doing something you're only going to use in one or two ways.
But it's also definitely lazy, and it lends itself to much harder to
maintain code in the long run. I don't wish to tear pandas and matplotlib
apart, as they're maintained by better developers than myself - but the
read_csv is still a bad interface. The constructor is a large mash of
options that apply to different stages up the chain from raw input to a
properly parsed and typed structure. How easy is it to add a new type of
data source? What if you want to be able to switch between different types
of source but with a consistent output structure? Suddenly the very usable
interface becomes a burden (and more often than not I have seen these
wrapped with OO interfaces to make them usable in a flexible environment).
Sure those interfaces are friendly. At first. Or, perhaps better stated,
they're very flexible when you only have one use for them.
The reason we say multi-argument functions are anti-patterns in C++ is
> precisely because you cannot possibly get the arguments right. Because you
> can't name them.
>
And along with that comes structure. Parameters are rarely independent and
having well defined entry points without ambiguity is a defense against
bugs. That's my take anyway.
And like, strong typing (or opaque typedefs) is just not at all a solution
> for named parameters.
>
It is not, alone, a solution. I'm not saying that each parameter should
have a different type (that would be insane), but they often carry meaning
that the type system is perfect for. You don't take the sin() of a double,
you take it of an angle which we may merely choose to represent as a
double. That's the difference between "do what I mean" and "do it how I say
to do it".
But again, this is down to preference. People should be able to code
however they want to and make APIs however they want to, and I'm generally
pro named parameters so long as the cons are aired. For me the biggest is:
originally non-breaking changes now become breaking, and devs need to be
given enough notice to get their interfaces in order.
Received on 2019-07-08 11:09:41