On Wednesday, 16 August 2017 at 19:05:54 UTC, Jesse Phillips
wrote:
On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:
On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole
wrote:
But then that only helps with one specific instance. D is full
of language features, I do not see why everyone is so against
them. Without them, D would be empty, nothing, and no one
would use it. Adding language features should be see as
something good, cause without them, we wouldn't get anywhere.
Its an important challenge of software development, and a
number of articles out there about it.
https://www.google.com/search?q=the+cost+of+features&ie=utf-8&oe=utf-8
At first glance I wasn't finding anything which uniquely
tackles compilers and languages.
Backwards compatibility isn't just for programming languages
but can be more important.
Yes, but you are choosing a side, like most people. What about
the cost of not advancing? How many man hours are wasted because
someone won't implement feature because they "think" it will
cause problems or because they are too lazy or won't get enough
$$$ to do it?
Cost is not a one way street. When you don't do something it is
doing something. The whole problem with backwards compatibility
is that it is based on ignorance. When computers were first
hitting the street, people were doing what I am suggesting, as
that's all they could do. They screwed up a lot of things and
wasted a lot of time. But then 50 years later people use that as
an example, out of ignorance, to suggest that the same mistakes
will occur. They completely neglect the fact that we wouldn't
have what we have without all those mistakes either.
You can argue all you want, until you are purple in the face, but
you cannot deny what I have said as being the truth and your
arguments are baseless for the same reasons you claim mine is.
If one had to do things blindly and ignorantly, then yes, your
arguments are sound. But by using your brain, learning from past
mistakes, and moving forward to make progress, the issues can be
minimized and a balanced can be made.
You cannot apply some general statement to all specific instances
unless that statement is truly general. The backwards
compatibility plague is based on ignorance, e.g., "We don't know
what will be the ramifications of doing X so we will stick with
the status quo!". That is a purely ignorant statement, that is,
it is saying the same as "We are ignorant of what will happen if
we do X so we won't do anything".
When you apply that logic to something that one doesn't have to
be ignorant of, one is missing out on doing X and if X is good
and done and improves things then it is a same and real ignorance
wins again. No progress could ever be made if people didn't try
things. If people try things intelligent then they minimize the
problems that people like you are afraid of.
The best solution is a balance, wouldn't you agree?
When a "feature" offers no foreseeable issues(essentially nearly
mathematically proved to be correct), then it shouldn't be looked
as bad.
Again, as I pointed out, where would anything be if everyone had
the mentality you state?
Would D have mixins? No, because who knows what kinda problems
they could introduce in the language?
Would D have traits? No, because who knows what kinda problems
they could introduce in the language?
etc...
etc..
etc..
etc..
And these cause problems not just in programming but in real
life. No one wants to fix the problems, say, of America because
who knows what kinda problems that will introduce... and given
the track record of those that do the "problem fixing" we can be
pretty sure of the outcome. But the problem is then not the
problem fixing but those that fix the problems.
So, my point is that your argument is baseless and doesn't mean
anything in the real world. It is a guide, a parable about the
past and potentially the future, but people like you seem to like
to make it a law, like gravity, which it is not. The sad fact is
that it slows down real progress. One could make arguments about
and if progress is a good thing or not in and of itself, but that
is a different issue.
A good UI can help a user with complexity. So does consistency.
Adding a syntax for special meaning can be difficult to
remember. My personal example is properties in C#. The syntax
is straight forward and clean, but only recently have I been
able to remember how to write one: ReturnType Name { get {
return a; } set(value) { a = value; } }
As for your specific suggestion I think it would be nice at
times but the complexity you haven't specified is how do deal
with ambiguities if two modules provide the same symbol name.
D may have a number of features which C++ doesn't and visa
versa, the complexity of the language for C++ to have those
features means I work with D and not C++.
Then why are you so against adding features? That is what made D
better than C++? Walter could have said to himself: "I'm not
going to implement this feature that C++ doesn't have because it
will break backwards compatibility", but he didn't. He tried
something he thought would work because he reasoned it would. He
didn't make a blind ignorant leap of faith that you are claiming
is done anytime on wants to change something. It was based on
experience and reason.
If you can find a specific reason why having such a notation is
wrong then that would be a valid point, but generalities that
don't apply is not helpful to the cause.
As far as your argument about ambiguities, that already exists,
so it is not a problem with a new feature that extends what we
have(it might inherit the problem, but it is not the cause of
it). So, you should talk to walter about fixing that.
Do you understand? I have no issues with trying to defend the
logic of something I say should be implemented, but you have to
use proper logic itself instead of going with your gut and then
creating baseless arguments against it. My main argument is that
your two arguments: 1. Adding language features is bad. 2. The
proposed idea creates the issue of ambiguity between identical
symbols.
My logical argument against yours:
1. It is irrelevant and has nothing to do with anything. It may
or may not be a valid argument in some sense but it is just a
safety net/guide rail and by no means used to judge the validity
of something. (one can't really reason anything from that
argument because as much as it is right it is also wrong)
2. The ambiguity is, at it's root, part of D's module system
design and part of D's problem, not the addition of something new
on top of it. It cannot be fixed by not adding the addition and
can't be fixed by choosing not to have it. So it too is
irrelevant. If, it were to complicate the addition and make the
addition have new problems, then that is a valid argument, but
that is something you have to prove or show, which you haven't
done.
So what I have ended up doing, rather than really defend my
proposal for what it is and does, is have to correct your logic
so that maybe we hopefully get somewhere. Note that none of this
is an attack on you so don't get upset. I simply would like to
see this feature get implemented if it is a good idea, and if it
not, then I don't want it to... but before we can determine that
in a correct way, we first have to judge it for what it is rather
than what it is not.
To even make it clearer: You mention your problem with C#'s
properties. Your logic is that they shouldn't be implemented the
way they are because it confuses you. That is not logical. I got
the properties in 2ms because I realize it is just a definition.
It is your ignorance(not a personal attack, we are all ignorant,
but you are ignorant in that thing which causes you not to get
it, which I wasn't... not because I'm better than you are
smarter, but because I'm different) that prevents you from doing,
not a defect in the properties. But instead of you finding that
thing that makes it difficult for you to get, you want to slow
everyone else down and make them use the same thing that works
for you(which might not work for them)... but in any case, it is
not logical, it is an argument based on ignorance.
In fact, I like they say C# does it and it makes complete sense
to me... in fact, many things that C# does makes sense and the
only reason I don't use it is because of the CLR/IR type of stuff
that becomes a hindrance for many things I do. IMO C# is the best
designed language I've ever seen out of about 30 languages I've
used. (from assembly to pascal, to eel, to D)
But all that is irrelevant, the map is not the territory. My
arguments are about the territory while yours, so far is about
the map. Hopefully you can get that so we can move on to both at
least be on the same topic. BTW, I'm not in to maps because I
think they are irrelevant made up BS and basically based on
humans ignorance and are the real waste of time. (And hopefully
by maps you realize I'm not talking about real geographical maps)
