interpreted vs. compiled

[Bill Baxter]

Walter Bright wrote:
> Daniel Keep wrote:
>>
>> Walter Bright wrote:
>>> ... A lot of people use Python, and are forced
>>> to mix in C++ to speed up the slow parts. It would be much simpler for
>>> them if they could use the same language for both.
>>
>> I'll have to disagree on this.  I used Python for my third year
>> comp.sci. group project, and it made things a hell of a lot easier.
>> Most of the code was dealing with the GUI, with only a few math-heavy
>> parts written by myself.
>>
>> Using Python for the mathy parts made them so much easier to debug it
>> wasn't funny, and I've never seen anything that could touch Python for
>> writing sane GUI code.
>>
>> In the end, I had to convert some of the slower code from Python to C,
>> but that was basically a trivial exercise.  Pyrex allows you to write
>> "Python-like" code that compiles directly to C that makes writing the
>> native module wrapping C code a non-issue.
>>
>> If I'd used just C++, the GUI coding would have driven me completely
>> insane.  If I'd been restricted to an interpreted language, our app
>> would have been slow as molasses.  By using Python, we got the best of
>> both worlds :)
> 
> Everyone knows that C++ sucks for writing GUIs, I hope to do much better 
> with D.
> 
>>
>> In a wacky kind of way, one of the reasons I chose Python was *because*
>> it could be easily optimised.  True, it had to be done in a different
>> language, but there was almost no effort required to do so, so I never
>> had to fear hitting a performance ceiling.
> 
> But you did hit a performance ceiling. You had to convert the 
> bottlenecks to C. Wouldn't it be nice not to have to do that? <g>


Yes, but "dynamic everything" is a big part of what makes GUIs so easy 
to write in a language like Python.  At the end of the day D is still 
going to be a statically typed language, so I don't think it'll ever be 
able to compete with a scripting language when it comes to the 
malleability of the code.

For example in the program I'm writing in Python now I realized that it 
would be convenient to get some notification any time any member of a 
particular class got modified.  In Python it's a snap.  Just make a 
10-line subclass that overrides __setattribute__ and use that instead of 
the original class and you're done.  None of the rest of the code I had 
written had to change a whit.  With D, the conversion would not be so 
easy, and in the end I'd still have to change client code here and there 
because foo.x+=5 doesn't work with D properties.

That said, it's already a lot less painful writing GUI code in D than it 
is in C++ (GC, delegates, 'auto', and 'with' come to mind).  I just 
don't think a statically typed, compiled language will ever really be 
able to compete with a scripting language on the GUI front.

On the other hand, a dynamic scripting language will never be able to 
compete with D on the speed front.  So you need both.  The price I pay 
for the convenience of being able to override __setattribute__ 
occasionally is that *all* attribute accesses have to happen via string 
lookups *all the time*.

I tried Pyrex for the first time last week because I was worried my core 
math routines would become a bottleneck.  It's pretty impressive.  I 
really didn't think it would be so easy to use.  I don't even know if I 
have a bottleneck in the math yet, but Pyrex turned out to be so easy to 
use it was like "heck! why not?".

I think the take home message is that people are quite willing to 
write/re-write performance critical parts of their code in a slightly 
restricted dialect if they can have unbounded expressiveness in the rest 
of their code.

What does it mean for D?  Well maybe For D maybe this could mean a third 
flavor of aggregate --
- struct: low-level value aggregate
- class: static polymorphic aggregate
- dclass: dynamic polymorphic aggregate (new!)

The difference would be that dclass would do everything dynamically ('d' 
for "dynamic").  All member lookups via strings.  All property accesses 
via special methods that can be overridden.  In that way you could start 
coding with dclass, and as bottlenecks appear, you just have to 
transition the performance critical things from 'dclass' to 'class'. 
Another alternative is to allow some syntax for dynamic members in a 
class.  But that seems messier to me somehow.  For instance, from my 
experience using Qt I was constantly asking myself "should this be a 
slot? should that be a QProperty?"  Why worry?  Just make 'em all 
slots/properties.  If you need some non-dynamic things in your dclass, 
make an inner class that's not dynamic.


You mentioned games as a big area where every ounce of speed is 
important.  But game developers are also some of the biggest consumers 
of scripting languages today.  I'm not so sure game developers would say 
they'd like to use the same language for everything, even if they could. 
    For big system stuff, static typing can really eliminate a ton of 
typical errors (little typos and thinkos especially).  For low-level 
rendering code it's critical.  But for designing the content of the 
game, dynamic tweakability and flexibility is more important, and 
forcing everything to be declared all the time can be counter-productive 
(especially when we're talking about artists doing the coding).


I was kinda surprised by the comment that speed was so important, 
because from the buzz I've been hearing more and more over recent years, 
the picture is quite the opposite.  Computers are now faster than they 
need to be for most jobs.  Sure there are exceptions, but they are just 
that, exceptions.  If you want to play to the numbers, the arena to be 
in is not performance critical code.  Java probably wouldn't be #1 on 
Tiobe if performance were the most important thing.  In fact, among the 
top 10 on Tiobe right now, interpreted languages have a combined score 
of 56%, with compiled languages (C/C++) only pulling in 27%.


--bb