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