On Jul 27, 10:39 am, David Cournapeau <courn...@gmail.com> wrote: > On Tue, Jul 28, 2009 at 12:28 AM, Dotan Cohen<dotanco...@gmail.com> wrote: > >> It is neither efficient or inefficient: it is just a distribution > >> tool, to deploy python software in a form familiar to most windows > >> users. It does not make it any faster than running the software under > >> a python prompt. > > >> As much as I like python for scientific programming, I would say > >> python is pretty far from the stated requirements in the posted blog > >> post. It is difficult to deploy software written with python (much > >> better than the alternatives, though), and it is slow if you can't > >> leverage numpy/scipy (where vectorization does not apply). > > >> It remains to be seen whether it will be true in practice, but > >> something like F#, with its integration in VS 2010, seems much closer > >> IMHO. It is compiled, high level language, and backed by the biggest > >> software vendor in the world. > > > The blog post is not looking to distribute his code, but he would like > > it to be cross platform for his own reasons. VB is not cross platform. > > I understand his "efficient binary as Ansi C" partially as a > deployment requirement, and independent of cross-platform issues. As a > scientist, being able to share my software with colleagues is a non > trivial matter. Python does not make this easy today. > > F# has nothing to do with VB: F# is a ML-language inspired from OCAML, > and run on top of the CLR. It can thus leverage the huge .net > framework (lack of non numerical API is one of the biggest matlab > hindrance, and comparatively big advantage of python + numpy/scipy), > and benefits from the much more efficient implementation compared to > python (under the currently CPython implementation at least). > > Some recent F# versions are compatible with mono, making it compatible > on most platforms that matter today for research (but of course, you > lose the IDE integration outside windows). > > David- Hide quoted text - > > - Show quoted text - I wish . . .
For comparisons, Mathcad has the symbolic notation appropriate for mathematical communications. I like features of Mathematica and Maple but Mathcad provides for the user to 'stay' with mathematical symbolism longer. I prefer Matlab execution environment. So I develop concepts in Mathcad, prove them in Matlab and then compile to through C where direct performance is required. Maple and Matlab have this type of relation. Matlab, from The Mathworks, has a companion product called Simulink. This allows the user to graphically build ‘algorithms’ in block form. There is a similar Python function. Each of these components would best be served if allowed to exist independently but supported with transparent integration. I would like to develop in a stable user environment - a stable GUI. And then allow efficient algorithms behind the scenes. By separating the functionality of the workspace, the user can be given (or create at will) a GUI that suites her desires and provides for the creativity and productivity she chooses. The functionality under the GUI should then be pluggable. Developers can provide solutions from many directions, compete for varying performance requirements, enhance functional features technology changes, and still not disturb the fragile user interface. Allow the user the comfort of home. Let them keep whatever GUI suits them and provide for their deployment (if any) needs behind the scenes. Ray -- http://mail.python.org/mailman/listinfo/python-list
