(suite du flashchat) tetris sur votre carte bleue - Page 2

Edited_3397

hmm pas capté ?

sinon non, les diagrammes UML, ainsi que presque tous les autres documents d'analyse ou de conception d'ailleurs deviennent très utile voire indispensables quand on travaille sur des *vrais* projets qui ont une taille conséquente (c'est à dire pas des cas d'école comme ce que tu dois encore faire [pour l'instant] à epitech je suppose); c'est pas uniquement pour faire joli ^^

Orion_ (./25) :
on utilise encore le C pour des raisons de perf.

En plus c'est pas forcement vrai, CF BeOS un os ecrit a 99.99999% en C++ (le reste est de l'asm) est loin d'etre un OS pas performant du tout...

C'est en effet souvent beaucoup plus rentable de changer d'algorithme que de langage... En plus, il vaut mieux gagner sur le temps de programmation et choisir le C++, quitte à perdre 5-10% en perfs qui seront de toute façon regagnés en 2 mois avec le changement de processeurs ...

Et le temps de programmation gagné peut servir à mieux optimiser les routines critiques que si tout était programmé dans un langage plus bas niveau ^^

De toutes façons, pour un "vrai" projet, le temps de développement ne correspond (sauf à la rigueur pour c qui est système, et encore) qu'à 1/10ème du temps de travail... le reste étant l'analyse, les specs et les docs.

Et 8/10 c'est la correction de bug

Ben normalement (après, ça dépend aussi des contraintes de programmation), si tu programmes de façon modulaire (en objet ou non), *si* la partie analytique est faite correctement (si on affine la granularité de façon progressive, ce qui fait qu'on part d'un modèle abstrait pour arriver petit à petit à l'algo en lui-même), il ne reste que peu de bugs. De façons générale, le bug vient d'une méconnaissance d'une spécification externe lors d'un appel d'un module, ou d'une erreur de frappe (bon, là, c'est la faute à pas de chance, et c'est le plus souvent le plus chiant à trouver).
Après, il y a des impératifs (utilisation de langages non procéduraux, manque de temps, chef d'équipe qui se s'y connaît pas...) qui font que développer en modules est impossible...
(Je ne parle pas d'informatique industrielle, vu que je ne connais pas du tout ce domaine... je parle principalement de développement orienté informatique de gestion ou sécurité).

Non mais je suis bien d'accord hein ^^

C'était juste un ptit troll Et c'est clair que quand je vois le nombre de bug que je peut avoir a corriger c'est que ça a été fait "chacun dans son coin" sans dans la plus grande liberté & co et ça se ressent fortement derriere..

Tu auras toujours des bugs bizzare qui sont indépendant de l'analyse (pbm de fonctionnement dans des cas qui n'était pas prévus a la base, ou des cas complexes qui ne peuvent arriver que dans la tete de l'utilisateur final qui fait par définition toujours n'importe quoi , et surtout quand on fait du tres bas niveau, un rien peu impacter sur tout le systeme et faire faire des choses bizzare a quelque chose qui au final n'a rien a voir...)

Pour en revenir au sujet initial, perso je doute que le code soit sur la carte a puce, mais plutot dans le terminal, dans le cas contraire j'aurais tendance a dire qu'une VM java a été installé sur le terminal (que le hard soit d'origine ou non) et que le soft est stoqué que la carte a puce qui ne sert en fait que de carte mémoire contenant le soft)

Edited_3398

Edited_3399

PC et embarqué, ça n'est pas complètement contradictoire

([google]javacard[/google])

Orion_ (./43) :
cela dit ca me parais quand meme enorme d'avoir du java dans ce genre d'appareil
(remarque on fait bien du java sur mobile alors que c pas adapter du tout)

Qu'est-ce que tu appelles "adapté" ? Les mobiles ont au contraire tout intérêt à avoir un language indépendant du matiériel, qui change souvent. Sans parler des puces qui mangent le java en natif.

arnsy (./13) :
Ba non puisqu'ils ont remplacé des composants.

au sens propre, hack = bidouillage. c'en est un.

Edited_3400

Tu connais mal java, du moins dans la téléphone mobile, il ya AS un standard pour le java pour téléphone portable, si certain constructeurs ne le respecte pas, et que les dévellopeur ne veulent pas l'utiliser, ce n'est pas faute d'avoir essayé.

Edited_3401

(que dire devant tant de preuves ^^)

Edited_3402

j'aurais du mal à dire le contraire vu que je suis pas fan non plus du Java, ceci dit si je devais donner mes arguments, j'essaierais de les rendre un peu plus forts que "machin m'a dit que ça suxait"... enfin après, ce que j'en dis...

Edited_3403

Mon cher orion qui a toujours raison, je te conseillerais d'aller voir :

[google]MIDP[/google]
[google]CLDC[/google]
etc...

Et reviens quand tu en sauras un peu plus sur le sujet, merci

Orion_ (./25) :
on utilise encore le C pour des raisons de perf.

Je rapelle qu'à l'avenir, les languages de haut niveau seront plus rapide que ceux de bas niveaux (cf topics/11-85305-les-languages-de-haut-niveau-plus-rapide-que-ceux-de-bas-niveau)

On peut booster quand même les langages de bas-niveaux, j'avais lu un article où ils utilisaient une machine virtuelle pour faire tourner du code natif. En fait, la machine virtuelle exécutait nativement la plupart du code, mais réorganisait un peu le code et faisait qqes optimisations à la volée et du coup ils étaient plus performants

./56 : mouais, ça j'attends de voir perso... ils seront plus rapide pour certaines tâches et avec certains développeurs, surement, mais ça me parait un peu optimiste d'en prétendre plus aujourd'hui

Edited_3404

Edited_3406