Interessensabfrage: Wer will RegExps lernen?

[TRex]

Wir können auch mit Automaten und BNFs anfangen, falls jemandem regex zu praxisnah ist

[eggy]

Den Weg über die Automaten und Reduktion halte ich für grundsätzlich für nen guten Ansatz.
Das Grundverständnis dort macht's, meiner Erfahrung nach, sehr viel einfacher, wenn's mal richtig kompliziert wird.

Ich hab Meillo aber so verstanden, dass es ihm lieber wäre, das von der praktischen Seite her aufzubauen.
Ist meiner Meinung nach auch nen guter Ansatz, weil die meisten Fälle, auf die man anfangs in der Praxis stößt, recht übersichtlich sind.

Wir können den theoretischen Teil dann auch gerne im Anschluss/parallel durchgehen. Falls es überhaupt jemanden interessiert

[Meillo]

Genau wie eggy schreibt: Die harte Theorie kommt anschliessend.

Mir ist es wichtig, niemanden abzuhaengen, darum verzichte ich so gut es geht auf einen theorielastigen Eindruck, der viele abschrecken duerfte. Gleichzeitig will ich auch nicht nur Praxisbeispiele bringen, weil man, und da stimme ich euch zu, REs nur verstehen kann wenn man sie eben versteht. Bloss ist mein Ziel, dieses Verstehen nicht aus der Sprachtheorie sondern aus ganz normalem nachvollziehbarem Denken heraus zu erzeugen. Mal sehen wie das klappen wird.

Ich bin schon voll gespannt auf das Experiment. Morgen geht's los!

[buhtz]

Da ich scheinbar der Auslöser oder der besagte letzte Tropfen war, der das Thema zum anlaufen brauchte, muss ich mich doch auch mal äußern.

Erst einmal Danke.

So eine Session hier im Forum habe ich noch nie mitgemacht und habe daher keiner genaue Vorstellung. Inhaltlich würde ich mir aber wünschen, etwas zu lernen, was ich eben nicht in Tutorials, Blog-Posts und YouTube Videos selbst nachlesen kann. Es geht eben doch ein bisschen um die Theorie; das große Bild dahinter. Was haben sich die RegEx ErfinderInnen dabei gedacht?

Ein ganz praktisches Problem: RegEx im Code (z.B. Python) reduziert dessen Verständlichkeit und daher auch Wartbarkeit. Das Argument, solcher Code sei wartbarer, weil er kürzer ist, als konventioneller Code, lass ich nicht gelten. Kurz ist nicht gleich wartbarer; schließt das aber auch nicht aus. Auch langer Code ist wartbar, solange er eben ordentlich strukturiert und gekapselt ist. Zurück zum Problem, dass RegEx auf den ersten Blick nicht lesbar und verständlich ist. Nicht jeder kann RegEx, wie wir hier wissen. Sogar die Entwickler, die RegEx in ihrem eigene Code nutzen, können dir nächste Woche schon nicht mehr sagen, was das soll und tut.
Die praktische Frage ist also, wie man Code mit RegEx ordentlich dokumentiert. Wie beschreibt man, z.B. in einem Kommentar / Doc-String, was das RegEx Pattern tut? Gibt es dafür evtl. sogar eine Guideline?

[eggy]

Sogar die Entwickler, die RegEx in ihrem eigene Code nutzen, können dir nächste Woche schon nicht mehr sagen, was das soll und tut.

"Was das tut": ganz einfach: GENAU das, was da steht .

"Was das soll": Semantik. Die Intention etwas zu tun, steckt nur im Kopf des Entwicklers. Das in unmissverständliche Worte zu bringen, ist oftmals schwierig, und kann nur derjenige machen, der sich den jeweiligen RegEx ausgedacht hat. Denn, ob nen vermeintlicher Edgecase vergessen wurde oder absichtlich nicht gesondert behandelt wird, kann kein anderer wissen.

Wie man RegExe wieder "menschenlesbar" macht? In Gruppen zerlegen und Stückweise aufdröseln. Wie? Im einfachen Fall Draufsehen, in komplexen Fällen über Automaten und Tabellen. Mehr dazu im Theorieteil.

[thoerb]

