5 ms·

What "no code" is really about is "no figuring out the toolchain, deployment, integration with third parties, etc". For actually writing business logic, replac

by s17n 6y ago

What "no code" is really about is "no figuring out the toolchain, deployment, integration with third parties, etc". For actually writing business logic, replacing code with drag and drop logic blocks is... not really helpful to anybody. But with all the crap that programmers actually spend our days dealing with removed from the picture, anybody can write their own business logic, even if they have to do it in gasp code.

capableweb 6y ago
> For actually writing business logic, replacing code with drag and drop logic blocks is... not really helpful to anybody It's not helpful for anybody to be able to write their own services, even if they cannot code? Everyone who can't code, would disagree with you. Sure, they can spend some free time to pickup programming, and maybe after a lot of reading and practicing, would be able to build the flow in a programming language, but why do that when you could just drag and drop logic blocks until it solves your particular problem, then move on to what you really care about?
- UK-Al05 6y ago
  Because drag and dropping blocks is the same difficulty as writing it down just with more steps. The difficulty isn't in writing the code, but specifying exactly what you want to do.
  - capableweb 6y ago
    Yeah, I mean, you're right, it is difficult to specifically know what you want the computer/server to do. But, writing code (as text) is a lot harder for people to do, than to use graphical elements. Why I don't know, maybe it's just more daunting to get started. But people have an easier time pickup "programming" via blocks rather than text.
    - lmm 6y ago
      In my experience that's not actually true. People might be able to drop some graphical elements into place, but they can't fix bugs in their "programs".
- Nursie 6y ago
  Eventually, there's almost always a need for some edge case, some scenario not quite covered by the no-code framework, and you're back to writing code, even if it's sold as not actually coding.
  - capableweb 6y ago
    I'd agree that of course "real" programming is gonna be able to cover a lot more cases than "building blocks" programming can ever cover. A bit like comparing only using libraries vs writing your own code, can get you far but will never allow you to do anything. > and you're back to writing code My point was more geared towards the people who can't write code. So this is not really an alternative for them. So something imperfect that kind of does what you need, in most cases, is most of the times better than nothing. I don't think anyone is selling "no code" as a solution that works for everything and any case. But it does work for a lot, so us "real" programmers can stop implementing the same boilerplate over and over, and people who can't program, can build automated workflows for themselves, which is nice.
    - Nursie 6y ago
      It's a nice dream, I'm not opposed to it in principle. However the systems I've seen from vendors pushing (for instance) "no code" data permissions rules on top of an identity database, have quickly shown their rough edges and the need for custom building blocks backed by code (or worse, XML pretending not to be code!). Maybe it's getting better than this now.
tluyben2 6y ago
> is "no figuring out the toolchain, deployment, integration with third parties, etc". Yep and programmers are terrible at delivering that: I do believe a lot of people like setting up their environments, running updates and fixing their code while nothing in the business logic was changed. I find it by far the most annoying part of modern programming; I want to build a product that adds to the bottomline; not figure out whatever I need to set up to get that done. After the set up, we do not need drag and drop or whatever; just code is fine, but can we just please skip any and all of the setup by default (you can change it if you require ofcourse!), while it being ready and secure for production, by default? That is what these no code tools do well: I can just start making datamodels, business logic and connections instead of worrying what crucial npm updates will break my code today. Edit: Also when I run the npm i module no code equivalent (pressing add plugin/module or something), it will immediately work; no 90 page setup document of ‘integrating’ things in my application. Sure the flexibility!!! But why are we (me included) so incredibly bad a sane and ‘just works after install’ defaults? I still think, as said above, that people must like this busywork, otherwise you would expect more complaining? I do know many freelancers (paid per hr) and many people under contract indeed like that work: it is a nice distraction from thinking about logic and it takes time (a lot of time sometimes), but I cannot believe people really would prefer it over taking a walk outside instead?
RNCTX 6y ago
> For actually writing business logic, replacing code with drag and drop logic blocks is... not really helpful to anybody. It occurred to me once that for the typical front end dev, there are 4 data types being dealt with, disregarding individual chars which don't have a whole lot of use on the internet at large. Now, someone who is using a framework of a framework is going through AT LEAST 4 translations. High level framework -> low level framework -> javascript -> machine code via the runtime. 4 data types, 4 languages. Just in the UI, not even talking about the server and the database. Perhaps the trend is a reaction to poor language and framework design...

