Functional programming has been in the top of the hype-cycle for decades: no side effects, methods written in a purely mathematical style, strong type systems… What’s not to like about functional programming? It’s even a loaded term! Just ask someone: “But is not your code functional , yet?”

Although the Turing machine (imperative) model of computation was shown to be equivalent to the λ‑calculus (functional), there’s actually a long gap in its asymptotics.

Start with the most simple of the data structures, the array: in a purely functional style of programming, to update an array you would need O(log N) time, but in an imperative language it’s just O(1). And this is not a specific problem with arrays, it’s the standard behaviour within pure functional programming languages due to the their overrated immutability of data: in “Pure versus Impure LISP”, it’s shown that O(N) functional programs written with lazy, non-strict evaluation semantics can be translated to a purely functional style in O(N log N). That is, at worst an O(log N) slowdown per operation may occur by simulating mutable memory access: immutability carries a very high cost, indeed.

In practice, extensions to the pure functional paradigm have been considered to address the need to directly reference and change the state of variables (monads in Haskell), and most algorithms can be implemented efficiently by using purely functional programming, but it also involves extensive and difficult knowledge (“[amazon_link id=“0521663504” target=“_blank” ]Purely Functional Data Structures[/amazon_link]”) for even the most basic of data structures, and the recognition  that they require a significant slowdown by constant factors and CPU stalling due to many cache misses.

And, as if that is not enough, debugging any functional program is a quest in itself: I would say that it’s an order of magnitude more difficult than an imperative language, vastly increasing software maintenance costs.

The best Python libraries I recommend to play with:

1. 1. SymPy, a Python library for symbolic mathematics
   2. Pattern, web mining module for Python
   3. NLTK, natural language processing with Python
   4. Scapy, interactive packet manipulation program
   5. Bitey and llvm-py, to import and modify LLVM bytecode

The architecture of a software product and its underlying infrastructure is not totally determined by its intended functionality, but it tends to mirror the structure of the organization in which it is developed (mirroring hypothesis): this effect is so strong that an order of magnitude in component modularity is observed between the software made within tightly coupled and distributed development teams, consistent with the view that distributed teams tend to develop more modular products. That is, the ultimate software architecture is just a copycat of the communication structures of the organizations and their interactions, reflecting the quality and nature of the real-world interpersonal communications between the teams in its various degrees of integration: having a common and clear mission, their physical closeness and possessing formal authority over others to control development.

So be it, software created by distributed teams with misaligned incentives under the routine of design by committee will only give rise to wars of specifications. Human nature being what it is, will generate power-plays in the distribution of information impacting product quality, as the structure of a system tends to reflect the power relationships and status of the people and organizations involved.

The process of software design rests on a shared mental process between the software developers: the search space of its architecture is constrained by the nature of the organization within which this search happens. In closed systems, it’s widely but wrongly believed that the designs are highly modular: on the contrary, dependency density and propagation costs run high, and project schedules fall apart during component integration, specially due to the indirect system dependencies.

In the largest study to date to the arguably largest and most successful codebase in the world, the Windows operating system, it was found that organizational structure metrics were better predictors for classifying failure-prone binaries that other models using traditional metrics of code churn, code complexity, code coverage, code dependencies and pre-release defect measures. Hence, as much though is ironically given to software architecture, it turns out that a well-planned organization with the proper checks and balances is the key to reduce the amount of communication and coördination necessary for the success of software projects. And then, and only then, trust and the willingness to communicate openly and effectively, shall follow.

As it turns out, Conway’s Law, the old adage commonly invoked in Computer Science to sum up these ideas, is but a version of a much older story, the techno-reenactment of the Tower of Babel (Genesis 11:1–9).