emfle

Here is what I think he might be getting at:

Advertisement is not a very effective form of marcomm because people tune it out, and if they don't, they don't believe what the ads say anyway.

PR is much more effective. Part of the reason is that if you can make your piece look like a regular article, that in itself makes it more believable. But the other part is that sometimes PR pieces are genuinely useful for the recipient.

If I were in the market for a new x, I think I'd want to read the reviews of xs, even if some of them are paid for by manufacturers of xs.

Fake Steve often makes fun of the Apple "flaks" and the "hacks" that print the "flaks"s output, but I think many people in the market for Apple products actually like reading the gushing stories about Apple.

If PR is the new advertising, then an obvious way to fix the newspapers is to make the relationship with PR companies explicit and charge for it. It's not deceptive if the readers want it and you don't try to hide what you are doing. Charging to make product reviews is one possibility. Offering to write stories about any topic for payment is another, which would make you a direct competitor to PR companies.

There is a balance between making high-quality, independent content and making for-pay content that must be carefully managed, but this is not really all that different from today's print media that range from all-ads newspapers with minimal and very crappy journalistic content, to media with high quality journalistic content and almost no ads.

A company doing this should probably never offer a positive review for cash, and never offer a positive spin on a topic. Only ever offer a review or a story, with payment due regardless of whether the customer likes it or not. In the end, this would be in the interest of the customers anyway, even though they might not believe that at first.

I am familiar with functional programming. In fact, for some reason recursion and higher-order functions always seemed easy to me (unlike pointers and virtual methods), but I think that's a quirk of my brain. Many other people seem to have a lot of trouble with the idea that you can just make a recursive call and trust that it's going to do what it is supposed to.

Not me personally, though.

But the lisp style leverages the linguistic propensity to give words special significance. We're also very good at learning languages and parsing sentences in context, so the lisp linguistic style leverages similar natural cognitive abilities.

Linguistic processing does require more cognitive effort, especially when it involves something like a macro that can change the context in which it is invoked. For exactly the same reason, most people are more productive with a graphical user interface than with a command-line one. This is directly related to the fact that abstract linguistic processing is more difficult than manipulation of the tangible, physical objects you find in a GUI.

I am saying that working with objects and methods requires less high-level cognitive processing than macros and continuations, not that you don't have to think about them. This is because the brain can treat the objects largely as if they were physical objects. With macros that is much harder.

No, I don't mean unfamiliar. Things like parentheses and prefix notation are unfamiliar to many people, but once learned, they don't require much more cognitive processing than other notation. There are several things in Java that are similarly weird until you learn them.

The point is that "requires you to think" is not a feature, it is a bug, because that thinking could be put to better use on whatever it is the program is trying to solve. Everything else being equal, this means that language features that can be used without much thinking will do better than language features that can't.

I think most people prefer languages that let them think about the problem they are trying to solve, rather than think about what the macros expand to, or what happens when they call that continuation.

However, as Tog himself notes, when the keyboard shortcut is already memorized and well understood, it's a clear productivity win.

Tog never says that as far as I can tell.

