MsieurHappy a écrit 80 commentaires

Si je résume:

1) ton système est dépendant de drivers proprio mal branlés qui bloquent les mises à jours
2) tu utilises l’AUR via yaourt, qui est une technique avancée hors distribution, et tu ne sais pas comment gérer correctement les mises à jours

et tu blâmes ArchLinux ?

Par exemple, le fichier de configuration nginx [de Debian] n'a rien avoir avec celui d'ArchLinux

En fait, il n’a même rien à voir avec tous les autres systèmes. Debian fait sa propre popote qui diffère
de ce qui est prescrit par le projet original. Avec ses avantages et ses inconvénients. Alors que celui
de ArchLinux est «vanilla», et donc très semblable à ce que tu trouveras sur *BSD et la doc officielle.

Mais il est vrai qu’il est beaucoup plus aisé de déployer un serveur Debian que ArchLinux, mais c’est clairement
pas l’ambition de cette dernière.

En tout cas, je te souhaite de trouver le système qui te convienne.

Qu’est-ce qui caractérise «le meilleur bureau libre» ? À moins de croire que tout le monde à les mêmes besoins et usages que toi, je vois comment tu peux affirmer ça.

Et de toute façon, on veut pas «le meilleur bureau libre», mais «le bureau le plus adapté pour être celui par défaut dans Debian». Donc on peut considérer de nombreuses caractéristiques et en exclure un certain nombre qui ne correspondent pas à ta définition du «meilleur bureau libre».

Pour moi, l’utilisabilité de KDE a des années lumières de retard sur celle de XMonad. Mais c’est pas pour autant que je vais propulser ce dernier au rang de «meilleur bureau libre», et encore moins prétendre que ceux qui l’utilisent pas sont des crétins arriérés.

Tu mélanges but et moyen. Les contenus mis en cause sont bien interdit, et sur ce point, il n’y a presque pas de débat.

Mais les moyens proposés sont questionnables sur leur efficacité. Pour reprendre le meurtre, on peut voir comment à évolué à travers le temps sa condamnation en France, en fonction de la technologie, de la société et de leurs effets: peine capitale spécifique à la classe du condamné et au type de meurtre, exécutée publiquement → peine capitale «égalitaire», exécutée publiquement → peine capitale «égalitaire», exécutée à huit-clos → abolition de la peine capitale. La peine capitale était imaginée comme préventive à l’égard des autres justiciables. Ce n’est plus le cas (dans de nombreux pays en tout cas).

Et ça pousse comment les ordinateurs ? C’est quoi comme plante ?

C'est si difficile à comprendre que chaque opération est un appel de fonction ?

C’est pas difficile à comprendre. Mais précisément, c’est un comportement qui n’est probablement pas souhaitable quand on veut minimiser la consommation mémoire et/ou la simplicité du modèle mental. Chaque fois qu’on utilise un opérateur, il faut plonger dans le code pour savoir ce qui se passe réellement.

Une macro de rien du tout, et hop, une épine ôtée du pied:

(def myvar (->> data op1 (op2 arg) op3))

Le type fantôme peut être avantageusement déclaré via newtype:

the type is checked at compile time, at run time the two types can be treated essentially the same, without the overhead or indirection normally associated with a data constructor.

On peut ensuite aussi jouer avec l'extension OverloadedStrings comme suit:

