<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Hilaire, On 3/17/2024 7:33 AM, Hilaire Fernandes via Cuis-dev wrote: <blockquote cite="mid:097afbb8-7342-4e56-8eed-1715a2afc7be@free.fr" type="cite"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> 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: <div align="justify"> <blockquote> 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. </blockquote> </div> 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] <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.matematicamente.it/staticfiles/software_math/dr_geo/schemedrgeo.pdf">https://www.matematicamente.it/staticfiles/software_math/dr_geo/schemedrgeo.pdf</a> [2] <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://inria.hal.science/inria-00531636v1">https://inria.hal.science/inria-00531636v1</a> [3] <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://drive.google.com/file/d/15vUiDzClBMAN8931bWe7O9oYHtNMzoQG/view">https://drive.google.com/file/d/15vUiDzClBMAN8931bWe7O9oYHtNMzoQG/view</a> <pre class="moz-signature" cols="72">-- GNU Dr. Geo <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://gnu.org/s/dr-geo/">http://gnu.org/s/dr-geo/</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://gnu-drgeo.blogspot.com/">http://gnu-drgeo.blogspot.com/</a></pre> </blockquote> 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, <pre class="moz-signature" cols="72">-- 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</pre> </body> </html>