Archief - [ALG] hoe verder gaan

wlibaers · 5 nov 2005

Jormungand zei:
Er zijn wel degelijk duidelijk gedefinieerde regels waaraan een taal moet voldoen om als een OOP taal door het leven te kunnen gaan. De talen die ik opnoemde voldoen aan deze eisen met glans. Het is bv. niet zo dat indien een taal het concept van een class ondersteund, dat deze daarom ook aanzien kan worden als een echte volwaardige OOP taal.

"OOP is subject to much contention as to its precise definition or its principal ideas."
http://en.wikipedia.org/wiki/Object-oriented_programming

Talen zoals Python en Objective-C hebben bijvoorbeeld bepaalde OOP-eigenschappen, maar niet alle delen van C++ of Java (private bijvoorbeeld ontbreekt, of wordt niet afgedwongen). Zijn dat dan geen OO talen? Nochtans worden ze wel vaak zo beschreven. C++ zelf zou je trouwens ook als gedeeltelijk niet-OOP kunnen beschouwen, omwille van het feit dat niet alles een object is en je losse functies hebt.

Bullshit. Ik heb hier nooit zitten zeggen dat niet-OO programmeurs per definitie slechts zijn, of sterker nog, losers zijn. De autheur van dat artikel moet nog volwassen worden.

Blijvende aanvallen op de persoon zonder te zeggen wat er specifiek mis mee is.

Er kan inderdaad goede code in C (bv.) geschreven worden, maar die begint al heel sterk te lijken op het concept van classes, dus waarom toch blijven volharden en het uzelf moeilijker (blijven) maken?

Er kunnen praktische redenen bestaan. Net zoals de reden voor het gebruik van C in DLL's bijvoorbeeld.

Populaire talen van het moment? C++ is een taal die er al van 1983 bestaat.
Begin dus niet te beweren dat die een populair taaltje van het moment is he. C++ is een volwassen taal, met zeer krachtige features. En tot op vandaag, met alle concurentie die ze krijgt van bv. Java, C# en zelfs VB.NET staat deze taal nog steeds zeer sterk. En ik wil hiermee ook niet zeggen dat die andere talen niet deugen (allee behalve VB dan ).

Bij die uitspraak dacht ik eigenlijk eerder aan Java en C#. Sommigen zijn trouwens van mening dat geavanceerde macro's ("templates" in C++) belangrijker zijn dan de pure OOP-eigenschappen van de taal.

Zie het gelijk je wil, het is gewoon een feit dat veel legacy C code een grote mesthoop is. En dit heeft vooral te maken met (1) de ervaring van de programmeur, (2) dat een structured programming language een andere denkwijze in gang zet, met vaak dit verschrikkelijke resultaat.

Weet je, een gelijkaardige redenering werd door Dijkstra gebruikt tegen de hele praktijk van "software engineering" (inclusief OOP), door hem beschouwd als een soort kwakzalverij, door een volgens Dijkstra fundamenteel verkeerde aanpak van het probleem. http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1024.html
(pagina 9)

Dat is weer zo een argument dat nergens op trekt. Je vergeet polymophism, een zeer belangrijk concept in OOP. En ja dat kan je ook nabootsten in C als je dat wil, ik zeg het al maar in jou plaats, maar dan ben je het jezelf wel zeer moeilijk aan't maken. Dat noem ik dan pas 'tijd verspillen'.

...

Wat ik dus zeker van jou ook kan zeggen. Je wil basis OOP technieken toepassen in bv. C. (Jou woorden: "Wat gewoon aantoont dat je geen "echte" OO taal nodig hebt om aan OO te doen."). Maar je wil zeker niet dit doen met een echte OOP taal . Dat noem ik nu eens koppig zijn en het uzelf moeilijk maken, of met jou woorden 'fanatisme'.

hetzelfde geldt voor "echte" OOP-talen. Want wat in die "echte" OOP programmeertalen voor polymorfisme doorgaat is maar een mager beestje hoor. Even verduidelijken?

"A programming language is low level when its programs require
attention to the irrelevant." - Alan Perlis

Dit is bijvoorbeeld toe te passen op geheugenbeheer. Als je geen specifieke strikte eisen stelt aan het geheugenbeheer (qua prestaties en ingenomen ruimte) ben je bijvoorbeeld doorgaans beter af met automatisch beheer (garbage collector) dan met manueel beheer (new/delete eventueel in combinatie met RAII, wat ook nog voor andere zaken toepasbaar is). Hetzelfde kan gezegd worden over vele OOP technieken. Wat jij als echte OOP-talen beschouwd zijn talen die specifieke uitbreidingen van de syntax hebben die dienen als afkortingen voor de code die je in eerdere programmeertalen zou moeten schrijven als je die functionaliteit wou.

