Alors je te conseille de te renseigner sur le Nim, c'est exactement ça.Envoyé par Neckara
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Alors je te conseille de te renseigner sur le Nim, c'est exactement ça.
@Pyramidev
> On a donc besoin d'un meilleur C++, beaucoup plus rapide à
> compiler, plus simple à apprendre et, tant qu'à faire, encore
> plus riche. Peut-être le langage D. D'ailleurs, je me demande
> si ce dernier peut aussi remplacer Julia.
Je suppose que tu veux plutôt dire :
...si ce dernier peut aussi être remplacé par Julia
(dont la version 1.0 est attendue cette année, mais qui est déjà très utilisé
dans certaines communauté scientifique).
Pour C-for-all, je pense qu'il est un peu tard... sauf s'il est adopté
comme standard comme une évolution du C.
J'ai lu que Julia utilise un ramasse-miettes, donc ne permet pas de descendre à un niveau aussi bas que ne le permet le langage D, dans lequel on peut désactiver le ramasse-miettes.
D'ailleurs, en D, si on veut descendre aussi bas que le C, on peut utiliser l'option Better C qui désactive aussi d'autres fonctionnalités comme les exceptions.
Donc Julia ne peut pas remplacer le langage D.
Je ne sais pas encore si Julia supporte des fonctionnalités importantes que le D n'aurait pas. Je vérifierai. Pas aujourd'hui, mais c'est dans ma to-do list.
Prudence...
Pour moi C a toujours été une sorte d'assembleur compréhensible et portable, et je l'ai vu utilisé la plupart du temps dans ce contexte. Pour des fonctionnalités évoluées, C++ offre je crois à peu près tout ce dont on peut rêver. Sinon, pourquoi ne pas prendre un langage vraiment nouveau plutôt que de tordre C ? J'avais jeté un œil à Go par exemple... Mais est-il aussi performant que C ?
Il ne faut pas oublier qu'un développeur est aussi sensé savoir écrire un code capable de bien se comporter même si le langage qu'il doit utiliser n'offre pas le dernier machin à la mode.
Et que la course au langage parfait est parfois un masque pour la paresse et/ou l'incompétence.
C'est sûr, il y a des langages anecdotiques dans la liste : le brainfuck en est un bon exemple
Julia permet aussi d'appeler manuellement le ramasse miette ou le désactiver : Base.gc() et Base.gc_enable
Julia s'appuie sur LLVM qu'on peut manipuler directement (je n'ai cependant jamais joué avec cela !). On peut aussi afficherD'ailleurs, en D, si on veut descendre aussi bas que le C, on peut utiliser l'option Better C qui désactive aussi d'autres fonctionnalités comme les exceptions.
la traduction LLVM d'une méthode Julia particulière. Cette traduction peut-être complètement différente selon le type des paramètres d'entrée de la fonction (d'où l'importance du typage (facultatif) qui peut permettre des optimisations lors de la compilation JIT).
Il y a 20ans, Je trouvais que le langage D était très prometteur, et aujourd'hui... il est toujours très prometteur !Donc Julia ne peut pas remplacer le langage D.
Je ne sais pas encore si Julia supporte des fonctionnalités importantes que le D n'aurait pas. Je vérifierai. Pas aujourd'hui, mais c'est dans ma to-do list.
En attendant d'autres langages sont sortis et sont réellement utilisés (Go, Rust, ...).
Julia est à part car il cible le monde scientifique (matlab, R, C++) avec un écosystème moderne (Ruby, Go, piton, ...). Sa première version publique est apparue en 2012 et devrait voir sa version 1.0 (i.e stable au niveau des API) sortir cette année.
À propos du langage C, son intérêt est d'être une référence stable de bas niveau, universellement diffusée et surtout facile à interfacer.
C'est dommage qu'il n'ait pas évolué il y a une vingtaine d'année vers un C-for-all avec de la surcharge, une gestion d'exception des bibliothèques décente (string, ...).
-- Maurice
Justement , heureusement que le C reste encore assez "basique" son but pour ma part reste aussi que faire un compilateur C doit rester accessible , "facile".
Néanmoins je ne comprend pas cette mode de vouloir améliorer le langage C , le C a pas mal de défaut , il me semble plus intelligent de partir sur des nouvelles bases (comme le Rust ) que d'essayer de faire un C amélioré !
Merci pour l'info.
Ça, c'est le C++98, non ?
Sur ce point, je suis tout a fait d'accord. le problème des alternatives à C comme C2 ou C-for-all est qu'elles sont perdues entre l'envie de rester proche du C, dont la stabilité est une qualité autant qu'un défaut, et l'envie de vouloir offrir plus comme le fait déjà le C++.
Go peut remplacer C dans pas mal de situations, mais, comme Julia, il ne peut être considéré comme un langage avec des capacités système, notamment à cause de son ramasse miettes quasi-obligatoire.
Sauf que le langage Julia (comme pour le Go), n'a pas du tout été conçu pour marcher sans ramasse miette. Si tu désactives le ramasses miette, ton programme va consommer de plus en plus de mémoire jusqu'à en manquer. Désactiver le GC n'est faisable que pour les programmes à courte durée de vie dont on sait qu'il se termineront avant d'avoir utilisé trop de mémoire.
Par contre, là je ne suis pas d'accord. Aucun langage ne sera jamais parfait vu que les besoins de chacun sont différents, mais avoir un langage qui évite les erreurs est un gros plus.
Le développeur qui ne fait pas d'erreur est un mythe. Il suffit de regarder les release notes des correctifs des navigateurs, base de donnée, OS et autre logiciel très surveillés et donc pas développés par des amateurs incompétent. Au moins la moitié des failles auraient généralement pu être évitées avec des langages plus restrictif.
De plus un développeur est rarement seul donc quand on intervient sur une section de code qu'on a pas écrit soi même avoir des garanties sur le bon fonctionnement de certaines abstractions est une aide non négligeable.
Répondre avec citation
Partager