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

Zerosquare (./1590) :
on a le droit de trouver que certains sont meilleurs que d'autres, et que certains sont plus adaptés que d'autres à certaines choses.

C'est grave si on pense la même chose avec des humains ? (genre: certaines femmes sont plus adaptés pour le sexe que d'autre )

Je sais pas, mais c'est pas le topic pour en discuter.

Pas les langages bien sûr, mais ceux qui les utilisent. PHP et JS sont nés de bricolages pour de petits trucs sans grande envergure, leur évolution est basée sur un héritage difficile à supporter (au deux sens du terme).
Ceci étant, si on les réduit à leur plus simple expression, ce ne sont jamais que des langages de script. Sont-ils plus/moins adaptés que d'autres langages de script comme Perl ou Python ? est-ce que le soucis derrière cette question n'est pas davantage une opposition entre une préférence pour le compilé ou le plain-text ?

Ha non mais Perl, java, lua ou Python je ralerais aussi tu sais. Ils ne sont pas plus adapté pour faire les applis embarqué que PHP/JS.

Faire des bricolages mouai a la limite, mais c'est du bricolage.

Ou alors c'est une utilisation tres particuliere, ce n'est pas le logiciel printipal de l'objet et juste le moyen de personaliser queqlues fonctions, a part ca, en embarqué tu as des contraintes fortes de temps d'execution et de mémoire, ce que les languages interpreté sont rarement tres bon.

Java a quand même et vrai typage et une syntaxe globalement plus propre que JS et PHP . Je connais mal phyton et lua, mais il me semble qu'il ont aussi une syntaxe bien plus propre.

Tous les objets embarqué n'ont pas des contraintes de temps réel. Mais de toute façon une appli en un langage de script, même performante aura besoin d'un environnement bien plus lourd et consommera donc fatalement plus.

Heu, temps d'execution n'est pas necessairement lié a "temps reel", mais a la consommation dans ce cas précis.

Et meme si pour JS/PHP qui sont des languages tres orienté je ne comprends pas du tout l'interet, c'est aussi parce que ce sont des langages interpreté (je ne parle meme pas de la qualité du language..)

Ce n'est pas dur d'avoir une syntaxe plus propre ou d'avoir moins de pièges que le JS ou le PHP
Mais comme dit Godzil, le problème est plus au niveau de la gestion de la RAM.

Bien sûr, on a toujours les cas « dégénérés » où finalement 99,9% du temps est passé dans du code C, le code purement en script n'étant que du ciment entre ces fonctions.

Hé, les gars... PicoLisp aka PilOS

Godzi et Zerosquare -> vous qui faites de l'embarqué, vous considérez qu'il n'y ait que le C de pertinent pour ce domaine ?

Ça dépend pour quoi.

Pour de l'embarqué comme les distributeurs de billets SNCF dont parlait récemment Ximoon, tu peux faire un peu ce que tu veux, c'est un environnement assez comparable à celui d'un ordinateur desktop (au pire, ce sera de l'ARM au lieu du x86, mais avec une puissance CPU et une quantité de RAM confortables).

Pour un appareil mobile comme une tablette d'entrée de gamme ou une liseuse, tu es restreint par les spécs matérielles. Utiliser du Java ou du C# par exemple peut être techniquement faisable, mais au prix de perfs dégradées et d'une consommation supplémentaire qui font que ce n'est pas franchement une bonne idée (rappelez-vous les vieux téléphones Java, par exemple).

Plus tu vas descendre en coût ou augmenter les contraintes de réactivité, moins tu auras le choix :

- les langages garbage-collectés sont hors-course pour tout ce qui a besoin de déterminisme ou de temps d'exécution maximum garanti (télécoms, contrôleurs industriels, etc.). Dans les cas les plus restrictifs, toutes les allocations mémoires sont statiques. Ça élimine déjà pas mal de langages.

