4 ms·

The key problem that creates "low" or "no" code products is a pattern that shows up in a lot of technical fields: non-technical people run into the first hurdle

The key problem that creates "low" or "no" code products is a pattern that shows up in a lot of technical fields: non-technical people run into the first hurdle, and assume it represents the majority of the difficulty. In software, this is sourcecode syntax. Somebody who's never written a line of code in their life sees source code, can't read it straight away, and assumes "We pay the software developers lots of money because they can read the cryptic runes" and goes on to pitch some "revolutionary solution" that eliminates this very minor hurdle, assuming that it will make the whole thing easy. You see the same thing in discourse about science and math: "If we could just eliminate all the jargon and syntax, anybody could understand a scientific paper". In all cases, they're wrong, of course, since the syntax and jargon are such negligible hurdles that by the time someone is technically capable enough at the actual problem they'll come as second nature, but the non-technical folk don't ever reach that level of understanding. Then this solution gets sold to other non-technical people, who, falling into the same trap, integrate it into their workflows.

danielvaughn 3y ago
Yep, they misunderstand where the complexity lies.
d-lisp 3y ago
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.

danielvaughn 3y ago

Yep, they misunderstand where the complexity lies.

d-lisp 3y ago

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.