De Devschuur Coffee Corner - Iteratie ⓬

[ThomasG]

gekkie schreef op maandag 5 augustus 2019 @ 11:10:
Hmm zo in de kantoortuin vind ik toch een hoop meer bugs.

Dat zijn geen bugs, maar een feature

[gekkie]

Little flying features .. *shoot* .. wou net zeggen dat de wespen nog niet wakker lijken .. maar daar kwam er dan gelijk al weer eentje kijken.

[SpiceWorm]

farlane schreef op zondag 4 augustus 2019 @ 21:57:
[...]

Dat is een probleem met alle abstracties, het zijn abstracties totdat ze het niet meer zijn

Ja logisch, behalve dan dat MS belooft dat je het .net framework kan gebruiken (xamarin komt immers voort uit mono) op android en in c# kan schrijven in visual studio. Dat leek mij erg fijn.

[...]

Je staat een IDE met een toolkit te vergelijken hier. Ik niet snap.

[...]

En hier vergelijk je een scripting language met een IDE. Snap ik ook niet.

Mja, dat snap ik dat je het wat verwarrend vind, maar het zijn allemaal manieren om apps te bouwen voor android. Ik weet bij android studio + de standaard sdk + running android zelf + het target device niet waar de problemen door ontstaan. Is het de brakheid van AS? Is het de brakheid van de sdk? Is het de brakke implementatie android? Of de customisation van de fabrikant op het ontwikkeldevice? Vandaar dat ik het op één hoop gooi want ik denk dat allevier problemen maken. Je snapt neem ik aan dat ik android studio niet gebruik om dmv c++ een app voor iOS te schrijven?

Flutter lijkt daarom interessant omdat het (hopelijk) een aantal problemen in een keer oplost en iig de basis gestroomlijnd is. Het is in ieder geval vanaf de basis opgebouwd met een hoop best practices toegepast.

Ik denk toch echt dat het probleem niet bij Android Studio zit.

Niet echt een leuke opmerking, omdat jij denkt te snappen dat ik niet snap waar ik mee bezig ben zeg je dat ik het probleem ben?

Ik heb zoals gezegd eerder een android app geschreven, met hardware interfacing, multithreaded, services, power management, native libraries, etc. Daar was het te verwachten dat ik onregelmatigheden tegen kwam (en dat deed ik, met busladingen, en ik was zeker niet de enige, heb zelfs nog bijgedragen aan een stukje originele documentatie in een antwoord aan mijzelf op SO, domweg omdat er geen recente documentatie was van dat onderdeel) maar ging er vanuit dat de basis workflow ondertussen wel soepel was. Maar helaas, nee.

ThomasG schreef op maandag 5 augustus 2019 @ 09:45:
[...]
Ik heb in het verleden wel eens de Android SDK gebruikt, om een library te maken. Het bedrijf waar ik toen werkte wilde een library aan de klanten bieden voor bepaalde functionaliteit (api koppeling, met ui views, e.d.). En gek genoeg zat er in de Android simulator een "bug" in precies die Android API die we daarvoor nog hadden, waardoor het gedrag in de simulator totaal anders was dan op echte Android telefoons, met de nodige kopzorgen van dien. Daarnaast was het, in ieder geval toen der tijd, ontzettend langzaam. Ontwikkelen voor Android was dus een eenmalig uitstapje dat ik vaarwel heb gezegd

Ja, idd dit soort dingen dus. Om de haverklap bugs waarvan het uren kost om ze op te sporen. Ik zou ook niet verbaast zijn geweest als je had verteld dat een andere emulator image een andere bug had gehad.

[ Voor 19% gewijzigd door SpiceWorm op 05-08-2019 11:59 ]

[Mugwump]

Je kunt ook Android development in Swift doen, mocht je daar gelukkiger van worden.

[farlane]

SpiceWorm schreef op maandag 5 augustus 2019 @ 11:53:
[...]
Ja logisch, behalve dan dat MS belooft dat je het .net framework kan gebruiken (xamarin komt immers voort uit mono) op android en in c# kan schrijven in visual studio. Dat leek mij erg fijn.

MS belooft een heleboel, maar als het niet werkt (en dat gebeurt ook bij MS geregeld) heb je preceis hetzelfde probleem. Ik zie niet in hoe Xamarin, hoe mooi het ook klinkt, dergelijke problemen gaat verhelpen.

Mja, dat snap ik dat je het wat verwarrend vind, maar het zijn allemaal manieren om apps te bouwen voor android.
... etc ...

Ok, dus eigenlijk bedoel je dat je Android development een brakke aangelegenheid vindt? Dat sterkt me nog meer in de mening dat dat (voor een groot deel) komt omdat je normaal met MS/.NET/Visual Studio werkt en het daarom kut vindt.

Flutter lijkt daarom interessant omdat het (hopelijk) een aantal problemen in een keer oplost en iig de basis gestroomlijnd is. Het is in ieder geval vanaf de basis opgebouwd met een hoop best practices toegepast.

De Android SDK daarentegen is een zooitje ongeregeld? Ik denk, maar ik hoop voor je dat ik het mis heb, dat Flutter uiteindelijk precies net zo niet werkt als de toolkit die je nu gebruikt.

Niet echt een leuke opmerking, omdat jij denkt te snappen dat ik niet snap waar ik mee bezig ben zeg je dat ik het probleem ben?

Ten eerste heb je zelf ook al aangegeven dat het misschien wel helemaal niet Android Studio is die jouw leven tot een hel maakt; het zou ook de Android SDK, de emulator (misschien wel Java?) of iets ander kunnen zijn.
Ten tweede stel ik niet je intelligentie ter discussie, dus trek het je niet al te hard aan.

Ik ben geen Android developer dus als ik er mee aan de slag ga dan vloek en tier ik ook meer dan eens, maar ik ben wel realistisch in dat veel van die frustratie komt door een gebrek aan ervaring met het platform.

[Douweegbertje]

SpiceWorm schreef op maandag 5 augustus 2019 @ 11:53:
[...]

Niet echt een leuke opmerking, omdat jij denkt te snappen dat ik niet snap waar ik mee bezig ben zeg je dat ik het probleem ben?

Niet om nou olie op het vuur te gooien, maar ja?

Het is niet zo zwart-wit maar je vergelijkt een SDK daarna met Python, en Python is dan beter. No shit. Weet je waarom, omdat je al je kennis kan gebruiken voor iets wat je al weet!
Exact zoals je zegt:

Ik heb zoals gezegd eerder een android app geschreven, met hardware interfacing, multithreaded, services, power management, native libraries, etc.

Laat nou net dat soort dingen niet het moeilijkste zijn als je eigenlijk programmeert "tegen" een SDK. Geen verassingen, geheimen en limitaties. Geen hoge iteraties van de SDK zelf en versions waar je tegen moet/kan builden.

Je kan beter een Android expert zijn dan gedegen programmeur. En dat is nou exact de downfall waar jij "waarschijnlijk" tegenaanloopt.

Neem het dan iemand niet kwalijk om daar een mening over te hebben, want zoals farlane als ik vinden jou echt niet dom, stom of slecht. (althans ik interpreteer farlane zo )

----

Ik heb daarnet weer een dag van mijn leven verpest met het praten tegen een API. Is die API slecht? nope. Ben ik slecht? nope, well maybe. Maar het is nieuw, ik snapte nog niet alles, ik snapte niet de volledige internals van het endpoint. Dus ja dan is het vervelend. Gelukkig kost dat maar "even" om het beter te begrijpen, eventueel de geschiedenis van bepaalde functionaliteiten. Zoiets met Android is exact hetzelfde, behalve dat het je misschien jaren kost om daar beter in te worden, waarna je nog steeds niet alles snapt.

M.a.w. don't feel bad. Ja het is soms )(!*@! krom en lastig, maar uiteindelijk is het niemand z'n schuld

Anyhow, prima om hier te ranten natuurlijk

[SpiceWorm]

farlane schreef op maandag 5 augustus 2019 @ 16:50:
[...]

MS belooft een heleboel, maar als het niet werkt (en dat gebeurt ook bij MS geregeld) heb je preceis hetzelfde probleem. Ik zie niet in hoe Xamarin, hoe mooi het ook klinkt, dergelijke problemen gaat verhelpen.


[...]

Ok, dus eigenlijk bedoel je dat je Android development een brakke aangelegenheid vindt? Dat sterkt me nog meer in de mening dat dat (voor een groot deel) komt omdat je normaal met MS/.NET/Visual Studio werkt en het daarom kut vindt.


[...]

De Android SDK daarentegen is een zooitje ongeregeld? Ik denk, maar ik hoop voor je dat ik het mis heb, dat Flutter uiteindelijk precies net zo niet werkt als de toolkit die je nu gebruikt.


[...]

Ten eerste heb je zelf ook al aangegeven dat het misschien wel helemaal niet Android Studio is die jouw leven tot een hel maakt; het zou ook de Android SDK, de emulator (misschien wel Java?) of iets ander kunnen zijn.
Ten tweede stel ik niet je intelligentie ter discussie, dus trek het je niet al te hard aan.

Ik ben geen Android developer dus als ik er mee aan de slag ga dan vloek en tier ik ook meer dan eens, maar ik ben wel realistisch in dat veel van die frustratie komt door een gebrek aan ervaring met het platform.

Ah, bedankt voor de verduidelijking. Ik had de opmerking echt opgevat als "problem exists between keyboard and chair" en dat schoot een beetje verkeerd, maar ik was te snel met reageren.

Douweegbertje schreef op maandag 5 augustus 2019 @ 22:57:
Laat nou net dat soort dingen niet het moeilijkste zijn als je eigenlijk programmeert "tegen" een SDK. Geen verassingen, geheimen en limitaties. Geen hoge iteraties van de SDK zelf en versions waar je tegen moet/kan builden.

Gek eigenlijk!...? Met de native libs / hardware interfacing snap ik je opmerking, maar services / multithreading lijkt mij toch gewoon sdk of zie ik dat verkeerd?

M.a.w. don't feel bad. Ja het is soms )(!*@! krom en lastig, maar uiteindelijk is het niemand z'n schuld

Anyhow, prima om hier te ranten natuurlijk

Thanks

[ Voor 77% gewijzigd door SpiceWorm op 06-08-2019 12:07 ]

[analogue]

Ik herken je frustratie hoor @SpiceWorm , ben zelf inmiddels geen app developer meer, maar gedoe met supportlibraries en inderdaad styling issues staan me nog bij.

Ik werkte in de begindagen nog met de Eclipse versie, ik moet zeggen dat ik Android Studio wel een hele verbetering vind. Daarnaast merk ik wel dat met o.a. de komst van Kotlin de API's en libraries iets logischer zijn opgezet, maar het lijkt soms alsof men verrast was dat Android zo populair is geworden en dat de toolkit haastig is ontwikkeld o.i.d. (geen idee hoor, just a thought)

[Gropah]

analogue schreef op dinsdag 6 augustus 2019 @ 12:09:
[...]
Daarnaast merk ik wel dat met o.a. de komst van Kotlin de API's en libraries iets logischer zijn opgezet, maar het lijkt soms alsof men verrast was dat Android zo populair is geworden en dat de toolkit haastig is ontwikkeld o.i.d. (geen idee hoor, just a thought)

