On Wednesday, 29 July 2015 at 11:16:29 UTC, Marc Schütz wrote:
On Tuesday, 28 July 2015 at 14:00:29 UTC, Paolo Invernizzi
wrote:
On Tuesday, 28 July 2015 at 13:26:48 UTC, Marc Schütz wrote:
On Tuesday, 28 July 2015 at 12:33:35 UTC, Paolo Invernizzi
wrote:
On Tuesday, 28 July 2015 at 11:50:09 UTC, Marc Schütz wrote:
On Tuesday, 28 July 2015 at 10:16:21 UTC, Paolo Invernizzi
wrote:
[...]
Sorry, but this is unhelpful. All you are saying here is
that "TypeTuple" is bad. Yes, but we already know that.
Everyone agrees on that.
The real question is: _What exactly_ is the problem with
TypeTuple? The "Type" part of the name? The "Tuple" part?
The combination? Maybe it's not the name at all, but the
concept, or only some part of its behaviour?
Nothing in your post gives us a clue which kind of name
would be better. In particular, it doesn't show that
`AliasSeq` is any better than `TypeTuple`. So we're
changing it from a bad name to one that could be even
worse, for all we know.
It seems you and deadalnix actually have useful evidence
that can answer these questions, but neither of you posted
them. Please do!
As already posted in the bike-shedding thread, I'm fine with
'Aliases'.
Or AliasSeq.
Or everything that does not have the 'tuple' or 'type' part
in it.
I'm so desperate I would be fine with 'Arguments'!
Please just proceed with something TOTALLY different for
this concept
Please reread my post, and then look at your answer again. I
asked for evidence, and you posted your opinion.
Again, that's not "my opinion", these are facts, collected
everyday in my working room, and I'm just reporting them.
You wrote "I'm fine with ..." and "Please just proceed with
something TOTALLY different", and not much else. How is this
anything more than opinion? It is probably based on facts, but
where is the evidence for these facts?
For sure it's based on facts, but, again and again, I don't have
the burden to prove anything.
The problem lays in the "Tuple" word, and in the "Type" word,
so just avoid them completely.
This is already a conclusion you drew from the experiences in
your company. But we have no way of knowing how well these
conclusions match reality. I don't understand why it's so
difficult just to recount a few of your experiences. I already
gave a few examples how this could look:
http://forum.dlang.org/post/[email protected]
Then everyone can judge for themselves whether your conclusions
are justified. Given that deadalnix declared this a "repeatable
experiment", I don't think this is asking too much.
And really, I'm genuinely interested in that. I don't keep
asking for it just to annoy everyone. And if you can't share
that information because it involves business secrets, then
please just say so.
Again, and again, you can try it yourself, it's a repeatable
experiment, as deadalnix said: just try yourself, teach D, and
take your conclusion.
I'm not a contributor, my day it's already made by 30hrs, I can't
simply afford the effort.
It is up to you, D developers, to take care of our
experiences, as we must teach D, or just ignore them.
We're trying, but you don't share the experiences. You just
tell us that you want something changed. But that's like going
to a doctor and asking him to operate on you, instead of
telling him where you're hurting and giving him the information
to decide whether you need surgery at all.
I'm trying to understand why you are the doctor and I am the
common man.
So, what kind of experience you have, more than me, in teaching D
to newcomers, turning them in efficient programmers in short time?
I've done my diagnosis, that's my work: I'm a CTO, I earn over
evaluations of technologies.
Feel free to doubt, and feel free to perform all the examinations
you prefer, they are repeatable, and take your conclusion.
---
Paolo
