Informatique

Je rajouterai que, depuis quelques années (2 ou 3, je dirai, avec l'émergence de node.js - qui en est une résultante, pas une cause), javascript a acquis une plus grande "maturité", la même chose que PHP a eu lors de l'arrivée de ses versions 5.2 puis 5.4.

Ça a pour conséquence de soulever d'énormes débats de fonds sur la qualité du langage, mais aussi sur les méthodes à employer pour s'en faire maître (dont le livre que je t'ai cité), et une éclosions de vrais projets sérieux autour du langage, comme node.js, node-webkit, express, koa, grunt, gulp, et tant d'autres.

Et c'est pareil dans la communauté php : progressivement, des développeurs en ont eu marre de faire "du php de gamin", et ont voulu avoir la possibilité d'industrialiser leur travail, avec la mise en place de frameworks intelligents & stables, comme laravel, et des outils comme atoum.

Ça divise les communautés en deux, entre les développeurs "casual", qui se contentent de faire du dev facile et râlent facilement quant à la complexité de certaines techniques modernes, et les développeurs avec une approche plus "pro", qui veulent se permettre d'exiger des outils industriels et bien supportés pour faire un travail de qualité.

La puissance du javascript, c'est que c'est un langage accessible : tu peux faire un peu plein de trucs en codant comme un cochon, et ça suffit pour le plus grand nombre.

Deja, je rale des que je dois toucher a un langage qui n'a pas de typage fort...

"Là, j'ai envie de dire "suck it up!", tu râles juste pour le plaisir de râler (mais bon, c'est si chouette à faire, je peux pas t'en vouloir). "

Bien sur que c'est drole de râler ! :D Et en même temps j'apprend 2/3 trucs, et c'est cool ^^

| Deja, je rale des que je dois toucher a un langage qui n'a pas de typage fort...

Ça, déjà, c'est un peu con, comme remarque. Moi, mes variables ne transtypent jamais. C'est pas pasque le typage est faible que t'es obligé de faire n'importe quoi.

| Le javascript c'est la pornstar des languages de dev. Souple, puissant, mais à la fin ca finit toujours bien crade.

Pareil. Avec un peu de rigueur, tu peux arriver à un code final très propre.

"Javacript est un langage peu rigoureux, il faut l'être à sa place"

Tu veux dire qu'il faut bosser a la place du langage ? :D

Nanméçavapas ?!

"Deja, je rale des que je dois toucher a un langage qui n'a pas de typage fort... "

D'un côté, on pourrait se demander l'utilité d'un typage fort sur un langage dynamique pour le web et, surtout, non compilé (enfin pas du côté du dev directement).
Le gros avantage des langages à typage fort, c'est le compilateur qui gueule au moindre problème et ça permet généralement d'éliminer pas mal de bugs. En JS, on perdrait vite cet avantage. Erreur de type, il se passe quoi ? Exception ?

Après le typage fort apporte aussi certaines contraintes de développement qui sont peut-être, justement, trop contraignantes pour beaucoup de tâches de développement web, mais c'est un autre débat.

"Le gros avantage des langages à typage fort, c'est le compilateur qui gueule au moindre problème et ça permet généralement d'éliminer pas mal de bugs"

On est bien d'accord.

"Erreur de type, il se passe quoi ? Exception ? "

Pourquoi pas ? T'as bien des erreurs quand tu essayes d'appeller une méthode sur un objet qui existe pas, non ?

"Après le typage fort apporte aussi certaines contraintes de développement qui sont peut-être, justement, trop contraignantes pour beaucoup de tâches de développement web, mais c'est un autre débat."

Vu comment c'est parti, on peut l'avoir ici non ?

"Pourquoi pas ? T'as bien des erreurs quand tu essayes d'appeller une méthode sur un objet qui existe pas, non ? "

Mais à ce moment-là on perds les trois quarts des avantages d'un typage fort. Imaginons un instant que des langages type Haskell, Java ou C++ fassent un check du type au runtime, et non plus à la compilation (typage dynamique). On se retrouverait également avec des erreurs au runtime, éventuellement rapportées par une exception. On passe donc d'un système de type tel une barricade qui empêche la plupart des erreurs de type de sortir de l'environnement de développement, à un système de type qui peut exploser à tout moment en production.
Un typage fort sans compilateur pour gueuler, c'est quand même moins utile. Ça n'a même qu'une utilité plus ou moins égale à un typage faible, puisque dans tous les cas il y a une vérification minimale obligatoire à avoir au runtime pour déterminer les capacités des éléments, par exemple lors des appels de fonctions
Bref, là je cumule aussi avec typage statique et dynamique, mais vu que le JS est dynamique, un typage fort me semble pas forcément nécessaire.

Au final, on se retrouve avec un système de type contraignant, mais qui permet de repérer les bugs grosso modo au même moment (lors des lancements de la suite de test ou, pire, en production) qu'un système de type faible. Alors que le principal attrait d'un typage fort et statique est, justement, de détecter ces mêmes bugs au moment le plus tôt possible : avant même que le programme puisse se lancer.

"Vu comment c'est parti, on peut l'avoir ici non ? "

Pourquoi pas.
Dans l'idée, et en mettant de côté mon précédent point, le problème que je vois avec un typage fort dans le web, c'est qu'on essaye de mettre de la rigueur dans un environnement dont la majorité des activités est à l'opposé total de cette philosophie.
Le web n'a rien à voir avec le développement software. Il y a bien des situations où la rigueur d'un typage fort est très appréciée mais, d'une manière générale, pour la plupart des projets non gigantesques qu'on trouve sur le web, un typage fort serait trop contraignant. Le web est rapide et si on perds trop de temps à cause du typage fort, ça marche pas. Alors qualitativement, ça peut se sentir (encore que, le typage faible et la notion de duck typing c'est pas non plus la peste), mais le web est un amas monstrueux de petits fixs et autres squelettes dans le placard, malheureusement. Et si on prends un peu de retard, ça se ressent très fortement.

Je dis pas que le typage fort et/ou statique est une plaie pour le web, mais je pense que le principe d'un typage faible avec duck typing lui correspond très bien : on fait abstraction de toutes ces contraintes de type pour se focaliser sur le plus petit dénominateur commun : la capacité d'un objet à répondre à des messages, peu importe son type. Ça fait gagner un temps fou et pour des infrastructures web qui sont amenées à bouger énormément, avoir cette couche d'abstraction supplémentaire permet une maintenance ridiculement simple, contrairement à un typage fort et statique qui force toujours à un minimum de réécriture, à partir du moment où on a un couplage en dur avec des classes et des types.

@Lesquale : avec ctrl+maj+j en général ça me suffit.

Pour le reste je repasserait, la j'ai un bug sur une appli et je vois même pas d'ou il vient ^^'

lesquale > Pour les productions sérieuses, une suite de tests unitaires est ce qu'il se fait de mieux, du type Mocha.

"Pr les tests unitaires, il faut avoir déjà terminé les fonctionnalités "

Heeeuuuu, non
Regarde du côté du TDD ('Test-driven Development') ou du BDD ('Behavior-Driven Development'), qui permettent justement une approche entièrement testée et progressive du développement.
En plus c'est très à la mode depuis quelques années alors c'est toujours cool sur un CV

Sinon on en parle du topic qui ne sert à rien ? Rapport avec les créations de sites web que de taper sur un mec même pas là ?