20.08.2017, 21:17
Python is actually at least as fast as pawn, since it also runs off bytecode on top of an interpreter. Calling pawn natives from Python doesn't actually cost more than the sheer overhead of a Python function call, which is rather cheap compared to all the optimizations you can do in Python and not in pawn (like, when people create an enum with 60 or 70 parameters and then fill a MAX_PLAYERS-sized array of this enum with zeroes? :P).
Also, it's worth noting what actually matters is code read/write speed, not execution: your time as a programmer is much more valuable than a few CPU cycles, especially as servers (physical or virtual) keep getting faster and faster. If you spend half the time debugging faulty code, then you can write twice as many features in the same timeframe, it's as simple as that.
Writing JS for SAMP could be interesting but it's not my focus - although if it works, all the better for people who would use it!
Writing C for SAMP would be a major PITA compared to Python - that's the reason the language exists in the first place, to abstract away memory management and other burdens.
About maintaining the plugin - well, I'm using it and maintaining it, already patched some of the missing natives for more recent SAMP versions, and now working on double-checking the threading code to make sure there is no race condition. If people think this tutorial would be useful, it goes without saying that I would immediately publish the modified Python plugin I'm using on GitHub, where anyone could fork the project if they please.
About bugs, I found none so far, and a major part of my production codebase is now using Python (and I'm actually migrating more and more of it every day). If any would arise, I am confident that I could find it and fix it, as I am already familiar with the plugin's C codebase.
Frankly, Fabsch did a fantastic work on this plugin, the code is extremely clear and well documented, the fact that his plugin still works in 2017 is already a clear proof that the quality of his code doesn't need to be questioned. One of the main reasons why I'm doing this poll is that I wouldn't want to see such great work go to waste, as it seems his original plugin went mostly unnoticed.
In any case, thanks for your honest opinion and constructive criticism - I hope I at least partly debunked the idea that it would be slower.
Also, it's worth noting what actually matters is code read/write speed, not execution: your time as a programmer is much more valuable than a few CPU cycles, especially as servers (physical or virtual) keep getting faster and faster. If you spend half the time debugging faulty code, then you can write twice as many features in the same timeframe, it's as simple as that.
Writing JS for SAMP could be interesting but it's not my focus - although if it works, all the better for people who would use it!
Writing C for SAMP would be a major PITA compared to Python - that's the reason the language exists in the first place, to abstract away memory management and other burdens.
About maintaining the plugin - well, I'm using it and maintaining it, already patched some of the missing natives for more recent SAMP versions, and now working on double-checking the threading code to make sure there is no race condition. If people think this tutorial would be useful, it goes without saying that I would immediately publish the modified Python plugin I'm using on GitHub, where anyone could fork the project if they please.
About bugs, I found none so far, and a major part of my production codebase is now using Python (and I'm actually migrating more and more of it every day). If any would arise, I am confident that I could find it and fix it, as I am already familiar with the plugin's C codebase.
Frankly, Fabsch did a fantastic work on this plugin, the code is extremely clear and well documented, the fact that his plugin still works in 2017 is already a clear proof that the quality of his code doesn't need to be questioned. One of the main reasons why I'm doing this poll is that I wouldn't want to see such great work go to waste, as it seems his original plugin went mostly unnoticed.
In any case, thanks for your honest opinion and constructive criticism - I hope I at least partly debunked the idea that it would be slower.