How can we make it easier to experiment with the compiler
sighoya
sighoya at gmail.com
Tue May 25 19:08:18 UTC 2021
On Tuesday, 25 May 2021 at 09:05:26 UTC, Ola Fosheim Grøstad
wrote:
> On Tuesday, 25 May 2021 at 08:32:46 UTC, sighoya wrote:
>> You can't encode the full semantic into one function name with
>> parameter names without to over blow these names.
>
> We can assume that the reader has read a book on compiler
> design and is familiar with the terminology and the most common
> algorithms. Provide a reference to wikipedia if unsure if the
> reader is with you...
For very general things, yes, this is possible, but there are
structures and algorithms out there which didn't resemble that
what you've learned or there isn't a simple name
invented/discovered by someone.
Everyone has a different intuition how to solve a problem which
could be pretty hard to follow without comments by reading solely
index operations, shifts and type names which are so specific as
the cosmos.
> Functions that are only called from a few places can have long
> descriptive names, that is not a negative.
Trade off, but I appreciate this in tests for instance.
> Yes, obviously. But adding 6 lines of comments for every
> trivial function is not helpful. It is a useless policy. It is
> a policy for the sake of having a policy.
Yes, I agree with this and six lines is mostly too much, look at
the example I linked before, this was mostly a one liner of a
comment.
> If time is invested in documenting things that should be
> changed... then change becomes less likely: "look, the
> documentation is over there, change not needed".
Okay, that may be true, but it makes it also easier to dive in
and to have fun to change things.
> Anyway, documentation is the wrong solution to structural
> issues. It does not enable anything.
Agree.
> It is kinda like saying a city does not read roadsigns because
> there is a good map available. Or that a city that is a
> labyrinth of one-way streets are easy to navigate with the
> right kind of map. Driving while looking at a map is not a good
> experience. And when things change, can you then trust the map?
>
> *shrug*
I think the metaphor speaks against you as the map is the wiki
article you mentioned :)
More information about the Digitalmars-d
mailing list