Discussion :

[skywaukers]

Donquiche a du mérite cependant d'avoir tenu ses propos sur ce forum qui est particulier en effet. J'aime me convaincre que les Pascaliens (les anciens) sont une communauté à part d'autant qu'ils sont toujours fidèles après si longtemps à ce langage. Cela dénote quand même un certain attachement.

Il a le mérite de déplacer un sujet factuel sur un terrain passionnel... Oui la communauté Pascalienne est attachée à ce langage. Mais peut-être faut-il se demander pourquoi plutôt que de les balayer en essayant de les catégoriser comme marginaux. Pour moi il y a des raisons qui ne sont peut-être pas les vôtres. La simplicité et la maintenabilité du code sont par exemple pour moi un gros critère d'attachement. La performance du code généré en est une autre. Et depuis quelques temps l'évolution du langage vers d'autres plates-forme s'ajoute à mes critères.

Cependant pour avoir migré sur d'autres plate-formes, je souscris partiellement à ce qu'il a écrit. Ailleurs, il y a d'autres approches, d'autres environnements qui font aussi bien que Delphi voire mieux dans son état d'avancement actuel. Il ne faut pas oublier que jusqu'aux dernières versions (XE), Delphi est resté immobile. Cela a un prix.

Bien sûr il a raison ! Comme dis plus haut il a établi la liste des critères qui selon lui définissait un langage adapté aux besoins actuels, et selon ses critères il a raison. Mais un trolleur qui viendrait affirmer des choses parfaitement fausses ne serait pas pris au sérieux (soit dit au passage il est loin de n'avoir affirmé que des choses vraie, et des lors qu'il tente de parler du Pascal il affiche clairement sa méconnaissance de ce langage, et montre par ailleurs sa connaissance d'autres technos).
Et oui aujourd’hui on paye l’immobilisme de Borland qui avait clairement laissé tomber Delphi. Et donc Embarcadero a eu un énorme travail à faire pour ramener Delphi au niveau où il se trouve aujourd’hui. Surement a-t-il encore au moins autant de travail à faire pour l’amener sur le devant de la scène, espérons que la progression de l’outil continue pour qu’ils aient les moyens de le faire.

Quant à l'annonce, je ne l'analyse pas. On énonce un fait mais je ne trouve pas les nombres. Il faut se méfier des taux de progression. Vous avez vendu 1000 licences. Vous en vendez une de plus. Vous progressez de 0,1%. Mais si vous n'avez vendu qu'une licence et que vous en vendez une autre, vous avez progressé de 100% ! Et on en déduit quoi... que d'un seul coup le deuxième produit bénéficie d'un essor fantastique, prometteur ?

Il est évident qu’on peut faire dire tout ce qu’on veut aux chiffres. Je pense aussi que si le Pascal a eu la plus grosse progression c’est qu’il avait la plus grosse marge de progression par rapport aux langages stars actuels. Mais tout de même on en déduit qu’il progresse, non ? Et si il progresse cela veut dire deux choses : qu’il n’est pas mort et qu’il répond suffisamment bien aux besoins actuels pour susciter l’intérêt de nouveaux adeptes. Je ne sais pas d’où sortent les chiffres, mais il semble aussi qu’Embarcadero a annoncé récemment une forte augmentation de son CA lié à la vente de Delphi, donc les informations semble se corroborer.

Ce qui me lasse également c'est de lire "Avec le Pascal tu peux développer pour Windows, MacOs, Linux ( Lazarus+Free pascal), Ios, Android, Google glass, Apple Watch, le web."

C'est une réplique de la documentation d'Embarcadero ! C'est un but ! "Mon" Delphi ne gère pas Linux... Mon XE7 ne le fait pas. Et les productions FMX sous mac OS X sont très loin de ce que l'on peut faire simplement en Qt. Quant à Androïd, tous les processeurs ne supportent pas les productions FMX. Je ne parle pas de ma version limitée de FastReport...

Bon, je ne vais pas faire mon trolleur de base en essayant de passer cela pour une attaque personnelle 
Mais quand même, pourquoi cela vous lasse ? Ai-je dis quelque chose de faux ? Le langage Pascal objet ne permet-il pas de faire tout cela ? Linux est encore un objectif pour Delphi oui (c’est bien pour cela que j’ai précisé Lazarus + Free pascal entre parenthèses). Mais pour le reste ? Alors encore une fois qu’il ne le fasse pas comme vous le voudriez, que d’autres le fasse mieux, personne ne dit le contraire et ce n’est pas le sujet.

Une fois ceci précisé, on attend la suite. Delphi doit encore progresser. Mais laisser à penser que ce que l'on fait en VCL est facile (ou même difficile) à obtenir en FMX (même sous Windows) est une... approximation.

Encore une évidence. Bien sûr que Delphi doit encore progresser, et le Pascal objet également (d’ailleurs le sujet n’est pas sur Delphi mais sur le Pascal objet…). Personne ne le conteste et même tout le monde l’espère. Après le reste n’est que littérature et l’esprit critique est une très bonne chose, lorsqu’il n’est pas employé juste dans un but trollesque.

[DonQuiche]

Pour la productivité, mon expérience fait que je suis beaucoup moins catégorique que toi sur la productivité des dev C# ou Java par rapport à Delphi...

Puisque tu connais C#, tu connais son "yield return" pour les itérateurs, tu connais linq, tu connais await. Tu sais parfaitement que chacun d'entre eux demanderait 10 à 50 fois plus de code pour être mis en oeuvre en Pascal, et parfois un code beaucoup plus compliqué !

Et tu sais aussi qu'aucun snippet ne t'aidera jamais sur ces parties. Et même pour les tâches où un snippet peut aider à l'écriture, ça n'apporte rien pour la lecture, le plus important (ou, pire, ça aide par automatisme mais on ne voit pas la modification sournoise qu'on y a placé).

PS : merci pour la réponse concernant le lambda.

Pas d'attaque personnelle de ma part, car on est encore libre de choisir, non ? Cependant, si je peux me permettre, la riposte est à la hauteur de l'arrogance de ton premier message

Il me semble que c'était bien une attaque personnelle.
Mais, peu importe, cela m'a donné l'occasion de m'expliquer sur un point qui semblait important : je ne savais pas que je postais dans le forum Delphi.

Par contre mon premier message n'était pas une attaque conte ceux qui utilisent Pascal mais contre ceux qui en font la promotion en prétendant que c'est un langage d'avenir. Et j'ai eu raison parce que c'est une voie sans issue et que je ne voudrais que des jeunes qui te lisent s'embringuent là-dedans.

1. Là, tu montres que tu as dû décrocher vers 2002-2004... et, sauf erreur de ma part, le comptage de références n'est pas un gage de modernité ni (surtout) d'efficacité : la chute des performances, les problèmes de circularité et la voracité en mémoire d'un tel mécanisme font qu'on s'oriente vers des solutions plus performantes.

2. L'argument ironique est malhonnête. Personne ici ne parle du Pascal de 1970. C'est un langage qui a beaucoup évolué et donné naissance à des avatars qui n'ont plus qu'un lointain lien de parenté avec leur ancêtre. Par analogie, c'est comme si tu mesurais le C# à partir du C++ pour l'assimiler au C né lui aussi vers 1970. Imagine donc un Pascal, un Pascal++ et un Pascal# : voilà, tu y es

3. Je ne regrette pas le passé, mais je n'encense pas le présent quand il se prétend notre futur On peut étaler des techniques tant que l'on veut, noyer son discours dans une ribambelle de termes ésotériques pour impressionner (qui sur ce site ?), il reste des réalités. PHP est-il le langage de programmation le plus évolué techniquement ? Tu admettras que non (en attendant sa prochaine version), mais il représente pourtant 80% du code des sites Internet. Le "retard technique" dont tu parles est extrêmement relatif dans un domaine qui cherche avant tout à produire : tu peux arriver avec la dernière des innovations, si tu es le seul à savoir la maîtriser, je me tournerais vers un groupe de programmeurs moins innovants mais plus efficaces et qui m'assureront un suivi pérenne. Libre à toi en revanche (et je le comprends) de vouloir être à la pointe du progrès pour une satisfaction toute personnelle.

a) L'absence de toute forme d'aide à la gestion mémoire est un gage d'ancienneté pour un langage. Et si le comptage de références a des problèmes, c'est également le cas de toutes les autres solutions (GC traçants à la Java ou preuves via le système de types à la Rust). Il n'y a pas de solution magique. Le mieux qu'on puisse faire aujourd'hui c'est de mêler analyse statique, comptage de références, pointeurs nus et GC traçants (déterministes ou non, compacteurs ou non). La bonne réponse dépend du langage.

b) Plutôt que de parler d'étiquettes, quelles sont d'après toi les qualités qui font que le Pascal resterait adapté à la prog système, et celles qui le rendraient adapté à l'applicatif ?

