Tweakers Dev Summit Update: stel jouw vraag aan Rasmus Lerdorf

We zijn hard bezig met de voorbereiding voor onze Tweakers Developers Summit, die op 16 februari in Utrecht zal plaatsvinden. In deze update praten we je bij over het programma en verzamelen we input voor een interview met onze spreker Rasmus Lerdorf.

Om te beginnen kunnen we melden dat alle early bird-kaarten zijn uitverkocht en enkel nog de reguliere tickets beschikbaar zijn. Dat betekent echter niet dat er geen goeie deal meer te scoren is, want de 3-voor-2-deal loopt nog even door; trommel wat collega's op en je geniet nog steeds voordeel. Overigens kunnen de tickets ook op factuur betaald worden, dus het kan geen kwaad je baas even lief aan te kijken. Met je ticket krijg je toegang tot een goed gevuld programma van 09.00 tot 22.00, een knallende social, de gehele dag door eten en drinken en een goed gevulde goodiebag. Check voor meer info de actiepagina.

Wat betreft het programma hebben we ook nieuws te melden. Zo zullen onze eigen developers Tim Cure en Jeroen Groeneweg een sessie verzorgen met de veelzeggende titel "18 years of Tweakers: Taming the legacy beast. How to refactor a legacy codebase to the current standards". Daarin gaan ze in op de uitdaging van omgaan met 18 jaar aan code en beschrijven ze de stappen die genomen zijn om een deel van de oude legacy-code weer up to date te krijgen.

Stel je vragen aan Rasmus Lerdorf

In aanloop naar de Summit willen we jullie alvast kennis laten maken met een aantal van de sprekers in de vorm van een interview. Daarvoor zijn we op zoek naar jullie input!

We beginnen met Rasmus Lerdorf, de oervader van PHP. Tijdens de Developer Summit zal hij het hebben over de technische staat waarin PHP anno 2017 verkeert en kijkt hij vooruit naar aankomende features in PHP 7.1. Heb je hier vragen over? Of wil je iets anders van hem weten over (de geschiedenis van) PHP, webdevelopment of zijn favoriete ijssmaak? Laat je vraag dan achter in een reactie en wij zullen ervoor zorgen dat het bij hem terechtkomt.

Wil je tussentijd met andere (potentiële) bezoekers over de Summit en development praten, of heb je nog suggesties die je aan ons door wilt geven? Zet het officiële Developer Summit-topic dan in je bookmarks.

Reacties (48)

[Barryke]

Questions for Rasmus Lerdorf

• What is your opinion on HipHop / HHVM, and have you used it yourself?
• What is your opinion on ES6 / Node.JS, and have you used it yourself?
• What is your opinion on the PHP community, compared to others?
• What is your opinion on the current state of PHP, compared to alternatives?

Ik ben er niet bij maar ik hoop hier wel een video of artikel te kunnen vinden.

[dakathefox]

Wat zijn eigenlijk jouw ervaringen met HHVM? Ik heb het namelijk altijd een draak gevonden en de komst van PHP 7 zorgde dat ik HHVM resoluut bij het grofvuil heb gezet.

[Barryke]

Geen; nog niet nodig gehad en gezien ik wel PHP7 gebruik zal dat niet nodig zijn begrijp ik.

[__Michiel__]

Wat ik me nu begin af te vragen is of de sprekers in het Engels een verhaal gaan houden? Die Engelse titel leidt me erg af...

[cracking cloud]

Rasmus Lerdorf zal misschien ook Deens kunnen, maar of je dat helemaal kunt volgen ...

[cracking cloud]

Jeg tåler intet Dansk

[veltnet]

Ik vraag me af wanneer er nu eens design specificaties en een ontwerp komen van PHP. Ik begrijp dat PHP in het verleden "organisch" gegroeid is, maar van een programmeertaal die al meer dan 16 jaar bestaat mag je verwachten dat dit op een gegeven moment professioneel wordt opgepakt.

[TimeVortex]

Daar wordt al hard aan gewerkt hoor.

[veltnet]

Wat ik daar zie is een beschrijving van wat er is, en geen ontwerp van wat er gaat komen.

Begrijp me niet verkeerd, ik gebruik zelf ook veel PHP voor werk dus ik probeer de taal niet te bashen maar ik kan me nog steeds verbazen over de manier waarop PHP wordt ontworpen in tegenstelling tot bijvoorbeeld Python, Java of andere talen. Dit zie je ook terug aan een aantal zaken in PHP, waaronder

