14 ms·

Programming Languages as Constraints

65 points by akkartik 10y ago

btrask 10y ago
Okay, libraries can't provide new inabilities. But that's why we have linters, static analyzers, style guides, compiler options and warnings, and ultimately code reviews and good taste. I think the big problem (and sometimes benefit) of old languages is their culture. For example, C programmers don't trust anything written since K&R. This is both good and bad. Creating a new language doesn't force existing communities to change; it means creating a new community and either waiting for the old ones to die off, or (ideally?) driving them into obsolescence. I remember when Wikipedia was new and there were lots of studies finding errors in their articles. Instead of replacing Wikipedia, those techniques for finding errors were simply incorporated into the editing process (as much as possible). I wish that as new classes of bugs came onto our radar, we could go back and refine old code instead of throwing it out with the bathwater. (Even OpenSSL wasn't beyond saving, judging by BoringSSL and LibreSSL. These projects still need more work, of course.)
- drabiega 10y ago
  Well, a lot of the point of these constraints is to reduce complexity, as the writer mentions. When you add constraints with most of those tools, you're actually adding complexity to your tooling, build process, and cognitive load if not to your actual code base.
- scott_s 10y ago
  And yet with those, we still have security vulnerabilities in C programs. That, I think, is a strong argument for languages which have very specific constraints. (For example: Rust.)
  - NoIdeaAtAll 10y ago
    Do you have any idea how much software is run behind a firewall? If someone is even able to run my software that means they have full access to a shell and compilers for multiple programming languages. As such, there are much easier ways to run malicious code than to exploit a buffer overflow in my C or C++... So really, your argument only applies to public facing servers or web browsers. Unless you're writing one of those, I think your argument is weak.
    - MaulingMonkey 10y ago
      > So really, your argument only applies to public facing servers or web browsers. Or, you know, literally anything touching a file format that might be downloaded. PDFs, word documents, images, zip files, movies, music, sounds, icons that show up in your file explorer, user profiles, any sort of web client (email, games, chat, wget, package managers, ...) lots of poison apples out there. This kind of nonsense is why the best advice to handling USB drives you find on the ground is to toss them in a fire barrel - everyone thinks they're "behind a firewall" and that they're totally protected! They have all the protection of a wet tissue in a hurricane. Oh, but I'm just writing a terminal! I don't touch file formats! It's safe to auto-execute commands in response to pasted newlines! ...and then you've helped enable the spread of malware through clipboard hijacking Javascript. Oops. Firewalls are not a panacea. Firewalls are a roadbump. > Unless you're writing one of those, I think your argument is weak. I think your security is borderline nonexistent. I think I cannot trust you with C. I think someone is probably in your systems if you're in charge of the security side of IT, of anywhere of significance, unless you delegated enough responsibility to make you a figurehead. I mean no offense by this. A lot of reasonably talented and smart programmers make the same mistake as you, and go write a bunch of exploitable vulnerabilities in C as a result. It's not like you're one of those madmen disabling ASLR, NX, stack cookies, or some of the many other mitigation techniques being used to try and clean up after this tragedy of our times. ...right?
      - NoIdeaAtAll 10y ago
        > I think I cannot trust you with C. You really don't get it, but your arrogance is overwhelming. I don't care who you trust. > I mean no offense by this. Yes you do.
        MaulingMonkey 10y ago
        > You really don't get it Then point out what I'm missing.
        NoIdeaAtAll 10y ago
- akkartik 10y ago
  "For example, C programmers don't trust anything written since K&R." That is an incredibly broad generalization. Perhaps you were implicitly assuming some qualifiers? :) --- "..that's why we have linters, static analyzers, style guides, compiler options and warnings.." But all those things are still just glorified retrofits on the job of the language. Are there any examples where a new library in a new domain adds inabilities that weren't originally enforced (or even conceived of) in the language? One example I can think of is reading/writing files. The original C had simple numbers for file descriptors, which meant that in a large application you might try to read from a write-only fd, or vice versa. The C++ standard library solved that by creating separate types for istreams and ostreams. No reason we couldn't apply that idea to C as well. On a tangent, I'm fascinated by the fact that Go hasn't bothered to steal that idea. For example, a goroutine can read or write any of the channels it has access to. If you try to juggle too many at once, that might cause the odd typo bug. It'll be interesting to see if source/sink channel types ever get retrofitted to Go in a decade or so.
  - mw42 10y ago
    > It'll be interesting to see if source/sink channel types ever get retrofitted to Go in a decade or so. Channels can be designated as receive-only or send-only in variable and function declarations: ch := make(chan int, 1) var send chan<- int = ch var recv <-chan int = ch send <- 1 // ok <- recv // ok recv <- 1 // invalid operation: recv <- 1 (send to receive-only type <-chan int) <- send // invalid operation: <-send (receive from send-only type chan<- int)
    - akkartik 10y ago
      Ah! Can't believe I missed that..
- andrepd 10y ago
  >C programmers don't trust anything written since K&R. C is one of the most used languages in the world, and the number of programmers is surpassed perhaps only by a handful of languages. That alone tells me any generalisation you make about C programmers is most probably erroneous.
  - pjmlp 10y ago
    Not everyone uses C willingly.
  - nickpsecurity 10y ago
    "COBOL is one of the most used languages in the world, and the number of lines of code is surpassed perhaps only by a handful of languages. That alone tells me any generalisation you make about COBOL programmers is most probably erroneous." One a name and one phrase changed but it's still technically true. Clearly something wrong with your argument unless you think COBOL is also superior to other languages due to uptake.
    - golergka 10y ago
      Comment you're replying to didn't say anything about C being superior or not.
      - nickpsecurity 10y ago
        It implied it had good design or worth vs other languages due to massive uptake vs other languages.
        KMag 10y ago
        My reading of the OP was just that there are tons and tons of C programmers, who almost certainly use C for many different reasons, and it's hard to believe any sweeping generalisation of such a large diverse group.... and therefore it's difficult to believe that none of the large and diverse number of C programmers trust anything after K&R.
- nostrademons 10y ago
  Of possible interest: http://www.nhplace.com/kent/PS/Lambda.html http://www.nhplace.com/kent/PS/Lambda.html
  - akkartik 10y ago
    Seems down from here. Backup link: https://web.archive.org/web/20160304012251/http://www.nhplace.com/kent/PS/Lambda.html https://web.archive.org/web/20160304012251/http://www.nhplac...
