state-managementdeclarative-programming

Can declarative programming be used for programming-in-the-large despite "inherited object" acting as a global object?


As a seasoned C++, Java, Python, Javascript, design patterns (MVC, ...), OO & functional programming, who is now learning declarative programming, I am stumped by the more than a little austere discussions about "state management approaches". I can't even put my hand on what they're talking about.

Suppose, for instance, that you know most chapters of Cormen et al. more than you care to admit, you know perfectly well that global variables lead to nasty and subtle mistakes that are tough to fish out, position your data as close as possible to the functions that will operate on that particular set of data, and then suddenly state management tells you that you actually need to create a global data object, position it as close to the root of your widget hierarchy as possible, and make that object available throughout your system.

Do you then not absolutely lose all hope for encapsulation? Does that "inherited" (the misuse of this word bugs me) object not suddenly become a global object that is effectively a global variable?

Now we've all written 5000 lines of code using global variables and gotten away with it. It's just that when we keep expanding the code that it becomes clear that it's becoming a nightmare. Are we then saying that declarative programming is meant for just a small user-facing app, and that the more serious code should still sit on some server? Are we saying that declarative programming is not meant for programming-in-the-large?


Solution

  • You probably tackled imperative, functional, logical and now declative programming. Declative tackles things like databases, grammars and mass data. Though suitable for all kind of problems.

    Now you would not like your bank account's programmer to write code determining which index to use and how to collect data from different tables' records. SQL is much more readable. Already primitively declarative; and truly declaritve with rule based processing works nicely.

    That is when order is introduced in a system. Where you are coming to understand things, and rely on cloaked implementation details like index selection.

    What you are stumbling upon looks like the problem with functional programming where types can become very complex and the code then hard to understand sometimes. Not seeing the forest through the trees.

    In my view declarative programming is very suited for larger data, as its traceability/verifyablity is much larger than other approaches. Also it theoretically is easier migrate the system.

    What can help is to register in the final produced result the steps taken to achieve the goal. Which is especially feasible in (sensible) declarative systems as opposed to operational systems.

    For learning programming it helps to tackle the problem abstractly and fill in what works. Ensure always that the approach and result is documented. Prototypes, test driven development.

    Sorry but I would like you to keep trying with declarative.