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

C'est la syntaxe qui en premier défini un langage donc si des points sur la syntaxes sont important.

let x = if condition {
        toto();
        42
    } else {
        0
    }

C'est juste immonde et le meilleur moyen de provoquer la fainéantise des gens qui utilise ce genre de fonctionnalité, jusqu'au jour ou le code ne sera plus lisible/maintenable.
Non sérieusement c'est juste immonde.

Forcer l'utilisation du mot clef "return" permet de n'avoir AUCUNE ambiguïté.

Pour -> c'est une source d'erreur dans pas mal de langage de donner le type de retour apres le nom de la fonction. Mais si tu y tiens, je prefere marquer explicitement "return XX".

Le C n'a que des conversion "implicite" quand il s'agit de nombre, et encore pas dans tous les cas, si tu fait
struct X a; struct Y b; b = a;
tu va te manger une erreur de compilation.

Les seul cas direct et legaux en C sont conversion de nombres vers un ensemble plus grand.
L'infering n'est pas du typage fort, vu que tu n'indique pas le type, il est "devine" par le compilateur.

Et oui en 2016 utiliser des raccourcis pour des mots cours pour un nouveau language je trouve ca absolument debile.
Ce n'est pas des mots comme anticonstitutionnellement, ou autre mot a ralonge.

function a le mérite d’être clair, fn est court et peu visible.

