Resetting PHP 6
Resetting PHP 6
Posted Mar 24, 2010 16:44 UTC (Wed) by cdamian (subscriber, #1271)Parent article: Resetting PHP 6
I also think choosing UTF-16 was wrong, most of the code, html and databases out in the real world are UTF-8 and choosing anything else is just silly.
I was at the OSCON in 2000 when Perl6 was announced and at that time I was working in London on a large Perl project and I wasn't convinced that it was a good idea. These kind of rewrites and revolutions usually take too much time and destroy your current user base if you are not careful. And while the rewrite happens the whole world keeps on moving. And if you make your users change all there code, they might as well change to a new language or system.
Some other projects trying the impossible:
- Python3 (though not a rewrite, but still slow adoption at the moment)
- typo3 5
- Doctrine 2 (small enough that it might work)
- Symfony 2 (hopefully with some migration path in the future)
Change is good, but too much change not always so.
Posted Mar 24, 2010 17:40 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
Posted Mar 27, 2010 22:53 UTC (Sat)
by man_ls (guest, #15091)
[Link]
Even when backwards compatibility is a requirement, like for Java (where the rare breakages are clearly signaled and known by everyone), testing time for new versions has to be allocated. With Python migrations are a showstopper for most people unless the new version somehow provides great advantages (which for me it doesn't). For developers of the language itself and the runtime, the supposed benefits of not having to be backwards compatible are probably offset by having to support two or three versions indefinitely.
Adoption of new python releases have always been slow. I'm using Python 2.5 mostly since
that is what is used in Debian unstable by default right now. Python2.6 was first released in
2008.
Resetting PHP 6
Of course Python2.6 and Python3 are avialable. I just try to write things so as to minimize the
effort it takes to port it to newer versions, which for me is acceptable since none of it is really
very complex. Larger projects are going to have larger problems, of course.
The big difference between Perl 6, PHP 6, and Python3 is that Python3 is out right now,
avialable, has a bunch of transition tools, code is somewhat backwards compatible to 2.6, and
it's had a couple stablizing releases.
Also it's not just about the Unicode support... Strings in Python 2.x were heavily overloaded
and used for _everything_...(the major alternative being using Array module, which is a
wrapper around C arrays, which end up being slower for most things then native python data
types) Being forced to use data encoded into ASCII strings for
everything has grown quite painful. Especially since every year less and less of your data is
actually
going to be stored in ASCII strings! It's all UTF-8 or binary.
Having _all_ strings be unicode while introducing the byte data type is a godsend for a lot of
things I need python for. Keeps things simple, clean and fast.
Backwards compatibility
The big difference between Perl 6, PHP 6, and Python3 is that Python3 is out right now, avialable, has a bunch of transition tools, code is somewhat backwards compatible to 2.6, and it's had a couple stablizing releases.
But "somewhat backwards compatible" is not good enough. For any non-trivial applications you still need to test everything again, and probably do some coding + testing + deploying. In business settings it translates to money and pains; in volunteer projects just pains.