Black Box? Logout | Themen | Suche
Moderatoren | Registrieren | Profil

EUKLID DynaGeo Forum » Forum für Benutzerfragen » Black Box? « Zurück Weiter »

Autor Beitrag
 

Hans-Jürgen Elschenbroich (Hje)
Veröffentlicht am Dienstag, 02. Mai 2006 - 22:26 Uhr:   

Hallo.

In CAS gibt es ja seid Langem das Konzept black box - white box.

Makros bei DGS haben dazu große Parallelen.
Bei mir lief folgende Frage auf, auf die ich die u.a. Antwort hatte, die ich aber wenig befriedigend fand.
Das ist eine Sache, die mich früher auch schon gestört hatte, dass Makro-Befehle im Dynageo-Konstruktionstext nicht als solche auftauchen und dadurch das Vorgehen erheblich undurchsichtiger machen.

Frage an die User: stört das andere auch?

Frage an den Programmierer: lässt sich das mit sinnvollem Aufwand ändern?

Dann könnte man nämlich nicht nur von der white box zur black box gehen (= das Programmieren von Makros) sondern auch umgekehrt, Schüler ein Makro "ach-wie-gut-dass-niemand-weiss" vorsetzen und herausfinden lassen, was das eigentlich so macht.

Tschüss
Hans-Jürgen Elschenbroich

+++++


> > oder wie man in euklid black boxes erzeugen kann, die die
> > schülerinnen nicht 'weißen' können, z.b. höhenschnittpunkt.
>
> Hm. Ich weiß nicht, ob ich das recht verstanden habe.
> Man kann Makros definieren. Auf der Benutzeroberfläche
> scheint das eine Black Box zu sein.
> Aber das ist keine wirkliche Black Box, sondern eher eine
> Gray Box, weil man im Konstruktionstext nicht nur den
> Makro-Befehl sieht, sondern alle Konstruktionsbefehle das Makros.
 

Hans-Jürgen Elschenbroich (Hje)
Veröffentlicht am Dienstag, 02. Mai 2006 - 22:50 Uhr:   

Ergänzung:

Mit dem Wunsch, die einzelnen Befehle des Makros nicht im Konstruktionstext sehen zu können, korrespondiert natürlich der Wunsch, die entsprechenden Objekte nicht als verdeckte Linien vorliegen zu haben und sichtbar machen zu können.

Das bezieht sich auf einen Artikel von Christine Knipping über "Schwarze Kisten" mit Cabri II im Buch Computer, Internet & Co (Barzel, Hußmann, Leuders).
 

Roland Mechling (Mechling)
Veröffentlicht am Freitag, 05. Mai 2006 - 12:44 Uhr:   

Dass die Anregung von Herrn Elschenbroich bisher keine Resonanz gefunden hat, könnte man als Indiz dafür werten, dass die wenigsten der DynaGeo-Benutzer im Alltag gar zu viel mit Makros in Kontakt kommen. So geht es im übrigen auch mir: wenn ich denn DynaGeo überhaupt mal in meinem Unterricht einsetze, dann meist in solchen Kontexten, bei denen nur die elementaren Programmfunktionen eine Rolle spielen. Makros kommen da eher selten vor.

Als Programmautor bin ich jedoch weniger für die Beurteilung des didaktischen Nutzens einer solchen Erweiterung zuständig als für die Abschätzung des Aufwandes, der dafür zu betreiben wäre. Nach einigem Nachdenken über die Idee wäre meiner Einschätzung nach dafür Folgendes nötig:
  • Es müsste eine weitere Sichtbarkeits-Variante geschaffen werden, die etwa "strikte Unsichtbarkeit" genannt werden könnte.
  • Die interne Objektliste müsste in ihrer Datenstruktur erweitert werden, so dass sie nun auch Informationen über die "Erzeugungsgeschichte" der Objekte speichern kann. Mindestens wären dazu zwei neue "Meta-Objekte" nötig, die den Makro-Anfang (eventuell mit den übergebenen Startobjekten) und das Makro-Ende (nach dem letzten erzeugten Zielobjekt) markierten. Aus technischen Gründen muss die Objektliste nach wie vor die Makro-Zwischen-Objekte enthalten, aber diese müssten als "strikt unsichtbar gekennzeichnet werden.
  • Die Generierung der Konstruktionsbeschreibung müsste entsprechend geändert werden, - was das geringste Problem wäre.
  • Dem Benutzer muss die Möglichkeit gegeben werden, zwischen dem (jetzigen) "White/Gray-Box-Modus" und dem (neuen) "Black-Box-Modus" umzuschalten. Dabei muss noch entschieden werden, ob diese Umschaltung global für die ganze Zeichnung gelten soll oder nur für das aktuelle Makro, und im letzteren Falle, ob zur Design-Zeit oder zur Laufzeit des Makros entschieden werden soll. All dies hat heftige Auswirkungen auf die Benutzer-Oberfläche.

