Récemment j'ai commencé à regarder un peu le langage Ada. C'est un langage que je trouve vraiment intéressant, à plusieurs titres.
Bon, un point négatif pour commencer : la syntaxe. C'est vrai que j'ai plus été habitué aux syntaxes type c, c++, c#, java, javascript que pascal ou basic par exemple, même si je fais du ruby. Au premier abord on peut trouver la syntaxe un peu lourde, le respect des majuscules, etc. Mais utiliser le mod ada pour emacs vous aidera mine de rien, entre autre en gérant tout seul comme un grand les majuscules des variables ! Et ça c'est juste génial !
Ensuite, le principe même du langage, son système de type essentiellement, est vraiment intéressant. Je ne vais pas vous le détailler, il y a pas mal de ressources sur le sujet (et c'est aussi une question au travers de ce billet) mais juste prendre un exemple.
Lorsque vous voulez travailler avec des heures dans un langage quelconque, vous allez utiliser en général un entier. Ok, ça marche, pourquoi pas. Le problème initial est qu'il est possible de mélanger des choux et des carottes. Par exemple, vous pouvez affecter la variable heure avec une valeur d'incrément d'une boucle. Ben oui, pourquoi pas puisque c'est un entier aussi ? (oui ce n'est pas souhaitable, mais les bugs existent souvent parce que des choses non souhaitables arrivent)
Bon, on peut faire mieux, en déclarant une nouvelle classe heure par exemple. Cette classe va stocker la valeur dans un entier et ça va quand même améliorer les choses puisqu'on ne pourra plus faire monheure = i; aussi facilement. Mais ça ne suffit pas. Comment gérer la plage de valeurs ? Il va falloir rajouter de tests un peu partout pour gérer les cas, les limites, l'égalité, etc.
Au final vous risquez de vous retrouver avec quelque chose du genre (oui c'est grossier, et en plus vous perdez, en java, les opérateurs + et -) :
public class Hour {
private Integer value = 0;
public Integer getInt() {
return value;
}
public void fromInt(Integer hour) {
value = hour % 24;
}
public void incr() {
fromInt(value + 1);
}
public void decr() {
fromInt(value - 1);
}
// [...]
}
Supaïr, non ?
Ha oui, pourquoi faire ça ? Ben juste pour écrire des logiciels un peu plus sûr, avec moins de possibilité de bugs, d'effets de bords, etc. Vous croyez pas que ce serait un peu mieux non ?
Bon ok, mais comment qu'on fait en Ada alors ?
Ben c'est plutôt facile :
type Hour is mod 24;
Alors, elle est pas belle la vie ?
De la même manière, on peut facilement faire des intervalles genre
type Day_Of_Year is range 1..366;
Bon tout ça pour dire que Ada m'intéresse de plus en plus. Il est peut-être moins fun que certains langages, mais je pense que la satisfaction de bien faire les choses l'emportera sans aucun doute ! Finalement ça donne un peu l'impression que Ada demande à ce qu'on réfléchisse avant de coder, alors que de plus en plus dans les autres langages on voit beaucoup de monde coder puis réfléchir lorsque cela ne fonctionne pas. Mais surtout, ces systèmes sont intégrés aux langage et ne nécessitent pas de lib externe supplémentaire (comme par exemple pour faire de la programmation par contrat).
Maintenant, à vous de travailler un peu : connaissez-vous, avez-vous des ressources intéressantes concernant Ada ?
Voici ce que j'ai pour le moment :
- Cours sur Ada en MIAGE
- Cours Ada à l'IUT d'Aix-En-Provence
- Une introduction lors du fosdem 2013
- Présentation des fonctionnalités ada2012 au fosdem 2013
En avez-vous d'autres ? Ou des livres par exemple ?
# langage fonctionnel
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Le système de type paramétrique de Ada semble pas mal, mais essaye un langage qui a du filtrage de type, c'est tellement simple à lire, que l'on se demande pourquoi les autres langages n'ont pas l'équivalent.
"La première sécurité est la liberté"
[^] # Re: langage fonctionnel
Posté par CrEv (site web personnel) . Évalué à 2.
Tu aurais juste un exemple histoire de voir vraiment ce que tu veux dire ?
[^] # Re: langage fonctionnel
Posté par Nicolas Boulay (site web personnel) . Évalué à 4. Dernière modification le 24 juin 2013 à 16:53.
L'exemple typique définit un arbre, il faut en gros que ta donné soit un poil complexe. Le genre de truc qui te prend un paquet de fichier en java, mais 10 lignes en ocaml. Par exemple, un moyen d'exprimer un paquet de donné binaire :
type mon_gros_tableau_binaire = (val_t * string) list; (*ici la string est un commentaire pour savoir d'ou vient la donné en question*)
"La première sécurité est la liberté"
[^] # Re: langage fonctionnel
Posté par CrEv (site web personnel) . Évalué à 3. Dernière modification le 24 juin 2013 à 17:05.
Bon, je ne connais pas vraiment l'ocaml (en fait pas ;-) alors peut-être que j'ai tout faux dans la suite !
Je ne comprend pas bien en quoi c'est mieux.
Si j'écris :
Sachant que dans ce cas on ne peut pas affecter la valeur d'un
Integerni d'unNaturalpar exemple àMy_Integerqui lui est de typeI.Et côté lisibilité c'est quand même plutôt bien, non ?
Après, comme indiqué, peut-être que je n'ai pas tout compris ;-)
[^] # Re: langage fonctionnel
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si un record est une structure, cela n'a en effet aucun rapport :)
Les type sommes, sont une sorte d'union de type, avec un enum pour faire la différence, sauf que c'est typé (un switch ne peut pas être incomplet).
"La première sécurité est la liberté"
[^] # Re: langage fonctionnel
Posté par CrEv (site web personnel) . Évalué à 2.
Ok, je pense que j'ai compris.
Alors dans ce cas ce serait à rapprocher de ça : https://en.wikibooks.org/wiki/Ada_Programming/Types/record#Variant_record
Même si, si je ne me trompe, dans ce cas le discriminant est un enum, mais ça permet d'avoir un switch et donc de faire varier la liste (et les types) des membres d'un record.
[^] # Re: langage fonctionnel
Posté par anaseto (site web personnel) . Évalué à 1. Dernière modification le 24 juin 2013 à 17:34.
En fait, dans son exemple c'est pas un record, mais une variante et ça sert à remplacer les
switch...casemais en plus puissant.Edit : grillé, Nicolas m'a devancé, c'est la deuxième fois en peu de temps que ça m'arrive :)
[^] # Re: langage fonctionnel
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est plus puissant, car le filtrage peut être emboité si nécessaire, et que "sa complétude" est vérifié (pas d'oublie possible, c'est génial en cas de modif).
"La première sécurité est la liberté"
[^] # Re: langage fonctionnel
Posté par reno . Évalué à 3.
Il me semble que la complétude est vérifié aussi en Ada: "In Ada, one advantage of the case statement is that the compiler will check the coverage of the choices, that is, all the values of the subtype of variable X must be present or a default branch when others must specify what to do in the remaining cases."
Donc je pense que tu as répondu un peu vite..
[^] # Re: langage fonctionnel
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
il gère aussi l'emboitement ?
Genre
type t = Plop of integer | Plip of string
type t2 = Foo of t1 | Foo2 of (t*t)
let foo t2 =
match t2 with
| Foo (Plop i ) -> ..
| Foo (Plip s) ->…
| Foo2 (_, tt) -> toto (tt)
…
"La première sécurité est la liberté"
[^] # Re: langage fonctionnel
Posté par reno . Évalué à 2.
Non, maintenant si c'est probablement un confort intéressant (jamais utilisé un langage qui a ça donc je ne peux pas parler en connaissance de cause), avoir le compilateur qui vérifie que je couvre bien tout les cas possible me parait beaucoup plus important pour faire évoluer un programme.
[^] # Re: langage fonctionnel
Posté par anaseto (site web personnel) . Évalué à 3.
Ce qui est génial aussi, c'est que si dans ta fonction
get_sizet'avais oublié un des cas possibles, le compilateur te le dis. C'est particulièrement utile quand tu t'aperçois que tu veux rajouter un type dansval_t, puis après tu laisses le compilateur te dire toutes les fonctions dans plusieurs fichiers où t'as oublié de rajouter une règle de filtrage pour ce type.[^] # Re: langage fonctionnel
Posté par Diagonale de Cantor (site web personnel) . Évalué à 6. Dernière modification le 24 juin 2013 à 16:37.
Juste une question stupide, qu'appelles-tu « filtrage de type » ? Tu parles du filtrage par motif ( pattern matching ) ou bien est-ce autre chose ?
[^] # Re: langage fonctionnel
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je parle du truc de ocaml, dont chaque branche est plus ou moins définit par un constructeur qui permet de déconstruire la donnée et récupérer ce qu'il y a dedans de façon typé.
"La première sécurité est la liberté"
[^] # Re: langage fonctionnel
Posté par Diagonale de Cantor (site web personnel) . Évalué à 4.
Ok. Donc c'est bien ce qu'on appelle pattern matching (ou filtrage par motif pour ceux qui sont allergique au franglais). Et effectivement c'est génial !
[^] # Re: langage fonctionnel
Posté par Imagine2 . Évalué à 1.
Est-ce ce qu'on appelle "extractor" en Scala?
Voici par exemple, comment construire un objet de type "pair" à partir d'un entier:
[^] # Re: langage fonctionnel
Posté par chimrod (site web personnel) . Évalué à 3.
Pas tout à fait, en OCaml, il n'y a pas d'extracteurs autres que ceux prévus par le langage. Si l'on veut comparer avec Scala, il faudrait comparer avec les case classes qui rajoutent un peu de lourdeur dans leur utilisation (on peut pas tout avoir…)
[^] # Re: langage fonctionnel
Posté par Imagine2 . Évalué à 1.
Je répondais à ceci:
…ce qui m'a l'air de correspondre aux extracteurs. Les "case classes" en Scala sont essentiellement pour le "pattern matching" (par exemple pouvoir mettre des objets dans les cas d'un "switch") ce qui est différent, malgré ce qui est dit plus haut.
[^] # Re: langage fonctionnel
Posté par chimrod (site web personnel) . Évalué à 4.
J'avais compris, et je répète qu'il n'y a pas d'extracteurs en OCaml, le seul moyen de déconstruire un type passe par le pattern matching.
Maintenant, le pattern matching peut être présent dans un switch (l'usage le plus courant) comme présenté dans le commentaire ci-dessus , mais aussi lors du passage d'argument d'une fonction (moins courant), dont voici un exemple :
Mais cela reste encore limité aux motif d'extractions gérés en interne dans le langage, et il n'est pas possible d'en rajouter de nouveaux.
[^] # Re: langage fonctionnel
Posté par neil . Évalué à 2.
En général ce mécanisme s’appelle les view patterns et existe dans un grand nombre de langage fonctionnels par exemple en Haskell ou en F# (active patterns), vu que le concept a été introduit il y a quand même longtemps (en 1987 !). Le problème de OCaml est qu’une partie de ce qui aurait pu atterrir dans le langage a été relégué dans les outils, dans ce cas dans camlp4.
[^] # Re: langage fonctionnel
Posté par neil . Évalué à 2. Dernière modification le 24 juin 2013 à 20:57.
Le système de pattern matching de OCaml/Haskell/Scala/F# semble pas mal, mais essaye un langage qui a des types dépendants (ou des types homotopes !), c’est tellement simple à vérifier, que l’on se demande pourquoi les autres langages n’ont pas l’équivalent.
[^] # Re: langage fonctionnel
Posté par chimrod (site web personnel) . Évalué à 3.
As tu des exemples de langages ? Je ne me représente pas trop comment implémenter ça…
[^] # Re: langage fonctionnel
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
tu as un exemple ? :)
"La première sécurité est la liberté"
[^] # Re: langage fonctionnel
Posté par neil . Évalué à 8. Dernière modification le 24 juin 2013 à 22:39.
C’était principalement de l’humour pour dire qu’il y a toujours des systèmes de type plus puissant, c’est à dire permettant de détailler encore plus finement ce que fait un élément d’un programme (une fonction par exemple). L’exemple de l’OP avec un alias de type pour les heures par exemple, permet de définir des fonctions typées comme :
et le compilateur va se charger de vérifier qu’on ne retourne pas une erreur (un entier négatif, ou supérieur à 366).
En Haskell et OCaml, par exemple, il y a tout un tas d’autres apports du système de type. Par exemple, avec les GADTs, on peut vérifier à la compilation que tous les arbres binaires que l’on va construire sont bien balancés, ou qu’une liste passée en paramètre est toujours non-vide. Ça permet d’avoir une sorte de pattern matching mais à la compilation plutôt qu’à l’exécution. On peut aussi utiliser le système de type pour faire des calculs à la compilation (un peu comme le template meta-programming en C++, mais de façon propre :p).
Les GADTs viennent des systèmes de types dépendants, dans lesquels on peut par exemple typer le fait qu’un programme prenne en entrée une liste de n éléments, et sorte une liste de (n+1) éléments :
Et c’est le système de types du compilateur qui va se charger de vérifier ça à la compilation (en fait écrire un programme bien typé est la même chose qu’écrire une preuve, que le compilateur va vérifier). Les types dépendants sont classiquement utilisés dans les systèmes de vérification de programmes comme Coq ou Agda, mais les fonctionnalités commencent à arriver dans OCaml et Haskell. Il y a aussi des expériences de langages généralistes entièrement dépendants tels que Idris ou F*.
Pour les systèmes de types homotopes, il va encore falloir attendre un moment avant d’avoir des jolies applications. En gros, en plus d’unifier de nouvelles branches des mathématiques, ça permet d’avoir des types beaucoup plus jolis, ou de transférer une preuve sur un algorithme naïf, à une preuve sur un algorithme optimisé.
[^] # Re: langage fonctionnel
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Dans type "puissant", j'entends aussi utilisable. Le nouveau système de type de ocaml, j'ai beau avoir lu la doc et l'exemple, je n'ai rien compris. Si un ingé moyen ne comprends même pas l'outil, qui peut comprendre un code écrit avec ?
"La première sécurité est la liberté"
[^] # Re: langage fonctionnel
Posté par neil . Évalué à 2.
J’imagine que tu parles des GADTs dans OCaml décrits en 7.18 du manuel ? Juste parce que c’est plus facile pour moi, voilà la version Haskell :
On peut la charger dans l’interpréteur, et exécuter l’exemple du manuel OCaml :
L’exemple définit un AST fonctionnel dont les termes sont soit des entiers, soit des additions d’entiers, soit des applications d’une fonction à un argument. Les ASTs sont couramment utilisés comme représentation interne des compilateurs et autres interpréteurs.
Dans ce cas, on considère l’addition comme un objet de première classe, c’est à dire qu’on peut le passer en argument, le retourner, etc, et on considère aussi qu’une fonction est curryfiée, c’est à dire qu’une fonction de deux arguments est en fait une fonction de un argument qui retourne une fonction de un argument. Ces deux concepts sont à la base de la programmation fonctionnelle. Un terme d’application fonctionne lui aussi de manière fonctionnelle, en prenant en paramètre une fonction (qui n’a qu’un argument, comme toute fonction :p), un argument, et retourne le résultat de cette fonction.
Avec l’aide d’un interpréteur, on comprend facilement ce que fait chaque terme de l’expression :
Utiliser les GADTs va permettre de vérifier à la compilaition qu’on ne construise pas de terme erronés :
Il y a d’autres applications que cet usage trivial de vérification d’arbres bien formés, exemple qu’on ferait en POO avec des classes, et les design patterns adéquats pour l’évaluation.
De façon générale, mais ce n’est que mon avis, les fonctions avancées des langages fonctionnels sont surtout intéressantes parce qu’elles permettent d’écrire rapidement et de façon très concise (surtout en Haskell) du code sûr et performant. Le cas d’utilisation typique est quand on travaille dans des startups, dans la recherche (scientifique ou R&D), dans lesquels on doit avoir rapidement un code qui marche pour montrer des nouveaux concepts (en gros des cas où l’important ce n’est pas le code mais ce qu’il permet de montrer). C’est mon cas, l’informatique n’est absolument pas mon domaine, juste un outil dont je me sert pour une partie de mon boulot (simulations numériques, affichages prouvables, visualisations, traitement de données). Je n’ai pas le temps de débugger, d’avoir des erreurs à l’exécution (ou du code lent de par les vérifications à l’exécution), et mon code ne sera lu ou utilisé que par un nombre nul ou très très réduit de gens, ce qui compte c’est de vérifier les idées.
[^] # Re: langage fonctionnel
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Pour simplifier, dans un GADT par rapport au type somme classique, tu peux y mettre des fonctions en plus des type de donnés. Ok.
L'exemple d'AST que tu donnes, je pense que cela peut se coder avec des variants en jouant sur des ensembles fermés.
"De façon générale, mais ce n’est que mon avis, les fonctions avancées des langages fonctionnels sont surtout intéressantes parce qu’elles permettent d’écrire rapidement et de façon très concise (surtout en Haskell) du code sûr et performant."
Tout le monde veut écrire du code rapidement et sans bug !
"La première sécurité est la liberté"
[^] # Re: langage fonctionnel
Posté par CrEv (site web personnel) . Évalué à 5.
Malheureusement j'en suis moins en moins convaincu… il y a pas mal de monde qui finalement se satisfait de logiciels écris rapidement qui tombe en marche :/
[^] # Re: langage fonctionnel
Posté par neil . Évalué à 3.
Non. Il n’y a pas de fonction « à l’intérieur » du type. Comme pour une somme classique, les fonctions sont indépendantes et à l’extérieur (ici c’est
eval). Une somme classique s’écrirait sous la forme :Mais déjà là, on est bloqué aux définitions de
eval Addeteval (App f x)qui retourne des fonctions de type différents. On pourrait s’en sortir en faisant retourner àevalsoit unInt, soit une fonction (de deux types possibles), mais il faudrait alors tester qu’on a bien une fonction pourfdanseval (App f x)par exemple, et ça serait un test à l’exécution (avec du pattern matching développé ailleurs dans ce journal) et non pas à la compilation. Or c’est non seulement lent (exécution), inutile (le développeur ne veut jamais passer autre chose que des fonctions àApp), verbeux et mal extensible (il faut rajouter tout le code de pattern matching), et sources de bugs (le compilateur aurait vu tout de suite à la compilation qu’il y avait un problème).On peut vouloir dire au compilateur que chaque terme sera évalué à un type particulier, en lui associant un phantom type, sous la forme
data Term a = ... | App (Term a) (Term a). Ainsi à chaque terme est associé un type à la compilation (il est viré à l’exécution). Mais ça ne résout pas nos problèmes, en ayanteval :: Term a -> a, il n’y a pas assez de contraintes surapour que le compilateur empêche un utilisateur d’écrireeval (Intg 123) :: Stringpar exemple (en gros de convertir n’importe comment). La solution c’est d’utiliser les GADTs, qui vont apporter la flexibilité d’écriture nécessaire (le compilateur déduit queeval (Intg n)retourne unInt, et queeval Addretourne unInt->Int->Int), et la sécurité du système de types, en résumant (mal) le manuel d’OCaml :PS : On peut simplifier le code que j’ai donné au dessus, genre avec
eval Add = (+).# Bienvenue dans le merveilleux monde d'Ada !
Posté par lancelotsix . Évalué à 9.
Bonjour,
Ada est un très beau langage malheureusement il garde une connotation vieillotte.
Question ressources, il y en a pas mal, mais c'est dispersé…
Tu peux commencer par regarder ada-france qui a quelques liens. Après, il y a adaic qui peut être intéressant.
Bien sur, si tu veux l'info 'à la source', il y a le 'RM' qui décrit tout ce qu'il faut savoir, mais sa lecture est un peu aride.
Question bouquins, la référence est le john barnes (Programming in Ada {95,2005}), il est bien écrit et couvre énormément de choses. La version 95 a été traduite en français, par contre de tête la version 2005 n'existe que en anglais.
Pour des petits exemples intéressants, il y a une série de petits articles qui montre différents aspects du langages sur le site d'adacore : gems. (adacore étant éditeur d'un compilateur libre basé sur gcc et contributeur conséquent au support ada par gcc).
Et sinon, si tu postes sur comp.lang.ada, il y a du monde qui devrait pouvoir donner plus de ressources et répondre à des questions si tu en as.
Voili voulou, bonne lectures !
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par CrEv (site web personnel) . Évalué à 3.
Je pense que c'est, entre autre, parce qu'il a gardé une syntaxe type Pascal. Alors que petit à petit les syntaxes c-like ce sont imposée. Bon pas totalement si on regarde ruby (mais on peut quand même l'écrire à la c) ou python par exemple. Mais ce sont essentiellement des absences de parenthèses.
Merci en tout cas pour les informations et line, gems semble plutôt cool pour apprendre petit à petit le langage.
Et c'est vrai qu'il y a aussi, j'avais oublié de l'indiquer, http://libre.adacore.com à garder dans un coin.
Quoi, ada utilise toujours les newsgroup ? Ha ben ok pour la connotation vieillotte ;-)
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par lancelotsix . Évalué à 3.
Ada est effectivement verbeux, et la syntaxe est héritée de pascal mais ce n'est pas toujours un mal… Qui n'a jamais eu de bug à cause d'une petite erreur de syntaxe (des = au lieu == et autres erreurs d'un caractère dans le source non détectables par le compilo) ? Au final, je trouve qu'on y gagne plus qu'on y perds.
Je ne dirai pas que les gems aident à apprendre le langage, du moins pas dans un premier temps. Ils sont en revanche excellents pour approfondir et découvrir et approcher des aspects un peu plus poussés ou des trucs auxquels on n'avait pas pensé.
Sinon, dans les ressources, il faut ajouter celles relatives à Ada 2012 (dernière standardisation en date) qui apporte des améliorations vraiment intéressantes au langage : https://www.adacore.com/uploads/technical-papers/Ada2012_Rational_Introducion.pdf , https://www.adacore.com/adaanswers/about/ada-2012/ ou http://www.ada2012.org/ .
OK, je m'incline…
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par CrEv (site web personnel) . Évalué à 3.
C'est bien ce que je pense ;-)
Mais la syntaxe le rend juste moins "conventionnel" que pas mal de langages, ce qui peu expliquer que pas mal de personne ne s'y intéressent pas.
Merci pour les autres ressources
Nan mais c'est pas sérieux hein. C'est surprenant car de moins en moins de monde utilise de newsgroup mais ce n'est pas un problème pour autant.
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par reno . Évalué à 2.
Pas vraiment imposée: pour ajouter à Ruby/Python: Scala, Go, Rust, Nimrod (etc) ont pas vraiment avec une syntaxe C-like.
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par CrEv (site web personnel) . Évalué à 2.
En fait j'aurais mis rust et go dans le même sac. Ce que je voulais dire par là (mais c'était peut-être pas assez clair) c'est surtout le fait de délimiter des blocs par des accolades en comparaison à du begin/end et par exemple
:=(même si c'est utilisé, différemment, en go)[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par reno . Évalué à 3.
Si pour toi C-like c'est les accolades OK, mais bon ils ont quand même une grosse différence avec les syntaxe que je qualifie de C-like: leur déclaration des types est dans l'ordre 'Pascalien' donc lisible..
Rust: let monster_size: int = 50;
Scala: val arr = Array[Int]
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par CrEv (site web personnel) . Évalué à 3.
Oui, tu as raison, "c-like" n'était peut-être pas le meilleur descriptif.
Disons alors qu'il y a quand même assez peu de langages orienté Pascal :-)
Question bête : quelqu'un sait pourquoi en c et autres, les déclarations de type sont dans cet ordre ?
Après c'est sur que, alors qu'on essai d'aller dans des choses plutôt minimalistes (rust et go en sont de bons exemples), la verbosité de Ada peut choquer au premier abord.
Mais je prend ça plus comme un point positif qu'autre chose.
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par reno . Évalué à 2.
Je pense que c'est parce qu'en mettant les noms des types d'abords tu évite un mot clef: 'int x' suffit par rapport à
'var x: int'.
Après avoir du code 'postfix' f(x) t[i] etc et des déclarations 'préfix', j'ai toujours trouvé ça peu lisible..
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par CrEv (site web personnel) . Évalué à 3.
Oui mais justement, en Ada (par exemple) tu écris :
Et si tu veux l'affecter en même temps :
Donc il n'y a pas de
varou autre.[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En ocaml, tu peux ajouter aussi les types avec des ":", quand tu le fais, le code est beaucoup moins lisible qu'en C. Ce qui est amusant, car ocaml est beaucoup plus compact que le C, dans le cas général.
"La première sécurité est la liberté"
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par barmic . Évalué à 2.
Et pourquoi les autres le font dans l'autre ordre ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par Lucas . Évalué à 2.
Sans vouloir m'avancer pour les autres langages, dans un entretien Martin Odersky expliquait son choix pour Scala en disant ça permettait (entre autres) de rendre la déclaration de type optionnelle (lorsque celui-ci est inféré).
Ainsi si tu écris
ou
c'est jamais ambigu. on comprend dans les deux cas que c'est la variable
totoqui est déclarée et initialisée à1. Si l'on n'avait pas cevalil serait ambigu dans le cas du type inféréJe déclare toto ou je l'assigne ?
De plus scala possède des
val(immuable) etvar(muable) donc ça permet de vérifier statiquement qu'une variable immuable n'est pas réassignée.Ce qui serait acceptable dans un langage dynamique (ambiguïté entre assignation et déclaration) ne l'est pas pour une langage statiquement typé.
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu n'assignes jamais en fonctionnel :) Cela parait dingue quand on vient du C, mais on s'y fait très bien.
D'ailleurs, j’attends un langage avec un type (linéaire) qui empêche qu'un bloc de mémoire soit pointé par plus d'un pointeur. Cela rend hyper simple le multi-tache.
"La première sécurité est la liberté"
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par kadalka . Évalué à -10.
Vous faites de la programmation fonctionnelle ?
Si c'est le cas, Ocaml est fait pour ça ?
Et par rapport à Haskell c'est comment ?
Merci pour votre contribution sur cette page concernant ADA
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par Lucas . Évalué à 2.
Merci de présumer de mes connaissances, mais je crois que je bosse en OCaml toute la journée (sur un projet que tu dois sûrement connaître vu que tu en parles souvent ici) et en Scala pour mes projets personnels (après avoir bossé dessus dans le cadre de recherches).
Donc reprenons, maintenant que j'ai fixé ça : en Scala (seul langage dont je parle ici, cf le début de mon message) on assigne très bien une valeur à une variable muable.
Pour le multi-tâche je travaille par passage de messages immuables via des acteurs généralement, ce qui évite la mémoire partagée, et ça change la vie.
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je n'ai rien présumé du tout, je répondais juste à : "Je déclare toto ou je l'assigne ?"
"(sur un projet que tu dois sûrement connaître vu que tu en parles souvent ici)"
Je parle beaucoup ici, tu parles de quoi exactement ?
"La première sécurité est la liberté"
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par Lucas . Évalué à 1.
Oui mais je persiste "je déclare toto ou je l'assigne" dans le cadre de Scala (encore une fois, j'ai bien précisé dès le début que je parlais uniquement de Scala) est tout à fait une phrase valide ;)
la deuxième ligne est une assignation (même la spec le dit ;))
Bref… Ne traumatisons pas plus les drosophiles qu'elles ne le sont déjà à ce point.
Allez un indice : c'est un générateur de code écrit en OCaml. Mais je suis pas ici pour me vanter donc on s'en tape.
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ok, tu parles de KCG :)
Mais ce qui me désole le plus, c'est qu'il y a mon nom écrit en gros au dessus, et qu'on bosse dans la même boite, sans que tu es l'air de t'en apercevoir. Tu es sans doute à Toulouse, mais bon, la boite fait moins de 100 personnes…
"La première sécurité est la liberté"
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par barmic . Évalué à 3.
Si je ne me trompe pas en Scala les valeurs (val) sont immuables mais les variables sont muables.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par lendemain . Évalué à 0.
Je crois que Lucas c'est mal exprimer au sujet des val, var, mutable et immutable.
"a" est mutable.
La différence c'est que "a" ne peux pas être réaffecté dans le même scope(enfin je crois).
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par Lucas . Évalué à 2. Dernière modification le 26 juin 2013 à 22:26.
Ne confonds pas référence (im)muable et objet (im)muable
Dans ton exemple a est une référence immuable vers un objet muable. C'est-à-dire (si on descend assez bas sur comment ça marche) que tu ne pourras pas changer l'adresse mémoire pointée par a (référence immuable), mais tu pourras changer le contenu à cette adresse (objet muable).
utiliser le mot-clef
valen Scala est environ comme utiliser une variablefinalen Java (pour les variables locales uniquement, pas pour les attributs d'une classe), donc oui ne peut pas la réassigner (pour la simple et bonne raison que justement cette référence n'est pas muable justement…)Mon raccourci muable/immuable sans préciser ce à quoi ça s'appliquait peut prêter à confusion il est vrai…
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par BlueDian . Évalué à 4. Dernière modification le 25 juin 2013 à 08:25.
Bonne découverte d'Ada !
En terme de ressources, pas mieux que toutes celles déjà citées.
Son typage fort n'est pas l'élément qui m'a le plus marqué, pour ma part, c'est surtout ses primitives pour décrire du multi-tâche (notion de taches, de rendez vous, de protection de ressource…) qui m'ont le plus impressionné.
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par BlueDian . Évalué à 3.
Voici un lien pour voir rapidement toutes les possibilités d'Ada dans ce domaine du multi-tâche :
Cours de Laurent Pautet
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par CrEv (site web personnel) . Évalué à 2.
Merci pour ce lien, je vais aller lire ça.
Quelqu'un pour le comparer aux goroutines ? (je ne sais pas si c'est comparable en vrai)
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par Thomas Douillard . Évalué à 5.
C'est plus haut niveau que les goroutines, plus de mots clés par exemple. A l'usage les goroutines (j'imagine, j'ai pas pratiqué) doivent demander d'apprendre ou de découvrir certain patterns qui sont assez naturels en Ada de mémoire (j'ai pratiqué mais ça date). J'avais été bluffé par la facilité avec laquelle j'avais simulé de manière parfaitement naturelle en quelques minutes et quelques lignes de code un PC complet avec un bus, une horloge, une mémoire, un tic d'horloge … qui tournaient en parallèle, en DUT. Plus loin dans mes étude, j'ai pleuré pour refaire les mêmes genre de trucs en C ou en java.
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par Thomas Douillard . Évalué à 2.
Les trucs présentés dans cet article http://www.seas.gwu.edu/~mfeldman/cs2book/chap15.html correspondent à mes souvenirs, par exemple.
# Proust alors.
Posté par kadalka . Évalué à -10.
Gaspard Proust c'est quand même autre chose hein. Ce n'est pas du Raymond Devos mais il est excellent.
Bon, ce n'est que mon avis.
Avec du C c'est tout aussi sur si bien sur on respecte certaines règle.
Je crois même que lorsque OpenBSD se targue d'être sur c'est grâce à sa rigeur dans le codage.
Non?
PS: Oui, d'accord parler d'openBSD sur un site où la horde de linuxien est la norme c'est pas bien.
Parler de GNU/linux c'est bien.
[^] # Re: Proust alors.
Posté par Atem18 (site web personnel) . Évalué à 4.
Hein ?
[^] # Re: Proust alors.
Posté par Marotte ⛧ . Évalué à 2.
Deux ?
[^] # Re: Proust alors.
Posté par CrEv (site web personnel) . Évalué à 7.
Avec de l'assembleur aussi c'est tout aussi sûr si on respecte certaines règles.
Et après tu vas encore venir te plaindre comme un pauv' petit calimero que les gens te moinsent. Ben finalement faut pas s'étonner. Et en plus, tu es un contre exemple à ta propre théorie des extrêmes. Si cette théorie était vraie tu serais parti d'ici depuis longtemps.
[^] # Re: Proust alors.
Posté par kadalka . Évalué à -9.
Me plaindre à titre personnel? non. Pour les autres: oui.
Ma théorie se tient.
Il y a toujours des exceptions, et j'en suis un, il paraît même le seul puisque les autres ne se montrent pas trop.
Dans ma dépêche, j'ai ajouté une remarque sur ce que j'ai vécu une fois dans le monde réel…
J'ai transposé ça au monde internet.
Sinon j'ai une question: qu'est-ce qui est faux dans ce que j'ai écrit ?
OpenBSD ne se targuait-il pas de la qualité de son OS par rapport à tous les autres ?
(Perso je n'aime pas trop la personnalité de De Raadt, surtout qu'il a été virulent avec linux, mais bon)
[^] # Re: Proust alors.
Posté par CrEv (site web personnel) . Évalué à 4.
Super pratique pour se planquer ça.
Bon et sinon, on les a entendu les autres ? Ils ont demandé quelque chose ? Ils t'ont soutenu ?
Oui tu fais partie des exceptions.
Avec 20 comptes avec un karma <= 0 sur les 3900 comptes actifs tu fais donc partie d'un ensemble comportant 0.5% des utilisateurs actifs. En ce sens tu es une exception. Pour le reste tu es malheureusement plus une pollution.
Et qu'est ce qui est faux dans le fait de dire que l'assembleur aussi c'est sûr ?
On peut écrire des logiciels sûr dans, je pense, à peu près tous les langages, même en brainfuck ou whitespace. Mais ça ne veut pas dire que brainfuck ou whitespace est forcément un bon choix.
Et, entre autre, les exemples cités dans le journal montrent qu'il y a quand même une sacré différence en terme d'investissement nécessaire pour avoir quelque chose de sûr suivant les langages.
Ha oui, et sinon (et ça peut intéresser tout le monde) il y a aussi spark qui est basé sur ada : http://www.spark-2014.org/ pour la version 2014, utilisant la programmation par contrat de Ada 2012.
[^] # Re: Proust alors.
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ou SCADE, mais c'est pas du tout libre.
http://www.esterel-technologies.com/products/scade-suite/prototype-design/scade-suite-modeler/#editor
"La première sécurité est la liberté"
[^] # Re: Proust alors.
Posté par kadalka . Évalué à -9. Dernière modification le 25 juin 2013 à 12:21.
1) J'aimerais bien qu'on ne discute pas de ça ici.
2) Les autres, je leur donnerais un très bon conseil: ne dites rien.
3) Pour les soutiens, je n'en cherche pas, mais s'ils soutiennent ils ne te le diront pas en tout cas.
4) Pour la pollution, laisses les visiteurs qui ne connaissent pas LinuxFR décider par eux-mêmes.
1) Ma remarque sur le C ne sous entend pas qu'ada est mauvais, c'est votre vision des choses qui est fausse sur ce point.
2) Le C est difficile parce qu'il n'est pas un langage objet dans le sens d'ADA.
3) Le C#/Mono/qu-importe-le-nom ont été inventé pour pallier à certains problèmes du C.
Vala me paraît être ce qu'il y a d'intéressant pour régler certains problèmes lié au C.
4) Le langage assembleur est très lié au matériel, donc votre remarque n'est pas pertinent sur le sujet.
5) J'aurais aimé lire des remarques sur Java vs ADA, ça aurait été intéressant.
6) Spark ? Bof.
7) On m'a dit du bien de LISP pourquoi ne pas plutôt le comparer à LISP ?
[^] # Re: Proust alors.
Posté par CrEv (site web personnel) . Évalué à 4.
Sur la première partie je rigole, ça suffira bien comme réponse !
Quelle vision ?
Nope. Et je ne parle même pas de l'orientation objet ici, juste du typage.
D'ailleurs ce n'est pas une histoire d'être difficile ou non, c'est une histoire de savoir si le langage offre des possibilité pour éviter des problèmes / erreurs / bugs ou non. Et pouvoir mettre la valeur 5 (poires) dans une variable (pomme) en est un, qui peut facilement être éliminé en Ada, beaucoup moins en C.
C# est plutôt là pour concurrencer Java (avec un bytecode portable), à la rigueur pour concurrencer C++ mais pas C.
Bien sur que si c'est pertinent.
C'est pertinent parce que ça permet de coder un logiciel.
C'est pertinent parce que Ada cible (entre autre) l'embarqué, là où on peut trouver de l'assembleur.
Et ton programme C, une fois compilé, quel est la différence entre ça et de l'assembleur ?
Ben j'ai montré un exemple côté typage entre Ada et Java justement.
C'est à dire ?
Parce que mes connaissances en lisp sont limitées pour faire une comparaison et que je présentais rapidement ada et non ada vs the world.
[^] # Re: Proust alors.
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Non, le C est difficile parce qu'il est plus proche de l'assembleur et que les abstractions sont faites à la main. On peut tout à fait écrire du code Ada qui n'est pas objet et le langage n'est pas objet à l'origine mais a évolué en 95 pour fournir un support objet Mais encore une fois, programmer objet (i.e avec polymorphisme, dynamic dispatching…) n'est pas obligatoire.
En voilà une parmi d'autres.
C'est sûr qu'il faut avoir déjà la culture Ada pour "apprécier" Spark. Celui-ci est un langage de niche créé pour éviter les écueils de la programmation Ada et faciliter l'analyse statique du code donc tant que l'on a pas à programmer un système dont les défauts ont des impacts en termes de vies humaines, oui, bof
Parce qu'ils ne sont pas de la même famille à savoir procédural contre impératif/fonctionnel ? D'ailleurs, quel LISP ? Common LISP, Le LISP, e LISP ?
[^] # Re: Proust alors.
Posté par kadalka . Évalué à -9.
1) Déjà merci pour votre contribution enrichissante.
2) " On peut tout à fait écrire du code Ada qui n'est pas objet " (…)
Tout à fait, d'ailleurs la majorité des langages de programmation modernes n'exigent pas l'objet.
Ma remarque concernait le fait que le C est difficile dès lors qu'on veut faire de l'objet.
Pour faire cela simplement, il vaut mieux passer par vala.
3) Merci pour les deux liens: je n'en demandais pas plusieurs et vous avez fait l'effort de m'en donner.
Une "surcouche" genre vala pour le langage C ? Là ce serait intéressant.
J'avais lu il y a déjà longtemps que LISP est un langage qui en gros est supérieur à java en tous points.
Je me suis donc demandé si ADA comparé à du LISP n'est pas intéressant dans une discussion ici, mais l'auteur de ce journal ne connaissant rien au sujet de LISP, je dois accepter de passer mon tour.
Ce qui serait intéressant c'est l'aspect programmation concurrente et fonctionnelle de ADA et d'avoir des infos de comparaison avec LISP.
Si personne ne peut en parler ce n'est pas grave.
[^] # Re: Proust alors.
Posté par CrEv (site web personnel) . Évalué à 4.
Mouai. Quelqu'un utilise vala en dehors de linux/gtk par exemple ?
J'aurais plutôt dit de passer à c++ (mouai), obj-c, voir D par exemple. Vala étant bien le dernier me venant à l'esprit.
Au fait, je n'ai pas dit que je ne connaissais rien à lisp… faut arrêter de déformer les propos hein.
Par contre oui, mes connaissances en lisp (enfin elisp pour moi) ne me suffisent pas pour comparer, ni d'ailleurs mes connaissances en ada.
Mais je dirais surtout que c'est pas du tout le même type de langage (fonctionnel pour lisp) et c'est un peu comme si tu demandes de comparer haskell et c, ça risque d'être compliqué car une grosse partie de la comparaison va venir du paradigme différent.
[^] # Re: Proust alors.
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Autant pour concurrente, on est bien d'accord, c'est un point intéressant, autant pour fonctionnel, j'ai bien l'impression que l'on ne parle pas de la même chose. Ada n'est pas un langage fonctionnel et ne le sera jamais, il s'agit d'un langage impératif.
En ayant l'esprit très ouvert, on pourrait peut-être assimiler les dernières avancées en termes de prédicat pour la vérification statique de code de programmation pseudo-fonctionnelle mais faut vraiment être très ouvert.
Ben, on peut toujours parler de LISP mais franchement, si je peux comprendre à peu près qu'on compare avec Ocaml qui est multi-paradigme, la comparaison avec LISP peut s'arrêter à : "Il y a plus de parenthèses en LISP".
[^] # Re: Proust alors.
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Justement, il s'agit non pas d'une surcouche mais d'un sous-ensemble avec annotation. En clair, Ada est un langage généraliste et possède donc des fonctionnalités qui ne sont pas utilisables en l'état pour des applications critiques d'où l'existence de Spark.
C'est justement cela qui rend Spark intéressant pour ce domaine.
[^] # Re: Proust alors.
Posté par barmic . Évalué à 6.
Tu numérote tes lignes maintenant ?
Le C ne t'aide absolument pas à avoir un programme sûr. S'appuyer sur des règles de codage c'est bien, mais ce n'est pas suffisant, il faut aussi faire de l'audit et avoir une batterie de tests de qualité (déterminer la qualité des tests et avoir des tests qui eux-même ne contiennent pas de bug est encore une autre histoire). C'est vrai dans tous les langages, mais il y a des langages qui apportent une sécurité supplémentaire qui soit n'est pas désactivable soit l'est manuellement donc tu sais que par défaut, tu a une meilleure fiabilité, quelque soit la personne qui a écris le programme.
Donc je vois pas en quoi arriver et dire ceci est pertinent :
Sans rien de technique ou quoi que ce soit d'un peu factuel, mis à part un « on dit ». Si tu veut nous dire que le processus de développement est plus important que le langage et que celui de ceux qui font OpenBSD est au top. Ok mais faut le dire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Proust alors.
Posté par lancelotsix . Évalué à 6.
C'est parce qu'il a une vocation différente qu'il est toujours délicat de le comparer à ADA. C est pensé comme un assembleur portable. De son côté, Ada est un langage de haut niveau permettant énormément d'abstractions impossibles en C (les enums sont plus que des entiers, les tableaux sont plus qu'un pointeur vers le premier élément, la sémantique du multi-tache construite dans le langage et bien d'autres encore…).
Le choix du C peut donc se montrer pertinent pour développer des couches bas niveau (même s'il n'est pas nécessairement le seul choix possible), mais il atteint ses limites dans des applications de plus haut niveaux.
Quoi qu'il en soit, par philosophie le C est permissif et pré-suppose que le développeur sait exactement ce qu'il fait. Il laisse faire même si parfois c'est une erreur évidente. C'est d'ailleurs (en partie) source de failles de sécurités en tout type (genre cela). De son côté Ada empêche tant que faire se peu que le développeur fasse des choses «risquées» (genre écrire en dehors des bornes d'un tableau), est parfois verbeux pour éviter tout ambiguïté, et dispose de compilateurs pointilleux.
Bien sur, une discipline importante permet de faire du C très propre et fiable, et bon nombre de systèmes extrêmement robustes en sont la preuve indiscutable. Cependant, il peut être intéressant de placer des garde fous au niveau du langage en plus de ceux permettant de faire du bon C.
En ce qui me concerne je considère que c'est un atout significatif.
Dans les grandes lignes : Ada est compilé nativement alors que Java nécessite un VM. Il est ainsi plus aisé de faire du bas niveau en Ada qu'en Java (constructions permettant d'être très précis sur la représentation machine des objets utilisés, on peu faire comme en C et accéder directement à la mémoire si vraiment on en a besoin, …). Après Java a d'autres avantages, dont notamment la capacité de faire de l'introspection ce qui n'est pas envisageable en Ada.
Il est en général plus intéressant de comparer Ada à C++ car ils se ressemblent plus sur ces aspects (et bien d'autres).
Bon, j'avoue que je prêche un peu pour ma paroisse, mais sachez que je ne dénigre pas le reste pour autant ! L'ensemble des langages disponibles offrent une diversité très profitable, surtout si on regarde ce qui se fait chez les voisins. Ça donne de bonnes idées et permet d’acquérir de bonnes pratiques parfois.
[^] # Re: Proust alors.
Posté par barmic . Évalué à 3.
L'omnipresence (la capacité qu'on (presque ?) tous les langages à s'interfacer avec lui et la disponibilité de celui-ci sur (presque ?) toutes les plateformes) du C en fait un langage de choix pour un tas d'autres application (comme les bibliothèque par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Proust alors.
Posté par lancelotsix . Évalué à 1.
Oui.
C'est une façon de répondre à la contrainte. C a cet avantage que les concepts qu'il manipule (proches de la machine) forment un bon «dénominateur commun» à bon nombre de langages. Si on cherche à développer quelque chose de facilement réutilisable dans de nombreux langages, il semble assez pertinent de se limiter à ces concepts.
Ceci étant dit, et étant donné que beaucoup de langages s'interfacent facilement avec le C, je suppose qu'il est également possible de faire le contraire. Écrire la librairie dans son langage qu'on aime bien et qui est trop fort de la mort qui tue, prévoir une interface se limitant aux concepts simplement manipulables en C et ensuite écrire un binding en C.
Je cherche un exemple percutant où ça aurait été fait, mais je n'en ai pas qui me vienne à l'esprit :( Est-ce que quelqu'un a un exemple qui ait utilisé ce genre d'artifice ?
[^] # Re: Proust alors.
Posté par barmic . Évalué à 2.
Qt doit avoir un binding en C. Sinon il y aussi les OS écris en autre chose que du C et qui exposent des appels systèmes en C.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Proust alors.
Posté par kadalka . Évalué à -9.
Exactement d'où l'existence de langages comme vala, qui permet d'écrire du C. C'est un genre de préprocesseur C.
On peut compiler directement du vala d'ailleurs.
Mais il me semble que vala ne peut pas se passer de GObject… (Je n'ai pas encore essayé donc je ne peux pas dire que c'est cela)
Donc je résume vos propos :
1) Ada c'est mieux que le C pour l'aspect langage de haut niveau
2) Ada permet quand même de faire du bas niveau.
3) Le compilateur est plus exigeant
4) On ne peut pas dépasser les bornes d'un tableau par exemple (pas de dépassement de tampon possible?)
5) Les gardes fous d'ADA sont un atout significatifs dans le sens où un développeur un peu distrait n'aura pas de soucis
Je parlais de java parce qu'on dit tant de bien de lui, alors que personnellement je n'ai jamais été convaincu par ce langage dès l'instant où python est arrivé.
1) Java ne peut pas se passer de JVM, mais on peut compiler du Python (Cython) et de l'ADA.
2) Le codage de python est plus propre que celle de java (pas de problèmes de parenthèses oubliées)
Ma question étant sur java, le code compilé peut-il fonctionner en multitâche sans problème ?
Par exemple, intel a créé un compilateur pour la programmation parallèle pour le langage C/C++.
Comparativement à java ce serait comment ADA et si vous pouvez y répondre comparativement aux possibilités du compilateur d'intel, ca s'en rapproche ?
A titre personnel, cela ne me gène nullement, mais il faut toujours être prudent sur LinuxFR.
Lorsque je défends debian contre Red Hat c'est toujours un moinsage en règle qui m'attend.
En tout cas, j'ai aimé votre contribution… Revenez plus souvent.
[^] # Re: Proust alors.
Posté par lasher . Évalué à 2.
Tu viens de démontrer une grande ignorance avec cette phrase. Python est arrivé en 1991. Java, bien qu'existant plus ou moins en interne chez Sun à ce moment, n'était même pas encore disponible pour le grand public (et puis, histoire d'être complet, Perl existe depuis 1987).
De plus tu ne connais visiblement pas bien les limites de chacun de ces langages. Java permet de faire du vrai multi-threading, pas Python.
[^] # Re: Proust alors.
Posté par grim7reaper . Évalué à 1.
Le langage Python en lui-même permet tout à fait de faire du vrai multithreading (Jython et IronPython en sont la preuve).
Il est vrai que l‘implémentation la plus répandu (CPython) ne le permet pas (à cause du GIL, Ruby est d’ailleurs logé à la même enseigne).
Mais c’est un détail, non négligeable certes, d‘implémentation. Le langage en lui-même en est tout à fait capable.
[^] # Re: Proust alors.
Posté par lasher . Évalué à 2.
Je parle des implémentations de référence de Python (et oui, Ruby et Perl ont le même problème). IronRuby, IronPython ou Jython sont des exceptions, et quelque part c'est triste à dire, mais ils introduisent une incompatibilité si tu fais du « vrai » multithreading avec (techniquement, Python permet le multithreading pour le multiplexage des E/S). Donc je maintiens ce que je dis : Python, celui utilisé à peu près partout, ne supporte pas un multithreading « général ».
[^] # Re: Proust alors.
Posté par kadalka . Évalué à -9.
J'utilisais Java avant python…
(c'est ce que je voulais dire)
Pourriez vous nous expliquez ce qu'est pour vous le vrai multithreading ?
Quelle version de Python utilisez vous ? (Ou devrais je dire, avez vous vu) pour affirmer qu'il ne fait pas du vrai multithreading ?
[^] # Re: Proust alors.
Posté par claudex . Évalué à 7.
Python ne fait pas du vrai multithreading parce qu'il ne permet pas que deux threads s'exécutent en parallèle.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Proust alors.
Posté par lancelotsix . Évalué à 2.
Ada est plus adapté que le C pour faire du haut niveau (il est d'ailleurs fait pour ça). «Mieux» est un mot un peu fort, c'est très subjectif…
C'est un doux euphémisme
Non. Tout comme en Java d'ailleurs (c.f. le procès entre google et oracle sur la vérification du fait qu'un indice est dans les bornes)
Oh si il en aura, mais avec le compilo ;) Le grand intérêt est que (hormis cas vraiment extrême), si le programme passe les vérifications du compilateur et ne fait pas ce qu'on attend de lui, c'est que l'erreur est dans la logique du code et pas dans sa traduction dans le langage.
Le code ada compilé fonctionne en multitache sans problème, c'est même un prérequis. Bien sur, ça demande un minimum «glue», qui a pour mission de faire le lien entre les abstractions du langage et les primitives fournies par le système cible. Mais ça c'est le taf du compilo, pas celui du développeur.
Ne connaissant pas ce compilateur ni ses possibilités, je ne peux pas répondre.
[^] # Re: Proust alors.
Posté par lasher . Évalué à 2.
Je ne sais pas ce que « compilateur parallèle » signifie. Intel a une option de parallélisation « automatique » qui n'est mise en œuvre que lorsque les boucles sont triviales à paralléliser (pas de dépendance portée sur plus d'une itération, etc.). Sinon,
icccommegccimplémentent OpenMP, qui nécessite une parallélisation explicite d'un programme écrit en C/C++ (ou Fortran avecifort/gfortran).[^] # Re: Proust alors.
Posté par Marotte ⛧ . Évalué à 5.
Dans les deux cas ça revient au même, tu te plains.
Par ailleurs, Internet fait partie du monde réel.
Ça :
« horde de linuxiens » c'est déjà un peu insultant et vu que beaucoup d'articles (dépêches, journaux) sur *BSD ont de bons scores tu es clairement à coté de la plaque.
Sinon oui c'est vrai, OpenBSD fait particulièrement attention à la qualité de son code. Mais comme on te l'a dit, on sait bien que l'on peut faire du code propre, élégant dans n'importe quel langage, c'est juste que c'est plus facile avec certains langages.
Le passage sur Gaspard Proust c'est un bel exemple de propos inutile. Il n'a pas le monopole de la phrase : « Alors, elle est pas belle la vie ? » ! De plus, personnellement, je ne pense pas que l'on puisse comparer son humour avec celui de Raymond Devos, c'est pas le même genre d'humour. Il y avait beaucoup de poésie chez Devos, ce n'est pas le cas chez Gaspard Proust.
[^] # Re: Proust alors.
Posté par CrEv (site web personnel) . Évalué à 4.
Surtout que je ne sais même pas qui c'est…
Moi je pensais plutôt à une pub avec un gosse qui dirait un truc dans le genre (même si ce n'est pas la phrase exacte).
Ho et puis on s'en fout en fait !
[^] # Re: Proust alors.
Posté par Marotte ⛧ . Évalué à 2.
Et c'est pas comme si tu pouvais faire Ctrl+T, taper "gaspard proust" et te renseigner un peu ?
C'est un comique de la taïlaÿ (il doit faire de la scène aussi), pas forcément toujours très drôle je trouve, mais qui en sort de bonnes de temps en temps.
[^] # Re: Proust alors.
Posté par CrEv (site web personnel) . Évalué à 3.
Ola calmos.
Ce que je voulais dire c'est que je n'avais surtout pas écris cette phrase en pensant à Gaspard Proust, d'où le côté totalement hors sujet de Kadalka.
[^] # Re: Proust alors.
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 26 juin 2013 à 08:32.
OK :)
Je n'ai jamais cru que tu faisait référence à cet artiste, je n'y ai même pas pensé à la lecture de la phrase « alors elle est pas belle la vie ? », mais tu as écrit :
C'est pour ça. Tu aurais dû écrire : « Surtout que je ne savais pas qui c'était. » ;)
[^] # Re: Proust alors.
Posté par lasher . Évalué à 10.
Je code en C et C++ très régulièrement. En fait, ce sont presque les deux seuls langages que j'utilise. J'écris et j'utilise du code multithreadé à longueur de journée. En fait, une partie de mon boulot consiste à maintenir une bibliothèque pour l'expression de programmes parallèles.
Le C, par définition, n'est pas sûr pour le multi-tâche. Plus exactement, C89 et C99 ne le sont pas, car ils ne savent pas ce qu'est une tâche. C11 a repris le même concept de tâche que C++11, et ça copie plus ou moins les threads POSIX. Bon ben autant dire qu'on est toujours pas dans le « sûr » par défaut.
En fait, l'un des créateurs du modèle mémoire de C++, J.Boehm (quand on suppose un processus séquentiel, pas besoin de modèle mémoire, mais une fois qu'on parle d'un modèle multi-tâches, alors il faut pouvoir décrire les règles de visibilité de lectures/écritures) a même écrit un papier qui s'intitule Threads Cannot Be Implemented as a Library. Un autre, grand expert des modèles d'exécution parallèles, a écrit un excellent article intitulé The Problem With Threads. Dans son papier, il décrit toutes les jolies propriétés liées aux machines séquentielles de Turing. Il explique en quoi c'est extrêmement important pour garantir que les programmes séquentiels sont corrects. Puis il explique comment, dès qu'on a des threads de type PThreads, toutes ces garanties s'envolent par la fenêtre, et qu'il est impossible de prouver qu'un programme multi-threadé est dépourvu de bogues et de race conditions (ou data races). Il propose ensuite un modèle où tout est déterministe par défaut, et seules des régions précises de code sont marquées comme « non-déterministes ». Bref, l'inverse de ce que proposent les threads classiques.
Tout ça pour dire quoi ?
# Majuscule ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Ben justement, contrairement aux autres langages, Ada est insensible à la casse. Les variables CrEv, CReV, CREV etc représentent toutes la même chose.
C'est assez contre-intuitif quand on vient d'un autre langage mais finalement, ça évite d'avoir à retenir le nom d'une variable ET sa casse.
Sinon, je suis d'accord qu'au premier abord, c'est pas folichon et pas franchement à la mode mais une fois qu'on a compris que le compilo n'est pas notre ennemi, ça va beaucoup mieux :D
Bienvenue alors :)
Ah oui, pour les ressources, en voici quelques-unes :
- Les gemmes d'Adacore
- Le newsgroup en anglais dont le niveau est élevé puisqu'on y trouve plusieurs participants à la norme
- Le newsgroup en français à plus faible débit vu qu'on doit être une vingtaine dessus mais dont la qualité est tout aussi bonne que la version anglaise :D
- le topic Reddit
[^] # Re: Majuscule ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Bon, vu que je m'étais largement fait griller sur les liens précédents, je vais en donner de nouveaux :)
- Pour faire joujou avec un Arduino, rien ne vaut le blog de Tero
- Pour s'amuser à faire du temps réel sur bare metal, MarteOS
- Pour les programmeurs C++ et bien qu'il traite de la version 95, ce document reste pas mal
Voilà
[^] # Re: Majuscule ?
Posté par CrEv (site web personnel) . Évalué à 2.
En fait pour le côté casse, finalement que le langage soit sensible ou non n'est pas très important, c'est surtout que emacs force une convention de codage sans qu'on ait besoin d'y réfléchir. Et ça je trouve ça vraiment cool :-)
[^] # Re: Majuscule ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
En outre, si je me rappelle bien, il te permet de respecter la norme de codage conseillée par l'Ada Quality and Style Guide mais c'est à vérifier.
D'ailleurs, tu peux vérifier tout ça avec le compilateur ou des outils externes comme AdaControl.
[^] # Re: Majuscule ?
Posté par barmic . Évalué à 3.
C'est dommage que ce ne soit pas forcé je trouve. J'aime bien l'idée dans ruby de donner une signification à la casse.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Majuscule ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Sémantiquement parlant, c'est quoi la différence entre Michel, michel et MICHEL ?
Ok, on pourrait dire que :
- Michel, c'est le prénom
- michel, un objet ?
- MICHEL, un sigle ?
C'est un peu subjectif, non ?
En plus, il ne faut pas oublier qu'en Ada, un identifiant n'existe que dans un contexte comme une fonction, une procédure ou un package.
[^] # Re: Majuscule ?
Posté par claudex . Évalué à 4.
Oui, ce n'est pas pour ça que ce n'est pas utile.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Majuscule ?
Posté par barmic . Évalué à 2.
Non. Plus à partir du moment où tu as des standards qui sont admis par la majorité (ce que semble indiquer ton commentaire au dessus).
Ça crée bien moins de pièges potentiels dans le code (si tout le monde suit une même règle sauf une minorité). Après il faut que ce soit bien fait bien évidement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Mmmh
Posté par groumly . Évalué à 7.
C'est plutot facile, mais c'est malheureusement completement faux.
Bon, pour l'heure mod 24, ok, mais pour les annees, 366 ca le fait pas du tout (le compilo ne t'empechera pas de creer une annee bisextile invalide), et pour les secondes, ca le fait jusqu'a ce que tu tombes sur une leap second, et j'abordes meme pas le sujet des heures d'ete/hiver ou des timezones, et autres trucs joyeux omme les divers calendriers.
Si ya un truc qui se represente pas avec un simple type tout con, c'est bien les dates et la mesure du temps en general.
Bon, ca veut pas dire que ce genre de typage est pas pratique, mais t'aurais pu prendre un exemple un peu moins casse gueule.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mmmh
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Surtout qu'il y a grosso modo ce qu'il faut dans la norme mais dans le principe, c'est quand même ça.
[^] # Re: Mmmh
Posté par CrEv (site web personnel) . Évalué à 3.
Attends, que je comprenne bien :
type Hour is mod 24;Et là
Ha oui mais non
Bon alors, c'est bon ou c'est pas bon ?
Pour les jours ok, j'aurais du prendre l'exemple dans le commentaire juste en dessous, qui contient donc
Et pourtant, tous les mois n'ont pas 31 jours…
Et pour l'explication de texte :
-> en reprenant le principe de typer plus finement
-> ce qui suit est un exemple d'intervalle
Ou alors mon exemple portait surtout sur l'heure, le reste n'étant qu'un exemple d'intervalle et toi tu as juste pris la mouche ;-)
Après je suis d'accord sur le fait que c'était simpliste, que les dates, les leap secondes et autre c'est casse gueule. Mais c'était juste un exemple pour présenter d'autres façon de typer.
[^] # Re: Mmmh
Posté par barmic . Évalué à 2.
Tu as tout de même donné l'exemple des jours dans l'année.
Je trouve ça remarque pertinente car oui ce principe est assez génial. Tu peut créer 2 types d'entiers qui sont identiques (représente le même ensemble d'entier), mais ne sont pas utilisables les uns avec les autres (il paraît que c'est l'un des grands cas d'usage qui a poussé ce langage : ne pas mélanger les unités).
Mais il y a assez souvent des types plus complexe qu'un sous ensemble d'un type de base (qui possèdent des règles métier plus ou moins complexes) et à ce moment là c'est trucs là ne te servent à rien et trop s'appuyer (croire qu'on a codé les règles métier alors que ce n'est pas complètement le cas) est un piège à éviter.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mmmh
Posté par lasher . Évalué à 4.
Alors j'ai une remarque et une question.
Ma remarque d'abord :
"sa" (désolé mais ça me piquait les n'œils).
La question ensuite :
Bien que je sois d'accord sur l'utilité évidente d'établir des plages de valeurs pour un « même type » directement dans le langage, au final ça revient malgré tout à créer deux types différents et laisser le système de typage (fort) faire son boulot. En C++ on ferait sans doute ça en créant une interface avec template, quelque chose qui aurait une interface du genre:
… Avec toutes les opérations de surcharges d'opérateurs qui vont bien œuf corse (qui peut être facilité grâce à l'utilisation de Boost). Au final le système de typage ferait aussi son boulot.
Certes la syntaxe est peut-être moins sexy, mais le résultat (et surtout l'utilisation !) serait la même (une exception serait lancée si on tente d'affecter un nombre trop grand à un entier de type u16 par ex). Mon exemple montre même un cas qui serait sans doute résolu à la compil, comme en Ada.
[^] # Re: Mmmh
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Sauf que tu vas devoir te le faire ton template ainsi que les opérations qui vont bien avec, c'est justement tout ça que tu n'as pas à faire en Ada et c'est le compilateur qui te génère les opérations de base et des assert qui vont bien dans ton code que tu peux retirer une fois le code en prod si tu es vraiment sûr de toi.
La syntaxe n'est pas moins sexy, elle s'arrête à la définition du type, c'est tout !!
D'ailleurs, il n'a jamais été dit qu'on ne pouvait pas faire la même chose dans les autres langages. La différence réside dans le fait qu'il faut les faire :)
[^] # Re: Mmmh
Posté par claudex . Évalué à 5.
Mais tu ne dois le faire qu'une fois. Ça ne me semble pas énorme comme boulot.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mmmh
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
C'est vrai, c'est pas énorme mais il ne faudra pas oublier de gérer le wrap around et tous les problèmes qui vont avec.
Mais sinon, pour ceux-là, ça marchera aussi ?
Sans compter que sur les types énumérés, on peut maintenant faire des prédicats pour constituer des ensembles disjoints (voir cette gemme)
[^] # Re: Mmmh
Posté par claudex . Évalué à 4.
Je ne connais pas du tout Ada, alors je ne suis pas sûr mais les deux premiers me semble faisable. La troisième demande plus de connaissance des templates que ce que j'ai pour répondre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mmmh
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Bon, j'ai trouvé ça et tu seras d'accord pour dire que c'est moins sexy :D
En tout cas, ça marche en C++ et ça ne me choque pas du tout.
La seule différence est que ce ne sera détecté qu'au runtime.
[^] # Re: Mmmh
Posté par claudex . Évalué à 4.
Je suis tout à fait d'accord pour dire que c'est moins sexy (mais il suffirait d'un peu de sucre syntaxique pour corriger ça).
Oui, je pensais qu'il y avait moyen de le faire à la compilation mais je ne retrouve rien de tel, j'ai dû confondre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mmmh
Posté par lasher . Évalué à 1.
Je ne comprends pas bien.
Soit je peux déterminer, à la compilation, la valeur d'une variable dont je veux limiter la plage de valeurs. Dans ce cas, je ne vois pas bien où est le souci (un peu de méta-programmation avec les templates permettra de régler le problème, un peu comme avec la solution d'utiliser les « static asserts » de Boost, Loki ou autres bibliothèques). Soit on ne connaît pas la valeur de la variable à la compilation, et oui bien entendu il faudra évaluer à l'exécution. Mais je ne vois pas en quoi ce serait différent avec Ada.
[^] # Re: Mmmh
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Et bien, il est là le problème. On part d'une solution à base d'un template et on continue en rajoutant un soupçon de meta-programming pour obtenir les mêmes résultats.
Donc la déclaration d'un type en une ligne en Ada demande nettement plus de code en C++ mais encore une fois, je n'ai dit nulle part que c'était infaisable en C++.
Exact et le compilateur Ada ne dira effectivement rien.
[^] # Re: Mmmh
Posté par barmic . Évalué à 0.
Les concepts manipulés en ADA pour faire la même chose sont surtout nettement plus simples (et moins puissant).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mmmh
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Certes mais restons raisonnables. Là, on est en train de comparer la déclaration de type avec les templates. Si on parle de généricité alors parlons des generics en Ada.
Et effectivement, les generics Ada ne permettent pas la méta-programmation (voir wikipedia) et possèdent d'autres limitations que le C++ n'a pas.
Voilà, on n'aura donc pas réussi à éviter le troll des langages :-/
[^] # Re: Mmmh
Posté par lasher . Évalué à 2.
Pour moi c'était pas tant un troll, que d'essayer de pousser la logique et comprendre jusqu'où cette feature est utile. Mes questions, aussi enquiquinantes soient-elles, sont de vraies questions, et ne sont pas là pour faire de la provoc' pure et dure. :-)
[^] # Re: Mmmh
Posté par barmic . Évalué à 5.
Ce n'est pas parce qu'on compare la manière d'implémenter quelque chose dans 2 langages différents que c'est du troll.
ADA possède des mécanismes pour répondre à ce besoin précis.
C++ possède des mécanismes qui entre autre permettent de faire ça (mais les template étant turing complet tu peut faire des tas d'autres choses avec comme faire planter ton compilateur¹).
¹ : là c'est du troll :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mmmh
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 27 juin 2013 à 10:43.
Sauf que dans un cas, c'est à toi de faire l'implémentation et dans l'autre pas.
Non, C++ possède des mécanismes qui permettent de l'implémenter soi-même, ce n'est pas la même chose.
Si on va dans ce sens, l'assembleur possède aussi les mécanismes qui permettent, entre autres, de le faire.
[^] # Re: Mmmh
Posté par lasher . Évalué à 3.
Oui, mais une fois que tu as codé ton truc avec des milliards de templates affreux, tu as sans doute une interface simple à utiliser (du genre de ce que je proposais). Et c'est écrit une fois pour toutes, et fonctionnera pour toutes les classes qui ont un comportement « prévisible » (i.e. qui implémentent les opérateurs de comparaison, affectation, etc., selon un mode de fonctionnement similaire aux opérations utilisables sur les types primitifs).
Note que je ne nie pas que le fait que ce soit intégré au langage soit une excellente chose; juste que à partir du moment où tu voudras utiliser des objets plus complexes, je ne suis pas certain que tu ne finiras pas, même en Ada, avec une solution usine à gaz potentiellement plus compliquée à mettre en œuvre que ma bête solution en C++.
Pour info, je me considère comme « moyen » en C++ pour le langage lui-même, et j'ai mis moins d'une heure¹ pour créer un template de classe qui vérifie dynamiquement les bornes; je sais comment faire la même chose statiquement en théorie, mais comme je pratique peu la méta-programmation, il est évident que ça me prendrait beaucoup plus de temps à correctement programmer. Ceci étant dit, programmer la fonctionnalité des plages dans un compilateur Ada n'est pas nécessairement moins compliquée, et dans les deux cas, l'utilisateur final n'a pas à regarder l'implémentation. ;-)
[1] Évidemment, l'implémentation est sans doute ultra trouée dès qu'on utilisera un type non primitif. Heureusement, le compilo gueulera très certainement… ;-)²
[2] Et aussi, je tends à réduire l'utilisation des templates au minimum vital. Je n'y ai recours que lorsque les gains vont clairement outrepasser la chiantitude à implémenter et déboguer l'implém.
[^] # Re: Mmmh
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
On est bien d'accord. Si le problème est compliqué, il y a peu de chances que sa solution soit très simple :)
Là aussi, je ne peux qu'aller dans ton sens parce que je ne garde pas que de bons souvenirs de mes templates C++ notamment sur le débogage :D
Mais comme le disait Michel, c'est ultra-puissant donc il n'y a pas de mystère, ça peut devenir compliqué.
[^] # Re: Mmmh
Posté par lasher . Évalué à 2.
Si je fais
Je ne vois pas trop ce qui est gênant (contrairement au C, C++ n'acceptera pas qu'on substitue un
intà unenumn'importe comment).[^] # Re: Mmmh
Posté par lasher . Évalué à 2.
Oui, j'aurais dû être plus précis, car c'était bien là que je voulais en venir.
# Exemple grâce à un ordinateur de vote ES&S iVotronic
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Pour illustrer l'intérêt de ce genre de vérifications, voici un cas réel vu sur un ordinateur de vote/machine à voter de type ES&S iVotronic, correspondant à l'heure et la date d'ouverture du scrutin : « Ouvert 65516:65525:65502 64800/01/1994 » (cf présentation à PSES2013).
# Que du bonheur (pour toi)
Posté par pyknite . Évalué à 2.
Si tu as autant apprecié la déclaration des nouveaux types je pense que quand tu vas découvrir la gestion de la généricité, la gestion de variable partagée dans les threads (ainsi que les rendez-vous, …) et le reste, tu vas mouiller ton caleçon ;)
[^] # Re: Que du bonheur (pour toi)
Posté par CrEv (site web personnel) . Évalué à 3.
J'en suis tout chose rien qu'à l'idée ;-)
Ce qui est pas mal c'est que les personnes qui parlent d'Ada semblent tout de même plutôt contentes du langage et de ces possibilités.
Mais par contre, pour vous, c'est quoi les points négatifs si on prend du ada 2005 ou 2012 ?
[^] # Re: Que du bonheur (pour toi)
Posté par pyknite . Évalué à 1.
Alors la aucune idée… Pour moi l'ada ça reste juste le langage très chiant que je me suis tapé pendant presque 2 ans en école d'ingé ;)
Sauf pour la programmation concurrente, la, ça dépote (et qu'on vienne pas me dire que en C ou en Java c'est mieux (de toute façon le Java, c'est pour les bisounours ))!
[^] # Re: Que du bonheur (pour toi)
Posté par CrEv (site web personnel) . Évalué à 2.
En quoi c'était très chiant ? (histoire de comprendre un peu)
[^] # Re: Que du bonheur (pour toi)
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Parce qu'on peut pas le hacker facilement :D
En école d'ingé, on code et on voit après et du coup, c'est très lourd parce que le compilo n'arrête pas de brider la créativité du développeur.
En vieillissant, on en a marre de corriger sans cesse les mêmes bugs cons et on préfère se poser pour réfléchir. L'impulsivité de la jeunesse contre la Sagesse quoi :D
# où faire de l'ada
Posté par CrEv (site web personnel) . Évalué à 2.
Une question un poil annexe, mais vu qu'il y a du monde qui semble en faire : où faire de l'ada (professionnellement j'entends) ? Une transition depuis du web/js/java ça se fait facilement ?
(ben quoi, c'est que ça me semble intéressant, aussi bien le langage que, j'ai l'impression, l'envie de programmer proprement)
[^] # Re: où faire de l'ada
Posté par grim7reaper . Évalué à 1.
Il me semble que de manière générale, Ada est quand même pas mal cantonné à l’informatique embarquée.
Ça risque de faire un sacré gap par rapport à Web/JS/Java.
[^] # Re: où faire de l'ada
Posté par CrEv (site web personnel) . Évalué à 2.
A part l'embarqué et le temps réel on ne l'utilise pas / peu ? Pourtant le langage pourrait vraiment être intéressant pour aider a faire de meilleurs softs, non ?
C'est probable… bon pendant un temps je faisais aussi du C++, c'était pas de l'embarqué non plus. (et après faut pas croire mais en java on peut aussi faire des gros trucs sympa, genre basé sur hadoop, du distribué, etc)
[^] # Re: où faire de l'ada
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Ben ouais mais vas faire comprendre ça autour de toi et tu verras que c'est vraiment pas la mode.
Pourtant on sait même faire du Web avec Ada, la preuve :D
Oui mais ça non plus, c'est plus la mode. J'ai même entendu dire par un collègue :
[^] # Re: où faire de l'ada
Posté par CrEv (site web personnel) . Évalué à 2.
Oui j'ai vu qu'il y avait AWS par exemple.
Mais même pour le web, dans pas mal de cas il pourrait très bien y avoir des serveurs (de traitement) en Ada et les frontaux en ckonveut (java, ruby, js, etc)
Mais c'est quand même triste de voir que "les gens" ne veulent pas vraiment la qualité, que ce n'est pas à la mode.
Je me souviens un jour où j'ai proposé qu'on envisage la programmation par contrat dans du java (avec par exemple cofoja). La tête des autres développeurs, et surtout le « ça ne sert à rien »
-_-'[^] # Re: où faire de l'ada
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
La qualité, ça coûte toujours trop et on préfère privilégier le time to market à la qualité quitte à passer des lustres à fournir des patchs.
Le probèleme en Ada, c'est que le développement est nécessairement plus long car il faut d'emblée se poser les bonnes questions plutôt que de hacker un truc vite fait.
[^] # Re: où faire de l'ada
Posté par grim7reaper . Évalué à 1.
Bah disons que je l’ai très rarement vu ailleurs (pas jamais, mais très rarement). Mais bon ça ne reste que mon expérience personnelle.
En théorie oui (bien que je ne pense pas que ça soit le langage miracle qui peut s’utiliser partout, mais dans un certain nombres de cas oui clairement).
Mais bon, entre ce qui est très bien théoriquement et ce qui est très utilisé réellement, il y a un gouffre en général…
Oui, je me doute.
Ma remarque ne sous-entendais pas que ceux qui font du dev’ web/JS/Java sont des sous-dev et qu’ils font uniquement des trucs simples.
Je voulais juste dire que les contraintes, exigences et problématiques rencontrées sont vraiment très différente.
[^] # Re: où faire de l'ada
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Dans le spatial, l'aéronautique, la défense, le transport majoritairement que ce soit chez l'éditeur de logiciels ou en SSII.
Par exemple :
- Sur LinkedIn en étant connecté :)
- Directement sur les sites concernés comme MBDA ou Sagem Défense (certes, sur celle-là, on demande de l'expérience compte tenu du domaine mais si tu as de l'expérience en C, tu peux déjà postuler)
Mais bon, il ne faut pas se leurrer, le langage n'est pas à la mode (cf. ce post) donc les offres de boulot ne sont pas légion.
Le gros problème risque d'être lié au fait que dans beaucoup de cas, on trouve Ada dans des systèmes temps réel et/ou critiques où les problématiques sont assez éloignées du développement Web. Dans ce cas, ce n'est pas le langage qui risque de poser problème mais plutôt son environnement.
Par contre, la transition vers Ada en tant qu'apprentissage d'une nouvelle techno ne pose pas de problème.
[^] # Re: où faire de l'ada
Posté par CrEv (site web personnel) . Évalué à 2.
Ce qui peut aussi être un avantage pour ceux voulant en faire, non ?
Ce qui s'apprend, non ? Sachant que j'ai une formation initiale plutôt orienté industrie que web (et en fait pas spécifiquement info)
C'est déjà ça :-) Au pire ça me fera juste un langage de plus
[^] # Re: où faire de l'ada
Posté par Alex . Évalué à 2.
l'anssi ils développent un kernel en ada
[^] # Re: où faire de l'ada
Posté par pyknite . Évalué à 2.
Pas mal d'application qui nécessite une certaine robustesse (les trucs qui font bio-bip dans les hopitaux, les distributeurs de monnaie (j'ai vu une "raised PROGRAM_ERROR" sur un distributer de la poste (suisse)),…).
[^] # Re: où faire de l'ada
Posté par lancelotsix . Évalué à 1.
Je ne sais pas encore, mais dès que j'ai réussi à trouver pour moi je te dis ;)
Comme ça a été mentionné, Ada est assez cantonné à des domaines particuliers (embarqué / temps réel / critique) qui peuvent demander de justifier du bon «background» et d'une expérience différente de celle nécessaire à du web.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.