{-# Language OverloadedStrings #-}
module PhantomType where

import GHC.Exts(IsString(..))

data Firstname
data Lastname

newtype P a = P { fromPhantom :: String }

instance IsString (P a) where
    fromString = P

prénom = "George"   :: P Firstname
nom    = "Abitbolt" :: P Lastname

data Client = Client (P Firstname) (P Lastname)

client1 = Client prénom nom
client2 = Client "Charles" "Bronson"
client3 = Client ("PasBill" :: P Firstname) ("PasGates" :: P Lastname)

Du coup on a plus du tout besoin d'utiliser de constructeur.
Mais on peut toujours mettre de façon explicite le type de la chaîne.

client4 = Client nom prénom

test = nom == prénom

ne compileront pas.

Il y a une implémentation de Clojure sur CPython2.

Du coup, les qualités de Clojure et la pelletée de bibliothèques de Python !

https://github.com/halgari/clojure-py

Le projet est encore jeune, mais c'est très prometteur.

Je dirais même que c'est un très bon langage! C'est un de mes langages préférés.
Galois en fait un usage abondant, dans des domaines de pointes. Et les champs de recherche où il est utilisé sont très excitant.

Mais c'était pour répondre à l'affirmation d'Albert_ quant à la différence entre langages impératifs et fonctionnels, qui se trouve peu/pas valable pour Scheme. Ce dernier étant, ce que je définirais, du côté fonctionnel des langages multi-paradigmes. À comparer avec le fonctionnel pur de Haskell, qui tranche carrément.

D'ailleurs, j'ai beaucoup apprécié la comparaison entre Lisp, Scheme et Haskell faite dans Land of Lisp. Ainsi que la petite histoire illustrée à propos de la Republic of Haskell.

Faudrait pas déconner, les Lisp (et le dialect racket utilisé dans le bouquin en particulier) ne sont pas Haskell!

Il y a une partie entière du livre présenté qui aborde «L'Impératif et les Objets». Mutation, boucle while, do, et for, constructions itératives, générateurs, présentation d'une forme voisin et sûr du GOTO et tout le toutim au programme. Woot!

La tout constructible aisément avec les macros hygiéniques de Scheme. Permettant soit à l'enseignant, soit à l'étudiant, de créer à loisir de nouvelles structures à de contrôle et formes syntaxiques.

Alors faudrait arrêter de décrier Scheme simplement parce que tu es ignorant à son sujet ainsi que du contenu du livre présenté.

Et dénoncer Scheme comme représentatif du problème des facs françaises, alors que ce langage est utilisé dans pas mal d'Uni de par le monde pour l'introduction à la programmation et/ou à l'algo (http://www.schemers.com/schools.html), c'est risible.

Précisément, si c'est pour former aux concepts de la programmation, pourquoi enseigner un langage spécifique à un domaine ?

J'ai juste l'impression de me répéter, mais Scheme n'est qu'un support.

Un support relativement neutre (au niveau de l'application), assez mathématique pour pas s'ennuyer de considérations informatico-informatiques, assez souple pour épouser la majorité des paradigmes et d'effleurer la mécanique globale d'un langage de programmation.

Là, on parle pas simplement d'une activité annexe comme la conduire pour tout à chacun. Là on parle de gens qui doivent professionnellement être capable d'écrire des programmes. Pas nécessairement avec l'acuité d'une personne dont c'est l'activité principale. Mais même en tant qu'«informaticien», la programmation peut être une activité plus que secondaire.

Comme déjà dit, c'est pas Scheme l'essentiel, c'est les concepts étudiés et mis en œuvre qui compte. Et ça ne veut pas dire que Scheme doit être le seul langage enseigné.

Et pour ma part, ton raisonnement induit un biais. J'ai le doux rêve que les facs sont sensées former des gens à un science, de tendre à épouser l'état de l'art. Ne pas en sortir formaté pour le marché du travail de l'instant T, mais avec le bagage nécessaire à l'exercice de sa science. Si la branche choisie implique de savoir programmer, il faut dans un premier temps développer les connaissances de base de programmation. Et qu'on soit, à terme, informaticien ou physicien, la base reste la même. En l'occurence, Scheme me semble, ainsi qu'à des personnes bien mieux placées que moi pour le penser, être un langage génial pour assimiler les grands principes.

Par la suite, il est compréhensible qu'on apprenne à utiliser des outils plus spécifique à son domaine. Mais on doit avoir les connaissances pour s'adapter à l'évolution technologique, et non la freiner parce qu'on a seulement appris à utiliser un outil développé il y a 10, 20, 30ans, et non pas à raisonner avec les principes essentiels. D'autant que l'hémergence de langages comme Scala ou Clojure (un lisp) et l'intégration de plus en plus importante de traits fonctionnels dans les langages «mainstream» tend bien à souligner l'importance des concepts fonctionnels.

Si on demande aux facs de niveler le niveau par le bas simplement pour satisfaire les industriels dans l'instant, c'est triste.

J'ajouterais qu'il n'y a pas de quoi s'étonner d'avoir une différence de position sur le marché du travail entre un universitaire et une personne sortie d'école d'ingénieur. Ces filliaires ont des objectifs différents. Si maintenant les gens font le mauvais choix, ou qu'ils n'ont pas conscience de cette différence, c'est un autre problème.

C'est que tu rates complètement l'objectif de cet ouvrage.

Le but n'est pas d'apprendre Scheme pour apprendre Scheme, mais d'utiliser Scheme pour apprendre des concepts et apprendre à raisonner en tant que programmeur. Et là, Scheme a des qualités extra-ordinaire, encore augmenté par les possibilités des dialectes de racket.

Avec Scheme, et cet ouvrage, on va pouvoir aborder la programmation sous des angles très variés et ainsi balayer un large spectre de connaissance, avec aussi bien du fonctionnel pur (abstraction très importante) que de l'impératif sur machine virtuelle à base de registre (modélisation simple d'un processeur, sans s'encomber de l'inutile pour la majorité des cursus), en assimilant les différents degrés d'abstraction (fonction d'ordre suppérieur, POO), les structures de bases (listes, arbres), les mécanismes en jeu (analyse syntaxique, manipulation de l'AST), des concepts avancés (fermeture, programmation paresseuse, continuation-passing style), en touchant à pas mal de choses (I/O, GUI, Web,…).

Le tout avec un seul langage, très propre et régulier. Et qui permet d'appréhender les problèmes avec le style qui nous convient le mieux.

Plein de bonnes choses à mettre dans la tête avant d'apprendre un langage de programmation plus «industriel». Un moyen d'ouvrir l'esprit et de donner une bonne base théorique, surtout avec un temps de cours réduit.

Quand je vois des ingénieurs diplômés qui ont bouffé du Java et du C pendant des années, mais qui ont une base théorique très (très) pauvre, je suis encore plus convaincu de l'intérêt de ce genre de cours.

Aucun langage ne fait plus que ce que fait électronique, ils font de l'abstraction plus ou moins de haut niveau.

Il est certes très utile de comprendre comment fonctionnent les entrailles de la machine, mais l'abstraction a pour but précisément de se détacher du fonctionnement concret de l'ordinateur, et d'offrir un moyen plus élaboré d'aborder les problèmes et d'exprimer plus élégamment leur solution.

L'ordinateur étant une machine à automatiser, autant automatisé ce qui peut l'être également en programmation.

Un nouveau langage pourquoi faire ? Une boucle est une boucle, un test un test etc.

Il y a des langages sans boucle! Alors évidement, il sera toujours exécuté par les mêmes instructions fondamentales du processeur. Mais l'expressivité n'est vraiment pas à négliger.

Ça m'a fait directement penser à l'expérience d'Ontologia: https://linuxfr.org/comments/1138809.html#1138809

Pour ma part, l'apprentissage de différents langages de programmation m'a énormément ouvert d'horizons quant à la manière d'affronter un problème.
Le langage qui a le plus marqué mon esprit est Haskell, et les concepts de programmation fonctionnel en général. Et quand j'utilise un langage de haut-niveau qui n'offre pas cette expressivité, je me sens très frustré. Et Java est probablement un des langages qui m'est le plus pénible tellement il est inexpressif et rigide, sans offrir de réelle contre-partie qualitative.

Et pour ce faire, on pourrait lire le très chouette Land of Lisp ! http://landoflisp.com/

Je le lis actuellement, et m'amuse bien. Que c'est rafraîchissant de programmer des petits jeux (mais pas que) pour découvrir le langage, le tout accompagné d'amusantes illustrations. Sans pour autant remettre en question la qualité technique de l'ouvrage !

Common Lisp y est à l'honneur, mais ça donne les clefs au lecteur pour appréhender les autres dialectes populaires, tel Scheme et Clojure.

Simple but refined, guaranteed to blow your mind.

Je pense effectivement que j'ai assez mal présenter les choses. Et qu'il fallait être dans ma tête pour avoir une vision claire de mon cheminement mental.

L'idée était de montrer l'utilisation de multiples facettes du système de type et que ça pleine compréhension permet d'écrire du code sûr et néanmoins court.

j'ai l'impression que cette complexité vient directement du type de langage d'où le fait de montrer qu'on peut faire plus "simple" (au niveau du raisonnement, de la logique du code) pour arriver à une fonctionnalité assez équivalente

C'est la nature de l'approche qui est très différente. Et c'est bien là qu'on constate la différence de paradigme: fonctionnel vs impératif (à objets). L'apparente complexité provient à mon avis qu'en Haskell on manipule des concepts plus élaborés et plus abstraits, mais le code s'en trouve simplifiée: composition + fonction d'ordre supérieur. Alors qu'en JavaScript on manipule des concepts plus basics (et plus familiers), mais on se retrouve avec un code plus complexe, avec de multiples branchements conditionnels, et plus sujet aux erreurs de programmation. En outre, le code JS n'est même pas équivalent.

Si j'en fais un module complet:
{-# LANGUAGE ExistentialQuantification #-}
module Properties where

import Data.Monoid (mconcat)
import Data.Ord (comparing)

data Property a = forall p. Ord p => Prop (a -> p)

compareProps :: [Property a] -> a -> a -> Ordering
compareProps ps a b = mconcat $ map (\(Prop p) -> comparing p a b) ps
(les imports sont de la lib standard)

Si quelqu'un a l'équivalent dans un autre langage de programmation, ou mieux, qu'il n'hésite pas. :)

mais mon avis est que lorsqu'on se repose trop souvent sur un compilateur, on oublie de réaliser les tests soit-même

C'est clair que c'est pas parce que ça compile que ça fonctionne correctement. Ça ne remplace pas l'écriture de tests. Mais la cohérence forcée du typage par le langage (parce que ça marche aussi bien avec un interpréteur qu'un compilateur en Haskell) permet de formaliser une partie du code et d'offrir des garanties que tu ne peux pas offrir en JS. Alors c'est sûr que pour un script JS sur une page Web l'intérêt est limité, mais dans plein d'autres applications, on va apprécier cette fonctionnalité.

