Bonjour.
Je m'intéresse depuis un moment aux langages fonctionnels, et je reste convaincu que ces langages représentent l'avenir de l'informatique (entendons-nous bien : je ne crois pas qu'ils remplaceront complêtement les autres langages, mais qu'ils remplaceront ceux-ci dans certains domaines, notamment dans le cadre de la programmation concurrente).
Je cherche s'il existe un langage fonctionnel permettant de faire de la programmation bas niveau comme en C. En connaissez-vous ?
# Pur ou pas ?
Posté par denxp . Évalué à 1. Dernière modification le 27 février 2015 à 15:46.
Si tu parles d'un langage fonctionnel pur, mise à part Haskell et Idris, qui pointe le bout du nez, je ne vois pas trop. J'appelerai pas ça "bas niveau" mais en terme de performance c'est pas mal, du moins pour Haskell : je n'ai pas encore essayer Idris.
Sinon il y a toujours rust, D et peut-être C++ (il doit bien y avoir des lambdas dans ce truc)
Bonus :-)
[^] # Re: Pur ou pas ?
Posté par totof2000 . Évalué à 2. Dernière modification le 27 février 2015 à 20:17.
Je ne cherche pas un langage fonctionnel pur, et le bas niveau, ce n'est ps tant pour les perfs que pour pouvoir accéder au matériel. A mon avis cet aspect devrait nécessiter quelues entorses à la pureté de laprogrammation fonctionnelle. Sinon, l'une des caractéristiques qui m'a intéressé dans les langages fonctonnels et qui est à mon avis un gros "bouclier à bugs" est l'immuabilité des variables, et par rapport au lien que tu as mentionné, c'est un gros défaut en C.
[^] # Re: Pur ou pas ?
Posté par denxp . Évalué à 1.
Alors Rust ou D en utilisant des objets immuables.
[^] # Re: Pur ou pas ?
Posté par freem . Évalué à 3.
Le C peut utiliser le mot-clé const, pour dire qu'une variable ne peux être modifiée. D'ailleurs, je trouve que le résultat est nettement plus agréable à utiliser que le traditionnel #define, qui, lui, en plus de ne pas vérifier la type, peut être undef. Erk!
Après, si le but c'est juste d'imbriquer des appels de fonctions sans pouvoir modifier le contenu des variables, je pense que tout langage permettant de définir une constante peut le faire. Si ce sont les lambdas qui t'intéressent, C++ peut le faire depuis C++11, et pourra même t'apporter un typage sûr des plus agréables comparé au C. Les templates sont aussi très sympa. Pas besoin d'utiliser l'objet, les exceptions et la RTTI si tu n'en veux pas (un langage purement fonctionnel pur ne doit pas utiliser ces concepts je suppose. Mais personnellement, je considère que les langages qui forcent leur utilisateur à ne penser que d'une façon sont limités. Le plus de paradigmes mon langage me permet d'utiliser, le mieux je me porte.).
[^] # Re: Pur ou pas ?
Posté par fearan . Évalué à 2.
Le seul soucis c'est que le compilo n'est pas adapté pour du fonctionnel, (mise à plat des fonctions récursive, optimisation de récursivité terminale…), mais rien n'empêche le compilo d'évoluer pour faire du fonctionnel.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Pur ou pas ?
Posté par freem . Évalué à 3.
On parle des compilo, ou des langages?
[^] # Re: Pur ou pas ?
Posté par totof2000 . Évalué à 2.
Je préfèrerais l'inverse : un langage ou par défaut la valeur de la variable soit immuable par défaut, et qu'un type particulier serve à définir une variable qui peut être modifiée.
Je ne veux pas d'un langage multi-paradigmes. Je veux un langage fonctionnel. Quand je disq ue je ne veux pas un langage fonctionnel "pur", je pense à un langage comme Erlang, qui n'est pas un langage fonctionnel pur mais n'est pas non plus un langage multi-paradigmes comme C++.
Personnellement je pense le contraire : utiliser un langage multi-paradigmes est une mauvaise idée: l'intérêt du langage fonctionnel est d'obtenir un code plus concis, plus clair et surtout permet d'éviter certains types de bugs. le multi-paradigme, c'est risquer de perdre les avantages du fonctionnel dans un bout de code qui ferait appel à du non-fonctionnel.
En tout cas merci quand même pour ton retour.
[^] # Re: Pur ou pas ?
Posté par GuieA_7 (site web personnel) . Évalué à 1.
Pour le coup OCaml (vers lequel tu semblais attiré, et c'est très bien) est multi-paradigme. En pratique l'approche fonctionnelle est privilégiée, mais le multi-paradigme n'est pas un mal en soit. Au contraire selon les problèmes un paradigme s'en sort mieux qu'un autre.
[^] # Re: Pur ou pas ?
Posté par totof2000 . Évalué à 2. Dernière modification le 02 mars 2015 à 15:05.
Merci pour l'info : je "cherche" effectivement ce type de langage : je n'ai pas encore eu le temps d'éplucher tous vos liens qui m'ont l'air intéressant(beaucoup de lecture en perspective, merci), ça risque de prendre un peu de temps. Et merci pour votre patience et vos réponses, même si j'ai émis des objections à celles-ci : pour tout vous dire, je ne sais pas exactement ce que je recherche, ou plutôt, j'ai du mal à l'exprimer de façon claire, et vos retours m'ont permis de mieux structurer mes idées et mes "exigences". Je vais "digérer" tout ce que vous m'avez indiqué, (en commençant par OCaml et Haskell) et je ferai peut-être un retour sous forme de journal si j'en ai le temps. Mais si entre temps d'autres idées vous viennent, n'hesitez pas à l'exprimer ici (+1 à tous ceux qui ont répondiu).
[^] # Re: Pur ou pas ?
Posté par freem . Évalué à 2.
Tant que c'est constructif, c'est positif :) (on dirait un mauvais slogan de mauvaise pub tiens…)
Je lirai ça avec un grand intérêt, les langages fonctionnels m'intriguent, mais je n'arrive pas à trouver la motivation pour m'y mettre. Sûrement parce que je ne connais pas leurs avantages, alors que je sais pourquoi j'aime C++ (et pourquoi je vais sûrement aimer Rust): typage fort (mais pas parfait, malheureusement: pour ça il faudrait casser la compat avec le C de manière brutale, et comme le C est la base des systèmes actuels…), RAII (qui permets l'absence de GC, notamment), multi-paradigme (procédural, objet, générique).
Donc, j'espère que tu auras le temps.
[^] # Re: Pur ou pas ?
Posté par freem . Évalué à 2.
Tu peux toujours définir des types constants, et t'y limiter. Personnellement, ça fait belle lurette que je n'utilise plus les types char, short, int et long: ils rendent les programmes peu portables, trop sensibles à un changement d'architecture ou de compilateur. Je leur préfère les FOOBAR_intXY_t. Si tu préfères des types constants par défaut, rien ne t'empêche de te faire un fichier qui définit des alias constants à coup de typedef.
Toutes les opinions se défendent.
Je n'ai vu dans tes réponses que l'argument de la constance. Dans ce cas, et dans le cas du C++, c'est faux: il est impossible (bon, ok, je mens: comme toujours en C++ on peut forcer la main au langage. La raison de cet état de fait, c'est que C++ est compatible avec le code crade, ce qui permets de nettoyer au fur et à mesure les bases… mais aussi de faire de la merde!) de modifier un objet via des méthodes marquées const. Il est aussi impossible de modifier tout paramètre constant passé de la même manière.
Personnellement, je me sers énormément du const, en m'inspirant de la programmation par contrat*.
Les autres avantages du fonctionnel, je ne les connais pas.
*: je vérifie systématiquement toutes mes pré-conditions.
Je ne fais que m'inspirer, parce que je ne vérifie jamais les invariants: beaucoup de code pour un intérêt très limité à mes yeux, le langage lui-même permettant une bonne sûreté de ce côté là, tant qu'on utilise pas friend à la légère et que l'on mets un maximum de chose en private, le tout couplé avec des classes réellement spécialisées.
[^] # Re: Pur ou pas ?
Posté par totof2000 . Évalué à 2.
Disons que j'ai un peu de mal à exprimer mon idée : il faudrait que je puisse te fournir des exemples pour que ce soit plus parlant : si je trouve le temps de faire le fameux journal, je pense que cde sera plus clair.
# C'est OCaml
Posté par Michaël (site web personnel) . Évalué à 4.
OCaml est le C des langages fonctionnels. L'assembleur généré est relativement lisible et associable au code écrit. Voilà quelques liens ou sujets:
Je pense que cela illustre assez bien les affinités «bas niveau» de ce fabuleux langage!
[^] # Re: C'est OCaml
Posté par totof2000 . Évalué à 2.
Merci, je vais regarder ça, C'est effectivement le genre de langage que je cherche. D'autres propositions sont les bienvenues.
[^] # Re: C'est OCaml
Posté par denxp . Évalué à 1.
Quelques projets bas niveau pour Haskell.
Il y a même un OS "entier"
# Que veut dire "bas niveau" ?
Posté par Zylabon . Évalué à 3.
Fondamentalement, les processeurs que nous utilisons sont très "impératifs", et pas fonctionnels. Il existe des processeurs qui exécutent du lisp, à ce titre, lisp est un langage "bas niveau", pour ces machines.
Sinon, un langage fonctionnel permettant de faire de la programmation bas niveau comme en C ? Pourquoi pas C ? Il ne lui manque que le ramasse miette, sinon tout est là.
Please do not feed the trolls
[^] # Re: Que veut dire "bas niveau" ?
Posté par totof2000 . Évalué à 2.
Il ne lui manque pas de ramasse-miettes, mais juste les variables immuables.
# C
Posté par max22 . Évalué à 2.
Bonne nouvelle, le C est un langage fonctionnel pur.
Un exemple ici.
[^] # Re: C
Posté par totof2000 . Évalué à 2.
Il lui manque un certain nombre de choses, par exemple l'optimisation de la récursion terminale.
[^] # Re: C
Posté par ninis666 . Évalué à 2.
C'est le compilo qui va gérer ma récursion terminale, pas le langage ….
[^] # Re: C
Posté par totof2000 . Évalué à 2.
Dans ce cas, je reformule ma question : existe-til un compilateur C qui ferait ce genre d'optimisation ?
[^] # Re: C
Posté par GuieA_7 (site web personnel) . Évalué à 2.
GCC au moins le fait depuis longtemps, au moins dans les niveaux d'optimisation les plus élevés
(http://stackoverflow.com/questions/490324/how-do-i-check-if-gcc-is-performing-tail-recursion-optimization => apparemment en 03 mais pas en 02). J'imagine que ce n'est pas le seul compilateur à le faire.
Mais bon ça n'en fait évidemment pas un langage fonctionnel.
[^] # Re: C
Posté par totof2000 . Évalué à 2.
Lien intéressant, bon à savoir. Ca peut servir par ailleurs. Merci ;)
[^] # Re: C
Posté par totof2000 . Évalué à 2.
A ma connaissance, le C ne permet pas ce genre d'optimisation : la récursion est limitée par la taille de la pile.
# Mezzo
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Leur ambition est d'obtenir quelque chose d'assez proche de Rust (au niveau de la gestion mémoire) me semble-t-il :
http://protz.github.io/mezzo/
https://github.com/protz/mezzo
Bon c'est un projet de recherche et je doute que ce soit une bonne idée en production, mais ça me semblait intéressant comme projet.
Sinon si c'est l'immuabilité qui t'intéresse (ce n'est pas le seul avantage du fonctionnel), alors Rust est un candidat intéressant. Si on oublie que la 1.0 n'est pas encore sortie (mais c'est pour bientôt) il a l'avantage par rapport à OCaml de ne pas avoir de GC et d'avoir des threads qui s'exécutent en parallèle ; en revanche le fait de se soucier des références (emprunt, temps de vie) rend le code plus complexe à écrire.
# Golang
Posté par Philippe Ivaldi (site web personnel) . Évalué à 1.
⚠ Troll inside ⚠
L'avenir de la programmation informatique passera par Go. C'est bas niveau si on veut, c'est fonctionnel si on veut, c'est objet si on veut, c'est nativement conçu pour la concurrence et la scalabilité, c'est open-source et enfin c'est développé par une des boîtes les plus réputées de la planète.
Que demander de plus ?
[^] # Re: Golang
Posté par Michaël (site web personnel) . Évalué à 4.
Quand on a un petit panneau “troll” devant son message, c'est presque une faute de goût de ne pas conclure par “c'est développé par les maîtres du monde.”
[^] # Re: Golang
Posté par GuieA_7 (site web personnel) . Évalué à 4.
Un langage expressif ?
# ATS
Posté par neil . Évalué à 2. Dernière modification le 07 mai 2015 à 20:37.
ATS possède un puissant système de types (avec, plus ou moins, types dépendents et linéaires) et des performances temps et mémoire proches du C. On peut typiquement écrire des noyaux avec tout en faisant de la preuve de programmes.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.