[Alg] Lineair Programmeren vs OO*

[Verwijderd]

He, ik moet voor school een PO maken over Lineair Programmeren vs. Object Oriented Programmeren. Door omstandigheden (vakkenwijzigingen enzow) heb ik achterstanden moeten inhalen en heb dus weinig tijd gehad voor deze PO. Hij moet vrijdag al af (om 24.00).
Mijn probleem is nu: ik kan helemaal niks vinden over Lineair Programmeren. Als ik bij zoekmachines zoek dan krijg ik alleen maar wiskundige onzin enzo en daar heb ik dus niks aan. Ik weet wel een beetje wat het is volgens mij: het doorlopen van een grote lap tekst achter elkaar zonder bepaalde objecten ofzo. Ik zoek echter nog wat eigenschappen en een geschiedenis of zoiets.
Wie helpt mij?

[.oisyn]

bedoelen ze niet procedureel programmeren?
lineair programmeren is idd heel wat anders dan ze bedoelen

.edit: wheehehe trage belg

[ Voor 15% gewijzigd door .oisyn op 19-02-2003 17:48 ]

[whoami]

Ik denk ook dat je eerder eens procedureel programmeer moet zoeken....

[Verwijderd]

tip: procedureel programmeren is bijvoorbeeld PHP (je kan er wel met oop aanklooien, maar wordt niet veel gebruikt), en oop is bijv. java (maar ik denk dat je die al wist )

[kvdveer]

Geinig, ik ben nu voor de uni bezig met lineair programmeren. Best pittig hoor, maar ik zou niet weten hoe er een verband getrokken kan worden tussen lineair programmereen en objectgeorienteerd ontwikkelen. Een beetje appels en asperientjes vergelijken is dat:+

[Soultaker]

Nog een term: imperatief programmeren.

Lineair programmeren slaat meestal op het algoritmisch oplossen van lineaire stelsels (en allerlei problemen die daarop terug te voeren zijn).

[Verwijderd]

kvdveer schreef op 19 February 2003 @ 19:27:
Geinig, ik ben nu voor de uni bezig met lineair programmeren. Best pittig hoor, maar ik zou niet weten hoe er een verband getrokken kan worden tussen lineair programmereen en objectgeorienteerd ontwikkelen. Een beetje appels en asperientjes vergelijken is dat:+

Het gaat hier ook niet om de verbanden tussen die twee, maar juist de verschillen....

[The Eagle]

Zoek maar eens op iets als 3GL versus 4GL. Dat zou je een eind verder moeten helpen. Verder kan ik je het boek "Programming Language Essentials" van Henri E. Bal en Dick Grune aanbevelen (ISBN 0-201-63179-2 , boek is in het engels).

Ik wens je veel suc6; ik heb tijdens mijn studie die stof ook moeten doorbijten en ik kan je zeggen: die was behoorlijk taai!

[Soultaker]

Verwijderd schreef op 19 februari 2003 @ 20:33:
Het gaat hier ook niet om de verbanden tussen die twee, maar juist de verschillen....

Bij een vergelijking ga je meestal uit van twee dezelfde soort dingen ("vergelijkbare" dingen). Je kunt twee soorten auto's vergelijken, en dan bepalen welke zuiniger rijdt, of meer vermogen heeft. Maar het vergelijken van een auto met een potje pindakaas is vrij zinloos.

[dusty]

OO: "event handled", lineair niet.

grootste verschil in mijn mening

[Verwijderd]

bedoel je lingo ?

[red bull]

Misschien zelfs wel lindo !

[whoami]

HK replies hou je maar in de HK

[whoami]

Ervan uitgaan dat je proceduraal bedoelt ipv lineair.

OO :
hiermee kan de programmeur eigen data-types definieren en op een abstractere manier gaan denken, ttz, een manier die meer naar de werkelijkheid aanleunt. je kunt bv een eigen datatype 'WErknemer' maken, met alle gegevens en operaties die je op die werknemer kunt uitvoeren.
Belangrijkste eigenschappen van een OO taal (imho):
- data encapsulation
- inheritance
- polymorphisme
- data hiding

[Soultaker]

whoami schreef op 19 februari 2003 @ 22:06:
HK replies hou je maar in de HK

Hoe kan dat nu? Er is immers geen huiskamer meer.
Je beseft je trouwens wel dat Lingo/Lindo tools zijn om lineair mee te programmeren? Het maakt de opmerking van red_bull niet veel zinniger, maar plaatst Tizzwat's reactie misschien in een wat ander licht.

dusty schreef op 19 February 2003 @ 21:52:
OO: "event handled", lineair niet.

grootste verschil in mijn mening

Zou je dat een beetje uit willen leggen? Ik snap namelijk niet echt hoe je dit bedoelt.

