3 ms·

I would like to understand why you think so since I am working on my own open source product which has many similar aspects as Retool, although not in the same

I would like to understand why you think so since I am working on my own open source product which has many similar aspects as Retool, although not in the same exact domain.

valenterry 5y ago
It always boils down to the same thing: people think that it's a technology problem. But it's a people problem. Software development (at scale) is not difficult because you tell a computer what to do (that part is quite simple), but because you and many others need to communicate your thoughts both to a computer _and_ humans (sometimes even themselves) over a potentially long period of time. And as if that were not bad enough, it all has to be coordinated. These two things - sharing thoughts and doing coordination work - are what eat your resources. When doing "normal" development, you use a programming language and most likely an IDE and a VCS such as git(hub). All of these usually exist for quite some time are used by _a lot_ of people and are well understood, polished and mature. (well, of course some more than others) But every no-code tool (or low-code) such as Retool has to recreate _all these_ by itself. This is really as bad as you having to learn a brand new programming language, an IDE and (partly) a VCS. Will they be as good as the tools that millions of people already use? Probably not. And just to clarify the programming language part: yes Retool is sort of a programming language. Even though you can embed SQL. (You can do this in other languages too). Clicking instead of mostly typing doesn't change this fact. Of course, all of that doesn't matter if you build something quickly and throw it away in a few month. In that case, Retool might actually pay off. But these cases are not the "hard" ones anyways and are usually not a big problem in most companies.
- rtpg 5y ago
  It seems like a bit of a mistake to look at this like a programming language instead of, say, an information organization tool like Trello. You don't have an IDE for designing process around Trello, you talk to people and figure stuff out that works (so long as it works well enough). I think these kinds of tools fit well in places where process are the big blockers, instead of the technical details (though of course technical details can crawl back up and bite you). (Though I do think what you're saying seems to apply more to Retool relative to more straightforward low-code platforms like Anvil)
  - valenterry 5y ago
    If it is not a programming language, you cannot do everything you can possibly think of and you would be restricted. But people _want_ to do what they have in mind, so they will work around the tool in some way. Either by employing a mechanism to still make the tool do what they want (e.g. macros in Excel) or by using another tool that fills the gap. In case 1 you now have the worst of both worlds and in case 2 you now have X tools with all the problems that a zoo of tools brings. If, on the other hand, you _can_ describe every business rule that you can think of in that tool, then it _is_ a programming language. There is no requirement for a programming language to use text. See scratch lang for example.

I would like to understand why you think so since I am working on my own open source product which has many similar aspects as Retool, although not in the same exact domain.

valenterry 5y ago

It always boils down to the same thing: people think that it's a technology problem. But it's a people problem. Software development (at scale) is not difficult because you tell a computer what to do (that part is quite simple), but because you and many others need to communicate your thoughts both to a computer _and_ humans (sometimes even themselves) over a potentially long period of time. And as if that were not bad enough, it all has to be coordinated. These two things - sharing thoughts and doing coordination work - are what eat your resources. When doing "normal" development, you use a programming language and most likely an IDE and a VCS such as git(hub). All of these usually exist for quite some time are used by _a lot_ of people and are well understood, polished and mature. (well, of course some more than others) But every no-code tool (or low-code) such as Retool has to recreate _all these_ by itself. This is really as bad as you having to learn a brand new programming language, an IDE and (partly) a VCS. Will they be as good as the tools that millions of people already use? Probably not. And just to clarify the programming language part: yes Retool is sort of a programming language. Even though you can embed SQL. (You can do this in other languages too). Clicking instead of mostly typing doesn't change this fact. Of course, all of that doesn't matter if you build something quickly and throw it away in a few month. In that case, Retool might actually pay off. But these cases are not the "hard" ones anyways and are usually not a big problem in most companies.

rtpg 5y ago
It seems like a bit of a mistake to look at this like a programming language instead of, say, an information organization tool like Trello. You don't have an IDE for designing process around Trello, you talk to people and figure stuff out that works (so long as it works well enough). I think these kinds of tools fit well in places where process are the big blockers, instead of the technical details (though of course technical details can crawl back up and bite you). (Though I do think what you're saying seems to apply more to Retool relative to more straightforward low-code platforms like Anvil)
- valenterry 5y ago
  If it is not a programming language, you cannot do everything you can possibly think of and you would be restricted. But people _want_ to do what they have in mind, so they will work around the tool in some way. Either by employing a mechanism to still make the tool do what they want (e.g. macros in Excel) or by using another tool that fills the gap. In case 1 you now have the worst of both worlds and in case 2 you now have X tools with all the problems that a zoo of tools brings. If, on the other hand, you _can_ describe every business rule that you can think of in that tool, then it _is_ a programming language. There is no requirement for a programming language to use text. See scratch lang for example.