OK, merci pour ta réponse claire ! Elle confirme mon impression première... Mon intérêt portait sur la possibilité de programmation mixte. À ce que j'ai compris de mes lectures, les anciennes version de GHC avaient la possibilité de générer un source en langage C mais ce ne serait plus le cas aujourd'hui. J'ai vu un tutoriel où, dans le cas d'un main en C, la procédure écrite en GHC doit au préalable être initialisée (ce qui me faisait pencher pour un interpréteur embarqué).
Il en découle qu'il ne semble pas avoir d'avenir pour GHC pour jouer avec des interfaces graphiques (GTK ou QT) qui sont le plus souvent écrites en C/C++ . Reste, peut-être, les Widgets interprétées ?
Concernant GHC en tant que substitut au C++ dans le domaine du calcul intensif, je m'interroge : quitte à s'investir intellectuellement dans l'apprentissage d'un nouveau langage, pourquoi ne pas préférer Fortran (version F2015, pas F77 !) ?
Ceci étant, concernant la galère que représente la chaîne de compilation classique (autotools) du C, ou pire de Fortran, GHC est apparemment infiniment plus confortable.
En définitive, la fabrication d'un exécutable et son paquetage est une punition injuste avec les anciens langages. Le processus standard actuel est une survivance de l'époque où les ordinateurs étaient si faibles qu'il mettaient un temps fou à compiler. D'où les Makefiles actuels (et leur cortège d'utilitaires atroces) qui n'ont plus de raison d'être avec les machines d'aujourd'hui. Alors oui, qu'est-ce qui est le plus simple : créer un nouveau langage avec un processus de compilation/paquetage indolore ou bien dépoussiérer l'existant ?
[^] # Re: Haskell pour les nuls
Posté par Denis Bernard . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 1.
OK, merci pour ta réponse claire ! Elle confirme mon impression première... Mon intérêt portait sur la possibilité de programmation mixte. À ce que j'ai compris de mes lectures, les anciennes version de GHC avaient la possibilité de générer un source en langage C mais ce ne serait plus le cas aujourd'hui. J'ai vu un tutoriel où, dans le cas d'un
mainen C, la procédure écrite en GHC doit au préalable être initialisée (ce qui me faisait pencher pour un interpréteur embarqué).Il en découle qu'il ne semble pas avoir d'avenir pour GHC pour jouer avec des interfaces graphiques (GTK ou QT) qui sont le plus souvent écrites en C/C++ . Reste, peut-être, les Widgets interprétées ?
Concernant GHC en tant que substitut au C++ dans le domaine du calcul intensif, je m'interroge : quitte à s'investir intellectuellement dans l'apprentissage d'un nouveau langage, pourquoi ne pas préférer Fortran (version F2015, pas F77 !) ?
Ceci étant, concernant la galère que représente la chaîne de compilation classique (autotools) du C, ou pire de Fortran, GHC est apparemment infiniment plus confortable.
En définitive, la fabrication d'un exécutable et son paquetage est une punition injuste avec les anciens langages. Le processus standard actuel est une survivance de l'époque où les ordinateurs étaient si faibles qu'il mettaient un temps fou à compiler. D'où les Makefiles actuels (et leur cortège d'utilitaires atroces) qui n'ont plus de raison d'être avec les machines d'aujourd'hui. Alors oui, qu'est-ce qui est le plus simple : créer un nouveau langage avec un processus de compilation/paquetage indolore ou bien dépoussiérer l'existant ?