Squeak stimulé par le projet OLPC

Posté par  (site web personnel) . Modéré par Florent Zara.
Étiquettes :
0
6
jan.
2007
Éducation
Squeak est un langage et un environnement de développement de haut niveau avec un modèle objet simple et cohérent. [NdM : Squeak est une implémentation du langage de programmation Smalltalk.]

Afin de permettre l'intégration de Squeak dans les portables à 100$ pour enfant du projet OLPC, un gros effort est en cours pour permettre le basculement de Squeak sous la licence Apache.

En effet la licence actuelle SqL comporte quelques clauses qui peuvent poser problème dans le cadre d'une diffusion de grand envergure. Courant 2007, Squeak sera enfin disponible sous une licence 100% libre. Le changement de licence est rendu nécessaire par une rédaction maladroite pouvant susciter des inquiétudes ou des incompréhensions. Ainsi, même si la licence actuelle est indiscutablement libre, elle comporte une clause d'indemnisation qui est trop générale, une clause de restriction à l'exportation qui ne sert à rien, une clause sur les fontes qui est légalement invalide...etc

Ces maladresses soulignent l'importance du choix d'une licence car un changement ultérieur est loin d'être simple. Dans un premier temps, il a fallu obtenir l'autorisation d'Apple pour faire le changement de la licence. C'est chose faite.

Mais -- ce serait trop simple -- ce changement de licence ne concerne que la version 1.1. C'est à dire la dernière version développée par Apple. De la version 1.1 à la version actuelle 3.8, il faut obtenir l'autorisation de chacune des personnes ayant participé au développement des versions suivantes de Squeak. En effet, pour des raisons de compatibilité de licence, les développeurs contribuaient sous la licence SqL.

C'est ce travail qu'est en train de faire Viewpoints Research Institute, en demandant à chaque contributeur d'envoyer un document signé autorisant le changement de licence de sa contribution vers la licence Apache.

