Note du modérateur: le language C# est un language orienté objet qui doit permettre aux développeurs de créer facilement des applications pour la plateforme .Net de Microsoft. La comparaison semble très complête, à lire.
Aller plus loin
- La comparaison (356 clics)
- la discussion sur K5 (11 clics)
- passage par ref / valeur en Java (7 clics)
- Penser en Java (46 clics)
- Le portail DotNet (31 clics)
# Opinion
Posté par Benjamin Michotte . Évalué à 10.
- c'est de l'orienté objet, ce qui permet une réutilisation du code ainsi que la modification de celui-ci sans devoir changer tout le reste. (et tous les autres avantages de la POO)
- c'est multi-plateforme. Le programme que j'ecris pour linux, tournera aussi sur windows ou sur tout os ayant une JVM.
- A partir du moment ou on a compris les trucs de base, on évolue rapidement dans l'apprentissage du java (je sais, j'ai encore des progrès à faire ;p)
- Il est génial pour tout ce qui touche le réseau et internet (que ce soit un « bete » programme comme jcoincoin ou une applic applet/servlet)
Par contre, je ne connais pas C# et je n'ai vraiment pas envie de connaitre... Si C# est pensé comme MS a pensé les MFC par exemple, quelle horreur ça doit etre.
De plus, meme si java n'est pas open, il a l'avantage d'etre gratuit.
TOUT le monde peut avoir une jvm pour son os (pour autant quelle existe bien entendu ;p) ....
Et pour C# ? Est-ce que je pourrai faire tourner un programme écrit en C# sous macOSX ? ou sous *BSD ?
Je ne sais d'ailleurs plus le prix absolument abérant (un gros doute sur le abérant) des outils C#, mais, petit étudiant que je suis, je n'ai pas les moyens de me les payer ... (je n'en ai pas l'envie non plus donc, ça tombe plutot pas mal).
Je trouve la position de MS totalement ridicule. Créer un langage _uniquement_ pour essayer de couler sun et le java....
Petite question en passant, est-ce que le C# possede un API aussi énorme que celle de java ?
[^] # Re: Opinion
Posté par ogallos . Évalué à -10.
Et moi qui croyait que MacOSX etait un BSD. (Gilbou de posse-press, pourrais tu confirmer?)
En tout cas, c'est clair qu'il n'existera pas de compilateur C# pour les autres systèmes que ceux de Microsoft.
[^] # Re: Opinion
Posté par chl (site web personnel) . Évalué à 7.
Si c'est le cas, je vois mal comment Microsoft pense rivaliser avec Java, qui a comme principal interet de pouvoir tourner sur toutes les platformes ...
[^] # Re: Opinion
Posté par Yohann (site web personnel) . Évalué à 8.
Pour la meme raison que personne, a part moi (et encore :( ) utilise SO5.2, car les "dots doc" doivent s'ouvrir ABSOLUMENT
La raison "Made in Microsoft" peut suffir a pas mal de gens, et c'est bien le probleme !
[^] # Re: Opinion
Posté par boubou (site web personnel) . Évalué à 7.
et de .NET sont prévues : http://www.ximian.com/about_us/press_center/press_releases/mono_ann(...)
C'est le projet mono.
[^] # Re: Opinion
Posté par ogallos . Évalué à 5.
[^] # Re: Opinion
Posté par chl (site web personnel) . Évalué à 1.
Strategiquement ca a aidé Sun pour implanter son Java, mais Microsoft n'as ptet pas envie que son C# fonctionne sur plusieurs platformes ? Ou ils savent ptet pas programmer sous linux :)
[^] # Re: Opinion
Posté par gabuzo . Évalué à -3.
[^] # Re: Opinion
Posté par François B. . Évalué à 8.
On y trouve entre autre les source du J2SE, du J2EE et de HotSpot.
[^] # Re: Opinion
Posté par Pierre . Évalué à 1.
Extrait : "Mono includes: a compiler for the C# language, a runtime for the Common Language Infrastructure and a set of class libraries."
[^] # Re: Opinion
Posté par Nelis (site web personnel) . Évalué à 8.
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
Microsoft a proposé un standard public pour C#, donc C# sera standardisé comme C ou C++ le sont actuellement (et comme Java ne le sera semble-t-il jamais :-).
[^] # Re: Opinion
Posté par Fabimaru (site web personnel) . Évalué à 3.
[^] # Re: Opinion
Posté par Bertrand Mathieu . Évalué à 5.
[^] # Re: Opinion
Posté par Gaël . Évalué à 6.
[^] # Re: Opinion
Posté par arnaud . Évalué à 1.
[^] # Re: Opinion
Posté par Nelis (site web personnel) . Évalué à 7.
Excuse moi mais là je ris :-) "Microsoft a proposé un standard public ...". Depuis qd est ce que MS suit les standards ? Tu crois que parce qu'il l'a proposé lui-même il le respectera ? Dès que ça ne l'arrangera plus de suivre le standard, il mettra des petites "features" non-standard ("ben quoi, on va pas nous repprochez de mettre des fonctionalités en plus pour nos utilisateurs").
La vie est un eternel recommencement ;-)
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à -1.
Depuis qu'ils les font :-)
> Tu crois que parce qu'il l'a proposé lui-même il le respectera ?
Oui, c'est dans leur interêt. Si ils veulent que ce langage marche, il faut éviter qu'il soit "balkanisé".
http://www.ecma.ch/ecma1/MEMENTO/TC39.HTM(...)
[^] # Re: Opinion
Posté par Buto . Évalué à 4.
D'où l'obligation de l'appellation J++, pseudo-Java qui définit par exemple des directives de compilation (le comble pour un langage supposé multi-plateforme), et avec l'arrivée de .Net la nouvelle appellation J#...
[^] # Re: Opinion
Posté par javp . Évalué à 5.
L'intérêt de MS n'est pas de faire un "langage qui marche". L'intérêt de MS est d'imposer sa platform .NET/HailStorm/XP (c'est normé ISO ou ANSI, ça ?). C# est l'un des moyens qui permettra d'atteindre ce but.
<parano mode on>
Imaginons qu'une société développe son business sur une platform Linux/.NET avec C#. Dans quelques années, MS modifie .NET (pour des tas de bonnes raisons, si,si ils en trouveront) de sorte que .NET se comporte de façon "étrange" sous Linux et ce sans toucher à C#.
Quelle alternative pour le sociétés qui ont tout misé sur Linux/.NET/C# ?
a) garder Linux et réécrire son business avec un autre langage, d'autres fournisseurs de services.
b) garder son business tel quel et migrer sous XP
A priori, je dirais qu'une de ces alternatives doit être beaucoup plus chère que l'autre...
</parano mode on>
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
Et pour ça il faut que les développeurs aient envie de développer dessus, parce que si il n'y a pas d'applis ils n'iront pas loin. Et pour que les developpeurs aient envie de développeur dessus, il faut que le langage soit agréable à utiliser, bref, qu'il marche bien.
> Imaginons qu'une société développe son business sur une platform Linux/.NET avec C#.
Si on a C# et .NET sous Linux, ça sera déjà un exploit :-).
[^] # Re: Opinion
Posté par Nelis (site web personnel) . Évalué à 2.
La tu es franchement idéaliste ... Pour que ça marche, il faut surtout que MS vende sa plateforme aux décideurs (pour ça ils sont fort MS), après les pauvres p'tits développeurs ont pas grand chose à dire ... Si dans ta boite on te dit que le client veut faire ça en .NET/C#, tu vas faire la révolution tout seul, sinon on te montre la porte ...
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Non. Tu ne forces pas des développeurs à passer à un langage contre leur grè, pas si tu veux que ton projet aboutisse. N'importe quel "décideur" sait ça, ou alors il va l'apprendre dans la douleur :-). Par ailleurs, un "décideur" en général ne souhaite qu'une chose : ne pas changer, à partir du moment où ça marche.
> Si dans ta boite on te dit que le client veut faire ça en .NET/C#, tu vas faire la révolution tout seul, sinon on te montre la porte ...
Ça par contre oui, c'est vrai, tu fais ce que le client demande, ce qui est bien normal, t'es payé pour. Mais pour que le client demande .Net/C#, il faut qu'il ai commencé à l'utiliser lui-même.
Bon, j'exagère, le coté marketing existe, et il y a aussi des managers qui se shootent au buzzword et te rendent un numéro de 01 Informatique avec les pages qui collent. Mais aucun marketing ne fera fonctionner un langage pourri. Si tout ceux qui essayent C# disent "on s'est vautrés", ça va finir par se remarquer.
Il faut arrêter de se mettre la tête dans le sable, MS n'embauche pas que des cons et ne fait pas que de mauvais produits, loin de là. Une boite n'arrive pas là où ils sont avec seulement un "vilain méchant marketing".
Il est bien plus simple et plus sur pour eux de faire de C# un bon langage qui plaise au développeurs et donc s'installera durablement (si Linux a percé, c'est parce qu'il plait aussi) plutôt que de faire un feu de paille marketing qui s'éteindra dès les premiers flops. D'autant plus sur qu'ils n'ont pas exactement misé petit sur .NET.
[^] # Re: Opinion
Posté par Jerome Demeyer . Évalué à 5.
Hum...
Java est standardisé par l'ISO (organisme de standardisation international),
le C est déjà ANSI (American National Standardization Institute) et est en cours de standardisation ISO
le C++... ben je ne me souviens pas qu'il fasse l'objet de la moindre standardisation...
Je me répète, mais mieux vaut promouvoir un langage ouvert et standard, meme s'il certaine parties sont sous copyright, plutôt que de l'enfoncer... ce qui ferais ressortir son "concurrent" direct (C#).
Pourquoi comparer de Java et du C++ ? Les applis C++ peuvent t'elles se lancer dans le navigateur du lambda ?
Le Java me semble etre un langage qui à réelement un avenir, le C# je n'en suis pas si sûr...
[^] # Re: Opinion
Posté par Johann Deneux . Évalué à 7.
Ben si. Voir:
http://www.research.att.com/~bs/C++.html(...)
[^] # Re: Opinion (C++ Standard)
Posté par Nicolas Eric . Évalué à 6.
Malheureusement peu de compilateurs implémentent la totalité du standard. A ma connaissance GCC v3, KCC, Intel C++ et Dec CXX sont ok, les autres non.
[^] # Re: Opinion
Posté par gabuzo . Évalué à 4.
Quel est l'intérêt de pouvoir lancer une appli à partir d'un navigateur ? Pour les applis installées en local il est nettement plus simple de taper mon_appli_ki_tue à partir d'un shell, ou de cliquer sur une icône que de lancer au préalable un navigateur.
Certes cela permettrait d'exécuter l'application directement à partir du serveur sans installation en local mais je ne me vois pas attendre le téléchargement de Gimp à chaque fois que je souhaite le lancer (et pourtant j'ai le cable).
Reste les applets qui sont utilisées uniquement au sein de pages web pour passer outre les limites de HTML. Java a alors un gros avantage sur les langages compilés mais j'ai plutôt tendance à penser que ce genre de chose est de moins en moins utilisé : les applets de sécurisation utilisées un temps par les banques ont été remplacées SSL 128bits et les animations, jeux, etc. sont plus souvent en flash qu'en Java.
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 8.
Ah, vraiment :
http://www.zdnet.com/zdnn/stories/news/0,4586,1014537,00.html(...)
"Sun Microsystems Inc.'s long-standing plans to submit its Java language for standardization via the International Standards Organization are dead, according to Alan Baratz, president of Sun's Java Software division."
Ça date de 1999. Dans un numéro de C++ Report (datant de 99 ou 2000, je ne sais plus), il y avait une triple interview de Ritchie, Stroustrup, et Gosling. A la question "considerez-vous que standardiser un langage soit important", Ritchie et Stroustrup répondaient "oui, c'est crucial", et Gosling : "ben on a essayé mais c'était un tel bordel politique qu'on a laissé tomber".
> le C est déjà ANSI (American National Standardization Institute) et est en cours de standardisation ISO
http://anubis.dkuug.dk/JTC1/SC22/WG14/(...)
"The current C programming language standard ISO/IEC 9899 was adopted by ISO in 1999."
(il s'agit de la dernière version, la première date de 87 si ma mémoire est bonne).
> le C++... ben je ne me souviens pas qu'il fasse l'objet de la moindre standardisation...
Ben tu dois vivre sous un rocher :
http://std.dkuug.dk/jtc1/sc22/wg21/(...)
http://www.research.att.com/~bs/iso_release.html(...)
Le standard C++ ISO a été discuté pendant plusieurs années, et voté en novembre 97. Et la boite pour laquelle je travaille est membre du comité.
Joli score :-).
Il y a quelques mois sur un autre sujet dans linuxfr, je me souviens d'un âne qui avait aligné exactement les mêmes imbécilités : C pas encore ISO, et C++ pas standardisé. On avait été 2 à lui répondre... C'est quand même pas toi, dis ?
> Pourquoi comparer de Java et du C++ ?
Je citais C++ et C uniquement pour le fait qu'il y a un standard pour ces deux langages, il ne s'agit pas de comparer
> Les applis C++ peuvent t'elles se lancer dans le navigateur du lambda ?
En général non, et on s'en fout, c'est pas fait pour. Et ça n'a rien à voir avec le sujet non plus :-).
[^] # Re: Opinion
Posté par Jerome Demeyer . Évalué à -1.
Sinon, Java est pratique pour etre plateforme-indépendant, mais les différentes plateformes disponibles en entreprise restent i386/UNIX i386/Win32 et des Sun ou des Macs... En disant que les Apple sont sur MacOSX(donc BSD, si je ne m'abuse), je voudrais savoir si ce n'est pas trop difficile de faire un programme qui puisse se compiler sur ces différentes plate-formes ?
Parce que si c'est tranquille, alors Java restera cantonné aux applis qu'on lance dans un browser, et la comparaison n'aura pas franchement lieu d'être, même si on fait de plus en plus de choses dans nos browsers...
Enfin si je demande ça, c'est aussi parce que je ne suis pas (encore) développeur C, C++ ou Java (vous avez peut-etre pu vous en rendre compte sur le post précédent, mettant en avant mon ignorance dans ce domaine, mais bon je croyais tellement ce que je disait) et je compte bien m'y mettre... dès que j'aurais choisi entre Java ou C.
Alors pour du parsing, du client/serveur, pour se connecter aux systèmes et aux SGBD... que choisir ?
[^] # Re: Opinion
Posté par Nelis (site web personnel) . Évalué à 2.
[^] # Re: Opinion
Posté par VACHOR (site web personnel) . Évalué à 1.
OK, alors faisons un test :
1- J'écris un programme Java sur Linux, puis je le fais tourner sous Windows ou Solaris. Même pas besoin de recompiler.
2- J'écris le même programme Java sous Linux, puis j'essaie de la faire tourner sous Windows ou Solaris. Pour peu qu'il y ait une GUI, bon courage, et bonne prise de tête !
Alors, lequel est "mieux normalisé", d'un façon ou d'une autre ?
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
> 2- J'écris le même programme Java sous Linux, puis j'essaie de la faire tourner sous Windows ou Solaris.
Je ne suis pas sur de bien comprendre ta question :-).
Si par hasard tu voulais dire "C++" ou "C" au lieu de Java sur l'item 2, ben oui, faire des GUI portables en C ou en C++ c'est la merde, faut une lib en plus, c'est exactement ce qu'on dit plus bas : pour faire un bon langage il faut une bonne grosse lib :-).
Tu montres juste que Java engloble plus de choses que C ou C++, rien a redire. Mais ça n'est pas de ça qu'il s'agit.
[^] # En tout cas, c'est clair qu'il n'existera pas de compilateur C#
Posté par jm . Évalué à 10.
http://www.go-mono.com/(...)
et dotGnu pense aussi
http://sourceforge.net/projects/dot-gnu/(...)
et puis Corel est plus ou moins financé par MS pour écrire/porter dotnet pour BSD
http://linuxfr.org/2001/06/30/4072,0,1,0,0.html(...)
Par contre, c'est évident que MS n'a pas intérêt à porter le CLR ailleurs (ou alors ils feront comme NT, qui à sa naissance existait sur PowerPC, Alpha ET x86). Et même, ils pourront porter la CLR, mais s'assureront que cela marche "mieux" sur Windows
Quand à la "racine" BSD de MacOSX, oui, Darwin est basé sur FreeBSD
http://www.opensource.apple.com/projects/darwin/(...)
Mais Aqua et compagnie, c'est pas du BSD... par contre, Apple a bien travaillé pour que Java soit un langage qui s'integre tres proprement à OSX et les diverses API http://developer.apple.com/javaosdn.html(...)
[^] # Re: Opinion
Posté par plouf . Évalué à 2.
En fait microsoft va porter .net pour freebsd (dont il apprecie la licence). http://www.oreillynet.com/pub/a/dotnet/2001/06/27/dotnet.html(...)
Par contre aucune "chance" pour linux
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Et puis c'est tellement plus confortable de ne pas remettre en question ses connaissances, hein ?
> Je ne sais d'ailleurs plus le prix absolument abérant [...]
MS n'est pas idiot : leurs outils de dev ne coutent jamais très cher, ça permet d'avoir plus de développeurs.
> Petite question en passant, est-ce que le C# possede un API aussi énorme que celle de java ?
Bien évidemment. L'une des grandes leçons de C++, c'est qu'un langage doit avoir d'entrée une lib standard bien foutue, sinon c'est le bordel parce que chacun fait la sienne.
[^] # Re: Opinion
Posté par G. R. (site web personnel) . Évalué à 5.
Sauf que C++ avait pour objectif d'être compilable là (et pour) où C l'est.
Ce qui signifie donc des machines embarquées ou les interfaces graphiques n'ont aucun sens.
C'est pourquoi, mettre dans une bibliothèque standard des trucs comme swing, une api réseau ou les threads n'est pas une bonne chose (le mettre dans une extension de la bibliothèque standard, pourquoi pas).
Tout dépend bien sûr des objectifs du langage. Mais faire une généralité en disant que plus la bibliothèque standard est grosse et complète, mieux c'est, c'est faux.
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 5.
L'embarqué était (est toujours, même), l'un des objectifs de Java, et actuellement son domaine de prédilection est les serveurs, où il n'y a pas de GUI non plus.
T'es pas obligé d'emporter toute la lib dans le programme...
> C'est pourquoi, mettre dans une bibliothèque standard des trucs comme swing, une api réseau ou les threads n'est pas une bonne chose
Si, et c'est pourquoi on cherche à l'ajouter à C++ maintenant. Voir une interview de Stroustrup sur le sujet :
http://www.linuxworld.com/linuxworld/lw-2001-02/lw-02-stroustrup.ht(...)
> Mais faire une généralité en disant que plus la bibliothèque standard est grosse et complète, mieux c'est, c'est faux.
Cite moi un exemple montrant le contraire. Pour autant que je puisse dire, c'est vrai.
[^] # Re: Opinion
Posté par G. R. (site web personnel) . Évalué à 2.
Si elle reste standard, c'est que ce qui n'y est pas fait partie des extensions au standard. C'est une définition.
Maintenant, si tu n'es pas d'accord avec ce que je viens de dire, ne lis pas le reste (ou si, mais il faudra que l'on se mette d'accord sur ce qu'est une bibliothèque standard).
Ajouter explicitement la gestion des threads dans la bibliothèque standard de C ou C++, par exemple, serait impossible. En effet, C et C++ doivent tourner sur des plateformes qui n'ont pas de gestion des threads. Ce doit donc être géré via des extensions à la bibliothèque ou par l'API du.
Viens ensuite un autre problème : Rendre ces extensions le plus générique possible et si possible standard. C'est ce qui s'est fait en C avec la norme POSIX. Mais c'est une norme qui est indépendante du langage C (en fait plutôt le contraire, mais bon).
Pour les interfaces graphiques, il n'y a pas pour l'heure de tels standards, ce qui est certes dommage, mais pas catastrophique.
Voilà mon avis, même si Stroustrup et Guillaume ne le partage pas.
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Il existe des définition un brin plus subtiles de "standard".
> Voilà mon avis, même si Stroustrup et Guillaume ne le partage pas.
Sun non plus ne le partage pas :
http://java.sun.com/j2me/(...)
Recognizing that "one size doesn't fit all," Sun has regrouped its innovative JavaTM technologies into three editions: Micro (J2METM technology), Standard (J2SETM technology), and Enterprise (J2EETM technology). Each edition is a developer treasure chest of tools and supplies that can be used with a particular product:
Java virtual machines* that fit inside the range of consumer devices
a library of APIs that are specialized for each type of device
tools for deployment and device configuration
a profile, that is, a specification of the minimum set of APIs useful for a particular kind of consumer device (set-top, screenphone, wireless, car, and digital assistant) and a specification of the Java virtual machine functions required to support those APIs
Un autre "standard" qui fait la même chose est SVG, il est prévu une version "mini" pour les plateformes plus limitées graphiquement, et même "micro" pour les trucs vraiment petits genre téléphones portables.
[^] # Re: Opinion
Posté par shbrol . Évalué à 1.
(genre Socket dérive de Frame), tu es dans la m... pour faire un programme réseau sur une plateforme sans affichage graphique. Bien sur, jamais personne ne ferait une chose pareille dans le design d'une librarie.
[^] # Re: Opinion
Posté par Benjamin Michotte . Évalué à -1.
> Et puis c'est tellement plus confortable de ne pas remettre en question ses connaissances, hein ?
Pas du tout, en tant qu'étudiant en informatique, j'ai encore pas mal de choses a apprendre et/ou a approfondir.
J'ai deja étudié « l'utilisation de class wizard (sigh) » et donc, une partie des MFC.
L'année prochaine on verra CORBA et la réponse microsftienne avec COM/DCOM.
Mes (maigres) connaissances, je les remets en cause tous les jours en cherchant comme améliorer telle ou telle chose dans la facon de coder, en apprenant par moi-meme certains langages que par manque de temps (sans doute) nous nb'apprenons pas à l'école (php, utilisation d'api comme gtk, (faut d'ailleurs que je me mette a perl et python ;p), ...
De toutes manières, l'informatique est un milieu dans lequel nous sommes _obligés_ de nous remettre en question très souvent...
Nouvelle version de java, nouvelle librairie puissante en C, nouveau langage, .... Mais pour une question de gout et de principes (surtout), je n'apprendrai le C# que si il doit devenir un de mes cours l'année prochaine...
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à -2.
J'ai passé l'age des provocations à 2Frs, merci. Mon post n'était pas un troll.
> Pas du tout, en tant qu'étudiant en informatique, j'ai encore pas mal de choses a apprendre et/ou a approfondir.
C'est déjà bien de le réaliser. Maintenant, pourquoi rejettes-tu d'emblée un langage comme C# si ce n'est parce qu'il vient de Microsoft, et que tu n'aimes pas Microsoft ?
Crois-tu vraiment qu'il soit dans leur interêt de faire un langage pourri ?
> Mais pour une question de gout et de principes (surtout),
AT&T a été un monopole au moins aussi dur que MS, sauf qu'eux le gouvernement US est parvenu à les briser. Mais encore maintenant ils sont loins d'être blancs comme neige. Pourtant tes principes ne t'empèchent pas d'apprendre et d'aimer C ou C++, non ?
Reste le gout, mais bon quand j'étais étudiant j'avais les mêmes réactions, et puis j'ai évolué :-).
[^] # Re: Opinion
Posté par Johann Deneux . Évalué à 7.
Ta notion de "jamais tres cher" differe de la mienne.
D'apres http://msdn.microsoft.com/vstudio/prodinfo/purchase/pricing.asp(...) il faut debourser au moins 1000$ pour Visual Studio 6.0
Les outils de dev de MS sont repandus parcequ'ils sont pirates, pas parcequ'ils sont bon marche.
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Par contre, $1000 dans le budget moyen d'un projet en entreprise, c'est rien.
[^] # Re: Opinion
Posté par gabuzo . Évalué à 1.
Cette possibilité de réutilisation du code n'a rien de propre à Java (comme tu le dis) et si un langage objet facilite les choses il reste possible de le faire en bête C (par exemple Gtk, ou toute autre bibliothèque).
Pour ce qui est de la possibilité de modification sans devoir tout changer cela tiens plus de l'idéalisme que de la réalité. Java permet de le faire, certes mais n'empêche de se planter sur sa conception et d'avoir au final un truc impossible à maintenir.
- c'est multi-plateforme. Le programme que j'ecris pour linux, tournera aussi sur windows ou sur tout os ayant une JVM.
Mouais c'est assez vrai sauf qu'en pratique il faut toujours s'interfacer avec un truc qui nécessite de faire du code natif.
- Il est génial pour tout ce qui touche le réseau et internet (que ce soit un « bete » programme comme jcoincoin ou une applic applet/servlet)
À mon avis pour ce qui est réseau et internet Perl et nettement au dessus de Java mais bon on rentre là dans un domaine hautement subjectif.
[^] # Re: Opinion
Posté par Vivi (site web personnel) . Évalué à 1.
Mouais et puis surtout ça n'a pas grand-chose à voire avec le langage en lui-même, là il s'agit des bibliothèques standard.
[^] # Re: Opinion
Posté par chrtela . Évalué à 1.
Ah bon ? Ce n'est pas mon impression. Les APIs java couvrent un spectre suffisament large pour que tu puisses faire beaucoup de choses avant d'en arriver à utiliser JNI.
[^] # Re: Opinion
Posté par gabuzo . Évalué à 2.
Tout à fait d'accord. Mais à partir du moment où l'on utilise JNI on sort de l'aspect multiplateforme séduisant (et à fort potentiel marketting) de Java.
[^] # Re: Opinion
Posté par freePK . Évalué à 2.
Tiens, je saute la-dessus. Je n'y connais rien en Java mais assez bien en Perl. Jusqu'a present, je n'ai rien lu sur Java qui puisse me faire laisser tomber Perl a son profit.
Quelqu'un d'assez pointu pourrait-il faire une comparaison (objective :-)) ? J'avais deja pose la question ici mais je l'avais posee apres la bataille ce qui fait qu'elle n'avait pas vraiment dechainee les passions...
Ce que j'aimerai, c'est du concret : pas du commercial (du genre, avec Java on fait des softs commerciaux de plusieurs millions de lignes (deja entendu...)). Ce que possede l'un et n'a pas l'autre (et qui soit vraiment valorisable).
Attention, quand je parle de Perl, je parle de Perl et de toutes ses extensions (notamment le CPAN).
Merci
PK, sans accent
[^] # Cours avancé de java ;)
Posté par Benjamin Michotte . Évalué à 1.
Tu veux faire un client-serveur quelconque.
il te faut donc d'un coté une socket sur laquelle tu feras des bind/listen/accept/obiwan....
De l'autre coté, tu ne dois faire qu'un bind.
Java te fournit des Socket et des ServerSocket.
En gros, l'ecriture du serveur sera quelque chose du genre
public class Server {
..public static void main(String[] args) {
...ServerSocket mySocket = null;
...Socket serviceSocket = null;
...// créeons d'abord la socket
...try {
.....mySocket = new ServerSocket(5000);
...} catch (IOException e) {
.....System.err.println("oops");
...}
...// on fait le accept
...try {
.....serviceSocket = mySocket.accept();
...} catch (IOException e) {
.....System.err.println("oops");
...}
..}
}
et tu as un serveur qui tourne. Il faut bien entendu maintenant lui faire recevoir les données et blablabla, mais en gros, c'est mettre un flux sur la socket et ca n'apporte que peu d'interet ici.
Le client sera encore plus simple a écrire.
L'avantage des *Socket, est simple, tu as deux classes et entre elles, un flux de sortie et en flux d'entrée. Pour faire toute une partie réseau qui, par exemple en C serait quand meme assez fastidieuse, cela devient d'un coup très simple et réduite à quelques lignes.
Il existe également les URL et les URLConnection qui fonctionnent simplement comme suit:
mon url = new URL("http://machin.truc"(...));
un flux et hop.
Maintenant, je rappelle que je ne connais pas Perl et que je ne peux pas comparer si il est plus "simple" ou pas
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Essaie de maintenir une appli de plusieurs millions de lignes en Perl et ça va très vite devenir très concret pour toi :-).
(Enfin, à ma connaissance il n'existe pas d'applis d'une telle taille en Perl, et je ne suis pas sur qu'il en existe en Java non plus mais ça me semble déjà plus du domaine du possible. Disons 200 KLOC, ça existe surement en Java, et en Perl j'ose à peine y penser).
[^] # Re: Opinion
Posté par freePK . Évalué à 0.
(Enfin, à ma connaissance il n'existe pas d'applis d'une telle taille en Perl, et je ne suis pas sur qu'il en existe en Java non plus mais ça me semble déjà plus du domaine du possible. Disons 200 KLOC, ça existe surement en Java, et en Perl j'ose à peine y penser).
Ben, non, justement. Un porc écrira du Perl non maintenable en une centaine de lignes. La maintenance, lorsque le source est écrit proprement, n'est pas un problème (que ce soit en Perl ou en autre chose).
Quant aux applis grosses, je n'ai pas d'exemples directs sous la main mais je pense que la conception passe avant le langage. Je connais des applis en Scheme de plusieurs millions de lignes : les fans d'Emacs apprécieront :-)
Quant à l'exemple donné plus haut du client serveur, bof. On fait la même chose (peut-être même plus rapidement) en Perl.
Non, je cherche ce qu'apport réellement le Java par rapport à Perl. Et jusqu'à présent, je ne vois rien d'autre que des arguments... qui n'en sont pas :-)
PK
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Ça c'est un cliché qu'on ressort quand on a pas eu a maintenir le code d'un autre :-). Tu peux écrire du code propre en Perl, ça demande juste beaucoup plus d'effort qu'en Java. Et comme dans la réalité, il y a des plus ou moins bons programmeurs, Perl est beaucoup moins maintenable que Java, c'est tout. C'est vrai même pour un bon programmeur Perl, d'ailleurs. Si il peut faire du Perl propre il fera du Java propre aussi, et ça restera toujours plus maintenable. Ne serait-ce que parce que Java est bien plus apte à la POO que Perl.
> Quant aux applis grosses, je n'ai pas d'exemples directs sous la main mais je pense que la conception passe avant le langage.
Moi j'en ai vu passer quelques unes, et je t'assure que le langage fait une énorme différence.
> Quant à l'exemple donné plus haut du client serveur, bof. On fait la même chose (peut-être même plus rapidement) en Perl.
Mouiii :-). On parle pas de la même chose là. Pas d'un petit truc comme slashdot ou daCode. Plutôt WebLogic ou WebSphere.
> Non, je cherche ce qu'apport réellement le Java par rapport à Perl. Et jusqu'à présent, je ne vois rien d'autre que des arguments... qui n'en sont pas :-)
Parce que tu décides qu'ils n'en sont pas. Pose tes oeillères, ouvre un bouquin sur Java, et peut-être que tu changera d'avis.
(Si encore tu parlais de Python ou Ruby... mais Perl, franchement... :-)
[^] # Re: Opinion
Posté par gabuzo . Évalué à 2.
Avantages de Java sur Perl :
Avantages Perl sur Java
[^] # Re: Opinion
Posté par freePK . Évalué à 1.
PK, pas pres de passer a Java :-)
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Ça alors, quelle surprise.
[^] # Re: Opinion
Posté par Nelis (site web personnel) . Évalué à -1.
Nelis [qui a abandonné depuis longtemps l'idée de faire essayer Java à PK] (hop -1)
# Erreurs de C++
Posté par Epsos . Évalué à 10.
* Le mot clef virtual : la plupart des gurus objet expliquent que le but de l'objet est de faire de l'objet !! C'est a dire utiliser du polymorphisme : toutes les methodes devraient etre polymorphique par defaut : ca evite des bugs. Quand on donne a une methode le nom d'une methode de la classe mere, c'est qu'on veut l'overloader !
* Les references : Il y a un truc que j'aime pas en C++ et que je trouve plus clean en java c'est le fait qu'il y ait pas de reference. Les references du C++ ca fait trop de chose en meme temps. Bref, c'est propice aux effets de bords et aux bugs. Attention : Ceux qui sont des brute en C++ ne feront pas l'erreur, mais je ne parle pas de killer en C++, je parle du langage en lui meme.
* Päs d'inner class, ca c'est pas cool. Je trouve que c'est le concept le plus joli que j'ai vu en OO pour modeliser un call back.
* Pas de genericite, ca c'est pas cool. Ca veut dire tout plein de cast pas beaux (et donc une probabilite de se planter au runtime) dans la librairie standard. Pour moi un container se doit d'etre type. Le container qui contient n'importe quoi n'est qu'un container parmi tant d'autre.
[^] # Re: Erreurs de C++
Posté par Marc . Évalué à 8.
Le principal défaut des fonctions virtuelles est l'ajout d'un niveau d'indirection par une table de fonctions virtuelles. Cela empêche la mise en ligne des fonctions qui est un important moyen d'optimisation (voir gcc -03).
Il est vrai que le C++ ne facilite pas l'écriture de code objet.
Mais si on se force a déclarer toute les fonction virtuelles, a ne passer que des références, a ne pas utiliser de pointeurs, a n'hériter que d'une seule classe, a utiliser des classes purement virtuelles comme interface dont ont implémente toutes les méthodes, etc...
On obtient presque du java :-) (félicitation à ceux qui ont lu jusqu'au bout).
En résumé l'avantage du java par rapport au C++, c'est qu'il limite les possibilités d'écrire du code non objet.
[^] # Re: Erreurs de C++
Posté par Epsos . Évalué à 3.
J'ajouterai juste que tu parles de quelqu'un qui s'y connait. Qui connait deja la plupart des pieges et qui sait s'en depatouiller. Bref, pas a la portee du premier venu. C'est pourquoi personnellement je prefere Java : le langage a justement ete cree (designe) de telle maniere qu'on ne puisse pas faire la plupart des erreurs qu'un debutant en C++ ferait.
De plus, Java incite a se concentrer sur l'algorithmique et non pas sur l'optimisation. Chose qu'on ne fait pas en c++, car comme tu dis en C++ on est conscient qu'un appel virtuel ca coute du temps, ... Mais il y a pire : si tu met ou il faut comme il faut des const tu permet au compilo de faire plus d'optimisations. Tu peux aussi declarer tout un tas de methodes inline pour encore plus optimiser ton code.
Ou je veux en venir ?? A ceci :
en C++ on perd trop de temps a penser son programme en tant qu'architecture + optimisation. Resultat au lieu de penser architecture propre, on degrade le cote architecture pour le cote optimisation, et a la fin on a un truc qui pourrait etre largement mieux d'un point de vue architecture.
Le point de vue de Java c'est : pensez architecture ! Les optimisations, c la JVM qui s'en charge. Ca ne doit pas etre votre probleme.
Bon, ca c'est la theorie. En pratique la JVM fait tourner ton programme nettement moins vite que ton compilo C++. Mais je trouve que ca va dans le bon sens. Et c'est ca qui compte. Car finalement le compilateur (ou la JVM) est l'entite la mieux place pour savoir ou mettre les optimisations.
Maintenant combien de temps ca prendra pour optimiser mieux que le programmeur ??
On arrive deja a pondre du code assembleur meilleur que le pekin qui s'y connait, je pense que cette etape viendra. Peut etre pas tout de suite mais elle viendra. Et en attendant, mieux vaut penser architecture propre, puis refaire une passe optimisation que l'inverse ... :-)
[^] # Re: Erreurs de C++
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
Ok, mais rien ne t'empêche non plus d'écrire un truc propre en C++ sans penser une seconde à l'optimisation matériel !
Ce n'est pas parce qu'on peut le faire que C++ t'oblige à le faire.
Cette souplesse du C++ est plutôt un avantage par rapport au java, non ?
[^] # Re: Erreurs de C++
Posté par Epsos . Évalué à 3.
Voila les genres d'optimisations que te laisse faire le C++ : inline, const, virtual, ref, ... Ce sont avant tout des optimisations de bas niveau. Des optimisations qui te font perdre du temps alors que le compilateur pourrait et devrait (comme KCC) les faire a ta place.
En Java, on ne te laisse pas le loisir de faire des optimisations de bas niveaux parce que la JVM devrait le faire a ta place (mais c'est vrai avec n'importe quel compilo optimisant)
En fait, le C++ est cense etre un langage objet. Qui dit objet dit haut niveau, qui dit haut niveau dit : on l'utilise pour se prendre la tete sur des problemes haut niveaux. Si j'ai envie de me prendre la tete sur des problemes plus bas niveaux, je vais prendre des langages plus bas niveaux : le C ou a l'extreme l'assembleur : j'utilise le langage adapte a mes objectifs et a mon probleme. Avec le C++ on te donne l'illusion de faire du haut niveau alors que tu dois quand meme te prendre la tete avec des problemes bas niveaux. En Java non. Oui je suis d'accord rien ne t'empeche de faire de l'assembleur en C++. Dans ces cas la personnellement je prefere prendre un assembleur que du C++.
Simple question de decoupage de probleme.
[^] # Re: Erreurs de C++
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
Ca veut simplement dire que si tu en as quand même besoin, tu peux y aller. Mais bon.
[^] # Re: Erreurs de C++
Posté par Lorenzo B. . Évalué à 1.
En WYSIWYG tu fais la mise en page en même temps que l'écriture, pas (ou moins) en LaTex.
En ce qui me concerne, mon soucis d'optimisation est inversement proportionnel au « niveau » du langage. Par réflexe d'ailleurs, parce que c'est parfaitement idiot à la base.
Mais on a tellement l'impression de ne rien maitriser que finalement on ne se donne aucun mal.
[^] # Re: Erreurs de C++
Posté par vrm (site web personnel) . Évalué à 1.
[^] # Re: Erreurs de C++
Posté par kadreg . Évalué à 0.
[^] # Re: Erreurs de C++
Posté par Epsos . Évalué à 5.
Ce qui est possible en C++, ce sont les nested class, pas les inner class.
Difference entre une nested et une inner :
l'inner class garde une sorte de pointeur vers la classe enclosing, ce qui fait qu'on peut se servir de l'inner classe comme d'un callback vers la classe enclosing. Classe qui aura acces a toutes les methodes et a tous les attributs de la classe enclosing.
[^] # Re: Erreurs de C++
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
- à quoi sert l'héritage multiple ? C'est juste pour se la péter à dire qu'on fait de l'héritage multiple ou il y a un vrai intérêt ?
- qu'est-ce que le polymorphisme, et quels langages l'implémentent ?
[^] # Re: Erreurs de C++
Posté par Epsos . Évalué à 6.
Des problemes se posent lors d'heritage en diamant par ex :
A
/ \
B C
\ /
D
D se retrouve avec 2 copies des methodes et des attributs de A. (un en passant par B, un autre en passant par C).
La plupart des problemes lies a l'heritage multiple c'est lors de la generation de code C++.
Pour faire de l'objet en C, grosso modo ce qu'on fait, c inclure la structure de la classe de base dans la classe derivee. De cette maniere, puisque les offsets des attributs sont toujours les memes, on se pose pas de question.
struct Base
{
byte i; // offset 0
byte j; // offset 1
}
struct derivate
{
struct Base base; // sizeof(Base) => 2
byte k; // offset 2
}
Lorsque tu as un heritage en diamant, comment tu calcules les offsets pour acceder a tes attributs ? On s'en sort en faisant du padding (en mettant des espaces entre les donnees) et en gerant l'acces aux attributs grace a un tableau qui indique comment acceder a un attribut donne suivant le type, mais ca complique les choses, et surtout ca ralentit pas mal l'execution du programme. On a le meme genre de probleme avec les methodes.
Tout ca pour dire que l'heritage multiple ca peut servir, mais souvent on s'en sort beaucoup mieux en revoyant son arbre d'heritage pour enlever les heritages multiples : l'arbre en general devient plus clair (mais c'est bien sur), preuve en general d'une meilleure architecture.
Le polymorphisme, (plusieurs formes, y a des latinistes dans le coin ??) permet a un objet d'un type donne de se faire passer pour un autre objet, ce qui est hyper pratique.
Ex : Tu as un arbre d'heritage
Vehicule
| \
Voiture Camion
Ton code :
Vehicule myVehicule = new Voiture();
==> Tu fait passer ta Voiture pour un Vehicule (normal une voiture est un vehicule)
==> Du code ecrit pour un vehicule fonctionnera a la fois pour une voiture et pour un camion.
Mais lorsque tu "overloade" une methode, ca te permet de changer la methode que tu vas appeler de facon transparente.
Ex :
myVehicule.f()
Si myVehicule est une Voiture, ca va appeler la methode f de Voiture, si myVehicule est un Camion, ca va appeler la methode f de Camion, etc...
Bon, tout ca est assez succinct, si tu veux un bon bouquin (online) pour commencer a voir ce que c'est que l'OO, va voir http://www.ibiblio.org/pub/docs/books/eckel/(...) et recupere "Thinking in java".
Tous les langages orientes objet (OO) implementent le polymorphisme, et l'heritage simple. Certains implementent aussi l'heritage multiple (C++, autre ?) plus d'autres "features" (RTTI, genericite, Reflexion, polymorphisme de methode, exceptions, ...).
[^] # Re: Erreurs de C++
Posté par Vivi (site web personnel) . Évalué à 2.
à noter que le polymorphisme est un terme assez vaste.
Par exemple ce qu'on appelle polymorphisme en Caml (que tu dois connaitre vu ton cursus), c'est assez différent : c'est un polymorphisme paramétrique (les fonctions manipulant des valeurs de type 'a list peuvent travailler avec des listes de n'importe quel type, etc.)
[^] # Re: Erreurs de C++
Posté par Le_Maudit Aime . Évalué à 0.
- LES héritages multiples de C++ (comme toujours en C++, il y a plusieurs façons de se tirer une balle dans le pied)
- l'héritage multiple de certains langages où on te dit qu'on émule cela finalement avec de l'héritage simple et un bidouillage sur les interface (Style Java et cie)
- l'héritage multiple propre des autres langages (à la Eiffel par exemple), mais comme l'héritage est moins mal conçu, ces langages n'ont aucunes espèce d'avenir et végèteront avant de mourir bêtement.
Dans le premier cas, cela permet d'écrire du c++, dans le second cas c'est de l'héritage simple avec récriture amélioré, dans le troisième c'est de l'héritage multiple.
(comme je vois que tu es à l'ENS, castagna au dmi a écrit un bouquin bien prise de tête sur les modèles des langages à objets. J'espère que tu aimes le lambda calcul typé. De plus, il a écrit un excellent article sur les problèmes de variance et de co-variance dans les langages à objet. cf. http://www.di.ens.fr/~castagna/(...))
moi en fait j'y connais rien, je programme en objet avec visual basic et je fais pas de politique donc je ne dirai pas tout ce que je pense de C++.
[^] # Re: Erreurs de C++
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Il y a un vrai interêt, même si les interfaces suffisent 90% du temps. Un papier là dessus écrit par un copain :
http://www.beust.com/cedric/java-delegation.html(...)
On fait souvent l'implication "POO => héritage", c'est faux. Je te conseille le chapitre d'introduction de Design Patterns à ce sujet. Et les suivants aussi :-).
http://hillside.net/patterns/DPBook/DPBook.html(...)
[^] # Re: Erreurs de C++
Posté par VACHOR (site web personnel) . Évalué à 3.
De même l'héritage multiple est une bourde. Peut servir parfois, mais la pluspart des développeurs avancés s'accordent à dire que c'est pas globalement très utile, embrouille parfois les arbres de façon trop complexe, et entraine des risques globaux inutiles.
Java est un langage très récent (1996), et qui s'est développé avec une rapidité sans équivalent. Pour l'instant il est sans équivalent en qualité de conception.
[^] # Re: Erreurs de C++
Posté par shbrol . Évalué à 0.
Quant à l'héritage multiple, c'est pas parce que ca existe que tu es obligé de l'utiliser si ca ne te plait pas. D'autre part, l'heritage multiple en
Java ca existe, ca s'appelle les interfaces. Tu fais la même chose en c++ avec des classes virtuelles pures. Ce qui me chifonne avec Java c'est que quelqu'un a décidé pour moi quelle était la bonne façon de faire.
[^] # Re: Erreurs de C++
Posté par Epsos . Évalué à 2.
Ex :
class A {int i}
class B : public A {}
class C : public A {}
class D : public B, C {}
D possede B::i et C::i ==> Super chiant.
On peut regler le probleme d'un seul coup en important tout le namespace de B (si on veut utiliser tout ce qui vient de B) ==>
class D : public B, C {using namespace B;} Ce qui permet d'eviter de nommer a chaque fois le chemin que l'on veut prendre.
En Java ce probleme ne se pose pas car une interface par definition ne contient que des methodes. Si deux methodes provenant de deux interfaces differentes ont le meme nom, tu n'as qu'une implementation (il y a des avantages et des inconvenients, c# a decide de permettre la resolution ==> On se retrouve avec deux methodes)
Bref, je suis pas d'accord avec ton terme d'heritage multiple, je parlerai plutot d'implementation multiple.
(Grosse difference entre C++ ou on "herite", et java ou on peut "etendre" et "implementer")
[^] # Re: Erreurs de C++
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Tu veux dire qu'un appel à une méthode virtuelle prend moins de temps qu'un appel de fonction C ? :-)
Et sinon, ça n'est pas seulement un pb de perfs mais de taille mémoire. Une classe avec des méthodes virtuelles contient un pointeur vers une table de ces methodes virtuelles, ce qui casse la compatibilité avec C.
En C++, tu peux prendre une struct C, la dériver, y ajouter toutes les méthodes non virtuelles que tu veux, et passer cette classe à une fonction C qui prend normalement la struct comme argument et ça marchera. Si tu ajoutes une méthode virtuelle, ça ne marche plus.
# Et l'objective C ?
Posté par Frederic PY . Évalué à 7.
1) Il est comme le C++ une extension/surcouche du langage C mais a su tirer profit des erreurs de son predecesseur (cf post precedent)
2) il est au moins aussi portable que Java - certains disent plus - e a servit un peu a la naissance de Java (aliance NeXT/Sun). Par contre il beneficie d'un maturite que java n'a pas encore vraiment
3) Contrairement a ce que certains pensent ce langage est facile a manipuler et n'est pas mort (voir Cocoa pour MacOSX ou encore le projet GNUstep a http://www.gnustep.org(...)
[^] # Re: Et l'objective C ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
Bien sur, Objective C tourne sur Ipaq et AS400 par exemple :-).
> et n'est pas mort (voir Cocoa pour MacOSX ou encore le projet GNUstep a www.gnustep.org
2 projets ? Mais c'est énorme! Et sur comp.lang.objective-c (le seul newsgroup sur le sujet) je trouve 23 posts en une semaine. C'est fou cette activité débordante.
Ah, mais surtout le mieux c'est sur Amazon : 2 bouquins sur Objective C :
http://www.amazon.com/exec/obidos/ASIN/0201508281/qid=1006177949/sr(...)
http://www.amazon.com/exec/obidos/ASIN/0201632519/qid=1006177949/sr(...)
dont aucun n'est encore imprimé. C'est clair, ce langage pête la santé :-).
[^] # Re: Et l'objective C ?
Posté par Frederic PY . Évalué à 1.
Il est vrai que nom mais en faisant un port de GNUstep base sur de l'ansi-c et uniquement ceci tu devrait pouvoir faire tourner une appli en Objective-C
>2 projets ? Mais c'est énorme!
C'est de projets de librairies servant de base a l'objective-c (cocoa etant celle privee de mac pour son dernier OS ... plusieurs projets se basent sur ces librairies la ... (cf les packages pour macosX bases sur cocoa)
> comp.lang.objective-c
regarde plutot les bouquins et news sur cocoa
[^] # Re: Et l'objective C ?
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
Cocoa étant en fait l'implémentation d'OpenStep tournant sous MacOSX.
Quand à Objective C, un bon début est http://www.gnustep.org/resources/documentation/ObjectivCBook.pdf(...)
un bouquin sur ObjectiveC qui date de NeXT mais présente bien le langage.
un article intéressant qui explique certains aspects du langage est http://www.gnustep.org/resources/ObjCFun.html(...)
Enfin un petit tutorial sur la création d'une appli sous GNUStep :
http://www.gnustep.it/pierre-yves/index.html(...)
[^] # Re: Et l'objective C ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
C'est très sympa comme langage, mais c'est mort. Compare avec ce que tu trouves pour Java, C++, C#, etc... Peut-être que MacOSX va le ressusciter, mais j'ai un gros doute.
[^] # Re: Et l'objective C ?
Posté par Nicolas Roard (site web personnel) . Évalué à 0.
A part ça, c'est vrai que c'est un langage très agrèable, surtout avec les classes OpenStep (jetez un oeil sur http://www.gnustep.net(...) si vous voulez voir) même s'il manque des choses je trouve (surcharge des opérateurs...)
Certains compilateurs permettent aussi de mixer du code ObjectiveC et C++ .
Bref, même si je mon langage préféré reste C++, je trouve ObjectiveC très attirant ;-) et le projet GNUStep avance à grands pas.
A surveiller de près !
# Pas tres original
Posté par sbruchet . Évalué à 4.
Mais au bout du compte, cela s'integre parfaitement dans une politique d'expansion et de monopolisation de Microsoft
En effet, il s'attaque point par point, toutes choses ou il n'ont pas le monopole. (Rien de bien nouveau, en fin de compte).
Et a terme il font fournir des applications Microsoft pour Linux et enfin finir de s'implenter.
# Arf
Posté par Vivi (site web personnel) . Évalué à -5.
# Pour élargir le débat
Posté par Laurent Ellerbach . Évalué à 4.
Pour élargir un peu le débat, je vous conseille de regarder parallèlement un article écrit par le club Java et une réponse de Microsoft :
http://www.club-java.com/Forum/Discussion/messages/1153.html(...)
http://www.club-java.com/servlet/fr.renaissance.forumWeb.servlet.Se(...)
Vous verrez que cela va au delà de la simple comparaison de deux langages.
Laurent Ellerbach
Microsoft France
# A propos de C#
Posté par Samuel Pajilewski . Évalué à 2.
Ce que je peux vous dire, c'est que C# n'est (selon mon ex-tuteur) qu'un Java Microsoft qui corrige les erreurs de Sun sur ce programme.
Le principal objectif de C# c'est de convertir les utilisateurs de Visual C++ (tres nombreux) à court terme et ceux de Java a moyen terme.
Java represente le plus grand danger de Microsoft à l'heure actuelle, bien plus que Linux !
En effet, si on s'y prend bien, il est facile des faire des applis portables pour OS ayant une JVM, ce qui est le plus grand danger pour Microsoft (D'ailleurs, savez vous pourquoi Visal J++ s'est arrété à la JDK 1.1.7 ? Tout simplement parce que la 1.2 (si je me souviens) permet de manipuler des objets et des fichiers , quelque soit la plateforme !
Ce que je peux vous dire également, C# n'est pas un programme de developpement universel comme l'est Java : il permet de developper facilement des applications pour la plateforme .Net, qui est son principal objectif.
En face d'eux, il y a Sun et son Java, ce sont les seuls concurrents (il y en a d'autres mais de toute autre envergure).
Enfin, Microsoft compte sur le soutient de la communauté Windows (90% des utilisateurs de PC) pour imposer C#.
Il est fort à parier que le compilateur C# et la RAD IDE sera installée d'office dans les futures versions de Windows, et que toute JVM sera banie (comme ils l'ont fait avec Netscape).
Beaucoup de developpeurs se sont deja tournés vers C#, et sans vouloir jouer l'oiseau de mauvaise augure (excusez moi pour l'ortographe) je pense que dans 2 ans on ne parlera plus de Java : Bien que ce langage soit portable, facile, rien ne peut empecher la deferlante marketing de Microsoft.
La seule chose qui peut empecher ça c'est que les utilisateurs reflechissent à deux fois avant de se jetter dessus, mais quand j'ai vu les clients de Microsoft France, je me dis c'est pas gagné...
(Un ancien fan de Microsoft)
[^] # Re: A propos de C#
Posté par Marc . Évalué à 2.
Alors là laisse-moi rire, rien que pour porter vers C# tout les servlet, bibliothèques, driver JDBC et applications java il faudrait plusieurs années. Car attention les deux language sont peut-être semblables mais pas les platformes.
[^] # Re: A propos de C#
Posté par Nelis (site web personnel) . Évalué à 2.
Il est fort à parier que le compilateur C# et la RAD IDE sera installée d'office dans les futures versions de Windows, et que toute JVM sera banie (comme ils l'ont fait avec Netscape).
C'est clair que les gens courent ... Ma copine utilise MSN, et bien la plupart de ses "amis" MSN la pousse à upgrader vers MSN.NET Explorer (peut importe le nom) car ils sont passés la dessus et que c'est incompatible avec la version précédente (en plus la plupart ont des merdes avec la nouvelle version). Pour le moment je lui ai dit de ne pas l'installer (en essayant de lui expliquer les techniques miscrosoftiennes pour imposer leurs technologies) mais bon, tot ou tard elle upgradera ... Enfin tout ça pour dire que je suis de plus en plus dégouté de MS, et que leur procès était une vaste couille ...
# Le Langage
Posté par xavier nicollet . Évalué à 0.
Allez directement à la fin du comparatif, et vous verrez la superbe conclusion de l'auteur.
Apparemment, "l'Académie française" nous fait encore une bonne publicité.
Que dire de plus ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.