main = interact (show . maximum . takeWhile (/= -99) . inputs)
On remarque qu'il n'y a plus de variable et plus de récursion. Je suis un peu habitué à ce style déclaratif, mais je pense ne pas m'avancer trop si je dis que ça se lit presque naturellement :
Il s'agit d'un programme interactif qui affiche la valeur maximale parmi une série (terminée par la valeur spéciale -99) qui a été entrée par l'utilisateur.
Maintenant, je ne pense pas pour autant que ce code soit facile à comprendre / implémenter pour un débutant (je ne pense pas que Haskell soit très adapté comme premier langage), mais on remarque quand même qu'on y gagne à utiliser des fonctions sémantiques (comme "max") vis à vis de l'exemple initial.
Accessoirement, en tant qu'étudiant, je trouve ça totalement idiot de faire comprendre des programmes dont l'explication est aussi tortueuse. On devrait pouvoir trouver des exemples qui parlent plus à l'instinct, pour familiariser avec les concepts (quelque chose où le résultat semble plus utile pour un nouveau, qu'il puisse se rattacher à sa compréhension naturelle pour intégrer ce qui se passe vraiment.)
(header nécessaire au bon fonctionnement du code précédent :)
module Simple where
import Data.List
import Data.Maybe
Non, tu ne peux pas prendre un cas particulier (manipuler des photos ou des cartes) pour généraliser la puissance de l'interface tactile. C'est actuellement quelque chose d'assez limité, et mis à part les graphistes (et certains scientifiques), l'utilisation d'une interface tactile n'apporte rien à l'utilisateur final. C'est peut être un peu plus instinctif pour certaines tâches, parce qu'on a l'illusion de "toucher" le contenu, mais ce n'est pas une révolution dans notre manière d'utiliser un ordinateur (on ne peut pas réellement faire plus qu'avant et ça ne simplifie pas grand chose pour ta grand mère).
(Par exemple, pour le coup du défilement, les claviers sont généralement équipés de touches fléchées qui font ça très bien et qui me semblent plus instinctives que "poser deux doigts et faire glisser".)
Je pense que l'ordinateur est un médium de création, pas un super lecteur de diapo... même si c'est la tendance actuelle. Les gens devraient pouvoir utiliser leur ordinateur pour faire plus de choses mais ils sont limités par ce qu'on leur propose. Le but d'une interface est de pouvoir communiquer avec son ordinateur et elles sont toutes intéressantes à ce niveau. C'est juste que le langage est plus polymorphe et s'adapte à plus de situations... mais qu'on l'ignore totalement quand on développe uniquement des interfaces tactiles ou graphiques. C'est contre ça que je râle..
Bon après, je suis certainement un vieux con réfractaire au progrès :) .
Tu as pensé à faire des alias ? Par exemple, alias installe='sudo apt-get install'Ce qui permet ensuite d'écrire juste "installe plop"... Enfin, je dis ça, je dis rien, on est bien d'accord que le shell n'est pas instinctif actuellement et que sa syntaxe est trop limitée pour permettre des alias vraiment puissant (en français, on a tendance à utiliser des groupes de mots pour décrire les actions par exemple --- et c'est moins facile à mettre en place).
Cela dit, je trouverais ça amusant de voir quelles commandes un utilisateur lambda essayerait de taper si on lui fournissait une base utilisable :) (n'étant pas (cor)rompu au fonctionnement du shell, peut être aurait-il des idées originales qui nous seraient également utiles ?).
J'utilise le shell quotidiennement (avec quelques rares programmes graphiques comme le navigateur web) et je me pose souvent la question de la productivité qu'il m'apporte... Est-ce que l'utilisation de "power-tools" (comme le shell, vim ou ion) change-t'elle vraiment ma productivité par rapport aux environnements graphiques ? Parfois je doute.
Ce qui est sûr par contre, c'est que je trouve le shell plus confortable pour un tas de raisons. Les GUIs ont été conçu pour faciliter la découverte des interfaces (plutôt que de se taper un manuel, on scan l'écran à la recherche du bon bouton) et utilisent le positionnement spatial pour habituer l'utilisateur aux fonctionnalités des logiciels.
Le problème à mon goût, c'est que je pense en français et qu'une GUI me demande de traduire mes pensées en une recherche spatial. Alors oui, c'est ce qu'on fait dans le monde pas virtuel ("me faut ce document, je l'ai mis où déjà"), mais l'informatique dispose de contraintes différentes (par exemple, la distance est un concept fabriqué en info). Pour cette raison, je trouve le shell plus pratique (traduire du français dans un autre langage, c'est plus facile à mon goût que traduire du français en une recherche (c'est pas la même approche)).
Le shell étant un langage, il me permet finalement de développer des idées construites (alors que les GUIs reposent sur l'utilisation de la souris (c'est à dire d'un doigt virtuel), et que le langage de la souris est complètement atrophié par rapport à la langue des signes par exemple). Pendant longtemps, on a empêché les sourds d'utiliser leur langage (et on les a condamné au rôle de simples d'esprit)... donc j'aimerais tant que possible éviter de me retrouver dans leur situation :) .
Bref, je vois d'un assez mauvais œil les différentes poussées technologiques dans le domaine du tactile (d'un point de vue historique, c'est une régression, l'être humain a commencé par faire des choses avec ses mains (interface tactile !), puis par développer des langages (des bruits et des dessins => GUI !) et finalement par découvrir l'écriture à proprement parler (... CLI !)). En info, on est entrain de revivre ce chemin dans le sens inverse.
Cela dit, ce n'est pas une raison pour privilégier le langage aux autres techniques d'interaction et je pense justement qu'il faudrait d'avantage allier les différentes solutions (cf par exemple les nouveaux genres de shell comme Enso [1] ou les progrès en matière de scripting des interfaces graphiques [2]). En attendant, le shell reste mon interface de prédilection :) .
[1] http://humanized.com/enso/
[2] J'ai plus le lien, mais en gros, il s'agissait d'une lib (basée sur GTK pour le rendu) qui permettait de scripter et de modifier en temps réel l'interface des applications (par exemple pour améliorer l'ergonomie ou le fonctionnement d'un logiciel).
Non, le mot fonctionnel lorsque l'on parle d'un langage de programmation décrit un paradigme (comme orienté objet ou impératif).
L'idée de base, c'est que les fonctions sont des valeurs dans ce type de langage (à titre de comparaison, on a l'habitude en programmation de pouvoir manipuler des nombres, des chaînes de caractères, des tableaux, et parfois même des regexs comme des valeurs --- mais plus rarement des fonctions). C'est un style qui est assez jouissif à utiliser, parce qu'il permet de mieux factoriser son code et de le rendre plus sémantique (plus expressif).
L'exemple typique pour illustrer l'aspect sémantique, c'est la fonction map() qui applique une fonction à chaque élément d'une collection (un tableau, une liste). Dans les langages impératifs, on utilise une boucle for pour ce genre de tâches : for (int i = 0; i < tab.length; ++i)
tab[i] = f(tab[i]);
Et on ne voit aucune raison de factoriser deux lignes de code... sauf qu'en pratique, l'exemple précédent ne se présente pas comme ça, mais plutôt comme : for (int i = 0; i < tab.length; ++i) {
// plusieurs
// lignes
// de
// code
}
Et il devient alors plus difficile de comprendre ce qui se passe, parce qu'un tas de facteurs peuvent influer dans le corps de la boucle (on peut modifier la valeur de l'itérateur, on peut décider de ne pas modifier à chaque fois le tableau, ou de faire d'autres opérations, ...).
Bref, la boucle for est générale, mais un peu trop pour faciliter la compréhension. Ce qu'il faudrait, c'est une boucle plus sémantique qui dit au programmeur "alors là tu vois, je vais mettre à jour toutes les cases du tableau", ce qui permet d'éviter de nombreux bugs (et on peut appliquer le même principe aux autres sortes de boucles que l'on retrouve souvent). Bref, on construit des briques expressives qui décrivent une action.
En ruby, irb(main):001:0> tab = [1,2,3]
irb(main):002:0> tab.map { |x| x * x }
=> [1, 4, 9]
Un exemple plus concret, c'est pour les GUIs : Lorsque l'on crée un bouton, il faut pouvoir spécifier son comportement lors d'un clic. La solution pseudo-OO serait de faire hériter son bouton de la classe Button et de redéfinir la méthode on_click() et finalement de l'instancier... mais c'est un peu lourd de faire ça pour chaque bouton (à mon goût).
À comparer avec le code suivant :
input = Textarea.new
bouton = Button.new
bouton.on(:click) do
puts input.value
end
Un autre exemple, pour les fanas d'algorithmie : Si l'on a un graphe que l'on souhaite parcourir en largeur (pour chercher un élément, ou autre), le code de parcours est assez général (c'est l'action sur chaque élément qui diffère). On peut donc souhaiter programmer une seule fois le parcours et laisser libre le choix de l'action au programmeur ensuite.
Un exemple d'utilisation : def has_value(graph, x)
graph.dfs do |value|
return true if x == value
end
return false
end
Bref, les possibilités offertes par le paradigme fonctionnel sont très riches et ouvrent de nouvelles opportunités. Entre autre, je pense que c'est un style qui permet de mieux éviter les erreurs parce qu'il permet une meilleure découpe des différents composants (dans l'exemple du dfs, par exemple, si une erreur est décelée, il est facile de voir que has_value() n'est pas à remettre en cause -- et que l'erreur se trouve dans la méthode dfs()). Le code tend à être plus "simple" (mais c'est relatif, car il est aussi plus abstrait).
Il ouvre également des portes pour les optimisations : Par exemple, pour map(), puisque l'on sait que chaque case du tableau va être mise à jour indépendamment des autres, il est possible de paralléliser trivialement les calculs sur plusieurs bécanes. Oui oui, le map dans MapReduce (de google) vient de là (et le reduce correspond à un autre type de boucle).
Finalement, l'arrivée du fonctionnel dans les langages comme C++, C# et les différents langages de script populaires (Ruby, Python, Lua...) montrent bien qu'il s'agit d'un concept intéressant.
Remarque: les langages implémentent plus ou moins bien le(s) paradigme(s) sur le(s)quel(s) ils reposent (par exemple, Java n'est pas suffisamment OO à mon goût). Ruby est "assez" fonctionnel dans le sens qu'il supporte l'idée, mais pas aussi bien que des vrais langages fonctionnels. Je recommande donc OCaml si vous voulez vous essayer à ce style langage :) .
Je pense que les critiques ne sont pas à prendre au sens premier : Si le projet était nul, on ne réagirait pas. Le but est avant tout d'aider l'auteur en lui indiquant les faiblesses actuelles, de lui proposer des pistes, des idées... Après, libre à lui d'en faire ce qu'il veut, on est pas là pour briser son projet, bien au contraire, on en attend encore beaucoup plus :) .
Le libre, c'est avant tout un échange de connaissances qui permet le développement de nouvelles (ou l'enrichissement d') idées (existantes) (que ça soit d'une manière verbale ou via du code). La diversité n'est qu'une conséquence de ce modèle :) .
Cela dit, c'est bien qu'il y ait aussi des commentaires qui complimentent le travail, parce que c'est vrai que ça fait plaisir et que ça motive à continuer :) . Donc bonne continuation à Logram, un travail impressionnant a déjà été abattu !
Je pense qu'il faut arrêter de marginaliser les langages de script pour des raisons de performance et les utiliser aux bons moments : dans une application, le langage de script peut servir comme glue entre les widgets et les bibliothèques. En pratique, la glue est assez courte, contient un code trivial et le temps d'exécution perçu par l'utilisateur est nul. L'intérêt principal repose donc dans la facilité de modifier l'interface graphique ensuite pour tester de nouvelles choses :) (ce qui est beaucoup moins évident quand la gui est codée dans un langage compilé) (je pense par exemple aux modifications "à chaud" qui permettent de tester des idées sans redémarrer le programme).
Bref, je dois reconnaître que je serais tout à fait fan d'un environnement qui me permettrait d'étendre les fonctionnalités d'un logiciel à la volée. Suppose que mon éditeur de texte ne propose pas de bouton pour sauvegarder d'un coup *tous* les fichiers en cours d'édition. Pourquoi est-ce que je ne pourrais pas en bricoler un ? (avec un code ressemblant à :
files do: [ :f | f save ]
Ou en Python (désolé pour l'indentation) :
for f in files:
f.save()
Ça ne me semble pas très dur à mettre en place ni à utiliser. Avoir un langage à disposition fait de nous des humains et nous permet de développer notre imagination. Sans, on est juste bon à pousser des grognements et toutes les interfaces se ressemblent pour faire ça :) .
Je pensais ajouter que l'excuse "oui mais c'est moche Squeak" était irrecevable entre gens civilisés (les goûts et les couleurs...). Donc : certes, Squeak n'incarne pas le dernier cri de la mode en matière d'apparence, mais une bonne idée reste une bonne idée (c'est d'autant plus une bonne idée si tu l'as réinventée : c'est qu'elle était nécessaire). Je t'indiquais Squeak uniquement comme source d'inspiration intellectuelle, pas pour son design :) (car ils se sont pas arrêtés aux languettes, y a bien plus fort que ça si tu creuses un peu).
Wasn't all this done years ago at Xerox PARC? (No one remembers what was really done at PARC, but everyone else will assume you remember something they don't.)
Déjà vu dans Squeak, entre autre : http://www.planete-sciences.org/robot/boiteabots/images/sque(...) (les machins avec du texte sur le bord de l'écran, ici avec la languette "Supplies" tirée). Peut être qu'il serait intéressant de se renseigner sur Squeak, étant donné qu'ils semblent avoir eu des idées qui te plaisent ? :) (histoire de pas réinventer la roue, mais je dis ça comme ça...)
Pour ma part, j'ai vraiment adoré le deuxième volume de la trilogie qui complète agréablement l'histoire (et permet de lever quelques zones d'ombres importantes tout en restant dans le ton du premier).. par contre, je confirme, le troisième est à fuir :] .
Certains ont déjà parlé de la sécurité pour madame michu, j'y connais rien et ça ne m'intéresse pas des masses - j'ai une confiance naïve dans les quatre libertés o/
Quoi qu'il en soit, dès qu'on touche à la sécurité de l'application ("es-ce que mon code fait ce pour quoi je l'ai codé et quoi qu'il arrive"), on se retrouve confronté à deux solutions complémentaires : le typage et les batteries de tests.
Les langages fortement typés (Ada a déjà été cité, même si je préfère les langages fonctionnels, qui proposent de l'inférence de type et du polymorphisme, comme ocaml ou haskell [1]) garantissent lors de la compilation/parsage que l'ensemble du programme est cohérent. Vis à vis de php, python ou ruby (et même le c), c'est un énorme plus : pour débuger une application python, il est nécessaire de vérifier le code par la pratique (ie, de parcourir lors de l'éxecution l'ensemble des branches - ce qui n'est généralement pas possible sur de grosses applications).
(Par exemple, HaskellDB [2] propose une solution intéressante au problème des injections sql en exploitant les capacités d'haskell comme l'explique brièvement ce slide : http://www.cs.chalmers.se/~bringert/publ/haskelldb/haskelldb(...) .)
Tester son application consiste à vérifier qu'elle fait bien ce qu'elle doit faire d'une manière automatique (et en séparant les portions testées) : malheureusement, écrire les tests peut s'avérer long et chiant (tout en ne garantissant pas qu'ils mettent en évidence les bugs). À nouveau, le typage peut intervenir dans cette phase comme l'illustre QuickCheck [3] (et d'autres) en générant les tests à partir de rêgles simples. Couplé avec darcs [4], c'est une bonne solution pour garantir que le logiciel ne risque pas de se comporter bizarrement en cours de route.
Bref, un typage fort est pour moi une feature extremement intéressante dans un langage de programmation :p (et pas seulement pour l'aspect sécuritaire, mais surtout pour l'expressivité qu'il apporte).
(En dehors d'ocaml et haskell, on citera également scala [5], qui en plus de proposer une syntaxe "à la java" (peut être plus accessible ?), utilise la jvm (d'où accès aux libs java (et vice versa) et surtout, le sandboxing pour la sécurité du coté utilisateur dont tu parlais au début))
(il faut aussi citer erlang, qui est spécialement orienté concurrence, mais que je connais moins.. dans tous les cas, c'est du bon ^_^)
Bref, pour peu que tu trouves le temps de t'intéresser à ces deux langages fondamentalement différents de ce que tu dois connaître, je pense que tu y trouveras ton compte.
http://www.etoile-project.org ? :) (qui a réelement besoin de développeurs, dont la philosophie est très proche du smalltalk (objc), travail collaboratif, idées innovantes, etc... - et ok, c'est pas un os, mais un environnement utilisateur, ce qui est beaucoup plus séduisant à mes yeux :} ).
Bref, je te recommande vivement de t'y intéresser, parce que la programmation GNUstep est à la fois jouissive et bénéfique à la communauté :]
Il y a quelque temps, j'avais imaginé une solution de tri automatique des emails permettant d'améliorer l'identification du correspondant et donc le blacklistage en cas de spam. L'idée se rapproche un peu des adresses jetables :
Soit l'adresse email "moi@serveur.org" : je souhaite m'inscrire sur linuxfr (qui revendra certainement mon email à xxx.com pour payer ses serveurs, et dont les membres sont tous plus douteux les un que les autres "FR33 LL ! 3NL4rgE y0uR c0mPut3r"). Pour éviter ce genre de dérapage, je donne l'email "moi@linuxfr.serveur.org" lors de l'inscription qui redirige les mails vers un sous-dossier linuxfr (ou qui modifie le titre de l'email pour "[LINUXFR] titre"). La transparence étant le mot clé de l'histoire, la création du sous-compte linuxfr devrait être automatique (de manière à pouvoir donner son email aussi facilement irl (par ex. "moi@rmll.serveur.org")).
De cette manière, je pense qu'on disposerait d'un système de tri simple et pratique :) ... mais n'en ayant ni les connaissances ni le besoin pour le moment, je me demandais si c'était réalisable / intéressant (et si certains fournisseurs emails proposaient déjà ce service ?).
Visiblement, ça pourrait poser un problème lors d'une réponse, l'email envoyé étant par défaut "moi@serveur.org", sans le sous-domaine (... et un être humain peut facilement passer outre, mais c'est secondaire au problème du spam).
Bref, je suis à la recherche d'avis sur la question, merci d'avance :]
[^] # Re: Programmation impérative...
Posté par lasts . En réponse au journal Psychology of programming. Évalué à 5.
main = interact (show . maximum . takeWhile (/= -99) . inputs)On remarque qu'il n'y a plus de variable et plus de récursion. Je suis un peu habitué à ce style déclaratif, mais je pense ne pas m'avancer trop si je dis que ça se lit presque naturellement :
Il s'agit d'un programme interactif qui affiche la valeur maximale parmi une série (terminée par la valeur spéciale -99) qui a été entrée par l'utilisateur.
Maintenant, je ne pense pas pour autant que ce code soit facile à comprendre / implémenter pour un débutant (je ne pense pas que Haskell soit très adapté comme premier langage), mais on remarque quand même qu'on y gagne à utiliser des fonctions sémantiques (comme "max") vis à vis de l'exemple initial.
Accessoirement, en tant qu'étudiant, je trouve ça totalement idiot de faire comprendre des programmes dont l'explication est aussi tortueuse. On devrait pouvoir trouver des exemples qui parlent plus à l'instinct, pour familiariser avec les concepts (quelque chose où le résultat semble plus utile pour un nouveau, qu'il puisse se rattacher à sa compréhension naturelle pour intégrer ce qui se passe vraiment.)
(header nécessaire au bon fonctionnement du code précédent :)
module Simple where
import Data.List
import Data.Maybe
inputs :: String -> [Int]
inputs = unfoldr (listToMaybe . reads)
[^] # Re: Le shell est une interface !
Posté par lasts . En réponse au journal Quel est votre vision de la ligne de commande ?. Évalué à 4.
(Par exemple, pour le coup du défilement, les claviers sont généralement équipés de touches fléchées qui font ça très bien et qui me semblent plus instinctives que "poser deux doigts et faire glisser".)
Je pense que l'ordinateur est un médium de création, pas un super lecteur de diapo... même si c'est la tendance actuelle. Les gens devraient pouvoir utiliser leur ordinateur pour faire plus de choses mais ils sont limités par ce qu'on leur propose. Le but d'une interface est de pouvoir communiquer avec son ordinateur et elles sont toutes intéressantes à ce niveau. C'est juste que le langage est plus polymorphe et s'adapte à plus de situations... mais qu'on l'ignore totalement quand on développe uniquement des interfaces tactiles ou graphiques. C'est contre ça que je râle..
Bon après, je suis certainement un vieux con réfractaire au progrès :) .
[^] # Re: La ligne de commande comme bonus de l'environnement graphique
Posté par lasts . En réponse au journal Quel est votre vision de la ligne de commande ?. Évalué à 1.
alias installe='sudo apt-get install'Ce qui permet ensuite d'écrire juste "installe plop"... Enfin, je dis ça, je dis rien, on est bien d'accord que le shell n'est pas instinctif actuellement et que sa syntaxe est trop limitée pour permettre des alias vraiment puissant (en français, on a tendance à utiliser des groupes de mots pour décrire les actions par exemple --- et c'est moins facile à mettre en place).Cela dit, je trouverais ça amusant de voir quelles commandes un utilisateur lambda essayerait de taper si on lui fournissait une base utilisable :) (n'étant pas (cor)rompu au fonctionnement du shell, peut être aurait-il des idées originales qui nous seraient également utiles ?).
# Le shell est une interface !
Posté par lasts . En réponse au journal Quel est votre vision de la ligne de commande ?. Évalué à 9.
Ce qui est sûr par contre, c'est que je trouve le shell plus confortable pour un tas de raisons. Les GUIs ont été conçu pour faciliter la découverte des interfaces (plutôt que de se taper un manuel, on scan l'écran à la recherche du bon bouton) et utilisent le positionnement spatial pour habituer l'utilisateur aux fonctionnalités des logiciels.
Le problème à mon goût, c'est que je pense en français et qu'une GUI me demande de traduire mes pensées en une recherche spatial. Alors oui, c'est ce qu'on fait dans le monde pas virtuel ("me faut ce document, je l'ai mis où déjà"), mais l'informatique dispose de contraintes différentes (par exemple, la distance est un concept fabriqué en info). Pour cette raison, je trouve le shell plus pratique (traduire du français dans un autre langage, c'est plus facile à mon goût que traduire du français en une recherche (c'est pas la même approche)).
Le shell étant un langage, il me permet finalement de développer des idées construites (alors que les GUIs reposent sur l'utilisation de la souris (c'est à dire d'un doigt virtuel), et que le langage de la souris est complètement atrophié par rapport à la langue des signes par exemple). Pendant longtemps, on a empêché les sourds d'utiliser leur langage (et on les a condamné au rôle de simples d'esprit)... donc j'aimerais tant que possible éviter de me retrouver dans leur situation :) .
Bref, je vois d'un assez mauvais œil les différentes poussées technologiques dans le domaine du tactile (d'un point de vue historique, c'est une régression, l'être humain a commencé par faire des choses avec ses mains (interface tactile !), puis par développer des langages (des bruits et des dessins => GUI !) et finalement par découvrir l'écriture à proprement parler (... CLI !)). En info, on est entrain de revivre ce chemin dans le sens inverse.
Cela dit, ce n'est pas une raison pour privilégier le langage aux autres techniques d'interaction et je pense justement qu'il faudrait d'avantage allier les différentes solutions (cf par exemple les nouveaux genres de shell comme Enso [1] ou les progrès en matière de scripting des interfaces graphiques [2]). En attendant, le shell reste mon interface de prédilection :) .
[1] http://humanized.com/enso/
[2] J'ai plus le lien, mais en gros, il s'agissait d'une lib (basée sur GTK pour le rendu) qui permettait de scripter et de modifier en temps réel l'interface des applications (par exemple pour améliorer l'ergonomie ou le fonctionnement d'un logiciel).
[^] # Re: Petite erreur dans le texte de la dépêche
Posté par lasts . En réponse à la dépêche Atelier Actux mardi 19/05/2009 : Ruby, un langage objet et (assez) fonctionnel. Évalué à 9.
L'idée de base, c'est que les fonctions sont des valeurs dans ce type de langage (à titre de comparaison, on a l'habitude en programmation de pouvoir manipuler des nombres, des chaînes de caractères, des tableaux, et parfois même des regexs comme des valeurs --- mais plus rarement des fonctions). C'est un style qui est assez jouissif à utiliser, parce qu'il permet de mieux factoriser son code et de le rendre plus sémantique (plus expressif).
L'exemple typique pour illustrer l'aspect sémantique, c'est la fonction map() qui applique une fonction à chaque élément d'une collection (un tableau, une liste). Dans les langages impératifs, on utilise une boucle for pour ce genre de tâches :
for (int i = 0; i < tab.length; ++i)tab[i] = f(tab[i]);
Et on ne voit aucune raison de factoriser deux lignes de code... sauf qu'en pratique, l'exemple précédent ne se présente pas comme ça, mais plutôt comme :
for (int i = 0; i < tab.length; ++i) {// plusieurs
// lignes
// de
// code
}
Et il devient alors plus difficile de comprendre ce qui se passe, parce qu'un tas de facteurs peuvent influer dans le corps de la boucle (on peut modifier la valeur de l'itérateur, on peut décider de ne pas modifier à chaque fois le tableau, ou de faire d'autres opérations, ...).
Bref, la boucle for est générale, mais un peu trop pour faciliter la compréhension. Ce qu'il faudrait, c'est une boucle plus sémantique qui dit au programmeur "alors là tu vois, je vais mettre à jour toutes les cases du tableau", ce qui permet d'éviter de nombreux bugs (et on peut appliquer le même principe aux autres sortes de boucles que l'on retrouve souvent). Bref, on construit des briques expressives qui décrivent une action.
En ruby,
irb(main):001:0> tab = [1,2,3]irb(main):002:0> tab.map { |x| x * x }
=> [1, 4, 9]
Un exemple plus concret, c'est pour les GUIs : Lorsque l'on crée un bouton, il faut pouvoir spécifier son comportement lors d'un clic. La solution pseudo-OO serait de faire hériter son bouton de la classe Button et de redéfinir la méthode on_click() et finalement de l'instancier... mais c'est un peu lourd de faire ça pour chaque bouton (à mon goût).
À comparer avec le code suivant :
input = Textarea.new
bouton = Button.new
bouton.on(:click) do
puts input.value
end
Un autre exemple, pour les fanas d'algorithmie : Si l'on a un graphe que l'on souhaite parcourir en largeur (pour chercher un élément, ou autre), le code de parcours est assez général (c'est l'action sur chaque élément qui diffère). On peut donc souhaiter programmer une seule fois le parcours et laisser libre le choix de l'action au programmeur ensuite.
Un exemple d'utilisation :
def has_value(graph, x)graph.dfs do |value|
return true if x == value
end
return false
end
Bref, les possibilités offertes par le paradigme fonctionnel sont très riches et ouvrent de nouvelles opportunités. Entre autre, je pense que c'est un style qui permet de mieux éviter les erreurs parce qu'il permet une meilleure découpe des différents composants (dans l'exemple du dfs, par exemple, si une erreur est décelée, il est facile de voir que has_value() n'est pas à remettre en cause -- et que l'erreur se trouve dans la méthode dfs()). Le code tend à être plus "simple" (mais c'est relatif, car il est aussi plus abstrait).
Il ouvre également des portes pour les optimisations : Par exemple, pour map(), puisque l'on sait que chaque case du tableau va être mise à jour indépendamment des autres, il est possible de paralléliser trivialement les calculs sur plusieurs bécanes. Oui oui, le map dans MapReduce (de google) vient de là (et le reduce correspond à un autre type de boucle).
Finalement, l'arrivée du fonctionnel dans les langages comme C++, C# et les différents langages de script populaires (Ruby, Python, Lua...) montrent bien qu'il s'agit d'un concept intéressant.
Remarque: les langages implémentent plus ou moins bien le(s) paradigme(s) sur le(s)quel(s) ils reposent (par exemple, Java n'est pas suffisamment OO à mon goût). Ruby est "assez" fonctionnel dans le sens qu'il supporte l'idée, mais pas aussi bien que des vrais langages fonctionnels. Je recommande donc OCaml si vous voulez vous essayer à ce style langage :) .
[^] # Re: Bonne continuation!
Posté par lasts . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à 2.
Je pense que les critiques ne sont pas à prendre au sens premier : Si le projet était nul, on ne réagirait pas. Le but est avant tout d'aider l'auteur en lui indiquant les faiblesses actuelles, de lui proposer des pistes, des idées... Après, libre à lui d'en faire ce qu'il veut, on est pas là pour briser son projet, bien au contraire, on en attend encore beaucoup plus :) .
Le libre, c'est avant tout un échange de connaissances qui permet le développement de nouvelles (ou l'enrichissement d') idées (existantes) (que ça soit d'une manière verbale ou via du code). La diversité n'est qu'une conséquence de ce modèle :) .
Cela dit, c'est bien qu'il y ait aussi des commentaires qui complimentent le travail, parce que c'est vrai que ça fait plaisir et que ça motive à continuer :) . Donc bonne continuation à Logram, un travail impressionnant a déjà été abattu !
[^] # Re: Heu...
Posté par lasts . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à 6.
Bref, je dois reconnaître que je serais tout à fait fan d'un environnement qui me permettrait d'étendre les fonctionnalités d'un logiciel à la volée. Suppose que mon éditeur de texte ne propose pas de bouton pour sauvegarder d'un coup *tous* les fichiers en cours d'édition. Pourquoi est-ce que je ne pourrais pas en bricoler un ? (avec un code ressemblant à :
files do: [ :f | f save ]Ou en Python (désolé pour l'indentation) :
for f in files:f.save()
Ça ne me semble pas très dur à mettre en place ni à utiliser. Avoir un langage à disposition fait de nous des humains et nous permet de développer notre imagination. Sans, on est juste bon à pousser des grognements et toutes les interfaces se ressemblent pour faire ça :) .
[^] # Re: Languette
Posté par lasts . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à 4.
[^] # Re: Languette
Posté par lasts . En réponse à la dépêche Logram, environnement de bureau totalement différent, fête ses 1 ans.. Évalué à 4.
Déjà vu dans Squeak, entre autre : http://www.planete-sciences.org/robot/boiteabots/images/sque(...) (les machins avec du texte sur le bord de l'écran, ici avec la languette "Supplies" tirée). Peut être qu'il serait intéressant de se renseigner sur Squeak, étant donné qu'ils semblent avoir eu des idées qui te plaisent ? :) (histoire de pas réinventer la roue, mais je dis ça comme ça...)
[^] # Re: Petite note sur le film Les infiltrés
Posté par lasts . En réponse à la dépêche American Gangster. Évalué à 1.
[^] # Re: Il y a deux notions de langage securise
Posté par lasts . En réponse au journal Qu'est-ce qu'un langage sécurisé ?. Évalué à 2.
# Typage
Posté par lasts . En réponse au journal Qu'est-ce qu'un langage sécurisé ?. Évalué à 6.
Certains ont déjà parlé de la sécurité pour madame michu, j'y connais rien et ça ne m'intéresse pas des masses - j'ai une confiance naïve dans les quatre libertés o/
Quoi qu'il en soit, dès qu'on touche à la sécurité de l'application ("es-ce que mon code fait ce pour quoi je l'ai codé et quoi qu'il arrive"), on se retrouve confronté à deux solutions complémentaires : le typage et les batteries de tests.
Les langages fortement typés (Ada a déjà été cité, même si je préfère les langages fonctionnels, qui proposent de l'inférence de type et du polymorphisme, comme ocaml ou haskell [1]) garantissent lors de la compilation/parsage que l'ensemble du programme est cohérent. Vis à vis de php, python ou ruby (et même le c), c'est un énorme plus : pour débuger une application python, il est nécessaire de vérifier le code par la pratique (ie, de parcourir lors de l'éxecution l'ensemble des branches - ce qui n'est généralement pas possible sur de grosses applications).
(Par exemple, HaskellDB [2] propose une solution intéressante au problème des injections sql en exploitant les capacités d'haskell comme l'explique brièvement ce slide : http://www.cs.chalmers.se/~bringert/publ/haskelldb/haskelldb(...) .)
Tester son application consiste à vérifier qu'elle fait bien ce qu'elle doit faire d'une manière automatique (et en séparant les portions testées) : malheureusement, écrire les tests peut s'avérer long et chiant (tout en ne garantissant pas qu'ils mettent en évidence les bugs). À nouveau, le typage peut intervenir dans cette phase comme l'illustre QuickCheck [3] (et d'autres) en générant les tests à partir de rêgles simples. Couplé avec darcs [4], c'est une bonne solution pour garantir que le logiciel ne risque pas de se comporter bizarrement en cours de route.
Bref, un typage fort est pour moi une feature extremement intéressante dans un langage de programmation :p (et pas seulement pour l'aspect sécuritaire, mais surtout pour l'expressivité qu'il apporte).
http://fr.wikipedia.org/wiki/Typage_fort
(En dehors d'ocaml et haskell, on citera également scala [5], qui en plus de proposer une syntaxe "à la java" (peut être plus accessible ?), utilise la jvm (d'où accès aux libs java (et vice versa) et surtout, le sandboxing pour la sécurité du coté utilisateur dont tu parlais au début))
[1] http://fr.wikipedia.org/wiki/Objective_Caml & http://fr.wikipedia.org/wiki/Haskell
[2] http://haskelldb.sourceforge.net/
[3] http://en.wikipedia.org/wiki/QuickCheck
[4] http://www.haskell.org/haskellwiki/How_to_write_a_Haskell_pr(...)
[5] http://en.wikipedia.org/wiki/Scala_(programming_language)
[^] # Haskell !
Posté par lasts . En réponse au journal encoder sur du multicoeur. Évalué à 3.
http://haskell.org
(il faut aussi citer erlang, qui est spécialement orienté concurrence, mais que je connais moins.. dans tous les cas, c'est du bon ^_^)
Bref, pour peu que tu trouves le temps de t'intéresser à ces deux langages fondamentalement différents de ce que tu dois connaître, je pense que tu y trouveras ton compte.
[^] # Re: projet communautaire
Posté par lasts . En réponse au journal Cherche idée pour un mémoire. Évalué à 1.
Bref, je te recommande vivement de t'y intéresser, parce que la programmation GNUstep est à la fois jouissive et bénéfique à la communauté :]
# filtre antispam
Posté par lasts . En réponse au journal Filtrer le Spam. Évalué à 2.
Soit l'adresse email "moi@serveur.org" : je souhaite m'inscrire sur linuxfr (qui revendra certainement mon email à xxx.com pour payer ses serveurs, et dont les membres sont tous plus douteux les un que les autres "FR33 LL ! 3NL4rgE y0uR c0mPut3r"). Pour éviter ce genre de dérapage, je donne l'email "moi@linuxfr.serveur.org" lors de l'inscription qui redirige les mails vers un sous-dossier linuxfr (ou qui modifie le titre de l'email pour "[LINUXFR] titre"). La transparence étant le mot clé de l'histoire, la création du sous-compte linuxfr devrait être automatique (de manière à pouvoir donner son email aussi facilement irl (par ex. "moi@rmll.serveur.org")).
De cette manière, je pense qu'on disposerait d'un système de tri simple et pratique :) ... mais n'en ayant ni les connaissances ni le besoin pour le moment, je me demandais si c'était réalisable / intéressant (et si certains fournisseurs emails proposaient déjà ce service ?).
Visiblement, ça pourrait poser un problème lors d'une réponse, l'email envoyé étant par défaut "moi@serveur.org", sans le sous-domaine (... et un être humain peut facilement passer outre, mais c'est secondaire au problème du spam).
Bref, je suis à la recherche d'avis sur la question, merci d'avance :]