[ Voor 10% gewijzigd door Soultaker op 19-02-2003 23:00 ]

[T-Blizzard]

Hmzzz wat wij met lineair programmeren hebben das idd wiskunde
Problem solving

[.oisyn]

Soultaker schreef op 19 February 2003 @ 22:59:
[...]

Hoe kan dat nu? Er is immers geen huiskamer meer.

lees MED: HK weer open

[dusty]

Soultaker schreef op 19 February 2003 @ 22:59:
Zou je dat een beetje uit willen leggen? Ik snap namelijk niet echt hoe je dit bedoelt.

Bij OO werk je meer "event" gericht.

[Expander]

Als je niet met OO werkt, werk je met processen en entiteiten..

Bij het ontwerp vóór linair programmeren worden vaak diagrammen gemaakt als:
- Data Flow Diagrams
- Entity Relationship Diagrams (ook voor databases handig)
- State Transition Diagrams

Zoals de namen al zeggen, gaan deze hulpmiddelen over het structureren van 'platte' processen en toestanden.

Dit tegenover het dynamische karakter van OO, waarbij UML heel handig is.

[mbravenboer]

Ik vind het wel grappig dat OO hier meer dynamisch en event georienteerd genoemd wordt. Op zich zit er natuurlijk in alle opmerking best wat waarheid, maar ik denk dat je het verschil met procedureel programmeren toch ook niet moet overdrijven. De belangrijkste punten zitten toch in het groeperen van data met operaties op die data en het verbergen van data voor de boze buitenwereld. Het event idee met messages is op meta level nog wel aardig.

[TimMer]

The_Eagle schreef op 19 februari 2003 @ 20:40:
...
Verder kan ik je het boek "Programming Language Essentials" van Henri E. Bal en Dick Grune aanbevelen (ISBN 0-201-63179-2 , boek is in het engels).

Zo, HHS gedaan?

[whoami]

Sorry, voor m'n bovenstaande warning als die opmerkingen erboven toch nog zo geen HK-gehalte hebben.

Back on topic nu:
Dark_Phalanx: heb je het nu echt over lineair programmeren, of bedoel je eerder proceduraal programmeren?

[EfBe]

OO: Data-georienteerd, niet op functies georienteerd.
Procedureel: gericht op functies, niet op data georienteerd.

Zo moeilijk is het niet.

[Zoijar]

TimMer schreef op 19 februari 2003 @ 23:58:
[...]

Zo, HHS gedaan?

Ik heb op de uni ook tentamen over dat boek gedaan...achtje

Lineair programmeren ligt dicht bij operations research, als je daar meer over wilt weten "Modelbouw in de operations research - Tijms, Kalverlagen". Maar je zal wel imperatief bedoelen idd.

[Verwijderd]

In m'n PO opdracht staat echt duidelijk dit:

Lineair programmeren versus object-oriented programmeren:

Wat zijn de verschillen? Welke voordelen biedt OO-programmeren?

[gorgi_19]

offtopic:
PO, voor welke opleiding / studie is dat? Staat dit voor Praktische Opdracht voor de middelbare school? Zo ja, dan zit er een foutje in de opdracht, als hier niemand een normale link kan leggen.

[Zoijar]

Het foutje kan ook (nog extra) in OO-programmeren zitten, dat ze event-based bedoelen.

[ Voor 8% gewijzigd door Zoijar op 20-02-2003 10:17 ]

[VisionMaster]

gorgi_19 schreef op 20 February 2003 @ 10:14:

offtopic:
PO, voor welke opleiding / studie is dat? Staat dit voor Praktische Opdracht voor de middelbare school? Zo ja, dan zit er een foutje in de opdracht, als hier niemand een normale link kan leggen.

Dit is de vraag die in mijn hoofd speelde toen ik dit topicje aan het lezen was.
Ik vind het vermoeiend om nog steeds niet te weten waar het naartoe gaat met dit topic.
Een 3gl vs 4gl is extreem veel de revu gepaseerd. Search zou uitkomst bieden, evenals je het echt over linieair programmeren heb.

[mbravenboer]

Lineair Programmeren versus OO is gewoon grote onzin. Zelfs als je je zo flexibel opstelt om bijvoorbeeld aan concurrency te gaan denken, zijn beide systemen even lineair, dus dat kan ook niet bedoeld zijn.

Waarschijnlijk snapt de docent er gewoon niet zo veel van en bedoelt hij inderdaad Procedureel Programmeren, want dat is de vergelijking die het meest voor de hand ligt. Die vergelijking ligt dan ook gelijk zo voor de hand dat de opdracht vrij stompzinnig is .

[.oisyn]

Misschien was het een strikvraag en moesten de leerlingen hier zelf achter komen

[kvdveer]

