Ask HN: What do you think about the no-code movement?

The problem with no-code is it is also usually no-ontology. It's always fun to mock 'ideology', but without a strong philosophical principle, every project will eventually morph into a hairball.

The underlying ontology behind code is, "reduce problems to a normalized form that can be stored in text, which we have gotten good at managing with snapshots and branches in DVCS".

With no-code, you don't have a normalized form to reduce to. Maybe your project is PowerBI modules or Excel-like superspreadsheets or whatever, but the 'stuff' that your project is made out of is not subjectable to the same kind of rigorous management that contemporary codebases tend to adopt.

The two analogies that come to mind are nosql, a movement which rather quickly discovered that RDBMS -- a normalized form for storing and addressing data -- was a pretty good idea, actually, for many use cases.

While NoSQL found important roles to fill, it is by no means as Big a Deal as the breathless tech media made it out to be, back in the aughts when mongodb first dropped.

The other analogy is double-entry bookkeeping. It's been around forever, and while it's not appropriate for every use case, its resilience and ability to represent complex changes in a complex system over time in a normalized way is similar to how a well-maintained codebase is represented by git (and competitors).

Code is a form for representing thoughts about changing systems which change the world in turn. It implies an ontology -- an "ideology", in the popular sense of the term -- and without that scaffolding, projects get floppy.

I'm much more excited about things like Git Copilot. Did you see the demo at Ignite, where that guy was literally just describing in English how he wanted the minecraft bot to behave, and the model wrote the (perfect) Minecraft scripting to make the bot obey?

That, IMO, is the future. Tools that create code that may or may not require tweaking, but can be still be committed to a repo, and is still something whose provenance and behaviour you can reason about, and diff-view when it changes.

Now, making the resulting code provably correct in a quick, automated way is probably the next thing I'd work on if I was in charge of Copilot development. But this will probably require changes to the languages that people use.

"Here is the code that does the thing you verbalized in English, here it is deployed, and also, here are several proofs, including a formal proof, the code does what is intended."

(Another advance I'd like to see are AST-based DVCS, rather than text diffs, but that is a story for another monologue)

[EDIT: I should mention that I happen to work at the specific Big Tech Company that makes Copilot; however, I work nowhere near the team that made it, and my opinions are emphatically my own.]

I've tried this with my current company, where the majority is not tech savy. The business analysts had immense difficulty in creating and maintaining automations on their own. And it gets worse: the few devs that we have at the company had to "rescue" the no-code automations on a daily basis and ended up rewriting most of them. It takes longer for a dev to create an automation in a no-code platform than by simply writing code for this solution.

Your mileage may vary, but my feeling is that no-code will keep growing in relevance, but it's not there yet on what it claims to do.

>>>> The unhappy path is that you stick with Excel too long and become mired in the world of VBA and advanced formulas and attempts at shared workbooks, and build pseudo-database application-contraptions.

How happy was the "let's just spin up a software project" path?

dang, I missed it, would you mind to PM me?

Its a shift in some ways. Lowers a lot of friction for prototyping and production purposes for plenty of adhoc tools. People think this will help. It does and it will. I've used quite a bit of it and had generally good results. We're only in the early stages even though plenty of tools are a decade old.

But it has limits like everything else. Vendor lock-in is returning similar to the old days of mainframes. But at least this time around the tools are more varied and from different vendors as well as the ability to use one of many languages in most cases.

You can run a bunch of businesses with writing very little code. What they don't seem to include in that no-code advertising blurb is the amount of configuration required for some no-code solutions. Especially integrating each *aaS to the next. That seems trivial but can become quite a project.

The bigger cloud offerings such as AWS create dependencies that might be an issue for a lot of businesses if they try to switch. This includes wanting on-premises solutions for whatever reason instead of the cloud. AWS is more than "hey you can run redis, mysql etc in the cloud". Its constellation of convenience is quite a thing to behold. Gets hard to leave. That's the new variant of the old vendor lock-in strategy: You don't want to leave and it can hurt a lot to do so.

There is also an issue with non-cloud alternatives as inherent to most of the no-code solutions in practical use. Unless of course you have a disaster recovery plan for when your favorite sites go down. We still need to have DR plans even for no-code.

You are ready for the no-code platforms you use to go offline, right?

Haven't mentioned security. Better not forget that either.

No-code means more contract management.