[eeps] A plea against trivial heterogeneity (eeps 21, 27, 28)

[Zoltan Peter Toth]

Dominic Williams wrote:
> Hello,
>
> I think a programming language should not provide several
> ways of achieving the same thing, especially when the choice
> is only a matter of taste.
>
> As programmers, we waste too much time thinking, hesitating
> or arguing about the totally trivial issues of style and
> layout. Then, we are not comfortable reading, let alone
> modifying, someone else's code. Code within the same product
> looks different, or people are frustrated with having to
> adjust to new conventions in a new project or company.
>
> I would actually go so far as to welcome a compiler which
> rejected code in which the layout (spaces, indentation etc)
> was not "standard". Obviously, all editors could then
> enforce the official layout. Then, all code would look
> identical in those trivial aspects.
>
> With that in mind, I am not favourable to the following
> EEPS:
>
> 21: Optional trailing commas for lists and tuples
> 27: Multi-Parameter Typechecking BIFs
> 28: Optional leading semicolons for choices
>
> Which all introduce an additional, optional syntax, which
> some people will adopt while others will stick to the
> existing syntax, leading to increased heterogeneity in
> styles of coding.
>
> Regards,
>
> Dominic Williams
>   
Hi,

- If your aim is to facilitate finding things in someone else's source 
code with reasonable
effort, searching only on a single (or low number of) pattern(s) if 
possible,
(which I support) then I think you would need to limit how macros may be 
used, IMHO.
Otherwise the code heterogenity gets out of control anyhow.
But probably limiting macros is not an option anymore, so this is only 
theory.

- If we don't allow e.g. EEP 27 (I support that idea - less typing, more 
readability)
then people will do it with sets  of macros.
And then, to interpret a function clause, you have to go and look up the 
macro first.
Is this something we want ?

    /Zoltan