De eerste android versie stamt uit 2008. Sindsdien is er voortschrijdend inzicht, technische redesigns om gebruik te kunnen maken van nieuwe technologieën, nieuwe features, nieuwe platformen (denk auto, tv en watch) en visuele redesigns. En dat allemaal terwijl het nog steeds mogelijk is om te ontwikkelen voor een platform van 2008, als je wilt. Hoewel tegenwoordig volgens mij 4.4 de laatste, nog semi breed, gebruikte versie is. Dan kan ik mij er alles bij voorstellen dat het moeilijk is om dat allemaal goed te krijgen

Oh, en het helpt wellicht ook niet dat het origineel bedoeld was voor toestellen zonder touchscreen.

[MichielPH]

SpiceWorm schreef op zaterdag 3 augustus 2019 @ 14:31:
Ik heb het gevoel dat als ik iets simpels wil doen (bijvoorbeeld zorgen dat niet het eerste element van een spinner automatisch geselecteerd is maar dat de drop down gewoon leeg is) ik een workaround moet maken.

Hoe zou ik me dit voor moeten stellen? Als de drop down leeg is, bevat de spinner toch geen items en is er geen 'eerste item'?

Alleen al de popups waar best wel complexe dingen in uitgelegd worden die na 5 seconden weer automatisch verdwijnen, als je nog niet eens halverwege het lezen bent.

Dit kan je voorkomen door met je muis boven de melding te zweven.

Edit: en dan heb ik het nog niet eens over de minutenlange apk installatietijd op een echt device omdat je de gui hebt veranderd omdat in tegenstelling tot in de designer op een echt android apparaat je nieuwe button niet zichtbaar is .

Dit is inderdaad zeer herkenbaar. Ik ben momenteel bezig met een Instrumentation Test die op een device moet draaien, maar installatie duurt soms inderdaad minuten. Haalt de flow er behoorlijk uit.

[Matis]

De afgelopen dagen hebben we wat problemen gehad met het alarmeren via het P2000 netwerk.
Bleek een probleem in de tijdsynchronisatie van de mast Oudenbosch. Na een reset is dit verholpen. Vanuit het GMK zijn ze ook niet bang voor het testen op productie

[Biersteker]

Na heel lang veel gedaan te hebben in NodeJS en PHP , die (grotendeels) het raam uit gemikt.

Rustlang

Mijn god, wat is dat een verademing. Nog niet alles is even volwassen. (Databases over meerdere threads beschikbaar maken in actix-web, fatsoenlijke http-request lib) maar strict typing ftw!

Nu maar hopen dat cargo niet zo'n puinzooi word als npm

[ Voor 8% gewijzigd door Biersteker op 06-08-2019 15:48 ]

[Tjolk]

Strict typing zit toch al jaren in PHP? Als dat het enige is wat je mist kun je net zo goed in PHP blijven werken.

[ThomasG]

Biersteker schreef op dinsdag 6 augustus 2019 @ 15:47:
Na heel lang veel gedaan te hebben in NodeJS en PHP , die (grotendeels) het raam uit gemikt.

Rustlang

Mijn god, wat is dat een verademing. Nog niet alles is even volwassen. (Databases over meerdere threads beschikbaar maken in actix-web, fatsoenlijke http-request lib) maar strict typing ftw!

Nu maar hopen dat cargo niet zo'n puinzooi word als npm

[Biersteker]

Tjolk schreef op dinsdag 6 augustus 2019 @ 16:11:
Strict typing zit toch al jaren in PHP? Als dat het enige is wat je mist kun je net zo goed in PHP blijven werken.

Hangt een beetje af of je kan overgaan naar PHP 7 , want legacy meuk.

Ook dingen als fatsoenlijke threading en de "je doet shit fout, will not compile" mentaliteit ga ik erg lekker op .

[ Voor 16% gewijzigd door Biersteker op 06-08-2019 16:15 ]

[armageddon_2k1]

Ja, van NodeJS en PHP naar een taal met een echt robuust type system is sowieso fijn. Daar hoef je niet alleen bij Rust aan te kloppen.

Bij PHP voelt het voor mij als een afterthought (nogal wiedes) en is het niet zo natuurlijk als in Scala, Kotlin of Rust. Helemaal met mooie pattern matching

[Biersteker]

armageddon_2k1 schreef op dinsdag 6 augustus 2019 @ 16:16:
Ja, van NodeJS en PHP naar een taal met een echt robuust type system is sowieso fijn. Daar hoef je niet alleen bij Rust aan te kloppen.

Bij PHP voelt het voor mij als een afterthought (nogal wiedes) en is het niet zo natuurlijk als in Scala, Kotlin of Rust. Helemaal met mooie pattern matching

Ja precies,

ook een tijdje met Golang gewerkt, maar ben echt een beetje rust fanboy aan het worden .
NodeJs heb je gelijk die hele typescript meuk,
PHP , te veel legacy en threading is meuk.

[boe2]

Biersteker schreef op dinsdag 6 augustus 2019 @ 15:47:
Na heel lang veel gedaan te hebben in NodeJS en PHP , die (grotendeels) het raam uit gemikt.

Rustlang

Ik denk dat bijna iedere taal als een verademing voelt als je je carriere hebt opgebouwd met javascript en php

[armageddon_2k1]

En PHP7.2, hebben die niet alleen type hinting op de scalar types?

Is wel even iets anders als een echt type system.

[Douweegbertje]

Mag ik wel even zeggen dat ik multithreading het meeste vercrackte argument vind om PHP te bashen.
Wat wil je, 100 threads draaien om een page te 'renderen' per bezoeker? -,-

Het "threading" stuk zit hem meer in het serveren. Dus FPM. Immers is PHP nog steeds een script.

Er zijn genoeg "services" die je kunt gebruiken - message bus - bijvoorbeeld voor je doeleinde (computing of whatever). Ik zou het persoonlijk super vreemd vinden dat als een X random user een page laad, dat jij multithreaded vage meuk gaat doen voor een request.

Draai daar een aparte (micro) service voor en gebruik de juiste tool voor de job?

[Sebazzz]

Threading gaat over zaken asynchroon doen zodat je meer concurrente pagina's kan serveren met hetzelfde setje threads.

[Douweegbertje]

Sebazzz schreef op dinsdag 6 augustus 2019 @ 21:57:
Threading gaat over zaken asynchroon doen zodat je meer concurrente pagina's kan serveren met hetzelfde setje threads.

En ik geef aan dat PHP een scripting taal is, dus kan en moet je dat anders oplossen. De werking van PHP is totaal anders. Wil je iets async dan los je dat op andere manieren op:

- Je gebruikt een bepaalde frontend die de requests doet. Denk aan het simpelste voorbeeld: JS met ajax calls.
- Je gebruikt message busses zoals bijvoorbeeld rabbitMQ voor echte backend processes

In al mijn jaren werken met PHP ben ik tegen veel issues aangelopen maar laat dit nu echt een argument zijn die echt niet van toepassing is voor PHP. Het is geen "applicatie", noch iets wat je rechtstreeks aanspreekt. Misschien CLI even in het middel gelaten, maar daar ligt zijn kracht ook niet.

Dit is ongeveer hetzelfde dat ik zeg dat C# kut is omdat ik geen .cs files rechtstreeks door apache kan laten executen en serveren als pagina

[ThomasG]

Douweegbertje schreef op woensdag 7 augustus 2019 @ 09:32:
[...]

Dit is ongeveer hetzelfde dat ik zeg dat C# kut is omdat ik geen .cs files rechtstreeks door apache kan laten executen en serveren als pagina

Maar wacht, dat kan wel

Weliswaar via een Apache module, maar dat moet met PHP ook.

[Douweegbertje]

ThomasG schreef op woensdag 7 augustus 2019 @ 09:44:
[...]
Maar wacht, dat kan wel

Weliswaar via een Apache module, maar dat moet met PHP ook.

Ja misschien moet ik ook geen exacte voorbeelden geven van een taal waar ik amper kennis van heb

[Matis]

Heerlijk om af en toe door de herstelrubriek van de NOS te bladeren.

De ene keer gaat het over een spelfout, de volgende keer over verkeerde cijfers: Factor 3000, kan gebeuren

[ Voor 34% gewijzigd door Matis op 10-08-2019 21:35 ]

[Koenvh]

@Douweegbertje PHP daarom bashen zou ik ook niet doen, maar het kan soms best wel een tekortkoming zijn. Net zoals de Python GIL ook een tekortkoming kan zijn. Ik zou best blij worden van betere threading in PHP.

Overigens is PHP volgens mij het station van pure scriptingtaal al lang gepasseerd.

[Immutable]

Koenvh schreef op zaterdag 10 augustus 2019 @ 21:40:
@Douweegbertje PHP daarom bashen zou ik ook niet doen, maar het kan soms best wel een tekortkoming zijn. Net zoals de Python GIL ook een tekortkoming kan zijn. Ik zou best blij worden van betere threading in PHP.

Overigens is PHP volgens mij het station van pure scriptingtaal al lang gepasseerd.

Zo heeft elke taal tekortkomingen. Na een tijd zie je gewoon in "waarom" een bepaalde taal is gemaakt. En voor welke doeleinde een taal is. Je ziet nog veel mensen die een taal kiezen van.. omdat je die taal toevallig kent. En dan het product gaan maken.

Je moet kijken wat je gaat maken, en daar de taal voor uitkiezen. Ik zie dit vaak gebeuren in bijvoorbeeld de industrie of men gaat een product maken met C# om die dan te verkopen. Ik decompile je project zo en jat je source code muhahaha.
Of dat men in de industrie talen gaat gebruiken met een Garbage Collector en dan erachter komt dat hard-realtime zaken niet werken! no shit.
Of dat men performance gerelateerde programma's in bytecode talen zoals C# Java of Scripttalen gaat programmeren in plaats van C/C++/Rust o.i.d. En dan gaat zeuren over performance en dan HEEL VEEL tijd steken in het optimaliseren van de GC en of optimaliseren van de byte / script code.
Of stukjes herschrijven betreft performance code in C voor python wat ik dan.. wel kan snappen.

Waarom kiezen mensen eerst een taal, en kijken dan naar de oplossing in plaats van andersom?
Enige wat je moet weten is procedureel, functioneel en object georiënteerd programmeer concepten. De taal is maar een syntax? Toch? Maar dit leer je allemaal op school volgens mij dus iedereen die is afgestudeerd moet dit kunnen.
Smalltalk is bijvoorbeeld een redelijke pure vorm van Object georiënteerd programmeren. Hierin is Pharo de moderne opvolger van. Lisp is een redelijke pure vorm van functioneel programmeren. Hierin kun je Clojure/Haskell voor leren hedendaags. Procedureel natuurlijk FORTRAN, voor hedendaags kun je beste daarvoor C gebruiken om te leren.

Dus leer voor de lol een beetje Pharo / ClojureofHaskell / C. Dan kan je zo elke andere syntax aanleren.
Meest vervelende talen zijn dan multi-paradigm talen. Hierin kun je verschillende concepten gebruiken, dit is zowel een voor als nadeel. Deze verschillende concepten mixen in je code is niet altijd een succes.

Het grappige aan oude talen is, dat ze nog steeds hele goed bedachte dingen bevatten die NU pas bijvoorbeeld zijn intrede doen in moderne talen. Metaclasses van Smalltalk komt waarschijnlijk pas in C++23 in de taal.

[ Voor 19% gewijzigd door Immutable op 11-08-2019 11:00 ]

[RayNbow]

