HOPE: The Ease Of Python With The Speed Of C++

[alcalde]

LOL - I think that you have hit the nail on the head.

C/C++ are languages for high performance.
Java/C# are the languages for enterprise software
Python/PHP are scripting languages for web.

As someone who once tried to drill a brick wall with a totally blunt wood-bit, I can definitely recommend picking the right tool for the job...

You're confusing where a language has achieved most of its success with what the language is actually capable of being used for. For instance, while PHP really is designed for web coding, Python is a general purpose language. Popular software such as Dropbox and the Mercurial version control system are written in Python. Python is also used heavily in finance and science.How would one even define "enterprise software"? There really aren't the hard and fast boundaries you suggest.

[alcalde]

Try using Julia or Golang. Python isn't really needed anymore now that better programming languages are available.

Of course then you have to define "better". You also have to address the fact that as very new languages, the ecosystems - books, libraries, tutorials, trained developers, conferences, etc. - for Julia and Go simply aren't there yet. Heck, they're also both languages "in progress" that may still change significantly at any point in time.

[alcalde]

Interesting, how does it fair against Cython?

I found the original mention of Nuitka misleading. While it does convert to C++ there's been little focus on speed yet, only compatibility. As such, it's not close to the performance of Cython or Numba. The option to get a single executable with no dependence on Python library files isn't working at the moment either. As such, there's little real benefit to it at the moment, although there can certainly be significant benefit in the future. It's a bold and impressive project.

[przemoli]

LMAO about that "easy use of C++". Yeah. Right.
Inner class overloaded functions anyone?

LMAO about that "speed of C++". Yeah. Right.
That's why game engine devs steer away from:
* Boost
* Exceptions
* Templates
* STL
* etc.

C++ must be daemon of speed.
And aren't those You know features introduced for the sake of "easy use"?



Conclusion:
Everybody needs ARN'T same.

HOPE looks like very, very bad idea (how do You debug Your code?), that was already proven not to work (Facebooks HIPHOP).
But if it works for You. Thats ok!
(Thought PyPy should be checked first. No need to spread Python "we need more ways to do it!" to python implementations without a reason.)

[alcalde]

Noone has been arguing for the ease of programming C. That is very different from C++.
I use a mix of languages, and ive never understood the idea that python would be so much easier than c++
static typing is so nice to have. It captures so many bugs at the compiletime instead of failing during runtime.
On the other hand, running things in interpretive mode is alsso nice. So a bit of pros and cons.d

1) Have you SEEN Python? It looks like pseudo-code. Here's a snippet from an article about a programming contest. The problem was to find the frequency count of the letter that appears the most times in string S and return the length of the string minus that number.

def getmin(s):
    return len(s) - max(s.count(ch) for ch in s)

That's it. The entire program. Python takes all the boilerplate and scaffolding and throws it out and makes things ridiculously consistent and hence intuitive. Know how to do X in one context, and you know how to do it in every context. C++ is widely known for having dozens and dozens of exceptions to rules and corner cases galore. Given those two facts, it should be clear how "python would be so much easier than C++". It's designed to be.

2) As someone who has over 17 years (sole) experience with statically typed languages.... no, no it's not "so nice", although we tell ourselves that all the time. So long as we never tried to do without it, we could convince ourselves that it was true... even as we dealt with function overloading, generics, inheritance schemes, typecasting and all sorts of other schemes to get around the self-imposed straitjacket of static typing. Static typing doesn't capture "so many bugs". In languages like C++ and where I principally came from, Delphi, (the static typing in languages like Haskell is a whole different story), it captures errors of the "I tried to pass the string 'kangaroo' to the square root function" variety. In short, errors that almost never happen and when they do they're immediately spotted anyway since they crash spectacularly. All the boilerplate and blood and tears just to know beforehand that we definitely passed an integer into a function that expected an integer. Big deal. The integer's supposed to be between 1 and 5. Static typing can't catch that it's a six. Static typing won't help you is a function needs two integers, A and B, but B has to be at least 2 x the value of A. Static typing doesn't save us from poorly formed cascading if statements, the "1.538" that ended up as "1.58", or any of the millions of potential subtle errors of logic that are the real bane of computer programming.

Delphi doesn't have a decimal type. Someone wrote a good library with a decimal type. He also needed to (re)create a bunch of mathematical functions tor it because the standard library is expecting numbers of type "real". Even though this new decimal type would work with those functions, static typing won't let you pass them in. A human can see it's valid code but the compiler can't, and with "bondage and discipline languages" the compiler is in charge, not the human. There's no "do it anyway" button. You have to write code to please the compiler... and in the worst case, all your time is spent making the compiler happy. With dynamic typing you get "duck typing" as in "if it walks like a duck and quack like a duck it's a duck". The language doesn't get hung up on identity; it merely asks what can you do for me. If a decimal type in Python has addition and subtraction methods or whatever the function needs, it's good. It uses it. No need to jump through hoops to make it happy.

Now some languages go through complex hoops of making their numbers work like an object with a class hierarchy and "boxing" to deal with this issue, but it's simply a layer of complexity dynamic languages don't need. Same with a collection - array, dictionary, etc. - containing different types of objects. There's no need for generics - you get them "for free".

