Define me a new function with SEXPs.
Define me a new class with SEXPs
Do operations with floats with SEXPs
Show me a function that returns a value without messing up the conditional its a part of in SEXPs
Show me a way to implement functions without having to edit five separate values in different places in SEXPs
Show me the extensive modules in SEXPs that would let me do network operations
Show me the ability to expand the SEXP system via modules
Show me how I can multithread with SEXPs
There is a reason that Python is slower than the SEXP system. It provides a lot of things that the SEXP system doesn't.
In addition, I hear still here people talking like Python isn't being compiled into bytecode and then run.
Python is being compiled into bytecode at program start. This bytecode is evaluated every frame. There is no parsing occuring every time Python is used. Past the first time python.tbl is parsed, the file is never opened again.Kazan brought up a link I posted with Python:
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=python&lang2=gcc&sort=fullcpuAlthough he obviously didn't read it or else he would be pointing out the 234x difference. (Apparently Python doesn't like extreme numbers of recursive functions). Which is something which shouldn't be happening.
Oh, and the tests are grossly inaccurate because there's no 'fully-featured SEXP' option. Python and SEXPs are both coded in C; I'm comparing
raw C to Python in that example. It's not iterating through switch statements or cycling through nodes to figure out what the instructions are like SEXPs would be.
So to say that because SEXPs are coded in C and are therefore as fast as C is a gross fallacy.
AFAIK the benchmarks were run taking compile time into account. And, well, see above bolded text.
Also, python isn't intended to be a replacement for the SEXP system. I see it as being a step more than that; a way to perform lower-level operations on an individual mission or mod basis.
And just to reiterate reasons for dislike of the SEXP system, the postfix operator system is just another hurdle to overcome when learning to write with it. A GUI editor is unreasonable (IMHO) because it means that you're spending a lot of time sorting through menus even if you already know what functions you want to use. It has a number of problems and limitations, not the least of which is that it's frustrating to code functions for, no matter how simple.
Before it can be Python or Lua's equal, those have to be fixed. Then, IMHO, we can honestly argue processor time.
And finally, I'm not convinced that SEXPs are going to be so much incredibly faster than Python or Lua for any reason except their simplicity. Python is, after all, coded in C as well and was designed as a scripting language from the start, AFAIK, so it stands to reason it'd have a decent parser (compared to SEXPs which were implemented only to provide mission scripting).
Edit: Oh, and I have no confidence in this massive SEXP overhaul happening in the same amount of time...hell, Python's already in and has more abilities than the SEXP system, so go figure.
But I already asked about using SEXPs for the HUD system before, as I couldn't get a full expression system working and hadn't thought up using another scripting system, and that never happened. The overhaul that's being proposed is pretty major, and would take awhile to do & test & work all the bugs out of. There are over 100 SEXPs, each would have to be ported to the new system, for one...