On Thu, 16 Dec 2004 06:13:41 -0700, Stewart Midwinter <stewart.midwinter@gmail.com> wrote:

A number of people commented on the article in GCN, at http://gcn.com/vol1_no1/daily-updates/28026-1.html, and wondered if more could not be done to address the perception of speed. The point is made that although people mention all of the benefits of Python, like ease of use, flexibility, they always come back to making references to its speed. And the question is raised, "what can we do to counter this perception?". I think the answer lies in a quote by a user in that same article: "At first, Doak was worried a Python-based program would not run simulations quickly enough, however he found performance to be acceptable.

Let's turn this around. Forget about trying to create a perception that Python is fast. Compiled languages will always be faster, at least for large applications. Or at least they'll be perceived that way. So let's acknowledge that upfront, but say "Python is fast enough for most uses", but then go on to say "and in addition to its acceptable speed, it offers many advantages like ease-of-use, flexibility, easy code maintenance (since the code is still understandable 6 months later!) etc.

Marketers of other products have used this same technique successfully. For example, at one time there was a perception that Kellogg's Corn Flakes were old and boring. Sales were slipping. Rather than refute that, marketers turned the issue on its head by emphasizing that the product had been around a long time because it was good, and good for you. Hence was born the slogan "taste them again, for the first time".

Possible slogan for Python: "Fast enough, and better in many ways".

One possible marketing strategy is to use the adjective "fast" in a broader sense. The Python slogan could be something like: "Programming has never been any faster" -- this changes the playing ground, from raw performance to *programming* performance. And sure, nothing beats Python (the overall package) in this respect. It can deliver fast code in a short time. Othere languages are faster to run, but take longer to code... BTW, I would move away from the "fast enough" when talking about performance. It's difficult to qualify what is "enough" in marketing terms; also, a selling/winning message can't be seen as taking excuses for any reason. On the other hand, Python never claims to be the fastest language on raw execution performance, but only to be fast; but in this sense, being "fast enough" is the same as being "fast". So, I would never say, "Python allows you to write fast enough code in a short time"; I would say "Python allows you to write fast code in a short time". Leave the "fast enough" out of this, please. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com

On Fri, 2004-12-17 at 09:20 -0200, Carlos Ribeiro wrote:

BTW, I would move away from the "fast enough" when talking about performance. It's difficult to qualify what is "enough" in marketing terms; also, a selling/winning message can't be seen as taking excuses for any reason. On the other hand, Python never claims to be the fastest language on raw execution performance, but only to be fast; but in this sense, being "fast enough" is the same as being "fast". So, I would never say, "Python allows you to write fast enough code in a short time"; I would say "Python allows you to write fast code in a short time". Leave the "fast enough" out of this, please.

I totally agree. Personally, the first thing I think of when I see "enough" is "640k aught to be enough for anybody" (quote from you-know-who), like you are defining the needs of the user. Promote the strong sides, don't excuse the weak ones. "Fast enough" is not a positive marketing term, it's an excuse for a problem which I fail to see in Python. Hardware cost is way lower than programmer cost - I am convinced that in most cases the total expence is lower for a Python solution compared to an equal performing C, C++, C# or Java solution. -- Eirik Mikkelsen <eirik.mikkelsen@unix.net>