Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The “No Code” Delusion

alexhudson.com

Post reply on HN
Print view View original

111–120 of 334 posts

Re: The “No Code” Delusion

#111

Post by solatic »

toyg wrote: post #102
solatic wrote: post #88

Earlier quoted context omitted.

> General purpose programing languages are getting more expressive by the day You know, once upon a time, we understood that declarative approaches to software engineering were superior to imperative approaches, when declarative approaches are feasible. Declarative approaches are much safer and easier to test, at a cost of only being able to express what the tool accepting the declarative approach can understand. Imp…

That's a bit of a no-true-scotsman there. If the problem is just the markup of choice, we should see an alternative markup emerging any time now. If we see imperative-focused tools instead, maybe it's not just about the markup.

We do see alternative "markups", if you want to call them that, emerging that solve the generative issues - the two that come to mind are Dhall and CUE. They bring forth JSON to help them interoperate and be relevant in a world that predominately expects JSON/YAML, but they can also be read directly.

Re: The “No Code” Delusion

#112

Post by satyrnein »

While everyone is right that a "no code" platform cannot replace all developers, if you take away the extreme framing, there is an interesting trend occurring. These days, business power users can accomplish a lot with tools like Excel (this one was always true), Google Forms, Salesforce, Airtable, Looker, and so on. People can define entities, custom fields, workflows, reports... things that used to be feature requests for developers.

Of course, many developers have had the experience of having to come in and deal with some insane Excel spreadsheets, but many of us have also been called into deal with crazy legacy systems built by professional developers. That itself is not an indictment.

As these tools grow, presenting new and lower cost ways of getting a certain class of activities done, I think we would be well served to figure out how to play nicely with these tools. (It's not like we want to spend our time building custom CRUD apps anyway.)

Re: The “No Code” Delusion

#113

Post by solatic »

UserIsUnused wrote: post #89
solatic wrote: post #88

Earlier quoted context omitted.

> General purpose programing languages are getting more expressive by the day You know, once upon a time, we understood that declarative approaches to software engineering were superior to imperative approaches, when declarative approaches are feasible. Declarative approaches are much safer and easier to test, at a cost of only being able to express what the tool accepting the declarative approach can understand. Imp…

There are declarative general purpose programing languages. That data you are talking about does need to be debugged, like Helm charts and pipeline definitions. Sure data is better, but config is code, not data.

Generators need to be debugged, not data. It's very easy to test a generator - a few unit tests checking whether, for a given input, the generator produced the expected output, and you're set. Data sometimes needs to be cleaned, but there's no such thing as a bug in data.

Whether the generated declarative output produces the expected behavior on the part of the tool interpreting the declarative output is part of the tool's contract, not the generator or the declarative output. If you need to check the tool's behavior then either a) you wrote the tool or b) you're writing an acceptance test for the tool, which is an entirely different endeavor.

Re: The “No Code” Delusion

#114

Post by satyrnein »

ebiester wrote: post #86
cm2012 wrote: post #68

Earlier quoted context omitted.

I can train one of my juniors in how zapier works in an afternoon. Teaching them (or myself) a programming language would take years and be more error prone.

I can teach IF, FOR, and the basics of python in a week. I can teach ruby in about the same. For what they are going to need for a low code solution, that's enough. You don't need to teach all of programming - only a subset that would be covered in a low/no code solution. If you don't believe this, look at how many non-CS professionals have learned VBA as their excel-fu reached a limit. Even if it's not clean to star…

I think you might be underestimating what these tools can do. I'm not the person you're replying to, but I have also seen a junior marketing person create a Web form to be sent to clients (using Jotform or similar), have it output to a Google sheet, have Zapier pick it up and move it to Airtable, where he defined a bunch of extra fields for internal staff to annotate the submissions, all while getting notifications when certain conditions were met.

Not only could he not learn enough python in a week to do this, but the professional developers on my team could not do this in a week.

Re: The “No Code” Delusion

#115

Post by commandlinefan »

davidpolberger wrote: post #71