Polymorfisme is daarvan een voorbeeld. In de oude stijl had je voor een functienaam een enkele echte functie die een enkele set argumenten kon aanvaarden. De zgn. "echte" OOP talen laten dan een specialisatie toe op basis van het eerste argument, door middel van speciale syntax (doorgaans a.f(b, c) i.p.v. het oude f(a, b, c), plus vaak nog extra sleutelwoorden zoals "virtual".

In bepaalde andere talen (die "wannabee OO taaltjes"?) heb je dan weer de zogenaamde generieke functie, die met een standaard syntax toelaat om op eender welk aantal parameters te specialiseren, zelfs als deze tijdens de compilatie nog onbekend zijn. C++ heeft ook iets in die zin, met de arbitraire (vanuit het standpunt van de gewone programmeur, voor de compilerschrijver is het belangrijk) restrictie dat het type tijdens de compilatie bekend moet zijn.

Dit is geen vergezocht voorbeeld. Dit soort generieke functie is geen zeldzaamheid. In de wereld van de "echte" OOP-talen staat dit, voor het geval van specialisatie op basis van twee parameters, bekend als het "visitor pattern". Het is ook geen alleenstaand geval, de hele Design Patterns literatuur is eigenlijk een grote bibliotheek bewijzen dat de "echte" OOP-talen, volgens bovenstaande definitie van Perlis, eigenlijk te low level zijn voor de taken waarvoor ze gebruikt worden.

Met andere woorden, wat je krijgt als je een "echte" OOP-taal gebruikt is een vereenvoudiging voor een klein aantal specifieke probleempjes van de vorige generatie. Je betaalt hiervoor met een berg nieuwe syntax en speciale gevallen omdat de OOP-programmeertalen die vandaag succesvol zijn hun succes eraan te danken hebben dat het direct of via C++ afstammelingen zijn van C waar alles maar bijgepropt werd.

En nee, overerving is ook niet echt algemeen. Het eenvoudige geval (slechts een parent class toegelaten) laat alleen toe die dingen te beschrijven die in een simpele boomstructuur passen, met multiple inheritance raak je al wat verder maar moet je wel uitkijken wat je precies doet.

En dan zijn er nog de toevoegingen zoals "private" die alleen dienen om ongedisciplineerde programmeurs uit andermans objecten te houden. Waarop men dan het concept van de "friend" functie uitvindt omdat de beveiliging gecontroleerd doorbreken soms wel nuttig kan zijn. Zijn we dan nog bezig met programmeren of eerder met bureaucratie?

Neen, dat heeft alles te maken met name mangling (of name-decoration) van een funtctie door de compiler. Bij C is dit simpel en heeft dus ook vaste regels. DLL's gecompileerd met de ene compiler zijn dus compatible voor een andere compiler (op voorwaarde dat ze de C standaarden handhaven.). Bij C++ is het probleem veel moeilijker omdat C++ oa. function overloading kent en dergelijke (er zijn nog vele andere problemen zoals namespaces, etc, etc). Men kan hier dus niet zomaar een simpel standaard name mangling scheme vastleggen. Met als gevolg dat er geen standaard is, en compiler uitgevers eigen schemes hebben. Als nadeel heeft dit natuurlijk dat dll's met c++ linkage niet gebruikt kunnen worden met verschillende compilers, soms zelfs niet met verschillende versies van dezelfde uitgever. Daarom vind ik C nuttig om DLL interfaces te maken. Dan kan ik als ik een paar regels in acht neem deze zelfs voor iemand die VB gebruikt ter beschikking stellen. Er zijn wel technieken om het C++ probleem op te lossen en er is ook zo iets als COM DLL's. Die zijn binair standaard.

Dit is eigenlijk een heel lange uitleg die bevestigt wat ik al vermeldde: de C ABI voor DLL's is min of meer gestandaardiseerd per platform, die voor C++ niet. (voor C trouwens alleen voor _cdecl in het geval van Windows systemen, in het geval van _stdcall past MSVC ook een lichte vorm van mangling toe, zie http://www.mingw.org/mingwfaq.shtml#faq-msvcdll ). Er is in principe geen reden waarom de name mangling niet standaard zou kunnen zijn (er is geen technische reden waarom compilers hier verschillen zouden moeten hebben), net zoals men voor de _cdecl C functies ervoor gekozen heeft dezelfde conventie te gebruiken. Het is gewoon niet gebeurd tot COM er kwam (COM is eigenlijk niet meer dan een set classes met virtuele functies volgens de MSVC structuur, met de voorwaarde dat elke COM class een set functies bevat om reference counting toe te passen voor al die objecten).

Ik spreek dan van een algorithm, dat kan men inderdaad perfect op een wiskundige manier beschrijven, als jij dat al een 'programma' noemt dan begin ik mij af te vragen of jij wel al eens aan 'echte' software hebt gewerkt?

1. Het is niet beperkt tot een enkel algoritme, maar kan in principe op hele programma's toegepast worden.
2. Daar zijn we weer met het pejoratief gebruik van het woord "echte". Om Dijkstra er nog even bij te halen...

"One American boasted that he had made an "algebraic translator" of 50,000 instructions, only to be immediately outdone by one of his compatriots, whose algebraic translator comprised no less than 80,000 instructions. Peter Naur broke the subsequent silence of awe by remarking that he had written an ALGOL translator of 5,500 instructions, upon which I could outdo him with a compiler of only 2,700 instructions. In short: our yardsticks for achievement measured in opposite directions!"
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1024.html

Wat mijn eigen ervaringen betreft: ik schrijf geen gigantische programma's, ik ben ook geen gediplomeerd informaticus, ik hou me wel als amateur bezig met programmeren, en op het werk (fysische scheikunde) programmeer ik om automatisch meetopstellingen te kunnen gebruiken en om gegevens te verwerken. Ik hou me niet bezig met gigantische monolithische applicaties, maar volg het UNIX-model van kleine programma's met een welomschreven taak, die indien nodig via de commandline en scripts gekoppeld kunnen worden (en eventueel het hele programma in een scriptingtaal schrijven). Dit model is waarschijnlijk het meest succesvolle geval van hergebruik van code. Alleen is het tegenwoordig niet meer zo bekend omdat de meesten de commandoprompt en shell scripts niet meer zo goed kennen door de opkomst van de GUI. Ik ben wel op de hoogte van OOP concepten en talen (Booch, Stroustrup,...) maar in mijn werk zou dat met een kanon op een mug schieten zijn.

Ik kan begrijpen dat diegenen die mastodont-applicaties schrijven andere noden hebben. Denk er van aan dat wat voor jou werkt niet noodzakelijk ideaal is voor diegenen in een andere situatie.

Jormungand · 5 nov 2005

"OOP is subject to much contention as to its precise definition or its principal ideas."
http://en.wikipedia.org/wiki/Object...ted_programming

Ik zie dat je wel heel graag met URL's zit rond te zwieren, Wikipedia is nu niet de meest 'correcte' bron he...

Talen zoals Python en Objective-C hebben bijvoorbeeld bepaalde OOP-eigenschappen, maar niet alle delen van C++ of Java (private bijvoorbeeld ontbreekt, of wordt niet afgedwongen). Zijn dat dan geen OO talen? Nochtans worden ze wel vaak zo beschreven. C++ zelf zou je trouwens ook als gedeeltelijk niet-OOP kunnen beschouwen, omwille van het feit dat niet alles een object is en je losse functies hebt.

C++ is zeer flexibel, dat heb ik reeds gezegd. Je zou zelfs gewoon C style kunnen doen zonder probleem. Maar dat wil niet zeggen dat het geen OOP taal is. Een eis voor C++, toen deze ontworpen werd, was om compatible te blijven met C.

Bij die uitspraak dacht ik eigenlijk eerder aan Java en C#. Sommigen zijn trouwens van mening dat geavanceerde macro's ("templates" in C++) belangrijker zijn dan de pure OOP-eigenschappen van de taal.

Run-time of compile-time polymorphism... Geen van beide is belangrijker. Dit omdat het een een probleem oplost dat het andere niet kan. Ze zijn evenwaardig en de kunst bestaat er nu juist in om ze in combinatie te gebruiken. Het is inderdaad wel zo dat c++ templates enorm krachtig kunnen zijn.

Weet je, een gelijkaardige redenering werd door Dijkstra gebruikt tegen de hele praktijk van "software engineering" (inclusief OOP), door hem beschouwd als een soort kwakzalverij, door een volgens Dijkstra fundamenteel verkeerde aanpak van het probleem. http://www.cs.utexas.edu/users/EWD/...xx/EWD1024.html
(pagina 9)

Je bent inderdaad een liefhebber van de anti-OOP pleiters. Ik heb ervaring met verschillende talen/methodes, en ik heb in gans mijn carriere als software architect het beste resultaat bekomen met OO designs. Voor MIJ is dat een feit, en het laat me koud met hoeveel links en quotes je nog komt aandraven. Voor grote, commerciele projecten is OO the way to go. Als jij "software engineering" ook als kwakzalverij aanziet dat is dat jou zaak. Ik vind het larie. Dijkstra maakt geen indruk op mij hoor. Ik weet wat mijn resultaten zijn met OOP. Diezelfde resultaten zou ik nooit kunnen halen met bv. C.

hetzelfde geldt voor "echte" OOP-talen. Want wat in die "echte" OOP programmeertalen voor polymorfisme doorgaat is maar een mager beestje hoor. Even verduidelijken?

"A programming language is low level when its programs require
attention to the irrelevant." - Alan Perlis

Als je die redenering door trekt dan kan men stellen dat alle talen low level zijn omdat er altijd dingen zijn waarop men moet letten die irrelevant zijn voor het probleem domein zelf. Er bestaat geen taal waarin je perfect kan uitdrukken wat je wil doen, zonder hier en daar over irrelevante dingen te struikelen. Dit wel op voorwaarde dat de complexiteit van het probleem voldoende groot is.

Er is een groot verschil tussen filosoferen over dingen en het in de praktijk toepassen van de wetenschap. Het is ook bekend dat computer wetenschappers niet de beste software architecs zijn... Sommige houden er ook een eigenzinnige mening op na.

In bepaalde andere talen (die "wannabee OO taaltjes"?) heb je dan weer de zogenaamde generieke functie, die met een standaard syntax toelaat om op eender welk aantal parameters te specialiseren, zelfs als deze tijdens de compilatie nog onbekend zijn. C++ heeft ook iets in die zin, met de arbitraire (vanuit het standpunt van de gewone programmeur, voor de compilerschrijver is het belangrijk) restrictie dat het type tijdens de compilatie bekend moet zijn.

C++ is nu eenmaal een statically typed language, dit is geen restrictie. Beide hebben voor en nadelen.

Dit is geen vergezocht voorbeeld. Dit soort generieke functie is geen zeldzaamheid. In de wereld van de "echte" OOP-talen staat dit, voor het geval van specialisatie op basis van twee parameters, bekend als het "visitor pattern". Het is ook geen alleenstaand geval, de hele Design Patterns literatuur is eigenlijk een grote bibliotheek bewijzen dat de "echte" OOP-talen, volgens bovenstaande definitie van Perlis, eigenlijk te low level zijn voor de taken waarvoor ze gebruikt worden.

Met andere woorden, wat je krijgt als je een "echte" OOP-taal gebruikt is een vereenvoudiging voor een klein aantal specifieke probleempjes van de vorige generatie. Je betaalt hiervoor met een berg nieuwe syntax en speciale gevallen omdat de OOP-programmeertalen die vandaag succesvol zijn hun succes eraan te danken hebben dat het direct of via C++ afstammelingen zijn van C waar alles maar bijgepropt werd.

En nee, overerving is ook niet echt algemeen. Het eenvoudige geval (slechts een parent class toegelaten) laat alleen toe die dingen te beschrijven die in een simpele boomstructuur passen, met multiple inheritance raak je al wat verder maar moet je wel uitkijken wat je precies doet.

Wat is het nu iegenlijk dat je wil duidelijk maken!? Dat "echte" OOP talen gewoon "uitbreidingen op" zijn? Er bestaat zoiets als evolutie en vernieuwing, en dat is maar goed ook. Wil je zeggen dat je maar bij C moet blijven omdat het daar allemaal mee ontstaan is? Verkoop je auto dan onmiddelijk en grijp terug naar paard en kar.... Ik vind dit nu echt een belachelijke discussie. Ik vraag mij dus echt af wat jou probleem met OOP is?

En dan zijn er nog de toevoegingen zoals "private" die alleen dienen om ongedisciplineerde programmeurs uit andermans objecten te houden. Waarop men dan het concept van de "friend" functie uitvindt omdat de beveiliging gecontroleerd doorbreken soms wel nuttig kan zijn. Zijn we dan nog bezig met programmeren of eerder met bureaucratie?

Jij bent nu specifiek C++ in het belachelijke aan het trekken. Als je goed op de hoogte bent van de regels van C++ software engineering dan weet je dat je "friend" nooit gebruikt. Als je echt nood hebt aan een class die een "friend" moet zijn dan heb je een slecht ontwerp. "friend" is echter wel nuttig voor classes die andere classes 'testen'. Bij unit testing is er geen enkel probleem dat de test class volledige toegang krijgt tot de geteste class, en hier is "friend" dus zeer welkom. Dit is dan ook de enige plaats waar ik "friend" gebruik. Java kent dit bijvoorbeeld niet en dat is soms echt wel een probleem bij het ontwerpen van unit tests.

Dit is eigenlijk een heel lange uitleg die bevestigt wat ik al vermeldde: de C ABI voor DLL's is min of meer gestandaardiseerd per platform, die voor C++ niet. (voor C trouwens alleen voor _cdecl in het geval van Windows systemen, in het geval van _stdcall past MSVC ook een lichte vorm van mangling toe, zie http://www.mingw.org/mingwfaq.shtml#faq-msvcdll ). Er is in principe geen reden waarom de name mangling niet standaard zou kunnen zijn (er is geen technische reden waarom compilers hier verschillen zouden moeten hebben), net zoals men voor de _cdecl C functies ervoor gekozen heeft dezelfde conventie te gebruiken. Het is gewoon niet gebeurd tot COM er kwam (COM is eigenlijk niet meer dan een set classes met virtuele functies volgens de MSVC structuur, met de voorwaarde dat elke COM class een set functies bevat om reference counting toe te passen voor al die objecten).

Lessen heb ik niet nodig hoor. :ironic:

"COM is eigenlijk niet meer dan een set classes met virtuele functies volgens de MSVC structuur, met de voorwaarde dat elke COM class een set functies bevat om reference counting toe te passen voor al die objecten"

COM is een vooral binaire standaard, dit zorgt ervoor dat het werkt voor vele talen. Die virtuele functies en abstracte classes is hoe het in C++ verwezelijkt wordt. Jij geeft een zeer magere beschrijving van wat COM echt is. En zoals ik al zei, ik heb geen lessen nodig.

1. Het is niet beperkt tot een enkel algoritme, maar kan in principe op hele programma's toegepast worden.
2. Daar zijn we weer met het pejoratief gebruik van het woord "echte". Om Dijkstra er nog even bij te halen...

"One American boasted that he had made an "algebraic translator" of 50,000 instructions, only to be immediately outdone by one of his compatriots, whose algebraic translator comprised no less than 80,000 instructions. Peter Naur broke the subsequent silence of awe by remarking that he had written an ALGOL translator of 5,500 instructions, upon which I could outdo him with a compiler of only 2,700 instructions. In short: our yardsticks for achievement measured in opposite directions!"
http://www.cs.utexas.edu/users/EWD/...xx/EWD1024.html

Dijkstra.... :sleep:

Ik hou me niet bezig met gigantische monolithische applicaties

Waarom is volgens U een gigantische applicatie noodzakelijk ook monolithisch?
Voor jou lijkt dat misschien zo (is het door de GUI?), maar kwa architectuur is dat helemaal niet zo.

maar volg het UNIX-model van kleine programma's met een welomschreven taak, die indien nodig via de commandline en scripts gekoppeld kunnen worden (en eventueel het hele programma in een scriptingtaal schrijven). Dit model is waarschijnlijk het meest succesvolle geval van hergebruik van code.

Ik heb het hier nu al dagen over 'software engineering' en 'dat OOP hiervoor het beste resultaat geeft'... Als shell scripte'kes schrijven daar nu ook al onder valt. Goe bezig.

Alleen is het tegenwoordig niet meer zo bekend omdat de meesten de commandoprompt en shell scripts niet meer zo goed kennen door de opkomst van de GUI.

Ik ben zeer goed op de hoogte van UNIX systemen hoor. Ik ontwikkel multi-platform software. Als voorbeeld, ik wil jou met je structured programming stijl eens een GUI framework zin schrijven dat platform onafhankelijk is. Veel plezier ermee. :ironic:

Dat de meesten geen terminals meer kennen of geen shell scripts kunnen schrijven? Dat weet ik niet hoor, in jou omgeving is dat misschien zo maar ik zou toch maar oppassen met dat te veralgemenen.

Ik ben wel op de hoogte van OOP concepten en talen (Booch, Stroustrup,...) maar in mijn werk zou dat met een kanon op een mug schieten zijn.

Ik kan begrijpen dat diegenen die mastodont-applicaties schrijven andere noden hebben. Denk er van aan dat wat voor jou werkt niet noodzakelijk ideaal is voor diegenen in een andere situatie.

Dat had je dus in het begin al moeten zeggen. Ik heb altijd gezegd dat voor kleinere applicaties andere technieken 'leefbaar' kunnen zijn (lees mijn posts maar terug als je wil). Het is echter commercieel niet leefbaar om "mastodont-applicaties" te schrijven (zoals ik dus weldegelijk doe) volgens de oudere technieken. OOP is the way to go. Wie ben jij om daar nu een oordeel over te vellen? Je zit niet in het vak. Je ontwerpt geen software components. Zinloze discussie...

Ik ondervind dagelijks de problemen die met een software ontwikkel proces samen gaan, ik ondervind ook wat beter is. Jij bent vrij om jou mening te hebben, en ik doe ook geen poging om je te overhalen dat je OO moet gaan toepassen. De werelden waarin wij onze dagelijkse dingen doen zijn gewoon te verschillend om hiervan een nuttige discussie te maken. De projecten waarmee ik in contact kom zijn enorm. Ik spreek over honderd duizenden regels code (ik schat dicht bij het half miljoen), en daarnaast ook nog eens duizenden en duizenden unittests (die ook nog eens bestaan uit gigantisch veel code) die zoveel mogelijk van die andere code moet testen.

Een mastodont van een post.

dJeez · 5 nov 2005

Jormungand zei:
Ik heb het hier nu al dagen over 'software engineering' en 'dat OOP hiervoor het beste resultaat geeft'... Als shell scripte'kes schrijven daar nu ook al onder valt. Goe bezig.

Het gaat erom dat al de afzonderlijke commando's die je gebruikt in je shell scripts geschreven zijn in plain old C. En dat is in dit geval zeker geen slechte keuze, net zomin als het feit dat de kernel van zowat elk OS geschreven is in C. OOP gebruiken voor high level toepassingen is ok, maar voor low-level zaken zou ik ook eerder geneigd zijn naar C terug te grijpen. Zeker aangezien iets als een command line tool doorgaans klein, makkelijk te onderhouden en goed op te volgen is. Of vallen een kernel en basis command line apps ook al niet onder software engineering volgens uw "visie"?

Ik heb wat moeite met uw ophemelen van OOP als dè wonderoplossing, wat het dus helemaal niet is. Voor sommige zaken is het de goede oplossing, voor andere dan weer totaal niet. Eigenlijk kan je het vergelijken met de hele OS vs OS discussie, voor het ene probleem is het ene OS beter geschikt dan het andere. Het komt dus eigenlijk - zoals steeds - neer op het kiezen van "the right tool for the right job".

Jormungand zei:
Ik ben zeer goed op de hoogte van UNIX systemen hoor. Ik ontwikkel multi-platform software. Als voorbeeld, ik wil jou met je structured programming stijl eens een GUI framework zin schrijven dat platform onafhankelijk is. Veel plezier ermee. :ironic:

Waarom zou je die zelf moeten ontwikkelen als Gtk al bestaat?

wlibaers · 5 nov 2005

Jormungand zei:
Ik zie dat je wel heel graag met URL's zit rond te zwieren, Wikipedia is nu niet de meest 'correcte' bron he...

Weet ik. Maar als er een algemeen aanvaarde definitie van OOP zou bestaan, wie zou dan zo'n afwijkende mening op Wikipedia zetten? Wat eerder correct zal zijn is dat er enkele verschillende OO-'kampen' zijn, en dat in bijvoorbeeld het C++/Java/C# kamp er vrij grote overeenstemming is over wat OOP betekent, omdat het in die talen inderdaad goed overeenkomt.

Je bent inderdaad een liefhebber van de anti-OOP pleiters. Ik heb ervaring met verschillende talen/methodes, en ik heb in gans mijn carriere als software architect het beste resultaat bekomen met OO designs. Voor MIJ is dat een feit, en het laat me koud met hoeveel links en quotes je nog komt aandraven. Voor grote, commerciele projecten is OO the way to go. Als jij "software engineering" ook als kwakzalverij aanziet dat is dat jou zaak. Ik vind het larie. Dijkstra maakt geen indruk op mij hoor. Ik weet wat mijn resultaten zijn met OOP. Diezelfde resultaten zou ik nooit kunnen halen met bv. C.

Welja, om dat te begrijpen moet je z'n achtergrond kennen. Hij was ervan overtuigd dat echt betrouwbare software maar gemaakt kon worden als men wiskundige bewijzen kon voorleggen dat de code correct was. Hij heeft voor zover ik weet nooit beweerd dat OOP slechter was dan eerdere technieken, maar wel dat geen van de technieken die als "software engineering" bekend staan het niveau van die formele methode kunnen bereiken. Dijkstra is bekend van structured programming, maar ging daar dus pakken verder in dan wat men er vandaag van maakt (een paar regeltjes en geen goto statements gebruiken).
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1308.html
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html

En ja, ik weet dat die strikt formele methode niet echt praktisch is bij grote applicaties waarvan de specificaties wat kunnen veranderen.

Als je die redenering door trekt dan kan men stellen dat alle talen low level zijn omdat er altijd dingen zijn waarop men moet letten die irrelevant zijn voor het probleem domein zelf. Er bestaat geen taal waarin je perfect kan uitdrukken wat je wil doen, zonder hier en daar over irrelevante dingen te struikelen. Dit wel op voorwaarde dat de complexiteit van het probleem voldoende groot is.

Wel, dat is eigenlijk de reden waarom je in Lisp nog steeds s-expressions hebt (de lawine van haakjes) en de m-expressions (Lisp met het uitzicht van wiskundige formules, lijkt een beetje op Haskell) zo goed als vergeten zijn: de s-expression vorm maakt het mogelijk om, in combinatie met het macro-systeem, zowat alle mogelijke functionaliteit die je nodig hebt aan de taal toe te voegen, zonder echt nieuwe syntax te moeten introduceren.

Vermits deze thread gestart werd door een beginnend programmeur op zoek naar een volgende taal zal ik er maar meteen bij vermelden dat Lisp, ondanks de voordelen, niet meteen een voor de hand liggende keuze is omdat de huidige implementaties ofwel duur zijn, ofwel niet rechtstreeks toegang bieden tot een hele hoop moderne libraries waar je waarschijnlijk wel gebruik van zou willen maken.

Waarom is volgens U een gigantische applicatie noodzakelijk ook monolithisch?
Voor jou lijkt dat misschien zo (is het door de GUI?), maar kwa architectuur is dat helemaal niet zo.

De GUI is een factor. Als je een GUI maakt moet je er eigenlijk voor kunnen zorgen dat alle functionaliteit die de gebruiker nodig heeft via die GUI bereikbaar is. De GUI moet dus gemaakt worden op basis van kennis van vele componenten van het systeem. Met de commandline kan je eigenlijk het samenstellen van het hele systeem uitstellen: als de gebruiker een interactie van enkele componenten nodig heeft maakt de gebruiker zelf wel de combinatie met een pipe of scriptje.

Ik heb het hier nu al dagen over 'software engineering' en 'dat OOP hiervoor het beste resultaat geeft'... Als shell scripte'kes schrijven daar nu ook al onder valt. Goe bezig.

Wat ik eigenlijk bedoelde was dat het een vergissing zou zijn om het grote software-engineering kanon boven te halen als een simpel scriptje volstaat

Ik ben zeer goed op de hoogte van UNIX systemen hoor. Ik ontwikkel multi-platform software. Als voorbeeld, ik wil jou met je structured programming stijl eens een GUI framework zin schrijven dat platform onafhankelijk is. Veel plezier ermee. :ironic:

Dat de meesten geen terminals meer kennen of geen shell scripts kunnen schrijven? Dat weet ik niet hoor, in jou omgeving is dat misschien zo maar ik zou toch maar oppassen met dat te veralgemenen.

Met uitzondering van basis-VB gebruikers zullen de meeste programmeurs het wel kennen. Het probleem is dat ze niet zomaar kunnen veronderstellen dat de gebruikers van de software ervan op de hoogte zijn.

Dat had je dus in het begin al moeten zeggen. Ik heb altijd gezegd dat voor kleinere applicaties andere technieken 'leefbaar' kunnen zijn (lees mijn posts maar terug als je wil).

Maar wat ook gezegd werd:

Jormungand zei:
Neen, het enigste wat ik wou overmaken is dat OOP niet ALTIJD DE oplossing is en men telkens opnieuw de overweging moet maken, want dat loont soms de moeite, zeker als je de volledige levenscyclus in 't oog houdt.

Klik om te vergroten...

Ik ben er zeker van dat jij ook wel nut ziet in OOP, maar met bovenstaande quote ben ik niet akkoord. Zelfs voor kleine projecten is OOP nuttig, OOP is imho altijd nuttig. In kleine projecten zijn er altijd stukken die misschien nog ergens anders hun nut kunnen bewijzen. Daarom, gebruik OOP en code for reuse and change.

Daar was ik het dus niet mee eens: de extra code die nodig is om volledig volgens OOP te werken si tijdverspilling als het project klein genoeg is om zonder die code ook een goed overzicht te behouden over het geheel.

Programmeren voor hergebruik, OK, zolang je er niet te ver in gaat. Sommigen die met dat advies geconfronteerd worden hebben de neiging voor de meest eenvoudige componenten allerlei methoden toe te voegen voor het geval ze ooit eens nodig zouden zijn. Mijn mening over hergebruik: bouw geen onnodige beperkingen in, maar wacht met het inbouwen van extra functionaliteit tot je ze echt nodig hebt (ook omdat dan pas echt duidelijk wordt hoe het precies moet werken). Als je functies of objecten moet maken voor anderen heb je die luxe natuurlijk niet, en kan je maar hopen dat de overeengekomen specificatie alles goed voorzien heeft.

Jormungand · 8 nov 2005

Het gaat erom dat al de afzonderlijke commando's die je gebruikt in je shell scripts geschreven zijn in plain old C. En dat is in dit geval zeker geen slechte keuze, net zomin als het feit dat de kernel van zowat elk OS geschreven is in C. OOP gebruiken voor high level toepassingen is ok, maar voor low-level zaken zou ik ook eerder geneigd zijn naar C terug te grijpen. Zeker aangezien iets als een command line tool doorgaans klein, makkelijk te onderhouden en goed op te volgen is. Of vallen een kernel en basis command line apps ook al niet onder software engineering volgens uw "visie"?

Command line tools kan je zowat vergelijken met een algorithme dat verpakt is in een command line doosje. Zulke programmaatjes zijn (zeer) goed in een bepaalde taak. Ze draaien typisch ook slechts een korte tijd, dat is nu eenmaal een eigenschap van command line tools. Vaak zijn ze inderdaad ook in C geschreven, waar ik overigens geen probleem mee heb hoor. Door de aard van zulk een programmaatjes is het niet echt een groot probleem als er bv. hier en daar een resource leak in zit. Ze draaien typisch toch maar een zeer korte, net lang genoeg om hun taak te doen en output te genereren. Het enigeering aspect is hier dus veel minder aanwezig. Vergelijk het met een huis bouwen en een tuinhuisje in elkaar knutselen. In het eerst geval heb je veel planning en een architect nodig, ik het tweede geval kan je de klus, als je wat handig bent, gewoon in je eentje klaren.

Een kernel is een ander verhaal, vele kernels zijn vaak eerder ontstaan dan eender welke OOP taal. Het is nogal logisch dat ze dan ook in C zijn geschreven. Dan zit men ook nog met het feit dat je dat niet zomaar kan veranderen van de ene dag op de andere, en dat is in mijn ogen ook niet nodig. Sommige nieuwere stukken van de windows kernel zijn wel in C++ geschreven, hoewel de buitenkant een C API is, voor dezelfde redenen. Dit is op zich helemaal geen probleem. Ik heb geen enkel probleem met een C API als interface naar OS funtionaliteit. Het is dan volgens mij ook wat makkelijker om bovenop die C API een generieke, cross-platform OO layer op te ontwikelen.

Ik heb wat moeite met uw ophemelen van OOP als dè wonderoplossing, wat het dus helemaal niet is. Voor sommige zaken is het de goede oplossing, voor andere dan weer totaal niet. Eigenlijk kan je het vergelijken met de hele OS vs OS discussie, voor het ene probleem is het ene OS beter geschikt dan het andere. Het komt dus eigenlijk - zoals steeds - neer op het kiezen van "the right tool for the right job".

Waarom zou je die zelf moeten ontwikkelen als Gtk al bestaat?

We hebben daar goede redenen voor. Het is ook niet aan jou om die vraag te steleln, je weet immers niet eens de aard van de applicaties die we ontwikkelen.

azerty · 8 nov 2005

dJeez zei:
Ik heb wat moeite met uw ophemelen van OOP als dè wonderoplossing, wat het dus helemaal niet is. Voor sommige zaken is het de goede oplossing, voor andere dan weer totaal niet. Eigenlijk kan je het vergelijken met de hele OS vs OS discussie, voor het ene probleem is het ene OS beter geschikt dan het andere. Het komt dus eigenlijk - zoals steeds - neer op het kiezen van "the right tool for the right job".

Dat is nu een perfect uitgelegd wat ik bedoel en wou overmaken...

Moto · 9 nov 2005

In OO is het gewoon idd de kwestie van een goede balans te vinden

Ik kom veel mensen tegen die rond elk klein ding een interface willen schrijven zodat ze der later iets anders kunnen inpluggen.
Of mensen die hun objecten te klein houden en zo zichzelf in de nesten werken.
Dan nog maar te zwijgen van die "programmeurs" die denken dat hun programma enkel maar goed is als ze elk mogelijk design pattern dat er bestaat in hun code steken :ironic:
goed voorbeeld daarvan is dit -> http://www.phppatterns.com/docs/design/hello_world_in_patterns

Als ge aan echte produkt-ontwikkeling doet moet ge zeker zo goed mogelijk OO gebruiken.
Maarja ik doe projecten voor klanten, "overbodige" OO kost dan gewoon teveel tijd

Tyfius · 9 nov 2005

Zoals hier al een aantal keer is aangehaald, OO heeft zen nut, maar moet goed gebruikt worden en wanneer het nodig is.
Op school ga je altijd OO leren, en voor die kleine apps is dat allemaal zo goed als nutteloos, ben je veel sneller van dat allemaal basic te doen natuurlijk. En daar knappen de meesten op af "OO is nutteloos" akkoord, maar 2 maand later krijgen ze een project, dat groot is, en je min of meer OO gaat moeten aanpakken, of het loopt in het 100.

Jormungand · 9 nov 2005

@Moto

Of mensen die hun objecten te klein houden en zo zichzelf in de nesten werken.

Dit trekt mijn aandacht, leg dat eens even uit met een voorbeeld...

killgore · 9 nov 2005

Jormungand zei:
@Moto

Dit trekt mijn aandacht, leg dat eens even uit met een voorbeeld...

kdenk dat em bedoelt dat ze het TE algemeen willen houden en bv. 20 afgeleiden gebruiken voor eigenlijk 1 ding

.

Emerxill · 10 nov 2005

Tyfius zei:
Zoals hier al een aantal keer is aangehaald, OO heeft zen nut, maar moet goed gebruikt worden en wanneer het nodig is.
Op school ga je altijd OO leren, en voor die kleine apps is dat allemaal zo goed als nutteloos, ben je veel sneller van dat allemaal basic te doen natuurlijk. En daar knappen de meesten op af "OO is nutteloos" akkoord, maar 2 maand later krijgen ze een project, dat groot is, en je min of meer OO gaat moeten aanpakken, of het loopt in het 100.

Ik wou net ne reply zetten met just et zelfde

.
Op school kregen wij ook OOP, en in het begin dacht ik zoals 95% van de aanwezigen "wat is mij dat voor nutteloze rotzooi, dat kan toch een pak sneller en anders". En zeker als de docent daar vanvoor zelf niet heel goed kon uitleggen welk nut OO nu precies had.
Daarna las ik elders dat in andere situaties OOP zeker zijn nut had en waarom. Beetje gelijk Jormungand, maar niet in die mate

.

Daarna ben ik in elk klein programma-tje dat ik schreef OOP zo goed mogelijk proberen toe te passen, kwestie van et aan door te hebben.
Doen ik afstudeerde was er 1/4 (slechts!) die fatsoenlijk doorhad waarvoor OO dienden en dit ook beheerste. (de fout van de school). Der waren er zelfs die doorgeraakten op hun J2EE examens zonder OO ook maar ergens te gebruiken :wtf:

Dus ik kan ergens wel begrijpen dat er veel zo "anti" OO zijn...

Ik heb nu niet de ervaring gelijk sommigen hier om hele verhandelingen neer te pennen (en verhandelingen te schrijven om te verhandeling van de andere te bekritiseren

).
Maar ik heb een project gedaan waar ik enerzijds hoofdzakelijk in vba-excel moest (twas van te moeten :doh: ) programmeren. Dat was meestal in bestaande code prullen. En af en toe kleine toolkes in excel maken. Dat allemaal door gewoon procedureel te proggen. (procedureel omdat et zo snel moest gaan, af en toe heb ik geprobeerd om der ne OO-swung aan te geven, maar dat was telkens hopeloos de mist in gegaan

)
En langs de andere kan had ik ne tool geschreven in J# om die excel bestanden in te lezen en te verwerken. Dit geheel door OOP te werken.
Nu, als mij vroegen om iets toe te voegen aan dat toolke geschreven in J# was dat absoluut geen probleem.
Maar als ik iets moest aanpassen of toevoegen in de vba-excel geschreven bazaar :eek:

begint ma (niet onmogelijk, verre van, ma ik heb toch gevloekt

). En dat was dan nog op relatief kleinere schaal eh...

Duffman- · 10 nov 2005

Jormungand zei:
Persoonlijk vind ik VB een taalje voor de kinder programmeurtjes onder ons, maar dat even ter zijde...

Ze leren mij op school VB.NET aan. Wilt ge nu eigelijk zegge dak daar later niks mee ben? Waarom is dat een taal voor kinder programmeurtjes vind jij?
Als ze mij dat aanleren heb ik toch al wel een mooie basis voor andere (mss betere) programmeertalen? Zoals C++ ofzo?

dJeez · 10 nov 2005

Duffman- zei:
Ze leren mij op school VB.NET aan. Wilt ge nu eigelijk zegge dak daar later niks mee ben? Waarom is dat een taal voor kinder programmeurtjes vind jij?

Wellicht wegens een overdreven superioriteitsgevoel en het vergeten van z'n eerste stapjes in de informaticawereld, doch dit volledig terzijde

.

VB (en eigenlijk basic in het algemeen) kan echter wel degelijk een struikelblok zijn (je kan er nl. veel slechte gewoontes aanleren), maar het is niet onoverkomelijk om later het nodige inzicht te krijgen en van die slechte gewoontes af te stappen. Om niet uit de biecht te klappen (beroepsgeheim bestaat ook bij ITers

) kan ik wel stellen dat Jormungand wel eens verbaasd zou kunnen staan van wat er bij sommige banken draait (of op z'n minst draaide) voor oa. het beheer van Luxemburgse kasbons en als noodoplossing om hypotheekaanvragen af te handelen. Om het duidelijk te stellen : het was nog erger dan een VB applicatie, en hoorde eerder bij de "huis-, tuin- en keuken"-applicaties thuis, maar was op specifieke vraag van de klant daarin ontwikkeld (en klant is nu eenmaal koning bij detachering, ben ik blij dat ik daarvan af ben

).

BTW We spreken dan over de periode net voor en na Y2K, dus zo erg lang is dat nog niet geleden.

Jormungand · 10 nov 2005

Ik weet dat er nog steeds vaak VB gebruikt wordt (tot mijn grote spijt). Ik vind VB een kindertaaltje omdat de taal zo beperkt is en een groeibodem is voor slechte code en gewoontes. Voila nu weet je het. En ik weet ook dat er in de praktijk heel veel geprutst en gekloot wordt, vaak het gevolg door harde deadlines.

killgore · 11 nov 2005

dJeez zei:
Wellicht wegens een overdreven superioriteitsgevoel en het vergeten van z'n eerste stapjes in de informaticawereld, doch dit volledig terzijde .

Met alle respect voro uw eerste stapjes in informaticawereld en zo, ma da heeft niets te maken met het feit da ge vb een kindertaal noemt ze

. Da mag zelfs uw allereerste taal geweest zijn en op dat moment geniaal geleken hebben, als jij later meer ervaring hebt en dat een kindertaal noemt is da maar vrij normaal

.

VB.NET heeft zen voordelen op ontwikkelingsvlak (snel ontwikkelen van sommige applicaties), ik vind het echter een ramp op programmatievlak.

dJeez · 11 nov 2005

Ik vind het ronduit belachelijk van talen zomaar als kindertaal te gaan bestempelen omdat hun syntax eenvoudig is. Er is ook wel wat degelijke soft geschreven in VB(.Net). Precies of de taal die je gebruikt doet ertoe, het is het resultaat dat telt. En ja, VB heeft zo zijn beperkingen en kàn slecht gebruikt worden (en ja, ik durf het zelf ook al eens Viezen Basic te noemen), maar dat belet niet dat het ook op een correcte manier benut kan worden. Net zoals je in C# pokkeslechte code kan schrijven, wat programmatie betreft ligt de eindverantwoordelijkheid bij de programmeur en niet zozeer bij de taal die je hanteert.

Ik heb trouwens maar 1x zelf VB gebruikt, in 't kader van een groepsproject op school omdat de anderen in de groep niets anders kenden (dat was VB3 denk ik - 't is al lang geleden...).