Immutable schreef op zondag 11 augustus 2019 @ 10:40:
Enige wat je moet weten is procedureel, functioneel en object georiënteerd programmeer concepten.

Ja hoor, en logisch programmeren krijgt weer geen aandacht...

[Koenvh]

@Immutable Klopt. Maar ik ben zelden projecten tegengekomen die precies in één straatje passen, en in dat soort gevallen is een beetje flexibiliteit wel handig. Sommige dingen kun je van tevoren aan zien komen (Python op embedded hardware is niet het beste idee), maar sommige dingen weet je van tevoren niet. Je kunt bijvoorbeeld best een Web API maken in PHP, en er dan achter komen dat een bepaalde request een stuk sneller afgehandeld kan worden als bepaalde berekeningen in parallel worden gedaan. Dan kun je wel zeggen "maar daar is PHP niet voor gemaakt", maar dat is dan op dat moment niet zo belangrijk. En om dan maar het geheel in een andere taal te herschrijven (en daar weer tegen andere problemen aan te lopen) is ook niet handig.

@RayNbow Da's een feit

[Mugwump]

Immutable schreef op zondag 11 augustus 2019 @ 10:40:
[...]


Zo heeft elke taal tekortkomingen. Na een tijd zie je gewoon in "waarom" een bepaalde taal is gemaakt. En voor welke doeleinde een taal is. Je ziet nog veel mensen die een taal kiezen van.. omdat je die taal toevallig kent. En dan het product gaan maken.

Je moet kijken wat je gaat maken, en daar de taal voor uitkiezen. Ik zie dit vaak gebeuren in bijvoorbeeld de industrie of men gaat een product maken met C# om die dan te verkopen. Ik decompile je project zo en jat je source code muhahaha.
Of dat men in de industrie talen gaat gebruiken met een Garbage Collector en dan erachter komt dat hard-realtime zaken niet werken! no shit.
Of dat men performance gerelateerde programma's in bytecode talen zoals C# Java of Scripttalen gaat programmeren in plaats van C/C++/Rust o.i.d. En dan gaat zeuren over performance en dan HEEL VEEL tijd steken in het optimaliseren van de GC en of optimaliseren van de byte / script code.
Of stukjes herschrijven betreft performance code in C voor python wat ik dan.. wel kan snappen.

En PHP is met een heel duidelijk doel gemaakt. De afkorting stond voor Personal Home Page. Het was bedoeld als laagdrempelige manier om je eigen homepage in elkaar te kunnen knutselen en daar is het ook glansrijk in geslaagd. Wat PHP volgens Lerdorf expliciet niet zou zijn? Een programmeertaal.
Het is vervolgens wel geëvolueerd tot programmeertaal waarin best wat concepten geïntroduceerd zijn, maar het blijft in mijn ogen toch heel gekunsteld aanvoelen. Kijk alleen al naar de manier waarop met static methods in classes wordt omgegaan. Je krijgt dus een taal waarin je dus in theorie wel een soort van fatsoenlijk OO kunt programmeren, maar waarbij je veel zaken weer expliciet moet gaan afdwingen, terwijl dat in C# of Java gewoon fundamenteel ingebakken zit (niet dat er op die talen niets aan te merken valt). En Java en .Net zijn op veel vlakken ook een stuk laagdrempeliger geworden. Met een paar commando's heb je een Spring boot hello world app draaien bijvoorbeeld, waar je vroeger eerst moest gaan uitzoeken hoe applicatieservers werkten, hoe allerhande frameworks in elkaar zaten en ga zo maar door.
De kracht van PHP was het laagdrempelige en daarmee ook de beschikbaarheid van ontwikkelaars. (L/W)AMP stackje en je kon aan de slag met een simpele website. Deployen? Gewoon je source code (S)FTPen en klaar.
Ga je echt hele OO standaarden afdwingen, frameworks met DI, ORM en al dat soort zaken gebruiken, dependency management doen, build straten inrichten en ga zo maar door? Kies dan gewoon lekker voor Java of .Net zou ik zeggen.

Waarom kiezen mensen eerst een taal, en kijken dan naar de oplossing in plaats van andersom?

Men kent vaak vooral enkel één taal (afgezien van het feit dat men naast een 'back-end taal' meestal ook nog wel wat javascript kan kloppen).

Enige wat je moet weten is procedureel, functioneel en object georiënteerd programmeer concepten. De taal is maar een syntax? Toch? Maar dit leer je allemaal op school volgens mij dus iedereen die is afgestudeerd moet dit kunnen.
Smalltalk is bijvoorbeeld een redelijke pure vorm van Object georiënteerd programmeren. Hierin is Pharo de moderne opvolger van. Lisp is een redelijke pure vorm van functioneel programmeren. Hierin kun je Clojure/Haskell voor leren hedendaags. Procedureel natuurlijk FORTRAN, voor hedendaags kun je beste daarvoor C gebruiken om te leren.

Dus leer voor de lol een beetje Pharo / ClojureofHaskell / C. Dan kan je zo elke andere syntax aanleren.

Ik heb WO TI gestudeerd en dan ligt er echt nauwelijks focus op het leren van specifieke talen. Je leert inderdaad de basisconcepten uit de verschillende paradigma, algoritmen en ga zo maar door. Dat je dan toevallig in Java, C(++), Haskell of Prolog doet is dan feitelijk niet zo relevant. Dat zorgt er ook voor dat je in de praktijk heel makkelijk met nieuwe talen aan de slag kunt.
Lang niet iedereen heeft echter een dergelijke meer formele opleiding op zak. De IT kent heel veel mensen die een meer toegepaste opleiding hebben gedaan waar je echt specifieke talen leert of omgeschoolden / autodidacten die ook vooral geleerd hebben uit de praktijk. Daar is niets mis mee, maar dan zie je vaak wel dat mensen niet dat abstractieniveau hebben om over talen heen te kijken.

Meest vervelende talen zijn dan multi-paradigm talen. Hierin kun je verschillende concepten gebruiken, dit is zowel een voor als nadeel. Deze verschillende concepten mixen in je code is niet altijd een succes.

Vooral de hele strikte logische en functionele talen zijn nog vrij puur. Eigenlijk is het gros van de talen die veel gebruikt worden wel 'multi-paradigm' tegenwoordig.
Je krijgt dan wel dit soort zaken.

Het grappige aan oude talen is, dat ze nog steeds hele goed bedachte dingen bevatten die NU pas bijvoorbeeld zijn intrede doen in moderne talen. Metaclasses van Smalltalk komt waarschijnlijk pas in C++23 in de taal.

Er zijn in mijn ogen ook geen hele fundamentele zaken 'ontdekt' in de informatica sinds de jaren '70 / '80. De 'trucjes' in de hedendaagse machine learning stammen eigenlijk gewoon uit die tijd alleen heeft men er vandaag de dag wél de rekenkracht voor. NoSql? Eigenlijk werd SQL pas in de jaren '80 ergens de facto de standaard in veel systemen, daarvoor waren die andere vormen van opslag ook gewoon in gebruik. De reden dat die weer terug zijn is de (noodgedwongen) trend van decentralisatie de laatste jaren.

[Whaam]

Hoi! Is dit het juiste topic om wat vragen te stellen over een arbeidsvoorwaardengesprek? Ik sta op het punt een baan aanbod te accepteren bij een detacheerder, maar ik heb totnogtoe alleen in loondienst gewerkt. En ik kom er niet helemaal uit in m'n eentje...

[Marc3l]

Ah de PHP discussie duikt weer op . Werk al +15 jaar met PHP. Zolang ik er nog plezier in heb en wij er zeer goed mee verdienen zal het mij een zorg zijn hoe goed/slecht het is
Diegene die het bashen en niet meer mee werken maken zich er het meeste druk om.

[dcm360]

Whaam schreef op zondag 11 augustus 2019 @ 14:54:
Hoi! Is dit het juiste topic om wat vragen te stellen over een arbeidsvoorwaardengesprek? Ik sta op het punt een baan aanbod te accepteren bij een detacheerder, maar ik heb totnogtoe alleen in loondienst gewerkt. En ik kom er niet helemaal uit in m'n eentje...

Dat hoort meer thuis in Persoonlijke Financiën, Studie en Loopbaan . Misschien kan je daar ook al (deels) antwoord op jouw vragen vinden.

[Whaam]

dcm360 schreef op zondag 11 augustus 2019 @ 14:59:
[...]

Dat hoort meer thuis in Persoonlijke Financiën, Studie en Loopbaan . Misschien kan je daar ook al (deels) antwoord op jouw vragen vinden.

Ah, cheers, probeer ik het daar! Ik kom er zelf met Google en zoeken in Tweakers niet helemaal uit helaas.

[Mugwump]

Bij een detacheerder werk je toch ook gewoon in loondienst?

[Whaam]

Mugwump schreef op zondag 11 augustus 2019 @ 15:01:
Bij een detacheerder werk je toch ook gewoon in loondienst?

Ja, eigenlijk wel ja. Alleen geeft deze detacheerder aan dat ze onder de uitzendwetgeving vallen, dat is dan weer geen loondienst. Ik bevind me ietwat op onbekend terrein hier.

[Mugwump]

Whaam schreef op zondag 11 augustus 2019 @ 15:20:
[...]


Ja, eigenlijk wel ja. Alleen geeft deze detacheerder aan dat ze onder de uitzendwetgeving vallen, dat is dan weer geen loondienst. Ik bevind me ietwat op onbekend terrein hier.

Hmm, als ik dat soort zaken hoor, dan gaan er bij mij persoonlijk toch wel wat alarmbellen af.
Dat soort wetgeving is echt niet in het voordeel van de werknemer doorgaans.

[Janoz]

Douweegbertje schreef op woensdag 7 augustus 2019 @ 12:01:
[...]


Ja misschien moet ik ook geen exacte voorbeelden geven van een taal waar ik amper kennis van heb

Heeft niks met de taal te maken. Middels CGI is zo ongeveer alles te gebruiken om een dynamische pagina te serveren. Zou zelfs met BAT files kunnen.

[wackmaniac]

Nog mensen van booking.com hier? https://www.volkskrant.nl...om-het-is-een-grote-chaos

[CurlyMo]

wackmaniac schreef op maandag 12 augustus 2019 @ 08:55:
Nog mensen van booking.com hier? https://www.volkskrant.nl...om-het-is-een-grote-chaos

Waarom klagen over PHP als je Perl kan gebruiken

[ThomasG]

CurlyMo schreef op maandag 12 augustus 2019 @ 09:05:
[...]

Waarom klagen over PHP als je Perl kan gebruiken

Wees blij dat ze het niet in COBOL via CGI gemaakt hebben

[Mugwump]

wackmaniac schreef op maandag 12 augustus 2019 @ 08:55:
Nog mensen van booking.com hier? https://www.volkskrant.nl...om-het-is-een-grote-chaos

Ik dacht dat ze daar inmiddels wel aardige stappen aan het maken waren om Perl uit te faseren. Dat begreep ik tenminste een aantal jaar terug van mensen die er werkten.

[BarôZZa]

Mugwump schreef op zondag 11 augustus 2019 @ 14:01:
[...]