by s17n 6y ago

capableweb 6y ago

> For actually writing business logic, replacing code with drag and drop logic blocks is... not really helpful to anybody It's not helpful for anybody to be able to write their own services, even if they cannot code? Everyone who can't code, would disagree with you. Sure, they can spend some free time to pickup programming, and maybe after a lot of reading and practicing, would be able to build the flow in a programming language, but why do that when you could just drag and drop logic blocks until it solves your particular problem, then move on to what you really care about?

UK-Al05 6y ago
Because drag and dropping blocks is the same difficulty as writing it down just with more steps. The difficulty isn't in writing the code, but specifying exactly what you want to do.
- capableweb 6y ago
  Yeah, I mean, you're right, it is difficult to specifically know what you want the computer/server to do. But, writing code (as text) is a lot harder for people to do, than to use graphical elements. Why I don't know, maybe it's just more daunting to get started. But people have an easier time pickup "programming" via blocks rather than text.
  - lmm 6y ago
    In my experience that's not actually true. People might be able to drop some graphical elements into place, but they can't fix bugs in their "programs".
Nursie 6y ago
Eventually, there's almost always a need for some edge case, some scenario not quite covered by the no-code framework, and you're back to writing code, even if it's sold as not actually coding.
- capableweb 6y ago
  I'd agree that of course "real" programming is gonna be able to cover a lot more cases than "building blocks" programming can ever cover. A bit like comparing only using libraries vs writing your own code, can get you far but will never allow you to do anything. > and you're back to writing code My point was more geared towards the people who can't write code. So this is not really an alternative for them. So something imperfect that kind of does what you need, in most cases, is most of the times better than nothing. I don't think anyone is selling "no code" as a solution that works for everything and any case. But it does work for a lot, so us "real" programmers can stop implementing the same boilerplate over and over, and people who can't program, can build automated workflows for themselves, which is nice.
  - Nursie 6y ago
    It's a nice dream, I'm not opposed to it in principle. However the systems I've seen from vendors pushing (for instance) "no code" data permissions rules on top of an identity database, have quickly shown their rough edges and the need for custom building blocks backed by code (or worse, XML pretending not to be code!). Maybe it's getting better than this now.

tluyben2 6y ago

> is "no figuring out the toolchain, deployment, integration with third parties, etc". Yep and programmers are terrible at delivering that: I do believe a lot of people like setting up their environments, running updates and fixing their code while nothing in the business logic was changed. I find it by far the most annoying part of modern programming; I want to build a product that adds to the bottomline; not figure out whatever I need to set up to get that done. After the set up, we do not need drag and drop or whatever; just code is fine, but can we just please skip any and all of the setup by default (you can change it if you require ofcourse!), while it being ready and secure for production, by default? That is what these no code tools do well: I can just start making datamodels, business logic and connections instead of worrying what crucial npm updates will break my code today. Edit: Also when I run the npm i module no code equivalent (pressing add plugin/module or something), it will immediately work; no 90 page setup document of ‘integrating’ things in my application. Sure the flexibility!!! But why are we (me included) so incredibly bad a sane and ‘just works after install’ defaults? I still think, as said above, that people must like this busywork, otherwise you would expect more complaining? I do know many freelancers (paid per hr) and many people under contract indeed like that work: it is a nice distraction from thinking about logic and it takes time (a lot of time sometimes), but I cannot believe people really would prefer it over taking a walk outside instead?

RNCTX 6y ago

> For actually writing business logic, replacing code with drag and drop logic blocks is... not really helpful to anybody. It occurred to me once that for the typical front end dev, there are 4 data types being dealt with, disregarding individual chars which don't have a whole lot of use on the internet at large. Now, someone who is using a framework of a framework is going through AT LEAST 4 translations. High level framework -> low level framework -> javascript -> machine code via the runtime. 4 data types, 4 languages. Just in the UI, not even talking about the server and the database. Perhaps the trend is a reaction to poor language and framework design...