Facebook geeft eigen op php gebaseerde programmeertaal vrij

Facebook heeft een programmeertaal vrijgegeven die zowel dynamische als statische typering ondersteunt. De taal, met de naam Hack, is grotendeels compatibel met php en maakt het mogelijk om statisch getypeerde code te draaien zonder dat die hoeft te worden gecompileerd.

De programmeertaal wordt al voor het overgrote deel van Facebook gebruikt, maar wordt nu pas aan de wereld getoond. De ontwikkelaars van de programmeertaal hebben hem vrijgegeven als opensource. Hack werkt in combinatie met HipHop, een combinatie van een just-in-time-compiler en een virtuele machine die eerder al door Facebook onder een opensource-licentie werd vrijgegeven.

Wat de programmeertaal bijzonder maakt, is dat hij zowel dynamische als statische typeringen ondersteunt. Talen met dynamische typeringen zoals php en Ruby maken het makkelijker om code te schrijven, terwijl talen met statische typeringen zoals Java stabielere, overzichtelijkere code opleveren. Hack ondersteunt beide naast elkaar, waardoor nieuwe features bijvoorbeeld eerst dynamisch kunnen worden gebouwd en later van statische typeringen kunnen worden voorzien.

Hack leunt voor een zeer groot deel op php: de meeste php-bestanden kunnen zelfs zonder wijzigingen als Hack-scripts worden gedraaid. Wel worden sommige uitgefaseerde php-functies niet ondersteund, evenals sommige functies die incompatibel met statische typeringen bleken. Bijzonder is dat Hack het mogelijk maakt om code met statische typeringen te draaien zonder dat het nodig is om de code te compilen.

Facebook heeft ook tools vrijgegeven om code met dynamische typeringen om te vormen naar statisch getypeerde code. Het sociale netwerk heeft die tools gebruikt om zijn code grotendeels naar Hack om te zetten. Facebook draaide sinds zijn oprichting op php.

<?hh
class MyClass {
  public function alpha(): int {
    return 1;
  }

  public function beta(): string {
    return 'hi test';
  }
}

function f(MyClass $my_inst): string {
  // Fix me!
  return $my_inst->alpha();
}

Voorbeeld van code in Facebook Hack

Reacties (106)

[Greybeard]

Ik heb hierover een maand geleden een zeer interessant artikel gelezen waar de vergelijking tussen PHP en HHVM & Hack gelegd wordt. Wel interessant voor de PHPer hier;). Link 2

[Reactie gewijzigd door Greybeard op 23 juli 2024 05:38]

[Gamemaniak]

Phalcon is met een soortgelijk iets bezig voor versie 2.0 met Zephir.

[Virtlink]

Ik heb al met Hack mogen werken, en ik vind het idee geweldig. Eindelijk static typing en generics in je PHP code, en daarnaast controleert of verbiedt de HipHop compiler nog allerlei dubieuze PHP Sadness-constructies. Dat voorkomt al heel veel bugs, en Hack zet de deur open naar verdere syntactische verbeteringen van PHP. Maar tegelijkertijd merk je toch aan allerlei kleinigheidjes (in de versie waar ik mee werkte) dat Hack nog een beetje moet groeien.

Zo is de static typing beperkt tot de HipHop compiler, die daarna de typing uit de source code stript om zo werkende legacy PHP code over te houden. Maar dit gaat soms wel eens mis. Ook supportte de HipHop compiler toen ik ermee werkte nog niet nieuwe PHP features zoals namespaces.

Tenslotte is de legacy PHP runtime natuurlijk nog niet geschikt voor static typing. Brede types als `mixed` of `array` kan je wel in Hack gebruiken, maar het is niet gemakkelijk gecombineerd met HipHop's static typing en generics. Daarom kan je per sourcecodebestand de strictheid van HipHop bepalen. Soms ontkom je er niet aan om HipHop te vragen losjes met je types om te gaan, en andere keren wil je zo strict mogelijk proberen zijn.

Ik verwacht dat Hack snel geadopteerd zal worden door de community, en dan is het een fijne schil over PHP heen, vergelijkbaar met Less en Sass voor Css, en Coffeescript voor JavaScript.

[Martinspire]

Wat voor mij altijd gestoord heeft aan PHP is dat er weinig consistentie in zit. De naamgeving van de diverse functies laat nogal te wensen over en ik vraag me af of dit met Hack beter geregeld is?

