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 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.
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.
So programmers who work with objects and methods don't have to think about them, while programmers who work with macros do? Sorry, but this just seems ludicrous to me.
Perhaps what you mean is that when a construct is unfamiliar to a programmer then they have to think harder about how to use it?
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.
As far as I can tell, you're talking about your experience of what's easier and harder. Your experience is not "the brain".
Certainly if you're habituated to the object-model style of programming, other forms of abstraction may seem weird. The irony here is that twenty years ago, the people making your kind of argument were directing it all against objects.
As a side note, treating programming objects as if they were physical objects works as long as there's a good fit between the two. As soon as you need the objects to behave in ways that physical objects don't (and believe me, in any complex OO system, you will), you find yourself tied up in knots that it will take a lot of thinking to extricate yourself from. (Speaking of complexity that isn't intrinsic to the problem...) Not accidentally, the tools that people reach for then tend to be ersatz versions of metaprogramming (reflection, code generation), and Greenspun is off to the races...
"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."
It's not. It's just a matter of practice. Most people find OO modeling natural (even when it is extremely tortured and difficult) because they've acquired a comfort with it born of many hours of practice. You might argue that you're not referring to familiarity with the paradigm, but I think you are, and don't realize it.
I assure you that a functional style has equal power to abstract as a OO style. You're right, our brains have a good ability to think of things as sets of objects. 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.
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 can't resist pointing out again how laughable this sounds to anyone who remembers the long debates about how hard it is to "think in objects" and how objects "would never work for the masses". (Actually, that was right, because the "most people" in question are still largely writing much the same code as they always did and always will; now they just surround it by "public class".)
I'm not disagreeing with you at all; I just feel compelled to make sure that somebody else sees this irony!
Maybe it's just because I've been using Common Lisp exclusively for a year, but what's so hard about macros? Especially, using them (as opposed to writing them).
You don't have to think about how the macro is written or what it's expanding into when you use it, you just have to know the semantics of the macro. "When I pass such and such, it will produce code that evaluates this in that way". Similar to a function or a language primitive right? If you're writing a for loop in Java, do you have to care how it's implemented in the JVM?!
As for writing macros: you're writing a function that takes an AST and returns an AST to use as replacement. This function will be called at compile-time to change your nice high-level macro call into lower-level code. There are a couple pitfalls (variable capture, multiple evaluation) but they're always the same and you'll learn about them quickly enough that it will become a sixth sense.
Yeah. Jeff's article makes it sounds as though Tog later refutes the original quote. But all he does is mention that Ctrl-C and Ctrl-V are exceptions because you can use them while using the mouse.
IMO, the post that Jeff linked to in the comments (http://tinyurl.com/2odgua) provides a better criticism of Tog's keyboard vs. mouse claim.
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.
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.
Do you think I would have done something as heavy-handed as compile s-expressions at runtime if it weren't necessary?
We had a page description language called RTML that was Lisp underneath. Users created templates in it, which we then executed to generate their pages. It is these page templates that are still stored on disk as s-expressions in the C++ version.
> 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 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.
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.