3 ms·

> 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

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

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