En PHP is met een heel duidelijk doel gemaakt. De afkorting stond voor Personal Home Page. Het was bedoeld als laagdrempelige manier om je eigen homepage in elkaar te kunnen knutselen en daar is het ook glansrijk in geslaagd. Wat PHP volgens Lerdorf expliciet niet zou zijn? Een programmeertaal.
Het is vervolgens wel geëvolueerd tot programmeertaal waarin best wat concepten geïntroduceerd zijn, maar het blijft in mijn ogen toch heel gekunsteld aanvoelen. Kijk alleen al naar de manier waarop met static methods in classes wordt omgegaan. Je krijgt dus een taal waarin je dus in theorie wel een soort van fatsoenlijk OO kunt programmeren, maar waarbij je veel zaken weer expliciet moet gaan afdwingen, terwijl dat in C# of Java gewoon fundamenteel ingebakken zit (niet dat er op die talen niets aan te merken valt). En Java en .Net zijn op veel vlakken ook een stuk laagdrempeliger geworden. Met een paar commando's heb je een Spring boot hello world app draaien bijvoorbeeld, waar je vroeger eerst moest gaan uitzoeken hoe applicatieservers werkten, hoe allerhande frameworks in elkaar zaten en ga zo maar door.
De kracht van PHP was het laagdrempelige en daarmee ook de beschikbaarheid van ontwikkelaars. (L/W)AMP stackje en je kon aan de slag met een simpele website. Deployen? Gewoon je source code (S)FTPen en klaar.
Ga je echt hele OO standaarden afdwingen, frameworks met DI, ORM en al dat soort zaken gebruiken, dependency management doen, build straten inrichten en ga zo maar door? Kies dan gewoon lekker voor Java of .Net zou ik zeggen.

Leuk dat hele verhaal over Personal Home Page en dergelijke, maar dat zijn de beginjaren en inmiddels zijn we natuurlijk ruim 20 jaar verder, is PHP gewoon een volwaardige programmeertaal met een marktaandeel van pakweg 80% op het web, van klein tot enterprise. Source code SFTP'en heb ik ook al jaren niet meer gezien, misschien dat het nog gebeurt bij partijen die Wordpressjes in elkaar knutselen. Zaken als OO, DI, ORM en dergelijke zijn al tijden gemeengoed.

Wat PHP zo sterk maakt is dat het vanaf het begin af aan ontwikkeld is voor het web. Heb door de jaren heen met vele programmeertalen gestoeid(van Basic tot Java, C, Objective C etc), maar voor het web grijp ik in veel gevallen naar PHP en JavaScript.

Mugwump schreef op zondag 11 augustus 2019 @ 14:01:
[...]

Ik heb WO TI gestudeerd en dan ligt er echt nauwelijks focus op het leren van specifieke talen. Je leert inderdaad de basisconcepten uit de verschillende paradigma, algoritmen en ga zo maar door. Dat je dan toevallig in Java, C(++), Haskell of Prolog doet is dan feitelijk niet zo relevant. Dat zorgt er ook voor dat je in de praktijk heel makkelijk met nieuwe talen aan de slag kunt.

De basisconcepten zijn inderdaad gelijk, maar elke taal heeft haar eigen nuances en eigenaardigheden. Als je Frans spreekt kan je makkelijker Spaans leren, maar het duurt wel wat jaar voordat je foutloos een boek kan schrijven zonder continu het woordenboek erbij te pakken.

Marc3l schreef op zondag 11 augustus 2019 @ 14:57:
Ah de PHP discussie duikt weer op . Werk al +15 jaar met PHP. Zolang ik er nog plezier in heb en wij er zeer goed mee verdienen zal het mij een zorg zijn hoe goed/slecht het is
Diegene die het bashen en niet meer mee werken maken zich er het meeste druk om.

Dito, ik vind het vaak ook gewoon lekkerder werken. Voor veel toepassingen heb ik sneller iets in PHP gebouwd dan in de meeste andere talen.

[ElkeBxl]

Marc3l schreef op zondag 11 augustus 2019 @ 14:57:
Ah de PHP discussie duikt weer op

* ElkeBxl voelt haar weer helemaal thuis hier in de coffee corner met de PHP discussie en vraagt haar af wanneer er weer over mechanische keyboards wordt gepraat...

[Mugwump]

BarôZZa schreef op maandag 12 augustus 2019 @ 15:45:
[...]

Leuk dat hele verhaal over Personal Home Page en dergelijke, maar dat zijn de beginjaren en inmiddels zijn we natuurlijk ruim 20 jaar verder, is PHP gewoon een volwaardige programmeertaal met een marktaandeel van pakweg 80% op het web, van klein tot enterprise. Source code SFTP'en heb ik ook al jaren niet meer gezien, misschien dat het nog gebeurt bij partijen die Wordpressjes in elkaar knutselen. Zaken als OO, DI, ORM en dergelijke zijn al tijden gemeengoed.

Ik stel dan ook vrij duidelijk dat de taal zich wel ontwikkeld heeft, maar veel concepten erg halfbakken geïmplementeerd zijn en ik daardoor geen reden zie om voor PHP te kiezen boven de alternatieven.

Wat PHP zo sterk maakt is dat het vanaf het begin af aan ontwikkeld is voor het web. Heb door de jaren heen met vele programmeertalen gestoeid(van Basic tot Java, C, Objective C etc), maar voor het web grijp ik in veel gevallen naar PHP en JavaScript.

Waarom maakt het dat zo sterk? Waar is het zo superieur ten opzichte van bijvoorbeeld Java, Kotlin of C#?

[...]

De basisconcepten zijn inderdaad gelijk, maar elke taal heeft haar eigen nuances en eigenaardigheden. Als je Frans spreekt kan je makkelijker Spaans leren, maar het duurt wel wat jaar voordat je foutloos een boek kan schrijven zonder continu het woordenboek erbij te pakken.

Ach, dat valt reuze mee als je het over de gangbare talen hebt. Talen waarbij je zelf memory management moet doen of pure functionele of logische talen zullen voor veel mensen die gewend zijn aan één van de "OO talen met wat functionele dingetjes", maar binnen die laatste categorie is het vrij makkelijk switchen.
Ja je moet even wat meer opzoeken, maar een goede IDE helpt daar flink.

[gekkie]

ThomasG schreef op maandag 12 augustus 2019 @ 09:11:
[...]
Wees blij dat ze het niet in COBOL via CGI gemaakt hebben

Say what ?
http://opencobol.add1tocobol.com/gnucobolcgi/gnucgiform.html

CurlyMo schreef op maandag 12 augustus 2019 @ 09:05:
[...]
Waarom klagen over PHP als je Perl kan gebruiken

Gisteren nog ergens een kranten rant gelezen over werken bij booking.com, waarbij een hoop nog pi pa perl schijnt te zijn.

[ Voor 36% gewijzigd door gekkie op 12-08-2019 16:53 ]

[Merethil]

gekkie schreef op maandag 12 augustus 2019 @ 16:51:
[...]

Say what ?
http://opencobol.add1tocobol.com/gnucobolcgi/gnucgiform.html


[...]

Gisteren nog ergens een kranten rant gelezen over werken bij booking.com, waarbij een hoop nog pi pa perl schijnt te zijn.

Je bedoelt deze?

wackmaniac schreef op maandag 12 augustus 2019 @ 08:55:
Nog mensen van booking.com hier? https://www.volkskrant.nl...om-het-is-een-grote-chaos

[Janoz]

BarôZZa schreef op maandag 12 augustus 2019 @ 15:45:
[...]

Leuk dat hele verhaal over Personal Home Page en dergelijke, maar dat zijn de beginjaren en inmiddels zijn we natuurlijk ruim 20 jaar verder, is PHP gewoon een volwaardige programmeertaal met een marktaandeel van pakweg 80% op het web, van klein tot enterprise. Source code SFTP'en heb ik ook al jaren niet meer gezien, misschien dat het nog gebeurt bij partijen die Wordpressjes in elkaar knutselen. Zaken als OO, DI, ORM en dergelijke zijn al tijden gemeengoed.

Maar wat is het nut van ORM en DI wanneer je alleen maar request-scope hebt? Het komt op mij altijd zo enorm inefficiënt over om eerlijk te zijn.

Dito, ik vind het vaak ook gewoon lekkerder werken. Voor veel toepassingen heb ik sneller iets in PHP gebouwd dan in de meeste andere talen.

Ik denk dat dat vooral iets over jou zegt dan over de taal. En dat bedoel ik niet negatief! Ik bijvoorbeeld zou, wanneer ik vanaf scratch begin, misschien wel sneller iets hebben met Spring Boot, maar dat zegt helemaal niks over Spring Boot.

[Janoz]

wackmaniac schreef op maandag 12 augustus 2019 @ 08:55:
Nog mensen van booking.com hier? https://www.volkskrant.nl...om-het-is-een-grote-chaos

Wat ik nog het meest hilarische vind is de reactie van Booking.com zelf icm de scores.

In de reactie allemaal hoger management* dat zich niet herkend in de kritiek, en vervolgens eronder zie je dat juist senior management de allerlaagste score krijgt!. Disconnected form the workfloor much??

*
• bestuursvoorzitter,
• hoofd Commercial Operations,
• een hooggeplaatste ict’er,
• uit Amerika afkomstige hoge manager

[wackmaniac]

Janoz schreef op maandag 12 augustus 2019 @ 17:23:
[...]

Maar wat is het nut van ORM en DI wanneer je alleen maar request-scope hebt? Het komt op mij altijd zo enorm inefficiënt over om eerlijk te zijn.

De scope betekent natuurlijk niet dat je code niet netjes en op orde hoeft te zijn. Zelfs in kleine serveless applicaties in javascript gebruik ik dependency injection, omdat het de boel nu eenmaal makkelijker testbaar en flexibeler maakt.

[Janoz]

Netjes of niet netjes, het ging me voornamelijk over de efficiëntie. Voor elk request weer één of ander framework inladen die vervolgens je halve (of nog erger, hele) applicatie aan elkaar aan het rijgen is, nog voordat je maar een clockcycle besteed hebt aan je daadwerkelijke functionaliteit. Maar goed, ik ken (modern?) php dan ook weer niet goed. Vandaar ook mijn oprechte vraag.

En daarnaast leeft je javascript code over het algemeen langer dan een php proces. DI geeft dan relatief veel minder overhead.

[gekkie]

Janoz schreef op maandag 12 augustus 2019 @ 17:42:
[...]
Wat ik nog het meest hilarische vind is de reactie van Booking.com zelf icm de scores.

In de reactie allemaal hoger management* dat zich niet herkend in de kritiek, en vervolgens eronder zie je dat juist senior management de allerlaagste score krijgt!. Disconnected form the workfloor much??

*
• bestuursvoorzitter,
• hoofd Commercial Operations,
• een hooggeplaatste ict’er,
• uit Amerika afkomstige hoge manager

Dat artikel inderdaad.

Maar wel een diversity mafkees en een snookertafel. Achja.
Gelukkig heb ik de toekomst met "AI" in HR ook al mogen zien .. .

[CurlyMo]

gekkie schreef op maandag 12 augustus 2019 @ 16:51:
[...]
Gisteren nog ergens een kranten rant gelezen over werken bij booking.com, waarbij een hoop nog pi pa perl schijnt te zijn.

Gelezen waar ik op reageerde

[Barryvdh]

Janoz schreef op maandag 12 augustus 2019 @ 18:08:
Netjes of niet netjes, het ging me voornamelijk over de efficiëntie. Voor elk request weer één of ander framework inladen die vervolgens je halve (of nog erger, hele) applicatie aan elkaar aan het rijgen is, nog voordat je maar een clockcycle besteed hebt aan je daadwerkelijke functionaliteit. Maar goed, ik ken (modern?) php dan ook weer niet goed. Vandaar ook mijn oprechte vraag.

En daarnaast leeft je javascript code over het algemeen langer dan een php proces. DI geeft dan relatief veel minder overhead.

In php zijn er ook steeds meer frameworks die het framework enzo in hun geheugen houden en asynchroon alles afhandelen, zoals Swoole. https://www.swoole.co.uk

Maar wie heeft het nog over PHP als we (bijna) P++ hebben? https://wiki.php.net/pplusplus/faq

[CurlyMo]

Barryvdh schreef op maandag 12 augustus 2019 @ 20:43:
[...]
Maar wie heeft het nog over PHP als we (bijna) P++ hebben? https://wiki.php.net/pplusplus/faq

Misschien is het typisch PHP, maar ik vind die pagina verre van helder geschreven

[Barryvdh]

CurlyMo schreef op maandag 12 augustus 2019 @ 20:46:
[...]

Misschien is het typisch PHP, maar ik vind die pagina verre van helder geschreven

Nou volgens mij is het hele voorstel een beetje verwarrend, maar dat is niet vanuit PHP zelf maar vanaf die ontwikkelaar alleen (dacht ik)

[gekkie]

CurlyMo schreef op maandag 12 augustus 2019 @ 19:18:
[...]

Gelezen waar ik op reageerde

Euh nee ? Vertel !

[BarôZZa]

Waarom maakt het dat zo sterk? Waar is het zo superieur ten opzichte van bijvoorbeeld Java, Kotlin of C#?

Ik zeg nergens dat het superieur is. Ik zeg dat ik er sneller mee werk voor de toepassingen die ik maak. Het is een tool net zoals alle talen.

Zelf heb ik het idee dat ik in andere talen meer code moet schrijven voor veel zaken die je in PHP met een paar regels hebt gefikst.

Of het nu een functie schrijven is met optionele parameters met een default waarde, of een remote file downloaden en parsen als json, of werken met multidimensionale dynamische arrays, of een CLI script schrijven, of werken met sessions.

Verder heb je de workflow waarbij je, afhankelijk van de applicatie, niet altijd hoeft te compilen en dergelijke om je changes meteen te zien. Bij mijn huidige werkgever is het een bestandje aanpassen en F5 in de browser. Afhankelijk van wat je maakt kan ook hosting een rol spelen. Als je een applicatie wil maken die op zoveel mogelijk webservers kan draaien, dan zit je prima bij PHP. Wordpress, Magento etc waren nooit zo populair geworden als ze in Java waren geschreven.

Daarnaast runt het als script, wat het ideaal maakt voor het web. Request -> verwerking -> output, klaar.

Ach, dat valt reuze mee als je het over de gangbare talen hebt. Talen waarbij je zelf memory management moet doen of pure functionele of logische talen zullen voor veel mensen die gewend zijn aan één van de "OO talen met wat functionele dingetjes", maar binnen die laatste categorie is het vrij makkelijk switchen.
Ja je moet even wat meer opzoeken, maar een goede IDE helpt daar flink.

Als je xx jaar ervaring met een taal hebt, dan is dat opzoeken gewoon een productiviteitskiller. Daarnaast mis je alle kennis van frameworks en libraries en zaken die gewoon verschillen.

Janoz schreef op maandag 12 augustus 2019 @ 17:23:
[...]

Maar wat is het nut van ORM en DI wanneer je alleen maar request-scope hebt? Het komt op mij altijd zo enorm inefficiënt over om eerlijk te zijn.

(database)abstractie, testing en loose coupling. Relatief inefficiënt als het om performance gaat, maar het zorgt voor leesbare code en in het geval van ORM is de database query vrijwel altijd de bottleneck en niet de mapping.

Ik denk dat dat vooral iets over jou zegt dan over de taal. En dat bedoel ik niet negatief! Ik bijvoorbeeld zou, wanneer ik vanaf scratch begin, misschien wel sneller iets hebben met Spring Boot, maar dat zegt helemaal niks over Spring Boot.

Deels mee eens. Natuurlijk speelt ervaring mee, maar ik heb wel degelijk ervaring met andere talen en doe daar in mijn vrije tijd ook dingen mee, maar de kracht van PHP is de balans tussen zaken snel en elegant kunnen oplossen. Let op: dit geldt specifiek het web, waar je in veel gevallen een applicatie hebt die met een database werkt en zoals ik hierboven zei: request -> verwerking -> output, klaar.

Janoz schreef op maandag 12 augustus 2019 @ 18:08:
Netjes of niet netjes, het ging me voornamelijk over de efficiëntie. Voor elk request weer één of ander framework inladen die vervolgens je halve (of nog erger, hele) applicatie aan elkaar aan het rijgen is, nog voordat je maar een clockcycle besteed hebt aan je daadwerkelijke functionaliteit. Maar goed, ik ken (modern?) php dan ook weer niet goed. Vandaar ook mijn oprechte vraag.

En daarnaast leeft je javascript code over het algemeen langer dan een php proces. DI geeft dan relatief veel minder overhead.

Je hebt gelijk wat efficiëntie betreft, maar hebt weer het voordeel dat requests geen invloed op elkaar hebben. Als de ene vastloopt, dan loopt de applicatie voor de rest niet in de soep. Je hebt ook minder last van zaken als memoryleaks. Het zorgt ervoor dat developers, en zeker de mindere goden, zich kunnen focussen op het bouwen van de functionaliteit zonder zich veel zorgen te maken om hoe het systeem blijft werken als er ineens tig mensen tegelijk gebruik van maken. Dat is voor veel developers al uitdagend genoeg heb ik gemerkt.

Verder kan je veel zaken al met slimme caching omzeilen. Wil je realtime applicaties bouwen, dan is PHP vaak niet de beste oplossing. Maar veel zaken op het web bestaan uit pakweg een formulier met data die verstuurd wordt en vervolgens wordt verwerkt. Of dat een seconde duurt maakt niet altijd uit.

En als het over javascript gaat: als bijvoorbeeld een webworker in een zeer specifieke situatie blijft hangen, dan ga je mij niet wijsmaken dat dat fijn debuggen is . Goed met concurrency omgaan kost veel mentale capaciteit en is voor sommige developers zelfs simpelweg niet te doen. Dat is een van de redenen waarom PHP zo populair is.

[AW_Bos]

Ik zit weer eens in een heerlijke discussie met iemand over het omrekenen van een UTC-tijd in PHP in de database naar tijdzones. Ikzelf vind dat je dit prima in een database-query kan doen, en met name omdat je hier makkelijk mee kan rekenen.

Maar de ander zegt dat je dit beter op presentatielaag moet doen, en met PHP (REQUEST_TIME) de juiste tijd moet pakken om de tijd in de database te mikken, en met de DateTime class uit te lezen en te converteren.

Beide mogelijkheden kunnen, maar is er een ongeschreven regel die zegt dat 'zus' of 'zo' het beste is?

[CurlyMo]

@AW_Bos Ze zijn beide te verdedigen zoals je had gemerkt Ik zou het zelf in de database doen, maar dat komt meer door mijn sql expertise. Ik kan me echter ook indenken dat je bij tijdzone specifieke templates het in de presentatie laag doet. Bijv. Rusland een heel andere layout dan Amerika en China weer anders dan Nederland.

[Douweegbertje]

Janoz schreef op maandag 12 augustus 2019 @ 18:08:
Netjes of niet netjes, het ging me voornamelijk over de efficiëntie. Voor elk request weer één of ander framework inladen die vervolgens je halve (of nog erger, hele) applicatie aan elkaar aan het rijgen is, nog voordat je maar een clockcycle besteed hebt aan je daadwerkelijke functionaliteit. Maar goed, ik ken (modern?) php dan ook weer niet goed. Vandaar ook mijn oprechte vraag.

En daarnaast leeft je javascript code over het algemeen langer dan een php proces. DI geeft dan relatief veel minder overhead.

Het stukje efficientie is niet zo heel relevant op dat niveau. Dat komt inherent uit je gedachte gang van het niet hebben van PHP ervaring volgens mij. Ten eerste laad je niets, zeker niet heel het framework. Je flowt langs de files als het ware. Daarvoor is eigenlijk opcache: https://www.php.net/manual/en/intro.opcache.php

Niet dat ik het nu exact heb getest maar ook al zou je 100 files "includen" die allemaal een echo doen, dan merk je hier vrijwel niets van in je execution time. Je execution time gaat pas hoger worden op het moment dat je bijv een array gaat fetchen met 100000 items en hier 3x over heen loopt.

Wat ik nu eigenlijk wil zeggen is dat "code optimalisaties" op een totaal ander niveau zitten dan bijv. een applicatie in Java of C#.. Bijvoorbeeld hoe je if statements noteert, je kan dat op de snelle en op de inefficiente manier doen. Zie ik dat terug in een request in PHP? nope.

Zodra je dingen met een database gaat doen, of "berekeningen" moet uitvoeren, is het handig om hier fatsoenlijk mee om te gaan. Ipv 100000 items uit de DB te fetchen gebruik je ORM en doe je dat in stukjes op exact de data die je wilt. En dat gaat snel. Desnoods ga je hier weer cachen... query cache.
Of je hebt al meuk in memcache zitten.

En vervolgens kijk je wat voor meuk je moet serveren. Je kan een pagina ook indelen in "blocks" en deze cachen, waarna je alleen nog een dynamisch blokje moet uitvoeren.
In de basis kan je gewoon PHP -> html static file doen als "cache". Echter gebruik ik zelf eigenlijk altijd Varnish.
Voor overige meuk zoals sessions, wat zowel via filecache als database kan, doe ik dat vaak via Redis.

PHP op zich zelf kan niet zo super veel, je hebt daar je "tools" voor benodigd zoals ik hier al in het begin zei. Uiteraard kan je voor een basis website prima af zonder die tools, maar ik heb websites gehost en aan mee ontwikkeled voor echt high traffic. Dan pak je er gewoon de juiste tools bij en dan heb je echt 0 problemen.

Een mooi voorbeeld is Intershop, wat een webshop is geschreven in Java. Ik outperform dat met Magento2 (PHP based) constant. Niet omdat de code nou zo awesome is, maar vanwege alle tooling eromheen. Dat ook overigens ook voor minder resources...
Persoonlijk hou ik echt niet van de code-base van Magento2, maar net zo goed weet ik dat men ook veel issues heeft met zijn Java variant intershop. Desalnietemin kan je beide prima draaien.

Maar is het nu een flaw vanuit PHP dat je die tools "moet" hebben? Ik vind persoonlijk van niet. Laat PHP lekker "dom" zijn en los de rest op met bewezen fatsoenlijke tools. Ik heb liever Varnish dan dat een applicatie dat "intern" doet. Dit geeft je zoveel meer ruimte voor de setup en veranderingen. Ik kan morgen Varnish vervangen voor nginx cache. Zeker ook met het stukje "cloud native" en containers in je achterhoofd.

Om weer een voorbeeld te geven, de Atlassian producten; jira, bitbucket, confluence. Lekkere java bakjes waar iedereen op zit te zeiken dat het niet vooruit te branden is (google maar). Het werkt wel, met x-gebruikers. Maar jira cloud is bijvoorbeeld echt een doorn in het oog. Daarna kan je alleen maar een dikke memory bak opzetten met veel heap en dan maar duimen dat het iets beter gaat. Nu is dit ook weer een eenzijdig zwart-wit verhaaltje van mij, maar mijn ervaring met non-PHP web applicaties zijn over het algemeen alleen slecht geweest

[ThomasG]

AW_Bos schreef op maandag 12 augustus 2019 @ 23:03:
Ik zit weer eens in een heerlijke discussie met iemand over het omrekenen van een UTC-tijd in PHP in de database naar tijdzones. Ikzelf vind dat je dit prima in een database-query kan doen, en met name omdat je hier makkelijk mee kan rekenen.

Maar de ander zegt dat je dit beter op presentatielaag moet doen, en met PHP (REQUEST_TIME) de juiste tijd moet pakken om de tijd in de database te mikken, en met de DateTime class uit te lezen en te converteren.

Beide mogelijkheden kunnen, maar is er een ongeschreven regel die zegt dat 'zus' of 'zo' het beste is?

Ik ben het er wel mee is dat dit in de presentatielaag moet, het is namelijk een presentatie detail. En in veel gevallen, zoals een API, is een UTC datum in ISO 8601 de beste oplossing. Wil je echter de datum omrekenen naar bijvoorbeeld de lokale tijd van de gebruiker, dan is dat een presentatie detail. Het nadeel van het in de query doen, is dat je bij elke query de tijdzone moet opgeven, en dat je de resultaten van de query en resultaten niet kunt cachen; of je moet dat voor iedere tijdzone doen. Wat nu als de resultaten via een microservice binnen komen, geef je dan in de request op welke tijdzone je wilt? Het voordeel van het in de presentatielaag doen is dat je meer flexibiliteit hebt. Of ga je de opmaak van de datum ook in de query doen? En als je de datum zowel kort als lang wilt weergeven, dat twee keer doen?

[DevWouter]

AW_Bos schreef op maandag 12 augustus 2019 @ 23:03:
Ik zit weer eens in een heerlijke discussie met iemand over het omrekenen van een UTC-tijd in PHP in de database naar tijdzones. Ikzelf vind dat je dit prima in een database-query kan doen, en met name omdat je hier makkelijk mee kan rekenen.

Maar de ander zegt dat je dit beter op presentatielaag moet doen, en met PHP (REQUEST_TIME) de juiste tijd moet pakken om de tijd in de database te mikken, en met de DateTime class uit te lezen en te converteren.

Beide mogelijkheden kunnen, maar is er een ongeschreven regel die zegt dat 'zus' of 'zo' het beste is?

Wat het "beste is" kan heel erg afhankelijk zijn van de situatie afhankelijk zijn. Loopt de webserver en database synchroon qua tijd? Wie kan de extra CPU cycles missen? Zijn tijdzones überhaupt interessant?

Persoonlijk zou ik geen UTC tijd in de database stoppen, maar de tijd plus tijdzone (eigenlijk heb je ook de locatie nodig want landen veranderen regelmatig van tijdzones. De laatste was nog geen 2 maanden geleden).

[Douweegbertje]

ThomasG schreef op dinsdag 13 augustus 2019 @ 09:15:
[...]
Ik ben het er wel mee is dat dit in de presentatielaag moet, het is namelijk een presentatie detail. En in veel gevallen, zoals een API, is een UTC datum in ISO 8601 de beste oplossing. Wil je echter de datum omrekenen naar bijvoorbeeld de lokale tijd van de gebruiker, dan is dat een presentatie detail. Het nadeel van het in de query doen, is dat je bij elke query de tijdzone moet opgeven, en dat je de resultaten van de query en resultaten niet kunt cachen; of je moet dat voor iedere tijdzone doen. Wat nu als de resultaten via een microservice binnen komen, geef je dan in de request op welke tijdzone je wilt? Het voordeel van het in de presentatielaag doen is dat je meer flexibiliteit hebt. Of ga je de opmaak van de datum ook in de query doen? En als je de datum zowel kort als lang wilt weergeven, dat twee keer doen?

IMO hangt het ook van de case af.
Betreft het een "Nederlandse applicatie" dan hoef je IMO niet veel spannende dingen te doen en is de datetime gewoon "as is". De voor- en nadelen zijn again IMO, vooral gericht op timezones. Wat als dat n.v.t. is? Het scheelt dan gewoon een stukje overhead om niets, echter wel met in je achterhoofd dat het uitbreiden lastiger wordt

[ThomasG]

Douweegbertje schreef op dinsdag 13 augustus 2019 @ 09:44:
[...]


IMO hangt het ook van de case af.
Betreft het een "Nederlandse applicatie" dan hoef je IMO niet veel spannende dingen te doen en is de datetime gewoon "as is". De voor- en nadelen zijn again IMO, vooral gericht op timezones. Wat als dat n.v.t. is? Het scheelt dan gewoon een stukje overhead om niets, echter wel met in je achterhoofd dat het uitbreiden lastiger wordt

Zelfs bij een "Nederlandse applicatie" heb je een probleem. De standaard tijdzone is namelijk +1, ofwel: de wintertijd. Maar wat nu als het zomertijd wordt? Het maakt niet zozeer uit in welke tijdzone je de datum opslaat, al het is het meest praktische is ze altijd in dezelfde tijdzone worden opgeslagen. Het weergeven is hoe dan ook een presentatie detail, ook bij een "Nederlandse applicatie". Of je ga rekening houden met de zomertijd in al je queries en business logic in de applicatie?

[dev10]

Douweegbertje schreef op dinsdag 13 augustus 2019 @ 08:55:
[...]

Om weer een voorbeeld te geven, de Atlassian producten; jira, bitbucket, confluence. Lekkere java bakjes waar iedereen op zit te zeiken dat het niet vooruit te branden is (google maar).

* dev10 is triggered.

Als ze bij Atlassian eens gingen focussen op snelheid in plaats van maar nieuwe functionaliteit toe blijven voegen, dan zou dat fantastisch zijn. Als je ziet hoe veel sneller GitHub, maar ook GitLab, is ten opzichte van BitBucket, dat is echt absurd.

Volgens mij moet je goud geld kunnen verdienen als je een pakket als Jira maakt, maar wat wel als een malle performt.

[Crazy D]

Wat je ook doet, zolang je een geboortedatum maar niet gaat omrekenen naar GMT bij het opslaan! Ooit een conversie gedaan vanuit MS Dynamics en daarin werd de geboortedatum van 13-08 00:00 opgeslagen als 12-08 23:00 (want ingevoerd in GMT+1) Vooral ook omdat je zelden een geboortetijdstip invoert (in business applicaties dan) echt heel logisch om dat terug te rekenen...

[Woy]

@Crazy D dat is het probleem van Date vs DateTime vs Time, dat probleem kom je inderdaad regelmatig tegen, aangezien niet alle platformen systemen daar standaard onderscheid in maken.

[Olaf van der Spek]

DevWouter schreef op dinsdag 13 augustus 2019 @ 09:42:
[...]


Wat het "beste is" kan heel erg afhankelijk zijn van de situatie afhankelijk zijn. Loopt de webserver en database synchroon qua tijd? Wie kan de extra CPU cycles missen? Zijn tijdzones überhaupt interessant?

Persoonlijk zou ik geen UTC tijd in de database stoppen, maar de tijd plus tijdzone (eigenlijk heb je ook de locatie nodig want landen veranderen regelmatig van tijdzones. De laatste was nog geen 2 maanden geleden).

Hoe sla jij tijdzones op in de DB?

Zelf sla ik altijd unix timestamps op met type int.

[gekkie]

DevWouter schreef op dinsdag 13 augustus 2019 @ 09:42:
[...]
Wat het "beste is" kan heel erg afhankelijk zijn van de situatie afhankelijk zijn. Loopt de webserver en database synchroon qua tijd? Wie kan de extra CPU cycles missen? Zijn tijdzones überhaupt interessant?

Persoonlijk zou ik geen UTC tijd in de database stoppen, maar de tijd plus tijdzone (eigenlijk heb je ook de locatie nodig want landen veranderen regelmatig van tijdzones. De laatste was nog geen 2 maanden geleden).

En we zijn er geloof ik met de EU ook nog niet helemaal uit wat "we" nou gaan doen qua tijdzones, voorlopig lekker geparkeerd geloof ik, zijn kennelijk weer interessantere zaken in de wereld aan de hand.


Hmm combinatie van spf, dkim, dmarc reports en mailinglists levert aardig wat mail terug op na een post op zo'n mailinglist. Zie je ook eens waar Abraham (met abo op de mailinglist) z'n mail allemaal host.

En datum tijd eigenlijk altijd als een Postgres timestamp with timezone; en in DB sessies altijd expliciet een tijdzone zetten zodat ik nergens een vage systeem tijdzone krijg die de handel als nog vernaggeld.

[ Voor 20% gewijzigd door gekkie op 13-08-2019 10:56 ]

[DevWouter]

Olaf van der Spek schreef op dinsdag 13 augustus 2019 @ 10:31:
[...]

Hoe sla jij tijdzones op in de DB?

Zelf sla ik altijd unix timestamps op met type int.

Probeer unix timestamps te vermijden, ze geven alleen maar het aantal secondes sinds 1-1-1970 aan en daarmee verlies je een heleboel informatie.

code:

915148800.75 => 1998-12-31T23:59:60.75
915148800.00 => 1999-01-01T00:00:00.00

Hoewel het eerste nummer groter is dan het tweede, verwijst het eerste nummer wel naar een dag eerder.
Als je dus een INT gebruikt betekent het dat 915148800 zowel kan refereren naar 31-12-1998 en naar 01-01-1999. En dat is afhankelijk van de implementatie.

Maar om antwoord te geven op je vraag.
MsSql: datetimeoffset
PostgreSql: time with time zone
MySql/MariaDb: Geen interne ondersteuning, je zult meerdere kolommen moeten aanmaken.

[NMH]

quote: https://knrs.iheart.com/c...-up-with-tons-of-tickets/

Droogie decided to buy a vanity California license plate that simply said "NULL," (...) he got dozens of other tickets in the mail as well. Apparently, when they didn't have the right data for a vehicle, a privately operated citation processing center used the word NULL in the license plate field for many tickets.

Little Bobby tables backfired.

[AW_Bos]

En ik maar denken dat een kenteken met DROP TABLE licenceplates; leuk was

Nu.nl bericht er ook al over:
https://www.nu.nl/tech/59...met-programmeursgrap.html

Dit doet me trouwens ook een beetje denken aan een creatieve bug in het CRM, tijdens mijn stageperiode. Bij het inboeken van binnengekomen producten in het magazijn kon je aangeven hoeveel producten je wou inboeken. En dit veld liet ik ooit eens per ongeluk op 0 staan.

Resultaat, de printer spuugde allemaal etiketten met logo, en zonder productgegevens uit

[ Voor 44% gewijzigd door AW_Bos op 14-08-2019 08:43 ]

[Onbekend]

Crazy D schreef op dinsdag 13 augustus 2019 @ 10:23:
Wat je ook doet, zolang je een geboortedatum maar niet gaat omrekenen naar GMT bij het opslaan! Ooit een conversie gedaan vanuit MS Dynamics en daarin werd de geboortedatum van 13-08 00:00 opgeslagen als 12-08 23:00 (want ingevoerd in GMT+1) Vooral ook omdat je zelden een geboortetijdstip invoert (in business applicaties dan) echt heel logisch om dat terug te rekenen...

