Re: Fwd: Heritage of Lua syntax for multi-line strings and comments

[Sean Conner <sean@...>]

It was thus said that the Great Claudio Grondi once stated:
> 
> 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.

  True.  I used to write programs that looked like this:

	1445 X=FREE(PEEK(4670)):Y=FREE(P
	EEK(4671)):IF X<2ORY<2 THEN PRIN
	T"MESSAGE BASE FULL!":RETURN :EL
	SE IFML>0THEN P$="10000000":GOTO
	1450:ELSEIFPF=0THEN P$="00000000
	":GOTO1450:ELSEPRINT"MESSAGE PRI
	VATE (Y/N)? ";:GOSUB625
	1446 IFCH$="Y"THEN P$="10000000"
	:PRINT"YES":ELSEIFCH$="N"THEN P$
	="00000000":PRINT"NO":ELSEGOSUB6
	25:GOTO1446

And there was a reason for that.  The screen width on the computer was only
32-characters wide [1] and the more you crammed into a "line" (this was
BASIC after all) the less memory it consumed.  Thankfully, I'm no longer
restricted to a 32 by 16 screen, but I still prefer monospaced fonts for
programming [2].

> >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.
> >
> 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).

  Indirection is used to solve actual problems.  Now, they may not be
problems you have, but someone, maybe a decent number of people, may have. 
As for your given example, on the Linux system I use daily, "which" is
"/usr/bin/which", with no links.  On a modern Ubuntu system I have access
to, I do see the two intermediate links you mention.  I don't know the exact
reason for it, but I can maybe guess is has something to do with
localization.  Because I also see multiple links to the man page, each of
which is a different language.

  I'm "working" (more like playing) on a project in assembly language where
the source code is in something like 500 files (mostly of static data that
the program needs in order to run).  I did it that way so I can organize the
data in an optimal way---I got tired of having to cut-n-paste huge swatches
of code to better organize the data.  It was a level of indirection that
helped me solve that issue.

  The Lua module system is yet another example of indirection.  I don't have
to care where the module "lpeg" lives, or even if it's written in Lua or C. 
The require() function handles all that mess for me.

  Yes, too many levels is bad (as the quote goes, "You can solve every
problem with another level of indirection, except for the problem of too
many levels of indirection") but at which level it turns bad is subjective. 
At my previous job, I felt that five layers of indirection was too deep, but
the primary developer felt that five was just right.  

> 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. 

  Different computer languages exist because there are different concerns
from the users of said languages.  Fortran came about because it became
tiresome to write mathematical formulas in Assembly language.  COBOL because
it was felt that non-programmers should be able to implement business logic
that was easily understandable by both human *and* machine.  Lisp because it
encouraged mathematical thinking (more than Fortran did) and exploration of
what it means to "compute."  Pascal for a pedagogical teaching language, and
C because Pascal wasn't suitable for systems programming (not really, but it
lead to a neat paper about it [3]).  Shell because it focuses on process
manipulation, not algebraic manipulation.  The list goes on.

> 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. 

  And one could say, "It's interpreters all the way down."  You use a
transpiler to transform one text, readable by humans, into another test,
readable my machine, to have that machine interpret it (even machine
language, the output from a C compiler, is interpreted by the computer). 
You can extend that further by having the computer interpret machine code
that itself is interpreting machine code for another architecture (or for
its own architecture, like IBM did with its System/360 architecture).

> 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. 

  The lightbulb thing ... it's complicated [5] and entirely related to
"planned obsolecence" (please do watch the video---it's worth the time).

  I did not plan on being a Microsoft aplogiest, but ...

  MS-DOS 1.0 was their solution to an operating system for the IBM PC,
introduced in 1981.  Microsoft at first did not want to write an operating
system and told IBM to ask Digital Research, but after a troublesom first
meeting between IBM and DR, Microsoft was an opportunity and took it.

  MS-DOS 2.0 was written to support hard drives ("fixed disc" in IBM lingo),
and to support devices other than floppy and hard drives---MS-DOS 2.0 now
supported loadable device drivers, as well as a simplified API for
referencing files (the original API, inherited from CP/M, was ... not quite
as simple to use).

  I suppose one could argue that MS-DOS 2.x was the last version you really
needed (other than bug fixes), but MS-DOS 3.0 was released to support larger
hard drives and better internationalization.  Past that, yes, it's just
Microsoft marketing new versions.

> 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.

  What is "well written" software?  For the most part, only programmers care
about "well written" programs, as users only care if the software works (and
most bugs come about due to corner cases not thought of by the developers). 
If anything, software in the past was "better" in that it came with
documentation.  Hell, my first computer's documentation had an appendix with
information about programming to the hardware.  These days, you'd be hard
pressed to get documentation with any program that is bought.  And forget
about hardware documentation.

> 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.

  That has been done before---Literate Programming.  It's great for
educational sources or legacy projects that don't change much (if at all),
but the problem is code that is perpetually being worked on, which (in my
experience) is most programs.  Yes, in a perfect world, documentation (and
code comments!) would be kept up-to-date, but we don't live in that perfect
world.  Also, who is the documentation for?  The documentation a programmer
prefers is not the same as what a user prefers.  I think that, as a
paradigm, Literate Programming is dead.

> 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.

  But (aside from the case where a feature is added because it *might* be
useful to someone) people *use* features.  You may use A, B and C, while
someone else might use B, D and E---does that make D and E not worthwile to
have?  Does my assembler [4] need to support operators other than '+', '-',
'*' and '/'?  No, I can do what I need with just those operators.  But do I
like having other operators, like '%' (modulus), '&' (Boolean AND) and '<<'
(shift left)?  Yes I do---means I can have the computer do calculations that
I would have to do.

  -spc

[1]	With high-resolution graphics and software, this could be increased
	to 51-characters wide, with a barely legible font but was ten times
	slower to render and scroll and consumed something like 8K of RAM
	(out of 64K) to do (6K just for the graphics screen).  Technical
	tradeoffs abound.

[2]	https://boston.conman.org/2023/05/10.1

[3]	http://www.lysator.liu.se/c/bwk-on-pascal.html

[4]	https://github.com/spc476/a09

[5]	https://www.youtube.com/watch?v=zb7Bs98KmnY