Discussion :

[DonQuiche]

a) (les substitutions sont de moi pour les besoins de la démonstration)

Après :
* "{le ramasse-miettes} n'a pas d'intérêt parce que ça ne me dérange pas d'écrire vingt lignes de plus"
* "bon ça a un intérêt mais {le ramasse-miettes} c'est un truc de chercheurs en décalage avec le monde réel"

Voici :
* "bon ça a un intérêt mais pas pour l'info de gestion"
* "de toute façon on s'en fout parce que c'est l'utilisateur qui compte". Parce que l'utilisateur se fiche bien de payer deux fois plus cher pour un logiciel bogué sous prétexte que l'équipe aime bien faire la gestion mémoire à la main parce que ça ne les dérange pas d'écrire vingt lignes de plus et parce que le ramasse-miettes est un truc de chercheurs déconnectés du monde réel sans intérêt pour l'info de gestion.

Cela dit, non, le GC n'est pas adapté à tout. Mais je parie qu'il est parfaitement adapté à tous les projets sur lesquels tu bosses de janvier à décembre.


b) Le typage dynamique n'est pas adapté aux gros et moyens projets et l'eau mouille. Quoiqu'en disent les adorateurs du typage dynamique et du dieu Pluie. Après je reconnais que la formulation était malheureuse : il y a aussi de petits projets dans nos entreprises, y compris chez Google.

Accessoirement le fait que je me ferais descendre sur le forum Python pour ces propos ne veut rien dire : ce serait le cas pour toute critique à l'encontre de tout langage de programmation, club de foot, parti politique ou religion. Je peux seulement espérer que les programmeurs sont moins prompts que les autres à vouloir égorger ces infidèles de Marseillais.


c) Le C# n'est tout simplement pas fait pour la programmation bas niveau, il a été fait pour les 90% de projets restants et c'est ce qui fait sa force.

Donc oui les pointeurs sont une blague en C# puisque tu ne peux avoir de pointeur que vers les rares types valeurs situés sur la pile ou dans un tableau préalablement épinglé (pinned). Les pointeurs ne servent peu ou prou qu'à l'interopérabilité avec le code natif.

Cela dit, non, le GC ne compacte que les pages managées. Si C# appelle une fonction C qui effectue un malloc, l'adresse fournie sera dans une page gérée par la biblio C et non par C#.


d) Eiffel est bien plus verbeux que Java, et un peu plus qu'Ada qui a échoué en dépit du soutien du gouvernement américain. Par ailleurs tout langage verbeux devrait aujourd'hui être à destination de la programmation robuste, ce qui nécessite bien davantage qu'une syntaxe verbeuse.


e) Je ne connais aucun langage miraculeux, il n'y en a jamais eu. En revanche je peux citer une dizaine de besoins avec pour chacun le ou les langages les mieux adaptés en 2015. Ce serait une liste restreinte mais sans surprise, sur laquelle ne figureraient ni Cobol ni Pascal, mais où l'on trouverait encore du C++, du Java, du C# et même cette daube de php, entre autres, mâtinés de solutions plus modernes (Chapel, Rust, Clojure par ex). Et j'ai bon espoir que d'ici dix ans plusieurs langages auront disparu de cette liste.

Plus intéressant, je sais quelles fonctionnalités deviennent indispensables, quelles approches deviennent obsolètes et quels nouveaux besoins apparaissent.

[e-ric]

Salut

@alheuredudejeuner : En tout cas félicitations, changer totalement de boulot c'est pas une décision simple et trouver du taf relève parfois du défi. Bienvenue dans cette petite communauté parfois un peu animée.

Cdlt

[e-ric]

@DonQuiche: Il n'est pire sourd que celui qui ne veut pas entendre.

Je pense que je vais écourter cette discussion qui est franchement stérile. Tel un cas pathologique, tu passes ton temps à déformer les propos de ceux qui te réponde de façon à justifier des thèses mal gaulées voire contradictoires.

Au final, si tu détiens la vérité pourquoi viens-tu prêcher vers des pauvres Pascaliens qui adorent se vautrer dans le péché ? Je ne parle même pas des pauvres Pythoniens qui eux aussi n'ont rien compris.

T'en rajoutes si tu veux après ce message, je ne pourrai pas répondre de toutes façons.

[naute]

Bonjour à tous,

j'ai tout lu... si si.
Je me suis cru un moment à Roland-Garros.

Merci à DonQuiche sans lequel cette belle partie n'aurait jamais eu lieu,

Ce serait une liste restreinte mais sans surprise, sur laquelle ne figureraient ni Cobol ni Pascal, mais où l'on trouverait encore du C++, du Java, du C# et même cette daube de php, entre autres, mâtinés de solutions plus modernes (Chapel, Rust, Clojure par ex). Et j'ai bon espoir que d'ici dix ans plusieurs langages auront disparu de cette liste.

et merci à lui de reconnaître implicitement qu'il aime, en fait, Cobol et Pascal, puisqu'il ne les inclut pas à la liste des langages qui, selon son souhait, auront disparu dans dix ans .

Je suis personnellement Pascalien depuis mes débuts, si l'on excepte le passage par le "Basic Level II" du TRS80, car, apprenant tout seul, la syntaxe du C me paraissait trop obscure en comparaison. Je ne suis absolument pas qualifié pour établir une comparaison entre les différents langages.

Je pense qu'une des raisons de la suprématie, en terme d'étendue, du monde C sur le monde Pascal tient plus à des raisons commerciales qu'à de vraies différences fonctionnelles. La gratuité et l'ouverture du code des compilateurs ainsi que des outils est apparue très tôt dans le monde C et très tard dans le monde Pascal, ce qui a freiné l'expansion et l'évolution de celui-ci. C'est du moins l'impression que j'ai.
A titre d'exemple, je ne suis pas sûr que PHP occuperait la place qu'il occupe s'il avait été payant.