- si tu as besoin de hautes perfs, d'économie d'énergie et/ou d'exploiter à fond le hardware dispo (ce qui est souvent le cas : le hardware, ça pèse dans le prix de revient du produit ; donc dès que tu fabriques en quantités non négligeables, c'est rogné au maximum, au grand dam des dévs hardware et software), tu peux oublier tout ce qui est langages interprétés ou compilés à la volée. Même le C++ est à utiliser prudemment, quand on peut le faire.

- enfin, même si d'autres langages seraient bien adaptés, il faut encore que les compilos existent pour la plateforme visée. Quand on voit que certains n'ont commencé à supporter le C99 que récemment, et qu'il y a encore des bugs sérieux qui traînent dans certains compilos C, ça te donne une idée de la maturité du secteur. Il y a des cas où tu as le choix entre C et assembleur, et c'est à peu près tout.

flanker (./1597) :
Mais comme dit Godzil, le problème est plus au niveau de la gestion de la RAM.

Boarf, de l'embarqué avec des langages interprétés, il y en a toujours eu, non ? J'ai souvenir d'avoir piloté des machines avec directement des grafcet, c'est une forme de script interprété à la volée...


Enfin, perso, je trouve que c'est un faux problème : je veux faire un truc simple et je ne connais (ou maîtrise) que le PHP ; je pourrais "perdre" du temps à apprendre un nouveau langage et faire "proprement" et de façon "optimisée" (enfin, c'est même pas dit, quand on voit certains trucs en C), mais j'ai un truc qui me permet d'aller beaucoup plus vite. Pour faire un peu de domotique, pas besoin de grand chose.
En plus, c'est loin d'être stupide, parce que ça permet d'avoir à disposition toutes les API web classiques, et de monter un webservice ou une appli web pour piloter son dispositif (chose qui serait un peu plus chiante avec du C embarqué).
Après, moi, ce qui m'inquiète plus, justement, c'est la mise à jour des services ouverts à l'extérieur (même si c'est juste sur un réseau local, il suffit d'un cheval de troie et d'une faille dans la boite...). Mais ça, ce serait la même chose avec un environnement Java.

Nil (./1601) :
Après, moi, ce qui m'inquiète plus, justement, c'est la mise à jour des services ouverts à l'extérieur (même si c'est juste sur un réseau local, il suffit d'un cheval de troie et d'une faille dans la boite...). Mais ça, ce serait la même chose avec un environnement Java.

