[HN Gopher] Low-Code Programming Models
___________________________________________________________________
Low-Code Programming Models
Author : mitchbob
Score : 80 points
Date : 2023-09-29 16:25 UTC (6 hours ago)
(HTM) web link (cacm.acm.org)
(TXT) w3m dump (cacm.acm.org)
| runningmike wrote:
| Low or nocode is imho not the holy grail for solving business IT
| problems. Low code or mda like tools have since 1980 be promoted
| using several names. have, e.g.:
|
| Low code tooling No code tooling Model Driven Engineering (MDE)
| Model Driven Design (MDD) 4GL tools
|
| Low code tools are not strong on versioning and dealing with
| multiple parallel development tracks and teams simultaneously.
| Most tools are in fact based on a big design upfront paradigm,
| like an overall data model. Versioning on models, meta data and
| data of all created and generated software assets is poorly
| supported, if supported at all. Common practices seen in mature
| agile software development tools using micro services paradigms
| and advanced distributed version control systems are often
| lacking in the new low-code MDA family of tools. In large
| companies it is not uncommon to encounter models with hundreds
| (or even thousands) of entities / classes. That kind of models
| not only doesn't help with developing software faster and more
| cost-efficiently but even has an adverse effect.
|
| Low code tools have a strong focus on initial productivity gain.
| But a continuous fast changing business context with changing
| requirements requires an approach and toolset that is suited for
| giving long term productivity benefits.
| eschneider wrote:
| > Low code tools have a strong focus on initial productivity
| gain. But a continuous fast changing business context with
| changing requirements requires an approach and toolset that is
| suited for giving long term productivity benefits.
|
| The best "low code" tools absolutely meet this requirement and
| best of all, don't _feel_ like programming to the users.
| Spreadsheets are the most obvious example.
| wizofaus wrote:
| If ChatGPT is gonna disrupt any technology you'd think it might
| be low code platforms.
| rangledangle wrote:
| It's really sad, because almost all of these platforms are
| code-averse. They sell the idea that "code is the hard part".
| Business folk eat it up.
|
| Then you sit there like an idiot dragging blocks around when
| you could have just asked GPT to bust it out in code in
| seconds.
|
| They're so bad for source control and documentation, too.
| wizofaus wrote:
| Sure but if it's just ChatGPT spitting out code that the
| users don't really understand I can't see it being a workable
| solution either. What I'm thinking is that low-code implies
| something like natural language pseudo code that LLM tech is
| able to accurately interpret and turn into executable code.
| Of course the "accurately" part is still something of an
| issue, but usually with a few rounds of "no that didn't work"
| or "that's not what I meant" you can likely get what you
| actually intended.
| sremani wrote:
| Low Code suffers from same problems DSLs suffer from. You need to
| nail the abstractions down to be proficient in getting systems up
| and RUNNING.
| mlhpdx wrote:
| I have been doing a lot of work with AWS StepFunctions lately,
| everything from replacing cron jobs to implementing HTMX
| backends. I think StepFunctions is an interesting case study (I'm
| not really familiar with other offerings, other than spending
| some time with the block-based programming like Scratch and
| MakeCode).
|
| To build solutions I have to use the Amazon States Language,
| which is a learning curve and being as charitable as I can a
| royal pain in the ass. Ultimately I end up with a JSON file that
| is a "giant, flexible config file" for their runtime.
|
| On the plus side, solutions using it are very nearly zero
| maintenance. No runtime updates, no package updates, no manual
| scaling, etc.
|
| Another plus, it's zero cost when not in use. No VMs I have to
| pay for hourly or monthly.
|
| The downsides (for me) are obvious: It's difficult to learn; It's
| very restrictive, and solutions often end-up needing some aspect
| of more flexible services like Lambda or Fargate (containers)
| when end-up adding cost and maintenance; It's proprietary and
| there is nothing I can use elsewhere (no other company support
| ASL as far as I know).
|
| Overall, though, I love it. Why? I despise having to choose
| between unpatched systems and the drudgery of constant patching.
| With StepFuctions I don't have to choose.
| rangledangle wrote:
| I was so stoked to build stuff this way; I had the same
| sentiments about the learning curve, but overall it seemed like
| an amazing tool and pretty fun.
|
| The problem is the people around me thought it was too
| difficult, and couldn't see long term. So we implemented a low
| code solution and now everything is in there and it's a
| mess/nightmare. I hate my work now, and everything we build is
| tightly coupled to this spaghetti platform that will inevitably
| decide to raise it's prices on us and we will have no recourse.
|
| Job hunting has been tough too, because very few places have
| done this, so they ask "what have you been working on?" and I'm
| basically setting record times for ending interviews if I tell
| the truth.
| TekMol wrote:
| The problem with low-code is the same as with outsourcing code on
| UpWork:
|
| Security
|
| You get something that works. But how do you know there is no way
| to:
|
| 1: Alter the code from the outside
|
| 2: Access parts of the DB one is not supposed to access
|
| Those can only be avoided by a programmer who knows about all the
| weird edge cases that might lead to 1 or 2 and how to write a
| complex system in a way that is structured to make bugs unlikely.
| wonderwonder wrote:
| A good low code platform will account for this and have role
| and access management baked in
| icoder wrote:
| I guess this can be said about your entire stack, OS,
| webserver, used libraries, etc.
| Jtsummers wrote:
| (2) is not a particular issue with low-code, it's just a
| problem for everyone. I'm in a "high-code" environment and they
| still managed to fuck up data access controls. You have to
| bring on people (or give them authority) who understand how to
| secure your data. Afterwards, high-code or low-code you're
| going to be ok (maybe not great, but ok).
| dang wrote:
| There was a watercooler-style thread about this yesterday:
|
| _Tell HN: Enterprises spend 10x more to build no-code solutions
| than coded ones_ - https://news.ycombinator.com/item?id=37689282
| - Sept 2023 (178 comments)
|
| But the current article is quite substantive so we won't treat it
| as a follow-up the way we normally probably would (https://hn.alg
| olia.com/?dateRange=all&page=0&prefix=true&que...).
| hcarvalhoalves wrote:
| I'm currently using a low-code tool for prototyping an app [1]
| together with a team that has no professional software engineers
| (although there are researchers capable of programming in
| Python/R).
|
| I found the tool super easy to use and we managed to have a
| functional app in one afternoon, but when they tried to use it
| themselves it wasn't as intuitive - the tool works best if you
| already posses some intuition of relational model, CRUD patterns,
| etc. Without this intuition the other members were having a hard
| time understanding how to better structure the data for the app,
| and started trying to "hack" it to make the app work the way they
| expected instead of working with the abstractions available.
|
| [1] http://appsheet.com
| RajT88 wrote:
| > Low-code enables domain experts to become citizen developers.
|
| I have yet to see a single "citizen developer" successfully
| building stuff using low-code/no-code solutions.*
|
| > At the same time, low-code platforms should also strive to make
| pro-developers (professionals with an education or career in
| software development) more productive.
|
| This is mostly what I see.
|
| Occasionally, I see real developers sticking with the low-
| code/no-code solutions far beyond what it should ever be used
| for, to the detriment of the product.
|
| What I do see a lot of is people with a long history in the
| business aspect being brought in as program managers, QA testers,
| UI designers, etc. They are generally very successful in those
| areas.
|
| *VB6 and Visual FoxPro I have seen business people building
| production apps with. You may not consider those to be "real"
| low-code/no-code solutions, but... I've seen business people
| teaching themselves those to build their own stuff.
| threatofrain wrote:
| I've seen designers build pretty good websites without touching
| code.
| sarchertech wrote:
| My mom was building pretty good websites in dreamweaver
| nearly 25 years ago without touching code.
|
| As soon as something went wrong though--watch out.
| RajT88 wrote:
| Exactly the problem with low code tools. As soon as you
| have a small deviation from the framework (be it an issue
| or just a wonky requirement) you are stuck.
| amilios wrote:
| Not sure if this counts, but many successful games have been
| made with Game-maker-style tools, which I think would be
| classified as "low-code". E.g. Undertale
| Karrot_Kream wrote:
| Excel sheets and now Airtable bases are another way to build
| apps I see pretty often. The problem is when these things
| outgrow their original platforms there's a huge step in effort
| up from "simplify the formula/query" to "ingest all the data
| into a database then write a view on top". My own wish for low-
| code tools is to cross this chasm.
| rahkiin wrote:
| I am considering/designing/PoCing implementing a low-code (visual
| programming like Unreal) system for a specialized ETL
| (algorithmic) system. Both E and L would be nodes and the target
| audience mostly uses math in the T.
|
| Great advantage seems to be an ability to schedule jobs based on
| algorithm needs, as everything is known in the graph. I also
| think we can give some guarantees like infinite loop prevention
| by analysing the graph. An alternative I see is a textual DSL
| which may be even more work to implement and user discovery
| becomes harder.
|
| I'd love to talk and discuss about this with others; it is hard
| for me to determine whether this is the way to go with so many
| opinions in either camp.
| zubairq wrote:
| I remember after coding in C++ for 5 years and then doing Java
| and thinking it was like low code as java was so easy because of
| the memory management and gc
| danielvaughn wrote:
| I've long been interested in low-code, because it's one of those
| things where the benefits _seem_ obvious, but become less obvious
| the more you think about it.
|
| In some cases the benefits are plain to see. For instance, if you
| needed to represent a squiggly line in SVG, the natural movement
| of a user's hand guiding a digital pencil is going to be far
| superior than writing out each x/y position in a vector path.
|
| But other use cases aren't so clear, and in fact, many tasks
| could be made far more efficient with a textual interface.
|
| I think the reason people assume that code is time-consuming or
| complex, is because historically it's been used to solve complex
| problems that non-technical users don't understand. So in other
| words, they don't understand the problem domain. My theory is
| that if they understood the problem domain, then they could
| understand any formal syntax dedicated to the domain.
|
| As an example, the following pseudo-code: begin
| dishwashing: gather(plates) sink.load(plates)
| each plate(rinse) each plate(dishwasher.load)
| dishwasher.on() end dishwashing
|
| Everyone understands the problem domain (how to wash dishes), so
| even though someone may be unfamiliar with historical programming
| conventions and syntax, they should be able to grasp what the
| code does.
|
| It's something I'm exploring with this language I've been
| building called Matry: https://matry.design.
| badtension wrote:
| Tangentially I want to mention that rinsing dishes before
| running the dishwasher is a known anti-pattern. The first
| washing cycle is exactly that - a rinsing cycle. I know this is
| off-topic but saving water is always a good idea.
|
| In my experience visual tools like RoseRT can quickly turn into
| an obstacle. I think it's super important to not only know what
| the non-code solutions may be good at but also keep the
| solution limited or at least be prepared to go back to code if
| the problem domain is complex enough.
| replwoacause wrote:
| Not according to the condescending maintenance guy who was
| replacing my broken dishwasher at the apartment I lived at
| years ago. You should have been there for THAT lecture.
| badtension wrote:
| Just nod and smile.
| vector_spaces wrote:
| I'm always rubbed the wrong way by folks showing up with a
| "well, actually" over this point about dishwashers because
| this advice only holds in general if you're using a recent
| model, which not everyone can afford -- in fact, probably
| most people can't, so it becomes a question of accessibility.
| True, it would reduce your costs over the long run to use
| something more efficient -- but one of the insidious
| realities of being poor is that you can't afford to think
| long-term. If it's between paying my rent this month, and
| maybe saving an extra $15/month over the long term, sorry,
| but I'm going to make sure there's a roof over my head.
|
| So if you're like me and have always lived in rentals with
| older model dishwashers for much of your life, and find
| yourself going crazy reading advice like this all over the
| internet despite making sure the filter trap is clean and
| taking full advantage of dishwasher pre-rinse cycles and even
| adjusting the temperature on your water heater and
| experimenting with different detergents, don't feel too bad
| -- dishwashers become less efficient over time for the most
| part, and hand-rinsing beforehand becomes a necessity. So go
| ahead and hand-rinse beforehand if you need to. It's not an
| anti-pattern unless you have a newer model.
| dragonwriter wrote:
| Even with a fairly recent model I've occasionally had food
| debris from un-pre-rinsed dishes redeposited (and firmly
| so, with a heated dry cycle) on _other_ dishes.
| badtension wrote:
| I've been washing dishes by hand my whole life and just
| recently got a dishwasher. When washing by hand pre-rinsing
| and soaking is essential so I kept doing that even after
| getting the machine, only recently discovering that I am
| wasting water this way.
|
| Thanks for the tip about the old dishwashers.
| sorokod wrote:
| >one of the insidious realities of being poor is that you
| can't afford to think long-term
|
| aka Sam Vimes "Boots" theory
|
| https://en.m.wikipedia.org/wiki/Boots_theory
| WalterBright wrote:
| There's a bug in it. Forgot to add detergent :-)
| danielvaughn wrote:
| I love that HN has pointed out two bugs in my trivial made-up
| example, lol.
| WalterBright wrote:
| If you hadn't made the code self-evident, I wouldn't have
| found the bug!
| OkayPhysicist wrote:
| The key problem that creates "low" or "no" code products is a
| pattern that shows up in a lot of technical fields: non-
| technical people run into the first hurdle, and assume it
| represents the majority of the difficulty. In software, this is
| sourcecode syntax. Somebody who's never written a line of code
| in their life sees source code, can't read it straight away,
| and assumes "We pay the software developers lots of money
| because they can read the cryptic runes" and goes on to pitch
| some "revolutionary solution" that eliminates this very minor
| hurdle, assuming that it will make the whole thing easy.
|
| You see the same thing in discourse about science and math: "If
| we could just eliminate all the jargon and syntax, anybody
| could understand a scientific paper". In all cases, they're
| wrong, of course, since the syntax and jargon are such
| negligible hurdles that by the time someone is technically
| capable enough at the actual problem they'll come as second
| nature, but the non-technical folk don't ever reach that level
| of understanding.
|
| Then this solution gets sold to other non-technical people,
| who, falling into the same trap, integrate it into their
| workflows.
| danielvaughn wrote:
| Yep, they misunderstand where the complexity lies.
| intrasight wrote:
| "Low-code is about creating instructions for a computer to
| execute or interpret. These instructions form a computer program,
| typically in a domain-specific language (DSL). For instance, low-
| code is often based on search-based program synthesis, and
| synthesis usually targets a DSL carefully crafted for the
| purpose."
|
| If that's the definition (and I agree that it is) then 90% of my
| code is low code, as that's how much is XML, XSLT, and SQL. In C#
| .NET 8, another 5% is Linq which is a DSL that I consider low-
| code.
|
| I have friends who work for a company that sells a million dollar
| low-code data platform. Business is good.
| TedDallas wrote:
| Low code has been a thing in ETL data integration space for a
| long time. Anecdotally the most consternation I have experienced
| lately has been supporting buggy low code implementations which
| seem to becoming worse and not better over the last 20 years or
| so.
| sien wrote:
| Is there an open source Low-Code system that works?
|
| Where I work we currently have 2 low code tools for automating
| internal business processes.
|
| Now a new executive has appeared and his answer to two of these
| systems is to get a third. This time it will be MS PowerApps.
|
| It seems that Low-Code is all high cost. The costs for licencing
| these platforms is 1-2 developers per year for our organisation
| of roughly 800 people.
|
| No doubt making applications on the web that work with SAML
| integration is harder than it could be, but the low-code tools
| lack of versioning and the ability to do automated testing is
| poor. Especially given the licencing costs.
|
| Even a good web based GUI for drawing UI's would be useful. But
| cost really is a factor.
|
| Visual Basic was a low code tool that did enable non-coders to
| create applications that were useful. It appears that the current
| crop of low-code tools are not near VB's ease of use or utility.
| wanderingmind wrote:
| Budibase is pretty good and helps you build simple web based
| solutions that can integrate with a wide range of data sources.
| Definitely worth checking out.
| rubenfiszel wrote:
| you should try windmill.dev, semi-technical folks can use the
| webeditor and the built-in versioning while more senior folks
| can keep their IDE and version directly from github/gitlab.
|
| The UI part is drag-n-drop;
| atoav wrote:
| IMO the problem with low code is, that the hard part about
| solving most problems isn't usually the way you write or execute
| it.
|
| The hard part is avoding weird edge case logic errors, race
| conditions, all these things good programmers will avoid by
| having an intuition of complex systems with state spread around.
| _This_ is what you pay software people for, and not for the
| ability to crank out text in languages that look cryptic to
| commoners.
|
| Now I do think that such low code environments can provide
| benefits in specific situations (e.g. when you use it as a highly
| flexible "config file" within the framework of another system
| that catches all those forbidden states).
| anonzzzies wrote:
| > highly flexible "config file"
|
| ... which will almost always trigger Greenspun's tenth rule
| albertzeyer wrote:
| Never heard of this before.
|
| https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
|
| > Any sufficiently complicated C or Fortran program contains
| an ad hoc, informally-specified, bug-ridden, slow
| implementation of half of Common Lisp.
| hyperthesis wrote:
| There's a spectrum of difficulty (of problems, not just within
| them as you note). Low code helps the low end.
|
| I'm surprised TFA implies spreadsheets aren't still dominant.
| ethbr1 wrote:
| The corollary of this is that low-code is best when a reusable
| component for a well-defined problem space exists.
|
| As soon as you drop into customized complexity, you should be
| building new low-code components with actual code.
|
| Which I think is the main reason low-code is popular in the
| API-to-API SaaS space: actions are limited and well-defined.
| hinkley wrote:
| None of these solutions are low-code though.
|
| Low code is using post-it notes to run your project. What
| "low-code" means is "someone else's code" and we already have
| tons of that, in the form of open source libraries and
| frameworks that avoid implementing tons of logic that is more
| or less idiomatic.
|
| This also includes SaaS solutions, where _I_ am not running
| any code at all. You are, and I 'm paying your for it. All I
| get are a palette of decisions I can make to alter how the
| product runs. Just like a YAML based solution.
|
| It's more snake oil, of an exact vintage that we already had
| in the late 1980's. And if you don't know what we called it
| then, it's because it was such a titanic flop that only
| computer history buffs know. An evolutionary dead end.
___________________________________________________________________
(page generated 2023-09-29 23:00 UTC)