Blackknight a écrit 1240 commentaires

Ada est plus verbeux et donc il est plus long d'écrire un programme

Alors, la verbosité est largement contrée par l'utilisation d'un IDE avec auto-completion, GPS étant un bon exemple donc dire qu'il est plus long d'écrire un programme, ça dépend aussi du programmeur.
D'ailleurs, tout le monde ne semble pas d'accord avec cette assertion (cf. là ainsi que les liens contenus).

Il est par contre moins performant que Rust.

Globalement, il est estimé que le code Ada est 30% moins performant que le C et de performance équivalente au C++ donc c'est tout à fait possible que le Rust soit plus performant dans certains cas.
Ceci dit, à l'époque des langages interprétés et d'après les discours que je lis ici-même, il semble que la performance brute ne soit plus une caractéristique primordiale.
Par contre, je suis intéressé par les sources que tu as pu trouver là-dessus.

Rust est destiné à faire un programme informatique sécurisé et performant (OS ou application) Ada se tourne plus vers une application critique bancaire, administrative ou d'avion. En Rust on fais attention à la sécurité informatique en Ada a ce que le résultat donne (int négatif après une addition de positif à cause d un débordement).

Qu'entends-tu dans ce cas par sécurité informatique ?
Le fait que le programme ne plante pas ?
Un programme qui ne plante pas même s'il donne de mauvais résultats ?

Pour la partie OS/Application que tu mentionnes, on retrouve Ada dans des machines n'ayant même pas d'OS sous la forme d'un exécutif temps-réel embarqué.
Il y a aussi eu une tentative d'OS pour x86 en Ada mais écrire un OS complet prend du temps et le projet a fini par s'arrêter.

Pour ce qui est des applications, GHDL ne rentre justement pas dans les catégories que tu mentionnes. Par contre, il y a effectivement historiquement des niches où on retrouve Ada mais heureusement il n'y a pas que là :)

En conclusion, moi je pense que les deux langages ont bien la même visée, faire des programmes qui fonctionnent sans avoir les écueils que l'on connait en C/C++.

En fait en Rust on manipule des références la plupart du temps, pas des pointeurs.

Notion qui ne s'écrit même pas en Ada :)
C'est le compilateur qui décide en fonction de la taille de la variable. Ceci dit, cela ne s'applique pas aux objets qui eux, sont toujours passés par référence.

mais je veux bien lire tes griefs.

Ce que je reproche aux macros en général, c'est que ça reste pour moi une verrue et que bien que cela soit géré par le langage et pas par un macro-processeur, on se retrouve à injecter du code là où on pourrait écrire une fonction.
Si le but est de forcer l'inlining, en Ada, il y a un aspect pour ça et on se passe très bien des macros pour le coup.

Par contre, la possession de pointeurs est clairement une bonne idée… Tellement bonne, qu'on la trouve dans Spark :)

Bon, je me réponds pour dire que toutefois, on peut écrire nombre de programme sans ne jamais utiliser de pointeurs :)

Pour moi, Ada était la suite logique du Pascal, un langage fortement typé. Sa politique commerciale l'a tué. S'il avait été libre, il aurait eu un tout autre destin.

Et oui, la 1ère version de GNAT date, hélas, de 1995.
Ce qu'il faut mentionner aussi, c'est que vu la complexité de la spécification, les compilateurs étaient souvent buggés et cela n'a pas aider à la réputation du langage.

Par contre, dans la légende Ada, il est souvent dit aussi que le langage provenant d'une spécification du département de défense américain, nombre d'universitaires refusèrent de travailler avec. Je suis "trop jeune" pour abonder dans ce sens :)

Ceci dit, c'est dommage d'en parler au passé, la prochaine version du standard étant en gestation et le compilateur GNAT, dans sa version payante du moins, supportant déjà certaines des évolutions (cf. le blog d'Adacore).

Le langage est donc toujours vivant… Preuve en est, on a sous les yeux une nouvelle version de GHDL :)

Je n'ai pas plus regardé que ça mais de ce que j'avais vu, certaines constructions relevaient de la contorsion plus qu'autre chose… Mais bon, mon jugement date un peu (cf. ce billet et mes commentaires).

Après, on dit qu'Ada est verbeux mais le Rust se défend pas mal dès qu'il s'agit de faire des templates :D

