Programmeertalen, welke, wat, hoe duur?

[RayNbow]

BoringDay schreef op maandag 09 november 2015 @ 20:00:
[...]


Het doet denk ik er helemaal niet toe of een boek 1300 pagina's heeft.
Bij andere talen is dat niet anders

The C Programming Language telt anders geen eens 300 pagina's.

[.oisyn]

Lees je nou gewoon slecht? Ik zeg toch juist dat je polymorphisme en exceptions ook niet gebruikt? En het hele gemis van de standaard library laat je voor het gemak maar even buiten beschouwing, terwijl dat ook een niet gering onderdeel is van de taal .

Je zegt dat C++ geschikt is voor beginners, en dan kom je met als voorbeeld een DSL gebouwd in C++. Ja dan houdt de discussie snel op inderdaad...

[Sissors]

.oisyn schreef op maandag 09 november 2015 @ 20:42:
Lees je nou gewoon slecht? Ik zeg toch juist dat je polymorphisme en exceptions ook niet gebruikt?

Dat zeg je ja. Maar waar is het op gebaseerd? (Exceptions gebruik ik overigens idd niet, polymorphism, zowel in de vorm van inheritance als in de vorm van templates gebruik ik wel, en heb je echt geen new voor nodig. Geen idee of exceptions ze nodig hebben.

En het hele gemis van de standaard library laat je voor het gemak maar even buiten beschouwing, terwijl dat ook een niet gering onderdeel is van de taal .

En waar is deze op gebaseerd? Uiteraard maakt het niks uit als een functie onder de motorkap het gebruikt (zoals een vector class zal doen). Daar heb je als gebruiker niks mee te maken, en dan hoef je dus ook niet na te denken over memory leaks en soortgelijken.

Je zegt dat C++ geschikt is voor beginners, en dan kom je met als voorbeeld een DSL gebouwd in C++. Ja dan houdt de discussie snel op inderdaad...

Jouw argumentatie komt niet verder dan wanneer je niet/beperkt new gebruikt, en je dus niet druk hoeft te maken over memory management, het geen C++ is.

[BoringDay]

Op het moment iemand gaat beweren je niet op memory management hoeft te letten bij een taal krijg ik een beetje het kriebel gevoel (soms is het noodzakelijk de regie in handen te nemen, dus weet wat er gebeurd).

[.oisyn]

Sissors schreef op maandag 09 november 2015 @ 20:47:
[...]

Dat zeg je ja. Maar waar is het op gebaseerd? (Exceptions gebruik ik overigens idd niet, polymorphism, zowel in de vorm van inheritance als in de vorm van templates gebruik ik wel, en heb je echt geen new voor nodig. Geen idee of exceptions ze nodig hebben.


[...]

En waar is deze op gebaseerd? Uiteraard maakt het niks uit als een functie onder de motorkap het gebruikt (zoals een vector class zal doen). Daar heb je als gebruiker niks mee te maken, en dan hoef je dus ook niet na te denken over memory leaks en soortgelijken.


[...]

Jouw argumentatie komt niet verder dan wanneer je niet/beperkt new gebruikt, en je dus niet druk hoeft te maken over memory management, het geen C++ is.

Nee, *jouw* argument was dat je louter geen memory management functies gebruikt. Ik beweer dat het veel verder gaat en je het *daarom* geen C++ kunt noemen. Bovendien werd er gezegd dat je in een embedded context helemaal geen geheugenallocaties gedaan werden, en daarom valt de stdlib dus af.

Polymorphisme, leuk voor die paar cases waar je direct je object by value aanmaakt, maar iets als een factory kun je al niet meer implementeren. Templates, een van de complexere features van de taal en absoluut niet voor beginners. De relevantie van dat jij ze wel gebruikt ontgaat me even.

[Sissors]

.oisyn schreef op maandag 09 november 2015 @ 20:58:
[...]

Nee, *jouw* argument was dat je louter geen memory management functies gebruikt.

Link? Mijn argument was dat als je bang bent voor geheugen beheer in C++ je een heel eind bij veel zaken kan komen door gewoon niet/heel beperkt new/malloc te gebruiken.

Ik beweer dat het veel verder gaat en je het *daarom* geen C++ kunt noemen.

Wat gaat veel verder?

Bovendien werd er gezegd dat je in een embedded context helemaal geen geheugenallocaties gedaan werden, en daarom valt de stdlib dus af.

Link? In sommige omgevingen wordt geen geheugenallocatie gebruikt. Dat is wat anders.

Polymorphisme, leuk voor die paar cases waar je direct je object by value aanmaakt, maar iets als een factory kun je al niet meer implementeren. Templates, een van de complexere features van de taal en absoluut niet voor beginners. De relevantie van dat jij ze wel gebruikt ontgaat me even.

De relevantie dat ik ze gebruik is omdat jij specifiek zei dat ik ze niet gebruikte. Om je te quoten:

zeg toch juist dat je polymorphisme en exceptions ook niet gebruikt?

[.oisyn]

Laat maar, we lullen langs elkaar heen denk ik. Als het je louter om memory management te doen is: als je alleen dat wegdenkt blijft de taal complex. Als je al die andere complexe zaken ook wegdenkt kun je het geen C++ meer noemen.

[ Voor 66% gewijzigd door .oisyn op 09-11-2015 21:09 ]

[BoringDay]

Templates zijn in principe ook niet complex alleen je moet er even in de materie duiken.
Iedereen kan bakstenen op elkaar stapelen maar niet iedereen kan een muur bouwen met een goed fundament.

[.oisyn]

Volgens die redenatie is niets complex, je moet alleen de materie snappen. Geldt bijvoorbeeld ook voor kwantummechanica. Maar jij vindt templates dus blijkbaar wel voer voor beginners?

[ Voor 21% gewijzigd door .oisyn op 09-11-2015 21:10 ]

[BoringDay]

.oisyn schreef op maandag 09 november 2015 @ 21:10:
Volgens die redenatie is niets complex, je moet alleen de materie snappen. Geldt bijvoorbeeld ook voor kwantummechanica.

Je kan natuurlijk de basis overslaan, kost alleen maar moeite en tijd.
Met een beetje knip en plakwerk komen we er ook wel

Begin bij het begin, mijn inziens hoort templates daar ook als onderdeel bij maar wel op het juiste moment (niet dat je er meester werk van maakt maar wel van op de hoogte bent en wat snapt

.oisyn schreef op maandag 09 november 2015 @ 21:33:
Het lijkt me nou niet bepaald de materie waarmee je middelbare scholieren bij hun introductie met programeertalem mee wilt lastigvallen, tenzij je ze af wilt schrikken om job security redenen

).

[ Voor 67% gewijzigd door BoringDay op 09-11-2015 21:42 ]

[.oisyn]

Het lijkt me nou niet bepaald de materie waarmee je middelbare scholieren bij hun introductie met programeertalen mee wilt lastigvallen, tenzij je ze af wilt schrikken om job security redenen

[Bartjuh]

Geef een leek de opdracht om één dag Python te leren, en één dag C++. Wedden dat de gemiddelde beginner C veel lastiger vind.

Ducktyping, simpele syntax, alles objects met magic methods (niks casten), handige scope rules. Python is 100x vergevingsgezinder, weinig verbose, goed human readable, etc. Veel, maar dan ook veel betere beginnerstaal. Dus niet een veel betere taal, dat is een andere discussie (C is sowieso veel sneller).

[ Voor 11% gewijzigd door Bartjuh op 09-11-2015 21:38 ]

[BoringDay]

.oisyn schreef op maandag 09 november 2015 @ 21:33:
Het lijkt me nou niet bepaald de materie waarmee je middelbare scholieren bij hun introductie met programeertalen mee wilt lastigvallen, tenzij je ze af wilt schrikken om job security redenen

Ik bedoel dan ook niet je er een meesterwerk van moet maken, maar op zijn minst van het bestaan af weet.
Wellicht iemand er nooit verder mee wat doet (net zoiets als staartdeling, we hebben het allemaal geleerd maar vraag me af hoeveel het in de praktijk toepassen).

[BoringDay]

Bartjuh schreef op maandag 09 november 2015 @ 21:37:
Geef een leek de opdracht om één dag Python te leren, en één dag C++. Wedden dat de gemiddelde beginner C veel lastiger vind.

Ducktyping, simpele syntax, alles objects met magic methods (niks casten), handige scope rules. Python is 100x vergevingsgezinder, weinig verbose, goed human readable, etc. Veel, maar dan ook veel betere beginnerstaal. Dus niet een veel betere taal, dat is een andere discussie (C is sowieso veel sneller).

Je moet ook niet een taal kiezen omdat het makkelijker is maar omdat je er een hoop van leert en uiteindelijk meer aan hebt.

[Bartjuh]

BoringDay schreef op maandag 09 november 2015 @ 21:48:
[...]
Je moet ook niet een taal kiezen omdat het makkelijker is maar omdat je er een hoop van leert en uiteindelijk meer aan hebt.

De eerste taal moet vooral toegankelijk zijn. Snel resultaat geven, en niet ontmoedigen. In praktisch elke programmeertaal zitten if's, while's, functies, arrays, etc (muv functionele/declaratieve talen, maar dat is andere koek). De basiselementen van programmeren, waar je moet beginnen.

Iemand de verder gaat komt vanzelf andere talen tegen, en komt daar dan ook makkelijker in.

[pedorus]

BoringDay schreef op maandag 09 november 2015 @ 21:08:
Templates zijn in principe ook niet complex alleen je moet er even in de materie duiken.
Iedereen kan bakstenen op elkaar stapelen maar niet iedereen kan een muur bouwen met een goed fundament.

C++ Templates zijn alleen maar een turing-compleet onderdeel van de compilatiefase, totaal niet complex ofzo. De complexiteit ervan is een reden dat dit bijvoorbeeld niet in java of c# is overgenomen, omdat de bedenkers daarvan zagen dat het een slecht fundament was... (Generics zijn geen Templates) Zo stikt het in c++ van de concepten die niet worden overgenomen in andere talen omdat ze slecht blijken uit te pakken (losse header files + defines bijv ...).

BoringDay schreef op maandag 09 november 2015 @ 21:42:
(net zoiets als staartdeling, we hebben het allemaal geleerd maar vraag me af hoeveel het in de praktijk toepassen).

Schitterende vergelijking, want staartdelingen worden veelal ook niet meer geleerd..

[BoringDay]

C is toegankelijk, alleen moet je eerst beginnen met de theorie (datatypes, operators, declaraties ect. ect.) en op basis van de theorie stapsgewijs gaan oefenen. Het gaat om het begrijpen van waarom iets zo werkt en C mijn inziens het meest geschikt voor.

De theorie is namelijk de basis niet meteen code kloppen.

[begintmeta]

Er zijn ook mensen die zeggen dat het theoretisch voor de theorie beter is functionele/logische programmeertalen te gebruiken om te beginnen meen ik.

[krosis]

pedorus schreef op donderdag 05 november 2015 @ 00:04: Maar wat je ook kiest, gebruik in jouw geval vooral geen scala of javascript. Gebruik c++, ruby of visual basic ofzo.

JavaScript werkt prima serverside. Node is snel.

[.oisyn]

pedorus schreef op maandag 09 november 2015 @ 23:42:
Zo stikt het in c++ van de concepten die niet worden overgenomen in andere talen omdat ze slecht blijken uit te pakken (losse header files + defines bijv ...).

Dat komt voornamelijk omdat C++ gebouwd is op het C ecosysteem, die op zijn beurt weer enorm oud is. Er zijn al wat proposals voor een module-achtige structuur. Het wordt momenteel gemaintained door de modules subgroup (SG2). CLang heeft al een implementatie.

[ Voor 8% gewijzigd door .oisyn op 10-11-2015 01:20 ]

[HuHu]

Sissors schreef op maandag 09 november 2015 @ 18:52:
[...]

Arduino = C++. Het is wel meer dan erop gebaseerd. (Ja er zijn wat dingetjes zoals dat de main functie onderwater is en het in setup en loop gesplitst is).

Sorry, maar als ik op de language reference kijk, zie ik toch echt geen C++. Pas als je zelf libraries gaat schrijven kom je met C++ in aanraking.

[...]

Drogredenatie die ik voor elke taal/platform kan maken. Hoeveel mensen weten hoe de achterliggende code van python libraries werkt?

Ik had het over achterliggende concepten. En die zijn bij C++ veel ingewikkelder dan bij Python.

[...]

Dan pak je mbed blink:

C++:

#include "mbed.h"
 
DigitalOut myled(LED1);
 
int main() {
    while(1) {
        myled = 1;
        wait(0.2);
        myled = 0;
        wait(0.2);
    }
}

Laten we dat dan vergelijken met een 'makkelijke' taal als python, oftewel blink programma op een Raspberry.

Python:

import RPi.GPIO as GPIO  
import time  
# blinking function  
def blink(pin):  
        GPIO.output(pin,GPIO.HIGH)  
        time.sleep(1)  
        GPIO.output(pin,GPIO.LOW)  
        time.sleep(1)  
        return  
# to use Raspberry Pi board pin numbers  
GPIO.setmode(GPIO.BOARD)  
# set up GPIO output channel  
GPIO.setup(11, GPIO.OUT)  
# blink GPIO17 50 times  
for i in range(0,50):  
        blink(11)  
GPIO.cleanup()

(Ja code doet niet exact hetzelfde, copy paste van voorbeeldcode voor beide platformen).

Oké... het enige dat je hier laat zien is dat voor een zeer specifiek probleem (Arduino programmeren) er nog geen mooie Python library of interface bestaat. Dat heeft helemaal niets met de taal te maken.

Kan iemand me hier, serieus, zonder sarcasme, zeggen dat het python voorbeeld makkelijker is dan de C++ code? En natuurlijk, python is voor zat zaken perfect, ik gebruik het soms ook. Maar het blanket statement dat C++ moeilijk is en bijvoorbeeld python makkelijk voor een beginner ga ik absoluut niet in mee.

Ook bij die python code kan ik 10 vragen per regel verzinnen, waarvan de meeste identiek aan de 'vragen' die jij over C++ verzint. Overigens als je problemen hebt met cout in c++, waarom niet gewoon printf dan gebruiken?

Overigens als instaptaal vind ik het een flink nadeel van Python dat het een taal is die heel anders werkt dan veel andere talen.

Het valt wel mee hoe verschillend Python is van andere talen. Ik merk in ieder geval dat het veel eenvoudiger aan studenten te onderwijzen is dan C++.

BoringDay schreef op maandag 09 november 2015 @ 19:31:
[...]


Geschikter?
Ten eerste zou je dan de vergelijking cout << "Hello world" moeten maken.
Ten twee is Python op C gebaseerd.
Ten derde die main is een stukje essentiële kennis wat ieder programmeur dient te snappen, laat staan lastiger vinden.

Ja geschikter. Ik begrijp niet wat je bedoelt met 'cout << "Hello world"', want dat compileert niet? Ik heb in zowel C++ als Python het minimale voorbeeld van "Hello world" gegeven. Hoe had ik de vergelijking anders moeten doen?

Het maakt mij niet uit dat Python in C is geschreven, het gaat om de taal zelf. Niet om de taal waarin de taal is geschreven. Uiteindelijk komen alle talen weer bij machinecode of assembly terecht, maar dat is geen argument.

Main (of generieker: het startpunt van je applicatie) is inderdaad een belangrijk stukje kennis. Maar je kunt ook niet ontkennen dat het in C++ ingewikkelder is dan in Python.

[RayNbow]

HuHu schreef op dinsdag 10 november 2015 @ 08:23:
Het maakt mij niet uit dat Python in C is geschreven

...plus dat niet alle implementaties in C geschreven zijn. PyPy is een Python JITter geschreven in Python.

[incaz]

BoringDay schreef op maandag 09 november 2015 @ 23:42:
C is toegankelijk, alleen moet je eerst beginnen met de theorie (datatypes, operators, declaraties ect. ect.) en op basis van de theorie stapsgewijs gaan oefenen. Het gaat om het begrijpen van waarom iets zo werkt en C mijn inziens het meest geschikt voor.

De theorie is namelijk de basis niet meteen code kloppen.

Dat is vooral zo'n ideaalbeld... maar zo zitten mensen niet in elkaar. Mensen kunnen en willen niet eerst droge materie als basis. Mensen leren juist het beste van concreet naar abstract, niet andersom.

Dat betekent dus juist een taal waar de basis als vanzelf naar voren komt, waar je snel mee aan de gang kunt, en waar je daarna pas toewerkt naar het theoretische kader, beter werkt. De theorie kun je daarna makkelijk ophangen aan de ervaringen, dat werkt veel beter dan andersom.

[Onbekend]

Een korte theoriecursus a.d.h.v. kleine voorbeelden is erg raadzaam.
Bijvoorbeeld de verschillen tussen if ( x = 1 ) en if ( x == 1 ), de do-, while- en for loops, if/else en switch/case.

Als je daarna de functies met verschillende soorten argumenten en classes met public en private variabelen (protected hoeft van mij nog niet) leert, dan kan iemand snel aan de gang met C#.

Daarna moet de programmeerervaring worden opgebouwd en komen de rest van de vragen vanzelf.

[Brent]

.oisyn schreef op maandag 09 november 2015 @ 21:33:
Het lijkt me nou niet bepaald de materie waarmee je middelbare scholieren bij hun introductie met programeertalen mee wilt lastigvallen, tenzij je ze af wilt schrikken om job security redenen

Ik had het genoegen een uitstekend C++ intro vak te volgen, en dat ging supervloeiend. De docent hield ons netjes bij harige zaken vandaan, en leerde ons modern C++. Door dat vak snapte ik classes pas (wat ik met Python totdantoe nooit aan toe kwam). C++ kan dus zeker geschikt zijn voor beginners, maar dan moet je wel een docent hebben die ver blijft van C-ismes, handmatig geheugenbeheer, liefst wat libs meeleverd etc etc. Modern C++ is heus modern! Het valt me alleen op dat mensen die langer meelopen niet meegaan met de ontwikkelingen

Bartjuh schreef op maandag 09 november 2015 @ 21:37:
Python is 100x vergevingsgezinder,

Deze mis ik het meest als ik C++ code. Maar ik zou eraan toevoegen dat dat ook grotendeels cultuur is. De meeste C++ in het wild (en de meeste (oude) C++ coders) omarmen STL te weinig, terwijl die juist een hoop ellende voor je wegneemt als je er goed mee om leert gaan.

Waar geen kruid tegen gewassen is, ik noemde hem al, is iets als pip. Tenzij je onderzoeker bent, is elk probleem al 3 keer opgelost. Python heeft de tooling en de cultuur tenminste 1 zo'n oplossing op Pypi te zetten zodat niemand dat nog eens hoeft op te lossen. In de C++ wereld is door de moeilijkheid van libraries vinden en compilen het wiel al miljoenen malen opnieuw uitgevonden. Mijn eerstgeborene voor een C++ package index + tooling + cultuur

[HuHu]

Je kon dus al programmeren (in Python) voordat je aan C++ begon, Brent?

[InZane]

krosis schreef op dinsdag 10 november 2015 @ 00:16:
[...]


JavaScript werkt prima serverside. Node is snel.

Ligt er maar net aan wat je wil gaan doen. Voor CPU intensieve taken wil je sowieso niet bij Node zijn.

[Brent]

HuHu schreef op dinsdag 10 november 2015 @ 12:49:
Je kon dus al programmeren (in Python) voordat je aan C++ begon, Brent?

Beetje, in beide overigens.

[valvy]

Zou je dat kunnen onderbouwen? Mijn (subjectieve) ervaringen zijn echt anders.

C++ wordt gecompileerd naar een generiek platform (het moet immers overal werken). Java heeft echter het voordeel dat een jvm optimaal op specifieke hardware beter gebruikt.

Zoals beter een cache gebruiken, meer cores. En nog veel meer wat per pc verschilt. En waar c++ geen rekening mee kan houden(wat een jvm wel kan)

Echter is c++ sneller in graphics, daar worden hardware optimilisaties gedaan in de video driver(dus eigenlijk geen c++ maar een shading language) en kunnen met name pointers wonderen verrichten.

[begintmeta]

valvy schreef op dinsdag 10 november 2015 @ 18:15:
...
C++ wordt gecompileerd naar een generiek platform (het moet immers overal werken). ...

Een hoop software wordt ook in C++ voor specifieke systemen gecompileerd, en er is ook heel wat software die afhankelijk van de omgeving waar het gedraaid wordt een bepaald pad kiest of zaken aan of uit zet (Intels MKL is daar een voorbeeld van (wel gedeeltelijk fortran, maar het principe is hetzelfde, libav (ook geen c++) heeft meen ik ook dergelijke voorzieningen)).

[ Voor 8% gewijzigd door begintmeta op 10-11-2015 18:31 ]

[Brent]

valvy schreef op dinsdag 10 november 2015 @ 18:15:
[...]


C++ wordt gecompileerd naar een generiek platform (het moet immers overal werken). Java heeft echter het voordeel dat een jvm optimaal op specifieke hardware beter gebruikt.

Je begrijpt het verkeerd. C++ kan alleen compiletime optimaliseren, Java ook tijdens runtime (meestal wat later, vandaar dat je vaak een JVM warm moet draaien). Echter, C++ kan heel wat codepaths meecompilen, en bij runtime gebruik maken van datgene wat past bij wat beschikbaar is. Java kan hoeft dit pas op runtime te beslissen, wat wat ruimte scheelt (in theorie).

De praktijk is echter dat het Java behalve op wat kleine punten niet is gelukt C++ te verslaan, vandaar dat bijna niemand Java gebruikt voor grote numerieke taken. Ik moet zeggen dat Java (of eigenlijk, de JVM) indrukwekkend is, maar de payoff is er wmb niet. Die is toch meer de betere deploybaarheid van .jars vs executables uit GCC/LLVM/etc. Je kunt Java ook een betere taal vinden (of niet). Maar als het op ruwe performance en optimalisaties aankomt (om niet te spreken van geheugenbeheer), dan kan de JVM slechts in de schaduw van GCC staan.

Zie evt ook https://gcc.gnu.org/wiki/FunctionSpecificOpt

[BoringDay]

incaz schreef op dinsdag 10 november 2015 @ 10:04:
[...]


Dat is vooral zo'n ideaalbeld... maar zo zitten mensen niet in elkaar. Mensen kunnen en willen niet eerst droge materie als basis. Mensen leren juist het beste van concreet naar abstract, niet andersom.

Dat betekent dus juist een taal waar de basis als vanzelf naar voren komt, waar je snel mee aan de gang kunt, en waar je daarna pas toewerkt naar het theoretische kader, beter werkt. De theorie kun je daarna makkelijk ophangen aan de ervaringen, dat werkt veel beter dan andersom.

Maar dat mensen niet zo in elkaar zitten is geen excuus? Waarom zou je eerst dingen leren waarbij de kans groot is dat je het fout aanleert en ook nog eens allerlei aannames doet er vervolgens kan je jezelf weer op allerlei punten corrigeren omdat je van een hoop dingen niks afwist.

[incaz]

BoringDay schreef op dinsdag 10 november 2015 @ 19:04:
Maar dat mensen niet zo in elkaar zitten is geen excuus? Waarom zou je eerst dingen leren waarbij de kans groot is dat je het fout aanleert en ook nog eens allerlei aannames doet er vervolgens kan je jezelf weer op allerlei punten corrigeren omdat je van een hoop dingen niks afwist.

Dat mensen zo in elkaar zitten lijkt me een uitstekend excuus. Het is ontzettend dom om te verwachten dat mensen leren op een manier die ze niet goed kunnen. Je kunt wel proberen om kinderen eerst de grammatica van een taal te leren en een lijst met woordjes en dan verwachten dat ze ineens vloeiend de taal kennen, maar zo werkt dat gewoon niet. Bij kinderen gaat dat via gebrabbel en kernzinnen naar langzamerhand steeds complexer, bij leren programmeren is dat in zekere zin niet anders.
Mensen werken meer iteratief, steeds een beetje gedetailleerder en complexer en abstracter. (De stapsgrootte verschilt wel tussen mensen, en hoeveel ze willen weten aan theorie, details en abstractie is ook per persoon anders, maar toch.)

Daar niet bij aansluiten is vooral heel ineffectief (je probeert theorie te stampen die helemaal nog geen aangrijpingspunten heeft) en levert alsnog heel veel fouten op in de basis. Wil je mensen goed leren programmeren dan moet je zoeken naar iets dat aansluit bij hoe mensen denken, en van daaruit de details en theorie uitwerken. Het is dan geen enkel probleem om in eerste instantie een highlevel taal te nemen die simpele dingen simpel maakt, en dat vervolgens uit te bouwen naar dingen die complexer worden. Belangrijk is dat ze op het juiste moment het juiste zetje krijgen, net voordat ze creatief maar gevaarlijk worden zeg maar.
(Maar, ik heb nog geen taal gezien die niet heel makkelijk glorieus misbruikt kan worden, dus verwacht uberhaupt niet dat een programmeertaal dat gaat voorkomen.)

[BoringDay]

Bij mijn weten begint praktisch elk boek met een stuk theorie voordat ze met voorbeelden komen (niet zonder reden overigens). Maar jij wil de inhoud overslaan en meteen maar een voorbeeld pakken.

Lijkt mij de omgekeerde volgorde (structuurloos).

[ Voor 3% gewijzigd door BoringDay op 10-11-2015 19:46 ]

[gekkie]

BoringDay schreef op dinsdag 10 november 2015 @ 19:45:
Bij mijn weten begint praktisch elk boek met een stuk theorie voordat ze met voorbeelden komen (niet zonder reden overigens). Maar jij wil de inhoud overslaan en meteen maar een voorbeeld pakken.

Lijkt mij de omgekeerde volgorde (structuurloos).

Meeste programmeerboeken die ik heb gelezen combineren theorie met voorbeelden en hanteren in de begin hoofdstukken met enige regelmaat versimpelingen van de werkelijkheid / mogelijkheden (welke in latere hoofdstukken worden aangevuld, vaak met hetzelfde voorbeeld dat aangevuld wordt met de nieuwe kennis uit het desbetreffende hoofdstuk waaruit dan ook gelijk blijkt wat de meerwaarde kan zijn van die nieuwe kennis (al komt ook dat soms niet uit de ver omdat de voorbeelden relatief simpel zijn))

Niet alles is linear uit te leggen, tevens is ook niet alles simultaan uit te leggen.

[BoringDay]

Stap voor stap inderdaad maar het begint met theorie per onderdeel en de voorbeelden zijn gebaseerd op dat stukje theorie.

[incaz]

Dat klinkt al heel wat genuanceerder, maar past niet bij C als beginnerstaal.

[pedorus]

Brent schreef op dinsdag 10 november 2015 @ 18:42:
De praktijk is echter dat het Java behalve op wat kleine punten niet is gelukt C++ te verslaan, vandaar dat bijna niemand Java gebruikt voor grote numerieke taken. Ik moet zeggen dat Java (of eigenlijk, de JVM) indrukwekkend is, maar de payoff is er wmb niet. Die is toch meer de betere deploybaarheid van .jars vs executables uit GCC/LLVM/etc. Je kunt Java ook een betere taal vinden (of niet). Maar als het op ruwe performance en optimalisaties aankomt (om niet te spreken van geheugenbeheer), dan kan de JVM slechts in de schaduw van GCC staan.

Hierboven poste ik nog een benchmark waar java net boven c++ uitkwam. Gezien de verminderde security van c++ op dingen als bounds checking enzo is het eigenlijk verbazingwekkend slecht van gcc..

Ander voorbeeld. Even de contestwinnaars van dit forum op een rijtje:
[Programming Contest 5] Tuintopia .net
Programming Contest Nieuwe Stijl: Contest 4 *Score-update* jvm
Programming Contest Nieuwe Stijl: Contest 3 *uitslagen!* jvm
Programming Contest Nieuwe Stijl: Contest 2 *WINNAARS LEZEN* c++ (30% verschil tussen binaries)
Programming Contest Nieuwe Stijl: Contest 1 *uitslagen!* jvm

Dit ging om vooral numerieke taken, waar als "niemand" daar java voor gebruikt java toch opvallend vaak (3/5) wint. Het lijkt mij dat de overhead van dingen als bounds checking enzo die je bij jvm/.net hebt ondergeschikt zijn aan de kwaliteit van de programmeur. Voor veel projecten is c++ voor de productiviteit dan ook een slecht idee wat mij betreft.

Onbekend schreef op dinsdag 10 november 2015 @ 10:12:
Bijvoorbeeld de verschillen tussen if ( x = 1 ) en if ( x == 1 ),

Ook weer iets waardoor c++ lastiger is uit te leggen, en een bron van (security) bugs.

InZane schreef op dinsdag 10 november 2015 @ 12:54:
Ligt er maar net aan wat je wil gaan doen. Voor CPU intensieve taken wil je sowieso niet bij Node zijn.

Valt nog wel mee, afhankelijk van het type. Mutli-core gebruik is wel een issue, en node eindigt niet bovenaan in een contest. Maar het meest vervelende vind ik dat je je bijna altijd in Future-land begeeft, zonder dat de taal daarvoor support biedt zoals c# of scala dat heeft. In de plaats daarvan zijn er tal van libraries om dat deels op te lossen, op steeds andere manieren. En het gebrek aan block scope in combinatie met closures wordt ik trouwens ook niet blij van.

[Bartjuh]

Verreweg de meeste programmeerboeken zijn geschreven voor mensen die al een (redelijke) basiskennis en ervaring hebben met programmeren. Voor if, comparison, bools, functies, etc moet je vooral eerst praktisch bezig. Laten zien wat er kan, printen naar scherm, wat berekeningen, invoer, plots, etc, en zo snel mogelijk resultaat geven zonder daarbij zorgen te hoeven maken over static typing, scope, oop abstractie, etc.

pedorus schreef op dinsdag 10 november 2015 @ 20:28:
[...]
Ook weer iets waardoor c++ lastiger is uit te leggen, en een bron van (security) bugs.

In python kan je zelfs sommige dingen super human-readable maken, zoals "if variable is not 3: print 5", of "if 'knikker' in bakje", waarin bakje een iterable is (list, dict, etc)

[ Voor 31% gewijzigd door Bartjuh op 10-11-2015 20:42 ]

[gekkie]

BoringDay schreef op maandag 09 november 2015 @ 23:42:
C is toegankelijk, alleen moet je eerst beginnen met de theorie (datatypes, operators, declaraties ect. ect.) en op basis van de theorie stapsgewijs gaan oefenen. Het gaat om het begrijpen van waarom iets zo werkt en C mijn inziens het meest geschikt voor.

De theorie is namelijk de basis niet meteen code kloppen.

Ik vind dan om de redenen die je hier aandraagt C weer volstrekt ongeschikt voor een beginner.
Net zoals hogere programmeertalen veel te veel abstraheren over C .. abstraheert C natuurlijk veel te veel van machinecode. Gewoon lekker zelf met de registers aan de slag en de instructies uit de developer manual van de chipbakker(s) halen. Je druk maken of iets in een cacheline past enzo .. je kunt er echt niet vroeg genoeg mee beginnen .

Achja in de jaren 80 was het toch makkelijker ... nagenoeg allemaal basic denk ik voor den beginner.
(okee misschien "logo" in de schoolbus .. wat een tijden )

[ Voor 8% gewijzigd door gekkie op 10-11-2015 20:46 ]

[Brent]

pedorus schreef op dinsdag 10 november 2015 @ 20:28:
[...]

Hierboven poste ik nog een benchmark waar java net boven c++ uitkwam. Gezien de verminderde security van c++ op dingen als bounds checking enzo is het eigenlijk verbazingwekkend slecht van gcc..

De fameuze microbenches Ik weet dat ze te vinden zijn, maar doet niet ter zake, en dat weet je als het je brood is

En modern C++ doet netzoveel bounds checken als Java, nu klink je als iemand die de taal het laast in het vorige milenium gebruikte

[pedorus]

Het andere voorbeeld met contestresultaten of de andere benchmarks negeer je maar voor het gemak, of dat de meeste HFT code in java is..

Gisteren nog een pakketje gestuurd naar een moderne c++ service (c++11): een string zonder \0 op het einde. Vervolgens werd er op willekeurige momenten keurig aangevuld met willekeurig geheugen. Een gebruikte library deed kennelijk toch echt niet aan bounds checking..

Overigens zijn er ook genoeg gevallen van beroerde java code (java.net.ssl is bijvoorbeeld vrij traag). Mijn punt is dat voor de meeste problemen java evenveel of meer performance kan geven als c++, omdat vooral developmentproductiviteit uitmaakt. Er is maar een beperkte set problemen waar dit niet zo is (vooral grafische dingen), en waar je soms zelfs assembly wil gebruiken.

[valvy]

begintmeta schreef op maandag 09 november 2015 @ 23:59:
Er zijn ook mensen die zeggen dat het theoretisch voor de theorie beter is functionele/logische programmeertalen te gebruiken om te beginnen meen ik.

Het mooie aan een functionele programmeer taal is dat het vrij makkelijk concurrent programmeren is. En zeker nu computers steeds meer cores krijgen, grid computing zal het een steeds grotere opmars maken.

Echter wordt dit al sinds eind jaren negentig geroepen en is imperatieve talen vaak nog steeds een stuk sneller dan functionele talen. (Maar functionele talen zoals haskell zijn echt elegant en leuk)

[Brent]

pedorus schreef op dinsdag 10 november 2015 @ 22:08:
Het andere voorbeeld met contestresultaten of de andere benchmarks negeer je maar voor het gemak, of dat de meeste HFT code in java is..

HFT is CRUD, maar dan heel snel. Ik moet toevoegen dat echte numerieke algos nog gewoon in FORTRAN gecode worden (paketten als BLAS enzo).

Gisteren nog een pakketje gestuurd naar een moderne c++ service (c++11): een string zonder \0 op het einde. Vervolgens werd er op willekeurige momenten keurig aangevuld met willekeurig geheugen. Een gebruikte library deed kennelijk toch echt niet aan bounds checking..

Geloof ik niets van

Overigens zijn er ook genoeg gevallen van beroerde java code (java.net.ssl is bijvoorbeeld vrij traag). Mijn punt is dat voor de meeste problemen java evenveel of meer performance kan geven als c++, omdat vooral developmentproductiviteit uitmaakt. Er is maar een beperkte set problemen waar dit niet zo is (vooral grafische dingen), en waar je soms zelfs assembly wil gebruiken.

Weleens in supercomputerland rondgelopen? Niet alles speelt zich op desktops af

[farlane]

valvy schreef op dinsdag 10 november 2015 @ 18:15:
[...]
C++ wordt gecompileerd naar een generiek platform (het moet immers overal werken). Java heeft echter het voordeel dat een jvm optimaal op specifieke hardware beter gebruikt.

Zoals beter een cache gebruiken, meer cores. En nog veel meer wat per pc verschilt. En waar c++ geen rekening mee kan houden(wat een jvm wel kan)

Echter is c++ sneller in graphics, daar worden hardware optimilisaties gedaan in de video driver(dus eigenlijk geen c++ maar een shading language) en kunnen met name pointers wonderen verrichten.

Tot zo ver de theorie. Pakken die theoretische voordelen die Java (het platform, want de taal heeft daar niets mee te maken) ook zo ongelooflijk goed uit?

Overigens kan ik met C++ ook heel nauwkeurig bepaalde hardware targetten (en dan ben ik volgens mij weer sneller dan Java kan zijn) alleen kan ik het niet @runtime doen.

[.oisyn]

En laten we wel wezen, automatic vectorization is nog altijd dramatisch in compilers/jitters. De meeste C++ implementaties ondersteunen SIMD intrinsics.

[Merethil]

.oisyn schreef op woensdag 11 november 2015 @ 10:54:
En laten we wel wezen, automatic vectorization is nog altijd dramatisch in compilers/jitters. De meeste C++ implementaties ondersteunen SIMD intrinsics.

Ik ben gaan Googlen waar je het in hemelsnaam over had en toen vond ik dat Java-gebruikers dan vastzitten aan het aanroepen van C(++) code dmv JNI.
Mijn kennis van dit soort zaken is nogal matig (iets met Enterprise developer enzo ), maar zou die issue nu "verholpen" zijn door gebruik van JNI?

Linkje voor wat ik vond: http://stackoverflow.com/...orized-floating-point-ins

[ Voor 11% gewijzigd door Merethil op 11-11-2015 11:12 ]

[.oisyn]

Merethil schreef op woensdag 11 november 2015 @ 11:12:
[...]


Ik ben gaan Googlen waar je het in hemelsnaam over had

Het gebruiken van SIMD (ook wel: vector) operaties voor herhalende wiskundige operaties. Stel je hebt twee even lange arrays van floats, en je wilt die componentsgewijs bij elkaar optellen. Je zou dan zoiets kunnen doen:

Java:

void addTo(float[] a, float[] b)
{
    for (int i = 0; i < a.length; i++)
        a[i] += b[i];
}

Moderne processoren (nou ja, modern, al vanaf de PIII wat betreft x86 ) hebben speciale registers en instructies aan boord om dit soort operaties te versnellen. In plaats van een enkel float register, heb je een register waar bijvoorbeeld 4 floats tegelijk in passen. En een bijbehorende instructie om die bij elkaar op te kunnen tellen. Grof gezegd heb je dus een 4x performance winst, want met een enkele instructie vermenigvuldig je 4 floats tegelijk ipv 1. Tegenwoordig heb je AVX-256 waar er 8 floats in een enkel register passen, en AVX-512 staat ook voor de deur (16 floats per register).

In C++ kun je bovenstaande code omschrijven door gebruik te maken van zogenaamde "instrinsics". Een intrinsic function is een functie waarvan de compiler van tevoren al weet hoe de implementatie eruit ziet. Dit gaat wat verder dan inline functions, en ze compilen vaak direct naar een bepaald pattern van assembly instructies. VC++ heeft intrinsics voor zo'n beetje alle assembly instructies die niet direct corresponderen met standaard operators, en dus ook voor SIMD.

Bovenstaande code kun je dus in C++ ook zo schrijven:

C++:

void addTo(__m128 * a, __m128 * b, size_t n)
{
    for (size_t i = 0; i < n; i++)
        a[i] = _mm_add_ps(a[i], b[i])
}

Waarbij de intrinsic _mm_add_ps() direct wordt vertaald naar de addps instructie

Automatic vectorization is het proces waarbij de compiler/JITer bovenstaande Java code herkent als vector operaties en dat compileert naar bijbehorende instructies, in plaats van gewoonweg enkele floats op te gaan zitten tellen. Voor hele simpele loopjes zoals bovenstaand lukt dat wellicht nog wel, maar bij complexere code snapt ie er niets meer van.

Al zie ik dat .Net 4.6 blijkbaar wel wat SIMD primitieven heeft in System.Numerics, mooi . Bijkomend voordeel is dat je met een Vector<float> dan ook meteen gebruik maakt van de lengte van onderliggende hardware. Run je je .Net app op een AVX-512 CPU dan heb je dus ook automatisch 16-component vector operaties. Dat is natuurlijk een groot voordeel van JIT tov static compilation. Al wil ik hierbij ook even gezegd hebben dat C++ geen static compilation impliceert, dat kan net zo goed geJIT worden.

maar zou die issue nu "verholpen" zijn door gebruik van JNI?

Leuk voor basale number crunching operaties, maar als dergelijke bewerkingen in je hele app te vinden zijn wordt dat natuurlijk lastig

[Merethil]

.oisyn schreef op woensdag 11 november 2015 @ 11:40:
[...]

[Uitleg]

[...]

Leuk voor basale number crunching operaties, maar als dergelijke bewerkingen in je hele app te vinden zijn wordt dat natuurlijk lastig

Thanks! Ik zat al wat rond te browsen en vond al wat uitleg hierover, maar de jouwe is nog wat duidelijker. Natuurlijk kan niet constant op die manier C(++) included worden door JNI als je het op veel plekken nodig hebt, dus daarvoor zou zoiets bouwen in Java duidelijk minder performen, maar zo te zien is er in ieder geval een mogelijkheid om, mocht het écht nodig zijn, dit zelf te forceren.

Ik zag wel, onder dezelfde link die ik hiervoor postte, dat er een aantal verbeteringen in zijn gemaakt met Java 7u40 en verder, waarbij er wel ondersteuning is gekomen voor auto vectorization van simpele for-loops, maar wat ik opmaak uit andere posts op 't internet omtrent het onderwerp is dat lang niet alles wat je zou willen

[gekkie]

Je moet wel vrij helderziende zijn als beginner om te bedenken dat je later wellicht een performance probleem gaat krijgen waar het wel of niet gebruiken door je compiler / runtime env. van onderliggende extended instructies cruciaal is. (en dan nog is het de vraag of het starten met een taal die er wel van gebruik kan maken, ipv later overstappen op zo'n taal, werkelijk het beste plan is.)

[begintmeta]

UIteindelijk zal het grootste deel van de software toch zichzelf gaan schrijven verwacht ik, je heb dat vooral talen nodig waarin je goed kan uitdrukken wat de bedoeling is.

[.oisyn]

gekkie schreef op woensdag 11 november 2015 @ 13:26:
Je moet wel vrij helderziende zijn als beginner om te bedenken dat je later wellicht een performance probleem gaat krijgen waar het wel of niet gebruiken door je compiler / runtime env. van onderliggende extended instructies cruciaal is. (en dan nog is het de vraag of het starten met een taal die er wel van gebruik kan maken, ipv later overstappen op zo'n taal, werkelijk het beste plan is.)

Dat klopt, maar ik vraag me af wie hier in de topic een dergelijke bewering heeft gedaan. Het is een beetje flauw om de zijdiscussie die is ontstaan te wijten aan de vraagstelling van de TS die opperde dat de ene taal wellicht sneller was dan de andere.

[ Voor 11% gewijzigd door .oisyn op 11-11-2015 13:36 ]

[gekkie]

.oisyn schreef op woensdag 11 november 2015 @ 13:34:
[...]
Dat klopt, maar ik vraag me af wie hier in de topic een dergelijke bewering heeft gedaan. Het is een beetje flauw om de zijdiscussie die is ontstaan te wijten aan de vraagstelling van de TS die opperde dat de ene taal wellicht sneller was dan de andere.

Mwah verwijten verwijten .. maar het lijkt me dan wel handig om enigzins de context van de TS erbij te houden. Vooralsnog lijkt de TS voor iets kleins en niks speciaals iets te zoeken (okee okee Linus begon misschien ook met "het is maar klein en niks speciaals", maar vooralsnog zie ik nergens dat de TS een niche op zou willen zoeken van een OS programmeren, een realtime 3D graphics spel, realtime beeldverwerking etc.

Kortom de kans dat hij in de nabije toekomst binnen die context dit soort optimalisaties nodig heeft acht ik kleiner dan de kans dat hij geholpen is met een taal om de basics van programmeren zich weer eigen te maken.

Nou maakt dat het gelijk weer lastig omdat er eigenlijk voor iedere taal ondertussen wel:

• een gratis IDE / editor met fatsoenlijke ondersteuning bestaat.
• er een of meerdere gratis beschikbare compilers / dev en runtime envirionment is.
• er voldoende stdlibs, code snippets, externe libs beschikbaar zijn, om nog iets sneller te kunnen komen waar je wil zijn.
• er voldoende boeken en webdocumentatie is.
• voor alle verschillende OS' en
• en elke taal en omgeving heeft z'n eigen nukken, maar voor de basics is dat beperkt

En dat het meest lastige soms nog wel eens is om uit te zoeken wat je bij een bepaalde taal juist beter niet kunt gebruiken aan legacy frameworks en libs.

[.oisyn]

Ik was in de veronderstelling dat de vraag van de TS inmiddels al lang en breed was beantwoord. En ik heb nota bene zelf al eerder gezegd dat ik C++ niet bepaald de meest ideale instaptaal vind

[farlane]

gekkie schreef op woensdag 11 november 2015 @ 14:02:
Mwah verwijten verwijten .. maar het lijkt me dan wel handig om enigzins de context van de TS erbij te houden

Het was meer een door de TS aangezwengelde secundaire (uitzichtsloze ) discussie over performance van taal X versus taal Y. Altijd leuk!

[Merethil]

gekkie schreef op woensdag 11 november 2015 @ 13:26:
Je moet wel vrij helderziende zijn als beginner om te bedenken dat je later wellicht een performance probleem gaat krijgen waar het wel of niet gebruiken door je compiler / runtime env. van onderliggende extended instructies cruciaal is. (en dan nog is het de vraag of het starten met een taal die er wel van gebruik kan maken, ipv later overstappen op zo'n taal, werkelijk het beste plan is.)

In dit geval ging het me natuurlijk ook niet om een beginner maar om een developer die, zoals al vaker geopperd is, gewoon de taal pakt die past bij wat je aan het maken bent/gaat. Er zijn gewoon talloze voordelen voor het gebruiken van een C(++) in tegenstelling tot een Java / C# / Python etc wanneer je aan de slag gaat met optimalisaties, snelheid en efficiëntie van je uiteindelijke programma.

Dit neemt niet weg dat in veel gevallen het overkill is om dit te gaan proberen te bereiken in alle software die je maakt: Soms is het net zo makkelijk en niet veel minder snel (maar waarschijnlijk wel sneller geproduceerd) als je met C# en WPF een programmaatje bouwt wat als kassa-interface gaat werken. Hetzelfde programma willen ombouwen om een kerncentrale volledig te automatiseren daarentegen... Tja

[gekkie]

farlane schreef op woensdag 11 november 2015 @ 14:37:
[...]
Het was meer een door de TS aangezwengelde secundaire (uitzichtsloze ) discussie over performance van taal X versus taal Y. Altijd leuk!

Hmm dan wordt het tijd voor een moddereter om de gehele "PHP is een poes" en alle whitespace discussies er dan ook alvast maar in te kopieren , hebben we die ook gelijk weer eens gehad .

[gekkie]

Merethil schreef op woensdag 11 november 2015 @ 14:47:
[...]
In dit geval ging het me natuurlijk ook niet om een beginner maar om een developer die, zoals al vaker geopperd is, gewoon de taal pakt die past bij wat je aan het maken bent/gaat. Er zijn gewoon talloze voordelen voor het gebruiken van een C(++) in tegenstelling tot een Java / C# / Python etc wanneer je aan de slag gaat met optimalisaties, snelheid en efficiëntie van je uiteindelijke programma.

Klopt alleen komen ze vaak verre van gratis, met de talloze voordelen krijg je er ook weer talloze nadelen bij. Vaak zijn alleen maar bepaalde delen van een programma werkelijk performance critical. Ga je vervolgens voor het volledige project low-level taal gebruiken dan, dan heb je daar voor last van de nadelen en weinig baat bij de voordelen. Uiteraard heeft mixen ook weer nadelen, zo blijft het altijd afwegen :-), achja als het allemaal eenvoudig was, was ook de lol er vanaf.

Dit neemt niet weg dat in veel gevallen het overkill is om dit te gaan proberen te bereiken in alle software die je maakt: Soms is het net zo makkelijk en niet veel minder snel (maar waarschijnlijk wel sneller geproduceerd) als je met C# en WPF een programmaatje bouwt wat als kassa-interface gaat werken. Hetzelfde programma willen ombouwen om een kerncentrale volledig te automatiseren daarentegen... Tja

Bij een kerncentrale heb je wel meer problemen, formele bewijzen hebben dat iets werkt, alles van compiler (te optimisitsche optimalisaties) tot runtimes. Lijkt me geen sinicure, ook niet met C.

[farlane]

[b]gekkie schreef op woensdag 11 november 2015 @ 15:25:
Bij een kerncentrale heb je wel meer problemen, formele bewijzen hebben dat iets werkt, alles van compiler (te optimisitsche optimalisaties) tot runtimes. Lijkt me geen sinicure, ook niet met C.

Runtime allocaties zijn in dat soort software niet toegestaan, laat staan een GC.

[begintmeta]

gekkie schreef op woensdag 11 november 2015 @ 15:25:
...

Bij een kerncentrale heb je wel meer problemen, formele bewijzen hebben dat iets werkt, alles van compiler (te optimisitsche optimalisaties) tot runtimes. Lijkt me geen sinicure, ook niet met C.

Worden dergelijke zaken niet ook regelmatig (onder andere) in bijvoorbeeld Ada of bijvoorbeeld ML-varianten of Haskell gemaakt? seL4 is zo te zien ook eigenlijk een 'legering' van diverse talen (zo te zien m.n. haskell, asm en c).

[ Voor 4% gewijzigd door begintmeta op 11-11-2015 15:58 ]

[gekkie]

begintmeta schreef op woensdag 11 november 2015 @ 15:57:
[...]

Worden dergelijke zaken niet ook regelmatig (onder andere) in bijvoorbeeld Ada of bijvoorbeeld ML-varianten of Haskell gemaakt? seL4 is zo te zien ook eigenlijk een 'legering' van diverse talen (zo te zien m.n. haskell, asm en c).

Ada lijkt idd in iedergeval voor te komen: http://archive.adaic.com/projects/atwork/nuclear.html
Lisp is wellicht ook nog wel een kandidaat. Voorspelbaarheid en correctheid lijken me een stuk belangrijker dan ruwe snelheid en de mogelijkheden werkelijk overal aan kunnen pielen voor micro-optimalisaties.
Dus voor het geval de TS nog aspiraties heeft in z'n achtertuin .

[ Voor 17% gewijzigd door gekkie op 11-11-2015 16:08 ]

[Brent]

farlane schreef op woensdag 11 november 2015 @ 15:31:
[...]

Runtime allocaties zijn in dat soort software niet toegestaan, laat staan een GC.

Het zal je verbazen

[begintmeta]

gekkie schreef op woensdag 11 november 2015 @ 16:05:
[...]

Ada lijkt idd in iedergeval voor te komen: http://archive.adaic.com/projects/atwork/nuclear.html
Lisp is wellicht ook nog wel een kandidaat. Voorspelbaarheid en correctheid lijken me een stuk belangrijker dan ruwe snelheid en de mogelijkheden werkelijk overal aan kunnen pielen voor micro-optimalisaties.
Dus voor het geval de TS nog aspiraties heeft in z'n achtertuin .

Ada is ook nog eens behoorlijk snel als ik wat makkelijk te vinden benchmarkjes mag geloven.

Dus misschien is Ada ook wel een kandidaat voor de TS.

[Area]

Kon geen relevante topic vinden en voor één simpele vraag wil ik geen topic openen.

Aan JavaScript-kenners, wat is het verschil tussen classList en className?
Kan iemand dat in Jan en Jippeke-taal aan mij even verduidelijken?

Alvast bedankt!

[.oisyn]

En dan kick je maar even een 5 jaar oud topic .

Je vraag lijkt me redelijk googlebaar. Je mag een topic openen, maar dan wel met een beetje moeite (leg uit welk antwoord je gevonden hebt en waarom je moeite hebt met het begrijpen ervan)