I want to develop a system for teaching various algorithms that students learn starting from primary school all the way to high school and perhaps even into university. For this I need a core system and for each algorithm an application layer on top of the core needs to be written.
The idea is the the student first solves the problem by hand, then implements low level components of the algorithm into procedures and then is able to solve the problem more quickly by invoking these procedures by hand. Then these procedures can be combined into higher level procedures that the student can use to solve the problem even more quickly. Eventually the the entire algorithm is implemented into a top level procedure that the student can invoke.
Thus the student learns all the steps of the algorithm (since (s)he initially does them by hand but also combines them into procedures that can be called but the student also learns programming at a basic level. It is noteworthy that once the student has partially implemented the algorithm (s)he is able to solve large instances of the problem by using the procedures already implemented. For example, a student learning long division could compute 91935 / 45 more easily after implementing subtraction and multiplication of a number by a single digit. The student could then do the division even faster by implementing a procedure that combines subtraction and multiplication of a number by a single digit. And so on.
Algorithms I am interested in implementing include multiplication, long division, simplifying fractions. and simple linear algebra. I am also interested in Chemistry/Physics and university level algorithms. For example Gaussian elimination and the simplex method could be taught this way.
OK so where does EToys fit in?
Well, I don't want to implement this utility from scratch. But EToys, Scratch, and BYOB/Snap all implement aspects of what I need already. Scratch looks like a better fit than EToys and BYOB/Snap looks even better (has procedures and recursion (recursion is useful for simplifying fractions for example)). Unfortunately for me, Scratch is being ported to Flash and Snap is being rewritten in Javascript but I very much want to continue working in Smalltalk. A version of Scratch has been ported to Pharo but the porters suggest that the best thing to do is rewrite Scratch from scratch since it is so poorly written.
So my question is: Would it be better to use the core of EToys to build my system. For that matter, if I wanted to re-implement Scratch should I not use the core of EToys to base it on? This probably means that EToys would need to be re-factored to some extent so that a core could be separated from the "EToys Application". In fact, I might need a Scratch/Snap core that goes on top of EToys core. For that matter should not EToys and Scratch already have been written with a common core?
For those of you familiar with the Enchanting project (which allows programming of the Legos Mindstorms robot using a version of Scratch) I would also want to be able to base Enchanting on the core of EToys. By the way Enchanting is an example of where a web based version of Scratch is not going to work so it looks like Enchanting developers will have to maintain their version of Scratch.
So what should my plan be?
Regards,
Ralph Boland
Both Scratch and Etoys are open source so it's just to pick what you want. The model of Scratch and Etoys are quite different and it's a _huge_ job joining them. I'm not very familiar with Scratch source, but what I have seen is quite good and simple code. It's made in a rather old image so much has changed since then in both Pharo, Etoys and Squeak.
I recommend you to make a few test projects and see what system fits your needs best.
Karl
On Sat, Dec 24, 2011 at 1:39 AM, Ralph Boland rpboland@gmail.com wrote:
I want to develop a system for teaching various algorithms that students learn starting from primary school all the way to high school and perhaps even into university. For this I need a core system and for each algorithm an application layer on top of the core needs to be written.
The idea is the the student first solves the problem by hand, then implements low level components of the algorithm into procedures and then is able to solve the problem more quickly by invoking these procedures by hand. Then these procedures can be combined into higher level procedures that the student can use to solve the problem even more quickly. Eventually the the entire algorithm is implemented into a top level procedure that the student can invoke.
Thus the student learns all the steps of the algorithm (since (s)he initially does them by hand but also combines them into procedures that can be called but the student also learns programming at a basic level. It is noteworthy that once the student has partially implemented the algorithm (s)he is able to solve large instances of the problem by using the procedures already implemented. For example, a student learning long division could compute 91935 / 45 more easily after implementing subtraction and multiplication of a number by a single digit. The student could then do the division even faster by implementing a procedure that combines subtraction and multiplication of a number by a single digit. And so on.
Algorithms I am interested in implementing include multiplication, long division, simplifying fractions. and simple linear algebra. I am also interested in Chemistry/Physics and university level algorithms. For example Gaussian elimination and the simplex method could be taught this way.
OK so where does EToys fit in?
Well, I don't want to implement this utility from scratch. But EToys, Scratch, and BYOB/Snap all implement aspects of what I need already. Scratch looks like a better fit than EToys and BYOB/Snap looks even better (has procedures and recursion (recursion is useful for simplifying fractions for example)). Unfortunately for me, Scratch is being ported to Flash and Snap is being rewritten in Javascript but I very much want to continue working in Smalltalk. A version of Scratch has been ported to Pharo but the porters suggest that the best thing to do is rewrite Scratch from scratch since it is so poorly written.
So my question is: Would it be better to use the core of EToys to build my system. For that matter, if I wanted to re-implement Scratch should I not use the core of EToys to base it on? This probably means that EToys would need to be re-factored to some extent so that a core could be separated from the "EToys Application". In fact, I might need a Scratch/Snap core that goes on top of EToys core. For that matter should not EToys and Scratch already have been written with a common core?
For those of you familiar with the Enchanting project (which allows programming of the Legos Mindstorms robot using a version of Scratch) I would also want to be able to base Enchanting on the core of EToys. By the way Enchanting is an example of where a web based version of Scratch is not going to work so it looks like Enchanting developers will have to maintain their version of Scratch.
So what should my plan be?
Regards,
Ralph Boland _______________________________________________ etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Sun, Dec 25, 2011 at 5:50 PM, karl ramberg karlramberg@gmail.com wrote:
Both Scratch and Etoys are open source so it's just to pick what you want.
Not quite so simple. Scratch is open source, but it is not Free Software. There are some restrictions you need to look into that may or may not impact your ability to proceed with your project. Etoys has no such restrictions. FWIW, there is an effort to change the Scratch license to a Free license, but AFAIK, the change has not yet taken place.
-walter
The model of Scratch and Etoys are quite different and it's a _huge_ job joining them. I'm not very familiar with Scratch source, but what I have seen is quite good and simple code. It's made in a rather old image so much has changed since then in both Pharo, Etoys and Squeak.
I recommend you to make a few test projects and see what system fits your needs best.
Karl
On Sat, Dec 24, 2011 at 1:39 AM, Ralph Boland rpboland@gmail.com wrote:
I want to develop a system for teaching various algorithms that students learn starting from primary school all the way to high school and perhaps even into university. For this I need a core system and for each algorithm an application layer on top of the core needs to be written.
The idea is the the student first solves the problem by hand, then implements low level components of the algorithm into procedures and then is able to solve the problem more quickly by invoking these procedures by hand. Then these procedures can be combined into higher level procedures that the student can use to solve the problem even more quickly. Eventually the the entire algorithm is implemented into a top level procedure that the student can invoke.
Thus the student learns all the steps of the algorithm (since (s)he initially does them by hand but also combines them into procedures that can be called but the student also learns programming at a basic level. It is noteworthy that once the student has partially implemented the algorithm (s)he is able to solve large instances of the problem by using the procedures already implemented. For example, a student learning long division could compute 91935 / 45 more easily after implementing subtraction and multiplication of a number by a single digit. The student could then do the division even faster by implementing a procedure that combines subtraction and multiplication of a number by a single digit. And so on.
Algorithms I am interested in implementing include multiplication, long division, simplifying fractions. and simple linear algebra. I am also interested in Chemistry/Physics and university level algorithms. For example Gaussian elimination and the simplex method could be taught this way.
OK so where does EToys fit in?
Well, I don't want to implement this utility from scratch. But EToys, Scratch, and BYOB/Snap all implement aspects of what I need already. Scratch looks like a better fit than EToys and BYOB/Snap looks even better (has procedures and recursion (recursion is useful for simplifying fractions for example)). Unfortunately for me, Scratch is being ported to Flash and Snap is being rewritten in Javascript but I very much want to continue working in Smalltalk. A version of Scratch has been ported to Pharo but the porters suggest that the best thing to do is rewrite Scratch from scratch since it is so poorly written.
So my question is: Would it be better to use the core of EToys to build my system. For that matter, if I wanted to re-implement Scratch should I not use the core of EToys to base it on? This probably means that EToys would need to be re-factored to some extent so that a core could be separated from the "EToys Application". In fact, I might need a Scratch/Snap core that goes on top of EToys core. For that matter should not EToys and Scratch already have been written with a common core?
For those of you familiar with the Enchanting project (which allows programming of the Legos Mindstorms robot using a version of Scratch) I would also want to be able to base Enchanting on the core of EToys. By the way Enchanting is an example of where a web based version of Scratch is not going to work so it looks like Enchanting developers will have to maintain their version of Scratch.
So what should my plan be?
Regards,
Ralph Boland _______________________________________________ etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev@lists.squeakfoundation.org
-
karl ramberg -
Ralph Boland -
Walter Bender