Pour savoir si c'est un bon remplaçant, il faudra attendre un peu… Et puis, il manque quand même encore des trucs comme le typage très fort ou la représentation en mémoire ;)
Et puis Rust a encore des macros !!! :D

Par contre, la possession de pointeurs est clairement une bonne idée… Tellement bonne, qu'on la trouve dans Spark :)

Bon, promis, je vais essayer de faire le tuto Rust… Ou alors un tuto Ada pour STM32 sur Hackable :D

J en conclu que tu est adaïste

Il suffit de regarder mes derniers journaux/dépêches mais je suis aussi BSDisteet je code en d'autres langages aussi , c'est pas limité en fait :)

Si je puis me permettre cette question, aujourd'hui quel est l'intérêt/apport/utilité d'Ada?

Vaste question ! Je vais y répondre très rapidement

• Intérêt : un langage assez bien construit et clair avec des concepts que l'on ne retrouve que là
• Apport : la sécurité
• Utilité : La même que n'importe quel langage informatique ? C'est un langage impératif/objet généraliste comme un autre donc on peut normalement faire la même chose qu'avec les autres.

Merci

PS : C'est une maladie chez les Adaistes de reprendre tout le monde là-dessus :D

En fait, c'est Ada, pas ADA.

Le langage tire son nom d'Ada Lovelace qui n'aurait certainement pas aimé que son prénom soit écrit sous la forme d'un sigle :)

Sinon ADA, c'est au choix :
- Un loueur de voiture
- L'American Dental Association
- Entre autres

Voilà, c'est tout :)

Qu'est-ce qui t'empêche de le faire tourner ? Tu peux installer ton propre serveur Signal, il faudra ensuite modifier le client pour qu'il s'y connecte.

Et tu retomberas dans le même travers que ton serveur XMPP, à savoir, le manque de confiance dans l'hébergeur et au final, tu n'atteindras jamais la masse critique qui fera que tout le monde veut causer avec toi sur ton serveur Signal.

Comme dit un pote : "Tu peux avoir le plus beau produit du monde, si tu n'as pas le marketing et les commerciaux qui vont avec, ça ne sert à rien".

Et ça, ça fonctionne même dans le libre, il suffit que Linus mette son nom sur git et hop, ça devient le truc le plus génial du monde… Perso, j'aimais beaucoup Monotone…

Dans le monde du mail, il y a énormément de services qui permettent de filtrer la plupart du spam, les outils sont bien plus performants.

Le mail a bientôt 40 ans, encore heureux qu'on ait des solutions !
Et encore, les solutions ne sont même pas au niveau du protocole mais sont des verrues sur les serveurs SMTP et les clients mail.

D'ailleurs, sur mon téléphone, j'ai pas un bogofilter qui tourne et ça se voit tout de suite.

D'ailleurs, voilà un projet intéressant : implémenter un hook Bogofilter sur ejabberd

De plus, alors que les utilisateurs acceptent de recevoir de temps à autre du spam dans leur boîte mail

Tu me diras comment ils font, moi, du spam, j'en reçoit une quinzaine par jour… Sur mon compte Jabber, rien et pourtant l'adresse est dispo ici-même depuis plus de 10 ans.

Il n'y a pas de spam sur Whatsapp and co, alors pourquoi accepter d'utiliser un service sur lequel on reçoit du spam ?

C'est pas ça qui devrait changer à partir de mai ? J'avais compris que le but de Facebook était de fournir un moyen pour que les entreprises puissent te contacter directement et que tu puisses commercer avec eux… De là à ce que l'on soit spammés, y a pas loin.

Alors, je ne connais rien à Matrix, mais le problème du spam ne risque-t-il pas d'arriver un jour ?

Du coup, tu as piqué ma curiosité et j'ai regardé rapidement.
Je suis tombé sur ce post de Prosody mais je pense que tu as déjà dû le voir.

Si j'utilise une allow list, qu'est-ce que je mets dedans ? Ça revient presque à désactiver la fédération.

C'est le même problème qu'avec les mails donc, sauf à coller un antispam côté serveur, y a pas de solution miracle.

Après, le fait qu'une whitelist ne fonctionne pas dans ton cas est plutôt une bonne nouvelle pour XMPP car ça veut dire que tes utilisateurs discutent avec des personnes issus de plein de serveurs différents :)