Il y a un malentendu à dissiper: le but n'est pas d'établir une relation d'égalité, mais une relation d'ordre (plus petit, égal, plus grand → LT | EQ | GT) sur une liste de membres, éventuellement en leur appliquant des transformations, tout en garantissant le fonctionnement du code à la compilation.

Mon code tient en 2 lignes (hors imports et la signature de la fonction, cette dernière étant uniquement pour aider à la compréhension du code, pour peu que le système de type de Haskell ne soit pas du chinois pour soi. ;)) ce qui me semble assez élégant et succinct.

En outre, le propos n'était pas tant de débattre sur l'utilité pratique de mon bout de code que de montrer les possibilités d'un système de type fort, statique et puissant. J'en convient, ça n'a probablement aucun intérêt quand on fait du JS, mais là n'est pas le propos. ;)

ha, j'avais pas compris que le but était de se reposer sur un compilo (perso j'aime pas me reposer dessus...)
L'exploitation du compilateur permet 1/ d'éviter des erreurs de programmations qu'on découvre qu'à l'exécution 2/ d'éviter un surcoût à l'exécution pour valider les données.

La différence majeure étant la garantie à la compilation que les champs comparés existent.
Et bien plus encore, car le Property enveloppant une fonction, on peut effectuer des traitements sur les champs avant de les comparer, encore une fois, avec la garantie sur les types.

