[olpc-software] sugar - patch

[Mike Hearn]

I don't necessarily disagree but feel a devils advocate argument might
be useful.

On 6/7/06, Dan Williams <dcbw at redhat.com> wrote:
> It's all about the trade-offs, yes.  For not being as memory and CPU
> efficient as C, we get to (a) not care as much about buffer overflows,

ExecShield ASLR seems to solve this for the desktop case ...

> (b) rapidly prototype features
> (c) allow children to easily make their own activities,

Make sense.

> (d) use all the C code that is very efficient through bindings,

I used to agree with this line of reasoning but practical experience
with optimisation has made me disillusioned with it. If you want to
write tight software it's pretty uncommon to have a small set of
hotspots unless it's an extreme case like a GUI over some kind of
maths problem. Sometimes slowness is a big, overarching problem (eg
with Java desktop apps ....)

> and (e) not care at all about C/C++ ABI/API issues.

Python has ABI and compatibility problems too, I had to investigate
this recently for autopackage. So I would say this is not really an
advantage.

> Again, if there are efficiency issues with parts of the environment, we
> may well end up recoding them in C.  We're certainly not going to do
> window-manager-like bits in Python.

Well, ok, you're the guys doing the work ... I just worry it'll end up
with the same problem Chandler had (where it takes 20 seconds to start
for no particularly good reason).

thanks -mike