On Flexibility and Software Temples

It's easy to assume that the idea of editing text is simple. It's such a basic task, and most people who touch a keyboard get away with it just fine.

And that assumption is only a short leap away from the claim that text editors should be simple to use as well. It paints a clear picture where an editor is a finished product.

All you have to do is shove in enough features in there.

Human-computer interaction = Features.

And this is the way that most text editors are written: let's build our vision of a product, and when the users complain, we will shove in MORE STUFF.

The philosophy, for most editors, is: just do whatever feels right. In other words, there's none.

Are features enough, though? Far from it!

The really one right thing to bet on seems to be the user experience. And there's a lot of stuff that goes into building it.

You can reason about it in more concrete terms: pillars. Pillars are used to construct temples and other sorts of buildings. (Considering the nature of the discussion, the religious connotation is not too far off, though.)

So, OK, let's build a temple. From scratch.

Take all of the features you want in your editor – well, those are your pillars.

And make no mistake, there are some pillars other than features: the ergonomics, the learning curve, the execution speed, the memory footprint.

Beneath all that are all the technologies used to build the foundation and the pillars. The language. You can think of it at the building material for everything else.

Do your materials fit and work well with each other? If so, then they may be called homogeneous.

And the real foundations beneath all are: extensibility, flexibility¹ You will be hearing this word a lot very soon., power. These are the metapillars. The language is a metapillar, too. Metapillars define the properties of the pillars, exercise a direct degree of influence on them.

At the foundation of the pillars and the metapillars, which are undoubtedly made of curtain materials, there lie the bones beneath it all. These are the meta²pillar of the community and the developers, the architects and the voluntary workforce.

Of course, there's also an antagonist to this little story.

The antipillar of shit.

It's called the world, and it contains everything and anything that wants to destroy any given temple of text editing. Those forces are the sea storms, the anti-religious governments, the earthquakes, the businessmen. Other temples and their adherents.

—

It may be tempting to say that the user experience is where it ends, but, really, it's where it all begins. Because make no mistake: the user experience is not just the roof of the temple, standing over all kinds of pillars. It's the whole damn temple.

And we have traced a rather interesting blueprint for that temple: the pillars of features and a few visible properties, the metapillars of power and language, and the meta-meta-pillar of the community.

Well, most editor-building efforts concentrate on features. They are feature-centric. They make it all about the pillars. And the reason for this prevalent attitude is simple: it's easier to provide a feature than it is to provide a power.

And the metapillar of power is effectively never considered. The power to change the temple. And that may as well be how we build real temples, but its lack is a blatant oversight for the temples of software.

Software should be more like a living organism if it is ever to mold to the user. Not a product – a construction box. Not a temple.

Feature-centrism is not the path to powerful software, no matter how cool or advanced are the pillars.

There are a lot of classic temples out there: nano, notepad, gedit. To name a few.

Where does Vim stand? Vim is pretty good on speed and footprint, a bit tough on the learning curve, and has great ergonomics once you get it.

But it's almost a classic feature-centric temple. Almost. It does give you a bit of power through its configuration mechanisms. It has a pretty contemptible and primitive configuration mechanism, but it's undeniably there.

Emacs? Well, Emacs got Elisp. Emacs actually addressed the fact that the user might want to reconstruct the temple to his own liking.

Can Vim outlast Emacs? Well, guess not, because, as a matter of fact, it has already been replaced by another temple: NeoVim. That one has more features with just slightly more power. Still, it's pretty far from Emacs. Plus homogeneity effectively got destroyed when they allowed multiple languages. But considering how bad VimScript was, the net effect must have been positive (in the short term, anyway; otherwise non-homogeneity will still bite them in the ass big time some day).

Emacs did not disregard the power of power, and that's why it is still going at it after 40 something years.

Of course, Emacs is far from perfect. It lets you do a lot, but the more you move away from its turtle sandbox game, the more fucked up it's going to get for you.

And its offshoots were but temporary distractions, temporary forks whose advances swiftly found their way back to the original effort.

Those advances were but features. Couldn't have happened otherwise. And the meta²pillars (the community) were a stronger force.

Emacs is defined by its metapillar of power, that's how it's understood by the people who use it. And that's why the New Emacs can't be just another Emacs.

And it certainly can't be replaced by anything less powerful. Products like vscode are just classic temples, because that's all corpos have learned to strive for. Claiming that it can overtake Emacs is absurd.

And not in the least because of other metapillars such as the language and the horrendous tech stack. And most importantly, that's how the community understands it: as a conglomerate of features.

