that includes the following characteristics: • Analyzing and logically organizing data • Data modeling, data abstractions, and simulations • Formulating problems such that computers may assist • Identifying, testing, and implementing possible solutions • Automating solutions via algorithmic thinking • Generalizing and applying this process to other problems
the underlying patterns (of steps) after breaking down a task, and solving these patterns by giving simple sets of instructions – such that a computer, an unthinking machine that follows steps, can do to complete the task.
thinking [with a variety of aims – design and develop their own metaphors for concepts, etc.] But essentially, to allow them to draw, make turtle art, using simpliﬁed programming commands. 2. Scratch aimed to obviate the difﬁculty of debugging syntax errors, and having to know scripting to make programs – to describe stories, make animations, etc, easily.
a large repository of puzzles, which are solved by very nicely designed conditionals and elements of recursion – without having to write any code, and only dealing with the concepts of the same. http://www.robozzle.com
project’s design. We imagined that making puzzles that ask for making certain pieces of music – would be an engaging act for the output, and also host a wide area for thinking and ﬁnding increasingly optimized solutions (in terms of whatever elements we put in).
this step, we were aware that we wanted support for functional modularity: Because ﬁnding common patterns, and distributing them across functions is one of the most common, and useful exercises, especially as a manifestation of computational thinking. We foresaw the nature of puzzles that we want our interface to enable ﬁnding multiple solutions for – play all permutations of a set of musical notes (very tough), play certain notes on odd beats, and different on even beats, and so on…
beat, on a horizontal timeline. (+) Similarities with the way music notation is written. Maybe, if our interface was adequately similar to how music notation is written, that could be a learning outcome as well. (–) To obtain the modularity of functions in this metaphor, was turning out to be very difﬁcult and synthetic/forced-seeming. If a certain piece of the timeline is separated into a function, it’s speed should be change-able, and it should be able to switch between other pieces of the timeline – a concept that didn’t sound very meaningful.
blocks and their construction corresponds to a set of notes in a particular manner. (+) being a tangible toy, this would probably have greater play and engagement. (–) tough to embed puzzles or challenges to discretely solve. Lesser scope, in our thoughts, for learning new concepts via puzzles/levels.
frequent circular metaphor for music loops etc., we imagined giving programmable disks to store the music – and act as modules representational of function blocks. (+) clear modularity in multiple disks – to allow for function programming and calling, (+) possible allowances for recursion, (+) Simple interactions for deﬁning music to be played, and clear scope for making puzzles with the aim of music generation, (~) Currently exploring the possibility of functionality of arrays in this metaphor – which along with recursion would provide scope for a vast variety of clever and interesting puzzles.
to be played is simply highlighted as blue when the spindle goes across it. • The user can’t yet add more disks, and remove disks. The code has support for multiple disks, but the UI so far doesn’t. • There is no puzzle interface, or monitoring of output created by the user, yet.
this means, is that the operations of a function aren’t pushed to a stack in the current prototype. Hence disk 1, which was supposed to be analogous to void main(), does not resume playing if linking to disk 2 (i.e. calling function2() in between) ﬁnishes playing. Calling any disk, currently, resumes its playing, rather than run it from the start again (as would happen with calling a function), while the remaining operations be kept in a stack to execute later. > Due to this, the shown puzzle 1 – solution 2 doesn’t work on our prototype.