[sfranken]

Wat nu langzamerhand op aan het lossen is. Door de invoeren van de stdlib in PHP en het feit dat er steeds meer OOP word is de wirwar in naamgevingen aan het afnemen gelukkig.

[Virtlink]

Nee, Hack lost in principe die inconsistente naamgeving niet op. Maar om helemaal goed gebruik te kunnen maken van Hack moeten veel van de legacy PHP functies ge-Hack-ified worden: onderverdeeld in klassen en voorzien van statische types en generics. Facebook is zelf al begonnen een bibliotheek met zulke functies aan te leggen, en dat is natuurlijk de uitgelezen kans om de naamgeving wat logischer te krijgen.

[TrisBe]

Denk dat je op de verkeerde site zit. Menig tweaker hier vind dit soort dingen dus wel geweldig.
Tweaken kan ook wel worden gedefinieerd als: "Met truckjes en weetjes het maximale resultaat eruit halen".

Dus het is altijd interessant nieuwe technieken te leren, vooral bijvoorbeeld deze Hack welke bij grotere projecten mij juist een stuk overzichtelijkere en leesbare code kan opleveren.

Als u dus een programmeur (in spé?) bent. Zal u zichzelf toch moeten aanleren dit soort meningen niet te delen over de werkvloer. Want menig collega zal dit dus wel interessant vinden en stellen niet erg op prijs als u ze een epic fail noemt.

Overigens als u van plan bent de kinderachtige hashtag gebruik op tweakers te introduceren. Snap dan wel dat een hashtag geen spatie mag bevatten. Dus u meneer/jongen bent een #epicfail.

[Verwijderd]

Tevens heb je vaak mensen die nieuwe zaken in programmer land verafschuwen.. heb ik net een taal geleerd moet ik weer iets anders leren.

Als je niet van continu leren houdt, ga dan niet programmeren.
Zoals mensen die al 10 jaar PHP programmeren... en dan alles op alles zetten om te zweren dat PHP HET is. Terwijl misschien andere zaken ook in de toekomst zeer relevant kunnen worden waardoor PHP misschien wel verdwijnt.

Maar dat willen ze niet, want iets nieuws leren... ho maar.

[Cybergamer]

Nou, ik denk dat het wel mee valt. Meeste programmeurs die zichzelf een beetje serieus nemen kunnen meerdere talen proggen.

Zelfs als dat niet het geval is dan is de drempel om een nieuwe taal te leren vrij laag, want de basiskennis is er al. OK, het is ff lastig in het begin, maar naarmate je langer bezig bent met een nieuwe taal stelt het eigenlijk niets voor.

[Mr.Monk]

Zonder die mensen die van techniek houden kon jij niet lekker op internet rondneuzen.. en zat je nog lekker in een command prompt te tikken.. De epic fail is u ben ik bang!

[g4wx3]

En een command prompt, of zal ik zeggen Terminal is minderwaardig?

Ik vind dat het jammer dat de console niet meer is geintegreerd in de gui

[computerjunky]

Ik vind dit meer php met plugins dan een nieuwe programmeertaal.
Als er zoveel PHP gebruikt word is het gewoon php met plugins wat mij betreft.

[RobertMe]

PHP is een combinatie van een taal en een framework. Zoals je C# als taal hebt en .NET als framework. In dit geval mag je, denk ik, gewoon spreken van een nieuwe taal, die heel erg sterk op PHP lijkt, gebouwd op het framework van PHP. De standaard library die je hebt is nog hetzelfde als in PHP, alleen de syntax om je code te schrijven is nu Hack, in plaats van PHP. Hetzelfde dus als dat je .NET code kunt schrijven in C#, VB.NET of F#. Of aan de Java kant AFAIK, de JVM waartegen je kunt programmeren in zowel Java of Scale.

In dit geval van HipHop zal dat ook wel zo zijn. Zowel PHP als Hack zullen naar eenzelfde soort intermediate language compileren. Wat dus waarschijnlijk loosely en dynamically typed is en alle (mis)features van PHP (als taal) heeft. Beide worden daarna dus door dezelfde interpreter/VM uitgevoerd en maken gebruikt van hetzelfde framework/standaard library. Deze extra (stricte) features van Hack zullen dus alleen door de compiler, die naar het intermediate language toegaat, worden afgedwongen. Op het moment dat de code vervolgens daadwerkelijk door de interpreter/VM wordt uitgevoerd heeft deze dus ook helemaal geen weet meer van of het PHP of Hack is, en zal daar dus ook niet stricter kunnen zijn dan PHP is.

