sciencetalk

Wat heeft de toekomst, relationele data of object georienteerde data.

Of zijn concepten, die beiden combineren (The best of both worlds)?

Hoewel wiskunde hier natuurlijk erg meespeelt, lijkt me dit in hoofdstuk een informaticadomein.

Ik verplaats het dan ook naar daar, moest het eerder wiskundig uitdraaien, dan kan het terug.

Object georienteerde data bestaat niet. Object georienteerd ontwerpen wel.

Voor grote ontwerpen (met veel mensen) is object georienteerd werken ideaal. Ieder werkt aan zijn eigen stukje binnen een groot ontwerp. Eigenlijk hebben goede programmeurs (die zijn zeldzaam!) altijd naar een object georienteerde werkwijze gestreefd. Ook binnen een taal die niet object georienteerd opgezet is kun je modulair werken (in essentie is dit oo).

Voor kleine klusjes is oo echter niet nodig.

Ik weet niet wat je je bij relationele data voorsteld. Ik ken wel relationele databases. Dat heeft weinig met het begrip oo van doen. Maar ook het opzetten van een database kan oo. Er zijn tegenwoordig programma's waarin je relationele databases object georienteerd kunt opzetten.

Ik vermoed dat men in de toekomst, nu we meer en meer de von neuman architecture verlaten ook de hierbij passende imperatieve talen zullen verlaten.

In de plaats komen dan functionele talen die natuurlijk ook oop ondersteunen, maar dan overeenkomstige de oorspronkelijke en ruimere smalltalk of de nog ruimere self interpretatie.



Daarnaast zullen continuations (call with current continuation) en language oriented programming belangrijker worden. Denk bij LOP aan bijvoorbeeld macros, interpreters, en compilers); Elk significant programma is eigenlijk een eigen programmeer taal en diens interpreter/compiler.

Zie ook Domain Specific language

Ieder werkt aan zijn eigen stukje binnen een groot ontwerp. Eigenlijk hebben goede programmeurs (die zijn zeldzaam!) altijd naar een object georienteerde werkwijze gestreefd. Ook binnen een taal die niet object georienteerd opgezet is kun je modulair werken (in essentie is dit oo).

Eerlijkgezegd vind ik het vermeende voordeel van OO bij samenwerking wat overdreven. Bij procedureel opgezet programmeerwerk kunnen mensen ook los van elkaar werken aan (sets van) functies, en zolang er maar goede conventies en documentatie bestaan over bijv de argumenenten en returns daarvan is procedureel werken geen belemmering. In de praktijk is dat voor OOP niet zoveel anders.

Maar het verschilt ook wel per toepassingsgebied natuurlijk. Zelf werk ik vrij veel met webgerichte programmatuur (scripting, zogezegd), daarbij is procedureel werken onverminderd populair. Wellicht komt dat ook omdat veel webapplicaties een relatief kleine codebase hebben, en je het overzicht daarover niet zo 123 verliest?

Of we echt de imperatieve talen vaarwel zullen zeggen betwijfel ik (althans voor laten we zeggen de komende 100 jaar).

Of functionele talen hun rol zal overnemen betwijfel ik. Hun rol zal wel groter worden, maar zal de imperatieve talen niet verdringen zolang er toepassingen blijven waarvoor de eerste meer geschikt zijn.

En voor de functionele talen echt zijn doorgebroken is er vast wel weer een nieuw paradigma in zwang.

Benm schreef:Eerlijkgezegd vind ik het vermeende voordeel van OO bij samenwerking wat overdreven. Bij procedureel opgezet programmeerwerk kunnen mensen ook los van elkaar werken aan (sets van) functies, en zolang er maar goede conventies en documentatie bestaan over bijv de argumenenten en returns daarvan is procedureel werken geen belemmering. In de praktijk is dat voor OOP niet zoveel anders.

Maar het verschilt ook wel per toepassingsgebied natuurlijk. Zelf werk ik vrij veel met webgerichte programmatuur (scripting, zogezegd), daarbij is procedureel werken onverminderd populair. Wellicht komt dat ook omdat veel webapplicaties een relatief kleine codebase hebben, en je het overzicht daarover niet zo 123 verliest?

Als je wel eens gewerkt hebt aan een project waaraan een paar honderd IT-ers aan meewerken, dan ga je begrijpen waarvoor OO dient. Je begrijpt toch wel dat dat niet kan door een verzameling van functies te maken.

Hoe dan ook denk ik dat men het idee van een groot ontwerp vooraf zal laten varen.

In de praktijk doet men dat tegenwoordig al vrijwel niet meer bij originele software: Programmeren is ontwerpen en men ontwerpt (en herontwerp) terwijl men bezig is en al doende leert en ontdekt wat nu werkelijk het probleem is. Wat dat betreft is programmeren geheel anders dan architectuur/bouwen of andere vormen van 'engineering' en lijkt het meer op tuinieren.

Slechts bekende problemen kan met vooruit plannen en laten doen door 100den programmeurs.

qrnlk schreef:Hoe dan ook denk ik dat men het idee van een groot ontwerp vooraf zal laten varen.

In de praktijk doet men dat tegenwoordig al vrijwel niet meer bij originele software: Programmeren is ontwerpen en men ontwerpt (en herontwerp) terwijl men bezig is en al doende leert en ontdekt wat nu werkelijk het probleem is. Wat dat betreft is programmeren geheel anders dan architectuur/bouwen of andere vormen van 'engineering' en lijkt het meer op tuinieren.

Slechts bekende problemen kan met vooruit plannen en laten doen door 100den programmeurs.