c) Oui, l'écosystème importe. Mais ce n'est pas un argument en faveur du Pascal : il y a cent fois plus de bibliothèques qui sortent chaque année pour dotnet, java ou C++ que pour Pascal. Et un choix beaucoup plus vaste d'outils de dév.

Vouloir enfermer le débat dans un carcan technique n'est pas non plus très honnête si tu fixes d'avance ce que tu considères comme les incontournables d'un langage moderne.

J'ai exprimé une opinion, pas fixé un carcan. Je suis las de ce procès permanent.

pour l'enseignement je choisirai non pas un langage à la mode mais plutôt un solide (j'ai pu voir les dégâts que peux faire un enseignement trop "riche" au détriment d'une bonne logique de base)

J'ai moi-même mentionné dès le départ l'adéquation de Pascal pour l'enseignement. Mais ma perspective est celle de l'industrie.

Le problème de cette renaissance de la reconnaissance du DRA, c'est que je ne connais aucun élève qui ne sache ce qu'est le DRA, ne sachant même pas que DRA signifie Développement Rapide d'Applications.

Le terme RAD est plus fréquemment employé.

Cela dit, je ne peux m'avancer catégoriquement, mais en termes de RAD je crois que Windev est bien plus avancé que Pascal : intégration des requêtes SQL dans le langage, interfaçage direct des formulaires avec la DB (databinding très simple, commit, etc), riche bibliothèque de composants métier (code-barres & co), etc. C'est un vrai outil de RAD, conçu dès le départ comme tel et ayant toujours avancé dans ce sens avec une évolution très cohérente.

A Donquiche, je rappellerai aussi que les nouveaux langages ne sortent pas du néant. Ils s'appuient, veulent corriger ou améliorer, d'anciennes approches. Et systématiquement, il faut faire des choix qui induisent des forces et des faiblesses.

Loin de moi l'idée de nier cela !