Misschien gaat het over de inpassing van traditioneele procedurele algorimes (lineair programeren bijvoorbeeld) in oop-ongeving?
* kvdveer zoek zijn glazen bol maar eens op.

[Vuurvlieg]

Schrijf gewoon een stukje over lineair programmeren (dat wiskunde gebeuren), en een stukje over oop, en dan concludeer je dat ze totaal verschillend zijn, oop is een manier om te programmeren en lineair programmeren is bedoeld voor het oplossen van lineaire stelsels vergelijken.. kan hij nooit fout rekenen lijkt me..

[kvdveer]

Ik verwacht dat dit een middelbareschoolopdracht is. Een stuk schrijven over lineair programmeeren lijkt me dan wat hoog gegrepen.

[Rataplan]

Ik laat het lineaire programmeren even voor wat het is en beperk me tot het roepen van "Von Neumann-bottleneck" - procedureel programmeren verplicht de programmeur rekening te houden met het feit dat er maar n instructies tegelijkertijd kunnen worden uitgevoerd. Hier heb je met OO geen last van. Praktijkvoorbeelden mag je zelf verzinnen

edit:
1 door n vervangen voor die antlover hieronder OO is niet-sequentieel, procedureel wel.

[ Voor 39% gewijzigd door Rataplan op 20-02-2003 13:57 ]

[johnwoo]

Rataplan schreef op 20 februari 2003 @ 13:25:
Ik laat het lineaire programmeren even voor wat het is en beperk me tot het roepen van "Von Neumann-bottleneck" - procedureel programmeren verplicht de programmeur rekening te houden met het feit dat er maar 1 instructie tegelijkertijd kan worden uitgevoerd. Hier heb je met OO geen last van. Praktijkvoorbeelden mag je zelf verzinnen

Ik kan prima een multithreaded procedureel programma schrijven hoor, waarbij dus meerdere instructies 'tegelijk' (op een multiprocessing systeem is het pas echt parallel) worden uitgevoerd hoor...
Ik kan ook best een single-threaded OOP programma schrijven, waarbij dus altijd maar 1 instructie 'tegelijkertijd' wordt uitgevoerd... Ik snap dus niet echt wat je bedoelt _{Of je verwoordt het te vaag}

Daarnaast kan je in een procedurele taal ook best OOP proggen. Bijvoorbeeld in C, gezellig zelf je vtables enzo bij zitten houden Is wel nogal omslachtig en nutteloos, maarja, het kan wel

[whoami]

johnwoo schreef op 20 February 2003 @ 13:46:
[...]


Daarnaast kan je in een procedurele taal ook best OOP proggen. Bijvoorbeeld in C, gezellig zelf je vtables enzo bij zitten houden Is wel nogal omslachtig en nutteloos, maarja, het kan wel

Ik denk dat jij hier OO verwart met event-driven.
In een procedurele taal kan je niet OO proggen, anders zou het geen procedurele taal zijn. In C++ kan je zowel OO als procedureel proggen.
OO is, zoals EfBe al eerder zei, op data geconcentreerd.

[johnwoo]

whoami schreef op 20 February 2003 @ 13:49:

[...]


Ik denk dat jij hier OO verwart met event-driven.
In een procedurele taal kan je niet OO proggen, anders zou het geen procedurele taal zijn. In C++ kan je zowel OO als procedureel proggen.
OO is, zoals EfBe al eerder zei, op data geconcentreerd.

Op een wat hoger niveau niet, nee. Maar wat is een OOP programma nadat het door de compiler is gehengeld? Methods worden toch functies, waaraan je behalve de parameters, ook de pointer naar het stukje geheugen van het betreffende object meegeeft. Dat kun je dus wel simuleren in een niet-OOP taal.

Een C-struct met als member een functiepointer is ook al behoorlijk data-georienteerd (je kan iig dan een functie aanroepen op die struct). Verzin een manier om aan die 'memberfunctie' ook de (this) pointer naar het structje mee te geven, zodat die functie ook nog weet over welke struct de call gaat, en het is volwaardig OOP. Daarna kan je speeltjes als overerving gaan toepassen.

Nu ik erover nadenk, stel dat ik een C-struct van bepaalde grootte heb, die ik meegeef (of eigenlijk, het adres ervan) aan een functie. Pass ik er een grotere struct naartoe, waarvan de eerste member weer die originele struct is, dan is dat in feite een soort 'uitbreiding' op de originele struct. Dit zou je als een vorm van non-OOP overerving kunnen zien (je neemt iets, en breidt het uit in plaats van het geheel opnieuw te implementeren). Alleen is het natuurlijk veel makkelijker als je compiler dat allemaal voor je regelt

[whoami]

Tja, als je zo begint.... Strax ga je nog beweren dat je mbhv assembly ook nog OO kunt proggen.
Trouwens, OO is meer dan data encapsulation en overerving. Polymorphisme is een belangrijk aspect van OO. Of je dat kunt simuleren dmv de methode die jij geeft, weet ik niet...

