[Main website]


In CL one can changes a lot of things and the run-time will be updated: function definitions; CLOS classes. In CL, after class definitions one had to call the API and finalize them. So the compiler can apply optimizations. Changes in structs require recompilation of code.

In Pharo is the same.

In Erlang there is a clear specification for live upgrading of the system.

For a programmer is more fun to code inside a live system.

CL, Erlang, relational DBMS are live-systems: they have rules about how to update the system while it is running. CL is a littlle weird, because in some cases there are no rules, like in case of struct, or because CLOS class must be finalized with an API. Erlang is more elegant.

Dok is in part a declarative system, so there must be a global analysis phase. Hence, this part can be incremental, but not live/interactive. But Dok compiles towards potentially live system run-times. So, at least during DEV phase, there can be a declaration of DEV run-time live system, and it is upgraded incrementally. It is not a problem if the system sometime must be restarted from scratch. In case the user must be advised. The system has rules on how upgrading it. The system can signal which parts can be broken beacuse there were no migration rules, that sometime are expensive and they are useful only for migrating production.

So the division between analysis and system, is useful also for seeing Dok as partially a declarative system, and partially as a live-system.

Another approach can be to have a declarative system (i.e. compile-time analysis) and a live notebook environment for examples of code usage. But this probably is more difficult to manage, because some parts of the queries are still declarative.

Another approach can be declaring notebooks, tests and so on, and at each change of code, another analysis is performed, and an update of the documents are produced, and the developer can see the differences.

TODO this page list live coding systems https://github.com/toplap/awesome-livecoding

Dok follows the contrary paradigmdok/paradigm/code-as-firsc-class-citizen