Cherche un livre sur la programmation

Salut,

je cherche un bouquin, je ne sais pas sur quel langage, je n'ai pas d'envie particulière j'ai juste envie d'apprendre quelque chose de nouveau ou en tout cas de différent par rapport à ce que je connais / utilise déjà.

Ruby, Javascript, C++, C#, php, python, sont les langages que j'utilise le plus (du plus utilisé au moins (j'ai mis python mais j'y connais rien, je l'utilise uniquement pour créer des extensions rapidement a base de copié collé bien dégueulassasse sans comprendre ce que je fais, mais je cherche pas particulièrement à l'apprendre, j'ai essayé et je n'arrive pas a m'y intéressé)).

Bref vous avez compris je sais pas ce que je veux, je voudrais vos avis sur ce qui peut être bon d'apprendre (bon dans le sens m'offrir une nouvelle vision et/ou de nouvelles possibilités).

Ensuite je cherche également un livre sur Android 5, j'en ai trouvé quelques uns mais les avis sur amazon sont toujours très mauvais, du coup je sais pas quoi penser. Donc si vous avez quelques conseilles

PS. Si le livre est dispo pour ma liseuse Kindle c'est encore mieux.

Merci

Salut !

Personnellement je trouve qu'angular rentre bien dans la catégorie des trucs "nouveaux" qui offrent de nouvelles possibilités et de nouvelles façons de faire ! Bon c'est possible que tu maitrises déjà le sujet, mais c'est tout ce que j'ai à te proposer.

Un super livre sur angular et un autre qui va bientôt sortir sur angular 2

Il faut voir si tu recherches un langage ou un livre déjà.

Si tu veux juste un langage, tu peux tenter de changer de paradigme : fonctionnel (Haskell, OCaml..) , logique (Prolog). Si tu veux un bon livre sur la POO, regarde Conception et programmation orientées objet . C'est un très bon livre sur le sujet qui en plus peut faire office de livre de référence pour Eiffel, un langage full OO bien conçu et assez méconnu.

Pour android, je passe mon chemin

Jette donc un coup d’œil à ça ça devrait t'intéresser si tu cherches quelque chose de "nouveau".

Angular j'ai déjà pratiqué effectivement.

@Davidbrcz un livre sur un langage ? Ma question est peut-être pas très clair. J'aime pas trop lire sur l'ordinateur, je préfère avoir du papier dans les mains ou pour l'informatique (vu le prix des bouquins dans ce domaine) lire sur ma liseuse, c'est bien plus agréable que sur l'écran du pc.

@Algue-Rythme Effectivement c'est vraiment différent de ce dont j'ai l'habitude. La syntaxe est bizarre j'ai l'impression de ne rien connaitre au sujet ^^.

