Compiler as dll

Daniel Keep daniel.keep.lists at gmail.com
Thu Jan 29 00:49:44 PST 2009



Nick Sabalausky wrote:
> "Daniel Keep" <daniel.keep.lists at gmail.com> wrote in message 
> news:glqsa7$13e2$1 at digitalmars.com...
>>
>> Nick Sabalausky wrote:
>>> [snip]
>>>
>>> I disagree. Making all add-ons be interpreted scripts is one of the 
>>> biggest
>>> reasons why Firefox (especially v2) is so absurdly slow (not that I'm a 
>>> fan
>>> of IE, Opera or Safari). Also, the fact that the vast majority of 
>>> scripting
>>> languages lack descent compile-time checking (such as static type 
>>> checking
>>> or mandatory explicit declarations), or at least push it off as a 
>>> secondary
>>> concern (modern ECMAScript), creates a situation where plugins have a
>>> tendancy to be unreliable.
>> There's an interesting talk Steve Yeggie gave a while back:
>> http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html
>>
>> There's also a video of it: http://au.youtube.com/watch?v=tz-Bb-D6teE
>>
>> -- Daniel
> 
> Hmm, yea, interesting, although his performance arguments are all about 
> "potential" that, as he points out, isn't going to be realized any time soon 
> for most scripting languages, and his compile-time-checking arguments 
> seem...broken. 

(Warning: personal rambling ahead.)

Well, the performance is an interesting one.  There's a guy who wrote
LuaJIT (a version of Lua that uses JIT compilation.)  He's currently
working on LuaJIT 2.0 that uses trace trees (like Yeggie mentioned.)

Last time I checked, he'd had to change his benchmarking scheme to
eschew scripting languages and benchmark directly against C.

I think scripting languages have a lot of headroom left, that's just
waiting for better interpreters and saner language design (I doubt
you'll see JS or Python ever reach Lua's speeds, at least not any time
soon.)

As for Firefox, it's worth pointing out that the current release of
LuaJIT is between 0 and ~12 times faster than TraceMonkey.  Just because
JavaScript is a crippled old dog doesn't mean you should write off all
dynamic languages. :D

Personally, I think the best approach is to combine the two; write the
hot spots in C, D or some other fast language, and all the glue in a
dynamic language.  For all it's expressiveness, there are just some
things that are easier to do with a dynamic language like Python or Lua
than with D.

And as for the compile-time checking thing... I think it's a bit of a
wash.  There are times that static checking is helpful... and times when
it's too restrictive.  All I know is that it's so much easier to debug
something when you can get an interactive interpreter inside the debugger...

  -- Daniel



More information about the Digitalmars-d mailing list