4 ms·

I am not expecting developers to welcome the new "No-code" movement. But eventually, it will happen. An app that's capable of building itself, supposed to be th

by jimmy2020 5y ago

I am not expecting developers to welcome the new "No-code" movement. But eventually, it will happen. An app that's capable of building itself, supposed to be the next generation of building apps. Take a look at web development. It's revolutionary and changing fast. Users have more power than anytime before. More flexibility is being added every day with the rising of third parties services that make development faster and more reliable than ever. The question should be about complexity. How to manage the "no-code" complexity. Is it better for the user or it will add a new burden of learning? Does the no-code mean a special team to learn how to build without coding. Is it cheap, or hiring a specialist is better when it comes to fixing bugs and shipping new features.

feoren 5y ago
The vast majority of software being written today is still CRUD applications centered on a database using a groupthink architecture where every noun gets a table and everything you ever want to know about that noun goes into that table. They're extremely brittle, completely un-reusable, and virtually un-maintainable. Meanwhile the front-end tech is iterating rapidly because we're at the very beginning of that sigmoid curve, not toward the end. Software engineering is still very much a baby discipline. We are brand, brand new, and not nearly as advanced as you seem to think. Meanwhile Bridge Engineering, a 4000-year-old discipline, is still inventing new ideas and is still done almost entirely by human engineers. They use computers to multiply their expertise, but in no way are the computers "designing the bridge" for them. Why would automation make software engineers obsolete when that hasn't happened to bridge engineers (and shows no sign of coming)? Apps have been "building themselves" for decades: it's called a compiler. How do you manage complexity? With software engineering. Writing software without writing code is like trying to design a bridge without doing math. And if it's those crappy, un-maintainable, un-reusable CRUD applications you're saying no-code will replace, then I say: good riddance! But even if no-code is more successful than its wildest dreams, it's still just automating that lowest tier of programmer. Meanwhile, better abstractions, programming languages, type systems, mathematical advances, training programs, techniques, and architectures have been raising that water level every year for a long time. Even a good no-code solution has a very limited expected life when it's competing with that.
- jimmy2020 5y ago
  > Apps have been "building themselves" for decades: it's called a compiler. To your point, can I call the cement mixer a self-made building material that resulted in an accumulation of 4000-year-old of knowledge? Every known industry has different levels of production to reach the final product. Which may be a tool builder to automate the industry. Exactly the same way the building evolves to the prefabricated. The limitations are with the raw material which is clearly to the advantage of the software industry. > Meanwhile, better abstractions, programming languages, type systems, mathematical advances, training programs, techniques, and architectures have been raising that water level every year for a long time I totally agree with all of the above. But that can be done along with investing more in the essential no-code tools. And if some has decided to go further good luck. The argument about we need to do more so please let's stop the entire direction of automating because somewhere they still using CRUD, old-fashioned and unmaintainable code is similar to let's stop space discovery because we still have problems on the planet earth. We can do both.
  - feoren 5y ago
    I feel less like I'm asking to stop space discovery until we fix Earth, and more like I'm cautioning against the claims of crystal healing and homeopathy. I would have no issue with a well-conducted, good-faith research study into crystal healing -- after all, simply coating a surface in silver dramatically increases its anti-bacterial properties, so clearly some "dark-ages alchemy" level claims are actually true. But with our current priors, given a random claim about crystal healing, what is the probability it's backed by solid research vs. the probability it's quackery? Similarly with no-code. Should we stop trying to build no-code solutions? No. In fact there are limited used cases where it goes well, such as the Blender material designer. But with our current priors and given a random claim about what some no-code solution will be able to do, the probability it's BS is very, very high. Maybe that's actually the answer: the place for no-code is not in replacing general-purpose programming languages, but in small, limited-purpose DSLs like shader languages (and even then, only in specific contexts). SQL is an example of such a thing, so if someone came out and said "I have a great no-code solution that's meant to replace annoying repetitive SQL queries in a limit set of circumstances", I would take that person much more seriously.

feoren 5y ago

The vast majority of software being written today is still CRUD applications centered on a database using a groupthink architecture where every noun gets a table and everything you ever want to know about that noun goes into that table. They're extremely brittle, completely un-reusable, and virtually un-maintainable. Meanwhile the front-end tech is iterating rapidly because we're at the very beginning of that sigmoid curve, not toward the end. Software engineering is still very much a baby discipline. We are brand, brand new, and not nearly as advanced as you seem to think. Meanwhile Bridge Engineering, a 4000-year-old discipline, is still inventing new ideas and is still done almost entirely by human engineers. They use computers to multiply their expertise, but in no way are the computers "designing the bridge" for them. Why would automation make software engineers obsolete when that hasn't happened to bridge engineers (and shows no sign of coming)? Apps have been "building themselves" for decades: it's called a compiler. How do you manage complexity? With software engineering. Writing software without writing code is like trying to design a bridge without doing math. And if it's those crappy, un-maintainable, un-reusable CRUD applications you're saying no-code will replace, then I say: good riddance! But even if no-code is more successful than its wildest dreams, it's still just automating that lowest tier of programmer. Meanwhile, better abstractions, programming languages, type systems, mathematical advances, training programs, techniques, and architectures have been raising that water level every year for a long time. Even a good no-code solution has a very limited expected life when it's competing with that.

jimmy2020 5y ago
> Apps have been "building themselves" for decades: it's called a compiler. To your point, can I call the cement mixer a self-made building material that resulted in an accumulation of 4000-year-old of knowledge? Every known industry has different levels of production to reach the final product. Which may be a tool builder to automate the industry. Exactly the same way the building evolves to the prefabricated. The limitations are with the raw material which is clearly to the advantage of the software industry. > Meanwhile, better abstractions, programming languages, type systems, mathematical advances, training programs, techniques, and architectures have been raising that water level every year for a long time I totally agree with all of the above. But that can be done along with investing more in the essential no-code tools. And if some has decided to go further good luck. The argument about we need to do more so please let's stop the entire direction of automating because somewhere they still using CRUD, old-fashioned and unmaintainable code is similar to let's stop space discovery because we still have problems on the planet earth. We can do both.
- feoren 5y ago
  I feel less like I'm asking to stop space discovery until we fix Earth, and more like I'm cautioning against the claims of crystal healing and homeopathy. I would have no issue with a well-conducted, good-faith research study into crystal healing -- after all, simply coating a surface in silver dramatically increases its anti-bacterial properties, so clearly some "dark-ages alchemy" level claims are actually true. But with our current priors, given a random claim about crystal healing, what is the probability it's backed by solid research vs. the probability it's quackery? Similarly with no-code. Should we stop trying to build no-code solutions? No. In fact there are limited used cases where it goes well, such as the Blender material designer. But with our current priors and given a random claim about what some no-code solution will be able to do, the probability it's BS is very, very high. Maybe that's actually the answer: the place for no-code is not in replacing general-purpose programming languages, but in small, limited-purpose DSLs like shader languages (and even then, only in specific contexts). SQL is an example of such a thing, so if someone came out and said "I have a great no-code solution that's meant to replace annoying repetitive SQL queries in a limit set of circumstances", I would take that person much more seriously.