On Wed, 12 Jul 2006 15:58:56 -0400, kris <foo@bar.com> wrote:

> Walter Bright wrote:
>> kris wrote:
>>
>>> Personally, I have to wonder what compelling reason there is to continue ploughing so much effort into helping make D a success, behind the scenes, when it appears to have so little value in your eyes.
>>   Language design is hardly cut and dried. There is rarely a right and a wrong answer. There are only benefits and costs, and those vary from application to application, and peoples' opinions of them vary as well.
>>  You and I have different opinions about how certain things should work. Nothing more should be read into it than that.
>
>
> Excuse me ... you and the *community* have different opinions !
>
> Do yourself, and everyone here, a big favour and stop insisting this this is between you and I. By doing so, you send a clear message that the opinions of everyone else clamouring (or begging) for exactly the same thing is utterly worthless. That the community segment requesting this small change simply don't know what they are talking about. Fools that we all are.
>
> The attitude here is exactly what was alluded to in the original post; you make a point of utterly ignoring (and removing) the principal points, and contort what little is left. Frankly, such behaviour should not be tolerated within this community.
>
> To make it perfectly clear, yet again, we're *all* asking for the equivalent of a combined import and alias:
>
> import x.y.z as n;
>
> where n becomes a required prefix. We're not interested in using alias as a secondary instruction, for all the myriad reasons noted that you have yet to even acknowledge exist. And the "static import", as you've surely seen by the many negative responses, simply does not cut the mustard with the D community.
>

I'm not against devising new syntax for this, just thought I'd explore current means first.

I thought it would be fine just importing inside a struct like so:  struct n { import x.y.z; }  to achieve the same thing, but it turns out, this style importing is frowned upon and can cause major issues. Perhaps it's a bug that should be resolved? or something that should be forbidden?

But with a new syntax, I suspect it'd be best to not even use "as" or another word or operator and just use  import x.y.z n;  just like a regular declaration or mixin identifier doesn't need it:  int as n;  mixin foo as bar;

kris wrote:
> Walter Bright wrote:
>> kris wrote:
>>> Personally, I have to wonder what compelling reason there is to continue ploughing so much effort into helping make D a success, behind the scenes, when it appears to have so little value in your eyes.
>> You and I have different opinions about how certain things should work. Nothing more should be read into it than that.
> Excuse me ... you and the *community* have different opinions !
> 
> Do yourself, and everyone here, a big favour and stop insisting this this is between you and I.

What I am referring to is your inference of nefarious motives when I disagree with you.

On Wed, 12 Jul 2006 12:05:22 -0700, Walter Bright <newshound@digitalmars.com> wrote:
> Derek Parnell wrote:
>> Oh for Bob's sake ... you mean the primary purpose of D is to write sample programs and examples? How did I miss that!!?? I thought it was to be a real language to write commercial applications with rather than an educational tool/toy. Sorry I misunderstood.
>
> I didn't mean it's useful to make D a language to teach people about programming. I meant it's useful for teaching D to people.
>
> It's not always true, but languages that are less wordy in their example code tend to be picked up faster. People's first projects in D aren't going to be large, complex, professional products. They'll want to just try it out on something simple. That bar should be as low as reasonable.

Private imports wont have any affect on the size of single file examples and small first programs/projects.

Regan

Walter Bright wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> kris wrote:
>>>
>>>> Personally, I have to wonder what compelling reason there is to continue ploughing so much effort into helping make D a success, behind the scenes, when it appears to have so little value in your eyes.
>>>
>>> You and I have different opinions about how certain things should work. Nothing more should be read into it than that.
>>
>> Excuse me ... you and the *community* have different opinions !
>>
>> Do yourself, and everyone here, a big favour and stop insisting this this is between you and I.
> 
> 
> What I am referring to is your inference of nefarious motives when I disagree with you.


This whole thing has become far more complex than it need be. The community is asking for what seems to be a minor syntactic change, to provide notable positive value. You feel such changes are entirely unecessary, that the value is simply not there, and place little no value in the highly-visible community desire, experience, and knowledge.

At the same time, you claim "D goes where the community wants it to". Yet, what further evidence is needed to show that the commmunity desires an "import x.y.z as n;" or "import x.y.z : n;" or import "import x.y.z n"?

1) Perfectly adequate reasons have been offered forth by various parties.
2) The community is united in asking for "something better". This is a true rarity in and of itself.
3) It does not affect existing code at all.
4) It appears to be reasonably straightforward to implement (if static import is not difficult, then the extension to the desired approach should not be notably more so)
5) it fixes the ancient namespace-collision problem, and is effortless enough to /encourage/ the use of safer imports. What could be better?

