Lambda the Ultimate

Where does he get the 10^25 from? Is he multiplying the increase in disk * increase in memory * increase in speed / increase in money?

That was my understanding that he meant something like that, comparing the PDP-8 to the computing power present in that hall.

Definitely some hyperbole there, though I think that has more to do with a dramatic presentation than with any of the substance of his point.

For the sake of amusement, let's count the zeros:

machines : 1 PDP-8 → 1000s of computers in hall: 3 orders
memory : measured in k → measured in G : 6 orders
speed : measured in M → measured in G : 3 orders
storage : measured in k → measured in G or T : 9 orders

Adding these orders together (i.e. multiplying the factors) gives 21. Obviously he used different assumptions. ;-)

I do think it's a bit strange to multiply the numbers...

It's like saying I got 10x as many apples and 10x as many pears, so I got 100x as many as I had before!

Even supposing we only look at speeds if you have 2x increase in CPU speed and 2x increase in memory speed that is not a 4x increase in overall speed. It's even stranger here because he multiplies cpu SPEED * memory SIZE. A weighted geometric average would make more sense. Or even better compare some benchmark on two systems that cost the same amount of money.

Saw it, that was an excellent talk. Don't nitpick. Whether it's 10^25 or 10^16, or whatever, I couldn't care less. He got the point across: Why if our computers are so much more powerful due to EE, do we still program in the same manner as fifty years ago? And he made clear Moore's ending, so there will be some requests for new languages.

My frightening suspicion is that C will still just be good enough for that task.

He missed out on Prolog though. [ Which is a different paradigm from the imperative/OO and functional languages. ]

Whether it's 10^25 or 10^16, or whatever, I couldn't care less.

The actual number is not even close to that. The speed is less than 10^4 times faster. If programmers got 10^1 to 10^2 times more productive, that's a whole different story compared to 10^4 than compared to 10^25.

because he multiplies cpu SPEED * memory SIZE.

He measures the TIMESPACE complexity, which is normal in digital circuits/EE.

[ So, it's TIMESPACE/volume/watt/price. Looks pretty industrial thinking to me. ]

Actually, he does not. First of all if he would have multiplied two spaces (ram and disk) giving units space^2, but second he multiplies factors newram/oldram which have no units. To put it a little more strongly: multiplying these numbers makes no sense whatsoever.

Well, I don't hope he multiplied ram times storage. With the formula above I get to some 10^25 or something.

TIMESPACE complexity is a well known and an untrivial, if not the best, measure of complexity in EE. I hope you don't doubt that?

I.e., the time/space complexity of multiplying is quadratic. That gives a very precise and good number to optimize size of circuits vs running time.

[ Ah well, ok, guesstimating it.

volume: 3 orders - miniITXes per refrigerator
speed : 6 orders - kHz vs Ghz
memory: 9 orders - kb vs Tb
watt: 4 orders - kW vs deciW - doesn't fit, guess it's 2 orders
price: 3 orders - K$ vs $ ]

I guess the best comparison would be something like iPod (those without the HD) vs PDP11.

Say you are computing digits of PI and you have $x money and the machine you can buy has a GB disk, b MB RAM, c GHz CPU, uses d watts, etc.

Suppose some new model comes along that uses 50% less watts. Can you now compute double the amount of digits of PI? No! To compute double the amount of PI you can compute you need nearly *all* of the properties to double: 2x faster cpu, you need double the storage space to store the bigger number, etc.

He is saying essentially that if *one* of the characteristics doubles then the machine gets 2x better. In reality this only happens if a group of the characteristics double. For example if each one in the group (money, volume, watts) gets 2x better then you can buy 2 of these machines and in the best case compute 2x as many digits of PI. Another group that does the trick is (ram, disk, cpu). If each of those gets 2x better then you can also compute 2x as many digits. However if the computer just gets 2x smaller and you gets 2x as much ram then you can't.

According to Google, a machine which takes half the amount of watts, but does the same, is roughly twice as good. I think he's right.

Sure you can have a situation where you are purely watt limited. But my whole point is that if you are then doubling something else will have no advantage or only a very small advantage.

I am not sure but I thought calculating the n-th digit of pi is linear. So, even then according to you reasoning you could use two machines which take the same amount of wattage, and compute double the amount of digits in the same time.

You forgot power: 20 kW vs 50-70 W. That gets you another few zeros.

Dijkstra's approach to SE was structured programming. Now, that's not without merit, but I do follow uncle Bob's reasoning that that ain't the final answer.

Uncle Bob, on the other hand, brings a well-known message from EE: CS has just been riding the EE wave, and hasn't brought a lot to the table except for the fact that they've been chasing arrows up each others *ahum* pointy hats for the last 5 decades.

Not sure he's right. If you're in EE, God delivered C in your lap, and there it ended. But they don't see that CS is often at the other end of the spectrum, and developments like SQL and C# are there to solve business' problems, not systems programming, for which C is just good enough, and can hardly be optimized upon.

Can we think of anything better, in terms of a GPL? Sure, I don't think the combinatorial approach has been thought through enough. Forth was the start of that. But at the same time, when I look at the code I just wrote, -I just wrote the code for position based parsing, and should have used better primitives- I suspect people just aren't smart enough to do that right.

From his blog:

Prolog comes closest to being something more than a simple reorganization of sequence, selection, and iteration. At first look logic programming seems very different. In the end, however, an algorithm expressed in prolog can be translated into any of the other languages, demonstrating the eventual equivalence.

Ignoring that Prolog certainly doesn't come closest, Bob Martin just dove head first into the Turing Tar Pit. I thought I knew what he was talking about in his talk: he seemed to be reiterating "Can Programming Be Liberated from the von Neuman Style?" But the footnote on Prolog suggests something different. What does he want? Some hypothetical model of computation that's "beyond" Church-Turing (plus I/O) in the sense that the model's programs could not be translated to mere Turing complete language (plus I/O)? Or just a process calculus to tame the concurrency beast, in which case the "equivalence" objection is meaningless? It's not clear.

Most people are slow, even the very bright ones. They will sit somewhere with their own misrepresentation of how life sticks, and just be complacent while the world falls apart.

His role in a conference is just to 'Rattle the Cage' a bit and 'Apply the Boot' to lazy, complacent asses. Just so that there's innovation.

There is no answer, he just states some facts to counter the misconception that with Ruby/Haskell/Perl all problems are solved and, in the end, innovation should stop.

This has always been my problem with Uncle Bob. He tends to say a whole lot of stuff that makes you think he's got a specific insight. But when you strip away all the verbiage, it becomes apparent that, while he seems to grasp the facts of computer science, its implications often seem to elude him.

But when you strip away all the verbiage, it becomes apparent that, while he seems to grasp the facts of computer science, its implications often seem to elude him.

I think you would agree with me that he is hardly alone in having that disorder. ;-)

