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.

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, but if you're not paying attention to the bottom line, it's easier to go down a rabbit hole instead of pivoting.

If you're only interested in having fun, you run the risk of building something really cool that nobody needs.

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.

The more time sinks you follow, the larger the net drain.

This is why I read only HN, avoid Facebook, etc., and own a mobile phone which isn't useful for anything except phone calls.

The article talks about how slow the book is. He fails to realize that Tolkien is writing about a very deep game of strategy. It's like watching grandmasters play chess. Sometimes there is a flurry of captured pieces, but a lot of it is maneuvering, which may seem boring to those who don't understand it.

Anybody complaining that the Iliad and the Odyssey are full of clichés is forgetting that they were written several thousand years ago. The clichés where stolen from Homer, not the other way around!

I learned programming on the Apple ][+ by typing in programs and then modifying them. Nothing forces you to read the code better than being forced to type it in!

Somebody should try to use it to predict Google's next move...

I just tried it in IE7, and the JavaScript from Google causes an error. The font still renders, however.

> Flash may have killed Safari but OSX keeps working as if nothing happened. That alone should say something about the OS.

Sure does: Keep the UI out of the kernel :)

Sad, but true. And this explains the state of the Linux desktop today: copied from Microsoft instead of inspired by Apple.

Yes, it's messaging that really forces clean encapsulation. Otherwise, you can end up in getter/setter hell, where everybody still knows everything about everything, even though all data is private.

They missed "discombobulate"