Peut-on m'expliquer la grande différence entre cet Objective-C et le C/C++ par exemple ?

Une différence de grammaire ;-)

@HAL-9000 [25/01/2010 10:39]

C est un langage procédural, classique, proche du matériel, fortement typé. le langage idéal pour de la programmation système sur machine sans s'embourber dans le langage spécifique du processeur (grâce à la magie des merveilleux compilateur moderne.

-

C++ est une "chose" bidouillée sur le C pour intégrer (de force, avec un bulldozer) la programmation dite "objet" et une tonne d'autres trucs ( les flots, les exceptions, les templates, le tout avec une syntaxe indigeste si possible). C++ est un dérivé de C. Oui ok, j'admets, je n'aime pas C++. Mais on en meurt pas :)

-

Objective-C est un langage objet, dynamique, faiblement typé (mais peut être fortement, au choix), basé message. Ce n'est pas un dérivé de C, mais une extension au C. (subtile mais important, objective-C est 100% compatible C, linkage compris). C'est un langage que effectivement je trouve bien conçu et équilibré.

Les règles d'écritures en vogue depuis NeXTstep sont verbeuses mais CLAIRES. (y a un maigre espoir que 2 semaine après avoir écrit un code, je reconnaisse vaguement de quoi je causais).

-
La grande force de Objective C sur C et C++, c'est son "runtime". Tout logiciel objective-C intègre en son sein un programme préexistant, qui fournit de nombreux services "dynamiques" (pendant l'éxecution du logiciel proprement dit). Tel que : le ramasse-miette (pour s'affranchir de l'allocution mémoire manuelle), le chargement et l'éxecution de code à chaud, la construction et l'envoie de message à des objets (sous-programme) du système, l'introspection (mais que fout le dit programme?) etc.

