jeudi 24 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

: Squeak stimulé par le projet OLPC

Posté par Fernandes Hilaire (page perso, ). Modéré le 06 janvier 2007.
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.

> Lire la dépêche (13 commentaires, moyenne: 1,7).  

Vous avez demandé le commentaire #792460.

Et Eiffel ?

Posté par Florian G (Jabber id, ) le 08/01/2007 à 02:28. (lien). É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/

--
Comment marchent le « moinssage » et le « plussage » ?

  • [^]Re: Et Eiffel ?

    Posté par Mildred (Jabber id, page perso, ) le 08/01/2007 à 08:39. (lien). Évalué à 1.

    Sauf que SmartEiffel s'éloigne du standard Eiffel.

    --
    La Roue du Temps

    • [^]Re: Et Eiffel ?

      Posté par Florian G (Jabber id, ) le 08/01/2007 à 17:29. (lien). Évalué à 1.

      Ah oui. Je viens de le lire.
      Dommage.

      Et si le standard ECMA Eiffel était vraiment pourri ? ...

      --
      Comment marchent le « moinssage » et le « plussage » ?

      • [^]Re: Et Eiffel ?

        Posté par outs () le 08/01/2007 à 18:33. (lien). É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 Papa Furax (page perso, ) le 09/01/2007 à 13:13. (lien). É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 Florian G (Jabber id, ) le 09/01/2007 à 21:24. (lien). É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).

      --
      Comment marchent le « moinssage » et le « plussage » ?

      • [^]Re: Et Eiffel ?

        Posté par Papa Furax (page perso, ) le 10/01/2007 à 09:50. (lien). É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 outs () le 11/01/2007 à 08:54. (lien). É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 reno () le 11/01/2007 à 22:51. (lien). É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.

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0757s (dont 0.006 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.