Stel je voor dat je in de VS bent geboren ergens 's avonds laat, en verhuist naar Australië waardoor je 20 uur eerder op de zelfde dag jouw verjaardag kan vieren.

Hoe je de datum/tijd exact wil vastleggen is verschillend hoe je het wil en kan gebruiken. Een orderverzenddatum wil je bijvoorbeeld altijd in de huidige tijdzone houden, terwijl je verwachte leveringsdatum wel met tijdzones rekening moet houden.

[DevWouter]

Onbekend schreef op woensdag 14 augustus 2019 @ 09:05:
[...]

Stel je voor dat je in de VS bent geboren ergens 's avonds laat, en verhuist naar Australië waardoor je 20 uur eerder op de zelfde dag jouw verjaardag kan vieren.

Hoe je de datum/tijd exact wil vastleggen is verschillend hoe je het wil en kan gebruiken. Een orderverzenddatum wil je bijvoorbeeld altijd in de huidige tijdzone houden, terwijl je verwachte leveringsdatum wel met tijdzones rekening moet houden.

Om jouw punt kracht bij te zetten: Een geboortedatum en een verjaardag zijn ook twee verschillende dingen. Zo heb je maar 1 geboortedatum en tegelijkertijd heb je meerdere verjaardagen.
En in sommige landen/culturen is de "verjaring" gelijk aan het begin van het jaar. Als je wordt geboren op 1 december, dan heb je 1 maand later al de leeftijd van 1 jaar, terwijl je eigenlijk nog maar 1 maand oud bent. Je verjaardag en geboortedag hoeven dus niet eens hetzelfde te zijn (los van schrikkelgeboortes)

[ThomasG]

DevWouter schreef op woensdag 14 augustus 2019 @ 14:47:
[...]


Om jouw punt kracht bij te zetten: Een geboortedatum en een verjaardag zijn ook twee verschillende dingen. Zo heb je maar 1 geboortedatum en tegelijkertijd heb je meerdere verjaardagen.
En in sommige landen/culturen is de "verjaring" gelijk aan het begin van het jaar. Als je wordt geboren op 1 december, dan heb je 1 maand later al de leeftijd van 1 jaar, terwijl je eigenlijk nog maar 1 maand oud bent. Je verjaardag en geboortedag hoeven dus niet eens hetzelfde te zijn (los van schrikkelgeboortes)

Daarom vieren ze in veel landen ook hun "geboortedag": birthday, geburtstag, etc. etc. De meeste belgen noemen het ook de geboortedag. Alleen wij Nederlanders moeten het zo nodig de verjaardag noemen.

[Otherside1982]

ThomasG schreef op woensdag 14 augustus 2019 @ 16:41:
[...]
... De meeste belgen noemen het ook de geboortedag. Alleen wij Nederlanders moeten het zo nodig de verjaardag noemen.

Huh?? Als Belg heb ik echt nog nooit geboortedag gehoord. Het is gewoon verjaardag.

[AW_Bos]

Geboortedag is voor mij de dag waarop je geboren bent: Maandag, dinsdag, woensdag, etc....
De datum waarop je een geboorte op dezelfde datum herdenkt en viert, dat beschouw ik als een verjaardag.
_{Hier valt een schrikkeldag in februari niet onder, vind ik. Wel lullig als je dit maar om de vier jaar viert en herdenkt.}

En voor wie oud is en waarvan normaal gesproken de haren uitvallen, dan is het een verhaardag
_{Kanttekenening: Mij er buiten gesloten dan}

[ Voor 19% gewijzigd door AW_Bos op 14-08-2019 22:46 ]

[ThomasG]

AW_Bos schreef op woensdag 14 augustus 2019 @ 22:44:
Geboortedag is voor mij de dag waarop je geboren bent: Maandag, dinsdag, woensdag, etc....
De datum waarop je een geboorte op dezelfde datum herdenkt en viert, dat beschouw ik als een verjaardag.

[...]

Volgens diezelfde logica is een verjaardag de dag waarop je verjaart, ofwel: ook maandag, dinsdag, woensdag, etc. Het is gewoon raar dat vrijwel iedere taal ter wereld het de geboortedag noemt (in ieder geval de Europese talen), en wij Nederlanders het de verjaardag. Heb je ooit een Engelsman horen zeggen: Happy aging day!

[Olaf van der Spek]

DevWouter schreef op dinsdag 13 augustus 2019 @ 10:52:

code:

915148800.75 => 1998-12-31T23:59:60.75
915148800.00 => 1999-01-01T00:00:00.00

Hoewel het eerste nummer groter is dan het tweede, verwijst het eerste nummer wel naar een dag eerder.

Zeker weten? In dezelfde implementatie?

Seconde 60 is voor veel software sowieso problematisch.

Als je dus een INT gebruikt betekent het dat 915148800 zowel kan refereren naar 31-12-1998 en naar 01-01-1999. En dat is afhankelijk van de implementatie.

Welke implementaties geven "31-12-1998" terug?

Maar om antwoord te geven op je vraag.
PostgreSql: time with time zone

Daar wordt de tijdzone ook niet opgeslagen, de tijd wordt geconverteerd naar UTC.

[bwerg]

ThomasG schreef op donderdag 15 augustus 2019 @ 09:18:
Het is gewoon raar dat vrijwel iedere taal ter wereld het de geboortedag noemt (in ieder geval de Europese talen), en wij Nederlanders het de verjaardag. Heb je ooit een Engelsman horen zeggen: Happy aging day!

Heb je ooit een Engelsman horen praten over een "shield toad"? Zo nee, is "schildpad" dan raar? Welkom in de wondere wereld van natuurlijke talen. Nee, dan liever programmeertalen. Daarin gebeurt ten minste nooit iets raars.

Semantisch gezien is "verjaardag" logischer dan "geboortedag". Je verjaart daadwerkelijk op die dag. Je wordt er niet op geboren, dat was X jaar eerder.

[ Voor 12% gewijzigd door bwerg op 15-08-2019 10:10 ]

[Gropah]

ThomasG schreef op donderdag 15 augustus 2019 @ 09:18:
[...]
Heb je ooit een Engelsman horen zeggen: Happy aging day!

Nee, maar heb ze wel eens horen zeggen: Happy real life cake day



Ik bedoel, reddit is best wel interessant, maar om dat zo door te laten bloeden naar "het echte leven"...

[ThomasG]

Gropah schreef op donderdag 15 augustus 2019 @ 10:24:
[...]


Nee, maar heb ze wel eens horen zeggen: Happy real life cake day



Ik bedoel, reddit is best wel interessant, maar om dat zo door te laten bloeden naar "het echte leven"...

Het gaat er meer om: waarom wij het de verjaardag noemen, en andere talen de geboortedag. Ja, wij vieren daar hetzelfde mee. Maar dat is niet wat het oorspronkelijk betekende. Ooit is de Nederlandse taal van geboortedag (geburtstag) naar verjaardag (verjährtag) gegaan, maar alle andere Germaanse talen niet. Waarom? Dat wij daar nu hetzelfde mee bedoelen is in die discussie niet relevant. De toon is namelijk veranderd.

[bwerg]

ThomasG schreef op donderdag 15 augustus 2019 @ 10:40:
Dat wij daar nu hetzelfde mee bedoelen is in die discussie niet relevant.

Wat is er überhaupt zinnig aan een discussie over waarom een taal gevormd is zoals hij gevormd is? Waarom wordt "oe" hetzelfde uitgesproken als de Latijnse "u"? Waarom zijn bananen krom?

[RayNbow]

bwerg schreef op donderdag 15 augustus 2019 @ 10:08:
Nee, dan liever programmeertalen. Daarin gebeurt ten minste nooit iets raars.

🤔

[BarôZZa]

bwerg schreef op donderdag 15 augustus 2019 @ 10:08:
[...]

Heb je ooit een Engelsman horen praten over een "shield toad"? Zo nee, is "schildpad" dan raar? Welkom in de wondere wereld van natuurlijke talen. Nee, dan liever programmeertalen. Daarin gebeurt ten minste nooit iets raars.

Semantisch gezien is "verjaardag" logischer dan "geboortedag". Je verjaart daadwerkelijk op die dag. Je wordt er niet op geboren, dat was X jaar eerder.

We hebben natuurlijk ook nog gewoon 'date of birth' en 'geboortedatum' voor als we specifiek verwijzen naar het moment waarop je bent geboren.

Maar over dagen gesproken. In het mandarijn is maandag t/m zondag 'dag 1' tm 'dag 7'. Januari tm december? Maand 1 tm 12. Hier hebben we oktober dat maand 10 is.

Tellen ook van links naar rechts. Hier? Veertienhonderdzevenentachtig. Eerst positie 2, dan 1, dan 4, dan 3.

Parels als wc-bril en walvis, zeeohond en nijlpaard, random de/het en ij/ei.

Nederlands is wel een beetje de PHP van de natuurlijke talen.

[CurlyMo]

BarôZZa schreef op donderdag 15 augustus 2019 @ 11:58:
[...]
Nederlands is wel een beetje de PHP van de natuurlijke talen.

Ach ja, elke taal is wel raar:

[bwerg]

BarôZZa schreef op donderdag 15 augustus 2019 @ 11:58:
Hier hebben we oktober dat maand 10 is.

Immers betekent "octo" achtste... oh, wacht. Ja ja, ik weet dat daar een historische verklaring voor is.

wc-bril en walvis

Hierin is het Nederlands anders behoorlijk consistent. Samenvoegingen worden zonder koppelteken aan elkaar geschreven, behalve in gespecificeerde uitzonderingsgevallen. Waaronder als een samenstelling met een initiaalwoord als "wc", want "wcbril" en "hboöpleiding" zijn niet heel leesbaar.

[BarôZZa]

bwerg schreef op donderdag 15 augustus 2019 @ 12:12:
[...]

Hierin is het Nederlands anders behoorlijk consistent. Samenvoegingen worden zonder koppelteken aan elkaar geschreven, behalve in gespecificeerde uitzonderingsgevallen. Waaronder als een samenstelling met een initiaalwoord als "wc", want "wcbril" en "hboöpleiding" zijn niet heel leesbaar.

Ik heb het niet over het koppelteken.

Ik heb het over dat we een 'toilet seat' een 'wc-bril' noemen en een walvis geen vis is .

Sneetje brood? Boterham.

Overigens is dat woorden aan elkaar schrijven natuurlijk ook vreselijk. Google is gelukkig iets slimmer geworden, maar zeker vroeger kon je soms meerdere keren zoeken. De Engelse manier vind ik een stuk mooier. Zoek maar eens de klemtonen, grotestedenbeleid. Lijkt op groteske. Maar toch niet. En ineens schrijven we grote steden aan elkaar.

[ Voor 24% gewijzigd door BarôZZa op 15-08-2019 12:26 ]

[ThomasG]

BarôZZa schreef op donderdag 15 augustus 2019 @ 11:58:
[...]

Nederlands is wel een beetje de PHP van de natuurlijke talen.

Nee, Engels is de PHP van de natuurlijke talen. In het Nederlands zijn er qua uitspraak regels, met enkele uitzonderingen. In het Engels is de uitspraak van de worden at-random: zelfde constructie, andere uitspraak. Andere constructie, zelfde uitspraak.

[RayNbow]

Had iemand het over Engelse spelling?

[BarôZZa]

