Je savais même pas qu'on avait une carte spécial quand on était sourd

Putain de merde, Coffescript c'est...
Je vais voir ce que vaut node.js aussi du coup.

Xenio > tu peux avoir des cartes pour toutes les afflictions, mais pas forcément officielles.

Les groupes pharmaceutiques en déclinent souvent pour les malades chroniques. Ça coûte rien, c'est moins encombrant que les bracelets similaires et de toutes façon les portefeuilles sont vérifiés par les secours généralement.

Wonderfall > ouai
Sinon t'as Opal, qui permet d'écrire directement du Ruby compilé en Javascript. C'est pas le même intermédiaire mais c'est sympa aussi.

Ah, ben merci je savais pas

"Opal, qui permet d'écrire directement du Ruby compilé en Javascript." - Caletlog

http://opalrb.org/

Seigneur Dieu, je crois que je vais vomir mon goûter...

J'aime pas CoffeeScript, y'a tellement de trucs optionnels pour alléger la syntaxe, certains devs en abusent clairement et ça rend le code illisible (et pour cause, quand j'en ai fait je me sentais presque obligé de supprimer au maximum tout ce qui était optionnel, quitte à pondre un code que j'avais moi-même du mal à lire).

Je pense aux parenthèses optionnelles, on dirait qu'il y a des devs qui veulent à tout prix ne jamais mettre de parenthèses en CoffeeScript, ou le fait que le `return` soit optionnel... des fois tu te retrouve à la fin d'une fonction de 20 lignes avec une valeur posée comme ça. Après réflection, ah oui, c'est la valeur de retour...

Y'a quelques jours je vois cet exemple typique, sauf que la valeur était en plus un objet litéral, en utilisant bien sûr le fait que CoffeeScript rend les accolades optionnelles. Ça ressemblait à ça :

  foo = ->
    # Code de ~20 lignes

    bar: 'baz',
    troll: somvar,
    life: 42

Putain y'a des limites, au début je me dis WTF pourquoi il ma balance du YAML au milieu d'une fonction.

Pourtant y'a des tas de bonnes idées inspirées du Ruby et du Python, et su sucre syntaxique qui fait baver, quand on en abuse pas trop quoi.

Aujourd'hui on peut compiler n'importe quoi vers du JS anyway, comme dit plus haut y'a Opal pour le Ruby, y'a Pyjamas et Pyjs entre autres pour Python, et de façon générale tout ce qui compile vers LLVM peut être exporté en JS.

Roberto > disclaimer : j'ai pas encore essayé, j'ai découvert ça avec la gem Yeah, qui s'en sert pour faire des jeux JS à partir de Ruby (et qui, pour le coup, marche plutôt bien).

Le code généré par Opal me semble un peu étrange, faudra que je vois ce que ça vaut réellement.

vava > ouai, y'a des trucs abusés. Le coup des parenthèses optionnelles ça vient du Ruby, et j'ai jamais compris l'intérêt. Okay, dans des DSL genre Rails c'est sympathique parfois, mais dans du code pur
La valeur de retour par défaut par contre c'est excellent. Ayant commencé par le Ruby, j'ai été étonné de voir que très peu de langages implémentent ce genre de système.

vava740 En même temps qui veut faire du JS ?

JamyGourmand:
Comment tu fais pour accéder à ton bios avec notre carte mère buguée?
Parce que même en me branchant en VGA ça passe pas ...

Dark_Chouhartem > Pour le coup je trouve que faire du JS natif (ou avec de simples préprocesseurs comme CoffeeScript) est plus raisonnable. Écrire du JS avec du Ruby/Python/Clojure/C++/Foo ça implique de savoir parfaitement ce que fait le compilateur à tout moment, et y'a pas mal de 'cool tricks' qu'on doit réinventer parfois difficilement dans le langage proxy.
Enfin ça reste pratique, mais j'ai du mal à donner toute ma confiance à ces outils (ou plutôt, confiance en ma capacité à utiliser ces outils sans faute). Surtout que généralement, quand le projet est de taille conséquente, on vérifie pas rigoureusement tout le code généré...

@Caletlog Je te donne l'exemple précis qui m'a dérangé : https://github.com/welldan97/assemble-jade/blob/ae0d7211f2256b2f4e650c086cab449a2370b7a7/src/assemble-jade.coffee#L44-L48

Je suis désolé mais quand la fonction fait plus de 3 lignes (et encore, je dirais presque une ligne), ne pas mettre le `return` nuit pas mal à la compréhension du code, du moins ça oblige à réfléchir, voir remonter l'indentation pour voir qu'on est à la fin d'une fonction.

Et puis dans le même code :

init = ->

Juste ça. Pour définir une fonction vide. Mais on le voit pas au premier coup d'oeil, faut vérifier l'indentation des lignes suivantes d'abord. En Python on aurait au moins eu un `pass` qui dit clairement que la fonction ne fait rien, et ça aide beaucoup à comprendre.

@Dark_Chouhartem Je suis d'accord avec Caletlog, faut quand même avoir une certaine confiance dans le compilateur pour commencer à compiler n'importe quoi vers du JS. Même si on a pour la plupart pas envie de faire du JS natif, c'est souvent la solution la plus sérieuse pour avoir un minimum de contrôle sur son code. Pas de mauvaises surprises sur les "hacks" utilisés pour émuler certines fonctionnalités. Par contre, pas de bonnes surprises sur certaines optimisations que peut faire le compilateur non plus.

Ah ouais il se passe quoi? T'as bien qu'un seul écran vga de branché?

Si tu peux accéder à q flash essaye de mettre à jour le firmware

Y'a un sourd ici ?

Je vais voir de le mettre à jour

J'ai essayé de pleins de manières différentes, avec un seul écran à chaque fois oui
J'ai même enlever la CG

Et quand je vais sur le bios j'ai en haut marqué un truc du style 'gigabyte uefi dual bios', mais rien d'autre, je peux rien faire à part reboot

Eviklovesyou il ne me semble pas, mais pourquoi cette question ?

vava > ah oui je vois. Dans ce cas-là, c'est effectivement stupide. Les simples accolades de l'objet auraient rendu le tout beaucoup plus clair. Et dans ces cas-là, je pense pas qu'on ait besoin d'un return : à partir du moment où on sait que la dernière expression évaluée est renvoyée, c'est plutôt naturel (sauf dans ton cas, mais c'est clairement un abus sur la souplesse des hashes/objets, pas sur le return. Je pense d'ailleurs pas que le return eut été possible en cumul de l'objet sans accolades, mais pas sûr).
Enfin en soit le return est pas particulièrement chiant à mettre, mais je trouve que son absence répond à un 'problème' assez logique : pourquoi considérer par défaut qu'une fonction ne renvoie rien (donc 100% effets de bord), et le renvoi de quelque chose considéré comme un cas spécial (puisqu'on doit utiliser explicitement un return), alors qu'en pratique, les propensions à utiliser ces cas sont inversées ?
Avec le renvoi auto de la dernière expression évaluée, on a la situation inverse, plus 'proche' de la réalité : on renvoie par défaut toujours quelque chose, et il faut spécifier explicitement si on ne veut rien renvoyer.
+ ça encourage à faire des méthodes compatibles avec le chaînage, mais ça c'est encore autre chose

Pour les fonctions vides, c'est comme de partout : mieux vaut mettre un commentaire sur la même ligne ou dans un bloc vide pour dire qu'on est conscient qu'elle est vide, et que c'est pas une erreur. C'est toujours plus lisible.

JamyGourmand :
J'arrive à accéder à un menu (via la touche Fin), mais je peux rien faire là
Reboot obligé

Je testerai ça plus tard sans CG/avec un autre écran

@Caletlog

« Enfin en soit le return est pas particulièrement chiant à mettre, mais je trouve que son absence répond à un 'problème' assez logique : pourquoi considérer par défaut qu'une fonction ne renvoie rien (donc 100% effets de bord), et le renvoi de quelque chose considéré comme un cas spécial »

J'avais jamais vu les choses sous cet angle, c'est vrai que ça a l'air assez logique comme ça.

Reste le fait que quasiment personne ne met un `return` vide quand il ne veut rien retourner.

Mais bon, la plupart du temps ça ne pose pas de problème.

vava740 & Caletlog Mais ça fait peur le js