3 ms·

We actually need "Just Code" tooling. The No Code movements shines a light on how bad we let things become for programmers (and aspiring ones). Building a mode

We actually need "Just Code" tooling. The No Code movements shines a light on how bad we let things become for programmers (and aspiring ones). Building a modern full-stack website these days involves a lot of knowledge, everything from docker to react, to how to use github, npm, vscode, the command line, etc. No Code/Low Code recognizes that most of that is "accidental complexity", and removes it. In a sense, it really lets you focus on the actual program (the "essential complexity"), in a way that "real" coding does not. The problem with No Code is that "code" is actually important, by which I mean functions and types and values. Things that are composable and decomposable - you can look under the covers and there's more code, or you can combine two things together to make a bigger thing. That's as opposed to "wizards", which many (not all) No Code tools are. We can remove the accidental complexity without removing the code though. I've been referring to this idea as "Just Code", and there's a bunch of tools out there which fit the bill: Darklang (disclaimer: I work on this), Glitch, and Repl.it are the ones I know best.

dustingetz 5y ago
lambda (userland abstraction creation) is the essential capability difference between full-code and low/no code. it raises an interesting question, what is the customer value prop of abstraction creation? most products’ value props are about providing a toolkit of prebuilt abstractions OOTB so the user can just solve their problem using the same patterns as everyone else. The user doesn’t want to build new patterns. Composition is about wiring and glue code, there are more accessible ways to solve wiring than userland lambda.
chubot 5y ago
I like this framing ... But I'll also frame my own project relative to that The vision for Oil (https://www.oilshell.org/ https://www.oilshell.org/) is "Just code" + "Just shell", i.e. one other language for "control plane" / configuration / automation. That is, Oil puts all the "glue", which is often YAML these days, under the category of "shell". (This requires adding features to shell, i.e. "the missing declarative part".) The status quo YAML often contains shell, and is sometimes generated by Go templates when logic is needed, so "Just Shell" is simpler. So I basically agree with you that "No code" is ambitious for most problems -- "Just Code" can be better and handles a wider range of problems. But I also think "Just code" is ambitious. Because what do you do about load balancing policies, scheduling policies, authorization policies (collaboration), SSL certificates, backup policies, deployment, build, tests, performance, monitoring, etc. You can try to make it all "data", and that certainly works for many simple apps. But when simple apps are successful (have many users), they turn into complex apps that need control flow, iteration, and abstraction in their control plane, configuration, and custom tooling. In other words, the plain YAML basically never cuts it, which is why you see shell embedded in it, why Go templates generate it, and why people create Lisp-ish languages in YAML (e.g. look at Gitlab / Github CI conditional expressions in YAML; Kubernetes YAML has sequencing and more) Otherwise you get a combinatorial explosion of hard-coded policies in the platform, i.e. a little YAML flag to specify a hard-coded algorithm for every piece of policy that any user could possibly want. Platforms have a lot of heterogeneity their usage patterns, i.e. a power law shape with respect to almost every dimension.
jeremy_daly 5y ago
> We actually need "Just Code" tooling. Totally agree with this, and this is what we're doing with Serverless Cloud (which I work on). Developers (generally) want to write code, but having to implement the same boilerplate or cloud infrastructure configurations over and over, or wire together cloud primitives every time to build a solved use case, is both inefficient and prone to human error. Baking most of this into a platform, and then letting developers just write business logic is a powerful abstraction.

dustingetz 5y ago

lambda (userland abstraction creation) is the essential capability difference between full-code and low/no code. it raises an interesting question, what is the customer value prop of abstraction creation? most products’ value props are about providing a toolkit of prebuilt abstractions OOTB so the user can just solve their problem using the same patterns as everyone else. The user doesn’t want to build new patterns. Composition is about wiring and glue code, there are more accessible ways to solve wiring than userland lambda.

chubot 5y ago

I like this framing ... But I'll also frame my own project relative to that The vision for Oil (https://www.oilshell.org/ https://www.oilshell.org/) is "Just code" + "Just shell", i.e. one other language for "control plane" / configuration / automation. That is, Oil puts all the "glue", which is often YAML these days, under the category of "shell". (This requires adding features to shell, i.e. "the missing declarative part".) The status quo YAML often contains shell, and is sometimes generated by Go templates when logic is needed, so "Just Shell" is simpler. So I basically agree with you that "No code" is ambitious for most problems -- "Just Code" can be better and handles a wider range of problems. But I also think "Just code" is ambitious. Because what do you do about load balancing policies, scheduling policies, authorization policies (collaboration), SSL certificates, backup policies, deployment, build, tests, performance, monitoring, etc. You can try to make it all "data", and that certainly works for many simple apps. But when simple apps are successful (have many users), they turn into complex apps that need control flow, iteration, and abstraction in their control plane, configuration, and custom tooling. In other words, the plain YAML basically never cuts it, which is why you see shell embedded in it, why Go templates generate it, and why people create Lisp-ish languages in YAML (e.g. look at Gitlab / Github CI conditional expressions in YAML; Kubernetes YAML has sequencing and more) Otherwise you get a combinatorial explosion of hard-coded policies in the platform, i.e. a little YAML flag to specify a hard-coded algorithm for every piece of policy that any user could possibly want. Platforms have a lot of heterogeneity their usage patterns, i.e. a power law shape with respect to almost every dimension.

jeremy_daly 5y ago

> We actually need "Just Code" tooling. Totally agree with this, and this is what we're doing with Serverless Cloud (which I work on). Developers (generally) want to write code, but having to implement the same boilerplate or cloud infrastructure configurations over and over, or wire together cloud primitives every time to build a solved use case, is both inefficient and prone to human error. Baking most of this into a platform, and then letting developers just write business logic is a powerful abstraction.