The problem isn't bounds-checking, the problem is that most of the _s() functions that deal with bounds-checking already have pre-C11 equivalents that check boundaries.

I also disagree with some of the interface choices, for example when strlcpy() fails it tells you how many characters you needed, not simply "error" as in strcpy_s. Also the use case for memcpy_s() is extremely limited. It just seems like the _s() functions were rushed and stuck in there without regard for what makes sense.

However it's going to take some time to learn all the gotchas in string functions... Failing to zero-terminate strings (strncpy), potential buffer overflows (many), global internal buffer and overwriting an argument (strtok), etc etc etc etc

I think your comment is spot-on. A good Perl programmer can do wonders, but if you add just one average programmer to the team (without a very extensive training), he can write stupid things faster than the good programmer could fix, LOL. Then the codebase would be a mess, with things that kinda work but are conceptually wrong or weird for those who really know the language.

And the good programmer could do anything in a less eccentric language anyway, so...

+1 just because of "I would personally prefer to tinker with a Brainfuck implementation than spend any amount of time in any bar"

I guess they just ran out of names, after deprecating java.util.Date (remember that there's also java.sql.Date).

Never using a space before the paren is more consistent. I don't know why people put a space there...

I don't want my function calls to be consistent with control structures.

I don't recall ever mistaking function calls with control structures.

That's the way you do it in normal text.

Same here...

If programmers of functional languages were better at naming things, it would be easy. Let's rename g to callTwice and h to aFunction:

  function callTwice(aFunction) {

    return function(y) {
      return aFunction(aFunction(y));
    };

  }

  function square(x) { return x*x; }

  var squareTwice = callTwice(square);

  81 === squareTwice(3);

To be fair, the g and h names should obvious to anyone who studied function composition in high school.

Also, the names you gave don't help at all, as the idea of calling those g and h is to treat them anonymously. By calling it "callTwice", you are thinking about it as some sort of utility function, which is not the case. Shows you didn't grasped the idea behind it yet.

Might be obvious to you and other FPers, but when you're trying to teach FP to programmers who may only "sort of" or "not at all" grasp FP and spend most of their daily life writing CRUD business logic apps for a living but WANT to learn more about FP in order to be better programmers then it's totally useless. I found the other example immediately more understandable - even though I personally understood the content I sympathize with the people who are struggling. The FP community needs to take the academic context out of a lot of its teaching mechanisms.

It's actually very easy to see what is happening with g and f in this example. I think the part that is pretty opaque to non-FPers is why you would want to do that. Until something clicks, it is hard to see why this construct is anything beyond a very convoluted way of calculating 3 to the fourth power.

So enlighten me.

In FP, you can treat all functions as "curryable" because that's how you achieve composition. So that would be the equivalent of naming all your functions "callTwice". Now that doesn't make sense.

I don't see how that invalidates my explanation

In F# I would certainly call it "callTwice" too:

  let callTwice aFunction y = aFunction (aFunction y)

Well, I guess this is going to be a fairly down-to-earth language.