Zo zijn er ook behoorlijk wat die neerkijken op scripting talen (Javascript, PHP, Perl, Python ed meer), welnu die hebben ook hun nut, en kunnen inderdaad slecht, maar ook goed gebruikt worden. Dat hoeft daarom niet te betekenen dat je direct maar moet spreken over een kindertaaltje (dat is eerder iets als Logo in mijn ogen - maar zelfs dat taaltje heeft dan weer zijn nut om kinderen spelenderwijs wat logica bij te brengen). Ik vind het eerder getuigen van een gebrek aan respect voor anderen en een iets te groot aangemeten ego.

Duffman- · 11 nov 2005

Maar als ik binnen enkele jaren voort wil studeren, en ik leer programmeren in andere talen. Is mijn opleiding VB.Net dan volledig nutteloos?
Is er al niet een soort logica die ik eraan overhoud die ik in andere talen nog kan gebruiken?

Tyfius · 12 nov 2005

Dat hangt ervan af hoe goed of hoe kwaad jou nu VB.NET wordt aangeleerd. Zoals reeds gezegd, dit kan op een goede manier, waardoor je de principes gaat kunnen doorhebben en het aanleren van een nieuwe taal vooral syntax en denk gebaseerd is (cfr de arrays die in elke andere taal vanaf 0 beginnen, en in VB vanaf 1).