[GrimaceODespair]

Over de discussie of het nou om Lineair of Procedureel (of evt nog Imperatief) proggen gaat, mss kan de topicstarter de originele opdracht es posten. Als ie tijd heeft natuurlijk, want het moet morgen af

edit:
lezen Grimace, lezen

[ Voor 12% gewijzigd door GrimaceODespair op 20-02-2003 14:17 ]

[Zoijar]

johnwoo schreef op 20 februari 2003 @ 13:59:

Nu ik erover nadenk, stel dat ik een C-struct van bepaalde grootte heb, die ik meegeef (of eigenlijk, het adres ervan) aan een functie. Pass ik er een grotere struct naartoe, waarvan de eerste member weer die originele struct is, dan is dat in feite een soort 'uitbreiding' op de originele struct. Dit zou je als een vorm van non-OOP overerving kunnen zien (je neemt iets, en breidt het uit in plaats van het geheel opnieuw te implementeren). Alleen is het natuurlijk veel makkelijker als je compiler dat allemaal voor je regelt

En zo werkt een C++ compiler dan ook vaak :-) Mijn eigen OO gc compiler output C in die vorm, met als eerste member van je struct dan een pointer naar een virtual table, om dynamic binding te implementeren. Kan je zo de output laten zien van een java achtig OO programma in C, beetje groot en ondidelijk alleen...

[GrimaceODespair]

whoami schreef op 20 februari 2003 @ 14:04:
Of je dat kunt simuleren dmv de methode die jij geeft, weet ik niet...

Als een compiler dat kan, dan kan C dat ook, aangezien je in C een compiler kunt schrijven.

[johnwoo]

whoami schreef op 20 February 2003 @ 14:04:
Tja, als je zo begint.... Strax ga je nog beweren dat je mbhv assembly ook nog OO kunt proggen.
Trouwens, OO is meer dan data encapsulation en overerving. Polymorphisme is een belangrijk aspect van OO. Of je dat kunt simuleren dmv de methode die jij geeft, weet ik niet...

Uhh.. ik zal m'n mond wel houden over assembly
Ik denk dat polymorphisme ook wel in C te implementeren valt (ok ok het is uiterst omslachtig vergeleken met hetzelfde proggen in C++) met een soort RTTI mechanisme. Geef een struct bijvoorbeeld een class identifier mee (GUID anyone? )

[ Voor 4% gewijzigd door johnwoo op 20-02-2003 14:17 ]

[CyBeRSPiN]

De verschillen zijn hier wel redelijk genoemd, maar het grote voordeel van OO is hergebruik van code!
Als je een klasse goed schrijft dan kun je die voor allerlei projecten gebruiken waarbij delen van code gelijk zijn (bijv. een Datum klasse)

[Rataplan]

whoami schreef op 20 februari 2003 @ 14:04:
Tja, als je zo begint.... Strax ga je nog beweren dat je mbhv assembly ook nog OO kunt proggen.
Trouwens, OO is meer dan data encapsulation en overerving. Polymorphisme is een belangrijk aspect van OO.

Volgens mij betoogt hij dat, gegeven het bestaan van de Von Neumann-bottleneck op de huidige generatie desktops, en gegeven dat niet mensen maar computers programma's uitvoeren, OO niet kan bestaan De boomstructuur van polymorphisme wordt uiteindelijk ook met calls naar specifieke functie-instances uitgevoerd, dus polymorphisme is ook een verzinsel

Johnwoo: de functionele omschrijving van een processor *is* een sequentiele - daar heb je gelijk in. De truc is om mensen een pragmatische benaderwijze te geven, en dat gebeurt dmv compilers. De structuur van de aan de compiler gevoerde code hoeft natuurlijk niet dezelfde te zijn als die van de uitgepoepte code. Over die structuurverschillen gaat het hier.

Anders moeten we het kort houden:

er bestaan twee instructies, ADD en BRANCH. ELK programma kan je daarin uitdrukken. Alles wat je verder hoort is een complot van de onderwijsmafia

Hmm, analoog daaraan zijn mensen dus even intelligent als baseparen. En ze hebben ook evenveel vingers

CyBeRSPiN schreef op 20 February 2003 @ 14:14:
De verschillen zijn hier wel redelijk genoemd, maar het grote voordeel van OO is hergebruik van code!
Als je een klasse goed schrijft dan kun je die voor allerlei projecten gebruiken waarbij delen van code gelijk zijn (bijv. een Datum klasse)

Dit lijkt mij flauwekul. Mijn eerste IT-boek - en dat zal Johnwoo deugd doen - is van ene meneer Rollins, en heet "8088 Macro Assembler Programming" - nuff said.

