[HN Gopher] In Defense of No-Code's Potential
___________________________________________________________________
In Defense of No-Code's Potential
Author : pgayed
Score : 52 points
Date : 2023-04-22 02:26 UTC (20 hours ago)
(HTM) web link (buttondown.email)
(TXT) w3m dump (buttondown.email)
| narag wrote:
| 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.
| mathgladiator wrote:
| I like this yes code concept. It resonates as I'm building a
| new kind of platform: https://www.adama-platform.com/
| [deleted]
| aatd86 wrote:
| 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.
|
| Give me grokkable code over pithy code everyday.
| shireboy wrote:
| 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.
|
| A guy can dream at least.
| glimmung wrote:
| It's critical, I agree.
|
| 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.
| sisve wrote:
| You should def check out windmill.dev.
|
| 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.
| glimmung wrote:
| 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.
| goplayoutside wrote:
| Power Automate Desktop (PAD) does this, actually.
|
| 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
| LikesPwsh wrote:
| Power Query does the same with its M language.
|
| Recorded steps in the GUI generate code that can be manually
| edited.
| noahjk wrote:
| 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.
| aae42 wrote:
| The article mentions VB6 but I would think Microsoft Access would
| be the much more widely used platform
| SanderNL wrote:
| 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.
| creshal wrote:
| Most of the arguments seem alright enough, but
|
| > 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.
| glimmung wrote:
| Agreed, but to me "native" includes the environment's native
| browser.
| 32gbsd wrote:
| 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.
| mlajtos wrote:
| > Find all of the phone numbers of form 0001234567 in a document
| and convert them to (000) 123-4567
|
| > 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.
| adrianmsmith wrote:
| 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.
| juliendorra wrote:
| 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.
| kwinkunks wrote:
| 100% agree, No Code (and possibly All Code, unfortunately, ha)
| was just a clunky, slow way to do what search-capable chatbots
| can now or will soon do.
| calmlynarczyk wrote:
| 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).
| turtleyacht wrote:
| 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.
| WillAdams wrote:
| 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:
|
| 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.
| samsquire wrote:
| Hi Will,
|
| 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.
| WillAdams wrote:
| 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.
| Dowwie wrote:
| 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.
| peter-m80 wrote:
| Building a flowchart with events and conditions is programming.
| Just a visual domain language.
|
| But harder to maintain. Harder to version and see diffs, harder
| to test....
| dusted wrote:
| 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..
| smitty1e wrote:
| 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?
| RodgerTheGreat wrote:
| 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.
| Kamq wrote:
| > 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.
| glimmung wrote:
| 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/
|
| (edited to add line re. web vs. native)
| sisve wrote:
| 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.
|
| (no affiliation, just a happy user)
| [deleted]
| bitwize wrote:
| > 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.
| ralala wrote:
| 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.
| jerf wrote:
| 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.
| danielvaughn wrote:
| It sounds like what he is proposing is a native Zapier.
| scrumper wrote:
| 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.
| throwaway2847 wrote:
| 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.
| scrumper wrote:
| 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.
___________________________________________________________________
(page generated 2023-04-22 23:02 UTC)