On Thursday, 8 November 2018 at 10:31:31 UTC, Jonathan M Davis
wrote:
On Thursday, November 8, 2018 2:34:34 AM MST Michelle Long via
Digitalmars- d-learn wrote:
Obviously, but that is not the case I mentioned. You can
assume that I know how scopes work. No need to assume everyone
that shows two cases that you have to bring up an unrelated
case as a potential cause unless it is relevant.
Remember, I'm showing the starting case that has the bug and
the final case that doesn't... it is simply "mental dustmite"
on the code I have.
You shouldn't assume everyone can't comprehend such
trivialities.
If a person cannot understand scope then I doubt they
understand goto's... and definitely not that adding braces
should not change the compiler behavior.
What happens when you do that you just create noise that makes
it more difficult to have a proper discussion that gets at the
whole point of the conversation.
You seem to default to assuming that the person you are
talking to has no clue about the problem at hand. You might
not do it intentionally but it is wrong to assume that because
it almost never helps.
If you fully understood the situation, you wouldn't be asking
whether your case was a compiler bug or not, and I don't know
which parts you do and don't understand. So, I tried to be
thorough in explaining the situation. And yes, by being
thorough, I'm more likely to cover information that you already
know and understand, but I'm also more likely to cover the
information that you actually need. In order to avoid repeating
anything you already understand and only tell you exactly what
you need to know, I would have to somehow understand exactly
which piece of the puzzle it is you're missing, and I don't.
Nope, you are simply wrong here. You have a need to try to show
that you know these trivial difference rather than, as you claim,
to show that they exist because the other party doesn't know them.
To say that anyone posting a problem doesn't fully understand the
situation simply because they don't know it is a compiler bug is
either a very arrogant and blatant egotism at work in your
mind(if you really believe what you said is true) or you are just
ignorant of the facts.
I mean, obviously I don't fully understand the situation, but
neither do you... so for you to claim that the poser must not
fully understand you are implying that you do, which you don't.
See, you will say the person asking must be ignorant(not fully
understand) of some facts about the problem.
Obviously! Everyone is, Even Walter does not have all the D code
memorized. So, in a theoretical sense... but in that same sense
neither do you. But you are asserting that you actually do know
since you then make the claim that you can solve this "ignorance"
problem because you do fully know everything.
You are conflating theoretical and factual.
You actually have no idea how much I know. You make the very
arrogant(even if you don't see it that way) assumption that you
know more about it...
And guess what? We haven't even defined what "it" is completely.
So you simply choose to consistently make decisions based on your
ego rather than what is factual and provable.
Everything is probabilistic and you mind and it's bias towards
stroking your own ego adjusts the probabilities to do this rather
than just taking them as very week approximations(that will
become more accurate over time by asking questions).
The fact is, it is kinda pointless, you will continue to approach
"helping" people with the same method. I'm trying to tell you
that is the wrong approach(maybe it is better than nothing, but
you basically make a shit load of assumptions about things and
generally are wrong and the most important ones) I've noticed
from the past that you tend to ignore all suggestions that you do
this rather than realizing you do and try to be aware and correct
them. This means you do not care about growing or are just
ignorant of reality.
I'm not saying you are evil or stupid but that you can learn to
be a better "helper" by actually trying to help people rather
than be "Mr. KnowItAll"(not, again, saying you are blatant about
it but you seem to go down the path of having to bring up trivial
and basically irrelevant things to point them out. It could be
that you have a little bit of the Captain Obvious DNA or
whatever).
I'm only ranting about this so that maybe you can learn how to
have a fully productive communication with someone when providing
them help rather than waste time. See, even if you were a perfect
programmer and knew everything about D it doesn't mean you have
any idea how to communicate with other human beings in solving
problems with D.
Sometimes the answer is a simple "yes" or "no"(0) and sometimes
it is a "thesis"(1). Knowing how much to spin it is what is key,
and you seem to not be good at that.
All I can say is stop making so many assumption... If you don't
think you are, well, you are, learn to recognize it.
Honestly, that rarely seems to be easy to do, and for whatever
reason, it seems to be even harder to do than normal when
discussing this issue with you. It seems like most of the
discussion of this issue between you and various folks has been
people talking passed each other without really coming to an
understanding, which always makes for a frustrating discussion.
The problem has to do with communication and assumptions.
I'd like to help, but I don't know what else I can say. I've
tried to explain how braces interact with goto and why,
You don't need to explain to me. What makes you think that you
know more about it than I do? This is the problem. You think you
are teaching me something when I have 20+ years of programming
experience.
You don't realize you are just getting in my way. I want real
fucking help. I don't want to be taught programming 101. What I
want is someone to read what I say and interpret it the best they
possibly can with their knowledge and simply say "Yes, that looks
like a bug", or "No, that definitely is not a bug" or "It's not
clear, can you expand on it".
To clutter up my quest for help by making me wade through junk
help(something offered as helped but isn't actually helpful even
though the helper thinks it is because, after all, they are
"helping") just slows down me actually getting help. I don't like
to waste my time. I have many things I like to do, I'm sorry if
that causes a problem with your method but I am the one asking
for help, am I not?
Again, I'm not saying you are bad person, it may come off that
way. I'm glad you want to help, but I know how it is, I've been
where you are. I can see the way you help in the way I used to
help before I learned that it wasn't as helpful as I thought it
was.
See, you think you have to point out every little detail(ok, not
every one but the ones you think are important) because you don't
want anyone not to know them and hit them. So you have to say
"Don't step in that shit right there, you see it? It's right
there, I think your going to step in it! Be careful!"... You
assume the other person doesn't see the shit.
You want to be helpful and prevent problems. That is not a bad
thing... but if you don't balance that with allowing the person
to step in shit then it becomes destructive help, which isn't
help.
Sometimes you have to say "There some shit there" and leave it
be. If the person steps in it, then let them step in it. They
will learn to pay attention more next time.
That is "balance".
Sometimes you don't even need to say anything. You have to learn
to judge the context rather than just being a back seat driver.
If you have a kid and you are teaching them to drive then you can
point out things you think are important more often. If it's your
father who has been driving for you and is in good health, maybe
you should just shut up and let him drive? Even if you disagree
with some things. That is "balance".
A balanced conversation in any context is always best because
balance is always the right way(not 0 and not 1, somewhere in
between... e.g., spin, a linear combo of 0 and 1 somewhere in
between usually). In fact, there is a balance to everything in
life, and learning those balances is important. I think you have
an in balanced way to help people. I'm simply trying to make you
aware of that so you can do a better job which will benefit
everyone.
Maybe one of the problems is that many people approach "helping"
the same way you do... and so it seems normal... just like eating
a bucket of ice cream seems normal at a summer fat camp... but
it's not normal.
so you should be able to figure out whether you're dealing with
a compiler bug or not. And if you are, unless you're dealing
with one that someone else already has found independently and
reported with a test case, somehow, you're going to need to
reduce it enough to be able to create a bug report with an
example if you want it fixed. A small example would be nice,
but even a large example would be better than nothing. Either
way, ultimately, without a reproducible test case, compiler
bugs almost never get fixed. It just isn't practical for the
compiler devs to track down bugs based on vague bug reports,
even if they'd like to be helpful.
See, the problem is you have certain ways you interpret words.
What you think `compiler bug` means is different to me.
For you it might be some specific array of code in the source
code for some specific compiler... or whatever. I have no idea
what it means to you.
On the same token, you have no idea what compiler bug means to
me! You think everyone uses the same definition, but everyone
uses different definitions because definitions are experiences.
This is actually a bigger problem and a problem of epic
proportions that causes most problems in the humanity. It's
pretty obvious once you understand it.
For me, I am not so literal as you, so when I say something it is
being written in generalities(sorta like templates or meta
code... it has a deeper meaning or application than specific
code). You are literal. It's like your brain thinks in terms of C
or pascal while mine thinks in terms of D templates(it is an
analogy, I wouldn't have to point this out of you actually
thought in generalities, but since you think literally(or more
so) I have to point it out... Sorta like how you have to point
out trivial cases. Maybe you fully understand it though).
Since you program in D I know you do have the ability to think
general. You are not as bad as some people who cannot think in
abstraction. In fact, you are probably better than most people...
but you still are far more literal than I.
For me, the literal is trivial... and trivialities have no need
to be discussed except when they are necessary.
The point with all this is you, just as much as anyone else; me
included, have to learn to read in between the lines in
things(that is an abstraction... think D templates where one has
to fill in the specifies themselves. E.g., T = int or T =
double(general = specific)).
But you seem to fail to have this ability to do this when helping
people.
I'll explain it like this:
When I want directions, I do not want every turn, the distances,
the angles of rotation, elevation, speed, every tree and blade of
grass described. Ok?
Does that make sense?
All I want to know is "Point me in the right direction and tell
me about how long/far away/time(they all will work about the same
for me). If there is any major shit I need to know to avoid
causing me major problems then I'd like to know that." But if you
just tell me a lot of needed shit that has nothing relevant to my
life after the trip, it is pointless for me. (One could say that
it's not pointless and they are right, but again, there is a
balance. Just like you seem to err to much on the literal I err
too much on the general. In a sense I have the exact opposite
problem you have, which is why when I communicate with you it is
a lot bigger of a problem)
[This is also, BTW, why most people either communicate well or
badly. I can communicate with some people well and have no
issues... it's because they think more like I do... then there
are people that think like you and I tend to have problems
with(it's nothing personal at all). I'm saying this precisely for
the same reasons you have to point out thinks like the brace
semantics. But in my case I have reason to believe you actually
don't realize the complexity of communication. (You might think
you do but you could learn a lot more than you know)]
Now, as you know some point want to be told as much as possible
with directions.
A good direction giver is someone who can determine quickly how
to give exactly the type of directions that the other person
needs and give them so the other person can save time and energy.
This is no different than compiler design(the same class of
problems, after all, grammars are languages). Note how "literal"
computer languages of the past were and have more "general" they
have become. I speak in generalities because I believe it is
better. This is why I like D, because it allows me to be general.
You too must think somewhat like this because you like D and I'm
sure you like templates. So, we are not that far off of thinking
as some in this world.
But, because I'm in a D forum I kinda have a higher level of
expectation, just like if I was at a AMA meting I'd have certain
expectations and if those expectations are not met then yes,
there will be "frustration"(the frustration for me is just having
my time wasted since time is important... and the reason why so
many damn programmers spend their whole lives trying to optimize
algorithms. Time should be important... everyone who reads this
definitely has a finite amount that cannot be regained... why
waste it because one is ignorant of how important it is?
One could argue that I have wasted a shit load of time typing
this. I have wasted literal time. My hope is that you will
understand, assuming you read it, and ultimately you would waste
my time if you didn't unless someone else got something out of
it, is that after you read it your "algorithm" becomes faster.
This then pays it's dues exponentially because all our future
conversations will then be faster and so will your communications
with other people.
One of your problems seems to be that you haven't realized that
programming is life, it's not just some made up thing by humans.
There is an innate thing in existence that has to do with
optimization... programmers just do it with code. But even DNA
has optimized itself in a code like fashion, and if you are not
ignorant of those things you will understand the gravity of the
problem and why I have put so much time in simply trying to get
you to realize the depth... precisely for the same reasons you
do, because I want to help(most humans do, but everyone is
ignorant, more or less, of what that actually means)).
So, you can do what you will with it. I hope you just spend some
time pondering what is really going on and try to realize things
are not so literal even if you r mind sees it that way. It seems
I'm making an ant hill out of a molehill and I am, but I know the
benefits to your own existence and everyone around you will
benefit and keep the ants away.
To simply:
When I first posted my original post:
`
This should not be an error when the goto jumps outside the
current block!
{
goto Y;
int x;
}
Y:
There is no chance of any local variable being used. This makes
it impossible to use goto statements in any reasonable way
without littering the code with brackets.`
The answer to that is *not* some long shit about other cases or
possibilities or "we need a working example" or "what compiler
version are you using" or whatever junk that almost never
helps(it's sort of like the help you see in many computer forums
or SE that are just shit answers from idiots that actually think
they understand because they have been using a computer for 3
years have *have the solution* which they read from another forum
because they are geniuses and can read... e.g., go clear your
internet explorer cache and that will stop the beeping noises
when your computer starts!)
The response should have been:
"No, that should not be an error"
or possibly
"No, that should not be an error. Did you clean your internet
explorer cache?"
But it would be better if something additional must be said
"No, that should not be an error. There is no issues with it in a
minimal example. Compiles fine with version x.y.z"
Or, another possible answer could have been
"Could you refine your answer, works fine here, but if it were
giving you an error then seems wrong".
If you take those code examples to literally then it's like
programming in BASIC. I'm not going to go program in BASIC, ok?
It's really simple as that. Anyone that tries to pull me in to
those types of conversations is going to have to deal with my
long winded explanations why BASIC sucks and why I like to
program in D. It's simply better, you agree with the literal
translation... but why not the general(do you even understand
what that means now?)?