It's an old way of thinking about software. Software built that way is literally not alive. It's just waiting to be buried. And that's exactly where these type of efforts end up: in the trash bin of history.

I don't think it's bad that legacy software gets replaced once in a while. But the way these are built, the new replacement is not ever much of a conceptual improvement. They just rearrange the pillars and swap the metapillars for close alternatives. And that's what will happen to vscode: it will get buried and replaced by something vaguely reminiscent of itself.

But mere features can't replace Emacs. Because there's power to it.

So, it's important that we examine the concept of power if we are to understand software engineering better.

Programmers love to talk about power in a vacuum. The power of languages. The power of systems.

Some mistake Turing-completeness for power, for fuck's sake.

Well, I like to talk about power, too. And for me, power lies in flexibility.

And by flexibility I mean the ease of making a system in question specialized.

That means the ability to swap a certain mechanism, a certain way of doing things in your system to something else. Adaptation.

And since you could specialize anything if you tried hard enough, the principal measure of flexibility is the ease of exercising it.

And, perhaps, the ease of learning it too.

In other words:

If you can't wield the power, you don't have the power.

To give a crude example: if your program is written in C, I have to recompile it to apply changes I have just added to the source code. That means I have to restart the program. It's not much of a power of you have to interrupt it.

And if your program is too cryptic for me to understand, or if it's designed badly, or if its architecture is not flexible enough to allow the modifications I want, I am all less powerful for it, even though, in principle, the changes that I want are possible.

So, flexibility lets you change a given system to your liking, to extend and specialize it to your purpose. And a truly powerful system will let you do it easily.

But one of the most striking effects of flexibility has to do with efficiency.

I have encountered multiple times a belief of sorts among programmers that flexibility hurts efficiency (as in speed). That's a shallow understanding of what flexibility is.

First of all, there are at least two kinds of efficiency (and we will add another one by the end of this article):

• Efficiency as in the user capability.
• Efficiency as in speed.

And how can we get efficiency? I think there are two ways:

• Efficiency via specialization.
• Efficiency via flexibility to specialize.

Without an argument, flexibility amplifies user efficiency. The user becomes more efficient in using the system as he specializes the system to his own needs.

Various systems try to accomplish user efficiency via building specialized inflexible systems where they pretend they know what the user needs. This is what most software does.

These systems exercise control. And every time they change the way system works, the user has to deal with it.

Other kinds of systems grant the power to the user. Needless to say, these are perceived as the more efficient environments.

Now, what about the execution speed?

Well, whenever you have a system with inputs predictable by the user, but not by the system's architect, the architect may leave the user the flexibility to adopt the system to the input.

In that case, the user may choose ways of dealing with the input more efficiently, yielding better speed.

The architects, in order for them to design a general-purpose system, are forced to use general-purpose algorithms/data-structures/constructs.

The power to swap a general-purpose algorithm or data structure for a better-suited alternative will easily yield better efficiency. And that's what the flexibility of specialization is all about.

Flexibility is usually associated with some minor constant-time penalty. But it doesn't even have to be: not if you provide the flexibility to change the levels of flexibility of a certain subsystem. Think of runtime recompilation.

Flexibility to specialize is, without a shred of doubt, superior to mere specialization if your goal is efficiency of speed and user capability.

Now, before we take this discussion any further, we first need to consider the relationship between flexibility and bloat.

Petrified strata of features emerge in the infinite vacuous spaces of power that never was.

Lack of flexibility invariably results in bloat.

Specialization without flexibility yields inefficiencies of all kinds due to eventual misuse.

Flexibility without specialization is not flexibility. It's just a generalization, which is inefficient by definition. A generic approach without any mechanism to specialize will result in all kinds of inefficiencies.

We have seen all this happen to browsers. We have seen it happen to Emacs. To the operating systems and to their ecosystems. To the command line interfaces.

All these systems lack the appropriate building blocks for what they are attempted to be used for. In other words, most such systems are misused.

Let's take a closer look at some examples of systematic bloat due to inflexibility and misuse.

Bloat is superfluous repetition. It's caused by the lack of appropriate compression mechanisms.

Flexibility of a system is its capacity to change and adapt in order to suit efficiency demands (which include preventing unnecessary repetition).

With these two definitions in mind, inflexibility can be said to be the only source of bloat once the system gets used for the purposes it wasn't suited for (i.e. misused). (Although, there are, of course, many ways to get an inflexible system.)

And so, in case of misuse, any kind of bloat can be traced back to a source of inflexibility.

