Que penses-tu de Julia (https://julialang.org/) ? Il est encore récent mais hormis le point a, il se défend sur tous les autres points.Citation:
Envoyé par wolinn
Version imprimable
Que penses-tu de Julia (https://julialang.org/) ? Il est encore récent mais hormis le point a, il se défend sur tous les autres points.Citation:
Envoyé par wolinn
Pas vraiment d'avis pour l'instant. Comme ce langage est très récent, on a pas non plus beaucoup de visibilité sur g.Citation:
Envoyé par SimonDecoline
Est-ce que ça va se développer, au point d'être adopté par des éditeurs de logiciel, ou va-t-il rester confiné à quelques universités, passer par un maximum de popularité dans quelques années, avant de décroitre et être remplacé par autre chose ? Ecrira-t-on toujours des compilateurs de ce langage dans 20 ans ?
Pour un industriel/éditeur de logiciel, c'est peut-être intéressant à évaluer, mais dans quelques années.
Ok, effectivement on y verra plus clair dans quelques années.Citation:
Envoyé par wolinn
Côté industriel, ça commence a bouger un peu (https://juliacomputing.com), et côté compilateur le fait d'utiliser llvm facilite un peu la pérennité.
Tu n'es pas très perspicace. Il y a un indice dans mon avatar, et un autre beaucoup plus clair dans ma signature.Citation:
Envoyé par thierryc
Non, heureusement.Citation:
N'y a-t-il que C comme compilateur disponible pour cet OS?
A peu près tous les langages existants sont disponibles.Citation:
Les applications n'y sont-elles développées qu'en C? Quels sont les autres langages disponibles?
Je faisais référence au support. J'ai suivi un lien que tu as mis dans ta réponse et Free Pascal ne fait pas partie des OS supportés, il y a bien une version bêta mais on sent qu'elle a des problèmes et que les développeurs de Free Pascal ne sont pas intéressés par mon OS.
Il serait probablement aussi économique à long terme de se débarrasser du français, de l'anglais, de l'espagnol, de l'allemand, etc. pour tous se mettre à l'espéranto...Citation:
Je reconnais bien volontiers que le C/C++/Java en legacy doit être maintenu , mais qu'on doit s'en débarasser dès que c'est économique de le faire (et c'est rapidement économique).
Un article très intéressant sur la complexité des architectures logicielles aujourd'hui et notre limite intellectuelle à les comprendre et les maîtriser.
http://internetactu.blog.lemonde.fr/...programmation/
c'est certain que c, c++ a encore de beau jour devant eux, mais dans des marchés de plus en plus de niche.Citation:
Envoyé par epsilon68
le nombre d'emploi le démontre bien.
article très intéressant, tel que dit dans l'article nombreux outil existe mais ils ne sont pas utilisés.Citation:
Envoyé par zecreator
après certes il y a des systèmes avec des millions de lignes de codes... mais je ne crois pas que la majorité soit emmené à travaillé sur de tel logiciel, surtout avec différents outils qui permet de limiter le nombre de ligne de code qu'on doit taper.
Je lis :Citation:
Envoyé par thierrycPeux-tu être plus précis, s'il te plaît? J'ai utilisé le Français que langue de programmation, aussi le vocabulaire des opérations apparaît en français...Citation:
Envoyé par Pyramidev
Par exemple, SetRectification1990, c'est spécifique au français. L'inconvénient que TOutilConversionEnglishBritish en dérive est que cela complexifie la compréhension de la classe TOutilConversionEnglishBritish, surtout si on veut réutiliser cette dernière dans un autre programme où il n'y a pas de case à cocher « Appliquer rectifications de 1990 ».Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32TOutilConversionAbstrait = class( TInterfacedObject, IOutilNombreCardinauxOrdinaux) private FLeNombreEntier: TEntierBorneParle; FOptions: TOptions; FRectification1990: Boolean; FtypeNombre: TTypeNombre; protected fLangue : TNomLangue; procedure DecomposerNombre( unEntier : TEntierBorneParle; out lUnite: TUnites; out laDizaine: TDizaines); virtual; procedure SetLeNombreEntier(AValue: TEntierBorneParle); virtual; procedure SetOptions(AValue: TOptions); virtual; procedure SetRectification1990(AValue: Boolean); virtual; procedure SetTypeNombre(AValue: TTypeNombre); virtual; function ConstruireListeOptionsTexte( desOptions: TOptions) : string; function isOptionInList( const uneOption: string; const desOptions: TOptions): boolean; public property TypeNombre: TTypeNombre read FTypeNombre write SetTypeNombre; property LeNombreEntier: TEntierBorneParle read FLeNombreEntier write SetLeNombreEntier; property Rectification1990: Boolean read FRectification1990 write SetRectification1990; property Options: TOptions read FOptions write SetOptions; constructor Create; virtual; function GetLangue: TNomLangue; property Langue: TNomLangue read GetLangue; // à surcharger: class function NomLangue: TNomLangue; virtual; function GetAvailableOptions: String; virtual; function Convertir( unEntier: TEntierBorneParle; ordinalOuCardinal: TTypeNombre; appliquerRectificationsDe1990: Boolean; autresOptions: TOptions) : TNombreEnChaine; virtual; end;
Si on veut que le code soit réutilisable, ce n'est pas une affaire de goût, mais de dépendances :Citation:
Envoyé par thierrycCe n'est qu'une affaire de goût, comme tu l'écris toi-même. De toutes manières, toute cette partie est invisible de l'extérieur, puisqu'il n'y a qu'une interface.Citation:
Envoyé par Pyramidev
- Chaque fois qu'on ajoutera une méthode publique dans TOutilConversionEnglishBritish, cela ajoutera automatiquement cette méthode dans TOutilConversionEnglishAmerican, avec une visibilité publique.
- Chaque fois qu'on modifiera la signature d'une méthode publique dans TOutilConversionEnglishBritish, ce changement s'appliquera aussi dans TOutilConversionEnglishAmerican.
- Le jour où on voudra retirer cette relation d'héritage, il faudra espérer qu'aucun utilisateur n'a eu l'idée de l'utiliser pour faire du polymorphisme, avec des adresses de type TOutilConversionEnglishBritish qui pointent parfois vers des objets de type TOutilConversionEnglishBritish et d'autres fois vers des objets de type TOutilConversionEnglishAmerican.
La composition permet d'éviter ce genre de dépendance.
Le code que tu as écrit est lisible par les développeurs qui connaissent la POO, même par moi qui n'ai jamais appris le Pascal. Par contre, les utilisateurs finaux, à moins qu'ils soient développeurs, j'en doute fort.Citation:
Envoyé par thierryc
Tu as raison bien sûr, sur la forme. L'ajout de langues étrangères nécessite un peu de reconstruction (aka "refactoring"). Sur le fond, cela n'a aucune importance car toutes les classes que tu commentes sont des classes dans des paquetages d'implémentation. Cachés. L'impact sur le reste du projet est nul. Si j'ai le temps, je reconstruirai un peu le source pour la version suivante. Nos échanges montrent d'ailleurs l'intérêt de travailler en versions successives : ma première version parlait les langues francophones, ma deuxième version ajoutait quelques langues anglophones, que verra-t-on dans la troisième version?Citation:
Envoyé par Pyramidev
D'expérience, Le source que tu commentes est lisible par un client non informaticien, après une brève formation. Je l'ai fait. Systématiquement. Tu exprimes des doutes, mais tu ne l'as jamais fait. Tu ne peux pas le faire en C++, c'est vrai. Essaye donc, que risques-tu? Prends Pascal, Ada ou Eiffel, et essaye. Avec tes compétences, tu n'auras aucun problème à t'y adapter et à devenir bien plus productif que ce que tu es déjà en C/C++/Java. Et si ton client exige pour des raisons obscures un "code" en C++, alors une fois que les exigences sont bien au point, la transcription du Pascal au C++ est immédiate et n'entraîne en général que peu de pertes de performances.
Au passage, je ne code pas, j'écris. Le mot "code" est le symptôme le plus évident des dysfonctionnements de notre métier. C'est le compilateur qui transcrit et "encode" mes sources. Plus nous "codons", et moins nos clients et nos utilisateurs comprennent ce que nous faisons, moins nous coopérons, moins nous sommes efficaces comme équipe intégrée, et plus nos projets en pâtissent...
Et demain, les IA "coderont" à notre place. Elles n'écriront pas à notre place. Il est plus que temps de monter en gamme.
Bien cordialement,
Thierryc
Delenda C++ est
Bonjour jlliagre;
Je te suggère de participer au portage vers Solaris, alors, si tu tiens à utiliser FPC. Après tout, FPC est libre et gratuit. Les développements de FPC se font suivant les besoins exprimés. Vu le nombre d'OS déjà ciblés et notamment le nombre d'Unices, le tien ne doit pas poser de problèmes particuliers. Cela vaut le coup de se fatiguer un peu pour un professionnel d'avoir de bons outils dans sa boite à outils...Citation:
Envoyé par jlliagre
Sinon, prends Ada et GNAT. Cela fonctionne sans problèmes sur SOLARIS et c'est encore plus puissant et rigoureux, même si la courbe d'apprentissage est un peu plus rude.
Le fil de discussion concerne l'avenir du C++. Ta réponse est hors sujet et ne traite pas de l'inefficacité économique des développements en C/C++/Java, par rapport aux alternatives.Citation:
Envoyé par jlliagre
Par ailleurs, j'aime bien cet idée d'écrire un langage de programmation dont les mots clefs seraient dans un langage universel comme l’espéranto. D'ailleurs, il y avait une mode à un moment de traduire les mots-clefs du Pascal dans différentes langues pour que chacun programme dans sa langue. Cela a fait long feu, bien sûr. Ceci, par goût personnel, j'aime pas les sonorités de l'espéranto. Si j'avais à choisir et du temps libre, j'écrirais un langage de programmation en latin, qui est une langue universelle, concise et à la sonorité magnifique, de mon point de vue... me voilà à faire du hors sujet, tu es contagieux ;-)
Bien cordialement,
Thierryc
Delenda C++ est.
Un client non informaticien ne comprend pas les structures de données, et certainement pas du code pascal, Ada ou n'importe quoi d'autre.Citation:
Envoyé par thierryc
On reste au niveau fonctionnel, au max avec des schemas d'entitée qu'on prend un temps fou à expliquer.
Je ne sais pas qui tu comptes convaincre, mais là pour le coup c'est vraiment pipeau.
La qualité c'est important, et elle dépend des programmeurs, pas des langages.
Unix est fait en C, c'est le top. Le C a été inventé pour de bonnes raisons, et on peut leur tirer notre chapeau.
Pareil pour C++, pourquoi aller toujours dans les cas limites? à l'école le prof nous expliquait à faire des dynamic cast pour implémenter l'opérateur = ....
donc oui ça c'est dangereux, à ne pas utiliser, mais ça a fait la mauvaise réputation.
En fait, peu importe que la compréhension soit bien profonde, c'est une technique commerciale.
C'est vrai qu'il y a certains clients un peu curieux qui sont enchantés qu'on leur explique ce qu'il y a sous le capot, même dans les grandes lignes.
Mais je n'abuse pas trop de ce procédé s'il n'y a pas de demande explicite. De plus, si on se laisse emporter à trop descendre dans les détails, il peut y avoir des réactions parfois négatives si le client décroche.
Merci pour le code. Deux remarques:Citation:
Envoyé par thierryc
Envoyé par Pyramidev
- Je renouvelle la critique que j'avais faite avec la version en Pascal : la sûreté de type est toute relative puisque par exemple "ConvertirNombreEntre70et79" a comme précondition d'avoir un nombre entre 70 et 79 mais le système de type assure uniquement d'avoir un entier entre 0 et 99.
Et ce n'est pas simple à corriger car il faut faire comprendre au compilateur, par exemple, que pour x dans [70,79], x-60 est dans [10,19]. Pyramidev donne une solution en template C++, est-il possible de faire pareil en Ada ? Éventuellement en plus intuitif (x.moins<60> n'est pas intuitif) ?
Et encore une fois, en faisant reposer toutes les suretés sur des types concrets, sous prétexte qu'on peut vérifier à la compilation, on sur-contraint nos fonctions et on se prive définitivement de programmation générique (les algorithmes sont directement liés aux structures de données).
bon je me demande qui a vraiment besoin de convertir un nombre en chaîne de caractère avec un contrôle de range en statique à la compilation.
Autre que des cas très spécifiques, je ne vois pas ... vraiment pas
Regarde la tronche du C++ moderne, templates everywhere donc pas le choix :mrgreen:Citation:
Envoyé par epsilon68
Je ne te comprends pas, ça n'a rien à voir.Citation:
Envoyé par foetus
De plus les templates sont très utiles mais ils sont surtout utilisé dans les libs (telle que eigen), beaucoup moins dans les applications.
les const expression tu voulais dire peut etre... mais ce ne sont pas des templates...
Je pense que c'était un commentaire ironique sur le fait que les templates étaient le "nouveau" truc à la mode et qu'on devait en mettre partout pour avoir l'air d'y connaitre quelque chose. Sur l'exemple de la conversion des chiffres en lettres, si tu veux que tout soit vérifié à la compilation, tu es malheureusement contraint d'utiliser des templates (les constexpr sont insuffisantes). Mais je te rejoins sur le fait qu'on s'en fiche un peu de tout vérifier à la compilation, surtout avec une telle syntaxe.Citation:
Envoyé par epsilon68
Les templates, je ne sais pas en C++, mais dans les langages que j'utilise, ça existe depuis très très longtemps. Alors après, peut-être que nous ne parlons pas du même type de "templates".Citation:
Envoyé par _Bérenger_
Les templates que j'utilise, évitent au développeur de réécrire 80% du code. Il suffit juste d'ajuster quelques arguments. Par exemple, un formulaire d'inscription ou de login, qui sont parmi les trucs les plus inintéressants du monde à développer. Autant utiliser un template pour ça, que l'on ajustera. On gagne du temps, et mon patron est content.
C'est évidemment un concept qui existe uniquement pour gagner du temps. En théorie, ce n'est pas toujours une bonne méthode, car elle cloisonne le développeur, qui ne sait plus développer sans framework ni templates. Et c'est mal...
le sujet est c++ donc bien évidemment on parlait de template en c++.Citation:
Envoyé par zecreator
Cela dit, "template", que ce soit dans un langage ou dans un autre, est un terme qui devrait définir le même concept non ?Citation:
Envoyé par epsilon68