[Alg] Waarom regular expressions?

[Verwijderd]

Waarom zijn regular expressions zo ontzettend poplulair?
Persoonlijk vind ik regular expressions lastig om op te stellen. Daarnaast is het ook nog eens zo dat ze voor derden (of voor jezelf na een tijdje) lastig te lezen zijn.

Waarom kiezen alle mainstream programmeertalen dan toch voor om Regular Expressions te gebruiken?

[Gonadan]

Omdat je er heel gemakkelijk een bepaald patroon mee kan zoeken.

En in sommige situaties heb je tientallen regels code nodig wat een regular expressie in 1 regel kan

Bij ingewikkelde patronen is het nog sneller ook

[EfBe]

Als jij een stukje text wilt parsen dan zijn regular expressions echt een uitkomst. En een stukje tekst parsen komt vaker voor dan je denkt. Ik heb bijna mn subversion <-> gemini pre/post commit connector af en die is gebaseerd op een oude post-commit connector van een 3rd party maar die had echt een ranzige routine om de comment te parsen op gemini issue IDs, gewoon een scan met allerlei uitzonderingcode en het werkte ook nog niet eens altijd. Met een regexp met een group match was het zo gepiept en in een fractie van de regels code .

De syntax is inderdaad erg banaal, maar dat is maar even.

[Tukk]

Het lastig lezen is simpel op te lossen met goede documentatie.

Daarbij is programmeren iets wat je moet leren, dus ook regular expressions. Ze zijn wel erg krachtig, daarom vind je ze steeds terug.

* Tukk moet ook altijd weer even zoeken wat nu de syntax was.

[ Voor 5% gewijzigd door Tukk op 29-03-2006 09:23 ]

[Verwijderd]

Tukk schreef op woensdag 29 maart 2006 @ 09:23:
Het lastig lezen is simpel op te lossen met goede documentatie.

Persoonlijk vind ik het erg slecht als je een stukje code moet uitleggen door documentatie.

[BtM909]

Verwijderd schreef op woensdag 29 maart 2006 @ 09:26:
[...]


Persoonlijk vind ik het erg slecht als je een stukje code moet uitleggen door documentatie.

Ligt dat dan aan de programmeur of degene die ernaar kijkt

Regular Expressions zijn voor de meeste talen uitgebreid beschreven, als jij het niet snapt, wil het nog niet zeggen dat ik mijn code maar moet aanpassen op jouw kennisniveau

[Gerco]

Verwijderd schreef op woensdag 29 maart 2006 @ 09:26:
Persoonlijk vind ik het erg slecht als je een stukje code moet uitleggen door documentatie.

Verzin dan een alternatief wat net zo krachtig is, maar dan leesbaar.

Regular expressions zijn gewoon erg handig. Compact, superkrachtig en helaas niet altijd nog begrijpbaar na een paar weken minuten. Weinig aan te doen, de voordelen ervan overschaduwen de nadelen bijna volledig, anders zou niemand ze gebruiken.

[ Voor 3% gewijzigd door Gerco op 29-03-2006 09:37 ]

[Tukk]

Verwijderd schreef op woensdag 29 maart 2006 @ 09:26:
[...]


Persoonlijk vind ik het erg slecht als je een stukje code moet uitleggen door documentatie.

Waarom?

De code laat wel zien WAT je doet, maar niet WAAROM je iets doet. Alleen dat al zal
je moeten uitleggen. Daarbij is een regular expression voor nummerbord mischien lastig te lezen.
Als jij er dan boven zet: Controle op correctheid nummerbord. Dan snapt iedereen het toch weer?

[Gonadan]

Verwijderd schreef op woensdag 29 maart 2006 @ 09:26:
[...]


Persoonlijk vind ik het erg slecht als je een stukje code moet uitleggen door documentatie.

Dan krijg ik het gevoel dat je nooit een groot stuk code hebt geschreven.
Zodra je enkele duizenden regels code tikt weet je echt niet meer wat alles precies doet, ook al maak je het zelf.

Commentaar is dan een goede uitkomst zodat je in één oogopslag kan zien wat een bepaald stuk code doet.
En dan hoef je niet een blokje code te gaan lezen om je geheugen op te frissen

[Verwijderd]

Gonadan schreef op woensdag 29 maart 2006 @ 09:33:
[...]

