Interesting to note that scientific paper "trivialization" is about replacing jargon words by their meaning; i.e. by opening abstractions, making the text large

Interesting to note that scientific paper "trivialization" is about replacing jargon words by their meaning; i.e. by opening abstractions, making the text larger and larger, note that every scientifical concept or abstraction needs other abstractions to be explained that needs themselves trivialization because an abstraction is an elliptical and compressed way of saying something else (every abstraction is a tree of abstractions). With this operation you are losing the possibility to even read some paper for obvious length reasons. What you lose in complexity is gained in thickness. The problem is that low/no code doesn't consist in the same thing; abstractions it propose are meant to build a bridge between our current language and programming languages, just as UI is a bridge between our behavior and the execution of some script/function. In fact in this case, we are proposing to trivialize software development, not by reaching the initial machine code it expresses (explaining abstractions) but by inventing on top of theses abstractions another type of abstraction that is understandable to the non tech person reading the code (high level languages vs assembly is performing a similar operation). The difference with the science paper case is that here, complexity of abstractions leads to a better understanding of the text. Problem is that with low/no code, you are lacking the ability to cross the bridge back (because you fail to analyze abstractions into their atoms) while scientific folks can. C is powerful because it allows you to stay in the position of someone that understand computers and assembly. Higher level languages (interpreted ones) are dealing with the problem that low code hopes to solve in a better way : you don't need to understand the C implementation of X language to use it, and still you have a lot a power and freedom to develop software, eliminating the overheads of dealing with memory and etc... I fail to see low code as something else than a subset of X interpreted language that allows you to write in pure english (but the complexity of software doesn't lie in its expression, rather in its conceptualization), OR as something else than a GUI that allows you to write software (or UI) by dragging and dropping stuff at the screen, which is the worst I can imagine because again you would have the same problem of learning to technify yourself and reading documentation to understand what is in fact a weird suboptimal programming language.