[Python-ideas] Python 3000 TIOBE -3% (Massimo Di Pierro)

[Nick Coghlan]

On Fri, Feb 10, 2012 at 8:50 AM, Daniel Greenfeld <pydanny at gmail.com> wrote:
> I think it is odd to encourage users to go to use open source distros,
> but if they have installation problems (which is really common -
> Massimo/Titus/Audrey/Zed/etc seem to back me up here) to recommend
> 'somewhere' to go to commercial-but-free distros.

The reason I encourage budding developers to switch to an open source
base as soon as they can is because it comes with an entire open
source ecosystem around it. With open source code that needs to
interact with OS level APIs, the development flow is often Linux first
(it's completely open source, POSIX compatible and very popular), then
OpenSolaris and the *BSD variants (also open source, POSIX compatible,
but significantly less popular) then Mac OS X (at least it offers a
decent POSIX layer), then Windows (from my perspective, the win32 API
and NTFS stand tall as a couple of the worst cases of NIH syndrome in
the history of computing).

In other words, it's almost the exact reverse of the situation in the
proprietary desktop software world (which usually goes Windows->Mac OS
X->Linux based on desktop market share).

With POSIX compatible code covering pretty much every platform other
than Windows, and with win32 API programming being such an alien (and
verbose) experience to anyone used to the file descriptor based POSIX
world, volunteers that are willing to develop and maintain such code
on their own time are pretty thin on the ground. As aresult, it's
frequently necessary to turn to proprietary vendors to get a smooth,
Windows-appropriate user experience.

Given that Windows itself is a proprietary OS, suggesting that people
use a free-as-in-beer-but-not-as-in-speech package that lets them skip
the boring bits and get straight to coding sounds quite reasonable to
me. Sure it's not perfect, but unless you can wave your hand and
create a larger pool of volunteer developers that decide to stick with
Windows for their hobbyist development instead of embracing a
completely open platform like Linux or a POSIX-compatible open core
one like Mac OS X, Windows support is always going to lag (including
in the installation-and-deployment space).

My experience on Linux is that most things, up to and including pip
installation of C extension modules, *just works* (the exception being
that some C extensions have broken build processes and require a bit
of cajoling - it would be nice if someone actually sat down and wrote
a bdist_simple PEP instead of just talking about it on this list).
Automating the setup of these platforms is fairly straightforward
because they come with tools like Python and wget preinstalled, so you
can just use them without needing to worry about giving the user
instructions on obtaining them.

In contrast, on Windows, you have to do a lot of work up front to be
able to compile C extensions at all, and installing pip is a far cry
from being able to just do "yum install python-pip". You don't even
have access to "wget" to fetch a script that handles the setup for
you.

Getting set up to do software development on Windows is hard because
Windows is built on the assumption that the world can be cleanly
divided into "Developers" that build their own copies of software from
source code (basically, people that are willing to pay for a copy of
Visual Studio, or at least download and install one of the Express
editions) and "Users" that only run software that someone else built
(everyone else). The Linux distros (and other open source platforms),
on the other hand, make the tools to *build* the software just as
readily available as the software itself (although, these days, they
also do their best to make sure you don't *need* to build stuff from
source).

Cross platform tools like Python can make an attempt to paper over
those fundamental philosophical differences between the platforms, but
really, there's only so much any given third party can do about it
(and, for most people, trying to do so doesn't qualify as a fun
hobby).

Suppose Python core gets our packaging story on Windows fixed. What
then? Well, NumPy still runs into problems due to BLAS. What's
installing Postgres, MySQL or MongoDB on Windows like? (I genuinely
don't know, I've never tried). Are there Windows installers for PyPy?
These kinds of road blocks are endemic in Windows open source
development, and they'll likely stay that way unless MS release a
native Windows POSIX compatibility layer that isn't horrible (I
personally expect that to happen somewhere around the time the Earth
gets swallowed by the Sun).

> If we should be pointing new users to ActiveState or Enthought, maybe
> we should just change the python.org default installers to what they
> provide.

No, because the python.org installers are what the redistributor's use
to create their own sumo packages.

It may be reasonable for us to point new users that aren't already
experienced Windows software developers directly to the sumo
distributions, though. For example, as far I know, Python(X, Y) does a
nice job of dumping a comprehensive Python environment on a Windows
system without relying on a proprietary vendor.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia