Bon, on reprend ton raisonnement point par point, il y a quelque chose de fallacieux là-dedans.
> si elle est imposé de la même façon qu'un cadre moyen
(H1) en absolu
(H2) en proportionnel
> et que tu trouve cela normal
yep
> et que tu trouve normal que l'impot soit proportionnel à la capacité contributive
yep, avec capacité contributive = revenu
> ca veut donc dire que tu considère que la capacité contributive de Mme bettencourt est identique (en % de sa fortune et/ou revenue) que celle d'un cadre moyen.
Dans le cadre de (H2): ce n’est qu’une reformulation de (H2). Si tu veux dire que (H2) => (H2), pas la peine, je savais depuis un moment (et tes hypothèses intermédiaires ne servent à rien).
Dans le cadre de (H1): ça veut dire que dans mon monde idéal, oui, cette situation implique logiquement que Bettancourt a le même revenu qu’un cadre moyen. Comme ce n’est pas le cas, mon monde idéal n’est pas le monde réel. So what ? Je me répète : je n’avais pas besoin de toi pour m’en rendre compte.
(par ailleurs, 17 milliards, c’est sa fortune, pas son revenu, et en France la base de l’impôt c’est le revenu — sauf pour cet extraterrestre légal qu’est l’ISF)
> Quand aux perfs, tenez vous le pour dit: le jour ou les sites vont rajouter de la pub en overlay sur les video, vous allez voir votre cpu remonter aussi haut qu'il le faisait avec flash.
Ben non, quand tu mets des sous-titres avec mplayer sur une vidéo, il ne désactive pas l’accélération matérielle pour autant. C’est donc que tu peux combiner overlay et accélération matérielle.
> Oui, mais les gens aiment les gros IDE.
Ça, ça dépend complètement du langage. Effectivement, l’immense majorité des devs Java aiment les gros IDE, mais c’est exactement parce que le langage est inutilisable sans (forcément, étant donné que les 3/4 du code sont tellement trivial qu’un IDE peut le générer et qu’un être humain se fait chier à en crever à l’écrire…)
Les développeurs Python, Ruby et PHP n’aiment en général pas les IDE parce que ces derniers sont incapables d’utiliser toute la puissance de leur langage (et pourtant, la puissance de PHP…)
Pour les développeurs C et C++, ça dépend franchement des milieux.
C’est quoi la différence entre « imprévisible » (Java) et « ça dépend » (C++) ? La même qu’entre un bon et un mauvais chasseur ?
> Sauf que la complétion, les opérations de refactoring, de génération de code et de modélisation ne sont souvent bien implémentées que pour Java. C'est bien dommage d'ailleurs!
Refactoring, peut-être (jamais essayé les outils de refactoring d’eclipse dont on me rebat tant les oreilles), pour le reste, tu as totalement craqué, n’importe quel IDE un tant soit peu complet est capable de faire ça pour le C ou le C++
> les conflits de voisinage etc. n'ont rien à faire devant la justice.
C’est vrai, autant qu’ils se règlent à la carabine, ce sera plus calme pour tous les autres voisins ensuite.
> qu'on ne peut résoudre autrement
Raisonnement circulaire. Si deux voisins ont un conflit mais arrivent à s’entendre sur la manière de le résoudre sans faire intervenir la justice, ben par définition ils n’iront pas devant la justice. S’ils n’y sont pas capable, c’est qu’on est pas capable de le résoudre autrement, à moins de rétablir les duels…
> Sinon c'est claquer l'argent du contribuable par les fenêtres.
L’Arbitrage (droit), c’est rendre justice aussi.
> temps de compilation interminable.
Relativement au C, l’écart n’est pas tellement évident sur une machine récente.
(par rapport à du vrai C++ avec des templates de partout, par contre, je suis à 100% d’accord)
> accès concurrents...
Toujours indéfinis en Java, et dans tous les langages que je connais d’ailleurs.
> IDE et outils peu puissants
La plupart des IDE « puissants » sont multi-langage. Quant à des outils puissants, liés au langage, qui auraient contribué au succès de Java, je vois pas.
Le fait que le C soit un langage très très très casse-gueule pour les "noobs", c’est pas une nouveauté hein…
Il est clair que quelqu’un qui a deux ans de « programmation » (comprendre : un DUT informatique) derrière lui, je le met pas dans un projet en C direct, sauf à mettre quelqu’un qui relit chacune de ses lignes derrière.
[troll]
D’ailleurs, c’est pas ça le principe d’un noob fraîchement diplômé, de se charger du code des projets Java-bateau, pour que les personnes plus expérimentées puissent se concentrer sur de vrais projets ?
[/troll]
> Bah ca serait un ajout, pas une modification : le compilateur accepterait, en plus de la signature tab[int] la signature tab[long].
Si C++ interdit la surcharge sur la seule base de la taille d’un type numérique, c’est pas pour rien : c’est très casse-gueule.
Mais bon, je pense (sans ironie) que je ferai mieux de me taire, je connais pas assez le fonctionnement interne des JVM ni même à quoi ressemble le bytecode Java (en dehors que c’est du bytecode).
> Ben en Java c'est pas un hasard.
Dans le sens de coïncidence, pas d’aléatoire.
> La norme Java ne défini pas de type dont le nom comporte le nomber de bits associés.
J’avais oublié ce détail (une des nombreuses raisons que je fuis Java, pourtant… mais si je devais toutes les retenir… mais on s’éloigne du sujet).
Effectivement, je vois pas de meilleure solution que d’encapsuler ça dans une classe et de mettre un commentaire.
> Le passé l'a montré : Java a déjà évolué de nombreuses fois
L’API J2** a évoluée, le langage Java a vu des fonctionnalités ajoutées. Par contre, je n’ai pas vu des fonctionnalités du langage modifiées (ce que serait « bon en fait on s’est planté, les long comme indice d’un tableau, c’est valide… J’aimerais bien voir d’ailleurs comment ils feront pour faire cohabiter les programmes dont le bytecode contient des index de tableaux en int et des index de tableaux en long, mais en même temps je connais pas le bytecode Java). Si tu as des exemples…
> C'est absolument pas une hérésie en Java
Si, de la même manière que new int[(int)math.PI] est une hérésie. Pour la n-ième fois, c’est pas parce qu’une constante marche « par hasard » qu’il est correct de l’utiliser. Si le type de ta variable nécessite sémantiquement une taille définie, tu l’explicites, sinon celui qui reprendra le projet dans 5 ans risque de se casser la tête (il voulait juste un nombre ou il voulait un conteneur pour 32 bits ? Je peux utiliser short pour réduire l’emprunte mémoire étant donné que maintenant on stocke des centaines de millions d’éléments ?)
> tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?
Heu, tous les algos de base pour la manipulation des structures de données : tables de hashage, graphes & arbres, liste chainées, tableaux, qui en pratique scalent selon la taille du type de base (pointeur pour les liste chainées, entier pour le tableau,…)
> Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
En quoi c’est ridicule ?
Comme tu dis toi-même, dans ce cas, le fait que ça marche ou pas ne dépend pas de l’architecture de la machine mais des capacités de la machine.
Ce qui n’est pas en soit surprenant.
> Ca a tout son sens quand ton soft gere 32768
Tu mélanges deux situations différentes. Ton soft gère 32768 éléments ou MAX_INT éléments ? Ce n’est pas la même chose.
Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.
> et on verra regulierement des tables de 2^32 elements
Ha, mais c’est exactement mon argument plus bas, hein !
1. Là où Java est portable dans le sens où il garantit que l’algo aura les mêmes limites partout, là où C est portable dans le sens où l’algo « scale » avec les capacités de la machine.
2. Justement, je suis impatient de voir comment fera Java quand on verra régulièrement des tables de 2^32 éléments, alors qu’il est écrit dans sa spec que l’index d’un tableau, c’est 32 bits.
> Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.
Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.
C’est pas « plus » ou « moins » portable, c’est différent. Pour une FFT fenêtrée de taille fixe sur un stream, l’approche Java est plus adaptée. Pour de la manipulation d’images, l’approche C est plus adaptée (tu aimerais que la limite en taille d’image puisse s’adapter avec l’évolution du matos : images 170 par 170 au max sur du 16 bits, 65000 par 65000).
Écoute, si c’est pour ne pas me lire et répondre en automatique à partir de quelques mots clefs, c’est pas la peine de me répondre. Tu n’y es pas légalement obligé.
> Eh tu vas rire, mais en Java, y'a un type "long" et un type "double".
Aucun, mais alors vraiment aucun rapport avec ce que j’ai écrit.
Ou alors on peut utiliser les double pour indexer des tableaux en Java. Dans ce cas, c’est une killer feature que vous devriez mettre en avant.
> Et là tu vas te bidonner : même que Java, si le besoin s'en fait ressentir, peut évoluer,
Ben nan, et c’est très précisément ce que je voulais dire.
En C, on a pas défini en dur « taille d’un pointeur », de même qu’on a pas défini en dur « type de l’indice d’un tableau » dans la spec. Alors ça pose quelques soucis de portabilité à certains gruiks qui voyant que sur leur machine sizeof(int) = sizeof(void*) pensent qu’ils peuvent caster des int en void* et vice-versa, certes, mais ça laisse le champ libre à l’évolution du C.
Donc quand on est passé de 16 bits à 32 bits puis 32 bits à 64 bits, pas de souci pour passer de tableaux contenant des dizaines de milliers d’éléments à des millions, et on aura ensuite aucun souci pour passer de tableaux contenant des centaines de millions d’éléments à des tableaux de plusieurs milliards d’éléments.
Au contraire, Java a dit :
- int = 32 bits
- indice des tableaux = int. long doit balancer une exception [http://java.sun.com/docs/books/jls/second_edition/html/array(...)] Ergo, avec Java, tu ne pourras tout simplement pas faire de tableaux de quelques milliards d’éléments même quand ce sera monnaie « courante » chez d’autres langages.
Le but est juste de montrer les inconvénients de définir une taille d’entiers fixes, pourquoi le C a choisi de ne pas le faire, et pourquoi ce choix a été un facteur de réussite sur le long terme.
Tu veux un autre exemple ? Prenons le cas où j’ai codé un algorithme sur ma machine 32 bits, que je veux utiliser sur un processeur 16 bits sans addl (je pense qu’on peut plus en trouver aujourd’hui, mais ça a existé).
En Java :
- soit la JVM n’existe pas pour cette machine : on a rien pour faire de l’int
- soit la JVM force artificiellement le 32 bits à l’aide d’une fonction addl, et bonjour les performances où toute opération sur un int c’est un appel de fonction
- donc, en pratique, je fais un sed s/int/short/g MonAlgo.java > MonAlgo-16.java
En C:
- je recompile et ça juste marche (tm). Sauf si bien sûr j’ai codé comme un porc.
- différence entre les plateformes : les limites de mon algorithme sont plus basses sur la machine 16 bits. Rien qui ne me choque là-dedans.
Pour moi, sur cet exemple, le C est plus portable.
Encore une fois, ce que je dis, c’est ça :
- le fait de ne pas fixer les tailles en C a été un choix
- ce choix, en pratique, revient à privilégier une forme de portabilité (algorithme qui s’adapte « automagiquement » aux capacités de la machine) sur une autre (certaines opérations peuvent « tomber en marche » sur une machine et planter 2 ans plus tard quand tu changes de machine)
- ce choix a été un des facteurs de succès du C sur le long terme
> Non clairement en C il faut utiliser ces types à taille fixe si on veut du code portable
Que dalle. Il faut utiliser des entiers de taille et d’endianness fixe pour la communication avec l’extérieur et vérifier les tailles lors de la sérialisation/déserialisation, c’est tout.
Si je veux un "entier sur 32 bits", parce que ça a un sens sémantiquement dans le contexte (pour coder une couleur RGBA par exemple), oui, je prend un entier de taille fixe.
Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos), je prend un int.
Bon sang, c’est juste une règle de bonne conduite dans tout projet et dans tout langage : un choix d’ordre sémantique doit être explicité ! int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement, et si tu les mélanges au petit bonheur la chance, c’est pas la faute du langage, c’est parce que tu ne sais pas ce que tu fais, et dans ce cas, comme le disait mon prof d’ingénierie logicielle : tu enlèves les mains de ton clavier et tu réfléchis. unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java, parce que pour du RGBA-32, la taille a un sens important. Même si ça marche et c’est portable en Java, c’est du même ordre que mon exemple new int[(int)PI] : c’est pas parce que _par hasard_ la constante ((int)PI ou sizeof(int)) marche pour mon problème qu’il est correct de l’utiliser !
> C'est quoi cet argument ridicule ?
Relis mon exemple. Tu ne l’as pas compris.
tl;dr : sur la question de la taille des entiers, il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C : il y a portabilité formelle (si ma fonction multiplyByTwo fonctionne sur une architecture avec 2**30 en entrée, alors elle doit fonctionner partout avec cette entrée, même si ça signifie que toute opération sur un int doit être ralentie (à la louche) d’un facteur 10 ou plus si la machine ne sait pas faire nativement) pour Java contre portabilité sémantique (la sémantique générale de l’algorithme multiplyByTwo est préservée, mais ses limites dépendent de la machine) pour le C
Tu veux dire que je peux pas faire de code spécifique au système dans Java, que c’est totalement impossible ?
Je suppose donc que je ne peux pas savoir :
- sur quel OS je tourne, et agir en conséquence
- l’endianness de la machine hôte, et agir en conséquence (par exemple IPC avec un programme écrit en C++ qui partage ses données dans le sens de la machine hôte)
- la JVM sur laquelle je tourne, et agir en conséquence
Encore une fois, c’est quoi la sémantique derrière malloc(INT_MAX) dans un exemple de code correct ? Si c’est "allouer 64K", permets-moi de crier bullshit : c’est un code qui aurait sa place sur DailyWTF, tout comme new int[(int)math.PI] le serait pour créer un tableau de 3 entiers.
Et si c’est pour dire que C est moins neuneu-proof, encore une fois (ça fera combien de fois dans ce fil ?) : je sais.
> avoir un tableau qui permettait d'indexer l'intégralité de la mémoire pour un coût relativement peu important
Tu n’as _rien_ compris au message de pBpG.
Quand tu indexes toute la mémoire, par définition, tu utilises toute la mémoire pour l’indexation (dit autrement : si tu essaies de faire une table de hashage dans laquelle la clef est l’adresse mémoire linéaire, alors rien que le stockage de tes clefs te prend la mémoire entière).
Ce que pBpG dit, c’est que sur une machine où l’entier est à 16 bits mais où l’adressage est sur 20 bits — à l’aide de mécanismes comme la segmentation —, malloc(INT_MAX), c’est 16 fois moins (en fait 32, il a oublié que INT_MAX était signé) que l’espace adressable, donc que ça plantera pas — au contraire de nos machines où taille de l’entier = capacités d’adressage.
C’est tout.
Le seul exemple qu’il a donné, c’est « sur 16 bits on peut utiliser malloc(INT_MAX) pour allouer 64ko, et ça plante sur 32 bits », ce que j’appelle difficilement un exemple probant.
> C'est sur que toi, t'as prevu toutes les evolutiosn de l'informatique pour les 30 prochaines annees.
Dans les faits, c’est le C qui a réussi à prouver qu’il pouvait tenir des décennies (presque 40 ans !) et toutes les évolutions qui se sont déroulées pendant ces décennies.
Moi, je suis impatient de voir les développeurs Java dans 30 ans quand le programmeur lambda pourra se permettre des tableaux contenants des milliards d’éléments, avec la spec de leur langage où il est écrit en dur « l’index des tableaux, c’est 32 bits ».
Si Java existe encore dans 30 ans, bien entendu.
C’est sûr, le C aurait été plus « portable » (au sens assez restreint de mes contradicteurs où seule un langage garantissant à 100% la portabilité peut être qualifié de portable) si on avait mis en dur dans la spec « un entier, c’est 16 bits, un long 32, et un pointeur doit pouvoir tenir dans un long ». Pas sûr que le C aurait fêté ses 40 ans s’ils avaient fait ce choix (mais j’aurais été amusé de voir la tête de pBpG et des autres développeurs de Windows (Linux aussi du reste) si ce choix avait été fait. Comment ça on doit changer de langage de programmation et tout réécrire de A à Z pour faire du 64 bits ? Mais je croyais que le langage était plus portable quand on définissait explicitement tout !)
> A l'epoque des procs 16 bits, ca avait peobablement plein de sens, comme pb pg l'a explique.
Bien au contraire, parce qu’à l’époque des processeurs 16 bits, beaucoup étaient également à adressage 16 bits, et donc malloc(INT_MAX) c’était allouer la moitié de l’espace d’adressage.
Je crois effectivement qu’on est juste pas d’accord sur une question de terminologie : pour toi, un langage pas portable, c’est un langage qui offre des garanties de portabilité, tandis que pour moi c’est un langage qui permet d’être portable (à l’inverse, au pif, de l’assembleur).
> Java ne t'autorise qu'à faire des trucs portables là où le C te permet de faire des trucs non portables.
Ce qui ne revient pas au même que de dire que le C n’est pas portable, nom d’une pipe en bois !
Encore une fois, c’est pas parce que Java n’est pas un langage à preuve formelle qu’il ne permet pas de créer des programmes corrects… si tu fais gaffe.
Si c’est juste pour dire que le C est un langage beaucoup, beaucoup moins neuneu-proof que Java, je suis d’accord.
> Tu vois pas l'utilite de creer un tableau de 64Ko en C sur un systeme qui a 1Mo de RAM et qui peut en addresser 1Mo voire 16 ?
Si je veux créer un tableau de 64 Ko, je fais un malloc(64*1024), pas un malloc(INT_MAX) parce qu’il se trouve que par le plus grand des hasards la constante matche.
De même, si je devais créer un tableau de 3 éléments, il ne me viendrait pas l’idée un seul instant de faire un new byte[(int)java.math.PI], même si ça fait ce que je veux.
Parce que bon, tu peux aussi faire un new byte[GetJVMName().getSize()] si par le plus grand des hasards la longueur du nom de ta JVM est pareil que la taille de ton tableau désiré.
Tu peux.
Ce sera juste pas portable et totalement crétin.
Heu, calloc(INT_MAX, sizeof(void*)), ça a beau être super crétin, ça a le même sens partout : créer un tableau associant à chaque entier disponible un pointeur. C’est d’ailleurs le même sens que new Object[MAX_INT] en Java.
Après, ça plantera si t’as pas assez de RAM oui (que tu sois sur un 16 bits avec 20ko de RAM et pas de swap ou un 32 bits avec moins de 4 Go de RAM + swap), mais c’est là une question de capacités de la machine.
C’est pas parce la taille d’un entier varie que la sémantique derrière change.
> Le code machine, ca tourne partout, par definition
On a trouvé une fortune plus grosse que le malloc(INT_MAX) de pBpG là !
Le code machine ne tourne pas partout, non (que ce soit l’assembleur ou le code binaire résultant), et c’est précisément pour cette raison que deux gus dans leur garage (Dennis Ritchie et Kenneth Thompson) ont inventé un langage portable qui puisse être traduit dans ces langages non-portables.
> Ca devient du grand n'importe quoi la...
Je confirme. Je ne sais pas d’où m’est venue cette idée saugrenue que la portabilité pouvait avoir un vague rapport lointain avec le fait de pouvoir faire fonctionner le même code source sans modification sur deux architectures aussi différentes que le x86-64 et le MSP430, vraiment.
Désolé de t’avoir faire perdre ton temps avec une idée aussi stupide.
Sur ce, excuse-moi, mais je dois aller modifier mon dictionnaire pour redéfinir « portable » comme « langage tournant sur une machine virtuelle, mais impossible à faire tourner sur une architecture sur laquelle ladite machine virtuelle n’existe pas ».
> Ce n'est pas un problème d'API : on parle bien de la définition du langage
Ben si, la preuve : tu as des APIs en dehors de la librairie standard pour te faire de la serialisation. Toujours pas aussi simple à utiliser qu’en Java, certes, mais ça a plus à voir avec l’absence d’introspection.
> Ce n'est pas un comportement différent de l'API
Ben si.
Avec la librairie standard du C, tu peux écrire tout et n’importe quoi librement. Et si un programme essaie de lire au petit bonheur la chance un truc écrit au petit bonheur la chance par un autre programme, ça a effectivement de fortes chances de pas bien se passer. Pour que ça fonctionne, tu dois définir correctement le format d’échange (endianness, taille des entiers, format des string, format des flottants,…). C’est quelque chose que les ingénieurs de Sun ont fait quand ils ont défini l’API de sérialisation, c’est quelque chose que C s’est refusé à faire (parce que c’est pas son boulot de faire des trucs haut niveau, parce que C a besoin de communiquer avec du non-C, et surement d’autres raisons que j’ignore).
C’est pareil en Java : si tu essaies de faire un dump mémoire dans un fichier et de reloader brutalement ce dump mémoire sur une autre architecture, il y a de fortes chances que ça marche pas. La différence entre C et Java, c’est que le premier t’autorise à faire ça (en cohérence avec sa philosophie : le langage est pas là pour penser à la place du programmeur, et il y a des situations où faire une telle chose est tout à fait correct) et que le second ne t’y autorisera jamais.
Objective-C, en tant que langage, est exactement dans la même situation que le C à ce niveau (taille de l’entier qui varie, endianness, alignement, etc). Pourtant, OpenStep/Cococa a défini une API et un format d’échange, comme Java, et bizarrement, on ne voit personne pour pleurer sur la non-portabilité d’Objective-C et des plist.
Non, franchement, dire que le C n’est pas portable sous le prétexte que je peux pas charger brutalement le contenu brut de la mémoire d’une architecture vers l’autre (ce que tu fais quand tu fais un write+read direct de tes structures, hein), c’est un peu pareil que dire que Java n’est pas portable parce que je peux pas faire un core dump d’un programme tournant sur la JVM sun et charger ce core dump dans une autre JVM et que le programme puisse continuer sans rien remarquer.
tl;dr : quel que soit le langage, si tu veux être portable, tu dois définir un format d’échange, la seule différence entre Java et C étant qu’en Java tu as un format défini direct dans l’API standard.
> Peut-on vraiment parler de communication avec l'extérieur ?
Ben oui, quand tu communiques avec quelqu’un d’autre que toi (toi = fork(), en gros), tu dois faire gaffe : définir un format d’échange, et ne pas te contenter de lui balancer un dump mémoire à la gueule en le laissant se démerder. Si Java n’a pas ce problème, c’est parce qu’il n’autorise tout simplement pas à balancer un dump mémoire ([troll]c’est la résolution des problèmes selon Java : si une fonctionnalité peut potentiellement être mal utilisée, on la supprime[/troll])
C’est vrai que ça tombe un peu comme un cheveu sur la soupe, mais sa remarque est pertinente : combien d’architectures supportées par la JVM, par .Net ? Parce que c’est bien beau de dire : c’est portable, yaka coder une implémentation de CLR/Java bytecode, en pratique, ça donne quoi ?
Personnellement, en C, je peux faire du code qui tourne sans modification sur mon PC et le MSP430 (je l’utilise pour faire des routines que je peux tester sur mon PC, c’est plus simple de débugger sur un PC que sur un MSP430). Java, il tourne sur un MSP430 ?
[^] # Re: Banques
Posté par Moonz . En réponse au journal Éloge du don. Évalué à 2.
> si elle est imposé de la même façon qu'un cadre moyen
(H1) en absolu
(H2) en proportionnel
> et que tu trouve cela normal
yep
> et que tu trouve normal que l'impot soit proportionnel à la capacité contributive
yep, avec capacité contributive = revenu
> ca veut donc dire que tu considère que la capacité contributive de Mme bettencourt est identique (en % de sa fortune et/ou revenue) que celle d'un cadre moyen.
Dans le cadre de (H2): ce n’est qu’une reformulation de (H2). Si tu veux dire que (H2) => (H2), pas la peine, je savais depuis un moment (et tes hypothèses intermédiaires ne servent à rien).
Dans le cadre de (H1): ça veut dire que dans mon monde idéal, oui, cette situation implique logiquement que Bettancourt a le même revenu qu’un cadre moyen. Comme ce n’est pas le cas, mon monde idéal n’est pas le monde réel. So what ? Je me répète : je n’avais pas besoin de toi pour m’en rendre compte.
(par ailleurs, 17 milliards, c’est sa fortune, pas son revenu, et en France la base de l’impôt c’est le revenu — sauf pour cet extraterrestre légal qu’est l’ISF)
[^] # Re: re
Posté par Moonz . En réponse au journal Le greffon propriétaire qui éblouit (oui, qui Flashe quoi) évolue. Évalué à 3.
http://www.whatwg.org/specs/web-apps/current-work/#devices
> Quand aux perfs, tenez vous le pour dit: le jour ou les sites vont rajouter de la pub en overlay sur les video, vous allez voir votre cpu remonter aussi haut qu'il le faisait avec flash.
Ben non, quand tu mets des sous-titres avec mplayer sur une vidéo, il ne désactive pas l’accélération matérielle pour autant. C’est donc que tu peux combiner overlay et accélération matérielle.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Ça, ça dépend complètement du langage. Effectivement, l’immense majorité des devs Java aiment les gros IDE, mais c’est exactement parce que le langage est inutilisable sans (forcément, étant donné que les 3/4 du code sont tellement trivial qu’un IDE peut le générer et qu’un être humain se fait chier à en crever à l’écrire…)
Les développeurs Python, Ruby et PHP n’aiment en général pas les IDE parce que ces derniers sont incapables d’utiliser toute la puissance de leur langage (et pourtant, la puissance de PHP…)
Pour les développeurs C et C++, ça dépend franchement des milieux.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
> Sauf que la complétion, les opérations de refactoring, de génération de code et de modélisation ne sont souvent bien implémentées que pour Java. C'est bien dommage d'ailleurs!
Refactoring, peut-être (jamais essayé les outils de refactoring d’eclipse dont on me rebat tant les oreilles), pour le reste, tu as totalement craqué, n’importe quel IDE un tant soit peu complet est capable de faire ça pour le C ou le C++
[^] # Re: Bien obligé non ?
Posté par Moonz . En réponse au journal "J'ai raison, mais je ne ferai pas valider mon raisonnement". Évalué à 4.
C’est vrai, autant qu’ils se règlent à la carabine, ce sera plus calme pour tous les autres voisins ensuite.
> qu'on ne peut résoudre autrement
Raisonnement circulaire. Si deux voisins ont un conflit mais arrivent à s’entendre sur la manière de le résoudre sans faire intervenir la justice, ben par définition ils n’iront pas devant la justice. S’ils n’y sont pas capable, c’est qu’on est pas capable de le résoudre autrement, à moins de rétablir les duels…
> Sinon c'est claquer l'argent du contribuable par les fenêtres.
L’Arbitrage (droit), c’est rendre justice aussi.
[^] # Re: Bien obligé non ?
Posté par Moonz . En réponse au journal "J'ai raison, mais je ne ferai pas valider mon raisonnement". Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Relativement au C, l’écart n’est pas tellement évident sur une machine récente.
(par rapport à du vrai C++ avec des templates de partout, par contre, je suis à 100% d’accord)
> accès concurrents...
Toujours indéfinis en Java, et dans tous les langages que je connais d’ailleurs.
> IDE et outils peu puissants
La plupart des IDE « puissants » sont multi-langage. Quant à des outils puissants, liés au langage, qui auraient contribué au succès de Java, je vois pas.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Il est clair que quelqu’un qui a deux ans de « programmation » (comprendre : un DUT informatique) derrière lui, je le met pas dans un projet en C direct, sauf à mettre quelqu’un qui relit chacune de ses lignes derrière.
[troll]
D’ailleurs, c’est pas ça le principe d’un noob fraîchement diplômé, de se charger du code des projets Java-bateau, pour que les personnes plus expérimentées puissent se concentrer sur de vrais projets ?
[/troll]
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Si C++ interdit la surcharge sur la seule base de la taille d’un type numérique, c’est pas pour rien : c’est très casse-gueule.
Mais bon, je pense (sans ironie) que je ferai mieux de me taire, je connais pas assez le fonctionnement interne des JVM ni même à quoi ressemble le bytecode Java (en dehors que c’est du bytecode).
> Ben en Java c'est pas un hasard.
Dans le sens de coïncidence, pas d’aléatoire.
> La norme Java ne défini pas de type dont le nom comporte le nomber de bits associés.
J’avais oublié ce détail (une des nombreuses raisons que je fuis Java, pourtant… mais si je devais toutes les retenir… mais on s’éloigne du sujet).
Effectivement, je vois pas de meilleure solution que d’encapsuler ça dans une classe et de mettre un commentaire.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
L’API J2** a évoluée, le langage Java a vu des fonctionnalités ajoutées. Par contre, je n’ai pas vu des fonctionnalités du langage modifiées (ce que serait « bon en fait on s’est planté, les long comme indice d’un tableau, c’est valide… J’aimerais bien voir d’ailleurs comment ils feront pour faire cohabiter les programmes dont le bytecode contient des index de tableaux en int et des index de tableaux en long, mais en même temps je connais pas le bytecode Java). Si tu as des exemples…
> C'est absolument pas une hérésie en Java
Si, de la même manière que new int[(int)math.PI] est une hérésie. Pour la n-ième fois, c’est pas parce qu’une constante marche « par hasard » qu’il est correct de l’utiliser. Si le type de ta variable nécessite sémantiquement une taille définie, tu l’explicites, sinon celui qui reprendra le projet dans 5 ans risque de se casser la tête (il voulait juste un nombre ou il voulait un conteneur pour 32 bits ? Je peux utiliser short pour réduire l’emprunte mémoire étant donné que maintenant on stocke des centaines de millions d’éléments ?)
> tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?
Heu, tous les algos de base pour la manipulation des structures de données : tables de hashage, graphes & arbres, liste chainées, tableaux, qui en pratique scalent selon la taille du type de base (pointeur pour les liste chainées, entier pour le tableau,…)
> Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
En quoi c’est ridicule ?
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Ce qui n’est pas en soit surprenant.
> Ca a tout son sens quand ton soft gere 32768
Tu mélanges deux situations différentes. Ton soft gère 32768 éléments ou MAX_INT éléments ? Ce n’est pas la même chose.
Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.
> et on verra regulierement des tables de 2^32 elements
Ha, mais c’est exactement mon argument plus bas, hein !
1. Là où Java est portable dans le sens où il garantit que l’algo aura les mêmes limites partout, là où C est portable dans le sens où l’algo « scale » avec les capacités de la machine.
2. Justement, je suis impatient de voir comment fera Java quand on verra régulièrement des tables de 2^32 éléments, alors qu’il est écrit dans sa spec que l’index d’un tableau, c’est 32 bits.
> Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.
Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.
C’est pas « plus » ou « moins » portable, c’est différent. Pour une FFT fenêtrée de taille fixe sur un stream, l’approche Java est plus adaptée. Pour de la manipulation d’images, l’approche C est plus adaptée (tu aimerais que la limite en taille d’image puisse s’adapter avec l’évolution du matos : images 170 par 170 au max sur du 16 bits, 65000 par 65000).
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
> Eh tu vas rire, mais en Java, y'a un type "long" et un type "double".
Aucun, mais alors vraiment aucun rapport avec ce que j’ai écrit.
Ou alors on peut utiliser les double pour indexer des tableaux en Java. Dans ce cas, c’est une killer feature que vous devriez mettre en avant.
> Et là tu vas te bidonner : même que Java, si le besoin s'en fait ressentir, peut évoluer,
Ben nan, et c’est très précisément ce que je voulais dire.
En C, on a pas défini en dur « taille d’un pointeur », de même qu’on a pas défini en dur « type de l’indice d’un tableau » dans la spec. Alors ça pose quelques soucis de portabilité à certains gruiks qui voyant que sur leur machine sizeof(int) = sizeof(void*) pensent qu’ils peuvent caster des int en void* et vice-versa, certes, mais ça laisse le champ libre à l’évolution du C.
Donc quand on est passé de 16 bits à 32 bits puis 32 bits à 64 bits, pas de souci pour passer de tableaux contenant des dizaines de milliers d’éléments à des millions, et on aura ensuite aucun souci pour passer de tableaux contenant des centaines de millions d’éléments à des tableaux de plusieurs milliards d’éléments.
Au contraire, Java a dit :
- int = 32 bits
- indice des tableaux = int. long doit balancer une exception [http://java.sun.com/docs/books/jls/second_edition/html/array(...)]
Ergo, avec Java, tu ne pourras tout simplement pas faire de tableaux de quelques milliards d’éléments même quand ce sera monnaie « courante » chez d’autres langages.
Le but est juste de montrer les inconvénients de définir une taille d’entiers fixes, pourquoi le C a choisi de ne pas le faire, et pourquoi ce choix a été un facteur de réussite sur le long terme.
Tu veux un autre exemple ? Prenons le cas où j’ai codé un algorithme sur ma machine 32 bits, que je veux utiliser sur un processeur 16 bits sans addl (je pense qu’on peut plus en trouver aujourd’hui, mais ça a existé).
En Java :
- soit la JVM n’existe pas pour cette machine : on a rien pour faire de l’int
- soit la JVM force artificiellement le 32 bits à l’aide d’une fonction addl, et bonjour les performances où toute opération sur un int c’est un appel de fonction
- donc, en pratique, je fais un sed s/int/short/g MonAlgo.java > MonAlgo-16.java
En C:
- je recompile et ça juste marche (tm). Sauf si bien sûr j’ai codé comme un porc.
- différence entre les plateformes : les limites de mon algorithme sont plus basses sur la machine 16 bits. Rien qui ne me choque là-dedans.
Pour moi, sur cet exemple, le C est plus portable.
Encore une fois, ce que je dis, c’est ça :
- le fait de ne pas fixer les tailles en C a été un choix
- ce choix, en pratique, revient à privilégier une forme de portabilité (algorithme qui s’adapte « automagiquement » aux capacités de la machine) sur une autre (certaines opérations peuvent « tomber en marche » sur une machine et planter 2 ans plus tard quand tu changes de machine)
- ce choix a été un des facteurs de succès du C sur le long terme
> Non clairement en C il faut utiliser ces types à taille fixe si on veut du code portable
Que dalle. Il faut utiliser des entiers de taille et d’endianness fixe pour la communication avec l’extérieur et vérifier les tailles lors de la sérialisation/déserialisation, c’est tout.
Si je veux un "entier sur 32 bits", parce que ça a un sens sémantiquement dans le contexte (pour coder une couleur RGBA par exemple), oui, je prend un entier de taille fixe.
Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos), je prend un int.
Bon sang, c’est juste une règle de bonne conduite dans tout projet et dans tout langage : un choix d’ordre sémantique doit être explicité ! int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement, et si tu les mélanges au petit bonheur la chance, c’est pas la faute du langage, c’est parce que tu ne sais pas ce que tu fais, et dans ce cas, comme le disait mon prof d’ingénierie logicielle : tu enlèves les mains de ton clavier et tu réfléchis. unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java, parce que pour du RGBA-32, la taille a un sens important. Même si ça marche et c’est portable en Java, c’est du même ordre que mon exemple new int[(int)PI] : c’est pas parce que _par hasard_ la constante ((int)PI ou sizeof(int)) marche pour mon problème qu’il est correct de l’utiliser !
> C'est quoi cet argument ridicule ?
Relis mon exemple. Tu ne l’as pas compris.
tl;dr : sur la question de la taille des entiers, il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C : il y a portabilité formelle (si ma fonction multiplyByTwo fonctionne sur une architecture avec 2**30 en entrée, alors elle doit fonctionner partout avec cette entrée, même si ça signifie que toute opération sur un int doit être ralentie (à la louche) d’un facteur 10 ou plus si la machine ne sait pas faire nativement) pour Java contre portabilité sémantique (la sémantique générale de l’algorithme multiplyByTwo est préservée, mais ses limites dépendent de la machine) pour le C
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Je suppose donc que je ne peux pas savoir :
- sur quel OS je tourne, et agir en conséquence
- l’endianness de la machine hôte, et agir en conséquence (par exemple IPC avec un programme écrit en C++ qui partage ses données dans le sens de la machine hôte)
- la JVM sur laquelle je tourne, et agir en conséquence
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
> Pourtant c'est un exemple reel,
Comme ce qu’on trouve sur http://thedailywtf.com/
Encore une fois, c’est quoi la sémantique derrière malloc(INT_MAX) dans un exemple de code correct ? Si c’est "allouer 64K", permets-moi de crier bullshit : c’est un code qui aurait sa place sur DailyWTF, tout comme new int[(int)math.PI] le serait pour créer un tableau de 3 entiers.
Et si c’est pour dire que C est moins neuneu-proof, encore une fois (ça fera combien de fois dans ce fil ?) : je sais.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Tu n’as _rien_ compris au message de pBpG.
Quand tu indexes toute la mémoire, par définition, tu utilises toute la mémoire pour l’indexation (dit autrement : si tu essaies de faire une table de hashage dans laquelle la clef est l’adresse mémoire linéaire, alors rien que le stockage de tes clefs te prend la mémoire entière).
Ce que pBpG dit, c’est que sur une machine où l’entier est à 16 bits mais où l’adressage est sur 20 bits — à l’aide de mécanismes comme la segmentation —, malloc(INT_MAX), c’est 16 fois moins (en fait 32, il a oublié que INT_MAX était signé) que l’espace adressable, donc que ça plantera pas — au contraire de nos machines où taille de l’entier = capacités d’adressage.
C’est tout.
Le seul exemple qu’il a donné, c’est « sur 16 bits on peut utiliser malloc(INT_MAX) pour allouer 64ko, et ça plante sur 32 bits », ce que j’appelle difficilement un exemple probant.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Dans les faits, c’est le C qui a réussi à prouver qu’il pouvait tenir des décennies (presque 40 ans !) et toutes les évolutions qui se sont déroulées pendant ces décennies.
Moi, je suis impatient de voir les développeurs Java dans 30 ans quand le programmeur lambda pourra se permettre des tableaux contenants des milliards d’éléments, avec la spec de leur langage où il est écrit en dur « l’index des tableaux, c’est 32 bits ».
Si Java existe encore dans 30 ans, bien entendu.
C’est sûr, le C aurait été plus « portable » (au sens assez restreint de mes contradicteurs où seule un langage garantissant à 100% la portabilité peut être qualifié de portable) si on avait mis en dur dans la spec « un entier, c’est 16 bits, un long 32, et un pointeur doit pouvoir tenir dans un long ». Pas sûr que le C aurait fêté ses 40 ans s’ils avaient fait ce choix (mais j’aurais été amusé de voir la tête de pBpG et des autres développeurs de Windows (Linux aussi du reste) si ce choix avait été fait. Comment ça on doit changer de langage de programmation et tout réécrire de A à Z pour faire du 64 bits ? Mais je croyais que le langage était plus portable quand on définissait explicitement tout !)
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Bien au contraire, parce qu’à l’époque des processeurs 16 bits, beaucoup étaient également à adressage 16 bits, et donc malloc(INT_MAX) c’était allouer la moitié de l’espace d’adressage.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Ce qui ne revient pas au même que de dire que le C n’est pas portable, nom d’une pipe en bois !
Encore une fois, c’est pas parce que Java n’est pas un langage à preuve formelle qu’il ne permet pas de créer des programmes corrects… si tu fais gaffe.
Si c’est juste pour dire que le C est un langage beaucoup, beaucoup moins neuneu-proof que Java, je suis d’accord.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Si je veux créer un tableau de 64 Ko, je fais un malloc(64*1024), pas un malloc(INT_MAX) parce qu’il se trouve que par le plus grand des hasards la constante matche.
De même, si je devais créer un tableau de 3 éléments, il ne me viendrait pas l’idée un seul instant de faire un new byte[(int)java.math.PI], même si ça fait ce que je veux.
Parce que bon, tu peux aussi faire un new byte[GetJVMName().getSize()] si par le plus grand des hasards la longueur du nom de ta JVM est pareil que la taille de ton tableau désiré.
Tu peux.
Ce sera juste pas portable et totalement crétin.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Après, ça plantera si t’as pas assez de RAM oui (que tu sois sur un 16 bits avec 20ko de RAM et pas de swap ou un 32 bits avec moins de 4 Go de RAM + swap), mais c’est là une question de capacités de la machine.
C’est pas parce la taille d’un entier varie que la sémantique derrière change.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 4.
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
On a trouvé une fortune plus grosse que le malloc(INT_MAX) de pBpG là !
Le code machine ne tourne pas partout, non (que ce soit l’assembleur ou le code binaire résultant), et c’est précisément pour cette raison que deux gus dans leur garage (Dennis Ritchie et Kenneth Thompson) ont inventé un langage portable qui puisse être traduit dans ces langages non-portables.
> Ca devient du grand n'importe quoi la...
Je confirme. Je ne sais pas d’où m’est venue cette idée saugrenue que la portabilité pouvait avoir un vague rapport lointain avec le fait de pouvoir faire fonctionner le même code source sans modification sur deux architectures aussi différentes que le x86-64 et le MSP430, vraiment.
Désolé de t’avoir faire perdre ton temps avec une idée aussi stupide.
Sur ce, excuse-moi, mais je dois aller modifier mon dictionnaire pour redéfinir « portable » comme « langage tournant sur une machine virtuelle, mais impossible à faire tourner sur une architecture sur laquelle ladite machine virtuelle n’existe pas ».
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Ben si, la preuve : tu as des APIs en dehors de la librairie standard pour te faire de la serialisation. Toujours pas aussi simple à utiliser qu’en Java, certes, mais ça a plus à voir avec l’absence d’introspection.
> Ce n'est pas un comportement différent de l'API
Ben si.
Avec la librairie standard du C, tu peux écrire tout et n’importe quoi librement. Et si un programme essaie de lire au petit bonheur la chance un truc écrit au petit bonheur la chance par un autre programme, ça a effectivement de fortes chances de pas bien se passer. Pour que ça fonctionne, tu dois définir correctement le format d’échange (endianness, taille des entiers, format des string, format des flottants,…). C’est quelque chose que les ingénieurs de Sun ont fait quand ils ont défini l’API de sérialisation, c’est quelque chose que C s’est refusé à faire (parce que c’est pas son boulot de faire des trucs haut niveau, parce que C a besoin de communiquer avec du non-C, et surement d’autres raisons que j’ignore).
C’est pareil en Java : si tu essaies de faire un dump mémoire dans un fichier et de reloader brutalement ce dump mémoire sur une autre architecture, il y a de fortes chances que ça marche pas. La différence entre C et Java, c’est que le premier t’autorise à faire ça (en cohérence avec sa philosophie : le langage est pas là pour penser à la place du programmeur, et il y a des situations où faire une telle chose est tout à fait correct) et que le second ne t’y autorisera jamais.
Objective-C, en tant que langage, est exactement dans la même situation que le C à ce niveau (taille de l’entier qui varie, endianness, alignement, etc). Pourtant, OpenStep/Cococa a défini une API et un format d’échange, comme Java, et bizarrement, on ne voit personne pour pleurer sur la non-portabilité d’Objective-C et des plist.
Non, franchement, dire que le C n’est pas portable sous le prétexte que je peux pas charger brutalement le contenu brut de la mémoire d’une architecture vers l’autre (ce que tu fais quand tu fais un write+read direct de tes structures, hein), c’est un peu pareil que dire que Java n’est pas portable parce que je peux pas faire un core dump d’un programme tournant sur la JVM sun et charger ce core dump dans une autre JVM et que le programme puisse continuer sans rien remarquer.
tl;dr : quel que soit le langage, si tu veux être portable, tu dois définir un format d’échange, la seule différence entre Java et C étant qu’en Java tu as un format défini direct dans l’API standard.
> Peut-on vraiment parler de communication avec l'extérieur ?
Ben oui, quand tu communiques avec quelqu’un d’autre que toi (toi = fork(), en gros), tu dois faire gaffe : définir un format d’échange, et ne pas te contenter de lui balancer un dump mémoire à la gueule en le laissant se démerder. Si Java n’a pas ce problème, c’est parce qu’il n’autorise tout simplement pas à balancer un dump mémoire ([troll]c’est la résolution des problèmes selon Java : si une fonctionnalité peut potentiellement être mal utilisée, on la supprime[/troll])
[^] # Re: Bonne nouvelle
Posté par Moonz . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Personnellement, en C, je peux faire du code qui tourne sans modification sur mon PC et le MSP430 (je l’utilise pour faire des routines que je peux tester sur mon PC, c’est plus simple de débugger sur un PC que sur un MSP430). Java, il tourne sur un MSP430 ?