Angesichts dieses doch erheblichen Aufwandes bin ich etwas skeptisch, ob sich eine solche Erweiterung lohnen würde. Und alle, die noch (wie ich!) von einer editierbaren Konstruktions-Beschreibung träumen, sollten sich darüber im Klaren sein, dass die Implementierung von "Black-Box-Makros" diese Entwicklungs-Möglichkeit in weite Ferne rücken ließe!

Mit freundlichem Gruß
Roland Mechling.
 

Hans-Jürgen Elschenbroich (Hje)
Veröffentlicht am Freitag, 05. Mai 2006 - 22:35 Uhr:   

Hallo.

Ich will da auch nicht drauf insistieren.
Das war halt als Frage im Vergleich zu Cabri an mich herangetragen worden, resultierend aus dem Artikel von Frau Knipping.

Wenn ich vor der Wahl stehe, nehme ich natürlich die editierbare Konstruktionsbeschreibung ...

Aber in dem Zusammenhang nochmal gefragt: Wäre es dafür nicht auch sinnvoll, nur den Makro-Befehl in der Konstruktionsbeschreibung zu haben und nicht der Reihe nach all die Befehle, aus denen das Makro gebaut ist?

Tschüss
Hans-Jürgen Elschenbroich
 

Roland Mechling (Mechling)
Veröffentlicht am Sonntag, 07. Mai 2006 - 09:06 Uhr:   

Hm, mir schwebte eine Lösung vor, in der lediglich die derzeitig verfügbare Konstruktionsbeschreibung editierbar werden sollte, mithin auf eine Spezialbehandlung von Makros - zumindest zunächst - verzichtet wird. Strukturell sind Makros wohl Funktionen, und es ist sicher um einiges komplexer, einen Compiler für Konstruktionsbeschreibungen zu bauen, der auch gleich noch ein Funktionskonzept implementiert, als einen, der halt brav Zeile für Zeile ein Objekt erzeugt. Die von Ihnen gewünschte Variante läuft auf eine "Programmiersprache für Geometrie" hinaus, und es ist die Frage, wie viele Benutzer die dann auch wirklich (ge)brauchen werden.

Je länger ich aber über diese Sache nachdenke, desto mehr beschleicht mich das Gefühl, dass Sie doch recht haben - was aber in diesem Fall die Sache nicht gerade beschleunigen wird ;-) Ehe ich mich solch neuen Ufern zuwende, müssen erst mal die derzeit schon auf meiner TO-DO-Liste aufgelaufenen Ziele erreicht werden, und da gibt's wahrlich noch einiges zu tun!

Mit freundlichem Gruß
Roland Mechling.
 

Hans-Jürgen Elschenbroich (Hje)
Veröffentlicht am Sonntag, 07. Mai 2006 - 11:28 Uhr:   

> Die von Ihnen gewünschte Variante läuft auf eine "Programmiersprache für Geometrie" hinaus,

Hallo!

Natürlich! Das gibt es ja spätestens seit KOBESCH-Zeiten.
Ich erzähle auch immer in meinen WS, dass das, was man auf der DGS-Oberfläche mit den Mausklicks macht, letztendlich geometrisches Programmieren ist.


> und es ist die Frage, wie viele Benutzer die dann auch wirklich (ge)brauchen werden.

Ja sicher, das ist die Frage. Weiß man's vorher?
Ich glaube nicht, dass sich das Nutzerverhalten eingefleischter Dynageo-User abrupt ändern wird.

Aber ich weiß aus früheren Zeiten von Geolog, dass der leise vorhandene Programmieraspekt (das ging ja alles linear, ohne Schleifen und Rekursionen) als moderne und sinnvolle Fassung der Konstruktionsbeschreibung durchaus geschätzt wurde und weiß das von GeoGebra-Nutzern auch.

Statt der umstrittenen Konstruktionsbeschreibung im Nachhinein ein Konstruktionsprogramm (parallel oder im Voraus, je nach Situation), das gibt Sinn.

Auch hier wäre eine Absprache unter DGS-Programmierern, was man jetzt wie bezeichnet, ein Riesenfortschritt.


> mir schwebte eine Lösung vor, in der lediglich die derzeitig verfügbare Konstruktionsbeschreibung editierbar werden sollte

Ist ja ok, ist doch ein guter Anfang. Wenn man eine Erweiterung auf Makros in dem Sinne direkt mitdenken kann, wäre für die Zukunft ja auch nichts verbaut.

Tschüss
Hans-Jürgen Elschenbroich

Beitrag verfassen
Beitrag:
Benutzername: Hinweis:
Dies ist ein geschützter Bereich, in dem ausschliesslich registrierte Benutzer Beiträge veröffentlichen können.
Kennwort:
Optionen: HTML-Code anzeigen
URLs innerhalb des Beitrags aktivieren
Auswahl: