Reprise du message précédent :

python, qui s'y frotte s'y pique

Et alors ce sont des compatibles 386, rien de plus.

non ya lorill ausssi

 
Encore !

Tu vas voir qu'il va nous sortir que pour faire des IHM en Python, y'a Boa Constructor...
Super le truc, un logiciel VB pour faire des interfaces Python... Vraiment génial !

Rhââââââ c'est trop bon, le coup de l'inconvénient du langage : il est trop restrictif !
 
J'en veux d'autres, continue !

Non, y'a glade qu'est bien mieux.
 

Tu sais quoi ? Tu devrais arrêter la drogue. En tout cas si JCVD n'a pas convaincu les gens de le faire, te montrer à eux devrait suffire.

Ben quoi ? Tu vas comparer un langage interprété et l'assembleur quand même ? Autant comparer Claudia Schiffer et Carlos...

Dans ce cas, explique moi pourquoi j'ai eu une erreur sur MSVBVM50.DLL quand j'ai voulu lancer Boa Constructor ??

   
moi qui utilisait tkinter me vais aller me renseigner sur ca tiens

Jar² > Je suis sérieux ! Explique moi en quoi un langage interprété est plus performant que l'assembleur !!

idiot!  le monde a changé depuis le 386
 
je te renvoie à cette page et tes chères études pour te montrer que non, ce ne sont pas seulement des compatibles 386: http://www.emulators.com/docs/pentium_1.htm
 
bonne lecture.

 
L'assembleur, c'est long à programmer, demande plus de mains d'oeuvre et au final, tu obtiens des logiciels plus chers.
 
C'est l'utilisation de langages de haut niveau qui a permis à MS de vendre à bas prix et ainsi de democratiser l'usage de l'ordinateur.
 

 
peut être parce que l'interpeteur de python est tellement intelligent qu'il optimise ton code mieux que si tu le faisais en ASM pure ?

Tu veux m'apprendre ce que c'est qu'un processeur aussi ?

Les interpréteurs sont tous les mêmes... L'autre jour j'ai essayé d'intégrer de l'assembleur à Java, il a réussi à m'interpréter mon code assembleur !!! (si si !!)
Alors moi, ce genre de langage, non merci ! Je préfère la performance pure plutot que la facilité de dev ! Et la boite dans laquelle je travaille aussi !

Quand dans 3 ans ton logiciel super rapide de la mort en assembleur sera fini de développer, le logiciel en langage interprété aura fini de tourner.
 
Et si vraiment c'est la performance brute qui t'intéresse, sache que tu auras bien du mal dans les cas compliqués à faire aussi bien qu'un compilateur C, C++ ou Ocaml (pour citer les plus rapides).

ben "ce ne sont que des compatibles 386", c'est trop réducteur à mon goût

 
+1    
Mais çà va ca se lit vite!

Faut dire que l'interpréteur Java est assez limité au niveau des extensions. Enfin, c'est possible, mais compliqué, alors qu'avec perl ou python tu peux intégrer ta procédure assembleur directement.

Tu as tout faux sur ce coup !  
Trouve moi un compilateur C++ qui optimise les accés mémoire aussi bien que l'humain !
Fais un test : un mini logiciel de traitement d'image. Tu le compiles en C++ et tu regardes le code sur un P3.
A aucun moment, il n'utilise le SSE ! Résultat : je me retrouve avec un truc aussi mal programmé que The Gimp, qui n'exploite pas mon processeur ! Et je te parle même pas du préchargement en cache via prefetch, ni du MMX...
 
J'ai testé : une fractale en C, et son équivalent en SSE. Je fais du x8 !!!  
Alors si le C est aussi peu performant, j'ose meme pas imaginer ce que peut donner Python...

 
Lorsque le messager apporte de mauvaises nouvelles, ce n'est pas la pein de tuer le messager. Utilise autre chose que gcc, ce jouet pour étudiants désoeuvrés.

Ouais mais quand même ! Faut le faire pour interpréter du code x86 sur une JVM ! Ca m'a dégouté à vie des langages interprétés ! Vive les vrais langages, ceux avec lesquels il faut réflechir un minimum plutot que de se contenter de vérifier si on a entré les bons paramètres de la classe Machin !

Euh, je l'ai fait avec ICC hein, le compilo d'Intel !
Alors retourne jouer aux billes avec GCC, et laisse les hommes parler entre eux !

 
eh ben pendant le temps que tu te paluche ton IHM a la mano et que tu t'amuse a compter les pixels a gauche du troisième bouton a droite, j'ai largement le temps de faire un module python avec swig qui calcule la fractale, nettement plus modulaire, rapide car je peux le faire en C/C++ voire même asm si ca m'amuse, car réutilisable (y'a que les abrutis qui s'amusent a recoder la roue à chaque fois).
 
Même en embarqué plus personne n'utilise d'asm pour l'applicatif et les IHM. Y'a plus que pour le DSP et les tâches critiques (VM java, affichage LCD etc...).

 
Certainement en version d'éval, parceque moi, ça marche :  
 

Lis le topic au lieu de vociférer : les IHM je les fais avec un éditeur de ressources qui me crache un fichier .res
Temps de développement : aussi rapide qu'avec IntelliJ
 

L'assembleur n'est pas utilisé, car il traine sa réputation de langage complexe : très peu de gens savent l'utiliser ! Et surtout pas les décideurs, qui savent à peine coder en Cobol !

 
arf cz sent le troll ca  

tu mes sors d'ou ces opcodes ??? t'as pas l'impression d'avoir compilé pour du Z80 la ?

J'ai l'impression que tu ne comprends pas du tout ce que je te dis ; peut-être que tu le fais exprès, mais je vais te donner le bénéfice du doute et recommencer depuis le début en essayant d'être plus clair.
 
Dans un programme, quasiment tout le temps de traitement est pris par une infime partie du code. L'exemple du logiciel de traitement d'image est tout-à-fait approprié : gimp, étant programmé entièrement en C, a l'avantage de la portabilité maximale (rien n'étant plus portable que le C), mais manque de vitesse sur les procédures les plus critiques, et le développement de l'interface en C est chiant.
Par contre, en utilisant - par exemple - python, tu peux développer l'interface très vite sans te poser de questions. Vient la question des filtres, et là évidemment l'interpréteur est trop lent. Mais ça ne pose aucun problème, puisque tu peux mettre du code C au milieu. Tu économises donc sur le temps de développement, sans perdre en vitesse d'exécution.
Pour les portions vraiment critiques, le C n'est parfois plus suffisant et on veut utiliser le MMX, 3dNow ou le SSE. Aucun problème, tu peux choisir de remplacer une procédure par son équivalent assembleur quand les instructions sont disponibles, le tout sans l'empêcher de fonctionner sur un pentium qui n'a pas les instructions en question.
 
Au total, tu as eu quelques dizaines de lignes d'assembleur à écrire, pas mal de bouts de C, et le gros du bouzin est dans un langage haut niveau. Compare-moi le temps de ce développement à celui d'un développement tout-assembleur qui tournera 3 % plus vite...

Vu comme ça, ça a l'air alléchant, mais il y a un truc ou deux que tu oublies quand meme :
 
- Impossible de faire un exe stand-alone en python : l'interpréteur Python doit etre présent sur la machine du client (super pour le déploiement)
- La taille des exe : à logiciel égal, la taille d'un exe en assembleur est 10 fois plus petite => économie de CD
- La sécurité du code : comment protéger un logiciel dont on peut voir le source ?
 
Bref, y'a encore du chemin à faire... Si Python est la panacée, pourquoi tous les logiciels sont codés en C/Assembleur ?

 
Y a quoi comme soft totalement en asm(autre que des bots pour deuzer)?

python il a pas ete fait en asm?
 
 
 
 
 
 
 
 
 
 

Les compilateurs, les JVM, etc... Bref, toutes ces choses totalement inutiles qui ne servent qu'a faire tourner vos langages compilés/interprétés à la con !

On peut, y'a chépukeltruc pour windows qui permet de fourrer l'interpréteur et tous les fichiers python dedans.
 

Certes, mais à moins de faire un logiciel vraiment gros, tu as le temps de voir venir - d'autant plus qu'au bout d'une certaine taille (puisque tu parles de CD), la concision du code python compense largement la taille de l'interpréteur.
 

Personnellement, je m'en tape. Mais il y a des gens qui font du propriétaire en python, et ils y ont pensé avant toi, donc ça existe aussi.
 

Pas dans les domaines que tu as cités.
 

Parce que comme toujours, les gens qui prennent les décisions sont mal informés.
Au passage, ça commence, il y a des boîtes de jeu qui utilisent python, par exemple.

 
Cites moi des noms, parce que tout les compilos et jvm que je connait sont en c ou en c++

Non, en C.

Les compilateurs !!! Mais bien sûr !!!!!!!!!!! GCC est fait entièrement en C, pas en assembleur. Ce n'est pas parce qu'il génère de l'assembleur qu'il est programmé avec, ce serait se tirer une balle dans le pied.

 
Ah ouais, la thèse du complot de billou, comme d'hab

Un complot, mais bien sûr...
 
N'attribuez jamais à la malveillance ce qui peut l'être à la stupidité.

 
Il a cité billou ou?