Discussion :

[Graffito]

Bonjour,

Et si on reposait la question en parlant non pas des avantages mais des inconvénients:
- C n'est pas un langage objet,
- PHP n'est pas adapté à des appplications locales (non Web), dispose de peu de bibliothèques applicatives et, PHP étant interprété, les process sont assez lents,
- Java et PHP ne disposent d'aucun EDI de haut niveau (style Visual Studio ou Delphi)

Sur le plan portabilité sur plusieurs plateformes, puissance du langage (capacité à coder avec le minimum d'instruction) et maintenabilité, Java est probablement le meilleur choix pour un gros projet (Personnellement, je prefère toutefois Delphi ou C#)

[ABN84]

- Java et PHP ne disposent d'aucun EDI de haut niveau (style Visual Studio ou Delphi)

Ah bon! et Matisse tu connais?

[Jedai]

Java n'a pas d'IDE perfectionnés ? Ca c'est nouveau !!

C n'est pas objet mais ce n'est pas un défaut en soi (personnellement je préfère largement les langages fonctionnels aux langage objets), son plus sérieux défaut dans le contexte des applications réseaux est qu'il est très bas niveau et qu'il est extrêmement aisé de créer des vulnérabilités graves et difficiles à détecter en C, pour une application réseau, c'est (ça devrait être) rédhibitoire, néanmoins il y a énormément d'application réseau en C tout de même, avec le succès qu'on connaît. (Non non, je ne suis pas du tout sarcastique...)

PHP... est un très mauvais langage en général, pour être honnête. On peut trouver des ressources édifiantes sur le sujet sur internet. Il y a plusieurs raisons à ces problèmes (dont la générale inexpérience en informatique de beaucoup de développeurs PHP), mais on ne peut nier que le code source de l'interpréteur PHP lui-même est de mauvaise qualité (le nombre de faille qui y a été trouvé est effarant) et que le langage n'encourage pas à de bonnes pratiques de sécurité.


Java, C#, Perl (Catalyst), Ruby (OnRails), Python (Django) sont tous des alternatives crédibles et préférables aux deux langages précédemment cités.

--
Jedaï

[Garulfo]

[...] (personnellement je préfère largement les langages fonctionnels aux langage objets) [...]
Jedaï

étrange venant de toi qui est bien placé pour savoir qu'on peut faire du fonctionnel et de l'objet dans un savoureux mélange... voulais-tu dire « procédural » ou sous-entendais-tu qu'avec de l'objet ton fonctionnel à de bonne chance de ne pas être pur ?

[Jedai]

étrange venant de toi qui est bien placé pour savoir qu'on peut faire du fonctionnel et de l'objet dans un savoureux mélange... voulais-tu dire « procédural » ou sous-entendais-tu qu'avec de l'objet ton fonctionnel à de bonne chance de ne pas être pur ?

Tu parles des objets à la OCaml je suppose ?
A vrai dire j'ai cherché à rester concis dans mon post et à ne parler que des solutions mainstreams (par exemple Haskell constitue une option intéressante pour faire des applications réseaux plus sécurisées, cf Happs...), je faisais donc allusion à l'orienté objet tel qu'il est pratiqué dans les langages mainstream actuellement, comme Java ou C#. D'autres modèles objets beaucoup plus intéressants peuvent être trouvés dans d'autres directions (OCaml, Eiffel, Smalltalk, ...), mais ils ne sont sûrement pas ce qui vient à l'esprit de la plupart des programmeurs quand on leur parle d'orienté objet au jour d'aujourd'hui.

--
Jedaï

[Graffito]

Ah bon! et Matisse tu connais?

Matisse sans Eclipse, ça marche ?
Eclipse sans add-on, est-il au niveau de Visual studio ou des produit d'origine Borland?

Le problème c'est que chaque développeur Java utilise son propre environnement de dévellopement différent de celui du voisin.

[Thierry Chappuis]

Matisse sans Eclipse, ça marche ?
Eclipse sans add-on, est-il au niveau de Visual studio ou des produit d'origine Borland?

L'important est que Eclipse avec add-ons le soit.

Thierry

[ABN84]

Matisse sans Eclipse, ça marche ?

oui, ça s'appelle Netbeans

[Graffito]

Bon, apparament je ne suis pas assez l'actualité JAVA(il me semblait que la plateforme de développement la plus installée restait Eclipse).

Netbeans 6.0 avec Swing a l'air plutot évolué .

[snake264]

Eclipse et Netbeans sont deux IDE très évolué et modulable qui avec les plug-in qu'il faut sont aussi performant que visual studio mais aussi surtout gratuit car la version express est quand même assé limité par rapport à ce que peut apporté Netbeans ou Eclipse.

[Tommy31]

e (capacité à coder avec le minimum d'instruction) et maintenabilité, Java est probablement le meilleur choix pour un gros projet (Personnellement, je prefère toutefois Delphi ou C#)

Peut on faire du Delphi ou C# sous linux de façon convaincante ? En d'autres termes est ce que Kylix et Mono sont aboutis ?

Curieux que personne n'est mentionné Ruby on Rails, ca buzze beaucoup quand même au niveau de ce framework...

[gorgonite]

Peut on faire du Delphi ou C# sous linux de façon convaincante ? En d'autres termes est ce que Kylix et Mono sont aboutis ?

Kylix ?
j'aurais plutôt dit Lazarus

[Thierry Chappuis]

Peut on faire du Delphi ou C# sous linux de façon convaincante ? En d'autres termes est ce que Kylix et Mono sont aboutis ?

Curieux que personne n'est mentionné Ruby on Rails, ca buzze beaucoup quand même au niveau de ce framework...

Ruby a été mentionné. Ruby + web, c'est implicitement RoR.

Thierry

[nikko34]

Il est bizarre ce débat.

Il n'y a pas de réseau dans le standard C, on a du code spécifique à chaque OS.

Maintenant, rien ne t'empêche d'utiliser une librairie de plus haut niveau qui sera portable et facile à utiliser.

Il en existe en C et aussi en C++.

Et là où c'est drôle c'est que JAVA doit sûrement implémenter sa partie réseau avec les fonctions C de l'OS.

Donc évidemment l'API java sera plus simple que celle de l'OS, puisque cette dernière est faite pour être la plus générale possible. Il faudrait comparer JAVA avec une lib réseau C ou C++ ( comme boost.asio par exemple ).

Mais faire des sockets en C par exemple (ou coder une classe socket C++ utilisant l'api C de l'OS ) est toujours très intéressant.

Pour le PHP ben euh... ya pas vraiment de rapport avec le reste? A moins que tu ne veuilles parler que de la publication de page web? Mais ça avec un binaire CGI et un serveur web tu peux générer tes pages webs sans aucune connaissance réseau ( écriture sur la sortie standard ).

[Tommy31]

Kylix ?
j'aurais plutôt dit Lazarus

Ca compile les projets Delphi sous linux ?

[Graffito]

Peut on faire du Delphi ou C# sous linux de façon convaincante ? En d'autres termes est ce que Kylix et Mono sont aboutis ?

Kylix était relativement abouti et plutot compatible avec Delphi6 (moyennant quelques IFDEF sur 1% du code, on avait un code commun), mais il n'est plus maintenu depuis 5 ans et devient de plus en plus dur à réinstaller sur les nouvelles distibutions Linux.
Mono (Linux ou Windows) permet de faire tourner des exe créés avec Visual Studio sous Windows, à condition de ne pas utiliser les composants Winforms les plus complexes (par exemple, j'essaierai même pas le DataGridView).

[kisitomomotene]

En C l'avantage c'est la portabilité entre systèmes Linux et Windows.

Pour ce qui est du JAVA je ne vois pas vraiment d'avantage.

Merci pour votre aide à ma réflexion

Attention les bibliothéques "évoluées" de C ne sont pas en général portable, particulièrement en ce qui concerne le réseau.
C n'est pas orienté objet, d'où des problèmes de maintenances, c'est encore mieux d'utiliser C++.
Java est offre beaucoup de solution quasi prêt à l'emploi -des frameworks et bibliothéques opensource et fiables- pour la gestion des applications distribuées, je crois que dans ce sens il est de loin la meilleur solution actuellement

[millie]

Le java est beaucoup plus portable que le C, puisqu'il marche partout où il y a une JVM.
Après pour les performances, les gens sont divisés... Deux écoles s'affrontent, disant que l'un est plus performant que l'autre...

En fait, si on utilise les sockets en C comme un barbare (c'est à dire en utilisant uniquement des appels du type : send, recv qui font directement appel à des appels systèmes), ça va forcement être ralenti (surtout si c'est pour lire 2 caractères à chaque fois)

En Java, on couple les sockets avec des BufferedInput/OutputStream en général pour bufferiser les entrées (on lit par exemple 5000 caractères d'un coup et au prochain read on lit directement dans le buffer) et les sorties. Ceci de manière totalement transparente.

Pour le réseau en C classique (sous UNIX avec les sys/socket.h etc. et sous Windows avec les win2sock), il faut en général recoder une couche au dessus pour imiter ce type de fonctionnalités.


Après, le reste a déjà été dit.

[gorgonite]

Le java est beaucoup plus portable que le C, puisqu'il marche partout où il y a une JVM.

C/C++ sont beaucoup plus portables que le Java... puisqu'en codant proprement et en utilisant un compilateur respectueux des normes, on pourra compiler vers bien plus de plate-formes, et donc faire fonctionner son programme là où on attendrait encore une JVM

morale de l'histoire :
il aurait mieux valu utiliser "Java permet une portabilité sans recompilation", et non "Java est plus portable que le C (ou le C++)"

En fait, si on utilise les sockets en C comme un barbare (c'est à dire en utilisant uniquement des appels du type : send, recv qui font directement appel à des appels systèmes), ça va forcement être ralenti (surtout si c'est pour lire 2 caractères à chaque fois)

En Java, on couple les sockets avec des BufferedInput/OutputStream en général pour bufferiser les entrées (on lit par exemple 5000 caractères d'un coup et au prochain read on lit directement dans le buffer) et les sorties. Ceci de manière totalement transparente.

Pour le réseau en C classique (sous UNIX avec les sys/socket.h etc. et sous Windows avec les win2sock), il faut en général recoder une couche au dessus pour imiter ce type de fonctionnalités.

pas vraiment d'accord.
sans avoir à se reconstruire une bib, passer par des FILE* pour les accès aux sockets permet d'éviter ce problème... pourquoi toujours partir sur l'hypothèse que les langages bas niveau oblige systématiquement à tout reconstruire

[snake264]

C/C++ sont beaucoup plus portables que le Java... puisqu'en codant proprement et en utilisant un compilateur respectueux des normes, on pourra compiler vers bien plus de plate-formes, et donc faire fonctionner son programme là où on attendrait encore une JVM

Le problème est là, il existe trop de compilateur C et C++ et dont certains ne sont pas entièrement aux normes, alors que le Java lui peut importe le compilateur que tu utilise ça marchera et en plus tu le compile une fois et c'est tout ce qui est un énorme avantage Et puis cela demande plus de temps au développeur de faire un code entièrement portable en C que en Java. Voir les sockets par exemple comme l'a si bien dit millie.

morale de l'histoire :
il aurait mieux valu utiliser "Java permet une portabilité sans recompilation", et non "Java est plus portable que le C (ou le C++)"

Oui et non je suis un peu mitigé sur ce point de vue car pour moi Java est tout ce qu'il y a de portable, le C aussi mais il est soumis à trop de condition.

sans avoir à se reconstruire une bib, passer par des FILE* pour les accès aux sockets permet d'éviter ce problème... pourquoi toujours partir sur l'hypothèse que les langages bas niveau oblige systématiquement à tout reconstruire

Entièrement d'accord, même si il est vrai que le C a été inventé pour justement tout reconstruire car à la base c'étais pour faire un système d'exploitation.