Ontologia a écrit 2138 commentaires

La GPL stipule seulement que la personne à qui tu donnes le binaire doit aussi disposer des sources.
Donc tu peux très bien proposer un business model ou tu fais de la GPL, parce que tu utilises de la GPL (ton code est teinté), mais ne donner le source qu'à ton client et lui faire signer une NDA comme quoi il doit se garder le code source pour lui, avec sanctions à la clé.

Et comme beaucoup de boites se fichent éperdument du source mais ne s'intéresse qu'au service rendu (qui est quantifiable et rassurant), ça peut tout à fait leur convenir...

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Tu as surement raison, mais pour la zone que tu pointes, pour bien la connaître, je peux te dire que ça correspond bien à la réalité.

Ce sont des constructions qui au plus récent ont 70 an et la plupart quelques siècles, ça ressemble vraiment à ça.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

A noter que l'on peut aussi importer le cadastre de la plupart des communes française en utilisant les fichiers cadastraux transformées en OSM ici : http://osm.cquest.org/bati/

Pour avoir essayé sur une zone que je connais ( http://osm.org/go/0A5cz1t3- ) c'est assez efficace et ça permet d'avoir une carte extrêmement précise des villes et village de France.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Ca m'étonne un peu, parce qu'en 5 ans d'utilisation de 10.4, 10.5 et Lion depuis quelques semaines, je n'ai jamais eu un seul plantage de noyau.
Quand à l'USB, je n'ai jamais eu de problème avec.

Les seuls choses que je pourrais reprocher à cet OS, c'est de ne pas proposer les utilitaires Unix GNU, et d'avoir un peu de mal à gérer quand il y a beaucoup d'I/O.
A part ça, ça tourne vraiment bien.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Avaaz est une organisation qui lance de vaste pétition, avec un système très bien organisé.
Les campagnes d'Avaaz dépassent souvent le millions de signataires.

En voyant passer leur pétitition, je pense que la lutte contre ACTA rentre tout à fait dans leur corde.

Pour les contacter :
http://www.avaaz.org/fr/contact?footer

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Je pense qu'il y a du Xème degré, X >>>>>>> 1

En big_endian ou en little_endian ?

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Oui mais dans la pratique, ça marche pour des cas très limités comme celui que tu présentes, mais tu te fais très vite jeter par le compilateur si tu as l'habitude de raisonner comme dans les langages objets classiques.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Comme toujours. C'était pareil avec NoSQL par exemple, il me faut un peu de temps pour voir les utilisation intéressantes.

Oui voilà, bon exemple, NoSQL, je me disais "keskecequecetruc ?" et puis tu intègre et tu commences à voir où le rationnel est bien et où le NoSQL est intéressant :-)

Un langage qui marche pas trop mal en prototype c'est IO :
http://iolanguage.com/

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

J'ai l'habitude un peu bizard de regarder ce genre de cours quand je fais le ménage, ça m'occupe l'esprit.

Je me demandais s'il y avait des cours en français de ce genre.
J'ai écumé diffusion.ens.fr et canal-u et j'ai été un peu déçu..

Certains auraient-ils des liens ?
Merci

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Pour avoir suivi pas mal de discussions entre D. Colnet (papa de SmartEiffel) et B. Sonntag (papa de Lisaac) qui sont évidemment tout à fait solide sur le lambda calcul et la sureté de type vu que c'est leur domaine de recherche, il ressort plusieurs choses :
- On ne sait pas faire de type-safe propre avec de l'objet, parce qu'algébriquement ça cadre mal (pour les détails faut leur demander, j'aurai beaucoup de mal à l'expliquer) avec la notion d'instance ou de clonage.
- Java est bourré de trous dans l'implem des génériques
- Java est un langage qui accepte le cast. Or, désolé, mais le cast, c'est tout sauf type-safe.
- Java possède le type Null, qui est par essence pas type-safe
- Java est covariant, et malheureusement, ce n'est pas type-safe non plus. Si tu veux vraiment l'être, il faut être invariant, car, à moins d'une analyse de flot très profonde sur une fermeture transitive totale du code, tu ne peux pas avoir l'assurance que tu n'auras pas de problèmes. Or, Java, c'est de la compilation séparée. Sans compter l'introspection, où tu ne peux rien savoir.
Regarde le modèle objet de OCaML, là c'est simple, c'est invariant. L'héritage est réduit à sa plus simple expression de ne pas recopier le code, mais lorsqu'il s'agit de mettre B là où il attend A, même si B hérite de A, le compilateur te jette tout de suite !

