Acceptatie Windows Server 2003 niet groot

[Spacebass]

De 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.

[Melvin]

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.

[Scarp]

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).

[Melvin]

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.

[Spacebass]

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  

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  

[Scarp]

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 ...

[Melvin]

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  

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 ?

[Scarp]

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

[Spacebass]

Mijn Thread  

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   (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.

[Melvin]

Ben het dus volledig eens met Spacebass

[Spacebass]

Dat 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  

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?

[Scarp]

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++.

[Spacebass]

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  

[Scarp]

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).

[Spacebass]

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  

[Scarp]

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)

[Scarp]

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.

[Spacebass]

Maar 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    

Maar is goed tot maandag zal ik je met rust laten...ik ga een filmpje kijken  

[Spacebass]

Hee je zou toch ophouden ... zie je dat programmeurs "mannetjes" zijn  

[Melvin]

Ik hou me hier wijselijk buiten

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

[Scarp]

Hee je zou toch ophouden ... zie je dat programmeurs "mannetjes" zijn  

Genoeg vrouwen bij mij op het werk

[Scarp]

Ik hou me hier wijselijk buiten

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 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).

[Erik]

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.

[Scarp]

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.

[Spacebass]

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  

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....