AccueilAccueil  FAQFAQ  RechercherRechercher  S'enregistrerS'enregistrer  MembresMembres  Connexion  

Partagez | 
 

 Débat programmation [1] : Pour ou contre le Java?

Voir le sujet précédent Voir le sujet suivant Aller en bas 
Aller à la page : 1, 2  Suivant
AuteurMessage
Asu
Utilisateur confirmé: Rang ****
avatar

Messages : 895

MessageSujet: Débat programmation [1] : Pour ou contre le Java?   Mar 15 Oct 2013 - 19:29

Histoire de relancer un peu la vie du forum j'ai décidé de faire quelques débats sur la programmation ( Pas forcément game maker ) et dont le thème de celui-ci est : Pour ou contre le langage Java?

A vous de débattre en échangeant conseils, astuces et idées!

_________________
‎<‎Cysteine‎>‎ nON mais la touche maj s'active/se désactive toute seule
‎<‎Cysteine‎>‎ et a du mal à réponDRE QUANd j'appuie dessus
‎<‎Cysteine‎>‎ et je l'ai démont2? IL Ny a rien DEDANs
Revenir en haut Aller en bas
marty
Utilisateur confirmé: Rang ***
avatar

Messages : 697
Projet Actuel : laby-ereinte !

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 15 Oct 2013 - 20:08

pour faire vivre la communauté:

lorsque quelqu'un propose un projet un tant soit peu intéressant et demande
5 pauvres minutes de votre temps et étant donné que c'est votre passion et que vous aimez partager votre approche du jeu vidéo, en tant concepteur et utilisateur, vous devriez participer à ce type de sujet :http://cbna.forumactif.com/t12493-totem#344471
au lieu de polémiquer une énième fois sur les différences entre les langages de programmation.

merci Smile

_________________
Code:
rnd=>insight=>play

http://gamemaker.info/fr/manual



Revenir en haut Aller en bas
Asu
Utilisateur confirmé: Rang ****
avatar

Messages : 895

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mer 16 Oct 2013 - 10:58

J'ai regardé ce jeu qui m'a l'air intéressent ( Je l'ai testé ) mais je n'ai pas trop d'avis dessus vu que c'est vachement court.

Je suis en train de faire mes premiers pas en Java, je sais pas si c'est que le tutoriel est mieux expliqué mais j'y arrive vachement mieux qu'en C++ avec lequel je me cassais la tête tout le long pour faire un truc en deux heures au lieu que je le fais en deux minutes en Java.

Pour ceux qui n'ont pas trop d'idée de ce qu'est le Java, voici un de mes codes que j'ai fait ( Relativement simple pour l'instant ) :

Testclass ( Où est stocké mon main )
Code:
public class Testclass {
   public static void main(String[] args) {
      Ville inst = new Ville("Marseille","France",666);
      inst.debugInfos();
   }
}
Ville ( Vous pouvez voir qu'il est appelé dans le main )
Code:
public class Ville{
   
   private String varName;
   private String varCountry;
   private int varPeople;
   
   public Ville()
   {
      System.out.println("Now generating a instance of 'Ville' with default constructor.");
      varName = "Default city name.";
      varCountry = "Default city country.";
      varPeople = -1;
      System.out.println("Generation ended.");
   }
   
   public Ville(String varName_gen, String varCountry_gen, int varPeople_gen)
   {
      System.out.println("Now generating a instance of 'Ville' with custom constructor.");
      varName = varName_gen;
      varCountry = varCountry_gen;
      varPeople = varPeople_gen;
      System.out.println("Generation ended.");
   }
   
   public String getCity()
   {
      return varName;
   }
   
   public String getCountry()
   {
      return varCountry;
   }
   
   public int getPeopleLivingin()
   {
      return varPeople;
   }
   
   public void debugInfos()
   {
      System.out.println("DEBUG > debugInfos() called");
      System.out.println("dbg > Name of the city : " + varName);
      System.out.println("dbg > Country of the city : " + varCountry);
      System.out.println("dbg > People living in the city : " + varPeople);
   }
}
Bien sûr, ça reste bien plus complexe que le GM ( Bon, sauf par rapport aux bugs débiles et incompréhensibles que l'on trouve très souvent avec GM gnii ), mais ça peut fournir de bien meilleures bases pour se jeter dans le bain du C++.

Un des côtés de Java qui sont mal pris, c'est souvent sa lenteur ( Pourtant, c'est pas si si lent que ça ) par rapport aux autres, comme le C++. Je suppose que vous vous faites cette idée avec Minecraft, avec lequel on avait 400 FPS en alpha avec une cg de ***** et que maintenant on en a 20 Yum! .

Un des plus gros avantages du Java, ce qui en fait qu'il est très réputé, c'est sa compatibilité. En effet, n'importe quel PC avec la JVM installée peut faire tourner les programmes Java! Il me semble même qu'Android gère les applications Java, et iOS ( Je ne sais pas si ça en est déjà le cas ou si ça le sera ou si ça ne le sera pas ).

_________________
‎<‎Cysteine‎>‎ nON mais la touche maj s'active/se désactive toute seule
‎<‎Cysteine‎>‎ et a du mal à réponDRE QUANd j'appuie dessus
‎<‎Cysteine‎>‎ et je l'ai démont2? IL Ny a rien DEDANs
Revenir en haut Aller en bas
Térence
Utilisateur confirmé: Rang *****
avatar

Messages : 2213
Localisation : Oui

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mer 16 Oct 2013 - 15:16

Bah java c'est cool, si tu sais l'utiliser à peu près correctement Smile
Ce qui est sur c'est que c'est bien plus rapide que GM si c'est optimisé correctement (ce que n'est pas minecraft). Ce qui est assez intéressant, c'est les possibilités : ia pleins de fonctions de bases déjà présente, et c'est particulièrement vrai pour tout ce qui est dessin : genre les courbes de béziers sont super simples à faire, le flou pareil (et avec matrice, donc tu peux faire un morceau plus fous que l'autre), et ia toutes les opérations de rotation, mise à l'échelle, anti-aliasing,etc... Il te gère meme les collisions entre polygones, ce qui est assez intéressant par exemple pour un losange qui tourne sur lui-meme, alors que dans un autre langage tu dois te farcir des alog de fous, bah là c'est implémenté (m'enfin très basiquement quand meme). Pareil, autre avantage, c'est la GUI implémenté de base, alors qu'en C++ faut passer par des intermédiaires (Qt pour la GUI, sfml/sdl pour le dessin).
Par contre niveau défauts : les layouts : un bordel pas possible pour placer un ****** de composent correctement... Puis aussi le problème c'est qu'apparement ca marche pas toujours chez tout le monde (genre mon RPG, ia bug chez une personne sur deux x) ). Ensuite, j'ai pas beaucoup essayé de porter sur android, mais c'était déjà un gros bordel pour dl les sdk et autres alors... Puis sur apple, faut pas rever, faut un langage spécifique ; et ses ******* de chez windows ne donnent pas accès aux nouvelles fonctionnalités de win8 avec java... Donc niveau portabilité c'est moyen, éjà que sur PC c'est pas gagné Razz

