[ALG] Programmeertaal voor wetenschappelijk programma

[LauPro]

Een buurman van me werkt aan een programma waarin wetenschappelijke calculaties kunnen worden uitgevoerd. Je kan dit zien als zijn levenswerk omdat er nu al meer dan 30 jaar werk in zit. Inhoudelijk kan ik niet op het programma in gaan omdat deze nog steeds onder embargo is (wordt binnenkort gepubliceerd in een tijdschrift). Maar de codebase is best fors, het geheel met forms en datafiles is 400 MB, waarvan ruim 2 MB enkel code is (geen forms oid).

In al die jaren is hij steeds tegen het probleem aangelopen dat de taal die hij gebruikt binnen een mum van tijd weer wordt opgevolgd. Zo was het programma in het begin GWBasic, daarna een hele tijd Quickbasic en zo'n 8 jaar geleden heeft hij alles naar Visual Basic over gezet, welke nu inmiddels bij versie 6 is beland.

Nu is het probleem dat Microsoft de ondersteuning voor Visual Basic binnen niet al te lange tijd stopt gaat zetten. Dit zal betekenen dat hij weer gedwongen gaat worden om over te stappen op een andere taal.

Omdat de code zoals die nu is nogal rommelig is zijn we tot de conclusie gekomen dat het herschrijven van de code de beste oplossing is. Echter dan rijst de vraag om in welke taal dat moet gaan gebeuren. Omdat er nu berekeningen in zitten die soms welk uren kunnen duren is het op zich verstandig om voor de snelheid voor C++ te gaan. Echter C++ is inmiddels ook al 30 jaar oud en heeft een wat hoge leercurve (de beste man is inmiddels met de vut). Na het doornemen van een paar voorbeelden met hem gaf hij aan de de syntax op zich wel duidelijk is. Maar dan ben je er natuurlijk niet.

Een tweede reden dat de boel herschreven moet worden is omdat hij de broncode wil publiceren over grofweg 2 jaar. En de huidige staat van de code is erg rommeleig, dit komt omdat er in de loop der jaren gewoon telkens dingen zijn toegevoegd. Een aantal stukjes zijn gewoon letterlijk uit QBasic-code gehaald.

Het volgende punt is dan de GUI. Het pakket kent nu een apart programma om grafieken weer te geven. Deze zal dan ook herschreven moeten worden. Alleen de bedoeling met de rewrite is dat de code pakweg de komende 50 jaar mee kan gaan zonder dat deze (waarschijnlijk tzt door iemand anders) weer moet worden omgezet naar een nieuwe taal. Ik zat in eerste instantie te denken om bijvoorbeeld GTK 2.0 te gebruiken. Echter is dat waarschijnlijk binnen een niet al te lange tijd weer hopeloos achterhaald (zoals GTK 1.0 nu is bijvoorbeeld). Vanuit de QT-hoek verwacht ik wat meer totaaloplossingen waarbij je eventueel je programma's middels een wizard kan omzetten naar de nieuwe libs tzt. Puur ontwikkelen op een Windows Platform ligt eigenlijk niet binnen de mogelijkheden omdat Microsft de eigenschap heeft om dus elke 10 jaar met een nieuwe taal te komen. En Java lijkt me nu ook niet echt geschikt voor dergelijke berekeningen.

Graag jullie mening over deze situatie .

[ Voor 3% gewijzigd door LauPro op 19-03-2005 18:05 ]

[alienfruit]

Ik zou kunnen denken aan Borland Delphi, bied hele mooie oplossingen op een snelle en eenvoudige manier over te stappen na bepaalde technologiën. Zoals kun je gemakkelijk nu je win32 applicatie omzetten naar .NET.

Als je wil zou je hem eens kunnen laten kijken naar:

Converting from VB to Delphi (wiki)

[ Voor 15% gewijzigd door alienfruit op 19-03-2005 13:34 ]

[EfBe]

Core omzetten naar C++, gui omzetten naar Real Basic. (http://www.realbasic.com ). Realbasic is vrij compatible met VB6. De Core omzetten naar C++ levert een gui-less engine op die niet alleen portable is naar andere platforms maar de code is ook tijdloos want C++ compilers zijn er legio.

Door de 2 platformen gescheiden te houden word je ook gedwongen beter na te denken over structuur en houd je je core ook echt clean. En staar je niet blind op 2MB aan rommelcode. Wellicht is het in 200KB C++ code te gieten wanneer je de poliepen van jarenlang gebroddel eindelijk verwijdert.

[Macros]

Je loopt hier aan tegen een fundamenteel probleem van de informatica. Laatst is er zelfs een hogleraar speciaal om onderzoek te doen naar de evolutie van software aangesteld aan de TUDelft. Ik zie een paar mogelijkheden:
1) niks veranderen, houden bij VB6
2) andere taal + gui framework kiezen en herschrijven

Als je voor 2 kiest zou ik voor iets proberen te kiezen wat waarschijnlijk heel lang blijft bestaan. Dan zou ik denken aan talen zoals C en C++, waarvoor altijd wel compilers gemaakt blijven worden. Voor je GUI is het veel lastiger. Elk platform heeft zijn eigen gui api en elk platform bestaat maar een paar jaar. Gelukkig zorgt Microsoft wel voor backwards compatibility (bijna allewindows 3.0 apps draaien nog steeds onder XP). Applicaties geschreven voor X draaien ook jaren laten nog zonder veer problemen, hogere API's zoals GTK en QT geven misschien meer problemen. Ook zou ik Java niet afschrijven. Een core geschreven in C/C++ kan goed gecombineerd worden met een Java GUI welke over 100 jaar nog steeds zou kunnen draaien in een Java VM waarbij je de oorspronkelijke versie van de code meegeeft.

Maar toch zou ik kiezen om het te laten zoals het is. Het blijft gewoon draaien, nu en in de toekomst, alleen zal de ontwikkeling lastiger gaan als MS VB6 niet meer ondersteund. Maar als die ondersteuning wegvalt zal er waarschijnlijk wel een alternatieve VB6 compiler komen van een ander bedrijf. Mocht later de drang om de app over te zetten naar een andere taal blijven, doe het dan, maar het lijkt me nu voorbarig.

[MSalters]

Grappig.

Nederland heeft recent de moeite genomen om de originele BASIC standaard weer terug officieel te maken. De standaard is nu officieel stabilized, en dus bewaard. Natuurlijk heb je daar niet zoveel aan, die oude BASIC was erg beperkt. Het geeft wel aan dat de nieuwere standaard talen waarschijnlijk ook blijvertjes zijn. Standaard C++ is misschien pas 7 jaar oud (1998), maar er wordt al nagedacht over nieuwe ontwikkelingen tot 2015. Fortran is wel oud (1960 of zo) maar gaat voorlopig ook niet weg.

Microsoft's producten zijn een heel ander verhaal. Langte termijn support is daar een zaak van tien to 15 jaar, maximaal. Aan de andere kant, het zijn producten en geen papieren tijgers. Andere bedrijven zijn niet altijd beter - Borland zou ik ook niet op vertrouwen. IBM misschien weer wel.

De meest voor de hand liggende combinatie lijkt me dus een standaard taal gecombineerd met een bedrijf wat een lange support levert.

Overigens wil ik nog wel even C++ pushen voor technisch-wetenschappelijk werk. Met SIunits kun je gewoon in meters danwel voeten rekenen, en de compiler maakt er effectieve en correct code van - óók als je meters en voeten bij elkaar optelt. Geen domme foutjes meer als 2*pi+lengte.

[Verwijderd]

I'm with EfBe.

Imho heeft het behoorlijke voordelen om de rekencore en de UI te scheiden:

• Core code kan zo laag-niveau geschreven worden als nodig is om het geheel snel genoeg te houden (denk C, C++, ASM als het moet)
• GUI code kan hoog-niveau geschreven worden in een omgeving die dat makkelijk maakt (een RAD omgeving als Delphi bijvoorbeeld, of Visual Basic als je echt moet...)
• De core kan platformonafhankelijk blijven, en voor elk gewenst platform kan daarna een GUI geschreven worden (GTK, Qt, Windows...)
• De core kan los gedraaid gaan worden van de GUI, bijvoorbeeld over een netwerk. Zo kun je een rekenserver inrichten die de core draait, en een stel werkstations die alleen de GUI draaien (en dus minder hoge eisen aan het systeem zullen stellen)
• Je kan verschillende soorten interfaces maken (onder andere command-line interfaces, en mogelijkheden bieden tot het verwerken van batch jobs)
• Als het rekenprogramma in de problemen komt, bijvoorbeeld in een oneindige lus, volstaat het de core af te schieten en te herstarten. De GUI met al het programmeerwerk erin kan mooi blijven draaien zonder last te hebben van problemen met de back-end.

Mathematica doet het ook zo (aparte kernel en GUI), en daar werkt het allemaal best goed.

[Alarmnummer]

Hmm... scheiden doe je vaak niet zomaar... moet je wel vanaf dag 1 rekening mee houden dat je bepaalde componenten wilt kunnen scheiden.

Verder vind ik de keuze om de gui in een andere taal te schrijven dan de core ook niet echt een handige keuze. De man is verknocht aan vb, dus nu moet de man ineens 2 talen erbij gaan leren. Ik zou gewoon voor 1 taal gaan.

Ik neem verder aan dat de man ook niet echt low level bezig wil (vb was dan sowieso al een slechte keuze) dus c++ vind ik al geen automatische keuze. Ik zou gewoon eens kijken of je het zooite kan porten naar VB.NET. En anders zou java ook een hele reeele optie zijn...

[LauPro]

Het grootste punt waar het pakket nu mee zit is dat er in plaats van grote arrays tijdelijke files worden gebruikt. Dit komt omdat QBasic ooit de beperking van 10.000 elementen per array kende. Zo zijn er nog vele constructies die gewoon niet deugen (option-boxes voor een hoofdmenu etc). Om dit op te lossen is het herschrijven van de code eigenlijk wel noodzaak, het heeft anders niet veel zin om de broncode vrij te gaan geven omdat een buitenstaander eerst vele uren zoet is met het uitzoeken van alle constructies.

Het voorstel om de GUI en het rekenwerk apart te scheiden spreekt mij heel erg aan. Echter dan zul je dus een soort van protocol op moeten zetten. Ik voorzie hier nog wle wat problemen. Het gebruik van XML dan op zich goed mogelijk om bijvoorbeeld tabellen heen en weer te fietsen.

Het programma bestaat uit zo'n 20 VB6-projecten; die elk eigenlijk een eigen berekening uitvoeren. Maar er zijn er ook een aantal tussen die output weergeven. Je zou dat op een soort modulebasis kunnen maken.

Maargoed; in feite ontwikkel je dan straks aan 2 kanten: de GUI en de backend. GUI kan dan in VB Java of in C++ en de backend een soort van XML based server (voor de makkelijke verwerking). Dit is een constructie die mij wel aanspreekt. Met name omwille de flexibiliteit die je creëert (nu staan veel locaties van paden hardcoded e.d.).

edit:
De man is begonnen in Basic omdat dat toen gewoon dé taal was waar je applicaties in maakte. Alleen nu brengt die beslissing vele beperkingen met zich mee, en omdat het pakket uiteindelijk wel moet doen waar het voor ontworpen is, heeft in de loop van de jaren weinig moeite genomen om veel dingen te optimaliseren. Maar dat is naar mijn idee ook meer dan logisch, als je grofweg 20 jaar werkt aan een programma dan kan je niet om de haverklap de complete structuur omgooien omdat je dan per saldo langer bezig bent.

[ Voor 17% gewijzigd door LauPro op 19-03-2005 18:19 ]

[BCC]

C# is denk ik ook een mooie optie voor dit geheel (lijkt erg veel op VB) en aangezien Microsoft's nieuwe besturingssysteem erop gaat draaien, denk ik dat het nog wel een tijdje meegaat. En het is tegenwoordig ook prima te draaien onder Linux. Ik zag dat je Java geen optie vond. Waarom niet? Het is de enige bekende platform onafhankelijke taal (ja, C ook wel tot op zekere hoogte) en de laatste versies zijn erg fatsoenlijk.
Scheiden van de front en de back-end lijkt me zeker bij zware berekeningen logisch. Dan kunnen je herrieschoppende blade servers in het serverhok lekker snel alles voor je fluisterstille desktopje uitrekenen..

[ Voor 21% gewijzigd door BCC op 19-03-2005 18:30 ]

[Mayco]

LauPro schreef op zaterdag 19 maart 2005 @ 13:28:
Alleen de bedoeling met de rewrite is dat de code pakweg de komende 50 jaar mee kan gaan zonder dat deze (waarschijnlijk tzt door iemand anders) weer moet worden omgezet naar een nieuwe taal.

Ok, hier maak je toch ff een foutje, een programma kan onmogelijk 50 jaar meegaan... Zelfs UNIX is nog niet zo oud... Denk eens na over wat voor computers we binnen 50 jaar hebben, en gaat je programma van nu er nog op draaien? Kans is enorm groot van niet...

[BCC]

Mayco schreef op zaterdag 19 maart 2005 @ 18:31:
[...]
Ok, hier maak je toch ff een foutje, een programma kan onmogelijk 50 jaar meegaan... Zelfs UNIX is nog niet zo oud... Denk eens na over wat voor computers we binnen 50 jaar hebben, en gaat je programma van nu er nog op draaien? Kans is enorm groot van niet...

Dat niet alleen, er komen steeds nieuwe manieren van programmeren. 50 jaar geleden deden ze echt nog geen Object geörienteerd programmeren, laat staan dat ze de CPU kracht hadden om het überhaupt te doen. Binnen niet al te lange tijd komen er geheid nieuwe programmeer talen / methodes van programmeren en omdat ze nog niet bestaan kun je er echt geen rekening mee houden.

[LauPro]

Ik heb even zitten kijken naar RealBasic, dat is zéér interessant. Die neem ik iig mee.

Mja, 50 jaar misschien wat hoog gegrepen. Het gaat erom dat er nu niet weer 2 jaar werk op gaat in het omzetten in een taal die misschien hooguit 10 jaar mee gaat. Er moet een structurele oplossing komen. En het lijkt me dat C++ voorlopig niet eruit gaat. Ik vraag me af wat de opvolger zou moeten worden, C# e.d. zijn allemaal talen die ook in C++ gemaakt zijn. Je zou hooguit op den duur bijvoorbeeld machines krijgen die een ingebouwde HW JavaVM hebben oid.