Can you give examples of impractical things they do? (Or practical things they don't do).

Not on average. He will make many more errors typing www.amzaon.com than he will typing something resembling amazon well enough for google to find the site.

Reminds me of this old joke:

- Mr. President! The Russians have landed on the moon, and they are busy painting it red!

- No problem. When they are done, we will just write "Drink Coca-Cola" in big white letters.

Some fraction will also not have JavaScript enabled. That was very popular among nerds back when JavaScript wasn't essential to web browsing.

Fortunately, that particular brand of nerd can safely be ignored. They are a tiny, tiny minority who make a lot of noise on websites such as this.

> Do you think I would have done something as heavy-handed as compile s-expressions at runtime if it weren't necessary?

Why not, if the language makes it simple? I am not claiming that Lisp does not have more powerful abstractions than C, just that they are not usually essential to any given feature in the application.

If Lisp is actually part of the user interface, then clearly there is no way to avoid having a Lisp interpreter. This is begging the question though.

The theory says that for any two programming languages there is a constant c such that any given program can be translated from one to the other with only a c difference in size.

That's just an elaborate way of saying that you can write an interpreter (of size c) for one language in another.

Nevertheless, I have a hard time believing that viaweb could not be written in C short of writing a Lisp interpreter. For that to be true, the runtime compilation of s-expressions would have to be essential to the application; there would have to be no other way to write it.

Heh, this is algorithm bait.

The obvious algorithm is to sort all the words in order of increasing frequency, then print the 100 first. This algorithm is O(n log n) because of the sorting. It generates the list in order of frequency.

There is an O(n) algorithm that first picks some random item as pivot, then does a partioning like QuickSort where items with higher frequency than the pivot are moved to the front of the array and those with lower frequency to the back.

If the first partition has more than a 100 items, then the algorithm only has to recurse into that part. If it has fewer (k), then it prints everything in the first partition, and recurses into the second to generate the 100 - k best items.

This is expected O(n) and will not generate the list in order of frequency.

The nice thing about C++ is that memory leaks are easy to fix. Valgrind is a pretty bad-ass tool.

In garbage collected languages leaks can be very hard to track down. And they do happen from time to time.

GPU's are getting more and more programmable, while CPU's are getting more and more cores and streaming instructions.

It's getting harder and harder to tell them apart and this means a typical PC more and more looks like two general purpose computers that are talking to each other over the PCI bus. Which is kinda dumb.

> Alternatively you could throw the move that would have beaten your opponent's previous move. The logic here is that players subconsciously try to beat their own previous move.

Wouldn't that mean you should throw the move that beats the move that would have beaten the opponents previous move?

But not "Wang Wordprocessor" or "gopher technology"?

It's difficult to predict the exact form it will take.

I went like this: Hmm, might be useful as I am looking for a new monitor. Click. Download plugin? Are you kidding me? I don't have the attention span for that.

I think Bruce Schneier would take issue with the idea of assuming attackers are stupid.

How many of your bosses did not go to college?

Spoiler: The butler did it.

I think the answer is "duh", but that's not likely to stop Apple. The patent situation is a Mutually Assured Destruction scenario. Nokia could likely sue Apple and get an injunction granted on the sale of iPhones. This would be devastating for Apple, but Apple could just as easily sue Nokia, and that would be equally devastating.

Neither company can afford the risk of getting an injunction granted on their products, and both companies know this.

There is something to this.

It also explains why software written in Java sucks so much compared to software written in Lisp or C. Any idiot can get a Java program "working", but an idiot writing C code will never get anything more than "Segmentation Fault".

Sure, but I/O can be parallelized too. The argument is not specific to CPU at all.

Well, there is actually a latency gain to be had from parallellizing indidvidual requests, rather than just running several requests in parallel.

Think about this example: You have 10 printers each capable of printing 10 pages per minute. Then 10 jobs are submitted each with 10 pages. If you run those jobs in parallel, all of them will finish after 60 seconds. If you parallelize each job and print page 1 on printer 1, page 2 on printer 2 etc., then the first job will finish in 6 seconds, the second in 12, and the last one in 60 seconds. The average latency is then (6 s + 12 s + ... + 60 s) / 10 = 33 s.

Your throughput will be the same, except for a bit of parallelization overhead.

That the tip is a percentage of the bill makes no sense whatsoever. Bringing you Filets de venaison frits sur leur sauce a l'echalote is no more work than bringing you a Sloppy Joe with fries.

The only explanation I can think of is that it is a way for restaurant owners to encourage waiters to encourage customers to buy expensive, high-margin food.

The concept of reciprocity may very well be hardcoded in human nature, because it is such an effective strategy.

Yes, he thinks evidence based scheduling is a worthwhile thing to do, so he builds the feature into his application, then blogs about it.

How dare he.

Of course there is more at stake for them which should make them more careful. But whether someone reads the text in the UI is not in general a measure of cluefulness. In fact smart people may be even less willing to read anything because they assume they don't need to.

Yes. Where is the down-arrow when you need it?