De Devschuur Coffee Corner - Iteratie ⓬

[Xessive]

Onze eerste PC was een Olivetti M240



Zat een HDD in van wel 20MB!! Dat was toen heeeeel wat. Die HDD woog dan ook wel wat, in mijn beleving het equivalent van een 30x30cm stoeptegel hahaha. En de gehele PC moest bijna met een steekkar verplaatst worden.

Wat voor monitor (CGA/EGA) erbij zat weet ik niet meer. Ik dacht een EGA.

En zowaar 2MB RAM. De hele buurt was jaloers op ons.

* leunt achter over en geniet van deze nostalgie *

[azerty]

Geven jullie ffe een seintje als het terug over php bashen, welk keyboard nu het beste is of iets anders gaat ipv geneuzel over de eerste computer?

[RagingPenguin]

azerty schreef op woensdag 2 september 2020 @ 09:53:
Geven jullie ffe een seintje als het terug over php bashen, welk keyboard nu het beste is of iets anders gaat ipv geneuzel over de eerste computer?

Maar PHP heeft tegenwoordig lambda's en types, dus zo slecht is het ook niet meer.

[Antrax]

azerty schreef op woensdag 2 september 2020 @ 09:53:
Geven jullie ffe een seintje als het terug over php bashen, welk keyboard nu het beste is of iets anders gaat ipv geneuzel over de eerste computer?

PHP is tegenwoordig een heel stuk beter dan in het verleden. o.a. types enzo.

[gekkie]

azerty schreef op woensdag 2 september 2020 @ 09:53:
Geven jullie ffe een seintje als het terug over php bashen, welk keyboard nu het beste is of iets anders gaat ipv geneuzel over de eerste computer?

Tsss die moderne issues, die zogenaamde vooruitgang ?
Alles was een mechanisch keyboard, programmeertalen nog te overzien, Dijkstra still alive, wat een tijden

[RagingPenguin]

Antrax schreef op woensdag 2 september 2020 @ 10:19:
[...]

PHP is tegenwoordig een heel stuk beter dan in het verleden. o.a. types enzo.

Dat is wel sarcastisch, righth?

gekkie schreef op woensdag 2 september 2020 @ 10:21:
[...]
programmeertalen nog te overzien

Waren er voordat de java alles overnam niet veel meer exotische programmeertalen?

[SideSplitter]

RagingPenguin schreef op woensdag 2 september 2020 @ 10:26:
[...]
Dat is wel sarcastisch, righth?

Mwa, als je PHP7 (of 8) pakt dan ben je bijna in een aftreksel van Java aan het schrijven (mits je netjes OOP blijft doen). Of je daar heel blij van wordt is een ander verhaal, maar het is in ieder geval beter dan de bende die PHP 4/5 was.

[ Voor 3% gewijzigd door SideSplitter op 02-09-2020 10:35 ]

[wackmaniac]

RagingPenguin schreef op woensdag 2 september 2020 @ 10:26:
Waren er voordat de java alles overnam niet veel meer exotische programmeertalen?

Ik denk dat er nog steeds meer dan genoeg exotische talen zijn. Het lijkt zelfs in zwang te zijn om als groot bedrijf je eigen taal te maken; Apple kwam met Swift (na Objective-C) en Google heeft meer talen dan dat ze services hebben gestopt. En dan neem ik de hobbyisten nog niet eens in ogenschouw

[gekkie]

RagingPenguin schreef op woensdag 2 september 2020 @ 10:26:
Waren er voordat de java alles overnam niet veel meer exotische programmeertalen?

Wellicht, maar binnen de talen zelf was het meestal nog wel te doen, wellicht door de limiterende kracht van zowel de hardware, als wel van de dode bomen ter documentatie.

[m-vw]

Op mijn basisschool (<1992) hadden we een C64. In die periode zelf ook nog een tweedehands C128 aangeschaft (met tape).

Computerles in de eerste klas voortgezet onderwijs bestond uit versimpelde theorie en wat prutsen in een DOS versie van paint.

Mijn opa en oma hadden overigens midden jaren 80 wel een IBM PC met spellen als Blockout, Mahjong en Prince of Persia.

[Wilf]

Ik bedacht mij net trouwens, zo in dit nostalgiegebeuren: Weten jullie nog hoeveel lawaai een computer(tower) of laptop maakte vroeger? Dat was één van de redenen waarom ik niet kon wachten om over te stappen op Mac destijds… Het waren stofzuigers! Lekker in je home studio moesten we allerlei trucs bedenken om die troep stiller te krijgen en waterkoeling van een laptop was nog niet echt ‘een ding’.

[.oisyn]

Antrax schreef op woensdag 2 september 2020 @ 10:19:
[...]

PHP is tegenwoordig een heel stuk beter dan in het verleden. o.a. types enzo.

Goed verhaal. Lekker kort.

[hellum]

Daar heb ik zelf weinig last van gehad. Mijn 386 en 486 computers waren gewoon passief gekoeld (behalve de voeding). Mijn K6 had een beetje geluid maar ook nog prima te doen. Vergeet nooit mijn eerste Pentium 4, die had zo'n ongelofelijk kabaal dat kon je in de kamer er naast nog horen. Als ik het me goed herinner kwam dat door de socket 478 stock cooler.

[Mugwump]

RagingPenguin schreef op woensdag 2 september 2020 @ 10:26:
[...]


Dat is wel sarcastisch, righth?


[...]


Waren er voordat de java alles overnam niet veel meer exotische programmeertalen?

Bij mijn weten heeft Java nooit alles overgenomen, maar juist vandaag de dag is er een wildgroei aan talen. Het internet, open source en ironisch genoeg ook juist onder andere de JVM maakt dat mogelijk.
Volgens mij is eigenlijk vrijwel altijd alles behalve een zootje C-afgeleiden gerommel in de marge geweest.

Vandaag de dag hebben de meeste C-afgeleiden ook wel wat invloeden uit de functionele hoek, maar in essentie is het C-syntax.

[whoami]

azerty schreef op woensdag 2 september 2020 @ 09:53:
welk keyboard nu het beste is

Als het maar een qwerty is.

[.oisyn]

whoami schreef op woensdag 2 september 2020 @ 14:08:
[...]
Als het maar een qwerty is.

Louter ANSI-US.

[ Voor 3% gewijzigd door .oisyn op 02-09-2020 14:13 ]

[Woy]

.oisyn schreef op woensdag 2 september 2020 @ 13:53:
[...]


Goed verhaal. Lekker kort.

Mand!

Of eigenlijk in dit geval

PHP!




Voor degen die het niet kennen: YouTube: Omroep Maxim: Meneer Mandje

[ Voor 37% gewijzigd door Woy op 02-09-2020 14:29 ]

[armageddon_2k1]

Knuppel in hoenderhok:

Waarom is Tweakers backend eigenlijk nog niet over op Rust?

[Otherside1982]

armageddon_2k1 schreef op woensdag 2 september 2020 @ 14:29:
Knuppel in hoenderhok:

Waarom is Tweakers backend eigenlijk nog niet over op Rust?

Omdat de developers vastgeroest zijn.


Badum-Tiss

[armageddon_2k1]

Nieuwe programmeertaal: WD-40.

[azerty]

whoami schreef op woensdag 2 september 2020 @ 14:08:
[...]
Als het maar een qwerty is.

Gaf mijn gebruikersnaam weg welke voorkeur ik heb soms?

[.oisyn]

armageddon_2k1 schreef op woensdag 2 september 2020 @ 14:29:
Knuppel in hoenderhok:

Waarom is Tweakers backend eigenlijk nog niet over op Rust?

Omdat C++ sneller is

[RayNbow]

.oisyn schreef op woensdag 2 september 2020 @ 14:49:
[...]

Omdat C++ sneller is

Sneller in wat? Onleesbare fouten uitspugen?

[Creepy]

Immutable schreef op dinsdag 1 september 2020 @ 22:15:
[...]


Goeiedag, die Panasonic is nu nog steeds best veel waard!! Was de laatste MSX zeker. Dacht leek me wel leuk om die juist ff voor paar tientjes op de kop te tikken... gaat niet gebeuren.

De Turbo R GT was de laatste. Die doet met enige regelmaat meer dan 1000,- op ebay ofzo. Ik heb de ST, de 1-na-laatse, maar de prijzen daarvan zitten ook al in de 600-800 range. Bezopen , maar goed Maar dan krijg je wel een z80 op 3.58 MHz EN een R800 op 28.63630 MHz

Een msx 2 (Philips 8245 of 8250) zijn vaak voor betere prijzen te vinden in NL. Op ebay is het ook echt weer te gek (300 euro +....)