[xx77qq]

Ik doe zelf ongeveer 15 jaar aan software ontwikkeling (begonnen als hobby in GWbasic tot nu professioneel in het bedrijfsleven).
Dat verhaal van je buurman klinkt als een bekende situatie, begonnen met een pakket wat geevolueerd is tot iets wat onbeheersbaar gaat worden. Heb zoiets een paar keer meegemaakt en de enige goede manier was een 100% rewrite. In het begin lijkt het veel werk, maar uiteindelijk is de kans groot dat je sneller en beter af bent.

Als je wetenschappelijk bezig bent (eigenlijk ook niet wetenschappelijk) dan zou ik niet voor talen als basic, delphi, C(++) kiezen maar direct voor een hogere taal. Staar niet blind op het feit dat C++ veel sneller kan zijn want de CPU's over 2 jaar zijn nog veel sneller.

Python is een hele goede taal met ook erg veel toepassingen in de wetenschappelijke wereld. Arrays, listen, dictionaries van miljoenen elementen zijn geen probleem. Veel goede numerieke libraries beschikbaar en portable tussen vrijwel alle OS'en die je kan verzinnen.

Even een globale opzet voor het porteren:
* GUI en programma logic van elkaar scheiden.
* Probeer een versiebeheer systeem te gebruiken
* Kies een hoge programmeertaal, scheelt *veel* programmeerwerk.

GUI's zijn lastig om jaren mee te nemen, vandaar het advies om GUI en programma logic van elkaar te scheiden. Daarmee is het veel makkelijker om bijvoorbeeld een webinterface te introduceren.

Ga niet te snel met de GUI stoeien, want daarmee is de verleiding veel te groot dat je alleen maar met je interface bent en niet met je werkelijke programma. Probeer het bijvoorbeeld eerst met een tekst/commandline versie.

[farlane]

Wat ik me wel afvraag is waarom je die complete codebase wil gaan herscghrijven. Ik neem toch aan dat de publicaties die hij wil maken niet om de GUI code gaat, maar alleen om de logica. Ik zou beginnen met het heschrijven van dat component ( in een taal van de mans voorkeur ) en daarna pas met die GUI aan de gang gaan.

[xx77qq]

farlane schreef op zaterdag 19 maart 2005 @ 19:16:
Wat ik me wel afvraag is waarom je die complete codebase wil gaan herscghrijven. Ik neem toch aan dat de publicaties die hij wil maken niet om de GUI code gaat, maar alleen om de logica. Ik zou beginnen met het heschrijven van dat component ( in een taal van de mans voorkeur ) en daarna pas met die GUI aan de gang gaan.

Misschien zit ik er helemaal naast, maar ik heb het idee dat logica en GUI niet van elkaar gescheiden zijn. De core logica kan daardoor best besmet zijn met GUI afhankelijkheden en restricties uit het verleden zoals arrays van beperkte grootte. In dat geval ben je beter af met helemaal opnieuw beginnen, grote kans dat het een stuk eenvoudiger wordt.

[LauPro]

Op het moment van publicatie worden gewoon de binaries meegegeven en niet de source. Dan kunnen mensen het pakket iig uitproberen. Echter is het wel de bedoeling dat de software in de toekomst gewoon vrij beschikbaar gaat worden (GPL waarschijnlijk). Mede om deze reden kan je eigenlijk de software in deze staat niet beschikbaar maken, al zou het alleen al zijn dat je daarop afgerekend kan worden (afgezien van dat het wetenschappelijk wel in orde is).

Het probleem alleen is dat het programma nu zo is opgezet rond een GUI. Dus een scheiding zal veel consessies met zich meebrengen. De vraag is in hoeverre extra snelheid wenselijk is. Je moet je voorstellen dat er berekeningen in zitten die in enkele seconden zijn gebeurd, maar ook berekeningen die 20 minuten duren (in VB6 dus) of als je grote files pakt enkele uren (uitzonderlijk).

Er worden nu niet vooraf parameters gevraagd aan de gebruiker, maar tijdens het berekenen door. Dit zijn al constructies waardoor het nu vrijwel onmogelijk is om simpel iets extra toe te voegen. Overzichtelijke wizard oid zouden echt een zegen zijn.

Tot nu toe ben ik tot de volgende conclusie gekomen:
• Maak een aparte backend in C++ voor al het rekenwerk.
• Frontend in verschillende vormen, Java, Web-based etc.
• Samenvoegen van alle losse programma's tot 1 geheel (indien mogelijk).

[ Voor 10% gewijzigd door LauPro op 20-03-2005 01:51 ]

[Domokoen]

Ik ben het met xx77qq eens dat Python heel interessant is... vooral omdat je er heel makkelijk allerlei dingen mee kan (debuggen, GUIs maken). Leg maar eens aan een VB-programmeur uit dat je bij een Segmentation Fault in C++ ergens in je programma een fout hebt gemaakt... en dat hij niet zegt waar. VB6 staat niet bekend om zijn snelheid, en Python kan heel aardig meekomen met Delphi en C++, dus ik kan eigenlijk geen argumenten bedenken waarom het niet geschikt zou zijn.

Er bestaat trouwens Delux dat VB naar Delphi of C# kan converteren... ik weet niet hoe dit werkt, ik heb alleen de standaard-versie een keer van een Cover-CD gebruikt en er kwam lelijke Delphi-code uit... maar het lijkt te werken (alleen was de standaard versie te beperkt om mijn hele programma om te zetten, dus ik heb er nooit veel mee kunnen doen).

[MSalters]

Verwijderd schreef op zaterdag 19 maart 2005 @ 18:01:
• Core code kan zo laag-niveau geschreven worden als nodig is om het geheel snel genoeg te houden (denk C, C++, ASM als het moet)

Om heel eerlijk te zijn is voor rekencode Fortran de snelste oplossing, alhoewel C++ tegenwoordig die snelheid steeds vaker haalt. (met een snelle moderne compiler en Blitz code)

Het probleem met C en ASM is dat mensen gewoon niet het overzicht hebben om optimalisaties op grote schaal door te voeren. Met FORTRAN lukt het aardig doordat de taal vrij simpel is en de compiler daardoor vrij veel statements tegelijk kan optimaliseren (geen wild pointers).
Met C++ is het wat ingewikkelder; daar heb je met templates in feite een compile-time script engine. Op die manier gezien is Blitz een optimizer in die script taal. Via operator overloading kun je ook operator synthese doen, zoals de klassieke A+B*C als een enkele ternaire operatie (die dan vaak ook op CPU nivo wordt opgepikt). Dat voorkomt onnodige stores, en dat is een grote winst.

Voor zover ik weet (maar dat is niet helemaal 100%) heb je in Fortran iets meer temporary stores die er niet uitgeoptimaliseerd worden. Dat is misschien een gevolg van een gebrek aan OO syntax? Daar staat tegenover dat je C++ stores zeldzamer maar wegens pointer aliasing iets duurder zijn.

De echte winst komt natuurlijk als er iemand bedenkt hoe __restrict goed in C++ in te passen valt. Dat geeft een optimizer zoveel kansen dat C nu ook mee kan doen - maar in C is het een feature met impact op alle numerieke programmeurs.

[MSalters]

LauPro schreef op zaterdag 19 maart 2005 @ 19:41:
Tot nu toe ben ik tot de volgende conclusie gekomen:
• Maak een aparte backend in C++ voor al het rekenwerk.
• Frontend in verschillende vormen, Java, Web-based etc.
• Samenvoegen van alle losse programma's tot 1 geheel (indien mogelijk).

Ik heb het al eens commercieel mogen doen (met collega). Eindresultaat: de originele auteur was onder de indruk, de geporte versie was zelfs in zijn ogen een stuk bruikbaarder. Toch was de GUI zo simpel dat een VBA programmeur er een VBA vervanging voor kon maken in een paar weken.
( uiteraard in C++/Qt )

[Macros]

Als ik hem was zou ik het eerst maar eens publiceren, als het dan positief onthaald wordt en je wilt het onder GPL uitbrengen kan je altijd nog een rewrite doen. Nu heb je grote kans dat je weer 5 jaar bezig bent met een rewrite in je eentje waardoor je dan weer gedeeltelijke een verouderde code-base hebt. Als het nou doorbreekt kan je het altijd nog door derden laten herschrijven.

[MrBucket]

Even tussendoor: wie gaat die conversie doen? TS of die buurman van je?

Maakt nogal een groot verschil in wat "de juiste" oplossing is, volgens mij. Kan me voorstellen dat als die buurman het nu in C++ moet gaan herschrijven, dat de puinhoop niet te overzien is...

[xx77qq]

LauPro schreef op zaterdag 19 maart 2005 @ 19:41:

Tot nu toe ben ik tot de volgende conclusie gekomen:
• Maak een aparte backend in C++ voor al het rekenwerk.
• Frontend in verschillende vormen, Java, Web-based etc.
• Samenvoegen van alle losse programma's tot 1 geheel (indien mogelijk).

C++ lijkt me geen goede keus. Als je dat niet erg goed beheerst wordt het een zooitje. Bovendien is het in C++ veel te gemakkelijk om bijzonder inefficiente code te maken (copy constructors die onderwater inefficient veel data heen en weer verplaatsen, destructors die element voor element verwijderen i.p.v. garbage collectors die efficient bulk deletes kunnen doen.).

Bovendien heb je in C++ veel regels/statements nodig om iets te bereiken, en de kans is groot dat je uiteindelijk meer met de taal C++ aan het stoeien bent dan met je werkelijke algoritme.

Kies voor een hogere taal die geoptimaliseerde numerieke libraries heeft, serieus dat werkt veel efficienter.

[BCC]

xx77qq schreef op zaterdag 19 maart 2005 @ 20:17:
[...]
C++ lijkt me geen goede keus. Als je dat niet erg goed beheerst wordt het een zooitje. Bovendien is het in C++ veel te gemakkelijk om bijzonder inefficiente code te maken (copy constructors die onderwater inefficient veel data heen en weer verplaatsen, destructors die element voor element verwijderen i.p.v. garbage collectors die efficient bulk deletes kunnen doen.).

Bovendien heb je in C++ veel regels/statements nodig om iets te bereiken, en de kans is groot dat je uiteindelijk meer met de taal C++ aan het stoeien bent dan met je werkelijke algoritme.

Kies voor een hogere taal die geoptimaliseerde numerieke libraries heeft, serieus dat werkt veel efficienter.

*Kuch* C# *Kuch*

[LauPro]

Wie het omzetten (of aanpassen) uiteindelijk gaat doen is nu nog niet zo van belang in eerste instantie, de man zelf wil iig het porten niet meer zelf gaan doen. Hooguit wat ouderhoud. Mogelijk dat ik het doe of dat bepaalde onderdelen worden uitbesteed (door bijvoorbeeld studenten). Het gaat er om dat de man in kwestie op dit punt een beslissing moet nemen die het op lange termijn zo min mogelijk werk met zich mee brengt.

Het publiceren naar dergelijke tijdschriften zijn zeer tijdrovende projecten. Hij is nu al 3 jaar bezig met voorbereiding voor het publiceren, naar verwachting zal het over 2 jaar helemaal klaar zijn. Nu de zaak onder mom 'dan ben ik er vanaf' online gooien zou dus zonde zijn omdat in de wetenschapswereld men erg veel waarde hecht aan dergelijke publicaties.

C++ is wat complexer, dat klopt. Echter lijkt het mij wel een taal die behoorlijk is accepteerd door de wetenschap. En de bedoeling is dus wel dat het uiteindelijke project zal worden uitgevoerd door mensen die bekwaam in de taal zijn (het hele project staat of valt erbij min of meer).

@MSalters: Hebben die VBA programmeurs een C++/QT frontend gemaakt? Of een frontend op de C++/QT backend?

[Verwijderd]

BCC schreef op zaterdag 19 maart 2005 @ 18:23:
Het is de enige bekende platform onafhankelijke taal (ja, C ook wel tot op zekere hoogte)

offtopic:
Je bedoelt zeker: C vanaf zekere hoogte?

[MrBucket]

LauPro schreef op zaterdag 19 maart 2005 @ 21:09:
Wie het omzetten (of aanpassen) uiteindelijk gaat doen is nu nog niet zo van belang in eerste instantie, de man zelf wil iig het porten niet meer zelf gaan doen. Hooguit wat ouderhoud.

C++ is wat complexer, dat klopt. Echter lijkt het mij wel een taal die behoorlijk is accepteerd door de wetenschap. En de bedoeling is dus wel dat het uiteindelijke project zal worden uitgevoerd door mensen die bekwaam in de taal zijn (het hele project staat of valt erbij min of meer).

Daar ging het me om, idd. Anders had je bij je keuze rekening moeten houden met welke talen bekend zijn bij hem en wat hij redelijkerwijs moet leren om productief te zijn. Maar dat is geen beperking, dus.

Overigens lijkt me C++ (in de handen van een ervaren C++-programmeur) een goede keuze qua toepassingsmogelijkheden, flexibiliteit, snelheid en houdbaarheid van de code.

[Verwijderd]

Ik werk nu een tijdje met R (www.r-project.org) en dat is een buitengewoon krachtige taal voor allerlei wetenschappelijke vraagstukken en berekeningen.
Het wordt verspreid onder de GPL, en wordt actief doorontwikkeld.
Het maken van grafieken wordt goed ondersteund.
een minpuntje is de user-interface, standaard is dat een CLI, maar er zijn verschillende subprojecten om daar verandering in te brengen.

[LauPro]

Het punt is dat de applicatie een aantal nieuwe methodes kent om data weer te geven. Dat is met name omdat het nog niet bestaat als het ware. Mede daarom is het vrij moeilijk om ook een scheiding aan te gaan brengen omdat er zowel op 'Logisch' vlak als zowel 'Grafisch' vlak een aantal nieuwe concepten zijn.

Overigens even een random quote uit de code voor de liefhebber .

