# Sondage: Nouvel Outil de Développement R.A.D



## eric210766 (24 Avril 2008)

Seriez-vous intéressé par un nouvel outil de développement (application doublecliquable) basé sur le langage Pascal Objet et sur Cocoa ? 
L'application serait un mélange d'Interface Builder et RealBasic.

Merci de votre participation.


----------



## ntx (24 Avril 2008)

Pascal  Un peu "has been"  Cocoa seul en Obj-C suffit amplement :rateau:


----------



## Eul Mulot (24 Avril 2008)

Pourquoi utiliser du Pascal ?!


----------



## grumff (24 Avril 2008)

Ta description de la chose n'est pas sans me rappeler un certain Delphi... (dont il existe un équivalent x11 je crois). Si ça avait la même simplicité et la même richesse, ce serait pas inintéressant. 

ntx : aucun langage n'est has been, il n'y a rien de pire que les gens qui développent en fonction des effets de mode et non de l'intérêt d'une techno.  En l'occurence Delphi qu'est basé sur du Pascal Objet surpasse largement x-code en terme d'ergonomie, tout en étant extrèmement riche. Il permet de développer des applis puissantes dans des temps reccords. Et personnellement j'ai rien contre le pascal. Taper "begin" n'est pas plus compliqué que de faire des acrobaties invraisemblables sur le clavier pour obtenir une accolade.


----------



## ntx (25 Avril 2008)

Je travaille dans l'industrie depuis 10 ans, et là pas de Delphi et autres Pascals : C, C++, Java voire C#. Alors peut être quand dans d'autres domaines le Pascal est encore d'actualité. Mais le passage au Pascal "objet" semble aussi une ultime tentative pour sauver les éditeurs (l'éditeur ?) qui travaillent encore avec ce langage et pouvoir profiter de la "mode" des langages objets. Quant à Apple, le passage à la famille C est complètement fait, adieu le Pascal de Mac OS Classic.


----------



## Didier Guillion (25 Avril 2008)

Je ne juge pas mon électricien sur la marque de son tournevis, alors pourquoi pas Pascal.
Quel serait le degré de portabilité ?

Cordialement


----------



## eric210766 (25 Avril 2008)

J'ai plusieurs fois posé cette question et l'on m'a souvent répondu avec les mêmes arguments pour les deux camps (le pour et le contre).
Le choix du langage est basé sur plusieurs principes:

1°) Le Pascal est probablement le langage le plus plus proche du raisonnement que l'on doit effectuer avant de coder.

2°) C'est un langage peu permissif ce qui évite bon nombre d'erreurs à l'exécution. 

3°) La version écrite à ce jour est fondé sur un Pascal Objet étendu, c'est à dire que certains concepts de l'Objective-C ont été introduits. Par exemple, les méthodes de classes, les chaînes unicodes, etc

4°) En ce qui concerne la portabilité. Puisque l'objectif principal est la production d'applications Mac et compte tenu que Cocoa est au cur du système, aucune portabilité n'est possible.

5°) En ce qui concerne le coté "has been" du langage, je partage cette idée et c'est précisemment l'objectif des extensions qui seront apportés dans ce projet.

Je remercie tous ceux qui ont particpés à ce forum.

Il reste ouvert à d'autres interventions.


----------



## Céroce (25 Avril 2008)

Tu devrais plutôt faire un sondage.


Je vais me permettre de donner un avis très tranché: j'admire tes ambitions mais tu vas perdre ton temps.

Cocoa ne se combine bien qu'avec Objective-C. Je ne veux pas dire technologiquement parlant: Les ponts pour utiliser Cocoa avec Java, Eiffel, Ruby ou Python fonctionnent bien, mais Cocoa possède une culture Objective-C.
Le chapitre consacré à Cocoa-Java dans le livre d'Aaron Hillegass, commençait ainsi: "N'utilisez pas Java pour programmer Cocoa". L'idée est que cela prend trop de temps, que la syntaxe n'est pas adaptée, et que finalement, ObjC s'apprend en une demi-journée. La difficulté vient de maîtriser Cocoa, pas ObjC. Tu remarqueras sur Objective-Cocoa que très peu de questions portent sur ObjC, et quand c'est effectivement le cas, de gens qui n'ont jamais lu un chapître sur la gestion mémoire en ObjC.

Je n'irais pas programmer Cocoa avec mon langage préféré, Python, parce que je vais perdre tout l'intérêt d'utiliser Python.


Ce qui revient à dire qu'il faut, à mon avis, recadrer ton projet. Personne n'a besoin d'un Pascal new-age qui s'interface à Cocoa. Pas plus qu'un Basic new-age.

Ce que tout le monde attend, c'est un langage facile pour programmer rapidement des trucs intéressants; ce qu'AppleScript, ou RealBasic n'ont pas tout à fait réussi à faire. Et fort justement, Delphi est doué pour ça. Introduire Cocoa enlève immédiatement la facilité. Cocoa n'est pas facile; c'est ce que nous nous tuons à crier sur ce forum à longueur d'année.


Ensuite, au sujet du Pascal. Oui, c'est has-been. D'ailleurs Objective-C, C++ et Java aussi le sont. On ne peut en être convaincu qu'en ayant vraiment programmé quelque chose de conséquent en Python ou Ruby. Je vais prendre l'exemple de Python, que je connais bien: bien que la syntaxe puisse être entièrement mémorisée, les listes et les dictionnaires sont des types de bases du langage, ce qui rend leur manipulation beaucoup plus simple. On ne gâche pas son temps à faire des déclarations de variables et pourtant, le langage est très _typé_. Python est un langage qui permet au final de développer rapidement, en gardant un code très lisible.


Bon, j'ai pas tout dit, mais je pense que tu comprendras l'idée. Réponds aux *besoins*. Cherche des partenaires. Si tu n'arrives pas à convaincre *une* personne, alors ton projet vaut que dalle!


----------



## Mala (25 Avril 2008)

Céroce a dit:


> Si tu n'arrives pas à convaincre *une* personne, alors ton projet vaut que dalle!


Moralité, Apple n'aurait jamais dû sortir l'iPhone!!! Bein oui Steve Ballmer trouvait l'idée d'un téléphone sans clavier complétement débile...
Microsoft CEO Ballmer laughs at Apple iPhone


----------



## grumff (25 Avril 2008)

J'ai du mal à suivre vos raisonnement moi. On a l'impression que la seule chose qui vous va pas est le langage. Personnellement des langages j'en connais une trentaine (certains mieux que d'autres, évidemment), mais ce qui me fait choisir entre l'un ou l'autre pour une tâche donnée, c'est jamais le langage, c'est hyper secondaire ça. Un langage c'est qu'une syntaxe, éventuellement une idéologie derrière. Ce qui est décisif dans un choix, c'est la richesse des composants, des library, les frameworks, l'environnement de développement, le fait que le code soit compilé, pré-compilé ou interprété.

Bref le Pascal ça me rebute pas plus que ça, c'est un des premiers langages que j'ai appris, ça se compile donc c'est relativement performant, mais ce qui m'intéresserait c'est d'en savoir un peu plus sur ce qui sera développé autour. J'en reviens à une comparaison avec Delphi, vu que le premier message m'y fait fortement penser, est-ce que le but c'est d'avoir un environnement avec la même richesse de composants ? Est-ce que ce sera une ergonomie du même genre ou plus proche d'InterfaceBuilder ? Qui est certes puissant mais pas aussi simple.
Et bien sûr, la question la plus importante, à quel prix ?


----------



## p4bl0 (25 Avril 2008)

grumff a dit:


> J'ai du mal à suivre vos raisonnement moi. On a l'impression que la seule chose qui vous va pas est le langage. Personnellement des langages j'en connais une trentaine (certains mieux que d'autres, évidemment), mais ce qui me fait choisir entre l'un ou l'autre pour une tâche donnée, c'est jamais le langage, c'est hyper secondaire ça. Un langage c'est qu'une syntaxe, éventuellement une idéologie derrière. Ce qui est décisif dans un choix, c'est la richesse des composants, des library, les frameworks, l'environnement de développement, le fait que le code soit compilé, pré-compilé ou interprété.
> 
> Bref le Pascal ça me rebute pas plus que ça, c'est un des premiers langages que j'ai appris, ça se compile donc c'est relativement performant, mais ce qui m'intéresserait c'est d'en savoir un peu plus sur ce qui sera développé autour. J'en reviens à une comparaison avec Delphi, vu que le premier message m'y fait fortement penser, est-ce que le but c'est d'avoir un environnement avec la même richesse de composants ? Est-ce que ce sera une ergonomie du même genre ou plus proche d'InterfaceBuilder ? Qui est certes puissant mais pas aussi simple.
> Et bien sûr, la question la plus importante, à quel prix ?


+1, sauf que je ne connais pas une 30aine de langages :rateau:

À part ça c'est exactement la même chose que ce que je pense mais sans la flemme de l'écrire


----------



## eric210766 (25 Avril 2008)

Je vais répondre à Céroce. J'ai lu avec intérêt sa critique.

 Je suis d'accord sur le principe que Cocoa se combine naturellement avec l' Objective-C. C'est logique puisqu'il est écrit dans ce langage. 

 J'ai lu le livre d'Aaron Hillegass. Il est clair que dans le chapitre 4, il n'est pas tendre avec les outils C++ et Java. 
Il se permet là de dire une contrevérité. La folie de surclasser ! J'ai travaillé avec CodeWarriors en utilisant le framework PowerPlant pendant plus 6 ans. Dans mes développements, je n'ai jamais dérivé la moindre classes relatives à l'interface visuelle. Je ne sais sur quel outil il se base, puisque son univers est Apple !  En revanche, son livre est précis et de de bonne facture.

 Le but du projet n'est pas de modifier le couple Xcode d'un coté et Interface Builder de l'autre en remplaçant  le langage. 
Il s'agit plutôt d'introduire le concept d'intégration d'un environnement de développement. Concrètement, il n'est plus nécessaire de naviguer entre les deux applications. La création d'un objet graphique sera automatiquement identifié dans le code correspondant. Une liste permettrait de choisir l'événement à implémenter pour un objet concret. Tout ceci est l'idée même de real basic, de vb ou de delphi. D'autre part, plusieurs opérations fastidieuses, telles que les connections, seront à jamais bannies. J'ai construit de nombreuses interfaces et je peux  dire que ça en devient pénible.
C'est la première idée du projet.

 La seconde idée s'appliquera plus tard, une fois que la fiabilité sera au rendez-vous. Il est clair que le projet est de longue haleine. De nombreuses versions sortiront gratuitement.

 Je cite "Personne n'a besoin". Je ne comprend pas. As-tu l'expérience suffisante pour affirmer ? Si tu as accès à des informations particulières, peux-tu me les communiquer ?

 Pour finir, "réponds aux besoins", tu ne crois pas que je vais dans ce sens ?  En ce qui concerne les partenaires, je développe seul et j'ai déjà beaucoup dans ma besace !

J'aurais aimé poursuivre mais je doit m'arrêter là. 

A suivre ..


----------



## grumff (26 Avril 2008)

Ça répond en bonne partie aux questions que je me pose, pour moi il y a un trou à combler dans le développement sur mac :
Je ne connais aucun environnement de développement qui permette de façon simple et rapide de construire une application stable, rapide, réactive avec une interface aqua et un grand éventail de composants. Bref, ce que fait Delphi sur PC, et dans une moindre mesure PowerBuilder.
Si c'est sur ce créneau que tu veux te positionner, et qui plus est gratuit dans un premier temps, ça m'intéresse évidemment.


----------



## eric210766 (26 Avril 2008)

erratum: Un erreur s'est glissée lors de ma dernière intervention.

Il ne s'agit pas de "surclasser" mais de "sousclasser" ! car "surclasser" n'a aucun sens !


----------



## Céroce (26 Avril 2008)

Mala a dit:


> Moralité, Apple n'aurait jamais dû sortir l'iPhone!!! Bein oui Steve Ballmer trouvait l'idée d'un téléphone sans clavier complétement débile...


Excuse-moi, ma phrase est mal tournée, je voulais dire que "si tu n'arrives pas à convaincre *au moins une autre* personne, alors ton projet ne vaut rien".

Ça arrive quand tu exposes un projet à quelqu'un et que tu lui demandes son avis. Il te dit: "hum, moui, c'est intéressant
- Tu veux participer ?
- Ben là, tu comprends, j'ai plein de projets".



			
				eric210766 a dit:
			
		

> J'ai travaillé avec CodeWarriors en utilisant le framework PowerPlant pendant plus 6 ans. Dans mes développements, je n'ai jamais dérivé la moindre classes relatives à l'interface visuelle.



J'ai développé environ 2 ans (bon, pas au quotidien) avec PowerPlant, et si, tu passes ton temps à sous-classer les classes graphiques. Par exemple, comment faisais-tu pour gérer un clic sur un bouton ? Tu dérivais la classe Bouton pour pouvoir réécrire la méthode qui gérait les clics. Cette manière, en plus d'être très peu flexible (il faut créer une sous-classe pour chaque bouton, super), génère des Mo de classes inutiles. De plus, elle n'oblige pas à utiliser le paradigme M-V-C. On peut considérer que c'est une contrainte de moins, et en effet cela simplifie l'apprentissage dans un premier temps, mais pour les programmes conséquent, ce paradigme est indispensable.



			
				eric210766 a dit:
			
		

> D'autre part, plusieurs opérations fastidieuses, telles que les connections, seront à jamais bannies. J'ai construit de nombreuses interfaces et je peux dire que ça en devient pénible.


Il ne faut pas exagérer, les bindings sont passés par là, et l'avantages des connexions, c'est qu'elles sont très flexibles et peuvent être attachés et détachées dynamiquement.



			
				eric210766 a dit:
			
		

> Je cite "Personne n'a besoin". Je ne comprend pas. As-tu l'expérience suffisante pour affirmer ? Si tu as accès à des informations particulières, peux-tu me les communiquer ?


Alors, non, je n'ai pas de statistiques à te soumettre, c'est juste une conviction, acquise après quelques années à voir les questions sur ce forum, entre autres. C'est pourquoi je te proposais de lancer un vrai sondage sur ce forum, qui affiche des pourcentages.


Pour l'instant, je pense que le débat est intéressant; je tiens à préciser que mon but n'est pas de te démotiver, plutôt de t'aider à préciser ton idée. Pour l'instant, ton projet me semble positionné d'une façon bâtarde: pas vraiment un outil d'expert comme XCode/IB, ni vraiment un outil d'amateur comme RealBasic.
Ma conviction, c'est que c'est sur ce deuxième créneau que nous t'attendons.

InterfaceBuilder est séduisant dans son concept, mais me paraît difficile à utiliser pour un amateur. De plus, il est très lié à XCode. J'imagine qu'en faire une version simplifiée serait toutefois un travail très lourd (n'est-ce pas ce que tu as commencé à faire chez Objective-Cocoa?)

Ton idée est identique, au langage près, à celle d'AppleScript Studio on ne peut pas dire que ça ait vraiment décollé. Pas seulement la faute au concept, la faute à Apple aussi.


----------



## Mala (26 Avril 2008)

Céroce a dit:


> Excuse-moi, ma phrase est mal tournée, je voulais dire que "si tu n'arrives pas à convaincre *au moins une autre* personne, alors ton projet ne vaut rien".
> 
> Ça arrive quand tu exposes un projet à quelqu'un et que tu lui demandes son avis. Il te dit: "hum, moui, c'est intéressant
> - Tu veux participer ?
> - Ben là, tu comprends, j'ai plein de projets".


Autant pour moi, effectivement je l'avais compris dans l'autre sens.


----------



## grumff (26 Avril 2008)

Céroce a dit:


> Pour l'instant, je pense que le débat est intéressant; je tiens à préciser que mon but n'est pas de te démotiver, plutôt de t'aider à préciser ton idée. Pour l'instant, ton projet me semble positionné d'une façon bâtarde: pas vraiment un outil d'expert comme XCode/IB, ni vraiment un outil d'amateur comme RealBasic.


Moi je suis justement convaincu que c'est dans ce créneau intermédiaire qu'il y a un trou à combler.


----------



## eric210766 (26 Avril 2008)

Merci grumff ! Tu as tout compris !
Il s'agit de reprendre l'idée de delphi et de l'adapter à l'environnement Mac par l'intégration de Cocoa. Les classes relatives à l'interface visuelle ne posent aucun problème.
Les méthodes d'action, les notifications et les méthodes événementielles sont regroupées sous le terme unique d'événement. Elles s'écrivent pratiquement toutes de la même façon

Par exemple. on dispose d'un bouton butOk et l'on veut écrire le code de réaction, on obtient la méthode suivante:

Event x.butOK_Action;
Begin
End; { butOK_Action };

x étant le nom de la classe du controleur. Il peut s'agir d'un controleur de fenêtre ou de boite de dialogue (pannel), ce qui est équivalent à quelques propriétés près. 

Si l'on veut traiter l'événement mouseEntered, il suffit de sélectionner cet événement dans l'éditeur de code, on obtient:

Event x.butOK_MouseEntered(inEvent:NSEvent);
Begin
End; { butOK_MouseEntered }

Pour les fenêtres, par exemple, la notification est traitée comme un événement. 

Event x.WindowDidBecomeKey;
Begin
End; { WindowDidBecomeKey }

Fini les sous cas, délegate, target et compagnie. Une approche unique et globale. C'est l'idée directrice d'XDev.

La gestion des menus est également simplifiée. Chaque menu traité doit implémenter deux méthodes. La première consiste à l'exécution de l'action de la commande. Elle s'écrira pour l'article Nouveau : 

Event x.mnuItemNew_Action;
Begin
End; { mnuItemNew_Action }

La seconde s'interesse à la façon de gérer la disponibilité. Elle s'écrira:

Event x.mnuItemNew_Validation:Boolean;
Begin
End; { mnuItemNew_Validation }

ou

Event x.mnuItemNew_Validation(inItem:NSMenuItem):Boolean;
Begin
End; { mnuItemNew_Validation }

A ce propos, je n'ai pas tranché. La seconde écriture permet de modifier l'article de menu dans son ensemble. La valeur retournée indique si oui ou non l'article est dispo.

Par ces quelques exemples, il est évident que certaines lourdeurs ont été radicalement éliminées.
Chaque fois que j'implémente une classe de Cocoa, je recherche toujours un moyen de masquer la lourdeur, l'initialisation, etc&#8230; C'est l'objectif de tout bon R.A.D. C'est la plus-value de l'application.

Je vais répondre à Céroce

Je vais aller à l'essentiel. En ce qui concerne PowerPlant, je suis très étonné car les controles sont probablement les classes que l'on étudie en premier lorsque l'on aborde un IDE qui le permet. Par défaut, on est attiré par tout ce qui est visuel.
Pour répondre à la question, comment gérer les clics d'un bouton, c'est simple. On instancie un objet de la classe LButton ou équivalent (de PowerPlant). Puisque LButton hérite de LBroadcaster, il est capable d'envoyer un message matérialisé par un MessageT (SInt32) qui identifie le controle. Le directeur est une classe dérivée de LListener. si bien qu'il est à l'écoute. Pour éviter l'anarchie, il faut lors de l'initialisation effectuer un enregistrement du listener par le broadcaster. 
La ruse est: Si j'écoute quelqu'un, c'est que je le connais ! 
Je confirme que M. Aaron Hillegass se trompe sur ce point. Quoi penser en ce qui concerne Java ? Je ne sais pas (je n'ai pas vérifié) et ça ne m'interesse pas !

Pour la démotivation, qu'on se le dise franchement, le projet sortira.

Le compilateur fonctionne, l'éditeur de code est quasiment finalisé. L'éditeur de l'interface est en cours de réalisation.Toutefois, je reste prudent. J'ai, par le passé, appris à mes dépends que certaines tâches qui paraissaient faciles ne l'étaient pas !
Quand à Cocoa, c'est long et lourd à implémenter. C'est le poids !

Je t'invite lors de sa sortie à l'utiliser, si tu veux, car il sera disponible gratuitement....
... dans un premier temps !


----------



## Mala (30 Avril 2008)

grumff a dit:


> Moi je suis justement convaincu que c'est dans ce créneau intermédiaire qu'il y a un trou à combler.



Mon premier sentiment était le même mais les éléments d'éclaircissement apportés sur developpez.com m'ont fait changer d'opinion.

Voir ici:
http://www.developpez.net/forums/showthread.php?t=536335


----------



## tatouille (30 Avril 2008)

en gros vous voulez reecrire 

http://www.fscript.org/


----------



## Mala (30 Avril 2008)

tatouille a dit:


> en gros vous voulez reecrire
> 
> http://www.fscript.org/



Heu, j'ai peur de ne pas comprendre. Quel rapport entre un RAD et F-Script???


----------



## Hurrican (30 Avril 2008)

Moi je pense aussi qu'un outil simple mais riche et bien interfacé avec Cocoa manque...
Et pas de Pascal ? Parce qu'il est ancien ? Alors pourquoi la majorité des softs sont ils écrits en basic (VB pour ne pas le citer) ?
Ce n'est pas parce que l'origine d'un langage est ancienne, qu'il est obsolète, ou pire qu'il est inefficace. En général les modernisations apportent souvent la réponse aux manques, et on ne perd pas souvent au change.
Un Pascal se maîtrise autrement plus facilement qu'un ObjectiveC et permettra d'écrire bien plus rapidement la plupart du code.
Si on prend le parallèle sous Windows, la plupart des logiciels sont développés en majorité sur VB, et on code spécifiquement telle ou telle partie en Visual C++ pour qu'il soit plus efficace, ou parce que les besoins seront mieux couverts avec ce langage. Voilà d'ailleurs un point à étudier de près.


----------



## tatouille (1 Mai 2008)

Mala a dit:


> Heu, j'ai peur de ne pas comprendre. Quel rapport entre un RAD et F-Script???


cf vb


----------



## tatouille (1 Mai 2008)

Un Pascal se maîtrise autrement plus facilement qu'un ObjectiveC ?

bof l'obj-c c est pas tres dure 
je ne comprend la comparaison


----------



## Mala (1 Mai 2008)

tatouille a dit:


> cf vb



Justement VB ok c'est un RAD à la base. F-Script est à mon sens aux antipodes dans le sens où son but n'est pas de simplifier la conception et l'interfaçage avec des IHM mais de scripter des applis. Il suffit de voir le bout de code d'exemple du convertisseur d'Apple revisité en F-Script pour s'en convaincre. C'est un outil impossible à prendre en main si on ne connaît pas parfaitement Cocoa et les mécanismes d'Obj-C.


----------



## Mala (1 Mai 2008)

Hurrican a dit:


> Si on prend le parallèle sous Windows, la plupart des logiciels sont développés en majorité sur VB, et on code spécifiquement telle ou telle partie en Visual C++ pour qu'il soit plus efficace, ou parce que les besoins seront mieux couverts avec ce langage.


Parce que développer une IHM en Visual C++ c'était une galère et que microsoft n'a jamais eu l'intelligence de mixer les deux. Ce n'est pas pour rien que Delphi (ou son petit frêre C++ Builder) plaît tant sur PC. La VCL (Visual Componant Librairie)  y est pour beaucoup.


----------



## Hurrican (1 Mai 2008)

Mala a dit:


> Parce que développer une IHM en Visual C++ c'était une galère et que microsoft n'a jamais eu l'intelligence de mixer les deux. Ce n'est pas pour rien que Delphi (ou son petit frêre C++ Builder) plaît tant sur PC. La VCL (Visual Componant Librairie)  y est pour beaucoup.


Nous sommes d'accord.


----------



## grumff (1 Mai 2008)

Mala a dit:


> Mon premier sentiment était le même mais les éléments d'éclaircissement apportés sur developpez.com m'ont fait changer d'opinion.
> 
> Voir ici:
> http://www.developpez.net/forums/showthread.php?t=536335



Je vois rien là bas de très différent de ce qu'on a put lire ici. Enfin juste une question, pourquoi une machine virtuelle ? Alors que le programme ne sera pas multi-plateforme et qu'il existe déjà des tas de compilateur pascal pour mac os x, dont certains sont certainement open-source et pourraient donc évoluer vers du pascal objet...
J'ai peur qu'on perde là dedans certains avantages que ce soft pourrait avoir sur un VB, au niveau des perfs et de la réactivité notamment.

Sinon j'avoue que je comprends pas cet acharnement contre le pascal. Vous le connaissez au moins ? La syntaxe est un peu différente des langages les plus courants, mais au niveau des mécanismes c'est très proche du c++. Et puis c'est bien une syntaxe similaire (quoique le langage soit très différent) qu'est utilisée en pl/sql, ça n'a jamais dérangé personne...


----------



## Mala (1 Mai 2008)

Hurrican a dit:


> Nous sommes d'accord.


On sent qu'il y a du vécu derrière cette réponse courte et consise!  



grumff a dit:


> Je vois rien là bas de très différent de ce qu'on a put lire ici.


Le coup de la machine virtuelle ce n'est pas rien tout de même. Quiz de l'intérêt d'un tel outil mono plateforme en interprété?



grumff a dit:


> Sinon j'avoue que je comprends pas cet acharnement contre le pascal. Vous le connaissez au moins ?


Le choix du langage implique des problèmes d'interropérabilité qui seraient de fait inexistant avec un projet équivalent qui s'appuierait sur du C++ ou de l'Objective-C. Mais bon après les goûts et les couleurs... 

Maintenant si on veut tout de même partir du principe que le language n'a pas d'importance ok.  Mais alors quel est l'intérêt de ce logiciel par rapport à un RB par exemple?


----------



## grumff (1 Mai 2008)

Mala a dit:


> Le coup de la machine virtuelle ce n'est pas rien tout de même. Quiz de l'intérêt d'un tel outil mono plateforme en interprété?


On est d'accord là dessus, c'est effectivement un choix que je ne comprends pas, comme je l'ai souligné plus haut, et un point qui me rend un peu moins optimiste sur ce qu'on va gagner par rapport à RB. Des éclaircissements seraient les bienvenus.


----------



## tatouille (1 Mai 2008)

Mala a dit:


> Justement VB ok c'est un RAD à la base. F-Script est à mon sens aux antipodes dans le sens où son but n'est pas de simplifier la conception et l'interfaçage avec des IHM mais de scripter des applis. Il suffit de voir le bout de code d'exemple du convertisseur d'Apple revisité en F-Script pour s'en convaincre. C'est un outil impossible à prendre en main si on ne connaît pas parfaitement Cocoa et les mécanismes d'Obj-C.



oui mais bon pour utiliser un framework faut il faut le connaitre 
la Microsoft Foundation Class  est aussi une vaste library apres cocoa justement cest plutot assez simple j ai pas mal developpe avec gtk qui a le meme system de IB et c est quand meme bien plus agreable, j ai dev en visual cpp aussi, l outil ultime ds ce genre a toujours ete cw avec power plant


----------



## Hurrican (2 Mai 2008)

Mala a dit:


> On sent qu'il y a du vécu derrière cette réponse courte et consise!


Ben, oui , et Grumff me connais  bien, hein Florent ? 
Même si je suis à la base plutôt spécialisé mini et gros systèmes, je développe aussi beaucoup (et de plus en plus) sur micro (PC/Mac).



Mala a dit:


> Maintenant si on veut tout de même partir du principe que le language n'a pas d'importance ok.  Mais alors quel est l'intérêt de ce logiciel par rapport à un RB par exemple?


Heu, j'utilise RB. A la base parce que multi-plateforme. Et comme le but était de faire switcher progressivement toutes les sociétés du groupe dont je suis le responsable, il me semblait un outil "idéal", pour le faire en douceur. 
Mais RB me pose trop de de soucis. Entre la stabilité qui n'est toujours pas au rendez-vous, la complexité réelle (obligé de développer des fonctions pour contourner des problèmes dans des instructions simples par exemple), et la lourdeur générale, je ne le conseille plus. 
RealSoftware essaie à priori de régler ses soucis divers dans les dernières versions, mais souvent de manière radicale et au détriment des développeurs. Exemple typique, la disparition des bindings pourtant si pratiques et utilisés, depuis la 2007r5. Ils n'ont jamais réussi à en chasser tous les bugs (je leur en ai moi même fai remonter au moins 3), et plutôt que de se battre avec, les ont virés... 
Reste que RB, s'il était fiable, et que le debugger faisait quelques progrès (déjà sur l'ergonomie), ce pourrait être un excellent outil. 
S'il pouvait exploiter Cocoa et IB... Mais là on rêve. 
Et c'est justement là qu'intervient un nouvel outil en Pascal Objet.


----------



## eric210766 (2 Mai 2008)

Merci à Hurrican de son entrée. 

Je ne comprend pas très bien l'orientation de la discussion. En effet, les propos se basent sur Windows. Je tient à préciser que l'outil à évaluer est sur Mac !

D'autre part, j'ai du mal à comprendre le ni ni de mala ? Ses conclusions sont franchement hatives ? C'est pour cette raison que je ne poursuivrais pas si le débat dérive de la sorte. 
En ce qui concerne le choix de l'architecture pour le langage. Celà fait plusieurs années que je m'interesse aux compilateurs. Je suis d'ailleurs tombé sur un ouvrage très accessible "Réalisation d'un compilateur" qui avait pour but l'élaboration d'un langage proche du Pascal, nommé Leria. Il était dépourvu de certaines instructions du langage.
Au fur et à mesure, je l'ai amélioré en le portant en C, puis en C++. A chaque portage, je lui apportais des modifications, l'orienté objet, héritage simple, les instructions manquantes. La dernière version en Objective-C apporte le support des chaînes unicodes, les méthodes de classes ainsi que de nouveaux mots clé pour le support des classes de Cocoa.
C'est pour cette raison que je ne me suis pas soucié de l'existence des autres compilateurs en open-source. C'est la principale raison.
D'autre part, j'ai téléchargé les sources de mySQL qui est un projet open-source. C'est inaccessible !  Du C fortement optimisé, c'est illisible. C'est la seconde raison.

Le compilateur engendre un code byteCode exécutable pour une machine virtuelle. Effectivement, il y a une perte que je n'ai pas encore évalué en ce qui concerne la gestion de l'IHM. En revanche, les appels de méthodes d'objets Cocoa sont sensiblement équivalents. Les temps supplémentaires sont les transmissions des éventuels paramètres ainsi que leur casting avant l'appel puis la transmission de l'éventuelle valeur de retour. Il n'y a pas de quoi à fouetter un chat !

Une information importante. Cocoa étant écrit en Objective-C, il exploite intensivement les  fonctionnalités offertes par ce langage. Il est clair qu'au moment de lancer une application Cocoa, le système met en place l'environnement et lance le runtime. C'est également une sorte de machine virtuelle à une exception importante près. En effet, les instructions sont exprimées dans le langage machine du processeur. 
De là, je veux insister qu'une application Objective-C est moins performante qu'une écrite en C++ et personne ne s'en plaint !

Je vais terminer par répondre à Hurrican.

 Le debugger du projet est identique à celui d' Xcode. Les informations sur les variables sont adaptées au langage Pascal. Désolé, je n'ai pas de photo à te montrer, car j'ai supprimeé le compilateur/débogueur afin raccourcir les temps de compilation !

 En 2005, lors de l'Apple Expo, j'ai discuté avec les commerciaux de RealSofware. Parmi eux, un semblait plus technicien que les autres. Il m'a dit que les ingés travaillaient sur l'implémentation de Cocoa. Qu'ils avaient des problèmes liés à la ré-entrance. Ce mécanisme intervient , entr'autre, lorsque l'on met des points d'arrêts dans les méthodes de délégation qui retournent une valeur. Ce problème est également mon problème et il n'y a pas de solution facile.
Par ailleurs, RealBasic est écrit en gnu C++. Il exploite Carbon. C'est là que survient le second problème. En effet, comment gérer Cocoa qui a besoin de son runtime alors que le C++ ne l'installe pas. Je n'ai pas ce problème.


----------



## grumff (2 Mai 2008)

> Ben, oui , et Grumff me connais bien, hein Florent ?


Si tu le dis Jean-Marc ! 



> Effectivement, il y a une perte que je n'ai pas encore évalué en ce qui concerne la gestion de l'IHM.


Et c'est justement ça qui m'inquiète. Il y a une autre machine virtuelle bien connue qui m'a toujours laissée un goût amer en ce qui concerne la réactivité des interfaces...  Qui a jamais utilisé une fois dans sa vie (en général c'est la seule) un certain Poseidon sait de quoi je parle... 

Mais bref, je suis quand même impatient de voir le résultat.  On va pas commencer à dire trop de mal des performances d'une application qu'on n'a pas encore eu entre les mains.


----------



## Hurrican (2 Mai 2008)

eric210766 a dit:


> Je ne comprend pas très bien l'orientation de la discussion. En effet, les propos se basent sur Windows. Je tient à préciser que l'outil à évaluer est sur Mac !


Nous ne faisons que des parallèles avec des expériences vécues. 
Nous avons tous bien compris qu'il s'agissait d'un outil mac.


----------



## Mala (3 Mai 2008)

eric210766 a dit:


> D'autre part, j'ai du mal à comprendre le ni ni de mala ? Ses conclusions sont franchement hatives ?


Tu as raisons mes conclusions sont hâtives mais comme le souligne Hurrican on se base sur du vécu.

Maintenant, je prenais l'exemple de RB parce que c'était l'outil évoqué dans ton premier post. Sa plus-value à lui (du moins c'est son argument commercial numéro 1) c'est le côté multi-plateformes même si Hurrican nous a clairement montré que d'après son expérience c'est un outil loin d'être parfait. Ma question - et je me répète mais tant pis - consiste simplement à comprendre la réelle plus-value de cet outil codé en Pascal, qui est dixit toi même une copie d'IB et d'Xcode sur le plan ergonomique?

