jafl5272

Does it scare anybody just how quickly the technology has evolved to negate many of his arguments?

I see they're taking a hint from Google.

But lawyers don't normally work in a management hierarchy, do they? And I'm pretty sure hospital administrators hate physicians just as much as managers hate programmers. (Not all of them do, of course, but I'm guessing it's similar.)

> So, what have we learned about the woman programmer’s dress code? Unlike the men’s dress code, beards are not in fashion

Thank goodness!

This seems like a pretty big change for a patch release?

On my MacBook Pro, only the command key has a symbol on it. All other modifiers only have text.

Somebody would surely find a way to spin that into an act of war, clear out the scuttled ships, and invade Iran.

He's not rejecting progress. He explicitly says that C isn't for everything. But he wants real progress: a language with GC, concurrency, etc., not just C-with-classes-plus-etc-etc-etc

I'll deal with this in order of decreasing insanity:

1) Polymorphism is NOT functional programming. Using function pointers, which you seem to detest, is one aspect of functional programming. If you've only used C++, then you don't know what you're missing from languages like Lisp or JavaScript. (I should know. I was once like that.)

2) I seriously doubt the Linux kernel avoids function pointers. Ever heard of dispatch tables? Good C hackers know that smarter data structures make for simpler code.

3) Any feature that can go horribly wrong will go horribly wrong when you have a large project with lots of contributors. Everybody who successfully uses C++ on a large project has a huge "coding standards" document to keep the project from crashing and burning. I know Google has it, and I've seen others, too. Even I have it for my own personal C++ projects!

4) What Linus meant by "context dependency" is that you have to know the object's type in order to know what the function will do and you even have to figure out which version of the function will be called, based on the arguments. This is hell when you get a small patch in the middle of a larger function.

Users work in an infinite number of different ways, and they way they worked before they use your app is probably forced by whatever crap they are currently using.

No matter what you do, you end up forcing a lot of people to learn to work the way the app wants them to. The best you can hope for is to build an app where, once it's explained, most users first go "Oh, ok, that makes sense." and then actually remember it later. If you're really good, the users will even say, "Wow! That's much better than the app I used before."

I thought your name sounded familiar. I'm very much looking forward to your post on this topic!

One more point: I would recommend building on top of the YUI 3 core instead of re-inventing it, unless you can point to something that you think they flat out did wrong. YUI 3 core is pretty small. The YUI team learned a lot from YUI 2 :)

Anybody who can build a framework is clearly not a moron. I just have strong opinions about frameworks, since I've built a few myself. Since I misunderstood his use of the term "HTML5 apps," I evaluated it as a framework for a web site, but he has now clarified that it is not.

> This is nonsense

This didn't apply to the entire framework, only to the invention of a new documentation generator. davebalmer and I simply disagree on this issue.

> Jo is geared more for downloadable apps

OK, that makes sense. This explains the use of non-standard tags, too. Progressive enhancement and using a standard DOCTYPE aren't a big issue for apps.