 |
lua-l archive |
|
|
||
|
On 11/24/23 21:35, Mouse wrote:
With this approach (the single quotation is quite narrow and not obtrusive)I suspect this is relevant to only a tiny, _tiny_ fraction of Lua users. I think you're the only person I've ever even heard of who actually prefers a non-monospaced font for writing code - not that I've done a survey of the field, or anything, but still.
Yes, I am aware of this attitude out there ... the revelation is that if you change this attitude things start to be easier and look better and you stop being stuck in old pattern of thinking.
The general craziness out there is to extensively use indirection inflating the size of the script with code of no relevance increasing at the same time the number of files involved in a project. From all the executable files in my Linux $PATH only 8% are the actual executable ones and the others are just wrappers to wrapper of wrapper for the actual functionality (check this out ... for example track down the command `which` and see that there are two soft-links on the way to a script which is finally calling the interpreter executable).But that actually strikes me as a reason to _not_ use it. Something as semantically important as a comment, or even string, delimiter is not something I, at least, want to be visually subtle.
One of the purposes of the oOo system/attitude/vocabulary/way-of-thinking I am currently working on is to encourage you to check the amount of the actual relevant code compared to the total text written while creating an application. You will be probably very surprised to see a huge variety between the two extremes: pure not understandable code with no documentation and commented code with well done documentation where the size of the documentation by far exceeds the size of the source code. If you start some very deep going thoughts on it you may arrive at the discovery that the actual code is an add-on to all of the text coming with it (not mentioned all the additional tutorials, blogs, etc.). In other words, not the comments are what should be actually marked in a script code ... the actual code is what need to marked among the text explaining what the code is good for.
I am maybe going too far comparing the oOo way-of-thinking about the computer technology as pure translators between the vast amount of languages out there (which are being there because of the Tower of Babel where all this started in order to make it hard to understand each other and prevent raising the tower up to the sky) to the geocentric vs. heliocentric way of thinking about the Sun, Moon, Planets and the Universe. But ... once you have got the clear perspective what it all actually is: transpilers from transpiler language to other transpiler language for transpiling to some further language based on a library using some other language ... the complexity of Planet movements you observe will vanish ... they start to go around the Sun instead of going forth and back making thing complex. It's crazy to see what happens: in the first step you get forced to use a system which comes with a bunch of issues in order to be later offered help to resolve the issues you encountered. I call it "the Microsoft way". You ensure being in the business by pushing something to the market which then needs further purchases of tools helping to resolve the issues put into it maybe not because of not knowing better, but on purpose. Like limiting the time light bulbs work ... in order to be able to sell more of them continuously. Well written software does not need much documentation and no further efforts ... The better the tool, the less you can earn after-sales ... and if it is perfect ... you don't earn anything except seeing that someone else is screwing it and pushing the screwed to the market to ensure after-sales.
OK ... it's already too much and maybe not really on topic, except you are ready to turn things upside down and start to see that the code is the actual exception worth to be marked and not the comments ... Best you embed the code into a documentation text in a way not disturbing the text flow of the documentation ... this way you can then run the documentation ... and know by the way what it is doing without the need of learning the specific syntax of the underlying programming language.
And from all the programming languages out there I have took into consideration up to now ( ... a very, very long list ... ) Lua seems to be the best start point on the journey to stop the craziness of adding features on top of features in order to provide then tools helping to manage it all ... forgetting on that path what was the actual goal which started the journey.