Re: the slowness of bgt
@18
I don't know that I agree that productivity is highly subjective, no. There are a number of objective measures that you could use for it and there are people who spend a lot of time researching it, but it's not my area of expertise so i can't quote studies or anything offhand at the moment.
Fair enough. I can probably find those on my own though.
However, please provide a non-theoretical example of where the control you keep mentioning matters for an audiogame? Have you done a practical, completed project that could only be done in C/C++? Has someone actually hit some sort of issue where only C/C++ and the headaches of manual memory management can solve it?
Crypto, for one. OS development, for another. Plus, I wasn't just talking about audiogames either; I was talking about programming in general. I guarantee you that most of the people who write audio games in Python will be using Python for various other projects. That's fine, but I don't think anyone should restrict themselves to a single language like Python. C/C++ is generally a good language to know anyway.
If I was going to put forward an objective measure of productivity, I would propose that more productive methods of software engineering are those which allow the programmer to think about less things. C/C++ adds a hell of a lot to think about. If you don't need what C/C++ offers, then you're probably losing quite a bit of time by having chosen to try to use it. Even some high-frequency stock traders, the kind who rent computers near the stock exchanges because of the speed of light, use other tools.
This is a very fair point. I personally don't agree with many of the decisions regarding either language, such as layering on compatibility layer after compatibility layer, standard after standard, and not removing dated stuff, for both compilers and the language itself. Do I think that C++ is an absolute mess? Yep, certainly do. However, I respect the language for what it has brought into the world, and will continue to use it because while it may be a mess, its also a very practical language. Most of the really confusing/obscure features of the language -- for example, most vexing parse, alternate operator tokens, keyword redefinition, placement new, bitfields, etc. -- are used only in very unique circumstances, so a learner of the language doesn't need to learn those. Memory management is something I think everyone should learn, because if you don't then your stuck in a world where you think that everything regarding memory is handled automatically for you. The problem with that assumption is in areas like security, you must manage memory yourself; the GC (or whatever mechanism your using to clean up memory that's automatic in nature) shouldn't be trusted because you have no idea when it'll run. That's one reason I've always been wary of cryptography in Python. Rust alleviates the headaches of memory management a bit, though you can still drop down and allocate memory yourself if you so desire. Plus, manual memory management is a good way of saving memory usage (yes, I know that we have computers with GB or even TB of memory, but that doesn't mean you should just allocate willy-nilly).
I've watched you follow my trajectory for a long time and, like me in the C/C++ is amazing phase that I went through in 2014 or so, I doubt anything I can say will convince you right now. But I'd honestly put money on you making a high-paying career around it over the next few years, then being yet another voice on the internet trying to explain to people how they really shouldn't be trying to use it unless they really need it for their project.
Nope, I went through that a year or so, if not earlier, ago. I'm now in the "Rust is awesome phase" but am realistic enough to know that I can't do everything I'd like in Rust, and when that happens I turn to languages like Go, D, or C/C++. Sometimes I'll go with Python, and Python works amazingly well, but I'm not going to make every project in Python. For me, some projects I make are learning opportunities I'd like to dive into, and for that I might use C/C++ or Rust to see how things work and what happens. I get what your saying, and I'm definitely not going to use C/C++ for everything; I do prefer the safety Rust offers.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
