Un point de vue intéressant sur l'OLP - page 2

 
Mikhail Mishanin:

Quelle réaction destructive au sujet et une discussion destructive. Dites-moi, en tant qu'adepte de la programmation procédurale, comment éviter la "spaghettisation" dans la POO, comment analyser et si cela a du sens d'utiliser les "spaghettis" de quelqu'un d'autre ?

Après tout, il s'avère que la POO est surtout destinée à la lisibilité et à la programmation en équipe, c'est-à-dire aux grands projets. Un conseiller expert qui négocie un symbole à son graphique avec le contrôle du risque maximum du solde / fonds dans le compte, bien, ne peut pas être appelé un grand projet - il est suffisant et plus rentable dans la mémoire / vitesse - programmation procédurale.

Questions :

- inconvénients/avantages de la POO (comme impératif) à partir d'une expérience personnelle

- les inconvénients/avantages de la FP (comme déclaratif) à partir d'une expérience personnelle.

Et un avis sur les perspectives est bien sûr intéressant, surtout dans la direction du calcul parallèle. Je ne vois pas l'intérêt d'aborder le sujet des quantum.

J'ai besoin de voir d'où ça vient, je ne comprends pas du tout ce qu'est le spargeting.

Une bonne caractéristique de tout code est d'avoir des fonctions aussi courtes que possible. Vous feriez mieux d'en avoir plus.

Par exemple, la moitié des propriétés de la POO sont des choses que nous voudrions séparer pour la facilité d'utilisation - par exemple, séparer un certain nombre de fonctions dans un groupe et leur donner leurs propres variables qui vivraient dans leur espace de nom).

Puisque nous travaillons avec un type de stockage "classe", nous pouvons clairement prédéfinir toutes les variables pour leur donner un certain type.....

il est pratique de créer une API externe. Vous pouvez travailler avec la référence de la classe (8 octets) lorsque vous travaillez - très souvent utilisé.

Exemple : Toutes sortes de listes de nœuds liés et autres.


// ici j'ai écrit seulement les particularités que je vois, il est clair qu'il n'y a pas de sens à écrire sur la possibilité et les propriétés des méthodes protégées et autres choses..... c'est juste du sucre.

Les propriétés de la FP sont ce que nous voudrions faire quelque part, après quelque chose, par exemple, nous voudrions créer une nouvelle fonction à la volée dans la fonction - diviser la fonction actuelle, qui utiliserait certaines des variables actuelles de notre fonction. Pour passer son exécution à une autre fonction - il s'avère que nous passons simplement la fonction retardée, le calcul qui n'a pas encore eu lieu - juste comme un morceau de code.....

En fait, c'est assez pratique.

Cela laisse la propriété du déroulement complet du code car en fait nous savons clairement quelle fonction nous avons - ce qui est susceptible d'être plus rapide en calcul que la POO. Vous pouvez organiser des transferts de calculs plutôt astucieux d'une fonction à l'autre - de plus, la fonction se souvient complètement de l'environnement des variables appelées de la fonction précédente - ce qui est très cool (bien qu'en fait, il s'agisse simplement de sauvegarder les variables déclarées de la portée externe). FP, d'autre part, vous pouvez définir l'adresse d'une fonction et la stocker dans un tableau comme une classe - bien que cela ne soit pas particulièrement utile.

Facilité d'écriture du code pour les actions différées, toutes sortes de fonctions asynchrones, les calculs parallèles...

 

Permettez-moi d'expliquer mes préoccupations sur la base de l'article cité et du concept de déterminisme lui-même. Ce qui me fait peur dans la "spaghettification" (la complexité du code lui-même et la tâche de trouver les erreurs de calcul) ? Eh bien, c'est ce sur quoi l'article se concentre - les valeurs "poubelles" dans les variables ou les retours non déterministes des fonctions.

Je construis/entraîne des réseaux neuronaux de ma propre structure de variables (évolution). Et pour eux, il est très critique que les "déchets" en valeurs viennent de nulle part.

Comme dans l'article - vous appuyez sur la pédale de frein, et la pédale se fiche de vous. C'est en cours d'utilisation. Et si, au stade initial de la construction (sélection automatique de l'architecture) et de la formation de votre réseau neuronal, des "déchets" sont possibles, comment sont-ils construits/formés ?

