Python has pretty good string support too. Just saying :P
Now you can see why I was getting my butt kicked so badly when I started programming in C++ char*/std::string after coming from a C# string background. I stopped just working intuitively like I was used to. :)
So many of the issues Hooman and I deal with in OP2Utility regularly are completely nonexistent problems in C#. I wander if Java is the same way, but I've never programmed in it.
Maybe we will have to do some sort of C# collaboration at some point in the future.
How is the language garbage? I did some looking around on places like StackOverflow asking why people thought it was a garbage language, and the points those topics raised were:As someone who likes Python, I'd mostly share those same complaints. Although, #1 wouldn't be so bad if it didn't allow you to mix tabs and spaces, or use inconsistent indentation sizes between blocks. And #3 can be worked around using Pypy or Cython instead of CPython, using libs like numpy and numba, etc.
1. Using indents to create code blocks instead of { }. I personally love it this way, as I no longer accidentally forget a { or a } and then have to hunt for the dastardly thing.
2. Dynamic type casting, over statically type casting. ie In python, value = 0 is an integer variable but in C++, you'd declare something like int value = 0; I personally find this is very useful, and if the end user can't tell what value is by looking at it, they should give it a descriptive name and/or use good commenting to indicate it's purpose in a function. However, you can enforce type casting in python, such as converting a number into a string.
3. Poor performance. It is true that as an interpreted language, it will be slower to process than a compiled language. However, python does support compiling of files into bytecode, beforehand, which I believe would give it the same or slightly worse processing time as it would be in a compiled format already.
What are the issues you find with the language, leeor?
Ugh, LUA. First time I was introduced to that was Supreme Commander... and it doesn't interpret all that fast for a complex game like SupCom 1 is.Lua seemed plenty fast in SupCom 1 actually. If the game seemed really slow back in the day, well, there's an infuriating explanation for that. The simulation speed throttling code that was meant to make sure your CPU was keeping up was totally broken, and would invariably reduce the game speed to -10 (as in 0.1x of realtime) after 20-40 minutes. It wasn't fixed until years after the last official update when someone discovered it and made a quick and dirty hack to disable the throttling code altogether, which still isn't exactly ideal mind you, but infinitely better than 40 in game minute games taking 4-5 hours.
However, I find that the use of { and } just consumes way too much excess space and makes the codebase look bigger than it is, making it harder to find stuff quickly.I only get bothered by this when the coding standard says { open brackets must always be on their own lines. I only like doing that after multi-line if statements or function declarations or whatever to avoid run-on indentation, but 90% of the time it just wastes lots of vertical line space.
As for constants, adapt. If you are working with a group of people, just prefix any variables that should be a constant, in a way that everyone on the team will immediately recognize. ie CONST_value = 0. Anyone reading that would know that the variable name CONST_value should be treated like a constant. Problem Solved.That's not a solution, that's a coding convention workaround, and doesn't address the other problems of Python's variable mechanics that I mentioned - and all of these issues are directly caused by how "weak" variables are. Coding conventions around different "kinds" of variables, like class member variables vs. locals, is a good idea in any language, but that only helps you as the user of the language, not the language itself.
I think code collapse is a symptom of bad code. You only need it if you're writing really long functions, which you generally should try to avoid. If a function is long, it's probably trying to do more than one thing, in which case it should be refactored and split. Whenever possible, I think a function should fit within one screen of text.
2. Dynamic type casting, over statically type casting. ie In python, value = 0 is an integer variable but in C++, you'd declare something like int value = 0; I personally find this is very useful, and if the end user can't tell what value is by looking at it, they should give it a descriptive name and/or use good commenting to indicate it's purpose in a function. However, you can enforce type casting in python, such as converting a number into a string.
first_thing = 10
second_thing = 20
some_object.property = 30
print(f'First: {first_thing}, Second: {second_thing}, Third: {some_object.property }')
# outputs: First: 10, Second: 20, Third: 30
do not even get my started on build pipelines in Javascript, they are the absolute worst thing ever
'%s %d' % some_string, some_number
'{} {}'.format(some_string, some_number)
'{1} {2}'.format(some_string, some_number)
'{a}, {b}'(a=some_string, b=some_number)
printf(userInputtedString); // Warning! Security risk, don't do this!
printf("%s", userInputtedString);
database_password = 'someSuper_secretStr1ng'
username = get_username()
print(f'Welcome {database_password}! ;)')
For Python, how would you go about creating a dynamic f-string? I assume for language translations, you'd want the f-strings to be dynamic. I'm also curious if there are access rules, or ways to restrict what f-strings may read.F-strings are awesome, but because they're always evaluated on the spot, they're not very usable as templates. There's a PEP for i-strings which are basically just f-strings that are lazy-evaluated that I hope makes it in.Code: python [Select]
database_password = 'someSuper_secretStr1ng'
username = get_username()
print(f'Welcome {database_password}! ;)')
Web programming seems like a perfect example of an area where you wouldn't want to trust inputs. Though with templates, usually the format strings are not something the end user has control over, so you should be ok in most cases. It can still be easy to go wrong though, such as the following C code:Code: c [Select]
printf(userInputtedString); // Warning! Security risk, don't do this!
For Python, how would you go about creating a dynamic f-string? I assume for language translations, you'd want the f-strings to be dynamic. I'm also curious if there are access rules, or ways to restrict what f-strings may read.Code: python [Select]
database_password = 'someSuper_secretStr1ng'
username = get_username()
print(f'Welcome {database_password}! ;)')