Je sais pas si cette question a du sens mais quels sont les avantages à utiliser un langage fonctionnel (je suis pas sur d'avoir bien compris la différence entre fonctionnel et impératif). Dans l'intro il dit : dans les langages fonctionnels purs, une fonction n’a pas d’effets de bord je comprend pas l’intérêt (j'imagine que je comprendrai après un peu de pratique).

dans les langages fonctionnels purs, une fonction n’a pas d’effets de bord

Un effet de bord c'est quand une fonction modifie quelque chose dans le programme. Voici deux exemples de deux fonctions proches, mais l'une avec effet de bord et l'autre sans :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// fonction avec effet de bord :
var resultat;

var addition = function(a,b){
 resultat = a+b;
}

// la même fonction sans effet de bord :
var addition2 = function(a,b){
 var res = a+b;
 return res;
}
résultat = addition2(a,b);

Le gros avantage de ne pas avoir d'effet de bords c'est que tu es sur que ta fonction ne touche à rien dans le programme et ne peut pas avoir de comportement indésirable en modifiant un éléments qui risque de tout faire planter. Tu ne modifie ainsi jamais les éléments, tu renvois simplement un résultat avec return.

Imagine que dans le premier exemple tu ai un moment une variable résultat qui provoque une erreur. Comment savoir si le problème vient de la fonction "resultat" qui aurai mal fait son travail ou d'une autre fonction qui aurait par la suite modifiée elle aussi la variable résultat ? Si ton code est complexe il devient facile de passer à coté du problème.

Avec une fonction sans effet de bord comme la seconde, il est facile de voir où est le problème. Ta variable résultat ne peut venir que du return d'une fonction, il suffit d'aller voir si cette fonction fait bien son travail. Si cette fonction fait appel à d'autres fonctions il suffit de suivre la chaine des appels jusqu'à trouver où est l'erreur. Mais en procédant ainsi tu es sur de trouver l'erreur. Alors que dans le premier cas tu n'as aucune façon de savoir d'où peut venir le problème car potentiellement n'importe quelle fonction de ton code à pu modifier la valeur de la variable et poser le problème.

Mon explication te conviens ?

Oui oui elle me conviens. Du coup si j'ai bien compris impossible de faire cela : fillPlayer(Player& p); pour remplir mon objet player par exemple.

Alors que dans le premier cas tu n'as aucune façon de savoir d'où peut venir le problème car potentiellement n'importe quelle fonction de ton code à pu modifier la valeur de la variable et poser le problème.

C'est à ça que sert un débugger non ?

C'est à ça que sert un débugger non ?

En pratique oui, tu peux utiliser un debugger qui t'aidera à rapidement trouver l'erreur. Mais rien ne te dit que tu vas trouver ton erreur : elle peut venir potentiellement de n'importe quelle partie du programme. Imagine si le programme n'est pas de toi où que vous êtes plusieurs à travailler dessus ? Comment être sur qu'une partie du code que tu ignore où n'a jamais vu n'interagit pas négativement avec ton code et provoque l'erreur ?

C'est impossible, surtout si ton programme est vraiment gros et que tu n'es responsable que d'une partie du code.

Alors qu'avec une programmation fonctionnelle sans effets de bords, tu peux remonter précisément à la source du problème car chaque résultat est le return d'une fonction. Il suffit donc de trouver chaque fonction impliquée et de vérifier qu'elle produit bien le résultat attendu jusqu'à trouver le problème.

En effet les effets de bords sont l'un des problèmes contre lesquels luttent très efficacement la paradigme fonctionnel.
Ça va même très loin, parce que potentiellement tout accès en lecture/écriture à un périphérique (disque-dur, écran, clavier, souris, lecteur CD, port USB, base de données, internet… ), quel qu’il soit, est susceptible de provoquer des effets de bord, et de telles situations arrivent couramment en pratique.
C'est d’ailleurs l'une des raisons pour lesquelles OCaml (un autre langage fonctionnel) est utilisé pour les logiciels embarqués dans l'aviation, car de tels logiciels nécessites d'être très sûrs et très fiables.

Mais ça c'est le point de vue "industriel". C'est ce qu'il faut dire au boss pour le convaincre que le langage vaut l'investissement. Toi, en tant que programmeur, c'est tout autre chose qui va te passionner.

Le paradigme fonctionnel te force à réfléchir différemment. A cause de la non-mutabilité des variables, tu es obligé de penser autrement tes programmes. Ce n'est plus une suite de traitements appliqués successivement à des données, ce sont des imbrications de fonctions et d'expression s'appelant mutuellement. La récursivité est indispensable, et se trouve même au cœur de la plupart des algorithmes.

L'idée derrière toute fonction consiste à simplifier chaque problème ou chaque instance de problème en sous-problèmes plus petits, et à répéter ce processus jusqu'à obtenir des problèmes "atomiques" (comprendre: triviaux et immédiats), puis à composer les résultats pour obtenir la solution globale.

C'est difficile au début mais très formateur.

J'ajouterais qu'un grand nombre d'algos qui te semblaient simples auparavant deviendront assez ardus (s'ils ne sont pas adaptés au paradigme fonctionnel c'est normal, ça nécessite toujours un effort).

En revanche, d'autres qui sont d'ordinaire assez délicat, comme l'analyse lexicale, syntaxique, et de manière générale tout ce qui touche à la compilation ou l'interprétation peut devenir plus simple (OCaml est très utilisé pour ça). De même, tout les algos concernant les arbres (qui sont des structures de données récursives) se simplifient énormément. Tu vas être ébahi de voir que l'on peut faire certaines choses en seulement quelques lignes !

Bref, je conseille. J'avais moi même posé une question semblable à a la tienne il y a quelques temps sur un autre forum, on m'avait conseillé Haskell et je n'ai pas été déçu. Mais ce ne fut pas sans difficultés : j'ai du m'y reprendre à trois fois avant de vraiment parvenir au bout du tuto. Et même aujourd'hui je reste un débutant dans ce langage.

Je dirais aussi que ça te permet de rendre tes tests plus fiables.

Si ton test ne passe pas avec un fonction à effet de bord, tu ne sais pas si le problème vient de ta fonction où d'un effet de bord qui influence ton résultat. Tu sais jusqu'il y à un soucis.

Si tu suis le paradigme fonctionnel, tu sais que si ton test échoue il n'y à que deux options : - les paramètres passés à la fonction sont incompatibles avec le traitement réalisé (mon exemple si tu passes un objet au lieu d'un nombre ou d'une string à la fonction addition le test echoue). - ta fonction fait appel à d'autres fonctions qui ne retournent pas les éléments correctement. Si c'est le cas leurs tests unitaires devraient échouer et tu pourra le voir directement.

Enfin si ton programme à de nombreux effets de bords tu peux très bien passer tous les tests unitaires et avoir des erreurs car tes tests ne seront pas capable de prévoir les interactions entre les différents éléments. Alors qu'en programmation fonctionnelle tu n'as pas ce problème ce qui rend tes tests plus viables et plus efficaces.

Après comme le dit Algue-Rthymes c'est un paradigme qui est beaucoup utilisé là où on a besoin de sécurité, que un comportement imprévu n'est pas tolérable car capable d'entrainer de gros problèmes. En pratique pour une bonne partie des développeurs et des cas d'applications les contraintes de la programmation fonctionnelle sont souvent supérieures aux avantages…

Voici encore une autre réponse.

edit: attention, je n'emploie pas le mot « objet » dans le sens de la POO.

Je dirais que l'avantage est que c'est plus simple (du point de vue théorique, pas du point de vue « humain » (comme les maths)). Par exemple, si on veut des effets de bords, on doit préciser ce que l'on veut exactement, et comment. On a le choix entre plusieurs constructions et on les utilise selon nos besoins, au lieu d'avoir un outil unique qui sert à tout gérer de la même manière. Cela permet aussi de manipuler les constructions (les composer, les paramétrer).

En un mot, les concepts sont plus orthogonaux, plus simples, plus composables. D'ailleurs, le nom de programmation fonctionnelle est un peu mal choisi… les fonctions qui n'ont pas d'effet de bord et qui peuvent être manipulées comme tout autre objet, c'est juste un exemple. Les fonctions « simplifiées »¹ doivent être combinées avec d'autres trucs pour faire des choses plus complexes. Et on essaie de découpler au maximum les outils de base (les rendre le plus orthogonaux possible) afin de faire les choses plus simplement, de manière plus générale (on a juste ce dont on a besoin, on extrait l'essence des choses).

Ensuite, il y a la transparence référentielle qui est importante. Enfin, pour moi il s'agit de la manière normale de faire… du coup j'ai un peu de mal à expliquer.

Le principe de base, c'est que l'on a des expressions qui désignent des objets. La différence avec la programmation non-fonctionnelle, c'est qu'ici, les objets sont indépendants de l'exécution du programme. On sépare en quelque sorte l'exécution du programme de sa description (le code). Tout le contraire du dynamique. On a du code qui définit tout plein d'objets (et on réutilise des définitions pour définir d'autres objets), mais chaque objet est isolé des autres, et ne dépend que de l'expression qui le définit (normal…). Bon, après on peut penser à la programmation non-fonctionnelle comme un cas particulier, où on a un gros contexte global, et chaque « fonction » peut le modifier, etc.² Mais on voit que les objets en considération sont beaucoup plus complexes et particuliers, que tout dépend de tout, bref c'est le bordel (selon moi).

