Few things

[Jascha Wetzel]

Bill Baxter wrote:
> Or you need to have a slick IDE that parses 
> everything and figures out for you where various symbols are coming from.

today's programming practice (and language design, as far as it's 
concerned) should be able to assume proper tools. many things like this 
can be tackled with semantics-aware features for editors. another 
example are complex naming conventions that emphasize type or scope of 
variables (like hungarian notation).
what these things have in common is, that they make code less readable 
by including information that can be obtained in different ways.
readability depends on the reader. the more familiar you are with the 
code, the less readable it becomes by additional information. the same 
holds true if you are only interested in the general function.

i think, that the more real code looks like pseudo code, the better. i 
often start programming by writing down pseudo code in the editor. it's 
easier to mess around with and it isn't as officially separate like an 
upfront pen-and-paper design phase. after i'm happy with the pseudo 
code, i add the remaining detail. over and over i'm impressed about how 
little detail i need to add to make it valid D code. the closer it stays 
to the pseudo-code stage, the easier it is to maintain and refactor. 
therefore keeping it that way should be a good thing. if additional 
information can be gathered from an edit-time parser, it shouldn't be in 
the code.

...sorry for the rant ;)