Hacker News Reader

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.

Yep, they misunderstand where the complexity lies.

Interesting to note that scientific paper "trivialization" is about replacing jargon words by their meaning; i.e. by opening abstractions, making the text larger and larger, note that every scientifical concept or abstraction needs other abstractions to be explained that needs themselves trivialization because an abstraction is an elliptical and compressed way of saying something else (every abstraction is a tree of abstractions).

With this operation you are losing the possibility to even read some paper for obvious length reasons. What you lose in complexity is gained in thickness.

The problem is that low/no code doesn't consist in the same thing; abstractions it propose are meant to build a bridge between our current language and programming languages, just as UI is a bridge between our behavior and the execution of some script/function. In fact in this case, we are proposing to trivialize software development, not by reaching the initial machine code it expresses (explaining abstractions) but by inventing on top of theses abstractions another type of abstraction that is understandable to the non tech person reading the code (high level languages vs assembly is performing a similar operation). The difference with the science paper case is that here, complexity of abstractions leads to a better understanding of the text.

Problem is that with low/no code, you are lacking the ability to cross the bridge back (because you fail to analyze abstractions into their atoms) while scientific folks can.

C is powerful because it allows you to stay in the position of someone that understand computers and assembly. Higher level languages (interpreted ones) are dealing with the problem that low code hopes to solve in a better way : you don't need to understand the C implementation of X language to use it, and still you have a lot a power and freedom to develop software, eliminating the overheads of dealing with memory and etc...

I fail to see low code

as something else than a subset of X interpreted language that allows you to write in pure english (but the complexity of software doesn't lie in its expression, rather in its conceptualization), OR as something else than a GUI that allows you to write software (or UI) by dragging and dropping stuff at the screen, which is the worst I can imagine because again you would have the same problem of learning to technify yourself and reading documentation to understand what is in fact a weird suboptimal programming language.

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.

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.

>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

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.

Soaking is definitely necessary for many sorts of baked-on food remnants. But rinsing is mostly unnecessary unless you're expecting to leave the dishes in the machine long enough before running it that food particles dry out and get stuck - in that case just run a quick rinse cycle, it'll almost certainly use less water than doing it by hand

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.

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.

Just nod and smile.

> 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 haven't been fortunate enough to use a dishwasher that can reliably remove all particles from a dish. And I hate getting a "clean" dish out which still has some small bits of food stuck - now especially well stuck having gone through the heat drying cycle.

Some dishes need a human rinse/scrub before going into the dishwasher. The dishwasher is really more of a bacteria reducer.

> 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

I guess this is the problem with "low code". An actual dishwasher program would maybe look something like:

    /* Setup some arcane registers and timers */
    ...
    init_program (&setup); while (state == WASHING);
    // enable_pump (78); while (state == PUMPING); // 62 too fast - Fred 2007
    // enable_pump (81); while (state == PUMPING); // For Peru market - Kim 2011
    enable_pump (1); enable_pump (1); enable_pump (1); // Relay maybe stuck tickle it
    enable_pump (11); while (state == PUMPING); // ???
    enable_pump (99); while (state == PUMPING);
    ...

But obviously without the comments. Sooner or later many programs need complex state machines and some order at the language level the keep our sanity.

There's a bug in it. Forgot to add detergent :-)

I love that HN has pointed out two bugs in my trivial made-up example, lol.

If you hadn't made the code self-evident, I wouldn't have found the bug!