Import concerns revisited

[Walter Bright]

Sean Kelly wrote:
>> 2) I think we can all agree that if it is at module scope in the 
>> middle, that is probably bad coding style - especially if there are 
>> forward references to it.
> 
> Certainly.  However, it's been my experience that the vast majority of 
> programmers on any given project tend not to be particularly scrupulous 
> with their coding style, and code quality tends to degenerate over time. 
>  Therefore, I believe that any means available to encourage good coding 
> style and ease readability is worth considering quite carefully.  Having 
> literally tossed old projects in the trash because the cost of 
> maintenance was actually higher than a complete rewrite, I really can't 
> stress this point enough.  But please note that I'm not suggesting a 
> language or tool should in any way "dumb itself down" for the user, only 
> that aesthetics plays a significant role in determining whether a 
> particular feature or technique will be successful.

I can agree with that. I had a particularly weird experience with the 
delegate literal syntax. People would email me saying:

D can't do this:
	apply(arg, { _1 < _2 });

and I'd say, yes it can:
	apply(arg, int delegate(int _1, int _2) { return _1 < _2; });

but they'd come back in the next email saying it would be really really 
cool if D could do lambda functions. Sigh. That's when I realized that 
the int delegate could be done away with in the syntax, leaving:

	apply(arg, (int _1, int _2) { return _1 < _2; });

and suddenly they'd see the lambda function. Something about the word 
'delegate' would just derail what they were seeing.

Another story: I had a friend who taught remedial algebra in college. 
She'd ask her students:
	"Solve x+2=5 for x"
and they were stumped. But if she said:
	"What goes in the circle: O+2=5"
and they'd all instantly say "3, of course." Just saying the word "x" 
would invoke the I-cannot-do-algebra subroutine.

I'm beginning to suspect that the word 'alias' has a similar effect :-(

>> 3) The with-import-as won't eliminate bad coding style with aliases. 
>> One can still plop an alias down in the middle of the module.
> 
> I do believe that bad code typically results from a few common causes:
> 
> * The programmer honestly doesn't know any better.  Often he's a novice 
> or simply hasn't been exposed to the level of programming required for 
> the task assigned.
> 
> * The programmer knows better but is in a hurry and doesn't care about 
> cutting a few corners.  He'll go back and fix it when there's more time. 
>  And that time will never be available.
> 
> In both of these cases, language aesthetics makes a difference.  In the 
> first case, a mentor could suggest an alternate approach.  For this to 
> succeed the learning programmer must be able to remember the solution 
> and it must be fairly easy to execute.  If not, the programmer is 
> destined to become a member of the second category, as he now knows 
> better but finds some excuse not to use the technique anyway, often 
> because he can't remember the details or because it requires too much 
> typing.  In both cases, having support for the suggested technique built 
> into the language or tool is ideal, as it presents both a syntactical 
> reminder and a simpler way to accomplish the task than the programmer 
> would be inclined to use otherwise.

In general, I agree with that. But I find 'alias' to be very easy to 
remember, while I have to stop and think about with-import-as. The 
'alias' is also already learned. The with-import-as is additional syntax.

> Finally, if the technique *looks 
> better* than another method and it's used pervasively, it will typically 
> be followed by others (the broken window problem).
> 
>> 4) At least with aliases, they need to be defined within the module. 
>> This means one can do a simple search of one source file to find any 
>> aliases.
> 
> Given the size of some of the source files I've seen, even a directed 
> keyword search may take some time.  This simply doesn't compare to a 
> glance at the import line.

The imports can be placed anywhere in the module, even (ugh) inside 
class definitions. 'import' isn't any easier to search for than 'alias'.


>> Yes, the latter is more typing. If one was to do this a lot, it can 
>> get annoying. But is it going to be done a lot? I think that is the 
>> crux of the matter.
> Assuming the language stays as-is, I believe the aliasing will likely be 
> limited to instances where collisions occur, as the technique is easy to 
> forget and requires a lot of typing.  I expect this will also lead to 
> maintenance issues as library upgrades cause symbol collisions and such.

It does require more typing, which I agree will tend to cause it to be 
used less, but I have a lot of difficulty believing it is easy to 
forget. It's like saying one would forget how typedef's work.


>> P.S. There are other possible syntaxes:
>>
>>     import foo.bar
>>     {    def = abc,
>>         jkl = ghi,
>>         mno,
>>     }
> 
> As long as the syntax is aesthetically pleasing and 
> logically/structurally similar to Kris' proposal, I won't bicker over 
> minutiae.  That isn't too say I'm overly fond of the syntax you just 
> suggested, but I do understand that a slightly different syntax may 
> parse more easily or  better fit the 'feel' of the language as a whole.

That is just a thought to show that new keywords aren't necessary. I 
find the 3 keyword approach to look a bit cobol-ish, and not as visually 
distinct as it should be.