Dan krijg ik het gevoel dat je nooit een groot stuk code hebt geschreven.
Zodra je enkele duizenden regels code tikt weet je echt niet meer wat alles precies doet, ook al maak je het zelf.

Commentaar is dan een goede uitkomst zodat je in één oogopslag kan zien wat een bepaald stuk code doet.
En dan hoef je niet een blokje code te gaan lezen om je geheugen op te frissen

Onzin... Commentaar zou een hulpmiddel kunnen zijn. Maar als jij commentaar nodig hebt, om uit te leggen wat de code doet, dan vrees ik dat het stukje code kandidaat voor refactoring is

Verder, twijfel ik overigens in het geheel niet aan de kracht van RegEx. Ik twijfel aan de syntax, en aan de leesbaarheid.
Het doet mij een beetje denken aan de one-liners uit bijv. Perl, die zeer moeilijk leesbaar zijn.

[Gonadan]

Verwijderd schreef op woensdag 29 maart 2006 @ 09:49:
[...]


Onzin... Commentaar zou een hulpmiddel kunnen zijn. Maar als jij commentaar nodig hebt, om uit te leggen wat de code doet, dan vrees ik dat het stukje code kandidaat voor refactoring is

Laat ik verstandig zijn en er niet op ingaan

Verder, twijfel ik overigens in het geheel niet aan de kracht van RegEx. Ik twijfel aan de syntax, en aan de leesbaarheid.
Het doet mij een beetje denken aan de one-liners uit bijv. Perl, die zeer moeilijk leesbaar zijn.

Dus je zou willen dat de syntax in plaats van .* iets van oneOrMoreCharacterWhichCanBeOfAllAsciiValues wordt?
Dan wordt het inderdaad een stuk leesbaarder

Ik ben het met je eens dat het in het begin lastig te lezen is.
Maar dat geldt ook voor b.v. Assembly.
Als je het vaker gebruikt heb wordt het steeds makkelijker

[Verwijderd]

Gonadan schreef op woensdag 29 maart 2006 @ 09:56:
[...]

Laat ik verstandig zijn en er niet op ingaan

[...]

Dat mag

Dus je zou willen dat de syntax in plaats van .* iets van oneOrMoreCharacterWhichCanBeOfAllAsciiValues wordt?
Dan wordt het inderdaad een stuk leesbaarder

Ik ben het met je eens dat het in het begin lastig te lezen is.
Maar dat geldt ook voor b.v. Assembly.
Als je het vaker gebruikt heb wordt het steeds makkelijker

Dat is dus de spijker op zijn kop. Eigenlijk zeg je... Het is inderdaad lastig om te lezen, maar naar mate je het vaker gebruikt wordt het eenvoudiger om te gebruiken.
Waarschijnlijk zijn regular expressions zo populair, omdat er geen (simpeler) alternatief voor bestaat!

BTW: Je programmeert toch ook geen geavanceerde websites, of GUI applicaties met assembler?

[ Voor 8% gewijzigd door Verwijderd op 29-03-2006 10:04 ]

[Gonadan]

Ik moet zeggen dat ik c of java in het begin ook lastig te lezen vond. (toen ik begon met proggen)

Er is nou eenmaal niets dat je ineens kan, behalve janken

Omdat regular expressions bij een wat ingewikkelder patroon nogal wat variabelen bevatten zou met een uitgebreidere syntax de code uit een groot aantal regels gaan bestaan.

Er bestaat trouwens in JAVA een package voor regular expression waarin je de syntax wel als woorden kunt gebruiken.
Probeer die eens

[Verwijderd]

Gonadan schreef op woensdag 29 maart 2006 @ 10:05:
Omdat regular expressions bij een wat ingewikkelder patroon nogal wat variabelen bevatten zou met een uitgebreidere syntax de code uit een groot aantal regels gaan bestaan.

Dat suggereert dus dat RegEx'en zo populair zijn door hun compacte syntax.

Er bestaat trouwens in JAVA een package voor regular expression waarin je de syntax wel als woorden kunt gebruiken.
Probeer die eens

Goed idee! Zal er eens naar kijken.

[Gonadan]

Verwijderd schreef op woensdag 29 maart 2006 @ 10:16:
[...]