Non seulement j'ai beaucoup d'affection pour Pascal qui m'a aidé à faire mes premiers pas mais j'ai aussi beaucoup de respect pour son créateur qui était en avance sur son temps, a fait un très beau travail pour l'époque, et a posé les jalons d'une nouvelle syntaxe qui a ensuite donné naissance à Python.

Le développement logiciel progresse par étapes, les langages de programmation en particulier s'appuient tous sur les succès et erreurs de leurs prédécesseurs et Pascal a une place importante dans cette histoire.

Delphi est un vieux langage. Il a été laissé en déshérence par ses repreneurs successifs. Il a intégré des add-ons de manière plus ou moins heureuse et s'est remis en cause récemment. FireMonkey est la nouveauté pour les Pascaliens... Et des vieux comme moi en souffrent à comprendre les mécanismes. Mais son potentiel -celui de FMX- est impressionnant au point qu'à terme, je pense que Delphi fera aussi bien, même mieux, que Qt... s'il clarifie ses approches et les transmet de manière ordonnée aux développeurs qui l'utilisent.

Tu m'as donné envie d'aller voir ça. Malheureusement mes recherches pour "FMX Pascal" n'ont rien donné, que devrais-je chercher ou aurais-tu une url s'il te plaît ?

Et merci.

[SergioMaster]

Cela dit, je ne peux m'avancer catégoriquement, mais en termes de RAD je crois que Windev est bien plus avancé que Pascal : intégration des requêtes SQL dans le langage, interfaçage direct des formulaires avec la DB (databinding très simple, commit, etc), riche bibliothèque de composants métier (code-barres & co), etc. C'est un vrai outil de RAD, conçu dès le départ comme tel et ayant toujours avancé dans ce sens avec une évolution très cohérente.

encore une fois ne mélangeons pas Pascal le langage et les IDE permettant le RAD, même si ceux-ci sont de plus en plus liés . Quand on lit Pascal doit-on lire Delphi ou Lazarus ?

Tu m'as donné envie d'aller voir ça. Malheureusement mes recherches pour "FMX Pascal" n'ont rien donné, que devrais-je chercher ou aurais-tu une url s'il te plaît ?

il faut faire une recherche avec le terme Firemonkey (et accessoirement Delphi+Firemonkey) plutôt que FMX et la réponse devient tout de suite plus "ouverte" ou tout simplement télécharger la version d'évaluation de Delphi XE8 pour s'y frotter

[matthius]

Puisque tu connais C#, tu connais son "yield return" pour les itérateurs, tu connais linq, tu connais await. Tu sais parfaitement que chacun d'entre eux demanderait 10 à 50 fois plus de code pour être mis en oeuvre en Pascal, et parfois un code beaucoup plus compliqué !
Et merci.

L'objectif du langage Pascal n'était pas celui du C, à savoir écrire des sources les plus petites possibles.

L'objectif du langage Pascal est simple : Préparer au maximum la programmation pour gagner du temps. Cela n'implique dans ce langage de créer des sources petites, mais surtout de comprendre facilement à quoi elles servent. Je pense que cette démarche est la même pour faire comprendre la révolution des robots.

Ainsi la création du compilateur utilisant l'assembleur Virtual Pascal sur Linux et Windows changera sans doute le nom Lazarus Free Pascal. La question c'est quand ?

J'ai remarqué une facilité à anticiper avec le compilateur Pascal, que je n'ai retrouvé sur aucun autre outil de DRA. Aussi Lazarus est certes lent sous Windows, mais il démontre la rapidité et la puissance de Linux. Je préfère développer pour Delphi sous Linux avec Lazarus, pour 3 raisons :

1. La rapidité, la sécurité et la sûreté sont sur Linux.
2. Je préfère le classement des propriétés à la Lazarus et à la Delphi 7.
3. Je crois en l'avenir et au domaine public.

[Invité]

Bon, je ne vais pas faire mon trolleur de base en essayant de passer cela pour une attaque personnelle.
Mais quand même, pourquoi cela vous lasse ?

Bonjour,

Cela n'a rien de personnel, en effet, sinon je vous aurais cité directement. On se croise depuis assez longtemps sur les forums pour se connaître un peu.

C'est plutôt le discours officiel que je vise. Je connais l'importance de la publicité -et que les autres font pareil- mais j"apprécie réellement FMX, moins le discours officiel qui l'entoure et qui est censé le faire mieux vendre. J'ai eu du mal à adopter FMX, n'y comprenant rien au départ, mais un passage par Qt que j'ai finalement retenu, m'a permis de revenir sur ma position.

FMX, s'il dispose d'un potentiel réellement concurrentiel, est encore très (trop) difficilement exploitable si on le compare à son vénérable ancêtre (VCL) qui a rendu les Pascaliens exigeants.

Quand je lis la publicité et que je découvre l'existant, la plume du râleur que je suis le démange

Donc, cela me lasse pour 2 raisons :

