That would be hardware-specific, but probably _always_ independently controllable. It's not like the IC manufacturer is going to link the CCD to an LED.
Certainly not arguing that it's difficult. It's extremely trivial.
It just makes no business sense for the camera manufacturer. The CCD is a generic chip that spews clocked image data over some serial connection. Keep it simple and generic, and ship to any business who wants it.
You can have a camera controller IC/ASIC/FPGA/µcontroller one step up from the CCD that manages the CCD and LEDs. That would have either firmware or hardware support for LEDs, but you'd still imagine that it would be configurable for cases where there is no LED installed.
It's absolutely possible, and I don't know all the options out there, but I can't imagine a manufacturer shipping an off-the-shelf IC that _always_ ties an LED to CCD operation.
Sometimes companies try to act in their customer's best interest. Or at least in such a way that they don't risk customers turning away. I noticed this story on HN quite recently: http://www.computerworld.com/s/article/9241003
1. The CCD IC controls the LED
2. A intermediate IC has firmware that controls the CCD and LED
It is safe to assume that the LED is always controlled either by an OS driver, or by an intermediate firmware. I doubt it would ever be controlled by the 'final' camera IC.
This means that, for Macbooks, running the CCD without the LED is _very difficult_, but, if the camera supports firmware upgrades, it is possible. And there could be undocumented commands to enable video without the LED.
If you're afraid of script-kiddies watching you read Reddit, you can probably trust the LED. If you're afraid the NSA has identified you as a special target, you probably cannot.
I spent a nontrivial amount of time thinking about writing a CoffeeScript-like syntactic sugar layer over C, and I ended up abandoning the project for several reasons, not the least of which being that too many things make nice (or even different) syntax hard. What to do about macros, for example, bothered me for a long time.
C++ is a beast of a language that has semantics which are pretty much too big to keep in your head - I think the best potential for this is some of the new languages targeting some of the same ends (Rust is closer to the capabilities of C++, but Go is more mature and has better tooling).
Alas, "Go" was forced to look sorta like C, even though it really acts more like Modula with closures and garbage collection. (ignoring that C & Modula are both just redressed Algol)
Go is more of a C-like counter example of the things the author is talking about, with its authoritarian use of K&R curly brace formatting, and not making statements into expressions.
