In de universitaire wereld is python in de mode aan het komen. Vraag me niet waarom men zo gek is op deze ouderwetse slome taal waarbij programma's geschreven in versie 2 niet compatibel zijn met versie 3 en je niet eens kunt compileren zo heb ik begrepen.
Het is multi platform en gratis, dat is wellicht een voordeel. En voor studenten is het een leuke kennismaking met code schrijven.

Overweeg een goed betaald en veelgevraagd ambacht te gaan leren, zoals meubelmaker of loodgieter, en het noeste ICT werk aan de echte selecte professionals over te laten. Kies voor een goed beroep waarmee je onder de mensen komt.

Ga dus beter met je handen werken, i.p.v. alleen met je hoofd. Daar wordt je veel gelukkiger van, want meer rust in je hoofd. Daarnaast kun je altijd nog af en toe wel eens beetje met Linux of OpenBSD blijven hobby'en.

Met C# kom je ver momenteel, verdient ook.

Deze video is wellicht interessant: https://www.youtube.com/watch?v=pvf0zSh3rDo

Wat betreft het leren van een programmeertaal is het het belangrijkste dat je leert programmeren. Zodra je daar goed in bent, is het leren van een andere programmeertaal niet ongelofelijk moeilijk. Ik kan Python aanraden, maar het belangrijkste is dat je er een kiest en er mee bezig gaat.

Lua is veel beter. Backwards compatibel, en ook nog een snel, en inzitbaar in embedded systems.En het is niet zo dat een willekeurige set toetsaanslagen een Python programma oplevert.

Misschien heb je hier iets aan: https://www.codementor.io/blog/worst-languages-2019-6mvbfg3w9x. Ik zou voor JavaScript gaan. In combinatie met HTML/CSS kennis. Of misschien PHP. Want voor het serieuzere werk (zoals Java) wordt in de regel meer opleiding verwacht dan alleen hands on ervaring. Het vak informatica behelst nl. veel meer dan alleen de programmeertaal en is een HBO/universitaire studie van een jaar of vier, vijf. Plus relevante ervaring. Daar rol je niet zomaar eventjes in.

Mischien begrijp ik de vraag niet maar mijn eerste vraag is, waar doe je het voor?

Voor mij was het nooit een vraag: De computer greep me en ik wilde dat'ie deed wat ik 'm opdroeg. Dus van BASIC naar Pascal naar assembly naar C naar weetikhet wat ik allemaal nog meer geschreven heb. Voor mij is het dus geen vraag "welke taal moet ik leren?" maar "welke taal helpt mij dit probleem op te lossen?" en dan pak ik de relevante materialen (software, documentatie, etc.) er gewoon bij. De rest komt vanzelf.

Zelfs met jaren ervaring in C en tegen Unix aan programmeren pak ik nog steeds regelmatig de manpages erbij als ik iets wil. Ik weet natuurlijk ruwweg welke functies ik nodig heb maar hoe ze precies gebruikt worden is altijd weer even opzoeken. Ik gebruik geen Integrated Development Environment-programma maar veel mensen doen dat wel precies zodat het ding automatisch suggesties kan doen voor functies die je mischien wel nodig mocht hebben. Of dat nu zo'n goed idee is... maar ik zeg dit omdat je klacht "jamaar ik moet dingen opzoeken" waarschijnlijk nooit overgaat. Zelfs in het piepkleine taaltje awk (handig!) waar maar een handvol functies beschikbaar zijn moet ik nog wel eens even opzoeken hoe deze ene functie nu precies werkt.

En PHP, nouja, daar is de modus operandi voornamelijk om je probleem in google te gooien en dan de eerste de beste oplossing van stackoverflow te plukken en verder niet na te denken.

Mijn passie ben ik kwijt (burnout) maar kijk vooral wat je zelf aanspreekt. Malware analyse en beveiligingsgaten vinden vind ik vreselijk saai en zet eigenlijk geen zoden aan de dijk, maar als jij het wat vindt, niemand houdt je tegen.

Qua talen, kijk eens bij lisp (zoek op SICP en kijk bijvoorbeeld de college videos van Abelson en Sussman), of FORTH (Brodie's Starting Forth, ook online te vinden). Beide onconventioneel en beide geven ze je dat net een beetje meer als je snapt waar het over gaat. Wat overigens niet voor iedereen weggelegd is. Qua niches zijn er wel meer hoeken waar je in kan kijken; haskell, erlang, rexx, jcl.

Wil je serieus Unix "im griff" krijgen dan heb je kennis van C en shell (bourne shell, niet bash) en de vrindjes (sed, awk, ...) nodig. Perl (5) was lange tijd de go-to voor systeembeheerders maar dat is een beetje verwaterd. Sommigen vinden python gaaf, anderen ruby.

Je gebruikt linux maar de bulk van de wereld draait nog steeds windows. Daar heb je (hun versie van) C++, C#, VBA, excel, en nog zo wat van die rommel. Macrootjes knutselen en met veel te grote excelsheets goochelen die al lang geleden in een echte database gepropt hadden moeten worden is saai en frustrerend (zoals alles op windows) maar er zit ook nog wel geld in. En mischien kun je ze zelfs wel laten zien dat het op linux beter kan. Database opzetten, met excel of access koppelen, interne tools op interne (web)server klussen, wiki erbij, noem maar op.

Wat ook wel helpt is een cursus SQL doen (bijvoorbeeld db-class.org); veel applicaties hebben databases nodig en veel programmeurs weten eigenlijk niet wat SQL voor ze kan doen, wat een RDBMS eigenlijk levert. Dus worden er nogal vaak RDBMS-faciliteiten in de applicatie zelf (matig tot slecht) heruitgevonden. Allemaal moeite die je je (werkgever) besparen kan als je weet wat de database kan leveren, hoe relationele algebra werkt, en zo verder.

Als je vooral geinteresseerd bent in applicatieprogrammeren voor het geld, nouja, ga kijken naar de jobadvertenties in de sector waar je denkt dat je wil werken en kijk waar ze naar vragen. Zorg dat je daar (meerdere) opties hebt. Hoe ga je ze vertellen dat je echt heus waar ervaring hebt in de gevraagde taal?

Als je vooral "mensen wil helpen", nouja, dan ben je als systeembeheerder ook al aardig op weg natuurlijk. Hoewel daar wel scripten en zelfs wel programmeren in zit is (als je het goed doet) omvat dat veel meer aan andere dingen. Je kan Limoncelli's The Practice of System and Network Administration er eens bijpakken. Is wel een echt enorme pil.

Dat vind ik wel een goeie. Je krijgt dan een objectieve indruk van je marktwaarde en wat er nodig is om die te verbeteren. Het verschil tussen wat je weet en kan en wat je moet weten en kunnen.

Ja of de omstandigheden moeten zich aandienen aan jou (als je geluk hebt, mij overkomt dat niet want overal... zijn de leeches overal zijn tekorten en collegas zijn gewoon parasieten die zelf hogerop willen komen ten koste van...) aals je een reeks van middelmatige skills hebt die je beter kunt inzetten in plaats van je (op leeftijd?) nog gaan "specialiseren" in een bepaalde programmeertaal.

Zal ik NLP leren? AI gerelateerd....? Is toch de toekomst? ;-)