• La publicité Embarcadero, je la lis et j'achète les versions assez régulièrement. Je prends des cas de figure usuels, pas un développement spécifique, et je compare la publicité à mes résultats :
  
  • Le dernier problème rencontré m'a poussé vers Unidac : Joindre à partir de FMX, une base de données Maria DB 5 hébergé sur un serveur Linux distant avec FireDac sur XE7 : le code fonctionne parfaitement en Win pas en Mac. Avec une solution Unidac, RAS. Et avec Qt (Win Linux et OS X) sur les mêmes machines: RAS. Donc en effet, il est "possible de ". Mais j'estime qu'on ne peut pas assimiler le fonctionnement de FMX sous Windows et FMX sous Mac OS X. Imaginez le temps perdu !
  • Autre problème récent (mais maintenant corrigé), le décalage des versions FastReport entre VCL et FMX. D'accord FastReport est un add-on "indépendant" mais il est fourni dans la distribution. Conclusion : jusqu'à un passé récent, je ne pouvais pas faire en FMX, ce que je fais en VCL. On ne peut pas parler d'équivalence des résultats. Je pouvais obtenir un meilleur résultat en Delphi VCL qu'en Delphi FMX Windows... Ce qui revient à considérer que si je développe avec pour cible du Desktop, je dois me contenter d'un résultat inférieur multi OS à ce que j'obtiendrais en cible Windows VCL. Je l'ai déjà écrit plusieurs fois, et c'est une vieille attitide des Delphistes (Windowsiens) à la base, que ce soit en Windows, Nux et mac OS X, je prétends au même niveau d'exigence de mes productions. Heureusement, la jeunesse arrive : ils vont bousculer tout cela !
  • Autre problème plus ancien, un programme FMX Androïd qu'un de mes élèves ne peut pas exploiter parce que sa Tablette Galaxy n'a pas le bon processeur... En effet, on peut développer des applications Androïd (même pour un néophyte comme moi en la matière) mais à la restriction près que certains processeurs (heureusement minoritaires) ne seront pas compatibles avec votre diffusion. Enfin cela passe mal.
  • Quant à Linux, les mots ont un sens. Cela a été annoncé, et cela figure dans aucun roadmap... On attend... Enfin on est à la version 8.
  • Le développement Web ? Je demandais encore récemment où on se procure la documentation pour utiliser HTML5 Builder, pas pour faire une esquisse de site, mais pour l'intégrer dans un vrai site et en faire la base de son développement ? C'est certainement faisable... mais je piétine... J'aimerais bien voir des sites d'envergure réalisés avec cet environnement.
    
• La deuxième raison de l'agacement est toute personnelle. Je développe en Delphi depuis des années. J'ai passé 4 ans avec Lazarus y compris à réparer des composants (enfin à les porter des fois même d'un environnement 32 à 64 bits... on en est là), j'ai développé des TStringGrids enrichies... et quand je lis et que des propos laissent supposer que c'est déjà incorporé dans l'IDE. Cet multiOS. Ce n'est pas parce qu'on peut afficher des Tlabels en Win32, Win64, Linux32, Linux64, Os X que l'environnement est multi-OS ! Il ne faudrait quand même abaisser le niveau d'exigence à ce point.

Je n'ai pas de leçon à donner. Et je m'en garderai bien. mais ici c'est un forum professionnel. Des gens comme Donquiche y ont leur place et l'argumentation ne doit pas être équivoque. Les mots ont un sens.... et les réalisations tout autant. FireMonkey est un produit à fort potentiel. Mais il n'est pas aussi universel qu'il est présenté. Si vous parlez d'un environnement vraiment multi-OS, je vous propose Qt 5. Et leur IDE fonctionne dans les 3 OS Desktop !
Si vous me parlez de développement Android, je trouve Delphi fabuleux dans son rapport avec mon niveau de connaissance mais il y a une restriction importante qui pour le moins n'est pas mise en évidence. Un "Javaïen Mobile" trouvera peut-être FMX totalement inadapté pour ses développements. Et son éclairage sera intéressant.
Si vous me parlez du développement Web ou de Linux, je demande à voir : Pour le premier un mode d'emploi et un site complet réalisé avec cet outil et pour le second le mention de son existence dans un roadmap d'Embarcadero.

Là mon agacement se résorbera. Ah non j'allais oublier : il me manque un contrat d'assistance professionnel comme on peut souscrire pour Qt...

[matthius]

Bonjour,[*]La deuxième raison de l'agacement est toute personnelle. Je développe en Delphi depuis des années. J'ai passé 4 ans avec Lazarus y compris à réparer des composants (enfin à les porter des fois même d'un environnement 32 à 64 bits... on en est là), j'ai développé des TStringGrids enrichies... et quand je lis et que des propos laissent supposer que c'est déjà incorporé dans l'IDE. Cet multiOS. Ce n'est pas parce qu'on peut afficher des Tlabels en Win32, Win64, Linux32, Linux64, Os X que l'environnement est mulit-OS !

Je comprends que l'informaticien s'intéresse à la valeur de ce qu'il crée.
Seulement le livre Robinson Crusoé vous explique qu'elle est due à la résistance à obtenir quelque chose. Selon cette explication, il y a là une grosse dérive du mot valeur. Dire "créer de la valeur" sans dire laquelle n'a aucun sens. Je ne sais pas à quoi ont servi vos TStringLists.

Aussi ce que j'ai remarqué chez ceux qui s'inspirent d'une démarche, c'est que le seul moyen pour eux de la comprendre est le dialogue, d'où la surveillance généralisée. Le problème de cette surveillance généralisée, c'est qu'il ne s'agit pas exactement d'avoir des idées, mais de résoudre le problème au moment où il arrive. Ça l'école ne l'apprend aucunement.

Je dis que je suis censuré. Seulement celui qui est censuré est connu dans les faits.

[gbegreg]

tu connais son "yield return" pour les itérateurs, tu connais linq, tu connais await. Tu sais parfaitement que chacun d'entre eux demanderait 10 à 50 fois plus de code pour être mis en oeuvre en Pascal, et parfois un code beaucoup plus compliqué !

Tu as des exemples de ce que tu avances ? moi oui :

Pour le yield, voici un exemple C# et Delphi désolé mais je le connais plus que Lazarus) pour comparer : http://www.gerixsoft.com/blog/delphi/yield
c'est vrai qu'il y a 10 à 50 fois plus de lignes en Pascal (l'unité System.Yield contient seulement une centaine de ligne, une fois ajoutée au projet on utilise yield comme en C#). C'est vrai par contre, en Pascal il faut déclarer ses variables dans var avant des les utiliser dans le code : ça rajoute des lignes et ça alourdi considérablement le code et sa compréhension

Pour linq : http://blog.devart.com/using-linq-in-entitydac.html

Pour await : http://www.thedelphigeek.com/2012/07...in-delphi.html

Les évolutions importantes, utiles et qui apportent réellement quelque chose (une réponse à un besoin fonctionnel, une simplification pour le développeur...) sont tôt ou tard reprises dans les autres langages. Rien n'est figé et tout évolue. C'est pour cela que dire que tel langage est plus productif qu'un autre ne me semble pas correct. Ce sont les outils, librairies, frameworks, api... qu'on utilise qui nous rendent plus productif à mon avis.

[Invité]

Je ne sais pas à quoi ont servi vos TStringLists.

Bonjour,

j'ai parfois du mal à suivre vos propos... sur les valeurs notamment. J'en reviens à des choses plus terre à terre. Vous m'en pardonnez, j'espère :

En réalité que savent faire les TStringGrids de Lazarus ou de Delphi VCL ? Beaucoup de choses potentiellement. Mais facilement ?

• Afficher le contenu d'un Tmemo en contrôlant l'affichage du multiligne (largeur fixe, hauteur calculée) ?
• Sélectionner des lignes discontinues (la 1ère et la 4ème) ?
• Permettre de stocker autre chose que des chaines C dans les cellules (Persistance d'images dans des cellules de StringGrid à partir d'un champ PostgreSQL.ByteA ou TEXT) ?
• Gérer le End-Ellipsis ?
• La coloration des lignes lors de leur survol ?
• L'intégration du tri (éventuellement multiple) au clic des entêtes ?
• L'intégration de champ de recherche dans les entêtes ?
• Des images en fond de ligne ?
• Déplacer des lignes à la souris ?

Vous trouverez sur le forum Lazarus mes nombreuses interventions sur ces sujets.

Dernière recherche : la gestion des champs HTML dans les StringGrids. J'ai un code fonctionnel en Windows... et j'ai abandonné en Nux faute de temps après y avoir consacré 2 semaines de vacances... Je sais les Profs sont toujours en vacances.

J'ai abandonné aussi parce que le code des TStringGrids est un patchwork de couches, de réparations, d'évolutions qui compliquent incroyablement le travail. J'avais demandé que le code soit réécrit pour être stabilisé parce que tout Lazarus est comme cela maintenant à force de courir... après quoi, je ne sais pas, puisque ce produit n'est pas commercial... Après l'évolution des OS peut-être. Quoique Windows, non , c'est le vieux Win32 depuis pfffffffffff; Mac OS non, il a été négligé au point que le "nouvel" interface graphique est en cours de développement. Reste Linux. Il est vrai qu'avec Ubuntu, les versions défilent. En tout cas, j'ai abandonné Lazarus parce que mon analyse est qu'avec un code rustiné ainsi, l'évolution des OS va distancer celle(s) de Lazarus. Le code est trop compliqué à maintenir. Combien de fois as-t-on vu des codes "réparés" retomber en panne quelques releases plus tard suite à une modification d'un autre code ?

Pour en revenir au TStringrids, vous savez tous ces trucs inutiles que l'on rencontre nulle part (mais qui sont intégrés d'origine dans VCL et Lazarus ) et que personne (les développeurs) ne demande visiblement mais qui sont quand même un peu utiles aux utilisateurs ! Vous savez ce que Donquiche appellerait Nouveauté (Evolution)... Pour Delphi, il y a heureusement TMS... Pour Lazarus ?

[skywaukers]

Ce n'est pas parce qu'on peut afficher des Tlabels en Win32, Win64, Linux32, Linux64, Os X que l'environnement est multi-OS ! Il ne faudrait quand même abaisser le niveau d'exigence à ce point.

Oui tu as raison, les mots ont un sens. En l’occurrence le sujet est sur le Pascal objet, pas sur l’IDE Delphi. Je déplore comme toi que l’environnement ne soit pas multi-plateforme (je crois d’ailleurs que c’est du à des mauvais choix de Borland qui avait incorporé des morceaux en dotnet dans l’IDE qui est [malheureusement] toujours la base de l’IDE actuel).
Après qu’Embarcadero tente de nous présenter leur produit comme le produit idéal, ça s’appelle du marketing, on ne peut pas les blâmer. Ils ne vont quand même pas mettre en avant les faiblesses de leur produit dans un argumentaire commercial. Ce qu’ils disent n’est pas faux en soit, c’est juste peut-être pas toujours aussi idyllique (existe-t-il quelque chose qui le soit réellement ?)

Je n'ai pas de leçon à donner. Et je m'en garderai bien. mais ici c'est un forum professionnel. Des gens comme Donquiche y ont leur place et l'argumentation ne doit pas être équivoque. Les mots ont un sens.... et les réalisations tout autant. FireMonkey est un produit à fort potentiel. Mais il n'est pas aussi universel qu'il est présenté. Si vous parlez d'un environnement vraiment multi-OS, je vous propose Qt 5. Et leur IDE fonctionne dans les 3 OS Desktop !

Oui, tout le monde a sa place ici, et heureusement. Mais on peut s’agacer aussi des gens qui viennent dans une discussion déplacer le sujet et se prétendre être la lumière qui vient guider les pauvres ignorants qui n’ont pas les mêmes visions qu’eux.
Qui peut prétendre ce que sera l’avenir ? L’histoire de l‘informatique a montrée à plusieurs reprises que les choses ne sont pas immuables (pour ne citer qu’un exemple probant, il fut un temps où aucun spécialiste se disant professionnel n’aurait misé un seul centime sur l’avenir d’Apple…).
Oui Delphi ne répond pas à certains critères proclamés vitaux par DonQuiche. Oui Delphi n’est pas autant idyllique que la plaquette commerciale tente de le dire. Mais non Delphi n’est pas mort, non ce n’est pas une technologie d’hier parce que même si sur des cas précis que tu cites la réalité n’est pas à la hauteur de la plaquette marketing, Delphi est bel et bien un produit professionnel qui permet de développer rapidement des applications multi-plates forme avec une base de code [presque] unique. Je dis presque parce qu’il existe des spécificités dans chaque plates-forme et qu’il faut donc bien en tenir compte dès lors qu’on veut développer autre chose qu’un petit formulaire composer de Label et de boutons.

Si vous me parlez du développement Web ou de Linux, je demande à voir : Pour le premier un mode d'emploi et un site complet réalisé avec cet outil et pour le second le mention de son existence dans un roadmap d'Embarcadero.

Je ne connais pas de site grand-public développé avec Delphi si c’est cela que vous attendez. D’ailleurs le principal problème de ce côté-là c’est le coût de l’hébergement, il est clair qu’on ne peut pas aller concurrencer des technos comme PHP sur ce trerrain.
Par contre je peux vous certifier que nous utilisons Delphi pour développer des applications web professionnelles et qu’il nous donne satisfaction que ce soit en terme de facilité de développement ou en terme de robustesse et de montée en charge des applications. Ce ne sont pas des applications grand-public, mais nous en avons qui ont plusieurs centaines d’utilisateurs. Et nous n’avons pas que de petits formulaires tout simple, nous avons des applications qui sont critiques dans notre process.

[matthius]

Tu as des exemples de ce que tu avances ? moi oui :
Les évolutions importantes, utiles et qui apportent réellement quelque chose (une réponse à un besoin fonctionnel, une simplification pour le développeur...) sont tôt ou tard reprises dans les autres langages. Rien n'est figé et tout évolue. C'est pour cela que dire que tel langage est plus productif qu'un autre ne me semble pas correcte. Ce sont les outils, librairies, frameworks, api... qu'on utilise qui nous rendent plus productif à mon avis.

J'ai effectivement constaté de plus en plus de dérives spéculatives.
Pour les informaticiens, il est souvent difficile de comprendre qu'un savoir-faire sert à gagner du temps. À la cantine numérique il y a eu toutes sortes d'explications montrant qu'ils croyaient que ça servait à complexifier le logiciel.

La démarche de Virtual Pascal est simple : Simplifier ce qui est le plus souvent répété pour gagner le plus de temps possible. Je mets au défi beaucoup de langages sur ce point.

En effet la javaisation de Delphi a été incorporée en partie sur Free Pascal. La réflexion était simple :*seul ce qui était utile a été incorporé à Free Pascal. Je pense à la sémantique des listes, qui permet effectivement de gagner du temps. Le reste pour moi était du marketing servant à flouter l'utilisation d'un langage. S'il y a autant d'incompréhension sur Delphi, en voici une explication.

Pour les logiciels libres, j'ai aussi constaté un récent début de dérives. En effet, Open Shot Vidéo était très intéressant au début, ce qu'il n'est possible de faire qu'avec un existant. Seulement KDE N Live a toujours été plus rapide. La question est : N'était-il pas plus simple pour l'informaticien d'Open Shot de participer à KDE N Live, au lieu de créer un logiciel plus lent en Python ?

[super_navide]

voilà du n'importe quoi , le Pascal Objet un langage d'avenir......

Voilà les langages d'avenir :

Java
Javascript
C#

et puis c tout ......

[matthius]

voilà du n'importe quoi , le Pascal Objet un langage d'avenir......

Voilà les langages d'avenir :

Java
Javascript
C#

et puis c tout ......

La question qui tue : Pourquoi ?

[Invité]

En l’occurrence le sujet est sur le Pascal objet, pas sur l’IDE Delphi.
Mais on peut s’agacer aussi des gens qui viennent dans une discussion déplacer le sujet et se prétendre être la lumière qui vient guider les pauvres ignorants qui n’ont pas les mêmes visions qu’eux.
Qui peut prétendre ce que sera l’avenir ?

• Le Pascal Objet n'est pas grand chose sans Delphi (ou Lazarus). Vous utilisez un simple éditeur de textes pour faire vos programmes et un compilateur. C'est en mode console alors ?
  Vous croyez réellement que l'étude a porté sur l'usage du Pascal Objet comme je viens de le décrire ?
  
• Si à chaque fois que des gens vous contredisent, vous les qualifiez comme se prétendant être la lumière, la discussion n'ira pas loin. Il est inadmissible de dévaloriser un contradicteur même si cette vieille figure et manière de rhétorique est un peu... ancienne et très pratiquée dans d'autres sphères ! Le discours de Donquiche est recevable, argumenté donc sensé. Celui de Super_Navide demande à l'être... documenté. Mais effectivement, je connais des programmeurs Java très proches et j'ai vu des applications dont l'ergonomie m'a laissé pantois. Je ne sais pas si je pourrais les imiter avec Delphi.
  
• Prétendre connaître l'avenir, non mais le supputer oui. Cela peut être utile notamment pour un développeur professionnel et anticiper le besoin de ses clients. Ne serait-ce que pour revenir à l'article initial et se faire une idée de sa pertinence.

Bon je décroche. Bonne fin de WE à tous.

[skywaukers]

La question qui tue : Pourquoi ?

parce que

[skywaukers]

[LIST]

[*]Si à chaque fois que des gens vous contredisent, vous les qualifiez comme se prétendant être la lumière, la discussion n'ira pas loin. Il est inadmissible de dévaloriser un contradicteur même si cette vieille figure et manière de rhétorique est un peu... ancienne et très pratiquée dans d'autres sphères ! Le discours de Donquiche est recevable, argumenté donc sensé. Celui de Super_Navide demande à l'être... documenté. Mais effectivement, je connais des programmeurs Java très proches et j'ai vu des applications dont l'ergonomie m'a laissé pantois. Je ne sais pas si je pourrais les imiter avec Delphi.

Je ne parlais pas de vous, vos critiques sont argumentées, mais de DonQuiche qui est venu avec un argumentaire très peu technique (rapprochement Delphi-Cobol, vieux langage = vieille techno) et qui dit venir combattre ceux qui n'ont pas cet avis pour éviter que les jeunes aillent dans le mur. C'est cela que je qualifie ainsi. Après il a argumenté certaines chose, dit d'autres choses fausse parce que visiblement il ne connaît pas tant que ça le Pascal objet d'aujourd'hui.
Après lorsque les arguments sont concrets, au contraire la discussion peut aller loin.

Apres pour revenir à l'article, il est factuel non ? Il y a progression du pascal objet c'est un fait. Après il ne dit pas qu'il vaut mieux apprendre le pascal objet que le Java ou le C# ou le PHP, ça ce sont quelques uns ici qui ont modifié le sujet. Par contre effectivement si le langage a progresser, alors un professionnel a plus de chance de le rencontrer qu'avant, il peut donc être intéressant pour lui de se pencher dessus.
Après les supputations.....

bon weekend
Dany

[matthius]

parce que

Le C permet de créer le plus vite possible des sources rapides avec le moins de savoir-faire possible. On utilise alors l'assembleur pour finaliser ce qui a été fait.

Le problème du C c'est qu'il n'est pas objet, donc pas DRA. Je n'arrive toujours pas à comprendre ces rites du meilleur éditeur de texte non EDI. On y discute souvent de leur capacité à devenir des EDI. Le C a un avantage : Il est le langage rêvé pour les aveugles. Un aveugle m'a dit qu'il comprenait la logique des EDI de DRA. Du coup je ne m'intéresse plus à regarder les éditeurs de texte "améliorés".

La richesse de Javascript c'est la capacité à l'oublier. C'est un langage à typage dynamique. Je comprends le questionnement de l'informaticien quand il panique en ne sachant pas à quoi il a à faire. Être réellement sûr de soi sur un langage permet d'éveiller ses sens pour s'améliorer ailleurs.

Le C# a été créé avec un informaticien de Borland. Je ne sais toujours pas ce qui le démarque, mis à part qu'on dit qu'il y a de la beauté dans certaines trouvailles, sans que j'en connaisse la finalité.

[Andnotor]

...

Vraiment une très bonne nouvelle

[gvasseur58]

Par contre mon premier message n'était pas une attaque conte ceux qui utilisent Pascal mais contre ceux qui en font la promotion en prétendant que c'est un langage d'avenir. Et j'ai eu raison parce que c'est une voie sans issue et que je ne voudrais que des jeunes qui te lisent s'embringuent là-dedans.

Bonjour,

Voilà une base de discussion plus saine Même si je ne partage pas totalement le second aspect sur le "langage d'avenir" qui tiendrait à des limitations techniques alors que l'écosystème que tu reprends à juste titre, mais en le minimisant, est d'après moi prépondérant.

Pour la partie technique, à titre d'information (y compris pour les delphistes), voici un extrait de la table des matières provisoire (et dans le désordre) du prochain livre de Nick Hodges (auteur de Coding in Delphi) :

• Before we start : Encapsulation - Coupling – Cohesion Command/Query Separation - Postel’s Law - Composition Over Inheritance
  
• Adapter Patterns
  
• Command pattern
  
• Decorator pattern
  
• Duck typing
  
• Aspect Oriented Programming
  
• Model-View-ViewModel
• Parallel Programming
• Parallel `For` Loops
• Multi-Threading and Parallelism
• Observer Pattern
• Operator Overloading
• Writing SOLID Code

Je précise qu'il s'agit d'un livre qui s'adressera aux programmeurs non experts mais désireux de progresser. Il complète un premier tome qui s'intéressait notamment à : Generics, Interfaces, Exception Handling, Anonymous Methods, Collections, RTTI, Enumerators, Attributes, Dependency Injection and Unit Testing. Est-ce que l'énumération de ces sujets mérite un haussement d'épaules accompagné d'un "trop trivial", "dépassé", "archaïque" ?

Pour l'aspect bibliothèques disponibles, l'argument des très nombreuses productions (en C++ surtout) ne tient qu'à moitié : sans compter les productions propres dont certaines sont très performantes (TMS, TRichView, EnVision, Esbpcs...) , des wrappers existent pratiquement pour tout ce qu'on veut. Je ne connais pas une application qu'on ne peut pas écrire avec Delphi. En revanche, je le déconseillerais pour du non applicatif, c'est sûr.

Du point de vue commercial, il y a un gros problème quasi-insoluble pour Embarcadero qui reste la locomotive du développement en Pascal via Delphi : à vouloir développer un outil multiplateforme (ou presque), il lui faut sans cesse courir après les nouvelles règles que fixent les développeurs d'OS (par exemple, Apple interdit l'accès de sa boutique aux apps ne fournissent pas de version 64 bits, d'où le travail prioritaire de la compilation 64 bits avec iOS), au risque de lasser des clients en proposant deux versions par an . De plus, Embarcadero vit du développement alors que Microsoft peut se permettre une gratuité toute relative. Enfin, last but not least, les choix d'Embarcadero sont discutables : vouloir privilégier le tout pro (quand on vient leur raconter que Pascal n'a rien à faire dans une entreprise, ça les énerve un peu ), c'est aussi se priver d'un vivier considérable qui venait des universités, des amateurs et même des blogueurs en tous genres. Personnellement, je ne vois pas comment, Embarcadero peut lutter à terme, que ce soit avec du Pascal ou tout autre langage d'ailleurs, sauf à proposer des produits exceptionnels (ce qui n'a pas toujours été le cas).

A titre récréatif, je tiens beaucoup à Lazarus : s'il est loin d'égaler son grand frère et s'il ne répond pas aux exigences que tu as exprimées à plusieurs reprises, il progresse vite - mais est-ce assez vite ? D'autres développements sont (peut-être) à suivre : Smart Mobile Studio propose un Pascal pour générer du Javascript (applications HTML5) sans s'appuyer sur un serveur. A tous deux, il manque une solide base de développement de bibliothèques : Lazarus est sur la bonne voie, mais le chemin est encore long ; Smart Mobile Studio doit se faire une place dans un marché saturé...

En bref, il me semble qu'un définitif "jeunes, passez, il n'y a rien à voir" est trop catégorique. Pascal a pris des formes diverses, s'est enrichi, a progressé et reculé, comme tout ce qui existe finalement. Il disparaîtra un jour, mais son enterrement précipité me fait sourire : je me souviens de l'enterrement d'Apple vers la fin des années 90 et de l'enthousiasme un peu avant pour Prolog qui, selon ses adeptes, allait révolutionner la programmation... En fait, si (comme tu le suggères), Pascal devait être cantonné à un langage d'apprentissage, je le préfèrerais à d'autres réputés faciles mais qui poussent à la "faute" (je pense à PHP, par exemple), et encore à d'autres qui n'incitent pas à écrire du code lisible et réutilisable quand il est confié à des programmeurs qui travaillent à l'abattage (je pense au C, C++...). Je place Java à part, car il attire souvent des programmeurs soucieux de la qualité du code : l'investissement en formation est si lourd qu'il exclut les pressés Mais cette position est toute personnelle. Pour avoir comme toi souvent changé de langage de programmation, j'ai toujours trouvé Pascal particulièrement intéressant : exigeant mais lisible, explicite mais pas trop bavard, rigoureux sans excès (sauf dérapage à coups de variants). Rien de parfait, mais quelque chose que je n'ai pas retrouvé ailleurs (c'était la minute nostalgie ). Quand je relis du code C que j'ai écrit il y a quinze ans, je ne me comprends pas toujours . Et je ne parle pas du Forth

Bon, je ne sais toujours pas ce que tu pratiques comme langage en ce moment. Je pencherais pour Java ou C#, je me trompe ?

[Michel]

En réalité, ces statistiques mesurent la demande des entreprises.
Cela peut simplement signifier qu'un certain nombre d'entreprises qui ont utilisé des applications développées en Delphi il y a quelques années doivent les mettre à jour et cherchent des personnes capables de les aider.
Cela ne nous dit rien sur le nombres d'applications réellement écrites en pascal.
Pour le reste j'aimerais vous inviter à relire les commentaires en remplaçant le mot pascal par langage C!
C'est amusant, le nombre d'arguments qui pourraient s'appliquer aux deux !

[matthius]

En réalité, ces statistiques mesurent la demande des entreprises.
Pour le reste j'aimerais vous inviter à relire les commentaires en remplaçant le mot pascal par langage C!
C'est amusant, le nombre d'arguments qui pourraient s'appliquer aux deux !

Je suis d'accord avec cet argument. Seulement une entreprise s'entretenait régulièrement avec moi pour m'indiquer que le choix de C++ Builder était une erreur.

Ma réflexion est que le langage Pascal permet de se concentrer plus facilement sur les Composants DRA. D'une part il y a sa capacité à trouver plus facilement les bugs, sans parler de la problématique Free Pascal. D'autre part l'algorithmique Pascal m'a permis d'être très performant sur l'objet par les Composants DRA. En effet, je n'ai effectivement eu qu'à me concentrer sur cette problématique, tout en créant mes Frameworks et Ancestromania. Avoir peu de problèmes répétés permet une meilleure intuition pour mieux évoluer.