Visual Basic:

   '_________________________________________________________________
   'nb: bij eerste keer aanklikken is jaNon1% = 0 en jaNon2% = 0
   'nb: Sorry, this is hopeless complicated !!!!!!!!!!!!!!!!!!!

[Verwijderd]

LauPro schreef op zaterdag 19 maart 2005 @ 18:16:
Het voorstel om de GUI en het rekenwerk apart te scheiden spreekt mij heel erg aan. Echter dan zul je dus een soort van protocol op moeten zetten.

Je moet de core met een goede interface maken. Alle GUI elementen moet je uit de core houden. Je hebt geen protocol nodig, want als je de twee zaken goed gescheiden houdt kan je gewoon een core-DLL maken, of de core-functies met RPC aanroepen, of een andere GUI met de core-bestanden compilen. Het gaat om de scheiding op architectuur-niveau.

Verder kan je misschien GnuPlot gebruiken voor de grafieken, scheelt je alweer een hoop GUI code.

[MrBucket]

LauPro schreef op zaterdag 19 maart 2005 @ 22:22:
Het punt is dat de applicatie een aantal nieuwe methodes kent om data weer te geven. Dat is met name omdat het nog niet bestaat als het ware. Mede daarom is het vrij moeilijk om ook een scheiding aan te gaan brengen omdat er zowel op 'Logisch' vlak als zowel 'Grafisch' vlak een aantal nieuwe concepten zijn.

Overigens even een random quote uit de code voor de liefhebber .

Visual Basic:

   '_________________________________________________________________
   'nb: bij eerste keer aanklikken is jaNon1% = 0 en jaNon2% = 0
   'nb: Sorry, this is hopeless complicated !!!!!!!!!!!!!!!!!!!

hehe...

Maar hij heeft niet "vanwege performance-redenen" al zijn locale variabelen maar globaal gedeclareerd omdat ze dan niet elke keer gealloceerd hoeven te worden (en zodat ze "voor het gemak" ook gebruikt worden om parameters door te geven)?

Het gebeurt...

[Johnny]

In je startpost heb je het over een heleboel forms (formulieren) waarmee de applicatie kan worden bestuurd. Als het er echt een heleboel zijn, kun je deze misschien heel handig met XML opslaan. Er is namelijk een enorm aanbod aan XML User Interface toolkits waarmee je alle formulieren kunt beschrijven, en dan converteren naar wat je maar wilt en daarmee platform-, en tijdsonafhankelijk bent.

[ Voor 4% gewijzigd door Johnny op 19-03-2005 22:58 ]

[LauPro]

Verwijderd schreef op zaterdag 19 maart 2005 @ 22:36:
[...]
Je moet de core met een goede interface maken. Alle GUI elementen moet je uit de core houden. Je hebt geen protocol nodig, want als je de twee zaken goed gescheiden houdt kan je gewoon een core-DLL maken, of de core-functies met RPC aanroepen, of een andere GUI met de core-bestanden compilen. Het gaat om de scheiding op architectuur-niveau.

Dat ligt er een beetje aan. Het pakket zal op den duur ook op universiteiten worden ingezet, dan is het wel handig als je het wat centraler kan opstellen en dus een aparte 'rekenwerkserver' op kan zetten waar je met client op in logt. Maar die scheiding lijkt me bij C++ sowieso al handig, het zal niet event-driven worden zoals dat bij VB6 het geval is (logica direct achter een event hangen dus).

Verder kan je misschien GnuPlot gebruiken voor de grafieken, scheelt je alweer een hoop GUI code.

Zal ik naar kijken, thanks voor de tip .

De meeste variabelen (bij de file waar ik die quote uit haal zijn dat ongeveer de eerste 100 regels met elk meerdere vars 'gedimmed') zijn globaal, bij de functies vaak een redim. Wat dat betreft is er qua performance niet heel veel aan gedaan. Wat al eerder aan gegeven is: het geheel is bijna helemaal vastgelopen als het gaat om beheersbaarheid, het is nu functioneel. Dus bij een rewrite moet je denk ik ook niet gaan uitzoeken welke var nu waar voor bedoeld was. Toch valt het redelijk mee qua traagheid; alleen bij echt grote databestanden (van een paar honderd MB al), dan loopt de rekentijd toch al snel in de uren. En dat is wel iets wat verbeterd zou moeten worden.

De formulieren opslaan in XML is een mogelijkheid. Echter vraag ik mij af en hoeverre dat haalbaar is. Met name omdat er vrij weinig IDE's zijn naar mijn mening die dergelijke functies gebruiken. Maar het is zeker iets om te bekijken.

[ Voor 8% gewijzigd door LauPro op 19-03-2005 23:27 ]

[Alarmnummer]

LauPro schreef op zaterdag 19 maart 2005 @ 23:26:
[...]
Dat ligt er een beetje aan. Het pakket zal op den duur ook op universiteiten worden ingezet, dan is het wel handig als je het wat centraler kan opstellen en dus een aparte 'rekenwerkserver' op kan zetten waar je met client op in logt.

Volgens mij heb jij geen idee van de complexiteit die dit met zich mee gaat brengen.

Maar die scheiding lijkt me bij C++ sowieso al handig, het zal niet event-driven worden zoals dat bij VB6 het geval is (logica direct achter een event hangen dus).

Wat jij daar noemt is niet eventdriven, dat is namelijk geprutst. Je kunt eventdriven dus niet zomaar even afschrijven omdat jij die kreet een keer in een slechte context voorbij hebt horen komen. Ik durf de stelling nog wel aan dat in de komende 5 jaar event driven (en daaronder valt vaak asynchrone communicatie) een erg veel grotere rol in gaat nemen. Trouwens... als je er goed over nadenkt is een iedere methode call al een event..

elk meerdere vars 'gedimmed') zijn globaal, bij de functies vaak een redim. Wat dat betreft is er qua performance niet heel veel aan gedaan. Wat al eerder aan gegeven is: het geheel is bijna helemaal vastgelopen als het gaat om beheersbaarheid, het is nu functioneel. Dus bij een rewrite moet je denk ik ook niet gaan uitzoeken welke var nu waar voor bedoeld was.

BIj een rewrite zul je tot de conclusie moeten komen dat de huidige aanpak een hoop gepruts is en dat je iets goeds neer moet gaan zetten. Misschien dat de man 30 jaar ervaring heeft met het ontwikkelen van 1 specialistisch onderdeel, maar van een degelijke architectuur heeft hij duidelijk geen kaas gegegeten. Verder zou ik keuzes mbt tot snelheid van een taal als de bliksem bij het grof vuil gooien en eerst eens af te gaan vragen hoe het in grote lijnen opgezet kan worden. Misschien dat een taal zoals c++ sneller is dan java, maar het valt wel in de zelfde orde van grote. Als ik dit zo een beetje aanhoor, dan heeft hij niets meer aan c++ dan aan een andere mainstreamtaal omdat er dus nog zo enorm op lost geklooi wordt. Zorgt dat je het geklooi opgelost krijgt.. en daarbij kan ik je de garantie geven.. dat gaat je niet zomaar even lukken.

Echter vraag ik mij af en hoeverre dat haalbaar is. Met name omdat er vrij weinig IDE's zijn naar mijn mening die dergelijke functies gebruiken. Maar het is zeker iets om te bekijken.

Tja..

Mijn tip:
blijf lekker verder broddelen en trek geen blik open met problemen Want die ga je krijgen, en als ik dit zo aanzien kan je ze gegarandeerd niet goed oplossen.
Wil je niet broddelen? Haal er dan iemand bij die weet waar hij het over heeft Op GoT heeft iedereen namelijk de behoefte onzinnge replies te geven puur en alleen om te laten zien hoe 'slim' ze wel niet zijn zonder te kijken hoe praktisch hun antwoorden zijn.

Jij (en jouw buurman) hebben schijnbaar de kennis niet om dit in goeie banen te leiden. Dat is absoluut niet erg. Maar probeer niet te doen alsof je denkt dat je het in goeie banen kunt leiden, want dan ga je gewoon knetterhard op je bek.

[ Voor 19% gewijzigd door Alarmnummer op 20-03-2005 00:44 ]

[Verwijderd]

Macros schreef op zaterdag 19 maart 2005 @ 19:58:
Als ik hem was zou ik het eerst maar eens publiceren, als het dan positief onthaald wordt en je wilt het onder GPL uitbrengen kan je altijd nog een rewrite doen. Nu heb je grote kans dat je weer 5 jaar bezig bent met een rewrite in je eentje waardoor je dan weer gedeeltelijke een verouderde code-base hebt. Als het nou doorbreekt kan je het altijd nog door derden laten herschrijven.

Wat heeft de GPL hier nou mee te maken. Een hoop wetenschappelijk georienteerde software is gewoon closed source en op commerciele basis verkrijgbaar. Voorbeeldje: Eviews. Daar staat trouwens een Nobelprijswinnaar bij de credits

Eigenlijk zie ik dan ook geen verschil tussen wetenschappelijke software en andere software. De standaard ideeen voor programma's die lang mee moeten gaan gelden dus hier ook. Probeer voor de core functionaliteit vendor specifieke talen als GW, Quick, Real of Visual Basic en Delphi te mijden, zodat je niet meer met vendor lock-ins te maken krijgt en houdt je aan een algemene standaard. Fortran en Cobol lijken mij trouwens ook niet zo'n goed idee. Probeer daar maar eens ontwikkelaars voor te krijgen Java is wat mij betreft een vraagteken (Enkel Sun ontwikkeld de taal, dus eigenlijk ook een vendor lock-in.) dus kom je al snel bij ansi C++.

Voor de GUI kun je veel meer korte termijn denken. 10 jaar geleden was alles dos en tekst schermen, nu heeft alles een GUI en zie je ook de Webapplicaties opgang maken. De eisen die aan een GUI gesteld worden veranderen dus vrij snel en je zult je GUI dan ook vaker moeten herschrijven.

Een voorbeeldje. In de 30 jaar dat hier een bepaald programma ontwikkeld wordt is de core feitelijk nooit herschreven (is nog steeds COBOL) maar zijn er meerdere gebruikersomgevingen op die core functionaliteit gebouwd. Bij die gebruikersomgevingen wordt tegenwoordig echt geen gebruik meer gemaakt van COBOL.

[alienfruit]

Mijn oom heeft trouwens hetzeflde probleem die heeft een programam gemaakt in MODULA-2 alleen die krijgt hij niet meer aan de praat in Windows XP (met SP2) Dikke pecht Nu kunnen we niet meer uit rekenen hoeveel ventilators er in de tunnel in verweggistan nodig is

[MSalters]

LauPro schreef op zaterdag 19 maart 2005 @ 21:09:
@MSalters: Hebben die VBA programmeurs een C++/QT frontend gemaakt? Of een frontend op de C++/QT backend?

VBA frontend op C++ backend, ter vervanging van C++/Qt frontend.

[LauPro]

Alarmnummer schreef op zondag 20 maart 2005 @ 00:33:
Volgens mij heb jij geen idee van de complexiteit die dit met zich mee gaat brengen.

Het is niet iets dat direct nodig is; echter op langte termijn natuurlijk wel een mooie oplossing. Maar het kan best zijn dat er meer mensen aan het porten gaan werken, waarschijnlijk krijg ik daar een vrij kleine rol in of helemaal geen. We zijn slechts aan het uitzoeken wat nu de juiste koers is voor het programma de komende tijd.

Wat jij daar noemt is niet eventdriven, dat is namelijk geprutst. Je kunt eventdriven dus niet zomaar even afschrijven omdat jij die kreet een keer in een slechte context voorbij hebt horen komen. Ik durf de stelling nog wel aan dat in de komende 5 jaar event driven (en daaronder valt vaak asynchrone communicatie) een erg veel grotere rol in gaat nemen. Trouwens... als je er goed over nadenkt is een iedere methode call al een event..

Wat ik heb begrepen is dat wanneer je direct je code in een functie stopt die wordt aangeroepen na het ontvangen van userinput er dan sprake is van event-driven programmen (althans dat staat in de eerste regels van een VB6 boek dat hier ergens op de plank staat). Maargoed er zijn meerdere definities van in omloop, dus het kan zijn dat ik het daarmee mis heb.

BIj een rewrite zul je tot de conclusie moeten komen dat de huidige aanpak een hoop gepruts is en dat je iets goeds neer moet gaan zetten. Misschien dat de man 30 jaar ervaring heeft met het ontwikkelen van 1 specialistisch onderdeel, maar van een degelijke architectuur heeft hij duidelijk geen kaas gegegeten. Verder zou ik keuzes mbt tot snelheid van een taal als de bliksem bij het grof vuil gooien en eerst eens af te gaan vragen hoe het in grote lijnen opgezet kan worden. Misschien dat een taal zoals c++ sneller is dan java, maar het valt wel in de zelfde orde van grote. Als ik dit zo een beetje aanhoor, dan heeft hij niets meer aan c++ dan aan een andere mainstreamtaal omdat er dus nog zo enorm op lost geklooi wordt. Zorgt dat je het geklooi opgelost krijgt.. en daarbij kan ik je de garantie geven.. dat gaat je niet zomaar even lukken.

De man zelf wil eigenlijk niet meer het programma gaan porten naar een andere taal zoals ik het al aan gaf. Alleen in de huidige staat kan het absoluut niet worden gepubliceerd (de broncode). Dat zou een negatief effect op zijn publicaties e.d. kunnen hebben. Los daarvan dat het geen enkel nut heeft, vrijwel niemand wordt er wijs uit. Ik denk dat enkel een zeer ervaren programmeur dat zou kunnen, en laat nu net de doelgroep niet uit ervaren programmeurs bestaan/

Mijn tip:
blijf lekker verder broddelen en trek geen blik open met problemen Want die ga je krijgen, en als ik dit zo aanzien kan je ze gegarandeerd niet goed oplossen.
Wil je niet broddelen? Haal er dan iemand bij die weet waar hij het over heeft Op GoT heeft iedereen namelijk de behoefte onzinnge replies te geven puur en alleen om te laten zien hoe 'slim' ze wel niet zijn zonder te kijken hoe praktisch hun antwoorden zijn.

