Tu ne travailles pas dans l'industrie, je me trompe ? Personne ou presque n'utilise de langage si avancé que ça. Un utilisateur d'ocaml/scala/haskell est vu comme un fou avant-gardiste. Les principaux langages sont toujours javascript, php, C, C++, Java, C#, perl, Go, ruby…
si elles demandaient d'introduire des choses difficiles à formaliser dans le langage.
Non pas seulement. Difficile à comprendre par exemple, le comportement de la généricité avec les sous classe, le comportement de l'héritage multiple en diamant, etc… La gestion des multiples constructeur en C++ qui nécessite de bien comprendre le fonctionnement sous-jacent.
En Ocaml, le code de base ne me pose pas de problème, si tu joues avec les modules et leur définition et un gadt au milieu, je vais beaucoup transpirer.
A l'inverse, l'immutabilité de Ocaml permet d'éviter le concept de pointeur que tout débutant déteste.
Bonne question : Vitesse de compilation, sécurité plus simple qu'en C++, un seul binaire : zéro runtime mammouth, faire un serveur web performant en 3 ligne, simplicité (beaucoup moins de blague que C++, ou de gestion mémoire que Rust), plus performant que Java.
C'est sûr qu'il ne faut pas coder en go comme en java.
1) pour avoir des briques de base sur lesquelles réfléchir
2) parce que la beauté théorique n'est qu'une des multiples dimensions d'un langage (clarté, simplicité, debug, vitesse de compile, performance au runtime, …)
Si on ne spécifiait tout qu'une seule fois, sans jamais aucun recouvrement, on ne pourrait pas détecter automatique d'incohérence.)
Je suis assez d'accord avec toi. Mais tu peux rajouter une dimension : on peut vouloir forcer l'usage d'une library d'une certaine façon (contrat). Ainsi, on évite les bug d'un usage de travers. Il y a duplication, mais dans le temps.
Cela me rappelle une discussion sur un codeur MS qui avait rajouter des checks de cohérence avec des assert() dans une lib. Ses utilisateurs râlaient, mais cela voulait surtout dire que des bug étaient masqués.
D'ailleurs si tu regardes la normes aéronautiques (FACE), il y a une description des variables d'entrée assez mortel avec 4 dimensions (ex: vitesse, vitesse par rapport au sol, en m/s, en fixe 32 bit de 0 à 300). Cela permet de coller des lib qui traitent de vitesse et de faire des conversions automatiques par génération de code statiques si l'unité n'est pas la bonne.
Par contre ça en a beaucoup pour la clarté du programme (sans annotation de type, c'est plus dur de lire le code et de comprendre ce qu'il fait), et la redondance apportée par ces annotations permet à nos outils (les compilateurs) de dire parfois "attention, tu utilises la variable x comme un pointeur, mais tu l'as déclarée comme un entier, n'y a-t-il pas confusion ?", ce qui élimine des bugs.
Il me semble que tu te limites trop. Tu embarques ça dans le terme "outils", mais je ne pense pas qu'un code informatique doit se limiter à du texte dans un éditeur de fichier. Eclipse introduit des sorte de lien hypertexte, l'auto-completion et la vérification d'erreur en ligne, cela aide beaucoup le codeur. Il y a une masse d'information qui pourrait être fournis par l'outil de dev, qui ne nécessite pas une notation du codeur. L'idée est qu'un codeur veut de la concision, quitte à faire trop de raccourci (oublies de vérifier les erreur ou les exceptions), mais un relecteur veut de la clarté (il est plus facile de vérifier l'oublie d'un test d'erreur qu'un catch d'exception). Un codeur veut un texte pour décrire ses objets rapidement, un relecteur veut un diagramme de classe ou de machine d'état ou de block pour tout appréhender rapidement.
Je pense vraiment qu'il faut arrêter de voir la sémantique d'un langage uniquement à travers une suite de caractère. Et la meilleur méthode pour écrire un code, n'est pas forcément la meilleur pour le relire.
ocaml sans l'objet et sans le gadt, et le coté module illisible pour non-initié est un super langage simple, mais avec un lib pauvre.
ELM http://elm-lang.org/ est un nouveau langage qui veut reprendre les bonne pratique des nouvelles lib javascript mais vérifier correctement l'usage (react, DOM virtuel…). Il inclus le type sum. C'est un truc à regarder.
Avec la lib de base de Ocaml tu ne fais pas grand chose. En dehors d'un "filtre unix", tu n'as rien sous la main (tout ce qui prend des fichiers en entré et qui produit une sortie). Tout ce qui est serveur ou interface graphique, est obsolète ou niveau bricolage dans ocaml.
Pour faire un compilateur ocaml est génial, pour du web ou une interface graphique, il faut tout refaire soi-même. c'est d'ailleurs pour ça que j'ai regardé golang.
Et si ocaml stagne, c'est Rust qui risque de lui prendre un peu de sa niche écologique restante.
une question d'approche par la simplicité (au risque d'être simpliste parfois), optique qui n'est pas du tout à la mode et qui manquait visiblement à pas mal de monde ; je pense que des langages avec des systèmes de types plus évolués pourraient essayer de s'en inspirer un peu.
Cela me rappelle ocaml qui est léger graphiquement en virant les "," et les "()" avec des mots clef simple comme "let" et "let in", et puis ils ont rajouté un tas de machin comme ".+", le truc le pire étant camlp4 et les notations à base de "<>" et autre "%". qui ressemble à du "modem line noise".
Un des trucs que j'aimais bien dans Lisaac, c'était sa syntaxe à mot clef. C'est à dire que l'on pouvait écrire des fonctions "à trou" genre func CreateUnObjet (string name) with (string comment). Dans les fonctions à grand nombre de paramètres, c'est plus lisible et moins lourd que les langages utilisant le nom du paramètres (ada, vhdl).
Un des trucs pourris mais finalement génial de ocaml, c'était l'absence d'espace de nom pour les type sum. Je pense que c'est génial, car il n'y a jamais aucune ambiguïté sur le mauvais usage d'un type. En cas d'usage de name space, celui-ci est souvent sous-entendu ce qui peut poser des problèmes pour retrouver le bon.
C'est hors du cadre discuté dans mon journal ci-dessus, et personellement je ne comprends pas encore très bien, scientifiquement, l'articulation entre un langage de programmation et les outils qui l'entourent.
Il faut voir cela comme une tache à accomplir avec une quantité non négligeable de code déjà existante. Plus le cycle "mise en avant du problème - correction - test", est rapide plus les développeurs sont contents. Cela peut venir d'outils de check statique ou de vitesse d’exécution (compilation rapide, déploiement simple, lancement de teste en une seul ligne de commande standardisé, possibilité d'instrumentation, etc…)
Le cerveau n'est pas fait pour la logique. Comprendre une suite de if avec un simple AND ou OR est facile, si le nombre de variable augmente, il est souvent bien plus lisible d'imbriquer les if ou d'utiliser un pattern matching ocaml.
Go est un langage simple qui permet d'être productif bien plus que les autres.
Les generics peuvent aussi devenir anti-productif, et complexifie beaucoup les outils. Type sum, oui cela serait bien mais une méthode tagless final, avec transformation des package en module, cela serait peut être mieux. J'aimerais beaucoup des packages avec des paramètres.
clairement aux antipodes de la plupart des systèmes à la pointe de la recherche (par exemple mezzo, ou même rust) qui sont plutôt du coté fonctionnel avec un typage expressif.
Les langages à la pointe de la recherche sont loin d'être les langages de programmation de choix. Ce n'est pas Ocaml, haskell, prolog ou autre qui sont le plus utilisé. C'est les trucs bricolés comme javascript, php, voir java, c++ ou perl.
Un programmeur moyen est incapable d'utiliser un type gadt complexe.
Je me demande si des ergonomes se sont penché sur les langages. J'imagine qu'il aimerait plutôt des dessins type UML simplifié pour décrire les objets, la preuve : on documente de cette façon. Mais je ne connais pas beaucoup de langages qui fonctionnent avec une parti graphique non anecdotique.
Je trouve aussi qu'il n'y a jamais de moyen pour forcer une architecture. Dans un gros projet, le plat de spaghetti arrive quand tout dépend de tout, alors qu'il faudrait définir quel ensemble de module ne doit dépendre de rien et quelle sont les groupes de modules indépendants. En gros, il faudrait pouvoir décrire la barrière conceptuelle qu'il y a entre un ensemble de classe/type à la manière des membres privés d'un objet. C'est souvent ce mélange à terme qui rend les micro-services à la mode : pouvoir séparer "violemment" le code.
Je ne sais pas si vous avez une étude complète disponible pour des langages courants. Go est un train de lancé la réflexion sur go 2.0. Ils veulent surtout des problèmes concrets du langage, et la manière choisit pour les contourner.
J'imagine qu'il serait aussi preneur de votre vision de go 1.x.
Depuis 20 ans que je bosse, on prédit la disparition des mainframes, et pourtant ils sont toujours là !!!
Pour avoir regarder le hardware des BULL genre DPS7000, j'ai l'impression que leur vitesse vient surtout de leur contrôleur disque qui faisait en gros les requêtes de base de donnée en hardware.
Donc, si un construction lance un contrôleur disque spécialisé, on peut imaginer que les mainframes perdent tout intérêts. La plus part des DB utilisent des "moteurs" qu'il peut être possible de porter en HW et de gérer des grappes de SSD ou de HD.
C'est comme l'histoire des ponts d'autoroutes inutiles au dessus de rien. Car la route prévue est passée un peu plus loin. Est-ce un gâchis d'argent ? Pas vraiment, il faudrait 10 ponts inutiles pour que cela coute plus chère qu'un seul pont construit alors que l'autoroute est en fonction.
Tout ce qu'on sait, c'est qu'il y a au moment de l'article plus de 12 000 enquêtes en cours. Ca donne le vertige.
Oui et non. Cela inclue aussi les enfants de 16 ans, ce qui n'est pas aussi inquiétant qu'un mineur de 8 ans. Les ados fuyant un environnement toxique, cela existe aussi. Un mineur de moins de 10 ans qui n'est pas enlevé par un de ses parents ou une femme en mal d'enfants (cela existe pour les bébés) qui a disparu plus de quelques jours, c'est très mal parti.
Mais surtout, il y a bien moins d'affaires "qu'avant". 250 affaires en 30 ans, c'est terrible sans être énorme.
Oui bien sûr, mais j'ai des collègues qui trainaient en bandes gamins. En gros, les gamins se géraient entre eux de 5 à 14 ans, et rentraient le soir.
Dans une banlieue craignosse, tu as toujours peur qu'il finisse copain avec des dealers de drogue, mais le risque est le même dans les banlieue fils-à-papa ou il verra de la cocaïne.
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Tu ne travailles pas dans l'industrie, je me trompe ? Personne ou presque n'utilise de langage si avancé que ça. Un utilisateur d'ocaml/scala/haskell est vu comme un fou avant-gardiste. Les principaux langages sont toujours javascript, php, C, C++, Java, C#, perl, Go, ruby…
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Non pas seulement. Difficile à comprendre par exemple, le comportement de la généricité avec les sous classe, le comportement de l'héritage multiple en diamant, etc… La gestion des multiples constructeur en C++ qui nécessite de bien comprendre le fonctionnement sous-jacent.
En Ocaml, le code de base ne me pose pas de problème, si tu joues avec les modules et leur définition et un gadt au milieu, je vais beaucoup transpirer.
A l'inverse, l'immutabilité de Ocaml permet d'éviter le concept de pointeur que tout débutant déteste.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Bonne question : Vitesse de compilation, sécurité plus simple qu'en C++, un seul binaire : zéro runtime mammouth, faire un serveur web performant en 3 ligne, simplicité (beaucoup moins de blague que C++, ou de gestion mémoire que Rust), plus performant que Java.
C'est sûr qu'il ne faut pas coder en go comme en java.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 5. Dernière modification le 18 octobre 2017 à 17:17.
1) pour avoir des briques de base sur lesquelles réfléchir
2) parce que la beauté théorique n'est qu'une des multiples dimensions d'un langage (clarté, simplicité, debug, vitesse de compile, performance au runtime, …)
"La première sécurité est la liberté"
[^] # Re: Concernant la clarté
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je suis assez d'accord avec toi. Mais tu peux rajouter une dimension : on peut vouloir forcer l'usage d'une library d'une certaine façon (contrat). Ainsi, on évite les bug d'un usage de travers. Il y a duplication, mais dans le temps.
Cela me rappelle une discussion sur un codeur MS qui avait rajouter des checks de cohérence avec des assert() dans une lib. Ses utilisateurs râlaient, mais cela voulait surtout dire que des bug étaient masqués.
D'ailleurs si tu regardes la normes aéronautiques (FACE), il y a une description des variables d'entrée assez mortel avec 4 dimensions (ex: vitesse, vitesse par rapport au sol, en m/s, en fixe 32 bit de 0 à 300). Cela permet de coller des lib qui traitent de vitesse et de faire des conversions automatiques par génération de code statiques si l'unité n'est pas la bonne.
"La première sécurité est la liberté"
[^] # Re: Concernant la clarté
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 5.
Il me semble que tu te limites trop. Tu embarques ça dans le terme "outils", mais je ne pense pas qu'un code informatique doit se limiter à du texte dans un éditeur de fichier. Eclipse introduit des sorte de lien hypertexte, l'auto-completion et la vérification d'erreur en ligne, cela aide beaucoup le codeur. Il y a une masse d'information qui pourrait être fournis par l'outil de dev, qui ne nécessite pas une notation du codeur. L'idée est qu'un codeur veut de la concision, quitte à faire trop de raccourci (oublies de vérifier les erreur ou les exceptions), mais un relecteur veut de la clarté (il est plus facile de vérifier l'oublie d'un test d'erreur qu'un catch d'exception). Un codeur veut un texte pour décrire ses objets rapidement, un relecteur veut un diagramme de classe ou de machine d'état ou de block pour tout appréhender rapidement.
Cette vidéo est absolument à voir : https://www.youtube.com/watch?v=PUv66718DII C'est un rêve de dev d'avoir une boucle de rétroaction aussi rapide.
Je pense vraiment qu'il faut arrêter de voir la sémantique d'un langage uniquement à travers une suite de caractère. Et la meilleur méthode pour écrire un code, n'est pas forcément la meilleur pour le relire.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je suis du même point de vue.
ocaml sans l'objet et sans le gadt, et le coté module illisible pour non-initié est un super langage simple, mais avec un lib pauvre.
ELM http://elm-lang.org/ est un nouveau langage qui veut reprendre les bonne pratique des nouvelles lib javascript mais vérifier correctement l'usage (react, DOM virtuel…). Il inclus le type sum. C'est un truc à regarder.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Je pense que Renaut veut dire que la propreté formelle d'un langage ne le rend pas forcément clair et concis. C'est mieux, mais on peut vivre sans.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Avec la lib de base de Ocaml tu ne fais pas grand chose. En dehors d'un "filtre unix", tu n'as rien sous la main (tout ce qui prend des fichiers en entré et qui produit une sortie). Tout ce qui est serveur ou interface graphique, est obsolète ou niveau bricolage dans ocaml.
Pour faire un compilateur ocaml est génial, pour du web ou une interface graphique, il faut tout refaire soi-même. c'est d'ailleurs pour ça que j'ai regardé golang.
Et si ocaml stagne, c'est Rust qui risque de lui prendre un peu de sa niche écologique restante.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Cela me rappelle ocaml qui est léger graphiquement en virant les "," et les "()" avec des mots clef simple comme "let" et "let in", et puis ils ont rajouté un tas de machin comme ".+", le truc le pire étant camlp4 et les notations à base de "<>" et autre "%". qui ressemble à du "modem line noise".
Un des trucs que j'aimais bien dans Lisaac, c'était sa syntaxe à mot clef. C'est à dire que l'on pouvait écrire des fonctions "à trou" genre func CreateUnObjet (string name) with (string comment). Dans les fonctions à grand nombre de paramètres, c'est plus lisible et moins lourd que les langages utilisant le nom du paramètres (ada, vhdl).
Un des trucs pourris mais finalement génial de ocaml, c'était l'absence d'espace de nom pour les type sum. Je pense que c'est génial, car il n'y a jamais aucune ambiguïté sur le mauvais usage d'un type. En cas d'usage de name space, celui-ci est souvent sous-entendu ce qui peut poser des problèmes pour retrouver le bon.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Il faut voir cela comme une tache à accomplir avec une quantité non négligeable de code déjà existante. Plus le cycle "mise en avant du problème - correction - test", est rapide plus les développeurs sont contents. Cela peut venir d'outils de check statique ou de vitesse d’exécution (compilation rapide, déploiement simple, lancement de teste en une seul ligne de commande standardisé, possibilité d'instrumentation, etc…)
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Le cerveau n'est pas fait pour la logique. Comprendre une suite de if avec un simple AND ou OR est facile, si le nombre de variable augmente, il est souvent bien plus lisible d'imbriquer les if ou d'utiliser un pattern matching ocaml.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
En tout cas, si vous faites un papier sur le langage, signalez-le dans : https://github.com/golang/go/wiki/ExperienceReports
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Go est un langage simple qui permet d'être productif bien plus que les autres.
Les generics peuvent aussi devenir anti-productif, et complexifie beaucoup les outils. Type sum, oui cela serait bien mais une méthode tagless final, avec transformation des package en module, cela serait peut être mieux. J'aimerais beaucoup des packages avec des paramètres.
Les langages à la pointe de la recherche sont loin d'être les langages de programmation de choix. Ce n'est pas Ocaml, haskell, prolog ou autre qui sont le plus utilisé. C'est les trucs bricolés comme javascript, php, voir java, c++ ou perl.
Un programmeur moyen est incapable d'utiliser un type gadt complexe.
"La première sécurité est la liberté"
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Le système d'interface règle un bon paquet de problème.
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je me demande si des ergonomes se sont penché sur les langages. J'imagine qu'il aimerait plutôt des dessins type UML simplifié pour décrire les objets, la preuve : on documente de cette façon. Mais je ne connais pas beaucoup de langages qui fonctionnent avec une parti graphique non anecdotique.
Je trouve aussi qu'il n'y a jamais de moyen pour forcer une architecture. Dans un gros projet, le plat de spaghetti arrive quand tout dépend de tout, alors qu'il faudrait définir quel ensemble de module ne doit dépendre de rien et quelle sont les groupes de modules indépendants. En gros, il faudrait pouvoir décrire la barrière conceptuelle qu'il y a entre un ensemble de classe/type à la manière des membres privés d'un objet. C'est souvent ce mélange à terme qui rend les micro-services à la mode : pouvoir séparer "violemment" le code.
"La première sécurité est la liberté"
# go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je ne sais pas si vous avez une étude complète disponible pour des langages courants. Go est un train de lancé la réflexion sur go 2.0. Ils veulent surtout des problèmes concrets du langage, et la manière choisit pour les contourner.
J'imagine qu'il serait aussi preneur de votre vision de go 1.x.
"La première sécurité est la liberté"
[^] # Re: La fin programmée des Unix proprio
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La mort de Solaris et de SPARC. Évalué à 3.
Pour avoir regarder le hardware des BULL genre DPS7000, j'ai l'impression que leur vitesse vient surtout de leur contrôleur disque qui faisait en gros les requêtes de base de donnée en hardware.
Donc, si un construction lance un contrôleur disque spécialisé, on peut imaginer que les mainframes perdent tout intérêts. La plus part des DB utilisent des "moteurs" qu'il peut être possible de porter en HW et de gérer des grappes de SSD ou de HD.
"La première sécurité est la liberté"
[^] # Re: Anthropisation
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Taxe béton Nicolas Hulot. Évalué à 3.
C'est comme l'histoire des ponts d'autoroutes inutiles au dessus de rien. Car la route prévue est passée un peu plus loin. Est-ce un gâchis d'argent ? Pas vraiment, il faudrait 10 ponts inutiles pour que cela coute plus chère qu'un seul pont construit alors que l'autoroute est en fonction.
"La première sécurité est la liberté"
[^] # Re: x 4
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Taxe béton Nicolas Hulot. Évalué à 3.
http://www.allocine.fr/film/fichefilm_gen_cfilm=131.html
Si tu as vu l'article au dessus sur l'espace laissé aux enfants ?
"La première sécurité est la liberté"
[^] # Re: x 4
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Taxe béton Nicolas Hulot. Évalué à 3.
Le nombre de crime à globalement baisser.
"La première sécurité est la liberté"
[^] # Re: x 4
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Taxe béton Nicolas Hulot. Évalué à 5.
Oui et non. Cela inclue aussi les enfants de 16 ans, ce qui n'est pas aussi inquiétant qu'un mineur de 8 ans. Les ados fuyant un environnement toxique, cela existe aussi. Un mineur de moins de 10 ans qui n'est pas enlevé par un de ses parents ou une femme en mal d'enfants (cela existe pour les bébés) qui a disparu plus de quelques jours, c'est très mal parti.
Mais surtout, il y a bien moins d'affaires "qu'avant". 250 affaires en 30 ans, c'est terrible sans être énorme.
"La première sécurité est la liberté"
[^] # Re: x 4
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Taxe béton Nicolas Hulot. Évalué à 4.
D'où tu sors tes chiffres, cela ne corresponds pas du tout à cet article :
http://www.20minutes.fr/societe/1161425-20130524-20130524-france-disparitions-enfants-constante-hausse
Des mineurs disparus non retrouvés, cela doit être quelques dizaines de crimes par an. 250 familles en 30 ans pour les crimes.
"La première sécurité est la liberté"
[^] # Re: x 4
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Taxe béton Nicolas Hulot. Évalué à 5.
Oui bien sûr, mais j'ai des collègues qui trainaient en bandes gamins. En gros, les gamins se géraient entre eux de 5 à 14 ans, et rentraient le soir.
Dans une banlieue craignosse, tu as toujours peur qu'il finisse copain avec des dealers de drogue, mais le risque est le même dans les banlieue fils-à-papa ou il verra de la cocaïne.
"La première sécurité est la liberté"
[^] # Re: une généralité malheureusement
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Taxe béton Nicolas Hulot. Évalué à 5.
La sncf paye ses voies, pas les machines à pétrole.
"La première sécurité est la liberté"