Indien je dit slecht wordt aangeleerd (en geloof mij, er zijn zeer VB.NET programmeurs die hun taal de beste vinden en ook vrij slechte gewoontes aanleren en doorgeven als leerkracht) en dan gaat de stap naar andere talen iets moeilijker zijn.

edit: :offtopic:

signature rules

alva848 · 12 nov 2005

Arrays in VB.NET zijn zero based.

Bubbling Zombie · 12 nov 2005

Duffman- zei:
Maar als ik binnen enkele jaren voort wil studeren, en ik leer programmeren in andere talen. Is mijn opleiding VB.Net dan volledig nutteloos?
Is er al niet een soort logica die ik eraan overhoud die ik in andere talen nog kan gebruiken?

Imo niet, als je nu een goede methodiek aankweekt. Wij hebben ook ooit vb.net gehad, maar ik raak dat nu niet meer aan (not even with a fifty foot pole). Heb er wel veel over geleerd aangaande algemene theorie achter OO, omdat je geen aandacht moet geven aan de syntax (allez, jawel, maar ge snapt wel

).

Archief - [ALG] hoe verder gaan

wlibaers

Legacy Member

Jormungand

Legacy Member

dJeez

Legacy Member

wlibaers

Legacy Member

Jormungand

Legacy Member

azerty

Legacy Member

Moto

Legacy Member

Tyfius

Legacy Member

Jormungand

Legacy Member

killgore

Legacy Member

Emerxill

Legacy Member

Duffman-

Legacy Member

dJeez

Legacy Member

Jormungand

Legacy Member

killgore

Legacy Member

dJeez

Legacy Member

Duffman-

Legacy Member

Tyfius

Legacy Member

alva848

Legacy Member

Bubbling Zombie

Legacy Member