Discussion :

[bassim]

Sur certains points.
Il me semble pas avoir lu qu'Anubis avait pour but de remplacer Java ou C#. C'est une philosophie différente.

Ben le concepteur du langage dis qu'Anubis est à vocation universelle .

Si tu crois que faire des boucles est indispensable pour l'algorithmique, tu te trompes lourdement. Et tu as beaucoup de choses à apprendre, choses qui te seront utiles même si tu te limites à Java/C#/C++.

Je n'ai jamais dis que c'était indispensable, mais la récursivité non plus

Je crois que ton point de vue est biaisé, je pense que tu raisonnes en impératif

Non, je raisonnais en Objet
Pour la programmation fonctionnelle je connais pas mais je suis ouvert à tout type de programmation pourvu qu'elle me soit utile.

mais je sais aussi que l'on peut très bien s'en passer

d'accord

Quel est le problème avec un langage n'ayant pas d'exceptions ? Si toutes les valeurs de retour sont correctement utilisées (et surtout, ne jamais avoir la valeur "null", qui est un problème de beaucoup de langages), ça me semble réalisable.

Si c'est réalisable (comme le prétends Anubis), j'attends qu'à voir le résultat sur un vrai projet de Moyenne/Grande envergure

[LLB]

Ben le concepteur du langage dis qu'Anubis est à vocation universelle.

Mais je ne crois pas qu'Anubis puisse concurrencer Ruby/Perl/Python dans leur domaine, ni Java/.NET au niveau des bibliothèques. C'est un langage généraliste (en ce sens que l'on peut faire à peu près tout), mais orienté vers les applications nécessitant de la sécurité.

Je n'ai jamais dis que c'était indispensable, mais la récursivité non plus

Certes. Mais d'un point de vue théorique, la récursion est souvent plus simple à analyser que les boucles, et il l'explique. Le principal avantage, c'est qu'on peut facilement éviter tout effet de bord (cf Haskell). Si un langage n'a pas de boucles, ça ne me dérange pas trop (je m'en sers très rarement).

Non, je raisonnais en Objet

De l'objet... avec des effets de bord.

Pour la programmation fonctionnelle je connais pas mais je suis ouvert à tout type de programmation pourvu qu'elle me soit utile.

Cf Caml, Haskell, Lisp, F#...
Ca me semble très important, pour un programmeur, de connaitre les bases de la programmation fonctionnelle. Dans beaucoup d'écoles, c'est étudié.

Si c'est réalisable (comme le prétends Anubis), j'attends qu'à voir le résultat sur un vrai projet de Moyenne/Grande envergure

Par exemple, prends OCaml. Tu peux coder sans utiliser d'exceptions. Et tu peux adapter les fonctions de la bibliothèque qui en utilisent, pour renvoyer un type option (maybe, dans Haskell). Je te garantis que c'est utilisable, mais c'est certes moins agréable quand on n'a pas l'habitude.

Ne pas avoir d'exceptions (Anubis, C...) exige juste une plus grande rigueur. En Anubis, contrairement au C, le compilateur peut vérifier énormément de choses. Donc, si on manque de rigueur, le compilateur le remarque.

[alex_pi]

Par exemple, prends OCaml. Tu peux coder sans utiliser d'exceptions.

Non, ils sont dans la librairie standard, et tu ne peux rien y faire (proprement). Un exemple typique (et une de mes grosses critiques à l'encontre d'Anubis) est l'accès au tableau, qui déclanchera une exception en cas d'accès hors borne. Alors oui, tu peux utiliser un accès "unsafe" en OCaml, mais c'est plus que déconseillé !

[LLB]

Oui, certes. Mais on peut les utiliser que très rarement, en utilisant par exemple des fonctions chapeau qui les intercepte. En bricolant deux, trois trucs, on doit avoir un bon aperçu de ce que ça donnerait. Bien sûr, ce raisonnement peut s'adapter à beaucoup d'autres langages.

