A lot of large performance-sensitive projects implement custom allocators in the form of arenas and freelists. Lots of platforms have a fast malloc implementation these days, but none of them will be as fast as this for the simple reason that the program knows more about its memory usage patterns than any general-purpose allocator ever could.

Not to say I can't understand Theo's point of view -- if he wants maximum security, then a program which bypasses one of his layers in the name of performance might not be the best for him.

On the flip side, the standards have no notion of such security layers and I feel it is perfectly reasonable for a team to not throw away performance in the interests of some platform-specific behavior. This was a bug, pure and simple. There's nothing wrong with using custom allocators. To say that "OpenSSL is not developed by a responsible team" is simply nonsense.

People who buy TRD are generally going for either aesthetics (the TRD exhaust for GT86 is rather unique looking), warranty/insurance, or loans. Increase my payment by $10/mo for the TRD catback? Warrantied and insured without question? Awesome, go for it!

People looking for perf will always go third party. You'll never see a TRD intake that gives large gains because it needs to work with the stock ECU. Go third party and you can get a giant intake that requires MAF scaling or a catless header etc. -- so many more options that TRD simply won't offer.

I think you've misread my comment, or perhaps I've not expressed my position well enough. You're speaking like I've dismissed functional programming. I haven't. In fact, I really love it! The parts of it that have bled through into the more imperative/OO-focused languages, like C#'s LINQ and your Python example, are phenomenal and a joy to use.

So, here it is again: not saying functional is bad. Certainly not being dismissive or skeptical of it. I'd just like to see what compelling features haven't yet bled through. What makes pure functional or even just mostly-functional languages useful, that isn't yet in other languages? What is the killer feature, the killer problem they can still solve way easier?

If a good, experienced programmer dives deep into a language for a month and doesn't surface with anything compelling, how much more time should they spend? I'm not looking to master F#, I'm looking for a reason to master F#.

Can you give some examples? Many C-based languages have benefited by gaining strong functional aspects. With that, I haven't really found a reason to use a functional-focused language.

A while ago I decided to dedicate a month to coding in nothing but F# (my usual choices are C++ or C#) in attempt to find the areas they really kick-ass in, and just couldn't land on anything. There are some rare circumstances that I found it to be useful, but I just didn't find it compelling enough to warrant applying elsewhere. I'd never done functional programming before, I'm fully aware a month isn't long enough to master anything, but usually it's enough to discover if something has a really cool, earth-shattering aspect about it. So I'm honestly interested here -- what did I miss?

Every few months someone announces a new fad language despite them rarely bringing anything new to the table, or the new things they do bring not being significant enough to warrant switching from some other well-established one.

I'm actually happy with this one, because it serves an easier to justify purpose: migrating your existing PHP codebase and developers to something that is immediately better and familiar.

I wouldn't badmouth a former employer, specifically because future hiring managers would see it as a huge red flag. And that's kind of pathetic, if you think about it -- if you're having a terrible experience that your higher-ups show no care of fixing, is it not ethical to warn others away from a poisonous company? The industry has scored fear into us under a facade of "professionalism".

I guess it's a bit of a crapshoot if you get a bad seller, but the fact that prices are 1/4rd of what you'd pay to buy something similar domestically is a pretty good lure.

I've ordered twice from Ali Express -- once for a RTL2832 tuner, and once for a mini-Gorillapod knockoff. Both times I received exactly what the page advertised, in perfect condition and they continue to work great today.

It's already happening in the States. AT&T recently put its support behind Powermat, a competing and incompatible standard. They actually stripped Qi from a number of the phones they sell -- phones that on other carriers support it natively -- and instead offer Powermat charging cases for them.

You appear to be at least as knowledgable as me, so please correct me if my technical understanding is wrong here.

I doubt I'd even be able to perceive the lower amplitudes in a 96dB dynamic range. The reason for wanting 24-bit samples is that some music has low passages and high passages (HTTYD comes to mind) that allow your ears time to adjust to the volume. I'd like music to be able to do this and still have fine detail in each section.

Check out the ODAC. Built to be cheap, and objectively transparent at the jack, unlike most DACs which just quote the specs of a high-end DAC chip inside of them and ignore a mess of other crap on the PCB that degrades the signal.

FLAC has native support for gapless playback, but the player still needs to explicitly take advantage of it by not waiting until your current song finishes to start decoding the next one.

Gapless is more common among FLAC players, I guess simply because if you care enough to support FLAC you've probably got a higher chance of caring about the rest of the feature set, but it's far from guaranteed.