Si je vais à l'essentiel du fonctionnement de la méthode expliquée, j'ai besoin que de 2 lignes:

data Property a = forall p. Ord p => Prop (a -> p)

compareProps ps a b = mconcat $ map (\(Prop p) -> comparing p a b) p

Pour illustrer les traitements possible, field2 est une liste d'entier dont on comparera la somme plutôt que les éléments, field3 est une chaîne de caractères qu'on comparera en négligeant la case:

compareProps [Prop field1, Prop (sum . field2), Prop (map toLower . field3)] a b

L'égalité (Eq) n'est pas la même chose que la relation d'ordre (Ord).
La majorité du temps, Haskell peut déduire tout seul l'opération d'équalité. Il suffit à la déclaration du datatype d'indiqué de dériver Eq

data Foo a b c = Foo { x :: a, y :: b, z :: c } deriving (Eq)

> Foo 10 20.0 "10" == Foo 10 20.0 "10"
True

Je me permet de vous partager une expérimentation personnelle sur quelques concepts de Haskell.

Quel programmeur n'a jamais eu la rébarbative tâche d'écrire une fonction de comparaison pour un objet/structure avec beaucoup de champs à comparer ? On se retrouve avec un arbre de if/else, ou autre structure de contrôle. Mes premiers pas en Haskell furent le théâtre d'abominables et naïfs

