Re: Could the Python swallow the Fox?



As you said, Python (3000)is not backward compatible .... ergo, you are
going down the same old path.... agree?

"Paul Hemans" <darwin@xxxxxxxxxxx> wrote in message
news:edGW1aZFJHA.4784@xxxxxxxxxxxxxxxxxxxxxxx
I am going to throw another view into the mix here.

I have been faced with the same question. 1 man shop with lots of apps. A
while ago I made a big push to convert all the user interfaces to HTML. It
was tricky because what I do is to host the interfaces in the _webbrowser
while running on the desktop and the same interfaces run through the web.
Works great and I can't believe more people aren't into that approach. The
other benefit of HTML interfaces is caching, I built a web server into the
app so that it can be run as a service and users can access the app across
the network. Performance is great.

For desktop apps, I am hoping that 64bit platforms hopefully won't affect
my apps too much, I have heard that I should be able to run the app in the
32bit compatible mode (which I haven't tried yet). Run as a COM server I
am able to pull the HTML interfaces into .Net. So I can also have a '.Net'
frontend when it is a corporate requirement for installation at some
sites.

I can write in C# and C++ but in my mind they are not what I would use for
writing business type applications. Strong typing is great in it's place
but it is annoying as hell when all I care about is building a business
rule. VB.Net might be alright to do the job as well, but I am very wary of
being locked into a proprietory language again.

Enter the Dynamic Language Runtime (DLR) layer for the .NET.

Since the DLR acts as a layer on top of the CLR, dynamic languages that
leverage the DLR will have full access to .NET programming libraries
written in other languages like C#. So I have the access to other
languages when I want them. But the DLR is also supporting non-proprietory
languages (Ruby, Python, Javascript).

I am having a good look at Python. I have the skills to use Javascript but
Python has an enormous number of support libraries already existing for
anything I could want to do with it. It seems better suited to backend
processing. I have been a MS shop through and through, so until recently
any open source language wasn't going to be an option .... until I read
about IronPython and .Net. MS has employed the guy that was heavily
involved in Jython (Python on Java) to write IronPython, which is Python
in .Net, and made it open source!! Apparently IronPython will run in
Silverlight as well. God, another language right, that's all I need, but
the more I look at it the closer to Fox it seems.

Related, but separate, is that I am starting to take Google's offerings
seriously. Google is doing some revolutionary things that may have very
big implications for programmers. What's that got to do with Python?
Google has the guy employed that wrote Python, and Python is core to their
web applications, and now MS has their own version of the language. That
is job security, I think.

So the pathway forward will be to take the business rules and convert them
to run in Python. They will probably be written in IronPython, though
apparently there are implementations of Python that can be accessed
through the MS script control. (Also through ASP pages). This code will be
triggered to run from the serverside code in the HTML interfaces. The
cursor record is converted into an object and passed into Python for
business processing. Hopefully, this code will be generic enough to run in
Google web apps as well.

Performance? Check this out ... "IronPython already provides better
run-time performance than the conventional C-based Python implementation
in some contexts, and, in an interview with eWeek, Microsoft developer Jim
Hugunin claimed that the eventual goal for IronPython is to achieve
performance that is 'at least two times faster than the native C-based
implementation.'"

At the end of the day I have to ask ... what if cloud computing ends up
the winner? Am I going to have to rewrite again? I have my own personal
reasons for believing that cloud computing has compelling reasons for it
to be a serious competitor to the desktop. I have been a loyal MS adherent
for many years, but I don't know why MS didn't implement the Fox onto the
DLR when they obviously have the ability. It really ticks me off, this is
the second time in my career when corporate decisions have led to a
language I am using being killed. So no more lock-in, the 'suits' should
not control computer languages, it is Javascript & Python for me.

With the new implementation of Python (3000) not being backward compatible
with earlier versions, now might be a good time to start to seriously look
at the language.




.



Relevant Pages

  • Re: Does Python really follow its philosophy of "Readability counts"?
    ... with enforcing that "shouldn't" in the language itself? ... In Python, direct access to pointers is a MUST NOT. ... where you are allowed to mess with the implementation. ... human assembly language programmers? ...
    (comp.lang.python)
  • Could the Python swallow the Fox?
    ... For desktop apps, I am hoping that 64bit platforms hopefully won't affect my ... Enter the Dynamic Language Runtime layer for the .NET. ... I am having a good look at Python. ... IronPython and .Net. ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Could the Python swallow the Fox?
    ... For desktop apps, I am hoping that 64bit platforms hopefully won't affect ... Enter the Dynamic Language Runtime layer for the .NET. ... I am having a good look at Python. ... involved in Jython to write IronPython, ...
    (microsoft.public.fox.programmer.exchange)
  • Re: Basic inheritance question
    ... used 'this' in C++ and Java. ... but in Python it doesn't. ... language, they would write a lot of ten liners that is changed a LOT ... Add three levels of inheritence and a couple globals and you'll find out ...
    (comp.lang.python)
  • Re: Python for Fortran programmers
    ... proposition for Python in the Fortran community", ... compiled language such as Fortran or C++, but I would still prefer to ... greater number of programming errors that are typically detected by a ...
    (comp.lang.fortran)