Sometimes, power refers to the feature-set of a software system. However, features have little to do with the capacity of a system to easily adapt to the unseen-before requirements. But this latter capacity is the definition of power that is actually useful to adopt in the context of software development. This includes the power of the user, of course. So:

Flexibility is the only source and measure of power of a software system.

Bloat is commonly referred to as unnecessary complexity, implying lack of simplicity, that the system isn't powerful enough to reduce the complexity. So, if you agree with equivalence of power and flexibility, then we can conclude that the lack of simplicity is due to the lack of flexibility as well.

But while it's pretty common to discuss powerful ideas as a way to reduce bloat, it's not very common at assume that flexibility has anything to do with it. In my opinion, it has everything to with it.

Think of abstractions in software. The cost of abstractions is high, it may seem, and is indeed the experience of many software authors. The way I see it: they just didn't have the meta-flexibility to deal with these abstractions, to reduce the bloat within the abstractions themselves. They couldn't do the right abstractions because the system in which they were writing those abstractions, the metapillars, weren't powerful enough. They were working within the kind of constraints that didn't allow for the right approach.

But, in my opinion, one of the largest reasons why abstractions get a bad rap (and rightfully so) is because of a huge flexibility vacuum.

Most often, this means the language. Or the "framework" within it. Or the paradigm. And since the inflexibility in case of misuse leads to bloat, the abstractions written within these pillars will then be costly and inefficient. And so we call this kind of bloat over-engineering.

So, the solution should most often not be to search for a better abstraction within a system, but either to switch to a different system or make the existing system more flexible.

Speaking of software design, one other matter that often gets confused is the talk about application programming interfaces (APIs), as if an API is what constitutes the quality of a system to its user. It's as if, if the API of a library is good, it doesn't matter what goes in beneath the surface, and the library itself is good.

But APIs, by themselves, do not constitute flexibility. If a piece of software is to be powerful, it must be flexible, and, by itself, an API is not the answer. What is, then?

I think, flexibility must come from building blocks. And inflexibility is caused by their lack or their inadequacy.

Real flexibility (and, thus, power) never stems from an API. The notion of an API is orthogonal to that of flexibility or the building blocks.

What's a building block? It's a notion within a system that is itself defined by the properties of its interaction with the rest of the system and with the copies of itself; by the nature of its operation. A building block could be an object or a process or even a concept. Ultimately, I think, it's a thought in your head, and then your formalized understanding of how your system should operate to provide the kind of efficiencies that you are aiming for.

But the two traits of building blocks seem to be:

• specialized reuse, and
• interoperation/contact with other blocks of the system.

Flexibility seems to spring from an appropriate set of building blocks. They should be directly accessible to the user, and if there's API, then it should simply reflect the nature of these blocks.

A good example of a building block is code in Lisp, a programmable programming language. Code is just data. And the user may exploit this fact via macros to a great effect. The macro system is an API to the building block of code.

We can define homogeneity as the degree of interoperability and compatibility between a building block and the rest of the system, including other building blocks and itself.

Lack of homogeneity is one of the greatest causes of inflexibility. A bad building block infects and jams the system in which it is operating.

Ever heard a complaint that there isn't enough reuse in software? Well, the reason there isn't enough reuse is that we use incompatible systems of expression, meaning that the building blocks can't interoperate. Most often that means the use of incompatible languages.

Therefore, we are bound to have incredible amounts of code that is similar in purpose but different in appearance.

But web is also guilty of this: it separates the source of a web page from the resulting web page itself. But the data and its presentation, even if separated, should both be a part of the same configurable environment. I discuss this point in this article.

The proliferation of modern web-technologies and non-compatible languages are a testament to the fact that the requirement of homogeneity is neglected. And that's why there's no flexibility and there is so much bloat.

We prize biological systems for the capability to adapt.

And, with time, we can even get quite fast at what we practice a whole lot.

One might say that we can't be too efficient, though, that there's a limit to efficiency, and that this is because flexibility has a cost; that if you build a specialized robot, then that robot will be much more efficient (in terms of execution speed) than some meatbag, such as one of ourselves.

Now, that's an interesting example, because that's when you need to start thinking about meta-flexibility. The kind of flexibility that tells you how flexible you want your current variant of a system to be.

It's the flexibility that lets you easily glide between the different kinds of tradeoffs, the kind which would let you turn your organism into a robot OR an organism that can learn and adapt, or, in fact, be anything in between.

Meta-flexibility is, of course, still flexibility at some conceptually-higher level of the system. And, so, flexibility can be very much responsible for providing high efficiency of execution.

And in a programming system, you would want to have such flexibility on a contextual basis, where you can adjust whole subsystems to your particular liking.

I don't believe there's any programming language out there that consciously explores this extreme. Not even Common Lisp or Smalltalk.

Common Lisp, for instance, is garbage-collected, so you can't really change that and proclaim you are going to be doing something manually in a certain part of the program.

Neither could you restrict a certain part of the program to use continuations, because that's not the model of execution that CL adopts.

(But, of course, even though the macro system and the gradual typing system are not devices of meta-flexibility at the core level, they may still be instrumental to creating sublanguages that reduce flexibility for the gain of specialization and, thus, performance.)

And while the practical necessity of such extreme control may appear questionable at first, it seems that the hesitation lasts just until you start seeing the new possibilities: not only to glide between tradeoffs, but also be able to do so as if the flexibility mechanism wasn't there in the first place.

And, in general, from the standpoint of meta-flexibility, if a part of a language adapts a certain philosophy or a way of doing things, that part needs to be able to change. And whatever section of code or a system you have, you should be able to change the flexibility level just for that piece of code; to exercise change over limited sets of building blocks, and not just over all of them at once. Sometimes, this means contextual execution. Sometimes: just the assignment of certain properties to individual blocks. And both.

I don't know what such a language would be like, the kind of language that fully introspects its own definitions with respect to the particular programs written in it.

I don't mean syntax, of course. I am certain that it could just be a Lisp. The interesting part is how flexibility of flexibility would work; how seemingly incompatible ideas blend, coexist and get embedded within one another. Some of the obvious targets include the typing systems, the runtime/compilation control, the memory models, the object models.

There is no one silver bullet, it seems, only the way of specialization within a flexible system that supports and harmonizes orthogonal modes of thinking.

So, I think, what we perceive as religious questions in programming is often but the lack of the flexibility in our programming systems.

For instance, two programmers may have different preferences of a language, and yet will likely agree that you should use the right tool for the job (to the point that this saying has become a terrible cliche). So, that must mean, if the languages are truly different, then the right one needs to be chosen. So, the only outcome of this is that neither is powerful enough to imitate the other one.

The only real measure of the right language for all jobs, then, seems to be, indeed, flexibility.

If premature optimization is the root of all evil, then inflexibility is its square.

Premature optimization often results in inflexible systems.

Premature optimization leads to shackles, a diversion from flexibility.

Perhaps, the reason why we have been so concentrated on optimization is because we can measure and perceive it. There's no such measurement for flexibility, nor is it readily perceptible. You have to look into the system to see if its really there.

—

The other evil kind of optimization is misguided optimization. It's an attempt to optimize a general-purpose data structure instead of providing the flexibility for the user to adapt to the particular input that he has.

Attempts to optimize a general data structure are never enough, and so come things like caching and, eventually, a desire to infer and convert between the general-purpose structure and an ad-hoc specialized structure (instead of just having a general interface to specialized structures).

Needless to say, this leads to an explosion in code complexity and size.

Misguided optimization and fucking bloat are like fire and smoke.

And it doesn't just end with bloat: the system becomes increasingly hard to develop and use, and, what's more, optimal execution efficiency is never achieved.

I have discussed this kind of optimization in the section on hardware, above. Another class of misguided optimizations may be said to include just about any optimization in a string-based text editor. (See the Rune section in The Power of Structure for a discussion.)

Bloat usually originates from poor expression capabilities of the system – the language is not flexible enough to describe a certain state of the system.

So, a system capable of dealing with bloat may be said to have efficiency of expression. That's one kind of efficiency.

Then there's efficiency of execution and it comes from the ability of the system to specialize to the user input or its own structure.

At last, if a user is capable of easily accomplishing what he wants within a system, the system may be said to have good efficiency of user capability.

All three kinds of efficiency may heavily benefit from and sometimes must originate in the flexibility across the system.

In other words, flexibility is instrumental to efficiency – of any kind.

Most software falls short on this metric, and, thus, typically, on all dimensions of efficiency.

Power lies in the ability of the system to adapt, to specialize. Specialization requires the meta knowledge about the input, its structure. So, it's important that structure doesn't get prematurely lost.

Failure to preserve or infer structure in advance is known to cause a lot of problems, such as in the case of text editors.³ Again, I address this issue in The Power of Structure.

So, universal structures, documents, containers etc. can only be truly efficient if the system allows specializing on them.

You can't have flexibility without the knowledge about structure.

Most software systems and ecosystems in existence are a huge mess. They are inefficient on all levels. Often times, the reason for this is precisely the lack flexibility, the lack of the appropriate building blocks.

And these systems, themselves being inflexible, in turn cause inflexibility of thought within whole communities, the kind of thought that prevents progress due to the sunk costs of development, due to the inability to start from scratch.

Inflexibility acts like a broken piece of equipment within a machine. Inflexibility is pathogenic in the sense that it causes other parts of the system to become inflexible just like itself.

And then, it is often assumed that generality is enough.

But that's not true.

A thing too general fails to be efficient in the face of a specialized problem. Most computer-related tasks, and, arguably, all the useful ones, are structured. Which means it's often possible to designate certain problems as specialized.

But most general-purpose system are not flexible enough to provide specialized efficiency on demand.

And a general-purpose system that doesn't provide sufficient specialization mechanisms will eventually get misused, yielding all kinds of inefficiencies.

And that's a source of a lot of problems in modern computing.

The reason why the userspace is so bloated is that our operating systems don't provide us with good building blocks, and because the building blocks that they provide (like the notions of files and executable blobs) are too rudimentary.

Instead of constructing high-level environments to write specialized programs with high reuse value, we instead employ low-level languages to optimize general structures, and those general structures end up being kitchen sinks.

And then, most programming languages make specialization hard to impossible, and absolutely disregard flexibility of expression. No wonder, programs written in these end up being over-engineered and full of boilerplate.

The systematic bloat in software systems reflects the inefficiencies of our thoughts across the whole computational man-made landscape. And we have riddled that landscape with the temples erected out of pillars of our flawed understanding of how to deal with flexibility at such scales.

I am convinced that whenever you see bloat, whenever you see pillars that construct priestly temples, that's where you will find inflexibility of viewpoint, extension and change, that's where you will find no proper regard for user experience whatsoever.

And while it's only my limited experience, I think it's pretty common in the programming circles to speak of power and simplicity and good abstractions, but barely ever mention flexibility.

Flexibility is often opposed to execution efficiency. It is said to incur a cost. But, on the contrary, some part of a system is simply not flexible enough to specialize on the costly flexible elements influenced by it.

Low performance is not a problem of being too flexible, it's a problem of not being flexible enough.

The only cost of a truly flexible system are the costs of time and effort to develop the right set of the core building blocks along with the ways of making them work together.

There are, of course, ideas, such as late binding, that enable flexibility, but, otherwise, flexibility is under the radar.

Even STEPS⁴ STEPS is an initiative of Viewpoints Research Institute to investigate powerful architectures with a purpose of reducing massive amounts of code bloat. See STEPS Toward the Reinvention of Programming, 2012 Final Report and the presentation by the team: T-Shirt Computing., which is, perhaps, the only initiative that attempted to attack all the mess head-on, never seemed to emphasize flexibility, but rather simplicity and bloat reduction. (It's still a great project, though.)

The cleverest of abstractions won't save us if we can't make them easily adapt to the local requirements of efficiency on demand.

Flexibility is the pillar of abstractions.

And so long as the inaccurate attitudes and views about flexibility persevere, so long will our computer environments be bloated, slow and user-hostile.

That's what I think the problem with modern software is. We build temples, and then we pray for them to play nicely with each other and with the user.

It won't happen.

Pillars build us temples that have preachers that can only tell you how nice the temple is. They won't let you touch the pillars. At most, you could only preach like they do.

The flexible, the adaptable, is the only kind of elegant. And an elegant system makes the user wonder what they can do instead of how they can get by.

Everything needs re-examination: the hardware, the operating systems, the languages, the user programs. It all has to become a cohesive system, with the building blocks exposed at every level.

Otherwise, we will continually be stuck within the mazes of temples.

Flexibility, perhaps, should become the primary measure of the wellness of a system from the perspective of software development.

Simplicity is an indicator of flexibility. And bloat is an indicator of its lack.

Flexibility requires homogeneity and the knowledge of structure within a system.

Flexibility arises from sets of cohesive building blocks and their properties.

Flexibility means the capability of a system to specialize itself and its parts.

Flexibility is evaluated by the ease of exercising it.

Flexibility to adjust the degree of flexibility (meta-flexibility) may at times be key to allowing efficient execution.

Flexibility is the capability of a system to adapt to the requirements of efficiency.

Flexibility ultimately results in efficiency:

• of expression,
• of user capability,
• of execution speed.

Flexibility is power.

Power is efficiency.

• ← Emacs is Not Enough
• Overcoming the Print-Statement →

• Table of Contents#
• Top#
• All Essays