Actually no, you'd be using another language to affect the object.
You can think of it as, you going in to SL to tell an object to do something, then running back out of SL with the result. It used to be that you use LSL to tell the object to do something, what I am building is replacing LSL for applications that are not time sensitive. This means you have no memory limitations and no language limitations.
For example, to llOwnerSay something, you would fire off that function from your C#, JS or Java code. The inworld object would receive the command over HTTP.
The advantage of this is that you're no longer limited by the script, you can now build huge programs that exist outside of the SL context, but still be able to access objects within SL via these commands. I've also tested two way communication, so you can request object state (like who it is attached to etc), or listen to well.. listen events.
The next step to expand the use case is to batch commands together, then run them together to get around the round trip time vs single commands.
EDIT: Another consideration - LSL lacks the huge amount of libraries offered in say Javascript, where there's millions of user created packages. Need a graph algorithm? Just grab it from NPM. Things aren't as easy in LSL.