No-node app builders are certainly no panacea, and I say that as a co-founder of an app builder (Calcapp). However, if your requirements fall into a domain that is common enough that no-code tools exist, people who don't consider themselves developers can often get a solution in place remarkably quickly. Database apps (CRUD) appear to be the target of most no-code products -- define your tables, build your user inter…

> if your requirements fall into a domain that is common enough that no-code tools exist,

… then you can quickly and easily, with very little cost, produce something that anybody else can quickly and easily, with very little cost, produce. Try not to be too surprised when it doesn’t turn out to be particularly valuable or helpful.

Re: The “No Code” Delusion

#116

Post by UserIsUnused »

solatic wrote: post #113
UserIsUnused wrote: post #89

Earlier quoted context omitted.

There are declarative general purpose programing languages. That data you are talking about does need to be debugged, like Helm charts and pipeline definitions. Sure data is better, but config is code, not data.

Generators need to be debugged, not data. It's very easy to test a generator - a few unit tests checking whether, for a given input, the generator produced the expected output, and you're set. Data sometimes needs to be cleaned, but there's no such thing as a bug in data. Whether the generated declarative output produces the expected behavior on the part of the tool interpreting the declarative output is part of the…

Things like pipeline definitions and helm charts are generators.

Re: The “No Code” Delusion

#117

Post by solatic »

UserIsUnused wrote: post #116
solatic wrote: post #113

Earlier quoted context omitted.

Generators need to be debugged, not data. It's very easy to test a generator - a few unit tests checking whether, for a given input, the generator produced the expected output, and you're set. Data sometimes needs to be cleaned, but there's no such thing as a bug in data. Whether the generated declarative output produces the expected behavior on the part of the tool interpreting the declarative output is part of the…

Things like pipeline definitions and helm charts are generators.

No, Helm uses charts (data) to generate object definitions (in YAML). Helm is the generator.

There's nothing that prevents you from writing a unit test that runs `helm template` directly to check whether a given chart with given values will produce a given set of YAML files.

Re: The “No Code” Delusion

#118

Post by kaikoenig »

I think no code has its place. I view that as a step/experiment towards a common "language/notation" to describe how a business interacts with its surroundings that is not Java or the likes. Will be really interesting to see where this all leads or if it blows over.

BTW - of course we are also build such a thing at Bitspark - https://bitspark.de/slang/ or https://github.com/bitspark/slang

Re: The “No Code” Delusion

#119

Post by ivansavz »

> “No Code” systems are extremely good for putting together proofs-of-concept which can demonstrate the value of moving forward with development.

Another positive aspect is the ability to teach junior coders. One of the coolest things on that front is MIT App Inventor https://appinventor.mit.edu/ — a webapp for creating Android apps using Blockly-style blocks, see screenshot here here https://appinventor.mit.edu/explore/designer-blocks#blocks

I was super surprised to see middle-school kids building real .apk and running on their phone.

Re: The “No Code” Delusion

#120

Post by Piskvorrr »

satyrnein wrote: post #114
ebiester wrote: post #86

Earlier quoted context omitted.

I can teach IF, FOR, and the basics of python in a week. I can teach ruby in about the same. For what they are going to need for a low code solution, that's enough. You don't need to teach all of programming - only a subset that would be covered in a low/no code solution. If you don't believe this, look at how many non-CS professionals have learned VBA as their excel-fu reached a limit. Even if it's not clean to star…

I think you might be underestimating what these tools can do. I'm not the person you're replying to, but I have also seen a junior marketing person create a Web form to be sent to clients (using Jotform or similar), have it output to a Google sheet, have Zapier pick it up and move it to Airtable, where he defined a bunch of extra fields for internal staff to annotate the submissions, all while getting notifications w…

This actually feels very unixish. `form | sheet; crontab: zapier | airtable`. Simple tools that can be simply combined - I feel similar about Tasker, where I can combine various building blocks without worrying about compiling an app. (It does get cumbersome without an IDE)
Post reply on HN