> mais une relation d'ordre
ok, j'avais zapé ce point...
> en 2 lignes (hors imports et la signature de la fonction
Si je met ma méthode dans un import, mon code tiens en une ligne (hors import et signature de la fonction)...
> En outre, le propos n'était pas tant de débattre sur l'utilité pratique de mon bout de code que de montrer les possibilités d'un système de type fort, statique et puissant.
ha mais je suis totalement d'accord. C'est juste que, ne connaissant pas les langages de ce type, à la lecture du cheminement pour écrire ton morceau de code, j'ai eu l'impression que c'était compliqué pour faire trois fois rien. Et j'ai l'impression que cette complexité vient directement du type de langage d'où le fait de montrer qu'on peut faire plus "simple" (au niveau du raisonnement, de la logique du code) pour arriver à une fonctionnalité assez équivalente.
Maintenant, il y a surement plein de cas où ce serait le contraire je pense... (ok, peut-être qu'il faudra un jour que je prenne le temps de regarder ce genre de paradigme...)
> L'exploitation du compilateur permet 1/ d'éviter des erreurs de programmations qu'on découvre qu'à l'exécution
oui, mais mon avis est que lorsqu'on se repose trop souvent sur un compilateur, on oublie de réaliser les tests soit-même. Et on se retrouve avec une tripoté de "codeurs" qui font : 2 lignes de code, CTRL-S, je regarde la sortie du compilo, je corrige si nécessaire, sinon je passe à la suite.
Le problème est que ces personnes, en se reposant exagérément sur le compilo ne savent finalement plus coder correctement mais seulement réagir face à une erreur à la compile. Et résultat, de part cette faillibilité on se retrouve avec plein de trucs zarb à l'exécution car c'est mal réfléchi et que le compilo ne peut pas tout faire.
[^] # Re: typage mou
Posté par CrEv (site web personnel) . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 3.
ok, j'avais zapé ce point...
> en 2 lignes (hors imports et la signature de la fonction
Si je met ma méthode dans un import, mon code tiens en une ligne (hors import et signature de la fonction)...
> En outre, le propos n'était pas tant de débattre sur l'utilité pratique de mon bout de code que de montrer les possibilités d'un système de type fort, statique et puissant.
ha mais je suis totalement d'accord. C'est juste que, ne connaissant pas les langages de ce type, à la lecture du cheminement pour écrire ton morceau de code, j'ai eu l'impression que c'était compliqué pour faire trois fois rien. Et j'ai l'impression que cette complexité vient directement du type de langage d'où le fait de montrer qu'on peut faire plus "simple" (au niveau du raisonnement, de la logique du code) pour arriver à une fonctionnalité assez équivalente.
Maintenant, il y a surement plein de cas où ce serait le contraire je pense... (ok, peut-être qu'il faudra un jour que je prenne le temps de regarder ce genre de paradigme...)
> L'exploitation du compilateur permet 1/ d'éviter des erreurs de programmations qu'on découvre qu'à l'exécution
oui, mais mon avis est que lorsqu'on se repose trop souvent sur un compilateur, on oublie de réaliser les tests soit-même. Et on se retrouve avec une tripoté de "codeurs" qui font : 2 lignes de code, CTRL-S, je regarde la sortie du compilo, je corrige si nécessaire, sinon je passe à la suite.
Le problème est que ces personnes, en se reposant exagérément sur le compilo ne savent finalement plus coder correctement mais seulement réagir face à une erreur à la compile. Et résultat, de part cette faillibilité on se retrouve avec plein de trucs zarb à l'exécution car c'est mal réfléchi et que le compilo ne peut pas tout faire.