interpreted vs. compiled

Thomas Kuehne thomas-dloop at kuehne.cn
Fri Jun 29 12:20:10 PDT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Baxter schrieb am 2007-06-27:

[...]

> 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.

'dynamic light' is currently implemented in Flectioned
(http://flectioned.kuehne.cn) as a prove of concept code
for DMD.

# import cn.kuehne.flectionedCall : call;
# import std.stdio : writefln;
#
# class Test{
#    void bar(){
#        writefln("Test.bar");
#    }
#    void bar(int a, char[] b){
#        writefln("Test.bar(%s, \"%s\")", a, b);
#    }
# }
#
# void main(){
#    auto t = new Test();
#
#    call(t, "bar");
#    call(t, "bar", 6, "Erwin");
# }

The main stumbling block is that DMD and GDC use different
calling conventions. I could implement the 'dclass' concept
but am unsure how usefull it is.


Thomas


-----BEGIN PGP SIGNATURE-----

iQIVAwUBRoVZbrZlboUnBhRKAQIjbBAAr+DBeltIb++qKzFwZmZrfODnozZMuURD
FrVgHTUmlEv/cDZHwdTZacypm9aU6ZnqnlG1OBNA8cluFHuKuMA/fQ11uVzebGQb
ceh2spfuplwlEG+zlHU7sqtL//gIK/cyFS84Fx2+DXuPn53QhEl4IshpmI8Hi47o
eLcKSndyo6b5mOjzNlyzdGRfYRDbWXf1oIHgTTP1j0jkhUOc5oP59iN0yHDQphqq
IuSQIV/HijVNbpyXz/cOAQ3PLNz5URPpj33kn5RUFjMZC5Z5YJ0MWkT2U39LGUDp
x7uegAxWfDy+1WjeLNQyZSSZ6QdFL9llynBH4284Vg+nL3BFW8oYYA3HjrV5Zb7b
Eoz2IBGX0fa8Phmyu9sts6J04wHwZw8YjudyhPnFSelQX9wDn82XLD8iVHCOdb30
M32TrFXm5TXiavX3zwGEXcZEFov09GLc3adBm096NTJ301YzPD2KFhVvDfk7exC3
XmBdOYfuxgcS92NCF+ETS5Mf01U2iwIvRmfXr+l2W7WSHASM5nEb6tcEU9Vi+fb4
YSqiS2mZpX3n0lQRTWSwb2Zwb5djeXIDtifc/Q5to7bxSyPOqLnTdS7rJBgUtkti
Fig1bdfvywX7tznWvxMZkuCa4MO527x2xgjc3GzcqeYsJu9wepwuAl1jP7OxXEkV
0XckFCgKPgc=
=kGY1
-----END PGP SIGNATURE-----



More information about the Digitalmars-d mailing list