Developpez.com

Club des développeurs et IT pro
Plus de 4 millions de visiteurs uniques par mois

CoffeeScript une réponse possible au champ miné qu'est JavaScript ?
Un blogueur explique pourquoi ce n'est pas le cas

Le , par Arsene Newman, Expert éminent sénior
« Pourquoi CoffeeScript n’est pas la réponse ? » telle est la question posée dans le billet de blog de Jeff Walker, un développeur avec plusieurs années d’expériences qui revient sur les plus et les moins de CoffeeScript.

Tout d’abord, CoffeeScript est un projet open source qui introduit une nouvelle syntaxe au langage JavaScript et qui apporte son lot de concepts nouveaux. L’autre mérite de ce projet est décrit dans ce qui suit : « La règle d’or de CoffeeScript se résume à : C’est juste du JavaScript. Cela veut dire qu’il y a équivalent strict à chaque ligne de CoffeeScript. Par conséquent, il n’y a pas autant de problèmes d’interopérabilité du JavaScript qu’avec d’autres comme Dart ».

Forts de ces arguments, Jeff Walker a décidé d’utiliser cette variante de JS dans un nouveau projet, néanmoins il semble que l’expérience n’a pas été concluante : « Cette expérience m’a amené à ne pas utiliser CoffeeScript sur mon projet actuel ». Pourquoi donc ? Le blogueur s’explique sur la base de quelques points essentiels :

- Un code ambigu :
Sous CoffeeScript, les parenthèses, les accolades et les virgules sont optionnels, remplacés par des espaces blancs et de l’indentation, toutefois cela amène à certaines situations ambigus, en voici un exemple :
  • Le code suivant ne peut être compilé :

func 5, {

event: (e) ->

if e.something
36
else
45,
val: 10}

Il est nécessaire de supprimer la virgule ou de la placer sur la ligne suivante devant val.

  • A + B revient à additionner A et B, alors que A +B est équivalent à un appel de A avec comme argument +B


- Lisibilité du code :
Sous CoffeeScript, tout est expression logique (une valeur de retour existe), or selon notre blogueur : « Le cerveau humain comprend facilement la logique sous forme de symboles ». Ainsi évalué l’exemple ci-dessous reste complexe (tiré du tutoriel officiel sur les boucles):
foods = ['broccoli', 'spinach', 'chocolate']
eat food for food in foods when food isnt 'chocolate'

  • En premier lieu la déclaration de foods qui est effectuée au milieu de cette expression n’apparait pas clairement comme une déclaration de variable.
  • De plus il n’est pas clair quelle est la valeur retournée à eat.
  • Enfin l’existence d’une condition n’est révélée qu’en dernier lieu.


- L’illusion de l’existence des classes :
Malgré les demandes des développeurs, la notion de classe n’a pas vu le jour sous JavaScript. Sous CoffeeScript le pas a été franchi, mais les classes ne sont qu’une simple émulation du concept, (cela est dû à la règle d’or de CoffeeScript). Cette situation mène à une plus grande confusion pour certains concepts de JS, en particulier le mot clé This qui n’a pas la même signification que sous les langages OO.

Pour finir, il est important de noter que « CoffeeScript a commencé à partir d’une position forte et une bonne approche philosophique vis-à-vis du champ miné qu’est Javascript ». De plus le blogueur signale qu’au quotidien cela diffère : « En réalité, les questions que j'ai soulevées en ce qui concerne CoffeeScript ne se rencontrent pas tous les jours », même si « En fin de compte, elles sont suffisantes pour dire que nous avons besoin de quelque chose de mieux ».

Source : Blog de Jeff Walker
Et vous ?

Qu’en pensez-vous ?

Utilisez-vous CoffeeScript ou bien une autre variante de JS ? Avez-vous rencontrés ces mêmes difficultés ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 02/04/2014 à 1:04
Ce n'est que mon avis, mais je trouve que donner un sens logique à des espaces est une hérésie (en CoffeeScript l'indentation remplace les accolades pour déterminer le scope). Pour la même raison, je n'ai jamais utilisé Jade ou SASS.

