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

Meowcate (./2190) :

Zerosquare (./2187) :
c'est vrai que ne pas différencier les deux, ça a tellement bien marché pour [par exemple] PHP...

D'où tu te moques ? c'est très bien ainsi, il n'y a pas de problème avec PHP, tout a été géré de main de maître.

Je confirme

flanker (./2189) :
(et sinon, j'imagine que ton pote n'a pas trouvé une façon encore plus inefficace de développer ?)

Franchement, "pote" n'est pas le bon mot, on n'a fait que travailler ensemble sur un truc qu'on voulait voir tous les deux (une version mise à jour de livecd-creator, parce que le remplacement officiel livemedia-creator a plusieurs défauts), et c'est la première fois que j'ai travaillé avec lui en plus. Cela dit, on va peut-être le devenir, étant donné qu'il s'intéresse à plusieurs projets auxquels je m'intéresse aussi (par exemple dnfdragora).

Sinon, pour le Python, franchement, je trouve que le langage est mal fait depuis le début: Déjà parce qu'il est interprété et dynamiquement typé, ce qui fait que pas mal d'erreurs qui seraient immédiatement relevées par le compilateur en C++ ne peuvent être détectés qu'en testant. (Toutes ces histoires de bytestring vs. unicode auraient donné des erreurs de compilation dans un langage compilé type-safe.) Et ensuite parce que la syntaxe sensible à l'indentation est imbitable. (La syntaxe C est devenu le standard de facto, cf. C++, Objective C, Java, JavaScript, C#, même Perl dans une certaine mesure. Python a décidé de faire à sa façon pourrie à la place. )

[EDIT: orthographe/conjugaison]

Tu as déjà codé et GFA Basic ? Il dérive du Pascal, tu peux alors aussi dire que le Pascal "a décidé de faire à sa façon pourrie à la place".

Kevin Kofler (./2195) :
Sinon, pour le Python, franchement, je trouve que le langage est mal fait depuis le début: Déjà parce qu'il est interprété et dynamiquement typé, ce qui fait que pas mal d'erreurs qui seraient immédiatement relevées par le compilateur en C++ ne peuvent être détectés qu'en testant.

Tu as aussi le droit d'utiliser des outils efficaces, ça aide pas mal pour travailler. C'est vraiment très rare que j'ai des erreurs de type, vu qu'elles me sont signalées à l'écriture (avant la compilation ou le test, donc)

(Toutes ces histoires de bytestring vs. unicode auraient donné des erreurs de compilation dans un langage compilé type-safe.)

Tu préfères le Python 2 qui mélange les deux, et maintenant tu regrettes le mélange… faudrait se décider.
Avec Python 3, je n'ai aucun souci de ce genre.

Et ensuite parce que la syntaxe sensible à l'indentation est imbitable.

Oui, ça force à avoir du code propre, je comprends que tu n'aimes pas

(La syntaxe C est devenu le standard de facto, cf. C++, Objective C, Java, JavaScript, C#, même Perl dans une certaine mesure. Python a décidé de faire à sa façon pourrie à la place. )

Oui, tous les langages qui se sont inspirés de C ont une syntaxe qui lui ressemble. Mézencore ?

flanker (./2197) :

(Toutes ces histoires de bytestring vs. unicode auraient donné des erreurs de compilation dans un langage compilé type-safe.)

Tu préfères le Python 2 qui mélange les deux, et maintenant tu regrettes le mélange… faudrait se décider.

Je veux soit une erreur de compilation, soit une conversion automatique, mais absolument pas une erreur de conversion en temps d'exécution.

Avec Python 3, je n'ai aucun souci de ce genre.

C'est avec Python 3 que j'ai eu ces soucis, sur un code qui marchait très bien en Python 2.

Oui, tous les langages qui se sont inspirés de C ont une syntaxe qui lui ressemble. Mézencore ?

Reformulons alors: pourquoi Python ne s'est-il pas inspiré du C comme les autres?

(et (pourquoi pas))

" oui " " en " cat
" effet " cat
" pourquoi " cat
" forcement " cat
" inspiré " cat
" du " cat
" C " cat
" ? " cat disp

./2185 : wha, il est quand même sacrément mauvais l'article d'origine, fallait être motivé ne serait-ce que pour passer du temps à le démonter

(et je me demande si ça ne lui donne pas plus de visibilité que ce qu'il aurait naturellement eu sinon)

Kevin Kofler (./2198) :

flanker (./2197) :

(Toutes ces histoires de bytestring vs. unicode auraient donné des erreurs de compilation dans un langage compilé type-safe.)

Tu préfères le Python 2 qui mélange les deux, et maintenant tu regrettes le mélange… faudrait se décider.

Je veux soit une erreur de compilation, soit une conversion automatique, mais absolument pas une erreur de conversion en temps d'exécution.

Mais oui, on sait que tu n'aimes que les langages compilés et comme tout le monde devrait avoir uniquement les mêmes besoins et envies que toi, les langages interprétés ne devraient pas exister
Il faudra que tu admettes un jour que tout le monde n'a ni les mêmes goûts, ni les mêmes besoins que toi.

Quant à la conversion automatique, elle est impossible à cause de Python 2, pas à cause de Python 3.

Avec Python 3, je n'ai aucun souci de ce genre.

C'est avec Python 3 que j'ai eu ces soucis, sur un code qui marchait très bien en Python 2.

Et as-tu essayé en injectant des caractères non-ASCII un peu partout ? C'est là le problème du Python 2 : les bugs arrivent quand un utilisateur met du non-ASCII alors que le développeur n'a testé qu'en ASCII.

Reformulons alors: pourquoi Python ne s'est-il pas inspiré du C comme les autres?

euh… parce que ? Depuis quand tous les langages devraient être inspirés du C ?

En plus, on peut tout à fait dire que les accolades en C sont superflues, vu tout le monde indente son code en plus d'avoir les accolades. Pourquoi ne pas se simplifier la vie et supprimer ces accolades inutiles ?
L'indentation permet d'avoir un code beaucoup plus lisible et plus court à écrire.

Décidément, faut que je fasse un préproc qui remette des accolades au C, avec une indentation Python

Il faudrait faire l'inverse, un préprocesseur Python+accolades+points-virgule → Python qui retire les accolades et points-virgules et qui indente et rajoute les \ avant les sauts de ligne où il faut automatiquement.

Quel intérêt ?

Lui faire plaisir

flanker (./2205) :
Quel intérêt ?

Permettre d'utiliser sérieusement le Python.

mais lol

Je pense qu'on devrait utiliser des accolades en capitales, car ça permettrait d'éliminer les injustices entre les langages.

Tout à fait, même que d'ailleurs il faut prendre des accolades de tout bord, police, taille, couleur, genre parce qu'il faut être équitable!

lol

Mon framework utilise des conventions de nommage jouant sur les singulier/pluriel des mots. L'anglais ayant quelques irrégularités, une classe contient toutes les règles nécessaires pour que le framework sache comment fonctionne le singulier/pluriel d'un terme choisi par le développeur.
À avoir vérifié la source de cette classe, je me demande encore quel codeur a cru bon de préciser que "pokemon" était apparemment invariable.

Ah oui tiens, j'ai touché pour la première fois à un site en CakePHP y'a pas longtemps pour un pote, je crois que c'est de loin le pire framework web que j'ai vu. Tout est basé sur des conventions de nommage avec plein d'horreurs comme ces règles singulier/pluriel que tu cites, tout ça pour gratter 3 lignes de code et éviter d'injecter explicitement ses dépendances #gerbe#

NoobsPHP, quoi.

C'est super commun. C'est une des bases même pourquoi j'aime pas golang par exemple.

Je vais dire alors que c'est parce que tu n'as pas l'habitude
Cela m'économise pas mal de configuration à mettre en place, l'ORM fonctionne ainsi simplement, et c'est à la base du fonctionnement en ligne de commandes (pour une bdd conçue avec les conventions de nommage, tout le projet peut être scaffoldé sans intervention utilisateur en deux lignes, pouf pouf).
Note cependant que ces conventions servent simplement à accélérer ta productivité en évitant d'avoir à écrire la config. Quand tu ne peux/veux pas suivre une convention, tu peux écrire la configuration sans soucis.

Tron (./2214) :
NoobsPHP, quoi.

PHP, pas vraiment. CakePHP a été construit sur le modèle de Ruby On Rail.

scaffoldé ?

Le scaffolding a été créé par Ruby On Rail. En gros, à partir d'une base de données qui suit des conventions de nommage, un script doit être capable de générer le code source d'un squelette type de ton application (les models sont créés à partir des tables et liaisons de la base de données, les controllers génèrent des méthodes de base view/list/edit/delete, et des views sont générées pour chacune de ces méthodes). Ça ne crée pas le site tout seul, mais c'est une base idéale pour commencer plutôt que de partir de zéro pour des prototypes répétitifs à écrire.
Même les tests unitaires peuvent être (en partie) automatisés, en se basant par exemple sur le type ou la limitation de taille des champs de la base de données. C'est assez populaire dans les frameworks web.

Meowcate (./2218) :
Le scaffolding a été créé par Ruby On Rail. En gros, à partir d'une base de données qui suit des conventions de nommage, un script doit être capable de générer le code source d'un squelette type de ton application (les models sont créés à partir des tables et liaisons de la base de données, les controllers génèrent des méthodes de base view/list/edit/delete, et des views sont générées pour chacune de ces méthodes). Ça ne crée pas le site tout seul, mais c'est une base idéale pour commencer plutôt que de partir de zéro pour des prototypes répétitifs à écrire.Même les tests unitaires peuvent être (en partie) automatisés, en se basant par exemple sur le type ou la limitation de taille des champs de la base de données. C'est assez populaire dans les frameworks web.

Ça me semble tout de même assez moche comme façon de faire :/
Du coup, tu dois manipuler deux langages (SQL ou tout autre moyen de description de la BDD et Ruby).
Ensuite, comment fais-tu quand le modèle évolue ? Des patchs SQL ? Et il faut répliquer les modifs SQL vers le code Ruby ? ^2

Je trouve qu'il est beaucoup mieux de générer le code SQL à partir du code Ruby. Comme ça, tu n'as jamais à manipuler du SQL (même s'il faut connaître le fonctionnement quand tu fais des vraies requêtes, tu n'as pas à retenir la syntaxe), et tu as les migrations d'une version à l'autre de ton modèle de données qui sont gratuites.

Garde en tête que le scaffolding n'est PAS un code final, ni même intermédiaire. Il s'est qu'une base à retravailler.
Par exemple, mon framework est bien plus efficace si j'indique dans le code quelle table est liée à quelle table, quel type de lien (A appartient à B, B possède plusieurs C...), quelles sont les clés étrangères, certains champs ont-ils des limitations (par ex un champ varchar(45) doit avoir une règle de validation des données vérifiant qu'une insertion ne dépasse pas 45 caractères).
Les conventions suivies règlent une partie de ces contraintes, le scaffolding génère du code pour gérer l'autre partie. Sur une base d'une vingtaine de tables, je devrais écrire une vingtaine de modèles pour gérer ces différentes configurations. Le scaffolding s'en occupe pour moi.
Je parle bien sûr du code répétitif, pas de ce que le script ne peut deviner (même s'il peut en deviner certaines. Par ex un champ "email" recevra une règle vérifiant à l'insertion que la donnée est une adresse email valable).

En fait, je crois qu'il y a un soucis de compréhension entre ceux qui ne sont pas partisans de ce concept et ceux qui l'utilisent quotidiennement. Un peu comme je vous expliquerais en tant que bûcheron qu'utiliser une tronçonneuse est bien plus rapide, que la coupe est plus nette, et qu'on me répond que c'est plus dangereux, qu'il faut y mettre de l'essence...

flanker (./2219) :
Je trouve qu'il est beaucoup mieux de générer le code SQL à partir du code Ruby.

Je ne suis pas sûr de saisir ce que tu veux dire. Je n'écris jamais du code SQL pur dans le code. Par ex, tu devrais pouvoir comprendre cette requête CakePHP :$commandes = $this->Commandes->find() ->where(['Commandes.user_id' => $userId, 'Commandes.exported' => 0]) ->contain([ 'Users' => ['Groupes'], 'Clients' => ['Groupes'], 'CommandeTypes' ]) ->order(['Commandes.actif' => 'ASC']) ->all(); // ou $types = $this->Commandes->CommandeTypes->find('list', [ 'keyField' => 'id', 'valueField' => 'type' ])->toArray();Pour autant, il est certain que pour écrire cette requête, il faut savoir ce qu'on veut faire en SQL.