|
|
Am 13.07.2021 um 12:05 schrieb Mr:
> Coming from Python I know that my apriori not (yet) feeling the same about this
> is probably thus biased, but could you please also develop more about why as a
> user you would prefer an abundant punctuation over a meaningful indentation
> system ?
Indentation is trouble.
If you ever encounter a source file that mixes tab-indented and
space-indented code, you may realize what I mean. In languages that
don't assign semantics to indentation, such a mix results in eyesores at
worst. In languages where whitespace matters, it can get far worse.
The core problem there of course is that there are different standards
how many spaces a tab should be worth: Two? Four? Eight? Three? Six?
Five? Been there, seen all of those.
And it's not like you can tell at a single glance what's going wrong
there, with tabs and spaces both being entirely invisible and therefore
looking identical.
And if you've ever edited makefiles (or proto-makefiles as used in
Autoconf-based build systems), you really learn to hate languages that
assign semantics to whitespace. If you set your editor to replace tabs
with spaces, you _will_ break your makefiles.
(Granted, most indentation-aware languages don't assign different
semantics to tab indentation vs. space indentation.)
So there's the tab issue, for starters.
The next issue of indentation-structured languages - or at least those
that use a hard "end of line is end of statement" rule - is that they
put a practical limit on how complex you can make a single statement. If
you have a very complex mathematical formula, you need to break it up
into smaller chunks, assign those to variables, and then assemble those
into your final result. Or even more interim results first.
Now it can be argued that this forces you to give more structure to your
code, thus making it easier to understand.
However, breaking up an expression into named sub-expressions is not the
only way to structure complex formula. Specifically, even short formulae
might benefit from being spread out over multiple lines. And maybe
liberally peppered with indentation without having to worry about
breaking semantics.
And what if you're just using a formula from someplace else, and have no
idea whatsoever what the individual portions of the formula really mean?
Or if you've optimized a mathematical expression for performance in such
a way that its original "natural structure" is no longer visible anyway?
What you'll then do is use meaningless single-letter variable names to
the sub-expression, and the resulting code will look far more complex
and far more difficult to grasp than it would have, could you have
written it as a single expression spread over multiple lines and
indented freely.
And speaking of variable names, restricting the practical length of a
statement may actually lead to poorer rather than better code, in that
people may develop a habit of keeping variable names short and thus
potentially more cryptic.
(Some "end-of-line-aware" programming languages allow spreading
statements across multiple line by "invalidating" a line ending, but the
corresponding syntax tends to be somewhat clunky. If you've ever done
much C/C++ preprocessor programming, you'll know what I mean. What's
more, such syntax often breaks in the presence of stray blanks at the
end of a line, which are a pain to find.)
Also, sometimes it may actually improve readability to put multiple
short statements on a single line (especially when there's a group of
statements that repeats in structure). Some end-of-line-aware languages
allow this (e.g. shell scripts), but again generally at the cost of
added symbols and therefore clunkiness.
Of course it can be argued that whitespace-agnostic languages need the
same extra symbols between statements, not only in a single line but
also between lines. But in my mind separator characters become less
clunky if they're used consistently throughout, as opposed to just on
special occasions.
And then there's the matter of copy-and-pasting:
When you copy-and-paste code from arbitrary sources (a web page here, a
PDF there, a terminal window over there, and what else you might happen
to come across), you may end up with broken indentation.
If the code is reasonably complex, have fun faithfully restoring the
original semantics.
If the semantics is all in the non-whitespace, smart editors may
actually be able to restore the original indentation, at least to the
point that its structure is agion easy enough to grasp for a human. If
semantics is in the indentation itself, how could an editor ever restore
that indentation?
Also, look at written human language: There's a reason we're using
special characters to indicate the boundaries between sentences and
subclauses, rather than using a "one line = one sentence" default rule
and using special syntax to spread sentences across multiple lines.
Now I can't rule out that Python may for some reason manage to get
around each and every one of the above issues - I've had virtually no
exposure to that language yet. But based on my experience with other
end-of-line- and indentation-aware languages, my guess is that at least
some of those issues do apply.
But even if Python should be entirely immune, that doesn't mean it would
be easy to design a new POV-Ray SDL that is also indentation-aware and
has the same level of immunity as Python.
And yet, feel free to throw together a corresponding proposal, and
present it here. Even if it should turn out to be seriously flawed,
there may still be interesting and inspiring morsels in there.
Heck, I've never claimed that my own proposal was really any good. I
just threw it out there to have _some_ starting point. For discussion at
worst, or for further development at best.
As a matter of fact, I don't even _particularly_ like it. It's not very
elegant, because it is not custom-tailored to our needs. It is derived
from an existing base. It does have interesting properties though, one
of which arises _specifically_ out of being derived from an existing
base. And for now I think it has the potential to be useful, and maybe
even reasonably good.
No worse than the current SDL, and better structured - that's all I'm
asking of a new SDL. Ideally with consistent syntax between scene
descriptions and functions, and maybe with a rigorous enough structure
to allow for a compiling rather than interpreting parser.
Post a reply to this message
|
|