[Koenvh]

whoami schreef op woensdag 2 september 2020 @ 14:08:
[...]
Als het maar een qwerty is.

Ik beheer ook mede een Duitse Windows server, en elke keer dat ik daarnaar RDP mag ik naar QWERTZ omschakelen. Echt heel praktisch, vooral omdat het meeste wel op de juiste plek zit. Ik had toch eigenlijk verwacht dat als RDP mijn lokale printers kan gebruiken, dat dan de toetsenbordindeling overnemen ook niet te veel gevraagd zou zijn.

[ThomasG]

RayNbow schreef op woensdag 2 september 2020 @ 14:51:
[...]

Sneller in wat? Onleesbare fouten uitspugen?

Dat is een feature van C++, zodat alle slechte programmeurs een andere taal gebruiken

[.oisyn]

RayNbow schreef op woensdag 2 september 2020 @ 14:51:
[...]

Sneller in wat? Onleesbare fouten uitspugen?

Als je de fouten niet snapt hoor je PHP te doen

[Koenvh]

.oisyn schreef op woensdag 2 september 2020 @ 15:28:
[...]


Als je de fouten niet snapt hoor je PHP te doen

In PHP is daar een oplossing voor:

code:

error_reporting(0);

[ThomasG]

Koenvh schreef op woensdag 2 september 2020 @ 15:51:
[...]

In PHP is daar een oplossing voor:

code:

error_reporting(0);

En natuurlijk een @ voor elke function call en variable

Het leukste van PHP vond ik altijd:

PHP:

$query = @mysql_query("...") or die(mysql_error());

[RayNbow]

.oisyn schreef op woensdag 2 september 2020 @ 15:28:
[...]


Als je de fouten niet snapt hoor je PHP te doen

Fouten in eigen code snap ik meestal nog wel... maar fouten van slecht onderhouden verouderde 3rd party meuk? Dan geef ik 't soms op.

[RagingPenguin]

RayNbow schreef op woensdag 2 september 2020 @ 16:19:
[...]

Fouten in eigen code snap ik meestal nog wel... maar fouten van slecht onderhouden verouderde 3rd party meuk? Dan geef ik 't soms op.

Maar dat is niet taalspecifiek Bevalve in Go, daar kopieert en plakt iedereen hele lappen code naar hun eigen codebase zodat 1st party verouderde niet onderhouden meuk is

[kenneth]

Kopiëren en plakken in Go, daar is een term voor: generics.

[Janoz]

ThomasG schreef op woensdag 2 september 2020 @ 16:01:
Het leukste van PHP vond ik altijd:

PHP:

$query = @mysql_query("...") or die(mysql_error());

En velen maar denken dat het een language construct was, terwijl het alleen maar een stukje type juggling icm lazy evaluation is.

[PrisonerOfPain]

.oisyn schreef op woensdag 2 september 2020 @ 14:49:
[...]

Omdat C++ sneller is

Sinds wanneer? Zie onderandere https://benchmarksgame-te...rksgame/fastest/rust.html en http://dtrace.org/blogs/b...erformance-of-c-and-rust/

[.oisyn]

*Triggered*

Waarom wijs je naar C en niet naar C++? Je bent zeker zo'n n00b die denkt dat dat hetzelfde is?

Vaag trouwens dat ze vergelijken met gcc en niet met een llvm target.

[ Voor 5% gewijzigd door .oisyn op 02-09-2020 18:47 ]

[PrisonerOfPain]

.oisyn schreef op woensdag 2 september 2020 @ 18:47:
Waarom wijs je naar C en niet naar C++? Je bent zeker zo'n n00b die denkt dat dat hetzelfde is?

Ik dacht dat je zelf wel 1337 genoeg was om op de C++ knop te klikken

[gekkie]

Oeh bitch slapping, roestvaststaal tegen corten-staal

[Koenvh]

gekkie schreef op woensdag 2 september 2020 @ 20:56:
Oeh bitch slapping, roestvaststaal tegen corten-staal

Pas op want ik heb slangen en edelstenen!
(en koffie )

[ Voor 4% gewijzigd door Koenvh op 02-09-2020 21:17 ]

[gekkie]

Koenvh schreef op woensdag 2 september 2020 @ 21:13:
[...]
en koffie

Cola is gevaarlijker voor team-cortenstaal

[Postman]

Corten staal roest juist makkelijk ter bescherming, beetje zoals aluminium. Roestvast staal en zuur daarentegen...

[gekkie]

Postman schreef op woensdag 2 september 2020 @ 21:34:
Corten staal roest juist makkelijk ter bescherming, beetje zoals aluminium. Roestvast staal en zuur daarentegen...

Hmm lijkt me dat al te veel cola ook niet briljant is voor die roestige beschermlaag.

[Postman]

gekkie schreef op woensdag 2 september 2020 @ 21:59:
[...]

Hmm lijkt me dat al te veel cola ook niet briljant is voor die roestige beschermlaag.

Zal niet helpen nee.
Enige voordeel is dat bij Corten je het verschil nauwelijks gaat zien, RVS krijg je bijna niet meer netjes.

[Matis]

Koenvh schreef op woensdag 2 september 2020 @ 21:13:
Pas op want ik heb slangen en edelstenen!
(en koffie )

Ik in Mammoeten en reïncarnaties!

Al is die laatste misschien een beetje te cryptisch. Vergt ook nog een stukje fonetische vertaling

[ Voor 21% gewijzigd door Matis op 03-09-2020 08:59 ]

[Antrax]

SideSplitter schreef op woensdag 2 september 2020 @ 10:34:
[...]


Mwa, als je PHP7 (of 8) pakt dan ben je bijna in een aftreksel van Java aan het schrijven (mits je netjes OOP blijft doen). Of je daar heel blij van wordt is een ander verhaal, maar het is in ieder geval beter dan de bende die PHP 4/5 was.

Snap inderdaad de haat niet tegen PHP.
Iedere taal heeft zijn voor en nadelen. Als je een taal niet leukt vindt, werk er dan niet mee? Hoef je het ook niet te bashen

[.oisyn]

Antrax schreef op donderdag 3 september 2020 @ 09:59:
[...]

Snap inderdaad de haat niet tegen PHP.

Grappig genoeg worden veel van de originele oorsprongen van de haat tegenwoordig aangepakt. Je zou zomaar kunnen zeggen dat die haat terecht was en dat het ervoor heeft gezorgd dat de taal is verbeterd

[Mugwump]

Antrax schreef op donderdag 3 september 2020 @ 09:59:
[...]

Snap inderdaad de haat niet tegen PHP.
Iedere taal heeft zijn voor en nadelen. Als je een taal niet leukt vindt, werk er dan niet mee? Hoef je het ook niet te bashen

De grote kracht van PHP was altijd dat oneerbiedig gezegd elke debiel een websiteje in elkaar kon klooien. Wat ook gelijk het nadeel was, want elke debiel ging een websiteje in elkaar klooien.
Nou is daar in mijn ogen op zich niets mis mee, alleen had PHP gewoon lekker moeten blijven wat het is, een hobbytaaltje.
Zoals @.oisyn al zegt worden niet voor niets veel van de kritiek op PHP wel degelijk aangepakt. Maar het punt is een beetje dat als je gaat proberen om PHP wat professioneler te maken en veel van de kritiekpunten weghaalt, je eigenlijk gewoon een wat gemankeerde versie van Java of C# overhoudt die niet meer de laagdrempeligheid biedt waardoor je makkelijk instapt, maar ook niet de performance en / of professionaliteit die talen die fundamenteel beter opgezet zijn benadert.

Er is ook een prima reden dat bijvoorbeeld de drie grote cloudplatformen PHP niet standaard ondersteunen in hun serverless oplossingen en AWS en Azure wel bijvoorbeeld nog Go en Ruby, die qua populariteit / gebruik nog niet het niveau van PHP halen.

[SPee]

Wie zegt dat je met een programmeertaal moet werken om deze te bashen

Waar PHP wel goed in is, is dat elke goedkope hoster dat met PHP doet.
Dat heb ik met Java/.net nog niet gezien. Daar had je een duurdere VPS for nodig. Gelukkig is het met de opkomst van containers ook daar mogelijk. Maar daar moet je het wel meer zelf regelen.

[OMX2000]

Creepy schreef op woensdag 2 september 2020 @ 14:57:
[...]

De Turbo R GT was de laatste. Die doet met enige regelmaat meer dan 1000,- op ebay ofzo. Ik heb de ST, de 1-na-laatse, maar de prijzen daarvan zitten ook al in de 600-800 range. Bezopen , maar goed Maar dan krijg je wel een z80 op 3.58 MHz EN een R800 op 28.63630 MHz

Een msx 2 (Philips 8245 of 8250) zijn vaak voor betere prijzen te vinden in NL. Op ebay is het ook echt weer te gek (300 euro +....)

Ik heb hier een VG 8235 staan. Met een diskdrive die vervangen is (double sided 720KB). Maar heb een tijd gezocht naar een NMS 8245 omdat het beestje was wat ik had in mijn jeugd.

Maar eigenlijk meer voor de heb. Heb te weinig tijd om er wat nuttigs mee te doen. Komt wel ooit weer als kids wat ouder zijn.

Die Turbo R GT was wel een leuk apparaat. Maar als ik me goed herinner was toen zelfs Konami gestopt met het developen van games ervoor.

[gekkie]

Mugwump schreef op donderdag 3 september 2020 @ 10:57:
[...]
Maar het punt is een beetje dat als je gaat proberen om PHP wat professioneler te maken en veel van de kritiekpunten weghaalt, je eigenlijk gewoon een wat gemankeerde versie van Java of C# overhoudt die niet meer de laagdrempeligheid biedt waardoor je makkelijk instapt, maar ook niet de performance en / of professionaliteit die talen die fundamenteel beter opgezet zijn benadert.

Het blijft ook een beetje een one-trick pony, een hoop andere talen bieden tegenwoordig ook aardige functionaliteit voor web-apps, maar zijn ook prima inzetbaar voor andere zaken. En zelfs voor dingen als websockets en pub-sub is PHP eigenlijk maar matig inzetbaar, CGI achtige script meuk met een korte executie tijd en state ergens anders in prakken en alles client side geinitieerd (of fijn cron achtige scriptjes gaan draaien ) ... oh the joy.

[Mugwump]

SPee schreef op donderdag 3 september 2020 @ 11:01:
Wie zegt dat je met een programmeertaal moet werken om deze te bashen

Waar PHP wel goed in is, is dat elke goedkope hoster dat met PHP doet.
Dat heb ik met Java/.net nog niet gezien. Daar had je een duurdere VPS for nodig. Gelukkig is het met de opkomst van containers ook daar mogelijk. Maar daar moet je het wel meer zelf regelen.

Ja, de laagdrempeligheid dus....shared hosting, even je bestandjes SFTPen en klaar het draait.
In mijn ogen eigenlijk iets dat met App Engine, Elastic Beanstalk of app services in Azure eigenlijk een meer dan volwaardig alternatief heeft. Misschien nog nét iets prijziger, maar je krijgt er aan de andere kant ook wel weer veel meer voor.

[Wilf]

Nou heb ik een aantal hosting providers gehad en om de prijs niet op te drijven kies ik meestal het budgetpakket. Daar zit altijd standaard in: MySQL en PHP. Ik had nog gemaild om te vragen of Python een optie zou zijn... Nee.

[Koenvh]

Er is een goede reden waarom eigenlijk alleen PHP aangeboden wordt door shared webhosters: het geheugengebruik als er niemand op je website is, is 0. Alleen Apache hoeft te draaien, en die wordt gedeeld, plus gebruikt ook niet veel geheugen. Dat in tegenstelling tot bijvoorbeeld Tomcat, waar ik me altijd afvraag wat dat ding met 2GB geheugen moet als er helemaal niks op de website gebeurt.

[PatrickH89]

Mugwump schreef op donderdag 3 september 2020 @ 10:57:
[...]


De grote kracht van PHP was altijd dat oneerbiedig gezegd elke debiel een websiteje in elkaar kon klooien. Wat ook gelijk het nadeel was, want elke debiel ging een websiteje in elkaar klooien.
Nou is daar in mijn ogen op zich niets mis mee, alleen had PHP gewoon lekker moeten blijven wat het is, een hobbytaaltje.
Zoals @.oisyn al zegt worden niet voor niets veel van de kritiek op PHP wel degelijk aangepakt. Maar het punt is een beetje dat als je gaat proberen om PHP wat professioneler te maken en veel van de kritiekpunten weghaalt, je eigenlijk gewoon een wat gemankeerde versie van Java of C# overhoudt die niet meer de laagdrempeligheid biedt waardoor je makkelijk instapt, maar ook niet de performance en / of professionaliteit die talen die fundamenteel beter opgezet zijn benadert.

Er is ook een prima reden dat bijvoorbeeld de drie grote cloudplatformen PHP niet standaard ondersteunen in hun serverless oplossingen en AWS en Azure wel bijvoorbeeld nog Go en Ruby, die qua populariteit / gebruik nog niet het niveau van PHP halen.

Tja, die 'reden' is eerder de algemene bias tegen PHP. Zo is Ruby in veel aspecten gelijk en in een aantal aspecten inferieur aan PHP. Daarnaast is PHP de afgelopen jaren veel professioneler geworden en nog steeds vrij eenvoudig in gebruik (daarnaast ook gradual, op amateurniveau prima te doen en op enterpriseniveau ook). Ik snap de meme, maar het krijgt hier van jou absoluut niet de credit die het verdient. En natuurlijk is het daarmee absoluut niet de beste tool voor elke job, maar termen als 'gemankeerde versie van Java of C#' getuigt gewoon van de old school PHP bias en beperkte ervaring met hoe men momenteel professioneel met PHP werkt.

[Koenvh]

gekkie schreef op donderdag 3 september 2020 @ 11:20:
[...]

Het blijft ook een beetje een one-trick pony, een hoop andere talen bieden tegenwoordig ook aardige functionaliteit voor web-apps, maar zijn ook prima inzetbaar voor andere zaken. En zelfs voor dingen als websockets en pub-sub is PHP eigenlijk maar matig inzetbaar, CGI achtige script meuk met een korte executie tijd en state ergens anders in prakken en alles client side geinitieerd (of fijn cron achtige scriptjes gaan draaien ) ... oh the joy.

Websockets in PHP kunnen wel met bijvoorbeeld Ratchet

[RagingPenguin]

Koenvh schreef op donderdag 3 september 2020 @ 14:07:
[...]

Websockets in PHP kunnen wel met bijvoorbeeld Ratchet

Maar dan moet je wel weer native stuff en PHP extensies gaan installeren (libzmq). Dat is op shared hosting vaak geen optie en gaat ook wel weer een beetje voorbij het idiot-friendly character van PHP. Dan is iets als node.js wel weer een stuk makkelijker om iets met websockets te doen.

[gekkie]

Koenvh schreef op donderdag 3 september 2020 @ 14:07:
[...]
Websockets in PHP kunnen wel met bijvoorbeeld Ratchet

Mjah ik weet dat men ook daar om heen aan het werken is geslagen.
En ja ze hebben ook een QT binding, dus ja je kunt er kennlijk ook GUI applicatie mee bakken.

Achja creatief van een half dode trekknol een hippe unicorn proberen te maken .

[RagingPenguin]

PatrickH89 schreef op donderdag 3 september 2020 @ 14:03:
[...]


Tja, die 'reden' is eerder de algemene bias tegen PHP. Zo is Ruby in veel aspecten gelijk en in een aantal aspecten inferieur aan PHP. Daarnaast is PHP de afgelopen jaren veel professioneler geworden en nog steeds vrij eenvoudig in gebruik (daarnaast ook gradual, op amateurniveau prima te doen en op enterpriseniveau ook). Ik snap de meme, maar het krijgt hier van jou absoluut niet de credit die het verdient. En natuurlijk is het daarmee absoluut niet de beste tool voor elke job, maar termen als 'gemankeerde versie van Java of C#' getuigt gewoon van de old school PHP bias en beperkte ervaring met hoe men momenteel professioneel met PHP werkt.

Zolang php nog gci-only is geen threads of ander concurrency model krijgt en de enige collecties ordered maps zijn blijft php beperkt tot simpele lichtgewicht (CRUD) backends. Voor het wat meer serieuze werk zijn fatsoenlijke ingebouwde concurrency en arrays wel gewoon een vereiste.

[Koenvh]

RagingPenguin schreef op donderdag 3 september 2020 @ 14:14:
[...]


Maar dan moet je wel weer native stuff en PHP extensies gaan installeren (libzmq). Dat is op shared hosting vaak geen optie en gaat ook wel weer een beetje voorbij het idiot-friendly character van PHP. Dan is iets als node.js wel weer een stuk makkelijker om iets met websockets te doen.

Zijn Websockets überhaupt "idiot-friendly"? En ja, dat gaat niet op shared webhosting, maar ik geloof dat je met websockets sowieso wel het "shared webhosting"-stadium voorbij bent.

[PatrickH89]

gekkie schreef op donderdag 3 september 2020 @ 14:20:
[...]

Mjah ik weet dat men ook daar om heen aan het werken is geslagen.
En ja ze hebben ook een QT binding, dus ja je kunt er kennlijk ook GUI applicatie mee bakken.

Achja creatief van een half dode trekknol een hippe unicorn proberen te maken .

GUI ligt misschien niet voor de hand, maar async zoals Ratchet, Swoole, ReactPHP, amphp lijken me toch een redelijk natuurlijke evolutie van de taal. For some reason is het wel OK om dit soort dingen te ontwikkelen voor andere eco-systemen, maar is het bij PHP trekken aan een dood paard. Tja...

[RagingPenguin]

Koenvh schreef op donderdag 3 september 2020 @ 14:23:
[...]

Zijn Websockets überhaupt "idiot-friendly"? En ja, dat gaat niet op shared webhosting, maar ik geloof dat je met websockets sowieso wel het "shared webhosting"-stadium voorbij bent.

In bv. nodejs zijn callbacks het enige wat je hoeft te begrijpen om websockets te kunnen gebruiken. En iedereen die javascript doet heeft vast al wel eens een callback gezien, praktisch alles in js hangt van callbacks aan elkaar.

[PatrickH89]

RagingPenguin schreef op donderdag 3 september 2020 @ 14:22:
[...]


Zolang php nog gci-only is geen threads of ander concurrency model krijgt en de enige collecties ordered maps zijn blijft php beperkt tot simpele lichtgewicht (CRUD) backends. Voor het wat meer serieuze werk zijn fatsoenlijke ingebouwde concurrency en arrays wel gewoon een vereiste.

Serieuze backends kunnen en worden prima gedraaid op PHP. Ook hier geldt natuurlijk dat het niet altijd de right tool is, maar vaak zeker wel. En dan is het prima enterprise ready.

[RagingPenguin]

PatrickH89 schreef op donderdag 3 september 2020 @ 14:33:
[...]


Serieuze backends kunnen en worden prima gedraaid op PHP. Ook hier geldt natuurlijk dat het niet altijd de right tool is, maar vaak zeker wel. En dan is het prima enterprise ready.

Maar een hoop 'enterprise' is just dood-simple crud applicaties voor administrative doeleinden. De grootste opkomst op het moment in het enterprise wereldje zijn de low-code en no-code platformen die nog minder toelaten maar ook nog meer idiot-friendly zijn dan scripttalen zoals php. Microsofts powerapps gebruiken letterlijk excel formules als scriptaal om apps te bouwen die je standaard (php) crud app vervangen (en het vaak nog een stuk beter doen ook dankzij een fatsoenlijke UI kit).

[gekkie]

PatrickH89 schreef op donderdag 3 september 2020 @ 14:24:
[...]
GUI ligt misschien niet voor de hand, maar async zoals Ratchet, Swoole, ReactPHP, amphp lijken me toch een redelijk natuurlijke evolutie van de taal. For some reason is het wel OK om dit soort dingen te ontwikkelen voor andere eco-systemen, maar is het bij PHP trekken aan een dood paard. Tja...

Mjah het zal denk ik met de richting van ontwikkeling te maken hebben waarom ik het in dit geval een dood paard vind. Ik vind het vanuit PHP namelijk niet aanvoelen als een "redelijk natuurlijke evolutie", omdat het niet echt een generieke programmeertaal is, waarbij je nieuwe concepten min of meer binnen het bestaande implementeert (async in andere talen was er vaak eerst als module ipv syntax), maar bij PHP moet je echt de taal uitbreiden met generieke zaken die andere programmeertalen al lang hadden. Dat gecombineerd met de matigheid der taal, dan bekruipt mij een "niet omdat het moet, maar omdat het kan" gevoel.

En ik zie dat soort nieuwe PHP zaken dan ook, zeker met de implementatie geschiedenis van PHP, ook niet heel snel als "enterprise ready".

[PatrickH89]

gekkie schreef op donderdag 3 september 2020 @ 14:46:
[...]

Mjah het zal denk ik met de richting van ontwikkeling te maken hebben waarom ik het in dit geval een dood paard vind. Ik vind het vanuit PHP namelijk niet aanvoelen als een "redelijk natuurlijke evolutie", omdat het niet echt een generieke programmeertaal is, waarbij je nieuwe concepten min of meer binnen het bestaande implementeert (async in andere talen was er vaak eerst als module ipv syntax), maar bij PHP moet je echt de taal uitbreiden met generieke zaken die andere programmeertalen al lang hadden. Dat gecombineerd met de matigheid der taal, dan bekruipt mij een "niet omdat het moet, maar omdat het kan" gevoel.

En ik zie dat soort nieuwe PHP zaken dan ook, zeker met de implementatie geschiedenis van PHP, ook niet heel snel als "enterprise ready".

Mag ik je wijzen op het ontstaan van Node JS? Waar de taal (die zeker niet minder matig is dan PHP) uberhaupt nooit backend gedraaid werd en wat toch redelijk geslaagd genoemd mag worden (in ieder geval heerst er niet hetzelfde sentiment als bij PHP). Dit heeft ook weer de weg vrijgemaakt voor bredere adoptie van Typescript.

Kijk, prima als je op basis van 'wat je al weet' verder bouwt, maar mij bekruipt toch vooral het gevoel dat mensen zonder ervaring met de huidige manier van werken PHP veroordelen op een imago van 10 jaar geleden (wat toen al discutabel was).

[RagingPenguin]

PatrickH89 schreef op donderdag 3 september 2020 @ 15:15:
[...]


Mag ik je wijzen op het ontstaan van Node JS? Waar de taal (die zeker niet minder matig is dan PHP) uberhaupt nooit backend gedraaid werd en wat toch redelijk geslaagd genoemd mag worden (in ieder geval heerst er niet hetzelfde sentiment als bij PHP). Dit heeft ook weer de weg vrijgemaakt voor bredere adoptie van Typescript.

Kijk, prima als je op basis van 'wat je al weet' verder bouwt, maar mij bekruipt toch vooral het gevoel dat mensen zonder ervaring met de huidige manier van werken PHP veroordelen op een imago van 10 jaar geleden (wat toen al discutabel was).

Javascript/node staat toch echt wel op een wat hoger niveau dan php hoor. Fatsoenlijke concurrency, map en set data types naast arrays, niet gelimiteerd tot gci mode, lambda's (oke krijg php nu ook, maar dan nog steeds met gekke scoping regels). Dat maak(te) node een hele goede keuze voor IO-heavy stuff, iets wat voor php juist een grote achilleshiel is. (niet dat ik zo'n grote fan van node ben, maar het is niet zo slecht als php)

[gekkie]

PatrickH89 schreef op donderdag 3 september 2020 @ 15:15:
[...]
Mag ik je wijzen op het ontstaan van Node JS? Waar de taal (die zeker niet minder matig is dan PHP) uberhaupt nooit backend gedraaid werd en wat toch redelijk geslaagd genoemd mag worden (in ieder geval heerst er niet hetzelfde sentiment als bij PHP). Dit heeft ook weer de weg vrijgemaakt voor bredere adoptie van Typescript.

Dat is buiten mijn sentiment gerekend dan
(javascript is ook inconsequent, ook veel lelijke syntax constructies, ook vanuit een nog ergere puinzooi beter geworden ... echter wel met het verschil dat je client-side nog moeilijk om javascript heen kunt en het de vraag nog is of webasm zo fijn gaat zijn). En ik vraag me ook nog steeds of waarom je javascript persé uit z'n niche zou willen halen. Tevens heb ik niet de indruk dat nodejs nog heel erg hard gaat qua adoptie en zeker niet omdat het prettig is om mee te werken. Het nagenoeg enige wat in het voordeel zou kunnen spreken is dezelfde taal voor front en backend, maar goed soms kan een scheiding (en dus de nood voor een (goed gedefinieerde) interface wellicht juist beter zijn.

Kijk, prima als je op basis van 'wat je al weet' verder bouwt, maar mij bekruipt toch vooral het gevoel dat mensen zonder ervaring met de huidige manier van werken PHP veroordelen op een imago van 10 jaar geleden (wat toen al discutabel was).

Nouja ik vraag me af of het de moeite dus nog waard is om van PHP nog iets proberen te maken buiten haar bestaande niche. Ik snap dat mensen die er in geinvesteerd hebben het doen, maar of je er in mee moet gaan ...

[ Voor 26% gewijzigd door gekkie op 03-09-2020 15:38 ]

[PatrickH89]

RagingPenguin schreef op donderdag 3 september 2020 @ 15:31:
[...]


