New Features [was Named multi-imports]

Wed Aug 16 15:19:31 PDT 2017

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..

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)