Mon approche. Le noyau est le moteur. - page 19
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Très bien. Disons que je suis convaincu.
En principe, je comprends tout cela depuis longtemps. Et je suis d'accord avec ça. Cependant, en même temps, je préfère ma propre approche. Pourquoi ?
Il y a une raison particulière :
LE DÉVELOPPEMENT DU PROGRAMME.
//---------------------------------------
À quelle vitesse le programme se développera-t-il avec la POO et avec mon approche ? Quelle approche est plus favorable à la croissance et à la complication des mécanismes ?
J'ai conclu que mon approche + la langue maternelle dans le code (60% de russe et 40% d'anglais), fournissent une croissance rapide maximale du programme.
C'est précisément de cette croissance rapide dont j'ai besoin. Je ne creuse pas dans les détails. Pas seulement en survolant chaque ligne de code. Ce n'est pas une approche professionnelle.
Je voulais que le programme se développe rapidement et devienne plus complexe. Que des mécanismes seraient créés pour remplir les fonctions qui leur sont attribuées. Rapide et facile.
Pour que vous puissiez ajouter de nouvelles fonctionnalités avec quelques lignes de code.
Mon approche est supérieure à la POO pour résoudre cette tâche particulière.
Pourquoi pensez-vous que votre méthodologie permet un développement rapide et facile ? Jusqu'à présent, je vois le contraire. Sur le sujet de la complication, je suis d'accord. Votre code est vraiment difficile à comprendre.
Pourquoi pensez-vous que votre méthodologie rend le développement rapide et facile ? Je suis d'accord sur la complication. Votre code est vraiment difficile à comprendre. Jusqu'à présent, je vois le contraire.
Et comment estimez-vous la complexité de la création d'une machine virtuelle (moteur). Langage de balisage. Une seule personne avec une approche ridicule peut-elle créer cela ? Même avec la POO.
Lorsque vous comprendrez exactement ce que j'ai créé avec mon approche, vous comprendrez quelles possibilités de développement de programmes elle offre. (Je ne veux pas être impudique. C'est juste que, sinon, vous ne comprendriez pas).
Et comment estimez-vous la complexité de la création d'une machine virtuelle (moteur). Langage de balisage. Une seule personne avec une approche ridicule peut-elle créer cela ? Même avec la POO.
Lorsque vous comprendrez exactement ce que j'ai créé avec mon approche, vous comprendrez quelles possibilités de développement de programmes elle offre. (Je ne veux pas être impudique, c'est juste que vous ne le comprendriez pas autrement).
Ok, au moins vous n'avez toujours pas répondu à la question. Attendons un code exploitable et voyons combien de temps durera votre enthousiasme.
Lorsque vous comprendrez ce que j'ai créé avec mon approche, vous comprendrez les possibilités de développement de programmes qu'elle offre
Le paradoxe, c'est que personne ne peut comprendre ce que vous avez créé... sauf vous, bien sûr...)
Donc, le paradoxe est que personne ne peut comprendre ce que vous avez créé (sauf vous, bien sûr).
J'ai dessiné beaucoup de fenêtres, fait un tas de vidéos sur le constructeur, fourni un moteur prêt à l'emploi avec des fenêtres, lié le moteur à un programme personnalisé sans connaître son code. Je m'apprête à créer des moteurs de calcul qui reprendront les fonctionnalités des EA, mais les programmeurs de forum éduqués ne comprennent pas ce que j'ai fait).
C'est juste une ironie méchante en quelque sorte...)
Cependant, la branche ne concerne pas ce que j'ai créé, mais l'approche. Mais il est impossible de montrer la puissance de l'approche sans démontrer les réalisations. Le public ne comprend pas pleinement les réalisations. C'est normal.
Pour comprendre la réalisation, il faut imaginer la complexité du problème initial. Répondons à la question suivante : quelle est la complexité de la création d'un langage de balisage ?
Pour quelqu'un qui ne l'a jamais fait, cela peut sembler facile, mais que faut-il vraiment faire ?
Quelqu'un le sait-il ?
Répondons à la question suivante : à quel point est-il difficile de créer un langage de balisage ?
Pour quelqu'un qui ne l'a jamais fait auparavant, cela peut sembler facile, mais que faut-il vraiment faire ?
Quelqu'un le sait-il ?
Pour votre langue, ce n'est pas grand-chose. Pour un programmeur, on pourrait dire que c'est une tâche de week-end.
Pour votre langue, un petit. Pour un programmeur, on pourrait dire que c'est une tâche de fin de semaine.
Eh bien, j'ai supposé une telle réponse. Cependant, pourquoi n'avez-vous pas créé un langage de balisage ? Vous faites du graphisme depuis longtemps et n'avez pas fait une langue en un week-end).
D'après ce que j'ai compris, vos fenêtres utilisent une bibliothèque graphique standard (à en juger par l'apparence).
Combien de temps pensez-vous qu'il vous faudrait pour créer votre propre bibliothèque graphique à partir de rien ?
Par exemple, il a fallu un an et demi à Anatoly. Et il a utilisé le code d'autres personnes aussi. La classe CCanvas, par exemple.
Mais combien de temps cela lui aurait-il pris de tout faire à partir de zéro ? Je pense au moins deux ans.
Seulement la bibliothèque, remarquez. Pas un langage de balisage.
J'ai cru comprendre qu'il n'y a pas encore eu de vérification et de code source ?
Pas encore. Nous y reviendrons bien assez tôt. Je voudrais d'abord souligner l'ampleur de la tâche sur laquelle l'approche devait être testée.