Je terminerais juste avec ceci. Le C++ est plus performant que l'Obj-C uniquement sur les appels de méthodes du fait de l'approche dynamique de ce dernier. Pour le reste, cela reste du C. Il suffit de faire un peu de traitement matriciel (genre manipulation de bitmap) pour s'en convaincre. A cela il ne faut pas oublier l'Obj-C++. Cela confère à ce langage une très grande ouverture aussi bien sur le plan de l'intégration de librairies existantes que des possibilités d'optimisation pour des cas où les perfs sont critiques. Sans oublier que c'est aussi un porte ouverte aux développements dont la partie Model serait entièrement conçue en C++ pour une question de portabilité tandis que les parties Vue/Contrôleur seraient conçues en Obj-C pour une question d'intégration avec l'OS (et là encore c'est du vécu).


----------



## Didier Guillion (3 Mai 2008)

Une question : est ce que le Pascal a été normalisé depuis le temps ?
Par exemple, j'ai des sources C qui doivent avoir plus de 20 ans, ont connus une dizaine de compilateurs et sont toujours fonctionnels.
Le Pascal peut il garantir cela ? (Dans les années 90, on parlait DES pascals et non DU pascal)


Cordialement


----------



## eric210766 (3 Mai 2008)

La première source de normalisation que je connaisse, de Pascal fût la version Turbo Pascal 1.0 sur Mac de 1986. Dans ce livre, il est mentionné que cette version de Pascal respecte en partie les spécifications ANSI/IEEE770X3.97-1983 décrites dans American Standard Pascal Computer Programming Language. 