Cela permet à "faible coût" (c'est fourni de base on va dire), des plugins comme ceux de Mail.app, l'injection de code dans un logiciel pour étudier son comportement ou sa charge processeur (on peut verrouiller cela hein, pas de panique), etc. On peut le faire avec d'autres langage, c'est juste déjà intégré naturellement de par la nature de objective C.

[url]http://fr.wikipedia.org/wiki/Objective-C[/url]

En gros, Objective-C est le chainon manquant entre C et Java. Dynamique comme Java, mais compilé comme C. Moderne et Objet, mais 100% C.

A mon sens c'est un bon langage. Un bon équilibre entre expressivité (la capacité d'un langage à permettre de formaliser clairement ce qu'on demande) et puissance sans perdre les avantages de C quand nécessaire.

Bon après, j'écrirais pas mes scripts d'administration unix en Objective C...

-
et une bonne fois pour toute, au cas où, Objective-C n'est pas un langage propriétaire inventé par Apple. C'est un langage universitaire des années 80, que NeXT utilisa pour entièrement concevoir leur environnement de développement autour (openstep aka cocoa).

GCC, le compilateur gnu intègre le support objective-c depuis de nombreuses années, sous os x ou ailleurs (linux ), même si l'avenir de objective-C chez apple sera LLVM/Clang (autre compilateur opensource).

-
A propos du développement web :

le problème du développement d'applications WEB (coté serveur, puis déployée chez le client) c'est que c'est l'ENFER.

que ça soit php ou java, c'est l'enfer. et c'est quasi-totalement différent de ce qui se passe sur le client (le navigateur) : javascript+html+css. Y a rien qui soit unifié et qui se tient de bout en bout.

Et bien entendu, y a une dichotomie quasi totale entre les outils utilisés en développement "web" (serveur) et le développement d'Applications (photoshop, pages, safari etc).

Non monsieur , on ne fait pas d'Applications de qualité en JAVA. non. Pensez à Limewire si vous doutez. L'écologie Java ne possède pas de _bons_ outils ni les briques essentielles pour faire aussi bien que Cocoa. et personne n'a l'intention d'écrire ce qu'il faudrait. Par contre Java couvre absolument tout ce qu'on pourrait imaginer avoir besoin pour du logiciel d'entreprise client-serveur.

Mais bref, on aimerait un langage unifié, couvrant TOUT, du client web au serveur ET l'ordinateur généraliste des gens ! le GRAAL.

Il n'existe PAS.

même si j'apprécie énormément la syntaxe objective-C et même si l'idée d'utiliser Cocoa et Xcode(interface builder surtout) pour développer l'interface d'un zoli logiciel web est séduisante, je ne suis pas convaincu par cette solution.

Ici, si j'ai bien compris ce qui est expliqué, il s'agit en gros, de recrée Java Enterprise (un serveur applicatif tel jboss/jonas/webobject + la pile classe java/runtime java) avec Objetive C (le serveur bombax + classes cocoa/objective C)

hu... okay, mais Java et les serveurs applicatifs java ont + de 10 ans de travail acharné derrière eux (et il en faut pour les monstres tels tomcat, jboss, les concepts de déploiement d'applications, la sécurité, et la logique métier derrière) alors que cette solution débarque de nulle part et que si Cocoa est géniale et complet pour la création d'Applications mac ou iphone (y a tout ce qu'il faut pour écrire un Word par exemple), c'est pas vraiment complet pour tout ce qui est besoin web (c'est pas son champs d'utilisation, tout bêtement)

Je crains donc d'y voir un "jouet", une belle idée en soi, mais pas viable si tôt qu'on va vouloir grandir (et on veut toujours grandir, 1000 fois on m'a dit le contraire, 1000 fois ça s'est produit)

-

à la rigueur, quitte à faire des applications web modernes, tout en considérant le public qui lit Macgeneration, et en voulant obtenir le meilleur des concepts de Cocoa/Objective-C, je conseille plutôt Cappucino (http://cappuccino.org/)

je reconnais pleinement que c'est pas équivalent à bombax (cappucino n'est pas un serveur applicatif web client-serveur basé cocoa), mais permet d'écrire de véritables logiciels s'exécutant au sein de safari/firefox, avec des outils de conception reposant sur la syntaxe et concept de objective-C, sans se couper des outils existants du web (javascript, apache, etc).

C'est plus.. hmm naturel et vous avez déjà dans un Os X standard (10.5 ou 10.6) ce qu'il faut pour utiliser cappucino sans installer un serveur supplémentaire

pour conclure, par rapport à une solution typique PHP, ce bombax devrait naturellement permettre de créer une application web plus robuste, plus solide et capable de gérer les problèmes habituels du client-serveur. C'est similaire à java enterprise.

Mais vous êtes face à un outil spécifique, sorti de "nul part", là où Java Enterprise est abondamment connu, reconnu, document, surdocumenté. Mais par contre, on peut utiliser Interface Builder pour la conception. C'est pas rien.

Je viens de parcourir le site de Bombax, et je me pose quelques questions.

Je ne trouve pas de mention sur la licence du logiciel (Prix, Condition d'utilisation...).

La partie Doc est assez courte. Le guide du développeur est présent mais pas celui de l'administrateur.

Je ne me vois pas (pour l'instant) installer ce genre de logiciels sur un serveur. Et pas non plus lancer plus avant des tests sur un produit (sans doute prometteur) mais dont l'utilisation reste nébuleuse.

A l'occasion merci d'en faire un vrai test.

ah oomu, tu pourrais peut-être essayer d'unifier tout ça !

@ oomu : « Dynamique comme Java »

Plus dynamique que Java, en fait. Java est limité dans ce domaine par son typage fort.

@ oomu

Merci pour ces précisions... Etant un programmeur en C/C++ et ayant très très peu touché au Java (il faudra d'ailleurs que l'on m'explique l'avantage de programmer en Java face au C/C++) je serais curieux de tester cet Objective-C que je ne connaît pas du tout. Maintenant si c'est un language qui tends à être obsolète d'ici peu, ça n'en vaut peut-être pas la peine ;)

@HAL-9000

Peu de chances que Objectiv-C devienne obsolete de si tôt, tant qu'Apple existera. Bon OK, ils sont peut-être les seuls à vraiment l'utiliser. Je connais bien C, C++, Java en Objective-C. L'Objective-C à des "fonctionalités" vraiment sympa en comparaison de Java, ce qui lui permet notamment en Cocoa de travailler facilement et plus élégamnnet avec les interfaces graphiques (Swing vs Cocoa), mais là c'est un avis perso.

Maintenant, je vous rappelle que WebObjects qui était à des années lumières en avance de ce qui se faisait en Java était écrit en Objective-C avant de passer en Java et gentillement tomber dans l'oubli général. Dommage d'ailleurs...

@oomu: Tu oublies de mentionner que WebObject était de l'Obj-C pure avant la version 5.0.

Quand Apple a abandonné l'Obj-C au profit du Java, des alternatives Open se sont développées comme SOPE ( http://sope.opengroupware.org/ ) qui m'a l'air d'être un peu plus qu'un "jouet" si ça t'intéresse, ou encore GnuStepWeb ( http://wiki.gnustep.org/index.php/GNUstepWeb ).

@spypol [25/01/2010 11:31]
>ah oomu, tu pourrais peut-être essayer d'unifier tout ça !

premièrement, j'ai des opinions géniales, mais pas des intuitions géniales pour inventer (hé bé vi, comme tout politicien vous le dira, avoir des opinions est très facile, concevoir c'est autre chose, houla.)

ensuite, on me paye pas pour cela. Mais si vous me faites un beau financement, si on monte une belle équipe des meilleurs, si on travaille avec Sun, google, apple, microsoft, le w3c, et les meilleurs, alors ouais ! fucking ouais ! on se lance !

je n'imagine pas objective-C devenir obsolète.

enfin, il date des années _80_. il était un langage de NICHE. Son premier usage sérieux fut par NeXT dans les années 90, vous étiez au courant vous en 92 ? je doute. donc voyez de quel obscurité il vient. Cela l'a tué ?

non, tout comme perl, ruby, lisp, prolog, cobol, etc vivent même si j'ai pas vu un seul article sur eux dans Le Monde ou Programmez! depuis perpet.

non c'est franchement pas grave. Concrètement : Objective C est le langage pour faire les meilleurs logiciels sur mac et iphone. Au delà, il est quasi inexistant

MAIS cela n'a aucune raison de vous arrêter pour _VOS_ projets. VOS projets sont VOS projets, et ils fonctionneront peu importe le beau langage que vous utilisez.

Si demain, un égocentrique mégalomaniaque de mon genre déclame de sa montagne que le langage est "obsolète", ni vos outils, ni vos compilateurs ni vos projets ne vont exploser.

tout va bien. erf, je connais des trucs programmés en Erlang qui vont très bien. et d'autres en LUA qui vont très très bien (non mais vraiment bien).

-
oui webobject était objective-C, et apple/next furent mal inspirés de le tout convertir à java (pour ensuite sans désintéresser). Je pense qu'ils voyait bien la force de java en entreprise. Mais quand des solutions libre/opensources puissantes, sous l'égide de la fondation apache ou autres, tels jboss sont apparus, Apple n'avait plus rien de spécifique à offre face aux solutions java commerciales déjà installées et l'opensource très fonctionnel.

Webobject est devenu le joyau secret d'Apple. Ils ont construit avec une bonne part de leur infrastructure.

" Etant un programmeur en C/C++ et ayant très très peu touché au Java (il faudra d'ailleurs que l'on m'explique l'avantage de programmer en Java face au C/C++) "

bon alors, déjà, Java ne rend pas caduque C et C++. Java répond a des besoins que C/C++ ne répondent pas.

-
la syntaxe objet de Java : java est objet, de la tête au pied. dit comme ça on se demande à quoi bon. Faut le vivre : tout , de la gestion des chaines de caractère jusqu'au chargeur de classes, gestionnaire mémoire ou autre est modulable, est objet, est interchangeable. On se dit "orf, ça me dépasse, m'en servirait jamais", sauf le jour où ca devient franchement utile. Un projet qui s'est intégré dans le runtime java pour ses propres besoins : Nuxeo CMS (nuxeo.com). Chose impossible en zope ou c++

Java est pseudo-compilé, c'est sa force et son défaut. Le fait qu'il est pseudo-compilé va vous le rendre génial (il est portable, et vous pouvez imaginer des trucs délirants) pour certains projets et abominables pour d'autres. A vous de voir. Objective-C est compilé, cela vous limite un peu.

quand on dit Java, en réalité on ne pense pas qu'à la seule grammaire java (la syntaxe), à la rigueur , la syntaxe java on s'en fout. elle ressemble au C, mais on s'en fout. Non, ce qui compte dans Java, ce sont les classes java, java enterprise, jdbc, et les millions d'autres classes java documentés, peaufinés, et utilisés abusivement dans toutes sortes de projet java.

Faire du java, c'est utiliser des milliers de briques préfaites pour répondre à des tonnes de problématiques courantes en développement client-serveur d'entreprise.

C'est aussi s'intégrer à des pratiques (déploiements, découpages fonctionnels..) et outils pré-existants (les serveurs applicatifs) conçu par et pour Java.

En gros, Java c'est un éco-système titanesque, très bien rodé. Cet éco-système est sa force. C'est aussi un obstacle considérable pour apprendre "java".

parce que si la syntaxe java s'apprend un samedi soir avec un cocktail, connaitre l'ensemble de la démesure de Java Enterprise et quoi faire avec, va vous demander des semaines de travail acharné.

Jonas ou Jboss ? Tomcat pour du jsp ou Java entreprise pour du bean ? Jakarta ? un war c'est mieux qu'un jar ? hibernate c'est quoi par rapport à mysql ? haAA y a 23 millions de classes J-bidule déjà existantes???

Voilà le genre de question face à Java : un univers existe déjà et vous êtes encouragés à le ré-utiliser.

-
Java est généralement sur-dimensionné pour un petit projet personnel ou un zoli service internet tout simple. (par exemple toute la clique java pour twitter, c'est surement délirant). Mais pour le service b2b d'une entreprise multi-site, c'est du solide.

Pour un magasin en ligne appelé à se faire bombarder des millions de fois par minute, c'est bien java.
Pour vendre votre shareware, c'est ptet un peu trop lourdingue

Pour un outil de gestion documentaire d'entreprise qu'on souhaite capable de bouffer des documents par milliers tout en gardant trace de l'activité des employés (cache, authentification centralisée, allocation de ressources selon l'utilisateur et conservation de l'état de son travail quelque soit son poste), c'est superbe.
Pour votre blog, c'est une surcomplication inadmissible.

-
Finalement, l'intérêt de Java, c'est typiquement, l'ensemble de tout les outils pré-existants et les pratiques professionnelles qui y sont associés que vous allez hériter.

Linux a énormément d'outils java, java est très impliqué dans le mouvement "opensource", et de nombreuses fondations telles Apache fournissent des briques java. Il y a donc de quoi se faire un très bel outil solide pour relativement peu de moyens

Mais faut une solide culture java pour savoir quoi foutre des Jbidules et pourquoi.

@BeePotato [25/01/2010 11:32]
>@ oomu : « Dynamique comme Java »
>Plus dynamique que Java, en fait. Java est limité dans ce domaine par son typage fort.

vrai.

[quote]Non, ce qui compte dans Java, ce sont les classes java, java enterprise, jdbc, et les millions d'autres classes java documentés, peaufinés, et utilisés abusivement dans toutes sortes de projet java.

Faire du java, c'est utiliser des milliers de briques préfaites pour répondre à des tonnes de problématiques.[/quote]

La même pour le C/C++ donc à ce niveau aucune convergence des deux langages.

j'utilise abusivement le terme interprété, j'aurais du dire pseudo-compilé.

Mouais le succes de java en entreprise reste un mystere pour moi.
Les serveurs d'application J2EE sont quand même pas exceptionnel. Cela reste tres couteux a mettre en place, administrer et securiser. Quand a traiter les incidents alors la c'est la cata.

Shim' qui abhorre ses serveurs J2EE.

Bonjour! Nous avons juste trouvé un bogue dans l'installateur de la version bêta récente 1.beta.3. Nous venons il corrigé dans la version 1.beta.4. Plus d'informations sont disponibles [url=http://groups.google.com/group/bombax-support/browse_thread/thread/e5869ad5807e90cb] ici[/url].

Merci!
[email=dominic@bombaxtic.com]Dominic Blais[/email]
Bombaxtic LLC
P.S. Objective-C n'est pas obsolète - regardez le Cocoa! ;)

@HAL-9000 [25/01/2010 13:40]
>La même pour le C/C++ donc à ce niveau aucune convergence des deux langages.

je ne suis pas sur de comprendre.

Loin de moi l'idée de dire que Java est le seul a profiter de choses pré-construites. bien sur que C/C++ a un héritage titanesque

mais.. quand même, y a quelque chose de spécifique à java.

quand je parle de Jboss, weblogic, ou de Java Enterprise, ou du runtime JRE 6, ce ne sont pas simplement des trucs faits par des gens à droite et à gauche.

Non. Il y a derrière une normalisation stricte, des standards à respecter, et des couches qu'on retrouve absolument partout.

Le moindre linux est prêt à vous installer des milliers de composants java que l'on retrouve absolument dans tout projet java sérieux.

télécharger le JRE et java enterprise, c'est obtenir de nombreuses classes fonctionnelles et standardisées. C'est beaucoup plus ambitieux que les simples bibliothèques standards C++ telle la STL.

quand on dit "j'ai installé C++" on sous-entend typiquement que le compilateur (gcc avec cygwin?). peut être on sous-entend MFC avec microsoft visualdev en prime ? vaguement. c'est flou.

Quand on dit Java, on sous-entend typiquement l'univers java et ses millions de pratiques inscrites dans le marbre.

Si votre application java enterprise (Jave EE) est standard, elle _doit_ se déployer par dessus jonas, redhat jboss , oracle weblogic, voir ibm websphere ! (avec au pire quelques retouches dans les fichiers de configuration de l'application)

Ces 4 produits fournissent un ensemble effarant de fonctionnalités censés respecter la norme Java EE.

@Macleone [25/01/2010 13:08]

je ne connais pas sope. intéressant.

-
j'adorerais adorer Gnustep. (et gnustepweb). A mes yeux, Gnustep est le plus grand gâchis historique du monde du logiciel libre. C'est un drame cosmique, c'est une tragédie grecque, oui c'est à ce point. Je pourrais en faire un roman.

@shimrode [25/01/2010 13:45]
"Mouais le succes de java en entreprise reste un mystere pour moi."
je pense avoir expliqué longuement pour quoi ce n'est pas un mystère : y a un univers préconstruit qui aide.

"Shim' qui abhorre ses serveurs J2EE."

je suis comme vous, j'abhorre l'administration java et me farcir un énième Jmachin qui veut pas s'interfacer avec l'autre Jtrucmuche (ha mais vi, c'est bien sur que parce que le fichier de définiition XML a changé avec la version 3.662.2 de la définition j-xml trucmuche ibm... blablabla.. arg)

mais je sais pourquoi le monde pro s'en sert : au final on peut pondre du _solide_.

je dirais même plus ; je prends beaucoup plus de plaisir à voir et étudier la cohérence et modernité de Cocoa/objective C que la lourdeur administrative fatiguante de Java.

Je trouve plus excitant le développement autour de javascript et le navigateur web (et donc des trucs comme cappucino) que me farcir des EJB java dans jboss.

L'un est fun, fluide, inventif, l'autre est pénible, lourd, bureaucratique, étriqué.

y en a un des 2 qui est mon gagne-pain, devinez lequel. :)

@oomu [quote=y en a un des 2 qui est mon gagne-pain, devinez lequel.]

Tiens toi aussi ;)

@ oomu

Quand je disais "convergence" il fallait lire divergence ;) (je te chariais sur le descriptif que tu venais de faire qui démontrait sur le cas des lib que les deux langages se comportent bien à l'identique)

Sauf que quand tu "installes" C++ c'est bien le compilateur [b]plus[/b] les librairies dites "élementaires". Après à chacun d'installer les lib manquantes (Quantlib par exemple ;)).

Toujours le meme discours qu'on entend :
"PHP c'est pour les bidouilleurs, c'est moche, ça devient vite un noeud de spaghettis"
"Java c'est cool, c'est enterprise ready, mais trop lourd, surdimensionné pour 95% des applis web"

Bon bah essayez un framework Python ou Ruby. Perso, j'utilise Ruby on Rails, et je trouve que c'est un bon juste milieu. Syntaxe super lisible, rapide à prendre en main si on a les bonnes bases du web et de l'objet. Objet et sans la lourdeur d'un framework Java (pas de XML de 200 Mo de config, etc), développement rapide, système de plugins, etc.

@Nyx0uf
"Les avantages de Java face au C ? le garbage collector pour les noobs qui savent plus gérer la mémoire et le multi-plateforme... et c'est tout."

oui...aussi :-)

Il faut bien dissocier Java du J2EE, l'un est un langage performant (mal utilisé mais performant) incluant une liste de librairies minime et tandis que l'autre est une usine à gaz monumentale qui est un cauchemar pour tout développeur. Seuls les DSI ne touchant pas au code et n'ayant pas à intégrer les applications trouvent que c'est une bonne technologie.
Le gros problème des applications écrites en Java (pas J2EE mais bien Java) c'est qu'ils sont souvent écrits avec les pieds. Les progiciels sont codés par des développeurs engagés durant les 5 dernières années en SSII, ils n'avaient pour 75% d'entre eux jamais fait d'objets avant d'être embauchés et une formation de trois semaines semblait suffisante aux yeux des commerciaux...effectivement ça suffit à faire des programmes minables et discréditer toute la chaîne.
Une personne avec des bases solides d'algorithmie, compilation, machines virtuelles saura faire des programmes performants en Java. Une personne connaissant les rouages de la VM (il "suffit" de lire la spec de cette dernière) fera aussi bien en Java qu'avec un autre langage objets (et beaucoup mieux qu'en C++).
Sinon comme il a été dit précédemment, à l'heure actuelle ruby on rails est une alternative très sérieuse à J2EE.

Pour un bon tuto C ou C++ ou Object-C voir le site "www.siteduzero.com"

Même moi j'ai compris ;-)