Dat suggereert dus dat RegEx'en zo populair zijn door hun compacte syntax.

Dat wil ik nog niet direct zeggen.
Maar het feit dat je met 1 regel een heel lap tekst kan parsen maakt ze wel populair.
En ik heb inderdaad liever de compacte syntax, ik zie zo waar hij naar zoekt.
Dus voor mij is het inderdaad de compacte syntax in combinatie met hun kracht

Edit:
Die JAVA package is trouwens wel minder snel dan bv. php regex.

En begin nu niet over dat java traag is want dat is niet zo, GEEN DISCUSSIE HIEROVER
en nee dit is ook géén uitlokking tot discussie, die gaat toch eindeloos door

[ Voor 24% gewijzigd door Gonadan op 29-03-2006 10:19 ]

[Verwijderd]

Gonadan schreef op woensdag 29 maart 2006 @ 10:18:
[...]

Dat wil ik nog niet direct zeggen.
Maar het feit dat je met 1 regel een heel lap tekst kan parsen maakt ze wel populair.
En ik heb inderdaad liever de compacte syntax, ik zie zo waar hij naar zoekt.
Dus voor mij is het inderdaad de compacte syntax in combinatie met hun kracht

Nou dat beantwoord dus mijn vraag!

Die JAVA package is trouwens wel minder snel dan bv. php regex.

En begin nu niet over dat java traag is want dat is niet zo, GEEN DISCUSSIE HIEROVER
en nee dit is ook géén uitlokking tot discussie, die gaat toch eindeloos door

Java traag? Kom op zeg... Dat is zooooo 2005

[weerdo]

Verwijderd schreef op woensdag 29 maart 2006 @ 09:49:
Verder, twijfel ik overigens in het geheel niet aan de kracht van RegEx. Ik twijfel aan de syntax, en aan de leesbaarheid.
Het doet mij een beetje denken aan de one-liners uit bijv. Perl, die zeer moeilijk leesbaar zijn.

3x raden waar RegEx vandaan komt, en waar de populariteit van Perl aan te danken is. RegEx is de defacto standaard taal om patroonherkenning te faciliteren, net zoals SQL de standaardtaal is om gegevens uit een relationele database te trekken is.

Omdat RegEx de defacto standaard is en bovendien vrij? is, zal geen enkele programmeur het nog in z'n hoofd halen om zelf het wiel opnieuw uit te vinden. Dat is de reden waarom RegExps zo breed (zelfs in VBScript!) ondersteund wordt.

[Verwijderd]

weerdo schreef op woensdag 29 maart 2006 @ 10:27:
[...]

3x raden waar RegEx vandaan komt, en waar de populariteit van Perl aan te danken is. RegEx is de defacto standaard taal om patroonherkenning te faciliteren, net zoals SQL de standaardtaal is om gegevens uit een relationele database te trekken is.

Omdat RegEx de defacto standaard is en bovendien vrij? is, zal geen enkele programmeur het nog in z'n hoofd halen om zelf het wiel opnieuw uit te vinden. Dat is de reden waarom RegExps zo breed (zelfs in VBScript!) ondersteund wordt.

Dat klopt... Het verbaast me gewoon dat er nog geen (beter) alternatief bestaat. Iets wat beter leesbaar / onderhoudbaar is.

[Gonadan]

Verwijderd schreef op woensdag 29 maart 2006 @ 10:33:
[...]


Dat klopt... Het verbaast me gewoon dat er nog geen (beter) alternatief bestaat. Iets wat beter leesbaar / onderhoudbaar is.

Ik hoor net dat er een uitdaging voor je gevonden is

[Janoz]

Regexp lastig lezen? Ja, daar ben ik het wel mee eens, maar japans is voor mij ook best lastig lezen. Wanneer je al langer werkt met regexps dan is het lezen niet zo heel lastig meer. De set met tokens is redelijk beperkt dus best te onthouden. Sowieso zie ik niet in waarom het uit een taal weggelaten zou moeten worden. Als je het niet wilt gebruiken gebruik je het niet. Heb je het wel nodig dan is het best vervelend als het weggelaten is.

Wel vind ik dat regexps te vaak worden gebruikt. Vaak zie ik mensen problemen hebben met hun ubb converteerder die ze niet zouden hebben wanneer ze gewoon een stackbased parser zouden gebruiken.

