Compiling to native

MicroPython seems to be compiled to native. Maybe Cython too?

Quora Answer : Will Python ever develop into a significantly different language to near the speed of C-based applications? What changes are expected if that will occur (e.g. on runtime environment, development flexibility, etc)?

Dec 22, 2017

I don't see any particular reason that Python can't get "just-in time" compilation, that brings its performance as near to C as you not caring. (The Java and Javascript VMs are probably pioneering this. At some point I expect the same ideas to be in Python. Or possibly Python to jump to using a version of the Javascript VM.)

The future of performance, in general, though, is offloading more of the work to dedicated hardware. Right now, graphics cards are the most common example of that. I'm betting that other kinds of extra hardware speed ups will be coming for other kinds of applications : speech, visual recognition. Perhaps some cryptography. Maybe even more hardcore maths operations for machine learning etc.

When your programming language is basically a wrapper for calls to specialized hardware, Python vs. C performance is neither here nor there.

Another big bottleneck in Python is the PythonGIL that prevents you doing proper parallel computation on multiple cores. I'm not enough of an expert to know if you could remove the GIL and have Python keep working. But I suppose someone could produce something extremely Python-like that removes it. And gets better performance through support for multiple processors.

Elixir is an interesting comparison. A Ruby-like language written for the Erlang VM and with Erlang's actor-model. You could similarly have something Python-like on top of a different underlying architecture.

I don't think the future of Python is to become more C-like in general though. If you want a lower level systems programming language that has some of the niceness of Python, then look to Rust or Go.

(EDIT: though MicroPython may be compiled in a more C-like way)

Compare Ruby

If you want another language to play with the RubyLanguage is well worth playing with.

: I was going to ask you about languages. Your profile suggests you are still mainly PerlLanguage oriented. I won't hear anything said against Perl, but I confess that I've shifted into thinking of Python as my default language for any new project. And now, when I come to maintain an old perl script, I'm likely to re-write it in Python as part of the maintainence process.

: I looked at the RubyLanguage site, but haven't yet seen a compelling reason to abandon Python for it. What are the advantages? – PhilJones

Quora Answer : Is using Python for developing a desktop environment a good idea? Why, or why not?

Sep 24, 2015

In principle, it's a great language for it. It's exactly the KIND of language that was created for desktop environments. (SmallTalk was the language invented for just that purpose - GUIs - and Python is close enough to Smalltalk that it retains 90% of the same virtues.)

In practice, the issue is that any desktop development today is closely tied to particular platforms / GUI toolkits and frameworks. Almost all desktop development is targeted at a specific toolkit, and the toolkits are all designed in / in conjunction with and using other languages. For example, Microsoft's desktop is now largely .NET, and C# is the default language for that. Apple's preferred languages are Objective C and now Swift. Google's Android (not usually desktop but can be) is Java. Etc. Other "cross-platform" libraries like GTK and Qt are C++ (I believe). So Python is always a second-class citizen with respect to them ... depending on bindings to / wrappers to those toolkits, that become available later, may not be so fully supported or documented or have many tutorials available.

These practical issues - and the inevitable fragmentation of effort as different projects adopt different toolkits - seem to have sunk many potentially awesome projects (eg. PythonCard). And has probably held back Python desktop development more than you'd expect.

A final thought. And I know this is slightly off-topic but it's something I'm pretty excited by right now. A book I'm just finishing, that I wholeheartedly recommend, is : .

That's a Clojure book, but I'd recommend it to almost anyone who has a bit of experience with functional programming and is prepared to read Lisp syntax. The examples and didactic rhythm are excellent.

It's very clear to me now that Functional Programming ideas are finally going mainstream. And "reactive" is the new paradigm for managing UI. Even in non FP languages like Javascript, reactive toolkits are becomming available.

I don't know your situation or your motivations. But if you sit down and work hard, you could create a great "traditional" GUI toolkit in Python. You could finally come up with the GUI equivalent of what Django is for web-development. But you'd still, basically, be reinventing a paradigm that Smalltalk established in the 1970s. The BEST you could possibly do would be to come up with a Python-looking reinvention of Smalltalk.

Or, you could decide to look to the future, and embrace the reactive paradigm. Either within Python (not entirely easy, but I think with clever use of decorators and generators you could get a fairly elegant DSL for declaring GUI layouts and event-streams) or a real functional language. In 2015, I'd certainly want to be going in this second direction.