Differences between revisions 2 and 3
Revision 2 as of 2003-04-24 03:06:06
Size: 1084
Editor: pool-151-203-223-75
Comment:
Revision 3 as of 2003-04-25 16:05:23
Size: 4059
Editor: pool-151-203-223-75
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
'''Notes Below'''

---------------------------------

How does one go about demonstrating the agility of a
programming language? What is agility anyway? Is there some sub-set of
agility that represents what we *really* mean to link Python with? In
what ways, specifically, is Python agile and/or more agile than other
choices?

If we want Python to be strongly associated with agility, we should help
our audience understand agility and buy in to agility in such a way that
use of Python follows naturally. It's like when people in usenet
discussions say "X isn't a real Y because it doesn't have Z." What they
really mean is "I learned about Y in the context of a product that
features Z."

We could be that context for agility. If we did this right, we might
hear people say things like "Java isn't a *real* agile language because
it doesn't provide dynamic typing." or "VB isn't a *real* agile
language because it doesn't support introspection."

----------------------------------
Line 7: Line 31:
For programmers, the pain will have to do with the inflexibility and tediousness of their current language, or lack of cross-platform support, or lack of an interactive mode, etc.  For non-programmers we need to identify other areas of pain, such as missing schedules because it takes too long to write the code, systems that are costly or difficult to maintain because nobody can comprehend the code, new
programmers taking too long to get up-to-speed and productive, development teams that are out of touch with the needs of the business, etc.
For programmers, the pain Python relieves will have to do with the inflexibility and tediousness of their current language, or lack of cross-platform support, or lack of an interactive mode, etc.

For non-programmers we need to identify other areas of pain, such as missing schedules because it takes too long to write the code, systems that are costly or difficult to maintain because nobody can comprehend the code, new programmers taking too long to get up-to-speed and productive, development teams that are out of touch with the needs of the business, etc.
Line 11: Line 36:

------------------------------------

Also need different messages for Mac, Windows, and Unix programmers. Screenshots of
an IDE, examples of how to quickly put together a GUI, that sort of
stuff has to go before the nuts and bolts of Python-the-language.

-------------------------------------

Some relevant papers:

http://www.shtull-trauring.org/aron/Work/Articles/SoftMeth.pdf

http://www.zoteca.com/information/wp/pythonEAI.htm

One of the things that is obvious to me is that Python is the best
language for 4M because it allows you to build rapid prototypes that
evolve into the final working system in the most efficient manner possible.

-------------------------------------

You need to get the message out that all programming languages are
not equal. As long as the manager believes that it doesn't really
matter which language you use, because 'they are all about the same'
then it will be hard to get him to change languages.

--------------------------------------

'You will make the same number of mistakes you always do. But since
the development cycle is shorter, you will, in effect, make them
earlier. This gives you more time to react -- to redesign, to get the
requirements changed, or simply to warn people that what they want is
turing out to be a lot harder than anybody thought.'

---------------------------------------

"In many ways, it's a dull language, borrowing solid old concepts
from many other languages & styles: boring syntax, unsurprising
semantics, few automatic coercions, etc etc. But that's one of
the things I like about it." --Tim Peters on Python, 16 Sep 93
 
This is, I think, a quote that should be used in marketing Python. It's a
familiar, powerful, *comfortable* language, with all the power required to
create full, powerful applications quickly and easily. Take away the fear
("it's a dull language") and promote its power.

The key concept identified so far is Python is an Agile Programming Language.

We need to refine and target this message.

Notes Below


How does one go about demonstrating the agility of a programming language? What is agility anyway? Is there some sub-set of agility that represents what we *really* mean to link Python with? In what ways, specifically, is Python agile and/or more agile than other choices?

If we want Python to be strongly associated with agility, we should help our audience understand agility and buy in to agility in such a way that use of Python follows naturally. It's like when people in usenet discussions say "X isn't a real Y because it doesn't have Z." What they really mean is "I learned about Y in the context of a product that features Z."

We could be that context for agility. If we did this right, we might hear people say things like "Java isn't a *real* agile language because it doesn't provide dynamic typing." or "VB isn't a *real* agile language because it doesn't support introspection."


The next step is to craft two different messages, one for programmers and one for non-programmers. We need to identify the areas of pain that Python eliminates through its agility.

For programmers, the pain Python relieves will have to do with the inflexibility and tediousness of their current language, or lack of cross-platform support, or lack of an interactive mode, etc.

For non-programmers we need to identify other areas of pain, such as missing schedules because it takes too long to write the code, systems that are costly or difficult to maintain because nobody can comprehend the code, new programmers taking too long to get up-to-speed and productive, development teams that are out of touch with the needs of the business, etc.

Nobody changes their behavior unless they have a big enough pain to motivate them, and a big enough potential reward to justify the transition costs (in terms of time, effort, short-term loss of productivity, etc.)


Also need different messages for Mac, Windows, and Unix programmers. Screenshots of an IDE, examples of how to quickly put together a GUI, that sort of stuff has to go before the nuts and bolts of Python-the-language.


Some relevant papers:

http://www.shtull-trauring.org/aron/Work/Articles/SoftMeth.pdf

http://www.zoteca.com/information/wp/pythonEAI.htm

One of the things that is obvious to me is that Python is the best language for 4M because it allows you to build rapid prototypes that evolve into the final working system in the most efficient manner possible.


You need to get the message out that all programming languages are not equal. As long as the manager believes that it doesn't really matter which language you use, because 'they are all about the same' then it will be hard to get him to change languages.


'You will make the same number of mistakes you always do. But since the development cycle is shorter, you will, in effect, make them earlier. This gives you more time to react -- to redesign, to get the requirements changed, or simply to warn people that what they want is turing out to be a lot harder than anybody thought.'


"In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it." --Tim Peters on Python, 16 Sep 93

This is, I think, a quote that should be used in marketing Python. It's a familiar, powerful, *comfortable* language, with all the power required to create full, powerful applications quickly and easily. Take away the fear ("it's a dull language") and promote its power.

DesignMarketMessage (last edited 2008-11-15 14:00:51 by localhost)

Unable to edit the page? See the FrontPage for instructions.