[EfBe]

Janoz schreef op woensdag 29 maart 2006 @ 10:35:
Wel vind ik dat regexps te vaak worden gebruikt. Vaak zie ik mensen problemen hebben met hun ubb converteerder die ze niet zouden hebben wanneer ze gewoon een stackbased parser zouden gebruiken.

En hoe ga jij dan je input stream tokenizen? Met je handgeschreven statemachines of met een setje regexp's ?

[SchizoDuckie]

Voor degenen die vele problemen hebben met het lezen van regexen en het snappen van regexen, hier een goeie link:

http://www.stklos.org/Doc/html/stklos-ref-5.html

Uitprinten en inlijsten maar

[Janoz]

EfBe schreef op woensdag 29 maart 2006 @ 13:10:
[...]

En hoe ga jij dan je input stream tokenizen? Met je handgeschreven statemachines of met een setje regexp's ?

Dat bedoel ik niet. Het is eerder dat ik mensen in de meest vreemde bochten zie draaien om een quote in een quote fatsoenlijk te matchen.

Het tokenizen implementeren gaat natuurlijk het makkelijkst met een parsegenerator .

[.oisyn]

EfBe schreef op woensdag 29 maart 2006 @ 13:10:
[...]

En hoe ga jij dan je input stream tokenizen? Met je handgeschreven statemachines of met een setje regexp's ?

Janoz' punt is dat ze een "ubb parser" maken mbv een serie regex replaces, ipv een regex die de input opdeelt in een tokenstream wat weer door een parser gegooid wordt.

[ Voor 6% gewijzigd door .oisyn op 29-03-2006 13:51 ]

[Michali]

Ik ben persoonlijk ook voor code die goed communiceert, maar in geval van regexen moet ik toch echt commentaar geven. In geval van een stabiele taal, iets wat dus niet of zeer weinig veranderd, mag van mij best compacte syntax gebruikt worden. Je leert er immers mee omgaan en na een paar keer leest dat dan nog makkelijker dan vol uitgeschreven woorden. Je weet waar een teken voor staat, en een berg tekens kun je dan interpreteren als een berg tekst. Wat mij betreft zijn regexen goed zoals ze zijn. Af en toe is de syntax idd. lastig, maar dat zijn bij mij meer punten waar ik nog niet zo veel mee heb gedaan.

[.oisyn]

