Thread: Ask me about Python

Originally Posted by ninja9578

No I wasn't; I was demonstrating how C++ programmers use the predictable behavior of when destructors get called. If there is garbage collection, you have no idea when destructors get called, so you can't use them the way you can in C++.

What I don't get is why C++ programmers always insist that if you can't accomplish something the way that you do in C++ then it's not as good. I've literally had someone try to tell me that C++ is more powerful than python because python doesn't have a 'do' loop. One would often use the 'with' statement to have a context manager have code run when exiting a scope as I demonstrated in my example (though it's much more flexible than that)

Originally Posted by ninja9578

BTW, java will never be faster than native code, that's only possible on the SPARC processor.

Keep telling yourself that. Optimizing code at compile time as pretty much been optimized to it's fullest extent. Optimizing code at runtime using Just In Time compilers has only just started and is theoretically much more promising. And note that I specified long running processes so that the JIT compiler can accumulate enough information to, e.g. do branch prediction superior to what's currently available in hardware.

Originally Posted by ninja9578

Scripting languages should stay on the web because they're portable, real apps will always be written in native compiled code, without garbage collection. The only "real" language that I know that has a garbage collector is C# and Objective C 2.0, and professionals turn it off in both languages.

You really seem to be hung up on destructors here if you are willing to dismiss an entire class of very expressive and powerful languages for no reason other than that they make destructors useless. I recognize that clever things can be done with them but clever(er) things can also be done with context managers, closures, descriptors, decorators and metaclasses, none of which are offered in C++.

I'll repeat myself.

favor C/C++ when you need the speed (and after you know that another language isn't fast enough)
favor C/C++ when pauses that are (increasingly only theoretically) associated with (modern) garbage collectors is a game killer.
favor C when you are writing for an embedded system

in all other cases

use a modern language, e.g. python, lua, ruby and most of all, Lisp.

I guess what I'm saying is that (while I may be 5-10 years ahead of schedule) C and C++ are the new assembler languages.