[ Voor 19% gewijzigd door Rataplan op 20-02-2003 14:23 ]

[johnwoo]

Rataplan schreef op 20 February 2003 @ 14:20:
[...]

Je hebt helemaal gelijk. Ik bedoelde alleen maar, dat over die vertaalslag die een OOP compiler doet, ook met een non-OOP taal wel heen te komen valt

Ik vind dit trouwens wel een interessant onderwerp, en ook een leuke discussie. Mag ook wel eens met al die PHP topics

[drZymo]

Zoals hier allang duidelijk is gemaakt (imho) is dat OOP niet gezien moet worden als een taal, want Object Georienteerde Programmeertalen zijn gewoon een schil over een mooie machine taal. Alles wat je in C++ kan maken kan ook in C, hetzij wat omslachtiger (en dus ook in assembler ). Zoals de heer Tanenbaum het mooi beschrijft. "Elke taal draait op een virtuele machine. Deze virtuele machine kan geimplementeerd zijn in directe hardware of geinterpreteerd zijn in een andere taal (die ook weer op een virtuele machine draait).".

OOP moet je ook niet zien als een taal maar gewoon een manier van denken. Mensen die OO denken, denken in objecten en niet in procedures. Ik zie OO daarom ook helemaal niet als je-van-het, want alles kan ook gewoon in C.

Dus ja zo denk ik er over

[.oisyn]

drZymo schreef op 20 February 2003 @ 14:31:
OOP moet je ook niet zien als een taal maar gewoon een manier van denken. Mensen die OO denken, denken in objecten en niet in procedures. Ik zie OO daarom ook helemaal niet als je-van-het, want alles kan ook gewoon in C.

lekker logisch. Eerst zeg je dat OO geen manier van programmeren is, maar een manier van denken. Dan zeg je dat je OO niet ziet als je-van-het, omdat het ook gewoon procedureel geimplementeerd kan worden. Maar die implementatie boeit nou juist niet, het gaat om de manier van denken, dat zeg je zelf

[Rataplan]

johnwoo schreef op 20 February 2003 @ 14:25:
(...) Ik bedoelde alleen maar, dat over die vertaalslag die een OOP compiler doet, ook met een non-OOP taal wel heen te komen valt

Ik snap je punt wel hoor Zo begrijp ik nog steeds niet waar UML nou precies goed voor is. Het voegt niks toe aan bestaande technieken, het doet er het zoveelste lollige jasje omheen.

Maar OO vind ik toch wel van een iets andere categorie, bijvoorbeeld gegeven .NET - ik denk dat binnen een paar jaar nauwelijks nog lokaal gerekend wordt, en iig niet meer gezien kan hoe je data tot stand komt - door berekening of invoer of weet ik veel wat. Benchen van systemen wordt dan bijvoorbeeld afhankelijk van remote caching, om eens een zijstraat te verzinnen

Ik vind dit trouwens wel een interessant onderwerp, en ook een leuke discussie. Mag ook wel eens met al die PHP topics

Eensch!

[whoami]

Rataplan schreef op 20 February 2003 @ 14:38:
[...]
Ik snap je punt wel hoor Zo begrijp ik nog steeds niet waar UML nou precies goed voor is. Het voegt niks toe aan bestaande technieken, het doet er het zoveelste lollige jasje omheen.

UML is een modelleer taal. Met UML kan je je classes schematisch voorstellen zodat iedereen die kan lezen en je een overzichtelijk geheel hebt van de relaties tussen die c lasses.

Maar OO vind ik toch wel van een iets andere categorie, bijvoorbeeld gegeven .NET - ik denk dat binnen een paar jaar nauwelijks nog lokaal gerekend wordt, en iig niet meer gezien kan hoe je data tot stand komt - door berekening of invoer of weet ik veel wat. Benchen van systemen wordt dan bijvoorbeeld afhankelijk van remote caching, om eens een zijstraat te verzinnen

Wat heeft OO nu te maken met webservices? Ok, in .NET maak je webservices op een OO manier....
.NET is ook wel meer dan webservices, en die webservices, nouja..... eerst zien, dan geloven.

[Rataplan]

.oisyn schreef op 20 February 2003 @ 14:37:
Eerst zeg je dat OO geen manier van programmeren is, maar een manier van denken. Dan zeg je dat je OO niet ziet als je-van-het, omdat het ook gewoon procedureel geimplementeerd kan worden. Maar die implementatie boeit nou juist niet, het gaat om de manier van denken, dat zeg je zelf

Volgens mij zegt 'ie dat hij de OO-manier van denken niet als je-van-het beschouwt; omdat het hetzelfde resultaat oplevert als (procedureel ofwel) machine-conform denken. Ik kan me daar wel in vinden.

