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
Il ne va nulle part ! L'interaction entre les deux logiques reste à construire. La vue n'existe pas par elle-même. Certains de ses éléments sont toujours liés à des variables et/ou des objets du modèle d'application lui-même.
Vous avez raison sur tous les points, Alexey. Il n'y a qu'un seul problème : vous ne reconnaissez pas "la même Fedora dans une robe différente" en ce qui concerne les objets et l'approche en général.
Nous allons attendre et voir. Jusqu'à présent, je vois une substitution flagrante de concepts. Tous les concepts de programmation de ces dernières années ont été bouleversés.
Mais attendons le résultat, ne le coupons pas dans le feu de l'action.
Nous verrons bien. Ce que je vois jusqu'à présent, c'est une substitution grossière de concepts. Tous les concepts de programmation de ces dernières années ont été chamboulés.
Mais attendons le résultat, ne le coupons pas dans le feu de l'action.
Eh bien, si le résultat justifie un renversement des concepts admis, que faire alors ?
Question étrange. À quoi vous attendez-vous ?
Je suis sûr à 100% que ça ne sera pas le cas...
Question étrange. À quoi vous attendez-vous ?
Je suis sûr à 100% que ça ne sera pas le cas...
Peter, vous avez une réaction très intéressante, comme on dit "et puis Ostap s'est emporté". Il y a des notes de ressentiment enfantin, primitif. Mais à quoi ?
J'ai simplement écrit que je ne pense pas que la déformation des concepts conventionnels justifie le résultat.
Si je comprends bien, vous n'essayez pas de développer un système distinct, mais une boîte à outils pour d'autres systèmes d'information. des programmeurs.
Mais d'autres programmeurs, utilisateurs potentiels de votre produit, déjà à ce stade, disent : "Peter, ce n'est pas bien ! En retour, vous dites : "Vous êtes tous des incompétents, vous ne savez rien de la programmation et vous avez inventé pour vous-mêmes une sorte de RPF et des classes ! Mais tout est en fait simple et facile à faire en assembleur. Je vais finir mon produit et vous apprendre de nouvelles règles de programmation, sinon vous jouez tous dans un bac à sable et ne voyez pas plus loin que votre nez !".
D'une certaine manière, ça ressemble à ça.
Mais vous ne comprenez pas l'essentiel : ceux qui utiliseront votre produit selon votre idée ont une compréhension complètement différente de la programmation et du concept d'"objet", du modèle événementiel, de la souscription à des événements, de l'héritage, etc. Il leur sera très difficile de passer des paradigmes conventionnels à un produit unique avec quelques variantes.
Je suis sûr que l'éditeur lui-même sera excellent, il n'y a aucun doute là-dessus. En tant que produit autonome, il peut être respecté et vous pouvez même jouer avec lui en tant que constructeur. Mais apprendre quelque chose de nouveau comme un "langage de balisage" juste pour connecter l'interface graphique à votre code ne serait pas rentable.
Vous avez fait un excellent travail en créant un constructeur graphique. Remarquez comment absolument tout le monde vous soutient dans cette direction.
Et pratiquement tous vous disent : Peter, tout cela serait demandé si vous réécriviez tout en POO. Mais vous ne m'entendez pas. Apparemment, vous créez un produit strictement pour satisfaire votre ego, et non pour les autres utilisateurs, dont vous ignorez ouvertement et de manière flagrante les intérêts.
Eh bien, en parlant de la langue russe, vous n'êtes pas un pionnier ici aussi. La société russe 1C a depuis longtemps développé un langage dont la programmation est principalement en russe.