Ik weet niet waarom je mijn post eruit pikt, maar goed...

Leuke feature, maar een beetje programmeur mag zich wel in meer dan 1 taal kunnen redden,
Ik beweer nergens dat een programmeur slechts 1 taal hoeft te kennen. Ik ben het wel eens met het feit dat het goed is voor iemands ontwikkeling om meerdere programmeerparadigma's te kennen.
Over de feature, het is niet zo maar "leuk", maar de long datatype in Python is er voor een bepaalde reden. Python's doel is niet om low-level system software te schrijven, maar om scripts en user applicaties te schrijven, waarbij low-level details zoals de woordgrootte van de onderliggende machine niet belangrijk zijn.
als je waarden gaat opslaan/communiceren loop je alsnog tegen problemen aan, inzicht in datatypes en datastructuren is en blijft vereist voor performance/security/software design redenen, enzovoorts enzovoorts.
Inzicht in datastructuren is ook belangrijk en het weten welke datatypen er al in een bepaalde taal zitten en hoe deze zich gedragen is ook belangrijk, anders begrijp je de betekenis van een programma niet.
Echter, dit betekent niet dat je per se de onderliggende hardware moet kennen.
Ik zeg niet dat hogere talen waarin je 'minder vaak' (ja, voorlopig imo nog niet 'nooit') aan de machine hoeft te denken niet nuttig kunnen zijn. Maar kennis van standaard datatypes is altijd nuttig.
Maar wat versta je onder standaard datatypes? Datatypes zijn afhankelijk van de taal waarin je programmeert.

De datatypes van de (meeste) machines bestaan uit bytes en woorden, die afhankelijk van de gebruikte instructie anders worden geinterpreteerd.
En als het je een noemenswaardige tijd kost om bijvoorbeeld het begrip signed/unsigned tot je te nemen kan je maar beter meteen stoppen met programmeren.
Het begrip signed/unsigned is ook geen moeilijk begrip, maar het is niet een detail dat in een programmeertaal hoeft worden opgenomen. Waarom moet een taal het onderscheid kennen tussen een datatype dat alleen positieve getallen kan beslaan en een type dat zowel positieve als negative getallen kan bevatten?
Als je low-level software schrijft in een low-level taal en waarbij het gebruikte geheugen en het benodigde aantal cycles van belang is, dan heeft 't nut om het onderscheid te maken.
Echter, wat als ik in een high-level taal schrijf, wat heb ik aan het verschil tussen signed en unsigned? Misschien zeg je dan dat het handig is zodat je alleen bepaalde waardes kunt toestaan, zoals in het onderstaande, simpele voorbeeld:
code:
1
2
3
| unsigned int abs(signed int value) {
/* computation here */
} |
Maar nu we in de context van een high-level taal zitten, waarom wil je alleen signed/unsigned in je taal opnemen? Als we toch high-level zitten, kunnen we gaan spreken over domeinen. Een high-level taal zou dan veel meer hebben aan iets als het volgende:
code:
1
2
3
| function f (x : int[10,..>) : int[0,10] {
// computation here
} |
Om nu terug te keren naar het onderwerp van de draad: leren programmeren is eigenlijk niets anders dan het leren van een bepaald model van rekenen. De talen als C/Java/etc. hebben een sequentieel, imperatief rekenmodel. In zo'n model worden zogenaamde statements achtereenvolgens uitgevoerd en na elk statement kan de toestand van de wereld zijn veranderd (het tijdaspect in dit model is belangrijk, zie ook bijv.
deze lecture).
Naast talen met dit model bestaan er ook functionele en logische talen, waar in de functionele taal expressies worden gereduceerd door het invullen van de actuele parameters in de body van de functie en waar in de logische taal geprobeerd wordt om clauses waar te maken.
Een programmeur
hoeft dus niet de details van de hardware waar hij op werkt te kennen om te kunnen programmeren. Veel high-level programma's kunnen alsnog met pen en papier geschreven en worden uitgevoerd, zonder dat het op een echte machine wordt uitgevoerd. Een programma is niets anders dan een berekening die de invoer afbeeldt op een uitvoer.
Dit gezegd hebbende, het is natuurlijk niet zinloos als programmeur om je kennis te verbreden en je te verdiepen in computerarchitecturen. Het is natuurlijk bijv. wel handig om te weten wat een stack is om meer te begrijpen wat een 'out of stack' fout nu precies inhoudt.