Comment éviter autant que possible les "déchets" (nondéterminisme) dans la POO ?

 
Mikhail Mishanin:

Permettez-moi d'expliquer mes préoccupations sur la base de l'article cité et du concept de déterminisme lui-même. Ce qui me fait peur dans la "spaghettification" (la complexité du code lui-même et la tâche de trouver les erreurs de calcul) ? Alors, qu'est-ce qui est mis en avant dans l'article - les valeurs "poubelles" dans les variables ou les retours non déterministes des fonctions.

Je construis/entraîne des réseaux neuronaux de la structure de mes variables (évolution). Et pour eux, il est très critique que les "déchets" en valeurs viennent de nulle part.

Comme dans l'article - vous appuyez sur la pédale de frein, et la pédale se fiche de vous. C'est en cours d'utilisation. Et si, au stade initial de la construction (sélection automatique de l'architecture) et de la formation de votre réseau neuronal, des "déchets" sont possibles, comment sont-ils construits/formés ?

Comment éviter autant que possible les "déchets" (nondéterminisme) dans la POO ?

L'article en général est un peu étrange, l'homme a clairement oublié de préciser le type de variable const, comme il avait js puis au moins readonly. Après cela, il écrit qu'il a soi-disant eu une erreur lorsque l'objet qui ne doit pas changer de taille (être une constante) n'est pas une constante ..... et sur la base de cela, il conclut qu'il y a une grande probabilité d'erreur dans la POO))).

En général, la POO vous permet de contrôler des zones de variables. La POO est conçue pour passer des variables à partir d'une fonction, c'est-à-dire que le type devrait déjà être défini par défaut puisqu'il y en a très probablement peu. Et si nécessaire, cette fonction peut elle-même être étendue à la volée.

C'est-à-dire qu'en POO, il y a plus de contrôle initial.

 

Je ne sais pas qui écrit de tels "articles", des mots vides, des phrases générales, un minimum de sens.

" Le code dans son ensemble était confus et désordonné - ce qu'on appelle "spaghetti " en argot " - à cause des mauvais programmeurs deToyota, nous considérerons qu'enPOO le code est confus.

" Les fonctionnalités OOP intégrées ne font qu'ajouter à la confusion. " - bien logique, la possibilité d'utiliser des fonctionnalités ajoute de la confusion au code, avec une augmentation constante du nombre de fonctionnalités OOP (C#) il sera impossible d'écrire du code simple désormais. Oui.

"Dans la plupart des langages orientés objet, les données sont transmises par référence, c'est-à-dire que différentes parties du programme peuvent traiter la même structure de données - et la modifier. Cela transforme le programme en un gros morceau d'état global et contredit l'idée originale de la POO " - Etprivé,protégé?

"...Si vous n'aimez pas cette citation, c'est parce que le nondéterminisme en général ne vous mène nulle part."Eh bien, oui, les fonctions imprévisibles GetMicrosecondCount, MathRand, CoptBuffer, toutes les fonctions réseau et autres doivent être jetées car le résultat y dépend de l'état extérieur. C'est horrible.

Ok, ça suffit, tout est clair ici.

 

La plupart des arguments y sont aspirés par vos doigts. Certaines expériences "prouvant" l'invalidité de la POO ne sont pas du tout correctes. Dans les langages POO normaux, sum(int a, int b) sera toujours propre, même si vous écrivez des absurdités comme a += b en interne. Encore une fois, si un objet est alloué sur le tas à l'intérieur d'une méthode, il est toujours protégé, car seule la méthode qui l'a appelé a une référence sur lui. Vous pouvez le changer à volonté. Il existe des types de référence et des types significatifs. Personne ne vous empêche d'écrire des fonctions propres sans aucun effet secondaire dans les langages POE. Les fonctions mathématiques standard sont, par exemple, les suivantes. Oui, parfois, vous ne pouvez pas vous passer des ressources partagées, mais il existe des collections pratiques à l'abri des fils et bien plus encore. Après tout, toute FP pure interagira inévitablement avec les IO, la BD, les requêtes réseau et bien d'autres choses encore, et c'est là que les démons de modifiabilité vont percer.

 