[Verwijderd]

is wel zo logisch, anders moet je browser er ook maar mee overweg kunnen. Lijkt me voor een bedrijf als Facebook wel een belangrijk punt

[RobertMe]

PHP (en Hack, en ASP.NET en Python en Java (Spring), en ...) en de browser staan los van elkaar. PHP output iets (meestal in de vorm van tekst), en wat daar voor de rest mee gebeurd maakt niet uit. Dat die tekst vervolgens ook nog eens HTML is in 90% van de gevallen en die naar een browser wordt gestuurd maakt totaal niet uit. Een browser interpreteert, HTML, JavaScript, CSS etc, wat allemaal een vorm van tekst is, en PHP kan tekst outputen. Simpel gezegd is dat de enige relatie tussen PHP en de browser.

En als jij een andere (server side) programmeertaal voor het web wil maken (of gebruiken) is het enige wat die taal hoeft te kunnen het kunnen genereren (en versturen) van tekst, heel erg simpel gezegd.

[Verwijderd]

Ik dacht dat PHP juist op de achtergrond draaide (server side), en dat je met HTML en CSS de style/tekst van je pagina bewerkt.

[DLGandalf]

Je hebt het juist, maar @RobertMe ook, hij zegt dan ook nergens dat php op de client draait.

[Davio]

Ja, je kan met server-side talen van alles maken waar je browser al dan niet mee overweg kan. Als jouw browser een HTTP GET/POST naar een PHP-pagina stuurt, krijgt hij een HTTP Response terug met een bepaalde mimetype.

Deze mimetype kan html zijn, maar heel eenvoudig ook xml, json, of een plaatje als een gif, jpeg of png. En als je het nog meer fancy maakt ook een pdf bijvoorbeeld.

Het is aan jouw browser en de daarvoor beschibare plugins of hij wel of niet met deze mimetypes overweg kan en als dat niet zo is, dan zal het bestand meestal gedownload worden in plaats van dat het in je browser wordt geopend.

Hack mag dan wel gebouwd zijn op het framework van PHP; als ik het artikel goed begrijp, heeft het gewoon zijn eigen (JIT)-compiler en is het dus eigenlijk zijn eigen taal en framework.

[Douweegbertje]

Ja, behalve dat het totaal iets anders is. Alleen al het verschil hoe het draait maakt het al geen PHP meer. Dat het toevallig overweg kan en de basis heeft van PHP maakt het nog geen één of andere plugin. Je zou het misschien beter als PHP 8.0 kunnen zien, aangezien PHP zelf nogal slacked qua verbeteringen. Al met al moet je niet appels met peren vergelijken, daarvoor zou ik als ik jou was iets meer inlezen over wat het nu precies is.

[Verwijderd]

Het kan aan mij liggen, maar in de programmeer wereld kom ik zelden de sterm "statically typed" tegen, maar wel "strongly typed". Beiden betekenen hetzelfde overigens.

[MadEgg]

Dit betekent niét hetzelfde.

Je hebt statically vs dynamically typed. Dit heeft betrekking op of argumenten en variabelen een vast type inhoud hebben of dat de inhoud kan variëren al naar gelang de omstandigheden. Python, bijvoorbeeld, is redelijk strongly typed, maar ook dynamically typed. Dit is valide Python:

a = 3 * 5
a = "Teststring"

Dan heb je weakly vs strongly typed. Dit gaat erom of een type flink bepaald wat je ermee kunt doen. PHP is weakly typed, waardoor je dingen als dit kunt doen:

$a = "3"
$b = 5
$c = $a + $b

In dit geval komt daar ook nog het juiste antwoord uit, maar daar heb je geen garanties voor omdat je $a een string is en je dus niet weet of de conversie goed gaat.

Python is een stuk strenger getypeerd, waardoor dit niet zou kunnen:

a = "3"
b = 5
c = a + b

Dit zal een TypeError exception gooien.

Dat Python dynamically typed is geeft je wel mogelijkheid tot duck-typing (if it act likes a duck...), waardoor de strengheid wat types betreft er niet altijd even hard uitkomt, maar je kunt geen operaties uitvoeren op incompatibele types, terwijl dat in PHP wel gewoon kan.

[GigaPixels]

Hack leunt voor een zeer groot deel op php: de meeste php-bestanden kunnen zelfs zonder wijzigingen als Hack-scripts worden gedraaid

Dan moeten we dat maar eens meteen gaan proberen.

Facebook draaide sinds zijn oprichting op php.

En wanneer schakelde het over op Hack?

[m8ZBm1Si]

We have deployed Hack at Facebook and it has been a great success. Over the last year, we have migrated nearly our entire PHP codebase to Hack, thanks to both organic adoption and a number of homegrown refactoring tools.

Bron

[Reactie gewijzigd door m8ZBm1Si op 23 juli 2024 05:38]

[Joop Visstick]

De vraag van GigaPixels was SINDS WANNEER niet OF ze het gebruiken.

Ik wil eigenlijk ook wel weten HOE LANG Facebook al Hack gebruikt.

[Gomez12]

Dat valt waarschijnlijk niet te zeggen.

1 : Je schrijft een stukje als uitbreiding voor hiphop en gooit dit in productie
2 : Je krijgt feedback vanuit de praktijk en breidt het stukje uit en gooit dit in productie
3 : Je krijgt feedback vanuit de praktijk en breidt het stukje uit en gooit dit in productie
4 : Je krijgt feedback vanuit de praktijk en breidt het stukje uit en gooit dit in productie
5 : Je krijgt feedback vanuit de praktijk en breidt het stukje uit en gooit dit in productie
...
100 : Iemand vindt het mooi genoeg en geeft er een interne-naam aan zodat er een team aan kan werken
101 : Je krijgt feedback vanuit de praktijk en breidt het stukje uit en gooit dit in productie
102 : Je krijgt feedback vanuit de praktijk en breidt het stukje uit en gooit dit in productie
....
200 : Iemand besluit dat het groot genoeg is om te open sourcen en er een losse naam aan te geven

In welke stap ben je nu begonnen met Hack te gebruiken?

[To_Tall]

Stap 1 als interne naam ik zou niet wachten op stap 100

Je begint een project dat project geef je een naam. Pas als het project dusdanig vorm heeft aangenomen kan je een naam aan je project meegeven dat publiekelijk bekend zal worden.

Hack zal waarschijnlijk staan voor het omcatten van PHP naar deze nieuwe taal. Hack PHP

[SWINX]

Dus nu weten we sinds wanneer?

[sw3at]

Niet precies, maar doelt wel op het feit dat het niet compleet omgeschakeld is. "Overgrote deel" lees ik als "de rest volgt nog".

[thegve]

Ik lees het als "delen van de back-end zijn in c / java / andere taal die beter is voor back-end danwel middleware dingen geschreven".

[markg85]

vind overigens wel dat PHP inmiddels langzaam mag stoppen met bestaan. De taal begint syntactisch steeds meer een zooitje te worden. Neem bijvoorbeeld dit:

function a($iets, ...$strings)

Ja... "variadic arguments" op een wel HEEL lelijke manier.
Heb je nog die oer lelijke namespaces die niet eens echt namespaces zijn. Meer veredelde includes. Veel taal inconsistenties, en ga zo nog maar even door.

Ik weet niet of er een taal is die PHP verslaat wat betreft het gemak van web development. Mogelijk is Node.js (ja, kan je ook hele sites in maken) de opvolgen. Mogelijk dit "Hack" of misschien iets anders wat nog gemaakt moet worden.

Maar PHP heeft wat mij betreft zijn langste tijd wel gehad.

[MadEgg]

Ik weet niet wat jij bedoeld, maar voor variabel aantal argumenten heb je func_num_args() en func_get_args(). Werkt prima.

Namespaces werken ook precies zoals ze moeten werken.

Ja, PHP heeft zijn tekortkomingen maar in de dingen die jij aandraagt herken ik mij absoluut niet. Inconsistenties van naamgeving van functies en volgorde van argumenten zijn wat mij betreft het grootste argument tegen PHP, maar het is nog steeds een van mijn favoriete talen. De rest maakt een hoop goed, wat mij betreft.

[RobertMe]

