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.)
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."
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.
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.
The guy surely learned a lot building this, but...
No comparison to jQuery or YUI 3. The documentation suggests jo has a lot of catching up to do.
> If you're using jo to create all the UI for your application, you won't need any content or tags in your index.html file.
Apparently completely ignorant of progressive enhancement: deliver the markup and CSS and then enhance with JavaScript.
> Often, important information that needs to be documented just doesn't fit into a neat, tidy spot.
This is nonsense: you put it in the overall description of the class. But based on this nonsense, jo invents its own, based on markdown. So you get a plain HTML page for each class instead of something similar to javadoc.
Agreed. As soon as this setting became available, I simply went it and set it to "does not incorporate ... encryption of any kind" for all of my projects that do not use encryption.