My god. How many times have I seen that same sentence over and over and over again. Compilers are extremely complex and take a lot of man-hours to be able to use. Those with the skill to do it generally want to get paid. Then, I think it was spreadsheets. Ummm... After that it was an OS kernel. And then I think WYSIWYG word processor.... Web sever, web browser, 3D modelling software, etc, etc, etc.

It's not just games. Software is complex. It takes a lot of man-hours to do. Currently, we have culture where some people write free software. Quite a few of those people get paid to do it now too. It's great! For a long time software has been ahead of the game in terms of "free culture" (by which I mean the products of creative effort that are freely distributable, not necessarily free of charge). Slowly other areas have been catching up.

Games have historically been difficult to create in a free software project because while there were plenty of programmers around, artists and musicians have been lacking. Game designers have actually been plentiful, but they have been stuck in the modding scene (and often doing incredibly creative work) rather than in new development. This is slowly changing.

The one place where free software game development really needs to improve is in realistic business models. I don't actually know of any full games (rather than engines) built on a free software model that are profitable. With business software, you can charge for support, but with games you can't. I would like to see someone try to do it, possibly using merchandizing, serialization and sponsored development (i.e., Chapter 2 brought to you be Coca Cola). It would take good marketing skills, which is lacking the most in free software development. Mozilla makes $100 million a year and they don't do support. I don't think it's a stretch to think that a decent game could do as well.

Right. That's what happened to newspapers. Newspaper production used to require a huge labor force. Look at all those people. 67 linotypes! A room full of proofreaders to catch typesetting errors. Hundreds of people moving paper around, making printing plates, loading them onto presses, running the presses, handling the printed newspapers. Compared to the army needed to print the papers, the reporting staff was tiny, a small expense. The reporting and editing staff, the composing room, and the printing plant were all in the same building. Any separation would slow things down, and the competition would "scoop" them.

Now compare a modern large newspaper plant. There are people around, but not many. There's essentially no direct labor. All paper and plate handling is mechanized. The files to be printed are created elsewhere and come in over a data connection. The printed newspapers leave in big trucks. Many different papers are printed in the same plant. The plant is far from the reporting and editorial staff, and is run by a separate corporation from the "newspaper".

So, to newspaper management, reporters are now the big labor cost, the first thing to cut.

The intent of the new syntax is that &char[n] buf means passing a reference to an array of size n. char[n] is an array type, something C currently lacks. Syntax like this is needed so that you can have casts to array types.

I've had a few go-rounds at this syntax problem. See "Strict pointers for C". Unfortunately, there's no solution that's backwards-compatible with existing code. However, mixing files of old-style and new-style code is possible, and mechanical conversion of old-style code to new-style code looks possible.

It's worth looking at this again now that C's market share is back above that of C++.

(replying to myself): Also, if her statistics are good, she might consider joining the biostatistics core at a med school or medical company. There will be no shortage of clinical trials or other biological experiments where they really need a statistician (or mathematician) to help with experimental design and statistical analysis / hypothesis testing.

If she has additional background in biology, or computing skills, she might find work in a computational biology lab as a staff scientist or assistant ... but the real key is to have a complementary skill, where mathematics helps propel the analysis and work.

What porn? I have over 10,000 edits on Wikipedia and don't recall seeing any porn. Wikipedia has bios of porn stars and links to their work, but they rarely host actual porn content. It has to be both notable and freely licensed to get into Wikipedia. Commercial porn doesn't qualify.

Is the problem here some religious group with a modesty fetish, or what?

If you want porn, search videos with Google or Bing and you'll find whatever you're looking for.

Google Shopping isn't even in their main toolbar. It's now hidden under "more".

The article is stupid. But the language and OS problem is real.

First, we ought to have secure operating system kernels by now. Several were developed and passed the higher NSA certifications in the 1980s and 1990s. Kernels don't need to be that big. QNX has a tiny microkernel (about 70KB) and can run a reasonable desktop or server environment. (The marketing and politics of QNX have been totally botched, but that's a different problem.) Microkernels have a bad rep because CMU's Mach sucked so badly, but that was because they tried to turn BSD into a microkernel.

If we used microkernels and message passing more, we'd have less trouble with security problems. The way to build secure systems is to have small secure parts which are rigorously verified, and large untrusted parts which can't get at security-critical objects. This has been known for decades. Instead, we have bloated kernels for both Linux and Windows, and bloated browsers on top of them.

On the language front, down at the bottom, there's usually C. Which sucks. The fundamental problems with C are 1) "array = pointer", and 2) tracking "who owns what". I've discussed this before. C++ doesn't help; it just tries to wallpaper over the mess at the C level with what are essentially macros.

This is almost fixable for C. I've written about this, but I don't want to spend my life on language politics. The key idea is to be able to talk about the size of an array within the language. The definition of "read" should look like int read(int fd, &char[n] buf; size_t n); instead of the current C form int read(int fd, char* buf, size_t n); The problem with the second form, which the standard UNIX/Linux "read" call, is that you're lying to the language. You're not passing a pointer to a char. You're passing an array of known size. But C won't let you say that. This is the cause of most buffer overflows.

(It's not even necessary to change the machine code for calling sequences to do this. I'm not proposing array descriptors, just syntax so that you can talk about array size to the compiler, which can then do checking if desired. The real trick here is to be able to translate old-style C into "safe C" automatically, which might be possible.)

As for "who owns what", that's a language problem too. The usual solution is garbage collection, but down at the bottom, garbage collection may not be an option. Another approach is permissions for references. A basic set of permissions is "read", "write", "keep", and "delete". Assume that everything has "read" for now. "write" corresponds to the lack of "const". "delete" on a function parameter means the function called has the right to delete the object. That's seldom needed, and if it's not present, the caller can be sure the object will still be around when the function returns. "Keep" is more subtle. "Keep" means that the callee is allowed to keep a reference to a passed object after returning. The object now has multiple owners, and "who owns what" issues come up. If you're using reference counts, only "keep" objects need them. Objects passed without "keep" don't need reference count updates.

Do those few things, and most low-level crashes go away.

I won't live to see it.