No code fails because its promises "coding" like features. I think it would be more successful if it did not try to be a gateway drug into programming. Its best if it just does its own thing.
It forces business people to think deeply about every detail, which is the very thing they are delegating. If they were good at that, they would be programmers themselves.
> Native
>
> I can see some of the benefits of cloud-based no-code, but then you can’t work with the computer. Ideally it should also “feel” like a native program, too.
That would've made for a good argument in 2000, maybe in 2010, but today? Corporate computers are usually locked down too much to allow installing native programs (and for good reason); while more and more households no longer bother with a full-on computer, relying more and more on phones and tablets.
If you really want to bring no-code in the form of easier automation to the masses, it has to be accessible from a web browser. Especially if has to run regularly to check on things; even among those who still have a desktop, many wouldn't want to keep it running 24/7 nor can necessarily guarantee good enough network connectivity.
I'd really like to see someone get this right, but the problem is we don't seem to know the answer and are asking the wrong question:
>What does an algorithm look like?
Flowcharting and diagramming pre-date computers and used to be popular ways to define software workflows --- why hasn't that directly translated into coding?
The Drakon Editor folks short-circuit this with the idea that the desirable option is always straight down --- is that a viable solution?
The Node Editor folks have solutions which some folks use, but there are also sites filled with literal visual spaghetti code:
It's been the better part of a century since Herman Hesse wrote _The Glass Bead Game_, but the most flexible systems still end up as a wall of text, which can be hard to format, or which one limits to plain text --- all-too few programmers avail themselves of:
I've been using TeX for a long while, and one thing which has frequently struck me is that documents are fundamentally a key-value/markup-content pair and it really should be much easier to to markup and tag documents, and then once they are tagged, changing the appearance should be as simple as swapping out a .css file (which can be achieved in TeX, but requires a bit of effort, though newer documentclasses such as memoir make this much easier), but there doesn't seem to be any sort of effort to stuff a document into a database, re-work it, then get a finished product out.
Jupyter Notebooks seem a step in the right direction, but there's no provision for the appearance AFAIK.
The Famous Article:
> So basically Visual Basic 6. VB6 was great! But we’re not going to get a better VB6 because the economics just aren’t there anymore. As programmers we expect all of our languages to be free and open source, but that’s actually super super weird. Most of the time people try to sell their software for “money”, and the clients with “money” are businesses. VB6 just happened to be released at a time when businesses needed to make desktop applications. Now all the money is in the web applications, so no-code people are selling tools to make web applications.
This is one of my standing questions. In a purportedly capitalist system, why does unfilled demand exist in a market?
The reason that comes to mind is non-capitalist drivers affecting the market. Do we need to address those, or confess that we're less capitalist than the press releases say?
If the expected cost of developing a product is more than the expected profit, capitalists won't invest in the product even if demand exists.
Capitalists are terrible at investing in basic R&D: long-term returns, hazy benefits, hazy costs. Only the fattest and most outrageously profitable corporations have an appetite for it, and it's always the first place to see cuts in a downturn.
Occasionally an artist, a lunatic, an ideologue, or a combination of the above will look beyond the framework of profit and find some other reason for making an economically suboptimal decision. If they succeed, the state of the art is advanced, paving the way for capitalists to crawl out of their previous local maxima and start making copies and minor iterations.
> In a purportedly capitalist system, why does unfilled demand exist in a market?
Because people aren't, generally, willing to pay for things.
The things people are willing to pay for, are pretty well covered. The remaining free things are generally the results of passion projects by the creators. This is going to create very different products than a market driven approach.
I think that makes sense. Because the difficulty and challenge of coding is not so much the code, but the understanding of requirements.
No-Code solves the coding part but you still need to be able to express the requirements, which is difficult for someone who doesn't have the thought process of a coder.
ChatGPT also solves the requirements part in that you can speak in English and be vague and (if you're lucky) it understands what you mean, just as a senior coder might.
And that means that expressing requirements to chatGPT is not easier than expressing them to a human professional. Which is hard. And prone to misunderstanding, re-explanations, back and forth. Formalisms and modelisation have been invented (even before computers, eg. blueprints or paper forms) to simplify expressing requirements and make communication about problems and solution better.
Natural language is a worse way of expressing intent and complex needs that other forms of UIs. It has the benefit of plasticity, but is really bad at discoverability, consistency, least-surprise, recognition vs. recall, and many other important aspect of an effective, leveraging UI.
Spreadsheets get a bad rap, particularly from software developers. However, even as a dev myself, I've always found them to be surprisingly powerful and a great tool for people who can bridge their gap in coding skills using formulas to build data-driven declarative capabilities. It might not be as powerful or performant as SQL or Pandas, but it's rather impressive given that you can do it off-the-shelf within a widely-used application.
I've seen non-technical people build some really cool things off of the back of spreadsheet data using things like AppSheet and Google Looker Studio (not sure why they changed the name from Data Studio). And now with Excel adding a ChatGPT formula and Google Sheets adding their own AI-driven features, power and non-power users alike will be able to really up their capabilities using only plain-language queries without having to devise complex algorithms or formulas (I realize ChatGPT isn't flawless yet).
I would love to introduce Visual Basic for Applications (VBA) as a gateway to software development, but even positive receptiveness to model and simulate requirements is welcome.
If only we could onboard a friction-free process from Excel to git! Some way to configure Github Actions, say, and have them upload their sheet somewhere. #ExcelOps
I think it would be easier then to say, "Here's why a real app would scale better." And they would be 100% behind that.
It doesn't need a defense. It has been recognized since the beginning of computing as playing an important role. University in late 90s early 2000s called it rapid application development. RAD tools have come a long way since then. ChatGPT is being used as a RAD tool with mixed success. I'm optimistic about where it will be in 5 years. Great potential.
That was a good read - liked the balance, and agree with his description of the ideal product, which is very close to mine. I don't need a desktop product, as long as it can run on premises and in the environment's native browser and meets the user's expectations in terms of the UI.
I'd add the option of commercial hosting and support to that list, which led me to Budibase - great product, although in the end I was left feeling "no code - but so many clicks!", although I have not gone back to look at v2. https://budibase.com/
The author might care to take a look at Saltcorn, which is in the "Goldilocks" zone for me - enough of everything, not too much of anything. I should write that up myself. https://saltcorn.com/
You should check out windmill.dev For me it was a breath of fresh air.
It's opensource - so you can self-host. The UI is quick and responsive.
But my favorite part of it is that it centers around code. Other tools like zapier and retool (my experience) and budibase (your experience) are so much many clicks and if you drop down to code (aka the off-ramp) you need to program in a input field.
With windmill you have an LSP and the Monaco editor (the code editor that powers VS Code) and you can have sync to git. So if you like you can sit and program in vscode, but are you doing small changes you can do it in the web gui. So code is "native" to windmill and it feels so nice.
> That’s the potential of no-code: making it easier for people to do more with computers without needing to know how to program.
This is the critical argument against no-code, the one argument omitted from the article: No-code doesn't make programming go away. Any time you have graphical flowchart symbols or whatever specific enough for a computer to execute, you have something isomorphic to a computer programming language. Except it's more difficult to change, maintain, move around, read or edit with different tools, version control, etc. No-code is programming, with extra hassle. And the hardness doesn't go away -- in fact, businesses that adopt no-code tools so their marketers or managers can create automation tasks, tend to throw those tasks over the wall to the software engineers once their original authors find that programming is hard and they have much better things to do with their time than debug flowcharts.
The most important requirement IMO is his last: a clear off ramp. Export to code would be nice, but what I think the market really wants is to go back and forth between a coded and no coded experience. Let me start a quick app in nocode editor, open in code editor to tweak something and add feature I know I can do quicker in code, then let my non-tech coworker adjust as needed, but then I edit in code when he breaks something. And be open source, popular, pluggable, etc like author suggests. All the benefits of no code, all the benefits of code, with no walled garden.
It's not a traditional low-code environment, but I recently played with Codux which has a nice balance of this - at least for me, who doesn't have a lot of React experience.
If you select a set of actions from a "flow" in the PAD low code UI, copy to the clipboard, and paste into a text editor, you'll get the code for the original steps in a language called Robin[1][2], a DSL for Robotic Process Automation.
If you paste a selection of Robin code back into the PAD UI, PAD automatically generates the corresponding low code steps.
Public work on the Robin language appears to have ended in 2021. I seem to recall having read that MS acqui-hired the team and shut down the public-facing side of the project, but I may be misremembering that part.
They center more around code, and then builds app and flows based on the code/scripts you create. It's been a really pleasant experience for me. The first time I looked at the product I did not quite get it. But when I tried it I was hooked. It was not what I expected but what I needed.
You can have your code in git and use vscode and push scripts up to windmill if you like, I do and like it.
You CAN also edit flows and apps from vscode. But I'm quite sure you do not want to - meaning it's JSON you will change and not the underlying svelte scripts.
I actually started using windmill after I described my pref. low-code solution on HN and what I felt was missing and got a response back saying that I was describing windmill.
That looks really interesting, may have some features not in my current toolbox (not sure, don't want to assume I understand their terminology) and seems to check most of the boxes for me - thanks for the pointer, I'll have a play.
The foundation of the "off ramp" to me is an RDBMS - I've been evaluating these tools by pointing them at the same db and working on the same app which has been very illuminating. It might be a bit trivial for HN, but I really should write it up properly somewhere.
Software development is easy, maintenance is challenging. When your system integrates with other systems and you want to make changes, it's critical to understand the details. I doubt people without IT background should be in charge of such processes.
This can superficially sound elitist, but for what it's worth I've seen plenty of conventional programmers, for whom this is their full time job, get this wrong, or spend weeks/months doing the work necessary to get it right. It isn't about the programmers being better people or something, it's really about the idea that you can not in general take something that professionals in their wheelhouse find a hard time doing and hand it off to people doing it part-time with no experience and get the same results.
Locally we're playing with "no code" but we're very much making sure it's "leaf node" sorts of tasks, that consume other services but don't provide them.
I think no-code should probably be contextualized in the context of other professions in the business. Would you take a no-accounting solution and hand it off to the programmers? Simplify away the double-entry bookkeeping (too hard for non-accountants, which, I mean, that's not sarcasm, it's really quite close to the truth), simplify all the accounting details, and then let the programmers run the finance department? What would the expected result be? Why would it be any different if you took a no-lawyer system and handed it off to sales to try to run the legal department?
There's a place for such tools nevertheless. Expense reporting software is essentially a "no accounting" accounting tool, for instance. But you keep it carefully fenced in to where it makes sense, you don't go trying to turn your expense reporting tool into the accounting software for the whole firm. I think no code has a valid place in the business but you need to make sure you're not doing the equivalent of claiming it can run accounting for the whole business.
My not so humble opinion: rather than making no-code tools, improve the usability of the yes-code tools, simplifying them and removing decades of cruft. Start by identifying the silos, including the allegedly open ones. Then, from first priciples, just trace the shorter line from ideas to drawing in the screen. Anything longer than two tokens for a "hello world" is an indictment against any language. If you don't understand that, you're unqualified to create a language.
It's not even about the amount of tokens to be fair.
It's about how easy and how consistent the idioms are.
If we look at frontend js... There is a new framework every other month because no one really found out the most minimal, straight and dumb way, to create a UI.
A couple weeks ago I'd have agreed with this wholeheartedly. The complexity ceiling in particular. But then I found myself having to quickly do a bunch of "creative coding" to come up with some realtime visuals to support a stage show. I auditioned a bunch of things like processing.js, Rust equivalents etc., but also Max/Jitter, TouchDesigner, and something called Isadora. Those latter three are all basically no-code environments for visual and audio programming. They have building blocks like wave generators and dividers and things, they look (to a musician) like a modular synth but it's absolutely programming, and can be at a fairly low level (you find yourself implementing logic gates naturally, for example).
Anyway... I thought I'd struggle without a language to call into but in fact they work really well. I settled on Isadora (on a metric of fastest-time-to-cool-output) and I haven't hit a limit yet.
So my reason for writing all this is that I think, and I know I am rambling here, that domain specificity is an important factor in the success of a low/no code tool. Generality exposes the complexity ceiling.
What's nice about these platforms is that they scale with the complexity you need. You can drop down to Python for scripting operations and UI interfaces in TouchDesigner, GLSL if you want to build your own shader pipelines, etc.
Yes. There's some flexibility in there, though I haven't got enough experience with it yet to see whether that is a way through a ceiling or just a source of additional confusion.
Isadora has GLSL too, and a JS actor which is nice for stuff which gets tedious to patch like a calculation with more than one operator. I have used that one a couple times.
I've always felt the hardest thing is not to write the code to do the thing.. The hardest thing for me has always been to figure out what the thing to do is..
> Step one, take a paragraph of text, any paragraph, and uppercase everything. No catch here, just make it allcaps.
> Step two, find a bunch of friends who don’t know how to program and ask them how they’d do the same thing.
This is so, so true. Even amongst programmers. I've lost count of the number of experienced developers I've seen who go to an online JSON viewer site [0] to parse the server response!
43 comments
[ 4.4 ms ] story [ 57.4 ms ] thread> Native > > I can see some of the benefits of cloud-based no-code, but then you can’t work with the computer. Ideally it should also “feel” like a native program, too.
That would've made for a good argument in 2000, maybe in 2010, but today? Corporate computers are usually locked down too much to allow installing native programs (and for good reason); while more and more households no longer bother with a full-on computer, relying more and more on phones and tablets.
If you really want to bring no-code in the form of easier automation to the masses, it has to be accessible from a web browser. Especially if has to run regularly to check on things; even among those who still have a desktop, many wouldn't want to keep it running 24/7 nor can necessarily guarantee good enough network connectivity.
>What does an algorithm look like?
Flowcharting and diagramming pre-date computers and used to be popular ways to define software workflows --- why hasn't that directly translated into coding?
The Drakon Editor folks short-circuit this with the idea that the desirable option is always straight down --- is that a viable solution?
The Node Editor folks have solutions which some folks use, but there are also sites filled with literal visual spaghetti code:
https://scriptsofanotherdimension.tumblr.com/
It's been the better part of a century since Herman Hesse wrote _The Glass Bead Game_, but the most flexible systems still end up as a wall of text, which can be hard to format, or which one limits to plain text --- all-too few programmers avail themselves of:
http://literateprogramming.com/
One promising development is Nintendo's _Game Builder's Garage_:
https://www.nintendo.com/store/products/game-builder-garage-...
(which when I gifted it to a co-worker's son was described as "This is the greatest game ever!")
These days I mostly do 3D, so have been using BlocksCAD:
https://www.blockscad3d.com/community/users/67750#/?_k=7br97...
and OpenSCAD Graph Editor:
https://github.com/derkork/openscad-graph-editor
I'd love to see a similar tool for making a GUI program.
I am interested in this space. I wrote something I called living documents which is a GUI for composing together behaviours.
There are screenshots here:
https://github.com/samsquire/liveinterface
The idea was that you could create a data model and widgets as easy as embedding them in a document.
Jupyter Notebooks seem a step in the right direction, but there's no provision for the appearance AFAIK.
But harder to maintain. Harder to version and see diffs, harder to test....
This is one of my standing questions. In a purportedly capitalist system, why does unfilled demand exist in a market?
The reason that comes to mind is non-capitalist drivers affecting the market. Do we need to address those, or confess that we're less capitalist than the press releases say?
Capitalists are terrible at investing in basic R&D: long-term returns, hazy benefits, hazy costs. Only the fattest and most outrageously profitable corporations have an appetite for it, and it's always the first place to see cuts in a downturn.
Occasionally an artist, a lunatic, an ideologue, or a combination of the above will look beyond the framework of profit and find some other reason for making an economically suboptimal decision. If they succeed, the state of the art is advanced, paving the way for capitalists to crawl out of their previous local maxima and start making copies and minor iterations.
Because people aren't, generally, willing to pay for things.
The things people are willing to pay for, are pretty well covered. The remaining free things are generally the results of passion projects by the creators. This is going to create very different products than a market driven approach.
> Reorder a photo directory from year/event/photo to event/year/photo
> Check daily on a few airbnbs to see if any lowered their prices
> Sending a PDF on your computer to your kindle via Amazon’s “email the file” thingy
> Check if there’s a Cubs game today to avoid the trains
> Take some structured data and put it into a template
I believe that all these kind of tasks will be fully doable through ChatGPT(-like) assistant.
No-Code solves the coding part but you still need to be able to express the requirements, which is difficult for someone who doesn't have the thought process of a coder.
ChatGPT also solves the requirements part in that you can speak in English and be vague and (if you're lucky) it understands what you mean, just as a senior coder might.
I've seen non-technical people build some really cool things off of the back of spreadsheet data using things like AppSheet and Google Looker Studio (not sure why they changed the name from Data Studio). And now with Excel adding a ChatGPT formula and Google Sheets adding their own AI-driven features, power and non-power users alike will be able to really up their capabilities using only plain-language queries without having to devise complex algorithms or formulas (I realize ChatGPT isn't flawless yet).
If only we could onboard a friction-free process from Excel to git! Some way to configure Github Actions, say, and have them upload their sheet somewhere. #ExcelOps
I think it would be easier then to say, "Here's why a real app would scale better." And they would be 100% behind that.
I'd add the option of commercial hosting and support to that list, which led me to Budibase - great product, although in the end I was left feeling "no code - but so many clicks!", although I have not gone back to look at v2. https://budibase.com/
The author might care to take a look at Saltcorn, which is in the "Goldilocks" zone for me - enough of everything, not too much of anything. I should write that up myself. https://saltcorn.com/
(edited to add line re. web vs. native)
It's opensource - so you can self-host. The UI is quick and responsive.
But my favorite part of it is that it centers around code. Other tools like zapier and retool (my experience) and budibase (your experience) are so much many clicks and if you drop down to code (aka the off-ramp) you need to program in a input field. With windmill you have an LSP and the Monaco editor (the code editor that powers VS Code) and you can have sync to git. So if you like you can sit and program in vscode, but are you doing small changes you can do it in the web gui. So code is "native" to windmill and it feels so nice.
(no affiliation, just a happy user)
This is the critical argument against no-code, the one argument omitted from the article: No-code doesn't make programming go away. Any time you have graphical flowchart symbols or whatever specific enough for a computer to execute, you have something isomorphic to a computer programming language. Except it's more difficult to change, maintain, move around, read or edit with different tools, version control, etc. No-code is programming, with extra hassle. And the hardness doesn't go away -- in fact, businesses that adopt no-code tools so their marketers or managers can create automation tasks, tend to throw those tasks over the wall to the software engineers once their original authors find that programming is hard and they have much better things to do with their time than debug flowcharts.
A guy can dream at least.
I'm happy if the data and its constraints are in a robust RDBMS - OK, Postgres! - that is something I can build on, in parallel potentially.
If you select a set of actions from a "flow" in the PAD low code UI, copy to the clipboard, and paste into a text editor, you'll get the code for the original steps in a language called Robin[1][2], a DSL for Robotic Process Automation.
If you paste a selection of Robin code back into the PAD UI, PAD automatically generates the corresponding low code steps.
Public work on the Robin language appears to have ended in 2021. I seem to recall having read that MS acqui-hired the team and shut down the public-facing side of the project, but I may be misremembering that part.
1. https://web.archive.org/web/20210306173947/https://www.robin...
2. https://gitHub.com/robin-language/robin
Recorded steps in the GUI generate code that can be manually edited.
They center more around code, and then builds app and flows based on the code/scripts you create. It's been a really pleasant experience for me. The first time I looked at the product I did not quite get it. But when I tried it I was hooked. It was not what I expected but what I needed.
You can have your code in git and use vscode and push scripts up to windmill if you like, I do and like it. You CAN also edit flows and apps from vscode. But I'm quite sure you do not want to - meaning it's JSON you will change and not the underlying svelte scripts.
I actually started using windmill after I described my pref. low-code solution on HN and what I felt was missing and got a response back saying that I was describing windmill.
The foundation of the "off ramp" to me is an RDBMS - I've been evaluating these tools by pointing them at the same db and working on the same app which has been very illuminating. It might be a bit trivial for HN, but I really should write it up properly somewhere.
Locally we're playing with "no code" but we're very much making sure it's "leaf node" sorts of tasks, that consume other services but don't provide them.
I think no-code should probably be contextualized in the context of other professions in the business. Would you take a no-accounting solution and hand it off to the programmers? Simplify away the double-entry bookkeeping (too hard for non-accountants, which, I mean, that's not sarcasm, it's really quite close to the truth), simplify all the accounting details, and then let the programmers run the finance department? What would the expected result be? Why would it be any different if you took a no-lawyer system and handed it off to sales to try to run the legal department?
There's a place for such tools nevertheless. Expense reporting software is essentially a "no accounting" accounting tool, for instance. But you keep it carefully fenced in to where it makes sense, you don't go trying to turn your expense reporting tool into the accounting software for the whole firm. I think no code has a valid place in the business but you need to make sure you're not doing the equivalent of claiming it can run accounting for the whole business.
It's about how easy and how consistent the idioms are.
If we look at frontend js... There is a new framework every other month because no one really found out the most minimal, straight and dumb way, to create a UI.
Give me grokkable code over pithy code everyday.
Anyway... I thought I'd struggle without a language to call into but in fact they work really well. I settled on Isadora (on a metric of fastest-time-to-cool-output) and I haven't hit a limit yet.
So my reason for writing all this is that I think, and I know I am rambling here, that domain specificity is an important factor in the success of a low/no code tool. Generality exposes the complexity ceiling.
Isadora has GLSL too, and a JS actor which is nice for stuff which gets tedious to patch like a calculation with more than one operator. I have used that one a couple times.
> Step one, take a paragraph of text, any paragraph, and uppercase everything. No catch here, just make it allcaps.
> Step two, find a bunch of friends who don’t know how to program and ask them how they’d do the same thing.
This is so, so true. Even amongst programmers. I've lost count of the number of experienced developers I've seen who go to an online JSON viewer site [0] to parse the server response!
[0]: https://jsononline.net/json-viewer