whoami schreef op 20 February 2003 @ 14:41:
UML is een modelleer taal. Met UML kan je je classes schematisch voorstellen zodat iedereen die kan lezen en je een overzichtelijk geheel hebt van de relaties tussen die c lasses.

Dat is mij bekend maar zoals ik zeg: het is just another way om overzicht te verkrijgen. En ik heb wel eens UMLspul voor mijn snufferd gekregen waar simpele problemen volstrekt idioot weergegeven waren. Het kan er namelijk ook onleesbaar en onoverzichtelijk uitkomen. Het is maar met welke tools je overweg kan: efficient programmeren en efficiente programma's zijn twee absoluut verschillende grootheden.

Wat heeft OO nu te maken met webservices? Ok, in .NET maak je webservices op een OO manier....

Mijn ervaring is dat OO-programmeren uitnodigt tot remoting van componenten; of het althans makkelijker maakt. Ik denk dat binnen afzienbare tijd heel veel software een beroep gaat doen op volledig abstracte en externe bronnen, wat imo aanzienlijk lastiger implementeren is met pak'm'beet C++. Maar zoals gezegd: ik roep maar een zijstraat, laat ons niet teveel offtopic gaan. Bovendien moet ik eik weer ff aan de slag

[whoami]

[nohtml]

Rataplan schreef op 20 February 2003 @ 14:52:
[...]
Volgens mij zegt 'ie dat hij de OO-manier van denken niet als je-van-het beschouwt; omdat het hetzelfde resultaat oplevert als (procedureel ofwel) machine-conform denken. Ik kan me daar wel in vinden.

Tja, ik niet eigenlijk.
Het resultaat kan hetzelfde zijn, maar de manier waarop je ontwikkelt is anders. Als je OO ontwikkeld, dan kan je op een veel abstracter niveau bezig zijn, waardoor je je meer kan richten op functionaliteit.

[Rataplan]

whoami schreef op 20 februari 2003 @ 14:54:
[nohtml]
[...]

Tja, ik niet eigenlijk.
Het resultaat kan hetzelfde zijn, maar de manier waarop je ontwikkelt is anders. Als je OO ontwikkeld, dan kan je op een veel abstracter niveau bezig zijn, waardoor je je meer kan richten op functionaliteit.

Volgens mij hangt dat volstrekt af van de functionaliteit die je moet implementeren, en van je vermogen tot abstract denken.

Het is zeker geen wondermiddel.

[Vuurvlieg]

Ik heb anders gewoon lineair programmeren op de middelbare school gehad, zo moeilijk is dat nou ook weer niet.. (ja en dat is duidelijk een mening ) maar ik heb geen oop op school gehad

[johnwoo]

drZymo is (net als ik tot op zekere hoogte) bestwel een bitneuker. Je zal hem eerder (ik noem maar wat) een driver ofzo zien bouwen dan een uitgebreid applicatiepakket.

Ik hou er ook wel van om de taal van de hardware een beetje te spreken. En ik weet dat het er op zich niet veel met OOP te maken heeft, maar het lijkt wel alsof de proggels tegenwoordig synoniem zijn met bloatware, verstrengeld in een web van dependencies. Het mooiste programma vind ik een enkele executable, zonder dependencies of wat dan ook. En met ActiveX (OOP) en .NET (OOP) is dat al niet meer mogelijk, je moet eerst een zut runtimes hebben. Moet ik wel bij vermelden dat ik nog nooit cross-platform heb moeten coden, kan me voorstellen dat je dan een runtime als dependency niet zo erg vindt. Maar dan nog zou ik liever bijvoorbeeld macro's gebruiken en 3x compilen voor 3 platforms, dan een runtime gebruiken

[ Voor 8% gewijzigd door johnwoo op 20-02-2003 15:06 ]

[.oisyn]

Rataplan schreef op 20 februari 2003 @ 14:52:
Volgens mij zegt 'ie dat hij de OO-manier van denken niet als je-van-het beschouwt; omdat het hetzelfde resultaat oplevert als (procedureel ofwel) machine-conform denken. Ik kan me daar wel in vinden.

ik wilde hierop reageren, maar toen bleek dat whoami het al gezegd had:

whoami schreef op 20 February 2003 @ 14:54:
Tja, ik niet eigenlijk.
Het resultaat kan hetzelfde zijn, maar de manier waarop je ontwikkelt is anders. Als je OO ontwikkeld, dan kan je op een veel abstracter niveau bezig zijn, waardoor je je meer kan richten op functionaliteit.

