Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

De Devschuur Coffee Corner - Iteratie ⓬ Vorige deelOverzicht

Pagina: 1 ... 73 74 75 Laatste
Acties:

  • Xessive
  • Registratie: januari 2011
  • Laatst online: 16-09 16:07
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 *

Seriously? Nope, not a bit...


  • azerty
  • Registratie: maart 2009
  • Laatst online: 16:46

azerty

McFly

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? :+

  • wttj
  • Registratie: december 2012
  • Niet online
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
  • Registratie: april 2012
  • Laatst online: 22-09 09:15
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.

.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!


  • gekkie
  • Registratie: april 2000
  • Laatst online: 00:35
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 :+

  • wttj
  • Registratie: december 2012
  • Niet online
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? :P
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
  • Registratie: april 2010
  • Laatst online: 22:20
wttj schreef op woensdag 2 september 2020 @ 10:26:
[...]
Dat is wel sarcastisch, righth? :P
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
  • Registratie: februari 2004
  • Laatst online: 15:03
wttj 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 :)

Read the code, write the code, be the code!


  • gekkie
  • Registratie: april 2000
  • Laatst online: 00:35
wttj 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
  • Registratie: mei 2013
  • Laatst online: 20:07

m-vw

GEZOCHT: De Kluts

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.

Garmin FR245M + HRM-RUN


  • Wilf
  • Registratie: maart 2007
  • Niet online
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 :D moesten we allerlei trucs bedenken om die troep stiller te krijgen en waterkoeling van een laptop was nog niet echt ‘een ding’. :)

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 22:50

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

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. :+

Call me cocky, but if there's an alien out there I can't kill I haven't met him and killed him yet. But I can't go in alone. That's why I'm ordering every available ship to report for duty. Anyone else should secure a weapon and fire wildly into the air.


  • hellum
  • Registratie: oktober 2007
  • Laatst online: 14:50
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
  • Registratie: mei 2017
  • Laatst online: 23:23
wttj schreef op woensdag 2 september 2020 @ 10:26:
[...]


Dat is wel sarcastisch, righth? :P


[...]


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.

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim"


  • whoami
  • Registratie: december 2000
  • Laatst online: 20:44
Als het maar een qwerty is.

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 22:50

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

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]

Call me cocky, but if there's an alien out there I can't kill I haven't met him and killed him yet. But I can't go in alone. That's why I'm ordering every available ship to report for duty. Anyone else should secure a weapon and fire wildly into the air.


  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
.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]

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • armageddon_2k1
  • Registratie: september 2001
  • Laatst online: 20:04
Knuppel in hoenderhok:

Waarom is Tweakers backend eigenlijk nog niet over op Rust?

Passieve Einzelgänger met een 10 tot 3 mentaliteit


  • Otherside1982
  • Registratie: februari 2009
  • Laatst online: 19:13
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
  • Registratie: september 2001
  • Laatst online: 20:04
Nieuwe programmeertaal: WD-40.

Passieve Einzelgänger met een 10 tot 3 mentaliteit


  • azerty
  • Registratie: maart 2009
  • Laatst online: 16:46

azerty

McFly

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
  • Registratie: september 2000
  • Laatst online: 22:50

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

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 :P

Call me cocky, but if there's an alien out there I can't kill I haven't met him and killed him yet. But I can't go in alone. That's why I'm ordering every available ship to report for duty. Anyone else should secure a weapon and fire wildly into the air.


  • RayNbow
  • Registratie: maart 2003
  • Laatst online: 18:18

RayNbow

Kirika <3

Sneller in wat? Onleesbare fouten uitspugen? O-)

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • Creepy
  • Registratie: juni 2001
  • Laatst online: 22:30

Creepy

Moderator Devschuur®

Tactical Espionage Splatterer

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


Goeiedag, die Panasonic is nu nog steeds best veel waard!! Was de laatste MSX zeker. :9 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 :P 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 +....)

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have star problems" --Kevlin Henney


  • Koenvh
  • Registratie: december 2011
  • Laatst online: 22:28

Koenvh

Hier tekenen: ______

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.

Waarom vandaag doen wat je morgen ook kunt uitstellen?


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:14
RayNbow schreef op woensdag 2 september 2020 @ 14:51:
[...]

Sneller in wat? Onleesbare fouten uitspugen? O-)
Dat is een feature van C++, zodat alle slechte programmeurs een andere taal gebruiken :+

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 22:50

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

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

Sneller in wat? Onleesbare fouten uitspugen? O-)
Als je de fouten niet snapt hoor je PHP te doen }:|

Call me cocky, but if there's an alien out there I can't kill I haven't met him and killed him yet. But I can't go in alone. That's why I'm ordering every available ship to report for duty. Anyone else should secure a weapon and fire wildly into the air.


  • Koenvh
  • Registratie: december 2011
  • Laatst online: 22:28

