software is not unlimited either by logic or by the physical world. Rather the differences are differences in abstractions we come up to manage the differences in complexity.

Software is limited by the hardware it runs on; but those limitations are the hardware's limitations, not the software's.

I'll take this slowly, and that is not an implied insult to you, just a necessity, because either I'm really bad at conveying my message -- though historically I've been told I'm reasonably good at that -- or this is one of those concepts -- like quantum mechanics -- that people have a real hard time grasping.

Eg. A 64-bit process can theoretically address 16 EiB (18446744073709551616 bytes); but the first x64 processors had a physical bus limit of 44-bits. That physical reality constrained the performance and capacity of software written for that processor. But with the next generation of hardware x64 chips had a 48-bit bus, so that same software -- if written correctly -- would, without even being recompiled -- would instantly have 16 times its old capacity.

But it doesn't stop there. The same processor that has 16 times the capacity, also halved the latency between chip elements, and effectively doubled the number of those elements available to the chip designer. The first means that the (unchanged) software runs (almost) twice as fast at the same clock speed; the second means that the chip designer can expand the size of the caches; and increase the depth of the instruction pipelines; and increase the number of parallel execution units; with the effect that that at the same clock speed, the cpu can enact the same instructions that on the earliest version took 3, 5, 8, or 21 clock cycles to complete, so that now, almost every instruction completes within a single clock cycle.

So, the same, unchanged, even un-recompiled, software has 16 times its old capacity and executes 2, 4 or even 8 times faster.

Software has only logical limitations.

Contrast that with the fact that building a bridge across the Atlantic Ocean will forever be physically impossible. Traveling to other galaxies will remain physically impossible.

Step 2 follows.

Some of those logical limitations come from physical properties, like separation in time or space, right? For example systems *not* separated by time or space would not be subject to the CAP Theorem, right? Is the CAP Theorem therefore not a physical limit?

Some of those logical limitations come from physical properties, like separation in time or space, right? For example systems *not* separated by time or space would not be subject to the CAP Theorem, right? Is the CAP Theorem therefore not a physical limit?

Hm. CAP theorem:

1. I vaguely remember reading something about the conjecture back in the day; but I know nothing about it.
2. I hadn't heard it had been proven; haven't read the proof; and almost certainly wouldn't understand it if I did.
3. It appears that the proof is contentious; but when the one refutation I started to read started getting into Einsteinian relativity; I stopped reading.

My "instant reaction" to CAP theorem is: If I can inject enough delays into the system; I can guarantee consistency. That may be completely undesirable for use; but it makes the limitations logical not physical, at least whilst we're dealing with earthbound distances and real-world system speeds.

Beyond that, I have no opinion; nor interest.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Part 2

In this complex machine, each gear wheel represents one decimal digit.

Each time the bottom gear completes a full rotation (counts to 10), it causes the gearwheel above to step forward by 1/10 of a rotation. And when the bottom gear completes 10 rotations it has caused the second wheel to rotate completely once; which in turn causes the third gear wheel to step forward 1/10 of a rotation; thus 100 is recorded.

So, to add digits of precision; you simply add more gears wheels; but there is a problem with that. As you add more gear wheels, the physical force required to click over the highest digit gets harder and harder. At first you can make the bearing more accurate and better lubricated; then you can add a reduction mechanism to the (human powered) input shaft so that it requires more turns of the handle to drive a single rotation of the bottom gears. It means it takes longer to run through a given calculation but the force multiplier of the reduction gear overcomes the input force requirement limitation.

That difference engine uses 31 digit numbers. With modern manufacturing techniques & materials, I could see that being extend to 100 or even 200 digits. The cost would be huge; and the reduction ratio of the input drive would be very high, meaning that the calculations would be very slow; so today, we'd just add an electric motor to do the donkey work.

So then you add more digits; and increase the reduction gear ratio further to compensate; but eventually physics wins out and the force required to turn all the gears in concert is so high that the metal of the gear teeth -- whatever metal you use -- simply cannot transmit the forces required. And you've hit the fundamental physical limitations of the system.

In software; that physical limitation doesn't exist.

On my commodity hardware machine, using arbitrary precision software, I can multiply 10,000 digits numbers together with ease. Slowly, but the greatest effort is inputting the numbers. And distributed computing projects like Great Internet Mersenne Prime Search are routinely working with numbers with millions of digits. Whatever physical limits the hardware of the day has; they can be overcome by "simply" using more hardware. Well design & properly written for the purpose, the software doesn't need to change at all.

Suggesting that the difference is simply a matter of scale is like saying the distance from here to Alpha Centauri is just a matter of scale. The truism that every journey starts with the first step; doesn't help when there are 41314127522800000 steps to take.

The difference between software and hardware are not orders of scale or magnitude; but the fundamental physical laws versus the human brains ability to conceive of and coordinate the logical complexity of the problem.

As of yet, software is still in its infancy. The software (DNA) that controls the hardware (wetware) of the human brain is millions of times more complex than the software we currently write. Our ingenuity has allowed us to construct hardware that can run our, relatively speaking, currently simply software, very fast. Much, much faster than the human brain.

However, we don't yet have good algorithms for solving problems that even extremely small, and primitive biological computers (eg. ant's, bumblebee's; octopus's and jellyfishes brains) take in their stride. We currently compensate for the crudity of our algorithms by using brute force; using speed and the historic growth of that speed.

That growth in speed is rapidly running out; so we are now moving to using concurrency and massively distributed concurrency to compensate. In doing so we hit another fundamental physical limit; energy demands and cost. The largest HPC systems are using 10s and 100s of MegaWatts of power; but mostly what they do are quite simple algorithms; they just do them billions and billions of times to produce the results we are after.

But it still requires the human brain to intuit the next steps in the evolution of our knowledge.