Onder de mensen? Ik kan je eens vertellen wat voor ervaring ik heb met groepjes mensen... Is schrijver ook een ambacht? Meubelmaken en duizend andere hobby dingen waar ik van droom komen pas na de financiele zekerheid.

In de praktijk hoef ik niet meer te werken eigenlijk tot mijn 67e en daarna krijg ik AOW. Eigenlijk is alles hobby.

Waarom het "rust " advies komt hopelijk niet van iemand die onrust in de hoofden van anderen zet ;)

Ik ga wat dingetjes schrjiven, ervaringen delen enzovoort.

De vorige keer dat ik "bij mensen" kwam werd ik wakker met een voedselvergiftiging. De keer daarop ook.

Meubels kopen ze maar bij de IKEA.

Kijk, hier heb ik wat aan! Met Python was me ook al tegengevallen dat v2 en v3 incompatible zijn in de syntaxis en dat is niet erg elegant. Ruby is dan wel wat vriendelijker maar heeft weinig support. Perl is mij te ouderwets.

Een kennis van mij was meubelmaker, er was op een moment geen goed werk meer voor deze. En besloot iets compleet anders te leren. Begon een cursus IT (totale newbie) na een cursus crime photography (werkte al voor de politie) en doet nu forensische opsporing of ondersteuning voor de politie.

Geen serieuze leercurve hier. Alleen ze hechten erg aan die lange opleidingen.

[/quote]

Pascal, Basic, php, html/css: allemaal 10 jaar ervaring (niet elke dag)
Awk/sed/ Linux en BSDs: 20 jaar ervaring met pauzes
C/C++: geen ervaring
javascript: altijd genegeerd
Perl/Python/RoR: cut & paste wat nodig is
Windows wereldje: genegeerd :-) dus geen VBA of C# maar wel met Delphi gespeeld vroeger
Assembly: ervaring maar gering
Debuggers assembly: verschillende debuggers 8 bit en 16 bit veel ervaring (latent aanwezig)
SQL: Postgresql en Mysql ervaring

Het antwoord ligt misschien niet in welke taal te leren. Systeembeheer boven applicaties bouwen. Dus Python en PHP zijn wel handig voor mij. PHP is opzoeken op php.net en Python is een kwestie van de syntax leren. Misschien is het dit voor een toekomstige systeembeheer job om processen te automatiseren, scripts aan een webinterface te koppelen. Ik heb dat in het verleden vaak gedaan en het neemt veel werk uit handen, veel dingen waar er nu tooltjes voor zijn. Want alles wat je kunt bedenken staat wel op github :-)

Ik heb geen behoefte andere mensen te helpen, alleen mijzelf. Systeembeheer is gewoon een makkelijke job afhankelijk van de organisatie. Het fijne is dat je altijd alles automatiseert en tijd over hebt voor studie en nieuwe taaltjes en dingen te ontwikkelen voor werkgever en je eigen kennisniveau. Een saaie baan maar goed voor als je mensen niet vertrouwt.

Nieuw en interessant voor mij is in sandboxen me in malware te verdiepen maar het stadium "Hoe het werkt" ben ik voorbij en ik ben niet van plan om het zelf te schrijven. Bij onderzoek alleen is er niets aan te verdienen tenzij je tijd over hebt en je wat wil doen voor een blog maar ook daar zit geen geld in; en bugs meldt je eigenlijk gewoon bij de dev (groot bedrijf misschien een bonus als je geluk hebt en iets nieuws aantreft). Die kans is dus klein tenzij ik me er volledig op toeleg. Maar hier is geen serieus betaald werk in te vinden ten opzichte van bijv. applicatie/systeembeheer en zorgen dat de boel blijft draaien voor een grote organisatie/instelling.

Midlife crisis.

Hey Jasper,

Ik kan je redelijk volgen. Toen ik rond de 50 was zat ik ook op zo een punt.

Volgende maand word ik 60. Ergens na de 50 ben ik iets helemaal anders gaan doen dan IT. Dat zou een goede tip kunnen zijn. Ik had het wel een beetje gehad, dat met emails teruglullen. En daarvoor al, in een grote wereldwijde firma gewerkt. Al die meetings, die post-its op flipovers plakken, en dan weer op een dag survival cursus met het hele "team". De inefficientie van zulke structuren. En dan de bakken met geld die daar naartoe gesmeten worden!

Een paar jaar geleden heb ik mijn ouwe vak weer opgepakt. Alle unix commando's bleken nog gewoon te werken. Onder diverse best handige nieuwe interfaces zat nog steeds de oude SQL. En als her-intredende-garnalenpeller-doende, merkte ik al snel dat de nieuwe generatie één belangrijk ding miste: Ervaring.

Ik ben momenteel lekker bezig. Mijn sterkste kant is meer all-round zijn. Assembler, of BASIC, of Pascal (wat bijna Algol is), C, allemaal leuk. Ik begon zo diep dat ik op papier zelf processoren ging ontwerpen, met logische poorten, flipflops, en schuifregisters. Maar het is voor mij nu van secundaire betekenis. Het fijne van nu is dat je alles niet meer uit je hoofd hoeft te weten. Wat dat betreft is het vak flink veranderd. Je wilt niet weten hoeveel dubbeltjes ik vroeger in het kopieer apparaat van de universiteit heb gegooid, om kopietjes te maken. Om zoveel mogelijk uit mijn hoofd te leren. Specs. Programmeertalen. Ik heb een hoop talen geleerd. Maar ook alle soldeerpootjes van de processors die toen voorhanden waren.

Ik heb nog nooit wat met Python gedaan. Maar ik heb wel leren leren. Geeft me twee dagen, en de rest zoek ik wel op. Ik hoef niet eens meer dubbeltjes in het kopieerapparaat te gooien. Mensen die eentalig zijn hebben grote moeite om een andere taal te leren. Maar ben je meertalig, dan pak je het zo op. De latere generatie is veelal van de PHP&SQL generatie. Die zijn ééntalig. Waarbij ze vaak de kracht van SQL niet eens kennen. Honderd keer die database in en uit.

Dat is nog niet zo relevant, want de machines zijn zo snel geworden dat die allemaal gebouwd zijn voor de jeugd die de toekomst heeft. Dat feitelijk onefficiënte software ook nog werkt. Dat je eigenlijk het verschil ook nog maar nauwelijks merkt.

Waar mijn markt ligt is in mijn ervaring. Van een klant die iets vaags wil. Maar dat ik die begrijp. Van een klant die klem zit met een project dat door een paar van die pubers wordt gemaakt en ik eigenlijk niet eens meer bij de meeting moet zijn omdat ik het gelul en de uitvlucht technieken al honderd keer heb gehoord. Als aannemers die tijdens het project al enkel bezig zijn om hun meerwerk er nog achteraan te gooien in plaats van eerst eens af te maken wat op de offerte staat. (Jacobse en Van Es!)

Mijn kracht is ervaring. Maar er is meer. Als je jong bent, dan ben je nog teveel bezig met je te bewijzen. En veel te veel bezig met je vak te zien als een technisch vak. Je hebt een witte jas aan, dus je wilt dat iedereen je ziet als dokter die alles weet. En dus minimaal beloond met vier vakanties per jaar, want je hebt een witte jas. Qua ambities overigens niks mis mee. Mijn Ferraris en Lambos liggen achter me, maar ik kan best begrijpen dat die guppen dat ook eens willen meemaken, en niet met het idee dat ze dat aan mij te danken hebben.

Het vak is geen technisch vak. Het is een creatief vak. Het is kunst maken. Toen ik jong was ben ik een paar keer in het Louvre geweest. Daar hing dan zo een Mona Lisa. Maar echt begrijpen waarom die zo bijzonder was, dat kon ik niet. Daar heb je jaarringen voor nodig. Hetzelfde heb je met IT projecten. Want ook de oude kunstschilders moesten het veel van hun technieken hebben. En er dan nog een ziel in leggen. Technieken kun je leren. Ziel komt met de jaren. Of terug naar de IT, team is mooi, maar de ziel komt van die ene die in de hoek zit, nooit wat zegt, en ineens een idee heeft. Wat dan vaak weer door het team de grond in wordt geboord. Het is een kunst vak.

Waar ik goed van leef is met dat te weten. En af en toe te zeggen, leuk, maar mag ik er eens een weekendje mee spelen? Vind je het niks, dan hoef je niks te betalen. Vanaf maandagmorgen hangen ze om mijn nek. Want ik kijk end-to-end. En van een afstand, maar ook van dichtbij.

En trends? Het is allemaal nog maar begonnen. Trek je niks aan van mensen die zeggen dat iets al lang bedacht is, of er al een ander is die het veel beter kan. De echte mooie tijd moet nog komen. Serieus.

Pas sinds de laatste 5 jaar zit iedereen, waar ze ook zitten, op kastjes te tikken. Er zijn er dan bij die "ook zoiets willen". Maar ze weten niet hoe. Die hebben vooral het oog van de kunstenaar nodig. Ook vooral om de originaliteit tussen de regels te lezen. En niet een blik open te trekken en wat plat na te maken.

Dat kun je alleen realiseren als je kijk hebt op kunst. En dat komt met de jaren.

Je wilt niet weten wat je op dat vlak waard kunt zijn als je van vóór de PHP/SQL generatie bent.

Ik leef daar goed van. Verstandig helpen plannen, de rest outsourcen, en daarna of tussendoor even de puntjes op de i zetten. Ik denk zelfs dat ik daar lekker mee bezig kan blijven tot het licht uitgaat.

Daar zul je niets in bereiken. De ICT met hun databases en programeer afdeling was ontzettend blij dat ze die lastige gebruikers kwijt waren door ze een PC met een spreadsheet mogelijkheid te geven. Dat was toen Lotus. Er is was een duidelijke reden dat de ICT meer dan 30 jaar terug er zo in stak en die is er nog steeds.

Er is een gapend gat tussen hadcore ICT nerds en wat de gebruikers bij de organisatie echt nodig hebben. Daartussen gebeurt veel, advies bureaus, hele stafafdelingen die zich met de afstemming en planning bezig houden. Dat is een drukke markt waar een zij-instromer het lastig zal hebben. Daar zit het memes maken de projecten met reorganisaties.

Bedrijven zij niet uit op een grote ICT staff in huis te hebben, integendeel. De verschuiving naar de cloud gaat verder doorzetten Saleforces Power-bi het verwachten dat de rapportjes direct uit het extern beheerde ERP systeem komen.
Nee ik denk niet dat je in die hoek moet zitten. Nieuw zou kunnen zijn domotica met een aansluiting naar IOT big data.
Camerasystemen en wat daar allemaal nog verder gaat. Het is koffiedik kijken.

We hebben het over een 50-er met carriere switch. Het willen opboksen tegen het jonge spul dat net van school afkomt lijkt me niet handig. Zeker niet op een gebied waar iedereen wel dat werk wil en kan doen. De vraag is wat je als persoon als bijzondere eigenschappen hebt waar je iets meer kan brengen.
De tijdspanne van over 2-3 jaar waarmee nu mee gestart wordt maakt het ook lastig. Voor je het weet is wat nu de belofte is straks uit de mode. Ik verwacht wel wat van phyton en lua wegens dat domotica thuis gebeuren. Ik denk niet dat wat er nu is dat exact zo is over een paar jaar nog zo is.

Dit soort standpunten met betrekking tot een taal zijn altijd vrij nutteloos. Er zijn tientallen goede redenen om een taal te kunnen gebruiken, net zoals er tientallen kunnen zijn om het niet te gebruiken. Waarom wel Python gebruiken. Omdat die 'slome taal' voor heel veel doeleinden meer dan snel genoeg is. Wat maakt het in vredesnaam uit of de end-user 0.000001 seconde wacht op resultaat of 0.001 seconde. Is 1000 keer trager, maar echt geen hond zal het merken. Zeker niet als je bijvoorbeeld erbij optelt dat het resultaat met bijvoorbeeld 87ms netwerklatency, 234ms frontend/css/javascript etc getoond word aan de gebruiker.

Een reden waarom het in de universitaire wereld veel gebruikt wordt bijvoorbeeld is dat met betrekking tot machine learning er heel snel iets bruikbaars gemaakt kan worden. Niet iedereen is programmeur, en gaat eerst 3 jaar C++ onder de knie krijgen om vervolgens iets te bouwen. Met python kan een doorsnee student op veel gebieden iets programmeren als ze slechts enige affiniteit met programmeren hebben.

Met python is het mogelijk om snel iets te kunnen ontwikkelen en redelijk bestand te zijn tegen fouten die in gecompileerde talen zoals c/c++ etc lijden tot heel lastig te debuggen dingen zoals segmentation faults, e.d.

Als wat jij zegt ook maar enig hout snijd, dan is de enige valide vraag nog: Waarom zijn er uberhaupt nog programmeertalen? Waarom doen we niet gewoon alles in assembler, of nog beter, waarom niet gewoon alles direct in 0'etjes en 1'tjes neerknallen?

Je leert het in Python en je doet het in een taal voor volwassenen.

Dan mis je echt waarom het ingezet wordt en waarom het in jouw taal voor volwassene een kostbare faal wordt.
https://machinelearningmastery.com/machine-learning-in-python-step-by-step/ Het gaat om de ML packages die vanuit anderen meekomen. Voorheen was de taal R, matrix gebaseerd, de taal voor dat soort mensen.
Het belangrijkste kenmerk: de informatieveiligheid moet vanuit de beheerders voor het OS komen, anders is er …. niets.
In die hoek heb ook: https://www.h2o.ai/ wat de ruimte lijkt in te vullen van revolution analytics (opgekocht door MS).
Je ziet aan de verkoopslogan de wens bij afnemers. Het moet niets kosten en wel snel van alles afleveren.

Dan zou er een heel andere functie belangrijk kunnen worden: ICT adviesbureau's - onafhankelijk advies.

Jááá karma4, je kan wel merken dat jij er écht verstand van hebt!

Dat is geen volwassen reactie.. Tja wat wil je met een Haddock achtergrond. Als je nu zou onderbouwen hoe je iets dat gemaakt is met Phyton of voor mij part met gebruik R package in jouw volwassen taal opgelost wordt. ...

Je licht er één nichetoepassing uit. En waar denk je dat de snelle numerieke libraries die voor jouw nichetoepassing worden gebruikt in geschreven zijn? In trage Python code? Echt niet... Die zijn in C of zelfs Fortran geschreven. Met Python scripting wordt het allemaal aan elkaar geplakt. N.B.: een taal voor volwassenen voor dit soort toepassingen zou bv. Julia kunnen zijn.

https://medium.com/@thomascherickal/will-julia-replace-python-and-r-as-a-data-science-tool-897efcf18b73

Ik ben volwassen en erg blij met Python. Met volwassen bedoel ik dat ik decennia professioneel geprogrammeerd had in andere talen voor ik er kennis mee maakte. Wat mij aanspreekt in Python is een cleane, goed leesbare syntax waarin je heel compact recht op je doel af kan gaan, zonder alle boilerplate en visuele ruis die veel andere talen meeslepen, en waarin een verrassend groot deel van de code die je schrijft gewoon in een keer werkt. Wie zo'n taal ontwerpt heeft iets heel belangrijks goed gedaan (hij heet Guido van Rossum en is er bij het CWI in Amsterdam mee begonnen).

Python is traag, ja, sommige benchmarks komen dacht ik een factor 20 of 30 trager uit dan C. En toch is het mogelijk (dat weet ik want ik heb het gedaan) om een template-library te bouwen in pure Python die de meeste tijd (als ik me goed herinner zelfs >90% van de CPU-tijd) doorbrengt in methods van het ingebouwde stringtype, in geoptimaliseerde C-code dus. En dat vergt niet dat je je in getructe bochten moet wringen om het voor elkaar te krijgen, voor alle duidelijkheid, het is gewoon nette Python-code. En ook is het mogelijk om beeldverwerkende software te maken (dat weet ik want ik heb het gedaan) waarvan een nog groter aandeel van de verwerking aan de geoptimaliseerde code van de numpy- en scipy-libraries wordt uitbesteed en nog een paar performancekritische stukjes in zelf in Cython geschreven code (dat is een Python-achtige taal, specifiek om modules voor Python mee te schrijven, waarmee een C-achtige performance haalbaar is).

In die decennia daarvoor heb ik onder meer aan grote administratieve en dus zwaar op database-I/O leunende mainframeapplicaties gewerkt die in een 4GL geschreven waren die net als Python trager was dan volledig naar machinetaal gecompileerde code. Ook daar was het geen probleem dat de taal traag was omdat zelfs met zo'n taal op een op I/O geoptimaliseerd platform (want dat zijn mainframes) de database-I/O de grote bottleneck is, niet het CPU-verbruik.

Moraal van het verhaal: die traagheid is voor veel toepassingen helemaal niet belangrijk. Python is een serieuze taal die geschikt is om serieuze toepassingen in te bouwen. Ik zie geen enkele reden waarom de bulk van wat ik in die tientallen jaren ben tegengekomen niet net zo goed (en qua onderhoudbaarheid vaak zelfs beter) in Python te bouwen zou zijn.

Of je er ook vacatures voor vindt in Nederland is een heel ander verhaal. Ik hoef inmiddels niet meer, dus het is inmiddels alweer jaren geleden dat ik een beetje oplette of er in die hoek wat te vinden was, en toen leek er niet veel te zijn. Er zijn heel wat organisaties die zwaar in Java of .NET hebben geïnvesteerd als platform en die zullen het echt niet over een andere boeg gaan gooien omdat er programmeurs rondlopen die van iets anders gecharmeerd zijn.

Ik ben het eens met de mensen die zeggen dat je voor waar vraag naar is naar vacatures moet kijken. Ik ben het met karma4 eens dat een 50-plusser die net begint het in veel gevallen waarschijnlijk aflegt tegen getalenteerde jonge honden.

Maar de vraagsteller noemt ook ouwelullentalen waar die jonge honden niet in geïnteresseerd zijn. Dan denk ik aan COBOL. Kan iemand vertellen of het beeld nog klopt dat financiële instellingen nog met even immense als onmisbare COBOL-systemen op mainframes zitten en kampen met een slinkende populatie aan programmeurs die daar raad mee weten en zin in hebben? Of hebben ze daar inmiddels overal oplossingen voor gevonden? Een jaar of tien geleden hield ik dat zelf als optie in mijn achterhoofd voor als een andere richting die ik toen probeerde zou mislukken.

Voor als het wat is is er een FLOSS-implementatie beschikbaar waarmee je aan de gang kan:
https://open-cobol.sourceforge.io/

Of op een Linux-systeem (uitgaande van apt als package manager):

Je gaat zoals gewoonlijk aan de essentie voorbij.

a/ Het ging niet om de taal zelf maar om het makkelijk kunnen kopiëren wat anderen al gebouwd hebben. Natuurlijk hopen ze zonder er zelf moeite voor te doen dat het allemaal goed werkt. Daar komt het probleem informatieveiligheid wat je stelselmatig ontwijkt.

b/ Dacht je dat het zinvol zou om wat anderen al gebouwd hebben nog eens helemaal over te doen. zonder ontwerp, zonder kennis van de algoritmes en de valkuilen. Zoiets kost veel tijd=geld. . Ook julia heeft dezelfde problematiek, met de verwijzing naar julia als vervanger voor R en Phyton geef je een bekende OSS probleem aan, Instabiliteit door gebrek aan visie.
Wil je in de big data wereld rondkijken gebruik dan https://www.kdnuggets.com/2018/12/machine-learning-data-visualization-deep-learning-tools.html[/url . Lees even die link van je door:"So should we throw Python and R away immediately?The answer is, an emphatic, no!If you’re new to data science and programming, learning Python and R is the best way to begin your exploration into the current industry"Het is niet af en weten nog niet of het wat wordt. Kijk naar het design van lua https://www.lua.org/wshop16/Ierusalimschy.pdf