-

• functie aliases - meerdere functies die een exacte of bijna exacte kloon zijn van elkaar en al meer dan 10 jaar in de taal zitten
• - Standaard iterators vs Standaard PHP library - SPL is meer geavanceerd maar wordt weinig gebruikt
• - en nog veel meer....

Hou zou mijns inziens niet verkeerd zijn om een PHP eindbaas te hebben die strenger is en meer keuzes durft te maken om dingen te schrappen of juist toe te voegen in plaats van alles wat het PHPdev team maakt op een grote hoop te gooien. Dit zou de taal ten goede komen.

PHP heeft een soort Guido van Rossum nodig, of Larry Wall, maar Rasmus Lerdorf is denk ik een beetje te lief om een benevolent dictator for life te zijn (wat hij dan ook niet is...maar wie is dan wel de eindbaas van PHP?).

[Reactie gewijzigd door veltnet op 24 juli 2024 01:12]

[totaalgeenhard]

How to set garbage collection PHP in general that overrules coded settings.

Op dit moment ben je overgeleverd aan interne processen, terwijl in bepaalde omgevingen (zoals shared hosting) je nadat een script is voltooid hij ook meteen zijn "rommel" gaat of laat opruimen.

Dit gebeurd dus meestal niet, waardoor lange tijd nadat bezoeker (en aanroeper van script) al weg is proces nog steeds geheugen inneemt.

Een proces killen, kan je doen als hij enige tijd idle is, maar is niet zo nette manier, wat je wilt is dat processen met een generieke serverbrede setting aangeroepen zal worden en daarbij alles wat inactief is uit geheugen zal gooien en daarbij in PHP gecode garbage of in losse PHP.INI staande settings zal overrulen.

[Reactie gewijzigd door totaalgeenhard op 24 juli 2024 01:12]

[DexterDee]

Voor langlopende scripts kun je gc_collect_cycles() op regelmatige basis gebruiken, deze doet een geforceerde flush. Ik gebruik het zelf met veel succes om langlopende scripts qua geheugengebruik binnen de perken te houden.

[jip_86]

Kan het kloppen dat het schema verdwenen is met het overzicht van alle sessies? Ik kan het niet meer vinden namelijk.

[iloste]

Dat klopt inderdaad. Hebben we voor nu vervangen door de sprekers visual. Zodra het volledige programma definitief is dan zetten we het schema weer terug met het overzicht van alle sessies

[chielsen]

PHP 7.1 is al stable en uit hoor :-)
Zo aankomend is het dus ook weer niet.

[totaalgeenhard]

is al stable en uit hoor

01 Dec 2016

Is net uit en nog niet geschikt voor productie.

Even nog een half jaartje aankijken voordat je in productie het gaat uitrollen.

[chielsen]

Er zijn al 6 release candidates geweest. Het feit dat deze build als stable wordt aangeduid betekent dat je hem in productie kan draaien.
Ik zou natuurlijk wel eerst testen of jouw codebase helemaal geschikt is, maar als je geïnteresseerd was in 7.1 dan had je dus al maanden kunnen testen (en meehelpen aan de ontwikkeling).

Je kan altijd wachten op de eerste minor om wellicht nog minder risico te nemen, maar ook bij een latere minor release heb je kans op bugs.

[afraca]

Ben wel benieuwd in wat z'n gedachten over de nieuwe 'JIT engine', die voor 8.0 gepland staat zijn. Als ik ik de RFC's van afgelopen tijd doorga, zie ik hem nooit meer echt als touwtrekker.

[justVR]

Goede line-up qua speakers! Misschien dat ik er bij ben. Prijzen (ook niet early bird) zijn zeer acceptabel.

[totaalgeenhard]

Waar zie je prijzen?

[jj71]

In het artikel staat:

Check voor meer info de actiepagina.

Kijk onderaan die pagina, daar zie je wat de tickets kosten.

[totaalgeenhard]

Thanks. Datum schikt me helaas niet.

[BikkelZ]

Er is maar één vraag die écht telt:

- Saus er op, of er naast?

Ik gebruik PHP vaak als ik een kleine API moet bouwen o.i.d. omdat het overal draait en niet te moeilijk doet maar ik ben altijd bang voor code die anderen geschreven hebben in PHP. Inclusief de grote en bekende frameworks, shops of CMS'en.

[thePiett]

Nou, want eigen code is altijd "beter" dan andermans code...