Jij (en jouw buurman) hebben schijnbaar de kennis niet om dit in goeie banen te leiden. Dat is absoluut niet erg. Maar probeer niet te doen alsof je denkt dat je het in goeie banen kunt leiden, want dan ga je gewoon knetterhard op je bek.

Het bovenstaande lijkt me wat kort door de bocht. Doordat we dus juist niet die kennis hebben om een dergelijk project in goede banen te leiden gooi ik het hier op GoT. Wat er uiteindelijk besloten gaat worden dat zal zeker deels gebaseerd zijn op dit topic. Maar het is absoluut niet zo dat we een dergelijk project in gaan met te hoge eisen. Kijk, voor dergelijke projecten is ook gewoon subsidie beschikbaar, dus mocht het zo zijn dat er bepaalde middelen nodig zijn dan is dat niet zo zeer het punt. Echter wil je natuurlijk proberen om zoveel mogelijk in eigen hand te houden zodat je het programma op je eigen titel kan publiceren.

[MSalters]

Alarmnummer schreef op zondag 20 maart 2005 @ 00:33:
[rekenserver]
Volgens mij heb jij geen idee van de complexiteit die dit met zich mee gaat brengen.

3-5 dagen werk? Dat is reeel als je een goede backend/frontend scheiding hebt met wel shared disk/user accounts

[...]

BIj een rewrite zul je tot de conclusie moeten komen dat de huidige aanpak een hoop gepruts is en dat je iets goeds neer moet gaan zetten. Misschien dat de man 30 jaar ervaring heeft met het ontwikkelen van 1 specialistisch onderdeel, maar van een degelijke architectuur heeft hij duidelijk geen kaas gegegeten. Verder zou ik keuzes mbt tot snelheid van een taal als de bliksem bij het grof vuil gooien en eerst eens af te gaan vragen hoe het in grote lijnen opgezet kan worden. Misschien dat een taal zoals c++ sneller is dan java, maar het valt wel in de zelfde orde van grote.
[...]
Wil je niet broddelen? Haal er dan iemand bij die weet waar hij het over heeft Op GoT heeft iedereen namelijk de behoefte onzinnge replies te geven puur en alleen om te laten zien hoe 'slim' ze wel niet zijn zonder te kijken hoe praktisch hun antwoorden zijn.

Even wat weggeknipt, maar wel veelzeggend. Rekencode is geen GUI code; Java wordt daar aan de lopende band nog steeds getrashed. Daar zijn een aantal redenen voor: een hoge geheugengebruik bij veel kleine objectjes( zodra Java swap raakt is het verschil 3 ordes van grootte ), minder locality of reference, onvoldoende controle over essentiele zaken als 'stride', vectorisatie verhoudt zich slecht tot polymorfisme. Allemaal zaken die in dit soort specialistische code meer uitmaken dan de 10-15% snelheid in de GUI. Denk je echt dat de bestaande code een paar uur aan het tekenen is?

[Alarmnummer]

LauPro schreef op zondag 20 maart 2005 @ 01:45:
Wat ik heb begrepen is dat wanneer je direct je code in een functie stopt die wordt aangeroepen na het ontvangen van userinput er dan sprake is van event-driven programmen (althans dat staat in de eerste regels van een VB6 boek dat hier ergens op de plank staat).

Zegt misschien genoeg over vb... maar event driven programming is niet zo erg.. Al je code achter een eventlistener raggen is wel erg... (en dat moet je dus ook niet doen).

De man zelf wil eigenlijk niet meer het programma gaan porten naar een andere taal zoals ik het al aan gaf. Alleen in de huidige staat kan het absoluut niet worden gepubliceerd (de broncode). Dat zou een negatief effect op zijn publicaties e.d. kunnen hebben. Los daarvan dat het geen enkel nut heeft, vrijwel niemand wordt er wijs uit. Ik denk dat enkel een zeer ervaren programmeur dat zou kunnen, en laat nu net de doelgroep niet uit ervaren programmeurs bestaan

Ik denk niet dat een zeer ervaring programmeur noodzakelijk is om de broncode te begrijpen. Maar dat je juist een zeer ervaren programmeur nodig hebt om het eindresultaat in goeie banen te leiden. Kijken welke talen, platformen, algoritmes en datastructuren gekozen moeten worden.

Het bovenstaande lijkt me wat kort door de bocht. Doordat we dus juist niet die kennis hebben om een dergelijk project in goede banen te leiden gooi ik het hier op GoT. Wat er uiteindelijk besloten gaat worden dat zal zeker deels gebaseerd zijn op dit topic.

Tip: niet doen. Je hebt te weinig informatie gegeven waarmee mensen je inhoudelijk een antwoord kunnen geven op je vraag. En verder zijn er te veel mensen die dingen zeggen waar je geen flikker aan hebt/mee kan.

Als er geld is: ga naar een serieus it bedrijf en kijk wat de mogelijkheden zijn. En misschien dat je nog wat hulp kan krijgen uit de academische hoek... Maar afgaan wat hier op GoT gezegd wordt is misschien wel het domste wat je kan doen...

[Alarmnummer]

MSalters schreef op zondag 20 maart 2005 @ 01:54:
[...]

3-5 dagen werk? Dat is reeel als je een goede backend/frontend scheiding hebt met wel shared disk/user accounts

Waar heb je het over? Ik heb het over het in goeie banen leiden van al die projecten waarbij ik 0.0 idee heb van wat die man allemaal heeft gemaakt en hoe dit het beste opgelost zou kunnen worden. En jij komt meteen met concrete getallen aanzetten.. Magisch.. of onzin.. take your pick.

Even wat weggeknipt, maar wel veelzeggend. Rekencode is geen GUI code; Java wordt daar aan de lopende band nog steeds getrashed. Daar zijn een aantal redenen voor: een hoge geheugengebruik bij veel kleine objectjes( zodra Java swap raakt is het verschil 3 ordes van grootte ),

Zodra java swapt? Wat is dat??? En verder 1) hoe vaak doe jij iets met java en ben jij subjectief tov c++ 2) hoe noodzakelijk is deze performance winst (aangezien er dus nog 10.000 meer noodzakelijke dingen zijn waarop eerst bezuinigt kan worden.. bv kiezen van betere datastructuren).

Daarom blijf ik bij mijn stelling: het maakt geen flikker uit voor welke mainstream taal je gaat... er valt toch nog genoeg ellende te knappen dat je toch 0.0 merkt van taal specifieke optimalisaties.

minder locality of reference, onvoldoende controle over essentiele zaken als 'stride', vectorisatie verhoudt zich slecht tot polymorfisme. Allemaal zaken die in dit soort specialistische code meer uitmaken dan de 10-15% snelheid in de GUI.

Ok.. ga nu eens terug naar het 1e bericht.. Dacht jij nou echt dat het wat uitmaakt voor welke taal de beste man zou gaan?? Hij loopt te prutsen met een max lengte van arrays die naar file weggeschreven moeten worden.. dacht jij nou echt c++ performance winst interessant was???

En verder zou ik niet weten wat je bedoelt met die "10-15% snelheid in gui".

[ Voor 20% gewijzigd door Alarmnummer op 20-03-2005 02:16 ]

[Johnny]

Alarmnummer schreef op zondag 20 maart 2005 @ 02:00:

Als er geld is: ga naar een serieus it bedrijf en kijk wat de mogelijkheden zijn. En misschien dat je nog wat hulp kan krijgen uit de academische hoek... Maar afgaan wat hier op GoT gezegd wordt is misschien wel het domste wat je kan doen...

Inderdaad, je kan een GoT-topic het beste vergelijken met een brainstormsessie. Binnen korte tijd heb je een heleboel creatieve ideeen en inzichten, maar een heleboel daarvan zijn niet (direct) geschikt om wat mee te doen in de huidige opzet.

Het is leuk om je referentiekader te verbreden en te zien wat er allemaal beschikbaar is, maar uiteindelijk zul je het zelf moeten doen.

[Verwijderd]

Houdbaarheid van software en broncode is een interessant probleem (eigenlijk houdbaarheid van alle data en media wel... wie kent het Domesday-verhaal nog? ).
BASIC is hier zeker geen goede taal voor... sowieso omdat er zoveel dialecten van zijn. Als je in VB ontwikkelt, zit je meteen aan VB vast, je kunt de code niet zomaar even gebruiken in een andere omgeving, zoals Realbasic of Powerbasic. Zelfs VB.NET lukt al niet.

Betere kandidaten zijn talen met duidelijke standaarden. De twee belangrijkste die mij te binnen schieten zijn FORTRAN en C/C++. Als je bv je code netjes volgens de FORTRAN77-standaard schrijft, dan zal deze code met bijna iedere compiler zonder aanpassingen werken.
Zo zijn er voor C en C++ ook ANSI standaarden en dergelijke.
Vooral ANSI C is een hele goede standaard, dat werkt bijna overal. Dat is natuurlijk ook wel een goede aanwijzing dat dat in de toekomst zal blijven werken.
Met C++ is het iets lastiger, er zijn de laatste jaren diverse standaarden opgesteld, maar de meeste compilers lopen nog wat achter met het implementeren hiervan.

Persoonlijk schrijf ik meestal wat ik 'C+-' noem... C-code met een vleugje C++, in feite. De meeste standaard-functies zoals classes, operator overloading, virtual functions en dergelijke, die werken in C++ overal wel. Dingen als templates worden iets lastiger, die houd ik altijd een beetje simpel (ook voor mezelf wel prettig, is makkelijker te begrijpen als ik het later teruglees).
Ik denk dat dit voor 'houdbare' code ook wel een goede strategie is. Hoe minder gebruik je maakt van exotische functionaliteit, hoe minder kans je hebt dat het niet meer gaat werken.

De keuze tussen FORTRAN en C++ is niet zo makkelijk... FORTRAN is van oudsher de wetenschappelijke taal... maar C++ is tegenwoordig minstens zo goed, en is veel bekender omdat het ook voor een heleboel gebieden buiten de wetenschap gebruikt wordt. C/C++ is het 'engels' van de programmeertalen, zeg ik altijd. Enorm veel mensen die het gebruiken/begrijpen, en veel documentatie en tools zijn specifiek op C/C++ gericht. Het lijkt me dan ook dat C/C++ voorlopig de beste toekomst heeft... FORTRAN is nu al een hele obscure taal (wordt op de meeste scholen/universiteiten al jaren niet meer gebruikt, voor zover ik weet), en zodra de hele FORTRAN-generatie met pensioen is, zou het zomaar kunnen dat FORTRAN gaat verdwijnen.

Ik denk dat C++ het programmeren ook een stuk makkelijker maakt, als je de taal eenmaal een beetje beheerst. FORTRAN is niet zo highlevel, heeft meer weg van C dan van C++. Je zult FORTRAN dus wat sneller doorhebben, maar als je doorzet met C++, zal het z'n vruchten zeker afwerpen. Persoonlijk raad ik altijd aan om eerst met C te beginnen, en als je dat goed beheerst, kun je makkelijk de overstap naar C++ maken. Je kunt gewoon geleidelijk de features van C++ gaan gebruiken in je C-code. Je hebt dan ook inzicht in wat C++ precies 'onder de motorkap' doet (alles is naar C te vertalen). In feite kun je C++ gebruiken om dingen die je al in C deed, wat netter en eenvoudiger op te schrijven.

Qua performance zullen de twee talen elkaar weinig ontlopen.
Dus ik zou zelf C++ aanraden... maar over 50 jaar durf ik niets te garanderen

Er werd ook C# genoemd, maar dat is nog wat pril. Het is op zich een mooie taal, maar omdat het momenteel nog echt gekoppeld is aan Microsoft, zou het hetzelfde lot kunnen treffen als VB.
Voor Java geldt hetzelfde, vind ik. Het is vooral Sun die de JVMs ontwikkelt. Als die ineens ophouden te bestaan, en Java is niet populair genoeg, dan zou het best eens kunnen dat er voor toekomstige OSen en architecturen geen JVMs meer ontwikkeld worden... Daar zit je dan.
Sowieso word je bij Java niet goed van die versies... Bij iedere versie worden er weer zoveel oude functies 'deprecated', en zoveel nieuwe functies toegevoegd die precies hetzelfde doen...
Dat is ook niet bevorderlijk voor de houdbaarheid. Heb ik altijd een groot nadeel van Java gevonden... Hoewel voorlopig alle deprecated code nog gewoon werkt, tot aan Java 1.0 toe, voor zover ik weet... De vraag is alleen: voor hoelang nog?

Het idee van een losse GUI is zeker goed. De GUI-module is sowieso een 'wegwerp'-onderdeel. Zoals al gezegd, het is niet echt mogelijk om een GUI te schrijven die echt portable is... En dat betekent dus ook min of meer dat je niet echt een GUI kunt schrijven die tot ver in de toekomst zal blijven werken.
De twee GUIs die het langste meegaan op het moment zijn de Windows GUI en X... Als je pure Win32-code schrijft, of pure X-code, dan is de kans groot dat het lang mee zal gaan. Maar dat is niet echt een gebruikersvriendelijke manier van GUIs ontwikkelen.
Het lijkt me beter om de GUI zo simpel mogelijk te maken (zo veel mogelijk functionaliteit in de 'core' plaatsen, en in C++ schrijven), zodat je de bijna onvermijdelijke rewrites van de GUI zo eenvoudig mogelijk maakt.

Verder denk ik dat een eerste versie met MFC in C++ een aardige start is. MFC is een wrapper om de Win32-code... Zolang Win32 blijft werken, blijft deze wrapper ook werken. Het maakt het alleen wat makkelijker om forms te ontwerpen en dergelijke (een andere wrapper mag natuurlijk ook, zoals bv ATL... als je de sourcecode er maar van hebt... Dan kun je iig altijd nog een eigen versie bouwen als MS besluit om de libraries niet langer mee te leveren). Dan heb je volgens mij een GUI die een zeer gunstige balans heeft tussen de houdbaarheid en de investering in het ontwikkelen ervan.

Een andere optie zou kunnen zijn om een web-interface te maken met PHP oid... Het voordeel is dat browsers redelijk universeel zijn, en dat ze waarschijnlijk nog heel lang bij ons zullen blijven. Het nadeel is dat je in feite het probleem alleen verplaatst... Nu ben je in feite afhankelijk van de code op de webserver die de GUI moet gaan verzorgen, en die kan net zo goed niet lang houdbaar zijn.

[ Voor 5% gewijzigd door Verwijderd op 20-03-2005 02:51 ]

[LauPro]

Alarmnummer schreef op zondag 20 maart 2005 @ 02:00:
Zegt misschien genoeg over vb... maar event driven programming is niet zo erg.. Al je code achter een eventlistener raggen is wel erg... (en dat moet je dus ook niet doen).

Mja zo is het nu dus wel opgebouwd. Er hangen hele lappen code achter forms. Dit is nogal flink wat uitzoeken omdat het geheel behoorlijk met elkaar verweven is. (Het verwijderen van 1 knopje kan ervoor zorgen dat de hele berekening stuk loopt.)

Ik denk niet dat een zeer ervaring programmeur noodzakelijk is om de broncode te begrijpen. Maar dat je juist een zeer ervaren programmeur nodig hebt om het eindresultaat in goeie banen te leiden. Kijken welke talen, platformen, algoritmes en datastructuren gekozen moeten worden.

Nou, uiteindelijk zullen mensen het programma willen toetsen. Want wie zegt niet dat er bijvoorbeeld gewoon statische data in zit in plaats van een baanbrekende formule. Op dat soort factoren moet de code straks kunnen worden gecontrolleerd. Als je als programmeur je code gesloten maakt dan kan je in principe de gebruiker alles wijs maken.

Als er geld is: ga naar een serieus it bedrijf en kijk wat de mogelijkheden zijn. En misschien dat je nog wat hulp kan krijgen uit de academische hoek... Maar afgaan wat hier op GoT gezegd wordt is misschien wel het domste wat je kan doen...

Hier spreek je jezelf wat tegen, als ik niet af mag gaan op wat er op GoT gezegd wordt dan moet ik jouw stelling ook negeren . Maar ik gebruik je punt, we zullen dan ook niet zomaar het diepe in duiken. Ik denk wel dat het verstandig is dat ik dit soort dingen bespreek met mensen die er met min of meer dagelijkse basis mee bezig zijn .

Het idee om het pakket volledig webbased te maken heb ik al eerder besproken. Dit is op zich een leuke constructie. Maar om nu direct PHP te pakken lijkt me wat gortig, ik denk dat PHP het niet zo fijn vind om met data files te werken van honderden MB's per stuk. Webbased applicaties hebben toch altijd wel een zekere robustheid nodig. Ik denk dat dat veel overhead gaat vragen. Los van alle client-issues en het ondervangen van berekeningen die 20 minuten duren (de meeste browsers houden het na een paar minuten wel voor gezien met het opvragen van een request). Je komt dan snel op iets als cron uit met uiteindelijk een HELL van afhankelijkheden (Webserver, Data Storage, Cron, Webbrowser etc).

@ddbruijn, allereerst; mooi verhaal. Met name dat MFC klinkt interessant, alleen je hebt het over win32 code... AMD64 staat al voor de deur en Intel werkt ook hard aan de weg. Best kans dat het binnen 5 jaar weer zo ver is. Daarnaast is portabiliteit op zich ook een punt dat in het achterhoofd moet worden gehouden.

Waar het uiteindelijk om draait is dat er nu niet (weer) in een 'trend' wordt gestapt. Momenteel is java inderdaad heel erg hot en C# is een prachtige taal. Alleen ik ben bang dat ze beide over 10 jaar door weer iets nieuws worden vervangen. Eerder kwam het punt terug over waarom deze software langer mee zou moeten gaan dan normaal. Dat is een beetje vanuit het oogpunt dat bijvoorbeeld de wet van Newton ook niet elke 10 jaar herschreven wordt. Het liefst zien we dat er straks een soort van snapshot gemaakt wordt van deze toepassing en dat het vervolgens gewoon bruikbaar blijkt. In het kader daarvan is Java wél ideaal omdat je deze VM over 50 jaar waarschijnlijk als een plugin je systeem heb hangen terwijl je bij de C++ tegenhanger toch wel heel erg afhankelijk bent van het systeem met bepaalde calls (bij een C++ moet je deze later gaan wrappen vergelijkbaar met Wine naar mijn idee).

Dat zou op zich wel frappant zijn imo, kiezen voor een momenteel ietwat tragere oplossing in Java welke op lange termijn winst oplevert.

Wat ik me nog af vraag, een aantal mensen gaven aan dat ze zelf ook dergelijke trajecten hebben uitgevoerd. Het lastigste lijkt me de documentatie in deze. Nu is het zo dat het programma vrij nauw met de documentatie is. Dit zal dus betekenen dat ook al deze documentatie zal moeten herschreven. Maar omdat de stof vrij complex is in sommige gevallen dus je toch het een en ander terug moeten koppelen tussentijds met de 'opdrachtgever'.

[ Voor 21% gewijzigd door LauPro op 20-03-2005 03:57 ]

[MSalters]

Alarmnummer schreef op zondag 20 maart 2005 @ 02:07:
[...]

Waar heb je het over? Ik heb het over het in goeie banen leiden van al die projecten waarbij ik 0.0 idee heb van wat die man allemaal heeft gemaakt en hoe dit het beste opgelost zou kunnen worden. En jij komt meteen met concrete getallen aanzetten.. Magisch.. of onzin.. take your pick.

Ik heb het over een server/client implementatie met de rekencode op de server. De schatting van 3-5 dagen is gebaseerd op het extra werk nadat de frontend/backend scheiding gedaan is.

[...]

Zodra java swapt? Wat is dat??? En verder 1) hoe vaak doe jij iets met java en ben jij subjectief tov c++ 2) hoe noodzakelijk is deze performance winst (aangezien er dus nog 10.000 meer noodzakelijke dingen zijn waarop eerst bezuinigt kan worden.. bv kiezen van betere datastructuren).

Swap is het gebruik van virtual memory. Dacht dat het een algemeen bekende term was.
Mijn laatste project was een Java project. Daar was geheugengebruik geen probleem, wegens de ACID eisen zal alle data toch in een DB. Het was wel een expliciet getrokken conclusie, die ook afgestemd is met de opdrachtgever.

Hoe noodzakelijk is performance winst? Met berekeningen die een paar uur duren is 10-15% al relevant, laat staan 50% of meer. Inderdaad helpen goede data structuren. Daar zit 'm dus echt de pijn. Integer in Java is dat niet. Kijk ook naar het hele gedoe rondom strict vs relaxed floating point. Om die reden zijn er dus ook veel minder numerieke libraries gemaakt in Java
( 80 C++ om 8 Java volgens deze neutrale bron )

Je ziet dat het reference material daar Java niet eens noemt.

[MSalters]

Verwijderd schreef op zondag 20 maart 2005 @ 02:41:
Verder denk ik dat een eerste versie met MFC in C++ een aardige start is. MFC is een wrapper om de Win32-code... Zolang Win32 blijft werken, blijft deze wrapper ook werken.

Daar zitten een behoorlijke lijst kanttekeningen aan. MFC wordt niet maar actief ontwikkeld, en Microsoft is aan het nadenken hoe ze er vanaf komen. Het is ook een berucht ingewikkelde library, met een heleboel legacy problemen (ouder dan C++ standaard, origineel ontwikkeld voor 16 bits compilers zonder templates, etc)

Qt is eerder genoemd, en Qt voor Windows gebruikt dezelfde Win32 API. Het blijft dus net zolang draaien. Diezelfde code werkt alleen ook met Qt voor Linux, dus je bent niet eens afhankelijk van de Win32 API.

[Alarmnummer]

MSalters schreef op zondag 20 maart 2005 @ 08:55:
[...]

Ik heb het over een server/client implementatie met de rekencode op de server. De schatting van 3-5 dagen is gebaseerd op het extra werk nadat de frontend/backend scheiding gedaan is.

Tja... dat zal volledig afhankelijk zijn van welke technieken hier toegepast gaan worden. Verder heeft de man een heel zooi applicaties die uiteraard ook allemaal wel weer specifieke eisen hebben. Een uitspraak over hoe lang zoiets gaat duren zou ik niet durven geven.

Swap is het gebruik van virtual memory.Dacht dat het een algemeen bekende term was.

Het is een algemeen bekende term, maar ik zie de specifieke relatie met Java niet. Windows zal bij gebrek aan geheugen voor iedere applicatie gaan swappen.. deze eer is niet alleen aan Java voorbehouden.

Mijn laatste project was een Java project. Daar was geheugengebruik geen probleem, wegens de ACID eisen zal alle data toch in een DB. Het was wel een expliciet getrokken conclusie, die ook afgestemd is met de opdrachtgever.

Het is wel vrij gebruikelijk dat er een stuk caching plaats vind op perstistable objecten. Anders krijg je een ongelovelijk brakke performance. Ik gebruik Hibernate als OR mapper en die heeft zelf een standaard cache aan boord.. (kunnen ook andere in worden gezet). Dus zo vreemd is het niet om objecten in het geheugen te houden.

Verder. hoeveel geheugen zat er in die bak? 16 mb? Ik heb zelf nog niet vaak geheugen troubles gehad en 512 mb extra kost tegenwoordig toch geen kont meer.

Inderdaad helpen goede data structuren. Daar zit 'm dus echt de pijn.

Daar zit hier alleen maar de pijn als ik de berichten zo eens bekijk.

Integer in Java is dat niet.

Wat heeft die er mee te maken? Integers zijn object wrappers om een int primitieve. Gebruik je alleen als je een int primitive wilt plaatsen op de plek waar een object wordt gevraagt.. meer niet. Je gaat ze niet gebruiken in high performance routines.. Ik hoop niet dat jouw mening over java en performance hierop is gebaseerd.

[quote]
Kijk ook naar het hele gedoe rondom strict vs relaxed floating point. Om die reden zijn er dus ook veel minder numerieke libraries gemaakt in Java
( 80 C++ om 8 Java volgens deze neutrale bron )
Dat zou best kunnen. 1) c++ gaat al heel wat meer jaartjes mee.. 2) als je de laatste druppels ergens uit wilt persen is c++ een betere keus..

De vraag is of dit noodzakelijk is. Jullie geven de keus ferrari, opel calibra gti... terwijl de man niet eens kan autorijden.

[Verwijderd]

LauPro schreef op zondag 20 maart 2005 @ 03:45:
@ddbruijn, allereerst; mooi verhaal. Met name dat MFC klinkt interessant, alleen je hebt het over win32 code... AMD64 staat al voor de deur en Intel werkt ook hard aan de weg. Best kans dat het binnen 5 jaar weer zo ver is. Daarnaast is portabiliteit op zich ook een punt dat in het achterhoofd moet worden gehouden.

Het verschil tussen Win16 en Win32 was al heel klein, qua GUI... en voor zover ik weet is er bij Win64 helemaal geen verschil... De code zou met een recompile meteen moeten werken op XP64, als het goed is (mits je netjes met pointers om bent gegaan, maar de VS.NET compiler waarschuwt daar wel voor).
Verder was MFC maar een voorbeeld, zoals ik al zei, ATL, Qt of wat dan ook, dat mag ook. Als je de source maar hebt. Zolang je de source hebt, kun je altijd de wrapper zelf compilen.

[Verwijderd]

Verwijderd schreef op zondag 20 maart 2005 @ 11:58:
[...]


Het verschil tussen Win16 en Win32 was al heel klein, qua GUI... en voor zover ik weet is er bij Win64 helemaal geen verschil... De code zou met een recompile meteen moeten werken op XP64, als het goed is (mits je netjes met pointers om bent gegaan, maar de VS.NET compiler waarschuwt daar wel voor).
Verder was MFC maar een voorbeeld, zoals ik al zei, ATL, Qt of wat dan ook, dat mag ook. Als je de source maar hebt. Zolang je de source hebt, kun je altijd de wrapper zelf compilen.

Dit laatste is natuurlijk niet helemaal waar. Probeer maar eens MFC voor OS X te compilen. MFC maakt uiteindelijk gebruik van windows API calls. Heb je geen windows is MFC dus niet bruikbaar. Ook al heb je de source.

[LauPro]

Alarmnummer schreef op zondag 20 maart 2005 @ 09:08:
Kijk ook naar het hele gedoe rondom strict vs relaxed floating point. Om die reden zijn er dus ook veel minder numerieke libraries gemaakt in Java
( 80 C++ om 8 Java volgens deze neutrale bron )
Dat zou best kunnen. 1) c++ gaat al heel wat meer jaartjes mee.. 2) als je de laatste druppels ergens uit wilt persen is c++ een betere keus..

De vraag is of dit noodzakelijk is. Jullie geven de keus ferrari, opel calibra gti... terwijl de man niet eens kan autorijden.

Ik maak hieruit op dat Java eigenlijk geen taal is om hele grote algoritmes in te gooien? Niet kunnen autorijden zou ik niet zeggen, technisch zit het op zich wel goed in elkaar. Alleen een goede structuur is ver te zoeken. Ik denk dat dit ook een beetje aan VB6 te danken is. Je kan met VB6 eigenlijk geen goede structuren op zetten (als in OO). Er zijn wel mogelijkheden om klassen te maken maar imo erg beperkt. Met C++ kan je jezelf eigenlijk niet beperken omdat je daar veel vrijer in bent, in VB6 en Java programmeer je als het ware binnen een 'box'.

[Alarmnummer]

LauPro schreef op zondag 20 maart 2005 @ 15:26:
[...]
Ik maak hieruit op dat Java eigenlijk geen taal is om hele grote algoritmes in te gooien?

Je kan er niet verder naast zitten. Java is uitstekend geschikt om grote algoritmes in uit te schrijven. Alleen kun je met c++ nog iets meer gaan tunen en tweaken om nog meer performance eruit te krijgen. De vraag is echt of je bereid bent om je code totaal te verneuken voor wat performance winst. Een nieuwe cpu van een paar honder euro kan dezelfde performance winst geven en daarbij blijft je code ook nog eens leesbaar. Ik heb vaak genoeg c en c++ code gezien waarbij het erg lastig was om het achterliggende idee te zien.

Niet kunnen autorijden zou ik niet zeggen, technisch zit het op zich wel goed in elkaar.

