[Sugar-devel] GSoC 2015: Interactive JavaScript Shell

Tony Anderson tony_anderson at usa.net
Sat Mar 14 22:43:44 EDT 2015


Hi, Sebastian

You must remember that I am an old curmudgeon. For me, simplicity was 
programming in assembler as opposed to typing in octal code. I entered a 
more complex world with Fortran and Cobol, simplified by Basic. Programs 
for the IBM 1401 started at position 333 since the only operating system 
was a load button and the only debugging tool was a button that dumped 
memory contents to a printer. Every program we wrote was complete. 
Today, there are few programmers who have ever written anything more 
complicated that 'Hello World' as a complete program. Today, virtually 
all programming is 'own code' to a pre-existing program. I think that 
the phrase 'own code' is now part of a curmudgeon's history - in the day 
it meant a subroutine written to be used in an existing program.

My main concern with full IDEs is that the user may not be able to write 
a real program to execute in a real environment. On the other hand, the 
beginning programmer shouldn't get bogged down in boilerplate. The 
programming languages have essentially no boilerplate (shebang?). It is 
a web page that requires a fixed skeleton. However, Richa's solution 
hides that from the user. It can't be completely hidden since the 
learner needs to know how to build a web page independently of the tool. 
This is covered by the Pocket HTML lessons.

The Explore section of the School Server content is organized in the 
form of a course with units and lessons. Amazingly, it now includes not 
one, not two, but three programming languages: Python, Javascript, and 
Shell Scripting.  Javascript is intended to build on a knowledge of HTML 
and CSS although the text, Eloquent Javascript actually introduces 
Javascript as a programming language and connects it to the web only in 
the second part (the third introduces node.js). Incidentally, the course 
based on Eloquent Javascript provides a 'take no mercy' approach to 
introducing all of these essential programming concepts. I am sure it 
would not be available to our students without Richa's tool. Anyone who 
fully understands the concepts in this text is 'good to go' at any level 
of programming.

The first prerequisite course, introduces the Terminal Activity, the 
file system, and the nano text editor. With this basis, the learner has 
a basis for saving programs and web pages as files and executing them 
from the command line (or displaying in the Browse activity with file:// 
and a path. The courses Terminal 1 and Terminal 2 (from William Shotts - 
http://linuxcommand.org/tlcl.php) continues into more on the shell and 
writing shell scripts.

My curmudgeon past also included putting the programs from David Ahl's 
Basic Computer Games (http://atariarchives.org/basicgames/) on a 
Commodore 64.
The first Python course from Al Sweigart's Invent Your Own Computer 
Games With Python (http://inventwithpython.com/) shows how to program 
similar text games in Python. The second Python course from Al 
Sweigart's Hacking Secret Ciphers With Python is also introductory and 
text-based but in the domain of cryptography. The
third course also based on a book by Al Sweigart, Making Games with 
Python and Pygame, depends on the material covered in the first two 
courses.

WIth regard to the proposed fourth Python course, you are right on 
target. However, the introduction to Pygame does not relate it to 
objects. An important goal to this course is to develop understanding of 
these essential programming concepts: programming to an event-driven 
environment and organizing a large program to be understood for ease of 
maintenance and debugging. An important corollary is learning to read 
programs written by others.

I think that Hello World is a good starting point since the learners 
will have already built Hello World as a standalone program. This allows 
the discussion to focus on what is required to run it as a Sugar 
Activity. For example, despite the complex folder that is the HelloWorld 
activity, everything is boilerplate except the 'activity.info' and 
'activity.svg' files. The 'HelloWorld' Python program is in activity.py 
file. There the actual label('Hello World') is one line as print 'Hello 
World!' is in the original. This presents the opportunity to explain the 
rest of the file in the Sugar context. This also gives a good incentive 
for the learner to convert the Toolbar code to a module

The BlockParty activity has been a favorite (I like Tetris), but it 
demonstrates a technique to build the activiity as a standalone 
executable file (__main__) and yet have it called by the framework in 
the Sugar context. This, of course, is a valuable capability of Python.

This can motivate the learner to learn how to make the Python programs 
from Swegart's texts into Sugar activities.

One unavoidable boilerplate issue in this course is the difference 
between sugar and sugar3. Given the direction of later Sugar builds, 
this topic is inevitable. The course will also have to cover olpcgame as 
a wrapper to pygame.

The course will also include challenges to work with and improve Sugar 
Activities from ASLO. One example is converting Toolbars to the new 
standard. Another is fixing activities with Hulahop to use webkit or 
WebKit. At a more difficult level, fix InfoSlice to access the 
wikipediae on the school server. One section of the course should be to 
build a 'collaborative' Sugar activity. For example, convert a two 
player game where both players play on the same XO to one where the 
players are on different XOs. I hope to show how to make a 'king of the 
hill activity' where the two players play the game and others watch. The 
loser becomes a watcher and the longest waiting watcher becomes the 
challenger.

Tony



On 03/15/2015 02:39 AM, Sebastian Silva wrote:
> I find this discussion very interesting.
>
> It is hard for me not to think of a full IDE like creature when 
> thinking of the jsfiddle tool.
>
> Perhaps I'm failing to see exactly the point or the inteded "Use Case".
>
> On my side, as a self-taught-as-a-child programmer, I appreciate 
> abstraction layers very much because they allow me to think of the 
> actual thing I want to implement.
>
> What I do not appreciate is boilerplate code.
>
> To really understand Hello World activity, you must understand some 
> basic concepts of Object Orientation, the notion of what is GTK, 
> event-driven programming, etc.
>
> Even Hello Web carries a lot of boilerplate with it.
>
> In my humble opinion it's not so bad when the boilerplate code is not 
> seen (i.e. part of the toolchain, or at least, in a template).
>
> Perhaps we've exhausted the discussion and it will come to a matter of 
> the design chosen by the implementors for its first iteration.
>
> Perhaps it's a good time to remember our core design ideas: 
> Simplicity, Collaboration, Reflection, and try to apply them to this 
> design.
>
> Sounds like a fun project.
>
> Regards,
> Sebastian
>
>
> El 11/03/15 a las 00:34, Richa Sehgal escibió:
>> Hi,
>>
>> Regarding inclusion of libraries such as Jquery, maybe we can let 
>> students create templates which we can save in their web folders. The 
>> objective is the following: As Tony mentioned, providing them with 
>> templates might not make them learn the basics, but essential parts 
>> of programming. For example, in my initial days of coding, I used 
>> Eclipse which started a new file in a nice template. During my first 
>> exam, I realized that I have forgotten the signature of the function 
>> main (the arguments type and number of arguments). Since then, for 
>> any new language that I pick up, I start from scratch. So what we can 
>> do is that students can create templates for shortcuts, but at least 
>> they would have some hands-on experience. This can then serve like 
>> what Sebastian mentions.
>>
>> As for the performance, after we develop the tool, we can do a 
>> performance benchmark and publish the numbers for different 
>> libraries, and CSS functionalities. These numbers can also be used by 
>> other developers as the basis for their algorithms, and we can see 
>> how to improve on them and also study how they change as XO and Sugar 
>> evolves.
>>
>> Thanks
>> Richa
>>
>> On Tue, Mar 10, 2015 at 5:05 PM, Tony Anderson <tony_anderson at usa.net 
>> <mailto:tony_anderson at usa.net>> wrote:
>>
>>     Hi, Sebastian
>>
>>     I am using Zim Desktop Wiki to reformat the book into digestible
>>     lessons (actually done). This makes it all html. My plan is to
>>     put this on the school server so that a
>>     student can download a chapter to view locally while working on
>>     it. I added a button to the Browse toolbar that displays a
>>     Journal object chooser and then displays the selected Journal
>>     object  - a zip file which contains the web site in a compressed
>>     folder.
>>
>>     I also provide a prerequisite course introducting the Terminal
>>     Activity and the nano editor. The model is that students would
>>     have a directory in /home/olpc/Documents named web. This
>>     directory would be used to hold thier web pages. At some point
>>     when they learn about links, they can set up a main page with
>>     links to the others. All
>>     of this is accessible from the Browse activity by
>>     file:///home/olpc/Documents/web/index.html.
>>
>>     The student should learn to add jquery by reference in the head
>>     of their web page. The actual js files can be downloaded from the
>>     school server (or installed with Sugar by usb stick). One problem
>>     with ide approaches is that it hides some of what we are trying
>>     to have the students learn. For example, I seriously considered
>>     using pippy to teach Python, but concluded that it would hide how
>>     to save Python programs, how to make them executable, and how to
>>     share them. In a course on making Sugar Activities, pippy can
>>     actually export the python code in a Sugar Activity wrapper, but
>>     what does the student learn about the construction of a Sugar
>>     Activity from that? I would rather they begin with the HelloWorld
>>     Activity.
>>
>>     I have used a localhost for years with no problem. Since
>>     switching from Firefox to Webkit, I haven't been using it but
>>     primarily because I haven't tried to implement the features that
>>     required it. I am not sure it will be relevant at the intial web
>>     level. In any case, jquery did not cause any performance problems
>>     on an XO1.
>>
>>     As regards Webkit, my concern is that in the Browse Activity it
>>     does not seem to support flexible boxes, the modern way to do web
>>     layout, and in many ways the key to reponsive web design.
>>
>>     Tony
>>
>>
>>     On 03/10/2015 10:11 PM, Sebastian Silva wrote:
>>
>>         El 10/03/15 a las 04:58, Tony Anderson escibió:
>>
>>             I am working on a course based on Pocket HTML
>>             (http://www.goer.org/HTML/) which is available via CC. At the
>>             javascript level, I think Eloquent Javascript would be a
>>             good base and
>>             is also CC.
>>
>>         Hi Tony,
>>
>>         This is wonderful. I have had my eye on that tutorial ever
>>         since I
>>         started to think about Web activities a long time ago.
>>
>>         My first attempt at a Web Activity was called WebSDK and was
>>         an IDE for
>>         doing web apps [1].
>>         Those were old-style web apps, the ones that had a Python
>>         mini-server
>>         running in the background.
>>         I still consider this a good approach to access Python
>>         infrastructure
>>         from Javascript, but I'm not sure how (or if) the new Web API
>>         infrastructure has replaced this mechanism.
>>
>>         I think, in any case, for a GSOC student working on dev tools
>>         for JS on
>>         Sugar, should consider the entire IDE scenario, not just the
>>         "fiddle"
>>         part. I.e. it should be possible to deploy a mini app (or
>>         content!) from
>>         this activity.
>>
>>         About embedding JQuery and other libraries, I would favor a
>>         "Wizard"
>>         approach. I.E. a form that will allow you to have a basic
>>         project from a
>>         template (w/ or without optional toys such as Jquery). I like the
>>         hand-holding approach especially since low performance
>>         machines can't do
>>         multi-tasking very well (so looking up docs is not easy).
>>         Therefore a
>>         version of the JS tutorial that Tony referenced would be
>>         great to have
>>         embedded,  IMHO, or included somehow. (Tony do you have an
>>         offline copy?)
>>
>>         In order to avoid slow pages on older machines, including XO,
>>         it should
>>         be super lightweight, i.e. utilizing as little CSS3,
>>         transformations,
>>         transparency, SVG rendering, and animation as possible. At
>>         least a
>>         couple of templates should be able to run on the XO1 without
>>         issues.
>>         Hopefully some profiling feedback would be shown inline during
>>         development (such as at least load time for the "fiddle").
>>
>>         Also, there are wrappers for web activities for versions of
>>         Sugar that
>>         don't include the Web Activities framework. Maybe include
>>         those as
>>         options in the templates. Finally, a good editor goes a long
>>         way for a
>>         good development environment (I used Ace editor component and
>>         it ran
>>         well on XO1, back in the day).
>>
>>         The way I think of this is that you should be able to develop
>>         something
>>         relatively basic without resorting to the Internet either for
>>         sensible
>>         libraries or their respective documentation. If done really well,
>>         perhaps we could even offer an alternative to Pippy and Develop?
>>
>>         Finally, I don't think the Webkit or even old Firefox
>>         rendering engine
>>         are a severe limitation. It's not worse than targetting Internet
>>         Explorer 6 and most web developers had to do that only a
>>         couple of years
>>         ago. I suggest you download Firefox 3.6 (from like 10 years
>>         ago) as that
>>         is the rendering engine found on Sugar 0.94 and limit
>>         yourself by what
>>         it can do. I havben't looked for a reference browser for the
>>         Webkit1
>>         engines, except Browse itself. It would be good to find out
>>         what our
>>         current engine equivalent is and document it (along with more
>>         contributions) to http://developer.sugarlabs.org/
>>
>>         Regards and good luck.
>>
>>         [1] http://somosazucar.org/files/2011/07/WebSDK1.png
>>         http://somosazucar.org/files/2011/07/WebSDK2.png
>>         .
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20150315/d2080955/attachment-0001.html>


More information about the Sugar-devel mailing list