Java et le blablabla sémantique sont deux choses différentes qui n'ont rien à voir et que faire le lien entre les deux est un peu débile et facile :)
Les gens qui font des "systèmes un peu complexes avec tout pleins de trucs imbriqués et connectés entre eux dans tout les sens" sont souvent des gens qui utilisent Java, c'est tout.
Ça ne fait pas de Java un truc super, ça ne fait pas non plus des "systèmes un peu complexes avec tout pleins de trucs imbriqués connectés entre eux dans tout les sens" des trucs plus compréhensible.
C'est juste que c'est trop complexe pour être expliqué en quelques mots sauf à utiliser des termes techniques pour lesquels il va te falloir aller faire un tour sur wikipedia :)
Le mieux à mon avis, c'est de proposer des éclaircissements, ou de payer un mec pour le faire à ta place :)
C'est vrai, en fait on peut voir deux choses qui montrent que mon avis c'est triste, et en même temps mon avis c'est pas triste :)
1) si tu as mieux, c'est plus constructif que de dire du mal, et sur ce point, on a beau dire, avec les "fais un patch" on avance plus vite que sans ! C'est *aussi* ce qui fais la force du libre, parce que le modèle tourne autour de la partition de tout le monde a la résolution du problème.
2) Tes remarques sont intéressantes, et je les partage même, et en fait, j'en ai une solution alternative :)
C'est exactement pareil que maven (ou presque), c'est déclaratif avec des plugins, sauf que c'est sympa à utiliser :)
Ça s'appelle sbt (pour Scala Build Tool), ça peut exploiter des dépôts maven ou Ivy (me corriger si je me trompe) et la raison pour laquelle c'est pas relou à utiliser, c'est simplement qu'il ont utilisé EXACTEMENT la même approche, mais de manière plus sympa.
Tout est écrit en Scala, et comme ce langage est super pour faire des DSL (domain specific langage) intégré dans le langage, on se retrouve avec un truc vachement bien, qui compile que quand la description du package et de ses dépendances est valide.
Maintenant pour la relation maven/autre langages, c'est complexes, et si on avait des solutions magiques ça se saurait, donc on peut retourner au "t'as mieux ?".
Il y a quelques tentatives de faire des trucs avec C, et même JNI, voir la série de plugin maven-native-plugin avec le format nar, le pendant du jar mais avec native à la place de java.
C'est simplement complexe et on ne sait pas faire mieux que ça :)
Dire que c'est pas satisfaisant c'est une chose, dire que c'est pas bien ça en est une autre ! D'où ma réaction "non constructive" !
À ce moment, c'est de bonne guerre de la part de Visa et Mastercard !
C'est ça aussi le libéralisme :)
Heureusement que les consomma^W citoyens ne sont pas dupes et vont pénaliser, de bonne guerre, ces entreprises en retour !
En fait il existe des outils qui font ça, voir par exemple findbugs dont on a parlé sur linuxfr il n'y a pas si longtemps.
Mais on ne peut pas encoder cette contrainte au niveau des types (en fait on pourrait dire que findbug étant le typage pour encoder ce genre de chose, c'est juste que c'est un typage pas compris par le compilateur Java mais compris par le vérifieur findbugs).
Donc Java a un typage fort, mais il est pas suffisamment fort, contrairement à Georges.
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é.
Je rebondirais même là dessus pour ajouter que ça peut parfois remplacer les tests.
L'exemple le plus connu et qui fait vraiment mal au cul quand on se remet au Java après avoir fais du Scala, c'est tout ces tests à écrire juste pour s'assurer qu'il n'y a pas un null qui traine.
La contrainte : "{ce paramètre,valeur de retour,etc…} ne peut pas être null" peut être exprimée avec des types !
Et bin on peut faire pareil avec pleins d'autres contraintes encore plus sympa :)
(Et là je ne parle que de type, contrairement à msieur happy qui nous parlait de prog fonctionnelle ET de types :)
ben franchement ça m'a l'air bien compliqué, ou plutôt ça donne l'impression de devoir se casser la tête pour pas grand chose finalement (juste comparer les champs de deux structures...)
Ta solution ne répond pas au problème, on veut que "field1", "field2", "field3" soit des fields d'une structure de donnée qui soit typée, là tu manipule une espèce de map.
Ici le compilateur ne peut PAS vérifier que "field1", "field2", "field3" existe bien dans a et b quand tu fais appel à compare, donc tu dois TE faire confiance (ou à un des 25 mecs avec qui tu bosses :).
Sinon
Du moment qu'on peut travailler avec introspection je ne vois pas vraiment le problème en fait...
C'est pareil, tu dois te faire confiance pour ne pas faire de bêtises.
Alors sur un exemple comme ça, c'est pas la fin du monde (et encore avec ta solution, ça ne marche que sur les maps...), mais sur des plus gros trucs plus complexes ça fait mal à la tête de tout tester avec son cerveau :)
Je te rejoins sur les typeclass de Haskell que tu peux effectivement ré-encoder aussi en Scala, voir le ma réponse au-dessus.
Ce que je voulais mettre en avant c'est qu'il y a différentes utilisation des interfaces, et que Go n'en permet qu'une seule, qui bien que flexible, n'est pas la plus importante à mes yeux dans un monde on ton code a de grandes chance de se retrouver dans les mains d'un autre.
Sinon, oui pour le langage de niche, mais c'est pour ça que je dis que c'est un n-ieme spinoff et qu'il n'innove pas.
En revanche il répond à un besoin très clair, et je ne le nie pas !
J'ai toujours tendance à m'exciter quand je commence à parler de Scala et parfois je peux paraître dédaigneux… Je m'en excuse !
Je crois que tu n’as pas compris leur système d’interfaces. Une même interface est comprise pareille pour tout le monde. Si tu fais un minimum de Go, tu verras par exemple que l’interface Reader est utilisée absolument partout (dans io, http, json, logger,…), et tout le monde la comprend pareil. Idem pour l’interface Error.
Ben oui, c’est ce que fait une interface en Go ; un ReadWriter, c’est un objet sur lequel on peut lire et écrire.
Ou alors j’ai pas compris ce que tu voulais dire par « donner une sémantique à ses méthodes ».
Oui, je n'ai pas été très clair (et un truc m'échappe peut-être), mais en gros, comme ton interface est inférée implicitement, si tout le monde fait bien attention, alors ça va aller, mais imagine qu'une personne implémente un read et un write qui ne sont pas compatible (pour une raison qui m'échappe :) alors est-ce que cette chose implémente ReadWriter ou juste Reader et Writer ?
Ce qui m'embête c'est cet implicite qui ne rend pas les choses explicites : quand je dis que j'implémente ReaderWriter, je signe un contrat pour une sémantique particulière, et peut-être qu'il y a plusieurs ReaderWriter, selon la sémantique.
Quand j'implémente une méthode read, j'implémente une méthode read et je met la signification que je veux derrière.
Sinon, avec des interfaces moins utilisées, des signification différentes vont émerger dans différentes parties du monde et un jour un mec va dire : ah zut, on a pas pareil, il faut se sync ! Ah oui mais merde, on est incapable de savoir à quelle sémantique ce rapporte cette implémentation ou celle-ci. Avec des interfaces, on a juste à regarder de quelle interface on parle (sans oublier qu'il y a un namespace qui permet de différencier les interfaces avec le même nom et ce, par le compilateur, pas un humain !).
> et là, justement ce n'est que du structural typing statiquement typé !
En quoi est-ce supposé être en contradiction ?
Le fait que le lien méthode / interface est implicite avec le structural typing.
Dans Go, l'interface ne sert que à donner des jolis noms à une définition structurelle d'un type, avec des interfaces à la Java, c'est plus qu'un nom, c'est un contrat à signer par ses implémenteurs.
Je suis d'accord, même si ce langage met ensemble des concepts intéressant, ça reste quand même un n-ème spinoff des langages qu'on connait.
Ils ont éventuellement innové avec leur interfaces, mais perso je trouve ça super nul, ça aide pas du tout à bien structurer son code, et c'est super pas utile en terme d’interopérabilité pour quand on fait des libs et qu'on veut avoir des types qui sont compris de la même façon par tout le monde.
La notion d'interface permet de donner une sémantique à ses méthode, et là, justement ce n'est que du structural typing statiquement typé !
En fait, je vais comme à chaque fois revenir à ce que j'aime, mais je trouve qu'un langage comme Scala innove bien plus.
Entre autres avec ses mixins, avec son typage VRAIMENT avancé (higher-kind et autres trucs du genre), avec une vraie réflexion sur le lien entre objets et fonctions.
Et il a même du structural typing... !
On est capable d'y retrouver tout ce qu'on connaissait du monde plus formel des langages fonctionnels, et de tout les délires venant de la théorie des catégories, ce qui permet de fabriquer des abstractions vérifiables (par exemple voir tout le travail sur la concurrence avec des librairies pour le pi-calculus, pour les acteurs, et le tout SANS primitives intégrées au langage contrairement à ce que déclare la présentation de Go comme étant obligatoire pour faire de la concurrence : c'est justement rendu possible par cet objet-fonctionnel).
Enfin bon, Go c'est vachement bien, ça doit bien marcher, être optimisé, mais est-ce que ça va rendre le monde de la programmation et de l’ingénierie du logiciel meilleur ? Je ne pense pas !
Scala ? Oui je le pense : avec de tels langages on développe de nouvelles manière d'aborder les problèmes (voir tout le travail sur les contraintes sémantiques encodées avec les types pour avoir plus de vérification et de sûreté à la compilation par exemple).
Et bin quand tu feras ton propre caramail, tu pourrais toujours patcher ton install pour avoir un dropdown qui sera envoyé comme textes aux autres nodes !
Je ne sais pas si c'est une bonne idée d'utiliser flattr lui-même, mais effectivement, je trouve cette idée plutôt pas mal.
En revanche j'ai du mal à voir quels seraient les inconvénients, parce qu'il doit bien y en avoir :)
On pourrait commencer avec les quelques idées suivantes :
* dictature du contenu par les plus aisés et/ou donateurs
* uniformisation des contenus et populisme/démagogie (pour attirer la donation facile)
Malgré tout, c'est assez révélateur de certains phénomènes. La toute première scène est assez cocace. Les trois sont rivés à leurs portables, et ne le posent même pas lorsqu'ils se parlent. Msn, facebook, les sms, c'est le même combat. La communication est certes plus facile, mais elle est plus insipide aussi. On peut parler des heures avec un inconnu par internet et ne pas le reconnaître dans la rue.
C'est un peu désespérant par certains côtés.
</cite
Sur le coup, je trouve que tu es à côté de la plaque, je te conseille fortement cette vidéo de Benjamin Bayart cité sur linuxfr : https://linuxfr.org/~AddiKT1ve/30383.html
Il y exprime assez bien ce que je pense de ce "phénomène" : internet comme place d'échange et de discussion est aussi réel que la vraie vie. Interagir avec des gens sur internet, c'est aussi du social, c'est aussi de l'interaction, c'est pas du faux, il y a de la vraie information échangée avec des vraies débats qui parfois produisent bien plus de connaissance que des discussions que tu peux avoir dans la vraie vie.
Pour moi, c'est un changement de paradigme d’interaction, et je suis bien heureux d'être là pour voir le monde changer comme ça.
Et sinon, c'est pas parce que tu reconnais pas un mec dans la rue après avoir discuté avec lui sur internet que tu es un gros naze, je vois pas où est le problème...
[^] # Re: J'ai pas compris non plus.
Posté par Victor . En réponse à la dépêche Plusieurs projets sémantiques incubés chez Apache. Évalué à 1.
Les gens qui font des "systèmes un peu complexes avec tout pleins de trucs imbriqués et connectés entre eux dans tout les sens" sont souvent des gens qui utilisent Java, c'est tout.
Ça ne fait pas de Java un truc super, ça ne fait pas non plus des "systèmes un peu complexes avec tout pleins de trucs imbriqués connectés entre eux dans tout les sens" des trucs plus compréhensible.
C'est juste que c'est trop complexe pour être expliqué en quelques mots sauf à utiliser des termes techniques pour lesquels il va te falloir aller faire un tour sur wikipedia :)
Le mieux à mon avis, c'est de proposer des éclaircissements, ou de payer un mec pour le faire à ta place :)
[^] # Re: Commentaire
Posté par Victor . En réponse à la dépêche Focuswriter, un éditeur de texte sans distractions. Évalué à 3.
Si oui, tu as la VO ?
(je ne cherche pas à créer un drame, c'est une vraie question :)
[^] # Re: Logiciels de la fondation Apache
Posté par Victor . En réponse à la dépêche La fondation Apache surfe sur Wave. Évalué à 2.
1) si tu as mieux, c'est plus constructif que de dire du mal, et sur ce point, on a beau dire, avec les "fais un patch" on avance plus vite que sans ! C'est *aussi* ce qui fais la force du libre, parce que le modèle tourne autour de la partition de tout le monde a la résolution du problème.
2) Tes remarques sont intéressantes, et je les partage même, et en fait, j'en ai une solution alternative :)
C'est exactement pareil que maven (ou presque), c'est déclaratif avec des plugins, sauf que c'est sympa à utiliser :)
Ça s'appelle sbt (pour Scala Build Tool), ça peut exploiter des dépôts maven ou Ivy (me corriger si je me trompe) et la raison pour laquelle c'est pas relou à utiliser, c'est simplement qu'il ont utilisé EXACTEMENT la même approche, mais de manière plus sympa.
Tout est écrit en Scala, et comme ce langage est super pour faire des DSL (domain specific langage) intégré dans le langage, on se retrouve avec un truc vachement bien, qui compile que quand la description du package et de ses dépendances est valide.
Maintenant pour la relation maven/autre langages, c'est complexes, et si on avait des solutions magiques ça se saurait, donc on peut retourner au "t'as mieux ?".
Il y a quelques tentatives de faire des trucs avec C, et même JNI, voir la série de plugin maven-native-plugin avec le format nar, le pendant du jar mais avec native à la place de java.
C'est simplement complexe et on ne sait pas faire mieux que ça :)
Dire que c'est pas satisfaisant c'est une chose, dire que c'est pas bien ça en est une autre ! D'où ma réaction "non constructive" !
[^] # Re: Visa, Mastercard, Wikileaks
Posté par Victor . En réponse à la dépêche Wikileaks, petit résumé de l'affaire.. Évalué à 2.
C'est ça aussi le libéralisme :)
Heureusement que les consomma^W citoyens ne sont pas dupes et vont pénaliser, de bonne guerre, ces entreprises en retour !
[^] # Re: Logiciels de la fondation Apache
Posté par Victor . En réponse à la dépêche La fondation Apache surfe sur Wave. Évalué à 3.
[^] # Re: typage mou
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 3.
Mais on ne peut pas encoder cette contrainte au niveau des types (en fait on pourrait dire que findbug étant le typage pour encoder ce genre de chose, c'est juste que c'est un typage pas compris par le compilateur Java mais compris par le vérifieur findbugs).
Donc Java a un typage fort, mais il est pas suffisamment fort, contrairement à Georges.
[^] # Re: typage mou
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 1.
Ou alors ça te dit undefined à la compilation ?
Genre quand tu écris :
compare(a, b, ["field1", "field2", "field3"]);
Ça te dit : oulala attention, tu écris un truc pas très très possible là, parce que field3, ça va être undefined ?
[^] # Re: typage mou
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 2.
[^] # Re: typage mou
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 4.
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é.
Je rebondirais même là dessus pour ajouter que ça peut parfois remplacer les tests.
L'exemple le plus connu et qui fait vraiment mal au cul quand on se remet au Java après avoir fais du Scala, c'est tout ces tests à écrire juste pour s'assurer qu'il n'y a pas un null qui traine.
La contrainte : "{ce paramètre,valeur de retour,etc…} ne peut pas être null" peut être exprimée avec des types !
Et bin on peut faire pareil avec pleins d'autres contraintes encore plus sympa :)
(Et là je ne parle que de type, contrairement à msieur happy qui nous parlait de prog fonctionnelle ET de types :)
[^] # Re: typage mou
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 2.
ben franchement ça m'a l'air bien compliqué, ou plutôt ça donne l'impression de devoir se casser la tête pour pas grand chose finalement (juste comparer les champs de deux structures...)
Ta solution ne répond pas au problème, on veut que "field1", "field2", "field3" soit des fields d'une structure de donnée qui soit typée, là tu manipule une espèce de map.
Ici le compilateur ne peut PAS vérifier que "field1", "field2", "field3" existe bien dans a et b quand tu fais appel à compare, donc tu dois TE faire confiance (ou à un des 25 mecs avec qui tu bosses :).
Sinon
Du moment qu'on peut travailler avec introspection je ne vois pas vraiment le problème en fait...
C'est pareil, tu dois te faire confiance pour ne pas faire de bêtises.
Alors sur un exemple comme ça, c'est pas la fin du monde (et encore avec ta solution, ça ne marche que sur les maps...), mais sur des plus gros trucs plus complexes ça fait mal à la tête de tout tester avec son cerveau :)
[^] # Re: typage mou
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 3.
Mais je pense que les gens ils veulent des trucs cools comme ça :)
(et aussi je voulais encore me la ramener avec du Scala, désolé :>)
[^] # Re: typage mou
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 1.
Voir par exemple :
http://debasishg.blogspot.com/2010/08/using-generalized-type(...)
Ou encore :
http://debasishg.blogspot.com/2010/09/towards-generic-apis-f(...)
[^] # Re: typage mou
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 3.
On est capable d'encoder plus d'information avec les types que avec ocaml (genre des contraintes et autre truc délires comme ça…)
[^] # Re: Mais sinon, pourquoi je devrais m'intéresser à ce énième langage
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 2.
http://infoscience.epfl.ch/record/150346
[^] # Re: Mais sinon, pourquoi je devrais m'intéresser à ce énième langage
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 3.
Ce que je voulais mettre en avant c'est qu'il y a différentes utilisation des interfaces, et que Go n'en permet qu'une seule, qui bien que flexible, n'est pas la plus importante à mes yeux dans un monde on ton code a de grandes chance de se retrouver dans les mains d'un autre.
Sinon, oui pour le langage de niche, mais c'est pour ça que je dis que c'est un n-ieme spinoff et qu'il n'innove pas.
En revanche il répond à un besoin très clair, et je ne le nie pas !
J'ai toujours tendance à m'exciter quand je commence à parler de Scala et parfois je peux paraître dédaigneux… Je m'en excuse !
[^] # Re: Mais sinon, pourquoi je devrais m'intéresser à ce énième langage
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 6.
Je crois que tu n’as pas compris leur système d’interfaces. Une même interface est comprise pareille pour tout le monde. Si tu fais un minimum de Go, tu verras par exemple que l’interface Reader est utilisée absolument partout (dans io, http, json, logger,…), et tout le monde la comprend pareil. Idem pour l’interface Error.
Ben oui, c’est ce que fait une interface en Go ; un ReadWriter, c’est un objet sur lequel on peut lire et écrire.
Ou alors j’ai pas compris ce que tu voulais dire par « donner une sémantique à ses méthodes ».
Oui, je n'ai pas été très clair (et un truc m'échappe peut-être), mais en gros, comme ton interface est inférée implicitement, si tout le monde fait bien attention, alors ça va aller, mais imagine qu'une personne implémente un read et un write qui ne sont pas compatible (pour une raison qui m'échappe :) alors est-ce que cette chose implémente ReadWriter ou juste Reader et Writer ?
Ce qui m'embête c'est cet implicite qui ne rend pas les choses explicites : quand je dis que j'implémente ReaderWriter, je signe un contrat pour une sémantique particulière, et peut-être qu'il y a plusieurs ReaderWriter, selon la sémantique.
Quand j'implémente une méthode read, j'implémente une méthode read et je met la signification que je veux derrière.
Sinon, avec des interfaces moins utilisées, des signification différentes vont émerger dans différentes parties du monde et un jour un mec va dire : ah zut, on a pas pareil, il faut se sync ! Ah oui mais merde, on est incapable de savoir à quelle sémantique ce rapporte cette implémentation ou celle-ci. Avec des interfaces, on a juste à regarder de quelle interface on parle (sans oublier qu'il y a un namespace qui permet de différencier les interfaces avec le même nom et ce, par le compilateur, pas un humain !).
> et là, justement ce n'est que du structural typing statiquement typé !
En quoi est-ce supposé être en contradiction ?
Le fait que le lien méthode / interface est implicite avec le structural typing.
Dans Go, l'interface ne sert que à donner des jolis noms à une définition structurelle d'un type, avec des interfaces à la Java, c'est plus qu'un nom, c'est un contrat à signer par ses implémenteurs.
Et si tu manques de flexibilité et d'ouverture, il existe d'autres solutions qui s'inspire des type classes :
http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf
Sur le typage avancé :
Pour le concept : http://www.cs.kuleuven.be/~adriaan/files/genericshk/tcpoly-o(...)
Pour son utilisation :
http://drops.dagstuhl.de/opus/volltexte/2009/2338/
http://www.comlab.ox.ac.uk//files/2187/ModularVisitor.pdf
Pour la réflexion object / fonctionnel :
http://infoscience.epfl.ch/getfile.py?docid=13847&name=T(...)
Mais bon, ensuite il faut fouiller le web, il y a des millions de trucs passionnants :
http://www.scala-lang.org/node/143
[^] # Re: Mais sinon, pourquoi je devrais m'intéresser à ce énième langage
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 4.
Mais je ne suis pas du tout un expert sur la question :>
[^] # Re: Mais sinon, pourquoi je devrais m'intéresser à ce énième langage
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 3.
Ils ont éventuellement innové avec leur interfaces, mais perso je trouve ça super nul, ça aide pas du tout à bien structurer son code, et c'est super pas utile en terme d’interopérabilité pour quand on fait des libs et qu'on veut avoir des types qui sont compris de la même façon par tout le monde.
La notion d'interface permet de donner une sémantique à ses méthode, et là, justement ce n'est que du structural typing statiquement typé !
En fait, je vais comme à chaque fois revenir à ce que j'aime, mais je trouve qu'un langage comme Scala innove bien plus.
Entre autres avec ses mixins, avec son typage VRAIMENT avancé (higher-kind et autres trucs du genre), avec une vraie réflexion sur le lien entre objets et fonctions.
Et il a même du structural typing... !
On est capable d'y retrouver tout ce qu'on connaissait du monde plus formel des langages fonctionnels, et de tout les délires venant de la théorie des catégories, ce qui permet de fabriquer des abstractions vérifiables (par exemple voir tout le travail sur la concurrence avec des librairies pour le pi-calculus, pour les acteurs, et le tout SANS primitives intégrées au langage contrairement à ce que déclare la présentation de Go comme étant obligatoire pour faire de la concurrence : c'est justement rendu possible par cet objet-fonctionnel).
Enfin bon, Go c'est vachement bien, ça doit bien marcher, être optimisé, mais est-ce que ça va rendre le monde de la programmation et de l’ingénierie du logiciel meilleur ? Je ne pense pas !
Scala ? Oui je le pense : avec de tels langages on développe de nouvelles manière d'aborder les problèmes (voir tout le travail sur les contraintes sémantiques encodées avec les types pour avoir plus de vérification et de sûreté à la compilation par exemple).
[^] # Re: Screenshots
Posté par Victor . En réponse au journal KissCount v0.1. Évalué à 2.
Et si tu es en HLM tu pourras même descendre dans les 100 € si tu es étudiants et bénéficiaire de la CAF :D
[^] # Re: Intéropérabilité
Posté par Victor . En réponse au journal Diaspora en alpha. Évalué à 3.
Je crois me rappeler que les mecs de chez Diaspora avait travaillé avec ceux de GNUSocial sur ces problématiques…
[^] # Re: Gender field ?
Posté par Victor . En réponse au journal Diaspora en alpha. Évalué à 2.
# Flattr... ou autre
Posté par Victor . En réponse au journal Que pensez-vous d'une intégration de Flattr dans Linuxfr ?. Évalué à 6.
Je ne sais pas si c'est une bonne idée d'utiliser flattr lui-même, mais effectivement, je trouve cette idée plutôt pas mal.
En revanche j'ai du mal à voir quels seraient les inconvénients, parce qu'il doit bien y en avoir :)
On pourrait commencer avec les quelques idées suivantes :
* dictature du contenu par les plus aisés et/ou donateurs
* uniformisation des contenus et populisme/démagogie (pour attirer la donation facile)
...
[^] # Re: Révélateur
Posté par Victor . En réponse au journal La nouvelle génération. Évalué à 2.
Par exemple : "On peut parler des heures avec un inconnu par internet et ne pas le reconnaître dans la rue."
[^] # Re: Révélateur
Posté par Victor . En réponse au journal La nouvelle génération. Évalué à 4.
Malgré tout, c'est assez révélateur de certains phénomènes. La toute première scène est assez cocace. Les trois sont rivés à leurs portables, et ne le posent même pas lorsqu'ils se parlent. Msn, facebook, les sms, c'est le même combat. La communication est certes plus facile, mais elle est plus insipide aussi. On peut parler des heures avec un inconnu par internet et ne pas le reconnaître dans la rue.
C'est un peu désespérant par certains côtés.
</cite
Sur le coup, je trouve que tu es à côté de la plaque, je te conseille fortement cette vidéo de Benjamin Bayart cité sur linuxfr :
https://linuxfr.org/~AddiKT1ve/30383.html
Il y exprime assez bien ce que je pense de ce "phénomène" : internet comme place d'échange et de discussion est aussi réel que la vraie vie. Interagir avec des gens sur internet, c'est aussi du social, c'est aussi de l'interaction, c'est pas du faux, il y a de la vraie information échangée avec des vraies débats qui parfois produisent bien plus de connaissance que des discussions que tu peux avoir dans la vraie vie.
Pour moi, c'est un changement de paradigme d’interaction, et je suis bien heureux d'être là pour voir le monde changer comme ça.
Et sinon, c'est pas parce que tu reconnais pas un mec dans la rue après avoir discuté avec lui sur internet que tu es un gros naze, je vois pas où est le problème...
# vCard
Posté par Victor . En réponse au journal Généralisation de la décentralisation & XMPP ?. Évalué à 7.
Pour l'avatar c'est flagrant, pour les autres, ce ne serait pas étonnant !