Koenvh

Hier tekenen: ______

.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:
1
error_reporting(0);

:+

Waarom vandaag doen wat je morgen ook kunt uitstellen?


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:14
Koenvh schreef op woensdag 2 september 2020 @ 15:51:
[...]

In PHP is daar een oplossing voor:
code:
1
error_reporting(0);

:+
En natuurlijk een @ voor elke function call en variable :+

Het leukste van PHP vond ik altijd:
PHP:
1
$query = @mysql_query("...") or die(mysql_error());

  • RayNbow
  • Registratie: maart 2003
  • Laatst online: 18:18

RayNbow

Kirika <3

.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. :p

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • wttj
  • Registratie: december 2012
  • Niet online
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. :p
Maar dat is niet taalspecifiek :9 Bevalve in Go, daar kopieert en plakt iedereen hele lappen code naar hun eigen codebase zodat 1st party verouderde niet onderhouden meuk is }:O

  • kenneth
  • Registratie: september 2001
  • Niet online

kenneth

achter de duinen

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

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 00:02

Janoz

Moderator Devschuur®

!litemod

ThomasG schreef op woensdag 2 september 2020 @ 16:01:
Het leukste van PHP vond ik altijd:
PHP:
1
$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.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 22:50

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

*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]

Call me cocky, but if there's an alien out there I can't kill I haven't met him and killed him yet. But I can't go in alone. That's why I'm ordering every available ship to report for duty. Anyone else should secure a weapon and fire wildly into the air.


  • PrisonerOfPain
  • Registratie: januari 2003
  • Laatst online: 17:50
.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
  • Registratie: april 2000
  • Laatst online: 00:35
Oeh bitch slapping, roestvaststaal tegen corten-staal :p

  • Koenvh
  • Registratie: december 2011
  • Laatst online: 22:28

Koenvh

Hier tekenen: ______

gekkie schreef op woensdag 2 september 2020 @ 20:56:
Oeh bitch slapping, roestvaststaal tegen corten-staal :p
Pas op want ik heb slangen en edelstenen! :P
(en koffie B) )

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

Waarom vandaag doen wat je morgen ook kunt uitstellen?


  • gekkie
  • Registratie: april 2000
  • Laatst online: 00:35
Cola is gevaarlijker voor team-cortenstaal

  • Postman
  • Registratie: februari 2000
  • Laatst online: 23:38
Corten staal roest juist makkelijk ter bescherming, beetje zoals aluminium. Roestvast staal en zuur daarentegen...

Systeemspecs


  • gekkie
  • Registratie: april 2000
  • Laatst online: 00:35
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
  • Registratie: februari 2000
  • Laatst online: 23:38
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.

Systeemspecs


  • Matis
  • Registratie: januari 2007
  • Laatst online: 20:06

Matis

Rubber Rocket

Koenvh schreef op woensdag 2 september 2020 @ 21:13:
Pas op want ik heb slangen en edelstenen! :P
(en koffie B) )
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]

If money talks then I'm a mime
If time is money then I'm out of time


  • Antrax
  • Registratie: april 2012
  • Laatst online: 22-09 09:15
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 :)

.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 22:50

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

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 :)

Call me cocky, but if there's an alien out there I can't kill I haven't met him and killed him yet. But I can't go in alone. That's why I'm ordering every available ship to report for duty. Anyone else should secure a weapon and fire wildly into the air.


  • Mugwump
  • Registratie: mei 2017
  • Laatst online: 23:23
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. :P
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.

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim"


  • SPee
  • Registratie: oktober 2001
  • Laatst online: 21-09 19:18
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.

let the past be the past.


  • OMX2000
  • Registratie: januari 2001
  • Laatst online: 00:44

OMX2000

By any means necessary...

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 :P 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.

Dè developers podcast in je moerstaal : CodeKlets Podcast


  • gekkie
  • Registratie: april 2000
  • Laatst online: 00:35
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 :p) ... oh the joy.

  • Mugwump
  • Registratie: mei 2017
  • Laatst online: 23:23
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.

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim"


  • Wilf
  • Registratie: maart 2007
  • Niet online
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
  • Registratie: december 2011
  • Laatst online: 22:28

Koenvh

Hier tekenen: ______

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.

Waarom vandaag doen wat je morgen ook kunt uitstellen?


  • PatrickH89
  • Registratie: november 2009
  • Laatst online: 20:43
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. :P
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
  • Registratie: december 2011
  • Laatst online: 22:28

Koenvh

Hier tekenen: ______

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 :p) ... oh the joy.
Websockets in PHP kunnen wel met bijvoorbeeld Ratchet ;)

Waarom vandaag doen wat je morgen ook kunt uitstellen?


  • wttj
  • Registratie: december 2012
  • Niet online
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
  • Registratie: april 2000
  • Laatst online: 00:35
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 :)B trekknol een hippe unicorn proberen te maken :') .

  • wttj
  • Registratie: december 2012
  • Niet online
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
  • Registratie: december 2011
  • Laatst online: 22:28