Als programmeur wordt er van je verwacht dat je 90% of meer van je tijd achter je PC zit en het grootste deel daarvan besteedt aan code kloppen en debuggen. Als dat niets voor jou is, dan kun je het idee om programmeur te worden beter vergeten. Er zijn misschien mogelijkheden in gerelateerde beroepen als tester, systeem- of applicatiebeheerder of projectleider. (Met wat je in je post vertelt lijkt tester me beter bij jou passen. Begin eens met het schrijven van goede foutrapporten voor een or twee Open Source projecten; daarna kun je kijken naar TMAP of ISTQB certificaten.)

Er zijn genoeg bedrijven die met grote Cobol (of PL/I) applicaties bij mijn werkgever aankloppen met de vraag of wij die naar een moderne programmeertaal (Java, C# or C++) kunnen omzetten. Ik ken ook genoeg verhalen van gepensioneerde programmeurs die nog een paar uurtjes per week bijverdienen met hun kennis van de applicatie. Kennis van (embedded) SQL of IMS kan ook waardevol zijn.

@karma4
Warrig gedraai waar het nu ineens weer over de 'essentie' van het 'snel kunnen kopiëren wat anderen hebben gedaan' zou gaan.

@Gisteren, 20:03 door Anoniem

Het is beter dan PHP maar daar is ook alles mee gezegd. In professionele omgevingen wordt het wel gebruikt voor (snel even) prototypen. Daarna wordt e.e.a. gerealiseerd in een echte programmeertaal (Java, C++).

Die Python traagheid resulteert er echter in dat er - vergeleken met andere programmeertalen - veel meer processorcapaciteit nodig is om hetzelfde te bereiken. En dat is (onnodig) slecht voor het milieu.

als ik echter zie hoe vaak het nog gebruikt wordt klopt dit toch niet helemaal. Misschien bedrijfstak afhankelijk?

Het is geen gedraai van mij, je draait om de hete brij van de essentie heen. Snel van anderen kunnen kopiëren informatieveiligheid op het tweede plan. Dat het met phyton juist om AI ML in de modellering gaat brengt met zich mee dat functionaliteit nieuwe algoritmes het selectie criterium is. Performance is niet als informatieveiligheid bijzaak.
Had je de LUA link gevolgd dan had je gezien dat het bedoel is voor IOT tv's camera's spellen en meer. Een schil om C heen om snel te leveren. Wat daarbij opvalt, geen enkele aandacht voor informatieveiligheid.

Wat in phyton ontwikkeld en bedacht is zal op een of andere manier met LUA uitgerold worden.
Het klinkt omslachtig en dat is het ook.

Slecht voor het milieu? -> blockchain! Massale VM's, opgestelde warmtekachels (dozen computers) gereserveerd voor een project dat na 5 jaar reserveren nog niets heeft. De onzin van wat er allemaal bedacht wordt in ICT kent geen grenzen.

Je blijft eraan voorbij gaan dat de meeste code in verhouding tot het geheel nauwelijks geraakt wordt. Als je kijkt waar performance-bottlenecks in software zitten dan gaat het vrijwel altijd om een beperkte hoeveelheid code die erg vaak geraakt wordt. Pak die stukjes aan en je wint al vrijwel alles wat er te winnen valt. Al die statements die in verhouding tot het geheel maar af en toe geraakt worden zijn niet waar de grote klappen vallen, ook niet als ze op zich gruwelijk inefficiënt worden uitgevoerd. Als ik met een profiler bezig ben performance-bottlenecks op te sporen zie ik regelmatig dat het verschil in hoe vaak statements worden uitgevoerd onderling een factor honderden tot tienduizenden verschilt. Dat kan nog veel hoger, maar als de factor tientallen miljoenen bedraagt is er met een profiler (die zelf vertraagt) niet meer doorheen te komen, dus dat vermijd ik als het even kan.

Verder doet een proces dat op I/O staat te wachten niets, ook niet als het in Python geschreven is. Bij I/O-bound applicaties, en dat zijn er heel wat, doet de applicatie gek genoeg vaak helemaal niet zo veel. De grote adminstratieve systemen op mainframes waar ik ooit volop aan gewerkt heb zijn meer bezig data heen en weer te schuiven dan dat ze CPU-intensieve bewerkingen op die data uitvoeren.

Die verschillen doen ertoe. Die betekenen dat bij een flink deel van de code de winst die je met sneller uitvoeren zou halen, ook qua energieverbruik, marginaal is.

Nog iets qua energieverbruik: ik heb gezien hoe in een computerzaal in de loop van de jaren de mainframes steeds minder ruimte innamen en steeds meer gangen met racks vol Unix- en vooral Windows-servers verschenen. De geluidsdruk van de ventilatoren tussen die racks was op een gegeven moment voor mij nauwelijks meer te harden. De mainframes, inmiddels per stuk zo compact als een forse koelkast, waren daarentegen fluisterstil en als je je hand voor de luchtuitlaat van de koeling hield voelde het eerder koel dan lauw aan. En toch draaide de bulk van de business logic nog altijd op die mainframes, in die 4GL die ook geen snelle taal was. Alle schijven waren trouwens ondergebracht in centrale raid-systemen, ook de Windows- en Unix-servers hadden geen eigen schijven aan boord. De koeling was puur voor de CPUs en moederborden nodig. Je kan je afvragen wat maakt dat voor een minderheidsaandeel in de dataverwerking waar het feitelijk om gaat kennelijk een fors veelvoud aan CPU-kracht nodig is in vergelijking met die mainframes. Ik heb IT'ers met een Windowsachtergrond meegemaakt die hardnekkig het mainframe als "veel te duur servertje" bleven onderschatten omdat ze er met hun verstand niet bij konden dat met zo weinig CPU-kracht zoveel werk verzet kon worden, inclusief een manager die er door dat ongeloof meer dan een jaar voor nodig had voordat eindelijk het muntje viel hoe groot de systemen waren die qua beheer nota bene onder zijn verantwoordelijkheid vielen.

Ik heb trouwens ooit een bericht gelezen dat een bank, ik dacht in Brazilië, tegen alle trends in zijn hele hebben en houden niet van maar juist naar een mainframe converteerde. Ze hadden namelijk niet alleen naar licentie-, beheer- en ontwikkelkosten gekeken maar ook naar energieverbruik, en dat viel zoveel lager uit dat het voor hun de gunstigste oplossing was.

Bij meerdere pakketten die op die Windows-servers draaiden om een relatief klein deel van de totale business logic te bestieren heb ik soms meegekeken als de beheerders daarvan het datamodel aan het bestuderen waren. Telkens bleek zo'n datamodel enorm te zijn. In termen van aantal entiteittypen meer dan eens groter dan het complete corporate datamodel van de eigen systemen, voor een veel beperktere functionaliteit. Kijkend naar hoe die datamodellen in elkaar zaten was de reden daarvoor evident: een pakketbouwer moet klanten met de meest uiteenlopende wensen bedienen en heeft geen maatwerk-datamodel voor zo'n klant maar een waar ongeveer alles wat klanten aan variatie aandragen in onder te brengen is door met de configuratie te goochelen. Dat kan volgens mij niet anders betekenen dan dat het aantal I/O's dat nodig is om een taak uit te voeren een veelvoud is van dat bij een maatwerk-datamodel. Het ligt voor de hand dat dát wel eens een hoop energie kan vreten.

Als je naar energieverbruik kijkt dan moet je kijken naar waar de energie werkelijk in gaat zitten. Er spelen veel meer factoren mee dan alleen de gebruikte programmeertaal, en die is lang niet altijd de belangrijkste factor. Maar inderdaad, kritische CPU-intensieve algoritmes wil je inderdaad niet in een trage taal implementeren. Alleen zijn dat meestal beperkte stukjes code, en die kunnen worden overgezet naar een andere taal. En als het beperkt is dan kunnen de voordelen van zo'n trage taal, qua ontwikkelsnelheid, leesbaarheid en onderhoudbaarheid (en bij Python zijn die wat mij betreft evident), wel degelijk de balans in het voordeel van zo'n taal uit doen vallen.

En trouwens, voor je een algoritme overzet naar een snellere taal doe je er goed aan om te kijken of het algoritme zelf niet beter kan. Ik heb meer dan eens met een slimmer algoritme verbeteringen bereikt waar de snelheidsverschillen tussen programmeertalen met afstand bij in het niet vallen.

Ik heb, zoals ik schreef, een aantal keer Cython gebruikt bij performance-bottlenecks. Cython is een gecompileerde superset van Python (Python is ook geldige Cython), waarin je naast de dynamische gegevenstypen van Python (duck-typing; de belangrijkste reden waarom het een trage taal is) ook statisch gedeclareerde typen kan gebruiken, zowel Python- als C-typen. Er zit een tool bij om je sourcecode te analyseren die heldere suggesties geeft voor snelheidsverbeteringen. Het resultaat van de compilatie is een module die je rechtstreeks kan importeren in Python-code. Die opzet maakt het isoleren en optimaliseren van problematische brokjes code bijna belachelijk eenvoudig, je hoeft je niet eens te verdiepen in hoe je in C of een andere taal een module die Python kan importeren voor elkaar krijgt, in plaats daarvan tweak je Python-code stapje voor stapje om naar Cython-code met hulp van de aanwijzingen die de tool geeft en zie je de uitvoeringssnelheid met sprongen vooruit gaan. Shared libraries/DLLs zijn trouwens ook vanuit Python te gebruiken, daar kan dus ook het nodige mee.

Een veel gehoord punt van kritiek qua performance is de "global interpreter lock" of GIL die in CPython (de reference implementation) de snelheidswinst van threading grotendeels om zeep helpt. Dat is nooit verholpen omdat a) de Python-runtime dramatisch veel complexer zou worden daarvan; b) single threaded Python bij elke poging daartoe veel trager bleek te worden, wat natuurlijk niet acceptabel is; en c) het probleem te omzeilen is door de verwerking niet over meerdere threads maar meerdere processen te verdelen. Dan ontbreekt de mogelijkheid van werken met gedeelde data-items, én de ellende van race conditions die dat op kan leveren, maar met queue-mechanismes kunnen verwerkingspijplijnen worden opgezet (een basale is ingebouwd in de standard library, voor meer veeleisende situaties vind ik ZeroMQ een aanrader — en niet alleen voor Python). Ik heb bewerkingen op numpy-tabellen (in de beeldverwerkende software die ik noemde) geparallelliseerd door ze memory mapped files als basis te geven (Python en numpy ondersteunen dat), en die kunnen tussen processen gedeeld worden waardoor meerdere processen elk hun "tegeltje" van de afbeelding kunnen verwerken zonder dat immense hoeveelheden data tussen processen heen en weer gepompt hoeven te worden. Dan ben je met volwassen programmeertechnieken bezig, Haddock, en Python is zo volwassen dat die prima ondersteund worden.

