Le réseau social a présenté Hack, un langage de programmation qui combine PHP avec des éléments de contrôle d'anciens langages comme le C++.

Facebook a publié son langage de programmation Open Source Hack. Ce dernier reprend « un grand nombre de fonctions et de caractéristiques de PHP en ajoutant des éléments en propre pour gagner en productivité », souligne Bryan O'Sullivan, ingénieur en charge du projet chez Facebook. En 2013, le réseau social a modifié sa base de code PHP pour la migrer sur Hack.
[Lire la suite de l'article en français sur Le Monde Informatique]

Site officiel : http://hacklang.org
Article sur le blog de Facebook qui présente Hack : https://code.facebook.com/posts/2645448 ... -for-hhvm/

ça s'appelle un fork en fait, c'est juste php sous un nouveau nom avec quelques trucs en plus, j'ai pas trouvé sur la doc l'interêt d'utiliser hack plutôt que php, quelqu'un a une idée?

Pareil j'avais commencé à regarder et puis j'ai pas trouvé l'intérêt qui me pousse à lire plus...

En gros ils ajoute le typage "fort" et du coup le générique (java style) vu que le type rend impossible ce que l'on pouvais faire avant (utilisation de string comme int etc).
Introduction de fonction anonyme "les lambdas" mais cela existe déjà.

Bref une sorte de mélange de php et java en gardant le côté script de la chose.
Il existe déjà groovy dans le genre ("dégradation" de java en script).

Si c'est adapté a leur usage pourquoi pas, perso le typage me manque un peu en php mais cela permet aussi pas mal de chose sans se prendre la tête (pas de cast des éléments de formulaire ou des retours de requête sql etc).

@+

L'idée n'est pas mauvaise en soit pour le typage, même si le plus gros du travail à faire pour PHP n'est pas de ce coté la je pense, mais plutôt d'harmoniser les noms de fonctions, car c'est un peu le foutoire pour ça.

L'idée n'est pas mauvaise en soit pour le typage, même si le plus gros du travail à faire pour PHP n'est pas de ce coté la je pense, mais plutôt d'harmoniser les noms de fonctions, car c'est un peu le foutoire pour ça.

Même sis je suis d'accord avec l'idée, considère que changer les noms des fonctions ou leur prototype, signifie casser instantanément tout code construit sur ces fonctions, la compatibilité ascendante pour un langage comme php est un must, on en est encore à faire la chasse aux directives de configuration de php 3... c'est pour dire que c'est pas demain la veille...

L'idée n'est pas mauvaise en soit pour le typage, même si le plus gros du travail à faire pour PHP n'est pas de ce coté la je pense, mais plutôt d'harmoniser les noms de fonctions, car c'est un peu le foutoire pour ça.

Même sis je suis d'accord avec l'idée, considère que changer les noms des fonctions ou leur prototype, signifie casser instantanément tout code construit sur ces fonctions, la compatibilité ascendante pour un langage comme php est un must, on en est encore à faire la chasse aux directives de configuration de php 3... c'est pour dire que c'est pas demain la veille...

Pas demain la veille, d'accord, mais il faudrait déjà commencer.

Et la solution ne me parait pas si compliquée que ça. Exemple, on a d'une part printf et print_r : si on uniformise en utilisant le « _ » partout, il suffirait de créer une nouvelle fonction print_f qui fasses strictement la même chose que printf sans supprimer celle-ci : à la version majeure suivante de PHP, on déclare printf obsolète, ce qui affichera des alertes si on travaille en mode strict, et encore une version majeure plus tard, on peut supprimer la vieille version... ou pas.
La durée de l'opération s'étalera sur plusieurs années et laissera largement le temps de mettre à jour les applications existantes.

Pour ma part, je dirai que le typage fort est un gros avantage pour bâtir des applications plus "rigides". Cela entraine des avantages ( pas d'erreurs hasardeuse car un développeur à passer un entier au lieu d'un string ), et des inconvénient : l'avantage de PHP c'est qu'il est facile d'accès, HACK est un peu moins accessible aux amateurs.

Ensuite, les Vector c'est pas spécialement ce que j'aime, cependant les génériques j'adore Pouvoir préciser qu'on a une collection d'un type d'objet précis, et pas un tableau fourre tout ^^

Pour moi c'est avant tout un language qui professionnalise un peu le développement PHP, on verra à l'usage

Pour moi c'est avant tout un language qui professionnalise un peu le développement PHP

Ce qui revient à dire que le PHP tout court n'est pas un langage de professionnels ? C'est plutôt arrogant comme attitude !

Que ce langage soit suffisamment ouvert pour permettre à des profanes de s'y initier en autodidactes est à mon sens une qualité. Ça ne retire pourtant rien au fait qu'il soit tout aussi utilisable par les professionnels les plus pointus. Si de prétendus professionnels font de la daube avec, personne ne pourra l'empêcher et ce n'est pas en rigidifiant le langage qu'on fera mieux. Je suis intimement persuadé qu'avec n'importe quel langage quel qu'il soit et un minimum de bonne volonté, on peut faire la pire des daubes imaginable.

Ce qui rendra les applications construites fiables et efficaces, ce n'est pas un langage, c'est la discipline et le sérieux des développeurs qui l'utilisent.

Pour moi c'est avant tout un language qui professionnalise un peu le développement PHP

Ce qui revient à dire que le PHP tout court n'est pas un langage de professionnels ? C'est plutôt arrogant comme attitude !

Réponse courte : J'ai dit que la professionnalise le développement, pas que PHP n'était pas un langage pro. Autrement dit, ça force les développeur à être plus exigeants.

Réponse longue :

Je suis moi même autodidacte et je me suis initié au développement grace à PHP. Je ne vais donc pas dénigré ce qui m'a tout de suite séduit par rapport au C ou au Java etc. Pas besoin de déclarer ses variables pour les utiliser, aucun contrôle fort automatique sur le typage etc...

Mais maintenant que le PHP n'est pas que ma passion mais aussi ce qui me permet de me nourrir et de payer mes factures, mon niveau d'exigence personnel sur mes développements n'est plus le même. Aujourd'hui déjà, je typehint tout ce que je peux et si je pouvais le faire pour des int, des floats et des strings je le ferai volontiers ( d'ailleurs, il y a une extension qui le permet mais qui n'est pas conseillée pour l'utilisation en production ).

On peut faire sans typehint ? Oui clairement, mais quand on a un moyen de rendre son application plus robuste, je ne vois pas pourquoi s'en priver.

On peut tout autant faire des conneries avec Hack qu'avec PHP, et faire des applications pro avec PHP qu'avec Hack. Mon avis est simplement qu'avec Hack, on passe à un niveau d'exigence supérieur nativement, ce qui entraine un développement plus pro.

Le point fort de Hack, c'est l'inverse de ce qui m'a fait aimé PHP au tout début. Comme quoi, les temps changent

C'est poser le problème à l'envers. Pourquoi ? Parce que ça revient à expliquer que le fait d'intégrer des outils de contrôles natifs dans le langage est préférable à la rigueur du développeur et, paradoxalement, c'est une incitation au laxisme.

Si bien des amateurs pourront sans trop de mal s'initier au PHP, très peu se lanceront avec Hack, pas plus qu'ils ne le feront avec Java ou C/C++ ou autre. Pourquoi devrait-on changer ça ?

La programmation est difficile, quel que soit le langage. On peut l'aborder plus facilement avec PHP qui est moins rigide et, ce faisant, réaliser certains aspects de la programmation, en particulier la nécessité d'une analyse exhaustive et détaillée pour justement isoler les différentes données qu'il va falloir manipuler, leurs types également. Il va falloir structurer tout ça de façon cohérente. S'il faut un tableau ici ou un objet là ou bien en entier ailleurs, alors il faut faire en sorte que la donnée qui arrive ne soit pas autre chose que ce qui est attendu et ne pas attendre que le langage indique que le type de donnée reçue est incompatible avec le traitement en cours.

J'insiste donc encore une fois sur la nécessité absolue de rigueur et de discipline pour le développeur. Partant de là, certains amateurs continueront et se perfectionneront, d'autre abandonneront et passeront à autre chose. Or si on a un développeur discipliné, ce dernier écrira un code cohérent en fournissant aux fonctions les paramètres appropriés du type attendu sans qu'il soit nécessaire qu'un élément du langage ne le lui indique.
Par ailleurs, avec ou sans ces contrôles natifs, si le type fourni n'est pas compatible avec le type attendu, il y aura une erreur. Quel est dans ce cas l'intérêt du contrôle natif ?

My 2¢

C'est poser le problème à l'envers. Pourquoi ? Parce que ça revient à expliquer que le fait d'intégrer des outils de contrôles natifs dans le langage est préférable à la rigueur du développeur et, paradoxalement, c'est une incitation au laxisme.

Je suis tout à fait d'accord, ce n'est pas parce qu'il n'y a pas de typage fort dans PHP que l'on doit coder comme un langage avec typage fort.
Selon moi c'est une autre méthodologie qu'il faut appliquer... (vérification du type par exemple, ce qui est tout à fait faisable avec les fonctions PHP)

Comparer un langage tel que le C ou le Java à PHP n'a aucun intérêt. Ils n'ont pas la même philosophie.

@cyrano : je confirme, coder comme un cochon c'est réalisable dans tous les langages (et j'en ai fait les frais)

@xTG : philosophie n'est pas forcément le mot que j'aurais employer mais c'est vrai que ce n'est pas utile en soit.
Par contre avoir une idée de la différence peux être intéressant (objet only ou pas, compilation ou pas etc).

@AoSiX : les génériques oui et non. En php on en a pas besoin du fait du faible typage.
Le fort typage implique le recourt a ce genre de chose si l'on souhaite avoir quelque chose de générique (sinon impossible de faire un orm objet par exemple).
Mais cela peux avoir un coup, soit en imposent des normes de dev (setter / getter en lower camel case et pas autrement etc) soit utilisant l'introspection (très coûteux en terme de performance).

Ceci dit un générique ne va pas te permettre de faire des choses extraordinaire juste t'aider un peu.
Imagine un bout de code (une ou plusieurs méthode qui font la même chose (par exemple un mvc objet avec un getView / setView) cela devra être refaire sur chaque contrôleur (en imaginant que tu en ai plusieurs).
Tu pourras faire un truc dans le genre ( en java)

[java]

abstrac class BaseController <T> {

private T;

public T getView(){
return this.view;
}

public void setView(T v){
this.view = v;
}
}

class MaVue {}
// utilisation

class Toto extends BaseController<MaVue> {}
// toto a donc setter / getter sur la vue qui doit être de type MaVue et pas autre chose

[/java]

En php tu faut la même chose, sans la partie pour le générique, et cela fonctionne nickel vu que c'est déjà générique.

Ceci n'est pas forcément contre le type, j'utilise aussi fortement le typehint quand je fait de l'objet avec php mais cela ne m'empêche pas d'être content de ne pas m'em**** a savoir si je dois avoir un entier ou un string sur une requête sql (sans même parler des dates qui, en java, ne sont pas cohérente entre le type date sql et le type date java).

Bref, hack pourquoi pas mais je ne suis pas certain que cela révolutionne le monde php car ce n'est pas le mode de pensé de base (ah bas en fait si philosophie c'est p´tet le bon mot au final).
En tous cas pas avant 10ans a la vitesse ou vont les gens côté évolution


-@+