Questions sur la demi-finale

peu*
capacité*
développeur*

« En soit, d'un langage à l'autre, pour mettre en place un algorithme dont les contraintes mémoire&temps d’exécution sont, il n'y a pas de grande différence »
Ce n'est qu'un avis personnel, mais le PHP n'est pas trop adapté à l'algo un peu "avancé". Les structures de données sont cachées au développeur, qui ne peut pas vraiment choisir s'il veut un tableau, une liste ou une hash table par exemple.

« epsilon012 : j'espère que tu t'es trompé dans tes compte, un dev' PHP dans le top 51, ça me semble peu. [...] Se cacher derrière un langage pour justifier que son code est meilleur qu'un autre est simplement ridicule »
Ah non, ce n'est pas ça le "problème". Le truc, c'est que PHP attire les noobs : en premier lieu car c'est un langage populaire, largement déployé, et utilisé pour le Web qui est souvent le service vers lequel les débutants se tournent naturellement ; en second lieu car le langage lui-même est simple à prendre en main et cache beaucoup de choses à celui qui l'utilise : duck typing, tableaux à tout faire... En soi c'est une bonne chose pour développer sans se prendre la tête, mais selon moi il n'est pas un bon langage pour un débutant, car il est quand même nécessaire de connaître les bases : types de données, structures de données, sécurité... Tout ça, ce ne sont pas des "problèmes inhérents à un langage qui risque d'encombrer l'esprit". :)

Les résultats sont quand même assez équivoques. S'il n'y a qu'un dév' PHP dans le top 51, c'est bien que le PHP est utilisé par une partie de noobs plus conséquente et/ou que les meilleurs le fuient.

jeu, 26/01/2012 - 22:35 — katagoto

> epsilon012 : j'espère que tu t'es trompé dans tes compte, un dev' PHP dans le top 51, ça me semble peu.
Les chiffres ne sont pas de moi, pour le TOP51, c'est serialk qui a donner les nombres. C.f. ce que j'ai ecrit :

mar, 24/01/2012 - 10:27 — epsilon012

> Top #: Le nombre de rendu avec un score dans le TOP51 (par serialk)

jeu, 26/01/2012 - 22:35 — katagoto

> un développeur expérimenté dans un langage plus "lent" fera sans doute un programme qui sera au final plus efficace et
> plus efficient qu'un développeur maladroit (ou moins riguoureux/méticuleux/etc.).
Oui et le fer c'est mieux que l'or puisque 1000 tonnes de fer sont plus cheres que 1 gramme d'or.

> Prologin demande un niveau suffisamment avancé en algorithmie que la necessité d'apprendre un langage réputé plus
> "rapide" ne fera que destabiliser le développera qui verra son esprit encombré par les doutes inhérents au langage
> support plutôt qu'au fond du problème.
"réputé plus rapide" ? Si ce n'était que de réputation... Les doutes inherents au langage sont plus nombreux en PHP imho.
Sinon, c.f. Wirth's law . Le probleme de PHP, c'est que ca se resume a ca , non seulement pour un grand nombre de personne qui l'utilisent mais parfois on se demande aussi pour Lerdorf.

Je viens juste dire un mot : Haskell est un langage génial pour faire de l'algo, et il n'y a aussi qu'un seul participant dans le top 51.

Si vous voulez alimenter le troll sur php, voici quelques trucs funs dans php :
- "1e3" == "1000" → true
- Unexpected T_PAAMAYIM_NEKUDOTAYIM
- Des noms de fonctions logiques : isset(), is_array(), empty() ou encore htmlentities() et html_entity_decode()
- Une rétrocompatibilité qui accumule les merdes : « implode() peut, pour des raisons historiques, accepter les paramètres dans un sens ou dans l'autre. ». Pas explode().
- microtime() : cette fonction est une grosse blague, « get_as_float : If used and set to TRUE, microtime() will return a float instead of a string, as described in the return values section below. »
- L'ordre des paramètres de mktime() : Wtf.

Wat.

ven, 27/01/2012 - 18:33 — serialk

> Je viens juste dire un mot : Haskell est un langage génial pour faire de l'algo, et il n'y a aussi qu'un seul
> participant dans le top 51.
Sauf que si tu regardes la colonne Suc%, tu vois que en effet Haskell est bien represente... pas PHP.

"tout les langages se valent plus ou moins en terme de perfs"
Lol ?
Je sais même pas si ça le mérite, ça.
Le "(globalement)" atténue à peine.
N'empêche, le jour où tu verras du PHP sur un système embarqué, tu m'appelleras, que je puisse me suicider !

WHAT !?
Personne ne l'a fait en Bash (la question 1 au moins) ?

Disclaimer : j'avais fait la finale en PHP (on était max 4), et cette année je comptais faire le 1 en Bash, mais j'ai oublié :/

J'ai tout lu. Mais je ne cite que les points sur lesquels je ne suis pas d'accord. ;)

D'ailleurs, je vais continuer !

"les scripts sont là pour gagner en portabilité"
Je ne savais pas qu'il y avait un interpréteur bash/php/autre installé par défaut sur w*nd*ws ...
Du coup, la barrière d'installation peut être bien plus grande qu'un programme écrit en C, C++, go, ou en fait n'importe quel autre langage compilé, qui, s'il est bien écrit, est portable par simple recompilation, et ne nécessite pas plus d'action de la part de l'utilisateur final que télécharger+lancer.

Et, quand je parle du PHP pour les systèmes embarqués, je peux aussi parler du calcul scientifique ou autre. C'est juste suicidaire d'utiliser le PHP pour des points où la vitesse est primordiale. Et l'algorithmique, en nécessitant des structures de données particulières pour être efficace, pose également un désavantage au PHP, qui ne permet pas vraiment de choisir la structure sous-jacente.

Par contre, je ne nierai pas le fait que le PHP fonctionne très bien pour ce pour quoi il est fait : les sites web. Mais, pour une bonne partie du reste, c'est simplement choisir une faux pour enfoncer un clou. A chaque outil sa tâche, à chaque tâche son outil (principe du KISS).

Lorsque j'ai lu "les contraintes spécifiques", j'ai compris les contraintes spécifiques car on doit utiliser telle ou telle librairie, parce qu'on doit s'interfacer avec tel autre programme, etc. Et pas les contraintes de performances. D'ailleurs, si tu sous-entendais les contraintes de performances, tu te contredisais tout seul. En effet, en reformulant ta phrase, "Je pense que tout les langages se valent plus ou moins en terme de perfs (globalement), à moins d'avoir des nécessités de performance". Où est la logique ?

"il n'existe pas de compilateurs C pour toutes les architectures."
Ah bon ? Tu peux m'en citer une ? Je me demande avec quels programmes elles fonctionnent ... (Et je ne parle que des architectures à processeur, hein.)
Par ailleurs, étant donné que, pour autant que j'en sache, tous les interpréteurs sont écrits en C - ou tout du moins un langage compilé. (Enfin, de plus ou moins loin : un interpréteur en C++ peut se résumer à du C, Jython écrit en Java doit lui-même utiliser une VM compilée, etc.)

"dire qu'on a pas le contrôle du type, que c'est un langage duck typé, qu'on ne maitrise pas nos structure de données, etc. c'est juste entièrement faux"
(Le reste de la phrase étant juste un enrobage, maintenant je vais me sentir obligé de justifier toutes mes coupes effectuées pour gagner de la place.)
Donc, plusieurs parties (je ne garantis pas la syntaxe, ça doit faire au moins un an que je n'en ai pas fait) :

Langage duck typé et contrôle du type : class A { public function duck() { echo "Ici class A"; }
class B { public function duck() { echo "Ici class B"; }
function foo(\$item) { \$item->duck(); }
foo(new A());
foo(new B());

1
2
3

Ca marche comment sans duck typing, ça ?  
 Oui, il est possible de limiter l'entrée de la fonction à tel ou tel type (enfin, je crois), mais le langage est
duck typé quand même.

Structures de données : \$tbl[0] = 0; \$tbl[1] = 1;
C'est quelle structure de données ?
Comment tu fais une liste doublement chainée ? Et une hash map ? Et une pile ? Et une file ?

Dîtes, vous arrêtez de rabaisser le PHP, ça en devient vexant (Eh ouais, j'assume, je fait partie des gens qui ont utilisé PHP)...
Je me justifie:
En soit, d'un langage à l'autre, pour mettre en place un algorithme dont les contraintes mémoire&temps d’exécution sont larges, il n'y a pas de grande différence, donc autant partir sur le langage qu'on maîtrise le mieux (du C je ne connais que les base)!
Donc bon, je vous Zutte! :)

Ce n'est quand même pas la fin du monde de faire une faute, même s'il y a des gens pour la souligner plusieurs fois. Le forum de Prologin n'est a priori ni une dictature, ni un lieu où l'on vient pour se prendre des remarques désagréables. Corriger les fautes des gens quand c'est fait sur un ton neutre ou sur un air de plaisanterie ça passe, si c'est pour rabaisser les gens c'est nul. Sachant que si on veut être aussi puriste que ça, en français on fait des phrases complètes, qui du coup commencent par une majuscule et finissent par un point.

Je pense qu'il y a quiproquo. C'est pas du genre de Thomas_94 de le faire avec un ton méprisant. Sa phrase est ambiguë, mais pour lui, elle ne l'était peut-être pas.

Si c'est le cas, je m'excuse, m'enfin je ne vois pas l'intérêt de son message dans ce cas :O

Peut-être une constatation neutre, mais je ne pense pas que tu ais besoin de t'excuser pour si peu. C'est seulement une interprétation hasardeuse d'un commentaire mal tourné.

Ekleog :

"il n'existe pas de compilateurs C pour toutes les architectures."
Ah bon ? Tu peux m'en citer une ? Je me demande avec quels programmes elles fonctionnent ... (Et je ne parle que des architectures à processeur, hein.)

attiny11
attiny12
attiny15
attiny28
at94K
at76c711
m3000
at90s1200

D'apres la doc de AVR Libc

Assembly only. There is no direct support for these devices to be programmed in C.

(Enfin il a l'air possible de contourner cette limitation mais ça me parait assez douteux)

katagoto:
"il n'est reste pas moins que ça reste du code machine, qui n'est pas forcément compilé, même s'il est rare d'écrire i, compilateur/interprêteur en binaire, je te l'accorde."
(Qu'est-ce que ce "i" ?)
Sinon, quand je parle de C, C++ ou autres, je parle de langage compilé (voire de binaire), au sens large du thème.
Le C et le C++ étant les noms que j'utilise pour désigner cette catégorie, car ils sont parmi les plus simples à utiliser parmi ces langages compilés.

"Ce n'est pas du duck typing, c'est un typage dynamique couplé à de l'inférence de type."
Et c'est ce qu'on appelle le duck typing : "When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck."
Est-ce que ce n'est pas ce qui est appliqué au PHP ? (bien que ce ne soit pas le seul, de loin)
Est-ce que le C++, possédant un typage dynamique (enfin, c'est émulable par l'héritage), et de l'inférence de type (avec le C++11, mot-clef auto), a un duck typing pour autant ?
J'en déduis que le PHP a un système de duck typing.
Au passage, le duck typing n'est pas forcément un mauvais point en soi, en tout cas à mon avis : c'est plus l'usage qu'on en fait qui l'est souvent.

"foo(B \$item) { \$item->duck(); }"
Je me permettrai de citer mon message précédent : "Oui, il est possible de limiter l'entrée de la fonction à tel ou tel type (enfin, je crois)".
Le "(enfin, je crois)" venant de mon absence d'expérience récente en PHP : je ne connais pas les derniers changements.

"Pour l'instant c'est un tableau, si tu fais \$tbl[42] = 42; là ça devient une table de hachage."
Selon la doc PHP, non : "An array in PHP is actually an ordered map." ( http://php.net/manual/en/language.types.array.php )
Tu perds donc même l'accès en O(1) en moyenne.
Est-ce qu'un langage où une variable change de type toute seule est un bon langage pour l'algorithmique ? Selon moi, non.

"Comme en C, ou bien on utilise array_push, array_pop, etc. Nous avons également une palette d'interface qui gère ça très bien."
Et le nom de ces fonctions est très bien choisi. Pourquoi ne pas faire "normal", en ajoutant une classe stack ?

polobricolo:
D'après cette page , partant d'un lien venant de la FAQ même que tu cites, c'est possible. Il semble même y avoir un toolkit presque clefs en main.

Ah oui, ma remarque faisait en effet gros con, je ne m'en suis pas rendu compte sur le moment.
C'est juste qu'«interprêteur», ça ne flatte pas la rétine.

*interpréteur

vous partez drôlement loin

katagoto:
"même si syntaxiquement c'est pareil"
Donc on est d'accord, puisque le duck typing c'est uniquement de la syntaxe, peu importe l'implémentation sous-jacente.
Au passage, Wikipedia dit comme moi - même si ce n'est pas la source de la Vérité absolue.
D'ailleurs, même le C++ permet du duck-typing au compile-time, avec les templates.
Voire le C au runtime, avec les void* (mais; là, il faut vraiment le vouloir).
Comme quoi, c'est finalement assez répandu le duck typing.

"La doc est là pour nous expliquer les moyens d'utiliser les fonctionnalités, quand tu regarde un peu le code source de PHP tuy vois clairement la différence, pareil si tu fais des benchmarks."
Donc les maps de PHP sont des hash map, mais sur lesquelles on itère en mode ordonné ? (bah oui, si la doc' dit que c'est ordonné, je suppose qu'on itère dessus dans l'ordre)
C'est encore plus épatant que ce que je croyais, en fait ! =D

"Les objets n'ont pas été intégrés dès le début dans PHP, ça fait partie de son lot d"incohérences."
Peut-être, alors, faire semblant que ce soit une stack, permettant d'écrire du code plus syntaxiquement compréhensible, comme :
\$s = stack(); // Fonction qui retourne un array vide
stack_push(\$s, 3);
\$trois = stack_pop(\$s); // Et là, juste renommer array_push et array_pop

roket: C'est pas le principe des forums prologin ?