I certainly don't look to him for computer science insights. He does have some interesting things to say about the expressiveness of PLs and how they affect the sociological aspects of software development.

The most provocative aspect of his talk is the implicit message he is sending to his audience of Ruby/Rails people, who often portray themselves as an elite with a "better language":

• Ruby is all recycled ideas from past decades
• The most important expressiveness issue of our time is concurrent programing and Ruby is known to be lousy at that, mainly because it has so much global state and meta-state.
• If you want a genuinely "better" language, you need to come up with some genuinely new ideas, or at least genuinely improved executions of old ones, and you at least have to understand the pre-existing state of the art

Since SICP is the gateway to PLT enthusiasm for many people, if all the Ruby/Rails people take his advice, would could have a lot of new company soon. ;-)

...all these great points Marc, and no conversion from kilowatts to watts. Yikes.

Just the other day I was reading old comp.object posts and stumbled upon this one by Uncle Bob, where he talks about how designing around the problem domain doesn't solve the complexity of software, but at least shifts the odds closer to our favor.

Of course, I've seen him state some things in the past that demonstrated some lack of understanding of programming language principles, but if I want to be deconstructive, I've seen Barbara Liskov exhibit similar faults in her reasoning. I've also seen plenty of times, too many to count with fingers, where Guido van Rossum was wrong, or where Joe Armstrong was wrong... due to missing "outsights" from Computer Science.

RE: The most important expressiveness issue of our time is concurrent programing

Code distribution (whether through 'app stores', web-apps, clouds apps, tea party, first-class pickling, or cellophane-and-sneakernet) is also up there. Related is maintenance, upgrade, scalability, and security. And parallelism is another big expressiveness concern. So I'd say [Robert Martin's] assertion is 'highly debatable' (though I do agree that concurrency is certainly among the more important concerns).

Ruby, though better for many properties than some competing languages, isn't especially well engineered for these concerns.

[added later:]

If you want a genuinely "better" language, you need to come up with some genuinely new ideas, or at least genuinely improved executions of old ones

I don't believe this necessary; more precisely, I believe that language-design is a bit like baking a cake, and we could do much to improve the mix of ideas: if we have ten old ideas to choose from, there are 1024 combinations of ideas, and over three-million permutations. We might consider 'combination' to be fitting ideas into a language or its standard libraries (UI, etc.). We might consider a 'permutation' to be relative prominence or layering of ideas - i.e. are developers more heavily encouraged to directly use recursion or iteration? or perhaps a more logical inference-based approach? which do they use directly?

In any case, there is a lot of search space to cover. Improved execution of old ideas can also improve a language, of course. And new ideas are often helpful. But I'm certain that PLT developers could make a lot of language improvements on almost any metric you can imagine, even if we never have a new idea and never improve execution of existing ideas.

you at least have to understand the pre-existing state of the art

That will certainly help you avoid wasting time reinventing wheels and get you straight to polishing them.

OTOH, it might also bias your thinking, preventing you from deviating far from the explored paths. A lot of new language designers (e.g. at Google's PiLuD or Yahoo's LangSmiths) effectively reinvent existing favorite-languages with slight tweaks that they imagine are original or critical. (This is okay; it's a learning experience in any case.)

If you already know some state-of-the-art you'll likely need to learn as many paradigms as possible to combat this bias.

So I'd say your assertion is 'highly debatable'

Not my assertion, Uncle Bob's.

I was interpreting the message, not validating it.

Most of it was a high-level overview of where we stand now as opposed to the seventies. The number of electrons pushed around on the web, the number of energy lost computing, the amount of devices per person (that he even underestimated), the order of improvement of hardware, the current state of affairs of engineering code, the use of interpreted languages, the advances and trends in current semiconductors, ...

You can extrapolate from that, for a part, he's just guesstimating where the next innovation will be.

Oh. I apologize for that misunderstanding, then. Though, I still stand by the counterpoints.