3 ms·

> The tradeoff for this is generality. No-code languages aren’t general-purpose in the same way a language like Python is, but for the vast majority of projects

> The tradeoff for this is generality. No-code languages aren’t general-purpose in the same way a language like Python is, but for the vast majority of projects, this is a good tradeoff. Most programming work happens inside a well-defined domain like web development, so why shouldn’t it happen in a language specialized for that purpose? I'm trying not to just react by saying "change is bad", but I am legitimately not sure I buy the argument in this article, even beyond the basic distrust of a prediction made by someone with a financial stake in the outcome. He goes to great pains to say that no-code is not the same as WYSIWYG editing, but I'm trying to conceptualize how his explanation differs from them. The IDE is the language, got it. But, the fundamental problem I have with this is the same: your expressiveness with the language is limited to what the product owner decides to support in the UI. So, you've moved away from having a language with elements that can be combined in infinite ways, toward something more like a MadLibs, where you can make some meaningful choices only within a strict framework somebody else has made for you. Or, if that's not fair, then a more generous analogy would be something like writing free verse compared to writing a sonnet. You're using the same language, but one option is much more constraining. Or, an even more practical example would be with something like WebFlow, which is the "no code" (note the quote marks) solution I've used. I think it's great, and you can do a ton of stuff with it without investing a lot of time into learning HTML, CSS, and Javascript. But, then you run into this weird situation where somebody decided that you can only absolutely position elements from the top or left, not the bottom or the right. If you want to do that in a "no code" way, you're out of luck, because nobody provided a button for you to do that. And even if this kind of system isn't what the author intends to mean, I think it is analogous to the kinds of problems any highly-abstracted programming environment will run into.

88913527 5y ago
I constantly hear Product Owners say that it's okay and acknowledged that ultimately, you hit walls with no-code/low-code. There was no button to do Thing X, so you just can't do it. But did anyone validate this with the end user? Is this actually what they want?
Closi 5y ago
> So, you've moved away from having a language with elements that can be combined in infinite ways, toward something more like a MadLibs, where you can make some meaningful choices only within a strict framework somebody else has made for you. Or, if that's not fair, then a more generous analogy would be something like writing free verse compared to writing a sonnet. You're using the same language, but one option is much more constraining. To be honest, I don't think this is a valid analogy as you are comparing apples and oranges. One is a tool to build simple CRUD interfaces which is typically used to quickly build business applications, and another is a coding language which provides lots of flexibility but is significantly slower to create an application and is much more complex to build. IMO a good solutions designer or architect will be able to identify which solutions/problems will be better solved in a low-code environment and visa-versa. It's not a 'one is better than the other', programming languages will be better for some problems and low-code solutions will be better for others.

88913527 5y ago

I constantly hear Product Owners say that it's okay and acknowledged that ultimately, you hit walls with no-code/low-code. There was no button to do Thing X, so you just can't do it. But did anyone validate this with the end user? Is this actually what they want?

Closi 5y ago

> So, you've moved away from having a language with elements that can be combined in infinite ways, toward something more like a MadLibs, where you can make some meaningful choices only within a strict framework somebody else has made for you. Or, if that's not fair, then a more generous analogy would be something like writing free verse compared to writing a sonnet. You're using the same language, but one option is much more constraining. To be honest, I don't think this is a valid analogy as you are comparing apples and oranges. One is a tool to build simple CRUD interfaces which is typically used to quickly build business applications, and another is a coding language which provides lots of flexibility but is significantly slower to create an application and is much more complex to build. IMO a good solutions designer or architect will be able to identify which solutions/problems will be better solved in a low-code environment and visa-versa. It's not a 'one is better than the other', programming languages will be better for some problems and low-code solutions will be better for others.