Zijn er hier eigenlijk programmeurs die zichzelf in elke programmeertaal thuis voelen? Vroeger zelf ooit op school Turbo Pascal geleerd. Toen zelf doorgestroomd naar Delphi. En nu weet ik van diverse talen genoeg zodat ik wat kan programmeren. Pascal, Delphi, C++, javascript, Php, Python... maar hoe meer er bij komt hoe minder ik begrijp waarom ze ontwikkeld worden. Rete irritant zijn die kleine syntax wijzigingen. De ene wilt alles tussen "begin" en "end" hebben, de andere tussen { en }... en bij Python dachten ze dat het handig was om simpelweg te gaan inspringen. Misschien is de ene taal wat makkelijker om wat te programmeren, maar persoonlijk zie ik echt alleen maar nadelen aan deze versnipperingen. Wel/niet niet hoofdletters, wel/niet ";" op het einde van een regel, =, ==, := om iets in toe te wijzen, variabelen wel of niet eerst declareren... man kan eindeloos doorgaan, ik snap niet dat professionele programmeurs niet helemaal krankjorum worden als ze met verschillende talen door elkaar moeten programmeren.

Grappig, ik heb precies hetzelfde. Ik programmeer al 40 jaar en heb ervaring in een erg lang lijstje.
Het is jammer dat er zo'n versnippering is want het zorgt ervoor dat veel energie verloren gaat in de ontwikkeling/leren van een taal en het maken van allerlij libraries en frameworks. Hierdoor wordt er veel te weinig tijd besteed om daadwerkelijk goede software als eindproduct te maken.
Het is mij ook een raadsel dat het "dialect" belangrijker blijkt te zijn dan een goed eindresultaat te produceren.

Wat je gewoon keer op keer ziet, is dat op ten duur de taal de techniek tegenhoud. En daarom zal er altijd evolutie blijven en nieuwe talen komen. Omdat je ook vaak zit met dat je fundamentele zaken bij een bepaalde taal niet kunt aanpassen zonder dat alle code van de vorige versies niet meer werkt.

De wetenschap in de computerindustrie komt zelfs hedendaags met nieuwe inzichten. Staar je niet blind op dat men alleen maar even de syntax verandert omdat het er mooier uit ziet en een taal uitbrengt. Kijk verder onder de motorkap. Waarom zijn dingen zo, zoals ze bedacht zijn. Vaak zijn die heel goed te motiveren.

Daarnaast heb je ook veel talen die een bepaalde niche heel goed kunnen uitoefenen, maar inleveren op bepaalde andere zaken. (Maar die er vaak niet toe doen in die bepaalde niche)

[Reactie gewijzigd door Immutable op 13 november 2020 13:27]

Veel nieuwe talen worden inderdaad ontwikkeld om een nieuwe techniek of een nieuw idee te implementeren. En als het ook maar enigszins handlig (of hip) lijkt wordt het daarna met ducttape en nietjes toegevoegd aan C++ :-D

Je hoeft als programmeur helemaal geen 30 talen te leren om gek te worden, C++ alleen volstaat.

Gekkigheid natuurlijk (hoewel waar). Maar het is idd soms gekmakend, de continue stroom aan veranderingen. Maar ja, part of the job. Ik vind zelf de wildgroei aan appstores/distributiesystemen/'crates' e.d. ook bar onoverzichtelijk. Wil je een nieuwe taal leren dan ben je soms langer bezig met het web aan meta-informatie te doorgronden dan met de eigenlijke programmeertaal.

Door jullie opmerkingen dacht ik aan de recente upload (eind mei dit jaar) van een talk uit 2011 van Uncle Bob die ik afgelopen maand heb gezien over de evolutie van programmeertalen ("The Last Programming Language)".
https://youtu.be/P2yr-3F6PQo?t=326. Quantum hardware werd er nog niet in besproken, ik zou zijn mening er wel over willen weten. Voor het gebruik van een quantumcomputer moet je je dingen aanleren die nu nog niet gewoon zijn.
Als je zoekt op 'how to program quantum computer' kun je ontdekken dat Qiskit een open-source SDK is om met quantum computers te werken; gebaseerd op Python.

Lijkt mij een van de dingen waar Guido zich mee bezig zou kunnen houden.

Er zijn zoveel talen dat vrijwel niemand elke taal überhaupt bij naam kent..

Pascal is een outlier IMO met begin / end / :=
Veel talen gebruiken de C-style syntax. Ik ben ook met TP begonnen maar na de overstap naar C++ heb ik niet meer terug gekeken.

maar hoe meer er bij komt hoe minder ik begrijp waarom ze ontwikkeld worden.

Andere syntax is maar een klein punt en soms wat irritant, maar tussen de meeste talen zitten toch fundamentele verschillen.

[Reactie gewijzigd door Olaf van der Spek op 12 november 2020 20:07]

Pascal is geen outlier omdat bijvoorbeeld Cobol ook begin en end gebruikt en dat was een tijdlang de meest gebruikte programmeertaal ter wereld.
Dergelijke sterk gestructureerde en meer verbose 3G talen zijn erg leesbaar en waren daarom relatief makkelijk te interpreteren en blijven daardoor langdurig goed onderhoudbaar.
Cobol code van 30-40 jaar oud wordt nog veelvuldig gebruikt en onderhouden.

Visual Basic doet ook begin / end. Superirritant, hoewel wel beter te begrijpen door leken.

Als hardcore python man moest ik afgelopen maand een Excel VB project fixen. Man wat mis je simpele dingen. Uiteindelijk gelukt, maar echt hoofdpijn. Andere dingen zijn daarentegen weer briljant geregeld in vb

Noem eens iets.

Ik ken alleen VBA heb alleen ooit eens een uitstapje C# gedaan.. Ben geen IT'er, maar doe veel lichte automatiserings taken bij ons op kantoor.

excel VB = VBA, net iets anders dan echt VB

Dat weet ik... al hebben ze wel een gemeenschappelijke basis

Ik ben als kind begonnen met mezelf Small Basic te leren. De begin/end syntax was zo duidelijk dat ik het in no time door had. De overstap naar VB.NET was daarna eenvoudig gemaakt, wat op zijn beurt weer leek op C#.

Als VB niet zo'n weinig gebruikte taal was, zou het een fantastische eerste taal zijn voor beginners.

Ik heb nu onder tussen aan projecten met C, C++, C#, JavaScript, Python, Java, ActionScript en Kotlin gewerkt. En Python is verre weg van een leesbaar, wat hun initiële setup was.

Java en C# zijn goed voor enterprise.
Kotlin is de Java/C# voor de nieuwe generatie.
C++/C voor games en algoritmes.
Alle andere zijn redundant.

C# heeft ook een belangrijke niche in games, het zou altijd de eerste keus moeten zijn voor de meeste code in moddable games. Alleen de baas even niet vertellen dat je de game bijna open source uitbrengt.

[Reactie gewijzigd door Pinkys Brain op 13 november 2020 00:51]

Inderdaad, ben ook grote fan van c#/.net. Zeker de net gereleased versie 5, waarmee je met 1 taal, c#, alles kan ontwikkelen, van multi-platform desktop apps tot Android en iOS apps, tot games voor Xbox en Playstation,...
En je hoeft voor websites idd geen JS te gebruiken, je kan met blazor alles gewoon in c# blijven doen maar als je echt wil kan JS nog wel.
Nieuwste versie is ook super geoptimaliseerd, met 1 vd snelste webservers en -code, compilen naar single file,...
Heb in't verleden nog met TFM(bancaire niche-taal), VB, Delphi, JS en vooral Java ontwikkeld, maar voel me de laatste 7-8 jaar toch beter in het .net-ecosysteem dan elders.
Wel denk ik dat relatieve nieuwelingen zoals Dart en Rust ook wel de moeite waard zijn.

Hoe minder ik in JS moet ontwikkelen, hoe blijer ik er van word! Vind ik écht een DRAAK ve taal en ik moet het praktisch dagelijks doen!

Ghoh, ik heb een tijdje met numpy gewerkt en daarbij regelmatig de source code in zitten duiken om te zien of iets in-memory gebeurde of een kopie aanmaakte. Voor een wiskundig package vond ik dat net heel leesbaar. Het ligt er volgens mij meer aan door wie het geschreven is.

Het grote probleem van Python vind ik dat er zo veel packages worden gemaakt die hetzelfde doen op een net iets andere manier dat je door de bomen het bos niet meer ziet. Als je dan ergens op een forum o.i.d. een vraag stelt hoe iets op te lossen is het vrijwel altijd 'oh ja, gebruik gewoon deze library' zonder ook maar enige redenering en de documentatie is vrijwel altijd super brak.

Plus ik krijg bij Python intuïtief heel moeilijk een idee of iets efficiënt is geïmplementeerd.

Wat jij hier benoemt is naar mijn idee niet zozeer een Python probleem maar meer een algemeen modern-programmeren probleem.

Ik werk zelf niet met Python maar zie wat jij benoemt eigenlijk overal wel. Het is gewoon een hele (naar mijn mening) slechte trend waarin programmeurs z.s.m. "efficiënt" worden gemaakt door in kant-en-klare frameworks gedumpt te worden vanaf het begin van hun studie.

Gevolg is dat zij niet zozeer "een taal" leren, maar "een framework". Wanneer framework/library dan niet doet wat ze willen of weer niet meer te trend is, zijn er problemen. Steeds meer vacatures vragen ook niet meer om kennis van een taal, maar eerder kennis van een framework. In mijn ogen zijn een aardig deel van deze mensen ook geen programmeurs meer te noemen, want ze zouden niet eens weten hoe ze een basic for loop, sort of date formatting nog moeten doen zonder zo'n library of framework. Ik heb het enorm veel in actie gezien als lead-developer. Treurig is het... 5 lagen extra software bovenop elkaar en dan nog eens 5 lagen software om die vorige 5 lagen sneller te laten werken. 15 miljoen regels code om "hello world" te printen.

Python word dan ook nog heel vaak gebruikt voor data science toepassingen / wetenschappelijk programmeren waar de meeste 'developers' geen computer science achtergrond hebben (maar bv. wiskunde, statistiek, informatiekunde). Dat is ook niet echt bevorderlijk voor het niveau van het gemiddelde stukje python code. En neem daarbij dan nog dat python zo'n beetje alles wel goed vind niet zo moeilijk doet over types enzo.

[Reactie gewijzigd door RagingPenguin op 13 november 2020 14:08]

En toch zie je dat probleem niet bij bijv. matlab (als je daar van een taal kan spreken). Als je het mij vraagt heeft matlab de meest duidelijke en precieze documentatie. Je weet precies waar je van op aan kan en wanneer je het wel of niet moet gebruiken.

Bijna bij elke documentatie van python beginnen ze direct met een 'voorbeeld' zonder überhaupt uit te leggen waar ieder argument voor staat. Laat staan welke overloads er zijn, die worden in het volgende 'voorbeeld' gezet. Dat is toch een heel ander verhaal bij matlab/c++/c# omdat daar veel meer organisatie in zit.

Overigens wordt Python zeker niet voor het overgrote deel voor wetenschappelijke doeleinden gebruikt. Eigenlijk in ieder veld waar niemand zich echt bekommert om efficiëntie.

Om maar te zwijgen over de wildgroei aan de dagelijks bijkomende JS libs/frameworks, elks bewerende hoeveel beter ze zijn! Dan vind ik Python hierin best wel meevallen...

De originele bedenker van het Django framework is ermee gestopt omdat het de verkeerde kant op ging. Dat zegt genoeg, toch? (Naar mijn ervaring programmeert bijna iedere python dev welke ik tegenkom in Django)

Goh, hangt er vanaf hoe je het bekijkt. Go en Rust lossen heel wat problemen op met C en C++ terwijl je nog altijd naar pure machine-code compileert. Go is heel sterk in de infrastructure-space voor het moment (Kubernetes, TerraForm, ...), en ook voor game-development wordt er tegenwoordig al naar Rust gekeken omdat het veel fouten voorkomt die makkelijk te maken zijn in C en C++.

Voor simpele scripts die cross-platform moeten draaien, gebruik ik Python. Voor het complexere werk gebruik ik Go die mij een single binary oplevert die ik kan gemakkelijk kan shippen zonder afhankelijk te zijn van een virtual machine (Java, .NET) en bijhorende versie-hel. Ik vind deze beide use-cases te verantwoorden, en zeker niet redundant.

Misschien is Go or Rust wel 'handig', maar voor grote project, vooral met deze markt, waarbij er geen developers gevonden kunnen worden, wil je senior developers inzetten. Dat zie ik ik niet echt gebeuren voor miljoenen projecten.

BTW, met redundant bedoel ik, voor professioneel gebruik.

Rust is juist bij uitstek geschikt voor grote projecten, omdat het allerlei moeilijk te debuggen geheugenproblemen voorkomt.
Mozilla gebruikt het bijvoorbeeld voor de ontwikkeling van hun Firefox engine.

Alle andere zijn redundant? Hoe ga je dan een web app bouwen? Dat kan alleen met gebruik van JavaScript (helaas), dat is immers de enige taal die in de browser draait (afgezonderd van het niche WebAssembly).

Hoe ga je dan een web app bouwen? Dat kan alleen met gebruik van JavaScript (helaas)

Ho eens even! Mag ik je voorstellen aan https://dart.dev/? Oke, het transpiled dan o.a. wel bijv. naar JS om in de browser te draaien, maar je hoeft niet perse in JavaScript te werken om een web app te bouwen!

[Reactie gewijzigd door nalufrank op 12 november 2020 22:38]

Ik heb ervaring met Dart en het is niet beter dan JS

Wasm is geen niche meer. En het is geen taal maar bytecode die gegenereerd kan worden vanuit een hele bende talen, zoals Go, Rust, C#, Python et cetera.

ASP.NET en C# (het eerste is een framework voor het tweede) draaien niet frontend (in de browser). JavaScript is zo gigantisch populair omdat het de enige taal is die in de browser draait, ASP.NET/C# draaien op de server.

.NET en C# draaien inderdaad veelal op de server, maar met Blazor (https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor) kun je C# (en het .NET) ecosysteem gewoon in de frontend draaien middels het 'niche Webassembly'.

Maar zolang Internet Explorer nog een ding is is dat nog vooral een niche...

Who cares about IE? :-)
Bedrijven moeten niet teren op technologie dat al zo oud is. IE11 is al v 2013.
Als je WebApps ontwikkelt, moet je browser nu eenmaal ook meegaan anders hadden we nu nog altijd Netscape Navigator FCOL

Als je WebApps ontwikkelt, moet je browser nu eenmaal ook meegaan anders hadden we nu nog altijd Netscape Navigator FCOL

Welke browsers er gebruikt worden bepalen we helaas als developers niet. En zeker binnen 'enterprise' omgevingen met managed windows installaties is IE11 nog gewoon de standaard (en mag je al blij zijn als het niet in een of andere compatibiliteitsmodus draait en stiekem een nog oudere versie is).

Nee, weet ik, maar ik ben al blij dat we onze tests binnen het bedrijf mogen baseren op 'moderne' browsers.
Ik vind het nog altijd beter dat we sporadisch een IE11 fix moeten toepassen dan heel de tijd hierop te moeten fixeren.

Inmiddels kan je C# (.Net) in de browser draaien. Check https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