Regardes du côté du module de blacklist si tes spammeurs viennent toujours du même endroit.

Sinon, tu peux passer par les whitelists

Sur ejabberd, il y a la configuration s2s-access.
Il serait étonnant qu'il n'y ait pas la même chose sous Prosody.

un core obligatoire minimaliste et une multitude d'options

Comme le noyau Linux ? Je croyais que faire des monolithes, c'était mal :)

Blague à part, pour avoir monté un serveur XMPP il y a trois semaines pour la première fois de ma vie, rien qu'en installant ejabberd avec la configuration de base, j'étais déjà à plus de 80% des tests de compliance.

De base, tu as donc la communication entre clients, les multi-users channel (MUCs), le PubSub, la communication entre serveurs…

De ce que j'ai pu voir, les exemples de configuration pour Prosody fournissent grosso modo la même chose donc le plus petit dénominateur commun, il n'est peut-être pas si petit.

Après, coté clients XMPP, ce n'est pas forcément tout rose mais pour la messagerie et les discussions de groupe, ça reste correct.
Effectivement, j'ai quelques soucis pour la vidéo avec certains et un bug dans Xabber pour le transfert de fichiers mais le bug semble résolu pour la prochaine version.

Je n'ai rien contre l'humour (au contraire), mais honnêtement, ça n'a rien à faire dans un protocole, fut-ce dans des XEP (et même si c'est clairement mentionné qu'il s'agit d'humour).

A première vue, tu ne dois pas aimer l'IETF non plus… Sauf si t'aimes les pigeons :)

Je n'ai jamais dit que c'était ce qu'il fallait faire mais simplement que ce n'est pas au protocole de définir si le champ password contient le mot de passe ou un hash, pas besoin de pousser des cris d'orfraie.

Sauf que le protocole ne précise pas comment doit être stocké ce mot de passe, c'est un choix d'implémentation.

Par exemple, dans ejabberd, la partie authentification contient tout une série de processus et s'il est possible d'avoir le mot de passe en clair, il existe tout une série de possibilités permettant de s'en passer.

Personnellement, depuis les annonces de WhatsApp, j'ai quelques copains qui ont commencé à s'inquiéter et à qui j'ai proposé de monter un serveur XMPP.
Résultat des courses, je suis l'heureux administrateur et propriétaire d'une VM de petite taille (2Go de RAM et 20Go de disque) chez Scaleway et qui fait très bien le taff pour la trentaine d'utilisateurs enregistrés.

A cela, j'ai ajouté un serveur Apache hébergeant Movim.

Alors, oui, la configuration n'est pas forcément très simple et il est utile de comprendre ce que l'on fait et active.
Par contre, j'ai aujourd'hui des utilisateurs qui utilisent Xabber ou Conversations sous Android et Siskin sous iOS. Après certains utilisent aussi l'instance Movim pour causer.

Au final, cela fonctionne même si j'ai dû guider les personnes dans leur choix de client.

Globalement, pour l'instant, cela se passe bien

La projection Mercator a des défauts et j'aimerais utiliser d'autres projections qui n'ont pas ses défauts, mais qui en ont d'autres desquels je peux m'accommoder.

Tu fais des tirs d'artillerie ? Je te conseille la LCC :)

Moi ça me rappelle les generics en Ada

generic
  type Element_T is private;
  with function "*" (X, Y: Element_T) return Element_T;
function Square (X : Element_T) return Element_T;

Ai-je bien compris ?
Peut-on faire des trucs encore plus forts avec les concepts que juste spécifier les opérations nécessaires ?

Certes mais cela donne au moins une idée pour ce qui est du ressort du hobby.

Et hop, c'est tombé hier, le code de certains composants d'un des prochains prototypes de drone d'Eurocopter sera en Ada sous VxWorks (source).

Comme quoi, ça bouge encore :)

A lire sur le site, je ne crois pas qu'il faut se débrouiller seul.

Il fallait lire

A lire sur le site, je crois qu'il faut se débrouiller seul.

Là, j'en sais rien, je bosse pas pour eux (ils n'ont pas voulu de moi ;))
A lire sur le site, je ne crois pas qu'il faut se débrouiller seul.
Après tout, c'est un éditeur pas une société de conseil.

Et puis, c'est facile de certifier, non ? :)