Benutzer Diskussion:FUZxxl

Diese Benutzerdiskussionsseite dient der persönlichen Kommunikation mit dem Benutzer FUZxxl.

Wenn du mich hier ansprichst, antworte ich auch auf dieser Seite. Wenn ich dich auf einer anderen Seite angesprochen habe, antworte bitte auch dort!

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

Hinweise

• Diskutiere bitte sachlich und freundlich!
• Greife niemanden persönlich an!
• Gehe von guten Absichten aus.
• Bitte beachte die Diskussionsregeln und die
• Hilfen zu Diskussionsseiten und
• Benutzerdiskussionsseiten!

Automatische Archivierung

Auf dieser Seite werden Abschnitte morgens automatisch archiviert, deren jüngster Beitrag mehr als 30 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte.

Zum Archiv

Wie wird ein Archiv angelegt?

Klammern dienen der Verständlichkeit für des Haskell nicht mächtiger Leser.

Danke für deinen Revert. Nur, wer – wie ich – kein Haskell kann, dem helfen die Klammern leider auch nicht, die Beispiele im Artikel Monade (Informatik) zu verstehen. Darauf hatte ich auf der DS auch schon hingewiesen, aber leider hat sich daran bisher wenig geändert. Vielleicht magst du da ja mal was dran ändern? *lieb guck* --RokerHRO (Diskussion) 10:22, 9. Mär. 2015 (CET)

Hm... Ich schau mal, was sich da machen lässt. Monaden sind generell ein eher fortgeschrittenes Thema und ich halte es für unsinnig den Artikel für Leute zu schreiben, die noch nie etwas von Typtheorie gehört haben bzw. nicht verstehen was Typen höherer Ordnung sind, eher sollte man betreffende Artikel erweitern. Das Thema Monaden wird zwei mal in der deutschen Wikipedia erklärt: Einmal aus der mathematischen Perspektive (im Typtheorie-Artikel) und einmal aus der Perspektive der Programmierung. Wenn ich in letzterem Artikel mathematische Notation anwende, dann mache ich ersteren redundant. Ich kann villeicht eine Beschreibung des Haskell-Codes in Prosa anbringen, ich bin mir aber nicht sicher, wie viel das bringt. Hast du Ideen dazu? --FUZxxl^D|M|B 15:06, 9. Mär. 2015 (CET)

Naja, ganz ohne Redundanzen wird es wohl nicht gehen. Aber wenn zum Verstehen von Monaden erstmal ein Mathestudium braucht (um den Artikel Typtheorie zu verstehen), dann ist das zu viel verlangt. (Vielleicht kann man ja den Artikel Typtheorie auch mal um 1…2 verständliche Beispiele anreichern, damit man eine Ahnung bekommt, um was es da überhaupt geht. Mir ist das beim Querlesen nämlich nicht klargeworden. ;-()

Vielleicht kann man ja auch den Teil der Typtheorie, den man braucht, um Monaden zu verstehen, eben in 1..2 Sätzen erklären?

Eine andere Syntax würde bestimmt helfen. Sei es in "Prosa" oder in einer verbreiteteren Programmiersprache wie z.B. C++ oder Java. Ein C++- oder Java-Programmierer sollte verstehen, wie man z.B. von einem Typ T zu einem Typ Nullable<T> kommt, wie ich auf der DS auch schon anmerkte.

--RokerHRO (Diskussion) 15:55, 9. Mär. 2015 (CET)

Die Syntax von Java oder C++ ist gänzlich ungeeignet zur Betrachtung typtheoretischer Konstrukte wie Monaden. Ich kann mir vorstellen, mehr konkrete Beispiele einzubauen, aber eigentlich sind da schon jede Menge. Es ist wirklich nicht einfach, das besser verständlich zu machen. --FUZxxl^D|M|B 17:00, 9. Mär. 2015 (CET)

Naja, unmöglich ist es nicht, Java o.ä. zu verwenden. Hier mal die Continuation-Monade für das Resultat (), in Java 8. (Consumer ist in der Standardbibliothek als Funktion nach void festgelegt).

@FunctionalInterface
public interface Observable<A> extends Consumer<Consumer<A>>  {
	
	static <A> Observable<A> of(A a) {
		return ac -> ac.accept(a);
	}
	
	default <B> Observable<B> map(Function<A,B> f) {
		return bc -> accept(a -> bc.accept(f.apply(a)));
	}
	
	default <B> Observable<B> flatMap(Function<A,Observable<B>> f) {
		return bc -> accept(a -> f.apply(a).accept(bc));
	}
	
	default Observable<A> filter(Predicate<A> p) {
		return ac -> accept(a -> { if (p.test(a)) ac.accept(a); } );
	}
}

Das wichtigste, was Java und Konsorten für einen supersinnvollen Einsatz fehlt, ist die Möglichkeit, über Typkonstruktoren zu abstrahieren, das hat aber nicht viel mit Syntax zu tun. --Daniel5Ko (Diskussion) 17:14, 9. Mär. 2015 (CET)

Dein Beispiel zeigt gerade sehr gut warum die Syntax ungeeignet ist. Extrem langer Code dessen Funktion nicht offensichtlich ist, dessen Typen schwer verständlich sind und überflüssige Bestandteile, die nur dazu dienen irgendwelchen extra Kram von Consumer zu unterstützen. Viel Spaß im Artikel nochmal zu erklären, was Function, Predicate, und Observable eigentlich sind. Nebenbei bemerke man die eigentümliche Namenskonvention, die von der gewöhnlichen, in der Mathematik genutzten Konvention abweicht und gesondert erklärt werden muss. --FUZxxl^D|M|B 17:27, 9. Mär. 2015 (CET)

Da ist kein wirklicher Extra-Kram. Predicate, Function und Consumer sind alles nur Funktionstypen (a->Bool, a->b, a->(), aber mit erlaubten Seiteneffekten) mit "eingängigen" Namen,

bei denen die Applikation auch noch jeweils speziell heißt (test,apply,accept respektive). Java-Programmierer finden das ganz bestimmt total in Ordnung. Observable ist nur Name für die Continuation, die ich da gerade definiert habe -- mit einer bestimmten Anwendung im Hinterkopf, die aber eigentlich keine Rolle spielt. --Daniel5Ko (Diskussion) 18:09, 9. Mär. 2015 (CET)

Es gibt jede Menge Zeug was du gerade eben erwähnt hast, dass man verstehen muss (über das, was man für das Verständnis des Haskell-Codes verstehen muss hinaus) um diesen Code lesen zu können. Zugegebenerweise, ich bin kein Java-Programmierer (habe die Sprache nur für die Schule gelernt und einfache Dinge darin programmiert), aber meinst du wirklich das verbessert die Verständlichkeit? Ich finde nicht, dass man eine Vertrautheit mit der Java-Standardbibliothek voraussetzen sollte. --FUZxxl^D|M|B 18:23, 9. Mär. 2015 (CET)

Ich bin nicht sicher, ob das die Verständlichkeit verbessert. Das muss RokerHRO beurteilen. Ich wollte hauptsächlich erstmal "Die Syntax von Java oder C++ ist gänzlich ungeeignet[...]" widersprechen. Aufgrund der (wenn man eine Monad-Instanz angeben will) notwendigen newtype-Wrapper sieht Haskell-Code für Continuations m.E. übrigens auch nicht sehr viel besser aus und besteht gefühlt nur aus diesen. --Daniel5Ko (Diskussion) 18:28, 9. Mär. 2015 (CET)

Puh, danke für eure Mühen! :-)

Also ich kann das Java-Beispiel auch nicht gerade „auf einem Blick erfassen/verstehen“, da ich mit der Syntax für Lambda-Ausdrücke in Java 8 noch nicht wirklich vertraut bin. In dem Code scheint mir zudem viel Boilerplate-Code mit drin zu sein, der in Java wohl nötig ist, oder? Wieso die eine Methode static ist und die anderen default verwirrt mich z.B. gerade.

Aber ich verstehe halt immernoch nicht, was der Code macht, erst recht nicht, wie er das macht. Ich kennte zwar "predicate" und std::function in C++, aber die Transferleistung zu Java krieg ich heute Abend zumindest nicht mehr hin. Ich steige schon in Zeile 5 aus, wo ich nicht weiß, was ac ist.

