RE: [Pythoncard-users] Python distribution problems

[Schollnick, B. <Ben...@xe...>]

> > Python and Pythoncard/wxPython/insert favourite GUI toolkit here are
> > *never* going to make a huge impact on the Visual Basic=20
> market. IMHO,=20
> > though, that's not a valid reason to stop using them.
>=20
> growing number of VFP/VB users who are unhappy with Microsoft for the=20
> way they've been brushed aside in lieu of the latest Flavor of the=20
> Month. These people are looking to pick up something new to=20
> develop in,=20
> and many of them would prefer not to commit to another=20
> Microsoft tool.=20

Which is sensible....

I have not used or purchased another Microsoft language since they sold
QuickPascal v1.0.  They promised features that did not exist in v1.0 and
I never forgot that lesson.

> Cool tools such as PythonCard help to increase the chance that they=20
> move to Python instead of remaining on the Dark Side.  ;-)

True.

> 	That's why if you're looking to grow your user base,=20
> it's important to=20
> make things as familiar as possible to those folk.=20

Not necessarily.  What we need to supply is something that is overall
better than what they were using.  Yes, it should be a usable and
productive User Interface and Design... =20

But familiar does not necessarily mean better.

Can you give us a few examples? =20

For example, the Windows Registry.  That's familiar to Windows
programmers, but would you suggest that we a need a registry like
component in Python or PythonCard?

I think I can safely say that 90% of Python/PythonCard developers would
say "NO"....

Yes, it's absurd comparison...  But you did not include any examples...
As I mentioned, familiar does not necessarily equal better.  Just
familiar.

> They're leaving=20
> their former comfort zone for something foreign, and the fewer hoops=20
> they have to jump through, the more likely they might stick with your=20
> product, and evangelize it to others.=20

Yes, but it also is a situation where a better product may have a small
learning curve, but is worth the investment.

I think PythonCard needs better documentation, but for 90% of the
situations, the documentation is more than enough....

> So while the things you mention=20
> are not valid reasons for an existing PythonCard developer to *stop*=20
> using the tool, they would be sufficient for a new PythonCard=20
> developer coming from the VB world to never *start*.

The Pythoncard tutorial that I used to evaluate PythonCard was enough to
convince me to use the software.  I would assume that anyone that was
thinking of using it would attempt to use the tutorial and start basing
a decision on that.

I am unclear on what you are suggesting they are basing their decisions
on?  (The quote does not include it)  Presumably on the fact that they
need to instead Python, WxPython, and PythonCard?  Windows programmers
are fully aware of dependencies...  .Net anyone? =20

		- Benjamin