Anonyme a écrit 62292 commentaires

  • # Java ça reste lent, mais c'est simple comme les lego.

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    Java est loin d'être mort, je développe quotidiennement des applis pour serveur Web (Servlet ou jsp) qui tappe dans des bases de données. Dans ce cadre d'utilisation ce langage est trés bien adapté. PHP peut aussi servir dans ce contexte, après c'est une question de choix personnel et du matériel qu'on utilise.

    -Comme on utilise les librairies standard sun, c'est trés portable (enfin entre solaris, linux et windows, les 3 OS supporté par sun, ça marcherait peut être sous des JDK sous d'autres OS mais on s'en fout, il faut être honnête).
    -Il y a bcp de librairies standard, on a pas besoin de reinventer la roue, et on gagne bcp de temps en développement.
    -Comme on fait toujours le même type d'applis, on a un squelette déjà fait ce qui nous évite de repartir de zéro à chaque fois.
    -On ne se fait pas chier comme en C a gérer la mémoire, ça fait gagner bcp de temps aussi. Bon le fait aussi de faire moins de boulot en aval (programmation) fait que la jvm sera plus chargée en amont.
    -avec le jdbc, un accés à une base de donnée c'est "finger in the noize", et tu peux standardiser ton code pour n'importe quelle type de base, il suffit de changer le driver.

    Non java est trés agréable à programmer, tu fais trés rapidement du code sale portable et qui reste lisible et maintenable. Surtout la jvm permet d'avoir une certaine stabilité, et en truffant le code de try, catch, tu es sur d'avoir une appli qui ne plantera pas (c'est pas pour autant qu'elle va reagir comme on le voulait :-).

    Je compare Java a des lego, c'est facile à monter, c'est amusant, c'est robuste, mais une voiture en lego ne sera pas trés aérodynamique (je parle des briques classiques, pas avec des piéces moulées profilées des nouvelles boîtes).

    Le C++ serait un mécano, en théorie plus puissant, mais les boulons se deserent tout le temps. Et tu n'obtiens jamais un montage robuste (c'est pour ça que c'est chiant).

    Mais Java reste lent quand même, on ne peut pas comparer une émulation software avec du hardware.
    On a quand même des problèmes de perfs de temps en temps.
    Mais pour une entreprise ce n'est pas trop grave, ça coute moins cher d'acheter un gros serveur que de developper du code C ou C++ que personne n'arrivera à maintenir et qui sera plus fragile.

    Par contre à titre personnel, ça me fait un peu chier de devoir me contenter d'un jeu en 256x256 au lieu de l'avoir en 1024x768.

    C'est comme UAE, sur mon duron 650, il arrive enfin a faire tourner des jeux amiga500 à la frame rate. C'est marrant, c'est nostalgique, mais je ça me gonfle de jouer à un jeu "récent" comme si le jeu avait 10 ans avec une machine a 10000FF. Déjà qu'on se plaint que les OS modernes sont gros et bouffeurs de ressources, si tu rajoute une couche java dessus.

    Java est dans une niche, et il est trés bien adapté, vouloir le rendre universel serait une erreur. Personnellement, je prefere programmer en C sur mes petits programmes personnels (en général c'est plûtot du calcul math) parce que c'est plus simple.
    Mais des qu'il faut faire "moulte" malloc et free, il vaut mieux passer à autre chose, on perd trop de temps à se prendre la tête sur un dépassement de pointeur, sans parler de faire une fonction de sortie propre alors qu'en Java le boulot est maché au détriment de la performance.

    Quand a swing, et bien, ça devient vite lourd a programmer, mais ça c'est le problème de tout ihm moderne. Quand a sa rapidité, ben à part Jbuilder qui répond bien, je n'ai pas vu un seul prog java agréable à utiliser en ihm. ça répond pas au quart de tour, et ça devient enervant.

    Les applets, c'est un autre problème, ie5.5(d'accord c'est du crosoft, mais dans la philo java, il faut faire des applets qui tournent sur le plus de navigateurs possible) est toujours en 1.0, donc ça reste limité. Mais c'est la solution la plus simple pour faire un programme java qui pourra être lancé sur 80% des ordis de la planéte sans rien connaître aux lignes de commandes et sans faire un .bat ou un .sh en fonction du système.

    Il n'y a pas de solutions miracle, la ou sun a vraiment été trés con, c'est qu'ils ont crées un proc virtuels qui étaient un peu trop compliqué à créer dans la réalité. Parce que si on avait des procs bytecode java a 500mhz, le langage aurait pu servir de base solide a un vrai os "multimedia". Ou alors faire du code morphing sur un proc style "transmeta", mais comme il n'y a pas de vai os java, ça ne sera jamais fait (enfin pas tout de suite).

    Le plus simple c'est d'utiliser l'OS et le langage adapté à une utilisation particulière et éviter de s'enfermer dans une solution unique, même si à titre personnele, il faut quand même se spécialiser un peu plus dans peu de langages si on veut évoluer et arrêter de butiner à droite ou à gauche sans rien faire de concret.

    C'est un peu comme le tunning du systéme, a force de vouloir choisir on ne fait rien.

    DARKLEON
  • [^] # Re: en JAVA????

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    Pour ton coup du String/StringBuffer. OK, mais alors pourquoi le type String existe ? Excuse-moi mais pour déclarer une chaîne, ça me parait plus logique d'utiliser le type String, que le type StringBuffer.
    Et puis ce qu'on considère comme des réussites en Java comme Jext ou Borland JBuilder, c'est LENT. Jext me bouffe 5MO de RAM, pour un éditeur de texte, c'est pas normal !! JBuilder, j'en parle même pas. Delphi est 10 fois plus rapide et moins bouffeur de RAM.
    On dit souvent à propos de Java que l'avantage c'est les classes de base. OK toujours, mais les classes de base sont horriblement lentes. On doit donc réécrire autre chose, mais tu perds la portabilité, car tu dois linker avec les librairies systèmes.
    Autre chose, javac n'optimise RIEN !! Si tu désassemble ton bytecode, tu verras que c'est affreux !! Tout est traduit litéralement, sans aucun effort d'optimisation, et pourtant javac est long à la compilation.
    Le problème essentiel de Java va être que tu as deux possibilités pour programmer : la débutante où tu utilises les classes de bases et les types String et autres. Alors c'est facile, mais lent, et tu fait taper sur les doigts. Deuxième solution, tu bidouilles ton code à la main, t'optimises, tu désassemble pour corriger, bref tu bosses. Mais ou est la simplicité de Java à ce moment là ? On se croirait revenu en asm : si tu décrémente ta boucle au lieu de l'incrémenter, tu économise une instruction, et donc ... Je m'arrêtes là, mais je croyais que le but des langages de haut niveau était justement d'éviter ce genre de trucs, en les mettant au niveau du compilateur.
    Le pense donc que Java n'est pas un mauvais langage en soi, mais qu'il s'embrouille avec des trucs imbuvables, comme sa volonté d'adopter à peu près la syntaxe de C++, ce qui compléxifie inutilement la chose. Java est jouable pour des mainframes ou la vitesse n'est pas génante, vu la puissance qui est sous le capot. Pour moi, dans l'état actuel des choses, programmer un Java rapide est très dur, bien plus que du C, et très contraignant.
  • [^] # Re: Si seulement j'avais la becane pour...

    Posté par  . En réponse à la dépêche Loki brade ses jeux pour les LUGs. Évalué à -1.

    Wow... T'es un couillu, toi ! Oublie pas de mettre un vieux carton de pizza et une canette de bière, en dessous de ton poster des X-Files, à côté de ta bécane ouverte...
    J'ai une idée, pour ta toute première solution commerciale : une solution pour placer automatiquement les accents sous Linux. Cool, hein ?
  • [^] # Re: Une question : c'est où ? (no txt)

    Posté par  . En réponse à la dépêche [GUILDE] Linux Party 21 avril. Évalué à 0.

    C'est ecrit en GROS au début de la news...
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    Windows est le systéme d'exploitation le plus utilisé sur la planéte.
    Contrairement à ce que tu dis, Sun est trés bon au niveau marketing parce qu'ils ont réussi à imposer java malgré toutes ses lacunes (opinion propre à moi-même). A la seule évocation du mot EJB, les marketings et les investisseurs sont aux anges et les développeurs pleurent leurs méres!
    La où ils sont forts, c'est qu'ils sont arrivés à faire croire aux développeurs qu'un seul language est bon pour toutes les situations. Il n'y a qu'à voire la percée de java dans le monde du web. Dernier arrivé mais premier dans les coeurs même si les temps de dév et le nombre de devs sont multipliés par 2, sans parler des serveurs qui sont sur les rotules.....
    Grâce à java, aprés les applis qui plantent, voici les sites web qui plantent (tm)(Internal server error chéri!)
  • [^] # Re: Les jeux pour Linux seulement n'ont pas d'avenir

    Posté par  . En réponse à la dépêche Loki brade ses jeux pour les LUGs. Évalué à -1.

    Peut être que je devrais me la fermer. Je te signale que quand je dis clap clap, c'est que j'applaudis réellement cette initiative et qu'il n'y avait rien d'ironique.
    -1 pour ma peine
  • [^] # Re: Pathétique ...

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    Oui, mais bon, on n'est obligé de faire du C/C++ pour être rapide, on peut faire du C# aussi !
  • [^] # Re: Bonne nouvelle :-)

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    J'espère qu'avec JUMP je pourrai le convertir en C# histoire que ca rame un peu moins... Nan, paske au moins C# c'est rapide... A peine 10% plus lent que du C/C++, c'est dire !
  • [^] # Re: désolé de vous décevoir

    Posté par  . En réponse à la dépêche Loki brade ses jeux pour les LUGs. Évalué à 0.

    pas de pb avec Internet Explorer contrairement a netscape, Konqueror et tous ces logiciels buggué et inutilisable !!

    des trolls dans la news Mandrake , j'en ai vu !! oui , c vrai , mais bon c'était plutot gentil :

    moi j'suis suse moi j'suis mandrake !! enfin bref a par le nom pas une grosse différence a mon avis ... si ce n'est que ça plante pas toujours au meme endroit .... le fait est que les deux plantes qd meme pas mal !! et si tu veux du troll :

    contrairement a W2K : a mon avis la meilleure distri linux !!
  • [^] # Re: Pathétique ...

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    Ouais, sauf ke plus les procs augmentent en puissance, plus les applis sont demandeuses en puissance, et le cout de l'interpretation de java, meme s'il diminue (bô progres meme) est toujours la.
    Resultat, t'as bô avoir un proc a 2Ghz, ton java te bouffe toujours trop de ressource par rapport a autre chose.

    Pis pas la peine de lancer un troll la dessus. C'est juste mon avis :-)

    David Jobet

    --
    Toujours pas logge. A pu password.
  • # Un hacker français poursuivi par la DST

    Posté par  . En réponse à la dépêche Un hacker français poursuivi par la DST. Évalué à 0.

    Lorsque l'état espionne les particuliers sous couvert de la raison d'état et ce au mépris total des libertés individuelles, ils trouvent ca tout à fait légal, par contre quand par un juste retour des choses, un particulier en fait de même, ils appellent ca du terrorisme !!

    Ils me font bien rire ces politiques, et on nous parle après de liberté, égalité,frat.....AH AH AH
  • [^] # Re: en JAVA????

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à -1.

    neuneu, crétin, naze, imbécile, ...
    Un peu plus qu'ailleurs, le moi-je-sais castrateur est roi ...
    Constatation simple et quotidienne d'un vocabulaire qui n'interpelle plus personne ...
  • [^] # Un beau jeu Win (et bientôt Linux)

    Posté par  . En réponse à la dépêche Loki brade ses jeux pour les LUGs. Évalué à 0.

    Vous aimez les robots ? Zieutez ça

    http://www.cognitoy.com/mindrover/mindrover.htm(...)
  • [^] # Re: Les jeux pour Linux seulement n'ont pas d'avenir

    Posté par  . En réponse à la dépêche Loki brade ses jeux pour les LUGs. Évalué à 0.

    "Pas de fierte dans cette affirmation, juste une constatation."
    ça a me fout de mauvais poil ce genre de phrase. Tiens, je constate que j'avais le choix entre quake 3 sous linux et quake 3 sous zindoze. Tiens, je constate que j'ai acheté la version zindoze. Tiens, je constate que parfois je suis complètement con mais que je n'y peux rien. Mais remarquez bien que ce n'est qu'une constatation.
    "Les marches n'ont pas besoin de soutien. Ils existent et se developpent, ou disparaissent."
    cf schneider ci dessous
    "je suis en train d'essayer de developper un driver pour les joysticks a retour de force"
    Ouaiiiii, ça c'est une initiative bien cool. clap clap, bravo. Surtout, si un jour vous pensez que cela fonctionne, faites nous un package simple à installer.
    "il faut viser le marche Win+Linux". Il est clair que les éditeurs de logiciels visent le marché le plus grand possible. Mais les éditeurs de logiciels ne sont pas les développeurs bénévols. Imagine que tu montres un super jeu qui n'existe que sous linux et pas sous zinedoze. De plus je te dirais qu'il ne faut pas développer le marché merdosoft.
  • [^] # Re: Pathétique ...

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    hummm, sa me rappelle le discours d'1 certain Bill ki disait il y'a longtemps, "personne n'aura besoin de plus de 2Mo de RAM", ou un truc du genre...

    Sauf ke lui cé le contraire, il pense ke cé les soft ki ne demenderaont pas tjrs + de CPU, cé ridicule de dire ke son soft il tournera tres bien ds 3ans, parce k'il sera depasse ! ;))
  • [^] # Re: Et Ruby, hein ?

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    > moralité: le meilleur langage, c'est le plus récent qui a réussi ses multiples héritages.
    Justement, je viens de regarder la FAQ Ruby, ce n'est qu'un langage à héritage simple ! Même le modèle objet dynamique de GTK+ (qui sera séparé pour être mis dans la GLib 2.0 pour que des projets comme Gstreamer puissent l'utiliser sans nécessiter GTK+) autorise ça. Et franchement, quand on a gouté à l'héritage multiple, on ne peut plus s'en passer (sauf en C++ pour lequel la lourdeur de la syntaxe est telle qu'on préfère faire comme si cette possibilité n'était pas offerte).
  • [^] # Re: mon opinion la d'ssus

    Posté par  . En réponse à la dépêche Linux Magazin 05/2001. Évalué à 0.

    tu m'etonnes, je vais pas alle en allemagne pour achete mon Linux Mag, en + je ne comprends rien à cette langue ;))
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    Il me semble que dans ce cas, le pb vient plutôt de la gestion des pré/post conditions dans Eiffel (et là, on est totalement hors Java).
  • # désolé de vous décevoir

    Posté par  . En réponse à la dépêche Loki brade ses jeux pour les LUGs. Évalué à 0.

    mais l'avenir de linux dans le domaine des jeux vidéos est a mon avis bien compromis. déja par le fait que linux dans sa conception n'est pas prévu pour le jeux avec son système Xwindows trop lourd, on s'apercois des biens pietres performances de ce dernier , rien qu'en essayant des jeux comme tuxracer, qui rame a fond alors qu'il n'a rien de transcendant comme graphisme .

    Un conseil gardez vous bien d'acheter des jeux sous linux , sinon vous serez toujours perdant lors de vos partie en rézo a cause du temps d'affichage des graphismes !!

    Achetez vous plutot un windoze et régalez avec un système prévue a cet effet ... et laissez linux faire ce pour quoi il a été conçut : un serveur Web !! préférez meme un *BSD qui sera plus performant !! en bref que reste t il a linux ...
  • [^] # Re: English... Baaaah...

    Posté par  . En réponse à la dépêche Loki brade ses jeux pour les LUGs. Évalué à 0.

    pour info:
    Civilization Call to Power (confirmé),
    HeroesIII(confirmé),
    SimCity3000(a verifier)
    disposent des modules francais.
    Le jeu est installé automatiquement en francais si le systeme (LANG...) est lui-meme configuré en francais.

    il n'y a plus aucune raison pour ne pas jouer ss linux :-)

    Pascal.
    mailto:pkuczynski@linbox.com
  • [^] # Re: en JAVA????

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à -1.

    ... mal été compris par des crétins dans ton genre ...
    Simplement hautain. C'est vrai qu'il a été insultant ...

    Et un -1 pour éviter la censure ...
  • [^] # Re: Si seulement j'avais la becane pour...

    Posté par  . En réponse à la dépêche Loki brade ses jeux pour les LUGs. Évalué à 0.

    Si c'est pas indiscret, c'est à cause d'un probleme de driver que les jeux 3D ne tournent pas ?

    Parce que sur mon P400, 128MoRAM, XFree3.3.6 Voodoo 3 (3dfx), UnrealTournament et Quake 3 tournent impeccablement
  • [^] # Re: en JAVA????

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    Juste une remarque : avec les passions que java déchaîne ici, je crois qu'il n'est pas prêt de tomber dans les oubliettes de la micro ;-)))
  • [^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    Pour les classes natives, est-ce que les sources sont dispo ?

    par ex :
    méthode java.io.File.isFile() :
    "Tests whether the file denoted by this abstract pathname is a normal file. A file is normal if it is not a directory and, in addition, satisfies other system-dependent criteria."
    J'aimerais savoir quels sont ces critères (device, tube nommé, lien symbolique, ... ???) mais dans les sources fournies par Sun (et qui m'ont bien souvent aidées), la méthode est déclarée "native" => et m****

    PS : je poste cette question de manière exceptionnelle et oportuniste : je sais qu'on est pas sur le SAV de sun ;-)
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.

    T'as un exemple pour le débuggage ?
    Pas forcément indispensable? si tu utilises java, dis-toi qu'à chaque fois que tu implémentes deux interfaces dans une classe, tu aurais pu hériter de 2 classes abstraites dont tu n'aurais eu à définir que 2 ou 3 routines d'accès (tout le reste du code étant déjà fait)...