First off, languages like python, java perl and ruby are interpreted languages, not compiled ones. This means, that by their very nature, they will be slower than compiled languages like pascal, C or C++.
There's not much that can be done about that, it's just the nature of the way the language is designed. Sure, there's some java tricks that can speed up the execution to near native speeds, but that's something that has had a lot of work put into it, and java is a much older language than python, so you can't expect the same performance from unoptimized interpreters. That said, there are ways to quote compile unquote python code, but truly, this doesn't really convert the python code into machine language (which is what the computer needs to execute something natively), it's normally just a method of embedding an interpreter into the executable, so a stand-alone python interpreter isn't necessary. Of course, this isn't getting into things like just in time compilation,, object code, and machine specific optimization some compilers introduce, things can get complicated in a hurry. But in general, suffice it to say interpreted is always going to be slower than compiled.
With that said,Python is only the latest in a long line of languages that were built for readability, ease of use, and simplicity. This doesn't make it better than other languages, it only makes it the current crowd favorite. Give it 5 or ten or twenty years, and there will be something new. In the 90s, it was java, in the 80s, it was basic, and no doubt it will be something different in a decade or two. I personally hate python, but the reasons are primarily due to personal preference as opposed to any real technical reason, (though they do exist too), but for the most part, I can use it well enough, and get along well enough to accomplish the task I set out to do. I'd honestly rather use a language like Power basic, Pascal, or C (depending on what I'm trying to accomplish). I'm fairly well versed in some two dozen programming languages, and each one has it's strengths and weaknesses, and for the most part, if I'm programming on windows, I use powerbasic. If I'm programming on unix type oses, I'll use C, and if I'm working on something that absolutely has to be cross platform, I'll generally use pascal, because the free pascal compiler has versions for each and every platform I'd need to support. C can be used for this too, but sometimes, differences in system implementations causes modifications to be necessary on some platforms, so I use pascal, and prevent that problem. Each programmer has their preferred languages, and each one will give you different reasons why they like those choices. There's nothing wrong with that, if the language in question can handle the task, then it doesn't matter if it's something you made up on a friday night after too many beers (I could name a few), or if it's a language that has decades of support behind it, if it does the job, then it shouldn't matter what is used. Of course, some languages are better for some things than others, but it doesn't matter how good the language is for something if you aren't comfortable with it, and actively dislike the language, you won't accomplish your task properly with issues like that holding you back.
Should python be used for every project? Absolutely not, though you'll meet folks that claim it should.Nor should C or C++ be used for everything, there's a reason why there are so many programming languages, and no language is any more important than any other, they can all do the same things given enough time and resources, and that's where the choices come in. It's considerably faster to throw a few python functions together, and drop it into your current project, than it is to rewrite a lot of that functionality from scratch in a language that doesn't have pre-existing functions to do the tasks, and that more than anything else is why it's gotten so popular. This email got a whole lot longer than I intended, and I apologize for that, but even gaming discussion groups can benefit from programming discussions, considering folks always want to know how easy it is to write a game, so I don't truly feel like this is off topic.
Of course, I've been flamed/kicked off groups for less, so <shrug> On 2/15/2021 11:42 AM, Damien Garwood wrote:
Hi Chris,If I implied that Python was evil based on irrefutable evidence, then that was definitely not my intention. Indeed, it is apparently the third most popular programming language behind C and Java (according to Wikipedia), and most of its output is perfectly usable. I myself use NVDA as my primary screen reader, which is 85% Python driven (according to GitHub). I use two Python-powered apps for my virtual change ringing practice sessions. And I play a few small Python-powered games. So I couldn't agree more that Python does, indeed, have its place. What I'm saying though, is that I don't think the place for it is for writing big blockbuster audio games. If we want more games like BK, A Hero's Call, or Manamon, I just don't think Python could cope. Of course I have no evidence to support that apart from my past experiences with three relatively small games, two of which were purely online-based and one which has since been optimised. I merely intended to provide my own opinions and experiences as a beginner myself so that any other learners could take those into account in their decision making processes. If this has already been explored elsewhere then I am unaware of it. If a new learner turns out to be one of the many who can overcome the barriers that have stopped me in my tracks and proved me to be some kind of ice-age wild monkey with a straw-filled head, then that's great. But I Also feel it's important that learners who are struggling with it are aware that there are alternatives, and ones which could prove easier and better for them, especially if they want to do the seemingly impossible and make a purely audio-driven equivalent of GTA. Finally, I'm genuinely curious as to what Python offers that is worth sacrificing speed and simplicity for. Whatever it is must be absolutely amazing, and once I find that spot then chances are I'll likely get the bug as well (no pun intended there).Anyway, to challenge your answers (constructively, I hope): 1. SpeedThat depends. If you're measuring a single operation, chances are you're probably right, the improvement may well be less than a millisecond. Try traversing data over a million or even billion cycle loop though, and that extra time adds up. Try doing intensive activities over a network, it could be even worse. A test that took 30 seconds in BGT and just under a minute in Python took less than 100 milliseconds in C. Granted, maybe I don't know the Python language well enough to know how to optimise my code, but bear in mind I'm speaking from a beginner's point of view - I was doing a test based on code from a tutorial.2. ReadabilityThat's more a case of personal preference. I find some areas of Python easier to read than others, but that would be the same for any language. I love Python's import/autonamespacing system, and given that a lot of build scripts seem to be written in Python, that would be a lot better to me than the cavernous leap between C/C++ code and makefiles or CMake. But I do prefer the way C/C++ does variable and function definitions (unless of course you count explicit casting). On the other hand, I much prefer BASIC's logic in calling its custom datatypes "types" compared to what C calls "structs". Programming in any language is all about compromise and it's all down to personal judgment as to what compromises you believe are worth your time and energy.Take the following Python definition: def get_media_info(entry, media)What on earth does def mean? Oh, it means function. Right. Does this function return a string? Or is there a media_info object somewhere? What are entry and media? Are they strings, or integers corresponding to list indexes, or separate entry/media objects...Is media perhaps the raw data of an audio file? We have no way of knowing without trawling the function to try and gain some context.string get_media_info(int entry, int media)To me, that's much clearer what things are. It returns a string, and requires two int parameters (probably indexes that allow access to a vector or array). Can't get much simpler or more specific than that. Of course, there are ways around it like anything - comments being one of them. But a "programming best practices" style tutorial told me that you should never have to comment what something is, you should only ever need to comment why you are using a certain method to achieve a goal. I could be either misinterpreting or being literalist about it, but bear in mind, 80 to 85% of my programming knowledge is self-taught based on personal blogs and the odd tutorial on the internet and so I've had no exposure to external or practical context or even discussions about this sort of thing.3. Maintainability Define "maintainable".If we're talking about compilers, C and C++ compilers are constantly being maintained, as is Python. You might even argue that C/C++ compilers are even more maintained - Python is most commonly associated with CPython. C/C++ can be compiled by Visual Studio, GCC (including MinGW and friends), Clang and so on. If you mean the language, then Python has its PEP system, and C++ is enhanced every three years. Granted C seems to be a bit more sporadic. If you mean distribution, then again, I'm afraid I can't agree. As I say, dependencies are a lot harder to manage, and some of the extra tools you need to get a common Python environment up and running just seem arcane to me. in C and C++, I can install a compiler and just start coding. While that is possible in Python, it's not ideal, and certainly not recommended (based on information from other more experienced Python coders). Having said that, running a Python script from the command line is much easier.python test.py is a lot easier than gcc --static -s -DNDEBUG -O3 -o test.exe test.cAnd that's not assuming any extra libraries/include paths. Again though, we must ask ourselves why that is. It's because Python can't build native executables, so literally all it has to do is run what we tell it to, and the rest is up to it to figure out. If you're talking about coding, then I'm afraid I can't speak for that. I know pip is supposed to be very good at resolving dependencies and making sure everything just runs, and if you're just running a .py file on your own system then more often than not that is likely true. Having said that, I've had experiences before that have not only failed to resolve the appropriate dependencies, but also seem to have broken pip (hence the apparent need for virtual environments), then we start getting back into territories I don't understand.4. Less chance of bugsAgreed. And for simple tasks that comes in very handy. All my little file modifying number/data generating utilities I once wrote in BGT, I could imagine rewriting them in Python under different circumstances. I certainly wouldn't presume to rewrite them all in C! For games though, what's best? Speed with the possibility of memory bugs that can be fixed, or slower speed with the possibility of other bugs in your code plus additional interpreter bugs that you have no control over, unless of course you're prepared to go trawling through the CPython source code, which itself is written in C? The last thing I'd want to write in my documentation is: "Known bugs due to development environment limitations". The amount of times I've seen that in audio games is unprecedented, and not just for BGT-powered games either.5. Speed via external libraries...True, but then you have to use DLLs, which brings us back to the distribution problem, and you'll also likely have to use wrapper layers, likely written in Python, which will slow it right back down again.6. IndentationIn practice, that's the least of my worries, as I have a little utility I use that converts braces into indentation and vice versa. It's what kept me sane in the days when I tried and epically failed to maintain some NVDA addons. Theoretically though, indentation has always caused a problem for me, and I should imagine it would for any other speech user who has never had to actively deal with it before. I have three friends who I know would definitely struggle with it. Having to see it in code that doesn't require it is one thing (at least you can strip it out if it really bothers you), but trying to juggle with it in a language that does is far too time consuming. Again, I can see how it is very useful for Braille and screen users. But those using speech (where the speech either starts reading from the first real character, or starts with a brief summary of indentation which your head then has to somehow separate from the text read immediately afterwards) then leaves us to have to go through a whole series of "space-counting" on every line just to make sure that the level matches what is expected. In C or C++, I can go "brace-counting", which takes much less time because I'm not having to analyse each and every line. It might be a different story if we can somehow separate the formatting from the code, either by perhaps using a different voice, changing pitch or stereo position, put some kind of audio effects processing on it, or even simply inserting some kind of gap between the formatting and actual text. But of course that's up to the NVDA team. Not only that, but I seem to find that four spaces seems to be the going rate for indentation these days. Do you really want to sit there, counting out sixteen spaces if you have instructions inside an if statement inside a loop inside a function inside a class? And not just for the one line, but for every single line inside that block? Oh, and woe to you if you miss out just one precious space... Joking aside. Either I'm overthinking this, going about it the wrong way, or other coders just tend to have a lot more patience and/or brain power than I do.As I say. Python could, theoretically, be the best language in the world. I don't know enough about it. But I have gone through the official Python tutorial and a kind of weird e-course thing, and still find it complicated, unmanageable, and unsuitable. If someone is willing to spend time with me showing me how it all works, then perhaps I could be drawn to it. At the moment though, Python is as scary as the snake it is indirectly named for.Cheers, Damien. On 15/02/2021 10:39 am, Chris Norman via groups.io wrote:I would say this is massively subjective, although there are some valid points in there I guess.It also completely glosses over a few major facts. Namely: 1. Speed is less and less of a problem these days. 2. It's much easier to read than either C or C++. 3. It's much more maintainable than either C or C++.4. While you lose a lot of speed, you also lose the chance that memory bugs will creep in.Also, if you need parts of your game sped up, you can always use external libraries written in C, C++, or Rust.Finally, indentation is not a problem for anyone in 2021, and it's ridiculous how often this is presented as a reason for not using Python. Even in languages where indentation is not mandatory, it's highly recommended because of the increased readability, for everyone, not just people who can see.Anyways, I don't want to start a programmers' pissing contest, just wanted to point out that if a new developer read your email, they would reasonably assume that Python was pure evil, and should be avoided like a fart in a confined space.Take care, Chris NormanOn Sun, 14 Feb 2021 at 13:24, Damien Garwood <dam...@daygar.plus.com <mailto:dam...@daygar.plus.com>> wrote:Hi, Personally, I don't see what all the fuss is about Python. For what my opinion's worth, I would suggest C or C++, all the way, 100%.The one advantage I can see with Python, apart from the fact that it isregularly maintained (always a plus), is its inherent ability to package scripts together and interact with them separately but cooperatively. In all fairness, I absolutely love that feature. Other than that: 1. Python is far slower than C and C++ (to be expected with an interpreted language using so many higher-level wrapper layers). Youmight not think that's a problem for games, but it depends on how big your games are, and how much you care about speed. As a developer, I'dmuch rather plan for the worst case, that is to say a massive open-world game which might have thousands of objects, and try and optimise it in a way that allows it to take three seconds to open in a solid languagethan having to stick with the limitations of it taking over 30 seconds in an interpreted environment, simply because you have no control overhow memory is allocated or accessed. 2. Python is far too bloated. Again, so many moving parts, having to ship the interpreter with the code, any DLLs (or indeed PYDs) that mightbe being wrapped etc. None of this can be linked statically. There are complicated workarounds that would trigger the alarm of certain virus scanners, but they're not ideal by any means. With C or C++, as long asyou have the source code to what you're linking, you could linkeverything statically and safely into one executable. As an example, if SoundRTS was rewritten in C++, chances are the distribution directory could easily contain 600 files less than the Python distribution does. We already saw an example on list the other day of what can happen ifyou just happen to be missing one DLL!3. Python is far too vulnerable to reverse engineering, only making it viable for open-source products. Experienced closed-source Python usersknow how to get around that, either by using obfuscation, or even bymodifying the interpreter. But again, that's using complicated methodsthat Python wasn't technically designed for, possibly making it even slower at runtime, and definitely making Python more complicated for thelearner. On the other hand, try to decompile a release binary in C andC++, and you get nothing but hex and assembly. 4. In some cases, Python seems a lot more complicated. I'm not sure whether that's because of the tutorials or the philosophy behind it, butstart talking to me about virtual environments, pip, the processes forbuilding executables, or the process for trapping exceptions in pyw,it's enough to send my head in a spin. In C++, you don't need packages and environments, and its ways of exceptions and executables are a lotmore elegant.5. On a more personal pet hate of mine, Python is far too visual withits indentation requirements. I guess that's OK for people using brailleor partials that can see a screen, but mere mortals using speech don'tneed it, and for my part I could spend the rest of my life without it. Ifind it much easier to read code with deliberate boundary symbols. Ofcourse that is simply a matter of preference and setup. The way I see it, Python wasn't designed for programming at all. In fact, I wouldn't be surprised if Python is slightly like AutoIt. That is to say, it started out as an automated or possibly shell scripting environment, and has since evolved to try to be like any otherprogramming language, and for that reason, it suffers from many defects and deficiencies. I believe even the Python documentation refers to afew situations that arise as a result of previous bugs or design oversights. Cheers, Damien. On 14/02/2021 11:20 am, Chris Norman via groups.io <http://groups.io> wrote: > Hi, > There are a few different audio game engines for Python, these include > Earwax <https://earwax.readthedocs.io/ <https://earwax.readthedocs.io/>> (beta), Lucia > <https://github.com/luciasoftware/lucia<https://github.com/luciasoftware/lucia>> (which is supposed to be more> familiar to those coming from BGT, Framework > <https://forum.audiogames.net/topic/38239/framework-my-new-set-of-tools-for-audiogame-creation-in-python3/ <https://forum.audiogames.net/topic/38239/framework-my-new-set-of-tools-for-audiogame-creation-in-python3/>> (for > want of a better name), and pyAGE > <https://forum.audiogames.net/topic/38941/pyage-yet-another-python-audio-game-engine/ <https://forum.audiogames.net/topic/38941/pyage-yet-another-python-audio-game-engine/>> (which > is still very much in its early stages). > > If you'd rather go the mainstream route, and don't mind a little more > work, there's Godot Accessibility > <https://forum.audiogames.net/topic/33909/migrated-godot-accessibility-to-github/ <https://forum.audiogames.net/topic/33909/migrated-godot-accessibility-to-github/>>. > > Finally, for some subjective comparisons, see this thread > <https://forum.audiogames.net/topic/38995/python-and-audiogame/ <https://forum.audiogames.net/topic/38995/python-and-audiogame/>> on the > audiogames.net <http://audiogames.net> <http://audiogames.net <http://audiogames.net>> forum. > > There are others, namely MonoGame <https://www.monogame.net/ <https://www.monogame.net/>>, and > probably some other stuff in C# too. > > Other than that, please just do everyone a favour (mainly yourself), and > don't use BGT. It's like deciding to dig yourself a swimming pool, using > a plastic bucket and spade for digging, wattle and dorb for lining, and > stiff prayer for water purification. > > HTH, > > Take care, > > Chris Norman > > > > On Sun, 14 Feb 2021 at 02:42, Immigrant via groups.io <http://groups.io> <http://groups.io <http://groups.io>> > <immigrant328=verizon....@groups.io <mailto:verizon....@groups.io> <mailto:verizon....@groups.io <mailto:verizon....@groups.io>>> wrote: > > Hello, everyone. I have just joined the group, and I hope the > distinguished> gamers and writers in this gaming community understand that I am> very much a> beginner, trying to write perhaps a couple of simple dice or card> games. I > wrote a dice game script in BGT, and the script doesn't generate any > compilation errors. However, the game window stays open only for a > couple of > seconds, and then disappears, so none of the program's keystrokes can be> executed. I realize that BGT is no longer supported, but it does> work under > Windows 10, and it is the only engine where I know how to implement > keystrokes and add and manipulate sounds. I checked basic tutorials > for a> few programming languages, and realized that game logic can be> programmed in > any of the languages but none of these tutorials addresses > keystroke-driven > implementation, or addition of sound. And even in the BGT tutorial, > I have > not found answers to some of my questions. The game I am currently > trying to > write is a dice roller, but if one tries to create, for example, a card > game, how do you make a card playable? If cards exist as strings, or > parts> of an array, or even instances of their own class, they are just> abstract> logical structures. But cards need to be manipulated - picked up,> discarded, > etc. If I have a hand with 5 cards, how do I program a way to > navigate the> list of cards and then perform an action on a card currently in> focus? How > to make it an element of interface so it can be selected? I hope I > clearly > expressed my questions, and I am grateful in advance for any > clarifications. > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#123345): https://groups.io/g/blind-gamers/message/123345 Mute This Topic: https://groups.io/mt/80623843/21656 Group Owner: blind-gamers+ow...@groups.io Unsubscribe: https://groups.io/g/blind-gamers/leave/607459/1071380848/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