Laten we even de begrippen goed krijgen.
1) inhoudelijke techniek (de wetenschappelijke zaken waar de man zo lang mee is bezig geweest)
2) implementatie techniek.

1 zal vast wel goed zijn... maar bij hem is 2 dus een puinzooi.

Met C++ kan je jezelf eigenlijk niet beperken omdat je daar veel vrijer in bent, in VB6 en Java programmeer je als het ware binnen een 'box'.

Probeer alsjeblieft zelf geen conclussies te trekken want je zit er volledig naast. In java kan je meer dan genoeg (er worden genoeg wetenschappelijke projecten opgezet in Java waarbij java niet vaak een beperkende factor is qua technische mogelijkheden).

Dus niet zo snel conclucies trekken want je hebt de kennis niet om dit te kunnen doen..

[MrBucket]

Zowel Java als C++ kunnen heel goed gebruikt worden om algoritmes mee te implementeren. Zeker als je het vergelijkt met VB, die is daar naar mijn idee toch een stuk minder voor geschikt.

Weet je trouwens of in het VB-project gebruik wordt gemaakt van aparte libraries voor speciale datatypen, of zijn die allemaal zelf geschreven? Zouden er datatypes of -structuren in aanmerking komen om door een bestaande library afgehandeld te worden?

Heb je enig idee in hoeverre de gebruikte datatypes, datastructuren en algoritmes in een net OO-jasje gevangen kunnen worden?

[LauPro]

Alarmnummer schreef op zondag 20 maart 2005 @ 15:51:
Ik heb vaak genoeg c en c++ code gezien waarbij het erg lastig was om het achterliggende idee te zien.

Dat is dus ook niet de bedoeling. Uiteindelijk moet de code leesbaar zijn zodat anderen mensen deze code makkelijk kunnen toetsen. Als we de code zo optimaal zouden tunen waardoor het onleesbaar wordt zijn we weer terug bij af.

1 zal vast wel goed zijn... maar bij hem is 2 dus een puinzooi.

Dat is correct.

Probeer alsjeblieft zelf geen conclussies te trekken want je zit er volledig naast. In java kan je meer dan genoeg (er worden genoeg wetenschappelijke projecten opgezet in Java waarbij java niet vaak een beperkende factor is qua technische mogelijkheden).

Dus niet zo snel conclucies trekken want je hebt de kennis niet om dit te kunnen doen..

Met alle respect, we moeten natuurlijk wel een beslissing nemen. En idd, ik ben niet iemand met tientalle jaren ervaring op dit vakgebied, maar wat zou dan een mogelijkheid zijn? Direct naar een bureau stappen die hier gespecialiseerd in is? Het artikel moet eerst worden gepubliceerd en in de tussentijd willen we zelf kijken wat we kunnen doen om de code te verbeteren.

@MrBucket: De types die zijn gebruikt zijn eigenlijk alleen integers, doubles, strings en een aantal long-varianten. Maar geen tropische types, ik geloof dat er een paar types zelf zijn gedefinieerd, maar dat is dan om niet teveel argumenten bij een functie mee hoeven te geven. Maar ook constructies waarbij arrays gevuld worden met verschilende types (dimmed as any) komen voor. Al zou je dus een andere taal overwegen dan is denk ik 80% van de code zoals die nu is gewoon niet direct portbaar en die moet je dan al herschrijven. Zeker omdat sommige integers nog als var% geschreven zijn (Basic stuff dus).

[Alarmnummer]

LauPro schreef op zondag 20 maart 2005 @ 16:08:
[...]
Dat is dus ook niet de bedoeling. Uiteindelijk moet de code leesbaar zijn zodat anderen mensen deze code makkelijk kunnen toetsen. Als we de code zo optimaal zouden tunen waardoor het onleesbaar wordt zijn we weer terug bij af.

Precies...

Daarom denk ik dat de meeste mainstream (oo) talen hier wel geschikt voor zijn. De performance zal bij geen van deze talen de beperkende factor vormen.

Met alle respect, we moeten natuurlijk wel een beslissing nemen.

De beslissing over taal en platform is eigelijk een van de meest 'definitieve' beslissing aangezien de rest van de beslissingen hier aan is gerelateerd. Niets is zo lastig om van taal en platform te wisselen. Trek hieruit je conclusies (hint: jij kunt die beslissing niet nemen) (ik trouwens nu ook niet )

[MrBucket]

LauPro schreef op zondag 20 maart 2005 @ 16:08:
@MrBucket: De types die zijn gebruikt zijn eigenlijk alleen integers, doubles, strings en een aantal long-varianten. Maar geen tropische types, ik geloof dat er een paar types zelf zijn gedefinieerd, maar dat is dan om niet teveel argumenten bij een functie mee hoeven te geven. Maar ook constructies waarbij arrays gevuld worden met verschilende types (dimmed as any) komen voor. Al zou je dus een andere taal overwegen dan is denk ik 80% van de code zoals die nu is gewoon niet direct portbaar en die moet je dan al herschrijven. Zeker omdat sommige integers nog als var% geschreven zijn (Basic stuff dus).

Hmm, dan zijn numerieke libraries dus geen groot issue.

Van hetgeen wat ik nu zo gelezen heb, zou ik mijn keuze (voor niet-GUI onderdelen iig) beperken tussen C++ en Java.

De kar van Pascal / Delphi wordt volgens mij nu echt door Borland getrokken, en hetzelfde geldt voor C# en Microsoft. Bovendien is C# nog niet zo lang op de markt, en heeft het nog niet zo'n stevige basis kunnen krijgen als de andere genoemde talen. Als C# geen stevige basis kan houden, dan is de taal met 10 jaar mss uit de roulatie.

Ddbruijn heeft volgens mij een goed punt wbt Fortran77:

Verwijderd schreef op zondag 20 maart 2005 @ 02:41:
FORTRAN is van oudsher de wetenschappelijke taal... <...> FORTRAN is nu al een hele obscure taal (wordt op de meeste scholen/universiteiten al jaren niet meer gebruikt, voor zover ik weet), en zodra de hele FORTRAN-generatie met pensioen is, zou het zomaar kunnen dat FORTRAN gaat verdwijnen.

Ik zou zo niet durven zeggen in hoeverre de combinatie Java / Sun een geval is van vendor lock-in, maar voor mijn gevoel is dit minder het geval dan met Delphi en C#. C en C++ zijn totaal niet vendor-afhankelijk, maar ik denk dat het ontbreken van echte OO-mogelijkheden en standaard datastructuren in C toch wel behoorlijke minpunten zijn.

C en C++ hebben denk ik de langste levensduur, en Java maakt denk ik ook een goede kans.

[xx77qq]

LauPro schreef op zondag 20 maart 2005 @ 16:08:
[...]
Dat is dus ook niet de bedoeling. Uiteindelijk moet de code leesbaar zijn zodat anderen mensen deze code makkelijk kunnen toetsen. Als we de code zo optimaal zouden tunen waardoor het onleesbaar wordt zijn we weer terug bij af.
[...]

Precies, vroegtijdige optimalisaties zijn een grote valkuil en daar hoort wat mij betreft ook de keuze van een programmeertaal bij (want de taal is zo snel, efficient, geoptimaliseerd voor win32, x64, etc..). Kies een taal waarin je het makkelijkst een probleem denkt op te kunnen lossen.

@MrBucket: De types die zijn gebruikt zijn eigenlijk alleen integers, doubles, strings en een aantal long-varianten. Maar geen tropische types, ik geloof dat er een paar types zelf zijn gedefinieerd, maar dat is dan om niet teveel argumenten bij een functie mee hoeven te geven. Maar ook constructies waarbij arrays gevuld worden met verschilende types (dimmed as any) komen voor. Al zou je dus een andere taal overwegen dan is denk ik 80% van de code zoals die nu is gewoon niet direct portbaar en die moet je dan al herschrijven. Zeker omdat sommige integers nog als var% geschreven zijn (Basic stuff dus).

Arrays vullen met verschillende types is meestal niet zo straight forward in de wat lagere/compiled talen. Misschien is het handig om je buurman een voorbeeld probleem hier neer te laten leggen, wij kunnen dat dan in onze favoriete taal oplossen en je buurman krijgt een idee hoe het in zijn werk gaat in verschillende programmeertalen.

Je requirement om meerdere types in een array te stoppen is een fluitje van een cent in python. Hier een voorbeeld code van een array met 3 elementen en we proberen deze elementen met 10 en 10.5 te vermenigvuldigen. Zoals je ziet kan je zelfs een string met 10 vermenigvuldigen (maar niet met 10.5):

Python:

een_array = [10, 20, "hallo"]

for item in een_array:
    print item, "* 10 = ", item * 10
    try:
        print item, "* 10.5 = ", item * 10.5
    except TypeError, e:
        print 'Error "%s" is not an number. Errormessage: %s' % (item, e)

geeft als resultaat:

code:

10 * 10 =  100
10 * 10.5 =  105.0
20 * 10 =  200
20 * 10.5 =  210.0
hallo * 10 =  hallohallohallohallohallohallohallohallohallohallo
hallo * 10.5 =  Error "hallo" is not an number. Errormessage: can't multiply sequence to non-int

[MrBucket]

xx77qq schreef op zondag 20 maart 2005 @ 19:01:
Precies, vroegtijdige optimalisaties zijn een grote valkuil en daar hoort wat mij betreft ook de keuze van een programmeertaal bij (want de taal is zo snel, efficient, geoptimaliseerd voor win32, x64, etc..). Kies een taal waarin je het makkelijkst een probleem denkt op te kunnen lossen.

Het probleem zit 'm momenteel meer in de complexiteit van het geheel dan in het niet flexibel genoeg zijn van de huidige implementatietaal. Ik zekere zin wil je nu juist door OO-paradigma's je flexibiliteit indammen, zodat je een nette structuur krijgt in je programma.

Arrays vullen met verschillende types is meestal niet zo straight forward in de wat lagere/compiled talen.

Niet helemaal waar. In C kan je void * of unions gebruiken, voor C++ kun je pointers naar base-classes opslaan, of een template-aanpak a la boost:any gebruiken.

Bovendien heb ik er een hard hoofd in dat er veel situaties zullen zijn waarin een array van verschillende types een goede designoplossing is (en te verkiezen boven een gezamenlijke abstract base class). Volgens mij wordt een array van variants veel te vaak misbruikt voor iets waar je eigenlijk een array van structs had willen hebben...

Je requirement om meerdere types in een array te stoppen is een fluitje van een cent in python.

Was dit een requirement van TS? Daar zal ik dan even overheen hebben gelezen hebben...

Hoe dan ook, python is een geinterpreteerde taal wat de performance toch enigszins zal drukken. En over de userbase en houdbaarheid van python zou ik ook geen uitspraken durven doen.

Ik begin zelf trouwens wel steeds meer geinteresseerd te raken in Python, ik ben van plan er binnenkort een keer mee te gaan stoeien, lijkt me wel cool Maar desondanks denk ik niet dat Python voor zo'n monsterproject een goede kandidaat is.

[Verwijderd]

MrBucket schreef op zondag 20 maart 2005 @ 19:28:
[...]

Hoe dan ook, python is een geinterpreteerde taal wat de performance toch enigszins zal drukken. En over de userbase en houdbaarheid van python zou ik ook geen uitspraken durven doen.

Ik wel Volgens een recent onderzoek van InfoWorld gebruikt 14% van de programmeurs Python - vorig jaar was dat 6% - hierbij moet wel worden gezegd dat een groot deel van deze programmeurs Python alleen in een thuissituatie gebruikt. Verder is er een zeer actieve community, en voor de meeste zaken bestaan prima libraries. Over de houdbaarheid durf ik ook niets te zeggen - Python bestaat nu 11 jaar en zit zoals je hebt gezien in de lift - maar koffiedik kijken durf ik niet aan

Hèt grote probleem van Python is idd snelheid; toch wordt het redelijk veel gebruikt in de wetenschappelijke wereld (dit zeg ik overigens niet uit eigen ervaring) - sterker nog, het is ontwikkeld op ons eigen CWI. Misschien kan de TS daar wat informatie inwinnen over hoe zij het, al dan niet in Python, zouden aanpakken. Wil je een beetje een idee krijgen van de beschikbare modules in Python voor wetenschappelijke doeleinden: op http://www.python.org/pypi?:action=browse&asdf=385 staat een onvolledige lijst. Zie ook www.scypi.org.

Kortom, Python lijkt mij prima geschikt voor een "wetenschappeijk programma" (wat dat dan ook moge zijn), maar ik kan dit specifieke geval niet beoordelen.

</python-marketing>

Ik begin zelf trouwens wel steeds meer geinteresseerd te raken in Python, ik ben van plan er binnenkort een keer mee te gaan stoeien, lijkt me wel cool Maar desondanks denk ik niet dat Python voor zo'n monsterproject een goede kandidaat is.

Waarom niet?

BTW: Heb er zelf geen ervaring mee, maar kan Haskell oid niets voor de TS beteken?

[Daos]

MrBucket schreef op zondag 20 maart 2005 @ 16:39:
[...]

Hmm, dan zijn numerieke libraries dus geen groot issue.

Van hetgeen wat ik nu zo gelezen heb, zou ik mijn keuze (voor niet-GUI onderdelen iig) beperken tussen C++ en Java.

De kar van Pascal / Delphi wordt volgens mij nu echt door Borland getrokken, en hetzelfde geldt voor C# en Microsoft. Bovendien is C# nog niet zo lang op de markt, en heeft het nog niet zo'n stevige basis kunnen krijgen als de andere genoemde talen. Als C# geen stevige basis kan houden, dan is de taal met 10 jaar mss uit de roulatie.

Ddbruijn heeft volgens mij een goed punt wbt Fortran77:

[...]


Ik zou zo niet durven zeggen in hoeverre de combinatie Java / Sun een geval is van vendor lock-in, maar voor mijn gevoel is dit minder het geval dan met Delphi en C#. C en C++ zijn totaal niet vendor-afhankelijk, maar ik denk dat het ontbreken van echte OO-mogelijkheden en standaard datastructuren in C toch wel behoorlijke minpunten zijn.

C en C++ hebben denk ik de langste levensduur, en Java maakt denk ik ook een goede kans.

