Online journals cannot be seriously interested in getting the public to purchase their content. Consider the case of the paper Error and the Will, which is typical (perhaps even on the low end) of what I've seen in terms of cost.

I came across this paper using Google Scholar. I can't find a digital copy anywhere, even using my alma mater's library system. I find myself asking these questions:

• Without knowing the content, should I spend the $30USD for it? That's a risky endeavour just to read it, not knowing if it contains something useful.
• I can "request permissions" to get a copy for personal use (although, oddly enough, "read it" is not one of the options when you do that, although "reuse in a thesis/dissertation" is). It takes up to five business days to see if that is acceptable and how much it will cost.
• If I'm trying to to write a paper and I want references -- say, 10-15 or so -- that will be well upwards of $300 just for the references I actually use, notwithstanding the ones I don't use. That's a huge risk with essentially no chance of a payoff.

Even if you are going to charge me to read something, at least learn a lesson from iTunes and Steam: make it easy and I won't bother with less "respectable" methods.

“The ability to reduce everything to simple fundamental laws does not imply the ability to start from those laws and reconstruct the universe.”— Philip Warren Anderson, More is Different

Something I have noticed in my time developing, reading about and researching software is the pervasive idea that because we can control the workings of small components, controlling large components is much the same. This can be seen in statements such as “all we need to do is hook A into B and we’re done!”

Unfortunately, there is some point at which the combination of components becomes an unwieldy mess and the ability to understand what is going on is effectively beyond its creator’s grasp.

Software development tends to happen by envisioning the system that you want to create, breaking it down into smaller components, making those components and then stitching them together. This kind of top-down approach is reductionism at work, something I rarely find gets acknowledged, and suggests to me it is taken for granted. I suspect it goes unacknowledged because of a tacit assumption that software can be written from a specification purely by deductive reasoning, a sentiment succinctly espoused by C.A.R. Hoare back in 1969:

“Computer programming is an exact science in that all the properties of a program and all the consequences of executing it in any given environment can, in principle, be found out from the text of the program itself by means of purely deductive reasoning.”

This assumes that “what goes down must come up”. It’s as if deconstruction is enough to predict the outcome of construction. That seems perversely arrogant.

Using reductionism to design and build software isn’t inherently wrong. What’s wrong is assuming that it’s sufficient. Part of the reason that it’s not sufficient is that when stitching the parts together you need a thorough, if not complete, understanding of the all the components in the environment in which the computation is taking place. In practice, it’s rare that you know what those components are and even if you do, many of them are physical and prone to failure or conscious and prone to whimsy.

Since it’s hard to know all the ways your components can be affected, when they get connected, this is the point at which the unwieldy mess starts to take hold and the illusion of control sets in.

What would it take to build software by giving up the control we may not have anyway? Is there more to it than genetic algorithms?