Acceptatie Windows Server 2003 niet groot

[Spacebass]

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

[Erik]

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

[Scarp]

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

[Melvin]

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.

[Spacebass]

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.

[Spacebass]

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

[Scarp]

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.

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.

[Spacebass]

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