Wij gebruiken Fortran nog op school, maar het meeste doen we in C. Rekenen doen we trouwens in matlab, maar dat veroudert ook snel.

Zoals iemand eerder al aan gaf kan je het beste ANSI standaarden gebruiken. Bij Java is het nu al merkbaar dat er geen standaard is. Er zijn al heel veel functies die je niet meer kan gebruiken (Deprecated). Bv. In 2000 heb ik nog geleerd om de .show() bij een JFrame te gebruiken. Tegenwoordig mag dat niet meer en moet je .setVisible() gebruiken.

[ Voor 4% gewijzigd door Daos op 20-03-2005 21:21 . Reden: linkje naar Sun ]

[MrBucket]

@_J_R_R: Thanks voor de info betreffende Python

Verwijderd schreef op zondag 20 maart 2005 @ 19:47:
Kortom, Python lijkt mij prima geschikt voor een "wetenschappeijk programma" (wat dat dan ook moge zijn), maar ik kan dit specifieke geval niet beoordelen.

BTW: Heb er zelf geen ervaring mee, maar kan Haskell oid niets voor de TS beteken?

Nu ga ik me een beetje op glad ijs begeven, dus als ik ergens de mist in ga: feel free to correct me.

Ik kan me goed voorstellen dat men op een aantal universiteiten Python gebruikt omdat het een toegankelijke syntax kent en flexibeler is dan een taal als java of C++. (De laatsten zijn strongly typed, en de compiler zal je bij het minste geringste afstraffen - of nog erger, wel compilen maar een stuk code opleveren wat niet doet wat jij er mee voor ogen had.)

Maar geen van de informatica-opleidingen die ik ken gebruikt Python als een pijler om programmeervaardigheden mee te onderwijzen. Dus misschien dat het bij niet-informatica studies als een handig hulpmiddel wordt gezien om bepaalde experimenten in software te realiseren, mede door zijn lage leercurve?

Wat betreft Haskel: deze taal is declaratief, terwijl de huidige codebase helemaal in Basic (=procedureel) is geschreven. Converteren naar een declaratieve taal maakt de stap veel groter, denk ik...

[xx77qq]

MrBucket schreef op zondag 20 maart 2005 @ 19:28:
[...]

Het probleem zit 'm momenteel meer in de complexiteit van het geheel dan in het niet flexibel genoeg zijn van de huidige implementatietaal. Ik zekere zin wil je nu juist door OO-paradigma's je flexibiliteit indammen, zodat je een nette structuur krijgt in je programma.

[...]

Niet helemaal waar. In C kan je void * of unions gebruiken, voor C++ kun je pointers naar base-classes opslaan, of een template-aanpak a la boost:any gebruiken.

Inderdaad het kan, maar het kost je een stuk meer statements/regels code dan in een taal die dat standaard al begrijpt. Boost is een erg prettige library, hetzelfde voor STL, maar de leercurve is stijl en de leesbaarheid van de code wordt er minder op.

Bovendien heb ik er een hard hoofd in dat er veel situaties zullen zijn waarin een array van verschillende types een goede designoplossing is (en te verkiezen boven een gezamenlijke abstract base class). Volgens mij wordt een array van variants veel te vaak misbruikt voor iets waar je eigenlijk een array van structs had willen hebben...

Ben ik met je eens, maar soms is dat juist veel praktischer om iets op de verkeerde manier te doen omdat die programmeertaal nu eenmaal zo in elkaar zit. Maar dat komt dan meer omdat je iets wilt doen waar die programmeertaal niet zo goed voor geschikt is.

Hoe dan ook, python is een geinterpreteerde taal wat de performance toch enigszins zal drukken. En over de userbase en houdbaarheid van python zou ik ook geen uitspraken durven doen.

Python is here to stay punt Waarom, omdat het gewoon werkt. Krachtig en een hele heldere syntax. In python probeer je iets en grote kans dat het gewoon werkt. Mijn ervaring in andere talen is dat je iets probeerd, je krijgt foutmeldingen, moet wat gaan casten/converteren en dan pas werkt het.
Maar het is niet voor alles geschikt, relationele data selecties doe je liever met SQL, time critical handling liever in C/ASM. En zo zijn er legio situaties waar een andere taal beter geschikt is.

Ik begin zelf trouwens wel steeds meer geinteresseerd te raken in Python, ik ben van plan er binnenkort een keer mee te gaan stoeien, lijkt me wel cool Maar desondanks denk ik niet dat Python voor zo'n monsterproject een goede kandidaat is.

Om er eentje te noemen: Google.

Zelf gebruik ik het in realtime embedded omgevingen, 90% python, 10% pure C voor timing critische zaken.
Goed, ik zal proberen niet door te slaan Maar na jaren C/C++ STL,boost/php geprogrammeer heb ik met Python het idee van jee wat is dit krachtig en vooral leuk!

[Verwijderd]

Ten eerste: Python is bijna helemaal strongly typed. Alleen tussen ints en floats vinden wel eens type conversies plaats. Zoiets als:

code:

a = "1" + 1

geeft je een keiharde TypeError Python is wel dynamically typed; het type van een object staat dus nooit van te voren vast (duck typing noemen we dat). Wat ik zelf zo fijn vind aan Python is "simple thing are easy, complicated things are possible" (ofzo). Simpele dingetjes kosten je geen uren om te maken. Aan de andere kant is Python wel een complete taal, met goede ondersteuning voor OO.

MrBucket schreef op zondag 20 maart 2005 @ 20:24:
@_J_R_R: Thanks voor de info betreffende Python

Maar geen van de informatica-opleidingen die ik ken gebruikt Python als een pijler om programmeervaardigheden mee te onderwijzen. Dus misschien dat het bij niet-informatica studies als een handig hulpmiddel wordt gezien om bepaalde experimenten in software te realiseren, mede door zijn lage leercurve?

Vaak wordt Python juist gezien als een erg goede eerste programmeertaal, maar ik kan heel goed begrijpen dat men op universiteiten een wat meer mainstream taal kiest. Zoals ik m'n eerdere post al zei, redelijk veel programmeurs kunnen in Python programmeren, maar toch wordt het nog niet heel veel gebruikt in bedrijfsomgevingen. Ik wijt dit zelf vooral in het feit dat er geen bedrijf achter Python zit dat er belang bij heeft dat het veel gebruikt wordt (zoals bij Sun > Java/MS > .NET, etc.). Daarom wordt het waarschijnlijk niet veel onderwezen.

Er is de laatse tijd wel een beetje een discussie aan de gang aan het komen, of Python misschien meer gemarket zou worden. Vooral de PSF (Python Software Foundation), zou te onzichtbaar zijn. Toch wordt Python wel gebruikt bij een aantal grote namen, een paar daarvan staan op http://python.org/Quotes.html .

Ik denk dat de redenen die jij noemt wel kloppen, hoewel ik daar alleen maar over kan speculeren Je kan in Python wel makkelijk experimenteren; je hoeft niet te compilen; heldere, compacte code - dit soort aspecten zorgen ervoor dat je vrij snel dingen kan aanpassen.

PS: Python is vrij traag, vaak wordt dit opgelost door grote bottlenecks in C(++) te schrijven en dan als Python module te gebruiken. Python wordt hier dan gedeeltelijk gebruikt als een prototyping taal, het gebied waar het imho in uitblinkt. Maar ik kan me zo voorstellen dat prototyping in dit geval niet zoveel nut meer heeft.

PPS: http://www.python.org/moin/NumericAndScientific

edit:
Ben je een heel boekwerk aan het typen, is iemand je voor . Google is voor zover ik weet trouwens niet helemaal in Python geschreven. Verder kan ik de ervaringen van de post boven mij alleen maar onderschrijven.

[ Voor 6% gewijzigd door Verwijderd op 20-03-2005 21:08 ]

[.oisyn]

Alarmnummer schreef op zondag 20 maart 2005 @ 15:51:
Je kan er niet verder naast zitten. Java is uitstekend geschikt om grote algoritmes in uit te schrijven. Alleen kun je met c++ nog iets meer gaan tunen en tweaken om nog meer performance eruit te krijgen. De vraag is echt of je bereid bent om je code totaal te verneuken voor wat performance winst. Een nieuwe cpu van een paar honder euro kan dezelfde performance winst geven en daarbij blijft je code ook nog eens leesbaar. Ik heb vaak genoeg c en c++ code gezien waarbij het erg lastig was om het achterliggende idee te zien.

Lekkere beargumentatie ook weer, omdat jij projecten hebt gezien waarin onleesbare C++ code voorkwam betekent dat meteen dat, als je er wat meer uit wilt persen, je code ook gelijk onleesbaar wordt? Onzin natuurlijk, code is zo leesbaar als de schrijver het maakt, optimalisatiedetails veranderen daar in principe weinig aan. Een groot optimalisatiemogelijkheid is bijvoorbeeld het aanmaken van de objecten op de stack ipv op de heap, daar wordt code echt niet minder leesbaar van hoor . Daarnaast, als het om wiskundige code gaat, is die code in C++ 100x zo leesbaar (nee dat is idd niet meetbaar ) puur door de mogelijkheid van operator overloading.

Bottom line is dat optimalisaties in code je code minder leesbaar kán maken, maar dat is natuurlijk niet per definitie zo.

[Alarmnummer]

.oisyn schreef op zondag 20 maart 2005 @ 21:20:
[...]


Lekkere beargumentatie ook weer, omdat jij projecten hebt gezien waarin onleesbare C++ code voorkwam betekent dat meteen dat, als je er wat meer uit wilt persen, je code ook gelijk onleesbaar wordt?

Niet alleen met c(++) code. Ook mijn java programma`s hebben qua duidelijkheid te leiden onder optimalisaties. In c++ kun je echter verder gaan met optimaliseren dan bij Java.

Daarnaast, als het om wiskundige code gaat, is die code in C++ 100x zo leesbaar (nee dat is idd niet meetbaar ) puur door de mogelijkheid van operator overloading.

Tja... en pointerellende schopt al die mooiheid weer in het modder.

Bottom line is dat optimalisaties in code je code minder leesbaar kán maken, maar dat is natuurlijk niet per definitie zo.

Precies..

Maar op het moment dat je niet meer met macro optimalisaties bezig gaat, en je alleen nog maar gaat concentreren op microoptimalisaties dan zal dat (bijna) altijd leiden tot minder leesbare code. Je kunt met c++ echter een stuk meer eruit persen dan bij Java -> en dit zal tot gevolg hebben dat je meer getweakte code krijgt (en dit is minder leesbaar)

[ Voor 7% gewijzigd door Alarmnummer op 20-03-2005 21:50 ]

[Onno]

Daos schreef op zondag 20 maart 2005 @ 19:52:
Bij Java is het nu al merkbaar dat er geen standaard is. Er zijn al heel veel functies die je niet meer kan gebruiken (Deprecated). Bv. In 2000 heb ik nog geleerd om de .show() bij een JFrame te gebruiken. Tegenwoordig mag dat niet meer en moet je .setVisible() gebruiken.

Een standaard betekent niet meteen dat iets een statisch geheel is dat nooit meer veranderen zal. Library functies/methods/enz veranderen ook wanneer er wel 'standaarden' zijn wel, om verschillende redenen. Zo had je vroeger in Unix bijvoorbeeld gethostbyname() om een hostnaam te resolven, terwijl je tegenwoordig geacht wordt getaddrinfo() te gebruiken, en is gethostbyname() deprecated. (want niet thread-safe, en niet echt geschikt voor meerdere address families zoals bijv. IPv6.. maar die twee dingen had je vroeger gewoon niet)

Ook standaarden worden gewoon af en toe geupdate, en versie x+1 zal niet per definitie een superset van versie x zijn. Als je dan toch versie x wilt gebruiken moet je een platform uitzoeken dat aan die versie voldoet.

Meestal zijn implementaties van die standaarden gelukkig wel zo dat ze ook oudere versies nog ondersteunen, en dat is niet anders bij Java. Deprecated methods werken vrijwel zonder uitzondering nog gewoon, je wordt alleen afgeraden om ze nog langer te gebruiken.

[xx77qq]

.oisyn schreef op zondag 20 maart 2005 @ 21:20:
[...]


Lekkere beargumentatie ook weer, omdat jij projecten hebt gezien waarin onleesbare C++ code voorkwam betekent dat meteen dat, als je er wat meer uit wilt persen, je code ook gelijk onleesbaar wordt? Onzin natuurlijk, code is zo leesbaar als de schrijver het maakt, optimalisatiedetails veranderen daar in principe weinig aan.

Mee eens, maar ook ik ben redelijk wat projecten tegengekomen waar optimalisaties teveel ruis introduceren. Helaas ook in mijn eigen projecten, maar dat zegt meer iets van mijn skills.

Een groot optimalisatiemogelijkheid is bijvoorbeeld het aanmaken van de objecten op de stack ipv op de heap, daar wordt code echt niet minder leesbaar van hoor . Daarnaast, als het om wiskundige code gaat, is die code in C++ 100x zo leesbaar (nee dat is idd niet meetbaar ) puur door de mogelijkheid van operator overloading.

En dat is voor mij ook meteen de enige plaats waar operator overloading zinvol is. Operator overloading wordt vaak misbruikt op plaatsen waar zinnige functienamen beter zijn. Krachtige feature, maar gebruik 'm op de juiste plaatsen.

Bottom line is dat optimalisaties in code je code minder leesbaar kán maken, maar dat is natuurlijk niet per definitie zo.

Inderdaad, niet per definitie, maar optimalisaties aanbrengen betekend meestal afwijken van het standaard pad, een binnenweg nemen en zelf wat extra werk verichten om ergens sneller te zijn. Niet altijd even duidelijk, maar soms noodzakelijk.

[Soultaker]

Alarmnummer schreef op zondag 20 maart 2005 @ 21:49:
Niet alleen met c(++) code. Ook mijn java programma`s hebben qua duidelijkheid te leiden onder optimalisaties. In c++ kun je echter verder gaan met optimaliseren dan bij Java.