So much of the nonsense and workarounds - which we don't see as workarounds when it's all we know - disappear with dynamically typed languages; I've found it amazing and a joy to use. I find Python MORE powerful than the (expensive) statically typed language I'd used for so long yet at the same time simpler and more readable.

About two years ago I noticed something. I was depending less and less on the type system for safety. My unit tests were preventing me from making type errors. The more I depended upon the unit tests, the less I depended upon the type safety of Java or C++ (my languages of choice).

I thought an experiment was in order. So I tried writing some applications in Python, and then Ruby (well known dynamically typed languages). I was not entirely surprised when I found that type issues simply never arose. My unit tests kept my code on the straight and narrow. I simply didn't need the static type checking that I had depended upon for so many years.

I also realized that the flexibility of dynamically typed languages makes writing code significantly easier. Modules are easier to write, and easier to change. There are no build time issues at all. Life in a dynamically typed world is fundamentally simpler.

Now I am back programming in Java because the projects I'm working on call for it. But I can't deny that I feel the tug of the dynamically typed languages. I wish I was programming in Ruby or Python, or even Smalltalk.

Does anybody else feel like this? As more and more people adopt test driven development (something I consider to be inevitable) will they feel the same way I do?

-Robert C. Martin, author of "Agile Software Development: Principles, Patterns, and Practices"

[Naib]

I found the original mention of Nuitka misleading. While it does convert to C++ there's been little focus on speed yet, only compatibility. As such, it's not close to the performance of Cython or Numba. The option to get a single executable with no dependence on Python library files isn't working at the moment either. As such, there's little real benefit to it at the moment, although there can certainly be significant benefit in the future. It's a bold and impressive project.

Still worth keeping an eye on.
I heavily use cx_freeze and Cython to package my applications up AND generate binary libs for the modules that need speed.

Cython is ok... But it is only giving me 20% increase but a price to pay for keeping py syntax. I have been playing around with pxd files to pre-decorate my key py to provide better C code and that is looking promising

[erendorn]

Python is also by now often used in labs or sometimes even analysis.

I fell for example in love with python then I was tasked to write a program which would read data from a oscilloscope using gpib and print the mean values after 2h to a printer.

My college was writing for over 3 weeks in C and his program still was not working. I used python, installed one external libary and wrote a program of 10 lines of code and had it working. Just awesome. Sure, my program was slower then his would have been but most of the time was spend waiting on IO anyways so it did not matter.

Still, in some situations I like so see some speed improvements and be it only so I can use python even in high performance situations and not have to spend writing C for 3 weeks.

That's not a comparison of the language per se, but of the libraries available for said language. Of course as your colleague was writing the library himself, it took him much more time, but because the scopes are different.

But it's undeniable that Python has a huge amount of libs available, which is a very strong point. Also, C is a bit too raw.

[kigurai]

That's not a comparison of the language per se, but of the libraries available for said language. Of course as your colleague was writing the library himself, it took him much more time, but because the scopes are different.

While I somewhat agree with you, separating the issue of language and libraries is a bit unfair I think.
The reason why I use Python for most of my stuff (which, btw include lots of really heavy computations) is that it's easy and fast to write the program I need.
And that is because most of the building blocks I need are part of the standard library. I can simply create lists, sets, maps without beginning by writing a lot of boilerplate code. I can parse CSV, xml, json, pickle data, and do multiprocessing all without having to search for third party libraries.

[TheBlackCat]

I mean really how many Python speed up initiatives are there out there? Maybe it isn't meant to be fast.

This is the standard way python advances. A need for something is seen. A bunch of tools appear. They have different focuses, different ideas, differ approaches. They all advance in parallel for a while, finding out what works and doesn't, optimizing, improving the API. Then either one proves superior or someone writes a "one solution to rule them all" that covers the best ideas from all the projects in a much nicer API. Either way, all the other projects are either abandoned, merge into that one, or change to just provide specialized, higher-level wrappers over that one.

This has happened many times with python. Just off the top of my head, this has happened for: n-dimensional arrays, http handling, opengl, widget toolkits, and asynchronous IO. At least from what I can see currently it is in the process of happening for JIT, a next-generation n-dimensional array, and a next-generation plotting system. Eventually the projects in each of these areas will merge into on.

[erendorn]

1) Have you SEEN Python? It looks like pseudo-code. Here's a snippet from an article about a programming contest. The problem was to find the frequency count of the letter that appears the most times in string S and return the length of the string minus that number.

def getmin(s):
    return len(s) - max(s.count(ch) for ch in s)

That's it. The entire program. Python takes all the boilerplate and scaffolding and throws it out and makes things ridiculously consistent and hence intuitive. Know how to do X in one context, and you know how to do it in every context. C++ is widely known for having dozens and dozens of exceptions to rules and corner cases galore. Given those two facts, it should be clear how "python would be so much easier than C++". It's designed to be.

To allow for comparison, here would be a c++ version, indeed longer, and not even necessarily faster, although still acceptably readable:

#include <algorithm>
#include <QString>

int getmin(const char * str) {
	QString s(str);
	int n(0);
	for (auto ch : s) n = std::max(n, s.count(ch));
	return s.size() - n;
}