[BikkelZ]

Er is een duidelijk verschil in gemiddelde kwaliteit in code in frameworks en projecten die ik de afgelopen jaren overgenomen heb als ik verschillende programmeertalen en frameworks vergelijk. Er zijn mensen die super strakke PHP code schrijven natuurlijk maar ik neem liever bijvoorbeeld een Python project over dan een PHP project omdat de gemiddelde Python programmeur meer ervaren is dan de gemiddelde PHP'er en ook de taal iets minder snel slechte gewoontes uitlokt. Dus de kans dat het een project is wat makkelijk over te nemen is is dan gewoon groter.

Ben gewoon heel vaak rotzooi tegen gekomen, ook in bekende open source projecten.

[dnzm]

Andere talen hebben vaak net iets meer drempel - iedere hoster biedt PHP-ondersteuning, andere talen ligt toch nog wat lastiger - wat de grootste nubs een beetje weert, ja. Ik kan me goed voorstellen dat de gemiddelde Python-programmeur een betere programmeur is, simpelweg omdat er minder tussen zullen zitten die hun hele kennis aan w3schools te danken hebben... (Sprak hij als PHP-dev, dus het is absoluut niet als bash naar wie of wat dan ook bedoeld).

[Tarabass]

Ik heb geen vraag over de geschiedenis van PHP, maar juist over de toekomst.

Met de opkomst van JavaScript als een backend taal, denk aan NodeJs maar ook WordPress, wat is de toegevoegd waarde van PHP als programmeertaal nog en denk je dat (op korte termijn) iedereen zijn API's/applicaties in JavaScript zal schrijven? En zouden beginnende programmeurs, ik ga al 15 jaar mee, nog tijd moeten investeren in het eigen maken van de taal PHP?

[veltnet]

PHP is natuurlijk server side in tegenstelling tot JS en JS-achtige libs welke vooral client side werken. En inderdaad, waarom zou je PHP leren als er ook talen zijn als Python, Perl , Java, etc. Het heeft uiteindelijk toch met persoonlijke voorkeur en kennis te maken. Je gaat niet snel een applicatie maken in een programmeertaal waar je minder kennis van hebt. En als je een hamer hebt (PHP) dan ziet elk probleem er uit als een spijker.

[Reactie gewijzigd door veltnet op 24 juli 2024 01:12]

[Tarabass]

Ik weet niet onder welke steen je de laatste tijd geleefd hebt, maar zeggen dat PHP in tegenstelling tot JavaScript server side is geeft aan dat je de ontwikkelingen van de laatste jaren niet gevolgd hebt. Een voorbeeld is WordPress, die hun applicatie voor een groot gedeelte hebben herschreven in JavaScript, ten koste van PHP. Mijn vraag komt niet zomaar uit de lucht vallen. Zoals gezegd loop ik al een tijdje mee en heb veel PHP geschreven/gebruikt. Maar elke beginnend ontwikkelaar kan ik van harte aanbevelen zich te richten op JavaScript, omdat we in een tijd leven waarin je alles met JavaScript kan en relatief maar weinig met PHP. Maar dat advies is natuurlijk al jaren oud. Ik bouw mijn websites/connect met mijn databases/autoriseer mijn gebruikers/benader de file system/update mijn sockets/compile mijn sass/minify/uglify mijn js/run mijn unit en integration testen in ieder geval enkel in JavaScript.

Op dit moment worden desktop applicaties geschreven in JavaScript, mobile apps worden geschreven in JavaScript, de complete serverkant wordt geschreven in JavaScript.

En natuurlijk weet ik het antwoord al op mijn eigen vraag in mijn vorige post. Maar ik ben erg benieuwd naar een reactie van Rasmus Lerdorf. Ik hoop niet dat hij dezelfde oogkleppen opheeft als jij. En juist jouw post bevestigd dat je graag een hamer wilt waarmee je op elke spijker kan slaan. En dat kan met JavaScript, niet met PHP.

En welke persoonlijke voorkeur heeft een beginnend programmeur nou eigenlijk? En als je tegen die kiddies zou zeggen dat met één taal alles kan maken, zouden ze daar nee tegen zeggen? Mijn vraag ging dan ook over de toekomst, en niet over het verleden..

[veltnet]

Sorry hoor, ik probeer je niet aan te vallen, maar slechts te nuanceren. Ik begrijp daarom ook niet waarom je deze toon aanslaat.