_________________
Je suis partie sur les ailes du vent et la tempête m'a ramenée.
Revenir en haut Aller en bas
SPLN
Utilisateur confirmé: Rang ***
avatar

Messages : 588
Localisation : Sur son ordinateur *vous vois* arrêtez de me regarder comme ça
Projet Actuel : En quête de projet(s)!
Mes projets:
SP Lecteur Multimedia (Stand by)
S-Portable Graphics (demo1.8 is out! demo2.0 is planned)
SSB RPG (Stand by)

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mer 16 Oct 2013 - 18:20

Moi ça fait un petit bout de temps que je code en Java. Hormis les layout, l'avantage considérable est le fait de pas avoir à se faire ch*** à compiler ton programme pour tant d'architecture si tu veux qu'il soit multi-plateforme sans avoir à libérer les sources et à le recompiler soit même. Perso je code souvent des petits outils en plus de changer d'OS entre Linux et Windows selon ma convenance.

Je trouve également que le java est moins dur que le C(++), quand je suis passé du GML => C++ j'ai vite lâché prise. Du coup je me suis mis à java pour les raisons cités plus haut. Après j'ai bouffé à l'école il y a 2 semaine du C, ça passe déjà un peu mieux. Pour ma part j'ai appris le Java via un Livre datant de l'an 2000. Le support papier m'a nettement mieux aider que de chercher sur le web des tutos (genre SDZ :v/).

En revanche le gros bémol de Java c'est la mémoire, tu peux difficilement la gérer et c'est ce qui rend java si accessible, mais si peu optimisé/able. Contrairement au C(++) qui lui t'oblige à la gérer quitte à ce que coder devienne plus dur avec des pointeurs, mallocs et cie. mais déjà plus optimisé.

_________________
SP Lecteur Multimedia
I am an in the GM Quiz!
Revenir en haut Aller en bas
http://sp-lecteur-multimedia.skyrock.com/
arthuro
Utilisateur confirmé: Rang ****
avatar

Messages : 1322
Localisation : Grenoble / Méribel
Projet Actuel : CBNA

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Jeu 17 Oct 2013 - 21:02

La première fois que j'ai essayer Java, j'ai détesté. Cela m'avais semblé trop haut niveau et quelques incompréhensions de ma part mon mis l'idée que Java c'était n'importe quoi. ( Et puis voir la lenteur de Minecraft ne donnait pas envie d'essayer)

Finalement j'ai été forcé de faire un projet en Java, et finalement Java c'est sympa!

C'est comme le C++ sauf qu'on utilise une Garbage Collector (désalocateur de mémoire), ce qui permet d'utiliser massivement des références de manière un peu plus safe.
En C++, on alloue beaucoup d'objets sur la pile et non sur le tas. Et ce surtout pour que ça mémoire soit désalloué toute seul à la sortie du bloc. On a tendance en C++ à faire des objets qui se contiennent, en Java des objets qui se font références.

Quelque chose que j'aime bien en Java. C'est que tout objet est comme une référence vers la zone mémoire de l'objet alors qu'en C++ c'est directement la zone mémoire. En java c'est comme si on utilisait que des pointeurs.
De plus c'est la version dynamique des méthodes qui sont appelé dans tout les cas.
Par exemple:
Si j'ai une class B qui dérive de A.
Si A possède la méthode f et g
A::f()
{
g()
}
et B redéfinit g
Si je fait:

A a=new B();
a.f()

j'ai appelé A::f() qui a appelé B::f() (et non A::f())

Alors qu'en C++ on se serait attendu a l'inverse.
Autrement dit en Java, les méthodes sont virtuel par défaut.

Puis finalement, l'environnement Java fournis est plutôt bien architecturé je trouve. (Pour le peu que j'ai vu)

Conclusion:
Le Java c'est sympa.
De toute manière il n'y a pas vraiment à être contre un langage en particulier.

Note: Cela fait pas longtemps que j'ai essayé Java. C'est possible que je dise des bêtises.

_________________

D'autres jeux :
In The Cube
In the cube 2
Revenir en haut Aller en bas
Mass
*Excellent utilisateur*
avatar

Messages : 3325
Localisation : Dans une canonnière wookie.
Projet Actuel :
Things


MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Ven 18 Oct 2013 - 18:30

Mon dieu, la boite de Pandore est ouverte mop 

_________________
Revenir en haut Aller en bas
http://madmass.mype.fr/CBNA/
onilink_
Modérateur
avatar

Messages : 8902
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Ven 18 Oct 2013 - 21:07

Ahah, mais effectivement être contre un langage ça veux pas dire grand chose, même celui ci souffre de quelques lacunes.

Java perso j'aime pas trop, car déjà je me suis habitué a la puissance (autant au niveau gestion de la mémoire que opti/contrôle, etc) des langages bas niveau tels que le C ou le C++, mais aussi car j'ai eu pas mal de mauvais retours quand a la jvm qui optimiserait très mal la mémoire.
Puis bon aussi le langage m'attire pas plus que ça, j'en ai fait a la fac et ça m'a pas donné des masses envie de continuer, même si le langage est énormément plus riche que le GML.

Encore un truc qui fait que j'aime pas java: le fait de devoir passer par celui ci pour faire des applis android ... bonjour la misère pour dev sur Ouya et compagnie quoi.

_________________
                 
Revenir en haut Aller en bas
En ligne
daminetreg
Administrateur
avatar

Messages : 16994
Localisation : Siege du CBNA!
Projet Actuel : Site Web du CBNA, version beta :

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mer 30 Oct 2013 - 23:34


Je programme quasiment autant en java qu'en C++ tous les jours, environ 10h/jour. Et du fait de l'expérience acquise depuis plus de 5 ans j'ai un avis objectif à propos de java.

A mon sens son avantage est sa grande API, mais de nos jours il n'est de loin plus le seul a posséder une API centrale écrite selon les même conventions et multiplateformes. D'autant qu'elle n'est pas sans bugs qui sont rarement corrigé sur les plateformes non mainstream (linux est vu comme tel par Oracle).

Pour moi, en revanche il a des désavantages très inquiétants, qui n'en font pas un langage valide pour de nombreuses applications, et aussi des décisions architecturelle et philosophiques propre au langage, qui, à mon sens, rendent la vie des développeurs et de fait des utilisateurs difficile.

Ce langage ne supporte pas l'idiome RAII (Resource Acquisition Is Initialization) : cela fait du langage un outil très peu sérieux pour n'importe quelle tâche autre que de l'algorithmie pure avec des données allouée autrement que sur la pile.

En effet lorsque vous ouvrez un fichier, un memory mapping, une socket ou quoi que ce soit d'autre, vous n'avez aucunement la garantie qu'il sera fermé en cas d'erreur ou en cas de fermeture de l'application.

Vous ne pouvez en avoir la certitude que si vous le fermez là où vous l'avez ouvert: dans la même fonction (i.e. finally). Mais si l'objet vie plus loin que cette fonction, il vous faudra partout dans votre code, même du code qui n'a rien à voir avec cet objet (i.e. Et qui donc ne peut intéragir avec l'objet) trouver un moyen de fermer la ressource que cet objet a ouvert. En effet, si une exception arrive n'importe où dans le code, votre application risque d'être fermée ou de sortir du contexte dans lequel elle est et les ressources ouvertes elles ne le seront pas.

Cela a des conséquences gênantes en fonction de l'OS: par exemple un memory mapping d'un fichier sur windows (ouvert avec java.nio.MemoryMappedByteBuffer) sera à moitié sauvegardé si "close()" n'est pas appelé, ne contenant pas toutes les modifications que vous avez faites (i.e. Imaginez une base de données qui se corrompt automatiquement dès que vous avez une erreur qui l'amène à la fermeture). C'est un exemple et il y en a pléthore.

Certains dirons qu'il y a les finalizer qui sont une sorte de destructeur en java, cependant ils ne permettent rien à part quelques optimisations et sont même déconseillé : Il n'y a aucune garantie que les finalizer de vos objets seront appellés, même suite à une erreur fatale, ou lors de la fermeture de l'application. La fonction qui serait sensé activer cela, ne fonctionne justement pas (i.e. System.runFinalizerOnExit est deprecated et n'a pas d'impact ou un semi-impact sur les différentes implémentations de vm que j'ai vu). Et encore pire une instance d'une classe ayant un finalizer verra sa garbage collection remise à plus tard.

