CitaatDe resultaten van een zojuist gepubliceerd rapport van de Yankee Group zeggen dat maar 12% van de huidige Windows- gebruikers het nieuwe besturingssysteem Windows Server 2003 van Microsoft in het komende jaar zal installeren. Dat getal staat in contrast met de 30% die Windows 2000 in het eerste jaar na uitkomen onder de 'installed base' scoorde.
Bedrijven zijn volgens mij nog altijd bezig met de overgang van Win98 naar WinXP op de clients. Dat kost veel meer tijd en moeite dan upgraden van 2000 naar 2003. En het moet wel, want vanaf nu (7/2003) mag Win98 niet meer uitgeleverd worden, en is het dus WinXP wat je moet gebruiken.
Klopt melvin, gisteren kreeg ik (eindelijk) de upgrade van Windows NT 4.0 naar XP. Echter gaat elke OS upgrade niet makkelijk bij ons, omdat onze werkstations dezelfde OS moeten hebben als ons product anders kunnen we er niet software op ontwikkelen en ff 3 miljoen regels code werkend te krijgen op een ander OS (en daarbij meestal ook een nieuwe compiler) gaat niet 1-2-3 (kostte ruim 2 a 3 jaar om van VMS (Unix) naar NT over te stappen!)
De support op NT is overigens ook al afgelopen, dus XP is nagenoeg verplicht (Windows 2000 is sowieso al geen optie meer en is door veel bedrijven overgeslagen).
De kans dat we dus nog weer op een ander overschakelen is voorlopig klein, dus we zullen het met XP de komende 3 jaar ofzo moeten doen (NT word ook al wat jaartje gebruikt).
Heb je het dan over complete systemen die je uitlevert (dus een pakket van computer, OS en programma), of het programma alleen ?
Als het het eerste is, zou ik eerder naar een Linux/BSD platform kijken omdat je daar alle vrijheid heb die je maar kunt hebben op gebied van wat erin moet/kan/mag en hoe lang je het blijft gebruiken zo.
Dan zou .Net toch een mooie oplossing zijn?
Ben je meteen van dat soort compiler gezeur af. Je ontwikkeld gewoon op welk os dan ook.
Momenteel programeren wij al een tijdje op xp (met Delphi dan) en dat zonder echt grote problemen. Delphi 7 (waar wij mee werken) kan je tijdens het compileren laten zien welke calls/functions/procedures/objects hangen op een specifiek besturingssysteem en laat dus zo al je zwakke plekken zien. Verder kan je als bedrijf je aandacht besteden bij zijn core buisness ipv alles zelf te moeten ontwikkelen.
Wij zijn bijv gespecialiseerd in Loon-salarisadministratie en willen bijv helemaal geen rapportage engine schrijven. Je kan natuurlijk componenten kopen of de standaard gebruiken van Microsoft...denk bijv aan de print preview die je bij office ook hebt...krijg je er standaard bij...Kan dus behoorlijk veel werk besparen doordat je dit soort oplossingen niet zelf hoeft te schrijven.
Ook standaard XML interfaces worden heel eenvoudig gemaakt wat weer bevoordelijk is voor Data exchange....
Zo heb ik de XML module geschreven voor ons prog voor de afdracht loonbelasting.....ik denk dat je wel weet wat een verademing het is niet meer met ASCII of CSV te werken ;)
3 miljoen regels is wel erg veel.... zijn er vast een hoop te veel ;D
Met welke compiler werken julllie Scarp? en werken jullie OO of procedureel...ook daar zou veel besparing in kunnen zitten....
ps de man die aan het hoofd staat van de .Net onwikkelingen bij Microsoft deed dat ook voor Delphi...sterker nog hij heeft de basis van de compiler geschreven....de snelste ter wereld ;)
Wij leveren complete systemen van > 1 miljoen euro. Dat is een groot stuk hardware en een tweetal "besturing" pc's (voorheen compaq w8000 dual cpu systemen).
Wij gebruiken zowel C, C++ als tegenwoordig ook C#. 3 miljoen regels is niet veel, met name als je kijkt naar de omvang van dit soort apparatuur. Uiteraard kom je als "engineer" niet bij elke regel, ieder heeft z'n eigen deel. We werken hier met over de 130 software engineers aan! Volgens mij is de software die ASML maakt nog groter aangezien daar 500 engineers per project eraan werken.
Aangezien onze apparatuur 10 jaar moet staan, kan je niet zomaar wat uitleveren.
Linux is geen optie, aangezien we net van VMS geport hebben naar Windows NT/XP en dat kostte al ruim over de 2 jaar!
Het is een feit overigens dat OO je bug oplossing tijd verhoogt, dus met OO doe je langer over bugs oplossen dan met gewoon ouderwets procedureel. Met name omdat fouten in baseclasses zitten etc ...
Anyway ... allemaal een beetje offtopic... het feit blijft dat wij elke keer een behoorlijke tijd aan een bepaald OS vastzitten en dus niet elke microsoft OS meekunnen onmiddelijk. Window 2k hebben we overgeslagen, dus het OS na XP zal ook wel worden overgeslagen. Volgens mij doen de meeste bedrijven dit. Want de afschrijving is 3 (en tegenwoodig 4) jaar op een PC, dus als MS om de 2 jaar een nieuw OS uitbrengt missen de meeste bedrijven er eentje. Ook kan je als groot bedrijf (Ik werk bij philips), niet zomaar ff zo'n upgrade doen, je moet je computers beveiligen, etc ...
Hier gebruiken ze ook Delphi 7, zowel op Windows als op Linux (Kylix heeft het daar dan) en ik heb er toch gemengde gevoelens over. Het interface ontwerpen is super makkelijk, met die anchorpoints enzo, maar ik blijf erbij dat ze Pascal eindelijk eens een spuitje moeten geven en netjes begraven ;D
Je statement over de snelste compiler ter wereld is ook wel een beetje vaag hoor, je kunt niet zo meteen compilers van verschillende talen met elkaar gaan vergelijken.
Over je OO bezwaar ben ik het ook niet echt eens Scarp, ik vind persoonlijk OO veel makkelijker omdat ik er mee opgegroeid ben in mn studie en altijd OO heb leren ontwerpen. Als je in procedurele programmas een bug heb in een veel gebruikte functie, dan ziet die net zo diep als wanneer je een bug hebt in je base classe. (maar die bugs vind ik eigenlijk het makkelijkste op te lossen, omdat ze op een groot aantal plaatsen terugkomen; de bugs in de kleine componenten zijn veel moeilijker te vinden :) )
Maar om even terug on-topic te gaan: Je hebt het toch over de Win2k3 Server versie neem ik aan, of over Windows XP zelf als workstation ?
correctie: delphi gebruikt geen echte pascal, maar een door borland aangepaste versie. Pascal zelf is een perfecte taal om programmeren in te leren (ook een goed gedefineerde taal, waarin weinig onduidelijkheden zitten, dit in tegenstelling tot de C / C++ standaarden, die boordenvol undefined behaviour zitten)
nog een correctie: Ik heb niets gezegd over "de snelste compiler".
Over dat OO kan je het niet oneens zijn, aangezien er gewoon cijfers zijn die dat bewijzen (een fout oplossen in C++ OO kost 2 tot 3x zoveel tijd als in een conventioneel C systeem)
Anyway, back ontopic ... we kunnen uiteraard altijd een ander draadje starten voor dit soort discussies :)
Mijn Thread ;D
Als je er 2 x langer over doet om een Bug in een OO ontwerp te vinden dan beweer ik nu dat het nooit 100% OO is ;) . In OO heeft elk object zjin eigen verantwoording en kennen elkaar dus niet eens, behalve via een interface hooguit het controler object, zeg maar een spin in een web.
Als betekend dat er een bepaalde afhandeling een bug zit, hoef je alleen het object te bekijken die verantwoordelijk is voor de bewerking. Je moet dit soort properties dan ook read-only overdragen. Kortom als er in mijn code een fout zit dan weet ik precies op welke plek de data opgemaakt wordt...durf jij het zelfde te beweren bij procedureel ;D (PS ik werk dagelijks met zowel OO als procedureel dus ik ondervind de kracht van beide).
Als seniors in een bedrijf met dit soort argumenten aankomen, denk ik eerder dat ze bang zijn om weer wat nieuws te leren. Bang dat hun kennis waarvoor ze zoveel gedaan hebben de helft minder waard is geworden.
En dat bugs in base classen zitten een probleem is, kan ik niet als argumentatie begrijpen...dat zou ik juist als kracht omschrijven. Als je het in de Class oplost dan is het in alle afgeleiden ook opgelost..toch ;)
Het debuggen en onderhoud van OO is juist sneller, en ontwikkelen is juist trager.
Dat wil niet zeggen dat OO DE oplossing is voor alles! Er zijn best stukjes software waarvoor OO te kostbaar is omdat de ontwikkeling ervan duur is.
Ben het dus volledig eens met Spacebass :)
CitaatDat is een groot stuk hardware en een tweetal "besturing" pc's (voorheen compaq w8000 dual cpu systemen).
Scarp:
Ik begin het een beetje te begrijpen :P
Het gaat dus om een besturings software die je vroeger zou embedden, maar tegenwoordig via "PC" achtige systemen bediend...
En systeem/process analyse/ontwerp volgens Yourdon of heb ik het mis?
tja.... statistiek zegt het tegenovergestelde ...
Juist door de onafhankelijkheid is het lastig een bug te vinden.
Overigens heb ik het over het verschil tussen OO met C++ en gewoon C.
Echt OO is nog lastiger, omdat je daarin eigenlijk ook geen type safety hebt. Als je puur OO kijkt heb je een Object waarnaar je gewoon een message kan sturen, onafhankelijk of dat object die message echt afhandelt. Er zijn alleen maar weinig pure OO talen, de meeste werken met methodes op een klasse. 100% OO is zeldzaam.
Ga overigens maar eens werken aan echte applicaties van grote omvang dan kom je erachter dat het allemaal niet zo triviaal is. De meeste talen zijn hier totaal niet geschikt voor (Delphi bv) en dan kom je al snel terug op C of C++.
Geen type safety....dat heeft met je taal te maken niets met OO...
Je trekt het nu een beetje taalafhankelijk volgens mij.
Message versturen naar je eigen objecten in je eigen applicatie?
Ik zet properties en voer een execute uit. als het object daar niets mee kan raise ik gewoon een exception van een eigen type met een duidelijke boodschap wat er fout is. de initiator zorgt ermaar voor dat hij de excpetion afhandeld.
Het verschil met vroeger is dat exceptions je beste vrienden zijn....zij vertellen er WAT er fout is
OO vraagt gewoon om een paar dingen: (er zijn er meer maar deze vind ik zelf heel belangrijk)
1. Extendibility
2. Reusablity
3. Compatability
4. Inhertitance
5. Polymorphism
6. Exception Handling
even over statistieken:
Ken je die Statisticus die verdronken was in een sloot?
Tja het was GEMIDDELD 1,20 diep ;D
Exceptions worden teveel misbruikt volgens mij. Simpele return waardes werken net zo makkelijk en zijn een stuk sneller.
Door OO talen zijn we een stuk slechter gaan programmeren en minder rekening houdend met zaken zoals geheugen gebruik etc... een beetje applicatie van tegenwoordig slurpt megabytes ... niet echt goed.
Het OO principe is wel leuk en netjes, maar ik blijf erbij dat je toch echt rare situaties hebt, die echt lastig op te lossen zijn.
Exception handling is geen noodzakelijke eigenschap van een OO taal.
Compatibility ook niet. Uithoeken van talen wil je zeker vermijden.
Overigens is het gewoon een feit dat C++ slechter is dan C. Lees de standaarden van beide talen eens door. In C++ is enorm veel slecht gedefineerd.
(Overigens, ik had het ook over C/C++, dus taalafhankelijk).
Dat is nou juist het mooie van exceptions, wat moet je dan als return waarde geven ?
True, False?? Als je dat makkelijker vind zit je denk ik al te diep in in procedureel.
Ga je met result constanten werken dan sluipt er weer het gevaar in dat het result ontvangend en uitvoerend object een constanten lijst moet delen, waardoor de boel weer aan elkaar geplakt wordt en je dus weer afhankelijkheden hebt die je juist probeert te voorkomen, want zijn alle procedures wel aangepast om met nieuw toegevoegde result waarden om te gaan...
Overigens vind ik exceptions wel degelijk een onderdeel van het huidige OO....je zal zien dat dat van delphi is overgenomen in .Net :) , het is ook geen algemene voorwaarde voor OO maar een die ik zelf een must vind.
en geheugengebruik kan een argument zijn, maar met de huidige "Garbage collection" zal de hoeveelheid gereserveerd geheugen beperkt blijven tot het strikt noodzakelijke. Ook laad je alleen dll's als die nodig zijn en blijft ook hierdoor het geheugengebruik beperkt.
Juist door een objecten structuur met ownership zal het mindersnel voorkomen dat er "blokken" geheugen bezet zijn die niet gefree'd zijn.
Wat versta jij onder compatability in OO?
Hoe ver ben jij gegaan in OO programmeren? (heb je er ook Apps mee geschreven?)
Ik doe bijv veel export naar andere applicaties. Wat je dan ziet is dat je de gedeelde functionaliteit in de class bouwt. Wijzigingen hoef ik alleen in afgeleide van dat object te maken en override datgene wat anders is. Voordeel is dat ik dus ook oudere exports kan maken afhankelijk van de gevraagde versie.
De tijd van een copy van een functie/procedure en deze aanpassen is niet meer!
Ik denk nog aan de ik weet niet hoeveel compiler directives/ if thens/case statements als er weer eens een wijziging komt in een onderdeel.
Qua onderhoud wil je bij procedurele werking die ouwe zooi het liefst uit je code voor de leesbaarheid, dat probleem heb je dan ook niet meer.
Trouwens wij hebben voor de oudjes ook nog een DOS versie uitstaan geschreven in: C :)
lol ... vertrouwen op garbage collection? Dat geeft de grootst mogelijke problemen hoor. We zijn nu met .NET bezig en C#, maar ik voorzie al problemen door de garbage collector. We hebben in het verleden al de grootst mogelijke problemen gehad met java en garbage collection. Onze performance expert maakt zich echt zorgen over het uit de hand lopen van het geheugen gebruik van .NET en met name de ondoorzichtigheid ervan. Geheugen erbij blijven prikken houd natuurlijk eens op.
Als je op snelheid moet programmeren, wil je echt niet de overhead van exceptions. Een functie 10 miljoen keren aanroepen en dan elke keer vertrouwen op een exceptie, dan ben je fout bezig. Mocht de uitkomst fout zijn dan retourneer je een fout code. Dus altijd oppassen met exceptions en alleen toepassen op niet snelheid kritische delen.
Ik zeg niet dat procedureel programmeren beter is dan OO. Ik zeg alleen dat de statistiek uitwijst dat OO meer tijd kost om fouten te vinden. Hoogstwaarschijnlijk win je op andere vlakken juist wel weer.
Ons hele user interface is object oriented geschreven, met COM/MFC/C++. Ons nieuwe user interface stuk wordt nu gedaan met WinForms/C#/.NET. Hierin heb ik nu een pakket geschreven van een kleine 10.000 regels code, welke ingezet wordt in een groter stuk code. Ook heb ik 2 jaar professioneel geprogrammeerd in Objective C.
Ik zie niet in wat compatibility te maken heeft met OO.
Wat versta je onder exports? Aanroepen van externe componenten?
Tja, als je procedureel programmeert dan moet je het natuurlijk wel netjes doen, dus nette header files aanmaken, niet teveel klooien met #define (kan je in C++ ook flink fout doen) etc ...
Ik weet niet of je het weet, maar het grootste deel van de bestaande programmatuur in de wereld is geschreven in C. Vooral voor geheugen/snelheid kritische (embedded) systemen wil je echt niet met C++ en al z'n overhead beginnen. Overigens is embedded software erg groot.
Ook hebben wij twee totaal andere domeinen. Ik werk met meer technisch gerichte software, jij blijkbaar met het bankwezen ... totale andere werelden, die totale andere eisen hebben.
Maar het is weekend, dus ik hou op met gelul over software... maandag weer verder.
(ps. ik ben geen oudje)
Citaat van: Spacebass op juli 11, 2003, 20:10:16
Overigens vind ik exceptions wel degelijk een onderdeel van het huidige OO....je zal zien dat dat van delphi is overgenomen in .Net :) , het is ook geen algemene voorwaarde voor OO maar een die ik zelf een must vind.
Exception handling zit naar mijn weten ook in C++, welke al sinds 1985 bestaat.
Delphi bestaat sins 1995.
Conclusie: exceptions komen niet van delphi af.
CitaatMaar het is weekend, dus ik hou op met gelul over software... maandag weer verder.
Kijk dat krijg je met Procedureel ... zelfs in het weekend geniet ik er nog van OO ;D ;D
Maar is goed tot maandag zal ik je met rust laten...ik ga een filmpje kijken ;)
Hee je zou toch ophouden ... zie je dat programmeurs "mannetjes" zijn ;D
Ik hou me hier wijselijk buiten :P
Ik denk ook dat Scarp zn domein niet echt is wat je ziet voor pc applicaties. Als je miljoenen herhaling moet doen, is OO natuurlijk al niet handig. Elke keer een object aanmaken, met de nodige type checks, dan doorgeven en dan printen/processen is natuurlijk vele malen onefficienter dan op ruwe data werken.
Daarom zijn vele dingen onder unix nog altijd in good old plain C :)
Citaat van: Spacebass op juli 11, 2003, 20:47:47
Hee je zou toch ophouden ... zie je dat programmeurs "mannetjes" zijn ;D
Genoeg vrouwen bij mij op het werk :)
Citaat van: Melvin op juli 11, 2003, 21:43:49
Ik hou me hier wijselijk buiten :P
Ik denk ook dat Scarp zn domein niet echt is wat je ziet voor pc applicaties. Als je miljoenen herhaling moet doen, is OO natuurlijk al niet handig. Elke keer een object aanmaken, met de nodige type checks, dan doorgeven en dan printen/processen is natuurlijk vele malen onefficienter dan op ruwe data werken.
Daarom zijn vele dingen onder unix nog altijd in good old plain C :)
Tuurlijk hebben wij een groot deel ook user interfaces, waarmee je prima OO kan doen. Ik beweer ook niet dat OO slecht is, ik zelf programmeer altijd al zo. En statistiek wijst gewoon uit dat bugs vinden in OO geprogrammeerde C++ twee tot drie maal zoveel tijd kost dan in gewoon procedureel C. Uiteraard zijn er uitzonderingen en als je netjes programmeerd en goed je werk doet en goed voorbereid dan zal het minder zijn.
Maar OO is niet heilig en C++ al helemaal niet. Het is 1 van de meest slecht gedefineerde talen. Pascal is super goed en strak gedefineerd (Knuth doet z'n werk goed! (als je niet weet wie Knuth is, verdwijn dan uit de Informatica aub :P Of klaag je opleiding aan, je bent dan verkeerd opgeleid)).
Zit dicht op hardware, vermijd dan C++. Moet je image processing doen, vermijd dan ook C++, maar gewoon puur C (of Fortran mocht je op een Supercomputer werken en veel matrix berekeningen doen).
Grappig ik hoorde in andere forums dat procedureel uitgestorven was en je er niet aan moets beginnen. (het zou je alleen maar verpesten).
Maar als ik jullie zo hoor dan valt dat allemaal wel mee en is procedureel juist best wel handig voor sommige dingen.
Erik, je moet gebruiken wat het meest nuttig is voor je toepassing. OO is niet heilig en heeft ook z'n problemen. Een universele oplossing voor alles bestaat gewoon niet, elk probleem moet je goed bekijken en de beste aanpak beslissen.
Als je maar 16 kb geheugen ter beschikking hebt, dan ga je niet je programma maken in C++ met al z'n overhead, maar gebruik je gewoon prodecureel programmeren met C. Uiteraard kan je ook in C gewoon netjes programmeren zodanig dat het prima overzichtelijk blijft (je kan zelfs C code schrijven op een OO manier).
Voor user interfaces, is sleur-en-pleur het makkelijkst en dan krijg je C#/VB/Delphi en dat soort talen, die allemaal OO zijn.
Is assembler niets voor jouw Scarp...sneller kan ik mij niet voorstellen ???
(Kan je trouwens ook in programmeren in Delphi, kan dat trouwens in VB ook?
kan het niet laten...ik bedoelde met exceptions handeling de manier waarop .Net werkt :) = Delphi..
NEEEEE maandag gaan we verder ;D
Nog even dit...scarp als je antwoord had gegeven op mijn vraag of het embedded achtige proces software beterof waren we er volgens mij allang uit :)
met exports bedoel ik zowel het exporteren en importeren van file's als het via com-servers aansturen van andere applicaties waarbij je middels streams data overdraagt ipv xml/ascii/csv als tussen stap....
en met compatability bedoel ik dat je met simpele assigns hele property arrays kan overdragen waarbij het object zelf bepaald hoe hij met deze properties omgaat. denk aan Pascal strings/Pchars/ansi strings/ints/longints enz wel via variants, wat misschien wel traag is maar wel superhandig als je bij je ontwerp nog niet weet wat voor data type's je overgedragen krijgt....of moet overdragen...
aangezien Object Pascal type based is zal de compiler je direct waarschuwen als je met niet compatable datatype's gaat werken...ik meende dat dat in C geen probleem was.....
en we zijn het absoluut eens dat Pascal wel heel goed begrijpelijk en leesbaar is in vergelijking met VB/VBA...vreselijk die Nederlandse vertalingen...
we zijn het allang eens over het feit dat procedureel voor sommige apps handiger is dan OO...
leuk voor de C++/Java mensen is dat .Net niet meer met multiple inheritance werkt....was dat vroeger niet een van de voorwaarden voor OO...nou ja wel minder kans op geshit...dat wel...
Citaat van: Spacebass op juli 12, 2003, 11:57:24en we zijn het absoluut eens dat Pascal wel heel goed begrijpelijk en leesbaar is in vergelijking met VB/VBA...vreselijk die Nederlandse vertalingen...
??? Vertel voor zover ik weet is VB/VBA allemaal (gelukkig) in het engels
Recordset, ActiveDocument en Methoden en Eigenschappen heb ik nog nooit in het nederlands gezien. Zou ik trouwens ook niet willen gebruiken anders wordt het wel erg onbegrijpelijk.
Assembler is leuk, maar daar zit je weer te dicht bij de machine en dat is gewoon te lastig. Standaard C is een goede tussenstap. Toch begrijpbaar en toch snelheid.
Ik inderdaad wel een programma gemaakt in Delphi, zelfs een freeware programma die gereviewed is in PC World Hong Kong (de schrijver van het artikel heeft me een exemplaat gestuurd :)).
Geef me een weekje en een goed boek over VB en ik programmeer daar ook prima mee. Op de Universiteit hadden we eigenlijk alleen Pascal geleerd (en Prolog en nog een paar exoten zoals Fortran voor supercomputers), echter je daarin kan programmeren, dan kan je de rest ook wel leren. Qua C en C++ heb ik het mezelf geleerd. Toen ik begon te werken, kwam ik in aanraking met Objective C, welke ik binnen een paar dagen ook wel heb geleerd.
Een mooie analogie: onafhankelijk of je nou een BIC pen of een standaard potloodje pakt, schrijven blijf je kunnen. Uiteraard moet je er ff in verdiepen, want een potlood moet je af en toe slijpen en bij kroontjespennen moet je af en toe wat inkt toevoegen, dus elk schrijfwaar heeft z'n eigenaardigheden.
Programmeren is exact hetzelfde. Of je nou C of C++ of een andere taal (Cobol, Prolog, Gofer, Fortran, Eiffel, Smalltalk, Objective C, etc) gebruikt, je blijft kunnen programmeren, maar je moet je ff verdiepen erin om de specifieke dingen en de syntax goed te begrijpen.
Compatibility is dus eigenlijk gewoon een eigenschap waarbij je datastructuren kan overdragen naar andere objecten. Volgens mij niet echt OO eigen, maar meer gewoon iets wat handig is. Wat dat betreft kan je dan net zo goed gewoon "Object" (C# notatie) overdragen. Echter maak je het type unsafe. Kan je niet beter gewoon eerst een goed ontwerp maken waarbij je het type vantevoren bepaald. (ooit met Variants en C++/COM gespeeld? dat is echt een ramp! :)).
In C kan je zo'n beetje alles doen ... heb je een int array, wil je er een float array van maken? Geen probleem ... doen we ff ... heb je een short array en wil je een int array, simpel ... gewoon casten ... Vergeet dat maar in C# :)
Uhm... exceptionhandling in .NET is zoals het in Delphi is? Het lijkt me eigenlijk net zoals het in C++ en Java is.
Multiple inheritance is een design fout, als je daarop moet vertrouwen, dan ben je echt fout bezig vind ik. In C# zou je dit kunnen oplossen via Interfaces. Is niet helemaal hetzelfde, maar komt een eind in de buurt.
Microsoft heeft multiple Inheritance eens super misbruikt in ATL, wat een rare constructies heeft dat allemaal zeg... niet normaal. (Ik heb MS examens gedaan in MFC/COM/ATL, ben officieel MCP (MS Certified professional) :)).
Programmeertalen in het nederlands ... lijkt me geinig ...
Als (x < 10) dan
begin
xxxx
einde
hehe :)
Ach jah... maandag mag ik weer verder kloten met m'n programma ... nog een paar weken tot de alpha test :)
Zo een taal in het nederlands lijkt me niet echt moeilijk, gewoon de tokens vervangen in je (f)lex parser door de nederlandse equivalenten :)
Wat jij eigenlijk wil zeggen Scarp, noem ik altijd het verschil tussen programmeren en coden. Programmeren is universeel, met data structuren, algoritmen en tijd/ruimte-complixiteit. Coden daarentegen is die dingen omzetten in concrete code, en daar heeft elke taal wel truukjes voor om dat efficienter te doen dan het puur overzetten uit de pseudo taal.
En dan is het dus van de toepassing afhankelijk welke taal je neemt. Ik gebruik tegenwoordig meer en meer scripttalen zoals perl, php en pyhton ipv C++ of Java. Lose typing is echt zalig, kun je zo een string aan een int plakken en dat laat je toe om echt heel snel dingen te maken. En je kunt ze zo beschikbaar maken via een website als webscript.
Via PHP heb ik bv. vorige week onze telefooncentrale gekoppelt aan de NAW database, zodat je kon opzoeken wanneer een $klant gebeld had. Mn baas was stomverbaasd dat dat zo makkelijk kon :)
Multiple inheritance is idd maar evil, ben ook niet zo'n voorstander van dat vogelbekdier gedoe :)
Donald heeft trouwens wel leukere dingen gemaakt, de TeX engine gebruik ik dagelijks voor mn documenten te maken.
Exceptions offer several advantages over other methods of error notification, such as return codes. Failures do not go unnoticed. Invalid values do not continue to propagate through the system. You do not have to check return codes. Exception-handling code can be easily added to increase program reliability. Finally, the runtime's exception handling is faster than Windows-based C++ error handling.
Because execution threads routinely traverse managed and unmanaged blocks of code, the runtime can throw or catch exceptions in either managed or unmanaged code. Unmanaged code can include both C++-style SEH Exceptions and COM-based HRESULTS.
uitleg voor een geassimilleerde MCP'er op MSDN ;) (just kiddn) maar C++ komt er in deze uitleg niet geheel rooskleurig uit nee....
Zijn exceptions in C ook Objecten? (serieuze vraag) dit zijn nl idd objecten in Delphi.
chief designer van C# is Anders Hejlsberg, weet je toevallig wie hij was en wat hij voor Delphi betekend heeft?
Hij heeft Object Pascal gemaakt en was chief architect van Delphi :) ... vind het dus niet raar dat veel Delphi zaken nu in .Net verwerkt zitten ;)
Het probleem van programmeren is dat je niet in de toekomst kan kijken. de deur dichttimmeren is natuurlijk een mogelijkheid, maar ik vind het een mooiere oplossing door ook aan toekomstige eisen te kunnen voldoen, desnoods met een tussenlaag die je kunt vervangen als daar noodzaak toe is. Als er echt iets zwaar wijzigt, tja dan heb je met welk systeem dan ook een probleem...
Maar zoals je zelf al aangeeft is het mooie van OO dat je complete delen weg kunt halen/vervangen zonder dat je applicatie onbetrouwbaar wordt of dat je 2 jaar bezig bent een port te schrijven.
Citaat van: Erik op juli 12, 2003, 12:11:47
Citaat van: Spacebass op juli 12, 2003, 11:57:24en we zijn het absoluut eens dat Pascal wel heel goed begrijpelijk en leesbaar is in vergelijking met VB/VBA...vreselijk die Nederlandse vertalingen...
??? Vertel voor zover ik weet is VB/VBA allemaal (gelukkig) in het engels
Recordset, ActiveDocument en Methoden en Eigenschappen heb ik nog nooit in het nederlands gezien. Zou ik trouwens ook niet willen gebruiken anders wordt het wel erg onbegrijpelijk.
Neem maar eens een nederlandse versie van Office en maak maar eens een procedure in VBA (Access of zo...formulieren ipv forms etc.. :P )
In C zitten geen objecten en naar mijn weten ook geen exceptions. In C++ wel. Windows based C++ exceptions vind ik een rare term, aangezien C++ in essentie niets met Windows te maken heeft. Ik denk dat ze ergens anders op doelen dan C++ exception handling.
Overigens kan je gewoon simpel testen hoe snel exceptie handling is. Maak een methode die een exception geeft en laat dat in een try/catch block afhandelen. Doe dit 1 miljoen keer. Maak ook een methode die gewoon -1 of false retourneerd als fout code en laat dit door een simpele if/then/else take afhandelen. Doe dat ook 1 miljoen keer. Time beide pogingen. Herhaal uiteraard een paar keer om JIT effecten te vermijden.
Echter helaas mag je je resultaten niet bekend maken, dit wordt bij .NET door MS verboden.
Overigens heb ik alleen MCP gedaan omdat het moest van mijn baas. Liefst had ik gewoon een boek gehad en had ik het ook wel geleerd.
C# is een vergaarbak van verschillende elementen van verschillende talen. Grotendeels heeft het de syntax van C en C++, daarbij gevoegd Java elementen en ongetwijfeld Delphi (Object Pascal). Plus nog wat smalltalk en nog wat reguliere expressies ... zo krijg je een nieuwe taal.
OO zorgt er niet perse voor dat je complete delen kan vervangen. Goede gedefinieerde interfaces kunnen daar ook prima voor zorgen. Stel ik maak een gewone library klasse waar ik vantevoren zeg dat die interface hetzelfde blijft. Dan maakt het voor de aanroeper echt geen bal uit of er nou OO gebruikt word of niet.
Gebruik de juiste manier op de juiste plaats, maar ga niet van te voren al zeggen dat je altijd een bepaalde methode gaat gebruiken.
Citaat
Wat jij eigenlijk wil zeggen Scarp, noem ik altijd het verschil tussen programmeren en coden. Programmeren is universeel, met data structuren, algoritmen en tijd/ruimte-complixiteit. Coden daarentegen is die dingen omzetten in concrete code, en daar heeft elke taal wel truukjes voor om dat efficienter te doen dan het puur overzetten uit de pseudo taal.
Daar komt het wel ongeveer op neer. Zoals je zelf aangeeeft, je gebruikt nu verschillende script talen. Die kan je allemaal vrij snel leren omdat je gewoon een goede basis kennis hebt, je kan nou eenmaal de logica achter programmeren zien of niet. Je kan het deels aanleren, maar een stuk creativiteit moet je kunnen.
Hetzelfde met bv pianospelen, technisch kan ik dat bijvoorbeeld wel leren, maar het wordt nooit echt muziekaal omdat het niet in mij zit.
Vandaar mijn verhaal over Delphi like exceptions in .net In Delphi zijn exceptions objecten...
Ik heb geloof ik al gezegd dat er vast apps zijn die een andere benadering vragen :)
Wat wordt er verboden door Microsoft....zou mij een worst wezen...
maar eh wat betreft die performance debug test gedaan is...wat waren de condities...en wie heeft die test uitgevoerd en bedacht...lijkt mij heel essentieel voor men daar conclussies aan verbind.
Tuurlijk kan je van alles bedenken om complete delen te vervangen , maar de essentie van OO is dat je hier op een gemakkelijke manier toe in staat bent doordat jij de achterliggende code niet hoeft te kennen, en dus ook geen result defenities hoeft te kennen...
Wij moeten vele malen per jaar aanpassingen doen aan onze software vanwege wettelijke regelingen en bepalingen en daarom juist kiezen wij voor de OO benadering.
Het programma was eerst procedureel en sinds wij zijn over gestapt naar OO is onderhoud echt een fluitje van een cent geworden. Ook wij maken trouwens enorm veel berekeningen, maar lossen de overhead op door floats als integers op te slaan en er mee te rekenen ipv met de aan de gebruiker gepresenteerde floats, dat heeft denk ik meer effect dan het verschil tussen een object creeren of niet...je kan trouwens ook class functions maken (met een result ;) ) zonder het object zelf te hoeven creeren....
Ook gebruik ik veel string en sort manipulaties met assembler (pointers) om te voorkomen dat er heen en weer gekopieerd word met geheugenblokken , scheelt ook ontzettend veel memory overhead..dat zijn gewoon allerlei mogelijkheden om je code te optimaliseren het delphi een aardige memory management heeft, kan het vast veel beter. Ook het reusen van objecten door alleen properties te veranderen zorgt ervoor dat ik niet voor elke berekening een nieuw object moet creeren...
Maar nogmaals ik denk dat we het opzich met veel dingen eens zijn, alleen zitten wij in andere hoeken van de programmeer wereld waarbij andere zaken belangrijk zijn.
Ik heb ooit een SAD cursus gevolgd samen met "realtime" software ontwikkelaars...zij hebben idd een hele andere benadering... ook nu blijkt dat weer.
Er is geen beste oplossing voor elk probleem, maar het is wel handig als je niet telkens het zelfde probleem moet oplossen in een ander jasje (reusablity)
(Werken jullie ook met Design Patterns? )
Lees dat boek Inmates are running the Assylum eens...was voor mij echt een eye- opener! Heeft mij een stuk dichter bij de gebruiker gebracht (aangezien jij met ook met interfaces bezig bent lijkt mij dat niet helemaal onbelangrijk) maar misschien heb jij dat niet nodig...ik had het wel nodig! knopje hier en dan een verdwijnend knopje daar...zo dat begrijpt de gebruiker vast wel ;D