4 ms·

That sounds great! Can you explain in more detail or point at an example? How do you provide typing across modules? With type hints? eDSLs instead of APIs - n

by eurekin 11y ago

That sounds great! Can you explain in more detail or point at an example? How do you provide typing across modules? With type hints? eDSLs instead of APIs - not changing client code... This sounds a little too good to be true. :) Can you provide an example. let's say for a UI form case?

sklogic 11y ago
> How do you provide typing across modules? With type hints? By only exporting simple functions (which only take DSL commands and return DSL commands) out of the modules - it works well with Racket and some other Scheme implementations, for example. In Clojure you can simulate this with namespaces and an explicit "(require ...)" which can be easily followed by the static tools. This way every name is either locally defined or coming from one of the modules you explicitly required, and with no higher order functions allowed in between modules you can track everything to its source. > let's say for a UI form case? That's the most classic example of this approach, used more widely than any other message DSL case. An UI frontend is forming messages (like "(button-clicked 'Save)" for the low level approach, or, for higher level, like "(ui-do-save)"). A backend is receiving nothing but a stream of DSL commands from the frontend (i.e., no API calls in between, the stream can even be serialised as text), and execute them one by one, replying with another stream of DSL commands for the frontend (like "(go-to-dialogue 'Choose-File)", or "(hide-save-options)"). The more abstract your command stream is, the less changes need to be propagated either way.
- rapala 11y ago
  That sounds exactly like encapsulation and message passing. The essence of OO according to Alan Kay.
  - sklogic 11y ago
    Not quite. OO messages are flat (a method + a number of arguments), while a DSL messages can have a very complex semantics (even Turing-complete, if necessary). What is common with the Kay view of OO (and different from all the modern OO languages) here is that messages are asynchronous, and this is a very important aspect.

by eurekin 11y ago

sklogic 11y ago

> How do you provide typing across modules? With type hints? By only exporting simple functions (which only take DSL commands and return DSL commands) out of the modules - it works well with Racket and some other Scheme implementations, for example. In Clojure you can simulate this with namespaces and an explicit "(require ...)" which can be easily followed by the static tools. This way every name is either locally defined or coming from one of the modules you explicitly required, and with no higher order functions allowed in between modules you can track everything to its source. > let's say for a UI form case? That's the most classic example of this approach, used more widely than any other message DSL case. An UI frontend is forming messages (like "(button-clicked 'Save)" for the low level approach, or, for higher level, like "(ui-do-save)"). A backend is receiving nothing but a stream of DSL commands from the frontend (i.e., no API calls in between, the stream can even be serialised as text), and execute them one by one, replying with another stream of DSL commands for the frontend (like "(go-to-dialogue 'Choose-File)", or "(hide-save-options)"). The more abstract your command stream is, the less changes need to be propagated either way.

rapala 11y ago
That sounds exactly like encapsulation and message passing. The essence of OO according to Alan Kay.
- sklogic 11y ago
  Not quite. OO messages are flat (a method + a number of arguments), while a DSL messages can have a very complex semantics (even Turing-complete, if necessary). What is common with the Kay view of OO (and different from all the modern OO languages) here is that messages are asynchronous, and this is a very important aspect.