func_get_args() is een hack om variadic arguments te hebben. Op het moment dat je een functie hebt met puur een variabel argumenten kan het nog enigszins. Op het moment dat je een functie hebt met een aantal vaste argumenten, en dan nog een rits variabele argumenten, wordt het al snel een zooitje. Omdat je dan alweer met een combinatie van array_slice en func_get_args moet gaan werken. Echte ondersteuning van variadic arguments is, in die gevallen waar het nodig is, toch echt wel een goede uitbreiding.

[MadEgg]

Tja, ik heb het nergens nodig gehad. Zie ook mijn reply hieronder. Ik gebruik ofwel een vaste lijst met argumenten, eventueel met defaults, ofwel géén argumenten en dan dus func_get_args. Mixen maakt het nodeloos complex.

[markg85]

Je snapt niet wat ik bedoel.. Voor je favoriete taal ben je dan niet bepaald op de hoogte van nieuwe features voor PHP 5.6. Deze feature heeft het dus gehaald en komt in 5.6. De RFC kan je hier vinden: https://wiki.php.net/rfc/variadics

[MadEgg]

Klopt, features in toekomstige versies hou ik me niet mee bezig aangezien ik daar nu toch nog niets aan heb. Ik schrijf code die op versies van PHP moet schrijven die je veel "in het wild" tegenkomt, dus kan ik geen features gebruiken die een nieuwere PHP dan versie 5.3 nodig hebben.

Ik zie het probleem ook niet. Ik gebruik ófwel een vast aantal argumenten (eventueel met een aantal met defaults), ófwel func_get_args en consorten. In het laatste geval kun je de verplichte argumenten evengoed opleggen door gewoon de gegeven argumenten bij langs te gaan en een exception gooien als het niet in de haak is. Die twee mixen wordt inderdaad een beetje chaotisch.

De gegeven oplossing voor PHP 5.6 zie ik dan ook niet een grote verbetering in. Dit is sowieso een constructie die al lang mogelijk was: gewoon een associative array als argument meegeven. Dit heb ik dan ook wel veel gedaan en is binnen het Zend Framework ook gebruikelijk. Deze oplossing komt het meest overeen met Keyword Arguments zoals ik ze zo waardeer in Python. Wat mij betreft hadden ze bij PHP dus beter ondersteuning voor keyword arguments kunnen toevoegen, eventueel in combinatie met deze variadic arguments (de **kw_args in Python dus).

[.oisyn]

Ja... "variadic arguments" op een wel HEEL lelijke manier.

Wat is er precies lelijk aan? Je stelt alleen dat het zo is zonder enige argumentatie. Behoorlijk subjectief als je het mij vraagt. De notatiewijze is bovendien vrij standaard in C-achtige talen waar PHP behoorlijk wat syntax van geleend heeft.

Ben het overigens wel redelijk met je overige punten eens hoor. Wat PHP nodig heeft is een radicale aanpassing die compleet niet backwards compatible is. Maar dat betekent tevens dat de acceptatie ervan zeer stroef zal verlopen, want er zijn inmiddels toch hele grote lappen code in geschreven.

[markg85]

Zoals ze het nu hebben gedaan staat gewoon lelijk. Gewoon 3 puntjes foor een variabele naam zetten en dat als veradic arguments afhandelen is wat mij betreft gewoon lelijk smerig.

Wat ze wat mij betreft hadden moeten doen is in de syntax van PHP blijven en een standaard variabele naam binnen een functie moeten toewijzen als variabele waar alle veradic arguments in komen. Bijvoorbeeld iets als dit:

function a($iets, ...)
{
$_FUNC_VERADIC_ARGUMENTS;
}

_FUNC_VERADIC_ARGUMENTS zou dan alle veradic argumenten hebben. Dit is meer in lijn met de syntax die ze nu toch al overal hebben met $_SERVER, $_GET, etc...

Wat ook kan is dat ze een nieuwe functie hadden geïntroduceerd zoals func_get_args alleen dan specifiek voor veradic argumenten.

Met beide alternatieven was het syntactisch heel wat mooier geweest en ook nog eens meer in lijn met C en C++

[sfranken]

Je bedoelt func_get_args() dus?

[markg85]

Nee, dat bedoel ik niet.
Ik bedoel precies wat ik zeg: "zoals func_get_args alleen dan specifiek voor variadic argumenten"

