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 (#123338): https://groups.io/g/blind-gamers/message/123338
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]]
-=-=-=-=-=-=-=-=-=-=-=-