Probleem met Java-code is dat je naar mijn ervaring al heel snel je code moet ombouwen naar een 'lelijk' alternatief als je efficiëntie wilt. Als je bijvoorbeeld een vector van 2D-samples op wil slaan, dan wil je omwille van de performance graag een array maken waarin de samples elkaar opvolgen en elke sample uit (bijvoorbeeld) twee 32-bits integers bestaat:

code:

+----+----+----+----+----+----+-
| x0 | y0 | x1 | y1 | x2 | y2 |
+----+----+----+----+----+----+--

In Java is dat onmogelijk om te maken, tenminste als je de samples als objecten wil modeleren. Het dichtste wat je bij de buurt kunt komen is een array van integers maken en dan handmatig de juiste indices berekenen als je er wat mee wilt doen.

In C++ is het echter geen enkel probleem om zo'n efficiënte datastructuur te maken die tegelijkertijd op hoog nivo gemodelleerd is. Sterker nog, met een std::vector<std::pair<int, int> > ben je er eigenlijk al (al wil je waarschijnlijk zelf een andere klasse implementeren dan pair, met je eigen operaties erin).

Al met al moet je naar mijn mening geen Java gebruiken als performance op dit soort punten een grote rol speelt. Natuurlijk zijn efficiënte algoritmen in Java nog steeds efficiënt, maar een ruimte-efficiënte object-georienteerde applicatie opzetten is in Java praktisch onmogelijk. In C++ is het echter goed mogelijk om redelijk efficiënte code te schrijven zonder de helderheid geweld aan te doen.

[Macros]

Leuk joh dat geouwehoer over efficientie, maar dat is helemaal het punt niet.
Laat die man het nou maar eerst eens afmaken voordat je gaat denken het over te zetten in een andere taal. Kijk maar naar Duke Nukem Forever. Elke keer stapten ze over op andere technologien. Ze hebben al 4 of 5 3D engines gehad, meerdere physics engines enzovoort. Als je nu over gaat stappen naar iets anders voeg je weer 3 jaar toe aan het project. Maak het eerst eens af, en kijk dan nog eens of je het kan herschrijven in een andere taal.

[Tomatoman]

Soultaker schreef op zondag 20 maart 2005 @ 22:23:
Verhaal over Java en vectors

Zullen we weer ontopic gaan?

Met alle respect voor de buurman, als hij nu al 30 jaar bezig is [norml]([/]8)7[norml])[/] om een stuk code in elkaar te zetten en het nog steeds een puinhoop is, vrees ik dat het nooit wat zal worden. Dat heeft helemaal niets met de programmeertaal te maken en evenmin met de bewering dat 'de taal die hij gebruikt binnen een mum van tijd weer wordt opgevolgd'. Zijn probleem is iets heel anders, namelijk dat hij zijn werk niet afmaakt. Dat heeft weinig met zijn programmeerkunsten te maken en veel met zijn karakter. Ik gok dat hij in zijn huis minstens drie verbouwingen heeft gestart die nooit zijn afgemaakt, dat hij altijd een stapel ongesorteerde post heeft liggen en dat zijn tuin al tijden achterstallig onderhoud heeft.

Na deze met opzet prikkelend geschreven binnenkomer hoop ik dat je begrijpt waar ik naar toe wil. De buurman moet gewoon een streep trekken waar hij nu met zijn programmeerwerk is en eerst afmaken waar hij mee bezig is. Daarna mag hij pas weer iets nieuws toevoegen. Doet hij dat niet, dan duurt het geen 2 jaar voordat hij aan publicatie toekomt, maar verslijt hij minstens nog drie nieuw te verschijnen programmeertalen.

Stappenplan[list=1]• Bevries de huidige status van de codebase. Implementeer geen nieuwe functionaliteit meer, ook al zul je bezweren dat dat moet. Niet overmorgen bevriezen, niet morgen maar nu.
• Maak een tijdplanning aan de hand van onderstaande stappen. Blijkt dit meer dan pakweg anderhalf jaar te kosten, dan moet het plan worden vereenvoudigd, want anders lukt het nooit om binnen twee jaar te publiceren.
• Maak half afgemaakte stukken code af en ga de hele codebase debuggen. Betreft de half afgemaakte code nieuwe functionaliteit, haal die incomplete stukken er dan voorlopig uit. Is afmaken min of meer synoniem aan nieuwe features toevoegen, verwijder die dan. Nogmaals: geen nieuwe functionaliteit meer!
• Klopt de tijdplanning nog? Zo niet: stappenplan uitkleden, zodat de deadlines niet hoeven te verschuiven.
• Schoon alle code op en zorg dat het een net geheel wordt met weinig bugs.
• Klopt de tijdplanning nog? Nog steeds geen nieuwe functionaliteit toevoegen.
• Nu ben je zover dat je een behoorlijke codebase hebt in een misschien wat verouderde taal, maar in ieder geval is het een samenhangend geheel. Trek hier een streep.
• Klopt de tijdplanning nog?
• Hehe, eindelijk is het moment aangebroken om de extra fuctionaliteit toe te voegen die voor de publicatie essentieel is. Zet eerst een deadline wanneer de software definitief af moet zijn. Trek hier de helft van de tijd vanaf, want die tijd is nodig om de nieuwe functionaliteit te debuggen en de nieuwe code netjes te maken. Belangrijk: 1 feature tegelijk implementeren en niet met de volgende beginnen voor de vorige helemaal af is.
• Deadline vestreken? Geen nieuwe features meer, maar publiceren. Die deadline was er niet voor niets!Het klinkt allemaal nogal kinderachtig hoe ik het schrijf, maar ik denk dat dat in dit geval nodig is. Geen gelul, geen excuses, geen andere programmeertaal, maar gewoon afmaken. En geen nieuwe features!

[Daventry]

Ik vraag me nog steeds af waarom je per se van taal wil wisselen.

Goed, de support op VB6 stopt - er komen geen nieuwe security-updates meer. Lekker boeiend. VB3 code draait ook nog steeds op Windows XP, dus zal VB6 code het binnen tien jaar ook nog prima doen in Windows (heb je er enig idee van hoeveel spul er in VB is geschreven? MS gaat heus er voor zorgen dat dat blijft draaien, want dat zou voor bedrijven wel eens een breekpunt kunnen zijn bij het updaten naar een nieuwe Windows versie).

Als ik het goed begrijp is jou buurman een wetenschapper die een beetje kan proggen. Het doelpubliek van je buurman bij zijn publicatie is ongeveer hetzelfde publiek als hij: geen programmeurs maar wetenschapeprs.

Wat je die mensen wil voorschotelen is een taal met een heel simpele syntax, zoals VB. VB is erg leesbaar (bijna Engels) ook voor niet-programmeurs.

Het omzetten naar een andere taal gaat tijd kosten, veel tijd. Wat veel eenvoudiger zou zijn, en ik je zou aanraden, is niet af te stappen van VB (het spul werkt in VB, VB zal binnen tien jaar nog draaien en de syntax is simpel) maar om de bestaande VB code te fatsoeneren.

Dat gaat op zich al tijd genoeg kosten en zal al een helse onderneming zijn. Het bijkomende voordeel is dat je buurman eventueel kan helpen. Hij heeft al aangegeven zich niet met het porten te willen bezighouden. Concreet wil dit zeggen dat als je naar een andere taal overstapt, hij de code amper nog zal kunnen lezen, of toch moeilijker, wegens de hem onbekende syntax.

Als je het nou bij VB houdt, kan die buurman nog steeds je extra uitleg verschaffen en ook de nieuwe code nakijken - je zou toch niet willen dat je, zeker in een puinhoop zoals zijn code, ergens een klein foutje maakt bij het porten waardoor half de functionaliteit naar de maan is.

[Bleh!]

alienfruit schreef op zondag 20 maart 2005 @ 00:55:
Mijn oom heeft trouwens hetzeflde probleem die heeft een programam gemaakt in MODULA-2 alleen die krijgt hij niet meer aan de praat in Windows XP (met SP2) Dikke pecht Nu kunnen we niet meer uit rekenen hoeveel ventilators er in de tunnel in verweggistan nodig is

Probeer eens windows 9x of DOS te installeren in een virtual machine. Zoals vmware/bochs/virtual pc.
Dan werkt het waarschijnlijk wel, alleen via een omweg.

Bochs is open source en gratis en VMware heeft de meeste mogelijkheden.

[Daos]

Onno schreef op zondag 20 maart 2005 @ 22:05:
[...]

Een standaard betekent niet meteen dat iets een statisch geheel is dat nooit meer veranderen zal. Library functies/methods/enz veranderen ook wanneer er wel 'standaarden' zijn wel, om verschillende redenen. Zo had je vroeger in Unix bijvoorbeeld gethostbyname() om een hostnaam te resolven, terwijl je tegenwoordig geacht wordt getaddrinfo() te gebruiken, en is gethostbyname() deprecated. (want niet thread-safe, en niet echt geschikt voor meerdere address families zoals bijv. IPv6.. maar die twee dingen had je vroeger gewoon niet)

Bij ANSI-C zijn ook bepaalde library functies in de standaard gedefineerd. Deze veranderen dus niet.
Unix functies staan niet in een standaard opgesteld.

Ook standaarden worden gewoon af en toe geupdate, en versie x+1 zal niet per definitie een superset van versie x zijn. Als je dan toch versie x wilt gebruiken moet je een platform uitzoeken dat aan die versie voldoet.

Bij elke standaard die ik ken is het zo dat de nieuwe versie een superset van de oude is. Kijk bijvoorbeeld naar C(++), Fortran, VHDL (IEEE-standaard).

Meestal zijn implementaties van die standaarden gelukkig wel zo dat ze ook oudere versies nog ondersteunen, en dat is niet anders bij Java. Deprecated methods werken vrijwel zonder uitzondering nog gewoon, je wordt alleen afgeraden om ze nog langer te gebruiken.

Ik dacht dat de compiler begon te zeuren, maar ik heb het verder niet getest. Ik zal het wel fout hebben.

[Aham brahmasmi]

Ik zat te denken aan IDL, een krachtig pakket veel in de wetenschappelijke wereld wordt gebruikt, met een taal die sterk lijkt op C. De TS zegt alleen nergens duidelijk wat de taak van het te porten programma is, dus het zou kunnen dat IDL toch niet flexibel genoeg is. Misschien wel de moeite waard om te kijken of dit geschikt is. Het is wel een pakket wat op veel universiteiten en wetenschappelijk instellingen/bedrijven gebruikt wordt denk ik.

[Daos]

Aham brahmasmi schreef op maandag 21 maart 2005 @ 11:25:
Ik zat te denken aan IDL, een krachtig pakket veel in de wetenschappelijke wereld wordt gebruikt, met een taal die sterk lijkt op C. De TS zegt alleen nergens duidelijk wat de taak van het te porten programma is, dus het zou kunnen dat IDL toch niet flexibel genoeg is. Misschien wel de moeite waard om te kijken of dit geschikt is. Het is wel een pakket wat op veel universiteiten en wetenschappelijk instellingen/bedrijven gebruikt wordt denk ik.

Ik heb het hier op school nog nooit gezien. Vrijwel alles gaat in C (software), VHDL (hardware) of in Matlab (numerieke wiskunde).

[MSalters]

Daos schreef op maandag 21 maart 2005 @ 10:50:
[...]
Bij ANSI-C zijn ook bepaalde library functies in de standaard gedefineerd. Deze veranderen dus niet.
Unix functies staan niet in een standaard opgesteld.

POSIX? Single Unix Specification (SUS)? Linux Standards Base (LSB)?

[THIJZEL]

Als je buurman de (nieuwe) taal nog moet leren, dan vind ik Java een goede keuze. Java verplicht je namelijk tot OO programmeren( natuurlijk moet je het wel goed aanleren).
Daarnaast zijn C en C++ mijns inziens moeilijker te leren.
Ook is Java platform onafhankelijk, mits je natuurlijk geen OS specifieke functies gaat gebruiken, maar die lijken me hier niet van toepassing.

[LauPro]

Even een update: Vlak een paar maanden na de start van dit topic heeft hij een hartinfarct gehad, daar is hij inmiddels weer helemaal bovenop (of nouja, 30% van zijn hart is afgestorven ) . Aan het programma heeft hij in al deze tijd vrijwel niets meer gedaan (paar kleine taalfoutjes e.d., finetuning).

Functioneel is het programma nu af. Afgelopen week heeft hij mij opnieuw gevraagd of ik er nog eens naar wilde kijken omdat nu al de eerste publicatie wordt gedrukt.

Daaropvolgend heb ik alle applicaties uitvoerig ge-bestudeerd. Het lijkt dat erom dat de omvang op zich mee valt, echter de algoritmen zijn zeer complex.

Aanvullend op tomatoman wil ik het volgende gaan doen:

1. Code freeze (dat is al gebeurd)
2. Inventarisatie van huidige codebase (zie onderstaand)
3. Opdelen van projecten naar modules (aangezien er wat redundantie is)
4. Beschrijven wat de taak van elke module zal zijn
5. Opstellen planning, definitief voorstel doen richting 'opdrachtgever'
6. Daadwerkelijk uitvoeren werkzaamheden
7. Oplevering

Zo zijn er van de 20 projecten ongeveer 3 weegave projecten, 10-voor berekeningen, 1 menu en 1 helpfunctie en de overigen zijn utilities (voor backup van databestanden etc).

Wat ik al met hem had besproken en waar hij wel oren naar had was dat om 1 platform te maken. Binnen dit platform opereren vervolgens de verschillende algoritmen. Dit platform zorgt ook voor de grafische weergave. Dit zal worden gemaakt in C++/QT4. De uiteindelijke overweging is dat er vanuit zijn vakgroep veel gewerkt wordt met C++ en dat hij er zelf (de geringe ervaring die hij heeft) positief tegen over staat mbt de snelheid. Nu wil ik dit wel een beetje nuanceren. Het zwaarste algoritme zorgt ervoor dat mijn AMD XP 3000+ dik 30 minuten staat te stampen, dus ik verwacht dat dat met C++ zeker tot eenderde terug te brengen is.

Dit aangezien het hele project waarschijnlijk open source zal worden. Er zal namelijk behoorlijk wat kritiek komen van buitenstaanders. Die moeten dit dan fijntjes kunnen uitzoeken of er niet een 'fout' in het programma zit.