Tu auras bien plus de failles avec du PHP fait main que dans d'autres langages avec les framework adaptés.
Si tu utilises RoR ou Django (ou n'importe quel framework digne de ce nom, je cite ceux que je connais), et à moins de le vouloir très fortement, tu élimines les failles CSRF, les injections SQL, les sessions sont correctes, les mots de passe sont stockés convenablement, le code de l'appli n'est pas accessible (même avec une configuration incorrecte), etc.
Avec PHP de base (et je ne suis pas sûr que ça change beaucoup avec certains framework), tu as par défaut plein de failles possibles qu'il faut connaître pour les boucher. Avec ces framework, il faut les connaître pour les ouvrir. Ça change quand même beaucoup.

Euh en PHP, ça fait longtemps que les injections SQL sont éliminées (ça date de quand, déjà, PDO ?!).
Pour le reste, ça dépend beaucoup de ton infrastructure serveur (si tu utilises un proxy front-end et de l'url rewriting, tu n'as jamais accès au code) et de ta façon de développer, c'est vrai. Mais c'est aussi ce qui permet la souplesse de la chose (avec un Tomcat, par exemple, tu évites aussi beaucoup de failles, mais tu n'as pas la même souplesse de déploiement).

flanker (./1602) :

Nil (./1601) :
Après, moi, ce qui m'inquiète plus, justement, c'est la mise à jour des services ouverts à l'extérieur (même si c'est juste sur un réseau local, il suffit d'un cheval de troie et d'une faille dans la boite...). Mais ça, ce serait la même chose avec un environnement Java.

Tu auras bien plus de failles avec du PHP fait main que dans d'autres langages avec les framework adaptés.
Si tu utilises RoR ou Django (ou n'importe quel framework digne de ce nom, je cite ceux que je connais), et à moins de le vouloir très fortement, tu élimines les failles CSRF, les injections SQL, les sessions sont correctes, les mots de passe sont stockés convenablement, le code de l'appli n'est pas accessible (même avec une configuration incorrecte), etc. Avec PHP de base (et je ne suis pas sûr que ça change beaucoup avec certains framework), tu as par défaut plein de failles possibles qu'il faut connaître pour les boucher. Avec ces framework, il faut les connaître pour les ouvrir. Ça change quand même beaucoup.

Bah deja tu compares des framework a un langage, si tu prends RoR et Django, prend Symfony ou Laravel pour PHP (entre bien d'autres), ce n'est deja plus la meme chose.

Et effectivement, PDO est la depuis un bon bout de temps.

Là en revanche je proteste : si tu utilises également un framework PHP (au lieu de comparer PHP pur à un framework d'un autre langage), tu auras aussi l'élimination de failles et injections. Et si tu fais du PHP pur sans savoir utiliser PDO et ses requêtes préparées contre les injections SQL, c'est que tu as appris PHP il y a environ 10 ans sans te soucier des évolutions du langage depuis. Pour les failles CSRF, je veux bien reconnaître que la solution est à mettre à la main, et non automatique.
Pour les frameworks cependant, j'ai mes habitudes avec CakePHP, l'un des plus anciens frameworks PHP, et la protection contre ces failles se fait en une ligne pour l'ensemble du projet. Quant aux injections SQL, l'ORM du framework fait que même sans saisir ce concept, il n'est pas possible d'en être victime.

Je n'ai jamais de mal à bâcher PHP à force de bosser avec, mais j'aimerai qu'on reste dans le stade du raisonnable à ne pas dire que si un type à poil ne fait pas le poids face à un gamin armé d'une mitraillette, cela signifie qu'un gamin est plus fort qu'un adulte.

#cross Nil#

Nil (./1603) :
Euh en PHP, ça fait longtemps que les injections SQL sont éliminées (ça date de quand, déjà, PDO ?!).Pour le reste, ça dépend beaucoup de ton infrastructure serveur (si tu utilises un proxy front-end et de l'url rewriting, tu n'as jamais accès au code) et de ta façon de développer, c'est vrai. Mais c'est aussi ce qui permet la souplesse de la chose (avec un Tomcat, par exemple, tu évites aussi beaucoup de failles, mais tu n'as pas la même souplesse de déploiement).

Arvi89 (./1604) :
Bah deja tu compares des framework a un langage, si tu prends RoR et Django, prend Symfony ou Laravel pour PHP (entre bien d'autres), ce n'est deja plus la meme chose.
Et effectivement, PDO est la depuis un bon bout de temps.

Quand on utilise un framework, oui, je suis d'accord avec vous. Mais PHP est censé être autosuffisant pour faire du web (c'est quand même un langage qui est fait pour !) et la plupart des gens, si ce n'est tous, commencent par faire du PHP brut. Combien de sites faits en PHP "pur", sans framework généraliste ? Il suffit de voir des sites comme Wordpress, ou PhpBB qui sont toujours faits "à la main", avec le lots de failles qui vont avec.

Quand tu prends un autre langage, tu n'auras pas tellement le choix et tu prendras un framework (sauf peut-être avec perl avec lequel tu feras un peu de cgi).
C'est ce que je disais plus haut : avec PHP, le comportement par défaut (faire sans framework et tout faire à la main) est mauvais et conduit à avoir des failles. Avec les autres langages "classiques", le comportement par défaut est beaucoup plus sain, dans la mesure où de toute façon tu ne peux pas vraiment faire autrement.

Moi je fait des sites web en C pur

flanker (./1606) :
avec PHP, le comportement par défaut (faire sans framework et tout faire à la main) est mauvais et conduit à avoir des failles

Je vais répondre, crois-moi, sans mauvaise foi aucune : avec un tel raisonnement, on pourrait aussi bien jeter à la poubelle des langages comme C/C++ sous prétexte qu'ils n'ont pas de garbage collector ou qu'on peut créer des buffer overflow.
Ce n'est pas parce que PHP n'a pas de garde-fou avec de grands panneaux lumineux "faut pas faire comme ça sinon ça crée des failles" que le langage doit être blamé pour ce qui est de l'incompétence de ceux qui l'utilisent. Encore une fois, ne pas gérer les failles CRSF est une méconnaissance du développeur. Ne pas savoir utiliser PDO pour éviter les injections SQL, c'est ignorer le B-A-BA du duo PHP/SQL depuis presque 10 ans.

Les frameworks dont tu parles permettent à des langages non-web de faire du web. Les frameworks PHP permettent de ne pas avoir à réinventer à chaque fois la roue pour des concepts comme l'authentification, la structure MVC, l'envoi d'emails HTML compatibles avec le plus de messageries possibles...

Godzil (./1607) :
Moi je fait des sites web en C pur

Fingueurs ine ze nauze : http://www.i-visionblog.com/2014/02/creating-website-using-c-programming.html

Folco (./1609) :

Godzil (./1607) :
Moi je fait des sites web en C pur

Fingueurs ine ze nauze : http://www.i-visionblog.com/2014/02/creating-website-using-c-programming.html

execute as CGI using Apache server

Do not want.

Godzil (./1607) :
Moi je fait des sites web en C pur

So do I! http://nxweb.org/

Moi c'était en 2001 sous QNX avec le serveur web fourni par QNX

Et pas un site de merde

6.1.0 community edition...

Les bornes SNCF Transilien, c'était de bêtes PCs sous Windows XP, avant la nouvelle version qui est déployée, qui est un PC sous Seven...

[manager vs dev]
— Pierre a vu sur le proxy que tu vas sur des sites de drogues.
— https://t.co/pVjMsnc526 n’est PAS un site de drogues…

— webAgencyFAIL (@webAgencyFAIL) April 19, 2016

LOL, la drogue PHP!

Non mais sérieusement, les developeurs C++ sont devenue des breles a ce point:

http://en.cppreference.com/w/cpp/keyword/or_eq
http://en.cppreference.com/w/cpp/keyword/and
http://en.cppreference.com/w/cpp/keyword/or
http://en.cppreference.com/w/cpp/keyword/and_eq
http://en.cppreference.com/w/cpp/keyword/not

????

A la limite les "and/or/not" & co, vraiment a la limite, mais or_eq ???

var1 or_eq var2

??

On perd completement le coté visuel de l'assignation, rien n'indique que c'est bien var1 et non var2 qui recois l'assignation Non seulement c'est un truc de feignasse (qui en plus demande de taper plus) mais en plus ca rends le code illisible

Le pire, c'est apriori défini comme des macros:

#define or_eq |=

\o/

Bientot

#define equal ==

ou

#define is ==
#define then {
#define endif }

if (var1 is 12) then
do something
else
do something else
endif

?

Ca vient initialement d'une habitude historique du C (iso646.h), à une époque où il existait des claviers qui ne permettaient pas de taper ces symboles. Aujourd'hui ça n'a plus d'intérêt, mais compatibilité ascendante tout ça...

Tiens, j'avais oublié cette incompatibilité entre le C (qui demande à inclure un include) et le C++ (pour qui on ne peut pas y échapper) !

C'est juste immonde et devrait etre banni de tout compilateur qui se respecte. C'est meme pire que la syntaxe K&R