salut
où puis-je trouver de l'information sur les familles de langage de programmation ainsi que les type de programmation
merci








salut
où puis-je trouver de l'information sur les familles de langage de programmation ainsi que les type de programmation
merci
sans compter ici-même, cet excellent lien http://www.developpez.net/forums/...liens-arbre-langages-p700-langages-decouvrir/
Plusieurs constatations personnelles:
- c'est long d'apprendre un langage
- puisque c'est long il ne faut pas perdre de temps
- l'astuce pour ne pas perdre de temps c'est qu'il ne faut apprendre que 3 ou 4 langages
- une autre astuce c'est qu'il ne faut pas s'intéresser de près aux langages de scripts
- disons 3 langages, oui mais alors lesquels ?
- re-astuce: 1 langage de très bas niveau (et là tout ce qui n'est pas de l'ASM est bon à jeter) et ensuite 1 langage de très haut niveau (et là tout ce qui ne fait pas concurrence à Haskell est bon à jeter)
- souviron34 répondra peut être "
Haskell" mais moi je dis que si tu maîtrise l'ASM + Haskell alors tous les langages que peut te conseiller souviron (et même les 690 autres qu'il ne te conseillera pas) c'est fingers in the nose
- le C/C++ c'est du haut niveau par rapport à l'ASM et c'est du bas niveau par rapport à Haskell, c'est donc typiquement le genre de 3ième langage fingers in the nose
c'est malheureusement insultant de considérer que C++ est si bas niveau... il ne faut pas croire qu'il ne s'agit que C avec des classes, c'est bien plus que cela même si une majorité des utilisateurs ne semblent pas aller plus loin que ce qui pourrait se faire avec des langages plus limités comme Java et C#![]()
Haut/Bas niveau, je ne le vois pas comme une échelle de valeur, je pensais plutôt à un panel large, qui s'étend du tout "commande" au tout "déclaratif" et je conseillais de s'intéresser aux extrémités de ce spectre, ceci afin d'aborder avec plus de sérénité les langages plus réalistes ou plus "mainstream" qui font les compromis intéressants qui les placent à mi-chemin.
Après c'était peut être un mauvais conseil, à chacun de voir par lui-même et pour lui-même.
Ce que je trouve dommage c'est que sous prétexte que j'aurais heurté ta sensibilité, tu en profites pour glisser un vilain troll C++ vs. Java.
C++ peut aller quand même très loin dans le déclaratif.
Boost.Spirit, pour décrire une grammaire.
http://www.boost.org/doc/libs/1_36_0...c/grammar.html
http://www.boost.org/doc/libs/1_36_0...c_actions.html
J'ai tjrs trouvé ça magique, et c'est ça qui est bon !
Alors, moi je pense tu te trompes potentiellement sur le langage Haskell SpiceGuid.
Je ne le connais pas assez profondément pour le comparer aux autres langages fonctionnels mais je pense que c'est un langage qui procède des fonctionnalités des restreintes, qui est très désordonné et très rapidement incontrôlable. De plus c'est un surtout un langages structurellement compliqué, ce qui est loin d'être un atout.
Après...corrigez moi si je me trompe.
Sinon pour ce qui est de la sélection de langages, je suis à fait d'accord avec toi. Apprendre beaucoup de langages ne sert à rien. D'autant plus que lorsque l'on sait programmer en procédural (notions algorithmique), et que l'on connais un langage objet, si on doit programmer avec un langage différent, une simple adaptation au langage suffis.
ne pas confondre sensibilité et recherche de l'exactitude... et nul besoin de troller sur C++ vs Java vs C# quand il existe des arguments valables
bel exemple :
ce que je trouve dommage, c'est que sous prétexte qu'on décide ne pas devenir le supporter intransigeant d'un mode de pensée, on puisse croire que lorsqu'on nuance les arguments très approximatifs de personne connaissant mal un sujet, et on en vienne à crier au troll![]()
@Floriang33
Et encore il y a pire que papillonner avec de multiples langages: papillonner sur de multiple frameworks
Une situation énervante que je rencontre en C++ :
- je peux instancier une structure (là où je veux, n'importe où il y a la place)
- ou bien je peux instancier une classe
- par contre je ne peux pas instancier une classe comme une structure, c'est-à-dire là où je veux
Ça n'a l'air de rien mais pour moi c'est une limitation gênante.
Qu'appelles-tu donc "structurellement compliqué" ? Haskell a une syntaxe simple, son sytème de module est facile à comprendre et utiliser également.
Comment peux-tu dire que Haskell a des "fonctionnalités restreintes" ? Son système de type est un enrichissement de Hindley-Milner et est l'un des plus puissants en-dehors des types dépendants, il est également l'un des rares langage qui permette une complète séparation du code pur et du code à effet de bord, il a une bonne FFI, un bon nombre de librairies maintenant (Hackage) et un excellent support du multicoeur...
Et pour un langage "désordonné et très rapidement incontrolable", je trouve qu'un projet comme XMonad est bizarrement consistant. Un WM complet en 1000 lignes de code, complètement extensible, et extrêmement stable...
La plupart des programmeurs qui n'ont jamais connu que du procédural et de l'objet ont de grandes difficultés à se mettre au fonctionnel, plus ils ont passé de temps avec de l'impératif pur, plus ils ont de mal à comprendre le paradigme fonctionnel. De plus ton "une simple adaptation au langage suffit" est fort cavalier, il y a bien plus de différences même entre les langages impératifs que tu ne semble l'impliquer (gestion manuelle de la mémoire/GC, système de types, modèle objet, etc), évidemment si on se contente de naviguer parmi les cousins du C et du Java, tout va bien, mais en dehors...
--
Jedaï
Oui, expliqué comme ça...
La où je voulais en venir avec "structure compliquée" c'est que à première vu la syntaxe du certaines méthodes lui est propre et n'est pas toujours simple.
Après je ne voulais aucunement mettre en doute sa maintenance et sa stabilité. Je n'ai pas assez utilisé le langage. Mais j'avais plutôt en tête que s'était certes un langage fonctionnel puissant mais qu'il ne possédait pas de fonctionnalité qui sorte de l'ordinaire. En tout cas je ne les connais pas.![]()
Le tact dans l'audace c'est de savoir jusqu'où on peut aller trop loin. Cocteau
L'abjection la plus totale, ce n'est pas de trahir, c'est de ne jamais donner un commencement de réalité à ses rêves les plus fous. M. Moreau
Les indispensables : Les règles,, FAQ et tutos avant de poster,
et
!
Traduction de Linux Device Drivers 3 : venez participer
![]()
membre de l'April - Promouvoir et défendre les logiciels libres
![]()
Pourquoi "certaines méthodes" ?
La syntaxe de Haskell n'a rien de compliquée, à part qu'elle diffère de la syntaxe C contrairement aux très populaires C, C++, C#, Java, ...
Tu penses plus probablement aux monades, qui n'ont pas grand chose à voir avec la syntaxe mais qui sont l'une des grosses difficultés dans l'apprentissage d'Haskell effectivement. Mais ça vaut le coup de les comprendre, cela donne un outil très puissant dans certaines circonstances, même dans d'autres langages.
A moins que tu penses au système de layout (indentation significative) ? Les règles sont simples pourtant, et Python le fait aussi. On peut même désactiver le layout en utilisant {} et ; à la place, non que quiconque écrive vraiment comme cela.
"Pas de fonctionnalités qui sortent de l'ordinaire" ? Tu as déjà essayé Haskell, même un tout petit peu ?
Haskell est le seul langage "pratique" qui soit purement fonctionnel à évaluation paresseuse (si on excepte Clean, pratiquement pas utilisé, mais intéressant aussi), je dirais que ça en fait un langage légèrement différent de l'ordinaire oui... Tous les langages ne sont pas aussi tolérants avec les structures de données infinies, ils n'ont généralement pas de système de type avec polymorphisme supportant la surcharge par le biais des classes de type (un mécanisme très puissant et relativement différent de l'approche objet) avec inférence de type (presque complète) et un support pour le modèle "m over n" de threading avec de puissants outils pour en profiter, un compileur optimiseur qui permet d'approcher des performances du C avec un code de haut niveau...
On peut reprocher bien des choses à Haskell, considérer que ce n'est pas le langage du futur, qu'on fera mieux, que le système de type est imparfait, que l'approche des effets de bords par monade n'est pas la bonne solution, etc. Mais parler de Haskell comme s'il s'agissait d'un langage comme un autre, sans rien pour le distinguer et qu'il est inutile d'apprendre ? On ne me l'avait jamais faite !
Tout à fait, même entre langage impératifs ou entre langages fonctionnels on peut voir de grosses différences, la syntaxe de Smalltalk est aussi différente de celle de C que la syntaxe de Lisp est différente de celle de Haskell. Même si quand on a étudié les syntaxes de l'intérieur, on finit par travailler intellectuellement plus au niveau de la syntaxe abstraite, ce qui tend à simplifier le passage d'un langage à l'autre au sein du même paradigme.
Il n'y a bien que les gens qui n'ont étudié que les cousins du C pour penser que toutes les syntaxes doivent se ressembler, encore une bonne raison pour apprendre au moins un langage exotique (comme Haskell) : ouvrir son horizon syntaxique !
--
Jedaï
Je vois où tu veux en venir, je ne voyais pas ça comme ça. Mais disons que les nomades m'enquiquinent un peu.![]()
![]()
Partager