5.1 Evaluation

Things are open. This level of transparency lets the designers to create their own systems and include the necessary changes in the other apps to reflect this. This means that interoperable technologies and other systems that fit into the ecosystem can be introduced with much ease (Invoke the metaphor of LEGO here?)

Looking towards the future of this ecosystem, one of the things that I think would make sense is to have an . It can be administered from the documentation websites [cross-link] that have been mentioned previously.

Once systems are divided into relatively independent parts, the third step of the design process occurs: creating visual representations as fit solutions for each sub-part. These sub-parts are then visually fitted together into a whole.

Include in Appendix.

Single point of failure. A way to improve this can be found in the future section.

Current systems without fail would have bugs when corner cases arises. Even though I have tried to prevent them by writing tests, it only works to the effect of checking only for the problems that I could forsee. In another words, it is limited by my understanding of the problem. But the corner cases could be much larger than that.

If time allows, I would opt for test.check, a generative testing library that opts for far more coverage than traditional tests. But even then I think a better idea would be to create fault tolerant programs and this indicate that I have to allow for some resilience. The amount of resilience in the current software is very minimal to non-existent. If something goes wrong, some manual recovery from my part would be necessary to address these problems. This have to be eradicated and as I point out in the [link here] future section. This can possibly be addressed by adopting an Erlang like fault tolerant behaviour.

Clojure enabled EDN over the wire.

The decision to use functional programming has been great to appreciate the fact that there is more than one way to reach your destination. And as Alan Kay writes in Computer Software in Scientific American, the intellectual limits of Computers are not yet understood and this has been an experience which more emphasized the need to understand clay so as to construct better pots. Computers are capable of self-interpretation whose upper ceiling has not yet been understood.

Every complex system is made alive not by the code but by the action of people who use the system to their ends. Starts from March 1 with Bundles and ModuleBridge. The toughest test of the system is when it tries to be useful in contexts where the designer didn't indent it to work. It hence was an interesting experiment to see what kind of uses people liked to put these systems into.

The right kind of pessimism is one where you assess the problems even after something works. It is good to see these systems as good looking or may be even well performing but one of the core values underlying in the construction of such a system is to focus on the kinds of things that this disables and a few such views. But this is really limited as it's the creator evaluating these systems and it is any way going to be an attempt in futility because I'm behind the creation and there's only so much that I can see. I will leave it to the reader to assess the system, break it down and take away the components if any from the source code (if you can make your way through those lisp paranthesis first)

While tackling the project it is easy to miss the forest for the trees and the trees for the forest but it is even tougher to miss the incumbent drought that is about to hit the forest. I have exercised my utmost efforts at crafting the apps here, but for someone at my level of expertise can’t possible handle the extended usage and adaption of the ecosystem, constant pruning of the systems and subsystems is to be maintained if the ecosystem is to be prolonged.

Perhaps the best test of a system is how it acts when users try to achieve new things with this. Being the designer of this system I am illposed to judge this but I think it might be helpful to get information from others after having used this system for a reasonable amount of time.

Visualize.

Visualze.

If the use of the system is to be continued it has to be ensured that high precision performance tuning is only done after properly understanding the problem domain. Even if all the unit tests passes it doesn't guarantee that some of the combination of the functions and certain characterists which can never be unit tested. It is unreasonable to unit test everything. New changes introduce new pathways to failure.

These new forms of failure are difficult to see before the fact; attention is paid mostly to the putative beneficial characteristics of the changes. Because these new, high