Discussion de l'article "La Programmation Basée sur des Automates comme Nouvelle Approche pour créer des Systèmes de Trading Automatisés"

 

Un nouvel article La Programmation Basée sur des Automates comme Nouvelle Approche pour créer des Systèmes de Trading Automatisés a été publié :

Cet article nous emmène dans une toute nouvelle direction dans l’élaboration d' EA, d'indicateurs et de scripts en MQL4 et MQL5. À l'avenir, ce paradigme de programmation deviendra progressivement la norme de base pour tous les traders dans l’implémentation des EA. En utilisant le paradigme de programmation basé sur les automates, les développeurs MQL5 et MetaTrader 5 seront tout près de pouvoir créer un nouveau langage - MQL6 - et une nouvelle plate-forme - MetaTrader 6.

Un rêve longtemps chéri de tous les créateurs de problèmes et développeurs de logiciels doit avoir une solution planifiée au problème (algorithme) et une implémentation de cet algorithme entièrement compatible avec celui-ci. Mais cela ne semble pas fonctionner de cette façon pour les créateurs et les développeurs. Les algorithmes ont tendance à laisser de côté ce qui est important pour les développeurs pour l’implémentation, tandis que le texte du programme en soi ne ressemble guère à l'algorithme.

Ainsi, il existe deux algorithmes - l'un est sur papier (pour enregistrer et documenter les solutions de conception) qui représente généralement un certain résultat de conception au lieu des méthodes employées pour obtenir un résultat donné, tandis que le second algorithme est dans l'esprit du développeur (qui est, cependant, , également enregistré textuellement).

La version finale du texte du programme est souvent suivie de tentatives de modification de la documentation au cours desquelles de nombreux éléments ne sont à nouveau pas pris en compte. Dans ce cas, la logique du programme peut être différente de la logique de l'algorithme, démontrant ainsi un manque de correspondance. Je dis intentionnellement "probable" car personne ne vérifiera jamais le texte du programme d’autrui.

Si le programme est volumineux, il est impossible de vérifier s'il correspond à l'algorithme par le texte seul. L'exactitude de l’implémentation peut être vérifiée à l'aide d'une procédure appelée « test ». Il vérifie essentiellement comment le développeur a saisi l'algorithme (présenté sur papier),l'a transformé en un autre algorithme dans son esprit et l'a sorti en tant que programme. Finalement, le développeur est le seul détenteur d'informations précieuses sur la logique et tout ce qui a été inventé avant l’implémentation devient absolument hors de propos.

Ce n'est même pas que le développeur puisse tomber malade (ou... démissionner). Le fait est que la logique du programme sous-jacent serait différente avec chaque développeur, en fonction de son intelligence et de sa connaissance d'un langage de programmation. Dans tous les cas, le développeur introduit et utilise beaucoup de variables intermédiaires comme bon lui semble. Et si le programme est volumineux et logiquement complexe, un spécialiste plus qualifié sera nécessaire pour trouver les problèmes (et je ne parle pas ici de problèmes de système d'exploitation ou d'utilisation incorrecte des fonctions du langage, mais plutôt d'une implémentation incorrecte en termes de logique) et de le résoudre à travers le texte du programme lui-même.

La majorité des développeurs, pour le moins, n'aiment pas écrire des algorithmes avant de les programmer (ou même de les dessiner sur papier), ce qui est probablement dû au fait qu'ils auront encore besoin de penser à quelque chose par eux-mêmes en cours de route. . En effet, pourquoi perdre du temps à dessiner des rectangles, des losanges et des flèches alors qu'il vaut mieux passer tout de suite à la programmation et disposer ensuite un algorithme un peu similaire ou très général dans la documentation.

Tout le monde s'y est habitué - les développeurs le font parce que c'est plus facile de cette façon, alors que les auteurs de problèmes n'ont pas toujours les compétences de programmation nécessaires et même dans le cas où ils le font, ils sont tout simplement incapables de modifier en temps voulu ce que les développeurs trouveront. Des environnements de programmation pratiques contribuent également à la validité de l'ordre d’élaboration indiqué. Des outils avancés de débogage et de surveillance des valeurs des variables nous donnent l'espoir de détecter toute erreur dans la logique.

Alors que le temps passe et que la date limite du projet approche, le développeur est assis et esquisse sur un « mouchoir » des solutions à un problème logique donné qui, soit dit en passant, doivent encore être implémenté, sans parler des erreurs négligées lors des tests pour les tests suivants à peu près le même scénario (chaotique)... C'est la situation actuelle. Existe-t-il une solution ou peut-elle au moins être améliorée ? On sent que quelque chose d'important est perdu dans la transition d'un algorithme présenté de manière standard au code du programme.

Auteur : MT5

 

Lorsqu'ils font la promotion d'un nouveau paradigme de programmation, ils commencent par présenter les inconvénients du paradigme utilisé et les avantages du paradigme proposé.

Malheureusement, ni les inconvénients ni les avantages ne sont abordés dans l'article.

Bien que cela soit intéressant pour le développement général, mais [jusqu'à présent] pas plus.

Le sujet n'est pas divulgué.

 
C'était intéressant à lire - cela ressemble beaucoup à une autre idée de M. Reshetov ;-) - Il y a beaucoup d'enthousiasme, mais pas d'effet. La section 1 ("Je commencerai de loin") fait douter que l'auteur ait une connaissance suffisante de l'industrie de la programmation - du moins, il exagère le fait qu'il est difficile de comprendre un grand programme, parce qu'un programme bien structuré est toujours divisé en petits modules, dont chacun est relativement facile à comprendre - beaucoup plus facile que l'horrible "feuille" de commutateurs-opérateurs que l'on nous propose à la place. Au lieu d'un opérateur de commutation, nous pourrions proposer un interprète d'un langage spécial qui utilise une sorte de grammaire de marché. D'ailleurs, les automates finis ont fait l'objet de discussions sur le forum, il suffit donc d'appeler (et de chercher) les choses par leur nom. Et surtout, l'article n'indique pas clairement comment il est proposé d'utiliser tout cela pour le commerce. Le sujet n'est pas révélé. IMHO.
 
MetaDriver:

Ce n'est pas nouveau

Je me suis mal exprimé. Ce n'est pas "nouveau", c'est "certains". Mais cela ne change rien à l'affaire. La question "que fait-il ?" reste ouverte.
 

Tout d'abord, lorsque vous écrivez un article sur un modèle, c'est une bonne idée de proposer une implémentation universelle et pratique.

L'article n'est pas allé plus loin qu'un interrupteur.

Bien que le modèle ne soit pas nouveau, une implémentation normale serait intéressante à voir et à discuter.

Je me joins aux intervenants précédents :) .

 

Je suis d'accord avec abolk, à l'exception de l'énoncé du problème "les gars, lorsque vous concevez un programme, pensez à tous ses états possibles", il n'y a pas de piquant dans l'article.

Il y a quelque chose que les gens ne savent pas, et après avoir lu l'article, hop, ils ont eu une révélation.

Il peut être utile pour les débutants, mais je ne le recommande pas, il est long et fastidieux.

Au fait, le rubik's cube a un état supplémentaire lorsqu'il est désassemblé :))