Javascript/node staat toch echt wel op een wat hoger niveau dan php hoor. Fatsoenlijke concurrency, map en set data types naast arrays, niet gelimiteerd tot gci mode, lambda's (oke krijg php nu ook, maar dan nog steeds met gekke scoping regels). Dat maak(te) node een hele goede keuze voor IO-heavy stuff, iets wat voor php juist een grote achilleshiel is. (niet dat ik zo'n grote fan van node ben, maar het is niet zo slecht als php)

Ik ben nog steeds benieuwd waarom map and set naast arrays nodig zijn voor 'het serieuze werk', kun je daar iets meer over vertellen? Maar concurrency zijn inmiddels oplossingen voor die ik hierboven heb genoemd (granted, nog geen onderdeel van de taal zelf). En Lambda's 'krijgt PHP nu ook' vind ik een vreemde uitspraak aangezien de release van PHP 5.3 toch wel een eindje achter ons ligt. Mocht je de arrow functions bedoelen, dan ligt die release ook alweer in 2019.

'Slecht' mag je overigens wel definiëren in deze, lijkt me een beetje arbitrair voor een taal die zo populair is en daarnaast een groeiende developerscommunity heeft.

[Ed Vertijsment]

gekkie schreef op donderdag 3 september 2020 @ 15:33:
javascript is ook inconsequent, ook veel lelijke syntax constructies

Mag ik, uit interesse vragen welke syntax constructies je lelijk vind?

gekkie schreef op donderdag 3 september 2020 @ 15:33:
En ik vraag me ook nog steeds of waarom je javascript persé uit z'n niche zou willen halen

My best guess, bij gebrek aan iets beters? JavaScript is begonnen als scripttaal voor UI's, dus asynchronous by nature (hoewel in de basis ook single threaded). Een asynchrone "hoge" taal past gewoon goed bij de workloads van vadaag, daarnaast zijn er simpelweg veel developers voor te vinden wat in tijden van schaarste handig is. En verder, tja, alles lijkt tegenwoordig wel een website te worden...

gekkie schreef op donderdag 3 september 2020 @ 15:33:
Tevens heb ik niet de indruk dat nodejs nog heel erg hard gaat qua adoptie

Valt volgens mij inderdaad wel mee.

https://trends.google.nl/...205-y&q=nodejs,python,php

gekkie schreef op donderdag 3 september 2020 @ 15:33:
zeker niet omdat het prettig is om mee te werken. Het nagenoeg enige wat in het voordeel zou kunnen spreken is dezelfde taal voor front en backend, maar goed soms kan een scheiding (en dus de nood voor een (goed gedefinieerde) interface wellicht juist beter zijn.

NodeJS zelf werk ik vrij weinig mee (wel JavaScript) ik vind NodeJS overigens niet vervelend, al mogen we wel een keer op dependency dieet. Qua interface? Ja interfaces, niet (perse) gelijke talen.

[Alex)]

Een tijdje geleden heb ik een keer een browser extension gemaakt voor Chrome. Gewoon op de ouderwetse manier: door zelf wat .js-files in mappen te plaatsen en dat allemaal in een .zip'je te gooien. Dat werkte best wel goed, maar het voelt een beetje klunzig aan in de tijd van package managers en repo's.

Nou ben ik me eens aan het verdiepen in de 'moderne' manier van webdevelopment: npm dus. En webpack. En hoe dat te combineren valt met het ontwikkelen van een Chrome extension.

En ik kom er maar niet uit hoe ik chrome.extension.getURL() in een webpack-friendly manier kan gebruiken. Ik heb precies één loader gevonden die beweert daarmee overweg te kunnen, maar natuurlijk is de documentatie té schaars en lijkt het project zelf dood te zijn (geen commits op Github).

[whoami]

azerty schreef op woensdag 2 september 2020 @ 14:45:
[...]


Gaf mijn gebruikersnaam weg welke voorkeur ik heb soms?

'k vond het een inkoppertje

* whoami gebruikt zelf ook azerty; dat komt ervan als je uit België komt.

Koenvh schreef op woensdag 2 september 2020 @ 15:02:
[...]

Ik beheer ook mede een Duitse Windows server, en elke keer dat ik daarnaar RDP mag ik naar QWERTZ omschakelen. Echt heel praktisch, vooral omdat het meeste wel op de juiste plek zit. Ik had toch eigenlijk verwacht dat als RDP mijn lokale printers kan gebruiken, dat dan de toetsenbordindeling overnemen ook niet te veel gevraagd zou zijn.

Ik heb hetzelfde probleem.
Af en toe moet ik eens rdp'en met een server die op een griekse boot staat. Keyboard instellingen zijn daar qwerty. Kan ondertussen al best qwerty typen op een azerty

[ Voor 52% gewijzigd door whoami op 03-09-2020 16:45 ]

[ThomasG]

Als er iets is wat volledig geschrapt mag worden uit de wereld geschiedenis, zijn het wel Azerty toetsenborden. Daar is gewoon niet op de typen.

[LEDfan]

whoami schreef op donderdag 3 september 2020 @ 16:44:
[...]

'k vond het een inkoppertje

* whoami gebruikt zelf ook azerty; dat komt ervan als je uit België komt.\

In veel informatica richtingen op hogescholen en universiteiten maar ook in bedrijven lijken ze toch veel qwerty te gebruiken.
Ik zie bij mij collega studenten toch ook dat er een aantal waren die al qwerty gebruikte of na de unief ook bij qwerty blijven.
In ICT gerelateerde jobs kom ik echt bijna alleen qwerty tegen. Ook de internationale context (al is het maar NL) helpt hierbij denk ik.
Misschien dat Franstalige Belgen nog wel meer met azerty typen, aangezien zij meer baat hebben bij de accenten.
Zelf zou ik voor programmeren niet meer aan azery willen beginnen...

[RagingPenguin]

PatrickH89 schreef op donderdag 3 september 2020 @ 16:18:
[...]


Ik ben nog steeds benieuwd waarom map and set naast arrays nodig zijn voor 'het serieuze werk', kun je daar iets meer over vertellen?

Als je 10000 records uit een database haalt en daar een excel export van opbouwt dan merk je echt wel verschil tussen een fatsoenlijke btree search of een array index t.o.v. een foreach over een map. Om maar een voorbeeldje te noemen. Z.g.a elk algoritme rust op het gebruik van de juiste data structuren en php heeft alleen maar een vreemde hybride tussen een map en een array die nooit helemaal de juiste keuze is. Goede collecties zijn essentieel voor het verwerken van veel data.

Waar het dan weer niet uitmaakt is in je standaard crud api die misschien per 100 gepagineerd en verder weinig boeiends doet met de data.

Maar concurrency zijn inmiddels oplossingen voor die ik hierboven heb genoemd (granted, nog geen onderdeel van de taal zelf).

Door een extra process te draaien waar je via tcp mee moet praten en zonder gedeeld geheugen. Leuk dat er een mooie api op ligt, maar zo'n ducktape oplossing is geen vergelijk met daadwerkelijke concurrency. Volgens die logica is node multithreaded omdat je via workers meerdere processen kan draaien. Niet dus.

En Lambda's 'krijgt PHP nu ook' vind ik een vreemde uitspraak aangezien de release van PHP 5.3 toch wel een eindje achter ons ligt. Mocht je de arrow functions bedoelen, dan ligt die release ook alweer in 2019.

Een lambda is inderdaad wat je in php met een arrow maakt (lijkt me niet zo verwarrend, lambda komt van lambdacalculus en heeft best wel strikte definities?).

'Slecht' mag je overigens wel definiëren in deze, lijkt me een beetje arbitrair voor een taal die zo populair is en daarnaast een groeiende developerscommunity heeft.

'niet zo slecht als php' is een relatieve term, dus waarom verwacht je een absolute definitie van 'slecht'?

[gekkie]

Ed Vertijsment schreef op donderdag 3 september 2020 @ 16:18:
[...]
Mag ik, uit interesse vragen welke syntax constructies je lelijk vind?

Meeste kun je tegenwoordig wel, maar het ouderwetsche C geloop over de elements van een array.

Heb wat te weinig recente javascript ervaring om er nog recente voorbeelden van te geven.
(niet het beste argument dus )

[azerty]

whoami schreef op donderdag 3 september 2020 @ 16:44:
[...]

'k vond het een inkoppertje

* whoami gebruikt zelf ook azerty; dat komt ervan als je uit België komt.


[...]

Ik heb hetzelfde probleem.
Af en toe moet ik eens rdp'en met een server die op een griekse boot staat. Keyboard instellingen zijn daar qwerty. Kan ondertussen al best qwerty typen op een azerty

Qwerty op azerty gaat inderdaad ook vrij vlot tegenwoordig

[Vihaio]

ThomasG schreef op donderdag 3 september 2020 @ 16:49:
Als er iets is wat volledig geschrapt mag worden uit de wereld geschiedenis, zijn het wel Azerty toetsenborden. Daar is gewoon niet op de typen.

Of qwerty. Het wordt tijd dat iedereen Colemak of een andere fatsoenlijke lay-out gaat gebruiken.

[Ed Vertijsment]

gekkie schreef op donderdag 3 september 2020 @ 17:01:
[...]

Meeste kun je tegenwoordig wel, maar het ouderwetsche C geloop over de elements van een array.

JavaScript:

const myArray = [1,2,3];

myArray.forEach(n => console.log(n));

Of lees hier: https://voidcanvas.com/al...ript-a-brief-explanation/

Ik hoor vrij vaak varianten van "JavaScript is matig" maar zelden komt de uitleg verder dan (ik quote jouw even maar niets persoonlijks):

gekkie schreef op donderdag 3 september 2020 @ 17:01:
Heb wat te weinig recente javascript ervaring om er nog recente voorbeelden van te geven.

JavaScript heeft in die zin last van het zelfde imago probleem als PHP. Veel van de onderbuikgevoelens jegens de taal zijn gebaseerd op ervaringen van >10 jaar geleden. Zeker de laatste jaren is JavaScript ontzettend verbeterd.

P.S. Met name het Array prototype is naar mijn mening over het algemeen zeer elegant.

[Hipska]

Mugwump schreef op donderdag 3 september 2020 @ 10:57:
[...]

Er is ook een prima reden dat bijvoorbeeld de drie grote cloudplatformen PHP niet standaard ondersteunen in hun serverless oplossingen en AWS en Azure wel bijvoorbeeld nog Go en Ruby, die qua populariteit / gebruik nog niet het niveau van PHP halen.

Vreemd, heb gisteren nog net een php web app in Azure gezet.

[gekkie]

Ed Vertijsment schreef op donderdag 3 september 2020 @ 17:47:
[...]

JavaScript:

const myArray = [1,2,3];

myArray.forEach(n => console.log(n));

Of lees hier: https://voidcanvas.com/al...ript-a-brief-explanation/

Ik hoor vrij vaak varianten van "JavaScript is matig" maar zelden komt de uitleg verder dan (ik quote jouw even maar niets persoonlijks):

Hmmm beetje krom opgeschreven van me (moest er net vlot van tussen), bedoelde dat het voorbeeld van array loopjes nu dus inderdaad beter is met forEach etc.. En de lelijke syntax inderdaad deels iets uit het verleden is.

[RagingPenguin]

Hipska schreef op donderdag 3 september 2020 @ 17:51:
[...]

Vreemd, heb gisteren nog net een php web app in Azure gezet.

Ik denk dat die naar Azure Functions verwees. Azure hosting kan gewoon alles wat je maar wilt, de enige vraag is hoeveel je zelf moet opzetten en hoeveel er al in een template zit.

[Kalentum]

gekkie schreef op donderdag 3 september 2020 @ 14:46:
En ik zie dat soort nieuwe PHP zaken dan ook, zeker met de implementatie geschiedenis van PHP, ook niet heel snel als "enterprise ready".

Niet zozeer als kritiek op jou, maar ik zie het vaker voorbij komen. Wat is eigenlijk 'enterprise ready'?

Is Python wel enterprise ready? Of Ruby? En indien ja, wat kan je dan niet met PHP waardoor het niet 'enterprise ready' is?

[Koenvh]

Kalentum schreef op donderdag 3 september 2020 @ 18:09:
[...]


Niet zozeer als kritiek op jou, maar ik zie het vaker voorbij komen. Wat is eigenlijk 'enterprise ready'?

Is Python wel enterprise ready? Of Ruby? En indien ja, wat kan je dan niet met PHP waardoor het niet 'enterprise ready' is?

Het moet in een ruimteschip starship met mach 5 nog blijven werken, dan is het Enterprise ready

[Mugwump]

Hipska schreef op donderdag 3 september 2020 @ 17:51:
[...]

Vreemd, heb gisteren nog net een php web app in Azure gezet.

Ik heb het ook niet over app services, elastic beanstalk of app engine, maar over de FaaS oplossingen. Dat is doorgaans waar men het over heeft bij serverless.

[gekkie]

Kalentum schreef op donderdag 3 september 2020 @ 18:09:
[...]
Niet zozeer als kritiek op jou, maar ik zie het vaker voorbij komen. Wat is eigenlijk 'enterprise ready'?

Is Python wel enterprise ready? Of Ruby? En indien ja, wat kan je dan niet met PHP waardoor het niet 'enterprise ready' is?

Die schuif ik door naar @PatrickH89 die het als eerste aanhaalde.

Wat mij betreft hangt dat niet alleen van de taal af, maar als er een geheel nieuwe syntax / construct / paradigma is, waarvan je je ook nog kan afvragen of het niet geducktaped is (dat rachet bijvb. bij PHP), dan vraag ik me wel af of je daar je enterprise op wilt bouwen.

Of dat als je dat nodig gaat hebben, je zou gaan overwegen of er talen en frameworks zijn waar het natuurlijker in past, kijkt of er ook nog eventuele andere voordelen zijn, of je er fiducie in hebt dat iets verder ontwikkeld gaat worden en voldoende populair is en blijft, zodat je het niet (alleen) zelf hoeft te gaan onderhouden.

En uiteindelijk je app dan wellicht volledig gaat migreren omdat je de huidige taal / framework wellicht wat ontgroeid bent en verder investeren daar in ook niet zonder risico is (implementeren in een andere taal ook niet, ook afhankelijk van of je daar de resources voor hebt, daar niet van).

Eigenlijk dus meer een (bedrijfs)economisch iets, afwegingen tussen kosten, baten, risico's, kansen, resources, de hele mik mak.

Met python kun je daar ook wel aan twijfelen hoor. python 2to3, vervolgens met 3 eerst async in een heleboel frameworks, uiteindelijk als syntax in de taal etc. Dan hou je nog de GIL over, risico's in memory management .. en ducktyping (al kun je dan nu ook wel type hints geven, dat hebben een hoop libs dan nog weer niet). Dus nee ook niet voor alles "enterprisy" echt de eerste keus, maar voor een hoop ook wel bruikbaar.

En wat PHP betreft .. tsja het is eigenlijk nergens (meer) exceptioneel beter / eenvoudiger in en je hebt gewoon risico's dat als je een gebruik wilt gaan maken van dingen als websockets het dan al gauw ducktapen wordt. Het enige wat er nog voor spreekt is dat er een hoop legacy code beschikbaar is in combinatie met een hoop legacy (intern) beschikbare resources (programmeurs die er iets mee kunnen).

[ Voor 21% gewijzigd door gekkie op 03-09-2020 18:54 ]

[RagingPenguin]

Kalentum schreef op donderdag 3 september 2020 @ 18:09:
[...]


Niet zozeer als kritiek op jou, maar ik zie het vaker voorbij komen. Wat is eigenlijk 'enterprise ready'?

Is Python wel enterprise ready? Of Ruby? En indien ja, wat kan je dan niet met PHP waardoor het niet 'enterprise ready' is?

"Enterprise applications are about the display, manipulation, and storage of large amounts of often complex data and the support or automation of business processes with that data."
- Martin Fowler

'Enterprise' gaat voornamelijk om schaling en de mogelijkheid om met veel data te werken in de context van backend programmeertalen. Enterprise gaat vaak samen met 'mission critical', maar het is wel goed om die twee termen uit elkaar te halen. Veel enterprise is gewoon administratie op schaal waarbij de kosten van een uurtje downtime prima te overzien valt.

Hierom is bv. dotnet heel goed in een enterprise content (LINQ, ef core, multi threading, 1st party support voor excel, etc) en is php een van de slechtere keuzes (beperkte datastructuren, een limiet op ram en functioncalls binnen een request, etc).

[Mugwump]

Martin wie?

[azerty]

Mugwump schreef op donderdag 3 september 2020 @ 18:27:
Martin wie?

Martijn Bloem, je kent hem toch wel zeker?

[gekkie]

azerty schreef op donderdag 3 september 2020 @ 18:53:
[...]
Martijn Bloem, je kent hem toch wel zeker?

Deze https://mostware.nl/specialist/martijn-bloem/ ?

[Koenvh]

azerty schreef op donderdag 3 september 2020 @ 18:53:
[...]


Martijn Bloem, je kent hem toch wel zeker?