Je suis pour que vive Pascal, mais je ne veux certainement pas la mort pour les autres langages.

En ce qui concerne le langage parlé, tout n'est pas exprimable dans tous les langages, ce qui conduit d'ailleurs à des emprunts utiles d'un langage à l'autre. "Cool" est peut-être un anglicisme, mais nous n'avons pas l'équivalent en France. De même que les anglais utilisent "rendez-vous" car rien n'a le même sens chez eux.
Un langage, à mon avis, est représentatif d'une certaine façon de penser, donc d'une culture, et sa disparition entraine la disparition de cette culture, ce qui, à mon sens, est dramatique.

J'imagine qu'on peut faire un parallèle avec les langages informatiques.

Cordialement, naute.

[skrink_skrink]

et un processeur donné! => C'est toujours des processeurs ARM ton code fonctionnera donc
sur tous les appareils, j'ai essayé DELPHI XE7 et DELPHI XE8, j'ai pu le vérifier.... Mais pour l'instant
je n'y ai pas encore trouvé d'avantage certain ou d'application pour laquelle ce serait mieux
qu'Android studio ou Eclipse

Mais dans l'avenir je ne sait pas....

Fonctionnera pas sur Intel....
N'utilise pas la framework mais l'embarque (NDK) car sous Android pas de DLL...
Bref, créer un exécutable avec delphi sous Android reviens à embarquer Android dans l'éxécutale (gestion des versions d'android....), c'est du simplement absurde.
(suffit de regarder la taille des applications générées) , on est loin des APK java!

Google laisse normalement cette possibilité pour le développement d'API ...

Sinon le langage Pascal est une racine et surtout la base de de nombreux autres langages :
Ada, Lua, Pascal Object , Oxygène, Langage normalisé d'automatisme ....
c'est certainement la deuxième plus grande branche derrière le C

Il ne faut pas confondre PASCAL et Delphi!

[Paul TOTH]

Fonctionnera pas sur Intel....
N'utilise pas la framework mais l'embarque (NDK) car sous Android pas de DLL...
Bref, créer un exécutable avec delphi sous Android reviens à embarquer Android dans l'éxécutale (gestion des versions d'android....), c'est du simplement absurde.
(suffit de regarder la taille des applications générées) , on est loin des APK java!

Google laisse normalement cette possibilité pour le développement d'API ...

Sinon le langage Pascal est une racine et surtout la base de de nombreux autres langages :
Ada, Lua, Pascal Object , Oxygène, Langage normalisé d'automatisme ....
c'est certainement la deuxième plus grande branche derrière le C

Il ne faut pas confondre PASCAL et Delphi!

non Delphi n'embarque pas Android dans l'executable

L'application Delphi est compilée sous forme de librarie (.so = les DLL de Linux/Android) et Delphi se charge de créer le bootstrap Java (Dalvik) pour la charger car il n'est pas possible de créer un APK 100% natif.

La taille des APK Delphi n'est pas liée à l'usage du NDK mais au framework Firemonkey qui implique un runtime assez imposant au départ...Après que l'application soit simple ou complexe, sa taille n'évoluera que progressivement.

Maintenant il est tout à fait possible de créer une application Android toute petite sous Delphi...mais ça implique de ne pas utilise Firemonkey, j'ai par exemple porté le CubeMan3D que j'ai réalisé sous FlashPascal sous Android, et le fichier APK généré par Delphi XE5 ne pèse que 825Kb.

EDIT: ne pas confondre Delphi et Firemonkey

[skrink_skrink]

Peut être effectivement si je n'utilise que peu de bibliothèque.
Maintenant si j'utilise la cam, maps, le téléphone, etc , je suis bien obligé de charger les bibliothèques ...
Plus une bibliothèque graphique en plus de celle d'Android .

Je pense que ce n'est pas dans la philosophie d'Android

Ce n'est pas moi qui le dit :

Before downloading the NDK, you should understand that the NDK will not benefit most apps. As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.

Et pourquoi ne pas faire comme Windev (et oui je sais !Windev! mais l'équipe Android tient bien le pavé)
et de donner la possibilité de générer une application utilisant le framework android.

Ne pas confondre EDI, langage et bibliothèque graphique.

[Paul TOTH]

Mais il est tout à fait possible d'utiliser le Framework Android, JNI est là pour ça.

Mais le but de Delphi n'est pas de développer pour Android ou OSX ou Windows ou iOS, mais bien de développer pour Android et OSX et Windows et IOS...ce qui implique de passer par une couche d'abstraction (FireMonkey) et non des solutions spécifiques à la plateforme

Quand Google précise que le NDK n'est pas forcément la meilleure solution, ils ont raison, la plupart des applications Android peuvent se contenter de Dalvik pour tourner sur tous les mobiles avec des performances raisonnables. Mais Dalvik implique est prévu pour un développement Java. Embarcadero aurait pu tenter de faire un Delphi pour Dalvik...mais quand on voit le succès de Delphi pour .Net qui était pourtant le langage .Net plus proche de sa version Windows...on peut avoir des doutes sur ce choix.

Si tu veux faire du Dalvik, tu prends Android Studio et Java, Google le dit lui même, vouloir faire du C++ n'est pas une bonne raison pour utiliser NDK (d'après eux), alors on pourrait dire que vouloir utiliser le langage Pascal n'est pas une bonne idée non plus...mais pour avoir testé le développement Java pour Android, je suis bien content de pouvoir utiliser Delphi