3 ms·

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

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 https://matry.design.

badtension 3y ago
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.
- vector_spaces 3y ago
  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.
  - sorokod 3y ago
    >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 https://en.m.wikipedia.org/wiki/Boots_theory
  - badtension 3y ago
    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.
    - wizofaus 3y ago
      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
  - dragonwriter 3y ago
    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.
- replwoacause 3y ago
  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 3y ago
    Just nod and smile.
- michaelteter 3y ago
  > 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.
WalterBright 3y ago
There's a bug in it. Forgot to add detergent :-)
- danielvaughn 3y ago
  I love that HN has pointed out two bugs in my trivial made-up example, lol.
  - WalterBright 3y ago
    If you hadn't made the code self-evident, I wouldn't have found the bug!
OkayPhysicist 3y ago
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 3y ago
  Yep, they misunderstand where the complexity lies.
- d-lisp 3y ago
  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.
rightbyte 3y ago
> 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.

badtension 3y ago

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.

vector_spaces 3y ago
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.
- sorokod 3y ago
  >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 https://en.m.wikipedia.org/wiki/Boots_theory
- badtension 3y ago
  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.
  - wizofaus 3y ago
    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
- dragonwriter 3y ago
  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.
replwoacause 3y ago
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 3y ago
  Just nod and smile.
michaelteter 3y ago
> 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.

WalterBright 3y ago

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

danielvaughn 3y ago
I love that HN has pointed out two bugs in my trivial made-up example, lol.
- WalterBright 3y ago
  If you hadn't made the code self-evident, I wouldn't have found the bug!

OkayPhysicist 3y ago

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 3y ago
Yep, they misunderstand where the complexity lies.
d-lisp 3y ago
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.

rightbyte 3y ago

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