Programmation du coucher du soleil ? - page 7
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
Qu'est-ce que tu veux dire maintenant ? Que le programmeur s'est progressivement transformé en développeur, avec une augmentation du nombre d'outils et des exigences des tâches ?
Je ne l'ai pas nié.
J'ai simplement posé quelques questions qui découlent logiquement de vos thèses.
Je posais juste quelques questions qui découlent logiquement de vos thèses.
Eh bien, oui, chaque industrie se développe et suit sa propre voie. Y compris le développement de logiciels. Voici une bonne définition du wiki, d'ailleurs :
Ledéveloppement de logiciels est le processus de conception, de spécification, de design, deprogrammation, dedocumentation, detest et decorrection de bogues impliqué dans la création et la maintenance d'applications, decadres ou d'autres composants logiciels.
Il est utilisé depuis environ 30 ans. Vous décrivez une tâche hautement spécialisée et l'extrapolez à la classe entière des tâches de développement. Le développement visuel existe depuis longtemps, qu'il soit partiellement ou entièrement automatisé. Cela n'exclut nullement la nécessité de développer d'autres classes de tâches, voire des tâches résolues par des environnements visuels, auxquelles s'appliquent des exigences de performance plus élevées, par exemple. Parce que tout universalisme se transforme tôt ou tard en un monstre.
Supposons que vous ayez raison. Examinons des exemples de tâches qui ne le peuvent pas :
1. se décomposer en objets.
2. représenter les objets comme des assemblages de paramètres et de relations.
3. assembler les objets à l'aide d'outils visuels.
Si ce n'est pas difficile, donnez des exemples de telles tâches.
Il vous répond pour troller, pas pour comprendre quelque chose, ne perdez pas votre temps - Peter et Fedoseyev sont deux des plus brillants représentants de mql sandbox, qui ne veulent pas en sortir.
Dès qu'une question à laquelle vous ne pouvez pas répondre et qui vous fait réaliser que vos arguments sont indéfendables, c'est du trolling. C'est drôle.
Eh bien, oui, chaque industrie se développe et suit sa propre voie. Y compris le développement de logiciels. Voici une bonne définition du wiki, d'ailleurs :
Ledéveloppement de logiciels est le processus de conception, de spécification, de design, deprogrammation, dedocumentation, detest et decorrection de bogues impliqué dans la création et la maintenance d'applications, decadres ou d'autres composants logiciels.
En d'autres termes, les programmeurs (ou développeurs) n'ont pas rédigé de documentation, n'ont pas testé et n'ont pas corrigé les bogues. Et maintenant ils sont impliqués dans le design ?
Disons que vous avez raison. Examinons des exemples de tâches qui ne le peuvent pas :
1. se décomposer en objets.
2. représenter les objets comme des assemblages de paramètres et de relations.
3. assembler les objets à l'aide d'outils visuels.
Si vous le voulez bien, donnez quelques exemples de ces tâches.
Non, Peter. L'avenir appartient à la programmation biologique. Cela se passe approximativement comme suit : un homme est rasé, un biomasse actif spécial est placé sur sa tête, et il commence à penser intensivement à la tâche à accomplir. En conséquence, dans la biomasse déposée sur la tête, des connexions neuronales se construisent, une sorte de ganglion artificiel se forme, correspondant aux pensées émises... C'est ainsi que les unités de bio-ordinateur pour les cyborgs seront créées. ))) Eh bien, tu sais ce que je veux dire.
1. Le développement visuel existe depuis longtemps, qu'il soit partiellement ou entièrement automatisé.
2. cela n'exclut nullement la nécessité de développer d'autres classes de tâches, voire des tâches résolues par des environnements visuels, auxquelles s'appliquent des exigences de performance plus élevées, par exemple.
3. Parce que tout universalisme se transforme tôt ou tard en un monstre.
1. Si vous le pouvez - donnez moi un lien pour lire sur ce sujet.
2. Pouvez-vous ventiler les problèmes par classe et indiquer spécifiquement les solutions qui ne se prêtent pas aux outils visuels ?
3. Tout n'est pas simple ici. Un énorme ordinateur des années 50 tient dans un téléphone portable, ce qui suggère que l'universalisme fonctionne bien et n'est pas rigidement lié à la performance. En tout cas, la performance résout le problème de l'universalisme des monstres.
Disons que vous avez raison. Examinons des exemples de tâches qui ne le peuvent pas :
1. se décomposer en objets.
2. représenter les objets comme des assemblages de paramètres et de relations.
3. assembler les objets à l'aide d'outils visuels.
Si cela n'est pas difficile, veuillez donner des exemples de telles tâches.
Calcul des nombres de Fibonacci, création de certaines réactions de l'interface utilisateur aux actions de l'utilisateur en dehors d'un ensemble prédéfini, rédaction de documentation, rédaction de tests unitaires.
Il s'agit de tâches très simples, mais il existe des systèmes énormes, par exemple le rendu d'images, etc.
Il y en a beaucoup, en général.