Bon, c'est geek et c'est très con, mais j'ai ri pendant au moins 15 bonnes minutes.
http://users3.ev1.net/~eekfrenzy/captio ... logue.html
HS
-
Little Lou
- Freakette
- Messages : 3358
- Enregistré le : mer. 03 nov. 2004, 11:17
- Localisation : United States of Whatever, man!
- Contact :
Avatar by Kiri
-
jem
- CyberPet
- Messages : 5037
- Enregistré le : mar. 14 oct. 2003, 5:57
- Localisation : les collines gersoises
Je commence par noter que tout ce qui suit ne s'applique pas aux jeux qui ont des besoins assez spécifiques : beaucoup de 3D via Direct X et de performance dans les calculs mathématiques.Catox a écrit :pour l'installation en direct avec le logiciel, les jeux le font avec DirectX... d'ailleurs pourquoi les jeux récents n'utilisent pas .NET (pour ceux que j'ai eu en tout cas) ? Parce qu'ils n'ont pas les mêmes besoins ?
J'ai du mal à voir quels besoins spécifques les applications "d'aujourd'hui" pourraient avoir que les outils de Visual Studio "d'hier" ne couvraient pas...
En gros les outils Visual Studio à l'ancienne c'était 2 familles (je schématise):
- Le C++ qui est assez ardu à développer et qui a tendance à planter méchamment à la moindre désallocation mémoire oubliée.
- Le Visual Basic qui est très simple et permissif, à la limite d'un langage de script, mais qui manque de performance pour les traitements bourrins (calculs mathématiques, gestion d'image de son, etc...) et a du mal à supporter des projets un peu volumineux.
Ces deux familles ont évolué en gros jusqu'en 98.
Entre temps est arrivé le Java qui a fait un tabac en proposant notamment :
- une programmation 100% orienté objet
- des librairies standard proposant enormément de fonctionnalités (gestion d'interface, de réseau, de base de données...)
- le concept d'execution "managé" qui fait entre autre que tu n'as pas besoin de gérer finement la mémoire de ton application, le runtime le fait pour toi.
C'est devant ce succès et devant l'impasse relative dans laquelle etait arrivé le visual que MS a décidé de monter sa plateforme .NET.
Pour répondre à ta question sur quels sont les nouveaux besoins des applis, on peut citer l'accès au Net (HTTP, FTP, Web Services), la gestion du XML, l'accès standardisé à différentes sources de données... Et surtout la réduction de la buggabilité des applis en utilisant des bibliothèques standard et du code plus exploitable sur le long terme.
Un codeur qui ne réinvent pas la roue gagne du temps, mais surtout evite de faire une roue voilée qui plantera pendant 1 ou 2 ans avant d'arriver à stabilisation.
I found my freedom now.
Funny how it feels just like being alone...
Funny how it feels just like being alone...
-
patrouchef
- Grenouille enragée
- Messages : 11285
- Enregistré le : mar. 09 juil. 2002, 23:24
- Localisation : Jardin des Hinata
- Contact :
-
Catox
- Otaking !
- Messages : 2783
- Enregistré le : mer. 16 avr. 2003, 13:22
- Localisation : Pertuis
- Contact :
Mais les bibliothèques, ça a "toujours" existé.
Je veux dire, y a pas besoin de regrouper des bibliothèques pour les rendres standards C'était justement l'intérêt de la chose, permettre aux dévellopeurs de difuser des routines utilisables par les autres.
L'intérêt qu'on peut voir là dedans, c'est de faire précharger ces routines par l'utilisateur, et donc d'alléger le programme, plus que la standardisation des routines.
Mais du coup on se retrouve à devoir télcharger 30 Mo pour utiliser un logiciel qui va peut-être n'en prendre qu'un Mo pour gérer l'affichage en arborescence d'une liste d'éléments... superrr...
Enfin, si ça aide vraiment les programmeurs... moi je peux rien dire, j'y pige plus grand chose depuis Windows... j'aimais mieux turbo pascal sous dos ^^
Et Delphi alors dans tout ça ?
- programmation orientée objet (depuis longtemps)
- principe de bibliothèques (depuis longtemps aussi, mais c'est valable pour le C et le basique aussi comme je disais)
Je veux dire, y a pas besoin de regrouper des bibliothèques pour les rendres standards C'était justement l'intérêt de la chose, permettre aux dévellopeurs de difuser des routines utilisables par les autres.
L'intérêt qu'on peut voir là dedans, c'est de faire précharger ces routines par l'utilisateur, et donc d'alléger le programme, plus que la standardisation des routines.
Mais du coup on se retrouve à devoir télcharger 30 Mo pour utiliser un logiciel qui va peut-être n'en prendre qu'un Mo pour gérer l'affichage en arborescence d'une liste d'éléments... superrr...
Enfin, si ça aide vraiment les programmeurs... moi je peux rien dire, j'y pige plus grand chose depuis Windows... j'aimais mieux turbo pascal sous dos ^^
Et Delphi alors dans tout ça ?
- programmation orientée objet (depuis longtemps)
- principe de bibliothèques (depuis longtemps aussi, mais c'est valable pour le C et le basique aussi comme je disais)
Kataouh tataouh
-
jem
- CyberPet
- Messages : 5037
- Enregistré le : mar. 14 oct. 2003, 5:57
- Localisation : les collines gersoises
Le C# dans tout ca c'est un nouveau langage inventé par Microsoft (mais standardisé par l'ECMA donc réutilisable par tout un chacun) pour programmer sur la plateforme .NET.
En gros c'est une evolution du C en direction du Java pour le rendre plus simple et plus objet (exit les pointeurs, les allocations et désallocations mémoires, notamment).
Delphi c'est en gros l'equivalent du Visual Basic mais made in Borland avec une syntaxe issue du Pascal : une plateforme de RAD (Rapid Application Development) avec pas mal d'aides graphiques pour faciliter les taches courantes.
A noter que les dernieres versions de Delphi se basent sur la plateforme .NET, les seuls différences avec VB restent donc l'environnement de développement et le langage.
C'est sûr que déployer 100Mo de biblis en tout genre pour juste une appli, ce n'est pas rentable. L'idée c'est que justement un maximum d'applications utilisent ces biblis pour justement les mutualiser. Là il y a l'enjeu de l'adoption des plateformes par les développeurs qui normalement aboutit à l'adoption pour les utilisateurs.
Comme tu le soulignait, Java a eu pas de mal de problèmes à ce niveau là dans ses premières versions dont les interfaces n'étaient pas top et étaient trop gourmandes pour les machines de l'époque. En même temps l'objectif d'avoir une bibli de GUI unique pour tous les système était très ambitieux.
Ca a pas mal retardé l'adoption de Java pour le développement des applications "lourdes", mais il semble maintenant revenu dans le jeu.
Enfin sur le point de l'interet de la standardisation, le but c'est justement que chaque programme n'ait pas a embarquer les composants dont il a besoin, parce que ca devient très vite le bazar.
Si le Prog1 s'installe avec une lib dans sa version 1.0
et que le Prog2 s'installe avec la même lib mais dans sa version 2.0, il va y avoir conflit.
D'autant plus si la lib n'est pas rétrocompatible. On se retrouvera alors avec fatalement l'un des deux programmes qui ne marche pas.
Dans certains cas, Windows peut même s'opposer au downgrade d'une lib déjà installé.
Java n'est pas totalement exempt de ce problème avec les différentes versions d'un JAR qui peuvent etre présentes sur un système et dont la prédominance changera suivant le CLASSPATH utilisé pour lancer le programme.
D'ou l'interet d'un jeu de libs très large, qui ne change de version que tous les 4 ou 5 ans, ce qui limite fortement la concurrence des versions sur un même système.
En gros c'est une evolution du C en direction du Java pour le rendre plus simple et plus objet (exit les pointeurs, les allocations et désallocations mémoires, notamment).
Delphi c'est en gros l'equivalent du Visual Basic mais made in Borland avec une syntaxe issue du Pascal : une plateforme de RAD (Rapid Application Development) avec pas mal d'aides graphiques pour faciliter les taches courantes.
A noter que les dernieres versions de Delphi se basent sur la plateforme .NET, les seuls différences avec VB restent donc l'environnement de développement et le langage.
C'est sûr que déployer 100Mo de biblis en tout genre pour juste une appli, ce n'est pas rentable. L'idée c'est que justement un maximum d'applications utilisent ces biblis pour justement les mutualiser. Là il y a l'enjeu de l'adoption des plateformes par les développeurs qui normalement aboutit à l'adoption pour les utilisateurs.
Comme tu le soulignait, Java a eu pas de mal de problèmes à ce niveau là dans ses premières versions dont les interfaces n'étaient pas top et étaient trop gourmandes pour les machines de l'époque. En même temps l'objectif d'avoir une bibli de GUI unique pour tous les système était très ambitieux.
Ca a pas mal retardé l'adoption de Java pour le développement des applications "lourdes", mais il semble maintenant revenu dans le jeu.
Enfin sur le point de l'interet de la standardisation, le but c'est justement que chaque programme n'ait pas a embarquer les composants dont il a besoin, parce que ca devient très vite le bazar.
Si le Prog1 s'installe avec une lib dans sa version 1.0
et que le Prog2 s'installe avec la même lib mais dans sa version 2.0, il va y avoir conflit.
D'autant plus si la lib n'est pas rétrocompatible. On se retrouvera alors avec fatalement l'un des deux programmes qui ne marche pas.
Dans certains cas, Windows peut même s'opposer au downgrade d'une lib déjà installé.
Java n'est pas totalement exempt de ce problème avec les différentes versions d'un JAR qui peuvent etre présentes sur un système et dont la prédominance changera suivant le CLASSPATH utilisé pour lancer le programme.
D'ou l'interet d'un jeu de libs très large, qui ne change de version que tous les 4 ou 5 ans, ce qui limite fortement la concurrence des versions sur un même système.
I found my freedom now.
Funny how it feels just like being alone...
Funny how it feels just like being alone...
-
Catox
- Otaking !
- Messages : 2783
- Enregistré le : mer. 16 avr. 2003, 13:22
- Localisation : Pertuis
- Contact :
"tous les 5 ans"
ça limite un peu l'accessibilité aux évolutions...
Y a un vague air de "je m'appelle microsoft et je mange le monde"
Je sais, je sais, tes arguments sont tout à fait valides et je suis un peu beaucoup un anti-microsoft primaire (à part pour Excel, c'est mon copain lui), mais quand même... c'est un peu vrai aussi quoi ^^
(ben si, quand même)
ça limite un peu l'accessibilité aux évolutions...
Y a un vague air de "je m'appelle microsoft et je mange le monde"
Je sais, je sais, tes arguments sont tout à fait valides et je suis un peu beaucoup un anti-microsoft primaire (à part pour Excel, c'est mon copain lui), mais quand même... c'est un peu vrai aussi quoi ^^
(ben si, quand même)
Kataouh tataouh
-
jem
- CyberPet
- Messages : 5037
- Enregistré le : mar. 14 oct. 2003, 5:57
- Localisation : les collines gersoises
Dans quel sens ca limite ? Parce que là chaque version est un grand pas en avant et il faut un moment aux développeurs pour le digérer.Catox a écrit :"tous les 5 ans"
ça limite un peu l'accessibilité aux évolutions...
Y a un vague air de "je m'appelle microsoft et je mange le monde"
Déjà à la sortie du .NET 1.0, les développeurs VB ont du se mettre à la vrai programmation objet et tout le monde à du retrouver ses petits parmi quelques 4760 classes et 120 000 méthodes.
4 ans plus tard le .NET 2.0 en a modifié ou ajouter quasiment autant
et seulement 1 an plus tard le .NET 3.0 ajoute les librairies de programmation Vista.
J'aime autant te dire que du point de vue des développeurs c'est déjà un rythme assez chaud à suivre.
Après pour le côté "je mange le monde", je pense que microsoft à plutot couru après Java qui avait pris pas mal d'avance et est encore loin de le rattraper en terme d'adoption, au moins pour les applis Web et serveur.
I found my freedom now.
Funny how it feels just like being alone...
Funny how it feels just like being alone...
-
Klaim
- Artisan Digital
- Messages : 10635
- Enregistré le : mar. 27 mai 2003, 13:13
- Localisation : Paris
- Contact :
Ptain une discussion de geek et je suis même pas dans le coup 
Catox> A propos des languages, il faut bien comprendre que chaque language a des qualités et des défauts (toujours) propres et qu'un bon programmeur va utiliser un language plutot qu'un autre selon ce qui est le plus adapté et non selon son bon plaisir.
En gros :
- Java est lent, ultra gourmand en mémoire, difficile à mettre en place de façon stable (poru les grosses appli bancaires par exemple) mais a l'avantage d'être facilement compréhensible (comprenez, ne nécessite pas d'être une brute en code/programmation) et permet de faire rapidement des logiciels à interface (donc permet de faire rapidement des trucs du genre editeur ou gestionnaire). Un programme Java est censé marcher sur n'importe quoi, mais c'est une légende.
- C# c'est comme java en plus rapide. (pour résumer) et en mieu foutu (ils font pas les mêmes erreurs mais globalement c'est la même philosophie) mais qui marche que sous windows (enfin sur linux aussi avec Mono mais ppas trop à jour. cela va bientot changer parceque microsoft fait des accord avec des gens de linux pour que leurs programmes marchent sur Suse(qui est un linux)).
- delphi et VB : ciblé pour ceux qui ne saventpas programmer (les commerciaux touches à tout), pratique pour comprendre comment on fait une interface mais galère quand tu veux faire quelque chose de sérieux;
Les languages précédents sont dit "de haut niveau" ou de "haute couche" parceque tu peux pas toucher directement à la machine , tu en es "loin" et donc c'est plus lent que si tu as accès directement à la machine.
Mais quand tu as accès à la machine, tu as tous les pouvoirs et surtout celui de foutre la merde. Autrement dit ça nécessite de la maitrise, et au mieu de l'expérience.
Si t'y va en Assembleur, tu fais directement joujou avec le processeur. Le problème c'est qu'a partir d'un grand nombre d'instructions tu captes plus rien a ton programme, et puis c'est pas très lisible de base.
Du coup ya le C et sont "amélioration" le C++ qui permet donc d'écrire un programme en gros comme en C# ou en Java MAIS en ayant la maitrise de la machien, et donc la puissance.
La différence de vitesse est incomparable entre C/C++ et les autres cités au dessus, d'où son utililsation pour la plupart des jeux.
Les jeux ne nécessitant pas un max de puissance n'ont pas besoin de ce language, mais c'est assez rare finalement.
En gros dans l'industrie ya pas mal de C# pour fabriquer les editeurs surtout, les outils, parceque c'est vraiment le language le plus adapté. Mais ensuite DANS le jeu, faut que ce soit rapide, sauf certaines parties, genre les scripts (qui sont en fait du code spécial qu'on peut changer facilement et qui permettent de modifier les paramettres d'un jeu par exemple).
Voilà en gros.
Sinon j'ai des liens vers des discussions a propos des languages si tu veux mais tu risques de pas tout capter...
Catox> A propos des languages, il faut bien comprendre que chaque language a des qualités et des défauts (toujours) propres et qu'un bon programmeur va utiliser un language plutot qu'un autre selon ce qui est le plus adapté et non selon son bon plaisir.
En gros :
- Java est lent, ultra gourmand en mémoire, difficile à mettre en place de façon stable (poru les grosses appli bancaires par exemple) mais a l'avantage d'être facilement compréhensible (comprenez, ne nécessite pas d'être une brute en code/programmation) et permet de faire rapidement des logiciels à interface (donc permet de faire rapidement des trucs du genre editeur ou gestionnaire). Un programme Java est censé marcher sur n'importe quoi, mais c'est une légende.
- C# c'est comme java en plus rapide. (pour résumer) et en mieu foutu (ils font pas les mêmes erreurs mais globalement c'est la même philosophie) mais qui marche que sous windows (enfin sur linux aussi avec Mono mais ppas trop à jour. cela va bientot changer parceque microsoft fait des accord avec des gens de linux pour que leurs programmes marchent sur Suse(qui est un linux)).
- delphi et VB : ciblé pour ceux qui ne saventpas programmer (les commerciaux touches à tout), pratique pour comprendre comment on fait une interface mais galère quand tu veux faire quelque chose de sérieux;
Les languages précédents sont dit "de haut niveau" ou de "haute couche" parceque tu peux pas toucher directement à la machine , tu en es "loin" et donc c'est plus lent que si tu as accès directement à la machine.
Mais quand tu as accès à la machine, tu as tous les pouvoirs et surtout celui de foutre la merde. Autrement dit ça nécessite de la maitrise, et au mieu de l'expérience.
Si t'y va en Assembleur, tu fais directement joujou avec le processeur. Le problème c'est qu'a partir d'un grand nombre d'instructions tu captes plus rien a ton programme, et puis c'est pas très lisible de base.
Du coup ya le C et sont "amélioration" le C++ qui permet donc d'écrire un programme en gros comme en C# ou en Java MAIS en ayant la maitrise de la machien, et donc la puissance.
La différence de vitesse est incomparable entre C/C++ et les autres cités au dessus, d'où son utililsation pour la plupart des jeux.
Les jeux ne nécessitant pas un max de puissance n'ont pas besoin de ce language, mais c'est assez rare finalement.
En gros dans l'industrie ya pas mal de C# pour fabriquer les editeurs surtout, les outils, parceque c'est vraiment le language le plus adapté. Mais ensuite DANS le jeu, faut que ce soit rapide, sauf certaines parties, genre les scripts (qui sont en fait du code spécial qu'on peut changer facilement et qui permettent de modifier les paramettres d'un jeu par exemple).
Voilà en gros.
Sinon j'ai des liens vers des discussions a propos des languages si tu veux mais tu risques de pas tout capter...
Modifié en dernier par Klaim le mar. 28 nov. 2006, 13:08, modifié 1 fois.
