OK, I'm not going to try and answer all of your questions here, partly because I already feel this topic is getting quite off topic, and secondly because some of it is frankly far outside my experience, and I('d hate to speak out of turn and give out incorrect information.
If this is something people are genuinely interested in, I'm more than happy to speak to them either personally (via email), or do some kind of Google Meet thing where I can try and explain some Python basics. Take care, Chris Norman On Mon, 15 Feb 2021 at 16:42, Damien Garwood <dam...@daygar.plus.com> 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. Speed > That 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. Readability > That'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.c > And 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 bugs > Agreed. 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. Indentation > In 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 Norman > > > > > > > > On 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 > is > > regularly 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). You > > might 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'd > > much 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 language > > than having to stick with the limitations of it taking over 30 > seconds > > in an interpreted environment, simply because you have no control > over > > how 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 > > might > > be 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 > as > > you have the source code to what you're linking, you could link > > everything 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 if > > you 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 > users > > know how to get around that, either by using obfuscation, or even by > > modifying the interpreter. But again, that's using complicated > methods > > that Python wasn't technically designed for, possibly making it even > > slower at runtime, and definitely making Python more complicated for > > the > > learner. On the other hand, try to decompile a release binary in C > and > > C++, 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, > > but > > start talking to me about virtual environments, pip, the processes > for > > building 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 > lot > > more elegant. > > 5. On a more personal pet hate of mine, Python is far too visual with > > its indentation requirements. I guess that's OK for people using > > braille > > or partials that can see a screen, but mere mortals using speech > don't > > need it, and for my part I could spend the rest of my life without > > it. I > > find it much easier to read code with deliberate boundary symbols. Of > > course 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 other > > programming language, and for that reason, it suffers from many > defects > > and deficiencies. I believe even the Python documentation refers to a > > few 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 (#123339): https://groups.io/g/blind-gamers/message/123339 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] -=-=-=-=-=-=-=-=-=-=-=-