Parler de l'OLP dans le salon - page 20
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
L'article ment !
Je n'ai pas lu le reste de l'article. Il est fort probable que l'absurdité de l'auteur ait été immédiatement signalée dans les commentaires.Lisez la suite, c'est tout ce qu'il faut.
En codage procédural, il est presque toujours possible de personnaliser l'architecture d'un programme au fur et à mesure de son écriture. Parce que la flexibilité et la liberté sont totales
+
Vous pouvez oublier la POO juste pour le plaisir, surtout pour les algorithmes de calcul, comme dans le commerce...
Sur les mythes de l'OLP - pas pour les adhérents de l'OLP qui ont la frousse.
"Il y a eu plusieurs mythes sur la POO depuis le milieu des années 1980. L'un d'entre eux, le mythe de la réutilisation, affirme que la POO rend le développement plus productif car elle permet d'hériter et d'étendre le code actuel au lieu de devoir le réécrire. L'autre est le mythe de la conception, qui implique que l'analyse, la conception et la mise en œuvre se suivent sans heurts, parce qu'elles sont toutes des objets. Bien sûr, aucun de ces mythes ne peut être le paradigme de la POO".
L'oncle est un théoricien et une grande gueule, comme la plupart des universitaires. Et peu importe qu'il soit professeur (le titre a longtemps été infléchi) et auteur de livres.
Ces bêtises de phrases circulent depuis longtemps et ignorent complètement la croissance exponentielle de la complexité des produits logiciels. Ce qui était 30-20-10 il y a quelques années n'est en rien comparable à l'ampleur et à la complexité des projets actuels. Et ils préfèrent encore jouer dans le bac à sable, en le réduisant à des modèles.
Faites-le s'asseoir pour fabriquer un produit réel, qui a de nombreuses exigences, notamment en matière de ressources, d'économie et de concurrence. Il va instantanément péter les plombs avec son raisonnement, échouant de toutes les manières possibles. Il est même plus probable qu'il soit mis à la porte pour cause de capitanat infantile au stade de la conception de la solution.
Le monde a essayé de nombreuses balles d'argent, mais elles se sont toutes révélées sans valeur et sont depuis longtemps passées par pertes et profits. Cela laisse une croissance constante de la complexité, une croissance des bibliothèques (et il y a un oop) et des frameshots (et il y a un oop), qui permettent au moins un certain contrôle de la complexité.
Et il est impossible d'échapper à la complexité croissante. Il y aura encore plus de complexité, il y aura plus de développeurs analphabètes incapables de suivre les exigences de qualité des connaissances.
Il y aura de plus en plus de tentatives d'élaborer des langages encore plus simples pour répondre à la masse toujours décroissante des programmeurs. De plus en plus d'entreprises de logiciels se retrouveront désavantagées en croyant simplement à la mauvaise technologie et en perdant la course à la concurrence. C'est juste que leurs concurrents utiliseront une technologie plus lourde, mais efficace en termes de résultats produits.
Investir dans des sociétés de logiciels a longtemps été une chose mortelle. Les taux de mortalité et d'échec sont stupéfiants, et la situation ne fera qu'empirer.
Pourquoi ? Oui, parce que c'est un business avec des masses de demandes économiques, pas de la technologie. Le marketing et les ventes représentent environ 80 % du chiffre d'affaires d'une entreprise de logiciels vivante et en activité. Une technologie inadaptée (et ici, la plupart des gens privilégient la simplicité supposée) tue facilement les ventes futures. Parce qu'il y a toujours des concurrents qui ont emprunté un chemin plus difficile et qui ont obtenu de meilleurs résultats à la fin.
Maintenant, parlons des micro-projets jusqu'à cent mille lignes. Cela vous permet de créer n'importe quoi, car cela a une chance de tenir dans la tête d'une personne et de maintenir l'illusion du contrôle. Si vous essayez d'augmenter l'échelle - douleur, frustration et mort.
Conclusions :
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Parler de l'OLP
Renat Fatkhullin, 2018.01.17 09:17
L'oncle est un théoricien et une grande gueule comme la plupart des universitaires. Et peu importe qu'il soit professeur (le titre a longtemps été gonflé) et auteur de livres.
Ces bêtises faites de phrases circulent depuis longtemps et ignorent complètement la croissance exponentielle de la complexité des logiciels. Ce qui était 30-20-10 il y a quelques années n'est en rien comparable à l'ampleur et à la complexité des projets actuels. Et ils préfèrent encore jouer dans le bac à sable, en le réduisant à des modèles.
Faites-le s'asseoir pour fabriquer un produit réel, qui a de nombreuses exigences, notamment en matière de ressources, d'économie et de concurrence. Il va instantanément péter les plombs avec son raisonnement, échouant de toutes les manières possibles. Il est même plus probable qu'il soit mis à la porte pour cause de capitanat infantile au stade de la conception de la solution.
Le monde a essayé de nombreuses balles d'argent, mais elles se sont toutes révélées sans valeur et sont depuis longtemps passées par pertes et profits. Cela laisse une croissance constante de la complexité, une croissance des bibliothèques (et il y a un oop) et des frameshots (et il y a un oop), qui permettent au moins un certain contrôle sur la complexité.
Et il est impossible d'échapper à la complexité croissante. Il y aura encore plus de complexité, il y aura plus de développeurs analphabètes incapables de suivre les exigences de qualité des connaissances.
Il y aura de plus en plus de tentatives d'élaborer des langages encore plus simples pour répondre à la masse toujours décroissante des programmeurs. De plus en plus d'entreprises de logiciels se retrouveront désavantagées en croyant simplement à la mauvaise technologie et en perdant la course à la concurrence. C'est juste que leurs concurrents utiliseront une technologie plus lourde, mais efficace en termes de résultats produits.
Investir dans des sociétés de logiciels a longtemps été une chose mortelle. Les taux de mortalité et d'échec sont stupéfiants, et la situation ne fera qu'empirer.
Pourquoi ? Oui, parce que c'est un business avec des masses de demandes économiques, pas de la technologie. Le marketing et les ventes représentent environ 80 % du chiffre d'affaires d'une entreprise de logiciels vivante et en activité. Une technologie inadaptée (et ici, la plupart des gens privilégient la simplicité supposée) tue facilement les ventes futures. Parce qu'il y a toujours des concurrents qui ont emprunté un chemin plus difficile et qui ont obtenu de meilleurs résultats à la fin.
Maintenant, parlons des micro-projets jusqu'à cent mille lignes. Cela vous permet de créer n'importe quoi, car cela a une chance de tenir dans la tête d'une personne et de maintenir l'illusion du contrôle. Si vous essayez d'augmenter l'échelle - douleur, frustration et mort.
Conclusions :
Le meilleur billet du mois, ou peut-être de l'année ! Renat, pourquoi vous ou votre entreprise n'écrivez pas d'articles sur Hubra(l'entreprise n'y est même pas enregistrée !) ? Vous avez tellement de choses à dire, mais votre expérience ne s'apprend que par bribes dans vos posts. Sérieusement, très actuel et précis. Pour illustrer votre propos: https://habrahabr.ru/post/344356/
Le meilleur billet du mois, peut-être de l'année !
Qu'est-ce qui vous a plu dans ce billet dans le contexte du sujet de la POO ? Il n'est probablement pas tout à fait juste de généraliser les choses commerciales aussi, les investisseurs ne sont pas idiots et impliquent leurs experts pour évaluer le risque des projets....
Cet article par certains, mais encore un professeur a des arguments logiques spécifiques à laquelle aucun contre-arguments adéquats ont été présentés pour la discussion ...
Il est également clair que la simple pogrammation n'est pas toujours un mal pour les projets...
Le meilleur billet du mois, peut-être de l'année ! Renat, pourquoi vous ou votre entreprise n'écrivez pas d'articles sur Hubra(l'entreprise n'y est même pas enregistrée !) ? Vous avez tellement de choses à dire, mais votre expérience ne s'apprend que par bribes dans vos posts. Sérieusement, très actuel et précis. En guise d'illustration du poste: https://habrahabr.ru/post/344356/
Nous travaillons pour des millions de personnes, pas pour les 1 000 à 5 000 lecteurs/visiteurs que les articles sur Habra obtiennent habituellement.
Nous avons créé une norme industrielle et nous publions des solutions qui ont un impact sur le monde. Pourquoi avons-nous besoin d'une sorte de Habr, et encore plus, cantonné dans une niche étroite du segment russe.
Qu'est-ce qui vous a plu dans ce post dans le contexte du sujet OOP ? Il n'est probablement pas tout à fait juste de généraliser les choses commerciales aussi, les investisseurs ne sont pas idiots et impliquent leurs experts pour évaluer le risque des projets....
Il y a des arguments logiques spécifiques dans cet article par certains, mais encore un professeur, auxquels aucun contre-argument adéquat n'a été présenté pour discussion...
Il est également évident que le simple pogramme n'est pas toujours un mal pour les projets...
Arrêtez avec les railleries dilettantes, s'il vous plaît.
Vous serez simplement banni pour cause d'analphabétisme technique. Nous n'avons pas besoin d'ignorants belliqueux dans notre forum.
...
Il est également évident que la simplicité de la programmation n'est pas toujours un mal pour les projets...
Il existe un axiome : la complexité ne va nulle part. Par conséquent, la "simplicité de programmation" pour l'utilisateur est un transfert de complexité vers le compilateur. La complexité est comme traitée par le compilateur dans les coulisses et lui, le compilateur, essaie de cacher toute perversion du programmeur selon le principe "mieux vaut le laisser fonctionner d'une manière ou d'une autre que rien du tout". Le compilateur, et non le programmeur, devient le propriétaire du projet. Le développement et la maintenance du code deviennent impossibles, car vous ne comprenez pas ce qui se passe (le compilateur le construit en quelque sorte, mais peu importe).
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Parler de la POO
Renat Fatkhullin, 2018.01.17 09:17
...
Et il est impossible d'échapper à la complexité croissante. Il y aura encore plus de complexité, il y aura plus de développeurs analphabètes incapables de suivre les exigences de qualité des connaissances.
Il y aura de plus en plus de tentatives d'élaborer des langages encore plus simples pour répondre au niveau de masse toujours plus bas des programmeurs. De plus en plus d'entreprises de logiciels seront déficitaires, simplement parce qu'elles croiront en une mauvaise technologie et perdront la course à la concurrence. C'est juste que leurs concurrents utiliseront des technologies plus lourdes, mais plus efficaces en termes de résultats produits.
...
Arrêtez avec les railleries dilettantes, s'il vous plaît.
Vous serez simplement banni pour cause d'analphabétisme technique. Nous n'avons pas besoin d'ignorants belliqueux dans notre forum.