Due to self-interference, the light bumps into itself on the way out, and subsequently can't get out. At least at my limited level of understanding, it's the wave-light nature of light at play here.

I imagine at some point, the trapped photons all get absorbed and the original energy dissipates as heat.

FWIW, I technically had some C++ before Perl, but not enough that I count it.

Re: Perl: I'm much the same way with Perl. I use Perl for lots of quickie projects. Great for anything I'm only going to spend at most a couple days developing.

Perl's also great for much larger projects too, where runtime performance isn't absolutely critical but flexibility and development ease is paramount. We actually have some fairly significant projects at work that are written in Perl.

One of them, which embeds Perl in another language as a metaprogramming language. I couldn't imagine trying to write that in C++ without a dedicated team. But, a set of hardware designers are effectively maintaining the tool in the background thanks to it being written in Perl.

I imagine the result resembles INTERCAL.

As for which language is your gateway language, it probably depends on what era you started programming in, too. My path was Microsoft BASIC => Assembly => Turbo Pascal => C => Perl => C++11, with some shell scripting and other goodies around the fringes. I've probably written more C than anything, but C++11 rules my future. Turbo Pascal was my short-lived gateway to C, where I then spent most of my career. I wrote some truly regrettable neophyte-programmer code in C there at the beginning, so really C was where I grew from a college-aged hacker to someone who can actually program. Now guess how old I am. ;-)

I guess for an analysis like this, you really need to limit yourself to people who consider themselves competent programmers. Those VB macro whizzes in accounting likely consider themselves accountants, not programmers. Likewise for the physicist with a pile of creaky MATLAB models.

BTW, I have to agree with you 100% on make and bash. I consider myself above average on make as compared to my coworkers, but that's an extremely low bar. And while I've done some crazy stuff in bash in the past, these days I'll hop over to perl for anything more than 10 - 20 lines, especially if I find too much 'sed' showing up or find myself wanting an actual data structure.

I finally brought up the PDF. It appears the authors consider C++ weakly typed because it allows type-casting between, say, pointers and integers.

While this is strictly true, I find myself avoiding such things whenever possible. Main exception: When talking directly to hardware, it's often quite necessary to treat pointers as integers and vice versa.

I guess to fairly evaluate a language like C++, you need to categorize programs based on how the language was used in the program. If you stick to standard containers and standard algorithms, eschewing casting magic except as needed (and using runtime-checked casts the few places they are), your program is very different than one that, say, uses union-magic and type punning and so on every chance it gets. (I've written both types of programs... again, FORTRAN in any language.)

One of my more recent projects was written ground-up in C++11. It relies on type safety, standard containers, standard algorithms, smart pointers (shared_ptr, unique_ptr) fairly heavily. It's been quite a different experience to program vs. my years of C programming. Way fewer dangling pointers, use-after-free errors, off-by-one looping errors, etc. But, the paper lumps both languages into the same bucket. That hardly seems fair.

BTW, this ACM Queue article was linked from the blog post I linked above. It's another good, somewhat relevant read, IMHO. It makes largely the same point, though: It's more the programmer than the language.

I wonder if you can do an analysis of code bases across languages for the same team? I regularly write significant amounts of C++ (these days, C++11), Perl and assembly language. Those are three rather different languages, with strong, weak and largely non-existent type systems, respectively.

Of course, all three languages also open themselves to a wide range of programming styles, and I imagine if you picked any other set of languages you could make a similar statement. But if you measure the same programmers programming in across them (assuming a reasonably high level of proficiency in all of them), then perhaps you can determine what portion of the effect is due to the programmer vs. due to the language.

After all, Real Programmers can write FORTRAN in any language.

As a matter of fact, I'm releasing a product soon that falls exactly into this category. I specifically chose to keep the VID/PID unmodified, as the product has a mode where it needs to look like an ordinary serial port.

Sure, I could get modified OSX, Windows and Linux drivers to teach it about a new PID so that ordinary comms software works, but it's far simpler and less risky for a small guy like me (we're talking a few hundred units total) to just go with the flow and make it work with the generic drivers everyone likely already has.

You're technically correct that the chip hasn't been physically damaged. However, it's effectively dead, and FTDI's EULA revision makes it clear that they intend to render non-functional any clones they detect:

Use of the Software as a driver for, or installation of the Software onto, a component that is not a Genuine FTDI Component, including without limitation counterfeit components, MAY IRRETRIEVABLY DAMAGE THAT COMPONENT.

I recently built a big pile of boards with an FTDI USB chip on them, as part of my retrogaming hobby. I bought from a reputable source, I think. But if it turns out that I got an illegitimate batch of FTDI chips, I now own a pile of bricks until I pay to get them reworked. I don't know yet, since I haven't tested them in Windows with the latest driver.

Counterfeiting harms the original producer of the chips, and this extends the harm to OEMs that use the chips (who may or may not be innocent), and their customers (who most certainly are innocent).

I can't see how this is a good thing for anyone.

As someone said recently at work: "Deposits to the 'trust bank' are always small. Withdrawals are always large." In other words, it takes years to build trust, but you can obliterate it in seconds. FTDI may have done just that.