comparaison Rails vs Seaside

• [^]Re: comparaison Rails vs Seaside

  Posté par reno () le 02/04/2007 à 22:15. (lien). Évalué à 4.

  Difficile de dire beurk a l'un, les deux sont différents, c'est tout.
  
  Ceci dit la syntaxe de Smalltalk est quand même un poil difficile a avaler quand on est habitué a la famille des langages C..
  Je me suis souvent demandé si un Smalltalk avec une syntaxe qui ressemblerait plus a celle du C ({} pour les blocs de code, ';' pour les fins de lignes mais en gardant les bonnes idée de Smalltalk: appels par mots-clef, espace comme séparateur pour les listes) n'aurait pas eu plus de succès..

  • [^]Re: comparaison Rails vs Seaside

    Posté par Sylvain Sauvage () le 02/04/2007 à 22:31. (lien). Évalué à 3.

    La syntaxe Ruby n’est pas franchement C non plus, elle me semble pourtant plus facile à avaler par tout un chacun.

  • [^]Re: comparaison Rails vs Seaside

    Posté par Aris Adamantiadis (page perso, ) le 02/04/2007 à 23:00. (lien). Évalué à 5.

    j'ai du apprendre smalltalk dans le cadre d'un projet de génie logiciel (avec seaside, en utilisant visualworks.)
    
    Il y a une notion qui est très utile et qui marche pas trop mal, c'est que *tout code est objet*. C'est à dire qu'il existe des "blocs" comme tu dis:
    [moncode.]
    L'interet, c'est qu'on peut passer du code en parametre, et faire ainsi des callbacks très reactifs. Par ex je me souviens qu'en seaside on pouvait incrémenter un compteur à partir d'un lien de cette manière:
    
    html add: Link new onClicked:[compteur = compteur+1.].
    (pour ceux qui sont novices, l'équivalent du . ou -> du C++ est l'espace, tout se lit de gauche à droite, les appels de methode sont des :, l'allocation d'un nouvel objet est l'appel de la methode new sur sa classe (qui est aussi un objet) et les instructions se terminent par un .)
    
    le langage a des particularités très interessantes, mais c'est dommage que les environnements ne soient pas plus attractifs (les 2 premières semaines avec visualworks n'ont pas été très facile).

    • [^]Re: comparaison Rails vs Seaside

      Posté par Sylvain Sauvage () le 03/04/2007 à 18:28. (lien). Évalué à 2.

      Ruby aussi permet de passer des blocs (entre accolades) qui peuvent utiliser des paramètres.
      Je préfère les vraies lambda mais c’est en cours et les blocs sont aussi une bonne idée.

      • [^]Re: comparaison Rails vs Seaside

        Posté par Damien (page perso, ) le 03/04/2007 à 20:21. (lien). Évalué à 1.

        Sauf qu'en Ruby c'est pas pratique de passer plusieurs blocs à une méthode, il faut les convertir en Proc pour je ne sais quelle raison...
        
        Quelle différence tu fais entre une "vraie lambda" et les blocs Smalltalk ? la curryfication ?

        • [^]Re: comparaison Rails vs Seaside

          Posté par Sylvain Sauvage () le 04/04/2007 à 19:06. (lien). Évalué à 2.

          Je parlais de Ruby et justement du fait que le bloc doit devenir un Proc (par Proc.new ou lambda) et donc qu’un bloc n’est pas une vraie lambda (les Proc le sont) et qu’il y avait une intention de réorganiser cela pour la 2.0 (je ne suis pas ça de très près).
          
          Pour ce qui de Smalltalk, je ne le connais pas assez. Un bloc ne peut pas avoir de paramètre ? C’est triste…

          • [^]Re: comparaison Rails vs Seaside

            Posté par Serge Stinckwich (page perso, ) le 04/04/2007 à 19:42. (lien). Évalué à 1.

            Salut Sylvain,
            si un bloc Smalltalk a des paramètres :
            
            [:x :y | x + y] value:3 value:4.

          • [^]Re: comparaison Rails vs Seaside

            Posté par Fernandes Hilaire (page perso, ) le 04/04/2007 à 20:21. (lien). Évalué à 2.

            Voir ces documents pour les détails :
            
            http://community.ofset.org/wiki/La_syntaxe_de_Smalltalk#Bloc(...)
            http://community.ofset.org/wiki/Les_bases_de_la_syntaxe_Smal(...)

    • [^]Re: comparaison Rails vs Seaside

      Posté par Serge Stinckwich (page perso, ) le 04/04/2007 à 05:52. (lien). Évalué à 1.

      A quoi pense tu quand tu dis environnements plus attractifs ? Eclipse ?

  • [^]Re: comparaison Rails vs Seaside

    Posté par benoar (Jabber id, ) le 03/04/2007 à 02:41. (lien). Évalué à 4.

    Je ne pense pas que la syntaxe aurait beaucoup changé son sort.
    
    Elle est parfois étrange, mais parfois très utile : rien que pour les fonctions qui prennent beaucoup de paramètres, ou alors des paramètres qui se "ressemblent" (par exemple foo(width,height) qui serait appelé comme ça : foo(5,8)), on sait tout de suite quel paramètre correspond à quoi : fooWithWidth: 5 andHeight: 8 (mon expérience vient de l'Objective C, d'où le nommage bizarre, mais la syntaxe est assez similaire à Smalltalk). Bon, c'est vrai que quand on a les paramètres "nommés" comme en Python, ça devient aussi pratique (même plus, puisqu'il n'y a pas d'ordre précis).

    • [^]Re: comparaison Rails vs Seaside

      Posté par Damien (page perso, ) le 03/04/2007 à 08:06. (lien). Évalué à 3.

      Si, il y a un ordre précis. Il faut définir plusieurs méthodes si tu veux avoir le choix: Par exemple Boolean implémente les deux #ifTrue:ifFalse: et #ifFalse:ifTrue:

  • [^]Re: comparaison Rails vs Seaside

    Posté par Damien (page perso, ) le 03/04/2007 à 08:09. (lien). Évalué à 5.

    Ceci dit la syntaxe de Smalltalk est quand même un poil difficile a avaler quand on est habitué a la famille des langages C.
    
    Oui c'est sur, c'est vraiment insurmontable d'apprendre une syntaxe concise. Et puis C est tellement limpide pour manipuler des tableaux de pointeurs de fonctions...

    • [^]Re: comparaison Rails vs Seaside

      Posté par reno () le 03/04/2007 à 13:19. (lien). Évalué à 2.

      Pas insurmontable bien sur, mais je pense que tu sous-estime l'impact de la syntaxe, surtout quand on n'as pas beaucoup d'expérience..
      
      Je me souviens d'une introduction a Smalltalk quand j'étais étudiant, la syntaxe m'avait beaucoup géné, maintenant beaucoup moins..
      
      Mais n'utilisant pas Smalltalk quand je vois un extrait de code [] a la place de {}, ça me gêne du point de vue lisibilité, certes on doit s'y habituer rapidement mais cela ne permet pas de comparer deux extraits de codes facilement..

      • [^]Re: comparaison Rails vs Seaside

        Posté par Damien (page perso, ) le 03/04/2007 à 20:18. (lien). Évalué à 3.

        Je me souviens d'une introduction a Smalltalk quand j'étais étudiant, la syntaxe m'avait beaucoup géné, maintenant beaucoup moins..
        
        Oui, pense à la première fois ou tu as vu du Java ou du C... est-ce qu'on met un ; après une classe, un typedef ? Dans un typedef, celui qu'on définit c'est le premier ou le dernier ? Dans int* i,j,k; pourquoi j et k ne sont pas des pointeurs, etc etc
        
        En Smalltalk tu apprends une fois pour toutes les 3 types de messages, les blocs, et les différents littéraux et c'est fini.

  • [^]Re: comparaison Rails vs Seaside

    Posté par Serge Stinckwich (page perso, ) le 04/04/2007 à 05:48. (lien). Évalué à 1.

    Je pense que ce n'est pas difficile de faire une syntaxe C/Java pour Smalltalk. Il y a tout ce qu'il faut pour le faire en terme de parseur notamment. Après je vois pas trop l'intérêt ... Tu vas écrire {} au lieu de [] pour représenter des blocs ? Mais tu peux envoyer des messages aux blocs Smalltalk, comment vas tu écrire cela ?
    
    Essayons :
    
    [3+4. Date today] value.
    
    devient :
    
    {3+4; Date.today();}.value();
    
    Tu pense que c'est plus clair ?

    • [^]Re: comparaison Rails vs Seaside

      Posté par reno () le 04/04/2007 à 07:57. (lien). Évalué à 2.

      > [3+4. Date today] value.
      vs
      > {3+4; Date.today();}.value();
      
      Il me semble que ça devrait être:
      [3+4. ^Date today] value.
      {3+4; ^Date.today();}.value();
      Enfin je pense, je ne m'y connais pas beaucoup en Smalltalk..
      
      Mais oui, pour moi habitué au C/C++, c'est vraiment beaucoup plus simple de lire la deuxième version que la première..

      • [^]Re: comparaison Rails vs Seaside

        Posté par Serge Stinckwich (page perso, ) le 04/04/2007 à 08:58. (lien). Évalué à 2.

        Le ^ n'est pas nécessaire dans ce cas la.
        Je suis d'accord avec toi que l'on n'aime pas changer ses habitudes ... cela veut dire que tous les langages que nous allons utiliser dans le futur devront tous avoir une syntaxe proche de celle de C ... c'est un peu triste comme perspectives ...
        
        C'est comme les étudiants d'informatique d'aujourd'hui, ils ne connaissent plus qu'une syntaxe (C), qu'un langage de programmation (Java) ... exit Ocaml, Prolog, Lisp, Haskell, Smalltalk, ADA, etc ... c'est la mono-culture, donc forcemment cela appauvrit les esprits.

      • [^]Re: comparaison Rails vs Seaside

        Posté par Serge Stinckwich (page perso, ) le 04/04/2007 à 09:31. (lien). Évalué à 3.

        En ce qui concerne la différence entre la syntaxe de Smalltalk vs celle de C, vous pouvez lire avec intérêt le billet suivant : http://onsmalltalk.com/programming/smalltalk/why-smalltalk/
        
        En fait, ce qui est important dans Smalltalk ce n'est pas la syntaxe, c'est l'environnement. Il faut le pratiquer pour le comprendre et pas uniquement lire des bouts de code sur du papier.
        
        L'exemple qu'il prend est le suivant :
        
        - avec une syntaxe C :
        
        Window window = new Window(0, 0, 800, 600);
        
        - avec une syntaxe Smalltalk :
        
        window := Window top: 0 left: 0 width: 800 height: 600.
        
        C'est beaucoup plus expressif en Smalltalk qu'en C. On comprend en ST que les 4 paramètres sont la position de la fenêtre, sa largeur et sa longueur. C'est impossible avec la syntaxe C/Java, il faut aller voir le code du constructeur pour connaiître la signification des paramètres.

        • [^]Re: comparaison Rails vs Seaside

          Posté par reno () le 04/04/2007 à 12:26. (lien). Évalué à 3.

          Je ne dis pas que la syntaxe du C est meilleure que celle de Smalltalk juste que malgrès sa "clarté" pour toi, la syntaxe Smalltalk n'est pas si évidente..
          Une syntaxe hybride serait bien plus lisible pour les gens habitués au C que du pur Smalltalk, par exemple:
          
          window := Window.new(top:0 left:0 width:800 height:600);

          • [^]Re: comparaison Rails vs Seaside

            Posté par Serge Stinckwich (page perso, ) le 04/04/2007 à 12:43. (lien). Évalué à 3.

            Oui, je suis conscient que c'est pas facile de sortir de ce que l'on connait. Il est difficile de se mettre dans la peau d'un débutant Smalltalk. Mais pour un débutant en informatique, la syntaxe C ne devrait pas sembler plus difficile que celle de Smalltalk.
            
            C'est clair que c'est pas difficile de communiquer :
            - les Smalltalkiens ne comprennent pas pourquoi il faudrait compliquer leur syntaxe pour se faire comprendre des Cistes,
            - les Cistes ne comprennent pas pourquoi il leur faudrait apprendre une autre syntaxe que celle du C.

          • [^]Re: comparaison Rails vs Seaside

            Posté par Fernandes Hilaire (page perso, ) le 04/04/2007 à 12:53. (lien). Évalué à 4.

            L'être humain est ainsi fait qu'il résiste naturellement aux changements, c'est sans doute lié à l'esprit de survie, c'est somme toute salutaire, et cela s'applique à chacun de nous.
            
            L'approche d'un nouveau langage passe donc par les mêmes mécanismes : c'est différent de ce que je connais, cela implique donc un coût d'apprentissage d'initial. Il s'agit donc d'évaluer le ratio coût/bénéfice.
            
            Avant de m'essayer à Smalltalk, j'ai pratiqué du C/C++ pendant des années (cf. le logiciel libre de géométrie Dr.Geo). Ce que j'ai pu constater en pratiquant Smalltalk c'est qu'il y a un changement de plan conceptuel sur la façon d'aborder le processus de développement. Cela ne veut pas dire que c'est plus compliqué, au contraire tout est globalement plus simple, accessible et compréhensible avec Smalltalk, il y a simplement un changement de plan conceptuel. D'un point de vu qualitatif, cela m'a permis d'apprendre beaucoup et beaucoup plus facilement/vite.
            
            A propos de l'intelligence augmentée avec des dispositifs informatiques, Doug Engelbart -- l'inventeur de la souris -- fait une comparaison intéressante: il est très facile de faire du vélo avec un tricycle, en revanche avec une bicyclette c'est plus difficile au départ, mais une fois maîtrisée la bicyclette permet d'aller plus vite et plus loin. C'est la même chose avec Smalltalk.

            • [^]Re: comparaison Rails vs Seaside

              Posté par Damien (page perso, ) le 04/04/2007 à 13:57. (lien). Évalué à 1.

              Oui et c'est plus facile d'apprendre avec un outil simple et minimaliste même s'il semble contre-intuitif au premier abord, qu'avec l'outil final plus de l'assistance.
              
              Pour reprendre la métaphore de l'apprentissage du vélo, ce qui est dur c'est de prendre assez de vitesse pour avoir le temps de mettre les pieds sur les pédales et ensuite essayer de garder l'équilibre. Donc en général on ajoute des roulettes... mais du coup l'enfant apprend à pédaler mais pas à tenir l'équilibre.
              
              Si au contraire on prend un vélo sans roulettes, et qu'on enlève les pédales (une draisienne), c'est très facile de courir et de se laisser rouler ou de profiter des descentes. L'apprentissage est plus progressif, plus drôle, et une fois l'équilibre acquis c'est immédiat de gérer les pédales.
              
              roulettes -> IDE, typage, public static void synchronized {}; etc
              draisienne -> syntaxe minimaliste, modèle objet avec l'essentiel et pas de bruit (et on remet les pédales en abordant le test unitaire, les refactorings et la métaprogrammation :-)

Installation de Seaside

• [^]Re: Installation de Seaside

  Posté par Miguel Moquillon (Jabber id, page perso, ) le 02/04/2007 à 13:24. (lien). Évalué à 3.

  Pour Debian et Ubuntu, il existe des dépôts pour installer squeak :
  deb http://ftp.squeak.org/debian/ testing main
  deb-src http://ftp.squeak.org/debian/ testing main
  (remplacez testing par stable ou unstable selon la version de votre distrib)
  
  Il y a même un packet pour seaside :-)
  Toutefois, il semble que ce soit une version anciènne.
  
  Je recommande donc les images de Damien Cassous qui sont vachement sympa pour rapidement commencer à développer avec.

Langage des dinosaures

• [^]Re: Langage des dinosaures

  Posté par lurker () le 02/04/2007 à 19:30. (lien). Évalué à 3.

  @+ dans le bus

  
  
  Sous le bus.

  --
  /o/

• [^]Re: Langage des dinosaures

  Posté par reno () le 02/04/2007 à 22:28. (lien). Évalué à 2.

  >Ce qui me fait rire c'est soit disant un langage 100 % objet sans notion de privée !!!!
  
  Bof, quel est le si grand avantage d'avoir la notion de privée par rapport a une convention (genre tout ce qui débute par un _ est privé a l'objet)?
  
  Dans les langages qui ont la notion de privée, a coup de cast/reflexion/etc, tu peux facilement accéder aux champs privé..
  
  Un truc que je trouve pas terrible dans Smalltalk est la déclaration des variables au début du bloc, une idée qui a fait son temps et a ajouter a la liste des mauvaise idée dont on doit se débarrasser: la déclaration des variable lors de leur première affectation est une bien meilleure idée.

  • [^]Re: Langage des dinosaures

    Posté par alpage (Jabber id, page perso, ) le 03/04/2007 à 00:00. (lien). Évalué à 3.

    Enfin n'oublions tout de meme pas les apports interessants de ce langage comme MVC ou le refactoring...

  • [^]Re: Langage des dinosaures

    Posté par Damien Cassou () le 03/04/2007 à 08:15. (lien). Évalué à 2.

    > Un truc que je trouve pas terrible dans Smalltalk est la déclaration des variables au début du bloc, une idée qui a fait son temps et a ajouter a la liste des mauvaise idée dont on doit se débarrasser: la déclaration des variable lors de leur première affectation est une bien meilleure idée.
    
    Le problème ne se pose pas vraiment en Smalltalk. La taille moyenne d'une méthode doit être de 7 lignes environ. Contrairement aux autres langages, déclarer toutes les variables au début du bloc rend le code plus court : on déclare toutes les variables en une seule ligne. Par exemple pour déclarer 2 variables :
    
    |persons folders|

    --
    Damien Cassou

    • [^]Re: Langage des dinosaures

      Posté par reno () le 03/04/2007 à 13:34. (lien). Évalué à 2.

      Certes les méthodes sont souvent courtes, mais il n'empêche que ta variable est dans un état intermédiaire 'nil' entre sa déclaration et son utilisation, ce qui peut induire des erreurs..
      
      Personnellement, je pense qu'entre deux constructions équivalentes de langages, celle qui induit le moins d'erreur, à lisibilité équivalente, est préférable, même si le nombre d'erreur induit est faible: c'est toujours ça de gagné!
      
      Il est possible de faire très simple pour la déclaration:
      var foo = pour la déclaration et l'initialisation
      ou comme en Limbo:
      foo := pour la déclaration et l'initialisation
      et foo = pour la modification d'une variable déjà déclarée.

      • [^]Re: Langage des dinosaures

        Posté par Miguel Moquillon (Jabber id, page perso, ) le 03/04/2007 à 16:55. (lien). Évalué à 1.

        Seulement lorsque tu veux sauvegarder ta méthode, l'environnement te crie dessus si jamais les variables ne sont pas initialisées, ne sont pas utilisées, etc. Et l'environnement, c'est Smalltalk (en effet, Smalltalk n'est pas un langage au sens habituel du terme mais un véritable environnement de dév et d'exécution d'objets)
        Donc, finalement ...

      • [^]Re: Langage des dinosaures

        Posté par Damien (page perso, ) le 03/04/2007 à 20:31. (lien). Évalué à 1.

        Certes les méthodes sont souvent courtes, mais il n'empêche que ta variable est dans un état intermédiaire 'nil' entre sa déclaration et son utilisation, ce qui peut induire des erreurs..
        
        En général on s'en rend compte vite de ce genre d'erreur, donc elles sont assez bénignes. C'est le même argument que pour le typage statique : la moindre erreur fait tout péter, donc c'est vite fixé... et comme tu est un développeur sérieux tu as plein de tests unitaires, n'est-ce pas ?
        
        foo := pour la déclaration et l'initialisation
        Sauf que ça disperse les déclarations de variables dans le code, donc il faut les chercher. Or si il y a bien qqch d'important, c'est de savoir si tu as affaire à une variable locale ou une variable d'instance... c'est pour ça que je préfère avoir toutes les variables locales déclarées au même endroit.

        • [^]Re: Langage des dinosaures

          Posté par reno () le 03/04/2007 à 21:58. (lien). Évalué à 4.

          >En général on s'en rend compte vite de ce genre d'erreur, donc elles sont assez bénignes.
          
          Sauf dans les cas ou on ne s'en rend pas compte, bien sur (affectation de la variable dans un if), et la le bug arrive en production..
          
          >tu est un développeur sérieux tu as plein de tests unitaires, n'est-ce pas ?
          
          Les développeur "sérieux" qui testent toutes les combinaison de branchements dans leur code, ça n'existe pas: beaucoup trop de combinaisons possibles.
          
          >Sauf que ça disperse les déclarations de variables dans le code, donc il faut les chercher.
          
          Bof, c'était le même argument pour le C ou le Pascal, en pratique en C++ je n'ai jamais eu le problème de lister les variables locales d'une fonction..
          
          >Or si il y a bien qqch d'important, c'est de savoir si tu as affaire à une variable locale ou une variable d'instance
          
          Bin je ne connais pas l'environnement de dev Smalltalk, mais il ne pourrait pas tout simplement utiliser une coloration pour indiquer la différence?
          Une convention de nommage peut faire l'affaire aussi (avantage, c'est imprimable).
          Ruby impose $ et @ pour différencier les types d'accès, ce qui permet très simplement d'éviter ce genre de confusion.

          • [^]Re: Langage des dinosaures

            Posté par Damien (page perso, ) le 04/04/2007 à 09:05. (lien). Évalué à 1.

            > le bug arrive en production..
            
            Eh ben il arrive et il est vite fixé... me dis pas que les clients mettent immédiatement tout l'avenir de leur boite sur un nouveau système en prod :)
            
            > Les développeur "sérieux" qui testent toutes les combinaison de branchements dans leur code, ça n'existe pas
            
            Non évidemment, on en oublie toujours, mais avec une couverture raisonnable tu attrapes vite beaucoups de bugs. C'est une histoire de confiance et de compromis. Enfin en tant que client ça m'ennuierait d'acheter un truc qui contient du code non testé, qu'il soit typé/initialisé statiquement ou pas...
            
            > Bin je ne connais pas l'environnement de dev Smalltalk, mais il ne pourrait pas tout simplement utiliser une coloration pour indiquer la différence?
            
            Si bien sûr, les outils Smalltalk colorisent comme il faut. Mais ça n'aide que la lecture, pas l'écriture. En fait tu peux taper ton code sans rien déclarer, et au moment de sauver la méthode, le browser te demande "euh, foo est pas déclaré, est-ce que je dois ajouter une var locale, une d'instance, renommer parce que c'est une typo, ou rien faire et compiler du code cassé?"
            
            > Ruby impose $ et @ pour différencier les types d'accès
            
            En Ruby le problème est de savoir quels sont les attributs d'une classe. Si il n'y a pas de attr_accessor ou similaires, il faut aller regarder dans toutes les méthodes et toutes les extensions de la classe dans différents modules et compter les @trucs.

• [^]Re: Langage des dinosaures

  Posté par mathk () le 03/04/2007 à 08:13. (lien). Évalué à 4.

  C'est vrai que ca
  http://www.dabbledb.com/
  ca fait dinosaures.
  
  Ils ont de la chance ces dinosaures.
  Domage que tu vives pas a la même époque qu'eux

• [^]Re: Langage des dinosaures

  Posté par maximegb (page perso, ) le 03/04/2007 à 12:01. (lien). Évalué à 3.

  Enfin bon le smalltalk reste et restera un langage de roger le bricolo pour des fanatiques. Ce qui me fait rire c'est soit disant un langage 100 % objet sans notion de privée !!!!
  
  Ca c'est du troll de compétition !

Pour les fans de framework web en langages exotiques

• [^]Re: Pour les fans de framework web en langages exotiques

  Posté par benja () le 03/04/2007 à 12:16. (lien). Évalué à 3.

  Pour les (futurs?) fans d'ocaml, il y a le serveur web/framework http://ocsigen.org/ qui est vraiment sympa.

  • [^]Re: Pour les fans de framework web en langages exotiques

    Posté par Alex () le 03/04/2007 à 13:05. (lien). Évalué à 1.

    Mouais
    alors moi jaime bien ocaml, jaime bien lisp, jaime bien smalltalk (en tout cas squeak) et seaside m'a pas mal bluffé, tout comme rails et ruby. Ya pas longtemps jme suis même mis au D...
    
    pis ya pas longtemps jme suis dit "tient jvais me chercher un nouvel emploi, question de me faire plus de pépette", j'ai cherché, pis jme suis dit : bon à partir de maintenant je n'apprends que des technos qui me serviront un jour.

    • [^]Re: Pour les fans de framework web en langages exotiques

      Posté par benoar (Jabber id, ) le 03/04/2007 à 13:14. (lien). Évalué à 3.

      Bah oui, ce serait triste si les entreprises réfléchissaient un peu plus à long terme, et payaient un peu plus pour des informaticiens capables de programmer avec des frameworks modernes : il n'y aurait plus de boulot pour la moitié des programmeurs de la planète (dont on retrouve souvent les idées de génie ici : http://thedailywtf.com )

    • [^]Re: Pour les fans de framework web en langages exotiques

      Posté par Nicolas Roard (page perso, ) le 09/04/2007 à 18:03. (lien). Évalué à 1.

      En même temps, tu sait jamais quand un langage "exotique" te sera utile -- au cours d'un entretien d'embauche j'ai eu une boite qui m'a demandé si j'avais déja programmé en ... PostScript (!!) -- la raison étant qu'ils avaient un langage maison implémentant de la logique métier, assez proche de PS (stack-based quoi).
      
      De façon moins anecdotique, je trouve qu'avoir programmé en lisp ou smalltalk (ou autre langage dynamique) change assez radicalement la façon dont on programme par la suite, même si on se retrouve à faire du C/C++/Java. Et en règle générale je suis persuadé qu'on s'enrichit beaucoup au contact de langages "exotiques" -- ça permet d'avoir une autre approche à son arc...

  • [^]Re: Pour les fans de framework web en langages exotiques

    Posté par benoar (Jabber id, ) le 03/04/2007 à 13:12. (lien). Évalué à 2.

    Pas mal : comme tous les frameworks des langages "haut niveau", il est basé sur des light-threads, mais comme Seaside, il utilise les continuations pour modéliser le "parcours" des pages. Lift utilise plutôt un modèle acteur. Je ne sais pas trop comment les comparer (je ne suis pas trop dans le dev web), mais c'était aussi pour montrer une approche différente que je parlais de Lift : je trouve que Ocsigen ressemble pas mal à Seaside, avec un "défaut" pour moi, c'est le HTML dans le code. OK, ça leur permet de dire "on fait du XHTML _typé_ à la compilation", mais alors c'est un mélange que j'hésite un peu à faire, surtout si le HTML doit être retravaillé par des graphistes.

    • [^]Re: Pour les fans de framework web en langages exotiques

      Posté par maximegb (page perso, ) le 03/04/2007 à 20:17. (lien). Évalué à 1.

      HTML doit être retravaillé par des graphistes
      
      Les graphistes ils ont le droit de toucher qu'aux PNG et aux CSS. Le HTML c'est les deveveloppeurs qui commandent !

      • [^]Re: Pour les fans de framework web en langages exotiques

        Posté par benoar (Jabber id, ) le 03/04/2007 à 21:04. (lien). Évalué à 2.

        Oui, c'est vrai qu'aujourd'hui c'est plutôt comme ça. On va dire que c'est des vieux réflexes que j'ai, alors (je répète, je ne suis plus vraiment dans le dev web depuis quelques temps).

performances seaside

• [^]Re: performances seaside

  Posté par Damien (page perso, ) le 03/04/2007 à 08:17. (lien). Évalué à 1.

  Il me semble que dabbledb.com a quelques milliers de comptes, et c'est une application web interactive qui use et abuse de Ajax.

• [^]Re: performances seaside

  Posté par Miguel Moquillon (Jabber id, page perso, ) le 03/04/2007 à 12:46. (lien). Évalué à 1.

  Il apparaîtrait que seaside, ou probablement commanche, le navigateur Web avec lequel s'interface seaside, a des problèmes de montées en charge dans un environnement de production. Pour résoudre ce problème, il convient, comme avec Tomcat, de le disposer en arrière d'un Apache et d'utiliser un load balancer.
  Voir les liens suivant sur le sujet :
  http://onsmalltalk.com/programming/smalltalk/seaside/scaling(...)
  http://onsmalltalk.com/programming/smalltalk/scaling-seaside(...)
  
  Sinon, j'aime bien aussi le sujet suivant ("My journey to Linux" ;-)
  http://onsmalltalk.com/programming/smalltalk/seaside/my-jour(...)

• [^]Re: performances seaside

  Posté par Serge Stinckwich (page perso, ) le 04/04/2007 à 05:40. (lien). Évalué à 1.

  Tu devrais poser ta question sur la mailing-liste Seaside : http://seaside.st/Community/MailingList/ Il y a au moins une entreprise française qui l'utilise en production. Ils avaient des soucis de performances. Ils faudraient leur demander s'ils ont résolu leur problème.