Thanks to the community transcripts wiki:

Spolsky: Quite probably. I mean C is a car, it’s very dangerous – it doesn’t have seatbelts, but it’s very powerful because it goes very fast. In fact, I’d go so far as to say, unless some people are gonna punch me about this one, but you cannot write multi-threaded code in the C programming language. You just can’t. Although technically all the capabilities are there, it is beyond the capability of mortal humans – and I know, some of you out there are very smart and you think that you have the capability of writing multi-threaded code in the C programming language, because you’re hot shit. Well, let me tell you, it is beyond the capability of humans on this planet, for their brains are just not adequate to the task of writing multi-threaded code in most languages, least of all low-level languages like C. It’s just not gonna work, it’s just not gonna make you happy. So there.

The only problem with this statement is that it means we are all doomed: since all operating systems are written in C, and all low-level libraries, it means that we have no way to build the first level of abstraction needed to provide the higher-level primitives for C# and Python and everything else higher up the stack.

But in general, I think this is a fairly true statement for volume programming.

An interesting point made is that the light-weight user-level threading of the virtual machine in Erlang optimizes for massively threaded performance. The key property is that the context for each thread is very small compared to an OS-level application thread (like pthreads, for example), and this means that the context switch cost is dramatically smaller thanks to less cache and TLB contents needing to be swapped in and out. Thus, for lots of threads, Erlang tends to get more work done per time unit, as there is less execution time lost to friction in the memory system. I am not sure you can emulate this in C using a user-level package. The very small initial stack and heap size of the Erlang VM is partially achieved by the very fact that in a VM, you have more insight into and control over when memory allocation happens, and thus you can more easily do stack and heap grow operations in small units.

Another interesting aspect of Erlang as opposed to C/C++ brought out in the interview is how to do error handling. In Erlang, this is part of the language, while in C/C++, writing code to handle all cases (and handle them correctly) quickly gets painful and overwhelming. Instead in Erlang, you have a system policy to kill any thread that does something bad and restart it. With that simple strategy imposed on you, the code gets much simpler.

The podcast also brought up a StackOverflow question about CouchDB that resulted in a good explanation of the concurrency model (optimistic concurrency on entire documents, an nothing smaller or larger than that). Damien Katz came in with some more insights on transactions and CouchDB, in a discussion on how to solve the classic bank account problem: moving money from one account to another. The “ACID” solution is to make sure that changes to two accounts are always both done or none done. The CouchDB solution is to put in a record of the account-to-account money transfer (I won’t use the word “transaction” as that is overloaded in this context) in the database, and just go through all records pertaining to a particular account to arrive at its current balance. That does feel more like proper bookkeeping practice, rather than having a single unauditable  balance in an account record…

Overall, worth its time to listen to.

The best bit is the discussion around named parameters and how that was introduced into Visual Basic for Application in Excel — and at the same time they reduced the argument counts to most functions by replacing them with manipulating properties of objects. I think that approach does make some sense, if you have something that lends itself to that kind of expression. Their comparison of having a single function call with 83 arguments to change the style of text in Word by silently effecting a dialog box, or actually setting each of 83 properties of a dialog box object makes eminent sense… Sense that applies to simulators as well: in Simics, we do have a system like that, with attributes on all objects in the simulation that can be set to change their behavior and connections. Trying to configure that in the SystemC-style with function calls and constructors from scratch would be a pain, definitely.

Another topic that struck a chord with me was the notion that we are moving towards a world of “little languages” built for particular purposes. I definitely think this is the right way to go, as domain-specific languages do make getting particular things done easier. The more general a language is, the worse it is at any particular task. Better then to use a smaller language built to do one thing. As Jeff put it, for databases uses SQL, for text processing using Perl, etc… Using a multitude of languages is the hallmark of good software design and a natural instinct for a computer scientist.

They also found a YouTube video of the old computer science (CS) song “Write in C“. They do not seem to get that this is a really old song, I remember singing it way back when I was a fresh undergrad CS student here in Uppsala… and it was part of the first edition of our nice leather-bound songbook called “Manualen”. The lyrics are starting to feel a bit dated, but it is still a very elegant piece of writing that I think took place in the mid-1980s, judging from the other languages referenced.

Anyway, an unusually listen-worthy edition of Stackoverflow.

Strongly recommended thread at stackoverflow: http://stackoverflow.com/questions/102714/what-was-your-first-home-computer is about your first home computer. Some good product shots, and also some really funny things inserted.

Idea:

• create a site for programmers to ask other programmers questions and get answers

Details:

1. make it so that good material gets community filtered, by a scoring system — you vote on answers to point out what is good, and the question-poster can select the “accepted” answer to the question
2. really good discussions can morph from discussions to collaborative wiki-style articles when needed, based on some criteria
3. create a score system to reward involvement and discourage bad behavior. You get points for asking questions, answering questions, etc. In a fairly involved way.
4. you have questions, answers, and comments on the answers. Interesting hierarchical system that I have not seen elsewhere
5. you can say “me too think so” to existing answers by scoring, rather than filling threads with “yes sure”, which other forums tend to do.

Conclusion:

• The mechanisms seem to work pretty well
• You do get some questions with hundreds of answers, which kind of hits forum madness and I cannot care to read them all
• You can use it for occasional reading and deep research

My main issue with the site is really that most questions seem to be related to things that are of little interest to me, especially web development in .net and other things that I am surprised to see are as common as they are! Embedded and linux seems to be quite rare, and people doing large-scale embedded even rarer. Simulation and EDA is non-existent from the looks of it.

But that can all change if more people discover it.

So please go there and check it out!