cet état est comme la quatrième dimension, car à partir de cet état on fait un pas vers le cube assemblé :)

 

"Permettez-moi de commencer par le fait que ce sujet est totalement inconnu de tout commerçant..... L'auteur Shalyto A.A. a développé en 1991 une méthode de programmation... Je vous invite tous à étudier une nouvelle orientation de la programmation."

Vous ne devriez pas prononcer des mots aussi forts. Les automates finis sont connus depuis 50 ans déjà, et tout programmeur les apprend dès la première année d'université.
Et le SWITCH-pattern est une méthode standard de réalisation d'automates en général, que tout programmeur compétent peut "inventer" en 5 minutes.
En particulier, j'écris des programmes de cette manière depuis 10 ans sans même soupçonner l'existence du respecté chef du département avec son invention :)
Et dans la programmation PLC, c'est depuis longtemps un "style et un standard".
Mais l'article est utile :).

 

Oups, à en juger par le surnom, l'auteur est italien, et l'article doit être traduit.

Je ne sais pas ce qu'il en est, mais je vois une image générale (à partir d'une correspondance personnelle par Skype) d'un énorme fossé en Occident entre les scientifiques spécialisés et les béotiens.

Apparemment, pour le commun des mortels, il s'agit d'une véritable découverte.

Nous avons des cuisiniers qui dirigent l'État, mais nous avons des cuisiniers qui ont deux diplômes de pré-Khtor :)

ZЫ peut-être qu'ils n'enseignent à l'école que la manière de remplir correctement le formulaire UB-40, parce que nos écoliers travaillent comme des dieux :)

 
Urain:

Oups, à en juger par le pseudo, l'auteur est italien, et l'article doit être traduit.

Non, ce n'est pas une traduction, c'est 100%.
 

un article étrange qui a au moins 10 ans de retard sur la programmation.

Le texte de l'article lui-même (avec le murmure constant du mantra "l'auteur est shalyto") est une copie du comportement du roi.

Маленький принц оглянулся - нельзя ли где-нибудь сесть, но великолепная горностаевая мантия покрывала всю планету. Пришлось стоять, а он так устал... И вдруг он зевнул.
        - Этикет не разрешает зевать в присутствии монарха, - сказал король. - Я запрещаю тебе зевать.
        - Я нечаянно, - ответил Маленький принц, очень смущенный. - Я долго был в пути и совсем не спал...
        - Ну, тогда я повелеваю тебе зевать, - сказал король. - Многие годы я не видел, чтобы кто-нибудь зевал. Мне это даже любопытно. Итак, зевай! Таков мой приказ.
        - Но я робею... я больше не могу... - вымолвил Маленький принц и густо покраснел.
        - Гм, гм... Тогда... тогда я повелеваю тебе то зевать, то...
        Король запутался и, кажется, даже немного рассердился.
        - Можно мне сесть? - робко спросил Маленький принц.
        - Повелеваю: сядь! - отвечал король и величественно подобрал одну полу своей горностаевой мантии.
...
...
        Маленький принц был восхищен. Вот бы ему такое могущество! Он бы тогда любовался закатом не сорок четыре раза в день, а семьдесят два, а то и сто, и двести раз, и при этом даже не приходилось бы передвигать стул с места на место! Тут он снова загрустил, вспоминая свою покинутую планету, и, набравшись храбрости, попросил короля:
        - Мне хочется поглядеть на заход солнца... Пожалуйста, сделайте милость, повелите солнцу закатиться...
...
        - Будет тебе и заход солнца. Я потребую, чтобы солнце зашло. Но сперва дождусь благоприятных условий, ибо в этом и состоит мудрость правителя.
        - А когда условия будут благоприятные? - осведомился Маленький принц.
        - Гм, гм, - ответил король, листая толстый календарь. - Это будет... гм, гм... сегодня это будет в семь часов сорок минут вечера. И тогда ты увидишь, как точно исполнится мое повеление.


L'auteur ouvre l'Amérique avec un regard abscons, là où les populations locales [les programmeurs] vivent depuis de nombreuses années avant lui.

De plus, l'auteur, sommité de la science mondiale, a un vocabulaire très réduit du dialecte local pour essayer d'expliquer aux gens qu'ils vivent très mal et dans l'obscurité sans ses "recommandations".


// et l'article est vraiment très fastidieux