Discussion :

[pprem]

Et d'ailleurs n'oublions pas que ce potentiel regain d'intérêt risque d'entrainer une arrivée de nouveaux développeurs et de curieux du Pascal alors attendez-vous tous à plein de questions et de besoins de formation ou de tutoriels à jour.

[Paul TOTH]

Et concernant les particuliers, c'est bien les revenus liés à la vente ou l'utilisation des logiciels développés sous Delphi qui est à prendre en compte. Le salaire de la personne ne rentre pas en ligne de compte tant qu'il ne provient pas d'une activité de développement faite avec une licence personnelle de Delphi.

Ce n'est pas ce que je lis moi

In the event Licensee has obtained a Delphi Community Edition or a C++Builder Community Edition license (collectively, the "Community Edition") the following terms apply in addition to the General Terms described in Section 2 above. Please note that RAD Studio is not offered and may not be licensed as a Community Edition. The Community Edition license applies solely if Licensee cumulative annual revenue (of the for-profit organization, the government entity or the individual developer) or any donations (of the non-profit organization) does not exceed USD $5,000.00 (or the equivalent in other currencies) (the "Threshold"). If Licensee is an individual developer, the revenue of all contract work performed by developer in one calendar year may not exceed the Threshold (whether or not the Community Edition is used for all projects). For example, a developer who receives payment of $5,000.00 for a single project (or more than $5,000.00 for multiple projects) even if such engagements do not anticipate the use of the Community Edition, is not allowed to use the Community Edition. In addition, a developer building solely an app store application would not be allowed to use the Community Edition once the app store revenue reaches a revenue of $5,000.00 or more in a year. If Licensee is a company that has a cumulative annual revenue which exceeds the Threshold, then Licensee is not allowed to use the Community Edition, regardless if the Community Edition is used solely to write applications for the business' internal use or is seen by third parties outside the company or has a direct revenue associated with it.

ce qui donne en français par Google Translate

