[Alg] Hoe krachtig is een programmeertaal?

[.oisyn]

Onderstaande topic is afgesplitst vanuit [rml][ Advies] Delphi vs VB6[/rml]

Hieronder komen zo de posts die uit de vorige draad komen, maar iets om aan te denken: wat is volgens jullie de definitie van "kracht"? Is dat bijvoorbeeld hoe efficient (snelheid / grootte) de gecompileerde code gaat worden? Of juist hoe snel je een bepaald doel kan bereiken? Of is het nou juist meer de uitdrukkingskracht die het mogelijk maakt om een complexe bewerking te beschrijven in slechts enkele statements (welke ook wel enigszins te maken heeft met hoe snel je een doel kunt bereiken)? Of is het soms een combinatie van bovenstaande?

Mijn inziens is het de combinatie, maar waarbij de uitdrukkingskracht toch wel iets zwaarder meeweegt. Asm is natuurlijk "het efficientst" als je er een competente programmeur achter zet. De uitdrukkingskracht is echter nihil, en een groot project ermee opzetten zal nooit lukken. Aan de andere kant heb je de functionele talen, met meestal een hele sterke uitdrukkingskracht. Meestal ideaal voor het uitwerken van bepaalde algoritmen, maar meestal een stuk minder sterk in dingen als statemachinges en andere procedurele operaties. Ik zou er geen GUI applicatie mee willen maken iig

Anyway, hier de reacties uit [rml][ Advies] Delphi vs VB6[/rml]

[ Voor 100% gewijzigd door .oisyn op 08-07-2004 00:30 ]

[ILUsion]

Basic is altijd wel een makkelijke taal geweest, zeker om de basis van het programmeren mee te leren (ik denk terug aan mijn QBasic-dagen), daarna ben ik overgestapt naar Visual Basic en VBA maar uiteindelijk miste ik toch wel kracht in de programma's dus nu zit ik bij Delphi (ik heb overigens net Delphi.NET eens geprobeerd, maar echt handig vind ik het niet). Hierna wil ik overstappen op C/C++ omdat die talen toch nog ietsje krachtiger zijn (ook Java spreekt me wel aan maar dan eerder J2ME en dergelijke). Alle .NET-talen hebben een groot voordeel: ze zijn platformonafhankelijk (zeker met de eerste release van Mono) dus een goede investering in de toekomst maar hetzelfde geldt voor Java al is daar de Virtual Machine trager. In dat voordeel ligt ook direct het nadeel: als je een simpel programma hebt dat ook onder Windows 9x en dergelijke moet draaien en de FrameWork meesturen niet gaat, dan zit je beter bij een gewone taal. Nu dat nadeel geldt enkel nu omdat .NET nog niet overal standaard staat, maar dat zou in de toekomst wel eens kunnen veranderen.

Dus kort samengevat:
is het de eerste keer dat je aan het programmeren slaat, dan probeer je eens een Basic-variantje uit
heb je al wat basis, dan moet je weten waarvoor je alles wilt gebruiken en dan kies je maar tussen Object Pascal en de .NET-talen. Ik zou je aanraden om dan voor Delphi te gaan, maar dat is omdat ik Delphi nu goed begin te kennen en omdat ik amper ervaring heb met .NET-talen.

[ Voor 66% gewijzigd door .oisyn op 08-07-2004 00:00 ]

[Tomatoman]

ILUsion schreef op 07 juli 2004 @ 20:12:
[...] dus nu zit ik bij Delphi (ik heb overigens net Delphi.NET eens geprobeerd, maar echt handig vind ik het niet). Hierna wil ik overstappen op C/C++ omdat die talen toch nog ietsje krachtiger zijn (ook Java spreekt me wel aan maar dan eerder J2ME en dergelijke).

Hier moet ik je toch even terugfluiten. Hierover zijn in dit forum talloze discussies geweest en daarin klinkt toch wel consensus door over dit punt: C of C++ is niet 'krachtiger' dan Delphi.

[.oisyn]

tomatoman schreef op 07 juli 2004 @ 20:31:
[...]
Hier moet ik je toch even terugfluiten. Hierover zijn in dit forum talloze discussies geweest en daarin klinkt toch wel consensus door over dit punt: C of C++ is niet 'krachtiger' dan Delphi.

Vind jij templates, template specialization en operator overloading niet onder features vallen die een taal krachtiger maken dan?

[Tomatoman]

.oisyn schreef op 07 juli 2004 @ 20:38:
Vind jij templates, template specialization en operator overloading niet onder features vallen die een taal krachtiger maken dan?

Vind jij dat genoeg om Delphi minder krachtig te noemen dan?

[.oisyn]

Minder krachtig dan C++ ja. Ik zeg toch ook niet dat Delphi niet krachtig genoeg is, maar ik vind wel dat C++ krachtiger is, iets waarvan jij zei dat het niet zo was.

[ Voor 13% gewijzigd door .oisyn op 07-07-2004 20:47 ]

[LordLarry]

.oisyn schreef op 07 juli 2004 @ 20:38:
Vind jij templates, template specialization en operator overloading niet onder
features vallen die een taal krachtiger maken dan?

Operator Overloading zit tegenwoordig in Delphi 8 for .Net, dus wie weet komt het toch nog goed

[Verwijderd]

.oisyn schreef op 07 juli 2004 @ 20:38:
Vind jij templates, template specialization en operator overloading niet onder features vallen die een taal krachtiger maken dan?

Delphi heeft voor al die zaken gelijksoortige functies. Alles is te doen, zij het op een andere manier.

Voorbeeld is multiple inheritance; dit kent delphi niet maar via interfaces is exact hetzelfde systeem te verkrijgen.

Voor de rest lijkt die discussie mij hier redelijk nutteloos, zoals wel meer van de opmerkingen hier geplaatst.

Keep in mind dat we het hier hebben over iemand die gewoon eens wil beginnen met het leren van een taal.

Die gaat niet met genoemde zaken in de weer. Tegen de tijd dat hij dat wel wil, weet hij genoeg van programmeren dat de taalkeuze niet echt spannend meer is.

Beweren dat Delphi minder krachtig is dan C++ is imo niet weten wat Delphi kan, nofi

[.oisyn]

De Generaal: grappig dat je precies templates achterwege laat, toch wel het paradepaardje van C++ en juist datgene wat C++ zo enorm krachtig maakt icm operator overloading (en met operator overloading bedoel ik niet zozeer dat het interessant is dat je zelf een + oid kunt definieren, maar juist dingen als conversion operators, adress-of en dereference operators e.d.).

Beweren dat C++ net zo krachtig is als delphi is imo niet weten wat je met templates allemaal kunt, nofi . En juist weten wat met templates allemaal te doen is vereist enige ervaring met C++. Kijk bijvoorbeeld eens naar boost::lambda en boost::spirit voor mijn inziens de perfecte voorbeelden van wat de combinatie templates en operator overloading je kunt bieden. Dat lukt je niet in Delphi

(en ja, natuurlijk is dit vrij offtopic, maar ik mag toch wel reageren op beweringen die zijn gedaan in de draad? )

LordLarry schreef op 07 juli 2004 @ 21:45:

Operator Overloading zit tegenwoordig in Delphi 8 for .Net, dus wie weet komt het toch nog goed

En generics komt in delphi 9 neem ik aan? Dan wordt het developen idd alweer een stuk fijner

[ Voor 41% gewijzigd door .oisyn op 07-07-2004 22:17 ]

[Verwijderd]

.oisyn schreef op 07 juli 2004 @ 22:12:
(en ja, natuurlijk is dit vrij offtopic, maar ik mag toch wel reageren op beweringen die zijn gedaan in de draad? )

Het ging mij er meer om dat TS niet echt wat heeft aan een Delphi vs. C++ discussie, het was meer sturend bedoeld..

Voor de rest ben ik het gedeeltelijk met je eens. Ja templates zijn krachtig en nee delphi heeft niet een gelijk mechanisme voorhanden. Maar het is wel degelijk te realiseren in Delphi, dan zul je echter zelf aan het programmeren moeten slaan.

Ook jouw voorbeelden zijn echt wel te maken in Delphi, het zal meer tijd vergen.

//edit
om het voorbeeld met de koelpasta even door de mangel te halen:

de 1e computer die je bouwt is er een dikke kans dat je gewoon het thermal pad of goedkope pasta gebruikt. Je haalt dan niet de optimale resultaten, maar het werkt wel. Pas als je nerd-gen zich voldoende ontwikkeld heeft, ga je eens AS kopen.

[ Voor 20% gewijzigd door Verwijderd op 07-07-2004 22:46 ]

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 19:23 ]

[.oisyn]

Verwijderd schreef op 07 juli 2004 @ 22:42:
Voor de rest ben ik het gedeeltelijk met je eens. Ja templates zijn krachtig en nee delphi heeft niet een gelijk mechanisme voorhanden. Maar het is wel degelijk te realiseren in Delphi, dan zul je echter zelf aan het programmeren moeten slaan.

Mja, wat is jouw definitie van 'krachtig' dan precies

Ook jouw voorbeelden zijn echt wel te maken in Delphi, het zal meer tijd vergen.

Het gaat er ook niet om of het wel of niet te maken is (zoals Eelis al zegt, alles is met elke turing-complete taal te maken), het gaat erom hoe makkelijk je het af gaat. In asm kun je ook OO programmeren, of het handig is is een tweede.

[.oisyn]

Vanaf hier weer verder

[ Voor 99% gewijzigd door .oisyn op 08-07-2004 00:00 ]

[Noork]

Misschien is het leuk om even een omschrijving te maken van "krachtig". Ik denk dat een kernbom krachtiger is dan Delphi. Ook mijn Mazda heeft meer kracht dan vb6.

Het ligt er toch gewoon aan wat je ermee wilt doen. Is het mogelijk om datgene te maken dat je beoogt.

[Tomatoman]

Ten eerste zul je in de discussie over 'kracht' of 'krachtigheid' een onderscheid moeten maken tussen de programmeeromgeving en de programmeertaal. Aanvankelijk ging de discussie over de programmeeromgeving, terwijl we het nu over de programmeertaal hebben.


Ten tweede kent krachtigheid van een programmeertaal soms een prijs. Operator overloading is wat dat betreft een prachtig voorbeeld. Het maakt C++ bijzonder krachtig , maar ten koste van de duidelijkheid van de taal. In Pascal en Object Pascal is er bewust voor gekozen de taal zo duidelijk mogelijk te houden. Zo zul je in de meeste gevallen een variabele expliciet moeten typecasten om er een ander datatype van te maken. Dat kost wat extra typewerk, maar maakt de code veel leesbaarder. Al weet ik het niet zeker, ik vermoed dat er bij Object Pascal bewust voor is gekozen operator overloading niet in de taal toe te staan met als voornaamste reden de duidelijkheid van de taal. Aanvankelijk was het in Object Pascal niet eens mogelijk functies te overloaden; pas vanaf versie 5 (of misschien 4) kent de taal deze functionaliteit. Aangezien overloading van functies vanuit het oogpunt van de compiler zeer eenvoudig te implementeren is, moet aan de late introductie een andere reden ten grondslag hebben gelegen: is overloading wel gewenst in de taal?

