tygorius

You're referring to the aggregate, so far as I know copyright law works on specific instances. Let's say the Kindle had a button that allowed you to isolate a couple of sentences and broadcast them to your friends on Facebook, or wherever. The small portion of the text being shared would fall under fair usage and not be a copyright infringement violation, even though the aggregate of all Kindle users might be large.

What is the important difference here?

I think the biggest difference between the two sides debating this issue is that one side thinks the amount of effort Google put into creating search results is a relevant concern, while my side thinks that once those results are shared with users Google's legal/moral claims to any ownership of that data evaporate.

The streetview point highlights the problem. If Google and I both take pictures of the Church of Mxyzptlk at 14th and Main, we both own copyright to our respective pictures. The fact that I created my picture after "piggybacking" off of a Google search for Mxyzptlk is irrelevant to copyright. So far as know (IANAL) the combination of a link with search terms is a utilitarian set of data rather than a creative expression and hence not copyrightable.

I'm not sure why you doubt his sincerity. Stack Overflow is where he's spending most of his time these days, isn't it? Why wouldn't he be mentioning it in most of his posts? It seemed appropriate for this post. What would constitute a sincere blog post?

In the traditional writer's workshop, you write something, it's passed around, and people make comments. Depending on the workshop, a good portion of the feedback can be useless. And it's quite possible that few or even none of the others are trying to write the same sort of thing as you, so you don't have a good source of contrastive examples.

Read the SO response he got again. Near instant feedback, from a peer group, with counter examples to show what worked with the readers and what didn't. Faster, better quality feedback that leads to accelerated improvement.

What he wrote were observations after quitting and several of the points he acknowledged were related to higher volume -- points that might not apply to readers with lower public profiles.

Actually, there was a GTD aspect of it (inbox, Tweet usage, LinkedIn) that seemed right at home for HN.

As to "the central idea of copyright", bear in mind that in addition to not being able to copyright ideas or data, there's also the notion of "fair use".

And yet... even as someone who knew (slightly) and liked (muchly) Jef Raskin, I find myself grinding my teeth every time Aza refers to his father as "the man who invented the Macintosh." Because, well, no, he didn't. What Raskin thought the Macintosh should be was a low-cost, non-bitmapped computer designed along the lines of his later computer, the Canon Cat. And as nifty as that computer with Forth in ROM might have been, it's not an accident that it sank like a stone in the market. In contrast, what Jobs thought the Mac should be is what we got, and frankly I think the world is much richer for Jobs' vision prevailing over Raskin's.

One of the key points about Jef Raskin was that he was creative and inventive, but could become fixated on ideas to the point of not noticing how the market had responded. An example that springs to mind was his adding special "leap" keys to the Canon Cat's keyboard and patenting the layout. Because he just knew his interface design was superior and therefore customers should (would!) adapt themselves to his way of doing things.

Perhaps more telling is the example his son chooses to close his post, where he describes the gift of a vintage safety razor: "It's the kind of clear insight for which all designers and inventors strive: beauty in turning constraints into advantages." A more detached assessment might have been, "a beautiful design from a time that is thankfully well behind us."

Bing's increasing market share is presumably already due to providing value. If Google's unique sales proposition has become, "we find obscure misspelled words better than those copycats at Microsoft", do you think that's going to make people less inclined to try Bing?

Good point. I think the current PR campaign, and really that is what it seems like now, is counterproductive. It used to be the response to Bing was "What, is that like Microsoft Bob for search?" The longer this campaign goes on, the more it increases the user perception of Bing as a serious competitor. Even if true, that's not really a good message to be promoting, even unintentionally.

Well, perhaps Microsoft thinks its business involves providing value to their customers rather than its competitors. What seems consistently missing from the Google PR campaign has been how Microsoft's behavior is a bad thing for the user.

Oh please. At worst, Microsoft's customers are sharing results of their browsing activities, based on information you gave them. How in the world could that be illegal?

Your team is really coming across as whiny on this issue, which seems to me precisely the wrong tactic to take in response to Bing's increasing market share. It makes your team look defensive, as if your advantage is slipping away and this sort of theatrical display is all you've got in response.

As a practical matter, I doubt customers will care so long as they've always had the option of turning off that part of IE's behavior. I mean, when did you last care about the authenticity of your phone directory's information?

Saw it in a theater when I was a lad -- too young to properly appreciate Eva Marie Saint, alas.

Not at all. If VS suits your needs, then rock on!

Personally, I enjoy the occasional vi/vim story here, as in reading the comments I almost always come away with several new ways of doing things in vim.

I think there's a better question to be asked, however. Given that programming involves a seemingly endless stream of tools/techniques that seem good enough and alternatives that are promised to be much better, do you have an efficient strategy for determining which alternatives to explore? (This is a question I've been wrestling with myself recently.) How much time should be budgeting for exploring an alternative before writing it off as a time sink instead of productivity multiplier?

In your case, since you already use vi/vim daily for some editing tasks, I'd suggest a low time-investment strategy of lowering the slope of your learning curve: review how you normally use it, isolate one or two procedures that seem awkward or irritating, and then focus a small amount of time on researching/practicing the recommended alternative practices of experienced users. I've found that by focusing on the occasional experiment, learning is much more enjoyable. If I think about how much I don't know about vim, on the other hand, I'm inclined to feel overwhelmed and put off learning anything.

Admittedly, this approach isn't going to help if your resistance point is learning to dump the arrow keys and mouse. On that one, I don't know that there really is any good alternative to a couple of weeks of devoted effort.

As a relative latecomer to vim, I think your distinction is worthy remembering. If you didn't start with vi, it's easy to assume that all the power and cool stuff is the result of improvements and not realize how much just plain old vi could/can do.

As to copy/paste, does that depend on the platform? I use vim in a terminal on Linux and Ctl+Shft+C/Ctl+Shft+V on selected text works fine for clipboard transfers. I don't use vim on Windows often enough to remember how things work there, however, and the article that prompted this discussion was focused on Mac usage.

Interestingly, both languages wound up with a schism of framework enthusiasts (CLOS & "big Forths") vs. minimalists (Scheme & Moore loyalists (for want of a better term)).

As an aside, your bunch of data example would run afoul of Forth catechism. The normal response would be to use a dictionary address or even address and offset to access a data structure. Antagonism to deep use of the data stack is so prevalent that Moore eventually reached the point with his chip designs of implementing the top of stack as a couple of on-chip registers -- if what you want isn't within the top couple of stack entries, so the logic goes, then you've failed to factor your design properly. Perhaps this preoccupation with very low level operations is an aspect where Forth programming might be considered the opposite of normal Lisp programming.

The same can be said for classic Forth. Indeed, the enthusiastic way that Lispers describe macros I find eerily similar to how I used to hear Forthians describe their language. Except in Forth the relevant term isn't macro but "defining word". Indeed, I think programmers in both camps see the proper use of macros/defining words as a sign that one has passed the beginner stage of using the language.

A classic compiled Forth word (ie, function) would consist of the word's name followed a string of addresses to execute; how those addresses were laid down, where they pointed, etc. were totally open to programmer control -- both during compilation and afterwards. It's been a couple of decades since I looked at Forth code, but I don't think there's anything that could be done in Lisp macros that couldn't also be done easily in Forth as well.

I think the big difference between the two -- at least, so far as the macro topic goes -- is that Lisp starts with an assumption that code and data can and should be interchangeable while Forth was initially developed for the machine control (embedded systems before they were called embedded systems) and thus code was merely a vehicle for creating applications.

If you've considered the issue of the use of nuclear weapons and have either the opinion that it's never justified, or that it is in certain situations, that's one thing. But then when discussing the issue you wouldn't really be equivocating, would you? Equivocation and the problems the author reported in candidates were evidence the students simply hadn't thought about important questions related to the their fields of interest. And yes, I think that's a cause for concern if the trend is increasing.

Since we're talking about a headline instead of a clinical diagnosis however, I'd suggest the author was using that phrasing as a more concise way of communicating "formerly known as a software genius, then famous as a convicted murderer, and now working on a shtick as a mad scientist."

I had the opposite reaction. I figured the writer had been so indoctrinated into the view that "teaching to the test" was evil, bad, and wrong, that when a positive result popped related to testing, just that one point alone became the "news" hook of the story.

Hmm, in looking at her list of past articles, it appears the author mostly covers the medical beat. Perhaps it's a case of a "helpful" editor spicing up the story with a more controversial headline.

As far as I know, all definitions of learning include the ability to recall. As the article points out, the students that drew concept maps "felt" they understood the material, but later were actually worse at demonstrating it with the follow-up test on understanding of the material (ie, both recall of the previous facts and the ability to draw inferences from them).

It's true that rote memorization is not the same as learning, but that's not what was being tested in the study. They specifically tested to determine both recall and understanding.

I've been struck over the years at how one of key benefits of the Smalltalk environment -- being able to explore/change things in a program while it's running -- is not more widely regarded in the field. I occurs to me now that the interviewed programmers might have already gotten much of the cognitive benefit of such exploration at the beginning of a project. For them, print statements and listings are a way of confirming details of what they expect to be happening as the code runs. For un-godlike programmers (and maintenance work), debugging is complicated by the lack of deep understanding of how the code is supposed to work, hence the need for more exploration time and debuggers.

If this author's approach seems similar to what you already do, then investigating something less dominated by visual senses might be useful. Twyla Tharp's "The Creative Habit" might provide some useful insights.

Also, it isn't about filling your head with useless data -- it's about improving the quality of your interactions with people, making life easier and better for both parties.

Or, to consider from a crass perspective, humans are wired for reciprocity (viz Cialdini's "Influence"), so as the article points out, you'll get more favors, preferential treatment, and marketing opportunities from people who feel they have a connection with you.

Particularly dubious is extrapolating Apple's iPad success to success for that form factor when other companies have barely started shipping product.

Netbooks, like notebooks before them, may no longer be generating buzz, but that doesn't mean they're "finished off", whatever that means. The last time I checked, Apple hadn't shut down its laptop operations.

As to gambling vs. trading, there's a whole industry of people who train traders in eliminating the gambling psychology that can destroy equity so quickly. A short time frame only exacerbates the psychological weakness.

Oddly enough successful day traders, that is, those who hold their positions for mere minutes and close out all positions by the close of the trading day, are about as far from gamblers (in a psychological sense) as you can get.

So, your point is that developers should only enforce their rights when it will be popular?

I was singularly unimpressed by the blog author's focus on blaming the developer for making things inconvenient for others. Well, insisting on your rights is quite often inconvenient for others. And it's not like it should be surprising. This sort of conflict was inevitable given the terms of the App Store and the GPL.