Bertrand Meyer is a programming language guru, computer scientist and arguably the uncle of object oriented programming

. Bertrand created the
Eiffel programming language. Eiffel is an object-oriented language that is based on a fixed set of powerful principles like Design by Contract and Command-Query Separation. It's a
very powerful language that has impacted the evolution of the more popular general purpose OO languages such as Java and C#.
With the arrival of multi-core and soon-to-arrive many-core chipsets concurrency and parallelism are top-of-mind for general purpose language designers these days. Bertrand has introduced the SCOOP model on top of Eiffel. SCOOP is a comprehensive effort to
make concurrent and distributed programming simple and safe, taking advantages of Eiffel's object technology and Design by Contract.
General purpose programming language designer and passionate functional programmig advocate
Erik Meijer leads the discussion in this addition of Expert to Expert. You all know
Erik by now. He's one of our favorite technical celebrities. He and his small team of innovators continue to build
great tools for software developers.
Very special guest star and famous mathematical logician
Yuri Gurevich joins us for the first half of the conversation (He happened to be in Bertrand's office when we arrived - very
lucky for us indeed!

).
This is a long conversation that I hope you eenjoy as much as I do. Find yourself some quality time to listen and learn from this chat amongst some the world's finest programming thinkers.
Enjoy!
Low res file here.
Follow the Discussion
Oops, something didn't work.
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.sign up for email notifications?
“I don’t use the internet any more because they can steel every thing” in context that was a very funny comment.
Regarding the Sleeping Barber Algorithm and with out breaking the demonstration. Wouldn’t you want to have as many barbers as you have chairs?
This does inspire some thought.
Basically, a chair will contain a customer, and a barber is required to do the work. This pretty much means that the number of chairs is the number of slots in the queue. The number of barbers will be determined by how many processor cores you have.
So pretty much, the more processor cores you have, the more barbers you can have. You ideally want one barber for each processor core. So, the more processor cores you have and therefore the more barbers you have, the faster you'll be able to cut the hair of all the customers in the chairs.
This analogy does make the problem sound simple.
Regarding the Sleeping Barber Algorithm and with out breaking the demonstration. Wouldn’t you want to have as many barbers as you have chairs?
You've both misunderstood the crux of the Sleeping Barber problem. The problem is a problem not of speed or efficiency, but one of concurrency. The point is to serve the customers without experiencing process- (customer-) starvation or deadlock and the Sleeping Barber problem is a double-rendevous problem requring a more careful use of locks to achieve the correct result than you might think at first.
There have been both hits and misses. 2007 was not the best year for channel9 videos. But you are right 2008 looks very promising: more videos on language, tools and process (development methods like Agile). A video about the new work item types in Rosario would be great...
Optionally, we can add barbers (threads).
As shown, this is actually a pretty clean pattern using Ports and lamdas and hides the locks and such in the runtime. User level locks on shared state could still be needed in the lambda. So it is not something that has to be "baked" into a language itself as this works pretty clean as a library.
I really like a few of ideas in this video in general:
1) I like the ccr Port abstraction. For some reason I like endpoints and messages.
2) I like the idea of Pre and Post conditions. This could be added to c#. Think spec# has.
3) I like the idea explicit handling of Query and Command on shared state. It allows tooling and static and runtime checks.
4) I like the idea un-named types like Tuples. c# has anonymous types, but you can't pass them around.
5) I love the idea of Transactions for object state and have them work with normal DB transactions for rollback. That seems to be a winning pattern for handling shared state and something like CCR below for handling concurrency and coordination.
private void button20_Click(object sender, EventArgs e)
{
// Have 1 Barber and N chairs. You can add Barbers (i.e. Threads in the pool) by changing the Dispatcher ctor.
Port<string> chairsPort = new Port<string>();
DispatcherQueue dq = new DispatcherQueue("Barber", new Dispatcher(1, "BarberPool"));
Arbiter.Activate(dq, Arbiter.Receive(true, chairsPort, (string name) =>
{
Thread.Sleep(100); // Time to cut hair.
Console.WriteLine("Customer {0} thanks the barber for the cut on thread {1}.", name, Thread.CurrentThread.ManagedThreadId);
}));
for (int i = 0; i < 15; i++)
chairsPort.Post("Customer" + i);
}
RE the Sleeping Barber: Why not just temporarily impart the knowledge and know-how of how to cut one's own hair to each customer that comes along with instructions to come back and report how it went?
Well, it looks to me that support for Queries and Commands would (almost) automatically require transactional support.
No one would like to read partial state, would they?
And in a way, it proves the point of functional programmers are trying to make - when you need to change the world, you have to create a new copy of it.
Whoever was reading the world at the moment you decided to modify it, would continue to use the "old" consistent version of it.
After you are done changing the world and committed your changes, all the new readers would see the new updated version. The old version will hang around long enough for all active readers conclude their activities and be "garbage collected" as soon as its no longer required.
Which is sort of what databases already do to implement non-blocking consistent reads.
So, it seems that eventually runtime environment will be a database with a common VM on top of it.
But that approach has its own issues, namely a requirement to have universal change sequence number to mark world versions.
Hmmm, is it a coincidence that Eric Meijer is said to be working on SQL Server these days?
The Data Programmability team is full of innovators. Erik is one of them.
C
Once again this video made me think of a really cool addition I'd love to see Channel 9 add to such video interviews. Charles, is there any chance you could ask your interviewees to state the last comp.sci book they read and enjoyed? I'm thinking the 'tradition' would be that it wouldn't even directly have to have anything to do with the subject of the video in question. You could then include the book details in addition to the usual interviewee home page link. Often times when watching or listening to the folks you interview I'm left thinking: 'Wow, I'd love the scan the titles on their technical bookshelf!'. Am I alone in this?
That's a fine idea, dot_tom! Thanks for the suggestion.
C
I used to write all my Cobol programs on paper first and work them out and debug them on paper. This was mainly because we had time limit on input and Run time for CPU. It actually worked out pretty well, because you could sit down and type the whole program in an hour or so and it was mostly debugged already. I would not do that today. As Erik has said before, today the IDE is so good, it is like "smart paper" that serves the same function as paper, but with other benefits.
yes. That is essentially what we came up with in another thread on object transactions. Transactions would atomically make a copy of the invariants. A writer could make updates to its' version and "try" update. I think it would a ~simple matter to extent object meta data to include a seq number.
Interesting idea. Thanks for sharing.
Keep on GoodThinking,
C
Me for one. Excepting trivial functions, most of what I do requires me to think, and I can't do that without a bit of paper and a pencil.
The Eiffel SCOOP mechanism was proposed over a decade ago, making the idea generations old in the software world, yet a functioning product still hasn't shipped. Why is that?
I'm not convinced that SCOOP can work. The problem I see with it is that it allows for arbitrary sharing of state among concurrently executing objects. If it can be made to work then the compiler will probably have to make such conservative decisions wrto synchronization that performance will be a tiny fraction of the theoretical optimum.
Its one of those ideas that have a seductive elegance at first glance but ultimately turns into a dead end.
Is this really true? My understanding is that SCOOP is very high level and there are a number of different ways it could be implemented internally. For example, it could be implemented on top of message passing?
I like the SCOOP concepts. Being a fan of design by contract for many years now, I like especially the way it works neatly with contracts. I would like to think foostar is incorrect in these assumptions.
Very good video. This was very nice to see Bertrand Meyer speaking about his work. Thanks for bringing this.
BTW, does he have to take into account the customers who do not see a barber and walk away? That was very funny!!
http://www.aiseesoft.com/mod-video-converter.html
Remove this comment
Remove this thread
close