5 ms·

As an SRE that occasionally encounters low-code things I'm also pretty skeptical.. * there is like no source control, or if there is the source controlled thin

As an SRE that occasionally encounters low-code things I'm also pretty skeptical.. * there is like no source control, or if there is the source controlled thing is an unreadable artifact which generally doesn't belong in source control. * the workflows are poorly if at all documented. * they still require a lot of custom code but that code isn't as reusable, tested or testable * they often require a proprietary runtime, worse this may only run on windows * they are difficult/impossible to instrument and so are difficult or impossible to monitor. Or if they do have monitoring it is going to work differently than the rest of your stack - likely using email based alerting which isn't ideal. * the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs) The only tool that was semi-reasonable here was Looker which isn't exactly marketed as low code but at least in the version of the product I used did integrate with source control. Though generally the people writing lookml were still engineers. I'm much more a fan of composable platforms that compress complexity but still make it possible to delve, customize and extend when necessary.

bb88 3y ago
> * the workflows are poorly if at all documented. Ideally it would be easier to understand if there's less code involved. Things should be more declarative, or the low-code solutions would generate good descriptions for what is actually happening. > * the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs) Or worse: "Why does this connection to this server fail with SSL Certifcate Invalid? Oh, nm, we'll just uncheck the SSL validation box."
- fieldcny 3y ago
  “Ideally” is quite a word, highly subjective. But really you are missing a key piece of the puzzle, it matters less what is happening and more why. Sure a low code tool could churn out a textual description to say if the value of some variable is < some threshold branch to X else branch to Y, but thats generally easy to figure out, why is that threshold important, that’s a question that requires understanding the intention of the user of engineer who set it up, that’s not something you can just puke out of an auto-doc tool. I would go so far as to say the inability to capture intention is one of the sharpest edges for low-code tools, it makes the solutions built on then extremely brittle and creates silos of knowledge. Expanding on that further this is why most auto generated documentation is worth the effort put into it.
  - bb88 3y ago
    All programming languages are some sort of abstraction to the underlying machine language. Low code is just "one more abstraction to machine language". Previous art in this area would be Lotus Notes (1990's), Hypercard (1980's), and Lotus 123 (1980's). Low code should be as close to a speaking language as possible. Declarative ideally. e.g. "Create a read-write rest framework for the database table named orders". An engineer would then go, "Oh, so you know you're missing permissions from the LDAP groups", and then solve that problem, and then figure out how make the LDAP groups map to the low code framework. That's kinda the sorta thing we do already.
- jabroni_salad 3y ago
  It should be easier to understand but lowcode designers seem to like making you jump between 30 different screens instead of having it all in one place. Unspooling a lowcode implementation has got to be one of my least favorite activities.
  - vinibrito 3y ago
    I think it would be too dense to have everything in one page. I don't remember any example of having it all in one page. Excel for example hides it all in modals.
- ahoka 3y ago
  What if you told IT months ago the reason their TLS setup is incorrect?
maccard 3y ago
> here is like no source control, or if there is the source controlled thing is an unreadable artifact which generally doesn't belong in source control I think this is an artifact of "source code is text" that our current tools assume (and is invalid IMO). Otherwise I agree
- ledauphin 3y ago
  i think the concept of "source code as AST" or something like that is basically a fine one, but the devil is in the details. your "true source" must continue to support (just off the top of my head): - precise "decompilation" to readable, idiomatic text - comments - line numbers or some semantic equivalent
  - fwip 3y ago
    You might like Unison [https://unisonweb.org/ https://unisonweb.org/].
  - maccard 3y ago
    The goal should be to store the inputs the user has provided. If your no code solution uses png files to encode the input, then store those, not an intermediate textual representation of them.
- ozim 3y ago
  You do understand that source code as text in current form is most efficient way to do it? There is no more efficient way unless you go to down to writing assembly or go down to writing 1 and 0. Everything you build up as low code has to create much more data which takes obviously much more space than high level languages we use today and if you want to do change control - any other data structure will take even more space. Then all of it will be obviously slower because more data is not just a bit more data but at least order or two orders of magnitude more. LLMs are great at compression but compression with them is not lossless so even if we write behavior to be interpreted by LLM to be executed it might turning out differently each time you run it. That last one is not a tradeoff we can deal in I would guess 95% of applications. People expect 2+2=4 from applications but they want to say „computer add two numbers that add up to 4” and they don’t really want to to crash because pi+x=4 and LLM went hanging because it is now calculating PI and then it will move to finding X. So this is why it will never work other way than „source code is text”.
gghffguhvc 3y ago
I don’t think the no source control is fundamentally the issue. Change control is the issue. Eg in CAD I quite like onshape’s “Versions and History”.
- abenga 3y ago
  Is the "Versions and History" transferrable between instances of the program? Can it be reliably used by a couple, dozens, even hundreds of people?
  - gghffguhvc 3y ago
    Yes. Onshape is web based. Every change is tracked and can be rolled back. There are versions and branches. Multiple people can work on the same document. The equivalent of a git comment would be a version with a comment.
- ivancho 3y ago
  Version control and source control are interchangeable terms and they both refer to tracking changes, it doesn't have to be source code
hanniabu 3y ago
I think Retool is the best I've seen. They have source control, great documentation, reusable custom code, can tie in external apis for monitoring. I'm someone that has a little less than junior dev experience (I can hack together a website), but nowhere near the ability to work on production code, yet I was able to be proficient with Retool. The only downside is the cost.
- kinj28 3y ago
  You may want to check alternatives. Ranges from open source to closed source folks like us.
citrin_ru 3y ago
> I am also skeptical towards DSLs What you would suggest instead of DSL? SQL is a DSL for data manipulation and I like it more than non-DSL code (ORM frameworks). Puppet language is a DSL and and I prefer it to Ansible (and alike) Yaml files (yaml is OK for small projects but hard and tedious to maintain for large ones).

bb88 3y ago

> * the workflows are poorly if at all documented. Ideally it would be easier to understand if there's less code involved. Things should be more declarative, or the low-code solutions would generate good descriptions for what is actually happening. > * the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs) Or worse: "Why does this connection to this server fail with SSL Certifcate Invalid? Oh, nm, we'll just uncheck the SSL validation box."

fieldcny 3y ago
“Ideally” is quite a word, highly subjective. But really you are missing a key piece of the puzzle, it matters less what is happening and more why. Sure a low code tool could churn out a textual description to say if the value of some variable is < some threshold branch to X else branch to Y, but thats generally easy to figure out, why is that threshold important, that’s a question that requires understanding the intention of the user of engineer who set it up, that’s not something you can just puke out of an auto-doc tool. I would go so far as to say the inability to capture intention is one of the sharpest edges for low-code tools, it makes the solutions built on then extremely brittle and creates silos of knowledge. Expanding on that further this is why most auto generated documentation is worth the effort put into it.
- bb88 3y ago
  All programming languages are some sort of abstraction to the underlying machine language. Low code is just "one more abstraction to machine language". Previous art in this area would be Lotus Notes (1990's), Hypercard (1980's), and Lotus 123 (1980's). Low code should be as close to a speaking language as possible. Declarative ideally. e.g. "Create a read-write rest framework for the database table named orders". An engineer would then go, "Oh, so you know you're missing permissions from the LDAP groups", and then solve that problem, and then figure out how make the LDAP groups map to the low code framework. That's kinda the sorta thing we do already.
jabroni_salad 3y ago
It should be easier to understand but lowcode designers seem to like making you jump between 30 different screens instead of having it all in one place. Unspooling a lowcode implementation has got to be one of my least favorite activities.
- vinibrito 3y ago
  I think it would be too dense to have everything in one page. I don't remember any example of having it all in one page. Excel for example hides it all in modals.
ahoka 3y ago
What if you told IT months ago the reason their TLS setup is incorrect?

maccard 3y ago

> here is like no source control, or if there is the source controlled thing is an unreadable artifact which generally doesn't belong in source control I think this is an artifact of "source code is text" that our current tools assume (and is invalid IMO). Otherwise I agree

ledauphin 3y ago
i think the concept of "source code as AST" or something like that is basically a fine one, but the devil is in the details. your "true source" must continue to support (just off the top of my head): - precise "decompilation" to readable, idiomatic text - comments - line numbers or some semantic equivalent
- fwip 3y ago
  You might like Unison [https://unisonweb.org/ https://unisonweb.org/].
- maccard 3y ago
  The goal should be to store the inputs the user has provided. If your no code solution uses png files to encode the input, then store those, not an intermediate textual representation of them.
ozim 3y ago
You do understand that source code as text in current form is most efficient way to do it? There is no more efficient way unless you go to down to writing assembly or go down to writing 1 and 0. Everything you build up as low code has to create much more data which takes obviously much more space than high level languages we use today and if you want to do change control - any other data structure will take even more space. Then all of it will be obviously slower because more data is not just a bit more data but at least order or two orders of magnitude more. LLMs are great at compression but compression with them is not lossless so even if we write behavior to be interpreted by LLM to be executed it might turning out differently each time you run it. That last one is not a tradeoff we can deal in I would guess 95% of applications. People expect 2+2=4 from applications but they want to say „computer add two numbers that add up to 4” and they don’t really want to to crash because pi+x=4 and LLM went hanging because it is now calculating PI and then it will move to finding X. So this is why it will never work other way than „source code is text”.

gghffguhvc 3y ago

I don’t think the no source control is fundamentally the issue. Change control is the issue. Eg in CAD I quite like onshape’s “Versions and History”.

abenga 3y ago
Is the "Versions and History" transferrable between instances of the program? Can it be reliably used by a couple, dozens, even hundreds of people?
- gghffguhvc 3y ago
  Yes. Onshape is web based. Every change is tracked and can be rolled back. There are versions and branches. Multiple people can work on the same document. The equivalent of a git comment would be a version with a comment.
ivancho 3y ago
Version control and source control are interchangeable terms and they both refer to tracking changes, it doesn't have to be source code

hanniabu 3y ago

I think Retool is the best I've seen. They have source control, great documentation, reusable custom code, can tie in external apis for monitoring. I'm someone that has a little less than junior dev experience (I can hack together a website), but nowhere near the ability to work on production code, yet I was able to be proficient with Retool. The only downside is the cost.

kinj28 3y ago
You may want to check alternatives. Ranges from open source to closed source folks like us.

citrin_ru 3y ago

> I am also skeptical towards DSLs What you would suggest instead of DSL? SQL is a DSL for data manipulation and I like it more than non-DSL code (ORM frameworks). Puppet language is a DSL and and I prefer it to Ansible (and alike) Yaml files (yaml is OK for small projects but hard and tedious to maintain for large ones).