Article bizarre....

La quantité tend à se transformer en qualité.

Quand il y a beaucoup de radios, il peut y avoir une incompatibilité électromagnétique et elles cesseront de fonctionner.

Les propriétés spaghetti du code proviennent généralement de la quantité et de la non-prise en compte de toutes les propriétés de l'enveloppe lorsqu'il y a de nombreuses utilisations dans différents états.

Dans les fonctions, la présence de rétroactions conduira à la même chose. L'hystérésis est une blague)

Comprendre les problèmes et les résoudre ... ))))

 
Alexandr Andreev:

// Je n'ai décrit que les fonctionnalités que je peux voir ici, il est évidemment inutile d'écrire sur la possibilité et les propriétés des méthodes protégées et autres choses..... c'est juste du sucre.

Les propriétés de la FP sont ce que nous voudrions faire quelque part, après quelque chose, par exemple, nous voudrions composer une nouvelle fonction à la volée dans une fonction - partageant la fonction actuelle, qui utiliserait certaines des variables actuelles de notre fonction. Pour passer son exécution à une autre fonction - il s'avère que nous passons simplement la fonction retardée, le calcul qui n'a pas encore eu lieu - juste comme un morceau de code.....

En fait, c'est assez pratique.

Eh bien, qui empêche de faire la même chose en OOP ? Même dans un langage purement procédural ? Vous passez un pointeur vers une fonction à une autre fonction et obtenez une exécution retardée.

En général, l'asynchronie est un modèle de conception pur. Vous pouvez également écrire du code asynchrone en C pur. Il suffit de créer une machine-état qui exécute la tâche en plusieurs parties. Au fait, je l'ai fait avec des indicateurs dans MQL qui prenaient beaucoup de temps à être calculés. Je l'ai fait pour éviter de ralentir le graphique et afficher une jolie barre d'état qui change son pourcentage de réalisation.

 
Vasiliy Sokolov:

Eh bien, qui vous empêche de faire la même chose en OOP ? Même dans un langage purement procédural ? Vous passez un pointeur vers une fonction à une autre fonction et obtenez une exécution différée.

En général, l'asynchronie est un modèle de conception pur. Vous pouvez également écrire du code asynchrone en C pur. Il suffit de créer une machine-état qui exécute la tâche en plusieurs parties. Au fait, je l'ai fait avec des indicateurs dans MQL qui prenaient beaucoup de temps à être calculés. Cela m'aide à ne pas ralentir le graphique et à afficher une jolie barre d'état qui change son pourcentage de mise en œuvre.

) Vous pouvez également utiliser l'assembleur. La question est de savoir où c'est le plus facile.

Et ne me mettez pas dans l'un ou l'autre camp.... Je ne suis pas très attaché à une chose ou à une autre.

 

Article étrange. La POO ne diffère pas du style procédural pour le pire, parce qu'elle permet de tout faire en style procédural par défaut, et vice versa, sans que le code soit terriblement gonflé, c'est-à-dire que la POO est une "superstructure par-dessus", pas un style fondamentalement différent.

Si l'article porte vraiment sur le fonctionnel plutôt que sur le procédural (ce qui n'est pas si évident si on s'y attarde), alors pourquoi comparer des choses qui ont des usages complètement différents.

Topeka starter, êtes-vous vous-même en train d'écrire et de parler de quoi ? fonctionnel ou procédural ?

 
Mikhail Mishanin:

Après tout, il s'avère que la POO est surtout destinée à la lisibilité et à la programmation en équipe, c'est-à-dire aux grands projets.

Je ne sais pas comment utiliser la POO. Mais j'en utilise des choses primitives. Dans un passé récent, j'ai posté un code très simple.


J'ai commencé à l'écrire en FP, alors que je ne comprenais pas encore ce que j'aurais éventuellement besoin de regarder.

Terminé par les éléments primitifs de la POO. J'ai probablement perdu mes compétences en matière de PF, mais ici la POO m'a semblé beaucoup plus simple et plus lisible.


Le code est très simple et court(description). Si vous l'écrivez en FP, il serait intéressant de comparer.