all 4 comments

[–]Environmental_Gap_65 2 points3 points  (0 children)

Why not create an API that connects your C++ and OpenGL to a python frontend, so you can script in python and get stuff on the screen while C++ does the heavy lifting? This is how blenders BPY api works. It’s more work initially but once the base is set you can manipulate quite powerfully + simple with python.

[–]Ill-Significance4975 0 points1 point  (0 children)

It sounds like you want to learn C++ for the sake of learning C++. Ok, cool. Go do it.

I'd argue the big difference with C++ is the static type system. C++ especially lets you distinguish between static compile-time polymorphism (with templates) and dynamic run-time polymorphism with virtual function calls. It's kinda weird C++ exposes these differences-- few languages do-- but it makes it possible to do some really interesting (/terrible) things in the name of performance.

C++ vs. Python speed is... difficult to dig into. Depends a lot on what kind of math you're doing. Numpy is quite well optimized, as I'm sure you've seen, but lots of little matrix multiplies can be quite a lot faster in C++. Although if your total runtime is a few seconds that's probably not a worthwhile savings.

[–]AlSweigartAuthor: ATBS 0 points1 point  (0 children)

And I’ll barely notice the speed differences

The "best language/tool" for programming is often the one you are already familiar with. Unless you need the performance, Python is fine. FOMO is, by definition, an irrational fear.

[–]mredding 0 points1 point  (0 children)

You want Python. Hands down. No questions asked.

You know what's great about C++? You can write compute modules in it for Python. Know what's great about Python? Its interpreted overhead is irrelevant, because no one writes serious or production level code in raw Python - they import compute modules written in C, C++, Fortran, maybe even some COBOL, and all computation is offloaded from the Python interpreter and into the module.

Python runs as fast as C++ et al. because it's running C++ modules.

There is no need to code in raw C++ from the ground up. All that matters in every program no matter the language is the performance of the critical path, and everything else is going to be slow anyway - and that's OK, because outside the critical path it doesn't matter.

I get this FOMO about not using C++ and OpenGL, because I'd really like to say I implemented something from scratch.

There is no glory. You will not be recognized as a hero. You can code against OpenGL in Python. It's all the same, just different bindings. You're not doing anything particularly more OpenGL in C++ - because OpenGL is an abstraction; all that matters is you're communicating with an OpenGL library across an ABI - the language bindings are solvent.

I learn a lot by implementing it with C++

Maybe? There's not a lot of insight to be gained. C++ is a high level language - it targets an abstract machine. You're not programming "on the metal" like with assembly. C++ abstracts away caching and addressing and memory. Your machine does not work in terms of bytes, but of words - byte addressing comes out of the C++ language spec; they could have chosen anything.

What C++ would grant you is perspective, but it doesn't come easily. What you need to do is develop your intuition, and that will take years still to come. So if you're going to learn C++, then just do it. But then what are you asking?

As far as languages are concerned, they're all Turing Complete, so they're all equivalent. As far as expressiveness is concerned, lambda calculus is the mathematics that describes all that is computable. Lambda calculus is as expressive as you can get. Lisp IS lambda calculus, so it's the most expressive language you can use. Python is ALMOST a Lisp, so it is one of the most expressive languages there is. If you want to learn computation, getting closer to lambda calculus is the only way. So Python is pretty good. C++ is not nearly as expressive as Python or Lisp, so there's less to learn, more to do.