Goed, smaken verschillen, maar ik ben (zoals ik zelf aan de lengte van mijn reactie kan zien) meer dan een beetje enthousiast geworden van Python. Dat je argument over uitvoeringssnelheid en energieverbruik mist hoe gelokaliseerd problemen daarmee zijn, hoeveel meer dan alleen de snelheid van de programmeertaal daar een rol in speelt en dat daar oplossingen voor bestaan heb ik denk ik wel genoegzaam onderbouwd.

Hoe meer het wordt gebruikt hoe meer processorcapaciteit er (onnodig) wordt verspild. Toch?


Warrig en irrelevant. Meer kan ik er niet van zeggen.


Dat er meer zaken slecht zijn voor het milieu doet er niets aan af dat dit ook slecht is voor het milieu. Een non-argument dus.

En dan kunnen we nu een blik C++-aanhangers opentrekken die Java geen echte programmeertaal vinden. Doet me denken aan iemand die ik ooit meemaakte die zichzelf er helemaal van overtuigd had dat assembler de hoogste programmeertaal is, want er is niets wat je daar niet mee kan, alle code die op een CPU uitgevoerd kan worden kan in assembler geschreven worden. Objectoriëntatie? Hij paste dat in assembler toe (en dat deed hij echt). Op een bepaalde manier is er geen speld tussen te krijgen, maar toch klopt er iets niet.

Haddock vs Karma4

Denk dat jullie 2 even in een cafeetje moeten afspreken, potje armpje drukken of zo.
Het autistich op elkaar reageren loopt me een beetje de neus uit.

Wie of wat is karma4?


Het is geen fanboykwestie. Kijk zelf maar naar de feiten:

https://www.tiobe.com/tiobe-index/

Als die index bepaalt hoe "echt" een programmeertaal is dan zou je tot je kunnen laten doordringen hoe dicht Python daar bij C++ staat. En ik heb op fora vaak genoeg reacties van mensen gelezen die werkelijk C++ wel en Java niet serieus nemen.

kotlin

Als autist vind ik dit een misplaatste opmerking. Iets langer nadenken voor je post zou je sieren.

Persoon die de zelfde oogkleppen op heeft als een kapitein haddock.
Beide staan te ver van de normale werkelijkheid af, dat ze heilig in hun eigen waarheid geloven.

Welke feiten? Is een overzicht. Maar je opmerkingen passen wel mooi bij mijn vorige opmerkingen.

Hier is TS