Parce que java part du principe qu'appeller le finalizer peut prendre du temps (i.e. On sait pas ce que le programmeur a fait dans cette fonction) et pour optimiser l'action du garbage collector (qui mange déjà du temps d'execution au CPU) l'implémentation officielle de la jvm (i.e. oracle/sun) délaye la garbage collection. Donc vous avez durant plus longtemps un usage mémoire qui peut-être gênant selon les limites de votre systèmes, et ce pour peut-être mais sûrement pas voir le finalizer appelé.

Plus de détails : http://asserttrue.blogspot.fr/2008/11/finalization-is-evil.html

Ce langage est uniquement orienté objet comme si les gens qui font java se disent que c'est la seule façon viable de résoudre n'importe quel problème. Par exemple la programmation par concept, la meta-programmation, la programmation fonctionnelle n'est pas possible de façon acceptable. Cela a des conséquences sur la performance des applications au final, car de nos jours on essaie d'écrire du code lisible et compréhensible, mais avec un seul paradigme on en vient à en abuser pour obtenir des abstractions permettant la généricité et cela a un impact sur la performance et la facilité de maintenance des applications (i.e. La plupart des abstractions uniquement orienté-objet requiert une modification de l'abstraction pour l'ajout d'une nouvelle implémentation de façon optimale). C'est peut-être pas dans toutes les têtes mais la résolution d'un problème avec plusieurs angles de vue est dans la plupart des temps un compromis optimal, bien meilleur en pratique que l'extrêmisme dans une seule façon de voir un problème. Et java a une philosophie extrême en ce qui concerne l'orienté objet. Ni Java 7, ni java 8 ne change quoi que ce soit à ce niveau là.

Java n'aime pas cohabiter, java consomme beaucoup de mémoire, mais pas toujours autant qu'on ne croit le voir dans la liste des processus. En effet le fait que chaque application java nécessite autant de RAM est dû au principe de garbage collection et à la façon dont java charge les classes et les compile durant l'exécution. Cela ne veut pas dire que les objets java présents dans le morceau de RAM réservé consomme tout, car souvent ils n'en usent qu'une toute petit partie.

Java utilise cet espace pour grouper les objets en fonction de leur génération (i.e. Objets vivant plus ou moins longtemps). Ce principe en revanche, reproduit dans toutes les vm que je connaisse ne lui permet pas d'utiliser plus de mémoire qu'on ne lui en donne au démarrage. C'est pourquoi les applications java sont gênantes sur une machine qui doit faire fonctionner différentes applications, elles réservent toujours un certain minima et en fonction des paramètres (dont les valeurs par défaut sont peu promptes à la cohabitation usent plus ou moins de RAM même si elle n'est pas nécessaire).

Java aligne de façon très gaspillatrice les valeurs en mémoire : Les règles d'alignement mémoire de java coûtent cher et ne sont pas adaptés à la plateforme sur laquelle la jvm tourne, cela pose problème lorsqu'on a beaucoup d'instance de la même classe. Aussi chaque instance a une référence stockée dans l'object header. Chaque object header coûte 8 byte donc une instance d'un tableau de byte avec une seule entrée, prend déjà 16 bytes sur une jvm 32bit : il y a un overhead de 12 bytes pour chaque tableau, object header (8 byte) +  length field (4 byte) et la jvm 32 bits aligne par multiple de 4. Et là on ne parle que de types primitifs.

C'est peu de prime abord, mais c'est très limitant si vous avez de grosses collections d'objets à traiter, vous n'avez aucune chance de réduire leur taille en alignant mieux, car quoique vous fassiez vous aurez toujours cet overhead sur lequel vous n'avez aucun contrôle.

Si cela vous intéresse plus : http://scn.sap.com/people/markus.kohler/blog/2006/12/04/reducing-the-memory-consumption-of-your-java-application-part-iv & http://www.javamex.com/tutorials/memory/object_memory_usage.shtml

Java est lent : tout code écrit en java qui n'est pas juste un algorithme trivial travaillant des double/int/float résulte en appels de méthodes par vtable, l'unique paradigme objet et la nature runtime de java, font qu'un code java qui doit être performant doit forcément être écrit de manière peu commode et au sein d'une seule méthode avec le tout dans des variable locales et triviales (int, double...) ce qui rend tout code devant être performant non maintenable, et au final il est moins performant qu'un code propre, maintenable et lisible écrit en un langage non-interprété). Et le pire c'est qu'un code écrit ainsi n'est pas réutilisable avec différents types, autrement il devrait faire appel au generics qui induise automatiquement l'overhead de l'autoboxing/unboxing.

Là où java est parfois plus rapide que certains compilateurs C++ ce sont pour des algorithmes qui travaillent des valeurs mathématiques simples (float, int, double...) qui sont dans une seule et même fonction, cela généralement résulte en de meilleures performances qu'en C/C++ car l'optimisation avec le JITter est plus simple à effectuer qu'avec une optimisation définie à la compilation. Si jamais cela vous intéresse : http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/

Enfin java n'est pas un standard libre, bien qu'il se vende comme tel, Oracle possède java et seul Google (en réimplémentant tout et en refaisant toute l'API) a réussi à faire sa propre implémentation embarquée java sans perdre de procès. Et java est hautement commercial, car selon Oracle/Sun java est un langage parfait et surtout avec leurs serveurs. :)Aussi vous savez que si vous faites une appli java pour autre chose que x86/AMD (e.g. ARM) vous devez payer une license à Oracle car java est libre uniquement pour x86/AMD. Ma boîte paye 10 USD par device ARM vendue à Oracle.

Pour finir j'ai une profonde préférence pour le C++ qui d'une part est le langage dans lequel java est implémenté et d'autre part qui propose bien plus de paradigmes et est perfectionné par un comité ISO et une communauté gigantesque qui pensent d'abord à faire avancer le progrès qu'à gonfler leur porte-monnaie. Oracle/Sun est une entreprise, elle fait du profit, son but n'est pas de rendre le monde meilleur:

If an open source product gets good enough, we'll simply take it.... So the great thing about open source is nobody owns it – a company like Oracle is free to take it for nothing, include it in our products and charge for support, and that's what we'll do. So it is not disruptive at all – you have to find places to add value. Once open source gets good enough, competing with it would be insane. ... We don't have to fight open source, we have to exploit open source. - Larry Ellison,
Financial Times interview (18 April 2006), founder of Oracle

SPLN a écrit:
En revanche le gros bémol de Java c'est la mémoire, tu peux difficilement la gérer et c'est ce qui rend java si accessible, mais si peu optimisé/able. Contrairement au C(++) qui lui t'oblige à la gérer quitte à ce que coder devienne plus dur avec des pointeurs, mallocs et cie. mais déjà plus optimisé.
Du code C++ respectant un style datant du standard de 2003 ne devrait utiliser aucun pointeur, il devrait utiliser uniquement référence + pile, et si des pointeurs sont nécessaires du fait de l'utilisation d'anciennes API ou pour X raison alors les utiliser avec boost::shared_ptr, boost::unique_ptr ou en C++11 std::shared_ptr, std::unique_ptr. Cela gère la mémoire pour toi et l'overhead est moins que minimal.

Les pointeurs c'est pour les gens qui écrivent du C et qui le compile avec un compilateur C++. :p

_________________
Mon CV : fr - de - en
Le CBNA Tous Ensemble! Réalisons!
Revenir en haut Aller en bas
http://lecbna.org/
M@d_Doc
Modérateur
avatar

Messages : 6599
Localisation : 47°44'8.04
Projet Actuel : aucun

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Jeu 31 Oct 2013 - 8:18

Oui, mais Java a un nom rigolo.

_________________
Tous les icones de gm utilisables sur le cbna ICI
Revenir en haut Aller en bas
http://www.lecbna.org
Wargamer
*Excellent utilisateur*
avatar

Messages : 6936
Projet Actuel : Bataille de cake au fruits

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Jeu 31 Oct 2013 - 11:24



J'ai utiliser Java quelques fois, à chaque fois c'était la *****.
La première fois mon code plantait sans raison dans une application vide, ensuite il s'es mis à ne plus compiler mes fonctions(error method not found), ensuite Eclipse s'est mis a planter non stop.

Et le fait de devoir coder une classe au complet dans un seul fichier est illisible, vive les partial class ou le C.

J'aime pas le java Yum!

_________________

Règle #1 du CBNA, ne pas chercher à faire dans la subtilité; personne comprend
Revenir en haut Aller en bas
Mass
*Excellent utilisateur*
avatar

Messages : 3325
Localisation : Dans une canonnière wookie.
Projet Actuel :
Things


MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Ven 1 Nov 2013 - 16:31

Jvous emmerde avec mon tricycle rire2 

_________________
Revenir en haut Aller en bas
http://madmass.mype.fr/CBNA/
Sekigo Le Magnifique
Utilisateur confirmé: Rang *****
avatar

Messages : 1720

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Sam 2 Nov 2013 - 0:44

La voiture C.
Tu montes dedans. Tout à l'air simple, rapide. Tu fonces sur l'autoroute avec. D'un seul coup, tu remarques un étrange sillon derrière toi. C'est une fuite d'essence. À 200 sur l'autoroute, ta voiture explose.

La voiture C++.
Le vendeur te dit "on a amélioré les problèmes de fuites mémoires, et y a plein de nouvelles fonctionnalités". Tu montes dedans. Le tableau de bord est remplacé par celui d'un avion. Il y a une bibliothèque complète dans le coffre pour apprendre à démarrer la voiture. Tu dois compiler la clé pour ouvrir le coffre.

La voiture C#.
Elle est superbe. Tout le monde en parle. Elle démarrerait au quart de tour, serait aussi rapide que la voiture C, et est accompagné avec un tas d'options. Tu la veux. Tu vas voir le vendeur, il te demande ton âme en échange. Tu remarques aussi les innombrables bolides mis à la casse derrière le vendeur.

La voiture Java.
Elle est belle, elle est rapide. Mais un détail te turlupine. Elle est accompagné d'une citerne-essence en guise de remorque. Il y aussi une tonne d'ingénieurs dans la voiture, et quand tu rentres dedans, ils t'assaillent de mots incompréhensible "factory, ant, DémarrerAvecLeContactEtÇaAllumeAutomatiquementLaRadio, blablabla"

La voiture Python.
Le moteur, les roues et tout ce qui est technique sont fabriqué par l'usine C (mais tu peux aussi te fournir chez Java ou C#). En fait, il n'y a que l'habitacle et le volant qui sont réalisé par le fabriquant. Elle est génial, elle roule pas aussi vite que les autres mais t'emmène là où tu veux.

La voiture Perl.
Tu rentres dedans. Bizarre, pas de tableaux de bord. Un manuel est dans la boite à gant, tu le lis et tu comprends qu'il faut que tu le réalise toi-même, et que ce n'est pas trop compliqué. Tu le fais, et tu démarres. Tu t'arrêtes au supermarché, tu fais tes courses et quand tu rentres de nouveau dans la voiture, tu as oublié comment fonctionne ton tableau de bord.

La voiture Php.
Le vendeur te dit qu'elle est simple à utiliser. Bien plus que tout les autres modèles. La preuve, ils ont remplacé le levier de vitesse par une boite automatique relié directement au moteur C. Tu remarques cependant qu'ils ont placé des pédales-objets de chez Java, ce qui fait tâche dans un truc sensé être simplifié. Mais tu n'es pas obligé de t'en servir, tu verras ça plus tard.
Tu démarres, ça va pas aussi vite que les autres voitures, mais c'est bien suffisant et ça a l'air de rouler dans la bonne direction. À 500 mètres de ta destination, le gps t'indique un message "Warning". Soudain, la voiture explose, ainsi que tout ce qui se trouve dans un rayon de 50Km.


(inspiré d'un vieux truc que j'avais lu sur les systèmes d'exploitation vers 2003-2004)
Revenir en haut Aller en bas
http://s2.noelshack.com/old/up/gmzonecbna-3cfbc56d25.jpg
Mobi
Utilisateur confirmé: Rang ****
avatar

Messages : 1256
Localisation : Dijon

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Sam 2 Nov 2013 - 11:44

Étonnant tient, l'éloge du python.... quand arrêteras tu ta propagande awesome 

_________________
Revenir en haut Aller en bas
En ligne
Térence
Utilisateur confirmé: Rang *****
avatar

Messages : 2213
Localisation : Oui

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Sam 2 Nov 2013 - 11:56

A quand la voiture ODL ? guns 

_________________
Je suis partie sur les ailes du vent et la tempête m'a ramenée.
Revenir en haut Aller en bas
onilink_
Modérateur
avatar

Messages : 8902
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Sam 2 Nov 2013 - 12:12

Ah ben ça, un jour je l'espère x)
Mais bon il fera pâle figure a coté du C++ mrgreen2 

Marrantes ces images sinon, mais pour le C je suis pas trop d'accord avec les fuites de mémoire a gogo.
Cela dépend vraiment de ce que tu programmes, et comment tu programmes. Ce serait comme dire que le C++ est lent parce que tu as essayé de simuler l'univers avec un algo pourri et que ça rame mrgreen2

Pour python c'est vrai que c'est un langage vraiment super, je comprend qu'il en fasse les éloges, mais ça reste tout de même du scripting.

Sinon vous parlez beaucoup de langage impératifs la, faudrait quelques retours de langages fonctionnels :b
J'avais testé vite fait Haskell et Lisp, Lisp j'ai pas trop aimé mais le langage a l'air d'en avoir dans le pantalon même s'il reste très ****** d'utilisation. Haskell quand a lui a une bonne syntaxe, de bonne perfs, et permet de faire des trucs assez classes niveau code.
Par contre la logique même de l'algorithmique dans ces paradigmes est assez perturbante quand on a pas l'habitude...

_________________
                 
Revenir en haut Aller en bas
En ligne
Sekigo Le Magnifique
Utilisateur confirmé: Rang *****
avatar

Messages : 1720

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Sam 2 Nov 2013 - 13:08

(Arrête( c'( est( trop( bien( le (lisp)))))))
Le Haskell, je suis en train de l'apprendre. J'ai fais du XSLT, qui est un langage fonctionnel mais là uniquement pour transformer du xml en autre chose. Et ça m'a bien plu. Les possibilités de Python pour le fonctionnel sont aussi assez avancé (compréhension de liste, fonction-objet, imbrication, récursion, travail intensif sur des listes, etc...).
Le fonctionnel pur, c'est clair que ça décoiffe quand on découvre. En gros, imaginez un programme dans lequel les variables que vous assignez ne peuvent pas changer de valeur. Ça parait compliqué, mais y a un immense avantage : aucun effet de bord. Théoriquement, tout bug est détecté à la compilation, et il n'y a pas de bug (hormis les problèmes algorithmique). Après, ce n'est pas la seule particularité des langages fonctionnels, loin de là, mais ça donne un aperçu du "choc".
Le seul problème, c'est que le fonctionnel, ce n'est pas beaucoup utilisé en entreprise. Dans les secteurs sensible, clairement (et le plus gros recruteur pour Haskell est Facebook au passage. On cite souvent cette enreprise comme succès-story pour php, mais en fait, c'est bien plus compliqué que cela), mais pas dans la majorité des postes où vous postulerez. Ceci dit, apprendre les théories derrière le fonctionnel, ça a été probablement un de mes caps majeurs dans l'apprentissage de la programmation. Dans mon parcours, il y a un avant et un après fonctionnel. Mais pour appliquer ces théories, il vous faut un langage qui soit multi-paradigme, à la Python. Tiens, une bonne idée pour mon topic ça, le fonctionnel en Python.

Et il y a un langage que je surveille fortement du coin de l'oeil : Rust. Un beau mélange entre C/Haskell/Python/Ocaml/etc...
Revenir en haut Aller en bas
http://s2.noelshack.com/old/up/gmzonecbna-3cfbc56d25.jpg
onilink_
Modérateur
avatar

Messages : 8902
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Sam 2 Nov 2013 - 15:15

Oh, le rust ça a l'air super cool. Dommage par contre j'aime pas trop la syntaxe.
Les trucs genre
Code:
fn mult(m: int, n: int) -> int {
    return m * n
}
c'est quand même assez ****** a écrire. Bon après j'imagine qu'on finis par s'y faire.

_________________
                 
Revenir en haut Aller en bas
En ligne
Wargamer
*Excellent utilisateur*
avatar

Messages : 6936
Projet Actuel : Bataille de cake au fruits

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Dim 3 Nov 2013 - 13:11

http://en.wikipedia.org/wiki/Shakespeare_(programming_language)

Le seul et unique langage qui permet tout.

_________________

Règle #1 du CBNA, ne pas chercher à faire dans la subtilité; personne comprend
Revenir en haut Aller en bas
daminetreg
Administrateur
avatar

Messages : 16994
Localisation : Siege du CBNA!
Projet Actuel : Site Web du CBNA, version beta :

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 5 Nov 2013 - 23:39

Sekigo Le Magnifique a écrit:
(Arrête( c'( est( trop( bien( le (lisp)))))))
Le Haskell, je suis en train de l'apprendre. J'ai fais du XSLT, qui est un langage fonctionnel mais là uniquement pour transformer du xml en autre chose. Et ça m'a bien plu. Les possibilités de Python pour le fonctionnel sont aussi assez avancé (compréhension de liste, fonction-objet, imbrication, récursion, travail intensif sur des listes, etc...).
Le fonctionnel pur, c'est clair que ça décoiffe quand on découvre. En gros, imaginez un programme dans lequel les variables que vous assignez ne peuvent pas changer de valeur. Ça parait compliqué, mais y a un immense avantage : aucun effet de bord. Théoriquement, tout bug est détecté à la compilation, et il n'y a pas de bug (hormis les problèmes algorithmique). Après, ce n'est pas la seule particularité des langages fonctionnels, loin de là, mais ça donne un aperçu du "choc".
Le seul problème, c'est que le fonctionnel, ce n'est pas beaucoup utilisé en entreprise. Dans les secteurs sensible, clairement (et le plus gros recruteur pour Haskell est Facebook au passage. On cite souvent cette enreprise comme succès-story pour php, mais en fait, c'est bien plus compliqué que cela), mais pas dans la majorité des postes où vous postulerez. Ceci dit, apprendre les théories derrière le fonctionnel, ça a été probablement un de mes caps majeurs dans l'apprentissage de la programmation. Dans mon parcours, il y a un avant et un après fonctionnel. Mais pour appliquer ces théories, il vous faut un langage qui soit multi-paradigme, à la Python. Tiens, une bonne idée pour mon topic ça, le fonctionnel en Python.

Et il y a un langage que je surveille fortement du coin de l'oeil : Rust. Un beau mélange entre C/Haskell/Python/Ocaml/etc...
C++ n'est pas en reste niveau programmation fonctionnelle :

  • Function objects
  • Lambdas (C++11)
  • Boost Fusion
  • Boost Phoenix
  • Boost Functional : Forward, Factory...
  • FTL : Functional template library (https://github.com/beark/ftl)


Ce vendredi & samedi je serai à meeting c++ : http://www.meetingcpp.com/ il y avait l'an dernier des bonnes discussions sur l'intégration au c++ des bons côtés d'Haskell.

_________________
Mon CV : fr - de - en
Le CBNA Tous Ensemble! Réalisons!
Revenir en haut Aller en bas
http://lecbna.org/
Térence
Utilisateur confirmé: Rang *****
avatar

Messages : 2213
Localisation : Oui

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 12 Nov 2013 - 17:53

Bon, je up le topic pour dire un peu de bien de java ^^
C'est la quantité et la diversité des fonctions : ca permet d'économiser pas mal de temps pour se concentrer sur d'autres trucs. Par exemple, en une heure j'ai réussi à faire un moteur de collision qui gère toutes les formes géométriques : rectangle, cylindre et mêmes polygones ; le tout avec gestion de la rotation (je pourrais aussi avoir le scale et le shear mais pour moi c'est pas utile).
Donc en gros avec une fonction pour définir/rafraîchir le mask (2 fonctions surchargées pour un total de 5 lignes), une fonction pour récupérer le mask (8 lignes) et une fonction pour tester si il y a collision (10 lignes), bah j'ai mon moteur :P23 lignes au total, et c'est bien plus optimisé que ce que j'aurais pû faire, et plus rapide que du pixel perfect guns 

Donc là il me détecte bien une collision entre le carré noir (rotationné) et le polygone en vert Smile

Moralité de l'histoire : le java c'est bien pour les glandeurs awesome 

_________________
Je suis partie sur les ailes du vent et la tempête m'a ramenée.
Revenir en haut Aller en bas
onilink_
Modérateur
avatar

Messages : 8902
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 12 Nov 2013 - 18:10

Yep, mais bon la on touche plus aux bibliothèques qu'au langage en lui même.
En C++ y a pas mal de librairies pour faire a peu près tout, mais après oui le soucis c'est qu'il faut (souvent):
-réussir a compiler la librairie si les binaires sont pas dispo (donc compiler les dépendances par la même occasion ...)
-réussir a comprendre comment ça fonctionne (avec de la chance c'est documenté et y a des exemples)

C'est sur que pour ça java avais l'air cool, même si a certains niveau j'ai trouvé ça aussi ****** (voir même plus) qu'en C++.
Mais bon je pense pas qu'il y ai de langage magique a ce niveau.
Par exemple hier j'ai eu besoin d'un rasteriseur de polices truetype, j'ai donc utilisé freetype, bah c'étais très ****** a utiliser mais en même temps si j'avais juste eu une fonction char * rasterize(const char * fname); ça aurais été très limité quoi...
Sachant qu'il me fallait aussi pas mal d'infos comme la disposition des lettres et tout.
Bon après c'est une librairie C, en C++ (ou java, ou autre langage oo) ça aurais pu être plus simple a utiliser et mieux structuré.

Mais ça c'est avant tout quelque chose qu'il faut attendre des dev, et non pas du langage.
Documenter une librairie (par exemple avec doxygen) ça reste des fois presque aussi fastidieux que l'écrire.
Ensuite faut aussi fournir des exemples, binaires... tout le monde n'a pas forcément la foi de le faire.
Mais bon c'est grâce a ça qu'une lib deviens populaire. Y a qu'a voir la SFML, c'est devenu une référence car elle est très bien documentée, pleine d'exemples et de tutos (en anglais et français).

_________________
                 
Revenir en haut Aller en bas
En ligne
Térence
Utilisateur confirmé: Rang *****
avatar

Messages : 2213
Localisation : Oui

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 12 Nov 2013 - 18:22

Ouais bah justement, c'est ca que je trouve cool avec java : ia une ****** de bibliothèque de base ! Alors que justement en C++, bah faut installer Qt, puis la SFML, etc... Et comme à chaque fois c'est le gros bordel... Razz
C'est ca que j'aime bien, pas devoir refaire les bases, c'est pareil en php, ia des milliers de fonctions pour faire a peu près tout. Je préfère passer du temps sur le fonctionnement du jeu en lui-même plutot que sur la gestion des collisions, en l'occurence ^^ Iaurait pas eu ca, j'aurais sûrement fait du pixel perfect, c'est plus simple que de décomposer les polygones en triangles et tout (j'en serais incapable), mais ca reste plus lent alors que c'est pas toujours nécessaire : genre un bonhomme, osef, c'est un ovale ^^
Et ca reste un juste milieu puisque ca te limite pas, contrairement à GM avec pleins de trucs Smile

_________________
Je suis partie sur les ailes du vent et la tempête m'a ramenée.
Revenir en haut Aller en bas
onilink_
Modérateur
avatar

Messages : 8902
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 12 Nov 2013 - 18:33

Bah maintenant quand même y a de sacrés bibliothèques en C++, rien que boost c'est assez énorme.
Par contre oui pour le jeu vidéo c'est pas encore ça. Sinon je serait pas encore en train de coder ma propre lib ><

De mon coté j'ai du faire les collisions polygones a la main ahah, mais bon ça reste fun a faire et a la fin t'es quand même fier de l'avoir fait toi même :b
Puis quand tu codes tout, tu peux passer ça dans tous les langages que tu veux au moins, tu dépend plus de la lib standard Razz

_________________
                 
Revenir en haut Aller en bas
En ligne
Térence
Utilisateur confirmé: Rang *****
avatar

Messages : 2213
Localisation : Oui

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 12 Nov 2013 - 18:48

ah nan mais je dis pas, c'est sûr que t'es fier de l'avoir fait toi même, mais c'est difficilement compatible avec mon côté feignasse Razz
Actuellement, j'ai fais une structure en chunk, ia encore moyen d'optimiser mais c'est déjà ca, je vais pouvoir avoir mon environnement ouvert sans chargement (ou même sans avoir de coupure au niveau de la view, genre l'arrêt du défilement quand t'arrive au bord de la map), et ca c'est cool Smile Faut juste que je réadapte le truc pour l'avoir de manière verticale : la base de mon jeu c'est de pouvoir rentrer dans des immeubles, et ca sert à rien d'updater tous les étages des tours ^^
La prochaine grosse étape c'est A*, et ca ca va être hard Razz
Puis bon, je pense pas passer à un autre langage de sitôt pour les jeux, si j'utilise java c'est pour sa rapidité par rapport à GM, puis je me vois pas coder un gros truc en JS par exemple... Pour avoir un truc plus rapide faudrait que je passe au C++, mais à mon avis c'est pas pour tout de suite ^^

_________________
Je suis partie sur les ailes du vent et la tempête m'a ramenée.
Revenir en haut Aller en bas
onilink_
Modérateur
avatar

Messages : 8902
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 12 Nov 2013 - 19:07

Pour le A*, je te conseille de créer un algo qui utilise une grille si ton jeu est compatible avec ça, et non pas des listes, sinon ça risque de méchamment ramer en java :b
(j'arrivais a faire ramer un A* avec listes en C++, c'est pour dire ><)

Sinon pour ce qui est de la rapidité de nos jours y a pas que le C++, je pense pas que le choix de ce langage doit commencer par 'je veux un langage qui va vite', mais plus 'je veux un langage qui a de la gueule' :b
Perso me suis tourné vers le C++ pour la syntaxe avant tout. Le fait d'avoir un contrôle presque total, c'est quand même assez cool Very Happy
(j'ai du être frustré à ce niveau a cause de GM Razz)

_________________
                 
Revenir en haut Aller en bas
En ligne
Térence
Utilisateur confirmé: Rang *****
avatar

Messages : 2213
Localisation : Oui

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 12 Nov 2013 - 19:24

Qu'est ce que t'entends par une grille ? Une grille virtuelle sur ma map, ou la structure de données (ds_grid avec GM) ? De toute façon c'est assez documenté sur le sujet, même en français, donc j'espère ne pas avoir trop de problèmes ^^ Mais effectivement faut que ce soit rapide, ce serait cool s ije pouvais avoir 20 ennemis qui te courent après en même temps dans les immeubles Razz

_________________
Je suis partie sur les ailes du vent et la tempête m'a ramenée.
Revenir en haut Aller en bas
onilink_
Modérateur
avatar

Messages : 8902
Localisation : Montpellier
Projet Actuel : Planet Centauri
OniDev

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 12 Nov 2013 - 20:15

Bah au lieu d'utiliser des nodes pour enregistrer les distances, tu les enregistres directement sur un tableau 2d Razz
Tu verras quand t'implémenteras le truc, au pire demande moi un pseudo code si t'y arrives pas.

_________________
                 
Revenir en haut Aller en bas
En ligne
Térence
Utilisateur confirmé: Rang *****
avatar

Messages : 2213
Localisation : Oui

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 12 Nov 2013 - 20:18

D'accord, je n'y manquerai pas Wink merci beaucoup Smile

_________________
Je suis partie sur les ailes du vent et la tempête m'a ramenée.
Revenir en haut Aller en bas
Asu
Utilisateur confirmé: Rang ****
avatar

Messages : 895

MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   Mar 12 Nov 2013 - 20:49

Ca me donne envie de me replonger dans les cours de Java d'open classrooms ^^
Sinon je trouve ces langages un peu dur pour moi, le java au pire ça va mieux, mais y'a quel language qui se rapproche un peu du GML? Le hashkell à l'air intéressent.

_________________
‎<‎Cysteine‎>‎ nON mais la touche maj s'active/se désactive toute seule
‎<‎Cysteine‎>‎ et a du mal à réponDRE QUANd j'appuie dessus
‎<‎Cysteine‎>‎ et je l'ai démont2? IL Ny a rien DEDANs
Revenir en haut Aller en bas
Contenu sponsorisé




MessageSujet: Re: Débat programmation [1] : Pour ou contre le Java?   

Revenir en haut Aller en bas
 
Débat programmation [1] : Pour ou contre le Java?
Voir le sujet précédent Voir le sujet suivant Revenir en haut 
Page 1 sur 2Aller à la page : 1, 2  Suivant
 Sujets similaires
-
» pour ou contre le vaccin ROR ?
» Pour ou contre la corrida ?
» Pour ou contre la Charte européenne des langues régionales ou minoritaires ?
» pour ou contre le vaccin de l'hépatite b?
» Pour ou contre la suppression de 2 jours feriés ..etc ...

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
Forum Le CBNA :: Développement :: Programmation-
Sauter vers: