Hey, thanks for the comments. I like talking about this stuff.
A. I wasn't talking about loading a nib vs programmatically wiring up a view. Many people never touch interface builder and write all their views from scratch, but in that case you still have the choice between compositing your view using subviews and overriding drawRect with drawing calls. Have you ever has the pleasure setting up a tableview controller on an older (first or second generation) iOS device? The difference in responsiveness there can be quite striking. This may be a topic rendered somewhat moot with newer hardware.
B. That's not my understanding, but if you have a source on that I'd appreciate a link. I was under the impression that while the cell will only be requested once it comes into view, scrolling the table still requires the visible to cells to be re-layed out, which is where the relative inefficiency of subview rendering starts to hurt you. I certainly could be wrong about that though.
C. If I recall, CoreGraphics is implemented on top of OpenGL. You still don't want to do complex graphics in your cell's drawRect in this sort of situation (I'm just imagining an image and a few labels, nothing fancy). Drawing a static image, pre-generated or cached, is a nice solution in some cases.
It's true, I didn't read up on the tech at all. That was just my initial reaction. If it's fast, great! I'd love to see some performance benchmarks.
As for Objective-C, whether the language in and of itself is the source of the slowness I was talking about is somewhat beside the point, IMHO. I'm aware that laying out views in Cocoa involves a lot of overhead, and that it's as much to do with the complexity of what's going on under the hood as anything. The fact of the matter remains though that you take a performance hit when laying out non-trivial views that need to be updated as fast as possible (e.g. when a table view scrolls by even one pixel and all the views have to be redrawn). You could probably convince me that Objective-C isn't the reason this is the case, but in any event, when you find the need to drop down into direct drawing API calls in order to get the performance you need, the "not much" overhead you're talking about can become much more noticeable. In a tight loop, a factor of 2 can make a huge difference, even though "2x slower than C" would be an enviable benchmark for many languages.
Again, I'm certainly not denigrating Ruby or other languages, but to me, that aspect of iOS development is a reminder that one needs to choose tools carefully for the job at hand. Hence my hesitation at the announcement of alternative toolkits for iOS apps, the vast majority of which I have yet to see any stellar examples of. Here's hoping this will break the mold.
I can't speak for the parent, but my take on it is that Ruby is considerably slower than Objective-C and one of the slower scripting languages in common use, IIRC. I wouldn't go out on a limb and suggest that it's unsuitable for iOS development without having a chance to see it myself, but it's something to keep in mind.
As I'm sure you've seen, even Objective-C is too slow for many things when developing for iOS - for instance, if you want to get halfway decent UITableView performance it's best to write a custom UIView where instead of laying out nested subviews, you drop into C and do all your layout in drawRect using only CoreGraphics API calls.
If you're attempting to do anything more complicated than hooking together pre-fab components, your performance is probably going to suck if your views are written in Ruby. And it's the silky smooth graphics people have come to expect that give iOS the reputation it's earned for slick UI.
It doesn't mean you shouldn't necessarily use a framework like this, but you don't get all that convenience for free. I've often felt that the reason Objective-C remains in use (aside from the fact that it's kept alive by Apple) is that it sits in a really practical middle ground between the bare metal performance of C and the convenience (and tradeoffs) of "nicer" languages. As I said above, though, this is just my default reaction, and I'd love to see this stuff in action if it's truly usable for a reasonable subset of use cases.
I'm afraid you're mistaken. The book you mention does exist, but as graeme pointed out, it's an "unintentional" parody of the original phrase "the medium is the message", which is indeed widely attributed to McCluhan.
It's worth pointing out that McCluhan never wrote a book titled "The Medium is the Message", as the phrase is actually taken from his book "Understanding Media: The Extensions of Man", which was published in 1964. I highly recommend it, if you're interested in challenging your preconceived notions of "post-modern" thought, whatever it is you take that to mean. This text covers many topics seminal to media theory, which I won't summarize here, but the line you casually discard as meaningless (as well as the greater context surrounding it) is by far the most influential portion.
Seeing as though I explained the meaning of the phrase for you above, I won't repeat myself here, but on a somewhat lighter note I think were he alive today, he would probably be intrigued by your comments, and the medium by which you derived them. The irony would not be lost on him.
It's useful to keep in mind McCluhan's adage "the medium is the message". It's the way a new medium influences culture in and of itself that has the greatest impact on us, not the content it carries.
Perhaps a better analogy for the Internet would be the printing press, but either way, it was arguably the ubiquity, accessibility and automation of electric power that changed society the most. Similarly, the fact that we can whip our phones out and query Wikipedia over a lunch discussion to settle a bet is much more revolutionary than the content of the article, or even the breadth of Wikipedia itself.
Strictly speaking, Japanese is moraic, in that it divides the rhythm of speech into units potentially smaller than a "conventional" syllable. For instance, the transliteration of "ice", as in "ice cream", would be three mora: "a" "i" "su". To me this is somewhat problematic, as the methodology of the study had native (or proficient) speakers counting the syllables as the corpus was transcribed, and it's unclear to me whether a native speaker would even count syllables in the same way an English speaker would. Another potential flaw is that the syllables counted were for "careful" speech, which differs phonetically from casual speech even in formal registers. For instance, the word "kakushita" (hidden) is technically 4 mora long, but in normal speech the u and i are effectively swallowed, even though a speaker would pronounce them if carefully sounding out the word. In this sense, either syllable or mora count is not necessarily a great metric, as you'd probably be better off counting the number of uttered phonemes in recorded speech.
However, the study is still quite interesting. Besides the syllabic analysis and derived information density, they also analyzed recorded speech for the time necessary to convey equivalent semantic content, and while this metric diverges somewhat from the others, Japanese still comes out at the bottom of the group. It's worth pointing out that if this hypothesis is correct, it's not at all in conflict with anecdotal observations about the high context in Japanese conversation. If anything, one would expect context to take over when formal information density is low, much the same way that tonal languages often have comparatively low phonemic inventories.
SupderCollider is a lot of fun, though I've been getting more and more interested in overtone lately, especially because by using a more general purpose language you can avoid some of the quirks that make writing code in SuperCollider occasionally tedious. Things like needing to recompile the whole class library every time you write or modify a class, or the lack of third party code on par with an environment like Clojure. I also feel like the functional approach and Lisp-style macros lend themselves quite well to the task.
The nice thing, of course, is that since the synthesis server and language are decoupled, you're not limited to one client or the other, and in theory even the synthdefs you compile in one client can be loaded and manipulated from another. Rohan Drape has done some work on Haskell (http://www.haskell.org/haskellwiki/SuperCollider) and Scheme (http://slavepianos.org/rd/r/d/darcsweb.cgi?r=rsc3) clients as well.
The New York Times article the post initially links to is a lot more interesting. Besides debunking formal brainstorming processes, it also points out the increasing necessity of creative group work, as well as strategies that are quite effective. Examples include MIT's chaotic Building 20, and the sweet spot of "familiar but not too familiar" in hit Broadway musical teams.
Perhaps Agile with a capital A does hold something in common with the formal technique of brainstorming. The key point of the Lehrer piece is that in order for group creativity to flourish you need to foster debate and disagreement, not just uncritical free association in a conference room. And even then, it's good not to put too much formal process in place, because the best interactions are unscripted. But this in turn solidifies the need for work spaces that maximize the chance for these encounters.
Nothing odd about it, IMHO. One of the things I think tech-oriented people consistently ignore is the role of emotion and the subconscious in decision making, even in what are nominally objective disciplines. Our conclusions may be based on reason, but then where do our hypotheses and inspirations come from?
I understand the impetus to filter out students that are less naturally inclined to it, and if your goal is to establish something of a programming conservatory, then administering a test like this would be an effective barrier. However, I think perhaps more advantageous reading of these results would be to recognize that the ability for students to construct these mental models is the single most important foundation in their education.
Anecdotally, I have had some experience teaching non-programmers basic programming skills at the university level, and it's absolutely the case that some kids, even bright ones, struggle greatly with these constructs at first. They look at the symbols and freeze, intimidated by the arcane expressions, and control flow is often non-intuitive to them. To me at least, that's a pedagogical challenge, not a lost cause. You should have seen the exclamations of wonder and excitement when some of them finally got it, once a particular way of illustrating it stuck for them.
Well, take this Clojure tutorial, for instance, comparing a simple DI implementation in Java with a single function in Clojure. The latter bears almost no resemblance to the former, other than achieving the desired effect. Is it fair to say that the user of a closure is implementing the Dependency Injection pattern, or is it a positive side effect of the fundamental properties of first class functions and lexical scope?
You can't add code to ducks any more than you can add code to sockets. Let's assume for a moment the hypothetical student in this scenario is bright enough to tell the difference between literally describing a thing, and expressing an abstraction of it.
So basically then, the thing we're all supposedly getting in a kerfluffle about is that the example program in a hypothetical textbook that introduces the concept of inheritance is a cheap duck simulator. Ducks are a corny example, so I think it's fair to dismiss it as bland. But talking about physical objects is a great way to introduce inheritance to a novice because inheritance is fundamentally about hierarchical abstraction (code simplicity and reuse, incidentally, are side benefits enjoyed by all methods of abstraction). And what easier way to talk about hierarchical abstraction than the most accessible mental model already possessed by anyone who made it out of elementary school – the animal kingdom. The easiest pedagogical metaphors to grasp for students without special knowledge are those that draw similarities to what they already know.
OO is about a lot of other things too. But concepts such as Dependency Injection, which was the meat of the grandfather rant, are IMHO more an outgrowth of dealing with the limitations of OO design than a topic so fundamental to objects and classes that they need to be discussed when you're still talking about fundamentals like these. Are they good things to know about? Definitely. Will a student's mind be warped by basic inheritance example that imitates a taxonomy he already understands? As long as the whole book isn't about duck modeling, probably not, and even then I'm not sure you couldn't teach <IQuackable> FactoryFactories with a little imagination.
As I'm sure others will point out, this article has less to do with node.js as it does with embedding v8 in Nginx. Although since node.js runs in v8, I suppose you could interpret it that way.
A. I wasn't talking about loading a nib vs programmatically wiring up a view. Many people never touch interface builder and write all their views from scratch, but in that case you still have the choice between compositing your view using subviews and overriding drawRect with drawing calls. Have you ever has the pleasure setting up a tableview controller on an older (first or second generation) iOS device? The difference in responsiveness there can be quite striking. This may be a topic rendered somewhat moot with newer hardware.
B. That's not my understanding, but if you have a source on that I'd appreciate a link. I was under the impression that while the cell will only be requested once it comes into view, scrolling the table still requires the visible to cells to be re-layed out, which is where the relative inefficiency of subview rendering starts to hurt you. I certainly could be wrong about that though.
C. If I recall, CoreGraphics is implemented on top of OpenGL. You still don't want to do complex graphics in your cell's drawRect in this sort of situation (I'm just imagining an image and a few labels, nothing fancy). Drawing a static image, pre-generated or cached, is a nice solution in some cases.