On Monday, 4 September 2017 at 01:50:48 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 23:12:35 UTC,
EntangledQuanta wrote:
[...]
The contexts being independent of each other doesn't change
that we would still be overloading the same keyword with
three vastly different meanings. Two is already bad enough
imho (and if I had a good idea with what to replace the
"in" for AA's I'd propose removing that meaning).
Why? Don't you realize that the contexts matters and [...]
Because instead of seeing the keyword and knowing its one
meaning you also have to consider the context it appears in.
That is intrinsically more work (though the difference may be
very small) and thus harder.
...
Yes, In an absolute sense, it will take more time to have to
parse the context. But that sounds like a case of
"pre-optimization".
I don't agree, because once something is in the language
syntax, removing it is a long deprecation process (years), so
these things have to be considered well beforehand.
That's true. But I don't see how it matters to much in the
current argument. Remember, I'm not advocating using 'in' ;) I'm
only saying it doesn't matter in a theoretical sense. If humans
were as logical as they should be, it would matter less. For
example, a computer has no issue with using `in`, and it doesn't
really take any more processing(maybe a cycle, but the context
makes it clear). But, of course, we are not computers. So, in a
practical sense, yes, the line has to be draw somewhere, even if,
IMO, it is not the best place. You agree with this because you
say it's ok for parenthesis but not in. You didn't seem to answer
anything about my statements and question about images though.
But, I'm ok with people drawing lines in the sand, that really
isn't what I'm arguing. We have to draw lines. My point is, we
should know we are drawing lines. You seem to know this on some
significant level, but I don't think most people do. So, what
would happen, if we argued for the next 10 years, we would just
come to some refinement of our current opinions and experiences
about the idea. That's a good thing in a sense, but I don't have
10 years to waste on such a trivial concept that really doesn't
matter much ;) (again, remember, I'm not advocating in, I'm
advocating anything, but against doing nothing.)
If we are worried about saving time then what about the
tooling? compiler speed? IDE startup time? etc?
All these take time too and optimizing one single aspect, as
you know, won't necessarily save much time.
Their speed generally does not affect the time one has to spend
to understand a piece of code.
Yes, but you are picking and choosing. To understand code, you
have to write code, to write code you need a compiler, ide, etc.
You need a book, the internet, or other resources to learn things
too. It's a much much bigger can of worms than you realize or
want to get in to. Everything is interdependent. It's nice to
make believe that we can separate everything in to nice little
quanta, but we can't, and when we ultimately try we get results
that make no sense. But, of course, it's about the best we can
do with where humans are at in their evolution currently. The
ramifications of one minor change can change everything... See
the butterfly effect. Life is fractal-life, IMO(I can't prove it
but the evidence is staggering).
I mean, when you say "read code faster" I assume you mean the
moment you start to read a piece of code with your eyes to the
end of the code... But do you realize that, in some sense, that
is meaningless? What about the time it takes to turn on your
computer? Why are you not including that? Or the time to scroll
your mouse? These things matter because surely you are trying to
save time in the "absolute" sense?
e.g., so you have more time to spend with your family at the end
of the day? Or spend more time hitting a little white ball in a
hole? or whatever? If all you did was read code and had no other
factors involved in the absolute time, then you would be 100%
correct. But all those other factors do add up too.
Of course, the more code you read the more important it becomes
and the less the other factors become, but then why are you
reading so much code if you think it's a waste of time? So you
can save some more time to read more code? If your goal is to
truly read as much code as you can in your life span, then I
think your analysis is 99.999...% correct. If you only code as a
means to an end for other things, then I think your answer is
about 10-40% correct(with a high degree of error and dependent on
context).
For me, and the way I "value"/"judge" time, is, how much stuff
can I fit in a day of my life that I like to do and how can I
minimize the things that I ultimately do not want to do. Coding
is one of those things I do not like to do. I do it as a means to
an end. Hence, having tooling, IDE's, compilers, etc that help me
do what I want to do coding wise as fast as possible(overall) is
what is important.
I just think here you are focusing on one tiny aspect of the
picture. It's not a bad thing, optimizing the whole requires
optimizing all the parts. Just make sure you don't get caught up
in optimizing something that isn't really that important(You know
this, because you are a coder, but it applies to life too,
because are all just "code" anyways).
Maybe the language itself should be designed so there are no
ambiguities at all? A single simple for each function? A new
keyboard design should be implemented(ultimately a direct
brain to editor interface for the fastest time, excluding the
time for development and learning)?
I assume you mean "without context sensitive meanings" instead
of "no ambiguities", because the latter should be the case as a
matter of course (and mostly is, with few exceptions such as
the dangling else ambiguity in C and friends).
Assuming the former: As I stated earlier, it needs to be worth
the cost.
yes, I mean what I called "perceived ambiguities" because true
ambiguities are impossible to compile logically, they are
"errors".
So, in this case I have to go with the practical of saying
that it may be theoretically slower, but it is such an
insignificant cost that it is an over optimization. I think
you would agree, at least in this case.
Which is why I stated I'm opposing overloading `in` here as a
matter of principle, because even small costs sum up in the
long run if we get into the habit of just overloading.
I know, You just haven't convinced me enough to change my opinion
that it really matters at the end of the day. It's going to be
hard to convince me since I really don't feel as strongly as you
do about it. That might seem like a contradiction, but
Again, the exact syntax is not import to me. If you really
think it matters that much to you and it does(you are not
tricking yourself), then use a different keyword.
My proposal remains to not use a keyword and just upgrade
existing template specialization.
I think that is a better way too because it is based on a solid
principle: https://en.wikipedia.org/wiki/Relational_theory, in a
sense. I see it more that things make more sense to the brain the
closer those things are in relationship. Space may or may not
have absolute meaning without objects, but humans can understand
space better when there is stuff inside it. (stuff that relates
to space, which I think some call feng shui ;)
You just really haven't stated that principle in any clear way
for me to understand what you mean until now. i.e., Stating
something like "... of a matter of principle" without stating
which principle is ambiguous. Because some principles are not
real. Some base their principles on fictitious things, some on
abstract ideals, etc. Basing something on a principle that is
firmly established is meaningful.
When I see something I try to see it at once rather [...]
To really counter your argument: What about parenthesis? They
too have the same problem with in. They have perceived
ambiguity... but they are not ambiguity. So your argument
should be said about them too and you should be against them
also, but are you? [To be clear here: foo()() and (3+4) have 3
different use cases of ()'s... The first is templated
arguments, the second is function arguments, and the third is
expression grouping]
That doesn't counter my argument, it just states that
parentheses have these costs, as well (which they do). The
primary question would still be if they're worth that cost,
which imho they are. Regardless of that, though, since they are
already part of the language syntax (and are not going to be up
for change), this is not something we could do something about,
even if we agreed they weren't worth the cost.
New syntax, however, is up for that kind of discussion, because
once it's in it's essentially set in stone (not quite, but
*very* slow to remove/change because of backwards
compatibility).
Well, all I can really say about it is that one can't really know
the costs. I've said that before. We guess. Hence, the best way
out of this box is usually through experiment. We try something
and see how it feels and if it seems to work. I'm taking about in
general
[...]
Well, yes, as I wrote, I think it is unambiguous (and can
thus be used), I just think it shouldn't be used.
Yes, but you have only given the reason that it shouldn't be
used because you believe that one shouldn't overload
keywords because it makes it harder to parse the meaning. My
rebuttal, as I have said, is that it is not harder, so your
argument is not valid. All you could do is claim that it is
hard and we would have to find out who is more right.
As I countered that in the above, I don't think your rebuttal
is valid.
Well, hopefully I countered that in my rebuttal of your
rebuttal of my rebuttal ;)
Not as far as I see it, though I'm willing to agree to disagree
:)
I have a logical argument against your absolute restriction
though... in that it causes one to have to use more symbols.
I would imagine you are against stuff like using "in1",
"in2", etc because they visibly are to close to each other.
It's not an absolute restriction, it's an absolute position
from which I argue against including such overloading on
principle.
If it can be overcome by demonstrating that it can't sensibly
be done without more overloading and that it adds enough
value to be worth the increases overloading, I'd be fine with
inclusion.
[...]
To simplify it down: Do you have the sample problems with all
the ambiguities that already exist in almost all programming
languages that everyone is ok with on a practical level on a
daily basis?
Again, you seem to mix ambiguity and context sensitivity.
W.r.t. the latter: I have a problem with those occurences
where I don't think the costs I associate with it are
outweighed by its benefits (e.g. with the `in` keyword
overloaded meaning for AA's).
Not mixing, I exclude real ambiguities because have no real
meaning. I thought I mentioned something about that way back
when, but who knows... Although, I'd be curious if any
programming languages existed who's grammar was ambiguous and
actually could be realized?
So, my "[perceived] ambiguity" is your context sensitivity. But I
was more trying to hint at how an arbitrary human my be confused
by seeing the same thing used in to different contexts having two
different meanings. They tend to just see them as ambiguities at
first and are confused, until they learn the context, in which
case the ambiguities no longer exist. They weren't real
ambiguities in the first place but they "perceived" them as such.
Usually context sensitivity, in the context of programming
languages, has a very specific interpretation so I didn't want to
use it.
[...]
Why do you think that? Less than ten people have
participated in this thread so far.
I am not talking about just this thread, I am talking about
in all threads and all things in which humans attempt to
determine the use of something. [...]
Fair enough, though personally I'd need to see empirical
proof of those general claims about human behaviour before I
could share that position.
Lol, you should have plenty of proof. Just look around. [...]
Anectodes/generalizing from personal experiences do not equate
proof (which is why they're usually accompanied by things like
"in my experience").
There is no such thing as proof in life. If their was, we'd
surely have something close to it in life. At best, we have
mathematical proof. It might be that existence is
mathematical(seems to be so, as mathematics can be used to
explain the relationships between just about anything). But human
behavior is pretty typical and has patterns. Just like most
phenomena. As much as humans have discovered bout life, the
general pattern is that the more we learn the more see that there
are underlying factors that generate these patterns.
And so, if you believe in these pattern oriented nature of
life(which is more fractal like/self similarity) you can start
connecting dots. It may turn out that you connected them wrong,
but that's a step in the right direction. You reconnect things
and learn something new. Draw a new line...
Look how children behave. You remember how you were a child, the
things that went on. Do you think that once a human "grows" up
that somehow they change and grow beyond those behaviors? Or is
it more logical that those behaviors just "morph" in to 'new'
behaviors that are really just functions of the old? When you
realize that people are just children that have older bodies and
more experiences, you start to see patterns. E.g., politicians.
They are just certain children, You might have had a friend that,
now that you look back, could say that he was a "politician". (or
whatever). Grown up behavior is just child behavior that is grown
up. It is not completely different.
The same is said of programming languages. Programming languages
just do jump from one thing to another but evolve in a continuous
way. What we experience now is the evolution of everything that
was before. There are no holes or gaps or leaps. It is a
differential function, so to speak(but of, probably, an infinite
number of dimensions). Everything is connected/related.
Anyways, I think we are starting to drift in the weeds(but that
is usually were the big fish hide!) ;)
I'd like to see such a feature implemented in D one day, but I
doubt it will for whatever reasons. Luckily D is powerful
enough to still get at a solid solution.. unlike some
languages, and I think that is what most of us here realize
about D and why we even bother with it.
Well, so far the (singular) reason is that nobody that wants it
in the language has invested the time to write a DIP :p
Yep.
I guess the problem with the D community is that there are no
real "champions" of it. Walter is not a King Arthur. I feel that
he's probably lost a lot of his youthful zeal that is usually
what provides the impetus for great things. Many of the
contributors here do not make money off of D in any significant
way and hence do it more as a hobby. So the practical side of
things prevent D from really accomplishing great heights(at this
point). I hope there is enough thrust for escape velocity
though(My feeling is there isn't, but I hope I'm wrong). Like you
say about saving cycles reading, well, if D isn't going to be
around in any significant way(it starts to stagnate in the next
few years), then my investment of time will not be very rewarded.
I've learned a lot of new programming things and some life stuff
from it so it's not a total lost, but it will be a shame(not just
for me)..
What we know for sure, if D does progress at a specific "rate",
it will be overtaken by other languages and eventually die out.
This is a fact, as it will happen(everything dies that lives,
another "over generalization" born in circumstantial evidence but
that everyone should be able to agree on...). D has to keep up
with the Kardashians if it want's to be cool... unfortunately.