En revanche, je n'ai rien trouvé dans le manuel de l'utilisateur de Think Pascal.
Ce langage jette les bases de l'orienté objet. Ce sont celles que j'ai implémenté compte tenu de la popularité de cet outil au début des années 90.

Bonne question. Effectivement, je ne peux égaler cette expérience puisque le compilateur n'a jamais quitté mes cartons,
J'ai effectué de nombreux tests trouvés sur internet, dans les livres que je dispose, afin de le fiabiliser au maximum.

Peux-tu me dire que produit le compilateur écrit en C que tu disposes. Quelle est la cible de l'éxécutable ?
De manière générale, un compilateur se décompose de la manière suivante:

	&#8226; Table des symboles,
	&#8226; Table des mots réservés ,
	&#8226; Pré analyseur syntaxique (PreParser),
	&#8226; Analyseur syntaxico-sémantique (Parser),
	&#8226; Producteur et optimlsateur  de code,
	&#8226; Relieur (Linker).

La machine virtuelle

	&#8226;  Exécuteur (player)
	&#8226; Frameworks trappés. (On parle également de glue)


----------



## nerval2005 (3 Mai 2008)

Bonjour,

Juste quelques lignes pour vous donner mon sentiment : je ne suis pas un expert en programmation, loin de là, et suis même assez débutant. Ceci dit, cela ne m'a pas empêché de créer sous windows une petite application de gestion de périodiques grâce au recours de Delphi.

J'ai toujours regretté qu'il n'y ait pas sur Mac un équivalent à ce RAD, avec une base de Pascal, un langage que je trouve suffisamment à ma portée.

Alors, personnellement, j'applaudis cette démarche, tout simplement. 

Cordialement


----------