Een taal is slechts een tool.

Een populaire taal heeft meer developers, daardoor heb je meer beginners en meer slechte code.

Reken maar dat er ook genoeg "noobs" zijn die heerlijke spaghetti code in asp en c# produceren!

Rust lost een aantal problemen op, die misschien niet per direct voor enterprise interessant zijn. Maar op termijn wel kunnen worden. Dan komen er ook vanzelf meer senior developers, en groeit een taal.

Goede reden om voor Rust te gaan is bijv high performance servers, geheugenbeheer.

Je hebt een hele serie imperatieve programmeertalen geleerd. Dat is allemaal meer van hetzelfde en inderdaad niet echt interessant. Probeer eens Lisp of prolog, dan merk je dat er ook andere wijzen van programmeren zijn.

@satoer @latka Laatst was Racket (ook een Lisp variant) hier nog in het nieuws, dat heeft wel wat leuke grafische voorbeeldjes om te proberen. Zelf vind ik de veiligheidsgarantie van Rust (meer C/C++ alternatief) wel erg vernieuwend.

[Reactie gewijzigd door scholtnp op 12 november 2020 21:20]

Racket (scheme/lisp) vind ik interessant sinds ik als jongetje in de jaren tachtig het een en ander over lisp en “lisp machines” had gelezen, daarom submit ik de racket-updates graag voor de meuktracker. Maar ik kan er zelf niet veel van, wel eens land of lisp en realm of racket wat doorgewerkt, maar goed... ik kan sowieso geen enkele programmeertaal echt goed, ik heb wat basiskennis van allerlei talen.

R is vermoedelijk de voor mij op korte termijn zinvolste taal om echt serieuzer te leren, en Python (om een beetje on topic te komen) eigenlijk ook. Rust vind ik ook interessant om wat serieuzer te leren. Maar ik moet zeggen dat Julia momenteel eigenlijk het hoogst op mijn lijst staat...

Wel leuk trouwens dat bijvoorbeeld Fortran nog in allerlei R-libraries verwerkt zit, net als Lisp een van de bejaardste talen, maar nog steeds in gebruik, en al decennia ook nog (een beetje) in ontwikkeling.

Lekker ik spreek dialect: AutoLISP, ongeveer de enige op de wereld volgens mij die <30 ishaha. Maar het is anders maar kan het niet efficient noemen.

Ik voel me bij geen enkele klassieke programmeertaal thuis het is zoals een Delftse hoogleraar ooit aangaf "je hoofd volstoppen met vergankelijk feitenmateriaal".
Toch wel Assembler, C , matlab en python geleerd want je moet wat maar ik voel meer voor Labview, simulink en GNUradio achtige ontwikkelomgevingen. Daar kun je veel creatiever zijn dan domweg simpele dingetjes coderen, in een technische omgeving kom je daar gelukkig wel mee weg.

De ondoorzichtigheid en onnodige complexiteit van OO programmeren heb ik trouwens nooit begrepen, wat voor masochist moet je zijn om bijvoorbeeld in C++ te programmeren.
Bedoeld als grap maar wat een waarheid https://www-users.cs.york.ac.uk/susan/joke/cpp.htm

Bedoeld als grap maar wat een waarheid

Hij is inderdaad heel herkenbaar; zo praat ik ook altijd over dingen die ik niet begrijp

Die complexiteit in C++ is zeker niet onnodig. C++ heeft gewoon de beste performance van alle programmeertalen. Rust komt daar aardig bij in de buurt, maar is ook gewoon complex.

Voorbeeld is het doorgeven van parameters, in C++ kun je parameters doorgeven: by-value, by-reference en dan ook nog als lvalue reference of als rvalue reference. Dat is complex, maar zeker wel nodig als je echt het maximale performance wil halen.

Andere programmeertalen doen dat niet, die maken een keuze. Dat maakt het eenvoudiger, maar die keuze is gewoon suboptimaal in bepaalde gevallen.

Daarnaast is C++ al 30 jaar oud, en is gebaseerd op C, wat nog wel veel ouder is. De legacy maakt het complex. Dan kun je zeggen: we halen de legacy er uit (bijvoorbeeld pointers), maar dan compileert oude code dus niet meer. Dat klinkt heel leuk, en maakt het allemaal wat simpeler, maar in een productie omgeving is dat natuurlijk een compleet onacceptabele oplossing.

Rust is een taal die bijvoorbeeld niet die legacy heeft, maar wel de focus dat er geen concessies gemaakt mogen worden voor performance. De taal is dan iets eenvoudiger, maar denk dat veel ontwikkelaars nogsteeds Rust zullen typeren als te complex.

Als je ook verdiept in C++ zul je zien dat het eigenlijk een combinatie is van verschillende programmeertalen. In embedded wereld wordt vaak C with classes gebruikt, voor server/desktop kun je toch een vrij eenvoudige OOP subset gebruiken, en als je herbruikbare libraries ontwikkelt (bijvoorbeeld STL), komt er een taal die generiek programmeren en de laatste set van optimalisaties van geheugenbeheer gaat gebruiken. Je hoeft niet de volledige taal te begrijpen om productief te zijn.

[Reactie gewijzigd door wkleunen op 13 november 2020 13:29]

Het grote verschil tussen C++ en andere populaire OOP talen (Java, C# etc.) is vooral dat C++ geen GC heeft en de rest wel. Dat je niet zelf je memory hoeft te managen en heap entries vanzelf worden opgeruimd maakt alles voor jou als developer veel makkelijker, maar het heeft wel overhead. Je zou ook nooit pointers uit C++ kunnen halen aangezien je al die dingen nodigt hebt om het geheugen te managen.

Dat is niet het enige grote verschil. Naast dat C++ geen garbage collector heeft, is het geheugenbeheer ook veel explicieter. Je kunt geheugen alloceren: globaal, op de stack of op de heap. Het is dus niet alleen dat C++ een GC heeft, maar je hebt ook controle over waar je dingen alloceert. Je kunt bijvoorbeeld een vector aanmaken als:

std::vector< Item * >
of als:
std::vector < Item >
of:
item items[10];

Voor cache coherence is dat gewoon belangrijk, en een echt significant verschil in performance met andere programmeertalen. Met java staan gewoon al je objecten gefragmenteerd op de heap, wat ook nog eens een shared resource is tussen threads.

Je kunt ook geheugen beheren met references. Enige verschil is dat een pointer ook null kan zijn, maar daarvoor zou je een optional reference kunnen gebruiken. Bovendien ondersteunt een reference geen arithmetic, wat een veel verstandiger idee is.

[Reactie gewijzigd door wkleunen op 13 november 2020 15:59]

Groot verschil is OO vs Functioneel. Het hele idee dat je werkt met data en dat transformeert dmv functies ipv objecten in OO.

Alle talen die hij opnoemt ondersteunen OO, behalve Turbo Pascal (en JS half).

Waarom zou JS OO maar half ondersteunen?

Opervlakkig is het wel OO (Es6+) , Maar JS blijft in de basis protyping. Je maakt geen instanties van classes, maar je erft over uit prototypes. Hoewel het dicht bij elkaar zit, is het zowel technisch als semantisch anders. Een wijziging in een class ebt niet door in reeds geïnstantieerde objecten, bij prototypes gebeurt dat wel.

JS is onder de motorkap (en oorspronkelijk) idd prototyping. Maar wordt OO niet gedefinieerd door de interface en niet door de implementatie? Lijkt me sws bijzonder om runtime classes (niet instances) aan te passen.

OO is ook grotendeels implementatie. Omdat je in JS alles inherit en alles ook per referentie inherit is het geen 'pure' OO (whatever that may be ;-))

Objecten die je voed aan een class zijn een referentie naar het object dat je meegeeft. Verander het object IN de class en je veranderd m ook daarbuiten. Kan je omheen werken natuurlijk, maar het zit niet IN de taal. (er zijn niet voor niets een berg libs die immutability mogelijk maken voor je, immutable.js, redux- implementaties etc).

Je bedoelt pass by reference voor objecten? Dat doet Python toch ook en heeft niet zo veel met OO zelf te maken?

ik denk t wel eigenlijk. Je geeft een object mee aan een constructor van een class. Zodat deze er iets mee kan doen. En ge exposed een method op die class die het object veranderd, en roep die aan in een implementatie-> het object veranderd ook buiten de class. Dat verwacht je niet in scrict OO: de class moet zijn grenzen respecteren zeg maar

Wat bedoel je met object meegeven aan de constructor? Gewoon als argument van new? Dus:

const bar = new Bar();
const foo = new Foo(bar);

Dan heeft bar natuurlijk an zich niets met Foo te maken. Foo kan bar muteren maar dan is het ook niet gek dat bar... muteert...

Volgens mij heeft de al dan niet aanwezigheid van pass by reference weinig met OO te maken?

ligt eraan. Schrijf het eens zo :
const wheels = new WheelSet()
const car = new Car(wheels)
const car2 = new Car(wheels)

en car heeft een method setWheelSize()

Nu voel je wel aan dat je wilt dat wheels alleen IN de juiste car muteert. In javascript moet je dat zelf regelen. In veel OO talen krijg je dit cadeau.

Maar goed, het is inderdaad een discussie over WAT OO is, en wat erbij hoort. Gaan we niet uitkomen ;-)

[Reactie gewijzigd door Sicco2 op 13 november 2020 09:51]

Je zet nu dezelfde wielen op meerdere autos. Tja, dat gaat fout.

Volgens mij wil je wielen van het zelfde type op meerdere auto's. Dus.

const car = new Car(WheelSet)
const car2 = new Car(WheelSet)

In Python gebeurt overigens afaik hetzelfde, ondersteund Python OO dus ook maar half?

Dat is standaard referentie types en heeft niks met OOP te maken, maar met het heap-stack model. Er is maar 1 WheelSet instance op de heap en als je die aanpast dan pas je hem aan. Car heeft dan alleen maar een pointer naar die ene instance.

Het zijn juist de functionele talen met geforceerde immutability (zoals Haskell, F# en andere ML talen) waar dan niet kan en Car verplicht word om z'n eigen WheelSet instance bij te houden als die die wilt wijzigen.

Volgens mij haal je hier OOP en FP een beetje door elkaar heen, voor FP word immutability wel als standaard gezien (maar is niet verplicht om een taal functioneel te noemen).

Het ligt natuurlijk aan je definitie, maar ik snap wel waar het vandaan komt.
Een voorbeeld van waarom het het maar half ondersteunt (ondersteunt is eigenlijk gewoon niet de goede term hier), is bijvoorbeeld dat de waarde van 'this' binnen een object method wanneer deze van buitenaf wordt aangeroepen null is (tenzij 'this' gebind wordt op het object wanneer het object geïnstantieerd wordt).

This is op zich toch niet zo moeilijk te begrijpen? Het wijst naar het aanroepende object en niet per se een class instance.

[Reactie gewijzigd door Ed Vertijsment op 12 november 2020 21:40]

Het ging me er meer om dat het basis idee achter de taal anders is. Niet een andere syntax voor hetzelfde idee.

Wat ik nog heel erg bijzonder vind, is hoe emotioneel en persoonlijk mensen reageren wanneer je bepaalde kritiek hebt op een van die talen. Alsof je het over hun kinderen hebt?

Ik heb ook heel wat talen voorbij zien komen, en ik heb de afgelopen jaren niks baanbrekends gezien.
Sterker nog, ik zie eerder een tegenovergestelde trend, waarbij de logica en voorbij gebrek aan concreetheid in talen mist.

Maar misschien is het wel net als muziek, interieur en kunst.
Op een gegevens moment wil de nieuwe generatie wat nieuws, net zoals wij dat destijds wilden.

Wat ik nog heel erg bijzonder vind, is hoe emotioneel en persoonlijk mensen reageren wanneer je bepaalde kritiek hebt op een van die talen. Alsof je het over hun kinderen hebt?

Wellicht omdat sommigen meer met deze taal bezig zijn dan met hun kinderen? Ook ben je niet zomaar een software developer, je bent een Python, C++ of Java developer.

Voor velen is het ook een keuze en keuzes worden nou eenmaal verdedigt. Je verdedigt de producten die je koopt, de partij waar je op stemt, het bedrijf waar je voor werkt. Het is nou eenmaal moeilijk om toe te geven dat je misschien wel een andere keuze had kunnen maken.

Ik denk dat emotionaliteit ligt aan bepaalde conventies of praktijken die in de ene taal gospel zijn en in de andere taal niet mogelijk. Denk bijvoorbeeld aan encapsulatie in Java vs. Javascript.

Sinds ik hoofdzakelijk in Go ben gaan schrijven, merk ik dat ik me helemaal niet meer zo druk maak om de brakke codestyle in onze Symfony code. Ik betrap me er zelf op af en toe "php is kut" te roepen, waar ik vroeger heel flame wars heb gevoerd. Erg fijn dat dat met een simple "go fmt" gewoon opgelost is.

Alleen yoda statements trekken nog wel het bloed onder m'n nagels vandaan.

Ik ken lang niet alle programmeertalen, of scripttalen. Maar ik merk wel dat als je de basis van alle programmeertalen kent, dat het dan wat makkelijker is om een andere taal te leren.

Twee (script)talen waarmee ik de laatste tijd veel in aanraking ben gekomen: Lua en Lisp. Lua wordt veel gebruikt bij het kunnen modden van Programma's/Games, en Lisp wordt gebruikt in AutoCad.

Lua vind ik 1 van de (script)talen die heerlijk leesbaar is. Hier een stukje voorbeeldcode. (helaas vallen de inspringen weg, ik had gehoopt dat met [code=lua] dit af te vangen was, maar helaas):

for x=1,5 do
local nr = 0

for d=0,9 do
if digits[d][y][x] == 0 then nr = nr + 1 end
end

if nr == 10 then
line = line .. '0'
end

line = line
end

Lua is een High Level language, met Dynamically Typed variables. Wat wel een vervelende combinatie is, is case-insensitive variables gecombineerd met variables die niet hoeven te worden gedefinieerd....

Lisp wordt o.a. gebruikt in Autocad, en ziet er zo uit:

(if (or
(= (cdr (assoc 0 entity)) "TEXT" )
(= (cdr (assoc 0 entity)) "MTEXT" ))
(setq result entityname )
)
)

(if (/= result nil )
(entget result )
nil
)

In Lisp zitten alle commando's tussen ( en ) . Wat ik wel raar vond, en nu snap, is de if-structuur. In het voorbeeld, is de entget doorgestuurd als het true is, en nil als het fout is. Met blocks is hier iets leukers van te maken, maar dat wist ik in het begin nog niet..

En als laatste 'leuke'.. Er zijn een paar extreem esoterische talen die zijn gemaakt om compact te zijn. Browse maar eens rond op deze pagina. Dit zijn Code Golf programming puzzels, zo klein mogelijk geschreven code voor problemen.

[Reactie gewijzigd door Magic Power op 12 november 2020 22:06]

Zo klein mogelijk geschreven code doet, me denken aan de "wedstrijd" welke taal het kleinste programma voor "hello word!" opleverde. Was toen C, een character, een macro call. En vervolgens werd de code op de compiler commandline uitgeschreven Maar ja, dat was het aanroepen van de compiler, niet de code.