Ik had een grap over Martijn Bloem, maar in 't Engels is 'ie flower

[gekkie]

Koenvh schreef op donderdag 3 september 2020 @ 19:25:
[...]
Ik had een grap over Martijn Bloem, maar in 't Engels is 'ie flower

Is Koenvh het pseudoniem van Herman Finkers alhier ?, meester van het bloemrijk taalgebruik .

[RagingPenguin]

Ik denk dat ik de nieuwe manier heb gevonden om deze chat nieuw leven in te blazen Kan php wel helemaal bij het grof vuil

[Kalentum]

gekkie schreef op donderdag 3 september 2020 @ 18:18:
[...]

Die schuif ik door naar @PatrickH89 die het als eerste aanhaalde.

Wat mij betreft hangt dat niet alleen van de taal af, maar als er een geheel nieuwe syntax / construct / paradigma is, waarvan je je ook nog kan afvragen of het niet geducktaped is (dat rachet bijvb. bij PHP), dan vraag ik me wel af of je daar je enterprise op wilt bouwen.

Dat is dus mijn vraag: wat bedoel je met 'enterprise'? Wat is het beeld dat je daarbij hebt? Als ik een 'enterprise' (is dat een product?) heb, op welk punt kan het niet in taal X? Welke functionele eisen bepalen wat 'enterprise' is?

RagingPenguin schreef op donderdag 3 september 2020 @ 18:23:
[...]


"Enterprise applications are about the display, manipulation, and storage of large amounts of often complex data and the support or automation of business processes with that data."
- Martin Fowler

'Enterprise' gaat voornamelijk om schaling en de mogelijkheid om met veel data te werken in de context van backend programmeertalen. Enterprise gaat vaak samen met 'mission critical', maar het is wel goed om die twee termen uit elkaar te halen. Veel enterprise is gewoon administratie op schaal waarbij de kosten van een uurtje downtime prima te overzien valt.

Hierom is bv. dotnet heel goed in een enterprise content (LINQ, ef core, multi threading, 1st party support voor excel, etc) en is php een van de slechtere keuzes (beperkte datastructuren, een limiet op ram en functioncalls binnen een request, etc).

Maar in PHP kun je ook mission critical (met downtime) applicaties bouwen die een administratie op schaal regelen, met 'veel' data, waarbij je ook nog eens leuk opgemaakte Excelsheets kan maken. Ik ben te lang uit PHP om te begrijpen wat beperkte datastructuren zijn (wat kan wel in .net wat niet in PHP kan?).

Desnoods bouw je je .NET applicatie in PHP want dat kan ook. Is PHP dan wel 'enterprise ready'? Is het alleen maar de library die de 'enterpriseness' bepaald?

[RagingPenguin]

Kalentum schreef op donderdag 3 september 2020 @ 20:02:
Dat is dus mijn vraag: wat bedoel je met 'enterprise'? Wat is het beeld dat je daarbij hebt? Als ik een 'enterprise' (is dat een product?) heb, op welk punt kan het niet in taal X? Welke functionele eisen bepalen wat 'enterprise' is?

Enterprise is de context waarin je je software gebruikt en heeft invloed op functionele eisen. Dat is natuurlijk geen harde grens, maar een schaal van ongeschikt naar heel geschikt. Enterprise omgevingen kenmerken zich voornamelijk door de grote schaal en een nadruk op het verwerken van grote hoeveelheden data. Daarnaast wordt er verwacht van enterprise software dat het makkelijk integreert met enterprise software pakketten (ERP's, CRM's ed). Vaak zijn in het enterprise wereldje SLA's en XLA's ook erg belangrijk.

Maar in PHP kun je ook mission critical (met downtime) applicaties bouwen die een administratie op schaal regelen, met 'veel' data, waarbij je ook nog eens leuk opgemaakte Excelsheets kan maken. Ik ben te lang uit PHP om te begrijpen wat beperkte datastructuren zijn (wat kan wel in .net wat niet in PHP kan?).

PHP heeft geen arrays en geen hashing om effectieve (b)trees te bouwen (enkel one-size-fits-all ordered maps). Dat is ontzetten limiterend op hoe efficiënt je grote hoeveelheden data kan verwerken. (Ik hoop dat je van de Big-O notatie hebt gehoord en iets weet van algoritmes en datastructuren?). Daarnaast heeft een PHP proces altijd een geheugen limiet en een limiet op de functie call dept waardoor je ook nog een harde limiet hebt op hoeveel data je in je geheugen kan hebben. Wat als je een excel opbouwen van meerdere gbs gewoon onmogelijk maakt waar in iets als dotnet een thread gewoon tijdelijk meer geheugen gebruikt. Die schaling heeft php niet.

Desnoods bouw je je .NET applicatie in PHP want dat kan ook. Is PHP dan wel 'enterprise ready'? Is het alleen maar de library die de 'enterpriseness' bepaald?

Eeh nee? Je kan een dotnet applicatie bouwen en die vervolgens via COM aan php knopen. Maar doet php niks anders dan een dotnet executable uitvoeren en wachten op het resultaat. Je programmeert dan in een van de CLR talen (C#, F#, c++, VB enz.).

En dat is altijd de oplossing geweest voor alles wat geen simpel scriptje is in php: doe het in een andere taal en knoop het via een extensie/com/tcp aan elkaar (wat ook direct een van de grootste veroorzakers is van het ducktape gehalte van php). En hoewel dat prima is voor generieke extensies zoals bv. imagick wil je niet je daadwerkelijke domain code gaan stoppen in een php-extensie. Dan kan je beter direct een geschikte taal gebruiken en daar alles in doen.

[PatrickH89]

RagingPenguin schreef op donderdag 3 september 2020 @ 16:59:


Door een extra process te draaien waar je via tcp mee moet praten en zonder gedeeld geheugen. Leuk dat er een mooie api op ligt, maar zo'n ducktape oplossing is geen vergelijk met daadwerkelijke concurrency. Volgens die logica is node multithreaded omdat je via workers meerdere processen kan draaien. Niet dus.

Heb je je verdiept in die aparte oplossingen? Swoole bijvoorbeeld is misschien de meest uitgebreide en heeft absoluut gedeeld geheugen. Als je het hebt over 'daadwerkelijke concurrency' dan is Swoole net zo concurrent als bijvoorbeeld Node. Ik ben overigens blij dat puur het verwerken van 10k regels aan data (wat hoe dan ook niet schaalt tenzij je met cursors en fopen werkt en daarmee dus ook prima werkt in PHP) wat bepaalt of iets geschikt is voor 'serieuze applicaties'.
Qua performance zijn er in dit opzicht overigens inderdaad betere opties dan PHP, maar als je hele stack in PHP zou zijn dan zou het verder ook weer nauwelijks problemen opleveren. Ook voor PHP is het genereren van een Excel met 10k regels peanuts, je moet alleen een heel klein beetje weten wat je doet.

[RagingPenguin]

PatrickH89 schreef op donderdag 3 september 2020 @ 20:47:
[...]


Heb je je verdiept in die aparte oplossingen? Swoole bijvoorbeeld is misschien de meest uitgebreide en heeft absoluut gedeeld geheugen. Als je het hebt over 'daadwerkelijke concurrency' dan is Swoole net zo concurrent als bijvoorbeeld Node. Ik ben overigens blij dat puur het verwerken van 10k regels aan data (wat hoe dan ook niet schaalt tenzij je met cursors en fopen werkt en daarmee dus ook prima werkt in PHP) wat bepaalt of iets geschikt is voor 'serieuze applicaties'.

Je bedoeld Swoole tables? Dat is meer een in-memory database dan gedeeld geheugen. Al hebben we het over shared memory tusses threads dan betekend dat dat je

code:

$foo = new Foo()

kan doen en je $foo ook in andere threads kan gebruiken. Niet dat je een tabel object moet aanmaken, kolommen moet definiëren en dan rijen kan invoegen. Dit is typisch zo'n php ducktape oplossing: we hebben geen shared memory dus maken we maar een mooie api om een in-memory database en gebruiken/misbruiken het als shared memory.

[Kalentum]

RagingPenguin schreef op donderdag 3 september 2020 @ 20:31:
[...]


Enterprise is de context waarin je je software gebruikt en heeft invloed op functionele eisen. Dat is natuurlijk geen harde grens, maar een schaal van ongeschikt naar heel geschikt. Enterprise omgevingen kenmerken zich voornamelijk door de grote schaal en een nadruk op het verwerken van grote hoeveelheden data. Daarnaast wordt er verwacht van enterprise software dat het makkelijk integreert met enterprise software pakketten (ERP's, CRM's ed). Vaak zijn in het enterprise wereldje SLA's en XLA's ook erg belangrijk.

Maar wat is Enterprise? een product? Is Facebook enterprise? Of Nationale Nederlanden? Slager op de hoek? een bedrijf dat 2000 projecten per jaar doet? Philips? Is 'enterprise' een onderneming?

Ik blijf het een vage term vinden. Blijkbaar heb jij er een beeld bij, maar ik heb het niet.

PHP heeft geen arrays en geen hashing om effectieve (b)trees te bouwen (enkel one-size-fits-all ordered maps). Dat is ontzetten limiterend op hoe efficiënt je grote hoeveelheden data kan verwerken. (Ik hoop dat je van de Big-O notatie hebt gehoord en iets weet van algoritmes en datastructuren?). Daarnaast heeft een PHP proces altijd een geheugen limiet en een limiet op de functie call dept waardoor je ook nog een harde limiet hebt op hoeveel data je in je geheugen kan hebben. Wat als je een excel opbouwen van meerdere gbs gewoon onmogelijk maakt waar in iets als dotnet een thread gewoon tijdelijk meer geheugen gebruikt. Die schaling heeft php niet.

Ik bedoel dit echt niet om te zieken ofzo, maar wat voor dataprocessing doe jij dan dat je je processing niet meer in PHP kan doen? Ik dacht altijd dat juist in de administratieve software toch vooral gewerkt wordt met relationele datamodellen. Dus dan zit je btree gewoon in je index van je database. Wat voor 'grote hoeveelheden data' zit je dan aan te denken?

Eeh nee? Je kan een dotnet applicatie bouwen en die vervolgens via COM aan php knopen. Maar doet php niks anders dan een dotnet executable uitvoeren en wachten op het resultaat. Je programmeert dan in een van de CLR talen (C#, F#, c++, VB enz.).

PHP kan je ook als CLR inzetten. .Net is taalagnostisch.

En dat is altijd de oplossing geweest voor alles wat geen simpel scriptje is in php: doe het in een andere taal en knoop het via een extensie/com/tcp aan elkaar (wat ook direct een van de grootste veroorzakers is van het ducktape gehalte van php). En hoewel dat prima is voor generieke extensies zoals bv. imagick wil je niet je daadwerkelijke domain code gaan stoppen in een php-extensie. Dan kan je beter direct een geschikte taal gebruiken en daar alles in doen.

Nu kom je op het niveau van implementatie en dat heb ik altijd gek gevonden: dat je een binary hebt maar alle shit die je mogelijk nodig hebt er gewoon ingebakken.

Ik heb PHP al zes jaar niet meer gebruikt dus wellicht weet jij er meer van dan ik maar domain code heb ik nog nooit in een extensie gestopt!

[gekkie]

PatrickH89 schreef op donderdag 3 september 2020 @ 20:47:
[...]
Heb je je verdiept in die aparte oplossingen? Swoole bijvoorbeeld is misschien de meest uitgebreide en heeft absoluut gedeeld geheugen. Als je het hebt over 'daadwerkelijke concurrency' dan is Swoole net zo concurrent als bijvoorbeeld Node. Ik ben overigens blij dat puur het verwerken van 10k regels aan data (wat hoe dan ook niet schaalt tenzij je met cursors en fopen werkt en daarmee dus ook prima werkt in PHP) wat bepaalt of iets geschikt is voor 'serieuze applicaties'.
Qua performance zijn er in dit opzicht overigens inderdaad betere opties dan PHP, maar als je hele stack in PHP zou zijn dan zou het verder ook weer nauwelijks problemen opleveren. Ook voor PHP is het genereren van een Excel met 10k regels peanuts, je moet alleen een heel klein beetje weten wat je doet.

Misschien een jaar te oud, maar echt hoopgevend klonk het toen nou ook weer niet:
https://tsh.io/blog/php-websocket/

Maar als je de keuze zou hebben (blik programmeurs voor elke taal) zou je dan nog een (web)app waar de
kans op het willen gebruiken van bijvb websockets aanwezig is, werkelijk nog gaan uitwerken in PHP?

Wat missen andere talen dan, wat PHP wel heeft ter compensatie ?

[PatrickH89]

Dat is afhankelijk van de zwaarte van de applicatie (en de zwaarte van de websockets functionaliteit). Als ik een blik programmeurs zou hebben voor elke taal zou PHP in dit geval niet de eerste keuze zijn, maar dat geldt ook voor talen als Python en Ruby. Dat zijn vooral de talen waar PHP een alternatief voor kan zijn denk ik.
Mocht de functionaliteit van websockets niet heel bijzonder zijn dan zijn er ook in PHP genoeg simpele oplossingen (cli command die altijd draaiende wordt gehouden) tot wat ingewikkeldere oplossingen zoals Ratchet of Swoole.

Maar goed, zulke clean slates heb je zelden. Je hebt altijd te maken met de kennis van je developers en de applicaties die al ontwikkeld zijn. In die situatie is er weinig tot niets mis met PHP (en is het zo schaalbaar als je wilt). In zijn standaard vorm is PHP totaal niet afhankelijk van een server en oneindig horizontaal schaalbaar, puur omdat elk proces ophoudt nadat de request is afgehandeld. Dus in die zin was PHP 'serverless' voordat het cool was.

[RagingPenguin]

Kalentum schreef op donderdag 3 september 2020 @ 21:05:
[...]


Maar wat is Enterprise? een product? Is Facebook enterprise? Of Nationale Nederlanden? Slager op de hoek? een bedrijf dat 2000 projecten per jaar doet? Philips? Is 'enterprise' een onderneming?

Ik blijf het een vage term vinden. Blijkbaar heb jij er een beeld bij, maar ik heb het niet.

Zoals ik al zei, het is een schaal en geen harde term. Verder denk ik dat het beter is als je 'enterprise software' in Google typed (no-offence maar ik weet echt niet hoe ik het beter zou moeten uitleggen).

[...]


Ik bedoel dit echt niet om te zieken ofzo, maar wat voor dataprocessing doe jij dan dat je je processing niet meer in PHP kan doen? Ik dacht altijd dat juist in de administratieve software toch vooral gewerkt wordt met relationele datamodellen. Dus dan zit je btree gewoon in je index van je database. Wat voor 'grote hoeveelheden data' zit je dan aan te denken?

Als al je data in een enkele database zit, ja true. Maar al wilt je finance afdeling een export met openstaande facturen per klant en je haalt een lijst met projecten uit je ERP, een lijst met facturen een oracle database en een lijst met contactpersonen uit je CRM en moet die data in-memory joinen to rijen met factureren + project + contactpersoon dan gaat die vlieger niet op. En dan zijn schalende data structuren heel belangrijk, het verschil tussen O(n) en O(log(n)) voor het opzoeken van de juiste objecten word met duizenden rijen enorm.

(ook een typisch voorbeeld van 'enterprise' software)

PHP kan je ook als CLR inzetten. .Net is taalagnostisch.

Oke, fair point. Maar hoeveel php draait er op dotnet en hoeveel op een server in gci? En waarom zou je php willen gebruiken als je al een dotnet omgeving hebt? Wat heeft php wat de extra moeite waard maakt?

Nu kom je op het niveau van implementatie en dat heb ik altijd gek gevonden: dat je een binary hebt maar alle shit die je mogelijk nodig hebt er gewoon ingebakken.

Ik snap deze zin niet helemaal? Vind je het gek dat sommige talen met een hoop data structuren komen? Eigenlijk heeft de taal zelf niets meer nodig dan arrays en een efficiënte manier om een hash van een value te maken en dan kan je alles implementeren als een library.

PatrickH89 schreef op donderdag 3 september 2020 @ 21:23:
In zijn standaard vorm is PHP totaal niet afhankelijk van een server en oneindig horizontaal schaalbaar, puur omdat elk proces ophoudt nadat de request is afgehandeld. Dus in die zin was PHP 'serverless' voordat het cool was.

Dat is wel een hele ruime interpretatie van term 'serverless' . Zeker als je nagaat hoe sterk php in een webserver zit verweven (mod_php anyone?).

[Mugwump]

PatrickH89 schreef op donderdag 3 september 2020 @ 21:23:
Dat is afhankelijk van de zwaarte van de applicatie (en de zwaarte van de websockets functionaliteit). Als ik een blik programmeurs zou hebben voor elke taal zou PHP in dit geval niet de eerste keuze zijn, maar dat geldt ook voor talen als Python en Ruby. Dat zijn vooral de talen waar PHP een alternatief voor kan zijn denk ik.

Ik vind Python nog wel een stuk breder. Data science in PHP, ik zie het nog niet zo.