[F] [mOved] Mon langage est mieux que le tien - Page 21

Ben en soi, cela semble plutôt logique. C'est justement dans un langage de haut niveau que tu va définir des opérateurs compliqués, vu qu'en assembleur, tout va se résumer à des conditions sur des flags
Après, tous ces langages qui ont des opérateurs étranges nous ont servi à quelque chose: On sait de nos jours que lors de la création d'un langage, il faut que les opérateurs par défaut (non surchargés, etc.) se comportent de manière facilement prévisible.

(Genre même en JavaScript, si l'opérateur == est relativement prévisible, le fait qu'il effectue plein de conversions implicites le rend non transitif donc c'est le bordel)

Non mais ce genre de 'blagues' font que les débutants avec ce genre de langage, on va cherché des bugs dans notre code, qui ne viennent pas de notre code, ca aide pas du tout.


GT Buggé !

Ah, ça c'est clair que JavaScript ne serait pas le modèle que je choisirais pour créer un nouveau langage. Il n'est pas aussi mauvais que PHP, mais ça reste du niveau unijambiste contre cul-de-jatte.

Je te rassure, personne de sensé ne conseillera de commencer la programmation par le PHP ou le Javascript. La seule excuse qu'ont les concepteurs de ces langages, c'est qu'ils étaient censés au départ être de simples bricolages sans grande importance. Pour le reste, ce sont de très bons exemples de ce qu'il ne faut pas faire (et des preuves supplémentaires que ce n'est pas la qualité qui fait la popularité, hélas).

./602 > Ben de toutes façons, tu peux t'attendre à ce que dès que le langage ne soit pas fortement (≠ statiquement) typé, ce soit le bordel. (Je sais pas s'il existe beaucoup d'exceptions, quelqu'un a-t-il des infos là dessus ?)

Zerosquare (./604) :
Je te rassure, personne de sensé ne conseillera de commencer la programmation par le PHP ou le Javascript. La seule excuse qu'ont les concepteurs de ces langages, c'est qu'ils étaient censés au départ être de simples bricolages sans grande importance. Pour le reste, ce sont de très bons exemples de ce qu'il ne faut pas faire (et des preuves supplémentaires que ce n'est pas la qualité qui fait la popularité, hélas).

Bof, c'est facile à prendre en main, si tu ne fais pas de trucs trop compliqué tu n'as pas trop de soucis, c'est bien pour ça que c'est si populaire (PHP).

Mais c'est vrai que je conseillerai plutôt le Python pour apprendre à programmer, je toruve dommage qu'on n'ai pas appris ça à SUPINFO.

PHP et JS donnent surtout de très mauvaises habitudes. À part si tu ne codes que pour toi, et que tu n'as aucune contrainte de fiabilité, de sécurité..., c'est vraiment pas une bonne façon de se lancer.

Y'a pas de problème de sécurité dans/avec *JavaScript*, hein (Vu qu'à la base, JavaScript ne fait rien)
PHP, en revanche…
La fiabilité par contre, c'est l'affaire du développeur (et oui, ça demande de connaître le langage avec lequel tu bosses ).
Donne le meilleur langage du monde au plus mauvais développeur du monde, et il en ressortira un mauvais développement.

Ce que tu veux dire je pense, c'est que ces langages embarquent trop comportements implicites susceptibles d'induire le développeur en erreur et donc de lui faire produire du code faux, mais là on est d'accord.

Il y a ça, mais pas seulement. Dans le cas de PHP, même si ton code est "parfait", tu restes à la merci des failles et autres bugs qu'il y a dans l'implémentation du langage (c'est vrai dans tous les langages bien sûr, mais certains sont bien pire que d'autres de ce point de vue).

Non mais alors là c'est des bugs dans les fonctions fournies avec le langage. C'est vrai qu'avec PHP, c'est difficilement dissociable du langage lui-même, mais c'est juste parce que le langage est super mal conçu. (Architecturalement parlant)
Dans les autres langages, même s'il existe une librarie de fonctions/classes de base, il n'y a souvent besoin que d'un petit sous ensemble (∅ pour le C89 ?) de celle-ci pour assurer au langage 100% de ses fonctionnalités (Comprendre que ce qui manque alors peut être réimplémenté ou bien contourné), et en général, celles-ci sont assez clairement définies, et déboguées correctement.

Mais de toutes façons, au niveau de PHP, je pense qu'il n'y à guère que squale92 et Meowcate qui iraient le défendre sérieusement ici, pour le reste on doit plus ou moins avoir la même idée de la chose

enfin bon le principal problème n'est pas le langage, mais l'expérience/le temps données/les reworks/le nombre de personne/le budget qui va faire que le programme va être plus ou moins bien branlé.

Arvi89 (./606) :
Mais c'est vrai que je conseillerai plutôt le Python pour apprendre à programmer, je toruve dommage qu'on n'ai pas appris ça à SUPINFO.

Perso, je trouve que c'est une mauvaise idée, à cause du typage dynamique.
Tu peux facilement avoir un truc qui tombe en marche plus ou moins par hasard en Python, sans que l'élève en comprenne réellement pourquoi.

Pour moi, un langage statiquement typé est obligatoire pour l'enseignement.

Zerosquare (./604) :
Je te rassure, personne de sensé ne conseillera de commencer la programmation par le PHP ou le Javascript.

Pourtant ici, le cours d'introduction à la programmation pour mathématiciens se fait en PHP. (À moins que ça n'ait changé depuis.)
(Je ne l'ai pas passé, parce qu'il était facultatif et parce que j'ai aussi fait informatique où on apprend la vraie programmation. )

Kevin Kofler (./614) :
Pourtant ici, le cours d'introduction à la programmation pour mathématiciens se fait en PHP.

Ah ben bravo... ils vont avoir une belle image des informaticiens, les matheux, tiens... Qui a eu cette idée "géniale" ?

Pour mathématiciens ?
Y'a difficilement moins concis mathématiquement que PHP… (Ou peut-être javascript)

C'est la faute à Wittgenstein, c'est tout!

(pis je vois pas à quoi ça va servir à un matheux, de connaître un langage dont le seul intérêt est d'être dispo sur la grosse majorité des serveurs web...)

à l'école, ils faisaient du matlab, du python, du mapple ou équivalent…

si si ca a un intérêt: leur faire découvrir l'Internet du Monde Mondial, et apprendre a se faire une page perso pour le future labo ou ils vont bosser.

Vous savez comme on faisait en France ya 15 ans

Je serais bien d'accord pour dire que PHP n'est pas ce que je conseillerai pour démarrer en prog.
Cependant, les problèmes évoqués sur ce topic sur PHP sont relativement spécifiques : peu de chances que ce genre d'incohérence n'arrive quand on code pour apprendre le langage.
Pour la table de vérité au passage, faute de bricoler je m'impose des normes : la variable à gauche ($var == 'var'), si les valeurs possibles sont connues et qu'on a besoin de souplesse == est envisageable*, sinon du === systématique.
Je sais qu'on ne devrait pas avoir à se faire ce genre de contrainte, mais chaque langage a ses incohérences et ses "spécialités" de conception (on peut faire une recherche de "What's wrong with..." avec chaque langage), même si PHP a toujours de mauvaises bases.

Kevin Kofler (./613) :
(Je ne l'ai pas passé, parce qu'il était facultatif et parce que j'ai aussi fait informatique où on apprend la vraie programmation. )

Désolé d'être resté à la "fausse" programmation, il faut dire que mon école était très limité : on n'a même pas appris à développer des sites web à l'aide de protocoles obsolètes. Ils ont préféré se concentrer sur les langages les plus populaires* du moment, les cons !

* J'ai bien aimé apprendre le C# à l'occasion, mais j'aurais préféré faire du Java à la place. Je n'ai jamais eu la motivation de l'apprendre en solo.

Meowcate (./620) :
Je sais qu'on ne devrait pas avoir à se faire ce genre de contrainte, mais chaque langage a ses incohérences et ses "spécialités" de conception (on peut faire une recherche de "What's wrong with..." avec chaque langage), même si PHP a toujours de mauvaises bases.

Certains plus que d'autres

Des fois, on se demande, quand même...
(oui, c'est bien la doc de la LibC GNU, pas celle de PHP )

O_o

C'est la sécurité du 42^e millénaire…

C'est surtout une fonction "blague" pour avoir une fonction avec "frobnicate" dans le nom, cf. le "See also: strfry".

Toute à l'heure sur mes toilettes, je me suis dit que j'étais quand même un peu trouducuté.

Je ne sais pas si certains d'entre vous ont essayé Android Studio, mais ce truc vient avec gradle, le nouveau système de build de référence pour les applications Android. Il marche plutôt bien mais le temps de build est disproportionné. Il a fallu une minute vingt (1'20) pour builder ma petite application contenant une 30aine de fichiers C++ et 4 classes Java sur une machine récente. Et encore, c'est en l'ayant lancé plusieurs fois avant avec un build failed. Pour comparaison, il faut 12 secondes pour sortir une appli Win32 avec le même code à partir d'un clean build sous Visual Studio depuis une VM que je venais de démarrer.

En fait, en 12 secondes avec Gradle on fait l'équivalent d'un --help :

$ ./gradlew
:help

Welcome to Gradle 2.2.1.

To run a build, run gradlew <task> ...

To see a list of available tasks, run gradlew tasks

To see a list of command-line options, run gradlew --help

BUILD SUCCESSFUL

Total time: 9.726 secs

Dans les 9 secondes il ne compte pas le démarrage et tout. Alors oui en optimisant (Android Studio garde un démon qui prend 1~2 Go en RAM, utilise tous tes cores CPU et retire parfois certaines phases de compilation) on arrive à ramener ça à 3~4 sec pour un build incrémentiel d'un Hello World, ce qui est raisonnable. Mais avec des désavantages comme l'impossibilité de stopper le build, car ce démon est lent à relancer et l'arrêt n'est jamais sûr, donc c'est simplement pas supporté. Sérieux ? Si tu t'es planté, tu perds 1 min et beaucoup d'électricité.

Je me pose des questions. Comment est-ce raisonnablement possible de designer et vouloir utiliser des outils pareils ? Ou pire oser releaser ça (même si on admet que les développeurs Java n'ont pas beaucoup d'amour propre). Oui "ça marche" contrairement à ce qu'on avait avant, donc c'est une grosse amélioration par rapport à Eclipse et ça justifie logiquement un passage sur ce système, mais quand même ? Où va-t-on s'arrêter ? A-t-on idée du nombre de cycles CPU que ça représente 1 min 20 d'un quad core ? Et combien sont réellement utiles dans le lot ?

Bah, et les choses sont je pense moins pire, mais au boulot pour une des plateforme on a deux moyens de builder, une utilisant de simples makefile une autre "plus souple" utilisant scons.

Resultat, scons est casse pour cette cible, et est de toute maniere bien plus lent pour tout generer que ce que makefile peux faire. (et JE trouve que makefile parallelise mieux que scons)

Donc bon, c'est une tendance general a faire des outils plus complexe, avec plein de plus de souplesses, par contre toujours au detriment que quelque chose, ici la vitesse.

Brunni (./626) :
(Android Studio garde un démon qui prend 1~2 Go en RAM, utilise tous tes cores CPU

...au secours

Ma formulation n'est pas bonne, il n'utilise pas en permanence tous tes cores. Juste quand il est utilisé.
Godzil> Oui. Mais je me demande justement s'il n'y a pas un moment où on pourrait s'arrêter. La courbe d'apprentissage de gradle est extrêmement complexe. Je sais que les implications dans le fait de designer une chaîne de build sont nombreuses (surtout pour pouvoir paralléliser), donc je comprends que tout ne soit pas évident. Au final c'est probablement juste que l'outil n'est pas fait pour ce qu'on en fait (une appli Android). En mettant toutes ces contraintes on y gagne en cas de build vraiment énorme et effectivement parallélisable. Dans d'autres cas, juste lancer le système de build prend le temps de faire tout le build sur un seul core CPU.

Non mais même, bouffer 1 ~ 2 Go pour un machin en arrière plan, dont la seule fonction est d'avoir des perfs à peu près normales... c'est du délire.