Ik ben geen echte programmeur, maar ik los dit zelf op door geen syntax te onthouden. Je gaat door volgens de al eerder ingezette route. Je ziet direct als jouw stuk afwijkt van wat er eerder geschreven is. En de meeste programmeurs zullen langere tijd in een project zitten. Eenmaal ingewerkt in een pakket/library/omgeving is de kans groot dat je de volgende keer grofweg in dezelfde situatie zit. Bij een baanwissel, of overgang naar een andere afdeling/project zal dat even schakelen zijn, maar veel basisconcepten zijn gelijk. Schakelen tussen imperatief, functioneel, object georiënteerd denken vindt ik moeilijker. Dat vereist soms echt een andere instelling.

Ja, maar dat is dus wel jack of all trades, master of none.

Ik heb er voor gekozen mij te specialiseren in een taal, en die kan ik voor alles gebruiken. Ik kan daar naast ook met andere talen overweg natuurlijk, vooral als ze C based syntax hebben, maar liever niet. Ik merk dat ik dan echt moet gaan zoeken naar dingen die ik anders zo uit mijn mouw schud.

Hear, Hear, precies wat ik ook wel eens denk. Zelf zit ik ook nog in de HDL talen VHDL en Verilog. Daar hebben ze ook de klok horen luiden ... VHDL lijkt bijvoorbeeld weer erg op Pascal met begin en end, maar dan toch ook weer niet helemaal. Ook bash, csh etc., allemaal weer net even anders. Tcl ook weer anders. Daar wordt je wel eens moedeloos van.

Het irritantste vind ik eigenlijk nog wel dat je aan de lopende band tussen die twee HDL talen schakelt, vaak ook gewoon in hetzelfde project.

Wat ik zelf chill vind van python is dat libraries zo makkelijk te installeren zijn. Ik heb Java en Python gedaan en hetzelfde stukje Java in Python is 2x zo klein.

Typed languages zijn sneller in runtime maar Python schrijft zo veel sneller en heeft betere debugging.

Ik vermoed dat veel uitvinders van programmeertalen zich qua syntax willen afzetten tegen andere talen gewoon om zich af te zetten, zonder dat ze er echt over hebben nagedacht dat het ook een effectief nut heeft. Want inderdaad zoals je zegt die kleine syntax verschillen maken de taal niet beter dan de andere, het is gewoon een kwestie van conventie. En als het om conventie gaat, is vooral consistentie van belang en niet wat je kiest (idem met formattering van code).

Er is een reden dat Java en C# zo populair zijn als OO programmeertalen na C en C++: onder andere omdat ze massa's syntax hebben overgenomen en hetzelfde gehouden. Uiteraard ook nog andere redenen, maar dat heeft zeker meegespeeld.

Ik denk persoonlijk dat het niet zo zeer is "om zich te onderscheiden" maar meer dat het in de ogen van de creator gewoon logischer/beter is.

Een programmeertaal is veel meer dan de syntax alleen, he. Het gaat ook om het ecosysteem b.v... Beschikbaarheid van frameworks en libraries maar ook ondersteuning van andere systemen in de hele keten (toolchain). De syntax is de basis.

Daarnaast zit "de ontwikkeling" van een taal echt niet in details als begin/end en het gebruik van accolades. Er zijn wel degelijk ook grote verschillen in allerlei functies en begrippen binnen die talen. Mogelijkheden en features die de ene taal wel en de andere taal niet heeft. Denk aan zaken als strong of weak typing, memory management, enz.

Het verschil tussen Python en C# gaat wat verder dan alleen de uiterlijke verschijning

[Reactie gewijzigd door BezurK op 12 november 2020 20:51]

ach alles heeft zo zijn functie denk ik maar, ik programmeer PLC's en daar zijn de IEC-61131 talen als ladder, statement list en structured text de talen die de klok slaan. Alhoewel C/C++ ook langzaam beginnen door te dringen is dit nog zeer incidenteel.

Ik geloof niet dat je echt een 'all-round programmeur' kan zijn. Als ik naar mezelf kijk dan vind ik het aansturen van machines en het knoeien(voor de hobby) aan Arduino's het leukst. Een GUI in elkaar zetten of het maken van graphics of een heel abstract wiskundig programma trekt mij dan weer totaal niet. Daarom kan ik mij heel goed vinden in lage talen. Soms knoei ik zelfs nog wel eens wat in assembly. Maar hoge, abstracte talen, zoals Python of Java trekken mij weer veel minder.

Waarom praat niet iedereen Nederlands? Zou ook echt makkelijk zijn, hoewel interpunctie in elke taal wel een voordeel oplevert, of niet.

Als professionele developer kan ik zeggen dat ik heus niet 3x per dag van programmeertaal wissel. De verschillen in syntax zijn dus meestal geen probleem. Het helpt juist wel om elkaar als developers te begrijpen dat de verschillende talen op conceptueel niveau veel op elkaar lijken.

Ik moest bij het lezen van jouw bericht meteen denken aan de kijk van Uncle Bob op de diversiteit van programmeertalen. Hij beschouwt heel mooi de voors en tegens hiervan.

Ik doe dagelijks wat Python , JavaScript (React enja soms nog jquery), en daar kan al wel eens go ook bijzitten. Maar vroeger was er bijna elke dag wel een mix van Delphi, c#, Python en JavaScript. Mij maakt het niet zoveel uit eigenlijk. Maar ik ken gerust genoeg mensen die maar 1 ding kennen en ook willen doen. Het hangt uiteraard af wat je doet ook natuurlijk

maar hoe meer er bij komt hoe minder ik begrijp waarom ze ontwikkeld worden. Rete irritant zijn die kleine syntax wijzigingen

Toevallig beweert Uncle Bob ongeveer hetzelfde

But what about that new language over there… What’s is called? Um. Gazoo?
Yes, there are new languages every month. Every week. Every day. We have no lack of new languages. The thing about those new languages is that there’s nothing new in any of them. They’re just made up of the pieces of old languages that they cut up and shook in a jar and then dumped out in a game of language Yahtzee.

Zijn conclusie:

Finally, Lisp is functional. And the future is looking very functional to me.

{
ikBenDolOp;
{
curlyBrace;
}
}

Die "wildgroei" is er al zo'n beetje sinds het begin van computers.
En ook de verschillen zijn niet nieuw. Dat inspringen waar naar python verwijst zat bijvoorbeeld ook al in Cobol.
Elke taal heeft zo z'n specialiteit en reden. Het is een beetje als gereedschap. Moet je maar eens opzoeken hoeveel soorten hamers er bestaan. Tientallen.

Ik verbaas mij altijd over de hoeveelheid werk om een stukje software te schrijven. Ik denk dat dit laat zien dat het vak 'software programmeren' nog behoorlijk onvolwassen (jong) is.

Er wordt nog veel geëxperimenteerd met talen en methodieken. Misschien dat hier de komende jaren meer rust in komt. Het invullen van lesprogramma's wordt dan makkelijker, en uiteindelijk ook het invullen van een vacature.

[Reactie gewijzigd door 12345j op 12 november 2020 23:38]

Ik verbaas mij altijd over de hoeveelheid werk om een stukje software te schrijven. Ik denk dat dit laat zien dat het vak 'software programmeren' nog behoorlijk onvolwassen (jong) is.

Zo jong is het al niet meer, er wordt al 70-80 jaar software gemaakt en er zijn al heel wat talen en methodieken uitgevonden.

Ik denk dat er gewoon een bepaalde inherente complexiteit in zit die wij mensen van tevoren makkelijk onderschatten. Als je een programma wilt maken dat goed werkt, dan word je uiteindelijk gedwongen om over allerlei details na te denken en rekening te houden met allerlei combinaties van mogelijke situaties, mogelijke fouten enz.; dat blijft gewoon veel werk, maakt niet uit wat voor programmeertaal je gebruikt.

