raganwald
(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Wednesday, September 20, 2006
  Surf's Up!


Every decade or so we have a major revolution in the way we develop software and the environments we develop for. But, unlike the object and web revolutions, we can see the concurrency revolution coming.
Herb Sutter, It's (Not) All Been Done
Awesome.

I've watched and participated on the periphery of several "waves" of computing progress. Yes, I wrote my very first SNOBOL programs on punch cards. Yes, I wrote a networked database application in MP/M. Yes, I wrote commercial software for Macintosh and marvelled at its Toolbox. And to learn Java, I used it to write a Scheme interpreter. (And yes, it did optimize tail calls and support continuations).

So I've lived on and in this ocean we call the computing industry, or computer science, or programming, for a while. I've seen it roil, I've seen it's placid moments. And I've seen its thundering, express train waves.

And I can tell you, it feels like another big wave is coming. A monster wave. A wave of tow-in surfing epic proportions. It's damn exciting. It feels like if we paddle like hell and try to stand on our boards we could be sucked under and crushed.

Or we could have the ride of our life, teeth bared in the most insanely happy grin we've ever worn.

I know that after the wave hits the shore, it will obliterate half of the vending stalls and the beach blankets and the hordes of sun tanners. And when the water subsides the industry will rebuild the beach houses and the industry will reopen the vending stalls, and the people who are rich today will probably still be rich then.

It's tempting to just wait, wait for the wave to hit and for the water to suck back into the ocean. Wait for others to solve the problems, to harness the energy. Wait until Microsoft and Sun and Apple and Linux and Apache and whoever else decide what we should do. Wait until they give us the frameworks, until they tell us where to swim.

Wait until there's no risk, like many people did with the Web and with Java and with their whole lives.

We can wait, just hunker on the shore and not take any chances out there in the water on our own.

But where's the fun in that?

Labels:

 

Comments on “Surf's Up!:
OK, I'll devil's advocate on this one.

I've seen this meme a few times since Sutter himself started it with the No Free Lunch article.

And sure concurrency is getting easier and better all the time. But what evidence is there that it is the next sea-change idea? Sutter hasn't really offered any evidence, and you don't seem to be either.

What make you so sure that this is the next big wave (as opposed to some currently marginal thing that we CAN'T yet see coming)?

Life is short, and you can't chase ever wave; only the one's you have a personal passion for.
 
When did we get the object revolution? I wasnt there when it was happening, but the charred cinders of remains I do see from the old Object Revolution point to its demise against the heathenistic delight of the *cough* Web Revolution. There is a lot of very important distributed systems work that just got dropped in the php+mysql field day we just had. We're probably better equipped now, we've toyed with xml & json & ajax, but there's huge work to be done.

There's many ways to talk about concurrency. Certainly parallel algorithms and distributed map functions have a massive place in the system, these tools for exploiting concurrency, but I personally would wager that the only time we're going to see anything resembling 'useful'-- the only time we'll see a real wave and true inertia-- is when we've built ourselves better distributed models.

In short, distributed systems are the asychronous model that can drive concurrency. Exploiting task-level concurrency is premature in the absence of more manifest distributed platforms.

-rektide

Mother fucking sweet ass post. This is going to be an amazing ride, one way or another. Hang ten.
 
I think concurrency is going to be more than just a passing fad. Primarily because the CPUs in the multi-core machines (individually) are actually slower than the fastest single CPU currently available. The average user thinks that the newest machines are the top-of-the-line machines. He also thinks that when he buys the newest machine, he is getting the "best", which in computer language equates to the fastest. What is going to happen when he gets the brand new top-of-the-line multi-core machine home and his software actually runs slower?

To be competitive commercial software vendors are going to tell their teams to speed things up. They’ll see how many cycles they can squeeze out by simple performance improvements, but at the end of the day someone is going to get the idea, "Why not use that other core?" This will cause the teams to look at their applications for concurrency opportunities.

There is a lot of very exciting things happening in technology. But on the desktop, concurrency is at the top of the list and if you build commercial applications, competition is going to force your hand.

So I have to say to Reg..."Yep"
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /