Linked by Thom Holwerda on Sun 9th Sep 2007 18:08 UTC, submitted by koki
BeOS & Derivatives "The primary intention of my previous article was to make it very clear why and when locking is needed in multithreaded applications. In this article, I want to present my experiences in writing a new prototype for a replacement of the document model in WonderBrush and how it is manipulated and rendered asynchronously."
Thread beginning with comment 269955
To view parent comment, click here.
To read all comments associated with this story, please click here.
Vanders
Member since:
2005-07-06

The majority of developers are incapable of writing multithreaded code with fine-grained locking. That is just a fact.


I still don't believe it. You're basically calling the majority of developers idiots.

First of all, scala does not hide the message passing details. It just lets you write a message handler in 1/10th the lines of code compared to C++.


This claim is based on API-specific details. I can write a message handler in C++ for Syllable (& BeOS would be similiar) in under 10 lines of code, and that's with a very generous white-space policy. I could collapse that to 5 lines with BSD-style indentation.

Besides, just because somebody does not get low level threading primitives like semaphores and mutexes does not mean that he is a bad programmer. Maybe he has valuable domain specific knowledge.


I never said it did, but I'd be concerned by any developer who did not have a basic understanding of what is happening below the surface of the code they are developing.

I guess all those people using Erlang to program high performance telecommunications gear must be idiots because they use a language that hides many multithreading problems...


Apart from the fact that is an ad-hominem, it really depends on wether they are using Erlang because they don't understand threading or because Erlang is highly suitable for the given domain-specific problem. As it is the later, your assertion is false.

Edited 2007-09-10 13:59

Reply Parent Score: 5

tuttle Member since:
2006-03-01

I still don't believe it. You're basically calling the majority of developers idiots.


I work with many scientists and engineers. None of them are idiots. In fact, many of them are quite smart and also good programmers. But most of them do not get low level threading primitives.

This claim is based on API-specific details. I can write a message handler in C++ for Syllable (& BeOS would be similiar) in under 10 lines of code, and that's with a very generous white-space policy. I could collapse that to 5 lines with BSD-style indentation.


Maybe a message handler for one specific message type. If I remember correctly, a BLooper processes BMessage objects which are basically hashtables. So to handle multiple different message type, you end up with a giant switch statement. In each branch of the switch statement, you have to manually extract all message parameters from the BMessage. For a complex message that will be several lines of code for each message type just for the decomposition. And then you need to handle the case where some parameters are not present or of the wrong type, etc.

In a language with pattern matching, all that is just one line of code.

I never said it did, but I'd be concerned by any developer who did not have a basic understanding of what is happening below the surface of the code they are developing.


There is a huge difference between understanding how e.g. a mutex works in principle and applying them correctly every single time.

Apart from the fact that is an ad-hominem, it really depends on wether they are using Erlang because they don't understand threading or because Erlang is highly suitable for the given domain-specific problem. As it is the later, your assertion is false.


Most of them probably use erlang because they understand threading so well that they know that low level threading primitives are very error-prone and result in very hard to find bugs.

Reply Parent Score: 3

Vanders Member since:
2005-07-06

You clearly have a pet language, so this discussion is kind of pointless, but there is one thing I want to pick up:

Maybe a message handler for one specific message type. If I remember correctly, a BLooper processes BMessage objects which are basically hashtables. So to handle multiple different message type, you end up with a giant switch statement. In each branch of the switch statement, you have to manually extract all message parameters from the BMessage. For a complex message that will be several lines of code for each message type just for the decomposition. And then you need to handle the case where some parameters are not present or of the wrong type, etc.


The thing is, all of this is trivial and no more difficult or error prone than any other form of procedural programming. It's a total non-issue, and irrelevant to any argument about threading issues, other than the fact that message passing is a good solution to reduce locking. How it is implemented is irrelevant. It's well known that C & C++ are verbose when compared to newer HLL's. If Kaj wern't so busy I'd ask him to come tell you about how wonderful and compact REBOL is.

Reply Parent Score: 2