5 ms·

Maybe it’s just me, but I assumed almost all devs with basic coding ability would be against low code. It has so many issues, from poor version control to never

Maybe it’s just me, but I assumed almost all devs with basic coding ability would be against low code. It has so many issues, from poor version control to never (and I do mean never - would love to be proven wrong) doing more than or even meeting the feature set of whatever competing “some code” solution offers. In the end, you end up with either less skilled people getting in too deep, or highly skilled people unable to fully avail their skills. I get the appeal, but it always seemed like a local optima to me. It turns out code is a pretty good interface.

sfn42 3y ago
That's what people don't seem to get. "Low code" is literally just a software library with a gui on top. They could just provide the software library as a standalone but then there's too much competition and the competition is often free to use. So they don't even bother because their whole product is redundant without the GUI, and the GUI itself is just a pointless obstacle to a developer.
- JonChesterfield 3y ago
  A programming language is a pointless obstacle in the way of writing the compiler IR directly. And the compiler IR is a pointless obstacle in the way of writing the machine code directly. Low code GUIs are a weird code generator, just the same as all the other programming languages. Whether it's an obfuscation or an enabler depends on your perspective and what you're trying to do with it. In particular, programming languages are pretty much a library (called the compiler runtime) with a text user interface on top.
  - sfn42 3y ago
    No, a programming language is a useful tool. There is absolutely nothing stopping you from writing machine code directly, go right ahead if you think that's easier for you.
    - JonChesterfield 3y ago
      Such as in the implementation of a JIT. There emitting the machine code directly is less bother than emitting assembly and much less bother than emitting C, compiling it and then loading it into the address space. The low code systems being derided here are programming languages. They're languages you use to program computers with. I suppose one could define "programming language" to be "a language for programming computers that is useful in some context", but they're pretty much all useful in some context. Maybe one could define it as being mandatory to use text editing to count as a programming language, but the smalltalk instances are something of a counter argument, as are the UML things.
      - sfn42 3y ago
        Alright. You say low code systems are programming languages, I said they're GUIs on top of software libraries. So in essence we both just said low code systems are graphical programming languages, in different words. The problem with these graphical programming languages is that they are constrained. To a developer like me they take away my freedom to do what I want, especially if they attempt to target non-developers. And even if there existed a totally complete general purpose graphical programming language, it would just be another programming language with the caveat that instead of just writing whatever I want I have to find it in some menu and drag it somewhere and whatever else. It's just a less convenient way of doing the same thing.
        JonChesterfield 3y ago
        You're right in a broad sense and wrong in a somewhat subtle one. A major part of the value add of any programming language is what it does not let you express. If you move from asm to C, suddenly goto is stuck within a single function and calling conventions are absurdly constrained. If you move further up the stack goto might be removed entirely and function calls might throw an exception if the calling convention is violated. People like this restriction. CPython has id() to get the address of a value. Really convenient. Totally messes up alternative implementations of the language. Other languages won't let you talk about the address of a variable at all. Removing capability from the programmer helps communication with other programmers, simplifies parts of the implementation, sometimes simplifies writing programs in the subset that remains. Working in a non-turing complete language can give you hard guarantees on termination. If you go as far as regular languages, function equality is decidable. As in convert to a DFA, minimise it and alpha-rename, and the two functions compute the same result iff said DFAs are definitionally equal. You don't get that with a general purpose language. Regardless, I share your irritation with low code systems to the extent I've tried to do things with them so far. An escape hatch to java is really not a thing I want. A wholly general purpose Turing complete graphical programming system sounds awful to me. That doesn't make the fundamental premise of a heavily restricted language with a weird interface wrong though. All programming languages are more or less heavily restricted already, and a bunch of them have weird interfaces. I believe low code style systems are the right things to program some applications in for much the same reasons that config languages shouldn't be Turing complete. Less clear is whether any of the current low code tools (other than Excel anyway) deliver on that optimistic view.

sfn42 3y ago

That's what people don't seem to get. "Low code" is literally just a software library with a gui on top. They could just provide the software library as a standalone but then there's too much competition and the competition is often free to use. So they don't even bother because their whole product is redundant without the GUI, and the GUI itself is just a pointless obstacle to a developer.

JonChesterfield 3y ago
A programming language is a pointless obstacle in the way of writing the compiler IR directly. And the compiler IR is a pointless obstacle in the way of writing the machine code directly. Low code GUIs are a weird code generator, just the same as all the other programming languages. Whether it's an obfuscation or an enabler depends on your perspective and what you're trying to do with it. In particular, programming languages are pretty much a library (called the compiler runtime) with a text user interface on top.
- sfn42 3y ago
  No, a programming language is a useful tool. There is absolutely nothing stopping you from writing machine code directly, go right ahead if you think that's easier for you.
  - JonChesterfield 3y ago
    Such as in the implementation of a JIT. There emitting the machine code directly is less bother than emitting assembly and much less bother than emitting C, compiling it and then loading it into the address space. The low code systems being derided here are programming languages. They're languages you use to program computers with. I suppose one could define "programming language" to be "a language for programming computers that is useful in some context", but they're pretty much all useful in some context. Maybe one could define it as being mandatory to use text editing to count as a programming language, but the smalltalk instances are something of a counter argument, as are the UML things.
    - sfn42 3y ago
      Alright. You say low code systems are programming languages, I said they're GUIs on top of software libraries. So in essence we both just said low code systems are graphical programming languages, in different words. The problem with these graphical programming languages is that they are constrained. To a developer like me they take away my freedom to do what I want, especially if they attempt to target non-developers. And even if there existed a totally complete general purpose graphical programming language, it would just be another programming language with the caveat that instead of just writing whatever I want I have to find it in some menu and drag it somewhere and whatever else. It's just a less convenient way of doing the same thing.
      - JonChesterfield 3y ago
        You're right in a broad sense and wrong in a somewhat subtle one. A major part of the value add of any programming language is what it does not let you express. If you move from asm to C, suddenly goto is stuck within a single function and calling conventions are absurdly constrained. If you move further up the stack goto might be removed entirely and function calls might throw an exception if the calling convention is violated. People like this restriction. CPython has id() to get the address of a value. Really convenient. Totally messes up alternative implementations of the language. Other languages won't let you talk about the address of a variable at all. Removing capability from the programmer helps communication with other programmers, simplifies parts of the implementation, sometimes simplifies writing programs in the subset that remains. Working in a non-turing complete language can give you hard guarantees on termination. If you go as far as regular languages, function equality is decidable. As in convert to a DFA, minimise it and alpha-rename, and the two functions compute the same result iff said DFAs are definitionally equal. You don't get that with a general purpose language. Regardless, I share your irritation with low code systems to the extent I've tried to do things with them so far. An escape hatch to java is really not a thing I want. A wholly general purpose Turing complete graphical programming system sounds awful to me. That doesn't make the fundamental premise of a heavily restricted language with a weird interface wrong though. All programming languages are more or less heavily restricted already, and a bunch of them have weird interfaces. I believe low code style systems are the right things to program some applications in for much the same reasons that config languages shouldn't be Turing complete. Less clear is whether any of the current low code tools (other than Excel anyway) deliver on that optimistic view.