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

[pal666]

While I agree with everything else you wrote and thought it was spot-on (using a low-level language as a first option is often a form of premature optimization), I can't agree with the above sentence. It's simply not true from a computer science standpoint. In theory a JIT can achieve better performance since it has more real-time metrics on the performance of the program and can optimize for the specific hardware and instruction set present (especially when compiled programs are often compiled for the 'lowest common denominator" in regards to CPU instruction features). I've seen real-world comparisons where JITed code has beat out compiled code - for instance, both Java and C# beating Delphi in SciMark 2011, and another in which a person tested their algorithm that manipulated image files and Java just edged out the other competition, including Nimrod, which cross-compiles to C++ code.

in both theory and practice, jit can't do better than aot, because you don't have enough resources to do heavy optimization during runtime. using jits produces slow memory hogs. even google understood it with android 5.0
and also you can't have fast code just by using better compiler, you need language designed for speed in the first place. which c++ was, but python wasn't

[pal666]

How in the world is C++ "Just as easy to work with as Python"? C++ has a billion special rules and corner cases to the point where you have books about "C++: The Good Parts". Python is designed from the ground up for simplicity and readability. What CPython is to C++ in terms of speed C++ is to Python in terms of ease of use.

c++'s core spec is about two times bigger than c. and same as c# and java, so please stop spreading bullshit
there was good parts book about javascript earlier and somehow millions of not really programmers are using it
python is designed from ground up for slowness

[pal666]

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.)

if you had some brain, you would think for a moment, why game engine devs use c++ and not python. and they are hugely constrained by speed of _development_.
and most of them are using all elements of your list
just admit that you are not intelligent enough to understand such simple things

[pal666]

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)

you can write like that in c++. nobody does it, because it is much(like in O(n^2) vs O(n)) slower than iterate once over string and once over counts.

2) As someone who has over 17 years (sole) experience with statically typed languages.... no, no it's not "so nice"

as someone, who has more experience, i can tell you, what is really not so nice. not so nice is when fedora installer dies on you saying something like "this object does not have that member". which would not even compile in proper language.

Delphi doesn't have a decimal type.

... bla bla bla, long explanation of how bad is delphi because it does not have templates.

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".

the only thing you get for free is void pointers. which you have in c++ anyway. btw, c++ supports advanced dynamic types on library level when you need them. the problem is python does not have static ones.

[kigurai]

you can write like that in c++. nobody does it, because it is much(like in O(n^2) vs O(n)) slower than iterate once over string and once over counts.

Of course you can write the same algorithm in C++. The point is that Python has some really nice syntax to do this kind of stuff which C++ does not.
And most of the times it doesn't matter if your algorithm is O(n^2) or O(n). The interesting fact is whether it is fast enough for the application at hand.
I am not claiming that Python is fast, but it sure works fast enough for me at most times, and when speed is required, Cython is pretty good at solving that problem without much extra work.

[pal666]

Of course you can write the same algorithm in C++. The point is that Python has some really nice syntax to do this kind of stuff which C++ does not.

my "like that" related to syntax. i hope you aren't going to insist on using variable before introducing it.

http://www.boost.org/doc/libs/1_56_0/libs/range/doc/html/range/introduction.html

[TheBlackCat]

as someone, who has more experience, i can tell you, what is really not so nice. not so nice is when fedora installer dies on you saying something like "this object does not have that member". which would not even compile in proper language.

It is also not nice when your program dies from a segfault, which you don't get with python. You can always point to certain sorts of bugs that happen on some language but not another, or is more common in one language compared to another. What matters is whether the language suits the purpose for which it is being used. Sometimes python does, sometimes it doesn't. People are trying to expand the range of situations where it is useful. I think that is a good thing.

[TheBlackCat]

you can write like that in c++. nobody does it, because it is much(like in O(n^2) vs O(n)) slower than iterate once over string and once over counts.

I am not sure what you mean by this. You have to iterate over the string to get the counts in the first place. In most cases it would be faster to find the unique values first, so you could do something like this:

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

But at the very least you still need to go through each character found in "s" and find how many times that character occurs somehow.

[dclink]

It is also not nice when your program dies from a segfault, which you don't get with python.

sure thing ...

[pal666]

It is also not nice when your program dies from a segfault, which you don't get with python. You can always point to certain sorts of bugs that happen on some language but not another, or is more common in one language compared to another. What matters is whether the language suits the purpose for which it is being used. Sometimes python does, sometimes it doesn't. People are trying to expand the range of situations where it is useful. I think that is a good thing.

first, there is no real difference from user pov between segfault and any other fatal error. and static typing automatically finds huge number of fatal errors during compilation and not during use in production.
second, static typing does not imply "raw memory access". there are plenty of statically typed segfault-less languages.
no dynamic language suits to writing robust programs.