Bij OOP wordt van de voren niet alles dichtgespijkerd. Programmeren is inderdaad een leerproces, en al doende worden wijzigingen in ontwerp aangebracht, b.v. als eerdere plannen op problemen stuiten. Er zijn verschillende stadia van ontwerp. Al doende wordt er steeds verder ingezoemd. Ik zie hier geen onderscheid tussen vroeger, heden en later.

Slechts bekende problemen kan met vooruit plannen en laten doen door 100den programmeurs.

Nee, dat is niet zo. Die honderden programmeurs worden verdeeld in afdelingen. B.v. een groep voor de interface, een groep voor de databases, een groep voor de koppelingen. Je zult versteld staan van de hoeveelheid werk dat een groot project met zich meebrengt. Elke afdeling kent weer zijn eigen onderverdelingen; active-x controls ontwerpen, documentatie, coordinatie enz. enz.

Wat ik dus bedoelde is dat bij volledig originele problemen zelfs deze onderverdeling niet bekent is; Juist omdat je bezig bent met een probleem uit een bepaalde categorie weet je al zo ongeveer hier het verdeeld kan worden.

Of we echt de imperatieve talen vaarwel zullen zeggen betwijfel ik (althans voor laten we zeggen de komende 100 jaar).

Het kan soms snel gaan. Op dit moment worden bijvoorbeeld switches al geprogrammeerd in een concurrent/functionele taal (

Of functionele talen hun rol zal overnemen betwijfel ik. Hun rol zal wel groter worden, maar zal de imperatieve talen niet verdringen zolang er toepassingen blijven waarvoor de eerste meer geschikt zijn.

Imperatieve talen gaan uit van de von neumann architectuur. Ze gaan uit van een volgorde van uitvoer, zijn zijn

En voor de functionele talen echt zijn doorgebroken is er vast wel weer een nieuw paradigma in zwang.

Ik neem niet aan dat men het 'functioneel programmeren' zal noemen, mogelijk niet eens 'concurrent programmeren', maar het zal wel gebruik maken van de deze basis.

Zie Structure and Interpretation of Computer Programs voor meer informatie.

Als je wel eens gewerkt hebt aan een project waaraan een paar honderd IT-ers aan meewerken, dan ga je begrijpen waarvoor OO dient. Je begrijpt toch wel dat dat niet kan door een verzameling van functies te maken.

Bij projecten van die omvang is het een ander verhaal, maar aan de andere kant zijn dergelijke projecten erg zeldzaam... want zeg zelf, welke applicatie vereist een team van 100+ programmeurs?

B.v. een groep voor de interface, een groep voor de databases, een groep voor de koppelingen. Je zult versteld staan van de hoeveelheid werk dat een groot project met zich meebrengt.

Volgens mij komt dat inderdaad wel veel voor, splitsen in blokken die min of meer los van elkaar te ontwikkelen zijn. Uiteraad lever je wel efficiency in omdat je ook weer mensen moet inzetten om het allemaal aan elkaar te rijgen, maar dat is denk ik inherent aan grote projecten, ongeacht welke methodes je gebruikt.

Wat ik dus bedoelde is dat bij volledig originele problemen zelfs deze onderverdeling niet bekent is; Juist omdat je bezig bent met een probleem uit een bepaalde categorie weet je al zo ongeveer hier het verdeeld kan worden.

Ik werk op het moment zelf aan een groot project, waar veel mensen aan deelnemen. Ikzelf zit bij de afdeling interfaces waar zo'n 20 man werken aan hetzelfde project.

Aan het eigenlijke programmeren ging een ontwerpfase vooraf die een half jaar in beslag heeft genomen.

Ik kan door geheimhoudingsplicht er helaas niet meer van zeggen.

Ik zie zeker wel de voordelen van concurrent programming bij veel toepassingen, maar heel veel toepassingen zijn lineair.

Als functioneel programmeren het ei van Columbus was geweest, dan was het al veel sneller gemeengoed geworden, want geheel nieuw is het idee al lang niet meer. Het zou echter kunnen dat de oorzaak ligt in de grote denkomslag die bij 'oude' programmeerbazen nodig is.

Estetisch staan functionele talen ver boven imperatieve talen. Als het daar om gaat sta ik achter je.

Ik denk dat het meer te maken heeft met de programmeurs pool: Zolang de meerderheid van de programmeurs alleen maar imperatieve talen kent zal een manager het amper aan durven om een programma te ontwikkelen in een functionele taal. Een manager wil graag de zekerheid dat hij zijn personeel kan vervangen indien dit nodig is. Managers staan nu ook niet direct bekend om hun moed om geheel nieuwe dingen te doen, dus meestal beperken dezen zich tot bekende systemen en methodieken.

Functionele talen zullen eerder hun plaats vinden in startups waar andere belangen meespelen en waar het meestal de programmeurs zelf zijn die hun eigen tools (waaronder de taal) kiezen. Hier worden risico's gemakkelijker genomen en worden nieuwe methoden sneller uitgeprobeerd. Een kleine startup kan gewoon niet op dezelfde manier werken als een groot bedrijf: Het moet wel een andere methode gebruiken en een functionele taal kan hierbij als 'langere hefboom' dienen.

Btw een andere zeer opmerkelijk verschijnsel is dat de meeste mensen die zich aangetrokken voelen tot computers en programmeren gemakkelijker imperatief kunnen leren programmeren dan mensen die computers slechts als gereedschap zien. Voor deze laatste groep is functioneel programmeren veel gemakkelijker dan imperatief programmeren.

Je ziet bijvoorbeeld Lisp gebruikt worden in de bioinformatica, wat volgens mij een zeer opmerkelijke ontwikkeling is.

Merk btw op dat SQL strict genomen geen relationele taal is en er worden steeds meer oo-databases ontwikkeld. Dezen zijn echter meestal intern in het programma inplaats van extern in een apart programma.