Ik verwacht niet dat er in de komende jaren ineens iets wordt uitgevonden wat die complexiteit zal oplossen.

Dat er zo veel talen en methodieken zijn uitgevonden is juist het probleem. Want wat voegen die toe? Is een applicatie met identieke functionaliteit nu in de helft van de tijd geschreven als 10 jaar geleden? Absoluut niet naar mijn ervaring.

Als ik kijk wat we 10 jaar geleden moesten programmeren, of vandaag de dag. Ik zie werkelijk niet dat er een efficiëntie slag is gemaakt. Kan het ook anders? Natuurlijk, kijk bijvoorbeeld in de industriële automatisering, daar zie je wel dat systemen veel efficiënter geprogrammeerd en inbedrijfgesteld worden. Applicatie programmeren is in die zin zeer zeker wel 'onvolwassen', je hebt de kneepjes van het vak niet door gekregen vanuit de vorige generatie.

[Reactie gewijzigd door 12345j op 18 november 2020 23:34]

Het is vrij irritant maar uiteindelijk een kleine zorg aangezien de compiler je syntax fouten eruit haalt?

Alleen syntaxfouten, geen denkfouten.
Als bijvoorbeeld de ene taal IF ... THEN BEGIN ... END ELSE BEGIN ... END gebruikt
en een andere taal IF ... THEN ... ELSE ... END en je moet dat met de hand omzetten gaat het al gauw mis als het wat ingewikkelder wordt.

Wat je beschrijft gaat toch over syntax lijkt me? In het eerste geval verwacht de compiler een END voor ELSE en in het tweede geval kan dit net niet? Maar ik ken de eerste taal niet.. De laatste is denk ik pascal?

[Reactie gewijzigd door jorisporis op 13 november 2020 19:42]

Niet elke programmeertaal heeft een compiler! Zelfs een compiler haalt er de runtime fouten niet uit...

Een geschikte editor die de syntax highlight kan ook al wel helpen.

Op zich heeft iedere taal wel wat voor- en nadelen. Maar de keuze voor de syntax is soms wat apart. Soms lijkt het wel een beetje om het anders doen omdat het kan. Ik vind een mooi voorbeeld altijd wel de if/else if constructie(s) elif, elsif, elseif, else if .. deze versies worden in verschillende talen gebruikt en ze doen allemaal precies hetzelfde. Toch een beetje onnodig

Gelukkig hoef je binnen een project meestal maar enkele programmeertalen te gebruiken. Het is natuurlijk ook zo dat veel developers zich toeleggen op een beperkt aantal programmeertalen. Daar voelen ze zich comfortabel bij , of die kwamen op hun pad tijdens werk / hobby projecten.

Het is wel irritant als je binnen een project moet wisselen van taal als die een licht afwijkende syntax hebben van elkaar.

[Reactie gewijzigd door Jantimon op 13 november 2020 01:39]

https://www.youtube.com/watch?v=P2yr-3F6PQo

interesting take on the differences between programming languages