OO 'denken' is gewoon een hele duidelijke manier van rangschikken van data en onderverdelen van verantwoordelijkheden. Dit levert nagenoeg meestal een onderhoudbaarder stuk software op. Bovendien is het ook makkelijker te hergebruiken, omdat het minder ingewikkeld in elkaar zit. En dan bedoel ik niet ingewikkeld in de zin van dat het moeilijker te begrijpen is, maar ingewikkeld in de zin van dat modules in je programma minder met elkaar zijn verweven, en dat je de scheidingslijn tussen die modules ook veel beter ziet. Ook is het makkelijker een bepaalde implementatie uit te breiden of een stukje software te schrijven wat makkelijk met de rest van het programma interfaced.

Neem bijvoorbeeld het verschil tussen C en C++ streams. In C zijn de streams altijd files. Je opent ze met fopen (), en je leest data met fread (). Het OS levert de verdere implementatie (verschil tussen console, echte files, named pipes, etc.), maar het blijven files. Je kunt niet in je C programma een eigen file stream schrijven die bijvoorbeeld bij een fread () uit een geheugenbuffer of een socket leest. Stel een bepaalde functie heeft een FILE * als argument, en je hebt je data in het geheugen staan. Dan moet je dus eerst de data naar een file schrijven, en dan met fopen () die file openen, zodat je de FILE * door kunt geven

Bij de C++ streams is er een superklasse, waarvoor je zelf de implementatie kunt schrijven. Natuurlijk zijn er filestreams die files openen, en console streams die van/naar console schrijven, maar je kunt ook heel gemakkelijk een eigen implementatie ervan maken die bijvoorbeeld van/naar een socket of geheugen leest, of een gecomprimeerde file bij het uitlezen uitpakt.
De functie van het vorige voorbeeld heeft nu een std::stream & als argument, en dat kan gewoon alles zijn. Je kunt een file meegeven, maar ook een geheugenstream, een socketstream, enzovoorts. Voor de functie blijft het hetzelfde: het is een stroom data, en waar die vandaan komt is niet interessant

[GrimaceODespair]

Vuurvlieg schreef op 20 February 2003 @ 15:05:
Ik heb anders gewoon lineair programmeren op de middelbare school gehad

Ik zou ff niet meer opnieuw verwarring gaan zaaien over de terminologie, Vuurvlieg (lees topic anders maar ff door)

[johnwoo]

.oisyn schreef op 20 February 2003 @ 15:06:

[...]


ik wilde hierop reageren, maar toen bleek dat whoami het al gezegd had:


[...]
Neem bijvoorbeeld het verschil tussen C en C++ streams. In C zijn de streams altijd files. Je opent ze met fopen (), en je leest data met fread (). Het OS levert de verdere implementatie (verschil tussen console, echte files, named pipes, etc.), maar het blijven files. Je kunt niet in je C programma een eigen file stream schrijven die bijvoorbeeld bij een fread () uit een geheugenbuffer of een socket leest. Stel een bepaalde functie heeft een FILE * als argument, en je hebt je data in het geheugen staan. Dan moet je dus eerst de data naar een file schrijven, en dan met fopen () die file openen, zodat je de FILE * door kunt geven

Bij de C++ streams is er een superklasse, waarvoor je zelf de implementatie kunt schrijven. Natuurlijk zijn er filestreams die files openen, en console streams die van/naar console schrijven, maar je kunt ook heel gemakkelijk een eigen implementatie ervan maken die bijvoorbeeld van/naar een socket of geheugen leest, of een gecomprimeerde file bij het uitlezen uitpakt.
De functie van het vorige voorbeeld heeft nu een std::stream & als argument, en dat kan gewoon alles zijn. Je kunt een file meegeven, maar ook een geheugenstream, een socketstream, enzovoorts. Voor de functie blijft het hetzelfde: het is een stroom data, en waar die vandaan komt is niet interessant

Zoiets is ook in C wel te abstraheren, door ten eerste geen FILE* te gebruiken maar een module te schrijven met een setje eigen functies die zowel op files, sockets en weet ik wat kunnen werken Die functies kunnen dan andere functies op een lager niveau aanroepen voor de specifieke zaken die per type anders zijn. Als je de functionaliteit goed verdeelt over de functies krijg je eenzelfde soort gelaagdheid die je bij OOP overerving noemt

Neemt niet weg dat ik OOP proggen/denken ook wel fijn vind hoor, ik zie het alleen niet als dè ontdekking van de (vorige) eeuw

[ Voor 3% gewijzigd door johnwoo op 20-02-2003 15:13 . Reden: typo ]

[.oisyn]

johnwoo schreef op 20 February 2003 @ 15:12:
[...]

Zoiets is ook in C wel te abstraheren

duh, dat het in een niet-OO taal kan weet mijn grootmoeder ook wel (en dat is in deze topic allang naar boven gekomen)

Punt is dat als je al zo bezig bent dat je feitelijk al OO aan het denken bent, en dat was nou precies waar het om ging


