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