Concern: boilerplate code

[matejpavlovic]

Original concern

Programming in Mir framework seems to require
a significant amount of boilerplate code due to its event-based
architecture. Each new operation requires to define a new event
sub-/type, as well as additional code to conveniently construct and
properly dispatch the new event sub-/type.

(copied @sergefdrv 's post in umbrella discussion #46 )

[matejpavlovic]

Yes, the boilerplate code around the protobuf events is non-negligible.
I think this is mostly due to using Protobufs to represent the internal events.
The use of Protobufs is inherited from the previous implementation and
the inconvenience it causes was, in my subjective experience, never big enough to make me look for alternatives.
However, I am not attached to it and if you know of better ways to represent the events, let's discuss them (probably there are).

The disadvantages of Protobuf events lie mostly in the extra code that needs to be written to define and create them.
The need for all this code at least partly comes from the fact that they are strongly typed
(i.e., a logically different event type is represented as a different Go language-level type).
In particular

• Especially the union ("oneof") type that is particularly useful in this kind of application is also particularly clumsy to represent in Go.
• If we were not constrained by the typing system and used a more generic way of representing the events (e.g. JSON),
  part of the boilerplate code might be avoidable.
• Protobufs don't even guarantee deterministic serialization,
  requiring separate serialization code where deterministic serialization is required (although most of the time it is not)

On the other hand, I also had the following considerations:

• Part of the boilerplate code is not really necessary.
  The Protobuf objects could be easily constructed in-line, without the extra level of indirection (constructor functions),
  it would just be a bit more verbose (and more error-prone in case an event definition is modified).
• While the boilerplate code might be relatively voluminous for what it does,
  it has a very low cognitive complexity.
  It could almost be generated by the protobuf compiler.
  It can be written quite mindlessly and very fast.
  The time I spend writing the boilerplate code is negligible compared to figuring out and writing the rest of the code.
• The price (extra boilerplate) we pay for the strongly typed Protobufs is not for nothing.
  What we get is that, once the boilerplate is written, the compiler almost doesn't let us use the events incorrectly.
  This partly applies to the boilerplate itself, where mistakes are unlikely.

Side note: The implementation is work in progress and the current code defining and creating events
is a bit messy at this point.
After cleaning it up and giving it a clear uniform structure, it may turn out less bad than it looks now.

Bottom line: Unless we get rid of the whole event-based architecture altogether
(which I would really prefer not doing, as such an architecture brings many benefits at a much more fundamental level),
let's look for ways of getting rid of unnecessary boilerplate code.
Switching to a more lightweight (but ideally still properly typed) representation of events could be a viable option.
Any ideas / proposals are welcome.

[sergefdrv]

I am not particularly concerned about using Protobuf. In fact, it provides serialization capability out of the box, which is often very convenient. I am certainly in favor of helper function (e.g. constructors) and other abstract wrappers since they achieve better decoupling and separation of concerns.

In principle, the event-driven architecture requires extra code to define event types and event dispatching. In alternative approaches to achieve modularity, e.g. dependency injection, one often needs to define additional abstractions, but dispatching seems to happen more naturally and easier to follow.

[matejpavlovic]

I'm not quite sure I understand. We seem to agree that additional abstractions are beneficial and necessary for achieving modularity, and that writing code to properly encapsulate them is also not an issue (from the original post it seemed to me that this was the main issue).
By boilerplate code, do you mean mostly the implementation of the event loop? Or the applyEvent() method of a module that reads the event type and then calls the appropriate handler?

[sergefdrv]

Yes, I think my intuition was that the event dispatching code is going to be inconvenient to write and follow.

[matejpavlovic]

Ah ok now I understand it better. I don't consider the event dispatching code (event loop, event buffers, etc.) to be boilerplate, at least not most of it. I consider it to be the implementation of the Mir framework.

The event-dispatching code needs to be written once (which it mostly is already, modulo small adaptations we might need to find useful in the future) and it provides a sort of execution engine (or runtime) for many different distributed protocols (those protocols being expressed in the form of event handlers, like they are in distributed algorithm literature). Whoever uses Mir or implements a protocol in Mir does not need to write or follow that code, the same way as a Java programmer does not need to follow the JVM implementation. Admittedly, the separation is not as strict as for the JVM and a Java program, but the protocol implementer mostly need not deal with the dispatcher code, except for, maybe, trivial modifications like adding support for new types of events (and even that is less and less necessary, because most of the useful events already have been defined).