ThomasG schreef op donderdag 15 augustus 2019 @ 12:28:
[...]
Nee, Engels is de PHP van de natuurlijke talen. In het Nederlands zijn er qua uitspraak regels, met enkele uitzonderingen. In het Engels is de uitspraak van de worden at-random: zelfde constructie, andere uitspraak. Andere constructie, zelfde uitspraak.

ThomasG schreef op donderdag 15 augustus 2019 @ 12:28:
[...]
Nee, Engels is de PHP van de natuurlijke talen. In het Nederlands zijn er qua uitspraak regels, met enkele uitzonderingen. In het Engels is de uitspraak van de worden at-random: zelfde constructie, andere uitspraak. Andere constructie, zelfde uitspraak.

Enkele uitzonderingen? Nederlands is uitzondering op uitzondering. Alle regels vliegen sowieso(mooi woord trouwens) de deur uit bij de krankzinnige hoeveelheid leenwoorden uit de landen om ons heen. Die we uiteraard weer vernederlandst uitspreken. Chirurg, jam, machine. Klemtonen in het Nederlands zijn willekeurig en moet je stampen. Hoe je woorden schrijft met ij/ei, c/k, b/p, au/ou, g/ch ook. Accent, account, cel, cavia.
De stomme 'e' is ook een mooie. Meloen, elleboog.

Bedelen. Twee werkwoorden. Bedeeld en gebedeld.

Nog zo'n leuk: hoe we landen en mensen eruit noemen. Nederland -> Nederlander. Duitsland -> Duitser, Oostenrijk -> Oostenrijker. Frankrijk -> Fransman/Française/Franse, Georgië -> Georgiër, België -> Belg

M'n Taiwanese vriendin leert Nederlands en haar hoofd ontploft elke keer. Voor haar is het 'China', 'China people' en 'China food'. Oefenen is leuk. Boo-sui. Boo-sui? Oh, bos-ui.

Nederlands en Engels liggen trouwens heel dicht bij elkaar, dus veel zaken gaan voor beide talen op. Maar als Engels dan PHP is... Misschien is Nederlands dan wel Visual Basic of Objective C

Overigens zie ik net dat je in .NET het volgende hebt: TextSource.GetTextEffectCharacterIndexFromTextSourceCharacterIndex(Int32) Method

[ThomasG]

BarôZZa schreef op donderdag 15 augustus 2019 @ 14:55:
[...]


[...]

Enkele uitzonderingen? Nederlands is uitzondering op uitzondering. Alle regels vliegen sowieso(mooi woord trouwens) de deur uit bij de krankzinnige hoeveelheid leenwoorden uit de landen om ons heen. Die we uiteraard weer vernederlandst uitspreken. Chirurg, jam, machine. Klemtonen in het Nederlands zijn willekeurig en moet je stampen. Hoe je woorden schrijft met ij/ei, c/k, b/p, au/ou, g/ch ook. Accent, account, cel, cavia.
De stomme 'e' is ook een mooie. Meloen, elleboog.

Wat probeer je daarmee te zeggen? Op een paar uitzonderingen na door geleende woorden, spreek je alle constructies op dezelfde manier. De "ing" in worden linkt bijvoorbeeld hetzelfde in alle woorden die het gebruiken. Terwijl in het Engels als je "ough" tegen komt, is de uitspraak totaal verschillend afhankelijk van het woord. Is daar een regel voor? Nee.

In het Nederlands hoef je het woord niet te kennen om te weten hoe je het uitspreekt. In het Engels moet je maar net weten hoe je dat specifieke woord uitspreekt.

Bedelen. Twee werkwoorden. Bedeeld en gebedeld.

Nog zo'n leuk: hoe we landen en mensen eruit noemen. Nederland -> Nederlander. Duitsland -> Duitser, Oostenrijk -> Oostenrijker. Frankrijk -> Fransman/Française/Franse, Georgië -> Georgiër, België -> Belg.

En dat is in het Engels niet zo?
Germany -> German
France -> French man
America -> American
New Zealand -> New Zealander
The Netherlands -> Dutchman

M'n Taiwanese vriendin leert Nederlands en haar hoofd ontploft elke keer. Voor haar is het 'China', 'China people' en 'China food'. Oefenen is leuk. Boo-sui. Boo-sui? Oh, bos-ui.

Tja, dat komt omdat de Austronesische talen totaal verschillen met de Germaanse talen. Dus ja, logisch dat zoiets lastig is. Vooral omdat wij klanken hebben die zij niet hebben. Veel Aziatische mensen kunnen bijvoorbeeld de R niet goed uitspreken.

[ Voor 4% gewijzigd door ThomasG op 15-08-2019 15:09 ]

[DevWouter]

Olaf van der Spek schreef op donderdag 15 augustus 2019 @ 09:43:
[...]

Zeker weten? In dezelfde implementatie?

Seconde 60 is voor veel software sowieso problematisch.

Ja, de POSIX 1 style implementatie. De Mills implementatie (van David L. Mills, niet te verwarren met milliseconds) lost dit op door een extra state toe te voegen, maar die wordt vaak genegeerd. Je hebt ook nog de TAI implementatie en die bevat geen leap seconds (en heeft daardoor ook een afwijking met de andere implementaties die over tijd steeds groter wordt).

Olaf van der Spek schreef op donderdag 15 augustus 2019 @ 09:43:
[...]

Welke implementaties geven "31-12-1998" terug?

In de POSIX1 implementatie kan 915148800 verwijzen naar de leap second van de vorige dag of naar het begin van de nieuwe dag verwijzen. Die is letterlijk dubbelzinnig.

In de Mills implementatie heb je dit probleem niet maar dan moet je wel een extra state ophalen.

Olaf van der Spek schreef op donderdag 15 augustus 2019 @ 09:43:
[...]

Daar wordt de tijdzone ook niet opgeslagen, de tijd wordt geconverteerd naar UTC.

Ah... Dat was mij niet bekend. Bedankt voor de correctie!

[BarôZZa]

ThomasG schreef op donderdag 15 augustus 2019 @ 15:04:
[...]
Wat probeer je daarmee te zeggen? Op een paar uitzonderingen na door geleende woorden, spreek je alle constructies op dezelfde manier. De "ing" in worden linkt bijvoorbeeld hetzelfde in alle woorden die het gebruiken.

Ingang

In het Nederlands hoef je het woord niet te kennen om te weten hoe je het uitspreekt. In het Engels moet je maar net weten hoe je dat specifieke woord uitspreekt.

Dat is dus niet waar. Alle voorbeelden die ik gaf spreek je anders uit dan dat je zou verwachten.
Als je aan het woord kon zien hoe je het moet uitspreken, dan hadden we geen homografen gehad.

En dat is in het Engels niet zo?
Germany -> German
France -> French man
America -> American
New Zealand -> New Zealander
The Netherlands -> Dutchman

Ik heb het niet specifiek over het Engels, ik vergelijk het met bijvoorbeeld mandarijn, wat een hele duidelijke en logische structuur heeft. Dat Engels ongeveer net zo warrig is als Nederlands staat vast.

Tja, dat komt omdat de Austronesische talen totaal verschillen met de Germaanse talen. Dus ja, logisch dat zoiets lastig is. Vooral omdat wij klanken hebben die zij niet hebben. Veel Aziatische mensen kunnen bijvoorbeeld de R niet goed uitspreken.

De R klant is een ander verhaal. Het bosui verhaal is omdat je niet aan het woord kan zien hoe je het uitspreekt. Ze leert dat bos in het meervoud bossen wordt, omdat je bosen uitspreekt als boosen. Dus bosui met één s, zou je uitspreken als boo-sui.

[ThomasG]

BarôZZa schreef op donderdag 15 augustus 2019 @ 16:19:
[...]

De R klant is een ander verhaal. Het bosui verhaal is omdat je niet aan het woord kan zien hoe je het uitspreekt. Ze leert dat bos in het meervoud bossen wordt, omdat je bosen uitspreekt als boosen. Dus bosui met één s, zou je uitspreken als boo-sui.

Dat kun je namelijk wel aan het woord zien, ook bij bosui. Er zijn maar een paar gevallen wanneer je een o uitspreekt als oo; zoals een meervoudsvorm met een medeklinker en daarna -en. In het geval van bosui is er geen enkele reden om aan te nemen dan de o zou klinken als oo. Als ze dat wel denkt heeft ze dat helaas verkeerd aangeleerd.

[bwerg]

BarôZZa schreef op donderdag 15 augustus 2019 @ 14:55:

De stomme 'e' is ook een mooie. Meloen, elleboog.

Dat is gewoon een gevalletje open en gesloten lettergrepen. Dat is in het Nederlands nou net wél vrij consistent (op leenwoorden etc. na), en het is geen stomme letter (zoals de helft van het Frans, bijvoorbeeld - zo spreek je "Crest" uit als "Kré" en "Brest" gewoon zoals je het schrijft). Zo inderdaad ook de uitspraak van bosui, zoals @ThomasG al aangeeft: bij een andere uitspraak zou je bo-sui schrijven.

Maar dat er geen bijectie is tussen geschreven en uitgesproken taal is nou niet echt nieuw. De taalontwikkelingen in de laatste millennia zijn nou niet bepaald door wiskundigen of taalkundigen ingevoerd.

[ Voor 8% gewijzigd door bwerg op 15-08-2019 17:06 ]

[BarôZZa]

ThomasG schreef op donderdag 15 augustus 2019 @ 16:28:
[...]
Dat kun je namelijk wel aan het woord zien, ook bij bosui. Er zijn maar een paar gevallen wanneer je een o uitspreekt als oo; zoals een meervoudsvorm met een medeklinker en daarna -en. In het geval van bosui is er geen enkele reden om aan te nemen dan de o zou klinken als oo. Als ze dat wel denkt heeft ze dat helaas verkeerd aangeleerd.

We hebben in het Nederlands regels hoe we de uitspraak opschrijven. Dat betekent niet dat je het kan omdraaien en dat je aan het woord kan zien hoe je het uitspreekt.

'Boven' is geen meervoudsvorm.
Als je weet hoe je tulpen uitspreekt, hoe spreek je dan vulpen uit? Je moet simpelweg het woord kennen om het correct uit te spreken, anders verwacht je dat je het uitspreekt als het meervoud van vulp.

bwerg schreef op donderdag 15 augustus 2019 @ 17:04:
[...]

Dat is gewoon een gevalletje open en gesloten lettergrepen. Dat is in het Nederlands nou net wél vrij consistent (op leenwoorden etc. na)

Hoe zou je maloen uitspreken of ellaboog ?

[ThomasG]

BarôZZa schreef op donderdag 15 augustus 2019 @ 17:09:
[...]

We hebben in het Nederlands regels hoe we de uitspraak opschrijven. Dat betekent niet dat je het kan omdraaien en dat je aan het woord kan zien hoe je het uitspreekt.

'Boven' is geen meervoudsvorm.
Als je weet hoe je tulpen uitspreekt, hoe spreek je dan vulpen uit? Je moet simpelweg het woord kennen om het correct uit te spreken, anders verwacht je dat je het uitspreekt als het meervoud van vulp.

Boven spreek je ook uit met oo...

[Mugwump]

ThomasG schreef op donderdag 15 augustus 2019 @ 17:15:
[...]
Boven spreek je ook uit met oo...

Tenzij je uit Twente komt, dan moeten er nog twaalf o's achteraan.