Bedankt voor alle adviezen en ik ga er mee aan de slag. Ik ben nu wel overtuigd van Python als een handige taal om allerlei zaken te linken (databases, shell operaties, web, eventueel later IoT/ domotica). Een goede middenweg en makkelijk te leren, een goede aanvulling op mijn verouderde bestaande kennis. Mijn geld ga ik dus niet met programmeren verdienen want daar zijn twintigers met veel enthousiasme in de eigen vrije tijd buiten werktijd (dus meer ervaring) beter in. Over die carriereswitch moet ik nog nadenken, maar Python ga ik wel leren. Dat wordt dan v3 mocht ik ooit wat gaan doen met ML en datasets (wat ik nu doe in Excel) :)

De andere talen zoals assembly dat hou ik maar aan voor hobby voor als ik heel veel tijd over heb op een winterdag. Dat is voor mij ook meer een nostalgisch iets.

De bevestiging voor Python heb ik in ieder geval gevonden dankzij jullie bijdragen. Ik zat al langer te denken om shell scripts met PHP over te zetten in 1 uniforme taal maar kon nooit kiezen tussen Perl, Python, Ruby. Vroeger was Perl namelijk "je van het" met die afschuwelijk CGI scripts voor Apache. Jullie hebben het voor mij makkelijker gemaakt :-) Dank aan iedereen.

O ja en ik zie dat Python ook gebruikt kan worden voor Android Apps, iets waar ik zelf nog wat ideetjes voor heb.

https://stackoverflow.com/questions/49955489/android-app-completely-in-python

Dat is handig want met Java heb ik niets. Devs zeggen dat Java geen echte programmeertaal is en velen hebben het steeds over de security issues ten opzichte van bijv C++ maar dit is gewoon keur. Als die specialistische fanboys van C++ zich massaal op Java hadden gestort hadden ze daar veiligere applicaties ontwikkeld want met C++ kun je ook onveilig code kloppen als je niet goed oplet. Dat argument van "Java is onveilig" houdt dus geen steek en is volgens mij gewoon een stuk marktwerking van een grote groep ervaren coders die voor C++ hebben gekozen en dat de hemel in prijzen. Over performance valt natuurlijk te praten ten op zichte van Java en over interoperability weer ten op zichte van C++. Python is ook niet de snelste maar stukjes code in Cython voor optimalisaties of bovenstaande voor portability naar Android systemen maakt het een heel goede algemene taal voor allerlei omgevingen.

Ah, https://beeware.org/. In ieder geval open source. Nou ik ben benieuwd naar je ervaringen hiermee.

Nee, het is wat het is. Aangezien ik hier jou niet mee bedoel hoef je je niet aangesproken te voelen.
Ik weet wat autisme is (direct mee te maken) en beter kon ik het niet uitdrukken.

Geruchten over de onveiligheid van Java vinden hun oorsprong in de problemen met Java applets (Java in de browser). Maar dat wordt niet meer ondersteund, dus maak je geen zorgen.

Java heeft z'n toepassingsgebied en dat is best groot. Als je systeemsoftware programmeert dan zou ik i.p.v. de C/C++ route eens naar Rust kijken. Dat is voor die toepassing een zeer veelbelovende programmeertaal.

Wederom laat je overduidelijk blijken dat je geen flauw benul hebt wat autisme is.
Ik hoef me niet aangesproken te voelen, maar doe het wel. Drammen is iets heel anders dan autistisch reageren.

Er zal tal van andere woordkeuzes om je ergernis te laten blijken in plaats van autisme hiervoor misbruiken.

Gewoon niets van aantrekken, beste EnGee. Als niet-autist ben ik weet niet al hoeveel keer als "autist" uitgemaakt, door mensen die helaas niet beter weten. Daar zaten helaas ook zogenaamd "hoogopgeleiden" onder. Wat die lieden met elkaar gemeen hadden, is dat ze weinig afwisten van de natuurwetenschappen en vaak nog minder van computers. Van het soort die ooit met "zesjes" en "met de hakken over de sloot" hun middelbare school of studie haalden.

Ze voelen zich gewoon geïntimideerd door sociaalbewogen mensen die, beroepshalve of gewoon uit interesse, wel veel van de natuurwetenschappen en computers af weten. Ze denken oppervlakkig in stereotypen. In plaats van dan hard aan hun eigen schromelijke gebrek aan inzicht te gaan werken, trachten ze anderen te kleineren. Het is dat ik ze erg kleinzielig en onbeholpen vind, anders zou ik ze nog hardop gaan uitlachen :-)))

Saai brood-op-de-plank werk. Een soortement van modern cobol.

Eh, nee. Redenen laat ik aan de oplettende lezertjes als huiswerk.

Dat is een andere manier om te zeggen dat je totaal geen benul hebt van waarom Rust niet een veelbelovend alternatief voor C/C++ zou zijn.

Dat is het niet. Kun jij wel vertellen waarom jouw claim wel waar zou zijn?

Rust roest? ;-)

Maar serieus, Rust lijkt inderdaad grote voordelen te hebben (qua security): https://youtu.be/HgtRAbE1nBM

uitstekend verwoord. Zoals mijn programmeer docent ooit zei. Programmeren is zelden het leren van een taal; maar meer een denkwijze. Als je de denkwijze beheerst.. kies er dan gewoon een taaltje bij. De denkwijze van loops, voorwaardes, scenarios, en objecten en classes.

Eminus

Dan beperkt je blikveld zich kennelijk al tot talen die objecten en classes en loops ondersteunen.

Verdiep je eens, al is het maar een paar weken, in een functionele taal, bijvoorbeeld Haskell. Dan ontdek je dat de denkwijze die je beheerst helemaal niet zomaar op elk taaltje past. En als je niet te snel afhaakt is de kans groot dat je ontdekt dat je op een andere manier leert kijken naar de talen waar je al vaardig in bent en beseft dat die op andere, soms betere manieren waar je nooit eerder bij stil had gestaan gebruikt kunnen worden.

Oké maar dan moet je je niet beperken tot bovenstaande voorbeelden. Want je laat de hele functioneel programmeren tak weg (geen loops; geen classes; etc.).

Even een klein stukje JavaScript code dat draait op een pagina van AD.nl.
Maar wie haalt de kleine foutjes eruit, uit de code, zoals deze hier in:
https://config-prod.choice.faktor.io/ec4dd53f-5731-40af-909f-c609b1960e3b/faktor.js
snippet:
eind snippet...

Met een ontbrekende punt-komma plaatsen erachter, dus } ; op lijn 7 -
Wie haalt het eruit? En de stukjes elders, die beter in dot notatie worden ingegeven.

Daarna even kijken hoe of ie laadt op https://gtmetrix.com/reports/

luntrus

Dat is het wél! Kun jij wel vertellen waarom jouw claim dat mijn claim niet waar zou zijn wel waar zou zijn?

