ZetaVM, my new compiler project

Re:ZetaVM, my new compiler project by akkartik on Saturday April 29, 2017 @06:33PM (#14229140)

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 :)

[ Parent | on HN ]

Re:ZetaVM, my new compiler project by tachyonbeam on Saturday April 29, 2017 @06:40PM (#14229167)

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

[ Parent | on HN ]

Re:ZetaVM, my new compiler project by sitkack on Sunday April 30, 2017 @01:57PM (#14232874)

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.

[ Parent | on HN ]

Re:ZetaVM, my new compiler project by akkartik on Sunday April 30, 2017 @02:05PM (#14232925)

Interesting. Can you show an example of how Lua's interface to the underlying platform improves on Python? Doesn't replacing APIs with protocols merely shift the breakage to higher-level logical errors rather than lower-level mechanical ones?

[ Parent | on HN ]

Re:ZetaVM, my new compiler project by sitkack on Monday May 01, 2017 @12:51AM (#14235642)

Lua is under-coupled with the base system. For the longest time it wouldn't even support dynamically loaded modules because it wasn't portable. It wasn't part of C89.

So when one uses Lua, it is up to the user to supply IO. This threading through the needle or hour-glass allows the users (embedder) to define how the scripts interact with the base system. This makes them more resilient over time, the interactions are better specified and highly mediated.

Somewhat analogous to the library vs framework dichotomy. Libraries survive better than frameworks do.

[ Parent | on HN ]

Re:ZetaVM, my new compiler project by akkartik on Monday May 01, 2017 @02:30AM (#14235947)

Fascinating! Seems to have some commonality with dependency injection, which is one of my interests (https://github.com/akkartik/mu#readme)

Can you point me at any Lua docs where I can read more about overriding IO in Lua?

[ Parent | on HN ]