Wat ik hiermee wil aangeven is dat het ontbreken van bepaalde functionaliteit niet persé een gevolg hoeft te zijn van een zwakte in de taal, maar ook een welbewuste keuze kan zijn. In dat geval is het mijns inziens geen zwakte.

[Emmeau]

.oisyn schreef op 05 juli 2004 @ 15:39:Asm is natuurlijk "het efficientst" als je er een competente programmeur achter zet.

En ook dit geldt alleen maar onder bepaalde voorwaarden, zoals bijv. directe aansturing van hardware.
Neem bijvoorbeeld de huidige generatie C/C++ compilers. Deze kunnen dermate optimaliseren (voor snelheid, of grootte) waar een programmeur nooit zo'n optimalisatie zou kunnen bereiken.

Ik denk dat er zonder context weinig zinnigs te antwoorden is op de exacte vraag "Hoe krachtig is een programmeertaal", maar een vraag als "Welke programmeertaal is in case X de meest krachtige is wel valide.

[.oisyn]

tomatoman: Operator overloading is wat dat betreft een prachtig voorbeeld. Het maakt C++ bijzonder krachtig, maar ten koste van de duidelijkheid van de taal

Maar waarom? Ok, je kunt niet goed zien wat er nou precies gebeurt als er a = b + c staat, maar dat is net zo goed het geval als je een generieke add functie zou maken die je overload voor de betreffende typen: a = add (b, c). Er is gewoon geen enkel verschil. En het een is ook niet duidelijker dan het ander. Het wordt natuurlijk erg als mensen operators gaan definieren met een andere betekenis dan de operator eigenlijk heeft, bijvoorbeeld ineens af gaan trekken bij een +. Nou is dat een extreem voorbeeld, maar de << operator, wat op native types een shift left betekent, wordt ook gebruikt om waarden naar een stream te schrijven. Je kunt hier echter prima harde afspraken over maken, en als iedereen zich eraan houdt en geen rare dingen gaat doen is er niets aan de hand. Je zou bijvoorbeeld ook gewoon kunnen lezen in een functie die write () heet, doe je ook niet.

Daarnaast, templates zouden best onbruikbaar worden als operator overloading niet bestond. Hoe test je bijvoorbeeld a en b in een template (dus waarvan het type niet van tevoren bekend is) op gelijkheid? equals (a, b)? a.equals (b)? Die equals is geen standaard functie die je verder in de taal tegen komt... De == operator echter wel, en die biedt je dan ook een standaard en eenduidige manier om iets te implementeren wat voor iedereen duidelijk is.

Ik zou dus niet zo stellig willen beweren dat operator overloading voor onduidelijkheid zorgt. Natuurlijk, het kan, maar dat kan met gewone functies net zo goed.

[ Voor 4% gewijzigd door .oisyn op 08-07-2004 00:22 ]

[.oisyn]

Emmeau schreef op 08 juli 2004 @ 00:12:
En ook dit geldt alleen maar onder bepaalde voorwaarden, zoals bijv. directe aansturing van hardware.
Neem bijvoorbeeld de huidige generatie C/C++ compilers. Deze kunnen dermate optimaliseren (voor snelheid, of grootte) waar een programmeur nooit zo'n optimalisatie zou kunnen bereiken.

Waarom denk je dat ik erbij heb gezet: "zolang je er een competente programmeur achter zet"? Huidige generatie compilers zijn idd retegoed in optimaliseren, desalniettemin kan een programmeur nog altijd efficientere code schrijven dan een compiler. De winst is misschien minimaal, maar daar gaat het niet om. Feit is dat als je de aller, aller, aller, allersnelste code wilt schrijven je dat het beste met de hand in assembler kunt doen, vermits je verstand hebt van zaken, dat is het punt wat ik wilde maken . C++ code zal altijd compileren naar assembly. Het is dus niet zo dat je met assembly automatisch minder efficiente code schrijft dan een compiler, het zal minstens net zo snel zijn, of sneller.

[ Voor 10% gewijzigd door .oisyn op 08-07-2004 00:24 ]

[Verwijderd]

Ik ben van mening dat de "kracht" van een taal ook te maken heeft met de inzetbaarheid van een programmeertaal, en in hoeverre je toegang hebt tot de mogelijkheden van het besturingssysteem waarop je zit te werken. Volgens mij zijn er namelijk ook verschillende soorten van programmeren :
- low-level : het programmeren van drivers of frameworks waarmee je weer andere programma's opzet
- high-level : het programmeren van gebruikersprogramma's ( die bijvoorbeeld weer gebruik maken van een eerder gemaakt framework )

Als je VB6 en Delphi ( de talen die ik het beste ken ) op die manier gaat bekijken, is het volgens duidelijk welke de meest krachtige taal is.
VB leent zich bijvoorbeeld niet echt voor low-level programmeren (vanwege het ontbreken van goede toegang tot de windows API, het ontbreken van een goede OOP ondersteuning, geen ASM ondersteuning ), maar het high-level programmeren is in VB wel goed ondersteund.
Delphi is daarentegen wel geschikt voor zowel het maken van low-level programma's ( zie bijvoorbeeld de mogelijkheid tot het maken van services en consoles applicaties ) en het maken van high-level applicaties.
Als je het op die manier gaat bekijken, kom ik tot de conclusie dat van die twee, Delphi de meest krachitge taal is.

Waar je ook eens naar moet kijken is naar de taal zoals deze "out-of-the-box" is : Wat kun je standaard met een taal. VB heeft een leuk default lijstje met componenten, maar als je ook maar iets extras wilt, zul je moeten gaan zoeken naar third-party componenten in de vorm van OCX-en en DLL's. Delphi daarentegen heeft een indrukwekkende hoeveelheid standaard componenten en onderdelen ( ik heb menige vb programmeur zijn kaak op de grond zien vallen toen hij de componenten lijst van Delphi zag ), en mocht je iets extra willen, is het eenvoudig om de standaardfunctionaliteit van de reeds aanwezig onderdelen aan te passen.

Een derde overweging is het uitdraaien van je uiteindelijke resultaat. Ik denk dat iedere VB-programmeur de problemen kent van het installeren van een VB applicatie : Je moet een run-time omgeving installeren, en meestal ook een heleboel extra OCX-en en DLL's ( zie vorige punt ). De door VB bijgeleverde en nogal buggy "Package and Deployment Wizard" maakt e.e.a. daarbij niet eenvoudiger.
Delphi daarentegen heeft meestal 1 enkele executable die je zelfs met een batchbestand nog zou kunnen installeren.

Kijkende naar deze drie punten is voor mij Delphi met een score van 3:0 dus duidelijk de meer krachtige taal.

[curry684]

Sorry oisyn maar in die statement moet ik je echt afvallen

Een assemblerprogrammerend mens kan niet meer op tegen een C/C++ compiler op een project dat groter is dan een task scheduler van een OS. En waarom? Ik weet nog toen ik begon met assemblerprogrammeren op de 8502 (C-64 voor de insiders). Goed te doen, goed te managen. Ik klom door naar de 68000 (Amiga). Feesten met self-modifying code, retesnelle code en alles. Toen kwam de crime: de 68020 in de A1200 had ineens 256 bytes cache! Gatver! Ineens kon self-modifying code niet meer! Sterker nog: je moest ineens rekening gaan houden met cache-boundaries, zodat je loops binnen 256 bytes zouden blijven om extra performance te gaan trekken. Kostte wat oefening, maar goed te doen, 256 bytes assembler was nog te overzien.

Waar zitten we tegenwoordig? Een beetje CPU heeft 19 branch prediction pipelines, read-aheads om adresbus-cycli te besparen, een 32Kb L1-cache en 1Mb aan L2-cache. Plots moet je je assembler zo gaan schrijven dat je adresbus-accessing niet sequentieel doet maar er registerwerk tussendoor plakt, desnoods compleet ongerelateerd, om wait states te voorkomen. Cache boundaries lopen op 32Kb afstand minimaal, en if that fails op 1Mb. En je moet je assembler ook nog zo schrijven dat je aan alle AMD en Intel specificaties voldoet zodat de CPU de minste kans heeft om verkeerd te gokken op branch prediction. Dit is een onmenselijke hoeveelheid werk en bijhoudwerk, die een compiler wel kan bevatten en op optimaliseren. Een compiler kan binnen 32Kb een loop proppen door de least-probable execution paths erbuiten te frotten. Een compiler kan overzien waar de meest branch-misses zullen zitten.

Ergo, mijn stelling is dat verdomd goed geschreven C/C++ voor een project vanaf een bepaalde kritieke massa per definitie sneller is dan hetzelfde project door een mens te laten ontwikkelen in assembler. Hierbij heb ik het expres niet over het invoegen van assembler voor kleine routines of lokale ultra-zippy code als kernel task schedulers, daar kun je wel degelijk nog op winnen.

[.oisyn]

Je valt me niet af, ik ben het volledig met je eens maar dat is totaal niet wat ik bedoel . Als je grote projecten volledig gaat implementeren in assembly lukt het je idd niet, door het simpele feit dat het practisch onmogelijk is een compleet project te implementeren op een zo efficient mogelijke manier, maar dat is niet mijn punt. Mijn punt was dat een stukje met de hand geschreven assembly minstens net zo snel is als de code van een compiler (namelijk als de code identiek is), of sneller. De code die een compiler produceert is altijd maar een subset van wat jij met de hand kunt doen. Je kunt dus meer dan een compiler, en derhalve is het mogelijk dat je snellere code kunt maken dan een compiler kan.

Overigens

Dit is een onmenselijke hoeveelheid werk en bijhoudwerk, die een compiler wel kan bevatten en op optimaliseren

In de demoscene werd precies dat gedaan, mind you . CPU specs ernaast, en bijhouden hoeveel cycles een instructie nodig heeft, waarvan ie afhankelijk is en in welke pipeline hij uitgevoerd gaat worden. En aan de hand daarvan instructies ordenen. Idd practisch gezien onmenselijk, toch zijn er wel degelijk mensen die zich ermee hebben bezig gehouden. En ja, dan praat ik dus wel over moderne CPU's he

[ Voor 30% gewijzigd door .oisyn op 08-07-2004 01:06 ]

[Tomatoman]

Goed verhaal curry684. Ik wil er nog een argument aan toevoegen waarom een mens niet in assembler moet gaan zitten klooien (afgezien van wat kritische code snippets misschien). Als je een project gaat uitvoeren in zulke low level code, kost je dat als programmeur ontzettend veel tijd. Zelfs al zou je programma daardoor wat sneller zijn dan een compiler het zou kunnen doen, door de hoeveelheid uren die erin moet worden gestoken wordt het project veel duurder. Een klant zit daar absoluut niet op te wachten. Als hij de helft van de kosten voor dat optimalisatiewerk in assembler zou steken in snellere hardware, is hij per saldo beter af. Niet alleen draait het programma effectief sneller (wat minder efficiënte code op een veel snellere machine), ook kost het minder tijd en geld.

Datzelfde argument is toe te passen op het betoog van FFrenzy. Doordat Delphi veel meer out-of-the-box functionaliteit heeft dan VB6, kun je er sneller een goed programma mee schrijven. De productiviteit van de ontwikkelaars is daardoor groter en de kwaliteit van het eindproduct hoger. Productiviteit is direct te vertalen in de kosten voor de opdrachtgever. Laten bij een vastgestelde functionaliteit nou juist de kosten en de kwaliteit de belangrijkste criteria zijn voor een opdrachtgever... Delphi scoort alweer een punt tegen VB6: 4 - 0 voor Delphi

[Johnny]

Volgens mij is kracht meer een kwestie van the right tool for the job. Iedere taal heeft wel een paar "talenten" waarin hij uitblinkt boven de rest, anders zou de taal geen bestaansrecht hebben en snel verdwijnen in de obscuriteit.

[.oisyn]

Johnny: mwoa, niet direct. Je zou je kunnen afvragen waarom VB.Net nu bestaansrecht heeft, evenals C# met de komst van whidbey. Als ik even alleen kijk naar VB.Net, wat voegt dat toe? Met uitzondering van oude VB6- functies is de beschikbare library exact hetzelfde als die van C#. Ze hebben een syntactisch verschil, meer ook niet. Dit in tegenstelling tot het voorbeeld van Delphi en VB6, waarin wel een enorm verschil zit. VB.Net is er nog voor die mensen die van de VB syntax houden, toch is er nog maar weinig van de oude syntax overgebleven (kon ook niet anders). Waarom is er dan überhaupt nog vraag naar VB.Net? Of andere .Net talen for that matter? Blijkbaar alleen maar omdat er een paar idioten zijn die niet graag een andere taal aan willen leren, ookal kunnen ze exact hetzelfde (niet helemaal waar trouwens)

[ Voor 5% gewijzigd door .oisyn op 08-07-2004 01:43 ]

[JeromeB]

Een programmeur zal prioriteiten moeten stellen bij het maken van een programma.
- welke functionaliteiten ben ik benodigt?
- hoeveel tijd heb ik om het te maken?
- met welke bedoelingen maak ik het?
- voor welke doeleinden moet het geschikt zijn?
- welke kennis heb ik reeds om het te maken?
- welke kennis zal ik moeten verkrijgen?
- hoeveel tijd heb ik om die kennis te verkrijgen?
- etc, etc.

Dit zijn belangrijke vragen bij het kiezen van een geschikte programmeertaal + omgeving. Elke vraag heeft een bepaalde prioriteit die belangrijk is in de keuze.

Het is dus helemaal niet zo belangrijk welke programmeertaal krachtiger is. Het is belangrijk dat de programmeur de geschikte programmeertaal + omgeving gebruikt.

Op dit moment ben ik voornamelijk in een leerfase. Ik bestudeer kort een taal en kijk of deze interessant is kwa mogelijkheden. Dit zet ik dus bovenaan mijn lijstje met prioriteiten. Als ik dit interessant vind dan ga ik daar mee aan de gang en experimenteer er mee. Tijd is dus niet belangrijk voor mij en komt dus onderaan mijn lijstje van prioriteiten.

[party42]

[b][message=21169260,noline]Op dit moment ben ik voornamelijk in een leerfase. Ik bestudeer kort een taal en kijk of deze interessant is kwa mogelijkheden. Dit zet ik dus bovenaan mijn lijstje met prioriteiten. Als ik dit interessant vind dan ga ik daar mee aan de gang en experimenteer er mee. Tijd is dus niet belangrijk voor mij en komt dus onderaan mijn lijstje van prioriteiten.

Dus aan de ene kant bestudeer je aan taal kort, maar toch is tijd niet belangrijk. Persoonlijk denk ik dat je door een korte verkenning in een programmeertaal niet de daadwerkelijke kracht ervan kan ontdekken, wellicht behalve of de IDE je aanspreekt. Als je kijkt naar de strictheid van Delphi (Object Pascal) dan verwacht ik (volgens jou redenatie) dat je deze taal snel links zal laten liggen.

Volgens mij zou je de keuze voor een programmeertaal niet moeten maken binnen de vaccuum van 1 project, maar meer moeten kiezen voor de lange termijn. Vervolgens (op basis van ervaring, inzicht etc) geef je zelf invulling aan de kracht van de gebruikte technieken.

[alienfruit]

Vind jij templates, template specialization en operator overloading niet onder features vallen die een taal krachtiger maken dan?

In principe is C++ ook minder krachtig gezien zijn onefficientie en gewoon waardeloze foutmeldingen, en de traagheid van compileren. Op die manier kun je niet "krachtig" genoeg aan het werk gaan, en om nou te zeggen dat C++ krachtiger is dan Delphi allene omdat het geen ondersteuning heeft voor template specialization gaat mij toch wat te ver. Delphi ondersteunt generics (wat zelfs C# nog niet eens ondersteund) en Operator overloading.

[whoami]

Eh, wrong.
generics worden in C# 2.0 (waarvan de beta uit is) ondersteund.

[alienfruit]

Aah, nou is het ongeveer vergelijkbaar inmiddels

[Voutloos]

Ik geloof wel dat kracht een combinatie van de genoemde factoren is. Hoe zwaar je de factoren moet wegen hangt van het probleem af dat je moet oplossen en omgevingseisen.

Voor AI gerelateerde problemen bieden functionele en logische talen vaak een uitkomst bijvoorbeeld. Maar een van de bekendere logische talen, Prolog, zou ik niet willen gebruiken voor voorspelbare, vaste berekeningen als een boekhoudprogramma.

En dus zal je al gauw een keuze maken uit een programmeerparadigma die je probleem efficient oplost:
(kort door de bocht ):
Imperative (oa ASM, C, Ada)voor een klein, overzichtelijk probleem, volgens een volledige vastgelegde flow of control.
OO talen(oa C++) voor omvangrijkere programma's,voor toekomstig hergebruik en als de nadruk op de datastructuren moet liggen.
Functionele talen (oa Lisp, Miranda) als je een probleem op een abstracte manier wil oplossen, zonder druk te maken over hardware/geheugenbeheer, zodat je je puur op het probleem kan richten.
Logische talen (oa Prolog) gaan een stukje verder en leggen de nadruk op de declaratieve betekenis.
En dan heb je wat talen die een combi van deze ideeën zijn, omgevingen die met een combinatie werken en gedistribueerde en parallele talen.

Bij de 1e 4 groepen die ik noem, neemt de expressiekracht en mogelijkheden tot abstractie toe als je de lijst afgaat, maar gaat dit ten koste van de prestaties.
Goede Assemblercode is het efficienst van de imperative groep, maar je wordt gillend gek als je een groot project erin moet maken of een logisch probleem moet oplossen.

Als je binnen het voor je probleem geschikte paradigma kijkt, vind je nog steeds een waslijst aan talen. Genoeg talen zijn al vervangen obsolete, wegens duidelijk betere vervangers. Dan pas kom je op een keuzelijst van 2/3 talen uit en heb je het over de nifty features die 1 van die talen wel heeft en de ander niet.

Dit is basiskennis, mar wel onderbelicht in dit topic. Misschien komt dat ook wel omdat bijna iedereen alleen maar aan imperative en OO denkt en niet aan functionele en logische talen.

[Harribo]

Ik heb geprogrammeerd in C,Delphi,asm en nog veel andere talen waaronder
logische en functionele talen.
Nu programmeer ik in Clarion, een 4GL taal.
Ik denk dat C toch het meeste kan. Daar kun je programmeertechnisch denk ik het meeste mee. Het leent zich heel goed om binnen 1 commando veel dingen te doen en daarnaast heb je ook de mogelijkheid om het zo leesbaar te maken als je zelf wilt mbv van oa mogelijkheden om procedures te creeeren.
Logische en functionele talen zijn prima leesbaar vaak, maar het probleem is dat ze vaak zeer beperkt zijn als je net even wat meer wil met een taal, zoals een Gui of variabelen doorgeven aan een procedure.
Kortom, als je mij vraagt : Kies C (++).

[ Voor 23% gewijzigd door Harribo op 08-07-2004 10:19 ]

[PommeFritz]

Harribo schreef op 08 juli 2004 @ 10:18:Het leent zich heel goed om binnen 1 commando veel dingen te doen

tegenstrijdig met het volgende:

en daarnaast heb je ook de mogelijkheid om het zo leesbaar te maken als je zelf wilt mbv van oa mogelijkheden om procedures te creeeren.

procedures zijn zooooo 1965

[Alarmnummer]

Voutloos schreef op 08 juli 2004 @ 10:13:
Ik geloof wel dat kracht een combinatie van de genoemde factoren is. Hoe zwaar je de factoren moet wegen hangt van het probleem af dat je moet oplossen en omgevingseisen.

Voor AI gerelateerde problemen bieden functionele en logische talen vaak een uitkomst bijvoorbeeld. Maar een van de bekendere logische talen, Prolog, zou ik niet willen gebruiken voor voorspelbare, vaste berekeningen als een boekhoudprogramma.

Ik denk dat de toekomst van talen zit in een naadloze integratie tussen talen uit verschillende paradigma`s. Sommige problemen laten zich nu eenmaal beter oplossen in bv een declaratieve taal, maar om daar een hele applicatie mee op te gaan zetten. Kies daarom de juiste tool (taal) voor de job en dan maar hopen dat je het kan integreren.

Gelukkig zie je dit trouwens wel steeds meer gebeuren met .NET en met Java. Daar worden ook allerlei talen voor uitgebracht die wegcompileren naar een overeenkomstige intermediate representation (bytecode).

[ Voor 13% gewijzigd door Alarmnummer op 08-07-2004 10:23 ]

[whoami]

Harribo schreef op 08 juli 2004 @ 10:18:

Ik denk dat C toch het meeste kan. Daar kun je programmeertechnisch denk ik het meeste mee. Het leent zich heel goed om binnen 1 commando veel dingen te doen en daarnaast heb je ook de mogelijkheid om het zo leesbaar te maken als je zelf wilt mbv van oa mogelijkheden om procedures te creeeren.
Logische en functionele talen zijn prima leesbaar vaak, maar het probleem is dat ze vaak zeer beperkt zijn als je net even wat meer wil met een taal, zoals een Gui of variabelen doorgeven aan een procedure.
Kortom, als je mij vraagt : Kies C (++).

Mja, dat vind ik wel een boude uitspraak.
Ten eerste is C != C++. C++ is OO, C is dat niet.

Daarnaast is het ook niet slim om te stellen dat je in taal X het meest kan. Je moet namelijk kiezen voor 'the right tool, for the right job'.
Zoals Voutloos al opmerkte zijn imperatieve talen niet geschikt voor bepaalde problemen.

Daarnaast kan je in C wel veel, maar als je een OO systeem gaat opzetten, dan valt C zowiezo al af.

[P_de_B]

Er zitten duidelijke verschillen in definitie van "kracht van een programmeertaal". Ik denk dat een programmeertaal krachtig is als je eenvoudig/goed het beoogde programma ermee kunt maken. Afhankelijk van de wensen en omstandigheden kan soms de ene soms de andere programmeertaal krachtiger zijn.

Als ik een heel eenvoudig GUI georienteerd programmaatje moet maken zou VB6 krachtiger kunnen zijn om die specifieke taak te volbrengen dan C. Puur omdat executiesnelheid in dit geval er niet toe doet, maar snelheid van programmeren veel belangrijker is. Je kunt dus in mijn optiek moeilijk de mate van krachtigheid van een programmeertaal beoordelen zonder het uiteindelijke ontwikkeltraject/programma mee te nemen in de overweging.

[Alarmnummer]

Trouwens.. een taal zijn 'feature' kan bij een situatie een voordeel zijn en bij een andere een precies zo groot nadeel. Als je kijkt naar bv getypeerde talen, dan kan je daar vaak niet even lekker in prototypen. Je moet veel gewicht meeslepen (de types) en dat kan je belemmeren om snel alles even op zijn kop te gooien. Aan de andere kant, voor veel serieuze toepassingen zou ik het niet aandurven om in een ongetypeerde taal te werken, of zelfs in een 'ongecompileerde' taal (dus een taal waar je pas runtime foutmeldingen krijgt).

Het is dus afhankelijk van de situatie wat de juiste taal gaat worden. En zo lang een taal turing compleet is, is hij net zo krachtig als iedere andere turing complete taal. Hoe veel of weinig taalfeatures er ook zijn.

[Voutloos]

Alarmnummer schreef op 08 juli 2004 @ 10:21:
[...]

Ik denk dat de toekomst van talen zit in een naadloze integratie tussen talen uit verschillende paradigma`s. Sommige problemen laten zich nu eenmaal beter oplossen in bv een declaratieve taal, maar om daar een hele applicatie mee op te gaan zetten. Kies daarom de juiste tool (taal) voor de job en dan maar hopen dat je het kan integreren.

Gelukkig zie je dit trouwens wel steeds meer gebeuren met .NET en met Java. Daar worden ook allerlei talen voor uitgebracht die wegcompileren naar een overeenkomstige intermediate representation (bytecode).

Juist. Ik deed de uitleg adhv van die 4 paradigma's, maar steeds meer nieuwe talen/omgevingen zullen een combi zijn daarvan. Natuurlijk zijn bepaalde eigenschappen van die paradigma's niet zomaar te verenigen in 1 taal en dan gaat jouw 1e alinea voorlopig prima op.

Alarmnummer schreef op 08 juli 2004 @ 10:34:
Als je kijkt naar bv getypeerde talen, dan kan je daar vaak niet even lekker in prototypen. Je moet veel gewicht meeslepen (de types) en dat kan je belemmeren om snel alles even op zijn kop te gooien. Aan de andere kant, voor veel serieuze toepassingen zou ik het niet aandurven om in een ongetypeerde taal te werken, of zelfs in een 'ongecompileerde' taal (dus een taal waar je pas runtime foutmeldingen krijgt).

Ik heb een periode veel Java gedaan met practica. Voor sites heb ik me nooit echt in PHP verdiept, dat ben ik de laatste tijd wel aan het doen, maar ik stoor me nog steeds aan de luiheid van het niet definiëren van types. Doe mij maar alles via strenge regels. Daarentegen heb ik ook in Prolog wat geknutseld en dan stoorde ik me hier helemaal niet aan, ook omdat de nadruk er helemaal niet opligt (je loopt toch alleen maar met een paar lijsten te klooien soms).

[ Voor 37% gewijzigd door Voutloos op 08-07-2004 10:47 ]

[sjink]

Je kunt 'krachtig' ook omschrijven als de mate van ervaring een programmeur nodig heeft om bepaalde doelen te bereiken in een programmeertaal.

Als ik als beginnend programmeur met geringe ervaring meteen al complexe dingen kan uitvoeren in een programmeertaal, door bv. de beschikbaarheid van componenten, simpele syntax, etc. dan kan ik deze programmeertaal na mijn mening als "krachtig" beschouwen.

[Alarmnummer]

Voutloos schreef op 08 juli 2004 @ 10:39:
[...]
Juist. Ik deed de uitleg adhv van die 4 paradigma's, maar steeds meer nieuwe talen/omgevingen zullen een combi zijn daarvan. Natuurlijk zijn bepaalde eigenschappen van die paradigma's niet zomaar te verenigen in 1 taal en dan gaat jouw 1e alinea voorlopig prima op.

In c# en java (java 5) is het ook mogelijk om metadata toe te voegen:
(zelfverzonnen syntax)

code:

[table=PERSOON]
class Persoon{
     [column=VNAAM]
      String _voornaam;

     [column=ANAAM]
     String _achternaam;
}

Je hebt nu je normale classes waar je op een oo manier mee bezig bent, maar door die metadata heb je nu ook declaratieve elementen in java. Tenslotte beschrijf je wat je opgelost wilt hebben (de mapping), maar niet hoe deze mapping tot stand moet komen.

Dus ook binnen 1 taal zie je allerlei paradigma`s verenigd worden. Persoonlijk denk ik trouwens dat metadata 'de' feature gaat worden van java 5.

[Voutloos]

sjink schreef op 08 juli 2004 @ 10:46:
Je kunt 'krachtig' ook omschrijven als de mate van ervaring een programmeur nodig heeft om bepaalde doelen te bereiken in een programmeertaal.

Als ik als beginnend programmeur met geringe ervaring meteen al complexe dingen kan uitvoeren in een programmeertaal, door bv. de beschikbaarheid van componenten, simpele syntax, etc. dan kan ik deze programmeertaal na mijn mening als "krachtig" beschouwen.

Iets uit verband gerukt, maar noem jij een "pleur en sleur"ontwikkelomgeving dan ook krachtig? Want dat is deze zeker niet voor een ervaren programmeur, die wil gewoon die-hard code zien.

@alarm#: metadata in java heb ik me nog niet in verdiept eerlijk gezegd, maar ga dat zeker binnenkort doen.

[ Voor 14% gewijzigd door Voutloos op 08-07-2004 10:50 ]

[Alarmnummer]

Voutloos schreef op 08 juli 2004 @ 10:48:
[...]
@alarm#: metadata in java heb ik me nog niet in verdiept eerlijk gezegd, maar ga dat zeker binnenkort doen.

Dan moet je ook zeker even kijken naar Aspect Oriented Programming (AOP)
http://www.javaworld.com/...-07-2004/jw-0705-aop.html
Dan begrijp je waarom je soms kut code krijgt en dat onmogelijk goed op kan lossen binnen de beperkingen van normaal oo (zelfs niet met de mooiste patterns)

AOP is imho het vervolg op OOP. Het is de volgende stap. Ipv dat een methode je laagste verdelings eenheid is, kan je nog een stap verder gaan.

AOP = trouwens metaprogramming, voor de liefhebbers.

[ Voor 21% gewijzigd door Alarmnummer op 08-07-2004 10:56 ]

[sjink]

Voutloos schreef op 08 juli 2004 @ 10:48:
[...]

Iets uit verband gerukt, maar noem jij een "pleur en sleur"ontwikkelomgeving dan ook krachtig? Want dat is deze zeker niet voor een ervaren programmeur, die wil gewoon die-hard code zien.

...

Yep, onder het mom van het doel heiligt de middelen
Mja het is in principe gewoon een andere kijk op deze discussie en ik denk dat dit argument in het bedrijfsleven sterker telt dan alle andere argumenten die hier voorbij zijn gekomen

[Verwijderd]

modbreak: crossposten doen we hier niet aan, en al helemaal niet als je opmerking in het betreffende topic compleet offtopic is

[ Voor 88% gewijzigd door curry684 op 08-07-2004 11:37 ]

[JeromeB]

party42 schreef op 08 juli 2004 @ 09:26:
[...]


Dus aan de ene kant bestudeer je aan taal kort, maar toch is tijd niet belangrijk. Persoonlijk denk ik dat je door een korte verkenning in een programmeertaal niet de daadwerkelijke kracht ervan kan ontdekken, wellicht behalve of de IDE je aanspreekt. Als je kijkt naar de strictheid van Delphi (Object Pascal) dan verwacht ik (volgens jou redenatie) dat je deze taal snel links zal laten liggen.

Volgensmij snap je mij niet helemaal. Als ik een taal kort bestudeer dan doe ik dat om te kijken of het mij interesseert en als het me interesseert dan bestudeer ik het uitgebreider. In een korte tijd kun je natuurlijk niet de daadwerkelijke kracht van een programmeertaal ontdekken, maar je kunt wel kijken of het interessant is om er mee verder te gaan.

Verder is tijd wel degelijk belangrijk. Het is immers een prioriteit, maar van al die prioriteiten komt het onderaan mijn lijstje.

party42 schreef op 08 juli 2004 @ 09:26
Volgens mij zou je de keuze voor een programmeertaal niet moeten maken binnen de vaccuum van 1 project, maar meer moeten kiezen voor de lange termijn. Vervolgens (op basis van ervaring, inzicht etc) geef je zelf invulling aan de kracht van de gebruikte technieken.

Als je goed leest is dat ook een prioriteit. Welke kennis heb ik reeds en welke kennis zou ik eventueel moeten verkrijgen.

[ Voor 2% gewijzigd door JeromeB op 08-07-2004 11:53 . Reden: verkeerd afgesloten stukje bbcode ]

[Bobco]

Iets wat ik een beetje mis in de thread is de afweging van welke libraries/frameworks er beschikbaar zijn om native te kunnen gebruiken. Uiteraard kan de discussie over details als het al dan niet verplicht afhandelen van exceptions best interessant zijn, maar als er 'echte' applicaties geschreven moeten worden is het bijzonder handig als je kunt putten uit een rijk arsenaal van goed bruikbare libraries.

Zelf doe ik op dit moment alleen maar Java en ik sta nog steeds verbaasd over de enorme hoeveelheid aan libraries, frameworks, complete applicatie servers en andere fijne dingen die gewoon inclusief source beschikbaar zijn. Als ik ooit nog eens een andere taal zou willen gaan gebruiken zou het voor mij een belangrijk punt van overweging zijn of die taal wel dezelfde soorten van libraries biedt.

[LordLarry]

Delphi biedt de VCL en heeft een enorme grote userbase met mensen die al dan niet gratis hun classes en componenten aanbieden. Kijk bijvoorbeeld maar eens op www.torry.ru

.Net is nog vrij nieuw, maar je ziet al dat ook daar veel leveranciers en mensen hun bijdrage aan leveren.

VB had vroeger ActiveX componenten, maar daar was ik nooit zo erg gecharmeerd van. C++ heeft natuurlijk ook veel code die beschikbaar gesteld is door 3en, maar omdat er nogal grote verschillen tussen de compilers en platformen kunnen zitten lijkt me de markt daar wat moeilijk.

/edit
Het mooie aan .Net is natuurlijk dat je het component/de class in de ene taal kan schrijven, maar gewoon gebruiken in de andere taal alsof er niets aan de hand is. Je kan van je class geschreven in Delphi 8 for .Net gewoon in C# een afgeleide maken.

[ Voor 20% gewijzigd door LordLarry op 08-07-2004 14:03 ]

[Verwijderd]

Voutloos schreef op 08 juli 2004 @ 10:48:
[...]

Iets uit verband gerukt, maar noem jij een "pleur en sleur"ontwikkelomgeving dan ook krachtig? Want dat is deze zeker niet voor een ervaren programmeur, die wil gewoon die-hard code zien.

Het hangt er natuurlijk een beetje vanaf. Zoals al eerder gezegd hier, The right tool for the right job. Je kunt drag & drop (grafisch) programmeren namelijk heel goed toepassen voor de creatie van een filter (dataflow network). In een lineaire vorm (pipeline) kan dit nog goed textueel, maar zodra je ingewikkeldere vormen krijgt (bv DAG, tree, free) wil je toch liever grafisch werken.

Het kan dan handig zijn als de serialisatie van je graaf dan een textueel formaat is (tegenwoordig bv vaak XML gebasseerd). Zie bv:

• JDAWN www.liacs.nl/~jdawn - DAG van executable elementen
• Compaan www.liacs.nl/~cserc/compaan/ - Process networks (embedded)
• Max/msp www.creativesynth.com/MAXMSP/maxmspmain.html - speciaal voor muziek

Let wel dat in het algemeen het dan niet gaat om turing complete talen, maar juist om een zeer specificiek domain.

[.oisyn]

alienfruit schreef op 08 juli 2004 @ 09:44:
[...]


In principe is C++ ook minder krachtig gezien zijn onefficientie

en gewoon waardeloze foutmeldingen

Of sloeg dat onefficient ook op die foutmeldingen (hoe definieer je de efficientie van een foutmelding dan)?
Ten eerste hangt dat geheel van de compiler af. Het is echt onzin om te zeggen dat C++ waardeloze foutmeldingen geeft, C++ is een taal en heeft an sich geen foutmeldingen. De foutmeldingen van Comeau zijn bijvoorbeeld heel erg duidelijk. Goed, bij ingewikkelde templates kan het soms lastig zijn om te zien wat er nou precies fout gaat, maar dat vereist simpelweg ervaring. Templates zelf vereisen ook ervaring, dus dat is niet eens zo'n probleem

en de traagheid van compileren.

Niet zozeer de traagheid, maar het hele compilatieproces is idd een groot nadeel van C++ dat ik graag veranderd zie. Door de geisoleerde translation units moet je gebruik maken van headers waar definities in staan die in andere translation units geimplementeerd worden. Alles wordt gecompileerd naar individuele objecten, en aan het eind wordt alles bij elkaar gestopt. Aan de andere kant vind ik werken op classniveau zoals C# en Java dat doen ook niet echt heel erg fijn. Bij grote classes krijg je source files van duizenden regels lang, terwijl je het eigenlijk op zou willen delen om het overzichtelijker te houden. Daarnaast vind ik class definities zonder implementatie verder ook wel fijn voor documentatie, iets wat overigens ook vanuit de .Net en Java wereld beaamd wordt. Maar het compileermodel van C++ is idd gewoon een ramp, en zorgt voor veel vertraging.

Overigens is dit niet alleen de oorzaak van de vertraging, achter veel C++ compilers zit een dikke optimizer waardoor veel efficientere code geproduceerd wordt. Daarom is C++.Net code meestal ook sneller dan C# (dit zijn Herb Sutter's woorden, dus niet van een een of andere vage benchmark), omdat de geproduceerde IL gewoon veel beter is door de aanwezige optimizer.

en om nou te zeggen dat C++ krachtiger is dan Delphi allene omdat het geen ondersteuning heeft voor template specialization gaat mij toch wat te ver. Delphi ondersteunt generics (wat zelfs C# nog niet eens ondersteund) en Operator overloading.

Ten eerste, generics != templates, dat zijn echt compleet verschillende dingen. C++ krijgt in whidbey overigens ook generics. En operator overloading, praat je dan ook over vrijwel alle operatoren, zoals conversion operators en de operators die op pointers werken? Met andere woorden, kun je een custom type definieren die zich gedraagd als pointer of reference?

C++ templates en operator overloading stellen mij bijvoorbeeld in staat zoiets te doen:

C++:

functor f = std::cout << _1 << std::endl;

f (123);
f ("woei");
f (mijneigentype ());

f is nu gewoon een "functie" die 1 parameter accepteert, en daarin de statement std::cout << _1 << std::endl uitvoert, waarbij _1 die ene parameter is.

Nou is dit an sich misschien een beetje een nutteloos voorbeeld, maar met STL algoritms kan het enorm handig zijn omdat je dan geen hele aparte classes hoeft te definieren voor een enkele operatie.

Je kunt een vector van int pointers bijvoorbeeld sorteren op de waarde waar elke pointer naar wijst:

C++:

std::vector<int *> v;
// .. vul v hier ..
std::sort (v.begin (), v.end (), *_1 < *_2);

In een andere programmeertaal zou je een Comparator oid moeten implementeren die de pointers dereferenced en vervolgens vergelijkt (al dan niet op de huidige regel met de anonymous class syntax).

En heeft Delphi deterministic finalization, dus een destructor call zodra een variabele op de stack buiten scope gaat? Hier is erg mooie en bovendien exception-safe code mee te schrijven, wat ook de reden is dat het in C# (en dus .Net 2) gaat komen. Nu heb je natuurlijk wel finalizers, maar je kunt je resources niet vrijgeven in finalizers omdat je niet weet wanneer hij aangeroepen gaat worden, en of hij überhaupt wel aageroepen zal worden.

Ik wil er geen pro-C++, anti-Delphi post van maken, Delphi is zeker een goede taal, ik beargumenteer alleen even waarom in mijn ogen C++ veel krachtiger is dan Delphi

[whoami]

.oisyn schreef op 08 juli 2004 @ 14:28:
[...]


Aan de andere kant vind ik werken op classniveau zoals C# en Java dat doen ook niet echt heel erg fijn. Bij grote classes krijg je source files van duizenden regels lang, terwijl je het eigenlijk op zou willen delen om het overzichtelijker te houden.

partial classes.
Worden in .NET 2.0 geintroduceerd.

Daarnaast vind ik class definities zonder implementatie verder ook wel fijn voor documentatie, iets wat overigens ook vanuit de .Net en Java wereld beaamd wordt.

Idd, dat is iets wat ik wel mis in .NET. (heb er jaren geleden zelfs een topic over geopend.).

Daarom is C++.Net code meestal ook sneller dan C# (dit zijn Herb Sutter's woorden, dus niet van een een of andere vage benchmark), omdat de geproduceerde IL gewoon veel beter is door de aanwezige optimizer.

Hoezo?
Gaat die IL die van VB.NET / C# / C++.NET afkomstig is dan niet gewoon door dezelfde optimizer, IL -> native compiler?

Ten eerste, generics != templates, dat zijn echt compleet verschillende dingen.

Wat is het precieze verschil dan?
Voor zover ik weet wordt er in C++ voor iedere template class een class 'gebouwd' voor ieder gebruikt type. In .NET / generics is dit niet zo.

En heeft Delphi deterministic finalization, dus een destructor call zodra een variabele op de stack buiten scope gaat?

Ik vermoed van wel.

[Alarmnummer]

.oisyn schreef op 08 juli 2004 @ 14:28:
Aan de andere kant vind ik werken op classniveau zoals C# en Java dat doen ook niet echt heel erg fijn. Bij grote classes krijg je source files van duizenden regels lang, terwijl je het eigenlijk op zou willen delen om het overzichtelijker te houden.

meer dan 500 regels -> it smells funny
meer dan 1000 regels -> it stinks
meer dan 2000 regels -> de kans is groot dat er iets mis is met je ontwerp.

Daarnaast vind ik class definities zonder implementatie verder ook wel fijn voor documentatie, iets wat overigens ook vanuit de .Net en Java wereld beaamd wordt.

Ik misbruik daar wel eens een interface voor. Maar in dat opzicht had ik liever een header file gezien zoals in c++ waarin de definities staan + documentatie. En een implementatie file.

Daarom is C++.Net code meestal ook sneller dan C# (dit zijn Herb Sutter's woorden, dus niet van een een of andere vage benchmark), omdat de geproduceerde IL gewoon veel beter is door de aanwezige optimizer.

Ik weet niet hoe het zit met c#. Maar in java optimaliseerd de javac compiler dus niet eens. De -O optie werkt al niet eens meer. Het hangt volledig af van de JIT (Just In Time compiler) welke optimalisaties worden uitgevoerd.

Ten eerste, generics != templates, dat zijn echt compleet verschillende dingen.

Ojee... toch niet weer de zoveelste generics/template discussie he

[Verwijderd]

Bobco schreef op 08 juli 2004 @ 13:26:
maar als er 'echte' applicaties geschreven moeten worden is het bijzonder handig als je kunt putten uit een rijk arsenaal van goed bruikbare libraries.

Dat is zeker waar. Veel van de mensen die zo enthousiast zijn over bv PHP roemen zaken die eigenlijk helemaal niet taal specificiek zijn, maar juist library specificiek.

In het algemeen zie je bv dat voor sommige zaken library facilities belangrijker worden dan vroeger. Bv, primitive arrays worden zowel in C++ als Java steeds minder gebruikt, en ik begreep dat het build-in object serialisatie mechanisme van Java ook zijn langste tijd heeft gehad.

Zelf doe ik op dit moment alleen maar Java en ik sta nog steeds verbaasd over de enorme hoeveelheid aan libraries, frameworks

Aan de ene kant is de standaard java library zeer compleet en bevat vooral veel high level dingen als GUI, netwerk, XML, enz. Daarbij vergeleken is de C++ library in de breedte gezien een heel stuk kariger. Aan de andere kant heb je voor bv grafische toolkits wel veel meer keus in C++: Motif, GTK, QT, Win32/MFC, etc. In Java heb je toch voornamelijk AWT/Swing, sinds relatief kort is er overigens wel een alternatief met SWT.

[Tomatoman]

.oisyn schreef op 08 juli 2004 @ 14:28:
En heeft Delphi deterministic finalization, dus een destructor call zodra een variabele op de stack buiten scope gaat?

In Delphi 8 (de .NET-versie): ja. In Delphi t/m versie 7: alleen voor interfaces.

[Verwijderd]

Alarmnummer schreef op 08 juli 2004 @ 14:44:

meer dan 500 regels -> it smells funny
meer dan 1000 regels -> it stinks
meer dan 2000 regels -> de kans is groot dat er iets mis is met je ontwerp.

Ik meen me te herinneren dat er in de code conventions die Sun voor java uitgeeft, een getal van 3000 regels wordt genoemt. 1 en ander hangt natuurlijk wel samen hoe je je code opschrijft. Bv, een serie van simpele getters/setters als 1 blok met telkens 1 getter/setter per regel, of elke getter/setter als normale functie opschrijven kwa layout; dus minimaal 5 regels (comment, signature, body, sluit haakje, lege regel).

Ojee... toch niet weer de zoveelste generics/template discussie he

Oh jee Maar heel in het kort voor de anderen die meelezen. In Java 1.5 heb je geen echte templates, maar wordt een truukje toegepast; de compiler voegt zelf de juiste casts in. De JVM weet dus niks van generics af.

Dit vangt voor de normale gebruiker 95% van het template gebruik af, maar juist de 'leukere' complexe dingen met templates (template meta programming etc) kunnen dan natuurlijk niet.

Hoe het in C# zit weet ik niet. Is het daar hetzelfde gedaan als in Java?

Ik denk dat de toekomst van talen zit in een naadloze integratie tussen talen uit verschillende paradigma`s.

Dat zie je opzich natuurlijk al wat langer. Een goed voorbeeld is mischien hoe veel Web Applicaties zijn opgebouwd

• Presentatie laag in (X)HTML met imperatieve code (JSP, PHP, ASP)
• Logica/controller laag in pure imperatieve code (Java, C++, C, eventueel C#)
• Toegang tot data laag via query taal (meestal SQL, eventueel een aangepast dialect hiervan)

[ Voor 18% gewijzigd door Verwijderd op 08-07-2004 15:04 ]

[Alarmnummer]

Verwijderd schreef op 08 juli 2004 @ 14:57:
Hoe het in C# zit weet ik niet. Is het daar hetzelfde gedaan als in Java?

c# genereerd echt code voor geparametriseerde classes. Een gedeelte wordt compiletime al gedaan, een gedeelte runtime:

code:

void foo(List<E> e){
      List<List<E>> eList = new List<List<E>>();
       eList.add(e);
       foo(eList);
}

Een voorbeeld van polymorfe recursie. De c++ compiler gaat op zijn bek omdat compiletime onmogelijk alle instanties van die list parametrisaties aangemaakt kunnen worden. Java gaat neit op zijn bek omdat de vm geen generics kent (de typeparameters worden trouwens wel bijgehouden in een attribuut in de bytecode. Daarom kan je class file ook weer bekijken en zien hoe ze geparametriseerd moeten worden).

voorbeeld dat java niet aankan:

code:

class Foo<A,B>{
      void foo(A a){....}
      void foo(B b){....}
}

Runtime kan je geen onderscheid maken tussen de 2 methodes (ze zijn beide van het type foo(Object item)

De c# doet het eigelijk als enigste goed. Hij gaat runtime code compileren (en cachen) en dat toepassen.

[ Voor 17% gewijzigd door Alarmnummer op 08-07-2004 15:28 ]

[Eelis]

.

[ Voor 103% gewijzigd door Eelis op 18-02-2015 19:23 ]

[alienfruit]

Nou, ik wil nou niet zeggen dat ik Anti C++ ben ofzo gebruik het zelf ook voor Symbian applicaties, maar ik wordt gewoon niet vrolijk van sommige foutmeldingen waar zelfs de regelnummers die MSVC++ meegeeft niet kloppen (kom op zeg, beetje compiler kan fatsoenlijke symbol info verzamelen) maar ik vind zelf dus echt sommige foutmeldingen in de MSVC++ compiler nou niet echt denderend.

Het kan misschien komen omdat ik niet zo vaak in C++ programmeer (alleen als ik aan me grafische app werk) dat ik sommige foutmeldingen "wazig" vindt, of niet door heb dat als de compiler zegt regel X dat het eigenlijk regel X - 15 bedoel.

[Verwijderd]

.oisyn schreef op 08 juli 2004 @ 14:28:
Niet zozeer de traagheid, maar het hele compilatieproces is idd een groot nadeel van C++ dat ik graag veranderd zie. Door de geisoleerde translation units moet je gebruik maken van headers waar definities in staan die in andere translation units geimplementeerd worden.

Wat is daar nu precies het nadeel van? Theoretisch zouden objects in dit model alleen gehercompileerd moeten worden indien dit daadwerkelijk nodig is; daarnaast ligt de beslissing om al dan niet te hercompileren bij de programmeur (of zijn make tool), niet bij de compiler. Als je in grote projecten extreem lange compileertijden krijgt duidt dit meestal op een slecht georganiseerd design-proces, het betekent dat definities die eigenlijk tijdens de ontwerpfase al hadden moeten worden vastgesteld nog tijdens de implementatiefase als variabel worden geacht.

Dit uit zich in headerfiles waar zowat elke file in het project dependencies op heeft; als je C++ werkelijk als OO-taal wilt gebruiken dan zouden headerfiles met classedefinities vrijwel nooit in dependencies moeten voorkomen (alleen de sourcefiles die die class implementeren zouden dependent moeten zijn) want als je een externe classedefinitie wijzigt breek je meteen het design-by-contract proces (en krijg je hoe dan ook trubbels met andere programmeurs van dat project).

[whoami]

Verwijderd schreef op 08 juli 2004 @ 19:48:
[...]


Wat is daar nu precies het nadeel van? Theoretisch zouden objects in dit model alleen gehercompileerd moeten worden indien dit daadwerkelijk nodig is; daarnaast ligt de beslissing om al dan niet te hercompileren bij de programmeur (of zijn make tool), niet bij de compiler. Als je in grote projecten extreem lange compileertijden krijgt duidt dit meestal op een slecht georganiseerd design-proces, het betekent dat definities die eigenlijk tijdens de ontwerpfase al hadden moeten worden vastgesteld nog tijdens de implementatiefase als variabel worden geacht.

Een compiler kan toch wel nagaan tijdens het build proces of bepaalde files nu wel of niet hoeven gehercompileerd te worden.

[Verwijderd]

alienfruit schreef op 08 juli 2004 @ 19:32:
Nou, ik wil nou niet zeggen dat ik Anti C++ ben ofzo gebruik het zelf ook voor Symbian applicaties, maar ik wordt gewoon niet vrolijk van sommige foutmeldingen waar zelfs de regelnummers die MSVC++ meegeeft niet kloppen (kom op zeg, beetje compiler kan fatsoenlijke symbol info verzamelen) maar ik vind zelf dus echt sommige foutmeldingen in de MSVC++ compiler nou niet echt denderend.

Hoewel soms anders gedacht wordt, maakt de taal zeer zeker uit hoe precies foutmeldingen kunnen zijn. Dit houdt oa verband met de syntax en context van sommige constructies. Bv, de spaced- en contextual keyword in de CLI C++ binding maken het moeilijker om precieze foutmeldingen te geven. Het punt is dat een bepaalde syntax ondubbelzinnig kan zien als ie goed is, maar op meedere manieren opgevat kan worden bij fouten. In zo'n situatie kan een compiler met de beste wil van de wereld niet altijd een exacte foutmelding geven.

[Verwijderd]

whoami schreef op 08 juli 2004 @ 19:51:
Een compiler kan toch wel nagaan tijdens het build proces of bepaalde files nu wel of niet hoeven gehercompileerd te worden.

Nee, dat kan die niet, je zou een (oneindig) groot aantal heuristieken in de compiler moeten inbouwen om vast te stellen of definities constant zijn of tijdens het project kunnen wijzigen en of het dus zin heeft dependencies op die definities te declareren of niet.

Voorbeeldje:

C++:

#ifndef DEFPORTS_HH
#define DEFPORTS_HH

#include <netinet/in.h>
#include "cport.hh"

const Cport FTPPORT (IPPORT_FTP);
const Cport MAILPORT (IPPORT_SMTP);
const Cport WEBPORT (80);

#endif /* DEFPORTS_HH */

Kan/moet de compiler weten of port 80 de standard webport is, hoewel die niet in netinet/in.h gedefinieerd is? Zo nee, dan worden een hoop files in ons project nodeloos dependent op deze header. Zouden er implementatiedetails (zoals private inlines) in staan die verder niets met het interface te maken hebben, dan werd er waarschijnlijk heel wat nodeloos gehercompileerd bij het wijzigen van zo'n (intern) implementatiedetail.

[ Voor 4% gewijzigd door Verwijderd op 08-07-2004 20:24 ]

[whoami]

Wat is een incremental compiler dan?

Je moet eens een project compilen in bv. Delphi. Als je bepaalde files niet gewijzigd hebt sinds de laatste compilatie (en dat kan ie zien ja, aan de last modified date), dan gaat ie die niet mee compilen.

[Verwijderd]

whoami schreef op 08 juli 2004 @ 20:36:
Wat is een incremental compiler dan?

Je moet eens een project compilen in bv. Delphi. Als je bepaalde files niet gewijzigd hebt sinds de laatste compilatie (en dat kan ie zien ja, aan de last modified date), dan gaat ie die niet mee compilen.

Dat is het standaard-gedrag van make maar dat brengt het niet, bij grotere (meer-mans) projecten wil je niet dat zowat elke sourcefile in je project opnieuw gecompileerd moet worden indien een van de toolset-builders een intern implementatiedetail van b.v. class String of class InetConnection verandert. Als het programmeerproces is voorafgegaan door een goed ontwerpproces, dan liggen de public interfaces van de diverse classes al vast voor het programmeren begint en hoeven de diverse andere classes die gebruik maken van zo'n interface geen dependency op de definitie van dat interface te hebben, want dat interface zal niet wijzigen (tenzij er inlined methods in dat publieke interface zitten uiteraard).

[Verwijderd]

Heel kort gezegd: talen waarin zoveel mogelijk een first-class citizen is. Lazy evaluation helpt ook wel, vind ik.

[Verwijderd]

Verwijderd schreef op 08 juli 2004 @ 22:34:
Heel kort gezegd: talen waarin zoveel mogelijk een first-class citizen is. Lazy evaluation helpt ook wel, vind ik.

En als zoveel mogelijk een first-class citizin is, is dan is de taal krachtig? Of juist flexibel?

De build-in arrays van zowel C, C++, Java alsmede vele andere talen zijn dat iniedergeval niet.

Ik heb bv in mijn eigen taal ontwerp (eigenlijk de taal waar ik aan mee hielp) er juist voor gestreeft om een minimale set van language features te maken, en zoveel mogelijk door de library te laten doen (zelfs de equivalenten van assignments, en functie-calls zijn library functies in die eigen taal).

Aan de andere kant, is talen zoals C++ en Java zijn andere zaken bv wel weer goed als first class citizen, bv enums. Die zaten vroeger niet in Java (in de officiele release nog steeds niet). Dan moest je heel onhandig rijen van ints gaan zitten aanmaken; onhandig en niet eens type-safe!

[ Voor 44% gewijzigd door Verwijderd op 08-07-2004 22:52 ]

[Alarmnummer]

Verwijderd schreef op 08 juli 2004 @ 22:43:
...

Het ligt er ook een een beetje aan wat je met zo`n taal van plan bent. Als je bv kijkt naar Prolog dan is het meeste daarin een term. Zelf rules en facts zijn weer termen. Dit heeft als voordeel dat je een programma kan beschouwen als data en daarop transformaties kan laten plaatsvinden: metaprogramming. ( Met Lisp kan het trouwens ook maar daar heb ik geen praktische ervaring mee).

Meta programming is voor Prolog een onmisbaar onderdeel bij sommige toepassingen, maar ik kan me goed voorstellen dat voor andere talen dit soort features totaal overbodig zijn.

[Apollo_Futurae]

Alarmnummer schreef op 08 juli 2004 @ 10:34:
Als je kijkt naar bv getypeerde talen, dan kan je daar vaak niet even lekker in prototypen. Je moet veel gewicht meeslepen (de types) en dat kan je belemmeren om snel alles even op zijn kop te gooien.

Ik vind prototypen in een getypeerde taal juist heerlijk. Je defineert eerst de objecten waar het in je programma om draait, door types te declareren (als het even kan abstract, dus nog zonder concrete realisatie). Daarna geef je van de belangrijkste functies het type, om uit te drukken hoe de objecten onderling gekoppeld worden.
Juist in die fase heb ik - bij gebrek aan invulling van veel details - veel houvast aan het raamwerk dat de types vormen.

Het is dus afhankelijk van de situatie wat de juiste taal gaat worden. En zo lang een taal turing compleet is, is hij net zo krachtig als iedere andere turing complete taal. Hoe veel of weinig taalfeatures er ook zijn.

Deze opmerking is al vaak gemaakt, maar niemand lijkt er zich verder iets van aan te trekken.
Misschien moeten we een paar concrete situaties formuleren om dan per situatie de krachtigste (beste?) taal aan te wijzen?

[Alarmnummer]

Apollo_Futurae schreef op 09 juli 2004 @ 01:59:
Ik vind prototypen in een getypeerde taal juist heerlijk. Je defineert eerst de objecten waar het in je programma om draait, door types te declareren (als het even kan abstract, dus nog zonder concrete realisatie). Daarna geef je van de belangrijkste functies het type, om uit te drukken hoe de objecten onderling gekoppeld worden.

Het ligt eraan in wat voor taal je bezig bent. Als ik met java bezig ben dan ga ik ook vaak prototypen door objecten aan te maken, te goochelen met de methodes en een beetje feeling ermee proberen te krijgen. Er kom dan meestal wel naar voren toe hoe je het precies moet aanpakken.

Als ik met Prolog bezig ga en ik moet een metainterpreter schrijven (een interpreter die prolog programma`s interpreteer) dan schrijf ik tov bv Java in een fractie van de regels code een prototype. Grammatica van het metaprogramma uitbreiden? no problem. Jij wilt de xor? No problem. En dan maak ik me niet druk om het feit dat je een xor moet 2 argumenten moet schrijven en dat iedere andere combi niet goed is.

[ Voor 18% gewijzigd door Alarmnummer op 09-07-2004 07:12 ]

[Voutloos]

:- op(600, xfy, xor).
En klaar ben je, maar dat is gewoon een feature van Prolog. Zeker wel handig, maar er zijn genoeg talen (aan de imperative kant van de schutting) die niet per se minder krachtig zijn omdat ze dit niet hebben.

[.oisyn]

Nog even reageren voordat ik met de noorderzon (nou ja, zon...) vertrek

whoami schreef op 08 juli 2004 @ 14:34:
partial classes.
Worden in .NET 2.0 geintroduceerd.

driewerf woei

Hoezo?
Gaat die IL die van VB.NET / C# / C++.NET afkomstig is dan niet gewoon door dezelfde optimizer, IL -> native compiler?

Het gaat om code -> IL, de geproduceerde IL van de C++ compiler is zelf al efficienter dan die van de C# compiler.

Wat is het precieze verschil dan?
Voor zover ik weet wordt er in C++ voor iedere template class een class 'gebouwd' voor ieder gebruikt type. In .NET / generics is dit niet zo.

Globaal gezegd zijn templates compile-time, en generics runtime. Een template parameter heeft geen minst geimplementeerde interface oid nodig, het vormt meer een textuele substitutie. Bij generics behandel je de template parameter gewoon als het type wat als minst geimplementeerd moet zijn.

tomatoman schreef op 08 juli 2004 @ 14:51:
[...]
In Delphi 8 (de .NET-versie): ja. In Delphi t/m versie 7: alleen voor interfaces.

Raar, ondersteuning voor deterministic finalization in .Net is er pas vanaf 2.0

Eelis schreef op 08 juli 2004 @ 17:58:
[...]

Puur uit interesse: maakt deze code gebruik van je eigen functor lib, of van een andere? (Ik dacht namelijk dat boost::lambda/boost::function dit zo niet konden.)

Ok ik speelde een beetje vals . Puur die functor is niet geimplementeerd in boost::lambda (waar de code op gebaseerd is) idd, maar het is natuurlijk wel mogelijk om zo'n soort object te maken. Zeg maar een soort boost::any waar je elk type in kan stoppen, en als je het aanroept als een functor dan wordt de call gewoon gedelegeerd naar het in de functor opgeslagen object.

[farlane]

Verwijderd schreef op 08 juli 2004 @ 21:00:
Als het programmeerproces is voorafgegaan door een goed ontwerpproces, dan liggen de public interfaces van de diverse classes al vast voor het programmeren begint en hoeven de diverse andere classes die gebruik maken van zo'n interface geen dependency op de definitie van dat interface te hebben, want dat interface zal niet wijzigen (tenzij er inlined methods in dat publieke interface zitten uiteraard).

Dit klinkt allemaal leuk en aardig, maar ik neem aan dat je ook weet dat dit in de praktijk erg moeilijk te bereiken is. Tijdens het proces van schrijven, komen er altijd nieuwe inzichten ( van de ontwerper/programmeur/klant ) die weer teruggevoerd worden naar het onwerp. Dat kun je gewoon niet voorkomen.

[Eelis]

.

[ Voor 105% gewijzigd door Eelis op 18-02-2015 19:23 ]

[Alarmnummer]

Voutloos schreef op 09 juli 2004 @ 08:58:
:- op(600, xfy, xor).
En klaar ben je, maar dat is gewoon een feature van Prolog. Zeker wel handig, maar er zijn genoeg talen (aan de imperative kant van de schutting) die niet per se minder krachtig zijn omdat ze dit niet hebben.

Daarmee definieer je alleen de operator maar niet de afhandeling, en dat gaat juist zo handig met Prolog. Je definieert snel even een set regels en je bent met een minimale inspanning voorzien van extra functionaliteit. Als ik dat in Java moet doen, dan zit ik ineens met een extra operatorclass, implementatie van methodes, registratie bij de parser etc.

[.oisyn]

Eelis schreef op 09 juli 2004 @ 09:31:
[...]

Die 'functor' lijkt vrij veel op boost::function, maar het verschil zit 'm in het feit dat boost::function geïnstantieerd moet worden met een signature template parameter (e.g. boost::function<int(std::string,float)>) en vervolgens ook alleen functors met een compatibele signature kan wrappen. Ik vermoed dat het niet mogelijk is om een function object wrapper te maken die signature-onafhankelijk is (zoals in jouw voorbeeld).

Bij het implementeren van het aanroep-mechanisme van zo'n wrapper kom je volgens mij namelijk niet onder een virtual call (of iets equivalents) uit, en virtual function templates bestaan nou eenmaal niet..

Je hebt gelijk, hier had ik idd even niet aan gedacht. Je hebt idd een virtual function of function pointer oid nodig, waardoor het niet werkt met een nog niet geinstantieerde template.

[Verwijderd]

Of een taal krachtig is hangt allemaal af van het doel. Ik kan me voorstellen dat men voor verschillende wetenschappelijke doeleinden asm gebruikt. Hoewel in veel gevallen C ook nog zal voldoen. Daarentegen voor het maken van GUI's gebruik ik het liefst java, en als ik iets maak waar geen GUI voor nodig is programmeer ik in C(++).

Een deel van de 'kracht' komt uit de performance die gehaald wordt wanneer het programma gerund wordt (en of de behaalde performance wel reeel is voor de toepassing van het programma), een ander deel is de snelheid waarmee een programmeur de opdracht kan realiseren.

Een taal heeft meestal (whitespace?!) een bepaald gebied waar het goed toepasbaar is, de taak is aan de programmeur om de juiste keuze te maken.

[Verwijderd]

Verwijderd schreef op 19 juli 2004 @ 17:39:
Of een taal krachtig is hangt allemaal af van het doel. Ik kan me voorstellen dat men voor verschillende wetenschappelijke doeleinden asm gebruikt.

Weet je dat zeker? Ik heb asm niet vaak gezien in de wetenschap, tenzij het om het gebied gaat wat zich expliciet richt op compilere optimalisaties. Voor de meeste andere wetenschappelijke gebieden is toch dikwijls de keus/ontwerp van het algoritme belangrijker. Het is daarbij essentieel dat erover geredeneerd kan worden kwa complexitiet en stabiliteit. Volgens mij wordt dan toch meestal naar C of C++ gekeken.

[eghie]

Verwijderd schreef op 20 juli 2004 @ 11:28:
[...]


Weet je dat zeker? Ik heb asm niet vaak gezien in de wetenschap, tenzij het om het gebied gaat wat zich expliciet richt op compilere optimalisaties. Voor de meeste andere wetenschappelijke gebieden is toch dikwijls de keus/ontwerp van het algoritme belangrijker. Het is daarbij essentieel dat erover geredeneerd kan worden kwa complexitiet en stabiliteit. Volgens mij wordt dan toch meestal naar C of C++ gekeken.

Voor de wetenschap is tijd van een groot belang (meestal), dus meestal word het wel geoptimaliseerd in asm. Waarschijnlijk worden de alogritmes enzo wel eerst getest in c/c++, omdat dat wat minder werk is en wat overzichtelijker dan asm, maar ik denk dat het uiteindelijk wel naar asm word omgezet en geoptimaliseerd.

[ritsjoena]

farlane schreef op 09 juli 2004 @ 09:07:
[...]
Dit klinkt allemaal leuk en aardig, maar ik neem aan dat je ook weet dat dit in de praktijk erg moeilijk te bereiken is. Tijdens het proces van schrijven, komen er altijd nieuwe inzichten ( van de ontwerper/programmeur/klant ) die weer teruggevoerd worden naar het onwerp. Dat kun je gewoon niet voorkomen.

Tuurlijk is het niet te vermijden. Tijdens het schrijven leer je het probleem steeds beter kennen. Veel kun je echter van te voren aan zien komen en voorkomen door goed voor te bereiden alvorens te gaan schrijven. Ervaring is hierbij van onschatbare waarde.

Verder kun je ook eerst een prototype maken om de mogelijkheden van het probleem te onderzoeken.

En soms moet je met de gemaakte keuzes en hun consequenties leren leven en of gewoon doorgaan of opnieuw beginnen. (en de opgedane ervaring gebruiken in een volgend project)

[ritsjoena]

eghie schreef op 20 juli 2004 @ 11:52:
[...]

Voor de wetenschap is tijd van een groot belang (meestal), dus meestal word het wel geoptimaliseerd in asm. Waarschijnlijk worden de alogritmes enzo wel eerst getest in c/c++, omdat dat wat minder werk is en wat overzichtelijker dan asm, maar ik denk dat het uiteindelijk wel naar asm word omgezet en geoptimaliseerd.

Een goede compiler (optimizer) doet wonderen. Het is maar een kleine groep die asm nog kent en als je C gebruikt kan een goede compiler beter optimaliseren (voor jouw hardware) dan veel asm programmeurs (in de wetenschap(algemeen)) kunnen. Want hardware kennis op het benodigde niveau is ook niet iets dat ze allemaal hebben.

Verder is mijn ervaring dat er nogal wat wetenschappers zijn die je kan helpen de performance van hun programma op te schroeven door ze te leren dat compilers voorzien zijn van een optimizer.

[TheGhostInc]

Het grappige van deze discussie is het grote aantal variabelen dat in enkele post wordt gebruikt. Elk uitgangspunt mist vaak raakvlak met andere punten, de zaken die ik langs heb zien komen:
De programmeur (wat kan hij, en wat zijn zijn ervaringen)
De taal (Wat zijn de mogelijkheden en libraries)
De compiler/omgeving (Fout meldingen, uiteindelijke snelheid en gebruiksvriendelijkheid)
Het resultaat (Waar gaat het heen)

Als beginnend programmeur merk je al dat je voorkeuren hebt voor talen. Als ik fijn werk in een taal ben ik krachtiger bezig dan als ik zit te prutsen in een taal die ik niet handig vind werken. Daarnaast zijn er genoeg programmeurs die niet meekomen met het OO verhaal (classes ed. is makkelijk, maar de wereld van OO is iets groter)

De taal, hoeveel jaar moet je programmeren voordat je de grenzen van een taal tegenkomt? En hoeveel last heb je van een gebrek aan een taal.


Kracht is volgens mij:
Als een goede programmeur, in zijn favouriete taal, die *HEM* geen beperkingen bied voor het resultaat in een voor de programmeur bekende omgeving aan het programmeren is.

IMHO:
Discussies in de orde van "Deze taal heeft dit... Nee, maar de andere heeft dat" neigen al gauw naar "Die van mij is groter... Nee, maar die van mij is ...". Pak dan eens de Source Code van een paar wat grotere Open Source projecten in die taal en kijk of het wordt gebruikt. Dan kun je kijken (en bewijzen) of jouw visie over *NUTTIGE* kracht overeenkomt met die van een grotere community.
Als Intel op de doos van hun CPU's zet dat je ze erg goed uit het raam kan gooien, krijgen we dan werp benchmarks? Of een voetnoot dat het niet nuttig is?

[.oisyn]

eghie schreef op 20 juli 2004 @ 11:52:
[...]

Voor de wetenschap is tijd van een groot belang (meestal), dus meestal word het wel geoptimaliseerd in asm. Waarschijnlijk worden de alogritmes enzo wel eerst getest in c/c++, omdat dat wat minder werk is en wat overzichtelijker dan asm, maar ik denk dat het uiteindelijk wel naar asm word omgezet en geoptimaliseerd.

Efficientie is idd vaak belangrijk in de wetenschap, maar dat vertaalt zich niet naar routines geschreven in assembler, maar juist het ontwerp van betere algoritmen. De wetenschap werkt over het algemeen niet eens met een programmeertaal, maar berust zich puur op het ontwerp van een bepaald algoritme (in pseudocode). Het optimaliseren door het in asm te schrijven is echt een laatste optimalisatiestap waar het minste winst te behalen is, en daar houden ze zich over het algemeen echt niet mee bezig hoor (of je praat echt over dingen als compilerbouw natuurlijk, maar dat is maar een heel erg klein deel van "de wetenschap")

[Verwijderd]

Uhh... ik vraag met af wat er hier bedoeld wordt met de wetenschap, en waarom daarbij al dan niet assembler zou worden gebruikt. De wetenschap is namelijk nogal een brede term...

Je hebt daar de fysische wetenschap, waar ze C/C++ leren hacken, omdat het makkelijk is om programmaatjes te kunnen schrijven, om dingen te bereken cq. te analyseren.

Je hebt de wiskundige wetenschap, waar ze eigenlijk niet programmeren, maar gewoon wiskunde pakketten gebruiken (à la Mathematica, Matlab), om berekeningen in te doen. Deze pakketten hebben een eigen programmeertaaltje, dat hoog niveau is, en voornamelijk geïnterpreteerd wordt door de applicatie. Het rekenen gebeurt in een (zeker wel geoptimaliseerde) rekenkernel, maar daar heeft de wetenschapper niets mee te maken.

Dan heb je de goeie ouwe informatiewetenschap, waar het nog eens helemaal anders ligt. Daar wordt naar talen zelf gekeken, en het niveau kan liefst niet hoog genoeg zijn. Functionele talen, logische talen, een vleugje objectoriëntatie en veel abstracte concepten zorgen dat assembler daar ook niet echt van toepassing is. Verdraaid, we hebben zelfs les gehad over een taal die niet gecompileerd kan worden...

En dan is er nog de electronische wetenschap, en die zitten inderdaad de hele dag practicumbordjes te programmeren met assembler. Maar ja, die weten niet beter .

[ Voor 4% gewijzigd door Verwijderd op 20-07-2004 13:57 ]

[ritsjoena]

TheGhostInc schreef op 20 juli 2004 @ 12:38:
De taal, hoeveel jaar moet je programmeren voordat je de grenzen van een taal tegenkomt? En hoeveel last heb je van een gebrek aan een taal.

Hangt ervan af wat je maakt. Sommige komen de grenzen van een taal nooit tegen, anderen al bij het eerste "serieuze" dat ze doen.

Kracht is volgens mij:
Als een goede programmeur, in zijn favouriete taal, die *HEM* geen beperkingen bied voor het resultaat in een voor de programmeur bekende omgeving aan het programmeren is.

Dit is waarom het aspect: wat ken je al en wat moet je nog leren belangrijk is bij het kiezen van de taal voor de toepassing. Aangezien de meeste talen de meeste problemen wel aan kunnen pakken en je alleen met specifieke problemen beter een specifieke taal kunt gebruiken, pakken de meeste programmeurs over het algemeen hun voorkeurstaal. (of 1 van de)

Een aspect dat hierop aansluit is dat als je veel in een taal programmeert, dan bouw je ook veel standaardfuncties op die je kunt hergebruiken.

IMHO:
Discussies in de orde van "Deze taal heeft dit... Nee, maar de andere heeft dat" neigen al gauw naar "Die van mij is groter... Nee, maar die van mij is ...". Pak dan eens de Source Code van een paar wat grotere Open Source projecten in die taal en kijk of het wordt gebruikt. Dan kun je kijken (en bewijzen) of jouw visie over *NUTTIGE* kracht overeenkomt met die van een grotere community.
Als Intel op de doos van hun CPU's zet dat je ze erg goed uit het raam kan gooien, krijgen we dan werp benchmarks? Of een voetnoot dat het niet nuttig is?

Als de discussie verzand in visserslatijn sla je te ver door. Als je een eerlijke discussie voert is deze echter in de trant van: "deze taal heeft dit, waardoor dit en dit makkelijker wordt. Deze (andere) taal heeft weer dit waardoor ...", kun je een hoop leren dat de keuze van een taal beinvloedt. Dit leidt tot de beste tool voor de beste job.

Of een nieuwe feature in praktijk handig is, is iets dat de tijd moet leren, maar voor je zover bent, moet je hem wel kennen en de mogelijkheden ervan doorzien.

[Verwijderd]

Verwijderd schreef op 20 juli 2004 @ 11:28:
[...]


Weet je dat zeker? Ik heb asm niet vaak gezien in de wetenschap, tenzij het om het gebied gaat wat zich expliciet richt op compilere optimalisaties. Voor de meeste andere wetenschappelijke gebieden is toch dikwijls de keus/ontwerp van het algoritme belangrijker. Het is daarbij essentieel dat erover geredeneerd kan worden kwa complexitiet en stabiliteit. Volgens mij wordt dan toch meestal naar C of C++ gekeken.

In de wetenschap (nogal vage term trouwens) is men op zoek naar resultaat, niet perse naar hoe snel het kan. Heel veel schrijven nog steeds in fortran.

[Verwijderd]

Verwijderd schreef op 20 juli 2004 @ 15:43:
In de wetenschap (nogal vage term trouwens) is men op zoek naar resultaat, niet perse naar hoe snel het kan. Heel veel schrijven nog steeds in fortran.

Huh? Het argument voor fortran is natuurlijk de beschikbare wiskundige/numerieke libraries, maar daarnaast wordt fortran gebruikt omdat een fortran-compiler nog steeds snellere executables levert dan het zelfde algoritme in C (er kan meer geoptimaliseerd worden in fortran omdat het een simpelere taal is; b.v. is address aliassing (zeg maar twee pointers naar een enkel adres) onmogelijk, waardoor de compiler een groot aantal "move-to-register" instructies kan laten vallen).