Sondage: Nouvel Outil de Développement R.A.D
- Créateur du sujet eric210766
- Date de début
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.
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.
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
bof l'obj-c c est pas tres dure
je ne comprend la comparaison
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.
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.
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...
On sent qu'il y a du vécu derrière cette réponse courte et consise!Nous sommes d'accord.
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é?
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?
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.
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
Ben, oui , et Grumff me connais bien, hein Florent ?On sent qu'il y a du vécu derrière cette réponse courte et consise!
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).
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.
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.
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.
Si tu le dis Jean-Marc !Ben, oui , et Grumff me connais bien, hein Florent ?
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.
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.
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).
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
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
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:
• Table des symboles,
• Table des mots réservés ,
• Pré analyseur syntaxique (PreParser),
• Analyseur syntaxico-sémantique (Parser),
• Producteur et optimlsateur de code,
• Relieur (Linker).
La machine virtuelle
• Exécuteur (player)
• Frameworks trappés. (On parle également de glue)
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:
• Table des symboles,
• Table des mots réservés ,
• Pré analyseur syntaxique (PreParser),
• Analyseur syntaxico-sémantique (Parser),
• Producteur et optimlsateur de code,
• Relieur (Linker).
La machine virtuelle
• Exécuteur (player)
• Frameworks trappés. (On parle également de glue)
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
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
