The article seems to argue against using No Code to develop your core business logic, or to fully replace traditional programming. If that's the delusion, then I agree, I believe No Code should (and maybe will) eat the edges of programming, the boring repetitive CRUD apps, form validation, data integration, ETL, business workflows, data visuaization. If he believes that removing traditional programming from the edges is a delusion, then I don't agree 🙂

Yes, I just read it following a post in HN and then was thinking to post here but saw that it is already done. I agree with @Mariano Guerra about his argument. As a programmer I do see the value to NOT to write code for a certain class of application. It is boring, non productive, and adds little value in each iteration,

I think “no code” has the same misleading value as “serverless”. It’s not “no code” it’s “somone else code”

isn't programming full of someone else's code?

ha-ha, that’s a good point. I wanted to say that you’ll not escape of development with “no code” approach, it’s still there, but in another form

Have we 'escaped' machine code? (Has 'no machine code' been a successful endeavor?)

While there are complex things best expressed through code, I suspect that most code currently written would be unnecessary if it were 1) properly abstracted and reused 2) configuration level details were moved to user control. So most “code” could be “no code”.

I agree with almost everything that article says, except for its conclusion that the problems are unsolvable. I think the author accurately identifies the problems with almost all existing no-code platforms (and those problems are specifically the ones Lynxtool attempts to address). Example: "No-code which is easy enough to be simple fails to be expressive." This is widely true, but I think cause is that no-code systems are usually not extensible within the system, and that to extend them, you must leave the system and write code, or even be at the mercy of the platform developer to provide new features. Most systems' expressiveness stops at the ability to define new functions, or if they express that, they fail to express iteration/repetition. (Lynx addresses this by choosing primitives from programming, rather than the primitives of the problem domain the product is targeted at). WYSIWYG editors and forms have no hope of escaping this limitation— IMO, node-and-wire is the only tool that scales in complexity (i.e. "expressiveness"). I think most "web API glue" products fall into that trap, and that seems to be what the author is calling "configuration over code". He points out that users have a hard time modeling "internal state" in their heads, and I think he's hit onto something extremely crucial there— most code systems expect that of their users. But this isn't an intractable problem— the answer is to show the users the internal state! In fact, most node-and-wire tools do this by allowing the user to probe different parts/stages of the computation and see what's there (and it's what Lynx does). We should not make users simulate code in their heads— that's what computers are for! It should show them the results! He also points out that removing the text doesn't remove the complexity described by the text. This is true, but I think most people underestimate how much of the problem is text for most people. At pixar, where artists work with node-and-wire tools, I've seen them build up insane complexity with nodes. It's the moment they have to write text and mentally simulate things they can't see that they hit a brick wall. Again, this is fixable.

I think people underestimate how much code “non-coders” are writing - Excel macros and markup/HTML for CMS/Wordpress dwarf any other programming language you can think of. I think capitalizing on that trend is much more interesting than what most people mean by “no code.”

HN: https://news.ycombinator.com/item?id=22033827

"no code" sounds weird. code is just a way of signifying meaningful semantics or concepts. regardless of what layer of abstraction or what language you're using to convey those meanings, you still gotta write "code"

I do agree that designing computation with text and with graphical elements belong to a single category of activity (call it "programming", perhaps), but we need some way to refer to the class of tools/activities that do so while eschewing machine grammars, and I'm happy to use the term "no code" for that.

@tbabb fair, point taken

I particulary agree with this part of the conclusion of Alex Hudson:

The sweet spot for me is the “power user”: the user of IT who is extremely adept already, and is probably bending tools beyond their design. Giving them an environment in which to deliver is extremely important, but this should be a joint effort with more technical staff - the two sides should not be in opposition.

I think that we are at a point where we need to blur the frontier between expert programming (i.e. mainly text) and end-user programming (i.e. mainly visual) and make it easy to switch between the two, allowing experts benefit from better visual representations and allowing "power end-users" to tinker with "lower level" programming with text.