• Dynamic typing means less help in finding bugs; risk of lower ambition
• No ''typing dialog'' with a compiler means less conceptual learning
• Non-explicit types in function defs is less efficient when learning abstract thinking
• Indentation syntax with silent begin-end can make nested blocks obscure to beginners
• No explicit variable declaration can lead to very hard bugs also for non-beginners
• Refactoring is more risky, hence discouraging -> bad for step-wise problem solving
• Not excellent at object orientation
• Not excellent at functional programming

I have no systematic empiricism behind the above hypotheses but I have some anecdotal evidence that suggest that the above list might be important to address when considering Python.

//Bjorn

I am impressed by your project. I would wish Kojo to be used in every school.

Thanks to Lalit.

I have another question.

I am a math teacher in senior high school. In Kojo, Would it be possible to script number theory, mathematical modeling and so on?

For example, try this script:

Mw.clear()
Mw.hideAlgebraView()
Mw.showAxes()
Mw.variable("m", 1, -5, 5, 0.1, 50, 50)
Mw.variable("c", 0, -2, 2, 0.1, 50, 80)
Mw.evaluate("y = m x + c")

To see more examples, look (in the script editor) at the scripts for Help -> Kojo Overview and Samples -> Math Learning Modules -> Solving Linear Equations (run these scripts, and then search for Mw. in the script editor)

Code completion on the Mw object (type Mw. and then Ctrl+Space) will show you what's available for geogebra interaction.

Or you can look at the Mathworld class (of which the above Mw is an instance) to see what's inside in more detail:
https://github.com/litan/kojo/blob/master/src/main/scala/net/kogics/kojo/mathworld/MathWorld.scala

Hope that helps. Feel free to ask more questions.

• clear the screen.
• create your pictures.
• draw your pictures (a picture can only be drawn once).
• animate some of your pictures in an animation loop. This involves:
  • transforming drawn pictures.
  • erasing drawn pictures and creating/drawing new ones.
  • wiping all pictures and creating/drawing new ones.

Here's some code showing this in action:

// you dont need to use Staging with Pictures cleari() val im = PicShape.image(Costume.car) val line = PicShape.hline(100) // val background = ... draw(im, line) // draw(background) val ang = 1 var totalAngle: Int = _ var angLabel: Picture = _ onAnimationStart { // initialize vars here totalAngle = ang angLabel = trans(120, 0) -> PicShape.text(totalAngle, 15) draw(angLabel) } animate { im.rotate(ang) line.rotate(ang) angLabel.erase() totalAngle += ang angLabel = trans(120, 0) -> PicShape.text(totalAngle, 15) draw(angLabel) // let the background be }

Hope that points you in the right direction. Feel free to ask questions about any further problems you run into (and feel free to post your canon animation code to get further help. You can email me the image files at pant dot lalit at gmail dot com).

thanks ;)

we need some help…

We want in teaching purposes write small games with two cannons. The main problem now is how to do correct animation with loaded images ?
We want that children draw two cannons and background. Than we scan this pictures, extract background and canons and put in into Kojo scene.
So the problems:
1. every drawn image overlaps the image we want to draw at runtime (example below)
2. we have original canon image that is paralel to X axis, and we want to rotate it in absoulte manner like "rot(13) -> im", but not in reference manner like in example below.
3. how correctly we should draw the scene (possibly using picture stack)
- draw background
- above background should place two cannons
- than print wind/gravity/velocity/other data

import Staging._ import Staging.{animate, wipe} cleari val im = PicShape.image("/home/alex/circle.png") // small picture about 60x60 pixels val ang=1; animate{ wipe im.rotate(ang).realDraw() line(0,0,200,200) }

• go into an exercise directory, and start up Kojo with a shell script that sets KOJO_CLASSPATH to the appropriate jars before launching Kojo (or copy/link the required jars inside the ~/.kojo/lite/libk folder, but that would be global, not project specific).
• use the //#include feature in the script editor to pull in exercise code.

I hope that points you in the right direction. Feel free to ask questions about any problems that you encounter while trying this.

Do let us know what environment you finally choose for your teaching needs!

You're right, the answer to why Scala doesn't quite shine through on that page (although it's hidden in there ;)). In any case let me jot down some points here:

Scala
- Is very easy to get going with
- Has great support for imperitive programming
- Has great support for functional programming
- Has great support for object oriented programming
- Has great support for concurrent and parallel programming
- Has a deep set of in-built data structures and algorithms
- Has access to everything written in Java
- Runs on a fast/robust VM

All of this makes it easy for kids to get going with programming, and provides them a very well thought out path for exploring (over many years) many different facets of programming.

I'm way more familiar with the Java ecosystem than with the world of Python, so an easy to use and powerful language on the JVM (i.e. Scala) was kinda the natural way for me to go. If I had to do it again, I would make the same choice. Why? Because in the end, the thing that matters (much more than the technology that you use) is what you do with that technology. The only thing you need to be careful about is that your choice of technology should not place aritificial restrictions on whatever you are trying to accomplish. With Scala/JVM, I'm very confident that I'll be well supported (by my technology choice) across a very deep/wide range of potential uses.

Hope that helps…

The only relevant text I found on the link you gave, in terms of a possible response to my query, was this: "The programming language used within Kojo (Scala) commands some of the highest salaries in the software engineering profession around the world. So all the work that kids put into Kojo has very practical benefits, in addition to all the rich learning benefits." The kids i have to teach are at a age where they dont really care about salaries or profession (meaning they are too young for that). May I please know if there is any other reason for your choice of Scala? I am especially interested in knowing advantages vis-a-vis some similar tool that could be Python+Kivy based.

In other words if Kojo were to be redeveloped from scratch would you still choose Scala or would you rather use Python and Kivy. I am aware that in software development often the choices have been made for some historical reasons and we get stuck with them, because at that time it seemed like a good idea given what else was available back then. Therefore I am not criticising your choice of Scala, but merely trying to evaluate for myself whether it would make sense to start from scratch. I am not wedded to Scala or Python or any other language for that matter. However, I heard from random people that the new developments with kivy tilt the balance in favour of Python and because I dont know either, I am checking with (Scala experts like) you whether it would be worth anybody's while putting in 3-4 months reinventing the wheel. Do you feel the new Kojo look alike built on Python/Kivy be a mere cosmetic facelift? This is what I am trying to get at. Hopefully you can give me an opinion with some technical justification (such as what features of Scala were really helpful, but are absent or awkward in Python/Kivy while developing this kind of amazing tool that you have created).

Thanks, and yes once again, congrats on doing a great job helping children, and enhancing the reputation of Indian software developers :) Cheers!

As far as the question why Kojo (using Scala/JVM)? is concerned, here's something I wrote up last year:
http://wiki.kogics.net/kojo-faq

Feel free to ask more questions if that link does not quite answer your questions about Kojo.

(I need to go and revise that page based on all the water that has flown under the bridge over the past sixteen months, but the current content in there is a fair reflection of the ideas behind Kojo).

This is fixable with some work, of course, but the extra effort required to do this has not yet been put in.

Translating stuff in the resources/samples directory (as I understand your idea) would require the prior translation of a much larger chunk of the Kojo API. Translators have not felt the need to attempt this yet.