"à priori ça sera transparent"
En général si tu corrige un bug, tu modifies aussi le comportement vu de l'extérieur de ta classe, sinon c'est que ton bug n'avait aucun inpact extérieur, et donc aucun intérêt à être corrigé ;)
Pour le classpath, voilà quoi. L'idée est quand même de déployer à un même endroit les bibliothèques, afin de faciliter le partage entre les appli, les maj, etc. Modifier le classpath ca relève plus de la bidouille, qui au passage demande une opération de la part de l'utilisateur, ce qui chez madame michou n'est peut être pas très simple ;)
Zope est effectivement un serveur d'application, mais depuis le temps qu'il existe, il n'a jamais vraiment persé. Je ne vais pas me risquer à donner une explication puisque je n'ai pas eu l'occasion de l'essayer.
Pour Rails, voilà quoi. Tu les gères comment les transactions ? C'est quoi le modèle de composant ?
Si je prend un exemple de simple logiciel comme blender qui utilisent des plugins python, il démarre beaucoup plus vite et charge bien moins mon processeur que beaucoup d'appli java bien moins complexes.
Quel est le rapport entre une appli Desktop et une appli d'entreprise qui tourne sur un serveur d'application ?
IBM devrait passer sur un framework mixe JAVA/php dans leurs futurs serveurs d'applications
Effectivement, Sun tente de rapprocher les 2 langages, mais PHP resterait le langage de "facade", pour la partie présentation, Java est gardé pour la partie métier. Enfin si les JSF évoluent en parallèle et gagne en puissance, PHP n'aura plus beaucoup d'intérêt.
Avoir une plateforme unifiée sans mélanger pleins de technos, c'est une grande facilité de maintenance.
tu fais vraiment fashion -victime de la programmation.
Si j'étais une fashion victime, je serais en train de coder avec Ruby on Rails, avec une touche de Ajax.
Gni ? Quel est le rapport avec le suivi de projet ?
Il est quand même fréquent de devoir déployer une appli, et que le client/utilisateur est déjà une appli qui utilise les mêmes dll, mais pas avec la même version... Il est donc très utile d'avoir les 2 versions en parallèle (pour éviter le fameux DLL Hell).
Ensuite il peut également être courant qu'une classe implémente 2 interface (tirées de 2 bibliothèques par exemples) qui ont en commun une signature de méthode... Quel est le rapport avec le suivi de projet et la gestion de conf ???
Un exemple de problème en Java :
tu concois une bibliothèque de fonction, du la déploie, des clients l'utilise à travers des applications.
tu trouves un bug : tu modifies une fonction pour qu'elle lève une exception, tu redéploie. Les cliens récupère ta bibliothèque mais ne recompile pas leurs applications (z'ont pas forcement les sources) : pouf on a une exception non checkée : ke passa à l'exécution ?
Dans Java le versionning c'est pas folichon (pour ne pas dire inexistant), par contre dans .NET c'est le pied : http://www.theserverside.net/articles/showarticle.tss?id=AssemblyVe(...)
En gros la moindre définition de classe, d'interface, d'assembly est versionné. On peut charger 2 versions différentes d'une même classe, tu peux signer une classe, etc. Pour éviter les conflits lors de déploiement ou de mises à jour c'est le pied.
le langage C# censé tiré pleinement parti du framework a été aussi conçu dans cet objectif, c'est pourquoi on ne retrouve pas entre autre la propagation des exceptions comme en Java, la possibilité de spécifier quelle méthode de quelle interface on implémente (2 interfaces pouvant avoir 2 méthodes avec la même signature, en Java tu as conflits), etc.
Ces langages peuvent tout à fait être adaptés à de gros projets, l'important étant de bien choisir le framework sur lequel tu vas développer. Les composants, ça se définit, le serveur d'application tu le codes, tout ces addons existent et sont déjà utilisables.
Bah vas-y, fais le en assembleur ! C'est vrai quoi, les API, ca se code, le serveur d'application aussi, etc.
Visiblement tu ne sais pas ce qu'est un composant et un serveur d'application. Vas voir les specs de .NET/COM+ et J2EE, après tu reviens discuter.
En creusant un peu on peut tout de même trouver un troll caché :
Qt c'est TrollTech. Les releases principales de KDE sont régulées sur les release de Qt, bref l'environnement KDE est fortement dépendant de TrollTech, et donc d'une entreprise commerciale. TrollTech a changé les conditions de licence pour Windows cette fois-ci, rien ne les empêchera de changer la licence dans le futur vers quelque chose de moins (voir non-) libre.
Bon ok c'est tiré par les cheveux, mais bon c'est TrollTech, ils ont des techniques cachés pour nous pondre des trolls ;)
~~~~>[]
le contrôle aérien est beaucoup trop complexe pour être programmé.
J'ai dis on confie le "maximum". Quand c'est trop complexe et pas faisable on fait pas forcement.
on avait essayé d'informatiser une partie du métier de contrôleur aérien
On avait "essayer". Z'ont pas réussi, mais c'est pas pour ca que ce n'est plus dans leur objectif.
Je vois pas le rapport.
Le système lui a peut être demandé confirmation, et par "habitude" a confirmé. Après ce n'est peut être pas une simple opératrice, elle doit avoir des responsabilités pour pouvoir manipuler ce genre de montant, auquel cas elle doit assumer son erreur, même si l'ordinateur n'a pas assez "averti".
T'es employé dans un magasin et tu oublies de fermer à clé la boutique en partant le soir alors que c'est quelque chose d'habituel, c'est une faute professionnelle.
De toute façon on n'a pas les détails techniques, on ne sait pas à quel niveau elle a effectuée l'erreur, ni quel niveau d'avertissement elle a eu de la part de l'ordinateur, si elle a eu à confirmer, etc.
Ce qui est sûr c'est que c'est l'humain qui a commis l'erreur, l'ordinateur ne l'a peut être pas assez averti mais l'erreur est humaine, et la responsabilité de l'opératrice sans doute en jeu.
Java a été nomé pour la première fois dans le post juste avant le tien, pas avant...
J'ai voulu proposer une solution pour le cas du journal : en l'occurence le projet Struts est en Java.
Ben en fait d'après ce que j'en avais lu moi, c'est qu'il n'y avait pas la même culture côté "russe" que côté européen : côté européen le pilote fait "confiance" à la technique, alors que côté russe, non pas qu'on fasse plus confiance à l'humain, mais on est habitué à "obéir" (lourd héritage politique derrière oblige), ce qui ne déclenche apparement pas les mêmes "réflexes" chez les pilotes. Enfin tout ca pour dire que l'ordinateur a cet avantage de ne pas réfléchir. Parfois ca aide. On s'en appercoit assez souvent au recrutement des militaires destinées aux premières lignes :-/
Existe-t-il un compilo bien optimisé qui me permette de reproduire le tout chez moi?
Tu mélange les 2 gaz, et tu prends le compilo qui tue : une allumette. Fait gaffe c'est assez rapide comme compilation, et résultat assez percutant ;)
Bah faut qu'ils rassurent leurs actionnaires. Quand à la "pauvre" opératrice comme tu dis, elle a tout de même fait une grave faute professionnelle il me semble. Elle n'a pas à assumer les responsabilités financières, mais elle doit quand même assumer ses responsabilité d'opératrice.
C'est étrange, ce discours me fait penser aux arguments de microsoft sur la qualité des logiciels libres...
Quel est le rapport ? Beaucoup d'applications "libres" suivent ce processus de "stabilité" avec des phases de tests, etc.
, mais de permettre à un développeur amateur de contribuer plus facilement à un projet, en rajoutant des fonctions à un programme.
Et pour un développeur amateur, il n'y a aucun intérêt de lui proposer la possibilité de modifier en live l'application. Il télécahrge la version "devel" et zou.
N'oublie pas que je parle au futur.
Donc dans le futur, tout ce qu'apporte la phase de compilation deviendra inutile, que ce soit en matière de perf ou de sécurité ? Comme je l'ai déjà dis, les applis vont "grossir", et ce qui va devenir important c'est de s'assurer de la qualité d'un logiciel : et pour ca un compilateur est un outil automatique qui s'inscrit dans cette stratégie, contrairement aux langages Python ou Ruby qui vont complètement à l'opposé.
Les machines étant de plus en plus puissantes, ces langages permettront d'écrire des applications de plus en plus grosses tout en étant suffisament rapides pour être exploitables.
Les machines deviennent de plus en plus puissantes, mais les applications sont de plus en plus grosses : conclusion il y a a toujours le problème des perfs, que tu le veuilles ou non.
De plus tu ne sembles pas du tout prendre la "dimension" d'un projet : les langages comme Perl Ruby ou Python ne sont pas du tout armés pour passer à l'échelle, il n'y a absoluement aucune notion de composant, et encore moins de serveur d'application avec tout ce qui va avec (transaction,etc.).
Il n'y a pas non plus de gestion du versionning.
Bref, ces langages ne sont pas adaptés aux "gros" projets, et se cantonneront aux petites appli "destkop" style "front-end", à moins qu'ils évoluent.
Si vous devez écrire une grosse application libre, dont le rapidité n'est pas primordiale, alors écrivez là dans un langage interprété.
Pourquoi tu t'obstines à vouloir opposer C/C++ à Ruby/Python ? Des langages "intermédiaires" comme Java ou C# ont la plupart des qualités de Ruby/Python (en terme de lisibilité, maintenance) avec en plus la sécurité d'un langage compilé et des perfs moins désastreuses.
Ecriture d'applications en assemblant les composants
Cf ma remarque plus haut : les langages Ruby ou Python n'ont pas du tout de modèle de composant et de gestion de version associés.
Tu considères mal.
Même si pour toi le montant parraît abberrant, c'est relativement courant dans le milieu des affaires. L'ordinateur est pas censé savoir que tu t'es planté d'action, etc. Si la secrétaire demande le mauvais ordre, c'est un mauvais ordre qui sera exécuté. En l'occurence l'ordre passé est tout à fait "normal" (c'est pourquoi il n'a pas été détecté), même si ce n'est pas celui initialement demandé.
S'il met 20 ans à mourir, c'est bien qu'il était fait pour durer :)
Oué mais c'est pas forcement l'avenir.
Combien de compilateur/jvm sont capables de gérer totalement les specs (même 1.4.2) ? Sur combien de plateformes ?
Il y en a au moins 1. Et visiblement tu confond alégrement les specs du langage et les API (référence au 1.4.2). Java est beaucoup plus récent que C++, et bizzarement il est beaucoup plus "stable", il n'y a eu qu'une seule évolution majeure, qui date d'il y a 1 an. GCJ gère parfaitement les dernières nouveautés de Java, le problème c'est les API. En C++ t'as pas le problème vu qu'il n'y a aucun API normalisé.
GNU Classpath avance, mais c'est pas encore le pied. Pour les compilateurs...euh :)
Blablabla, API != langage. On parle du langage pas des APIs. Si tu veux comparer tu prends les APIs les plus communs de C++ et tu regardes leur évolution. Prend l'exemple du support des templates par exemple.
vois que python n'est pas non plus super d'un point de vue efficacité sur ce genre de plateforme, et je ne parle pas de chose système/bas niveau là...
y'a des intermédiaire entre Python et C pour l'embarqué.
Dans les deux cas, le système est en cause, je suppose qu'il faudrait que de telles opérations soient validées.
Genre tu crois que dans le nucléaire elles n'ont pas besoin d'être validées. Et puis il y a un certains nombre de système de sécurités pour empêcher de faire une connerie, même validée.
En gros les controleurs contraignent les avions a un niveau de vol, apres si les pilotes ne les respectent pas...
Bah justement, le contrôleur a indiqué au pilote russe de monter ou descendre (je sais plus), et l'ordinateur de bord indiqué le contraire. Le russe a fait confiance à l'humain, et craque.
C'est une erreur humaine, pas informatique.
Le programme aurait été buggué et aurait lui même effectuée une mauvaise opération ok, mais là c'est l'opératrice qui s'est gourré.
Je te rassures, dans le nucléraire, c'est surement pas une secrétaire qui en glissant sur son clavier manipule les réacteurs ;)
Quand au contrôle aérien, voir même au pilotage aérien, pour justement éviter ce genre de problème typiquement "humain", on confie le maximum de boulot aux ordinateurs. Cf le magnifique "crash" en plein vole au dessus d'un lac (en Autriche il me semble) entre 2 avions : les ordinateurs de bord s'étaient accordés pour que l'un monte et l'autre descende, et ben c'est le pilote russe qui, habituer à obénir aux ordres humains n'a pas privilégier l'ordre de son ordinateur.
Google -> repose sur des outils systèmes entièrement en C
Oué comme je l'ai dis, pour les parties "systèmes", mais pas pour la partie "métier" et "présentation".
au moins elles auraient été débugguées
Imagine qu'elle te fasse une fuite mémoire suivit d'un segmentation fault ;)
Ma hotline, elle utilise sûrement Oracle, qui n'a pas été développé en ruby à ma connaissance :)
C'est vrai, le hotlineur il est sûrement en bash, il a taper oracle-client puis tapes "insert requete into trash", non mais franchement :)
Reprend mon post depuis le début : j'ai dis clairement que là où le C perd et perdra du terrain, c'est sur les parties "logicielles" et non "techniques". Enfin si tu vois ce que je veux dire.
Ca me fait doucement rigoler, ça... Je te sens un peu naïf sur ce coup là :)
?
C++, tu es garantie d'en avoir pour encore au moins 20 ans, vu la stabilité du langage.
Oué bah oué, et ? C'est pas pour autant qu'il a de l'avenir :) Sa mort sera lente ca c'est sûr. Autant je crois que le C a de l'avenir dans certains domaines, autant le C++ n'en a pas beaucoup à mon goût.
Et puis bon la stabilité du C++ mdr quoi :) Ca date de quand les dernières spécif déjà ? Y'a combien de compilateur capable de gérer toutes les spec parfaitement ?
. Java, tu es obligé de réapprendre constamment
Gni ? Ce qui change c'est les API, ils évoluent, et ils faut effectivement se "tenir au courant". Mais en C++ tu n'utilises aucun API toi ?
il faut plus d'un an pour être expert Java :)
Pour être expert dans le langage si. Après pour les API c'est une autre histoire, mais c'est le même problème dans tous les langages.
Ah oui j'oubliais, tu dis n'utiliser que des petits projets au quotidien :
tu n'utilises jamais Google ? Tu ne vas jamais sur le site de ta banque ? Sur un portail d'information ? Faudrait pas oublier les applications web hein ;) Et là le C voilà quoi ;)
Et puis pendant que j'y suis : tu n'appelles jamais de hotline, tu ne vas jamais chez un commercant ? Non parcque sans le savoir tu utilises des grosses applications ;)
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 2.
En général si tu corrige un bug, tu modifies aussi le comportement vu de l'extérieur de ta classe, sinon c'est que ton bug n'avait aucun inpact extérieur, et donc aucun intérêt à être corrigé ;)
Pour le classpath, voilà quoi. L'idée est quand même de déployer à un même endroit les bibliothèques, afin de faciliter le partage entre les appli, les maj, etc. Modifier le classpath ca relève plus de la bidouille, qui au passage demande une opération de la part de l'utilisateur, ce qui chez madame michou n'est peut être pas très simple ;)
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 2.
Pour Rails, voilà quoi. Tu les gères comment les transactions ? C'est quoi le modèle de composant ?
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 1.
Quel est le rapport entre une appli Desktop et une appli d'entreprise qui tourne sur un serveur d'application ?
IBM devrait passer sur un framework mixe JAVA/php dans leurs futurs serveurs d'applications
Effectivement, Sun tente de rapprocher les 2 langages, mais PHP resterait le langage de "facade", pour la partie présentation, Java est gardé pour la partie métier. Enfin si les JSF évoluent en parallèle et gagne en puissance, PHP n'aura plus beaucoup d'intérêt.
Avoir une plateforme unifiée sans mélanger pleins de technos, c'est une grande facilité de maintenance.
tu fais vraiment fashion -victime de la programmation.
Si j'étais une fashion victime, je serais en train de coder avec Ruby on Rails, avec une touche de Ajax.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 2.
Il est quand même fréquent de devoir déployer une appli, et que le client/utilisateur est déjà une appli qui utilise les mêmes dll, mais pas avec la même version... Il est donc très utile d'avoir les 2 versions en parallèle (pour éviter le fameux DLL Hell).
Ensuite il peut également être courant qu'une classe implémente 2 interface (tirées de 2 bibliothèques par exemples) qui ont en commun une signature de méthode... Quel est le rapport avec le suivi de projet et la gestion de conf ???
Un exemple de problème en Java :
tu concois une bibliothèque de fonction, du la déploie, des clients l'utilise à travers des applications.
tu trouves un bug : tu modifies une fonction pour qu'elle lève une exception, tu redéploie. Les cliens récupère ta bibliothèque mais ne recompile pas leurs applications (z'ont pas forcement les sources) : pouf on a une exception non checkée : ke passa à l'exécution ?
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 2.
http://www.theserverside.net/articles/showarticle.tss?id=AssemblyVe(...)
En gros la moindre définition de classe, d'interface, d'assembly est versionné. On peut charger 2 versions différentes d'une même classe, tu peux signer une classe, etc. Pour éviter les conflits lors de déploiement ou de mises à jour c'est le pied.
le langage C# censé tiré pleinement parti du framework a été aussi conçu dans cet objectif, c'est pourquoi on ne retrouve pas entre autre la propagation des exceptions comme en Java, la possibilité de spécifier quelle méthode de quelle interface on implémente (2 interfaces pouvant avoir 2 méthodes avec la même signature, en Java tu as conflits), etc.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 0.
Bah vas-y, fais le en assembleur ! C'est vrai quoi, les API, ca se code, le serveur d'application aussi, etc.
Visiblement tu ne sais pas ce qu'est un composant et un serveur d'application. Vas voir les specs de .NET/COM+ et J2EE, après tu reviens discuter.
[^] # Re: 80% du marché bientôt?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4. Évalué à 5.
http://osnews.com/story.php?news_id=10731(...)
Gnome est devant KDE qui n'a que 33% d'utilisateurs. Comme quoi on fait dire ce qu'on veut aux sondages.
il faudrait qu'il accélère leurs discution pour utiliser un langage plus haut niveau...
Il serait temps que KDE y réfléchisse aussi ;)
[^] # Re: Un nouveau troll !
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4. Évalué à 1.
Qt c'est TrollTech. Les releases principales de KDE sont régulées sur les release de Qt, bref l'environnement KDE est fortement dépendant de TrollTech, et donc d'une entreprise commerciale. TrollTech a changé les conditions de licence pour Windows cette fois-ci, rien ne les empêchera de changer la licence dans le futur vers quelque chose de moins (voir non-) libre.
Bon ok c'est tiré par les cheveux, mais bon c'est TrollTech, ils ont des techniques cachés pour nous pondre des trolls ;)
~~~~>[]
# !
Posté par TImaniac (site web personnel) . En réponse au journal Qt 4.0.0. Évalué à 2.
[^] # Re: mouais
Posté par TImaniac (site web personnel) . En réponse au journal Petite et grandes erreurs informatiques. Évalué à 0.
J'ai dis on confie le "maximum". Quand c'est trop complexe et pas faisable on fait pas forcement.
on avait essayé d'informatiser une partie du métier de contrôleur aérien
On avait "essayer". Z'ont pas réussi, mais c'est pas pour ca que ce n'est plus dans leur objectif.
[^] # Re: mouais
Posté par TImaniac (site web personnel) . En réponse au journal Petite et grandes erreurs informatiques. Évalué à 2.
Le système lui a peut être demandé confirmation, et par "habitude" a confirmé. Après ce n'est peut être pas une simple opératrice, elle doit avoir des responsabilités pour pouvoir manipuler ce genre de montant, auquel cas elle doit assumer son erreur, même si l'ordinateur n'a pas assez "averti".
T'es employé dans un magasin et tu oublies de fermer à clé la boutique en partant le soir alors que c'est quelque chose d'habituel, c'est une faute professionnelle.
De toute façon on n'a pas les détails techniques, on ne sait pas à quel niveau elle a effectuée l'erreur, ni quel niveau d'avertissement elle a eu de la part de l'ordinateur, si elle a eu à confirmer, etc.
Ce qui est sûr c'est que c'est l'humain qui a commis l'erreur, l'ordinateur ne l'a peut être pas assez averti mais l'erreur est humaine, et la responsabilité de l'opératrice sans doute en jeu.
[^] # Re: editeur à la place de l'IDE
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 3.
J'ai voulu proposer une solution pour le cas du journal : en l'occurence le projet Struts est en Java.
[^] # Re: mouais
Posté par TImaniac (site web personnel) . En réponse au journal Petite et grandes erreurs informatiques. Évalué à 3.
[^] # Re: Bière open source
Posté par TImaniac (site web personnel) . En réponse au journal Un bière OpenSource. Évalué à 4.
Tu mélange les 2 gaz, et tu prends le compilo qui tue : une allumette. Fait gaffe c'est assez rapide comme compilation, et résultat assez percutant ;)
[^] # Re: cynique
Posté par TImaniac (site web personnel) . En réponse au journal Petite et grandes erreurs informatiques. Évalué à 3.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 2.
Quel est le rapport ? Beaucoup d'applications "libres" suivent ce processus de "stabilité" avec des phases de tests, etc.
, mais de permettre à un développeur amateur de contribuer plus facilement à un projet, en rajoutant des fonctions à un programme.
Et pour un développeur amateur, il n'y a aucun intérêt de lui proposer la possibilité de modifier en live l'application. Il télécahrge la version "devel" et zou.
N'oublie pas que je parle au futur.
Donc dans le futur, tout ce qu'apporte la phase de compilation deviendra inutile, que ce soit en matière de perf ou de sécurité ? Comme je l'ai déjà dis, les applis vont "grossir", et ce qui va devenir important c'est de s'assurer de la qualité d'un logiciel : et pour ca un compilateur est un outil automatique qui s'inscrit dans cette stratégie, contrairement aux langages Python ou Ruby qui vont complètement à l'opposé.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 1.
Les machines deviennent de plus en plus puissantes, mais les applications sont de plus en plus grosses : conclusion il y a a toujours le problème des perfs, que tu le veuilles ou non.
De plus tu ne sembles pas du tout prendre la "dimension" d'un projet : les langages comme Perl Ruby ou Python ne sont pas du tout armés pour passer à l'échelle, il n'y a absoluement aucune notion de composant, et encore moins de serveur d'application avec tout ce qui va avec (transaction,etc.).
Il n'y a pas non plus de gestion du versionning.
Bref, ces langages ne sont pas adaptés aux "gros" projets, et se cantonneront aux petites appli "destkop" style "front-end", à moins qu'ils évoluent.
Si vous devez écrire une grosse application libre, dont le rapidité n'est pas primordiale, alors écrivez là dans un langage interprété.
Pourquoi tu t'obstines à vouloir opposer C/C++ à Ruby/Python ? Des langages "intermédiaires" comme Java ou C# ont la plupart des qualités de Ruby/Python (en terme de lisibilité, maintenance) avec en plus la sécurité d'un langage compilé et des perfs moins désastreuses.
Ecriture d'applications en assemblant les composants
Cf ma remarque plus haut : les langages Ruby ou Python n'ont pas du tout de modèle de composant et de gestion de version associés.
[^] # Re: mouais
Posté par TImaniac (site web personnel) . En réponse au journal Petite et grandes erreurs informatiques. Évalué à 0.
Même si pour toi le montant parraît abberrant, c'est relativement courant dans le milieu des affaires. L'ordinateur est pas censé savoir que tu t'es planté d'action, etc. Si la secrétaire demande le mauvais ordre, c'est un mauvais ordre qui sera exécuté. En l'occurence l'ordre passé est tout à fait "normal" (c'est pourquoi il n'a pas été détecté), même si ce n'est pas celui initialement demandé.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 2.
Oué mais c'est pas forcement l'avenir.
Combien de compilateur/jvm sont capables de gérer totalement les specs (même 1.4.2) ? Sur combien de plateformes ?
Il y en a au moins 1. Et visiblement tu confond alégrement les specs du langage et les API (référence au 1.4.2). Java est beaucoup plus récent que C++, et bizzarement il est beaucoup plus "stable", il n'y a eu qu'une seule évolution majeure, qui date d'il y a 1 an. GCJ gère parfaitement les dernières nouveautés de Java, le problème c'est les API. En C++ t'as pas le problème vu qu'il n'y a aucun API normalisé.
GNU Classpath avance, mais c'est pas encore le pied. Pour les compilateurs...euh :)
Blablabla, API != langage. On parle du langage pas des APIs. Si tu veux comparer tu prends les APIs les plus communs de C++ et tu regardes leur évolution. Prend l'exemple du support des templates par exemple.
vois que python n'est pas non plus super d'un point de vue efficacité sur ce genre de plateforme, et je ne parle pas de chose système/bas niveau là...
y'a des intermédiaire entre Python et C pour l'embarqué.
[^] # Re: mouais
Posté par TImaniac (site web personnel) . En réponse au journal Petite et grandes erreurs informatiques. Évalué à 6.
Genre tu crois que dans le nucléaire elles n'ont pas besoin d'être validées. Et puis il y a un certains nombre de système de sécurités pour empêcher de faire une connerie, même validée.
[^] # Re: mouais
Posté par TImaniac (site web personnel) . En réponse au journal Petite et grandes erreurs informatiques. Évalué à 3.
Bah justement, le contrôleur a indiqué au pilote russe de monter ou descendre (je sais plus), et l'ordinateur de bord indiqué le contraire. Le russe a fait confiance à l'humain, et craque.
# mouais
Posté par TImaniac (site web personnel) . En réponse au journal Petite et grandes erreurs informatiques. Évalué à 6.
Le programme aurait été buggué et aurait lui même effectuée une mauvaise opération ok, mais là c'est l'opératrice qui s'est gourré.
Je te rassures, dans le nucléraire, c'est surement pas une secrétaire qui en glissant sur son clavier manipule les réacteurs ;)
Quand au contrôle aérien, voir même au pilotage aérien, pour justement éviter ce genre de problème typiquement "humain", on confie le maximum de boulot aux ordinateurs. Cf le magnifique "crash" en plein vole au dessus d'un lac (en Autriche il me semble) entre 2 avions : les ordinateurs de bord s'étaient accordés pour que l'un monte et l'autre descende, et ben c'est le pilote russe qui, habituer à obénir aux ordres humains n'a pas privilégier l'ordre de son ordinateur.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 3.
Oué comme je l'ai dis, pour les parties "systèmes", mais pas pour la partie "métier" et "présentation".
au moins elles auraient été débugguées
Imagine qu'elle te fasse une fuite mémoire suivit d'un segmentation fault ;)
Ma hotline, elle utilise sûrement Oracle, qui n'a pas été développé en ruby à ma connaissance :)
C'est vrai, le hotlineur il est sûrement en bash, il a taper oracle-client puis tapes "insert requete into trash", non mais franchement :)
Reprend mon post depuis le début : j'ai dis clairement que là où le C perd et perdra du terrain, c'est sur les parties "logicielles" et non "techniques". Enfin si tu vois ce que je veux dire.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 3.
?
C++, tu es garantie d'en avoir pour encore au moins 20 ans, vu la stabilité du langage.
Oué bah oué, et ? C'est pas pour autant qu'il a de l'avenir :) Sa mort sera lente ca c'est sûr. Autant je crois que le C a de l'avenir dans certains domaines, autant le C++ n'en a pas beaucoup à mon goût.
Et puis bon la stabilité du C++ mdr quoi :) Ca date de quand les dernières spécif déjà ? Y'a combien de compilateur capable de gérer toutes les spec parfaitement ?
. Java, tu es obligé de réapprendre constamment
Gni ? Ce qui change c'est les API, ils évoluent, et ils faut effectivement se "tenir au courant". Mais en C++ tu n'utilises aucun API toi ?
il faut plus d'un an pour être expert Java :)
Pour être expert dans le langage si. Après pour les API c'est une autre histoire, mais c'est le même problème dans tous les langages.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 1.
tu n'utilises jamais Google ? Tu ne vas jamais sur le site de ta banque ? Sur un portail d'information ? Faudrait pas oublier les applications web hein ;) Et là le C voilà quoi ;)
Et puis pendant que j'y suis : tu n'appelles jamais de hotline, tu ne vas jamais chez un commercant ? Non parcque sans le savoir tu utilises des grosses applications ;)