replicator.org ... incoherent code

User interface libraries contain controls for editing data. For example, text boxes, radio buttons and buttons.

They combine data visualization with user input, which seems convenient for developers.

“Rendering” presents content to the user. Input processing handles the feedback the user gives back to the controls.

Obviously, these are two completely different concepts:

I assume that the the combination of input processing and rendering in “controls” is seriously flawed and causes user interface development to be perceived as hard.

Input processing needs to be separated from control rendering because they differ in so many ways:

In time

Rendering needs to be available at any time. As soon the presentation model changes, it needs to be invoked.

User input needs to be processed at the time a control is focused.

On the surface

To update only parts of the screen, rendering should be partial; it may modify only parts on the screen at a time. Visually, it is expected to work in parallel.

User input processing happens in one screen area at a time.

Of performance

Rendering must be fast to keep the eye pleased. It may be parallelized to run on multiple cores.

Input handling may be processed much slower in a single thread.

In implementation complexity

Rendering is conceptually simple: structured data is rendered to a bitmap.

Input processing is more complex, it maintains focus states, may handle text input and processes different input devices.

Of relations

Rendering just reads the data model and writes to the screen bitmap.

Input handling reads and writes the data model, it even modifies what is temporarily rendered and how (the view model). Additionally, it listens to events and maintains a set of internal states.

Of states

Rendering does not need to maintain temporary states.

Input controls often implement large state machines.

Because of these huge differences, a number of essential conflicts are present in all frameworks I know:

• The complexity of event processing and calling back into the application binds all controls to the UI thread, and so they may not respond fast enough for rendering. Therefore, incremental rendering is often impossible, rendering can not be parallelized, output must be cached and a lot of memory is wasted.
• Input controls maintain a lot of states, even when they are invisible the waste memory.
• Virtualization (the selective instantiation / rendering of controls depending on the visible area) is hard, because event handling and focus processing is not separated.

• Separation of the domain model and the view model gets hard, because the roles of the controls are not clearly defined.

To avoid these conflicts, input processing and rendering should be separated:

My suggestion to user interface framework developer:

Introduce the concept of sensor fields that have no rendered representation and instantiate the required input (control / logic) at the time they get used.

My suggestion for the user interface developer:

Render output-only “components” and overlay edit controls at times when the user actually requires them. For high performance applications, use a fast rendering library instead and overlay edit controls from your favorite UI framework when required.

yours
armin

What’s wrong with application software: In five words: It fails to act social.

The granularity in which components are talking to each other is the computer. The channels they are communicating with is the network.

This is not enough. Software needs to get social. Components need to talk to others via asynchronous messages. Messages that can be targeted or broadcasted.

Imagine a system where components can access and modify your personal tag cloud. Components can “see” their environment and act cooperatively to present or transform data.

New files and data flow into the system: Every component may be able to access and interpret them in different ways, presenting the user with a number of diverse options.

Data’s visualizations need to be integrated in a common user experience. One that is scalable, compatible with future hardware and input devices, a 2D zooming interface.

Data entered and edited can be shared. Users can collaborate, live edit and act on multiple version branches. Conflicts can be resolved visually.

Data is stored forever, it is never lost, all revisions, every change.

Data is secure, can be moved via network at any time, so can their visualizations.

Components’ code is treated like data, everyone can produce them, everyone can use them, security is built in – based on social trust.

An environment with a common UI, automatic parallelism, a spatially indexed database and infinite room for extensibility, socially.

Make your apps more like you, act social!

yours
armin

Notes:

• All the techniques for the above vision are available, someone needs to act.

• Browsers will fail as long there is a central Document Object Model.

One thing that bothers me, is that code I’ve written months before looks alien to me.

The question is why? Is it just the memory that fades or are there other factors involved?

Two assumptions:

• While writing code, the understanding of the problem and the context is at the highest peak ever for that particular piece of code. Meaning that you will probably never get into a state to fully understand all the details again. That explains the complexity which is so often observed in an initial implementation. Therefore, continuous refactoring is an important step to lower the detail awareness that is required to understand code over time.

• Even if you fully understand a piece of code, it may hard to use it, and this leads me to a related observation:

The processes of learning and creating get mixed seamlessly. Especially when there is Internet around, there is no differentiation. You learn and create at the same time.

But creating and learning are a distinct processes. They may use different brain mechanics and so should be separated while developing software.

This leads to a number of consequences:

• It is disrupting to look up for information while you are writing code. I.e. when you spot yourself switching to a browser looking for a solution to an algorithmic problem or the syntax of an API call, you switch to a learning and gathering mode which is far off from your creative flow you want to keep running. A good advice is: keep the creative flow, write the problem down and circumvent it with your current expertise and knowledge. But: take your time to research and fix the problem later on.
• Discriminate learning tasks from doing tasks as good as you can. I think that the success of Test Driven Development originates from this fundamental principle: The separation of the creative and the learning tasks in discrete units. Writing tests and debugging is more about learning how code works and is used. Writing and refactoring the code to be tested is the creative part.

• A good sign of a proper development process is either the flow, which is – as soon we collected enough knowledge about the details – a single stream of creativeness. Or the dance, in which we consciously and continuously switch between creating and learning.

I think it is worth to internalize: Learning is different from creating, meaning that even if we create something by ourselves, we need to take the time learn it.

Keep flowing and dancing,

yours
armin

One of my projects in which I have invested about 9 months of work is approaching a new stage what I am starting to call software post-production.

I’ve reused the term from movie productions because of the similar intent: Movies need to go through post-production to enhance their visual and audible appearance. Post-production is the process that converts a draft-product in a sellable product.

This blog entry is just about a number of hacks I use in a setup that requires explorer.exe to be restarted.

I don’t want to start a discussion whether this is good practice or not.

Rebooting was not an option.

Learning from failures

Over the years I have tried to implement several systems that should – what I called it – revolutionize the perception on what software can do. Actually, I would have been pretty satisfied, if one of these systems would have grown out of its infant stages and so spread out to a wider audience.

In restrospect I now clearly see that – programming for one self – especially when having a broader perspective, may lead to software that is profoundly overengineered and so – caused by perfectionism and paranoia – is clearly violating the YAGNI principle.

I am sure you have heard from the new Email client google wave that is currently in a limited user invite-only testing stage.

Now people may wonder what are the differences to regular Email clients? The answer to that question could be the feature list, but that does not actually reveal what it feels like to use wave.

While writing a .NET based wizard engine I thought it would be fine to use an IoC container.

The concepts behind are pretty simple: Instead of creating an instance of a class, an IoC lets you specify explicit requirements in the form of interfaces (services) that are injected into a object instance before use. These services need to be registered and be available at the time of the instantiation.

Databases don’t store collections, they store tables. If some data needs to be stored as a list, it needs to be normalized. Usually meaning that a new table is required. For example: to get the collection of a 1:n relationship, an SQL query is processed to select a subset of that table.

Projected to object orientation, a table is a collection of all instances of the same class.

Why this matters? Because a collection is a concept that is not easily implementable in self-adjusting computation.

Following Conway’s law:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

We are starting to get more serious about making programming more like the world actually seems to work.