| 'no code' usually does not just refer to a different type of editor, like a visual widget composer. It usually implies the creation and specification an now be done by a person that does not need coding skills. The latter is not impossible, but there is a tradeoff. As computers have endless capabilities, a hue number of design choices need to be specified in order to select/create the specific outcome desired. This required information need can for the end programmer/designer be reduced by shrinking the potential design space through premade implicit descisions. Creating a 'stopwatch' app from scratch starting with a blinking cursor in an empty text file will require a lot more specification than creating it in a dedicated graphical stopwatch designer where all that is still needed is specifying the color of the start/stop button, but the former leaves you endless more possibilities than the latter. Getting the above tradeoff right usually runs into the 80/20 situation. You can live with 80% of the choices made, they cover 80% of your needs, but for the rest... And now your non-coder runs into a problem. Not only is the skillet promise now void, the higher level abstraction made in the 'no code' model is not crisply delineated, so the coder brought in to finish the job now has to understand the complexities of the code underlying the abstraction where the design tradeoffs were chosen not in favor of this under the hood meddling. A similar problem occurs when a bug or unforeseen configuration breaks the no code veil. This is referred to as the 'leaky abstraction' problem. In the end usually you still need a coder that understands the lower level. And specifitions for highly open systems are more efficient conveyed and maintained through textual 'code' than through other types of graphical editors. |