Si le Titulaire de la licence a obtenu une licence Delphi Community Edition ou une licence C ++ Builder Community Edition (collectivement, la «Community Edition»), les conditions suivantes s'appliquent en plus des Conditions générales décrites dans la Section 2 ci-dessus. Veuillez noter que RAD Studio n'est pas proposé et ne peut pas être sous licence en tant qu'édition communautaire. La licence Édition Communautaire s'applique uniquement si les revenus annuels cumulés du Licencié (de l'organisation à but lucratif, de l'entité gouvernementale ou du développeur individuel) ou des dons (de l'organisation à but non lucratif) n'excèdent pas 5 000 USD (ou l'équivalent dans d'autres devises) ) (le seuil"). Si le Licencié est un développeur individuel, le revenu de tous les travaux contractuels réalisés par le développeur au cours d'une année civile ne peut pas dépasser le seuil (que l'édition communautaire soit utilisée ou non pour tous les projets). Par exemple, un développeur qui reçoit un paiement de 5 000,00 $ pour un seul projet (ou plus de 5 000,00 $ pour plusieurs projets) même si ces engagements ne prévoient pas l'utilisation de l'édition communautaire, n'est pas autorisé à utiliser l'édition communautaire. En outre, un développeur qui crée uniquement une application de magasin d'applications ne sera pas autorisé à utiliser l'édition communautaire une fois que les revenus de l'application auront atteint un chiffre d'affaires de 5 000,00 $ ou plus au cours d'une année. Si le licencié est une société dont le revenu annuel cumulé dépasse le seuil, le licencié n'est pas autorisé à utiliser l'édition communautaire, même si l'édition communautaire est utilisée uniquement pour écrire des applications à usage interne ou est vue par des tiers en dehors de la société ou a un revenu direct associé à celui-ci.

[alheuredudejeuner]

Bonjour

c'est une bonne nouvelle pour la pérennité de notre outil.

Et je payerai avec beaucoup de plaisir ma version pro MAJ annuelle.

Il me reste au moins un fantasme a réaliser.

Quand j'arrive chez le client, je trouverai cool d'avoir une casquette ou un tshirt Delphi, histoire d'être identifié comme dev Delphi.

Cordialement

André

[tlt]

bonne nouvelle, mais ça arrive un peu tard. ça va être galère de trouver des tutos à jour

[SergioMaster]

Bonjour

ça va être galère de trouver des tutos à jour

Au temps pour nos efforts
Il faut simplement que d'avantage de personnes se lancent dans la rédaction (c'est pas aussi compliqué que l'on croit) ou ne serait-ce que propose des sujets !
En fait, il ne manque pas de tutoriels mais il faut être multilingue l'anglais bien sûr mais aussi l'espagnol, le portugais etc. et avoir du temps !

[Invité]

Super !


Je me demande juste comment vont évoluer les arguments des détracteurs, dont l'absence d'une telle version était la rengaine favorite...

Bonjour,

en préliminaire, j'apprécie peu le mot "rengaine". Le vocabulaire me semble peu adapté. Je préfèrerais "contradiction". Je sais bien que je suis sur un forum Delphi. J'ai toujours apprécié de pouvoir m'y prononcer librement... et votre formulation me semble à vocation dissuasive (de manière consciente ou non).

Alors la rengaine. Le problème se situe (au moins) à 5 niveaux :

1. le prix... pour la découverte : ok c'est partiellement résolu.
2. l'ouverture du code tant que l'on ne dispose pas des éléments suffisants pour travailler dans des conditions satisfaisantes : quoiqu'en dise Sergio, dériver les Custom est un enfer. Il faut tout deviner dès que l'on sort des sentiers battus.
3. on pourrait également évoquer le debuggage en cross-compilation pas exempt de reproches
4. les capacités : je reste sur mon exemple de la réalisation d'une petite radioweb sans l'utilisation de bibliothèques étrangères, c'est la cata malgré mes nombreuses recherches. En élargissant, sans les composants TMS et autres on serait encore au moyen âge... Une Grid ou un TreeView gérant le HTML et les images encodées en base 64, cela se fait "à la main" en Qt. Evidemment, il faut chercher, mais les "briques" permettant de réaliser le composant et la structure, l'architecture des composants permettent cette prouesses assez facilement finalement. Pour avoir réalisé la même choses en Lazarus -je ne me suis même pas aventuré en FireMonkey- c'est possible mais la structure fait qu'a l'arrivée l'ensemble est lent à la réactualisation et malheureusement, il n'y a pas moyen de l'améliorer.
5. les restrictions de la techno : par exemple, le livebinding obligatoire pour le remplissage de dbGrid (une cata en vitesse), la gestion des streams (idem), la gestion des styles (pfff....) pour finalement quelque chose que l'on faisait aussi bien en programmation "classique".

Bref, Lazarus est un vrai Delphi celui qui a fait la renommée à juste titre du Pascal Objet; Qt est une vraie plateforme généraliste, peut-être moins assistée, mais beaucoup plus polyvalente que FireMonkey, aussi "géniale" dns une autre approche... quant à Delphi VCL c'est le passé, et tout ce qui a fait son succès, rapidité, solidité, simplicité, un caractère généraliste et une capacité à permettre de développer des composants adaptés à chaque situation... ont disparu ou ont été dilués dans un fatras de nouvelles approches (acquisitions) dont on aurait ps se passer ou du moins dont on aurait pu permettre une approche différente avec le même produit. FireMonkey ne donne aucun choix : pourquoi suis-je obliger de choisir le livebinding pour accéder aux données alors que le dataset était largement satisfaisant et même plus performant, pourquoi suis-je obligé d'utiliser les styles alors que la programmation permettait auparavant de régler cette problématique par programmation directement dans le code ? Delphi pourrait maintenant être gratuit, je limiterais quand même son usage... à ma seule curiosité.

Enfin, quand je vois la mousse 3D de Firemonkey, on fait cela aussi bien en Qt... sans pseudo-émerveillement sur le forum. J'espère que ce n'est pas le point d'accroche de cet environnement même s'il est souvent mis en exergue : ce n'est que l'avatar de VGScene tout simplement, rien d'historiquement propre à Delphi, hormis le rachat du produit et son intégration (portage ?) dans ce "dernier". Finalement, Toulourou, c'est assez facile de rester un détracteur quand on a été un vieil amoureux et utilisateur de Delphi VCL qui me conviendrait parfaitement, si il permettait de développer en Linux et mac OS (voire en Androïd et iOS). C'était faisable puisque Lazarus à maintenu une approche VCL même si malheureusement cette équipe manque cruellement de moyens et pour eux, je ne serai pas un détracteur : ils font ce qu'ils peuvent en gardant le génie de Delphi 7 avec leurs moyens insuffisants. A mon sens, Embarcadero aurait mieux fait de racheter Lazarus

A bientôt. Gilles

[yvslms]

trop tard en effet, le mal est fait et les autres ont pris la place.

Mais non c'est pas trop tard !!
RAD reste sans équivalent en terme de productivité et facilité d'utilisation notamment pour le développement mobile - bien loin devant Xamarin, Qt et les autres...
Et avec deux langages parfaitement complémentaires : Delphi et C++.
Reste un effort à faire sur les nouvelles technos RX, 3D... mais cela devrait bouger maintenant.

[Invité]

RAD reste sans équivalent en terme de productivité et facilité d'utilisation notamment pour le développement mobile - bien loin devant Xamarin, Qt et les autres...
Et avec deux langages parfaitement complémentaires : Delphi et C++.
Reste un effort à faire sur les nouvelles technos RX, 3D... mais cela devrait bouger maintenant.

OK une approche mobile donc. Firemonkey compile "aussi" pour MacOS, évidemment pour Windows et, dans une certaine mesure, pour Linux, vous l'oubliez ! A mon sens, pour le mobile, soit vous prenez Java et les produits Apple si vous voulez développer "à la main"... et vous avez tous les possibles ouverts, soit vous prenez un RAD limité par nature : j'utilise Windev Mobile (et Windev aussi d'ailleurs) pour "maquetter" notamment l'ergonomie.

Mais vous avez raison : votre approche est effectivement celle que je perçois d'Embarcadero. Je ne cherche pas un RAD et j'ai bien pris conscience au fil des versions que Delphi m'échappait. Voila pourquoi je me suis tourné vers Qt pour le développement Desktop multi-OS.

Cordialement. Gilles

[Roland Chastain]

Excellente nouvelle.

Deux petites questions. Peut-on compiler par ligne de commande ? Pourquoi le compilateur seul n'est-il pas gratuit comme le compilateur C++ ?

[Papy214]

Excellente nouvelle.

Deux petites questions. Peut-on compiler par ligne de commande ? Pourquoi le compilateur seul n'est-il pas gratuit comme le compilateur C++ ?

Excellente question ! Certains composants risquent de ne pas pouvoir s'installer sans la compilation de ligne de commande.

[ManyTwo]

(Je précise c'est une vrai question, pas un rhétorique hein)


Quels seraient selon vous les avantages de Delphi sur des languages concurrents? Quels sont les intérêts d'utiliser Delphi (et le Pascal objet) plutôt qu'un autre language plus "courant"?

Je m'explique, Delphi (enfin pascal) est un language généraliste, qui n'est pas hyper spécialisé (donc qui justifierait un marché de niche avec peu de concurrents).
Pour moi il vise les mêmes développement que des projets en c++, en c# ou en java (entre autres)

J'essai de lister quels sont les points déterminants dans le choix d'un language généraliste, orienté autours de Delphi et les concurrents possibles, si vous pouvez rajouter/donner votre avis:

Facilité d'utilisation du language

Delphi est très verbeux, ce qui est un + ou un - selon les gens. C# ou Java sont denvenu des classiques, donc beaucoup de gens sont à l'aise avec leur "formalisme".
-> Le "style" d'un language ne doit pas etre un argument primordial, mais si cela peut simplifier le dev/maintenance. C'est vraiment sujet à la préférence personnelle.

Fonctionnalités de l'EDI

Je n'ai pas utilisé les toutes dernières versions de Delphi, mais il me semble que toutes les fonctionnalités requises pour la plupart des développeurs d'application sont présentes.
Par contre, les fonctionnalités avancées (pas forcément utilisées par une majorité) sont moindre qu'un Visual studio par exemple (Debug multi process, profiling direct, live unit test etc).
Beaucoup moins d'extensibilité: Les plugins tierces sont légion sur Eclipse et visual studio par exemple.

-> l'Edi fonctionne bien dans un cadre "standard". Il devient plus limité face aux EDI plus populaires, car beaucoup plus de cas spécifiques sont couverts par l'extensibilité offert par des tiers.
-> Pas de "Bonus" particulier a utiliser delphi par rapport a un concurrent

Stabilité de l'EDI

Delphi a longtemps eu une réputation de faible stabilité, mais cela à l'air d'être de moins en moins le cas, et certains concurrents sont dans le même cas.

-> Pas de "Bonus" particulier a utiliser Delphi par rapport a un concurrent

Disponibilité des ressources tiers

Comparé a des languages plus répandus, il y a de facto moins de composants tiers, de projets open source, de support offert sur ce language (exemple: un web service qui fournirait ses api dans différent languages, Pascal n'y est pas souvent pas.). GetIt comparé aux autres Gestionnaires de packages est assez peu fournit.
Les éditeurs de composants sont plus restreint, ceci dit il y a de très bonnes suites de composants.

-> Pas de bonus particulier a utiliser Delphi

Performances et pertinences des technologies utilisées

Par exemple Vcl et Firemonkey. Si on compare ces technos à leur équivalent .net (WinForm et WPF), je pense qu'elles n'ont pas a rougir. pour moi la différence se ferai plus au niveau précédent, les ressources tiers disponibles.
Un avantage pourrait être qu'il y a moins de dépendances à gérer et une portabilité plus simple (les versions de .net par exemple, pas toujours évident à gérer sur un ciblage large des versions windows).

la gestion mémoire manuelle et la compilation en langage machine (pas d'IL) est censé offrir les performances du c++. Cependant dans beaucoup de projet, les performances de c# ou java suffisent largement pour s'éviter la complexité de la gestion mémoire. Ou sinon, c++ est la norme.

-> Si l'ont a besoin de performances quelles sont les raisons selon vous d'utiliser Pascal au lieu de c++?
Sinon pourquoi utiliser Delphi au lieu de languages managés? La portabilité?

Communauté

Les ressources offertes par la communauté (tutoriels, blogs, code , solution aux problèmes (stackoverflow par exemple) est pour moi un coté non négligeable. ce la permet de gagner un temps considérable, de mettre des "cerveaux en commun".
Le but n'est pas de reprendre bêtement du code trouvé sur un forum sans comprendre ce qu'il fait soyons d'accord.
Forcément les languages plus populaires ont une plus grande communauté et les ressources qui vont avec.

-> Pas de "Bonus" à utiliser Delphi

Ressources humaines disponibles pour les entreprises

Commencer des nouveaux projets a longue durée de vie en Delphi dans des entreprises implique d'avoir des gens disponibles sur le marché, à un cout raisonnable. Ce qui est de mmoins en moins le cas. Et c'est également un argument "secondaire" mais de poids non négligeable pour la pérennité de Delphi dans le monde pro..


C'est vrai que ici je fais un peu "détracteur", mais justement c'est pour demander l'avis de gens plus spécialisés en Delphi que moi. Quels sont les atouts qui ferait choisir Delphi (Pascal) plutôt que du c#, Java ou c++ notament?
Est ce que Delphi en tant que language généraliste a vraiment un avenir? le marché n'est-il pas déjà bien pris par des acteurs majeurs? Delphi devrait-il chercher à se spécialiser plus pour être un produit de niche? ou se focaliser par exemple sur le développement avec leur techno prometteuse mais peu répandue?

[jackk]

Mais non c'est pas trop tard !!

C'est tout ce que je lui souhaite. J'ai accompagné Borland depuis Turbo Pascal sous CP/M sur un APPLE II jusqu'à ce que les versions gratuites (limitées, mais c'est normal) disparaissent, c'est pour dire si j'aimais.
Depuis tout s'est délité et je ne vois pas trop ce qui va permettre de remonter la pente. Qu'est-ce que DELPHI/C++ Builder apporte de plus que Qt ou Visual Studio et ses Winforms?

[ShaiLeTroll]

Ressources humaines disponibles pour les entreprises

Commencer des nouveaux projets a longue durée de vie en Delphi dans des entreprises implique d'avoir des gens disponibles sur le marché, à un cout raisonnable. Ce qui est de moins en moins le cas. Et c'est également un argument "secondaire" mais de poids non négligeable pour la pérennité de Delphi dans le monde pro..

Pour le vivre chez mon employeur où l'ERP maison en Delphi devrait céder sa place définitivement en 2021 à SAP, je peux te dire que je connais bien cet argument, il est totalement vrai en France.
Actuellement, je ne cherche pas vraiment ailleurs mais si je vois une annonce en C++ acceptant un profil de niveau intermédiaire sur Paris Intra-Muros, je tente ma chance car pour le moment, le marché de l'emploi en Delphi est quasiment mort (saturé effectivement de SSII et dans des secteurs fonctionnels qui m'ennuient).

Je fais du Delphi depuis ma première semaine d'apprentissage, soit Octobre 1999, j'ai un emploi, j'ai encore à apprendre énormément sur le langage et ses bibliothèques (pas l'occasion du FMX même si cela m'intéresse)
Demain, si je trouve un emploi en Delphi (en 10, surtout pas en 7), C++ ou Java dans un domaine industriel ... je capitaliserais mon expérience POO en Delphi (que j'ai déjà appliqué au PHP 5.2/Zend 1.5 en 2010 et j'ai surpris les développeurs expérimentés en PHP par ma vision de l'objet bien plus aboutie qu'ils en savaient)

demander l'avis de gens plus spécialisés en Delphi que moi

Tu comprends avec ce que j'ai écrit ci-dessus, l'avis de ce gens va être biaisé vu que beaucoup pratique depuis dix, quinze ou vingt ans.
Ils sont tellement à l'aise avec l'outil, certains sont très doués car ont appris à faire par eux-mêmes les choses sans dépendre d'un tiers.

L'orientation actuelle de Delphi, FMX, DataSnap, ...
c'est dans le bon sens, même si il y a de la concurrence, ce n'est pas un problème,
cela ne peut que créer de l'émulation et des nouvelles idées qui seront reprises par l'un ou par l'autre.
Vous chercher l'opposition entre les technologies, je ne suis pas sûr que cela soit le bon esprit,
certains aimeront QT, d'autres aimeront C# ou Delphi, juste parce qu'ils se sentent plus à l'aise avec l'un que l'autre.

Et puis, tout ce que j'ai appris à l'école ... à part l'assembleur ou la récursivité, je dirais que le niveau n'avait rien d'extraordinaire,
j'ai appris bien plus en 2mois d'entreprise que 2ans à l'école... et j'ai fait 3ans en apprentissage,
lorsque j'ai eu mes premiers cours de Delphi (en licence) pour utiliser un objet Tortue et que le Prof est devenu mon Tuteur en cours d'année et a découvert que je faisais un pilotage de robot, du multi-thread, TCP\IP, DB ... il a mieux compris pourquoi, j'allais au bureau au lieu de ses TP.

[yvslms]

Depuis tout s'est délité et je ne vois pas trop ce qui va permettre de remonter la pente. Qu'est-ce que DELPHI/C++ Builder apporte de plus que Qt ou Visual Studio et ses Winforms?

Est-il possible de compiler une appli Visual Studio / Winforms à partir du même code sous iOS, Android, MacOs ?

[Anselme45]

Je suis depuis longtemps critique face à la politique menée par les différents proprio de l'EDI C++ Builder et Delphi, mais je dois avouer qu'à la lecture de la plupart des commentaires de ce forum, on se croit au bal des "mal-baisés" et des "mécontents de tout"!

Pour une fois qu'une décision de l'éditeur va dans le bon sens, je trouve particulièrement désagréable de voir une pléthore de mecs critiquer la mesure en disant des "c'est trop tard", "cela sert à rien"... Sans pour autant proposer des idées pouvant permettre la pérennité de la solution.

On a bien compris que beaucoup ont abandonné Delphi (ou se sont sentis abandonné par Delphi) et qu'ils gardent une "dent" contre Delphi. Cela peut se comprendre, mais est-ce bien utile d'étaler ses humeurs alors que l'on n'utilise plus Delphi depuis des décennies?

Perso, je me félicite de cette décision... J'espère que cela puisse rajeunir la communauté des utilisateurs...

PS: En technologie, rien n'est définitif! Pour ceux qui croient Java gravé à tout jamais dans le développement logiciel... Attendez de voir l'évolution futur de ce langage avec la nouvelle politique d'Oracle destinée à en faire une usine à fric... Il ne serait pas impossible que Java rejoignent le Fortran dans le musée des langues disparues...

[Invité]

Est-il possible de compiler une appli Visual Studio / Winforms à partir du même code sous iOS, Android, MacOs ?

A mon sens, cela n'a pratiquement aucune utilité au niveau du développement. Hormis avec Nougat, Androïd ne peut pas afficher nativement deux fenêtres simultanément à l’écran. Vous acceptez une telle limitation sous Linux, Windows ou MacOS lorsque vous réalisez vos programmes ? Donc par nature l'approche est différente. Bon d'accord pour afficher "Hello Word", le même programme devrait être compatible.

En plus, si vous voulez aller "au fond des choses" avec FireMonkey sous Android, vous serez obligé d'utiliser des bibliothèques Java (RAD Studio intégrées pour Android) qui n'ont évidemment aucune utilité pour un développement desktop.

Vu comme cela évidemment, je peux comprendre que Firemonkey ait un grand intérêt. Intérêt que je conteste... tout aussi évidemment.

Cordialement. Gilles

[Paul TOTH]

(Je précise c'est une vrai question, pas un rhétorique hein)


Quels seraient selon vous les avantages de Delphi sur des languages concurrents? Quels sont les intérêts d'utiliser Delphi (et le Pascal objet) plutôt qu'un autre language plus "courant"?

Je m'explique, Delphi (enfin pascal) est un language généraliste, qui n'est pas hyper spécialisé (donc qui justifierait un marché de niche avec peu de concurrents).
Pour moi il vise les mêmes développement que des projets en c++, en c# ou en java (entre autres)

J'essai de lister quels sont les points déterminants dans le choix d'un language généraliste, orienté autours de Delphi et les concurrents possibles, si vous pouvez rajouter/donner votre avis:

Facilité d'utilisation du language

Delphi est très verbeux, ce qui est un + ou un - selon les gens. C# ou Java sont denvenu des classiques, donc beaucoup de gens sont à l'aise avec leur "formalisme".
-> Le "style" d'un language ne doit pas etre un argument primordial, mais si cela peut simplifier le dev/maintenance. C'est vraiment sujet à la préférence personnelle.

Delphi n'est pas verbeux, il est structuré, comme je suis un développeur structuré, mes codes C++ ne sont pas moins longs que mes codes Delphi, si ce n'est que {} prend moins de place que begin/end

Fonctionnalités de l'EDI

Je n'ai pas utilisé les toutes dernières versions de Delphi, mais il me semble que toutes les fonctionnalités requises pour la plupart des développeurs d'application sont présentes.
Par contre, les fonctionnalités avancées (pas forcément utilisées par une majorité) sont moindre qu'un Visual studio par exemple (Debug multi process, profiling direct, live unit test etc).
Beaucoup moins d'extensibilité: Les plugins tierces sont légion sur Eclipse et visual studio par exemple.

-> l'Edi fonctionne bien dans un cadre "standard". Il devient plus limité face aux EDI plus populaires, car beaucoup plus de cas spécifiques sont couverts par l'extensibilité offert par des tiers.
-> Pas de "Bonus" particulier a utiliser delphi par rapport a un concurrent

sur le traitement du code, Delphi n'est pas l'IDE le plus évolué, mais pour ce qui est de l'intégration des composants visuels je pense qu'il est parmi les plus efficace.

Stabilité de l'EDI

Delphi a longtemps eu une réputation de faible stabilité, mais cela à l'air d'être de moins en moins le cas, et certains concurrents sont dans le même cas.

-> Pas de "Bonus" particulier a utiliser Delphi par rapport a un concurrent

Disponibilité des ressources tiers

je pousse depuis des années pour que la stabilité du produit soit une priorité...mais commercialement il est difficile de vendre une nouvelle version pour sa stabilité, donc les efforts sont plus souvent mis sur les nouveautés et/ou les évolutions rendues obligatoires par des impératifs externes (abandon du 32bits par Apple par exemple)

Comparé a des languages plus répandus, il y a de facto moins de composants tiers, de projets open source, de support offert sur ce language (exemple: un web service qui fournirait ses api dans différent languages, Pascal n'y est pas souvent pas.). GetIt comparé aux autres Gestionnaires de packages est assez peu fournit.
Les éditeurs de composants sont plus restreint, ceci dit il y a de très bonnes suites de composants.

-> Pas de bonus particulier a utiliser Delphi

il y a beaucoup de composants Delphi, il est vrai que l'offre OpenSource a baissé par rapport à la grande époque ou a migré vers FreePascal, du coup on trouve plutôt des solutions payantes

par contre je trouve sous Delphi bien plus souvent des solutions qui s'intègre dans le code de façon légère et efficace...j'ai développé dernièrement un produit qui fait concurrence à un autre. Le mien est un exécutable autonome de 5Mo, le concurrent installe 316 fichiers dans 28 dossier pour un total de 120Mo On y trouve du MSVC*.DLL, du QT*.DLL et tout un tas de fichiers liés...c'est un choix

Performances et pertinences des technologies utilisées

Par exemple Vcl et Firemonkey. Si on compare ces technos à leur équivalent .net (WinForm et WPF), je pense qu'elles n'ont pas a rougir. pour moi la différence se ferai plus au niveau précédent, les ressources tiers disponibles.
Un avantage pourrait être qu'il y a moins de dépendances à gérer et une portabilité plus simple (les versions de .net par exemple, pas toujours évident à gérer sur un ciblage large des versions windows).

la gestion mémoire manuelle et la compilation en langage machine (pas d'IL) est censé offrir les performances du c++. Cependant dans beaucoup de projet, les performances de c# ou java suffisent largement pour s'éviter la complexité de la gestion mémoire. Ou sinon, c++ est la norme.

-> Si l'ont a besoin de performances quelles sont les raisons selon vous d'utiliser Pascal au lieu de c++?
Sinon pourquoi utiliser Delphi au lieu de languages managés? La portabilité?

je n'ai jamais trouvé qu'il était compliqué de gérer la vie des objets de mes produits, notamment avec le principe de "owner" et "parent" dans composants de la VCL (ou de FMX) qui font que le cycle de vie de "composants" et totalement transparent.

les langages managés, y compris Delphi pour Linux et Mobile (iOS, Android) qui utilise l'ARC, apporte tout un tas de contraintes de programmation liées à ce modèle; cela impose une bonne connaissance des weak reference si on ne veux pas plomber sa mémoire...Et je trouve tout cela beaucoup plus difficile à debuguer personnellement.

Communauté

Les ressources offertes par la communauté (tutoriels, blogs, code , solution aux problèmes (stackoverflow par exemple) est pour moi un coté non négligeable. ce la permet de gagner un temps considérable, de mettre des "cerveaux en commun".
Le but n'est pas de reprendre bêtement du code trouvé sur un forum sans comprendre ce qu'il fait soyons d'accord.
Forcément les languages plus populaires ont une plus grande communauté et les ressources qui vont avec.

-> Pas de "Bonus" à utiliser Delphi

Developpez.com a commencé sont existence avec Delphi il est vrai que les temps ont changés, mais c'est la question de la poule et de l'oeuf entre la taille de la communauté et la popularité du produit...mais il y a 20 ans on disait de Delphi que ce n'était pas un produit pour vrai développeurs car les purs et durs font du C++...je crois que C++ a perdu aussi un peu de sa superbe, mais je suis de toute façon pour la diversité.

Ressources humaines disponibles pour les entreprises

Commencer des nouveaux projets a longue durée de vie en Delphi dans des entreprises implique d'avoir des gens disponibles sur le marché, à un cout raisonnable. Ce qui est de mmoins en moins le cas. Et c'est également un argument "secondaire" mais de poids non négligeable pour la pérennité de Delphi dans le monde pro..

un coût raisonnable...de nos jours ça veux dire payé au lance-pierre...je gagne ma vie aujourd'hui avec du développement Delphi, si demain je passais sur un autre langage, je ne changerais pas pour autant mes tarifs, c'est ma compétence et mon expérience qui font mon tarif, pas mon outil de programmation je facture d'ailleurs au même tarif les développements PHP/MySQL et Delphi.

C'est vrai que ici je fais un peu "détracteur", mais justement c'est pour demander l'avis de gens plus spécialisés en Delphi que moi. Quels sont les atouts qui ferait choisir Delphi (Pascal) plutôt que du c#, Java ou c++ notament?
Est ce que Delphi en tant que language généraliste a vraiment un avenir? le marché n'est-il pas déjà bien pris par des acteurs majeurs? Delphi devrait-il chercher à se spécialiser plus pour être un produit de niche? ou se focaliser par exemple sur le développement avec leur techno prometteuse mais peu répandue?

comme dit plus haut, je suis pour la diversité, je pense qu'aucun langage ne répond à toutes les problématiques et que ce choix dépend beaucoup plus du contexte que d'un préjugé quelconque sur les qualités intrinsèques du produit. Il m'est arrivé de développer en LotusScript car la messagerie était Lotus Notes, en C car la plateforme était du WinCE, en Java avant que JS ne permette de faire des pages complexes,.... et à chaque fois, la solution a été efficace car adaptée au besoin.

[philnext]

(Je précise c'est une vrai question, pas un rhétorique hein)


Quels seraient selon vous les avantages de Delphi sur des languages concurrents? Quels sont les intérêts d'utiliser Delphi (et le Pascal objet) plutôt qu'un autre language plus "courant"?

Je m'explique, Delphi (enfin pascal) est un language généraliste, qui n'est pas hyper spécialisé (donc qui justifierait un marché de niche avec peu de concurrents).
Pour moi il vise les mêmes développement que des projets en c++, en c# ou en java (entre autres)

J'essai de lister quels sont les points déterminants dans le choix d'un language généraliste, orienté autours de Delphi et les concurrents possibles, si vous pouvez rajouter/donner votre avis:

En tout cas tu poses la bonne question.

Facilité d'utilisation du language

Delphi est très verbeux, ce qui est un + ou un - selon les gens. C# ou Java sont denvenu des classiques, donc beaucoup de gens sont à l'aise avec leur "formalisme".
-> Le "style" d'un language ne doit pas etre un argument primordial, mais si cela peut simplifier le dev/maintenance. C'est vraiment sujet à la préférence personnelle.

Comme tu dis une question de préférence personnelle. Dans le genre ma préférence va à Python.
Mais fondamentalement je ne crois pas, au moins pour les langages cités que ce point soit une différence.

Fonctionnalités de l'EDI

Je n'ai pas utilisé les toutes dernières versions de Delphi, mais il me semble que toutes les fonctionnalités requises pour la plupart des développeurs d'application sont présentes.
Par contre, les fonctionnalités avancées (pas forcément utilisées par une majorité) sont moindre qu'un Visual studio par exemple (Debug multi process, profiling direct, live unit test etc).
Beaucoup moins d'extensibilité: Les plugins tierces sont légion sur Eclipse et visual studio par exemple.

-> l'Edi fonctionne bien dans un cadre "standard". Il devient plus limité face aux EDI plus populaires, car beaucoup plus de cas spécifiques sont couverts par l'extensibilité offert par des tiers.
-> Pas de "Bonus" particulier a utiliser delphi par rapport a un concurrent

En fait je pense qu'aujourd'hui, et c'est pour ça que je l'utilise encore, Delphi a la meilleure productivité dès que l'on fait du visuel, surtout multi-plateforme.

Stabilité de l'EDI

Delphi a longtemps eu une réputation de faible stabilité, mais cela à l'air d'être de moins en moins le cas, et certains concurrents sont dans le même cas.

-> Pas de "Bonus" particulier a utiliser Delphi par rapport a un concurrent

Oui on est d'accord.

Disponibilité des ressources tiers

Comparé a des languages plus répandus, il y a de facto moins de composants tiers, de projets open source, de support offert sur ce language (exemple: un web service qui fournirait ses api dans différent languages, Pascal n'y est pas souvent pas.). GetIt comparé aux autres Gestionnaires de packages est assez peu fournit.
Les éditeurs de composants sont plus restreint, ceci dit il y a de très bonnes suites de composants.

-> Pas de bonus particulier a utiliser Delphi

Oui même si, avec Delphi on trouve toujours des solutions, souvent de bonne qualité, le choix est bien moins important et donc génère moins de ressources qualitatives que d'autres langages. De plus les langages nativement open source (ou passé en open source) produisent nativement des produits tiers open source donc plus accessibles financièrement et modifiables.

Performances et pertinences des technologies utilisées

Par exemple Vcl et Firemonkey. Si on compare ces technos à leur équivalent .net (WinForm et WPF), je pense qu'elles n'ont pas a rougir. pour moi la différence se ferai plus au niveau précédent, les ressources tiers disponibles.
Un avantage pourrait être qu'il y a moins de dépendances à gérer et une portabilité plus simple (les versions de .net par exemple, pas toujours évident à gérer sur un ciblage large des versions windows).

la gestion mémoire manuelle et la compilation en langage machine (pas d'IL) est censé offrir les performances du c++. Cependant dans beaucoup de projet, les performances de c# ou java suffisent largement pour s'éviter la complexité de la gestion mémoire. Ou sinon, c++ est la norme.

-> Si l'ont a besoin de performances quelles sont les raisons selon vous d'utiliser Pascal au lieu de c++?
Sinon pourquoi utiliser Delphi au lieu de languages managés? La portabilité?

Oui en perf. la valeur ajoutée de Delphi par rapport à C++ n'est pas déterminante.

Communauté

Les ressources offertes par la communauté (tutoriels, blogs, code , solution aux problèmes (stackoverflow par exemple) est pour moi un coté non négligeable. ce la permet de gagner un temps considérable, de mettre des "cerveaux en commun".
Le but n'est pas de reprendre bêtement du code trouvé sur un forum sans comprendre ce qu'il fait soyons d'accord.
Forcément les languages plus populaires ont une plus grande communauté et les ressources qui vont avec.

-> Pas de "Bonus" à utiliser Delphi

Ressources humaines disponibles pour les entreprises

Commencer des nouveaux projets a longue durée de vie en Delphi dans des entreprises implique d'avoir des gens disponibles sur le marché, à un cout raisonnable. Ce qui est de mmoins en moins le cas. Et c'est également un argument "secondaire" mais de poids non négligeable pour la pérennité de Delphi dans le monde pro..


C'est vrai que ici je fais un peu "détracteur", mais justement c'est pour demander l'avis de gens plus spécialisés en Delphi que moi. Quels sont les atouts qui ferait choisir Delphi (Pascal) plutôt que du c#, Java ou c++ notament?
Est ce que Delphi en tant que language généraliste a vraiment un avenir? le marché n'est-il pas déjà bien pris par des acteurs majeurs? Delphi devrait-il chercher à se spécialiser plus pour être un produit de niche? ou se focaliser par exemple sur le développement avec leur techno prometteuse mais peu répandue?

Globalement ton analyse est bonne et tes arguments pertinents.
Néanmoins j'utilise Delphi, pour certains logiciels, donc pourquoi ?
Principalement par ce qu'il est plus productif (du moins pour moi) pour les dev. avec interface (hors Web, bien sûr) et que la productivité c'est la base pour un dev.

[sergio_is_back]

Delphi n'est pas verbeux, il est structuré, comme je suis un développeur structuré, mes codes C++ ne sont pas moins longs que mes codes Delphi, si ce n'est que {} prend moins de place que begin/end

Je suis du même avis, la bonne structuration du Pascal en fait un langage agréable à écrire et à maintenir

sur le traitement du code, Delphi n'est pas l'IDE le plus évolué, mais pour ce qui est de l'intégration des composants visuels je pense qu'il est parmi les plus efficace.

Pour avoir utilisé NetBeans, Visual Studio, (Même un peu de Windev), Eclipse, etc... Delphi est le plus agréable et plus efficace en ce qui concerne le design d'interfaces graphiques...

il y a beaucoup de composants Delphi, il est vrai que l'offre OpenSource a baissé par rapport à la grande époque ou a migré vers FreePascal, du coup on trouve plutôt des solutions payantes

par contre je trouve sous Delphi bien plus souvent des solutions qui s'intègre dans le code de façon légère et efficace...j'ai développé dernièrement un produit qui fait concurrence à un autre. Le mien est un exécutable autonome de 5Mo, le concurrent installe 316 fichiers dans 28 dossier pour un total de 120Mo On y trouve du MSVC*.DLL, du QT*.DLL et tout un tas de fichiers liés...c'est un choix

Il y a même tellement de composants et de bibliothèques disponibles (gratuits ou payants... au choix de chacun) qu'après plus de 20 ans de Delphi j'ai par encore fait le tour de tout ce qui existe... Les ressources ne manquent pas, il faut juste savoir ce que l'on cherche...

A noter que beaucoup de sources FreePascal sont compatibles avec Delphi, la plupart des packages sont développés avec les directives de compilation
ha-doc pour que Delphi puisse les utiliser sans problème.

[yvslms]

A mon sens, cela n'a pratiquement aucune utilité au niveau du développement. Hormis avec Nougat, Androïd ne peut pas afficher nativement deux fenêtres simultanément à l’écran. Vous acceptez une telle limitation sous Linux, Windows ou MacOS lorsque vous réalisez vos programmes ? Donc par nature l'approche est différente. Bon d'accord pour afficher "Hello Word", le même programme devrait être compatible.

En plus, si vous voulez aller "au fond des choses" avec FireMonkey sous Android, vous serez obligé d'utiliser des bibliothèques Java (RAD Studio intégrées pour Android) qui n'ont évidemment aucune utilité pour un développement desktop.

Vu comme cela évidemment, je peux comprendre que Firemonkey ait un grand intérêt. Intérêt que je conteste... tout aussi évidemment.

Cordialement. Gilles

C'est une question d'usage.
En ce qui me concerne le gain de productivité est du simple au triple et ce n'est pas faute d'avoir été voir ailleurs.
Bien sûr on ne conçoit pas une appli desktop comme une appli mobile et c'est justement là que FMX est intéressant (peu importe le langage - perso je travaille en C++), à partir d'un même projet on gère très rapidement et facilement les spécificités propres à chaque plateforme à partir du même code sans avoir à gérer une multitude de modules. Par exp. l'utilisation des bibliothèques Java sous Android est totalement transparente dans le code - juste un paramétrage dans les options une fois pour toutes.... Idem pour les autres. Quand on voit comment cela se passe ailleurs c'est tout simplement époustouflant.
A ma connaissance le seul outil qui offre une philosophie et une productivité aussi avancée est Unity (mais totalement fermé et spécialisé en 3D en C# avec l'EDI de Visual).
Reste encore pour Embarcadero un assez gros travail d'optimisation.
Cela viendra à partir du moment ou les utilisateurs sont au rdv.
Maintenant Embarcadreo semble vouloir s'en donner les moyens.

Bien cordialement