- catnaroek 10y ago
  > But that's why we have linters, static analyzers, Which tend to be based on heuristics, rather than any sort of rigorous foundation. There's no shortage of static analysis tools for C and C++ that reject good code and accept bad code. > style guides, Which can be very onerous, limiting your ability to define useful abstractions, leaving you with just the bad parts of the base language (e.g., Google's C++ Style Guide). > compiler options and warnings, No amount of compiler options or warnings will force you to use an abstract type, well, abstractly, in a language that has unrestricted memory access (C and C++), unrestricted reflection (Java, .NET, anything dynamic), or both (some Common Lisp implementations). > and ultimately code reviews and good taste. If only the latter weren't in short supply...
sharpercoder 10y ago
One inability I am thinking about lately is disallowing primitive types on public members. Take C#, but properties and methods would only allow returning and taking class/struct types. This way you enforce strict use of objects, enforcing expressivity. No more `double meters` but `Meter meters`.
- 14113 10y ago
  How you you encode "dimensionless" quantities within such a system?
  - tomsmeding 10y ago
    You have stuff like Integer right? Which doesn't really bring you anything...
  - scotty79 10y ago
    Every value has some identity in domain space. Even if it doesn't have a unit.
- hartez 10y ago
  That actually sounds like a fun Roslyn analyzer project.
- catnaroek 10y ago
  A separate class for each unit of measurement isn't the right way to perform compile-time dimensional analysis. It doesn't easily support forming compound units from more basic ones.
  - scotty79 10y ago
    I don't think this is the main point of this limitation. Main point is to prevent "primitive obsession" anti pattern.
    - catnaroek 10y ago
AnimalMuppet 10y ago
Constraints provide freedom. This is not Orwellian newspeak. In a Turing Machine, everything is possible. But nobody wants to program in it because it's too hard. Same thing with assembly. Everything that the CPU can do, you can do in assembly. But everyone wants out of assembly if at all possible. Why? Because the price for the freedom was too high. Same thing with jumping to any line in a program. Sure, there are times when it could make your life easier, but they aren't very many. And what's horrible is when someone a decade ago, who doesn't even work there anymore, used it to make their life easier, and you have to figure out their bit of "cleverness". It's worth not being able to do that in order to keep that from being done to you. (This is the way civilized society works, by the way. I give up the freedom to kill random other people in order to not live in a society where I worry a lot about random other people trying to kill me.) Within the constraints ("I can't do X"), you find two kinds of freedom. First, "I no longer have to worry about somebody else doing X in code that I need to work on". Second, "I gain Y". For an example of the second kind, garbage collection means that I no longer have to keep track of when I should free memory. By giving up something (the ability to allocate and free memory myself), I gained freedom. This is a net win if I don't need the thing I'm giving up. You're not trying to write something specific. Give up the things you don't need in order to write the program you're trying to write, if doing so reduces the number of things you have to do in order to write that program. Give up something you weren't going to use anyway in order to have less that you have to do. That's a win.
- agumonkey 10y ago
  > Constraints provide freedom. My feeling when I program in ml / lisps. Limited set of abstractions and composition rules. Fuels my mind. My brain choke at the first mutable statement sequence.
  - catnaroek 10y ago
    ML lets you define just about any abstraction you want, and actually enforce it, both statically (using abstract types) and dynamically (using exceptions). The only thing that's limited in ML is which abstractions can be enforced using only static means.
pjmlp 10y ago
> The ability to refer to memory addresses (all languages, except the C family) Someone should learn about Algol family of programming languages.
- adrianratnapala 10y ago
  My assumption had always been that our modern languages had already done that for us, so we don't need to. But you are right, the original statement is absurd. Ada and (at least Turbo-) Pascal have pointers. And so does Java.
  - pjmlp 10y ago
    Algol, * Pascal, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Ada, D, Swift, Rust And I am not listing all of them.
    - icebraining 10y ago
      Even Python, using ctypes.
      - pygy_ 10y ago
        LuaJIT's FFI also allows to manipulate and dereference arbitrary pointers.
  - Someone 10y ago
    I see having pointers to support dynamic memory allocation as something different from the ability to refer to memory addresses. For example, in C, one can [1] write a program that attempts to write data to any memory address. With Java, that is not possible. With pascal, Wirth's intention was similar, but IIRC variant records provided an undesired escape hatch. [1] probably not without invoking implementation-dependent behavior.
    - pjmlp 10y ago

65 points by akkartik 10y ago

Okay, libraries can't provide new inabilities. But that's why we have linters, static analyzers, style guides, compiler options and warnings, and ultimately code reviews and good taste. I think the big problem (and sometimes benefit) of old languages is their culture. For example, C programmers don't trust anything written since K&R. This is both good and bad. Creating a new language doesn't force existing communities to change; it means creating a new community and either waiting for the old ones to die off, or (ideally?) driving them into obsolescence. I remember when Wikipedia was new and there were lots of studies finding errors in their articles. Instead of replacing Wikipedia, those techniques for finding errors were simply incorporated into the editing process (as much as possible). I wish that as new classes of bugs came onto our radar, we could go back and refine old code instead of throwing it out with the bathwater. (Even OpenSSL wasn't beyond saving, judging by BoringSSL and LibreSSL. These projects still need more work, of course.)

drabiega 10y ago
Well, a lot of the point of these constraints is to reduce complexity, as the writer mentions. When you add constraints with most of those tools, you're actually adding complexity to your tooling, build process, and cognitive load if not to your actual code base.
scott_s 10y ago
And yet with those, we still have security vulnerabilities in C programs. That, I think, is a strong argument for languages which have very specific constraints. (For example: Rust.)
- NoIdeaAtAll 10y ago
  Do you have any idea how much software is run behind a firewall? If someone is even able to run my software that means they have full access to a shell and compilers for multiple programming languages. As such, there are much easier ways to run malicious code than to exploit a buffer overflow in my C or C++... So really, your argument only applies to public facing servers or web browsers. Unless you're writing one of those, I think your argument is weak.
  - MaulingMonkey 10y ago
    > So really, your argument only applies to public facing servers or web browsers. Or, you know, literally anything touching a file format that might be downloaded. PDFs, word documents, images, zip files, movies, music, sounds, icons that show up in your file explorer, user profiles, any sort of web client (email, games, chat, wget, package managers, ...) lots of poison apples out there. This kind of nonsense is why the best advice to handling USB drives you find on the ground is to toss them in a fire barrel - everyone thinks they're "behind a firewall" and that they're totally protected! They have all the protection of a wet tissue in a hurricane. Oh, but I'm just writing a terminal! I don't touch file formats! It's safe to auto-execute commands in response to pasted newlines! ...and then you've helped enable the spread of malware through clipboard hijacking Javascript. Oops. Firewalls are not a panacea. Firewalls are a roadbump. > Unless you're writing one of those, I think your argument is weak. I think your security is borderline nonexistent. I think I cannot trust you with C. I think someone is probably in your systems if you're in charge of the security side of IT, of anywhere of significance, unless you delegated enough responsibility to make you a figurehead. I mean no offense by this. A lot of reasonably talented and smart programmers make the same mistake as you, and go write a bunch of exploitable vulnerabilities in C as a result. It's not like you're one of those madmen disabling ASLR, NX, stack cookies, or some of the many other mitigation techniques being used to try and clean up after this tragedy of our times. ...right?
    - NoIdeaAtAll 10y ago
      > I think I cannot trust you with C. You really don't get it, but your arrogance is overwhelming. I don't care who you trust. > I mean no offense by this. Yes you do.
      - MaulingMonkey 10y ago
        > You really don't get it Then point out what I'm missing.
        NoIdeaAtAll 10y ago
akkartik 10y ago
"For example, C programmers don't trust anything written since K&R." That is an incredibly broad generalization. Perhaps you were implicitly assuming some qualifiers? :) --- "..that's why we have linters, static analyzers, style guides, compiler options and warnings.." But all those things are still just glorified retrofits on the job of the language. Are there any examples where a new library in a new domain adds inabilities that weren't originally enforced (or even conceived of) in the language? One example I can think of is reading/writing files. The original C had simple numbers for file descriptors, which meant that in a large application you might try to read from a write-only fd, or vice versa. The C++ standard library solved that by creating separate types for istreams and ostreams. No reason we couldn't apply that idea to C as well. On a tangent, I'm fascinated by the fact that Go hasn't bothered to steal that idea. For example, a goroutine can read or write any of the channels it has access to. If you try to juggle too many at once, that might cause the odd typo bug. It'll be interesting to see if source/sink channel types ever get retrofitted to Go in a decade or so.
- mw42 10y ago
  > It'll be interesting to see if source/sink channel types ever get retrofitted to Go in a decade or so. Channels can be designated as receive-only or send-only in variable and function declarations: ch := make(chan int, 1) var send chan<- int = ch var recv <-chan int = ch send <- 1 // ok <- recv // ok recv <- 1 // invalid operation: recv <- 1 (send to receive-only type <-chan int) <- send // invalid operation: <-send (receive from send-only type chan<- int)
  - akkartik 10y ago
    Ah! Can't believe I missed that..
andrepd 10y ago
>C programmers don't trust anything written since K&R. C is one of the most used languages in the world, and the number of programmers is surpassed perhaps only by a handful of languages. That alone tells me any generalisation you make about C programmers is most probably erroneous.
- pjmlp 10y ago
  Not everyone uses C willingly.
- nickpsecurity 10y ago
  "COBOL is one of the most used languages in the world, and the number of lines of code is surpassed perhaps only by a handful of languages. That alone tells me any generalisation you make about COBOL programmers is most probably erroneous." One a name and one phrase changed but it's still technically true. Clearly something wrong with your argument unless you think COBOL is also superior to other languages due to uptake.
  - golergka 10y ago
    Comment you're replying to didn't say anything about C being superior or not.
    - nickpsecurity 10y ago
      It implied it had good design or worth vs other languages due to massive uptake vs other languages.
      - KMag 10y ago
        My reading of the OP was just that there are tons and tons of C programmers, who almost certainly use C for many different reasons, and it's hard to believe any sweeping generalisation of such a large diverse group.... and therefore it's difficult to believe that none of the large and diverse number of C programmers trust anything after K&R.
nostrademons 10y ago
Of possible interest: http://www.nhplace.com/kent/PS/Lambda.html http://www.nhplace.com/kent/PS/Lambda.html
- akkartik 10y ago
  Seems down from here. Backup link: https://web.archive.org/web/20160304012251/http://www.nhplace.com/kent/PS/Lambda.html https://web.archive.org/web/20160304012251/http://www.nhplac...
catnaroek 10y ago
> But that's why we have linters, static analyzers, Which tend to be based on heuristics, rather than any sort of rigorous foundation. There's no shortage of static analysis tools for C and C++ that reject good code and accept bad code. > style guides, Which can be very onerous, limiting your ability to define useful abstractions, leaving you with just the bad parts of the base language (e.g., Google's C++ Style Guide). > compiler options and warnings, No amount of compiler options or warnings will force you to use an abstract type, well, abstractly, in a language that has unrestricted memory access (C and C++), unrestricted reflection (Java, .NET, anything dynamic), or both (some Common Lisp implementations). > and ultimately code reviews and good taste. If only the latter weren't in short supply...

sharpercoder 10y ago

One inability I am thinking about lately is disallowing primitive types on public members. Take C#, but properties and methods would only allow returning and taking class/struct types. This way you enforce strict use of objects, enforcing expressivity. No more `double meters` but `Meter meters`.

14113 10y ago
How you you encode "dimensionless" quantities within such a system?
- tomsmeding 10y ago
  You have stuff like Integer right? Which doesn't really bring you anything...
- scotty79 10y ago
  Every value has some identity in domain space. Even if it doesn't have a unit.
hartez 10y ago
That actually sounds like a fun Roslyn analyzer project.
catnaroek 10y ago
A separate class for each unit of measurement isn't the right way to perform compile-time dimensional analysis. It doesn't easily support forming compound units from more basic ones.
- scotty79 10y ago
  I don't think this is the main point of this limitation. Main point is to prevent "primitive obsession" anti pattern.
  - catnaroek 10y ago

AnimalMuppet 10y ago

Constraints provide freedom. This is not Orwellian newspeak. In a Turing Machine, everything is possible. But nobody wants to program in it because it's too hard. Same thing with assembly. Everything that the CPU can do, you can do in assembly. But everyone wants out of assembly if at all possible. Why? Because the price for the freedom was too high. Same thing with jumping to any line in a program. Sure, there are times when it could make your life easier, but they aren't very many. And what's horrible is when someone a decade ago, who doesn't even work there anymore, used it to make their life easier, and you have to figure out their bit of "cleverness". It's worth not being able to do that in order to keep that from being done to you. (This is the way civilized society works, by the way. I give up the freedom to kill random other people in order to not live in a society where I worry a lot about random other people trying to kill me.) Within the constraints ("I can't do X"), you find two kinds of freedom. First, "I no longer have to worry about somebody else doing X in code that I need to work on". Second, "I gain Y". For an example of the second kind, garbage collection means that I no longer have to keep track of when I should free memory. By giving up something (the ability to allocate and free memory myself), I gained freedom. This is a net win if I don't need the thing I'm giving up. You're not trying to write something specific. Give up the things you don't need in order to write the program you're trying to write, if doing so reduces the number of things you have to do in order to write that program. Give up something you weren't going to use anyway in order to have less that you have to do. That's a win.

agumonkey 10y ago
> Constraints provide freedom. My feeling when I program in ml / lisps. Limited set of abstractions and composition rules. Fuels my mind. My brain choke at the first mutable statement sequence.
- catnaroek 10y ago
  ML lets you define just about any abstraction you want, and actually enforce it, both statically (using abstract types) and dynamically (using exceptions). The only thing that's limited in ML is which abstractions can be enforced using only static means.

pjmlp 10y ago

> The ability to refer to memory addresses (all languages, except the C family) Someone should learn about Algol family of programming languages.

adrianratnapala 10y ago
My assumption had always been that our modern languages had already done that for us, so we don't need to. But you are right, the original statement is absurd. Ada and (at least Turbo-) Pascal have pointers. And so does Java.
- pjmlp 10y ago
  Algol, * Pascal, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Ada, D, Swift, Rust And I am not listing all of them.
  - icebraining 10y ago
    Even Python, using ctypes.
    - pygy_ 10y ago
      LuaJIT's FFI also allows to manipulate and dereference arbitrary pointers.
- Someone 10y ago
  I see having pointers to support dynamic memory allocation as something different from the ability to refer to memory addresses. For example, in C, one can [1] write a program that attempts to write data to any memory address. With Java, that is not possible. With pascal, Wirth's intention was similar, but IIRC variant records provided an undesired escape hatch. [1] probably not without invoking implementation-dependent behavior.
  - pjmlp 10y ago