Hi, Thank you so much for this extremely informative and well throughout email.
Take care, Chris Norman On Tue, 16 Feb 2021 at 19:46, Travis Siegel <[email protected]> wrote: > Just a quit explanatory email to address some of the issues raised, and > (possibly) explain why python is so popular. > > 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. 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 <[email protected] > >> <mailto:[email protected]>> 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>> > >> > <[email protected] > >> <mailto:[email protected]> <mailto:[email protected] > >> <mailto:[email protected]>>> 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 (#123346): https://groups.io/g/blind-gamers/message/123346 Mute This Topic: https://groups.io/mt/80623843/21656 Group Owner: [email protected] Unsubscribe: https://groups.io/g/blind-gamers/leave/607459/1071380848/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
