[Cuis-dev] About complexity in the face of the user

[Juan Vuletich]

Hi Hilaire,

On 3/17/2024 7:33 AM, Hilaire Fernandes via Cuis-dev wrote:
>
> Hi folks,
>
> Some thinking related to a recurring issue I have with end-user edited 
> Smalltalk sketch script, particularly when debugging.
>
> For the record, in DrGeo a user can design interactive geometric 
> sketch with mouse and clic operation. There is also the possibility 
> for the user to design such script with programming instruction. It is 
> a way of doing part of the DrGeo genome since its early development.
>
> When DrGeo was coded in C++, scripts were written in Scheme, an 
> Italian teacher wrote some contents about it[1]. When porting to 
> Squeak, I was hoping to describe script with Etoys, to be honest it is 
> the main reason I ported from C++ to Squeak then. So I started to add 
> Etoys tile to control DrGeo points, but I did not have the time to go 
> far enough[2], then Etoys long term visibility was in question.
>
> *At some point we should have a tile framework for Cuis for general 
> use in end user scripting.
> *
>
> While tile are nice, it has a tendency to not be very compact, but it 
> could be fixed with tile representing more high level concept.
>
> Anyway, when editing script, at some point the user has to deal with 
> complexity when debugging its script. It is true with Scheme and 
> Smalltalk, with C++ version of Squeak, Etoys, Pharo and Cuis version 
> of DrGeo
>
> Adele Goldberg, at her June 2022 talk for Camp Smalltalk 50th 
> Anniversary, insisted a lot, at several moment, in how a system with a 
> perspective of educating should be able to present meaningful information:
>
>
>     /*The Simulation Kit*
>     An important point made by our teaching experience is that,
>     because we expect the learner to
>     extend a model through programming new methods, not just by
>     parameter modification, it is
>     critical that some outcome that the learner mistakenly creates
>     does not get explained using
>     vocabulary outside of what has been already been introduced.
>     The obvious example from the Smalltalk system itself is its class
>     browser and the debugger.
>     *Imagine you are creating a weather forecasting model and an error
>     occurs in execution. But
>     instead of seeing the error at the level of weather activity and
>     the buttons and dials of the weather
>     station, you see a bug in how text is displayed on the screen,
>     thereby introducing an underlying
>     part of the modeling environment that you have not yet learned
>     about (and maybe do not want to
>     learn about!). Certainly, dealing with an error outside of a kit
>     is a distraction, potentially
>     defocusing the learner’s modeling intentions.*/
>
>
> You can read her full presentation "Smalltalk research through the 
> eyes of an educational mission"[3].  Her speeches and writing are 
> always pleasant to read with actionable ideas.
>
> What Adele describes are the challenges I am facing in DrGeo end user 
> scripting. The extended model is the interactive geometry model of Dr. 
> Geo.
>
> ...
>
> [1] 
> https://www.matematicamente.it/staticfiles/software_math/dr_geo/schemedrgeo.pdf
> [2] https://inria.hal.science/inria-00531636v1
> [3] https://drive.google.com/file/d/15vUiDzClBMAN8931bWe7O9oYHtNMzoQG/view
>
>
> -- 
> GNU Dr. Geo
> http://gnu.org/s/dr-geo/
> http://gnu-drgeo.blogspot.com/

I understand and agree with what Adele says. I guess that a possible 
approach could be to limit the Smalltalk debugger to code in the 
"extended model" or "kit", and don't open it or encourage its use if the 
error is unrelated.

You suggest a different approach: To switch to a different programming 
language. The first question that comes to my mind is: how do Scratch 
and other tile programming environments handle debugging?

Thanks,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240318/9f23a888/attachment.htm>