Just what more is needed, exactly? What more does it take for an unobtrusive change to be effected? Exactly what does the 'motto' mean, if all the above is still not sufficient to garner such a non-impact change?




> What I am referring to is your inference of nefarious motives when I disagree with you.

Au contraire; learned friend.

If there are indeed nefarious motivation, it is evidenced within your replies to various posts. I contend that posts by others are exhibiting a similar level of frustration for similar reason, and, whatever you refer to is not reserved for me alone. Thus, it cannot be simply when you and I disagree.

Chris Miller wrote:
> I thought it would be fine just importing inside a struct like so:  struct n { import x.y.z; }  to achieve the same thing, but it turns out, this style importing is frowned upon and can cause major issues. Perhaps it's a bug that should be resolved? or something that should be forbidden?

There were bugs with it, but were resolved. It's there because:

1) the language should be as consistent as possible. C++ is loaded up with weird special case rules that serve to make the language very hard to master.

2) features can often be combined in unexpected and fruitful ways; we should be careful to not close the door on that unless absolutely necessary.

Walter Bright wrote:
> Derek Parnell wrote:
>> Oh for Bob's sake ... you mean the primary purpose of D is to write sample programs and examples? How did I miss that!!?? I thought it was to be a real language to write commercial applications with rather than an educational tool/toy. Sorry I misunderstood.
> 
> I didn't mean it's useful to make D a language to teach people about programming. I meant it's useful for teaching D to people.
> 
> It's not always true, but languages that are less wordy in their example code tend to be picked up faster. People's first projects in D aren't going to be large, complex, professional products. They'll want to just try it out on something simple. That bar should be as low as reasonable.

Really, how about Java? It is quite wordy from example programs to even the large projects, yet it has been thoroughly successful. D should be designed for mid and large projects, not small, simple ones.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bill Baxter wrote:
> 
> Q1: How many D users out there are *opposed* to imports being private by
> default?  Even if it requires everyone to change their code?
> 
+1 (Not opposed, in favor)

> Q2: How many D users out there are *opposed* to imports being "static" by
> default?  Even if it requires fixing the imports in every D source file
> everywhere?
> 
-1 (Opposed)



-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On Thu, 13 Jul 2006 05:05:22 +1000, Walter Bright <newshound@digitalmars.com> wrote:

> Derek Parnell wrote:
>> Oh for Bob's sake ... you mean the primary purpose of D is to write sample programs and examples? How did I miss that!!?? I thought it was to be a real language to write commercial applications with rather than an educational tool/toy. Sorry I misunderstood.
>
> I didn't mean it's useful to make D a language to teach people about programming. I meant it's useful for teaching D to people.
>
> It's not always true, but languages that are less wordy in their example code tend to be picked up faster. People's first projects in D aren't going to be large, complex, professional products. They'll want to just try it out on something simple. That bar should be as low as reasonable.

I understand your desire to not 'frighten' new comers away. My concern is that your "low as reasonable" seems to encourage poor programming practices. Can you provide an example where the 'import' and 'visibility' ideas being brainstormed at the moment would force example code to look scary? At worst, someone might have to add 'public { ... }' somewhere.

-- 
Derek Parnell
Melbourne, Australia

Bruno Medeiros wrote:
> Bill Baxter wrote:
> 
>> Q1: How many D users out there are *opposed* to imports being private by
>> default?  Even if it requires everyone to change their code?
>>
> +1 (Not opposed, in favor)

 Not me either.

>> Q2: How many D users out there are *opposed* to imports being "static" by
>> default?  Even if it requires fixing the imports in every D source file
>> everywhere?
>>
> -1 (Opposed)

Not me either.

Bruno Medeiros wrote:
> Walter Bright wrote:
>> It's not always true, but languages that are less wordy in their example code tend to be picked up faster. People's first projects in D aren't going to be large, complex, professional products. They'll want to just try it out on something simple. That bar should be as low as reasonable.
> 
> Really, how about Java? It is quite wordy from example programs to even the large projects, yet it has been thoroughly successful.

Java is an exception. I find it wordy, though, and I've often heard that complaint about it. And yes, it's been successful. How successful would it have been without a billion dollar push behind it? Maybe it's successful in spite of the wordiness. No language is perfect, and people often settle for flaws because the good stuff outweighs it.

On the other hand, many terse languages have succeeded despite having no money behind them - C, Perl, Ruby, etc. Sometimes when I read the debates between static and dynamic typing, the real issue seems to be that often people just don't want to be bothered with typing in a type.

Cobol has clearly stepped over the line in wordiness, and APL has stepped over the line in terseness. I think D hits the sweet spot in between.

> D should be
> designed for mid and large projects, not small, simple ones.

People aren't going to get to a mid to large project with D if it is not going to be very usable for small ones.