3 ms·
I've been hacking Arc for a while now and we've been using calls to 'language servers' to deal with the poor library support. Basically, we wrap calls to Perl o
by garply 17y ago
I've been hacking Arc for a while now and we've been using calls to 'language servers' to deal with the poor library support. Basically, we wrap calls to Perl or Python up and send it via http to a local server that does nothing but eval the code and respond. That's gone a long way toward fixing the library problems (although it makes me, at least, less likely to develop actual Arc libraries since I can just wrap a call to Perl much more quickly). It's a relatively unique solution to the problem, I think.
Unfortunately, the language is really fucking slow. I wish I had an interpreter written in C.
- lukev 17y agoIf you're doing method calls over HTTP+eval, then I'm very surprised Arc's speed is the choke point in your application.
- mquander 17y agoHmm, if it's on the local box and not actually going over a network, like the poster implied, I don't think it would be so bad; assuming it's just a call to do some oddball library thing here and there, and not in the computationally intensive portions.
- lukev 17y agoStill. You're likely to incur at least a few milliseconds of latency on the HTTP call, and most "eval" implementations I've worked with are prohibitively slow. I haven't benchmarked other languages, but I was using it in a Groovy app until I realized each call to eval was taking over 100ms. Even granting that Groovy is a dog, parsing from a string is non-trivial. At that point I'd ask myself whether it was worth the trouble.
- garply 17y agoWell, that would be problem if the eval'ed calls were short and frequently made, but I'm talking about code that doesn't make use of the lang servers. It is Arc that's slow. Of course, if I did have a problem with multiple http+eval calls, in many cases I could probably write what I wanted to do in the other language in batch, so the overhead would be quite small.