Ein ganz praktisches Problem: RegEx im Code (z.B. Python) reduziert dessen Verständlichkeit und daher auch Wartbarkeit. Das Argument, solcher Code sei wartbarer, weil er kürzer ist, als konventioneller Code, lass ich nicht gelten.

Der Reguläre Ausdruck hat ja eigentlich mit dem Programmcode nichts zu tun, sondern ist ein Suchmuster. Man kann auch beides voneinander trennen, in dem man den Regulären Ausdruck in einer Variable speichert. Das macht es dann wieder übersichtlicher.

[Meillo]

So eine Session hier im Forum habe ich noch nie mitgemacht und habe daher keiner genaue Vorstellung. Inhaltlich würde ich mir aber wünschen, etwas zu lernen, was ich eben nicht in Tutorials, Blog-Posts und YouTube Videos selbst nachlesen kann. Es geht eben doch ein bisschen um die Theorie; das große Bild dahinter. Was haben sich die RegEx ErfinderInnen dabei gedacht?

Das groessere Bild dahinter will ich auch vermitteln -- das passt also gut zusammen.

Was du hier im DFDE bekommst, was ueber Materialien im Internet hinaus geht, ist die Moeglichkeit zu interagieren und die Inhalte fuer dich passend mitzugestalten.

Zudem denke ich, dass meine Herangehensweise eine etwas andere ist als sie zumeist im Internet zu finden ist. Ich hoffe, dass sie den Zugang zu REs erleichtert.

Fuer den Anfang habe ich inzwischen einen Plan, um die Grundlagen aufzubauen. Dann werde ich die Wuensche in diesem Thread abarbeiten. eggy traegt die richtige Theorie bei. Und sicherlich werden sich auch noch weitere User finden, die jeweils etwas ueber ihre jeweilige Lieblingsprogrammiersprache beisteuern koennen. An der Stelle beginnt dann das Wunschkonzert.

Auch fuer Themen wie das folgende, das sich ja eher um Stil, Konventionen und Erfahrungen dreht und nur zu einem Teil direkt mit REs zu tun hat, sondern mehr eine generelle Frage zu fortgeschrittenen Programmiertechniken und die Dokumentation von eher kryptischem Code ist, wird dann Raum sein. Ich werde das spaeter aufgreifen.

Ein ganz praktisches Problem: RegEx im Code (z.B. Python) reduziert dessen Verständlichkeit und daher auch Wartbarkeit. Das Argument, solcher Code sei wartbarer, weil er kürzer ist, als konventioneller Code, lass ich nicht gelten. Kurz ist nicht gleich wartbarer; schließt das aber auch nicht aus. Auch langer Code ist wartbar, solange er eben ordentlich strukturiert und gekapselt ist. Zurück zum Problem, dass RegEx auf den ersten Blick nicht lesbar und verständlich ist. Nicht jeder kann RegEx, wie wir hier wissen. Sogar die Entwickler, die RegEx in ihrem eigene Code nutzen, können dir nächste Woche schon nicht mehr sagen, was das soll und tut.
Die praktische Frage ist also, wie man Code mit RegEx ordentlich dokumentiert. Wie beschreibt man, z.B. in einem Kommentar / Doc-String, was das RegEx Pattern tut? Gibt es dafür evtl. sogar eine Guideline?

Ich freue mich natuerlich, dass du dabei bist ... und ja, du hast ganz recht: Da du gewissermassen der Ausloeser warst, bist du nun gewissermassen auch in der Pflicht, vorbildlich aktiv mitzuarbeiten.

[TRex]

Sogar die Entwickler, die RegEx in ihrem eigene Code nutzen, können dir nächste Woche schon nicht mehr sagen, was das soll und tut.

Oh doch, mit dem genannten Trick und natürlich Erfahrung, um die Ausdrücke schneller zu lesen.

Wie man RegExe wieder "menschenlesbar" macht? In Gruppen zerlegen und Stückweise aufdröseln. Wie? Im einfachen Fall Draufsehen, in komplexen Fällen über Automaten und Tabellen. Mehr dazu im Theorieteil.

Genau. Das Gruppieren kannst du schon beim Schreiben machen, und das lohnt sich sehr oft bei mittelmäßig komplexen Ausdrücken bereits. Also nicht nur den String vierteilen, sondern tatsächlich benannte "Gruppen" nutzen.

[Meillo]

Wie man RegExe wieder "menschenlesbar" macht? In Gruppen zerlegen und Stückweise aufdröseln. Wie? Im einfachen Fall Draufsehen, in komplexen Fällen über Automaten und Tabellen. Mehr dazu im Theorieteil.

Genau. Das Gruppieren kannst du schon beim Schreiben machen, und das lohnt sich sehr oft bei mittelmäßig komplexen Ausdrücken bereits. Also nicht nur den String vierteilen, sondern tatsächlich benannte "Gruppen" nutzen.

Klasse! Der Dino meldet sich (mit seinen kurzen Aermchen) fuer eine Kurseinheit zu dem Thema im spaeteren Verlauf der Veranstaltung.

[buhtz]

Sogar die Entwickler, die RegEx in ihrem eigene Code nutzen, können dir nächste Woche schon nicht mehr sagen, was das soll und tut.

Oh doch, mit dem genannten Trick und natürlich Erfahrung, um die Ausdrücke schneller zu lesen.

Erfahrung ist das Problem. Nein, eigentlich ist das Problem, dass man im FOSS Umfeld immer Erfahrung voraussetzt. Am Ende muss man das halt für jedes Projekt selbst entscheiden. Aber in meinem Kontext möchte ich jedes ScriptKidy und jeden Schul-Nerd der auf die Idee kommt etwas zu meinem Code beizutragen auch entsprechend an die Hand nehmen. Das ist tatsächlich meine Zielgruppe für meine Code Dokumentation. Im Kontext von RegEx reihe ich mich da selbst eigentlich auch ein. RegEx werde ich nie in dem Umfang und der Regelmäßigkeit nutzen, dass ich es out-of-the-box lesen könnte; d.h. schon für mich selbst muss die Docu DAU-tauglich sein.

Besonders im Kontext von RegEx fällt mir das immer auf, dass sich Leute mit Ihren RegEx Kenntnissen brüsten, mit pattern um sich werfen und es "toll" finden, wenn es keiner versteht. Im Python-Kontext fallen mir hier die one-liner-Fetischisten ein. Diese Ich-bin-der-Experte-und-du-hast-keine-Ahnung-Wall steht in der FOSS Welt (eigentlich IT generell) noch viel zu häufig rum. Linux Distros kann man auch schon an der Höhe dieser Wall beurteilen. Dieses deutsche Debian Forum trägt sehr viel dazu habe, dass die Debian Wall nur bis zu den Knien reicht. (Warum gibts hier keine Herz-Smilies?) Und diese RegEx Session ist auch ein schönes positives Beispiel dafür.

Sorry, war jetzt abgedriftet.

[Ibex]

Ich würde mich sehr gerne mit dem Thema beschäftigen, bin mir aber nicht sicher ob ich genug Vorkenntnis mitbringe um folgen zu können, und der Sonntag gehört auch den Kids, so dass es vermutlich zeitlich schwierig wird.

Wie kann ich mir den Kurs den vorstellen? Werden Fragen und Lösungen hier im Forum gepostet und diskutiert? Gäbe es auch die Möglichkeit, das ganze später nachzulesen und nachzuarbeiten?

[eggy]

Wie kann ich mir den Kurs den vorstellen? Werden Fragen und Lösungen hier im Forum gepostet und diskutiert? Gäbe es auch die Möglichkeit, das ganze später nachzulesen und nachzuarbeiten?

Da geht's los: viewtopic.php?t=183942
Ersten Thread lesen. Ein paar Gedanken zu den Fragen die Meillo stellt machen. Evtl Posten.
Nächste Woche geht's dann weiter.
Und klar kannst Du das im eigenen Tempo machen, und falls Fragen auftreten, die auch noch später stellen.
Zeitnah wäre besser, weil alle gedanklich irgendwie an der gleichen Stelle sind.
Aber später ist natürlich auch ok. Es sollten dann auch genug Leute, die schon nen Stück weiter mitgemacht haben hier sein, die bei den "alten Kapiteln" auch helfen können.