compare a b = case compare (field1 a) (field1 b) of
    EQ -> case compare (field2 a) (field2 b) of
        EQ -> case compare (field3 a) (field3 b) of
            EQ -> compare (length (field4 a)) (length (field4 b))
            ord -> ord
        ord -> ord
    ord -> ord

J'ai donc mis mon cerveau en branle pour profiter de la richesse de Haskell: généricité, type class, fonctions d'ordre supérieur, composition, applications partielles, inférence de type, etc.

En Haskell, on a la chance d'avoir le type Ordering, qui représente le résultat d'une comparaison par 3 constructeurs, plutôt que des entiers:
data Ordering = LT | EQ | GT
qui est une instance de Monoid, ce qui nous permet d'utiliser mappend, et mconcat en particulier, sa généralisation sur les liste:
class Monoid a where
    mempty :: a
    mappend :: a -> a -> a
    mconcat :: [a] -> a

instance Monoid Ordering where
    mempty = EQ
    LT `mappend` _ = LT
    EQ `mappend` y = y
    GT `mappend` _ = GT

En outre, avec la fonction Data.Ord.comparing, on peut aisément comparer un champ, ou plus génériquement une propriété, des valeurs à comparer:
comparing :: Ord a => (b -> a) -> b -> b -> Ordering

Il nous est maintenant possible d'écrire facilement un enchaînement comparaison de propriétés, dont on retourne le résultat dès qu'on a divergence (LT ou GT):
compare a b = mconcat [comparing field1 a b, comparing field2 a b, comparing field3 a b, comparing (length . field4) a b]

Mais c'est encore très redondant et surtout généralisable! On aurait qu'à avoir la liste des champs/propriétés à comparer!

Cependant, comme une liste a un type donné, on ne peut pas voir une liste hétérogène.
C'est là qu'intervient les existential types! On va créer une fine enveloppe pour stocker nos propriétés à comparer, en garantissant le type d'entrée et la possibilité de comparer le type de sortie:

data Property a = forall p. Ord p => Prop (a -> p)

Il nous reste alors plus qu'à jouer du mconcat et du comparing pour écrire une fonction permettant de comparer séquentiellement sur une liste de propriété:

compareProps :: [Property a] -> a -> a -> Ordering
compareProps ps a b = mconcat $ map (\(Prop p) -> comparing p a b) ps

On peut maintenant réécrire notre comparaison plus simplement:
compare = compareProps [Prop field1, Prop field2, Prop field3, Prop (length . field4)]

Le code en question, avec les imports et tout, dans un exemple un peu plus concret: http://media.msieurhappy.net/pub/Properties.hs

Voilà, entre autre chose, ce que peut permettre un puissant système de type. :)


PS: J'ai essayé de faire au mieux, mais ma p'tite présentation est probablement très confuse et impénétrable si on a pas quelques notions de Haskell. Je m'en excuse par avance. /o\

Tant qu'on a la bombe atomique pour protéger la Souveraineté en péril de la France, on peut bien laisser entre les mains d'une boîte étrangère, et pas réputée pour son ouverture, le choix de ce que l'on peut ou non distribuer comme application et contenu aux élèves.

C'est pas sympa de ne pas le mettre dans le sondage, alors qu'il y a eu tout récemment une dépêche à son sujet. :(

Active Record repose maintenant sur la bibliothèque ARel

dans la dépêche. Donc le problème ne serait pas le même ?

Un graphiste qui utilise Debian Stable !? Gimp existait déjà quand Debian Stable est sorti ?

Il faut voir que les mécanismes d'appel sont très différent entre les 2 langages. Il ne sera pas possible de travailler de la même façon.

Avant d'avancer des idées de solution, j'aimerais savoir pourquoi tu as ces valeurs nulles et si elles sont significatives pour le reste du traitement.