Les éditeurs sont incapables d'auto-indenter ce genre de code, puisqu'ils ne peuvent pas deviner à quel scope on souhaite placer une instruction. Et si jamais ils réindentent tout de même le fichier (ce qui est loin d'être rare, surtout dans les équipes où chacun a son propre IDE), le fonctionnel du code peut changer ! Un bogue à cause d'une mauvaise indentation, il fallait l'inventer.
Avatar de Podyaourth Podyaourth - Membre à l'essai https://www.developpez.com
le 02/04/2014 à 9:12
Comme l'a dit mon VDD, donner un sens à l'indentation du code est certainement une mauvaise idée.

Très peu de développeurs, selon moi, sont prêts à faire preuve d'apostasie.

On remarque parfois que l'indentation du code est la "signature" de celui qui l'a écrit.

Le meilleur exemple que j'ai en tête est, qu'à l'époque où je faisais du C++, chaque développeur mettait ses accolades / sauts de ligne où il l'entendait :

Code : Sélectionner tout
1
2
3
4
5
 
if( toto == 1) { 
     toto+=1; } 
else { 
     toto-=1; }
Code : Sélectionner tout
1
2
3
4
5
6
7
 
if( toto == 1) 
{ 
     toto+=1; 
}else { 
     toto-=1; 
}
Je reprend la merveilleuse phrase de mon VDD : "Un bogue à cause d'une mauvaise indentation, il fallait l'inventer."
Avatar de SpaceFrog SpaceFrog - Rédacteur/Modérateur https://www.developpez.com
le 02/04/2014 à 9:27
Javascript un champs miné ?
Je dois avoir de la chance parce que ça fait un bail que je me promène dans ce champs et je n'ai pas encore sauté
Avatar de valkirys valkirys - Membre expérimenté https://www.developpez.com
le 02/04/2014 à 17:06
Citation Envoyé par Arsene Newman  Voir le message
Ainsi évalué l’exemple ci-dessous reste complexe (tiré du tutoriel officiel sur les boucles):
Code : Sélectionner tout
1
2
foods = ['broccoli', 'spinach', 'chocolate'] 
eat food for food in foods when food isnt 'chocolate'
  • En premier lieu la déclaration de foods qui est effectuée au milieu de cette expression n’apparait pas clairement comme une déclaration de variable.
  • De plus il n’est pas clair quelle est la valeur retournée à eat.
  • Enfin l’existence d’une condition n’est révélée qu’en dernier lieu.



Code : Sélectionner tout
1
2
3
# Health conscious meal. 
foods = ['broccoli', 'spinach', 'chocolate'] 
eat food for food in foods when food isnt 'chocolate'
Avec la couleur ça me parait plutôt clair...
Avatar de Enerian Enerian - Membre éclairé https://www.developpez.com
le 02/04/2014 à 17:16
Citation Envoyé par SylvainPV  Voir le message
Ce n'est que mon avis, mais je trouve que donner un sens logique à des espaces est une hérésie (en CoffeeScript l'indentation remplace les accolades pour déterminer le scope). Pour la même raison, je n'ai jamais utilisé Jade ou SASS.

Je suis partiellement d'accord. En python ça passe nickel par exemple, mais ils sont beaucoup plus stricts. Notamment, les lambda ne peuvent pas dépasser une ligne. Et là tout change.

Quand je vois ça :
Code : Sélectionner tout
1
2
3
setTimeout -> 
  doSomethind() 
, 1000
ou ça
Code : Sélectionner tout
1
2
3
4
5
 
myFunc 
  hello: 'world' 
  , -> 
    doSomething()
(équivalent JS pour ceux qui veulent pas chopper une migraine : )
Code JavaScript : Sélectionner tout
1
2
3
4
5
myFunc({ 
  hello: 'world' 
}, function() { 
  return doSomething(); 
});

j'ai envie de vomir (ou presque)...
CF est bien trop permissif et ambigu à mon gout. Ou plutôt il permet de produire trop facilement du code permissif et ambigu.
Après je pense qu'on peut faire un code élégant avec, en établissant des règles et des conventions strictes, mais c'est rarement le cas.

champ miné qu’est JavaScript

Si tous ceux qui utilisent JavaScript prenaient le temps de l'apprendre et de comprendre le pourquoi de ce qu'ils considèrent être des incohérences, ils se rendraient compte que le champs de mines n'est qu'une illusion.
Avatar de ctxnop ctxnop - Membre expérimenté https://www.developpez.com
le 02/04/2014 à 17:34
Citation Envoyé par Enerian  Voir le message
Je suis partiellement d'accord. En python ça passe nickel par exemple

Moi je suis moyennement d'accord avec ça
J'aime bien le fait que l'indentation soit codante dans le principe, parce que ça oblige à indenter et force donc un style d'écriture commun à tout le monde, ce qui augmente la lisibilité in fine.
Mais dans la pratique c'est en réalité trop rigide. On ne peut plus indenter volontairement pour aligner des choses afin de rendre plus lisible.

L'idéal, a mon sens, serait que l'éditeur applique un style à l'ouverture (indentation par tabulation ou espace, accolage en fin de ligne ou sur nouvelle ligne, limite a 80 caractères par ligne, etc...) et qu'on puisse spécifiquement forcer un style sur des bloc précis quand le développeur veut imposer le style pour une question d'alignement (genre un pose un mini diagramme en ascii-art).
Mais ça suppose que tous les éditeurs supportent la fonctionnalité, y compris les logiciels de comparaisons histoire que les fichiers ne soient pas en permanence en différence. Ca impose également que le langage contienne ce qu'il faut pour réellement appliquer un profile (c'est donc foutu pour le python et les langages dont l'indentation est codante).

Bref, les histoires de styles c'est une éternelle question qui ne sera jamais réellement résolue parce que chacun ses gouts et que les gouts et les couleurs ça se discute pas...
Avatar de garheb garheb - Membre averti https://www.developpez.com
le 02/04/2014 à 17:59
Une horreur les morceaux de code qu'il montre en effet.

Le problème avec le JS c'est pas sa syntaxe, elle est très bien, c'est son typage faible et son système de classes trop limité (le fait qu'on ait trois manières de faire des classes, mais aucune n'est aussi bien que n'importe quel langage à succès (c#, java, c++...)).

Le fait d'avoir des espaces/tabulations qui signifient quelque chose me fait penser à Jade, c'est une énorme connerie, qui rend les programmes super chiant à débugger et qui n'apportent rien.
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 02/04/2014 à 18:24
les indentations codantes ne sont pas tellement le problème car sur python les IDE te le disent direct si tu merde
mais sur CoffeeScript le fait que tout est expression ça c'est une connerie pour moi, il y a pas mieux pour avoir du code ilisible
Avatar de mothsART mothsART - Membre régulier https://www.developpez.com
le 02/04/2014 à 19:03
Ayant testé pas mal de langages différents, y'a des choses récurrentes que j'ai du mal à comprendre : les accolades ouvrantes/fermantes.
Python a fait ce pari "de génie" de donner du sens à l'indentation : la courbe d'apprentissage est sans doute un peu plus ardu mais derrière ça veut dire un gain en lisibilité et de maintenance et ça, ça n'a pas de prix.
Dans la plupart des projets un minimum sérieux dans d'autres langages, l'indentation est obligatoire et peux être un frein pour des nouvelles contributions : se faire refuser un pull request pour de l'indentation, c'est balo quand même.

L'histoire des goûts et des couleurs : oui et non...
D'une part : peu de dev choisissent réellement leur langage et par conséquent leur manière de coder (elles sont donc conditionnés et souvent irrationnels).
De plus, il serait bon de prêter attention à des études sérieuses sur le fonctionnement de cerveaux vierges face des usages.
N'importe quel dev c'est contraint à de la gymnastique souvent

La raison de l'ascii art est irrecevable à mon sens : si tu as de l'ascii art, c'est forcément soit dans des commentaires soit dans un fichier statique externe.

Coffeescript est une surcouche d'une part (donc forcément bancal) et assume à moitié ces choix d'autres part. Leur règle d'or d'être du javascript c'est du pur commercial : on préfère être démago plutôt que d'assumer pleinement des choix radicaux tel que l'indentation!
Je dirais que coffeescript/livescript (à moindre mesure Dart) peuvent donner des bonnes idées pour des nouvelles standardisation de l'ECMA ou autre mais reste peu utilisable en prod et voué à disparaître tôt ou tard.
Avatar de mangobango mangobango - Membre actif https://www.developpez.com
le 02/04/2014 à 19:24
Euh... bon la discussion sur l'indentation c'est comme les goûts et les couleurs. Pour ma part je trouve qu'une indentation stricte évite 15 styles de codages différents (si le codeur veut signer son code, il met un commentaire "#Mangobango waz ayre"). Par contre gaffe à ce que l'éditeur indente de manière cohérente (mélange tabulations vs espaces). Mais c'est vrai qu'il y a des couacs avec cette foutue indentation dans Coffeescript. Moi je m'impose de garder les parenthèses pour les appels de fonctions, et pour les lambdas de plusieurs lignes je les emprisonne dans des parenthèses aussi... hop!

Il y a un tantinet de mauvaise foi sur l'exemple des "list comprehensions" qui se lit quasi comme une phrase anglaise (un peu lourde certes). Et avec la coloration syntaxique, ça passe très bien. Les "compréhensions de listes" ne sont pas propres à Coffeescript, Python les a, Haskell aussi, la sytax est souvent très similaire et dérive des "set-builder notations" (http://learnyouahaskell.com/starting-out). Dit autrement, c'est peut-être pas digeste au premier regard, mais on l'apprend une fois pour toutes.

Bon, sinon il parle des avantages? Le modèle objet plus classique? Les supers-pouvoirs du "=>"? Je trouve qu'au final c'est plus facile à suivre que du Javascript, moins de "bruit" visuel et logique.



Daniel
Offres d'emploi IT
Consultant sap finance/controlling H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Expert décisionnel business intelligence H/F
Safran - Ile de France - Évry (91090)
Ingénieur intégration, validation, qualification du système de drone H/F
Safran - Ile de France - Éragny (95610)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil