Disclaimer: I worked with the OP and she is a ferociously productive engineer.

Dismissing newer technologies as "shiny" instead of evaluating their merits*

Or, evaluating technologies based on how useful hey are rather than the amount of hype they are generating

Language hipsterism*

Huh? I don't even know what this means.

Being disturbed by modular code*

The OP was disturbed at the thought of building a program by gluing together "modules". In this sense she is using "module" to mean (essentially) black-boxes of unknown origin and quality. If you had ever seen her code you would have a hard time convincing anyone that it wasn't modular.

* Being turned off by callbacks and reinventing the wheel instead

The OP says she hates the design of cgic, not that she's against callbacks. She made a practical decision that cgic didn't do enough for her to warrant the pain of using it, and discovered that creating something that she actually liked using wasn't that much work.

To put it more generally, she is saying that - given the choice between using some existing code that isn't quite right (or outright sucks for some reason or another) and taking some time to roll her own, she has found that it is often worthwhile to spend a little time to create something that she knows works and that she enjoys using.

* The usual silliness about all tools being capable and therefore equal (they're all Turing complete, yes, but we still want to know which ones are more productive for some use case.)

The OP said no such thing. She said that she has found a language she is highly productive in (C++) and she hasn't yet seen a newer "shinier" language that would make enough of a difference to warrant switching to it.

Right, but then she goes on to mention libxml2, which for someone unfamiliar, could be a "black box of unknown origin and quality". In this case, of course, I wouldn't dare criticize libxml2: it's an impressive piece of software with a great track record and excellent test coverage. But I just happen to know that. To someone who doesn't, they'd have to learn. Just as, for someone who doesn't know anything about some Ruby XML library, they'd have to learn.

So basically her argument boils down to "I'm fine using modules written in my language of choice that I already know about, but I don't feel like learning about new modules written for a different framework".

Regardless, C/C++ is just not a safe language when writing code that has to survive adversarial conditions. Maybe the OP always writes perfect, vulnerability-free C code (though I doubt it), but most people do not. Advocating a language that doesn't have some kind of memory protection for web apps just strikes me as irresponsible.

A buffer overflow or use-after-free() in C can let an attacker run arbitrary code on your server. A buffer overflow in Java throws an exception and terminates the program (or is handled gracefully). Not saying that there aren't other classes of vulnerabilities, but using a language/runtime such as Java or Ruby eliminates some of the trickiest sources of security bugs.

It does sound like she's ferociously productive. It's also possible that she could be ten times as productive and that C++ is holding her back. The programmer credo is to work hard and work smart.

> I guess the current "shiny" thing is still more-or-less Ruby [with] Rails. Oh, I suppose there's also the whole node thing, in which you write things in Javascript and run them server-side with v8. She dismissed node right away (with no argument from me)

> I have no practical experience with them

Casual dismissal without evaluation of merits.

> it's all been linked to frothy people clamoring for the latest shiny thing. I've seen that pattern plenty of times before, and it's always annoying.

This is what I mean by hipsterism: Dismissal based on an excited fanbase.

> that somehow you would need to abdicate almost all of your code to modules where you just hope they work.

I had a problem with this sweeping generalization. If cgic isn't great, that's fine. Certainly you still have to evaluate your dependencies' merits.

> that creates an awful design where you give up main() to that program's code and then just wake up when it decides to call back to you

This did read like an indictment of callbacks as a whole, but I see now that she's not happy about libraries that hijack main() and have some secondary entry point. I concede that.

> It might not be wonderful, but you could build something relatively quickly, at least in theory.

High-level languages have proven productivity gains and known pitfalls. Here, she is hand-waving them away without giving them a chance.

> Better still, since I"m not chasing the shininess in that realm, I can spend those cycles on other things.

Trollish fallacy.

> she hasn't yet seen a newer "shinier" language that would make enough of a difference to warrant switching to it.

As far as I can tell she didn't even give them a fair chance. She dismissed them based on supposed hype and blubbiness.

I would think it's more about trying not to dismiss older technologies just because of the merits of something newer.

Being disturbed by modular code

The C++ code described in the article sounded pretty modular to me...

http://www.informit.com/articles/article.aspx?p=1193856

http://stackoverflow.com/questions/424839/what-were-the-main...

As I see it, it's the old low-level vs high-level discussion all over again. I'm sure you have seen it before.

Low-level programmers argue that they have control and know how everything is working. High-level programmers argue security, problem isolation, modularity (i.e. not only using your own code!), readability, maintainability.