Koenvh

Hier tekenen: ______

wttj 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.

Waarom vandaag doen wat je morgen ook kunt uitstellen?


  • PatrickH89
  • Registratie: november 2009
  • Laatst online: 20:43
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 :)B 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...

  • wttj
  • Registratie: december 2012
  • Niet online
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
  • Registratie: november 2009
  • Laatst online: 20:43
wttj 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.

  • wttj
  • Registratie: december 2012
  • Niet online
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
  • Registratie: april 2000
  • Laatst online: 00:35
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
  • Registratie: november 2009
  • Laatst online: 20:43
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).

  • wttj
  • Registratie: december 2012
  • Niet online
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
  • Registratie: april 2000
  • Laatst online: 00:35
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 :p
(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
  • Registratie: november 2009
  • Laatst online: 20:43
wttj 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
  • Registratie: juli 2014
  • Laatst online: 22:54
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.

svenv.nl


  • Alex)
  • Registratie: juni 2003
  • Laatst online: 21-09 13:58
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). :/

We are shaping the future


  • whoami
  • Registratie: december 2000
  • Laatst online: 20:44
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 :P

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


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:14
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
  • Registratie: juni 2012
  • Laatst online: 21:35
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...

  • wttj
  • Registratie: december 2012
  • Niet online
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
  • Registratie: april 2000
  • Laatst online: 00:35
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 :o )

  • azerty
  • Registratie: maart 2009
  • Laatst online: 16:46

azerty

McFly

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 :P
Qwerty op azerty gaat inderdaad ook vrij vlot tegenwoordig :p

  • Vihaio
  • Registratie: november 2006
  • Laatst online: 21:27
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
  • Registratie: juli 2014
  • Laatst online: 22:54
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:
1
2
3
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.

svenv.nl


  • Hipska
  • Registratie: mei 2008
  • Laatst online: 16:44
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.

Bitcoin.de


  • gekkie
  • Registratie: april 2000
  • Laatst online: 00:35
Ed Vertijsment schreef op donderdag 3 september 2020 @ 17:47:
[...]
JavaScript:
1
2
3
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.

  • wttj
  • Registratie: december 2012
  • Niet online
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
  • Registratie: juni 2004
  • Laatst online: 22:26
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?

PVoutput


  • Koenvh
  • Registratie: december 2011
  • Laatst online: 22:28

Koenvh

Hier tekenen: ______

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 :+

Waarom vandaag doen wat je morgen ook kunt uitstellen?


  • Mugwump
  • Registratie: mei 2017
  • Laatst online: 23:23
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.

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim"


  • gekkie
  • Registratie: april 2000
  • Laatst online: 00:35
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. :P

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]


  • wttj
  • Registratie: december 2012
  • Niet online
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
  • Registratie: mei 2017
  • Laatst online: 23:23
Martin wie? :P

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim"


  • azerty
  • Registratie: maart 2009
  • Laatst online: 16:46

azerty

McFly

Martijn Bloem, je kent hem toch wel zeker? :+

  • gekkie
  • Registratie: april 2000
  • Laatst online: 00:35

  • Koenvh
  • Registratie: december 2011
  • Laatst online: 22:28

Koenvh

Hier tekenen: ______

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 :+

Waarom vandaag doen wat je morgen ook kunt uitstellen?


  • gekkie
  • Registratie: april 2000
  • Laatst online: 00:35
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 :D.

  • wttj
  • Registratie: december 2012
  • Niet online
Ik denk dat ik de nieuwe manier heb gevonden om deze chat nieuw leven in te blazen :o Kan php wel helemaal bij het grof vuil :+

  • Kalentum
  • Registratie: juni 2004
  • Laatst online: 22:26
gekkie schreef op donderdag 3 september 2020 @ 18:18:
[...]

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

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?
wttj 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?

PVoutput


  • wttj
  • Registratie: december 2012
  • Niet online
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
  • Registratie: november 2009
  • Laatst online: 20:43
wttj 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.

  • wttj
  • Registratie: december 2012
  • Niet online
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:
1
$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
  • Registratie: juni 2004
  • Laatst online: 22:26
wttj 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!

PVoutput


  • gekkie
  • Registratie: april 2000
  • Laatst online: 00:35
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
  • Registratie: november 2009
  • Laatst online: 20:43
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.

  • wttj
  • Registratie: december 2012
  • Niet online
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' :o . Zeker als je nagaat hoe sterk php in een webserver zit verweven (mod_php anyone?).

  • Mugwump
  • Registratie: mei 2017
  • Laatst online: 23:23
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. :P

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim"

Pagina: 1 ... 73 74 75 Laatste


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True