Aller plus loin

  • # Inclusion de deux projets basés sur Squeak

    Posté par  (site web personnel) . Évalué à 4.

    A noter que Squeak sur OLPC devrait inclure deux développement intéressants :

    V-toys un système de programmation visuelle sans recours au texte principalement destiné à l'apprentissage de la programmation à de jeunes enfants ne sachant pas encore bien lire et à des élèves en difficultés avec l'expression textuelle.
    http://community.ofset.org/wiki/V-toys

    Scratch un environnement de programmation multimédia simplifié qui offre une ergonomie extrémement intuitive (au détriment toutefois de l'homogénéité légendaire de ce système ou tout, absolument tout, est objet)
    http://weblogs.media.mit.edu/llk/scratch/index.html
  • # Pour essayer OLPC

    Posté par  . Évalué à 2.

    Le lien avec toutes les infos :
    http://wiki.laptop.org/go/OS_images_for_emulation
    L'interface est très spéciale : ça vaut vraiment le coup pour les curieux d'entre vous !
    (attention : encore du béta !)
    Par exemple : avec Qemu : le clavier est bloqué : pour corriger, après avoir démarré, faire ctrl+alt+3, se logger avec comme nom "root", taper "modprobe i8042" plusieurs fois jusqu'à ce que ça marche, puis aussi "dhclient" pour l'internet, et enfin ctrl+alt+1 !
  • # Version 3.9

    Posté par  . Évalué à 2.

    Notre cher ami Hilaire aurait-il oublié la version 3.9 sortie il y a déjà quelques mois ?

    * La version officielle : http://www.squeak.org/Download/
    * Une distribution pour les développeurs : http://damien.cassou.free.fr/squeak-dev
    • [^] # Re: Version 3.9

      Posté par  (site web personnel) . Évalué à 2.

      Non bien sûr, mais en fait j'ai écrit 3.8 car c'est la version sur laquelle se base la version Squeak-olpc, mais tu as raison le changement de licence couvre la version 3.9.

      Au passage, la distribution pour développeurs de Damien est vraiment chouette pour ceux qui souhaitent avoir de suite tous les outils avancés de développement Smalltalk.
  • # Et Eiffel ?

    Posté par  . Évalué à 1.

    Pourquoi ce langage et pas le langage Eiffel, qui lui aussi est dérivé de Smalltalk ?
    En plus, le meilleur compilateur est libre (et français) : Smarteiffel (The GNU Eiffel Compiler).
    http://smarteiffel.loria.fr/
    • [^] # Re: Et Eiffel ?

      Posté par  (site web personnel) . Évalué à 1.

      Sauf que SmartEiffel s'éloigne du standard Eiffel.
      • [^] # Re: Et Eiffel ?

        Posté par  . Évalué à 1.

        Ah oui. Je viens de le lire.
        Dommage.

        Et si le standard ECMA Eiffel était vraiment pourri ? ...
        • [^] # Re: Et Eiffel ?

          Posté par  . Évalué à 1.

          C'est pas vraiment que l'un ou l'autre soit <>. Le fork vient surtout d'une divergence d'avis sur l'évolution d'eiffel. ECMA eiffel change significativement par rapport au eiffel historique (celui définit dans les livres déjà parus) ce n'est pas juste une normalisation basé sur ce qui existait.

          En gros maintenant il y a trois version : l'historique, l'ECMA et la smarteiffel.
    • [^] # Re: Et Eiffel ?

      Posté par  . Évalué à 2.

      Il est vrai que je ne connais pas très bien Eiffel, mais de ce que j'en sais, ça n'a pas grand chose à voir avec Smalltalk, mis à part que c'est un langage objet.
      • [^] # Re: Et Eiffel ?

        Posté par  . Évalué à 1.

        Et que tout est objet. Et qu'il y a un ramasse-miettes.

        Mais Eiffel « est toujours le seul langage industriel implémentant en standard les concepts de programmation par contrat. » (dixit Wikipedia).
        • [^] # Re: Et Eiffel ?

          Posté par  . Évalué à 2.

          Si on va par la, la plupart des langage objets sont des descendants de Smalltalk. .
          Ca me semble un peu léger comme points communs.


          Pour ce qui est de la programmation par contrat, j'ai encore des doute (mais j'ai peut-être pas encore tout compris).
          Nul doute sur le fait que celà puisse éviter des bugs. Sur la théorie, je suis tout à fait d'accord.
          Par contre là ou j'ai des problèmes, c'est qu'au niveau d'une application réelle, bien souvent une (post|pre)condition, ou un invariant non vérifié doit être gérer par l'application en tant qu'"erreur métier", et pas planter l'appli sur une rupture de contrat.
          Cela implique de coder deux fois les choses: une fois pour le contrat, et une fois pour gérer l'erreur métier, moi je trouve pas ça terrible.

          Cela est peut-être utile pour la phase de debug, mais je n'ai pas encore trouver une bonne manière d'organiser tout ça, et en plus ça complexifie encore un peu le développement: certain dev peuvent se sentir protégé car ils ont bien codé leur contrats, mais livre-t-on le code avec ou sans les contrats.
          En fait un contrat, utilisé hors de la programmation d'un composant générique, réutilisable (ce qui arrive peu souvent en fait), ça me parrait être un voeux pieux, un peu comme quand je tombe sur un commentaire qui dit: "ça ne devrait pas arrivé" (donc on ne fait rien). L'expérience montre que les utilisateur ont de l'imagination.
          • [^] # Re: Et Eiffel ?

            Posté par  . Évalué à 1.

            Si c'est une erreur metier c'est pris en compte par le logiciel par une procédure spécifique.
            Si c'est pris en compte par le logiciel ce n'est pas une erreur au sens programmation par contrat.
            Donc ce n'est pas a coder deux fois.
        • [^] # Re: Et Eiffel ?

          Posté par  . Évalué à 2.

          D implémente aussi la programmation par contrat, mais je suis d'accord, il n'est pas encore au niveau "industriel" (librairie standard insuffisante).

          Les dev Smalltalk ont travaillé sur des projets pour les enfants, pas étonnant qu'ils soient motivés par l'OLPC.

          Pour ce qui est de "l'erreur métier", c'est mieux oui, mais entre une appli que se plante de bonne heure grace a un contrat mais qui ne fait pas n'importe quoi ou une appli qui fait n'importe quoi, je prefere la premiere.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.