func_get_args geeft alle argumenten terug. Ook niet variadic.

[.oisyn]

En dat vindt je dan mooi? Een global identifier of keyword introduceren terwijl het vele malen handiger is om dat ding gewoon een lokale naam te geven, zoals elke andere parameter?

Met beide alternatieven was het syntactisch heel wat mooier geweest en ook nog eens meer in lijn met C en C++

Wat onzin is. De enige reden waarom de traditionele variadic argument uit C geen naam heeft is omdat je er verder toch niets mee kan, je kan er immers geen dynamic typed array van maken oid. In C++ heb je echter variadic templates, waarin variadic parameters weldegelijk een naam hebben en precies de syntax hanteert die Hack ook gebruikt

En het is trouwens variadic, niet veradic.

[markg85]

En het is trouwens variadic, niet veradic.

gelukkig schreef ik m consequent fout
Thanx!

[BuzzeW]

Als ik PHP naast Node leg dan verkies ik toch nog steeds heel erg sterk PHP t.o.v. Node hoor. Niet dat PHP nu dé taal is, maar om OOP te gaan werken in Node, dus in een taal die daar feitelijk niet voor geschikt is, not that easy.

[Gomez12]

OOP is dan ook niet the right tool for everything.

[mxcreep]

Inderdaad, dat wordt tegenwoordig nogal eens vergeten geloof ik. Procedureel wordt als vies beschouwd en toch zijn er nog hele knappe stukken software op die manier geschreven.

[BuzzeW]

In een taal als Node niet OOP gaan werken, dan ben je aan het knoeien. Dat OOP niet nodig is voor alles ben ik zeker akkoord, maar als je wil websites gaan programmeren (en dan hebben we het niet over een statische one-pager) dan werk je OOP.

[Gomez12]

Even 2 quotes onder elkaar dan :

maar om OOP te gaan werken in Node, dus in een taal die daar feitelijk niet voor geschikt is, not that easy.

In een taal als Node niet OOP gaan werken, dan ben je aan het knoeien.

Dus in wezen zeg je dat je in een taal als Node die feitelijk niet geschikt is voor OOP dat je toch OOP moet gaan doen anders ben je aan het knoeien?

In feitelijk niet geschikte talen iets gaan afdwingen vind ik eerder knoeien maar dat zal wel aan mij liggen

[BuzzeW]

Comments gaan vergelijken om dan een statement te maken, wauw.

Wat ik dus zei:
1. Ik prefereer PHP boven Node, aangezien PHP functioneert in een OOP omgeving, en Javascript geen taal is die gemaakt was om OOP te gaan programmeren.

2. Wanneer je toch voor bepaalde redenen voor Node kiest/moet kiezen dan kan je niet anders dan OOP gaan werken, anders wordt je code één groot zooitje. Zelfde als je alle functionaliteit van een website in de index.php zou duwen. Werkt niet.

[Verwijderd]

Hack werkt op de toevoegingen na percies hetzelfde als PHP dus de oplossingen van je problemen ga hier niet vinden. Ik denk dat dat ook niet de bedoeling van Hack is, ze zullen de syntactis gewoon hetzelfde laten

[markg85]

Ze kunnen natuurlijk een andere weg in slaan en op syntactisch gebied wat afwijken van PHP. Maarja, dat hadden ze dan _voor_ de bekendmaking moeten doen. Nu zitten ze eraan vast.

Denk ook niet dat een taal als PHP de toekomst is van web development. Denk eerder dat javascript of een afgeleide daarvan de toekomst is omdat je dat met html5 toch al veel nodig heb (canvas, webgl, dynamische formulieren, etc...)

[Foxl]

Denk ook niet dat een taal als PHP de toekomst is van web development. Denk eerder dat javascript of een afgeleide daarvan de toekomst is omdat je dat met html5 toch al veel nodig heb (canvas, webgl, dynamische formulieren, etc...)

Je weet het verschil tussen backend en frontend? Javascript kan natuurlijk nooit PHP vervangen. Los daarvan zit je dan met precies dezelfde problemen.

[mxcreep]

Je hebt gelijk en toch ook weer niet, Javascript op zich is namelijk al vaker ingezet als een serverside taal, o.a. in de Broadvision applicatie server, uiteraard heb je dan ipv DOM gerelateerde objecten weer allerlei server objecten ter beschikking om te gebruiken.