Overigens zou je de regex ook in EBNF notatie kunnen opnemen in je comments, dat is al een stuk duidelijker te lezen. En het vervelende van regexen in gewone strings in programmeertalen is doorgaans dat je meer moet escapen dan nodig is (een backslash matchen wordt dan \\\\, erg irritant), het is dus handig als er een alternatieve string syntax beschikbaar is (zoals C# dat bijvoorbeeld heeft, of gewoon native regex ondersteuning zoals in talen als javascript en perl)

[.oisyn]

Verwijderd schreef op woensdag 29 maart 2006 @ 09:49:

Onzin... Commentaar zou een hulpmiddel kunnen zijn. Maar als jij commentaar nodig hebt, om uit te leggen wat de code doet, dan vrees ik dat het stukje code kandidaat voor refactoring is

Je praat zelf onzin, zie de reply van Tukk een paar regels boven de post die ik nu quote . Code vertelt wat er moet gebeuren, niet waarom het moet gebeuren of waarom de programmeur ervoor heeft gekozen het zo op te lossen. Dergelijke comments schelen enorm bij het vinden en repareren van bugs, omdat de originele gedachtengang veel beter te achterhalen is. En nee, lang niet altijd heb je zulke comments nodig, maar bij complexe stukjes software en algoritmen hebben ze zeker wel voordeel. Om dan maar te zeggen dat je het moet refactoren (als we het toch over populaire termen hebben) is gewoon te kort door de bocht. Maar goed, dit is al eerder aan bod gekomen in [rml][ alg] Commentaar in code nodig of overbodig?[/rml]

[ Voor 6% gewijzigd door .oisyn op 29-03-2006 14:14 ]

[Verwijderd]

.oisyn schreef op woensdag 29 maart 2006 @ 14:07:
[...]

Je praat zelf onzin, zie de reply van Tukk .....

Is dat zo?

Wat behoorlijk onzinnig is, commentaar gebruikem om uit te leggen hoe een bepaald stuk code werkt.

Ik wil ook niet zeggen dat commentaar altijd overbodig is.

Mee eens, commentaar dat aangeeft WAAROM bepaalde code voorkomt is zinvol.

De opmerking van Gonadan ging over WAT de code doet. Dat is hetgeen waar ik op reageerde.

[ Voor 5% gewijzigd door Verwijderd op 29-03-2006 14:48 ]

[.oisyn]

Ok, fair enough, Gonadan gebruikt idd de verkeerde woorden, maar je eerste reactie over het niet nodig zijn van comments was er natuurlijk al veel eerder

[ Voor 7% gewijzigd door .oisyn op 29-03-2006 14:52 ]

[Gonadan]

Verwijderd schreef op woensdag 29 maart 2006 @ 14:47:
[...]

Is dat zo?

Wat behoorlijk onzinnig is, commentaar gebruikem om uit te leggen hoe een bepaald stuk code werkt.

Ik wil ook niet zeggen dat commentaar altijd overbodig is.

Mee eens, commentaar dat aangeeft WAAROM bepaalde code voorkomt is zinvol.

De opmerking van Gonadan ging over WAT de code doet. Dat is hetgeen waar ik op reageerde.

Dan moet ik er helaas toch op ingaan

Normaal gesproken geven functie- en variabele namen aan waar ze voor dienen.
Maar ik heb ondervonden dat het toch handig is om soms je functies of zelfs delen ervan te becommentariëren, zeker als je niet de enige bent die aan de code werkt.

Dus dat stukje over refactoring slaat nergens op

Edit:
Niet altijd natuurlijk, je hebt ook spaghetticode uiteraard

[ Voor 5% gewijzigd door Gonadan op 29-03-2006 14:54 ]

[Verwijderd]

.oisyn schreef op woensdag 29 maart 2006 @ 14:51:
Ok, fair enough, Gonadan gebruikt idd de verkeerde woorden, maar je eerste reactie over het niet nodig zijn van comments was er natuurlijk al veel eerder

Ik zeg toch nergens dat comments niet nodig zijn?

Persoonlijk vind ik het erg slecht als je een stukje code moet uitleggen door documentatie.

[mschol]

regular expressions vind ik zelf lastig om op te zetten en heb nu gelukkig een hulpje:
regexbuddy
hiermee kan je d.m.v. een normale gui je regexp opstellen en e.v.t. direct laten comparen met de string die je moet vinden..

[.oisyn]

Het waarom valt toch ook onder het uitleggen van code

[Verwijderd]

Gonadan schreef op woensdag 29 maart 2006 @ 14:53:
[...]

Dan moet ik er helaas toch op ingaan

Normaal gesproken geven functie- en variabele namen aan waar ze voor dienen.
Maar ik heb ondervonden dat het toch handig is om soms je functies of zelfs delen ervan te becommentariëren, zeker als je niet de enige bent die aan de code werkt.

Dus dat stukje over refactoring slaat nergens op

Edit:
Niet altijd natuurlijk, je hebt ook spaghetticode uiteraard

Ik bedoel er mee te zeggen.... Als je commentaar nodig hebt om uit te leggen WAT je code doet, dan heb je iets gemaakt was expressiever kan. (En dus is het kandidaat voor refactoring)

[Bigs]

Ik ben het niet eens met de stelling dat RegExen onleesbaar zijn, code die patronen verwerkt zonder regexen is vaak veel moeilijker te begrijpen dan een regular expression. Het is natuurlijk wel zaak dat je ze dan goed onder de knie hebt en daar zit ook een beetje het probleem.. de leercurve voor RegExen is best stevig. Ik moet zelf ook regelmatig op mijn cheatsheet kijken als ik regexen schrijf. Toch vind ik dat geen bezwaar, het resultaat werkt over het algemeen namelijk als een trein.

[Verwijderd]

.oisyn schreef op woensdag 29 maart 2006 @ 14:56:
Het waarom valt toch ook onder het uitleggen van code

Niet echt... Waarom je iets doet hoeft niet vastgelegd te zijn in de code.
Maar eerder in een requirements document, Use case, user story of iets dergelijks.

[Verwijderd]

mschol schreef op woensdag 29 maart 2006 @ 14:55:
regular expressions vind ik zelf lastig om op te zetten en heb nu gelukkig een hulpje:
regexbuddy
hiermee kan je d.m.v. een normale gui je regexp opstellen en e.v.t. direct laten comparen met de string die je moet vinden..

Inderdaad goede tool! Voor Eclipse heb je ook een aantal plugins beschikbaar. Bijv: http://brosinski.com/regex/

[Gonadan]

Verwijderd schreef op woensdag 29 maart 2006 @ 14:59:
[...]


Niet echt... Waarom je iets doet hoeft niet vastgelegd te zijn in de code.
Maar eerder in een requirements document, Use case, user story of iets dergelijks.

Dat ben ik met je eens, de beweegredenen van bepaalde programmeerstructuren zet je in de documentatie.

Maar dat als code commentaar nodig heeft om uit te leggen wat het precies doet op een ingewikkeld stuk inhoudt dat de code gelijk niet goed is vind ik grote onzin.

[.oisyn]

Verwijderd schreef op woensdag 29 maart 2006 @ 14:59:

Niet echt... Waarom je iets doet hoeft niet vastgelegd te zijn in de code.
Maar eerder in een requirements document, Use case, user story of iets dergelijks.

De grote lijnen wel, maar (bijvoorbeeld) dat er verwacht wordt dat een bepaalde pointer in een bepaalde case niet 0 kan zijn en je daar ook niet op controleert is niet echt iets wat je in de documentatie zet maar in de comments van je code.

[Verwijderd]

Gonadan schreef op woensdag 29 maart 2006 @ 15:04:
[...]

Dat ben ik met je eens, de beweegredenen van bepaalde programmeerstructuren zet je in de documentatie.

Maar dat als code commentaar nodig heeft om uit te leggen wat het precies doet op een ingewikkeld stuk inhoudt dat de code gelijk niet goed is vind ik grote onzin.

Er is ook niemand die zegt dat de code niet goed zou zijn.
Het zou alleen een stuk expressiever kunnen.... En daarom beter leesbaar zijn... En daarom het commentaar overbodig kunnen maken.

[Verwijderd]

.oisyn schreef op woensdag 29 maart 2006 @ 15:09:
[...]

De grote lijnen wel, maar (bijvoorbeeld) dat er verwacht wordt dat een bepaalde pointer in een bepaalde case niet 0 kan zijn en je daar ook niet op controleert is niet echt iets wat je in de documentatie zet maar in de comments van je code.

Ook dat zou je expressiever kunnen maken, door bijv constanten te gebruiken i.p.v. een simpele pointer.
Ik vrees dat we hier nog heel erg lang over kunnen discussieren

[.oisyn]

Idd, bottom line is dat ik geen goed voorbeeld kan verzinnen maar jij ook niet alle mogelijke voorbeelden af kunt dekken met een simpel argument als "dat moet je anders opschrijven" of "dat kan dan in de documentatie"

[Verwijderd]

Is er (naast de eerder genoemde Java package) een alternatief voor regular expressions dat breed gedragen is? Met andere woorden, dat ik veel talen geimplemeteerd is? Ik ken het niet.

Ik moet zeggen dat ik regular expressions ook lastig vind, maar zoals met de meeste complexe, fijn beschreven zaken zijn ze wel heel krachtig. Ik moet altijd denken aan het verschil tussen Lego en Playmobil met dit soort dingen. Lego heeft veel meer en veel kleinere steentjes waardoor je meer verschillende bouwsels kan maken. Playmobil is makkelijker en groter, maar je kunt er veel minder mee maken.

[Janoz]

Modbreak:

Zullen we in dit topic maar weer verder gaan met de (on)duidelijkheid en het (over)gebruik van regexpen? Mochten er nog nieuwe inzichten mbt commentaar aan "[rml][ alg] Commentaar in code nodig of overbodig?[/rml]" worden toegevoegd, dan kan dat in dat topic.

[Verwijderd]

.oisyn schreef op woensdag 29 maart 2006 @ 15:24:
Idd, bottom line is dat ik geen goed voorbeeld kan verzinnen maar jij ook niet alle mogelijke voorbeelden af kunt dekken met een simpel argument als "dat moet je anders opschrijven" of "dat kan dan in de documentatie"

Laten we het er op houden dat de waarheid ergens in het midden ligt