Scheint also wirklich schwieriger zu sein, als ich dachte. :-( --RokerHRO (Diskussion) 23:05, 9. Mär. 2015 (CET)

@Boilerplate: Sei froh, dass das Java 8 ist. :D In Java 7 hätten die Methoden eher 5 oder 7 Zeilen statt einer.

Für ein allererstes Beispiel sind Continuations sowieso nicht geeignet. Ich wollte nur mal ein nicht-triviales Code-Beispiel geben, das nicht zu lang ist.

Trotzdem ein paar Entschlüsselrungshilfen:

• Consumer sieht im wesentlichen so aus: interface Consumer<A> { void accept(A a); },
• Daher hat Observable<A> die abstrakte Methode void accept(Consumer<A>);, die hier nicht explizit erwähnt wird. (Semantischer Hintergedanke: die Consumer, die hierüber ankommen, sind Listener, die direkt bei Ankunft oder später ein oder mehrere oder gar keine "Ereignisse" vom Typ A gemeldet bekommen, indem deren accept aufgerufen wird.)
• ac,bc stehen für A-Consumer und B-Consumer.
• Die werden in allen 4 Methoden als formale Parameter eines Lambda-Ausdrucks eingeführt, und dieser wird zur accept-Methode des Observable<X>-Objekts, das zurückgegeben wird.
• default-Methoden sind dafür da, dass alle Klassen, die ein Interface implementieren, diese Methoden auch sofort haben.
• Dass of statisch sein muss, ist klar: wir haben ja an der Stelle, wo wir aus irgendeinem Wert ein Observable machen wollen, noch kein Observable. Hier wird das umliegende Interface lediglich als Namensraum benutzt. Virtualität in irgendeiner Form liegt hier nicht vor.

--Daniel5Ko (Diskussion) 10:09, 10. Mär. 2015 (CET)

Jugend-Foto-Workshop im Juni

Hallo,

ich schreibe dich an, weil ich dich als unter 25-jährige Person auf der Geburtstagsliste der Wikipedia gefunden habe und wir (Wikimedia Deutschland e. V.) Anfang Juni einen Foto-Workshop für unter 25-Jährige anbieten.

Dieser wird als Beitrag zum Europäischen Jahr des Kulturerbes „Sharing Heritage“ veranstaltet. WMDE bietet – neben anderen Workshops zum Denkmalschutz – einen Workshop an, der sich explizit an junge Menschen richtet (unter 25 Jahren). In diesem Workshop kannst du mit anderen interessierten jungen Wikipedianern und manchen, die es erst noch werden wollen, von professionellen Referenten lernen, wie du super Fotos von denkmalgeschützten Objekten machen kannst und diese auch gleich für den Fotowettbewerb Wiki Loves Monuments in Deutschland (WLM) einsetzen kannst. Bring einfach deine eigenes Equipment mit: Von der kleinen Digi-Knipse über das Smartphone bis hin zur Spiegelreflexkamera, mit allen können gute Fotos für Wikimedia Commons gemacht werden.

Dir hat das Spaß gemacht und du willst mit anderen zusammen ebenfalls auf Fototour gehen? Dafür besprechen wir zum Schluss des Workshops gemeinsam miteinander, wie solch eine Veranstaltung auch bei dir um die Ecke einfach organisiert werden kann.

Wenn das was für dich ist oder du Freunde im Umkreis hast, für die die Veranstaltung spannend sein könnten, trage dich gerne auf der Projektseite ein.

Wir freuen uns!

CDRTools

Wo kann man denn die Version 3.02 der "volunteers" finden? Trotz längerer Suche konnte ich nur die Version im Rahmen der schily-tools vom 2021-09-18 ausfindig machen. Ggf. wäre es sinnvoll, einen entsprechenden Hinweis zu ergänzen, bspw. einfach die Versionsnummer 3.02 mit der entsprechenden Quelle zu verlinken. --109.73.24.2 11:47, 28. Mär. 2023 (CEST)

Moin, cdrtools wird als Teil der schilytools auf Codeberg weiterentwickelt. Dort haben wir in eine kürzlichen Release (müsste 2022-09-18 gewesen sein) die Versionsnummer ohne weitere Änderungen auf 3.02 gesetzt, um das Ende der Schaffensperiode von Jörg zu definieren. Ich dachte, ich hätte das bereits irgendwo mal verlinkt. --FUZxxl^D|M|B 01:44, 29. Mär. 2023 (CEST)