Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
*SelonEnvoyé par Golgotha
Celons ta logique, si on est obligé d'importer math.h dans un programme C c'est que le langage C à donc un vrai problème ?
Sinon, ta comparaison est spécieuse.
math.h fait partie de la bibliothèque standard du C. Et la bibliothèque standard fait partie de la définition du langage.
En revanche, je ne pense pas que JQuery fasse partie de la bibliothèque standard fournie avec JS.
rooooooooo... non mais.... donc si jQuery était une lib 'standar' là ça serait bon ?
là c'est limite de la mauvaise foisdit tout de suite que tu veux me mettre en colère
Je n'ai jamais dit qu'utiliser JQuery est une mauvaise chose au contraire, je l'utilise très souvent quand je dois faire du JS un peu complexe et multiplateforme.Je comprends pas....
jQuery est une librairie JavaScript : ou est le problème ??
Donc, toi tu va faire du C/C++/C#/java from scratch ? bon courage hein, essaye de faire un programme sans importer une seule librairie.
Celons ta logique, si on est obligé d'importer math.h dans un programme C c'est que le langage C à donc un vrai problème ?
Franchement je ne suis pas du tout d'accord avec ta logique. Les libs sont des briques à utiliser pour ne pas ré-inventer la roue et elles existent dans tous les langages.
Et comme le dit grim7reaper, on ne peut pas comparer JQuery avec math.h en C, mais plutôt comme Struts en Java par exemple (Désolé pas d'exemple en C).
Enfaite ce sont plutôt les autres exemples que j'ai donné (Dart, TypeScript) qui me font dire que certains veulent remplacer le JS et JQuery n'entre pas dans ce cas.
Il n'y a pas de lib standard dans Javascript. Le DOM est une API , comme NodeJS a son API qui n'a rien à voir avec le DOM.En revanche, je ne pense pas que JQuery fasse partie de la bibliothèque standard fournie avec JS
JQuery existe principalement parce que tout les navigateurs n'implémentent pas le DOM de la même manière , les anti-jquery oublient complètement cet aspect.
Et pourquoi un langage doit-il fonctionner exactement de la même manière que les autres ?
Chaque langage possède ses avantages et ses inconvénients, ainsi que ses incohérences ... et c'est normal !
Après lorsque l'on maitrise bien un langage x ou y .. le résultat sera le même. ( pour des langages compatibles avec le produit final souhaité ).
Bref .. aucun langage n'est nul .. et aucun n'est parfait, le tout et d'utiliser le ou les bons pour arriver à un produit fini efficace et qui colle avec la demande.
Si Javascript ne vous plait pas, il suffit de vous mettre au CoffeScript qui a le même objectif, mais sans les côtés bizarres. Be positive
Faut juste abandonner les brackets.
false == false renvoie true
ok je sors []
WAT ne veut pas dire mauvais
Le WAT c'est de la dérision. On peut s'en servir pour s'amuser et se distraire ou pour critiquer un langage mais jamais de manière sérieuse. C'est comme dire que l'Homme est totalement inadapté à la vie terrestre parcequ'il ne cours pas vite, a froids ou des coups de soleils s'il n'est pas couvert, doit manger beaucoup de vitamine parce qu'il ne sais pas les fabriquer et que dire des 16 ans nécessaire a le rendre adulte.
Plus qu'une critique d'un langage, il s'agit de s'amuser des cas non prévus par le langage, si simple pour l'humain mais que le programme (Compilateur) ne comprends pas. Si javascript est critiqué c'est surtout qu'il permet d'écrire un tas d'erreur sans s'en rendre compte. Jamais javascript ne sort d'erreur (Ou si rarement). On peut déclarer un variable dans une fonction et s'en servir dans une autre... Pour moi javascript a un sens dans la mesure ou c'est aberrations permettent d'améliorer ses performances et d'éviter aux pages web de se planter même si une partie des scripts n'est pas chargé. Ainsi si une variable n'existe pas on la considère tout de même définie et ne connaissant pas le type de cette variable il peut y avoir qq souci mais cela ne devrait rien bloquer... Sauf au niveau du DOM (getElementbyId("NaN").
Ah non justement. Les fonctions sont les seuls objets définissant un scope particulier donc si une variable est déclarée (avec le mot clé var) dans une fonction, elle n'est pas utilisable dans une autre fonction hors scope. C'est précisément lorsqu'elle n'est pas déclarée (sans le mot clé var) qu'elle devient implicitement globale et est donc accessible dans tout le script.On peut déclarer un variable dans une fonction et s'en servir dans une autre...
Pas de question technique par MP !
Dans ce cas tu recommenderais de toujours utiliser la syntaxe var x = function() {} lorsque c'est possible?Ah non justement. Les fonctions sont les seuls objets définissant un scope particulier donc si une variable est déclarée (avec le mot clé var) dans une fonction, elle n'est pas utilisable dans une autre fonction hors scope. C'est précisément lorsqu'elle n'est pas déclarée (sans le mot clé var) qu'elle devient implicitement globale et est donc accessible dans tout le script.
Le javascript n'échappe pas aux bonnes pratiques et y en a une qui dit que les variables globales c'est le mal (dans 99% des cas).
_skip, non, ce n'est pas tout à fait ce que je disais.
Dans ta notation var x = function() {}, tu crées une fonction anonyme que tu affectes à une variable, ce qui n'est pas tout à fait la même chose que de définir une fonction nommée (function x(){}), mais c'est un autre aspect, ce dont je parlais, c'est de toujours déclarer ses variables avec le mot clé var :
que ce soit à l'intérieur d'une fonction ou non.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
J’avais déjà vu cette vidéo il y a quelques temps, mais ça me fait plaisir de la revoir
C’est intéressant de voir la réaction des gens, frustrés. Oui on aurait pu prendre d’autres langages en exemple (comme PHP tiens). En fait ça me fait peur, parce que ça montre à quel point les « programmeurs » d’aujourd’hui dérivent vers des langages mauvais. Cette vidéo montre bien pourquoi JavaScript est mauvais (et c’est un exemple parmi d’autres). Et voila ce qui est encore plus affolant :
Bien que le Java soit un langage qui m’horripile aussi, le fait qu’il fasse la distinction entre 1 et 1.0 vient de son typage fort. Et selon ce certain Mike, c’est « tout bonnement débile » ? Mais dans quel monde vit-il celui-là ? Le typage fort a l’avantage de bien faire la distinction entre les types. Peut-être qu’un programmeur JS ne le sait pas, mais entre comparer deux nombres, et comparer deux strings, c’est un peu différent. Du coup, "87534" == 8534, ça peut paraître un peu louche. On ne sait pas vraiment ce qui se fait derrière, les perfs vont forcément être mauvaises, et ça peut être sujet de bugs obscures.JavaScript ne doit plus être constamment tourné en dérision. Mike démontre aussi que d'autres langages peuvent être utilisés pour le WAT, c'est notamment l'exemple de Java qu'il cite. Par exemple, pour lui, le fait que Java fasse la distinction entre 1 et 1.0 ou 1 et "1" est tout bonnement débile.
Savoir que 1 – par exemple en C++ – est un int et que 1.f est un float, ça fait une différence notable. On va pouvoir savoir combien d’octets prennent chaque type, quel est la précision, etc.
C’est marrant de voir les gens à fond dans le JS ou PHP débouler pour protéger leurs langages infâmes en essayant de faire passer des avantages de langages forts pour des inconvénients. Après ils se retrouvent à écrire des ORM en mettant des @Int @Double sur leur variables. Ce post me donne le sourire
Il semble qu'aucun langage ne trouve grâce à vos yeux à part, peut-être, C++...
Aaaaabsolument! On ne compare pas une chaîne et un nombre; si une chaîne contiennent effectivement un nombre, on la "parse" pour obtenir ce nombre. Un programmeur C++ ne le sait peut-être pas, mais en JavaScript l'opérateur == effectue une conversion de type, c'est pourquoi son usage n'est pas recommandé et qu'on lui préfère l'opérateur ===.
Si, comme je le pense, vous voulez parler des avantages du typage fort, il n'y a, à ma connaissance, aucune étude qui démontre clairement la supériorité d'un système de types (statique vs. dynamique, fort vs. faible) en terme de productivité et de nombre d'erreurs par ligne de code. En outre, si l'on veut parler de "bons" systèmes de types, je ne pense pas qu'il soit judicieux de brandire celui de C++ en exemple; celui de Haskell serait sans doute un meilleur choix.
JavaSript a des défauts et ils sont bien connus. Encore une fois, ces erreurs de conceptions n'en font pas si mauvais langage. Peut-être qu'un jour un autre langage le remplacera dans les navigateurs Web, mais pour l'heure, il est le seul qui soit supporté. A défaut d'avoir ce que l'on aime, apprenons à aimer ce que l'on a, car en prenant le temps de s'y arrêter un peu, on s'aperçoit que ce n'est pas si mal.
Entre typage dynamique et statique aucune idée.
Mais entre typage faible et fort, même si je n’ai pas d’étude sous le coude, il me semble évident que le typage fort va réduire les bugs car toute une classe de bug, plus ou moins grande selon la force du typage, sera éliminé durant la phase de compilation/vérification.
Oui c'est une honte ces réactions de frustrés venus défendre un langage !
Il vaut mieux des frustrés venus démontrer la supériorité glorieuse des langages ayant grâce à leurs yeux !
bref du coup c'est quoi les langages mauvais et quoi les langages bons ? et comment on en reconnait un si on en croise (parmi la longue liste de langage existant ?
Tout dépend du besoin. Le problème avec JS est qu’il est le seul. Du coup comme beaucoup l’ont déjà dit « on n’a pas le choix ». C’est aussi une des raisons pour laquelle les gens le défendent : « on n’a pas le choix, alors on s’y fait, et on finit avec un avis biaisé. Ouais c’est bof le JS. Ah ouais c’est pas trop mal. Hey le JS arrête c’est sympa. Attends ça déchire trop le JS ! VIVE*LE JS !! AAAAAH JS !! ». Le prototypage de JS est une bonne chose, mais je me souviens m’être fait la remarque plusieurs fois lorsque je bossais sur du JS pour une boite et lors d’une discussion avec le responsable technique de l’équipe web :Oui c'est une honte ces réactions de frustrés venus défendre un langage !
Il vaut mieux des frustrés venus démontrer la supériorité glorieuse des langages ayant grâce à leurs yeux !
bref du coup c'est quoi les langages mauvais et quoi les langages bons ? et comment on en reconnait un si on en croise (parmi la longue liste de langage existant ?
« — Tiens, utilise backbone.js et underscore.js, c’est génial !, me dit-il.
— Ok; voyons voir. Ah tiens, ça rajoute en fait des fonctionnalités que le langage n’a pas, et c’est laid en plus d’être redondant.
— Oui mais c’est le futur ! »
Depuis longtemps j’ai la sensation – c’est subjectif mais je sais que beaucoup partagent cet avis – que les développeurs JS vivent 20 ans en arrière. Donc non seulement c’est typé faible, mais en plus ça donne la sale sensation que tout est pluggué par dessus et que le langage est tellement faible qu’il a besoin d’une horde de développeurs pour lui apporter un foreach.
Pour le typage, entre static et dynamique, je ne pense pas qu’on puisse dire que l’un est meilleur que l’autre. En revanche pour faible / fort, c’est évident. Un compilateur n’est pas qu’un simple outil qui va traduire des tokens.
Et pour la remarque sur la « supériorité glorieuse des langages ayant grâce à mes yeux », je ne fais qu’exposer leurs avantages. Le C est un excellent langage mais j’ai préfère le C++ pour son typage, entre autre. Je préfère coder avec un langage de bas niveau car contrairement à 90% des développeurs d’aujourd’hui, savoir comment la mémoire est allouée et ne pas me manger une collection pendant une opération importante, ça me tient à cœur oui. J’ai fait un peu d’Haskell dernièrement, et bien que j’adore ce langage, son GC me pose problème. C’est sans doute une différence d’expertise après tout, je suis plutôt dans l’optimisation bas niveau et rendu temps réel (je vois déjà venir les mecs me dire qu’on peut faire du temps réel avec un GC – non, pas de manière optimale, non.). Donc j’anticipe vos réactions en disant que oui, le JS n’a pas vocation à ce genre d’utilisation. Ça ne l’empêche pas d’être particulièrement mal fichu et repoussant.
je te conseille de cree ton propre language si sa peut t'evité la frustration comme ca tu ne poura t'en prendre qu'a toi meme mais qui sait peut etre que tu crera le language ultime
c'est pas vers cette periode que le C a ete cree et meme bien avant il me sembleles développeurs JS vivent 20 ans en arrière.
Le C a plus de 40 ans… Qui plus est, on peut dire ceci d’un langage qui vieillit :c'est pas vers cette periode que le C a ete cree et meme bien avant il me semble
- il prend en maturité au fil des années; on finit avec un langage mature
- de part l’expérience de ce langage, les nouveautés apportées au fil des années par le biais de standards sont toujours de plus en plus pointilleuses et intéressantes
Donc c’est quoi ton argument ? Entre vivre avec un langage qui a plus de 40 ans, et qui est donc affûté, et vivre avec un langage comme si on en commençait le développement (comme il y a 20 ans), il y a une sacrée différence.
Les aspects bas-niveau sont voués à être dépassés, skypers.
En ce qui concerne les performances, les compilateurs C d'aujourd'hui sont assez "intelligents" pour optimiser le code bien mieux que tu ne le ferais toi-même.
Et pour la gestion de la mémoire, on a des GC qui ne sont peut-être pas parfaits, mais qui pour des applications ne nécessitant pas des grosses perfs apportent un gain considérable en temps de dév.
Contrairement à toi, et pour le genre d'applis que je développe, je ne veux pas avoir à gérer la mémoire, car c'est contre-productif.
Maintenant soyons clair : le problème du choix n'est à imputer qu'à la domination du web face aux autres protocoles (existants ou qui auraient pu être inventés).
Le web n'a pas été prévu pour ça à la base, historiquement la notion qui y prime est celle de document, et non celle d'action comme en dév système.
Toutes les surcouches ayant été créées pour faire du web quelque chose d'applicatif sont presque une hérésie. Il aurait mieux valu inventer un protocole dédié.
Amha.
Cedric Chevalier 
Répondre avec citation
Partager