[Reactie gewijzigd door mxcreep op 23 juli 2024 05:38]

[Foxl]

Daar zit wat in, al noemt @HenkPJ html5, canvas, webgl, dynamische formulieren etc. waardoor ik er vanuit ging dat hij de clientside variant bedoelde.

[markg85]

Ja, dat verschil kern ik.

Tegenwoordig is het mogelijk om een website - ook fancy met database erbij en noten maar op - in JavaScript te maken met bijvoorbeeld node.js. dat draait dan dus op een server zoals je nu al de LAMP stack kent.

Zie er op zich wel voordelen in omdat men nu CLIENTSIDE toch al veel dingen in JavaScript doet (zoals canvas, webgl, jquery, etc...)

Dus als dezelfde taal voor zowel de frontend en backend gebruikt kan worden (wat het nu kan) dan lijkt mee dat zeker een interessant voordeel.

Of JavaScript en node.js nu de toekomst worden weet ik niet.

[markg85]

zonder "Hack" documentatie te hebben gelezen.. Had de type definitie niet netjes foor de functie definitie kunnen staan zoals in C++, C, Java en nog een berg andere talen doen?

Er zal vast een technische reden zijn om het erachter te zetten, maar nu lijkt het juist weer op het initialiseren van class members a.d.h.v. constructor arguments:

C++
class A {
A(int i) : b(i)
{}
private:
int b
};

Even als snel voorbeeld uiteraard.

[Reactie gewijzigd door markg85 op 23 juli 2024 05:38]

[Douweegbertje]

Het is meer zo;

function blaat(int $x): int {

Dus je eist int als input, en je geeft int als return. Wat er achter staat is dus wat je returned.


En verder qua init

class Point {

public function __construct(
private float $x,
private float $y
) {}
}

Dus op zich helemaal niet zo gek.

[Reactie gewijzigd door Douweegbertje op 23 juli 2024 05:38]

[markg85]

ja, ik begrijp de werking, maar vindt de volgorde verwarrend.
Als ze nou in PHP gewoon de naam "function" vervangen voor het return type ziet het er al gelijk een stuk beter uit. En dan misschien het type "mixed" als als type voor alles ofzo. De PHP documentatie heeft het tenslotte ook vaak over het type mixed als input argument (iets waar het een string, in, array, whatever kan zijn).

[Stackprotector]

Het lijkt mij dat deze oplossing meer fall-back support geeft. Het geeft plaats om in huidige php code static types toe te voegen in plaats van alles te gaan hernoemen en zo heel andere code te krijgen.

[McVirusS]

Je hebt zeker een Java achtergrond?

[markg85]

Nee, c++.
Ik moet niets van Java hebben.

[bbr]

Net als delphi dus.

function FGeefInteger(input: Integer): Integer;
begin
//hoi
Result := 0;
end;

En als je geen resultaat verwacht maak je het een procedure (soort van de void in C)

[Reactie gewijzigd door bbr op 23 juli 2024 05:38]

[simplicidad]

Er zal vast een technische reden zijn om het erachter te zetten, maar nu lijkt het juist weer op het initialiseren van calss members a.d.h.v. constructor arguments

Ik weet niet of het er iets mee te maken heeft, maar het deed mij direct denken aan hoe je in UML uw class methodes en hun return type definieert.

http://www.cs.bsu.edu/homepages/pvg/misc/uml/

[Stackprotector]

Dit heeft ook een soortgelijke vorm in c++

class Something
{
private:
int m_nValue;
double m_dValue;
int *m_pnValue;

public:
Something() : m_nValue(0), m_dValue(0.0), m_pnValue(0)
{
}
};

[Verwijderd]

Zeer zeker niet. Je geeft een voorbeeld van een initialization list. Dat is op geen manier te vergelijken met een return type van een functie of, in jouw geval, een methode ofwel member function.

[markg85]

Dat klinkt eigenlijk wel heel logisch. Zou me niets verbazen als het daarvan is.

[.oisyn]

Had de type definitie niet netjes foor de functie definitie kunnen staan zoals in C++, C, Java en nog een berg andere talen doen?

Grappig dat je C++ noemt, die juist een beweging ziet naar returntype áchter de parameters. Dat heeft verschillende redenen: parseproblemen met lambda's en automatic return type deduction aan de hand van de parameters. Dat laatste is in PHP natuurlijk niet echt van toepassing maar dat eerste is wel waarom veel C-achtige talen er juist voor kiezen om de returntype achter de functie te zetten. Het parsen van C en zeker C++ is uitermate complex en vereist dat de parser over type informatie beschikt, iets wat je juist niet wilt in een dynamische taal zoals PHP of Actionscript (om maar een voorbeeld te noemen van een andere taal waarin return types na de parameterlijst komen).

Als je in C een pointer naar een array van 10 ints wilt returnen uit een functie moet je 'm als volgt definieren:

int (*MijnFunctie(int parameter))[10] { /* ... */ }

Wordt er niet echt leesbaarder op, en dus werk je daar meestal omheen met een typedef. In C++11 kun je dit doen:

auto MijnFunctie(int parameter) -> int(*)[10] { /* ... */ }

Da's toch een stuk leesbaarder.

[Reactie gewijzigd door .oisyn op 23 juli 2024 05:38]

[DLGandalf]

Ik denk zomaar dat dit te maken heeft met de chaotische parsers die nodig zijn voor PHP als taal. Door de PHP ontwikkelaars is al menig maal verteld dat het heel moeilijk is om de taal uit te breiden.

Ik heb op de TU Delft met een vak mogen werken aan de HHVM en Hack, en als ik me goed herinner worden de originele parser tables gebruikt met addities. De keuze voor de type definitie voor of achter de de functie te plaatsen kan heel erg bepalend zijn of je parser nog wel werkt of niet.

zoals makkelijk te zien op github, is de syntax grammar vrij groot
https://github.com/facebo...aster/hphp/parser/hphp.ll

[Reactie gewijzigd door DLGandalf op 23 juli 2024 05:38]

[remystr]

Geen goede naam, als je het wil googlen kom je niet bij de juiste pagina's

[MacWolf]

Mja, Google Go was ook niet een erg handige naam, maar als je tegenwoordig naar code in Go zoekt, gebruik je gewoon golang als zoek parameter. Kan me voorstellen dat je in de toekomst met hacklang wel goede resultaten zal vinden.

[Fiber]

Nu al op twee: https://www.google.nl/#q=hacklang

Alleen er schijnt al een programmeertaal met de naam Hacklang te bestaan...

[Verwijderd]

Hacklang is van Facebook

[MetalfanBlackness]

Ik denk dat @Fiber bijvoorbeeld doelt op https://github.com/endeav0r/hacklang

[Verwijderd]

Duidelijk die zag ik niet voorbij komen na mijn zoektoch in Google. Maybe andere resultaten.

[bbr]

Inderdaad, slechte naam. Geen doekjes om te winden.
Als je iets wil zoeken vind je allerlij verkeerde paginas.

[Mic2000]

Ja of juist wel, lekker verwarrend voor big brother wie nou echt aan het hacken is

[Reactie gewijzigd door Mic2000 op 23 juli 2024 05:38]

[Genetai]

Wat dacht je van al die hackers die Facebook willen naaien. Straks staat Facebook Hack wel bovenaan op Google en dergelijke. Al het black hat hack spul komt dan weer een paginaatje verder weg, scheel vast weer wat luie hackers, Facebook blij

[bbob]

nu maar hopen dat hack niet gehacked wordt.

[addictive]

Zoeken op "facebook hack" voelt inderdaad een beetje gek.

[KrKr]

Aaaaaand you're on a list... :-)

[ro8in]

Kan iemand mij misschien simpel uitleggen wat het voordeel hier van is? Ik zie in het voorbeeld enkel bij de functie gedefinieerd staan wat hij terug gaat geven, maar kan me niet echt inbeelden wat ik er mee moet. Ik ben dan ook niet echt thuis in java wellicht dat ik daardoor iets mis...

[Reactie gewijzigd door ro8in op 23 juli 2024 05:38]

[sfranken]

Dit heeft 0,0 met Java te maken. Dit is een superset op PHP (zoals C++ een superset van C is).

[seba]

Het voordeel is dat veel fouten er in design-time (door hulp van de IDE) of compile-time al kunnen worden uitgehaald en dat de compiler of interpreter over meer info beschikt om zo efficienter te werken.

[Reactie gewijzigd door seba op 23 juli 2024 05:38]