Un autre truc, c'est que parfois, on se retrouve à devoir donner un nom à un objet pour le désigner… Mais on veut séparer la manière de dénoter un objet (avec des expressions, arbre syntaxique) et la manière de dire « tel nom désigne tel objet ».

Maintenant, une séparation qui n'est pas faite (enfin, on conçoit bien pourquoi), c'est celle entre expression désignant un algorithme et expression désignant l'objet calculé. On devrait par exemple décrire des algorithmes impératifs de manière fonctionnelle, manipuler les algorihtmes, prouver des choses, les paralléliser, avoir différents modèles de calcul à disposition, etc. Un langage de programmation devrait être un langage de description d'objets mathématiques, et un programme un objet spécifique (il faut bien organiser les choses, par exemple pour éviter d'avoir à exprimer en double une fonction qui se calcule directement avec son expression).

Un autre truc est le nommage des paramètres des fonctions. Ces noms sont indispensables en pratique mais moches théoriquement : ils servent à nous, humains, à voir qu'est-ce qui va où, mais cela obscurcit la théorie derrière et mélange des choses.

Ensuite, certaines choses peuvent être plus difficiles à exprimer dans un langage fonctionnel. Je m'explique cela par le fait que ces langages forcent à exprimer les choses simplement, à analyser la situation, bien séparer les choses. Sauf que quand tout est mélangé dans la manière qui nous vient pour exprimer un algorithme, c'est compliqué de bien analyser et rendre beau, symétrique, etc. (c'est même pas dit que ce soit possible). C'est comme si on essayait de décrire mathématiquement le latin (edit : en fait pas vraiment, c'est souvent possible de rendre les algorithmes beaux avec un peu de travail, mais le latin je ne pense pas).

J'ajouterai que l'on essaye d'utiliser des constructions de plus haut niveau que la récursivité quand cela est possible. La récursivité permet de tout calculer, et c'est une bonne manière de voir les choses, mais c'est un peu comme quand on me dit que la topologie est fondée sur les ouverts : c'est un fondement possible, mais ça ne fait pas l'essence de la chose (même si ce fondement peut refléter une caractéristique importante de la chose). Par exemple, le C « fonde » les choses avec des boucles, des tests conditionnels, la récursion. En programmation fonctionnelle, on préfèrera des constructions plus théoriques, moins arbitraires (même si on peut théoriser ces choix arbitraires, et même si c'est pas parfait non plus en Haskell par exemple).

Je vais commencer à lire un peu parceque j'ai un peu de mal pour vous suivre la

Concernant android 5 ? Un bon tutoriel / livre

Que recherches tu précisément ? Un livre pour t'apprendre à utiliser Androïd ? Pour t'apprendre à y développer des applications ?

Effectivement j'avais pas précisé, je cherche donc un livre qui introduit le développement d'application android .