Werken als developer bijvoorbeeld voor de bekende ISP-tracking orgels,
want dat zijn providers wel zo ongeveer met zoals in onderhavig geval 50 derde partij trackers,
waarvan er 44 notoire trackers zijn.
43 cookies met daaronder cookies van 18 bekende trackers,
Web en mailservers hebben niet dezelfde locaties.
Geen CSP header gezet en nog enige header settings niet ingesteld.

En dan vinden we het nog verbazend,
dat de beveiligingsituatie steeds verder precair wordt.

Zie voor jezelf hier: https://privacyscore.org/site/134082/

luntrus

Trol. Je plaatst je buiten de discussie door hooghartig dergelijk uitspraken te doen.

Over C: in die taal is het directe aanspreken van geheugen nogal een hobbel voor beginners. Als je met adressen, pointers en arrays van pointers kan werken en allocaties kan doen op de juiste manier met de juiste geheugen types, dan ben je een eind op weg te begrijpen hoe het werkt. Ook een functie als memset wordt vaak niet begrepen, soms gaat het alleen per toeval goed.

C++ is daarin anders: het automatiseert een aantal geheugenoperaties. En het werkt iets anders met objecten, maar dat is niet echt wereldschokkend. Ken je wel C++ en geen C, dan heb je een probleem als je aan C programma's moet werken.

Rust ontlast programmeurs nog meer. Maar als je hiermee begint mis je wel wat inzicht in veilig programmeren.

Welles, nietes. Zouden jullie in plaats van de ander te vragen zijn/haar standpunt te onderbouwen je eigen argumenten kunnen presenteren? Of als je daar geen zin in hebt er gewoon over ophouden?

Jazeker maar het wordt wel steeds meer een ding, het energiezuinig software maken: "Fight the global warming: compile your C# apps ahead of time" - Michal Strehovský, May 2 -
https://medium.com/@MStrehovsky/fight-the-global-warming-compile-your-c-apps-ahead-of-time-9997e953645b

Wel een vaardigheid die je moet hebben als je op "systeemniveau" wil knutselen.

Dat kan het, maar het doet het niet automatisch. Net als in C ruimt het dingen van de stack op die "out of scope" gaan, met dien verstande dat C++ toestaat dan ook user code uit te voeren via objectdestructors. En daarop voortbouwend kun je zelfs een Garbage Collector inbouwen. Daar zijn dan weer programmabibliotheken voor, hoewel die nooit echt breed aangeslagen zijn. Wat betreft geheugentoegang, dezelfde truuk met gebruikerscode in een accessor-operator-definitie op je objectklasse die range checks e.d. kan uitvoeren. Je krijgt daarmee mogelijkheden zelf code te schrijven die aangeroepen wordt door code die er net zo uitziet als ingebouwde code.

Dat kan in C niet, hoewel je heel goed je eigen accessor-functies kan schrijven. Die zien er dan net even anders uit.

De eerste pijler van "objectgeorienteerd programmeren" is encapsulatie: In plaats van (zoals in klassiek C) tussen verschillende delen van je (grote) programma te communiceren via structures, doe je het nu via classes, of liever, via de accessors van die classes. Dat wil zeggen dat de interface nu "code" is in plaats van "data". Code die invarianten kan opzetten en bijhouden, en die vlak bij de data-definitie wordt opgeslagen zodat je minder makkelijk wijzigingen in hoe de klasse met data omgaat over het hoofd ziet in een van de vele stukjes code die aan de data in je structure rommelen.

Verder is C++ vooral een overlay op C (de eerste C++-compiler, cfront, was dan ook een "voorzetsel" voor C), dus je kan alle fouten maken die je in C ook kan maken. Als je dan "C/C++" probeert te schrijven zonder de vaardigheden die je in C nodig hebt is dat vragen om problemen. "C/C++" zeggen is wat mij betreft dan ook een indicator van onkunde: Of schrijf C, of schrijf C++, maar haal de twee niet doorelkaar. Ondanks dat ze wel sterk gerelateerd zijn, en dat je voor C++ dus ook (genoeg) C moet kennen (om niet jezelf in je vingers te snijden).

rust is tegelijk een hype en heeft een community met een "Code of Conduct" die regelmatig elders als giftig wordt gezien. En oh ja, een Rust Evangelism Strike Force die graag "herschrijf het programma in rust!" als universele oplossing aandraagt.

Maar daar ging het niet eens om. De claim was dat het goed was als systeemprogrammeertaal. En dan komen er toch ineens wat andere eisen om de hoek kijken. Bootstrapping bijvoorbeeld. En dat is (op z'n zachtst gezegd) Heel Veel Werk voor rust. Tot op het punt dat je beter af bent met iets als C om je systeem in te schrijven.

Rust heeft duidelijke voordelen en je hoeft niet meteen je hele systeem in Rust te gaan schrijven.

Persoonlijk denk ik dat met de komst van A.I. en het beter ervan worden, bepaalde jobs in de nabije toekomst gaan vervallen en daaronder is programmeur er een van.
A.I. kan straks veel beter programmeren dan wij mensen en foutloos omdat het veel beter en dieper kan testen.

Een ander iets is, je kan wel een programmeer taal willen leren maar als je geen visie hebt wat je gaat maken, anders dan het leren van een taal, je er niet echt iets mee op schiet.
Het is een probleem waar ik vaker aankomende programmeurs heb over horen klagen, boeken lezen en leren programmeren kan iedereen, het uitvoeren en doorgroeien in programmeren is een heel stuk moeilijker omdat visie/motivatie ontbreekt om jezelf verder te pushen in de programmeertaal ontwikkeling.

Als je wilt leren programmeren en er straks je werk van wilt maken dan zou ik gewoon de statistieken raadplegen die je op Internet vindt als je top-3 programmeertalen Googlet en van daaruit je keuze maken.
Voor elk wat wils.

Mwah, we staan nog aan het prille begin. AI krijgt langzaam aan vorm. Sommige onderdelen zijn iets verder omdat deze sneller en gemakkelijk zijn in te vullen. Wellicht over 15-20 jaar dat het geheel afgekaderd is. Tot die tijd is er nog genoeg te doen.

Voor systeemsoftware is Rust heel goed i.v.m. syntaxflexibiliteit en minder kans op buffer overflows. Het is wel trager in de uitvoering maar hoewel Rust soms gevraagd is verdien je er geen hopen geld mee want iedere C programmeur kan binnen 3 tellen Rust leren, omgekeerd is dat niet het geval.

Ik ben zelf enthousiast van Python maar deed er niet veel mee. Deze thread heeft mij gestimuleerd om een opfriscursus te doen van Python. Gezien de veelzijdigheid van deze scripting taal en de beschikbaarheid van libraries heeft het ook mijn voorkeur.

Het houdt me van de straat en ik doe tenminste iets nuttigs waarin ik mijn creativiteit kwijt kan. Het zal alleen niet zo snel meer gaan met die talen als toen ik 15 jaar was.

Alleen bij naïef (gebruik)... Oftewel onzin.