Talk:Old Develop activity

Feedback on Translation of keywords

There is a drawback if keywords are translated to one's native language. People will want to share code snippets. Although translation is feasible in the IDE, it is not obvious online. Using custom translations are even more of an issue. The IDE could translate the snipped based on its original language but this would require extra effort by the user.

There are much less keywords than methods provided by the standard libraries. If people need to learn the meaning of 'httplib' etc., then learning the meaning of 'string' and 'if' is not much more extra effort. How many native English speaking people automatically associate the word 'string' to a bunch of characters? ;-)

I think learning some keywords initially is more valuable in the long term. Multi/dynamic language comments on the other hand is beneficial, especially in example code etc.

--WeBToR 05:10, 20 December 2006 (EST);

Translation is not just a find-and-replace activity. Many concepts do not translate into a concise word that fits into the target grammar. Traditional programming languages are a sub-set of tailored english, while retaining some sort of 'natural' association to the english language as a whole. It's rarely the case in other languages. IT generates new words or meanings in english that rarely translate in a natural way—believe me.

Unfortunately I don't have much to propose... both alternatives (meaningless regurgitation of tokens or misfit translations) are things to avoid... There must be some other way, alternative or solution... which? can't say... we should probably step out the box and ask a kid.. :) --Xavi 21:42, 29 December 2006 (EST)

WeBToR is right - sharing 'meaningless' tokens with people who speak any language at all is extremely useful. However, once you get into descriptions of how things work -- manuals, mouseover text, &c -- it makes sense to have. As for avoiding misfits -- once a few native language speakers from a new language start using the system, they will update the decriptions appropriately (not just in a find-and-replace way). Sj talk

Version Control

Hey, someone by the name of jpritikin changed the section about the vcs system, and I'd just like to clarify things a bit for him: originally, I actually intended to use git. It was actually Ivan (neuralis) who convinced me to consider bazaar instead thanks to the fact that it has python bindings (it *is* python), and thus wouldn't require me to fork git for every vcs operation. -- Andrew Clunis Orospakr

Forking is better. This isn't Windows or VMS or even Solaris. Forking is cheap. Forking protects you from many types of crashes and leaks... and no, Python is not immune to such problems. (garbage collectors fail if you have a forgotten reference to something) Forking gets you concurrency without the complexity of threading, which Python handles very poorly in any case. Concurrency is of value on any system because the OS can keep the GUI responsive while work goes on in the background. This is even without SMP or a normal disk; with those the concurrency matters a great deal more. Future generations (years from now) of the OLPC XO are likely to be SMP because that costs less power than increasing clock speed. AlbertCahalan 16:45, 25 February 2007 (EST)

Useful for non-XO developers, too

I'd just like to point out that this project would also be useful for people who do not have XO machines but would like to contribute to the OLPC project. It's currently much easier to run an OLPC image in an emulator than it is to set up a Sugar build environment. So having an emulator image with the Develop activity would make it easier for more people to contribute new activities (less to download, set up, etc.), even if they are not a target student or teacher. —Leejc 15:27, 15 February 2007 (EST)

must use UUID

You need to be using a UUID to identify versions. Much terrible badness can happen if you don't. Git does OK, with a moderately secure hash to protect against most troublemakers. Bzr is weak. Ideally you'd use a secure 256-bit hash.

This hits app bundles as well. Apps need to be installed by UUID, so that two apps can have the exact same name. Though slightly confusing, it'll be far less bad than arbitrarily renaming, overwriting, or blocking. Users can tolerate "the Tam Tam on the left" and "the extra Tam Tam over there" if icons dont move around needlessly.

AlbertCahalan 16:57, 25 February 2007 (EST)

other languages

Suppose the view-source button is used during boot-up. As appropriate, the OpenFirmware or LinuxBIOS source should be loaded up in the editor. These are not written in Python. It is particularly important to handle C, sh, and make. For example, Tux Paint is in C and make. It would also be good to handle Java, JavaScript, and C++. AlbertCahalan 17:06, 25 February 2007 (EST)

Since Ruby (and notably Ruby on Rails) is becoming very popular on the web and has the (from an XO point of view) added benefit of having a syntax somewhat similar to Python, it couldn't be a bad idea to add support for that as well. RoR is quickly becoming a de-facto standard of creating solid web-apps, and I could imagine a great deal of good coming from the new breed of children-hackers. OskarLissheim-Boethius 21:34, 3 March 2007 (CET)