2 ms·

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 eas

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

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