Niet "elke" programmeertaal, nee; ik heb zelf nog nooit iets gedaan met functionele programmeertalen (haskell, F# en co) of Lisp-achtige talen. Maar in mijn huidige baan wissel ik tussen PHP (5.2 ugh), Javascript, Go en Typescript zonder veel problemen. Soms moet ik me even achter de oren krabben omdat het bij de ene `[]string` en de ander `string[]` is, maar verder valt het wel mee.

Dit jaar met Go begonnen, en gezien ik ook veel Java gedaan heb moet je toch een paar OOP zaken afleren. Structs met methods lijken op classes met methods, maar zijn het niet, en interfaces werken ook anders (en moet je anders gebruiken).

[Reactie gewijzigd door YopY op 13 november 2020 09:29]

Klopt, de wildgroei aan talen is effectief niet bij te houden als 'professioneel programmeur'.

En dan zoom jij nog enkel in op syntax-gerelateerde verschillen, maar onder de motorkap is er op semantisch vlak ook nog een bak aan verschillen tussen alle programmeertalen.

Wel of geen garbage collector, performance-optimalisaties die je moet kennen, quirks van talen waarvan je weet dat je ze moet ontwijken, etc etc. En daar bovenop ook nog; tegenwoordig ontkom je er eigenlijk niet aan om een hele sloot aan libraries te includen voor een beetje project. Daar moet je ook van weten welke je wel en niet moet hebben, omdat sommigen je gewoon enkel teleurstellen.

Het is een ambacht, en een schilder weet ook door jaren ervaring welke materialen voor welke klus geschikt zijn. Die kan vast ook timmeren, maar natuurlijk veel minder goed dan een timmerman. En zo kan ik zelf ook schilderen, maar nooit zo goed als een echte vakman.

Wat betreft klussen ben ik een generalist. Een schilder is een specialist. Voor mijn werk specialiseer ik me dan ook liever in een enkele taal/platform.

Jij kijkt alleen naar de Syntax. Ik zelf persoonlijk kijk wat de taal FUNCTIONEEL onder de motorkap allemaal kan. Syntax is maar bijzaak, en aan te leren.

Waarom kijken veel programmeurs alleen maar naar syntax? Who cares.

I wouldn't care for 'Syntax', maar 't is juist dóór die 'Syntax' dat er véél misgaat. Hoeveel quirks zijn er wel niet in javascript? De 'Syntax' geeft niet aan hoe je er 'onder de motorkap' ermee moet werken!

Daar heb je wel weer gelijk in.

Kom met een pre-parser!
Die de code pre-parsed en dan aan de gewenste programmeertaal geeft.
Dan kan je elke taal gewoon schrijven met { }, hoef je voor python niet meer om je inspringing te denken, etc

[Reactie gewijzigd door Zynth op 13 november 2020 10:52]

Tijdens mijn informatica studie voelde ik me bij veel programmeertalen thuis en vond ik de vraag welke programmeertaal ik het fijnste vond maar een lompe vraag. Alles had zijn fijne en minder fijne kanten, maar je koos de programmeertaal die paste bij je probleem.

Nu programmeer ik al een tijd alleen in Python, mis regelmatig specifieke zaken van andere programmeertalen, maar zou in no way zomaar weer iets in PHP, C++ of Java eruit kunnen kloppen.

Inderdaad super irritant dat er zoveel syntax verschillen zijn, zelfs om eenvoudige zaken uit te voeren als: i = 1 + 1 bvb.!
Inderdaad ook super irritant dat je bij elke taal je meer moet bezighouden met de 'taaldetails' dan met het programmeren zelf.
Ik ben zelf wel Pro-Python, maar de overgang v versie 2 naar 3 had naar mijns inziens anders moeten verlopen (lees: met backward compatibility) en heeft onze 'Benevolent Dictator For Life' toch wel een stuk in eigen voet geschoten...
Dus zelfs in de Python versies heb je die 'versnipperingen'... Dagelijks zijn er wel vragen hierover op Stackoverflow e.d. (meeste over: print "TEST" t.o.v. print("TEST"). Was dat nu zó moeilijk om die compatibility te bewaren?

Ik vergelijk het ook met een linguïstische taal; als ik op vakantie ga naar bvb. Duitsland, Italië, Portugal, ... moet (lees: wil) ik ook niet per sé weten of een bepaald woord mannelijk, vrouwelijk of onzijdig is. Je wilt gewoon proberen een taal te spreken om ter plekke te kunnen communiceren met anderen en niet voor jezelf bezig zijn met dergelijke 'details' die je dan toch moet gaan instuderen en in mijn ogen tijdverlies betekent...

style en het raar idee dat men programmeurs moet verplicthen om in vaste structuren te schrijven ... python is a crime against supercomputing in essentie mr blijkbaar spreekt het heel wat autisten (no offense to de echte) aan.
Zwaar , log en een memory hog ... die vent past direct in windows-ontwikkeling wrsl. Programmeren is von neuman logic ongeveer voor zowat alles en al die nieuwigheden van de jaren 1960 zoals OO .. een machine heeft geen objection, dat gaat niet over performance dat gaat over teamplay en autisme (no offense to de echte ...)

[Reactie gewijzigd door Anoniem: 1367158 op 14 november 2020 09:59]

Zeker, begonnen op Teleac met Assembler; een beetje Commodore Vic20 en de C64 ook in 6502/6510 machinetaal; Cobol; Algol RPG IBM 360/ assembler; DB/2-DB/DC en vele versies van Basic; Pascal; SERA, Z80; Telon; REXX en op PC: Dbase2;3;4; Clipper; Java; Hypertext talen; SQL; XML; Python en vele andere varianten: Excel en Apple Numbers zijn de laatste tijd in focus.
Momenteel op Apple: Swift.
Het gestructureerd (modulair) programmeren is de basis; liefst object georiënteerd.
De omslag van procedureel naar Object georiënteerd was even pittig.

Op een Mainframe heb je vaak combinaties van Transactie georiënteerde talen met Database management talen zoals IMS DB/DC en DB/2.

Het is allemaal de vraag: wanneer; welk doel en op welk platform is er een oplossing gewenst.

Programmeren is eerder een denkwijze en de programmeertaal is het gereedschap.
Als metafoor: als je aan een Engelse auto gaat sleutelen heb je ander gereedschap nodig dan bij een Duitse auto (metrisch/inches).

Als reden noemt hij dat hij besloot dat pensioen maar saai was.

Mij lijkt pensioen ook erg saai.

Het eerder dit jaar noodgedwongen thuis moeten blijven en bijna niets meer kunnen doen voor mijn werk vanwege de eerste Corona lockdown beschouw ik als een voorproefje op hoe pensioen waarschijnlijk aanvoelt. Ik vond het verschrikkelijk.

Dus ik kan me heel goed voorstellen dat hij weer aan het werk gaat. Voor het geld hoeft hij het niet te doen, neem ik aan.

[Reactie gewijzigd door Uruk-Hai op 12 november 2020 19:59]

Er is onderzoek naar gedaan. mensen in de nadagen van hun leven is gevraagd wat ze eventueel anders hadden kunnen doen. Het gros zegt niet "had ik maar harder gewerkt, dan had ik een nog betere baan gehad" maar "ik zou als ik het over kon doen, meer tijd bij de mensen doorbrengen die mij lief zijn"

Ik hou wel thuis zitten. Kan ik mn game backlog inhalen.

Zijn veel mensen waarvan de thuissituatie dusdanig saai/verschrikkelijk is dat ze zelfs liever werken.

Soort workerdrones zijn dat.

[Reactie gewijzigd door Flagg op 12 november 2020 20:02]

Kubernetes

Ik kom om in de thuis projectjes waar wat onverdeelde aandacht, lees pensioen wel mooi voor is. Duurt alleen nog maar 33 jaar voor pensioen en moet zeggen dat ik het werk nu nog veel te leuk vind. Maarja werk ook voor me zelf

Kan ook slecht echt stil zitten

[Reactie gewijzigd door bazzi op 12 november 2020 21:27]

Doe wat je leuk vindt, dan hoef je geen dag meer te werken. Dat is meer mijn insteek...

Verschil is denk ik wel dat je bij pensioen weet dat je niet hoeft te werken, in jouw geval kan je niet je leven plots anders gaan inrichten vanwege de onzekerheid.

Nou ik ken anders evenzo mensen die totaal afgebrand na een zittend beroep niet meer echt kunnen genieten van hun pensioen. De definitie "zwaar beroep" wordt in mijn optiek uit het lood enkel aan lichamelijk zware beroepen toegekend en gaat voorbij aan mensen die zowat hun alles (op)geven aan hun baan. (hetgeen verboden zou moeten worden maar dat terzijde)

Pensioen is van origine (na WW2) gebaseerd op 40 jaar werken en het betalen van premie vanaf je 25e. Daar komt die 65 vandaan. Inmiddels ligt de AOW leeftijd al op 66+ en wordt/is uiteindelijk gerelateerd aan de levensverwachting van de bevolking. De reden dat het onbetaalbaar wordt is dat we nog steeds op het omslagstelsel zitten waar de overheid dit 30-40 jaar terug had moeten omzetten. Als ze toen hadden geregeld dat je niet 100% voor de vorige generatie betaald maar elk jaar 2% voor je zelf was gaan betalen dan was dit inmiddels 60-80 procent geweest. Dan heb ik het ook alleen nog maar over de AOW en niet het aanvullende pensioen dat door de jaren heen veranderd is van garantie stelsel eindloon naar middelloon en nu naar beschikbare premie waarbij alle risico's (en dat zijn er nogal wat) naar de werknemers zijn verlegd. Hier zijn nog wel wat boeken over te schrijven maar de conclusie is dat als je nog met pensioen wil je hier zelf op tijd geld voor opzij moet zetten.

Mss enigszins off topic maar moest het even kwijt,

deels off-topic, maar wel zeer relevant;

het aanvullende pensioen dat door de jaren heen veranderd is van garantie stelsel eindloon naar middelloon en nu naar beschikbare premie waarbij alle risico's (en dat zijn er nogal wat) naar de werknemers zijn verlegd.

Veel tweakers zetten amper geld opzij terwijl zij als freelancer lekker 60 euro per uur binnen harken en net zo hard weer uitgeven om er dan na 40-45 jaar achter te komen dat ze hun hand op kunnen gaan houden bij de voedselbank.

Ambtenaren tot hun 70ste ha ha ha ha. Mafkees! Alsof de godganse dag achter een pc zitten en bureaucratische kutproblemen oplossen niet zwaar werk is.. Jij heb duidelijk een verkeerd beeld hiervan. Een mens is gewoon "op" op een bepaald moment. Het enige probleem is dat mensen wel steeds ouder worden en dat is pensioen-technisch gewoon niet meer te betalen..

Dus geestelijk zwaar werk en 8 uur per dag achter de computer is geen reden om ook met je 65ste met pensioen te mogen? Sorry hoor maar zwaar werk is niet alleen lichamelijk daar verkijk jij je lelijk op.

Precies. Het voordeel van lichamelijk zwaar werk is dat als je stopt je ook klaar bent. Als je geestelijk inspannend bezig bent geweest is het niet altijd even makkelijk om je hersens stop te zetten. Zeker met analytische problemen die opgelost moeten worden kunnen je hersens zomaar 24/7 doordraaien. Wat ook vaak wordt vergeten is dat je hersens normaal al zo'n 20..30% van ons totale energieverbruik bepalen en bij geestelijk inspannend werk nog veel meer.

Daar zeg je wat. Ik ken iemand die een periode tijdelijk blind is geweest door programmeerwerk achter de computer. Echt een heel maf verhaal. Hij had zich teveel ingespannen in zijn werk en ineens viel zijn gezichtsvermogen uit.

Zo zwaar kan kantoorwerk dus zijn...

En daarnaast is er natuurlijk nog het vrij algemeen bekende RSI. Ik weet niet of het daardoor kwam, maar ik kreeg op een gegeven moment last van iets dat frozen shoulder heet. Dat wil zeggen dat je je bovenarm ten opzichte van je schouder niet meer maximaal kunt bewegen. Als je dat wel probeert voel je pijn.

[Reactie gewijzigd door Uruk-Hai op 12 november 2020 20:18]

Zo zwaar kan kantoorwerk dus zijn...

Nee, zo kunnen oogziektes zijn. Die kunnen heel langzaam gaan of heel snel. Voor zover ik weet bestaat er geen direct aanwijsbaar verband tussen stress en tijdelijke blindheid. Als dat er zou zijn zouden heel veel developers blind als een tor zijn.

Kantoorwerk kan natuurlijk zeer zwaar zijn maar feit is dat de uitval door arbeidsgerelateerde problemen tientallen malen hoger is bij beroepen waarbij het lichaam zwaar belast word. RSI is een probleem maar rugproblemen bij bouwvakkers komen gewoon veel (veeeeeeel) vaker voor.

Nee, zo kunnen oogziektes zijn. Die kunnen heel langzaam gaan of heel snel. Voor zover ik weet bestaat er geen direct aanwijsbaar verband tussen stress en tijdelijke blindheid.

Mijn rechterpols was tweeëneenhalve maand verlamd zonder aanwijsbare oorzaak. Neurologisch was er niets aan de hand. Toen kwam men met de conversiestoornis op de proppen. Het blijkt dat bij sommige mensen de hersenen bepaalde lichaamsdelen kunnen worden uitgeschakeld onder grote stress.

Zie: https://nl.wikipedia.org/wiki/Conversiestoornis

Ik ken ook iemand die door stress meeste zicht verloren had. Uiteindelijk na een carrièreswitch en andere leefomgeving is het langzaam teruggekomen. Deze persoon is echt van het aanpakken en geen aansteller.

Ben maar eens verantwoordelijk voor alles en iedereen en dan wordt je verplicht om allemaal thuis te werken.. reden genoeg voor een burnout, het is maar net hoe je erin staat.

Persoonlijk lijkt "operator kerncentrale" me een stuk relaxter dan baliemedewerker van een parkeergarage op bijvoorbeeld een vliegveld met rijen chagrijnige mensen.

Thuis werken was voor mij een zegen om uit een dreigende burnout te komen. Inmiddels loopt het weer als een trein met 1-2x per week een ‘echte’ meeting ( we hebben de boswandel vergadering inmiddels wekelijks, werkt super goed)

Binnen de Azure Cloud zijn er genoeg verbeteringen te ontwikkelen rondom de dienstverlening waarbij gebruik wordt gemaakt van Python. Inmiddels veel projecten meegemaakt op gebied van Data Science die gebruik maken van Python, waarbij met name stabiliteit en beheersbaarheid in een cloud omgeving het probleem was. Hoop dat hij daar zijn bijdrage aan gaat leveren.

misschien is dask dan iets voor je.

Hmm. Microsoft hangt altijd nog sterk strongly typed talen aan. Hopelijk gaat hij dat niet verpesten...

</cynisch>

Misschien gaat die dat juist bij microsoft doen. Python een typechecker geven (als typescript voo python?). Zou ook verklaren waarom ze hem nodig hebben en niet een leger aan senior pyhton developers. Finger crossed xd.

edit: microsoft heeft al een python typeschecker: pyright

[Reactie gewijzigd door RagingPenguin op 13 november 2020 13:51]

Guido heeft echt een accent gekregen, lijkt dat die bijna nooit meer Nederlands spreekt :-)

Als reden noemt hij dat hij besloot dat pensioen maar saai was.

Er zijn/waren anders genoeg in Python2 geschreven open source projecten waarvan de ontwikkelaars bij Python2 bleven "hangen" omdat de migratie naar Python3 een complete rewrite van hun codebase betekent.
Daar had hij gerust een handje kunnen helpen om zijn pensioen minder saai te maken.

Ik heb genoeg codebases naar Python 3 omgezet om te weten dat een “complete rewrite” zwaar overdreven is. Er zijn ook al genoeg tools en documentatie om je te helpen.

Toch betaal ik 55 cent per regel voor een conversie. En dat is na 12 offertes.

Is dat niet erg goedkoop ??
Consultant = 850 euro per dag , dan moet die 1500 regels code per dag produceren.

Sterk !

Of mis ik nu iets

[Reactie gewijzigd door klakkie.57th op 12 november 2020 22:33]

Geen 1500 regels per dag produceren, maar converseren. Dat is nogal een verschil aangezien je amper na hoeft te denken over de logica zelf, enkel het compatible maken met de nieuwe syntax.
Ik ken de verschillen in Python 2 vs 3 verder niet, maar ik ga er van uit dat je ruim de helft van je regels code niet eens aan hoeft te raken.

Ja, dat consultants (ik was er eentje) vaak willen "upsellen" en je halve applicatie willen herschrijven.

De schoorsteen moet tenslotte roken. Een project waar ik jaren geleden bij betrokken was stelde diep in de 2 era, bij de eerste betas van 3 al, dat de code 3 compatible moest zijn.
De uiteindelijke transitie was letterlijk een dagje testen en klaar.
Een ander project heeft tot 2018 vastgehouden aan 2.x. Die conversie kwam inderdaad op 55-65 cent per regel uit gezien het aantal uren dat daar in is gaan zitten, nog los van de verloren ontwikkeltijd.
Kortom, hulde voor de eerste manager die gelijk in zag dat v3 onvermijdelijk was

Ja hallo, daar haalt een figuur van zijn kaliber toch geen energie uit? Hij hoeft ook echt niet aan liefdadigheid te doen ofzo.

Nieuwe versies van talen, frameworks etc zijn een fact of life, evenals de bijbehorende code migraties. Dat moeten developers prima zelf kunnen doen.

Complex project van 2 naar 3, weekje? Max

Hmm.. ik ken idd nog wel een project dat op Python 2 is blijven hangen:

https://ironpython.net/

Ligt het aan mij dat ik het gebruik van het woord "uitvinder" een beetje kinderachtig vind klinken in deze context? Een programmeertaal ontwikkel je, die vindt je niet uit.

Het mag misschien een onpopulaire mening zijn, maar als programmeur zijnde vind ik python nou niet bepaald een doorontwikkeld product. De taal is is zo vrij dat er zoveel in mag dat het leesbaarheid niet bevordert, en moet het nog meemaken dat projecten direct draaien als je ergens een clean install doet.
Dus naar mijn mening mag je het wel een "uitvinder" noemen, want het is leuk voor hobbyen, maar en mag naar mijn mening wel een "ontwikkelaar" naar kijken om het een echt product te maken.

Vanuit het oogpunt van technische perfectie heb je weliswaar gelijk, maar toch vult het een gat dat slecht door traditionele programmeertalen opgevuld kan worden. Misschien nog eventueel deels wel door low code oplossingen trouwens.

De kunst zit erin om iets te bedenken dat precies een hele goede fit met die situatie heeft. En dat heeft hij gedaan. Al moet ik er wel bijzeggen dat een deel daarvan ook te danken is aan de immense stapel libraries.. ik kan zelf niet goed bepalen in hoeverre het bestaan van dat ecosysteem ook aan hem toe te schrijven is.

Goed om te zien dat er open source advocates bij Microsoft komen te werken

Zijn ze de laatste jaren al mee bezig hoor. Hij lijkt een zelfde functie titel te krijgen als andere grootheden uit de open source wereld die bij MS zijn gaan werken

Bijvoorbeeld Miguel de Icaza en Brendan Burns. Dit soort gasten helpen samen echt het 'nieuwe' Microsoft vormen

1998 belde, ze willen hun comment terug!

Welcome to the Dark Force.

Goed om te zien dat Guido lekker nuttig (voor ons) bezig blijft. Succes!

Hopelijk werkt hij aan Pyright, of nog beter het Python equivalent van TypeScript. Dat zou Python zoveel beter maken.

Bedoel je zoiets als PEP 484 - Type Hints?
Bij deze PEP kwam ik achter bij een GDScript (Godot Game Engine) en het leek me zeker interessant om zelf verder mee te werken.

Wat mij betreft is het nog allemaal te vrij, maar het is zeker een stap in de goede richting.