DISCLAIMER: ik ben ook geen OO-profeet hoor, in tegenstelling tot sommige anderen op GoT Schone en effectieve code is mijn motto. Vaak biedt OO echter wel een goede uitkomst om tot die schone en effectieve code te komen

[ Voor 25% gewijzigd door .oisyn op 20-02-2003 15:17 ]

[GrimaceODespair]

johnwoo schreef op 20 February 2003 @ 15:12:
Neemt niet weg dat ik OOP proggen/denken ook wel fijn vind hoor, ik zie het alleen niet als dè ontdekking van de (vorige) eeuw

Het heeft conceptueel mss niet zoveel voeten in de aarde, maar ik denk wel dat het heel belangrijk geweest is voor de manier waarop (nieuwe) programmeurs zijn gaan denken. Hoe je progt blijft natuurlijk vrij persoonlijk en vaak afhankelijk van je opleiding, maar als je OO bent 'opgevoed' heb je volgens mij een natuurlijke tendens om abstracties te maken. Dat is iets wat je, imho, minder hebt als je procedureel leert proggen.

[johnwoo]

.oisyn schreef op 20 February 2003 @ 15:14:

[...]


duh, dat het in een niet-OO taal kan weet mijn grootmoeder ook wel (en dat is in deze topic allang naar boven gekomen)

Punt is dat als je al zo bezig bent dat je feitelijk al OO aan het denken bent, en dat was nou precies waar het om ging

Ah, op die fiets
In feite prog ik dus eigenlijk procedureel op een OOP manier?

Denk dat het ook voor een groot gedeelte in de naamgeving zit... Volgens mij is die gelaagde, abstraherende denkwijze er al sinds de oudheid der computerprogrammatuur

Het heeft conceptueel mss niet zoveel voeten in de aarde, maar ik denk wel dat het heel belangrijk geweest is voor de manier waarop (nieuwe) programmeurs zijn gaan denken. Hoe je progt blijft natuurlijk vrij persoonlijk en vaak afhankelijk van je opleiding, maar als je OO bent 'opgevoed' heb je volgens mij een natuurlijke tendens om abstracties te maken. Dat is iets wat je, imho, minder hebt als je procedureel leert proggen.

Mwah, abstraheren lukt ook wel zonder OO. Feit is wel dat OOP talen het gewoon makkelijker maken. Of dat ook beter is, dat verschilt denk ik per geval en per persoon.

_{Ik denk dat we het uiteindelijk toch bestwel eens zijn Dus ga ik nu maar weer verder met andere dingen}

[ Voor 39% gewijzigd door johnwoo op 20-02-2003 15:26 ]

[.oisyn]

lees ook even de disclaimer die ik onder mijn vorige post geedit had

[Rataplan]

.oisyn schreef op 20 February 2003 @ 15:22:
lees ook even de disclaimer die ik onder mijn vorige post geedit had

Als jij dan dit nog even leest

Volgens mij zitten we nu, geheel in stijl van het onderwerp van dit draadje, allemaal hetzelfde te zeggen - en allemaal op een andere manier. Ik ben het dan ook ernstig met drZymo Tanenbaum eens.

Ben eik wel benieuwd wat de ts hier ondertussen van vindt

[ Voor 6% gewijzigd door Rataplan op 20-02-2003 15:33 ]

[Verwijderd]

Wat ik er van vind?
Vind het wel top dat iedereen zoveel antwoord heeft gepost, maar dat levert wel wat verwarring op aangezien veel mensen een ander antwoord geven, maar na alles eventjes rustig doorgelezen te hebben is alles flink duidelijker geworden en ik denk dan ook dat het me wel lukt. Enne, ik heb ff m'n leraar nagevraagd en die zei inderdaad dat het dus procedureel programmeren is

[Verwijderd]

ik kan je inmiddels van alles vertellen over lineair proggen omdatk dood word gegooid met allerlei OR problemen die fijn in lindo (idd misschien zelfs lingo ) moeten worden opgelost.

snap alleen je probleem niet helemaal.

en voor de mensen die zeggen op de middelbare school mineiar proggen gehad te hebben, dat klopt wel, maar dan had je alleen X1 en X2 en misschien X3 als variabele, met de computer kun je tot Xijzk variabeles gaan als je snapt wat ik bedoel....

[Verwijderd]

Ok, ik heb de PO nu zo'n beetje helemaal af (dankzij jullie hulp ), alleen ik moet nog wat informatie hebben over de geschiedenis van procedureel/lineair programmeren. Geloof me, ik heb me helemaal rotgezocht (had vandaag alle tijd, ben ziek ) maar ik kan helemaal NIKS vinden! Ik zou het echt zeer op prijs stellen als iemand een siteje voor me heeft, het hoeft niet heel veel te zijn...

[GrimaceODespair]

Deze link ff uit de losse pols gegoogled (9e link)