Bref, Java est un peu type-safe. Les NullPointerException et les ClassCastExceptions quotidiens sont là pour le prouver.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Dans les langages Objet "pur" une classe est un objet comme un autre. Donc tu peut la cloner si tu veut (reste à en trouver l'intérêt).

Oui mais tu as toujours une séparation entre le modèle formel qui n'a aucune existence physique, et la réalité, l'instance.
Là est le problème, même pour les langages à superclasses.

Ce n'est pas une spécificité des prototypes. [chargement méthode à chaud]

Oui mais le problème d'une classe, c'est qu'elle embarque tout son héritage avec elle même, donc si tu modifie une classe plus haut dans l'arbre d'héritage, l'ajout de méthodes que tu vas faire dans la superclasse ne l'atteint pas. Ou alors c'est une affreuse bidouille.

Tu présente des choses puissantes, mais j'ai du mal à voir les cas d'utilisation. J'ai l'impression que c'est un paradigme qui manque de langages.

C'est difficile parce que tu n'as pas l'habitude de penser avec ces nouveaux concepts. Moi même au début j'ai eu du mal.
Le concept de l'héritage diamant dynamique est impossible à faire en classe. Ce type d'héritage te permet de définir une grammaire formelle, avec l'héritage statique, et de définir ton arbre syntaxique avec l'héritage dynamique.
(Xor dans le schéma, c'est l'héritage dynamique)

C'est pas parce que tu ne vois pas d'applications qu'elles n'existent pas. Si tu avais l'habitude de programmer en procédural, tu ne verrais surement pas l'intérêt de l'objet à classe...

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Une classe n'est pas vivante en soit, il faut l'instancier.
Un prototype est vivant, il se clone.

Dans les langages objets à prototype, tu n'as que la notion d'objet qui existe. C'est un pattern singleton en lui même (que l'on s'évertue à reproduire en classe de façon crade).
De plus, comme il n'existe que la notion d'objet, l'héritage se fait au niveau de l'objet, pas de la classe. Par conséquent, l'héritage est dynamique.

Note : le proto en JS est extrêmement mal implémenté.
Mais ça permet aussi de charger des méthodes à chaud, comme en JS, vu que l'objet "mère" est vivant.

Ca permet aussi une vraie séparation physique en mémoire des proto, et donc une séparation physique de l'héritage.
En classe, B hérite A, tu instancie B, B est une concaténation de A et B.
En prototype, A est vivant, B aussi, et le mécanisme d'héritage permet d'appeler le père, qui est un objet vivant à part entière.
Cela permet ainsi de définir des arbres d'héritages complexes, du genre héritage diamant.

Ah, autre chose :
Dans le cadre de l'héritage multiple en proto : l'arbre de recherche se fait en profondeur, pas en largeur.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Alors deux choses :

• En ce qui me concerne, je pense, comme Anthony Hoare, que le type Null ne doit pas exister dans le langage. Point. Foin de NULL_NOT_INITIALIZED, NULL_NOT_FOUND, NULL_REMOVED. Si tu veux gérer ce genre de cas, tu créés un type Somme :

  type probleme = 
  | NULL_NOT_INITIALIZED
  | NULL_NOT_FOUND
  | NULL_REMOVED
  

• Les contraintes strictes sur les types est un sujet très intéressants et peu défriché. En fait tu l'as à haut niveau en OCaML/haskell, et à bas niveau avec des langage comme Esterel, etc... En OCaML/haskell, tu peux faire du type somme, du polymorphisme, bref des types algébriques assez poussé. En Esterel, tu peux mettre des contraintes sur tes entiers, mais Esterel, c'est fait pour du circuit logique (des processeurs quoi).

Bref, ya pa encore de langage qui le gère sur toute la longueur du problème.

En C++ avec les templates, tu peux faire pas mal de choses. Le gros problème de C++, c'est que la sémantique étant catastrophiquement bloatware, et que (donc) le compilateur étant basé sur de la compilation séparé, il est absolument impossible de faire une analyse de flot sur la totalité de ton code pour exporter les contraintes de tes types.
En d'autres terme, le gros problème de C++/Template c'est que le compilo va checker ce qu'il peut checker avec les valeurs en dures qu'il trouve dans le code.
S'il n'en trouve pas, ton code est pas testé, et ça plante au runtime, comme les autres.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Mais tu reconnaitra surement que la plupart des types qui s'amusent à faire un langage n'y connaissent pas grand chose : il y a encore une opposition certaine entre les professeurs Nimbus qui font des trucs "qui servent à rien", et les Ingénieurs "qui sont à peine capable de faire un intranet en Java".
Ca donne des dizaines de variations de java qu'on trouve tous les jours sur Github, google-code, etc....
Et cela au plus haut niveau : Dart en est un exemple vivant !

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

J'ajoute juste que ce pattern est spécifiquement intéressant lorsque le compilateur est capable de détecter l'exhaustivité des cas.

Scala possède ce pattern, mais le compilateur n'étant pas capable de vérifier l'exhaustivité des cas, même simple, c'est là totalement inutile, car on va remplacer un Null Pointer Exception par un cas non géré, un Match Failure.
Le programme plante, ça revient exactement au même.

L'intérêt des langages comme OCaML/Haskell, c'est leur capacité à vérifier à la compilation l'exhaustivité des cas. Et c'est très difficile à faire.

Cela implique que la transformation "sémantique" qu'on a fait avec le type Null*, en y impliquant une contrainte à la déclaration, est détecté à la compilation partout dans le code où la valeur risque d'être utilisé.
C'est là que réside la puissance du concept !

*Dans les langages objets, le type Null est un en même temps un type et une valeur, puisqu'elle représente le "rien". Rien est en même temps une chose et son instance, marrant non ?

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Tout à fait, OCaML possède un mécanisme d'exceptions qui n'a que très peu de différence avec celui de Javouille, mis à part que les exceptions ne sont pas des types, mais ça n'a rien à voir.
Et effectivement, quand tu tombes sur cas None, tu puex souvent être amenés à emmètre une exception, c'est d'ailleurs là que tu tu poses des questions intelligentes sur la gestion de celle-ci, parce qu'elles peuvent se multiplier très vite..

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Les classes sont une régresséion par rapport au prototype, dire que c'est mieux parce que "ça correspond aux habitudes des programmeurs", je trouve ça grave comme réflexe.
Mais bon...

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Heureux que cela t'ait sensibilisé :-)
Désolé pour le langage le plus "commun", OCaML est le langage le moins inconnu qui possède cette propriété.
Eh oui, les langages ne comportant pas de type/valeur Null sont extrêmement rares. C'est quelque chose de très difficile à gérer au niveau du compilateur.
OCaML et Haskell ont une grosse infra derrière, avec une base mathématique théorique de très haut niveau (Théorie du lambda calcul de type), c'est pas à la portée du premier implémenteur de compilateur venu.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

C'est consternant qu'en 2011 on conçoive encore des langage intégrant le type Null...
Antony Hoare, célèbre scientifique qui l'a conçu en 1965, l'a appellé "My Billion-Dollar mistake" estimant à plusieurs milliards de dollars, sans doute quelques dizaines, le coût provoqué durant 40 ans par le Null Reference.

Un bon langage, est un langage sans type Null. Pour avoir codé sans, c'est vraiment génial.

En OCaML (de même qu'en Haskell), où il n'existe pas, on doit gérer ses propriétés sans type Null comme ceci :

class toto = object
 val mutable unePropriete = (None  : string option)
 method getProp = match unePropriete with
 | Some(str) -> str
end

Ici, on ne gère pas le "Null" ici appelé None.
Le compilateur le détecte impitoyablement :

Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
None
class toto :
  object val mutable unePropriete : string option method getProp : string end

Dans le fond, pourquoi garde t-on le type Null ?
A mon sens pour deux raisons :
- Le poids des habitudes
- Et surtout la fainéantise : c'est bien plus difficile, même en intégrant le option de Ocaml, qui simplifie beaucoup de choses, de concevoir son code en ayant à l'esprit que TOUTE ses valeur doivent être assignés avec quelques chose de propre.

Ainsi on se traine ce boulet, qui continue à faire des dégâts !

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

C'était effectivement cela, il avait les droits, mais un petit coup de chmod était nécessaire :-)

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

J'appuie le témoignage de Fabien plus haut.
Pour avoir utilisé postgre dans le cadre d'une petit appli web, je peu te certifier que c'est non seulement très rapide, mais très facile à utiliser et installer.

Je pense qu'on va observer des migrations massives, et pas que du monde MySql. Mes antennes m'apprennent que ça migre un peu partout (Oracle -> Postgre), mais qu'on veut pas trop en parler, peur du qu'en-dira-t-on...

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Un problème m'a beaucoup chagriné en utilisant Android sur mon nouveau téléphone, c'est l'impossibilité d'utiliser les outils GNU. J'ai eu beau cherchr, même pour les compiler soi même, j'ai quasiment rien trouvé.

J'aimerai beaucoup avoir la possibilité d'y avoir un terminal avec les outils GNU classiques et pas seulement la très limité Busybox.
Ne parlons même pas d'un système de package à la Debian.

Peut-être l'un d'entre vous a entendu quelques chose de similaire ?

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Tous ceux en ont marre de passer leur temps à devoir se taper des kilomètres de préfixes templatés dans leurs boucles for comprendront.

Bah utilises un autre langage... plus moderne..

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Le problème du canvas c'est qu'il ne te récupère pas les événements sur chaque graphique que tu dessines dessus. La notion de couche y est de plus absente..
C'est pour cela que j'ai essayé CanvasLayer qui gère plusieurs couches sur le Canvas, mais cette lib n'est plus maintenue et pose quelques problèmes de dysfonctionnements.

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Quelqu'un pourrait appeler son secrétariat pour lui proposer de lui donner des cours de base d'informatique ?

Toutes les coordonnées sont là : http://www.assemblee-nationale.fr/13/tribun/fiches_id/331567.asp

« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker