On Wed, Feb 4, 2009 at 7:14 PM, Wade Brainerd <span dir="ltr"><<a href="mailto:wadetb@gmail.com">wadetb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Wed, Feb 4, 2009 at 1:38 AM, Albert Cahalan <span dir="ltr"><<a href="mailto:acahalan@gmail.com" target="_blank">acahalan@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="Ih2E3d">
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
Bobby Powers writes:<br>
> 2009/2/2 Tiago Marques <tiagomnm at <a href="http://gmail.com" target="_blank">gmail.com</a>>:<br>
<div><br>
>> Python is killing the XO, what's being done in that regard?<br>
>> The $100 laptop will always be hardware limited, how can<br>
>> python be a benefit and not a *huge* burden? I for one can't<br>
>> get my head around that.<br>
><br>
> The idea is to give kids as much transparency into the software<br>
> stack as possible, AND make it easy to hack on and easy to create<br>
> new activities for. Python is much more forgiving than C.<br>
<br>
</div>Python is less forgiving if you want performance on the XO. :-)<br>
<br>
For teaching, remember that Knuth uses assembly. C is an awful<br>
lot closer to that than Python, and isn't the XO about teaching?</blockquote></div><div><br>Ha, ahat age group is Knuth teaching assembly to?? What level of math and science skills are they expected to have?<br> <br>
</div><div class="Ih2E3d">
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">> Its killing the XO? A personal pygtk based project launches in a few<br><div>
> seconds on my debXO install on an XO, but much much longer on 8.2.<br>
> It is a completely loaded statement to say that Python is killing<br>
> the XO, and didn't really deserve a response :)<br>
<br>
</div>I'm assuming that "personal [...] project" means small.<br>
<br>
The fact that you consider "a few seconds" to be acceptable shows<br>
just how much people have lost touch with the concept of performance.</blockquote></div><div><br>Python is not the problem. Just strace the activity startup process to see everything that goeson. <br>
<br>
A lot of it appears to be erelated to<br>
a) Rainbow<br>
b) Journal instance creation<br>
<br>
Also I agree that the huge animated loating icon is probably not
helping on XO. Could'nt it be replaced by a large non-animated icon in
the center of the screen, and then smoe dots that appear around the
icon in a circle, adding one dot per second, like a clock? That would
take no overhead and would even give an informal way to measure startup
time by counting the dots.</div></div></blockquote><div></div><div>That seems a good idea. </div><div>The use of SVGs seems unnecessary. Although an awsome functionality, which probably saves a lot of work, would allow to scale the use of Sugar to systems with bigger screens - were it probably will never be in use. I've never seen SVGs being used extensively in a desktop system, let alone an "embedded" one. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div><br></div><div class="Ih2E3d"><div> </div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
Current usage of Python can be mostly explained as follows:<br>
<br>
<a href="http://en.wikipedia.org/wiki/Sunk_cost_fallacy" target="_blank">http://en.wikipedia.org/wiki/Sunk_cost_fallacy</a><br>
<a href="http://en.wikipedia.org/wiki/Sunk_cost" target="_blank">http://en.wikipedia.org/wiki/Sunk_cost</a><br>
<a href="http://en.wikipedia.org/wiki/Irrational_escalation" target="_blank">http://en.wikipedia.org/wiki/Irrational_escalation</a><br>
<a href="http://en.wikipedia.org/wiki/Cognitive_bias" target="_blank">http://en.wikipedia.org/wiki/Cognitive_bias</a><br>
<a href="http://en.wikipedia.org/wiki/Point_of_no_return" target="_blank">http://en.wikipedia.org/wiki/Point_of_no_return</a><br>
<a href="http://en.wikipedia.org/wiki/Psychology_of_previous_investment" target="_blank">http://en.wikipedia.org/wiki/Psychology_of_previous_investment</a><br>
<a href="http://en.wikipedia.org/wiki/Foot_in_the_door" target="_blank">http://en.wikipedia.org/wiki/Foot_in_the_door</a><br>
<br>
The remaining bit of the explanation is that the developer pool<br>
is now full of Python people. Nearly all others have run away.<br>
One can't expect to attract non-Python talent when Python gets<br>
a non-negotiable privileged position.</blockquote></div><div><br>Please don't try to hijack a technical discussion into a political one. Use of the Python language is not the cause of the performance problems on the XO or in Sugar in general. Every system must be optimized no matter what language it is written in. It just takes a little effort.<br>
<br>Wade<br></div></div>
</blockquote><p>As I talked with some people that know more Python than me, they argued that programmer productivity would be a major factor for it's use in some situations. I haven't heard that argument here. I haven't read a good argument that justifies the burden of using an interpreted language in a desktop environment, so it really does seem stubbornness more than anything else, even more and it's all already written in Python.</p>
<p>No matter what interpreted language you're using, it will always stink. Either it's java, python, javascript, whatever. Sugar isn't a webapp, it doesn't even need to be so portable that it can't be written in a language that can be compiled.</p>
<p>Even in powerful machines, most programs I have used written in Java have a huge amount of computing and memory overhead - and Java isn't the worst of it, I read.</p><p>I can't stress this enough: unless the whole OLPC project is starting to take aim at building a laptop that doesn't cost less than $170, I don't see any reason at all not to properly optimize the software. You will always be running some kind of over powered, embedded type system, with little RAM and CPU power. </p>
<p>You have to go against a huge corporation with more powerful hardware, more marketing money AND software that runs a lot faster - and it's not going well, as far as I know. </p><p>Either software manages to hide the lack of horsepower, instead of exhibiting it more, or there will still be problems to land major deals.</p>
<p>The whole project is taking the show source thing way too far, hurting you too much, especially as that is still far from "the vision". You already have Pippy, which should be enough for most kids. The really good kids won't have a problem doing the work to go to the next step(building activities and such) and you can always leave the door open for python activities, while having the basis of Sugar in C, C++ or something. Isn't that what bindings between languages are for?</p>
<p>Best regards,</p><p> Tiago Marques</p>