Oui si j'hésite vraiment je choisirait avec ce critère. Même pour les programmes du type "écrire un programme qui vérifie si il existe un mat en X coups pour une partie d’échec donnée, avec X < 100 par exemple", il faut faire attention aux détails ?
Pour qu'un algo de ce genre soit efficace, ça implique des structures de données un peu intelligentes. Donc de l'allocation dynamiques un peu futée, et des indirections bien placée, etc. Bref, ce ne sera pas un code basique donc oui, il faudra faire attention aux détails.
apzoeiruty3 a écrit:
Sinon pour bugs, certes peut être qu'il ne marche pas tout le temps mais encore une fois c'est pour un usage personnel donc j'ai pas envie de passer un temps énorme à savoir si les programmes vont marcher effectivement.
Autant avoir un langage qui ne t'impose pas ce boulot du coup. Et les langages de bas niveau ne sont pas connus pour faciliter cela.
C'est tellement proche que j'ai du mal à voir ce qu'il pourrait vraiment t'apporter d'incroyablement différent par rapport à OCaml. Quitte à prendre un langage plus formel autant y aller à fond : Coq, Isabelle, Agda (avec le "g", pas Ada).
Les deux sont fonctionnels mais Caml est impur tandis que Haskell est pur. Ça paraît rien mais ça change radicalement la façon de programmer. Haskell va beaucoup plus loin dans l'idéologie fonctionnelle. Caml ne permet pas de faire des raisonnements aussi puissants qu'avec Haskell. Aussi, j'ai tendance à observer que l'écosystème de Haskell est plus développé. Haskell s'inspire aussi d'autres maths que le lambda-calcul (base des langages fonctionnels) et a un système de type un peu plus évolué à mon goût.
Si tu veux prendre un langage fonctionnel, autant apprendre Haskell, à la rigueur OCaml, en tout cas pas Caml.
Je ne recommanderai pas des langages plus formels comme Coq, Agda ou Idris à l'inverse de Ksass`Peuk parce que ces langages ne sont pas du tout prêt (ni même destinés) à un emploi dans l'industrie. Ils sont très intéressant à apprendre, mais je doute qu'ils puissent un jour être utilisés efficacement dans le domaine professionnel. (Remarque, c'est ce qu'on disait avec Haskell il y a quelques années)
Si ça t'intéresse, en plus de Coq, Agda ou Idris, tu peux regarder Curry, qui est un mélange de Haskell et de Prolog (programmation logique fonctionnel pur). Mais bon, chaque chose en son temps, je te conseille d'abord de te concentrer sur Haskell avant de partir dans ces trucs un peu rigolos.
@Noking > J'hésitais justement à partir soit sur C soit sur C++ mais comme les langages datent je m'étais dit qu'il y avait d'autre langages plus pertinents à apprendre à l'heure actuelle.
Plus pertinent parce que plus récent ? Non pas forcément, regarde les sytèmes basés sur UNIX ou les protocoles réseaux, ils sont tous "vieux" et c'est parce que ça fonctionne très bien qu'on ne change pas justement ! Un langage qui "date" mais qui est toujours utilisé c'est un langage fiable qui a fait ses preuves ! Entre C et C++ (si tu choisis l'un d'entre eux à la fin) il faut choisir selon tes besoins : si tu as de gros projets qui nécessitent une techno objet etc, C++ sera mieux
LoupSolitaire a écrit:
apzoeiruty3 a écrit:
Idéalement il faudrait un langage qui impose une certaine rigueur dans l'écriture et qui ne présente pas les "comportements indéterminés" dont tu parles, mais je demande peut être beaucoup
Haskell ?
Désolé de relancer mais... C ?
Après bien sûr il n'y a pas que le C dans la vie, je voulais juste présenter les avantages qu'il y a. Certes il y a aussi des inconvénients, je considère que le choix doit être fait en fonction des affinités avec le langage et le type de projet qu'on souhaite mener !
Un langage qui "date" mais qui est toujours utilisé c'est un langage fiable qui a fait ses preuves !
C'est surtout parce que ça coûterait trop de temps et d'argent de tout redévelopper généralement. Partout dans le monde, il y a des systèmes qui sont encore là parce qu'on ne veut pas en refaire le développement depuis zéro. Pas parce qu'ils nous comblent. Linux est un parfait exemple de ça : c'est un bazar incroyable, il y a des bugs partout (on estime 15 en moyenne par milliers de lignes de code, jusqu'à 25 dans le code des drivers, sur un truc qui fait environ 18 millions de lignes), c'est très difficile à maintenir ... Seulement ça coûterait bien plus cher de redévelopper un truc clean à partir de rien (et sans garantie qu'on y arrive), donc on se contente.
J'ai pas de problèmes avec le fait d'apprendre C, mais on peut lire beaucoup trop de légendes à ce sujet (la pire étant : "en faisant du C, on comprend ce qui se passe dans la machine").
Oui du coup si c'est dans le même style que Caml je vais plus me contenter d'un autre langage, car les boucles while c'est pas mal aussi
Le C pourquoi pas mais Ksass `Peuk a l'air assez réticent quand même. D'ailleurs quand tu dit qu'on ne comprends pas ce qu'il se passe dans la machine ça veut dire quoi ? Car on doit allouer la mémoire en C non ? Et selon toi si on avait le temps, l'argent et la motivation de redev Linux on le ferait dans quel langage ?
Après c'est vrai que C c'est la base de pas mal de codes donc ça peut être intéressant de se plonger dans ce langage
Comme je l'ai dit, apprendre le C est intéressant (voir le post que j'ai mis bien plus tôt). Il y a pleins de choses qui ont un vrai apport pour mieux comprendre le développement :
gestion manuelle des ressources,
gestion des erreurs à tous les étages d'appels,
comprendre les idées qui amènent vers des abstractions de bas niveau,
et finalement la manipulation d'un langage très simpliste qui rend le développement complexe par conséquent.
Les points sur lesquels je m'oppose sont les légendes qui peuvent graviter autour de ce langage. Les systèmes écrits en C d'une fiabilité hors normes ne sont pas fiables parce qu'ils sont écrits en C. Ils sont fiables parce qu'énormément de temps et de compétences ont été allouées pour que ce soit le cas. Le compilateur le plus fiable pour le langage C, ce n'est pas GCC, c'est CompCert, et il n'est pas écrit en C, il est écrit en Coq. Un langage qui réclame de très fortes compétences, et pourtant je suis à peu près certain que CompCert a réclamé moins d'efforts de développement que GCC.
apzoeiruty3 a écrit:
(1) D'ailleurs quand tu dit qu'on ne comprends pas ce qu'il se passe dans la machine ça veut dire quoi ? (2) Car on doit allouer la mémoire en C non ?
(1) Ben ça veut dire ce que ça veut dire : quand on manipule C, on manipule l'abstraction qui nous est fournie par le langage C. Elle est certes de bas niveau, mais c'est déjà à mille lieues de la machine. En dessous de "malloc" qu'on utilise pour allouer, il y a la bibliothèque C, et puis encore en dessous, il y a plusieurs couches du système d'exploitation, qui passent notamment par le module de mémoire virtuelle et qui dialoguent avec plusieurs composants (le processeur, la MMU et le TLB), et ça, encore heureux, ça nous est complètement caché.
(2) Oui, dans les autres langages aussi. La différence c'est à quel point le mécanisme est implicite et comment est fabriqué le mécanisme de libération.
Idéalement il faudrait un langage qui impose une certaine rigueur dans l'écriture et qui ne présente pas les "comportements indéterminés" dont tu parles, mais je demande peut être beaucoup
Haskell ?
Désolé de relancer mais... C ?
Justement non, C possède plein de ces comportements indéterminés.
Idéalement il faudrait un langage qui impose une certaine rigueur dans l'écriture et qui ne présente pas les "comportements indéterminés" dont tu parles, mais je demande peut être beaucoup
Haskell ?
Désolé de relancer mais... C ?
Justement non, C possède plein de ces comportements indéterminés.
Pas vraiment, du moment qu'on ne cherche pas à taper sur n'importe quelle case mémoire et qu'on code rigoureusement, le comportement est déterminé ! Ou alors je me trompe mais dans ce cas je veux bien que tu nous expliques tes arguments
NoKing a écrit:
> Pas vraiment, du moment qu'on ne cherche pas à taper sur n'importe quelle case mémoire et qu'on code rigoureusement, le comportement est déterminé ! Ou alors je me trompe mais dans ce cas je veux bien que tu nous expliques tes arguments :)
Justement, ça peut arriver assez facilement sans chercher explicitement à taper n'importe où en mémoire.
Le C est bourré de comportements indéterminés.
Pas vraiment, du moment qu'on ne cherche pas à taper sur n'importe quelle case mémoire et qu'on code rigoureusement, le comportement est déterminé !
Et c'est tellement facile de faire ça que toutes les failles récentes d'OpenSSL sont justement dues à des accès merdeux de pointeurs. Bref, j'ai mis un tutoriel en lien plus haut à propos de la preuve de programmes C, montrer qu'un programme C est correct et ne contient pas d'accès pourris, c'est dur. Et plus important encore, ça rend le langage bien plus difficile à apprendre parce que justement ton programme peut avoir l'air de fonctionner même quand il est plein de bugs.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C