Skip to content

Commit

Permalink
Updated Discussion on Dynabook (markdown)
Browse files Browse the repository at this point in the history
  • Loading branch information
jrfern committed Apr 20, 2024
1 parent dad57d3 commit 4646f91
Showing 1 changed file with 4 additions and 4 deletions.
8 changes: 4 additions & 4 deletions Discussion-on-Dynabook.md
Original file line number Diff line number Diff line change
Expand Up @@ -170,7 +170,7 @@ The older proposals, as you wrote it, failed because it was not teacher-centered

**---HF**: It is a model representing a media of some knowledge you can interact with. Two basic examples of dynamic knowledge models are a digital image in very high resolution and a digital sound track. The images are numerous in a paper textbook, however, contrary to digital image, you can't zoom-in to discover additional details.

A more elaborated example of a dynamic-knowledge-model, illustrating more precisely its model dimension, is a DrGeo sketch, designed with a script, the user will insert it in her document, along handwritten notes. The user could then interact with the sketch, dragging objects to observe what is happening and discovering behavior to engage in new learning. The model itself is an interactive geometry engine the user can script with a dedicated DSL -- Domain Specific Language -- to represent dynamic knowledge the end user can interact with. The model dimension in a given dynamic-knowedge-model domain is what make it versatile, with one you can design a lot of different interactive contents. It relies on the facilities provided by Oriented Object Programming, as explain by [Adele Goldberg](https://youtu.be/IGNiH85PLVg?si=HpbUQNGj1SU6rfwj&t=860).
A more elaborated example of a dynamic-knowledge-model, illustrating more precisely its model dimension, is a DrGeo sketch, designed with a script, the user will insert it in her document, along handwritten notes. The user could then interact with the sketch, dragging objects to observe what is happening and discovering behavior to engage in new learning. The model itself is an interactive geometry engine the user can script with a dedicated [DSL](https://rmod-files.lille.inria.fr/Team/Presentations/2010-DSL-Choose-Ducasse.pdf) --- ***Domain Specific Language*** --- to represent dynamic knowledge the end user can interact with. The model dimension in a given dynamic-knowedge-model domain is what makes it versatile, with one you can design a lot of different interactive contents. It relies on the facilities provided by Oriented Object Programming, as explain by [Adele Goldberg](https://youtu.be/IGNiH85PLVg?si=HpbUQNGj1SU6rfwj&t=860).
Technically all these views are Morph instances representing the underneath model. The Morphs offer a common way to interact with and be integrated in the handwritten document.

**---JR**: Let me try to understand. Are [PhET simulations](https://phet.colorado.edu/) dynamic knowledge models?
Expand All @@ -179,12 +179,12 @@ Technically all these views are Morph instances representing the underneath mode

**---JR**: We are speaking of free resources, so we have their source and the rights to use and modify them. Doesn't the answer to your question depend of the familiarity of the user with the programming language or scripts, or on the existence of high level tools to create and modify the simulations? If we took this statistic point of view, would the fact that more teachers use python or javascript than smalltalk prove anything? And as a second point, do we really expect the teachers to create the resources? Isn't it enough to reuse, mix, adapt,assess... free available educational resources? Are the ones available so bad, so insufficient? And the educational institutions and volunteers have been creating resources for more than twenty years? Are they useless and have always been so?

**---HF**: So we will not know if PhET instances are models or just user applications... In dynamic knowledge model, the meaning of model must be understood clearly. A Model is an object or group of objects created and manipulated through a set of programming instructions in the context of a dedicated [DSL](https://rmod-files.lille.inria.fr/Team/Presentations/2010-DSL-Choose-Ducasse.pdf), in a live environment the experience is even easier. Access to the source and right is one thing, the ability to modify the source to achieve a different result in the context of real use case is a completely different thing. There is a huge barrier in concept, knowledge and accessibility between the two, even if you have access to the source. In the Dynabook app I want to lower this barrier as much as possible, to give maximum freedom to the user to study, to learn and to modify. Smalltalk is ontologically designed with this very specific intention, to empower user. This is something that is hardly done with JS or Python, there are short is some conceptual and technical areas as pure OOP, partial compiling of object, environment with "live" entities to interact with. When you know one programming language, learning another is not an issue.
I don't understand your questions regarding existing free resources, your tone seems to indicate I discard them. Not at all, I see no reason they can't be used in the context of the Dynabook. I am describing what is a dynamic knowledge model and I choose to implement the Dynabook App in Smalltalk and not js+css+html because the later is terrible to manage complexity, although it benefits of the awesome job done by corporate like Google on the JavaScript VM regarding efficiency in execution (https://v8.dev).
**---HF**: So we will not know if PhET instances are models or just user applications... In dynamic knowledge model, the meaning of model must be understood clearly. A *Model* is an object or group of objects created and manipulated through a set of programming instructions in the context of a dedicated *DSL*, in a live environment the experience is even easier. Access to the source and rights is one thing, the ability to modify the source to achieve a different result in the context of real use case is a completely different thing. There is a huge barrier in concept, knowledge and accessibility between the two, even if you have access to the source. In the Dynabook app I want to lower this barrier as much as possible, to give maximum freedom to the user to study, to learn and to modify. Smalltalk is ontologically designed with this very specific intention, to empower users. This is something that is hardly done with JS or Python, they are short is some conceptual and technical areas as pure OOP, partial compiling of objects, environment with "live" entities to interact with. When you know one programming language, learning another is not an issue.
I don't understand your questions regarding existing free resources, your tone seems to indicate I discard them. Not at all, I see no reason they can't be used in the context of the Dynabook. I am describing what is a dynamic knowledge model and I choose to implement the Dynabook App in Smalltalk and not js+css+html because the latter is terrible to manage complexity, although it benefits of the awesome job done by corporations like Google on the JavaScript VM regarding efficiency in execution (https://v8.dev).

**---JR**: Then an easy question for you to answer: why the **Cuis environment**? I know you fell in love with Smalltalk many years ago, but explain why not you as a developer but the end user should prefer the developers use Cuis over javascript plus html5 plus css.

**---HF**: First, I don't fall in love with programming language, I use the right tool to achieve what I want to do. Smalltalk let me handle the complexity far more easier that C++, the previous language DrGeo was code with. You can search the literature why. The user has no preference regarding the developer environment as long as he does not need to operate directly on the engine, in the contrary Smalltalk is more developer friendly.
**---HF**: First, I don't fall in love with programming languages, I use the right tool to achieve what I want to do. Smalltalk let me handle the complexity far more easier that C++, the previous language DrGeo was coded with. You can search the literature why. The user has no preference regarding the developer environment as long as he does not need to operate directly on the engine, in the contrary Smalltalk is more developer friendly.

**---JR**: Is your project multiplatform? Does in run on Windows, Linux, Android, containers, usb drive...?

Expand Down

0 comments on commit 4646f91

Please sign in to comment.