4 ms·

Hmm, I haven't heard this idea before that the FFI or surface area of libraries in a language causes bitrot. Could you elaborate on the connection? I can take v

Hmm, I haven't heard this idea before that the FFI or surface area of libraries in a language causes bitrot. Could you elaborate on the connection? I can take version 1 of the C sources of Vim from back in '92 and compile them without trouble. I'm not aware of dynamic languages like Javascript or Python 2 having any bitrot issues either. Backwards compatibility seems like a pretty big constraint for everyone. Edit 16 minutes later: I just tried your benchmark with my VM-like language (https://github.com/akkartik/mu https://github.com/akkartik/mu), and the time taken was almost identical. Interesting exercise! Here's the Mu and Plush/0 programs side by side: $ cat fib.mu def fib n:num -> result:num [ local-scope load-ingredients base-case?:bool <- lesser-or-equal n, 1 return-if base-case?, n n <- subtract n, 1 fib-n-1:num <- fib n n <- subtract n, 1 fib-n-2:num <- fib n result <- add fib-n-1, fib-n-2 ] def main [ local-scope x:num <- fib 29 $print x, 10/newline ] $ cat benchmarks/fib29.pls #language "lang/plush/0" var fib = function (n) { if (n < 2) return n; return fib(n-1) + fib(n-2); }; var r = fib(29); print(r);

tachyonbeam 10y ago
C has been fairly stable across time, but you gave to admit, a C program from 1992 still compiling as-is, that's an exception rather than the rule. The reason Vim from 1992 might still compile is actually because it doesn't have that much dependencies apart from standard C and POSIX APIs. JavaScript has massive bitrot issues. The HTML DOM is huge and constantly changing. I have had my own web apps break multiple times over the years. As for Python and C, if you stick to the core language, and minimize dependencies, you might be Ok. The problem is that the more dependencies you have, if any one of them break, they can render your program broken... And if you're not there to fix it, your program remains broken forever. My argument for reducing API surface and keeping APIs low-level and minimalist is that the smaller an API, the more difficult it is to implement it wrong. It's easier for two implementations to implement a smaller API and have the same behavior. It's also easier to test small APIs for conformance, etc.
- akkartik 10y ago
  I think I see what you mean. However, all these previous languages would claim that the parts they control have not suffered from bitrot. The dependencies you're thinking of are not considered part of the language in each case. Is that right? How would you keep people from creating new libraries in your language for unanticipated use cases? Say a self-driving car library, or a command-and-control module for all the IoT devices in a house from 2029? It seems to me that bitrot is fundamentally a result of change in the outside world. The only way to opt out of bitrot when the world changes rapidly seems to be to disengage from the world and become irrelevant. I'm fairly certain Mu will not suffer from bitrot in 30 years -- but it'll only be because nobody ever built anything with it :)
  - tachyonbeam 10y ago
    > How would you keep people from creating new libraries in your language for unanticipated use cases? Say a self-driving car library, or a command-and-control module for all the IoT devices in a house from 2029? I can't prevent people from doing that. I can only put together the conditions to make it easy to write software that doesn't break, as much as possible. > It seems to me that bitrot is fundamentally a result of change in the outside world. Yes and no. On the one hand, some breakage is inevitable with changing conditions. On the other hand, the computers we have now provide the same basic facilities as computers did in 1969. It ought to be able to provide some stable building blocks, and hope that people will use them. Currently, it seems to me that software breaks all the time, at a rate that is unacceptably high.
  - sitkack 10y ago
    I have come to the same conclusion as tachyonbeam, it is interaction with the outside world that causes bitrot. Rather than have APIs, we need communication protocol with simple semantics. The VM should interact over a constrained, well defined protocol, that protocol could implement a POSIX io model, but that would be up to the client to offer that abstraction over messages. The surface area of POSIX is too high to build systems that can run for 10s or hundreds of years. Look at the design of Lua over Python. The assumptions it makes of the underlying platform are much much cleaner, thus it is more portable and easier to debug platform issues.

tachyonbeam 10y ago

C has been fairly stable across time, but you gave to admit, a C program from 1992 still compiling as-is, that's an exception rather than the rule. The reason Vim from 1992 might still compile is actually because it doesn't have that much dependencies apart from standard C and POSIX APIs. JavaScript has massive bitrot issues. The HTML DOM is huge and constantly changing. I have had my own web apps break multiple times over the years. As for Python and C, if you stick to the core language, and minimize dependencies, you might be Ok. The problem is that the more dependencies you have, if any one of them break, they can render your program broken... And if you're not there to fix it, your program remains broken forever. My argument for reducing API surface and keeping APIs low-level and minimalist is that the smaller an API, the more difficult it is to implement it wrong. It's easier for two implementations to implement a smaller API and have the same behavior. It's also easier to test small APIs for conformance, etc.

akkartik 10y ago
I think I see what you mean. However, all these previous languages would claim that the parts they control have not suffered from bitrot. The dependencies you're thinking of are not considered part of the language in each case. Is that right? How would you keep people from creating new libraries in your language for unanticipated use cases? Say a self-driving car library, or a command-and-control module for all the IoT devices in a house from 2029? It seems to me that bitrot is fundamentally a result of change in the outside world. The only way to opt out of bitrot when the world changes rapidly seems to be to disengage from the world and become irrelevant. I'm fairly certain Mu will not suffer from bitrot in 30 years -- but it'll only be because nobody ever built anything with it :)
- tachyonbeam 10y ago
  > How would you keep people from creating new libraries in your language for unanticipated use cases? Say a self-driving car library, or a command-and-control module for all the IoT devices in a house from 2029? I can't prevent people from doing that. I can only put together the conditions to make it easy to write software that doesn't break, as much as possible. > It seems to me that bitrot is fundamentally a result of change in the outside world. Yes and no. On the one hand, some breakage is inevitable with changing conditions. On the other hand, the computers we have now provide the same basic facilities as computers did in 1969. It ought to be able to provide some stable building blocks, and hope that people will use them. Currently, it seems to me that software breaks all the time, at a rate that is unacceptably high.
- sitkack 10y ago
  I have come to the same conclusion as tachyonbeam, it is interaction with the outside world that causes bitrot. Rather than have APIs, we need communication protocol with simple semantics. The VM should interact over a constrained, well defined protocol, that protocol could implement a POSIX io model, but that would be up to the client to offer that abstraction over messages. The surface area of POSIX is too high to build systems that can run for 10s or hundreds of years. Look at the design of Lua over Python. The assumptions it makes of the underlying platform are much much cleaner, thus it is more portable and easier to debug platform issues.