Pour l'accès au tableau, tu as raison, j'avais oublié qu'il n'est pas redéfinissable en Caml (contrairement à F#). Mais bon, c'est un détail.

[alex_pi]

Oui, certes. Mais on peut les utiliser que très rarement, en utilisant par exemple des fonctions chapeau qui les intercepte. En bricolant deux, trois trucs, on doit avoir un bon aperçu de ce que ça donnerait. Bien sûr, ce raisonnement peut s'adapter à beaucoup d'autres langages.

Je ne pense pas qu'il y ait le moindre intéret de "bricoler" justement puisque les exceptions sont un gros plus par rapport aux vieux langages sans exception où il fallait faire moulte tests sur la valeur de retour pour savoir si ça c'était bien passé ou non.

Pour l'accès au tableau, tu as raison, j'avais oublié qu'il n'est pas redéfinissable en Caml (contrairement à F#). Mais bon, c'est un détail.

En OCaml tu as

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
val unsafe_get : 'a array -> int -> 'a

val unsafe_set : 'a array -> int -> 'a -> unit

qui portent bien leur nom

[Jedai]

Mais je ne crois pas qu'Anubis puisse concurrencer Ruby/Perl/Python dans leur domaine, ni Java/.NET au niveau des bibliothèques. C'est un langage généraliste (en ce sens que l'on peut faire à peu près tout), mais orienté vers les applications nécessitant de la sécurité.

Anubis est extrêmement verbeux et de ce fait n'est sûrement pas très approprié à l'écriture de petits programmes comme en Ruby/Perl/Python, néanmoins Haskell a dans ce domaine de grandes qualités, et j'en veux pour preuve cet exemple de recodage en Haskell de bon nombres de petits outils shell.

--
Jedaï

[InOCamlWeTrust]

Les applications nécessitant la sécurité ne peuvent écrites qu'en C, le seul langage offrant un contrôle total quant au déroulement des erreurs/exceptions (les signaux et les valeurs de errno principalement, mais pas seulement...) et leur nature. Tous les autres langages cités sont bons pour de l'applicatif, mais pas pour de la sécurité : il n'est même pas possible de savoir si une erreur s'est produite lors de l'allocation d'une ressource... donc pour de la sécurité, c'est un peu raté !

[gorgonite]

Les applications nécessitant la sécurité ne peuvent écrites qu'en C, le seul langage offrant un contrôle total quant au déroulement des erreurs/exceptions

je ne suis pas totalement d'accord...

le C permet un controle très fin de ce que l'on fait (mais l'assembleur est encore plus fin )

sinon, il faut voir ce qui est important de surveiller... si l'on utilise pas de structures complexes et des allocations dynamiques, il y a quand même moyen de faire sur avec d'autres langages

[DrTopos]

Les applications nécessitant la sécurité ne peuvent écrites qu'en C, le seul langage offrant un contrôle total quant au déroulement des erreurs/exceptions (les signaux et les valeurs de errno principalement, mais pas seulement...) et leur nature. Tous les autres langages cités sont bons pour de l'applicatif, mais pas pour de la sécurité : il n'est même pas possible de savoir si une erreur s'est produite lors de l'allocation d'une ressource... donc pour de la sécurité, c'est un peu raté !

Tu es gentil, mais il ne faut quand même pas exagérer. En Anubis, une demande d'allocation de ressource (fichier, connexion, fenêtre graphique, etc...) renvoie toujours une donnée d'un type du genre ``Maybe(Ressource)''. Non seulement, on sait si la ressource a été allouée, mais en plus contrairement au C et à de nombreux autres langages (y compris fonctionnels), on est obligé de traiter le cas d'absence de ressource de suite directement dans le code. D'ailleurs, les primitives d'Anubis (qui sont en C justement) capturent les signaux et consultent les errno, pour fabriquer la bonne réponse. A mon sens, la façon dont j'ai implémenté ces primitives est ce qu'on pouvait faire de plus sûr. D'ailleurs, je rappelle que tout au long de ce projet, la sûreté a été mon principal objectif, bien avant les performances et le confort des programmeurs.

C'est bien de critiquer et c'est utile, mais quand ça ne correspond pas à la réalité, cela ne peut qu'induire en erreur, et ce n'est plus très honnête.

[Jedai]

Les applications nécessitant la sécurité ne peuvent écrites qu'en C, le seul langage offrant un contrôle total quant au déroulement des erreurs/exceptions (les signaux et les valeurs de errno principalement, mais pas seulement...) et leur nature. Tous les autres langages cités sont bons pour de l'applicatif, mais pas pour de la sécurité : il n'est même pas possible de savoir si une erreur s'est produite lors de l'allocation d'une ressource... donc pour de la sécurité, c'est un peu raté !

Drôle d'affirmation, je dirais plutôt qu'il vaut mieux éviter C pour la sécurité (tout dépend de ce que tu entends par sécurité bien sûr, moi je pense à "programme qui ne fait que ce qu'il doit faire et meurt proprement si on lui demande des actions illégales ou refuse de les effectuer", donc de l'applicatif peut parfaitement être sécurisé, ce sont des classifications indépendantes). Une erreur lors de l'allocation d'une ressource c'est typiquement une erreur non-récupérable sauf en C (sauf que le langage de haut-niveau essaiera sans doute de résoudre le problème lui-même avant d'abandonner), et heureusement !
J'ai l'impression que quand tu penses "sécurité" tu penses "temps-réel de bas niveau", ce n'est pas la même chose dans mon dictionnaire...

--
Jedaï

[alex_pi]

En Anubis, une demande d'allocation de ressource (fichier, connexion, fenêtre graphique, etc...) renvoie toujours une donnée d'un type du genre ``Maybe(Ressource)''. Non seulement, on sait si la ressource a été allouée, mais en plus contrairement au C et à de nombreux autres langages (y compris fonctionnels), on est obligé de traiter le cas d'absence de ressource de suite directement dans le code. D'ailleurs, les primitives d'Anubis (qui sont en C justement) capturent les signaux et consultent les errno, pour fabriquer la bonne réponse.

Justement, qu'en est-il des différentes erreur possible ? Parce que la vision "Maybe" est un peu tout noir ou tout blanc. Soit j'ai la ressource, je suis content, soit je ne l'ai pas, et c'est tant pis pour moi. Alors que la version "exception", c'est soit je l'ai, je suis content, soit je ne l'ai pas, et je regarde mon exception un peu plus en détail, et je me rends compte que c'est parceque le fichier n'existe pas, où que je n'ai pas les droits en lecture dessus, ou que... Donc qu'en est-il en Anubis (puisque c'est le sujet de ce thread, et non de savoir si pour faire un code sécuriser, il faut l'écrire en C...)

[LLB]

Regarde le code du serveur en Anubis : http://www.developpez.net/forums/sho...94&postcount=3

La fonction start_server renvoie soit ok, soit l'erreur. C'est donc une sorte d'extension du type type Maybe.

[DrTopos]

Regarde le code du serveur en Anubis : http://www.developpez.net/forums/sho...94&postcount=3

La fonction start_server renvoie soit ok, soit l'erreur. C'est donc une sorte d'extension du type type Maybe.

Effectivement, Maybe n'était qu'un exemple. On utilise aussi souvent le schéma Result($E,$R) défini comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
type Result($E,$R):
   error($E),
   ok($R).

C'est à dire qu'on a un type $R pour le résultat, et un autre $E pour les erreurs.

Par exemple, la primitive connect pour ouvrir une connexion TCP/IP est déclarée comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
public type NetworkConnectError:
  cannot_create_the_socket,
  address_port_not_available, 
  connection_refused, 
  network_unreachable,
  address_port_already_in_use,
  out_of_time. 
   
public define Result(NetworkConnectError,RWStream)
   connect(Int32 ip_address, 
                Int32 port).