Talk:Old Develop activity: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
Line 10: Line 10:
--[[WeBToR]] 05:10, 20 December 2006 (EST);
--[[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.
: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
: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.. :) --[[User:Xavi|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). [[User:Sj|Sj]] [[User talk:Sj|<font color="fc9"><small>talk</small></font>]]

:::I have to differ. Many kids will learn Python without learning English; but many others will be put off by something obviously foreign. Even if you literally translated the word "string" (and by the way, that would mean a different word here in Guatemala than in neighboring Mexico, even though they're both Spanish... so I should say, even if you translated it once per language, for Spanish lets take the worst case which would be Castilian) that would be more welcoming to the kids, and I would bet that it would have measurable effects in terms of adoption of programming. [[User:Homunq|Homunq]] 17:41, 28 July 2007 (EDT)

:::ps. But "string" is not a keyword in python anyway, and I really can't quibble with __str().
== 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. [[User:AlbertCahalan|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. &mdash;[[User:Leejc|Leejc]] 15:27, 15 February 2007 (EST)

I'd like to 2nd the idea of either a Sugar image with Develop built-in or at least git utilities included such that Develop could be easily added to a running image.

I would also like to identify that Eclipse already has a Python plugin called PyDev which might make for another place for non-XO device owners to build activities for Sugar besides Develop. Don't get me wrong, I believe that Sugar needs an activity for developing activities but I also believe that we should leverage existing development tools outside of Sugar when they provide a rich development environment. Having recently seen Adobe's Flex2 Builder plugin for Eclipse, and other Eclipse plugins, I believe that a Sugar plugin would be of great value. Much of the initial project creation and packaging overhead could be automated and the posibility of a design/GUI-builder is there too( as in the Flex Builder ). &mdash;[[User:dlarue|dlarue]] 15:51 28 April 2007 (PST)

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

[[User:AlbertCahalan|AlbertCahalan]] 16:57, 25 February 2007 (EST)

== other (programming) 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++. [[User:AlbertCahalan|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. [[User:OskarLissheim-Boethius|OskarLissheim-Boethius]] 21:34, 3 March 2007 (CET)

:Hackety Hack seems worth watching. 'Make hacking easy again, like in C64 days'. Just starting; ruby; Windows-only so far :(; real apps in a paragraph; includes lessons; attempting high availability (Wii, etc). [https://code.whytheluckystiff.net/hacketyhack/wiki Hackety Hack Wiki]; [http://hacketyhack.net/ hacketyhack.net]; [http://talkety.hacketyhack.net/ Talkety Talk forums].

== Abiword gadget? ==

What if somebody tries to do formatting on source code, or include an image? [[User:Homunq|Homunq]] 15:04, 29 July 2007 (EDT)
::using part of abiword does seem a little OTT since all you really need is colouring and possibly bold - no need for variable width characters, different fonts, images, embedded objects, central or justifyed, paragraph spacing or 101 other things it's probably got - seems to me using it would just bloat things unnecessaraly.[[User:Hello1024|Hello1024]] 18:39, 9 August 2007 (EDT)
:::Well, "bloat" is not exactly the word, since it's in the OS already - but I agree with the point. [[User:Homunq|Homunq]] 20:10, 9 August 2007 (EDT)

Revision as of 19:49, 2 September 2007

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