Hacker News Reader

Comment by atoav | Hacker News Reader

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).

View on HN

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.

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.

> All I get are a palette of decisions I can make to alter how the product runs.

It's amazing how many scenarios this covers.

In the exact same way that IaaS abstracts away things a lot of people don't need to care about.

It’s amazing how long you can unproductively stare at a piece of config that results in nothing happening when something was supposed to happen. Declarative code can be hell on beginners. It depends so much more than imperative or functional code on how clear the documentation is. And that was never our strong suit.

I'd invert that and say "If you can't write clear documentation, quickly, on a low-code component, then it shouldn't be a low-code component."

There are many things that low-code should never be used for.

But there are a lot of things it can be. E.g. IFTTT type stuff

> It's more snake oil

Being able to model a system graphically and run that graphical model is invaluable when working with non-programmer domain experts. And as often happens when drawing pictures of things, we may see new ways to organize processes that are big improvements over the formerly-obvious way they were built.

Another great use is allowing low-tech users to build their own low-code models. With a small bit of education, they can solve their own problems. And as some problems are short term situations, that low-code solution may suffice until the problem no longer exists. If the problem needs a long term professional solution, the developer can take the working low-code model and reimpliment it in code.

“Low code modules” is why everyone thinks Jira is hot garbage.

It gets set up by a manager who makes a bunch of choices that sound good but are wrong. There was just a post on Reddit the other day claiming that if a developer sets up Jira, it’s a nice tool.

It even has pretty pictures you can use for lifecycle definitions. That doesn’t help. We have spent years considering the consequences of decisions that sound nice but aren’t. Even if we only write five lines of code, that’s what you’re paying for. “Low-code” is “without programmers” and good luck with that.

I'd say everyone things Jira is hot garbage because Jira's UX philosophy is "add a feature somewhere, when there's a customer who needs it."

That works when you're SAP. Probably not for anyone else.

Was it called 4GL?

We have a winner.

The other problem with low code is that the visual abstraction can often make it harder to grok. I've had the unfortunate experience of spending hours trying to click through different nodes of a moderately complex Salesforce flow to piece together WTH it's doing.

It's also impossible to diff two across revisions.

If the same solution were written in code using high level libraries it would be a few hundred lines.

I wish these low code solutions would build on top a traditional text based language and allow you to flip back and forth.

To be fair, plenty of solutions involving code and high-level libraries can be incredibly difficult to grok too.

I’m currently suffering through nested serializers and business objects that have too much custom metaprogramming.

What’s worse: some of those would have been trivial when written in a more direct manner and would benefit from no-code tools.

I hope the next evolution in software development includes caring about what your stack traces look like. Pattern based development is especially noisy that way. By the time you find a value going wrong you’ve forgotten why you needed to know that.

I totally agree.

Lately I've been seeing "A Philosophy of Software Design" by John Ousterhout making waves with more experienced developers, and I definitely think it's going in the right direction of having richer abstractions and focus on DX rather than forcing the atomization of source code.

I’ve spent a good deal of time looking at code with other people, and one of the things I have seen first hand is how blind we are for a species with front facing eyeballs.

I spent a good chunk of my childhood doing word searches and “find seven differences” puzzles. And a good chunk of college playing text based games with a friend who would run around so fast that the screen was a blur. Somehow he could still read it, and I eventually learned to barely keep up with him. I use that skill today every time I’m tailing logs.

He wasn’t “unusual”. I was unusual, he was a genuine freak of nature. Almost nobody spots bugs as fast as I do, and getting them so see a line I’ve described verbally is a chore (line numbers are always on when I pair now) and I am far from infallible.

So when people tell me we are going to have non technical people look at a picture and determine what’s wrong with it, or two pictures and tell me the difference, well I am extremely skeptical. Every time graphical programming comes up, I assert that visual diff tools are the main thing blocking them from being feasible, and that assertion is generally well received.

Today there are a couple companies who might eventually get there, but they are focused on browser testing. I think that means commodification will have to happen first, as there’s not much money in dev tools.

I tried to do that with Salesforce flows, back when I did work in Salesforce. I started off with Scheme macros, got as far as variables and constants but it quickly got too complicated.

Right before losing interest I was exploring using BabelJS to parse JavaScript into AST's then generate Flow XML from an AST. I think this approach would have more legs.

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.

The term low code is horrible. It's overused, misused and probably created by a marketing team to sell ads.

There are a wide variety of platforms. Some are very open and honest about their core use cases (forms, Crud apps, automations). I work for an open source platform, Budibase, and they're pretty open in re to their use cases.

Others promise the world (SaaS apps, social networks) which are outside of their capabilities and probably not a great investment imo.

Spreadsheets are still dominant, but they're also the reason why many users turn to a low code platform.

> highly flexible "config file"

... which will almost always trigger Greenspun's tenth rule

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.

It was 2009, I think, when I found myself implementing a rudimentary Lisp reader in PHP, because while the client had proved fully to understand the concept of list syntax, the client also had proved wholly and with basaltic resolve unwilling to be parted from beloved Excel. Exporting to CSV for upload and processing was just about thinkable, and the only meaningful concession I managed to extract.

(The use of Lisp lists to represent tree-structured data wasn't a concession. See, you can generate those with Excel formulas...)

Oh god.

I’ve avoided hearing war stories about modernizing excel based companies for ten years. Academically I knew it must still be happening, but emotionally I’d convinced myself everything was daisies and the world had moved on.

Next it’ll be extracting applications from notebooks, I suspect.

That already happens.

I mean, that story's about to be 15 years old, but I take your point.

When I'm asked to prototype something that seems to pose a real danger of the next step being "okay let's deploy this", I do it in Emacs with org-babel. That's more than enough of a programming environment to validate an idea, and like a notebook each code block's results become part of the document, so it's very observable - but thanks in no small part to Emacs's reputation as alien space magic for weirdos, nobody's ever been mad enough to consider trying to jam it in production as-is.

Reply on news.ycombinator.com