really reminds me of american business practices my father used to be exposed to in the 1960's and 70's over here ("out there", to you) while working for a german manufacturer.
"out there". hah. hey i can see russia from my home.
your post is not detailed in that part, but the incompatibilities that you talk about may very well stem from a very vexing problem with python, that is the version dependency of compiled c extensions.
this probably does not matter for people on real computers, but windows folks will have to (*) get themselves visual c to re-compile an extension to fit the version of python; or (*) recompile all of python plus their extensions with a free alternative to msvc; or (*) hunt for ready-made binaries on the web. i believe the issue goes away when you use the ctypes module to access c executables, as then the c part and the python part work in a more decoupled fashion.
as much as one may criticize windows folks for 'not being (able|willing) to compile c', it has to be said that (*) python is also here to make programming easier and more accessible and to take 'compilation' out of 'programming' where possible; (*) the choice of msvc as the standard c compiler for python on windows is a pity (as it is not a free tool); (*) reading how-to's on compiling *can * be quickly discouraging.
i am not 100% sure but i think the necessity to recompile a given extension module for a new version of python is caused solely by a mismatch in the version numbers (the one in the extension and the one that python announces). this makes any troubles encountered when moving from python 2.x to 2.x+1 even more annoying.
the area of smooth and easy upgrading of python c components has for sure a lot of openenings for creative thinkers. if it was for 100% python modules alone, i would migrate from 2.5 to 2.6 and early on to 3.0 with few second thoughts. anything that has ever stopped me upgrading has been the availability of the binaries that i didn't want to loose in the process.
Re:Establishing de facto (open source) standard ?
on
ECMAScript 4.0 Is Dead
·
· Score: 1
i absolutely second the sentiment that what is needed is a sort of CLR (common langugae runtime) / parrot / bytecode machine implementation, on top of which languages can be implemented. that clr could be expressed in some sort of "high level assembler", on top of which language implementors can pour their syntactic icing that essentially makes bytecode accessible and readable.
one could even envision some sort of "universally accepted plugins"---code that is identified by a URL, verified by secure digests, and written either in the clr or some platform-specific code according to use. popular plugins could provide services such as displaying certain image formats, playing sounds, or represent widgets, and the user wouldn't have to download them anew for each website (as is already posssible when site A references http://x/foo.png, then when site B references the same image, it may be retrieved from cache). levels of trust could be community-derived and user-configurable, so that some things that have attained a high score in terms of tested use would just load without acknowledgement, while code without that trust level would need explicit consent.
Slashdot Mirror
really reminds me of american business practices my father used to be exposed to in the 1960's and 70's over here ("out there", to you) while working for a german manufacturer. "out there". hah. hey i can see russia from my home.
your post is not detailed in that part, but the incompatibilities that you talk about may very well stem from a very vexing problem with python, that is the version dependency of compiled c extensions. this probably does not matter for people on real computers, but windows folks will have to (*) get themselves visual c to re-compile an extension to fit the version of python; or (*) recompile all of python plus their extensions with a free alternative to msvc; or (*) hunt for ready-made binaries on the web. i believe the issue goes away when you use the ctypes module to access c executables, as then the c part and the python part work in a more decoupled fashion. as much as one may criticize windows folks for 'not being (able|willing) to compile c', it has to be said that (*) python is also here to make programming easier and more accessible and to take 'compilation' out of 'programming' where possible; (*) the choice of msvc as the standard c compiler for python on windows is a pity (as it is not a free tool); (*) reading how-to's on compiling *can * be quickly discouraging. i am not 100% sure but i think the necessity to recompile a given extension module for a new version of python is caused solely by a mismatch in the version numbers (the one in the extension and the one that python announces). this makes any troubles encountered when moving from python 2.x to 2.x+1 even more annoying. the area of smooth and easy upgrading of python c components has for sure a lot of openenings for creative thinkers. if it was for 100% python modules alone, i would migrate from 2.5 to 2.6 and early on to 3.0 with few second thoughts. anything that has ever stopped me upgrading has been the availability of the binaries that i didn't want to loose in the process.
i absolutely second the sentiment that what is needed is a sort of CLR (common langugae runtime) / parrot / bytecode machine implementation, on top of which languages can be implemented. that clr could be expressed in some sort of "high level assembler", on top of which language implementors can pour their syntactic icing that essentially makes bytecode accessible and readable. one could even envision some sort of "universally accepted plugins"---code that is identified by a URL, verified by secure digests, and written either in the clr or some platform-specific code according to use. popular plugins could provide services such as displaying certain image formats, playing sounds, or represent widgets, and the user wouldn't have to download them anew for each website (as is already posssible when site A references http://x/foo.png, then when site B references the same image, it may be retrieved from cache). levels of trust could be community-derived and user-configurable, so that some things that have attained a high score in terms of tested use would just load without acknowledgement, while code without that trust level would need explicit consent.