edit: (et personnellement taper -> en C me fait vraiment chier, je prefere taper des lettres que des caractères spéciaux, d'ailleurs le claviers sont fait pour taper du texte et pas la ponctuation, enfin hors ponctuation courante. je passe plus de temps a taper "->" que "return")

Pour les noms courts, bah c la flsfi unx. Et mut est sans doûte l'abbréviation de "mutable", pas de "mutated". Une variable qui peut être "mutated" est "mutable".

Godzil (./2341) :
C'est juste immonde et le meilleur moyen de provoquer la fainéantise des gens qui utilise ce genre de fonctionnalité, jusqu'au jour ou le code ne sera plus lisible/maintenable.
Non sérieusement c'est juste immonde.Forcer l'utilisation du mot clef "return" permet de n'avoir AUCUNE ambiguïté.

J'avait justement pris cet exemple pour montrer un cas qui n'a rien a voir avec le return. L'équivalent C serait une expression ternaire, ce qui serait juste complètement immonde.
Ceci dit je ne dis pas qu'il faut absolument l'utiliser comme ça. C'était juste un exemple pour montrer que le fait que chaque bloc peut retourner une valeur va bien au delà du simple remplacement du return.

Godzil (./2341) :
Pour -> c'est une source d'erreur dans pas mal de langage de donner le type de retour après le nom de la fonction.

J'aimerais que tu explique ça parce que j'ai du mal a voir comment ça peut poser problème.

Godzil (./2341) :
Le C n'a que des conversion "implicite" quand il s'agit de nombre, et encore pas dans tous les cas

Ce qui m'a quand même posé problème assez souvent, alors que l'inférence à la Rust, jamais pour le moment.

Godzil (./2341) :
L'infering n'est pas du typage fort, vu que tu n'indique pas le type, il est "devine" par le compilateur.

En C on se retrouve trop vite obligé d'utiliser du void*, j'ai du mal a trouver que c'est un typage fort.
En Rust, le typage est quand même déterminé à la compilation et le fait que tous les composants des types et toutes les fonctions soient typés fait qu'il n'y a pas de cascade surprenante. Les valeurs finissent rapidement par être utilisées dans des fonctions ou des structures qui forcent leur type.

Godzil (./2341) :
En 2016 utiliser des raccourcis pour des mots cours pour un nouveau language je trouve ca absolument debile.

En 2016 on est aussi capable de colorer de manière plus visible les mot clés. De plus comme "fn" est en début de ligne, franchement, il ne manque pas de visibilité.
Personnellement que ça soit long ou court me laisse assez indifférent, mais je trouve bizarre que la facilité de saisie te pose un problème pour la flèche et pas pour ça.

Godzil (./2341) :
edit: (et personnellement taper -> en C me fait vraiment chier, je préfère taper des lettres que des caractères spéciaux, d'ailleurs le claviers sont fait pour taper du texte et pas la ponctuation, enfin hors ponctuation courante. je passe plus de temps a taper "->" que "return")

En même temps je pense qu'au total, on doit taper à peu près autant de -> en C qu'en Rust, et probablement plus en C++.

Kevin Kofler (./2342) :
Pour les noms courts, bah c la flsfi unx. Et mut est sans doûte l'abbréviation de "mutable", pas de "mutated". Une variable qui peut être "mutated" est "mutable".

En effet mut veut dire mutable.

Godzil (./2341) :
edit: (et personnellement taper -> en C me fait vraiment chier, je prefere taper des lettres que des caractères spéciaux, d'ailleurs le claviers sont fait pour taper du texte et pas la ponctuation, enfin hors ponctuation courante. je passe plus de temps a taper "->" que "return")

Pour le C/C++, utilise KDevelop, tu peux taper . et il te le remplace automatiquement par -> si c'est un pointeur.

Ou comment transformer un programmeur en fainéant.

C'est pas plus simple de créer un langage cohérent et frugal ?

Je rejoins Uther sur un point : Godzil je ne comprends pas trop ce que tu cherches dans cette discussion, mais comme - je trouve - trop souvent tu avances des assertions sans donner d'argument et de façon bien trop agressive. Cracher sur une technologie que tu n'aimes pas ou ne connais pas, écrire EN MAJUSCULE et mélanger argument et opinion ne rend pas tes messages plus crédibles, en plus de donner un mauvais ton à la discussion.

Pour essayer de revenir dans du plus factuel maintenant :

- Je ne sais pas trop ce que signifie "typage fort" pour toi, le terme me semble assez vague. S'il signifie "langage capable de repérer les erreurs de type à l'exécution", c'est un critère bien trop lâche, même PHP possède un typage fort dans une certaine mesure selon cette définition. Je pense que tu veux plutôt parler de typage statique, et dans ce cas Rust possède effectivement un typage statique encore plus strict que C/C++ en interdisant au maximum des choses comme void* qui permettent de s'échapper totalement de notion de type aussi bien à la compilation qu'à l'exécution (avec les risques que ça implique). L'inférence est une notion presque orthogonale ici, puisqu'elle ne change rien au fait que le langage soit statiquement typé : il ne s'agit que de savoir si le langage est capable de deviner les types en fonction du contexte ou si tu dois les écrire explicitement, mais le résultat est le même. Sur ce point tu peux comparer Rust à Scala, qui un typage statique avec inférence comparable (et assez agréable à l'utilisation, après un petit temps d'adaptation).

- La discussion sur les mots courts ou longs me semble arbitraire. Pourquoi ne faudrait-il pas raccourcir le mot "function" en "fn" ou "mutable" en "mut", alors qu'on autorise carrément des caractères uniques pour d'autres constructions syntaxiques comme la définition de blocs de code avec "{" et "}" ? On pourrait considérer que c'est illisible aussi, qu'il ne faudrait rien raccourcir et revenir à Pascal avec des blocs qui commencent par "begin" et finissent par "end". D'autres langages poussent à l'inverse un peu plus loin et préfèrent réserver davantage de caractères spéciaux pour éviter au maximum les mots-clé, comme par exemple les lambdas en JavaScript, C# ou C++ qui proposent des syntaxes avec des parenthèses, crochets et "->" (je fais exprès de prendre trois langages bien différents pour bien montrer que ça n'a aucun rapport avec des notions de typage ou de compilation). Bref, Rust a fait ici un choix qui se justifie plutôt bien il me semble, le seul excès sur lequel j'ai l'impression que tout le monde finit par tomber d'accord porte sur les langages qui poussent la surcharge d'opérateurs trop loin comme C++ ou Scala. J'ai du mal à comprendre comment on peut considérer universellement que choisir fn ou mut comme mot-clé est un "mauvais choix" ? Le seul argument que je retiens ici est "caractères ASCII vs caractères non-ASCII", qui effectivement mérite d'être discuté.

Avant de répondre : respire un coup, désactive ta touche caps-lock, accepte le fait que d'autres gens sur ce forum peuvent avoir un avis différent du tiens sans pour autant être des abrutis complets, je suis sûr que la discussion ne pourra qu'en bénéficier.

(pour moi, le typage fort est quand tu ne peux pas additionner des choux et des carottes ; le meilleur exemple est le Caml — tu ne peux pas additionner des flottants et des entiers — et le pire est le JS)

OK, ça montre bien que le terme est pas forcément compris pareil par tout le monde

Je ne sais pas s'il y a un nom bien défini pour ce que tu décris, moi j'aurais tendance à appeler ça "conversion implicite". Un langage typé avec des conversions implicites pourra accepter d'additionner des entiers et des flottants en convertissant l'un d'eux automatiquement, tandis qu'un langage typé sans conversion implicite détectera une erreur. Pour le JS c'est un cas encore différent puisqu'il n'y a pas de notion de type du tout (pas même dynamique), donc pas de notion de conversion non plus : une addition est une opération qui prend deux variables en paramètre.

(pour moi, type age fort, c'est un ancien ninja, 60ans passé, qui est très fort, tu vois le type ?)

Zeph (./2348) :
OK, ça montre bien que le terme est pas forcément compris pareil par tout le monde
Je ne sais pas s'il y a un nom bien défini pour ce que tu décris, moi j'aurais tendance à appeler ça "conversion implicite".

Ce n'est pas incompatible : plus le typage est faible, plus il y a de conversions implicites possibles ^^

( )

Il y a plusieurs types de "typage fort":

• typage strict: absence de conversions implicites. Il y a plusieurs niveaux là: style VB, JS ou PHP où il y a même des conversions implicites entre chaînes de caractères et nombres; style C où ce n'est qu'entre nombres; style Pascal où il faut déjà une conversion explicite entre entiers et flottants; style Ada où tout doit être explicitement converti.
• typage statique: assignation d'un type fixe à une variable à l'avance, généralement lors de la compilation. Là aussi, il y a un niveau intermédiaire entre le typage statique totalement type-safe et le typage entièrement dynamique: un typage statique où tu as des types génériques non-type-safe, du moins à la compilation (void* en C, les divers types variant (par exemple QVariant en C++/Qt, le Variant de VB etc.), Object en Java, …). Certains sont totalement unsafe (aucune vérification, par exemple void*), d'autres ont au moins un typage dynamique type-safe (variants, Object de Java). Rares sont les langages où il n'y a vraiment que des types statiques, parce qu'il y a des cas où ce n'est vraiment pas pratique.
• typage explicite: absence d'inférence. Le problème de l'inférence est que tu ne contrôles pas directement le type assigné et qu'il n'est pas forcément celui que tu attends, ce qui peut être source d'erreurs. Donc il y a des erreurs que le typage statique explicite reconnaîtrait que le typage statique implicite par inférence laisse passer, en assignant silencieusement le "mauvais" type.

Un typage totalement "faible" n'existe pas parce qu'il faut faire un compromis entre typage laxiste (non-strict) et typage implicite (inférence), parce que tu ne peux pas convertir implicitement si tu ne sais pas en quoi convertir, tu dois forcément soit mettre une conversion explicite pour faire marcher l'inférence, soit déclarer un type explicite pour faire marcher la conversion automatique. Un typage totalement "fort" serait possible en principe, mais en pratique tu trouveras toujours des compromis.

[EDIT: orthographe]

Les langages modernes qui proposent de l'inférence de type proposent souvent aussi des mécanismes pour spécifier explicitement le type, par exemple dans le cas d'expressions complexes ou si le type ne peut pas être deviné par le lecteur. Par exemple en Scala :val a = 3; // Pas besoin de spécifier le type, il est évident val b = machin(); // Type non spécifié, mais impossible de le deviner sans aller voir la définition de "machin" val c : Double = machin(); // Type spécifié explicitement pour faciliter la lectureJe trouve que c'est un bon compromis pour éviter de devoir mettre des types partout quand on voit des constantes numériques ou des chaines de caractère faciles à reconnaître, tout en laissant la possibilité de montrer (et vérifier) les types dans des cas plus complexes.

Kevin: l'exemple pour ton dernier paragraphe il existe, c'est javascript non?

Zeph (./2354) :
Les langages modernes qui proposent de l'inférence de type proposent souvent aussi des mécanismes pour spécifier explicitement le type, par exemple dans le cas d'expressions complexes ou si le type ne peut pas être deviné par le lecteur. Par exemple en Scala :val a = 3; // Pas besoin de spécifier le type, il est évident val b = machin(); // Type non spécifié, mais impossible de le deviner sans aller voir la définition de "machin" val c : Double = machin(); // Type spécifié explicitement pour faciliter la lectureJe trouve que c'est un bon compromis pour éviter de devoir mettre des types partout quand on voit des constantes numériques ou des chaines de caractère faciles à reconnaître, tout en laissant la possibilité de montrer (et vérifier) les types dans des cas plus complexes.

L'autre intérêt que je vois est pour le IDE : si l'IDE n'a aucune idée du type des arguments, l'auto-complétion ne risque pas de fonctionner :/

Le IDE avancés sont généralement capable de connaître le type réel d'un variable déclarée implicitement pour les langages qui sont statiquement typé.

Uther (./2357) :
Les IDE avancés sont généralement capable de connaître le type réel d'un variable déclarée implicitement pour les langages qui sont statiquement typé.

Oui, s'ils ont des indications. Si l'IDE n'a que le prototype de la fonction (sans indication de type), je ne vois pas trop comment il peut déterminer le type des variables (sauf peut-être en se basant le nom, en supposant par défaut que deux variables ayant le même nom ont le même type).

C'est un argument que j'ai beaucoup entendu à propos de Scala justement, quand je râlais parce que les développeurs mettent trop peu de types explicites dans leurs code. On m'a beaucoup répondu "oui mais dans IntelliJ il suffit de faire <insérez ici votre raccourci clavier> pour voir le type". C'est vrai, mais ça veut dire que si j'utilise n'importe quel autre outil moins avancé je n'ai plus accès à cette information. Par exemple au boulot je passe au moins autant de temps à lire du code via Gerrit qu'à en écrire, et dans l'interface de Gerrit il n'y a rien qui peut m'aider à connaître le type d'une expression alambiquée.

flanker (./2358) :
Oui, s'ils ont des indications. Si l'IDE n'a que le prototype de la fonction (sans indication de type), je ne vois pas trop comment il peut déterminer le type des variables (sauf peut-être en se basant le nom, en supposant par défaut que deux variables ayant le même nom ont le même type).

En effet, mais pour le cas de Rust seules les déclaration de variables et les paramètres des lambda sont typés implicitement. C'est pour ça que j’apprécie le langage même si je n'était pas du tout fan du typage implicite à la base.

Zeph> Je suis d'accord que trop compter sur l'IDE n'est pas une bonne chose. C'est pourquoi je trouve le choix de Rust bien équilibré : de l'implicite mais pas partout au point ou on ne sait plus avec quel type on travaille.

Zeph (./2359) :
"oui mais dans IntelliJ il suffit de faire <insérez ici votre raccourci clavier> pour voir le type".

C'est tout de même moins pratique de devoir faire une action (surtout quand le code vu est déjà dans une fenêtre d'aperçu) :/

C'est vrai, mais ça veut dire que si j'utilise n'importe quel autre outil moins avancé je n'ai plus accès à cette information. Par exemple au boulot je passe au moins autant de temps à lire du code via Gerrit qu'à en écrire, et dans l'interface de Gerrit il n'y a rien qui peut m'aider à connaître le type d'une expression alambiquée.

Suffit d'améliorer Gerrit

squalyl (./2355) :
Kevin: l'exemple pour ton dernier paragraphe il existe, c'est javascript non?

JavaScript utilise en théorie un typage totalement dynamique, donc l'inférence ne s'applique pas. Cela dit, les bons JITs font de l'inférence pour pouvoir typer statiquement toutes les variables où c'est possible, parce que c'est beaucoup plus rapide que de devoir passer par un type générique tout le temps.

Tcl sinon.

Intéressant :
http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

Oula, c'est très extrémiste, ça. Enfin, le niveau d'extrémisme est très varié, la règle 23 est essentiellement du simple bon sens, mais par exemple la règle 11 (goto et setjmp-longjmp interdits) ou la règle 22 (#undef interdit) sont très restrictives.

Et il n'y a même pas les 2 niveaux de conformité les plus élevés (standard MISRA-C).

On s'en branle, ils arrivent quand même à envoyer des sondes dans l'espace sans trop de problème.

Et puis une remarque sur l’extrémisme du JPL, venant de ta part, fdg quoi...

Même remarque que plus haut sur l'agressivité... C'est dingue, vous n'arrivez vraiment pas à avoir une discussion sans vous insulter ? Détendez-vous, sortez courir, je ne sais pas mais arrêtez de pourrir ce forum en permanence ça devient pénible à la longue !

, c'est vraiment PÉNIBLE!!
#loin#

C'est fou comme parfois, je vais chercher le crash bug dans une fonction complexe, alors qu'il était dans la partie facile du code. Dans la partie que c'était pas la peine de vérifier tellement elle était évidente...

C'est toujours comme ça, Murphy oblige