Lisaac 0.12 en GPL v3

Posté par Ontologia (site web personnel) le 24 septembre 2007 à 17:00. Modéré par Jaimé Ragnagna.

Étiquettes :

sept.

2007

Après un an de travail intensif, Benoit Sonntag nous livre une version stable et intégralement réécrite de Lisaac, un langage ayant une productivité proche des langages de script avec les performances du C. Lisaac est un langage objet à prototype avec une bibliothèque et un compilateur sous licence GPLv3.

Les benchs effectués sur des traductions fidèles de programmes C donnent des résultats différents en fonction de l'architecture cible : on obtient, grossièrement, un code de 20 % plus rapide à 30 % plus lent.

La spécification 0.2 apporte de nombreuses nouveautés au langage : un système de types amélioré, une syntaxe où la casse permet de séparer clairement mot-clé, prototype/type et variables, un système de contrats amélioré et gérant l'héritage, une gestion automatique des micro/macro objets, l'héritage alimentaire, une gestion des blocks très puissante. L'innovation la plus visible est l'apparition des résultats multiples : une méthode peut retourner plusieurs valeurs, de même qu'elle peut en accepter plusieurs en argument.

Le compilateur est en outre capable de produire des statistiques sur les appels potentiels sur NULL et de prédire l'endroit où ils risquent d'arriver. Les temps d'exécution, la consommation mémoire et surtout la stabilité du compilateur ont été considérablement améliorés.

L'intérêt majeur pour le libre est la disponibilité du seul compilateur objet au monde à réaliser une analyse de flot profonde du code. Cette technique de compilation, qui analyse et prédit les chemins potentiellement empruntés par le code à l'exécution permet une optimisation très poussée de celui-ci afin se rapprocher des performances du C (voir les benchs).

Dominique Colnet (auteur de SmartEiffel) et Benoit Sonntag ont quasiment terminé un traducteur Eiffel vers Lisaac. Ce traducteur permettra à Lisaac de bénéficier d'une bibliothèque Eiffel rigoureusement traduite de l'originale, et donc de disposer d'une bibliothèque testée et sûre. Cette bibliothèque devra ensuite être retravaillée afin d'utiliser au mieux la puissance d'un langage objet à prototype.

La version 0.3 de Lisaac, implémentera la gestion de la concurrence avec le modèle COP, qui automatisera celle-ci. La version 0.4 apportera la stabilisation syntaxique, sémantique et fonctionnelle du langage, ce qui permettra le lancement du projet Isaac OS, le système d'exploitation objet à prototype. Le projet Isaac sera ainsi réellement lancé.

Espérons que la communauté répondra présent à ce formidable défi.

NdM : l'"héritage alimentaire" est appelé comme cela car c'est un héritage qui possède toutes les propriétés de l'héritage classique, mais "secrètement". C'est à dire que vu de l'extérieur de l'objet qui utilise ledit héritage alimentaire, on ne sait pas qu'il hérite. Lisaac est un langage objet à prototype conçu au LORIA (INRIA Lorraine) en 2001. Il a été conçu afin d'écrire le système d'exploitation objet IsaacOS. Lisaac s'inspire de SmallTalk pour sa syntaxe à mot clé et sa logique exclusivement objet, de Self pour l'objet à prototype et d'Eiffel pour le typage statique ainsi que la programmation par contrat. La philosophie qui l'inspire se veut la plus minimaliste possible, de sorte à proposer un langage simple à apprendre, sans une multitude de mots clés et subtilités.

La principale difficulté fut de réussir à compiler un tel langage afin d'obtenir des performances permettant d'écrire un système d'exploitation autonome. En effet, la plupart des langages orientés objet compilés (C++, Eiffel...) utilisent soit des techniques de tables virtuelles (C++) pour résoudre la liaison dynamique (choix de l'objet sur lequel appeler une méthode, en fonction de l'arbre d'héritage) ou de résolution syntaxique grossière (Eiffel). Le compilateur Lisaac utilise une technique d'analyse de flot, certes très consommatrice en mémoire (algorithme exponentiel), afin d'analyser les possibilités d'exécution, prédire les appels, les spécialisations de type et optimiser le code en conséquence. Le langage étant très minimaliste (le compilateur ne connait pas la conditionnelle qui est défini dans la bibliothèque, à la manière de Smalltalk), le compilateur travaille sur une sémantique très bas niveau, ce qui lui permet de généraliser toutes sortes d'optimisations, en analysant la géométrie du graphe du code.

Adhérant largement aux principes de génie logiciel définis par Bertrand Meyer, le concepteur d'Eiffel, Benoit Sonntag a conçu un langage fortement typé et doté de contrats.
Le compilateur embarque aussi la possibilité de définir des contrats qui permettront de s'assurer de la validité de chaque unité de code et de s'arrêter à l'endroit où se trouve le problème, puis de l'afficher. Un système permettant de vérifier statiquement une partie des contrats a été implémenté dans cette version.

Lisaac, un peu à la manière de Smalltalk, possède le prototype BLOCK comme fondement. BLOCK est une liste d'instructions à évaluation retardée jusqu'à l'appel de la méthode .value. On peut ainsi écrire toutes les structures de contrôle que l'on désire, écrire des fonctions que l'on ne retrouve généralement que dans les langages fonctionnels (comme map/fold/filter).

La fonction fold_left de collection, est définie par :

- fold_left function:BLOCK with element:E :E
( + result:E;

result := element;
lower.to upper do { j:INTEGER;
result := function.value (result,item j);
};
result
);

s'utilise

maliste.fold_left { i,j : INTEGER;
i.max j
} with 0;

maliste étant un tableau d'entier.

La bibliothèque, directement issue de celle d'Eiffel, n'utilise que très peu ces possibilités. Les évolutions de celle-ci vont donc entre autre chercher à en tirer plus souvent partie.

En Lisaac, il n'existe pas de différence entre slots et données, ainsi la syntaxe est la même entre une propriété et une méthode. De même une méthode peut devenir une donnée :

- code_vers_donnee : INTEGER
+ un_entier_quelconque : INTEGER;
// code
// ...
code_vers_donnee := un_entier_quelconque
);

code_vers_donnee va devenir et rester une propriété. Bien évidemment, il pourra redevenir plus tard une fonction.

On peut jouer de la même façon avec le slot définissant le parent. En effet, héritage dynamique oblige, le parent est défini dans la section Inherit :

Section Inherit
+ parent : Expanded FATHER := FATHER;

// Code...
Section Public
- set_parent p_parent : FATHER
parent := p_parent;
);

On peut définir parent où l'on veut dans le reste du code du prototype.

Apport de la spécification 0.2

La spécification 0.2 apporte des innovations importantes

Meilleur typage grâce à l'héritage alimentaire et au mot clé Strict qui impose strictement l'utilisation d'un type.
L'héritage alimentaire (Interfaces ou mix-ins) permet de profiter des avantages de l'héritage sans hériter du type. Ainsi si B hérite alimentairement de A, B ne peut être de type A, même s'il hérite de l'ensemble de ses slots. C'est un concept existant dans les langages SmartEiffel (qui a maintenant sa propre norme) et Sather, qui permet de réaliser des arbres d'héritage beaucoup plus propre.
Un système de contrats amélioré permet de choisir le niveau de debug, afin de choisir la "profondeur" de test des contrats.
Un slot peut renvoyer une liste de valeurs, et on peut de même définir un slot (une variable) comme une liste de type :
- mavar : (INTEGER,STRING,CHARACTER);
Le mot clé Expanded remplace *.
Une meilleur gestion des BLOCK. Lisaac est maintenant capable d'encapsuler le contexte Self dans un block, ce qui permet de stocker ceux-ci où l'on veut et de les déclencher au besoin.
Le support en natif des réels flottants et à virgule fixe.
Un nouveau gestionnaire mémoire et le Garbage Collector ont été totalement réécrits.

Le gestionnaire mémoire est entre autre issu d'une réflexion initiée en lisant un article de LinuxFR et suite à ce journal. Il s'agissait d'essayer de voisiner les données utilisées en même temps afin de s'assurer qu'elles se trouvent en cache L1 à l'exécution. Nicolas Boulay a ensuite rapidement embrayé une discussion avec Benoit Sonntag afin de mettre au point diverses optimisations. En effet, Lisaac n'utilise que très peu le système d'allocation mémoire du système d'exploitation. Il s'alloue un quantum de mémoire (virtuelle) et la gère ensuite à sa façon. Cela permet d'obtenir des optimisations très sensibles et poussées du code.

Le Garbage Collector de Lisaac est certainement un des ramasses-miettes les plus rapides à l'heure actuelle. Il est basé sur une architecture de type "Mark and Sweep" améliorée. En effet un "Mark and Sweep" classique parcourt tous les pointeurs, considérant n'importe quoi comme une référence possible. Le compilateur Lisaac génère un GC qui connait le type des objets qu'il gère, ce qui permet d'accélérer le marquage. Plus précisément, le marquage oublie volontairement les entiers, les caractères et les NATIVE_ARRAY (prototype de base pour les collections, qu'il est déconseillé d'utiliser).

Des contrats sur des données et du code
Non content de permettre de poser des contrats sur des slots de code, il est aussi possible d'en poser sur des slots de données. Par exemple, je veux qu'un entier soit strictement supérieur à 50 et soit un multiple de 11.
Autrement dit que
[i in |N | i>50 | i mod 11 = 0 ]

Rien de plus facile en Lisaac. À la déclaration de la variable, on écrit :
- i : INTEGER := 110 [ ? {(Result > 50) && {(Result % 11) = 0}}; ];

Le mode debug activé, le compilateur compilera le programme de façon à ce que chaque accès à la variable i vérifie ce contrat. Si celui-ci n'est pas respecté, le programme s'arrête avec un message d'erreur indiquant une valeur non autorisé pour la variable i.

Cette fonctionnalité appartenant à la spécification 0.2 est désactivée dans cette version 0.12 et sera activée dans la version suivante.

Éditeurs et coloration syntaxique
Des templates de coloration syntaxique sont disponibles pour les principaux éditeurs, notamment emacs, Vim, récemment proposé par Xavier Oswald, mais aussi Kate/KDevelop, développé par Anthony Pajot, qui, outre la coloration syntaxique, permet même la complétion sous KDevelop.

Projets
Les prochaines évolutions de la bibliothèque, pour une bonne partie d'entre elles, serviront de base à IsaacOS, qui sera libéré dans quelques mois, lorsque la version de Lisaac implémentant la spécification 0.3 proposant COP (Concurent Object Programming), sera prête.

Lorsque le traducteur Eiffel vers Lisaac sera disponible, on synthétisera une bonne partie de la bibliothèque avec celle de SmartEiffel, qui est testée et certifiée depuis 15 ans. Il sera alors temps d'amender celle-ci d'un point de vue cosmétique, afin de lui faire épouser les réelles possibilités du langage (en particulier les possibilités offertes par le type BLOCK).

Un effort de documentation est à fournir, en effet la bibliothèque donne lieu à deux version de la doc : la version "référence" qui se veut complète mais succincte, et une version plus détaillée qui renseigne chaque méthode des principaux prototypes de la bibliothèque, en détaillant chaque paramètre. Les deux documentations sont incomplètes pour le moment, mais suffisantes pour démarrer. En outre, à la suite de la contribution de Jérome Hilbert, Simon Fuhlhaber et Grégoire Jacquemin produisant un schéma UML (en svg) d'un ensemble de source Lisaac, nous aimerions améliorer celui-ci afin de le rendre plus configurable (position, couleurs des items)

Des rapports de bugs sont attendus pour la bibliothèque et le compilateur, n'hésitez pas à compiler vos programmes avec, cela vous (et nous) permettra de savoir où cela plante exactement.

Nous envisageons, dans les mois qui viennent, de mettre en place une sorte de CPAN pour le langage Lisaac.

À noter que la bibliothèque étant GPLv3, tout logiciel écrit avec cette bibliothèque est elle-même GPLv3 (vaccination oblige).

Aller plus loin

Isaac Project (145 clics)
Page de téléchargement (74 clics)
Benchmarks (36 clics)
Lisaac sur Wikipédia (64 clics)

# Sather

Posté par Sytoka Modon (site web personnel) le 24 septembre 2007 à 17:50. Évalué à 3.

Etant un admirateur de Sather, je ne peux qu'être enchanté par cette annonce parfaitement rédigée.

Merci.
- [^] # Re: Sather
  
  Posté par ciol le 24 septembre 2007 à 17:59. Évalué à -9.
  
  Pareil.
  
  (non en fait je veux juste qu'on me plussoie parce que j'en ai marre d'être d'office à -2 je veux écrire des JOURNAUX ><)
- [^] # Re: Sather
  
  Posté par Ontologia (site web personnel) le 24 septembre 2007 à 22:07. Évalué à 3.
  
  Ah et en passant, je rend à césar son idée, puisque le projet de CLAN (clone de Perl CPAN) est une idée de Sytoka.
  
  Espérons que la masse critique soit suffisante pour que cela serve à quelques chose...
  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
  - [^] # Re: Sather
    
    Posté par Sytoka Modon (site web personnel) le 27 septembre 2007 à 07:54. Évalué à 6.
    
    Génial, je suis bien content que nos discutions est amené ce point là qui manque tant à OCaml et à Effeil.
    
    En parlant du CLAN, la notion d'espace de nom a-t-elle été rajouté dans Lisaac ? Je sais que Benoit est contre mais comme il a été indiqué dans pas mal de post de cette nouvelle, l'aspect social est important dans la réussite d'un langage. Or je suis sur que pouvoir structurer l'arbre des classes dans des espaces de noms et donc pouvoir les ranger par thème dans le CLAN est très important. Au niveau du compilateur, vu qu'il y a une optimisation globale, la notion d'espace de nom n'a aucun intérêt. C'est cependant un des soucis d'Effeil de ne pas supporter cela car l'arbre des classes d'Effeil est un 'bordel' à mon sens car il y a 10000 classes à plat. Comment retrouver ses petits la dedans ?
    
    Si on prends le CPAN de Perl, les choses sont classées dans des boites, ce qui est sous l'espace Apache:: concerne Apache et ainsi de suite... C'est hyper clair pour l'utilisateur et facilite grandement search.cpan.org !
    
    Puisque je suis cité, j'en profites, c'est pas tous les jours ;-) Un autre de mes dadas était les iterator de Sather qui était implémenté sous forme de coroutine et qui était bien supérieur a tout ce que j'ai vu dans d'autres langages. Tu l'as dis toi-même dans un de tes posts ci-dessous, un GROS problème en programmation est le nombre d'erreur réalisé dans les bornes des boucles. C'est là ou les iterators de Sather était sublime car je ne me souviens plus avoir fait ce genre d'erreur dans ce langage ce qui n'a pas été le cas avec tous les autres langages que j'ai utilisé.
    
    Pour ceux qui pense que les iterators de leur langage sont aussi bien que ceux de Sather, je conseille d'aller voir la page suivante et de prendre le temps d'aller au dela du premier exemple...
    
    http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)
    
    Ma question est donc : est-il possible de faire aussi bien en Lisaac ?
    - [^] # Re: Sather
      
      Posté par Mildred (site web personnel) le 27 septembre 2007 à 12:40. Évalué à 4.
      
      Non, il n'y a pas d'espaces de noms. Actuellement, tous les prototypes du compilateur (l'équivalent des classes) doivent avoir un nom différent.
      
      Je ravaille sur un patch du compilateur afin de pouvoir séparer la compilation en projets. Un projet contient des prototypes publics accessibles par les autres projets, et des prototypes privés réservés à lui seul.
      
      Le gros avantage c'est de permettre d'avoir plusieurs prototypes de même nom dans la compilation. Et permet donc un cloisonnement minimal. Cela permet de créer des bibliothèques sans se soucier des noms des prototypes publics par exemple.
      
      Par contre, il n'y a pas de possibilité de préfixer les noms des prototypes par le nom du projet (il faudrait changer le langage, je change juste le compilateur), et il n'y a pas de possibilité de faire des imports partiels ou de renommer des prototypes. Si le besoin est vraiment grand, c'est toujours possible de faire un import partiel/renommage en important un projet intermédiaire qui exporte juste les bons prototypes.
    - [^] # Re: Sather
      
      Posté par Ontologia (site web personnel) le 27 septembre 2007 à 15:01. Évalué à 2.
      
      J'ai scotché quelques minutes en tête à tête avec ta doc, et soudain fiat lux !
      
      En fait c'est quoi les iterator à la Sather ?
      
      C'est l'idée que je définis une boucle, et qu'un message sur une classe integer va me permettre de définir le sous ensemble parcouru dans cette boucle.
      C'est potentiellement très puissant, car ça évite de faire joujou avec un index à l'intérieur, et ça aide à la lecture du code parce qu'on comprend tout de suite ce qu'on fait.
      
      Figure toi que j'ai implémenté ça en Lisaac (avec l'aide de Ben sur la fin) en Lisaac il y a quelques jours... Mais en plus puissant !
      
      j'ai pensé à ça, après avoir lu et relu cette doc qui est géniale :
      http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf
      
      Le pb des parcours d'ensemble y est pas mal abordé.
      
      Sather te permet de le faire, mais le problème est que tu es limité par les messages sur int (ceux avec le !), alors que le système qu'on a codé permet d'aller plus loin :
      
      La méthode se trouve dans numeric :
      
      - to upper:NUMERIC do action:BLOCK items func:BLOCK <-
      
      ça s'utilise comment ?
      
      1.to 7 do { i : NUMERIC;
      //code
      sum := sum + i;
      } items { j:NUMERIC;
      j.factorial
      }
      Dans cet exemple tu va sommer les factoriel (le i du premier bloc, prend le resultat de l'itérateur (j, qui va de 1 à 7) appliqué au deuxième), et ce qu'il y a de mieux par rapport à Sather, c'est que tu n'a pas besoin d'utiliser un message existant dans NUMERIC... Il te suffit de définir un BLOCK qui prend un int et t'en renvoi un. Et tu définis ce que tu veux
      
      D'après ce que j'ai vu, ça apas été rajouté dans la dernière release (c'est un oubli), tu te le rajoute et tu pourras jouer avec :)
      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
      - [^] # Re: Sather
        
        Posté par Sytoka Modon (site web personnel) le 28 septembre 2007 à 08:54. Évalué à 6.
        
        As tu regardé les pages suivantes ?
        
        comment définir un iterator http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)
        
        quelques exemples avec plusieurs iterator et pas forcément entier http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)
        
        J'ai l'impression que ce que tu fait est à des lieux des iterators de Sather et ressemble fortement à ceux de Ruby.
        
        Il faut bien comprendre ceci. Un objet dans Sather peut avoir trois types d'objet qui lui sont rattaché : des attributs, des méthodes (jusque là, que du classique) et des iterators. Un itetator N'EST PAS une méthode et ne se comporte pas du tout pareil.
        
        Un iterator est une coroutine qui n'est valable que dans un block loop. Il peut y avoir plusieurs iterators dans un même block (ce qui n'est souvent pas le cas dans les autres langages qui n'ont pas d'iterator de bas niveau mais un truc simulé via des méthodes).
        
        Un iterator peut avoir des paramêtres de type IN, OUT et INOUT mais avec aussi la notion ONCE ou non. Si un paramêtre à l'adjectif ONCE, il n'est évalué que lors du PREMIER appel alors que sinon, il est évalué à chaque appel.
        
        Un iterator n'a pas de valeur de retour comme une fonction mais se suspend via l'instruction yield et renvoi provisoirement une valeur à ce moment là. Lors du prochain appel, c'est l'instruction qui suit yield qui est exécuté.
        
        S'il y a une boucle avec plusieurs iterators, c'est le premier iterator qui se termine (plus de yield) qui permet de quitter la boucle, que les autres iterators soit finis ou non. Par contre, le langage à ce moment termine tous les contextes des autres co-routine non finit et purge la mémoire (mais tout cela est complètement transparent).
        
        Les iterators de Sather ne sont pas du tout limité aux entiers. C'est juste un cas particulier. Il y a par exemple des ietrator sur les booléens qui permettent de faire les boucles while et until facilement. Il y a plein d'iterator sur les chaînes et aussi sur les réels.
        
        Je vais mettre deux exemples que j'aime bien mais la syntaxe de linuxfr est parfois casse-pied. On en trouve d'autres sur le web mieux rédigés.
        
        Il faut évidement définir x mais il n'y a pas besoin de l'initialisér, c'est l'iterator sum! qui s'en occupe. Dans cet exemple, trois itérators fonctionnent en parallèle et le code est particulièrement clair et sur (qui n'a pas oublié un jour de faire x:=0 avant la boucle ?).
        
        loop x := sum!(a.elt! * b.elt!); end;
        
        Un autre qui parle d'affichage qui permet d'imprimer "1,2,3" en mettant une virgule entre les éléments juste ou il faut.
        
        a:ARRAY{INT} := |1,2,3|; loop #OUT + ",".separate!(a.elt!.str); end;
        
        L'iterator separate! est définit comme suit :
        
        class STR is ... separate!(s: STR): STR is -- La premiere iteration, on retourne juste la chaine 's' -- Sur les suivantes, on retourne Self + 's' yield s.str; loop yield self + s.str; end; end; ... end;
        
        On remarque qu'il y a une boucle infini dans l'itérator separate! Cette boucle ne s'arrête jamais, simplement, lorsque l'iterator separate! n'a plus rien à manger, la boucle au dessus s'arrête d'elle même et toutes les coroutines en cours de tout le contexte sont automatiquement nettoyé.
        
        On voit bien sur ces exemples que le block LOOP est particulier et permet de gérer les contextes des iterator. C'est le fait d'avoir ce block spécial qui donne toute la force à ces iterators. Les iterators ne peuvent être employés que dans les block loop avec une petite extension syntaxique avec 'parloop' pour la partie calcul parallèle de Sather
        http://www.gnu.org/software/sather/docs-1.2/specification/pa(...)
        Un dernier lien qui donne les spécifications du langage, c'est pas le document le plus pédagogique que j'ai trouvé ;-)
        http://www.gnu.org/software/sather/docs-1.2/specification/sa(...)
# Pertinence de cette dépeche ?

Posté par Lucas le 24 septembre 2007 à 18:41. Évalué à -6.

A chaque fois qu'une dépeche sur Lissac passe sur DLFP, je me demande ce qu'elle fait là. Alors cette fois-ci, j'exprime mes doutes.

Il me semble que Lissac est juste un language de recherche parmi énormément d'autres. Je ne remets pas en doute son côté innovant, mais pourquoi publier cette dépêche sur DLFP ? Surtout en première page ? Est-ce que ça veut dire que tous les projets de recherche publiés sous licence libre vont avoir droit à une dépêche de premiere page sur DLFP ?

De plus, qui est cet "Ontologia", dont la page perso est celle du projet Isaac ? Quelle est sa relation avec Benjamin Sonntag et avec les modérateurs de DLFP ? A noter que la page Wikipédia de Lisaac[1] est également écrite par lui, et qu'elle provoque également des interrogations[2,3].

[1] http://fr.wikipedia.org/wiki/Lisaac
[2] http://fr.wikipedia.org/wiki/Discuter:Lisaac
[3] http://fr.wikipedia.org/wiki/Utilisateur:Ontologiae
- [^] # Re: Pertinence de cette dépeche ?
  
  Posté par Troy McClure (site web personnel) le 24 septembre 2007 à 19:18. Évalué à 9.
  
  rapport avec le libre: oui
  depeche bien redigée: oui
  
  moi je ne vois pas en vertu de quoi on refuserait une telle dépeche.
  - [^] # Re: Pertinence de cette dépeche ?
    
    Posté par Antoine le 24 septembre 2007 à 19:21. Évalué à 0.
    
    moi je ne vois pas en vertu de quoi on refuserait une telle dépeche.
    
    Parce qu'il y a chaque jour des centaines de projets libres qui sortent une nouvelle version et qu'il faut bien faire un choix ?
    - [^] # Re: Pertinence de cette dépeche ?
      
      Posté par Benoît Sibaud (site web personnel) le 24 septembre 2007 à 19:42. Évalué à 10.
      
      > Parce qu'il y a chaque jour des centaines de projets libres qui sortent une nouvelle version et qu'il faut bien faire un choix ?
      
      Le jour où ces centaines de projets libres enverront des centaines des dépêches concernant leur projet respectif, on envisagera de faire un tel choix. En attendant, on passe les dépêches bien rédigées traitant de logiciel libre, et si certains veulent plus de dépêches, qu'ils en proposent, et si certains veulent des dépêches sur un sujet X ou Y, qu'ils en proposent... Maintenant si certains ne veulent pas voir de dépêches sur W ou Z, et bien qu'ils ne les lisent pas...
      
      Les règles de modération sont détaillées sur https://linuxfr.org/moderateurs/moderation.html .
      - [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Lucas le 25 septembre 2007 à 08:49. Évalué à 6.
        
        Attention: je ne remets pas en cause l'intérêt pour la recherche et l'innovation de Lisaac. Je trouve juste votre manière de communiquer un peu curieuse. Comme je l'ai dit plus haut, il y a des dizaines de langages de recherche, tous très innovants dans un domaine particulier. Et il y a aussi des centaines de projets de recherche très innovants qui ne sont pas des langages. :-) Pourtant, il n'y a que sur Lisaac qu'on a régulièrement des dépêches DLFP. Bon, on m'a dit que si une dépêche est bien rédigée en français, et parle de libre, pas de problème pour la passer en première page. OK. J'en prends note.
        
        Maintenant, des questions constructives:
        
        Sur Wikipédia, Lisaac est mis à côté de langages qui ont été utilisés pour des centaines de softs. Peux-tu donner quelques exemples de logiciels écrits en Lisaac ?
        
        Il y a un problème courant de licence avec les compilateurs. Puisqu'en général, ils recopient une partie de leur code dans les fichiers générés, il faut utiliser une exception pour que les fichiers générés ne soient pas soumises à la même licence. C'est le cas de GCC ou de flex: GCC est sous GPL, mais cela n'a pas d'incidence sur les programmes compilés avec GCC. Est-ce qu'une exception similaire est présente dans Lisaac ? Ce qui permettrait à qqun de réimplémenter la bibliothèque (qui elle, est sous GPL, c'est sûr) sous une autre licence ?
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 11:07. Évalué à 1.
        
        Tu racontes n'importe quoi sur les licences. Les licences ne peuvent absoluement pas s'appliquer sur ce qui est généré, c'est du n'importe quoi.
        
        Tu mélanges la licence du compilo et la licence de la library qui va avec.
        "La première sécurité est la liberté"
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par M le 25 septembre 2007 à 21:38. Évalué à 2.
        
        mouais la frontière n'est pas si nette que ca ?
        
        Par exemple les buildin gcc ca rentre dans quelle catégorie ?
        c'est pas du code de la bibliothèque (et pas library), car on ne fait pas appel a une fonction externe
        c'est pas du code générer bêtement (ie traduite un + du language en un + assembleur).
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Mildred (site web personnel) le 27 septembre 2007 à 12:50. Évalué à 1.
        
        Il n'y a pas vraiment de builtin en Lisaac, tout est pris de la lib standard.
        
        mais c'est vrai que si tu fait un string du compilateur, tu va trouver des constructions C qui sont utilisés pour générer le code. Mais je ne pense pas que ce soit problématique.
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par benoar le 29 septembre 2007 à 20:14. Évalué à 2.
        
        Renseigne toi un peu avant de critiquer comme ça : Il existe une exception spéciale de la libstd++ qui permet d'utiliser les templates dans du code proprio car quand tu utilises des templates de cette lib, un bout du code de la libstd++ va se retrouver dans ton code. Et donc théoriquement tu ne pourrais pas faire de proprio, ou autre chose que de la (L)GPL, s'il n'y avait pas cette exception.
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par TeXitoi (site web personnel) le 29 septembre 2007 à 20:55. Évalué à 2.
        
        Les templates, c'est des bibliothèques, c'est pas le compilo...
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Matthieu Moy (site web personnel) le 30 septembre 2007 à 18:11. Évalué à 2.
        
        Oui, mais tel que GCC les compile, le code compilé correspondant aux templates est dans le binaire, et non dans la bibliothèque partagée.
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par benoar le 30 septembre 2007 à 18:52. Évalué à 3.
        
        ... ce qui en fait donc un travail dérivé et devrait donc se soumettre aux conditions de la LGPL, car cela n'est pas du simple linkage. Bref, c'est uniquement grâce à cette exception (en plus de l'"exception" pour linkage) qu'on peut faire du proprio avec la libstd++ et les templates, et qu'un compilateur quelconque, même sous LGPLv3, devrait se préoccuper si des bouts de sa "lib standard" ne se retrouveraient pas dans le code généré, ce qui ferait que tous les programmes compilés avec seraient forcément sous (L)GPLv3.
        
        C'était pour préciser un peu que les problèmes de licences ne sont pas si simples que ça... et ça me fait peur que nicO (qui fait apparemment plus ou moins partie des "devs" de Lisaac ?) en ait rien à foutre...
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Sytoka Modon (site web personnel) le 30 septembre 2007 à 21:04. Évalué à 0.
        
        D'un autre coté, je préfère un Lisaac 100% libre que la solution batarde de scilab. Au moins avec un Lisacc et un CLAN, on peut espérer voir quelque chose dans le monde libre alors que scilab a un réel problème à résoudre qui n'a toujours pas de solution.
        
        Si on prends un autre langage que j'aime bien, perl, j'avoue que je n'ai vu que du perl libre la ou je suis passé.
        
        J'ai cru comprendre que Lisaac était passé du coté du CNRS ? Serais L'INRIA le problème...
        
        Ok, je -> []
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par benoar le 30 septembre 2007 à 21:11. Évalué à 0.
        
        Tu parles de la clause "non commerciale" de scilab ? Donc le 100% libre selon toi, c'est bien qu'on puisse commercialiser Lisaac ?
        
        Je pose ces questions parce que je ne vois pas complètement le rapport avec avoir du "100% libre" : avec scilab, c'est du libre forcément non commercial, et avec Lisaac c'est du libre éventuellement commercialisé. Donc dans les deux cas c'est "libre" au sens où on ne pourra pas dériver du code pour faire du proprio (!= commercial, hein), ce qui est déjà pour moi une très bonne chose (mais c'est vrai que le non-commercial de scilab peut bloquer un peu sa montée en popularité).
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Nicolas Boulay (site web personnel) le 30 septembre 2007 à 21:28. Évalué à 4.
        
        Par définition, du libre non commercial n'est _pas_ du libre.
        
        Les clauses nc empèchent de faire des distributions type mandriva, red hat, suse. Ils empèchent de distribuer les binaires dans une révue. Il empèche de diffuser sur des sites web qui vivent de la pub. Bref, c'est quasi ingérable à redistribuer, ce qui est un des points majeurs du libre.
        
        Alors, certe, tu peux me dire que l'on peut demander. Mais l'un des points fort du libre, c'est justement que l'on a pas besoin de demander ! J'imagine bien Mandriva gérer un contact avec les détenteurs des copyrights des 16000 logiciels de leur distrib...
        "La première sécurité est la liberté"
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par benoar le 01 octobre 2007 à 13:53. Évalué à 1.
        
        Oui bien sûr que ce n'est pas libre si on ne peut pas commercialiser le résultat. Je ne comprenais juste pas le "on peut espérer voir quelque chose dans le monde libre", alors qu'avec scilab c'est tout à fait possible, même si ce ne sera pas complètement libre, au sens où on ne pourra pas commercialiser des dérivés de scilab.
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Nicolas Boulay (site web personnel) le 30 septembre 2007 à 21:33. Évalué à 2.
        
        Il n'y a pas de notion de "link" dans la GPL. Uniquement une notion de "travaux dérivés".
        
        Il peut y avoir des travaux dérivés de la la lib standard. Mais un compilo ne génère jamais du travail dérivé. Je ne voix d'ailleurs pas de quel exception tu parles pour libstd++. Elle n'est pas simplement sous lgpl ?
        
        La LGPL définit une sorte de périmètre/module autour de la lib. Je pense qu'il est clair que l'utilisation d'une collection dans un code, ne contamine pas le code en question puisque l'on ne touche pas à la signification de la dite collection.
        "La première sécurité est la liberté"
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Matthieu Moy (site web personnel) le 30 septembre 2007 à 23:24. Évalué à 3.
        
        > Mais un compilo ne génère jamais du travail dérivé.
        
        Si je prends un cas d'école (pas un compilateur, mais c'est pour le principe) :
        
        #! /bin/sh
        [... pleins de choses ...]
        cat $0
        
        Est-ce que la sortie de mon script est un travail dérivé de mon script ?
        
        > Je ne voix d'ailleurs pas de quel exception tu parles pour libstd++
        
        Une solution aurait été de regarder la licence de ladite libstdc++ :
        
        The libstdc++-v3 library is licensed under the terms of the GNU General
        Public License, with this special exception:
        
        As a special exception, you may use this file as part of a free software
        library without restriction. Specifically, if other files instantiate
        templates or use macros or inline functions from this file, or you compile
        this file and link it with other files to produce an executable, this
        file does not by itself cause the resulting executable to be covered by
        the GNU General Public License. This exception does not however
        invalidate any other reasons why the executable file might be covered by
        the GNU General Public License.
        
        Par contre, ce que je ne comprends plus (j'étais persuadé que c'était LGPL + exception), c'est comment une application propriétaire peut linker la libstdc++ (partie non-template).
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par benoar le 01 octobre 2007 à 13:57. Évalué à 2.
        
        Contrairement à ce que dit nicO, il y a bien une notion de linkage dans la GPL : c'est d'ailleurs pour ça que le LGPL existe ... Cette licence dit juste que un programme qui se linke à la libstd++ (ou tout autre lib sous LGPL) n'est pas considéré comme du travail dérivé, et ne doit donc pas forcément respecter les obligations de la LGPL. Typiquement, quand on fait du proprio.
        
        Merci d'avoir ressorti le texte de l'exception : c'est juste la "continuité" de l'exception pour linkage dont je parle, pour dire que comme dans le C++ on peut se retrouver avec du code LGPL dans son code quand on utilise des templates, et bien on n'est pas non plus obligé de respecter la LGPL, puisque ce n'est alors pas considéré comme un travail dérivé.
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Nicolas Boulay (site web personnel) le 01 octobre 2007 à 14:17. Évalué à 2.
        
        Trouves dans la gpl l'endroit ou l'on parle de bibliothèque ou de notion de link, je suis curieux...
        "La première sécurité est la liberté"
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Matthieu Moy (site web personnel) le 01 octobre 2007 à 14:36. Évalué à 4.
        
        Tu as tout à fait raison sur ce point : les seules occurences des mots « link » et « library » dans la GPL sont dans le dernier paragraphe, qui ne fait pas partie à proprement parler de la licence :
        
        This General Public License does not permit incorporating your program into
        proprietary programs. If your program is a subroutine library, you may
        consider it more useful to permit linking proprietary applications with the
        library. If this is what you want to do, use the GNU Lesser General
        Public License instead of this License.
        
        La GPL se base sur la notion de « travaux dérivés », sans la définir (donc, il faut prendre les définitions dans la loi qui s'applique). Mais l'interprétation usuelle de « travaux dérivés » est que linker avec une bibliothèque (statique ou dynamique) constitue un travail dérivé. C'est en tous cas l'interprétation des auteurs de la GPL :
        
        http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
        
        D'ailleurs, en parlant de libstdc++, il y a une question de cette FAQ dessus :
        
        http://www.gnu.org/licenses/gpl-faq.html#LibGCCException
        
        Does the libstdc++ exception permit dynamic linking?
        
        Yes. The intent of the exception is to allow people to compile proprietary software using gcc.
        
        Mais je ne comprends pas très bien pourquoi ne pas avoir utilisé la LGPL, si c'est pour avoir une GPL avec exception pour autoriser le link avec du propriétaire.
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Nicolas Boulay (site web personnel) le 01 octobre 2007 à 15:13. Évalué à 1.
        
        Le link est un cas pratique mais il y en a d'autres. MySQL par exemple, est un serveur, et pourtant la GPL s'applique aussi sur les applications qui l'utilisent directement.
        
        Il n'y a pas de link mais pourtant ton application a besoin de MySQL, c'est donc un travail dérivé.
        "La première sécurité est la liberté"
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par benoar le 01 octobre 2007 à 19:57. Évalué à 3.
        
        Tu peux donner un exemple de ce cas pour MySQL ? Ça me paraît très bizarre...
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Nicolas Boulay (site web personnel) le 01 octobre 2007 à 22:32. Évalué à 1.
        
        C'était le discours du stand MySQL a Solution Linux. Ils ne font qu'utiliser la GPL.
        "La première sécurité est la liberté"
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par benoar le 01 octobre 2007 à 23:05. Évalué à 2.
        
        Bon alors déjà demader à MySQL AB s'ils sont d'accord avec leur interprétation de la GPL ...
        
        Ensuite, ça veut dire quoi "utiliser directement" ? Parce qu'il existe quand même un nombre énorme de programmes qui utilisent MySQL, et je pense qu'une très grosse partie est proprio et ne s'embête pas avec ces soit-disantes restrictions de la GPL (et je ne pense pas qu'ils aient payé de licence autre non plus).
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par benoar le 01 octobre 2007 à 19:57. Évalué à 2.
        
        Mais la libstd++ est sous _LGPL_ et _avec exception_ !
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Nicolas Boulay (site web personnel) le 01 octobre 2007 à 22:33. Évalué à 2.
        
        GPL pas lgpl à prioris.
        "La première sécurité est la liberté"
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par benoar le 01 octobre 2007 à 23:16. Évalué à 2.
        
        He merde, je m'a trompé : c'est GPL + exception. La raison ici : http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.htm(...)
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par benoar le 01 octobre 2007 à 19:55. Évalué à 2.
        
        Je dis que la notion de link existe dans la LGPL. Point 5 de la LGPL :
        
        A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
        
        Elle précise même le problème liées aux templates ou assimilés, qui incluent du code sous LGPL dans l'exécutable résultat :
        
        However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
        
        D'où l'exception de la libstd++.
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Nicolas Boulay (site web personnel) le 01 octobre 2007 à 22:38. Évalué à 2.
        
        C'est bien pour cela que je demandais pour la GPL ...
        "La première sécurité est la liberté"
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par benoar le 01 octobre 2007 à 23:17. Évalué à 2.
        
        Et bien si la LGPL c'est une GPL avec exception pour linkage, c'est que la GPL considère le linkage comme un travail dérivé...
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Yusei (Mastodon) le 25 septembre 2007 à 11:42. Évalué à 7.
        
        Moi j'aimerais bien lire plus de news sur de nouveaux langages et sur des projets de recherche innovants. Sans se passer des news sur Lisaac, tant qu'à faire. Même s'il y en a, soyons fou, une par semaine.
        
        D'ailleurs à chaque fois qu'on parle de Lisaac je vois mentionner d'autres langages innovants dont je n'ai jamais entendu parler, et des fois dans ma grande paresse je trouve la force de rechercher des infos dessus, et j'apprends des choses intéressantes.
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Sylvain Sauvage le 25 septembre 2007 à 16:42. Évalué à 2.
        
        Moi j'aimerais bien lire plus de news sur de nouveaux langages et sur des projets de recherche innova[teur]s. Sans se passer des news sur Lisaac
        
        En clair :
        — tu veux A (avec A = « des articles sur de nouveaux langages et des projets de recherche innovateurs ») ;
        — sans te passer de B (avec B = « des articles sur Lisaac »).
        D’où je déduis que B ne fait pas partie de A, et même qu’il est en contradiction avec A (le fait d’avoir A empêcherait d’avoir B).
        
        Donc, Lisaac n’est ni un nouveau langage ni un projet de recherche innovateur ? Ça doit faire plaisir…
        
        ;oP
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par GTof le 26 septembre 2007 à 14:58. Évalué à 1.
        
        Mais non, il dit juste qu'il aimerait s'il y avait beaucoup de news sur les nouveaux langages, avoir quand même des news sur Lisaac. Y a vraiment des gens qui cherche la petite bête ...
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par GTof le 26 septembre 2007 à 15:03. Évalué à 2.
        
        Pourtant, il n'y a que sur Lisaac qu'on a régulièrement des dépêches DLFP
        
        C'est peut être parce que ce sont les seuls à proposer des news sur leur langage. On va quand même pas leur reprocher ce que font les autres ...
        
        Puis à chaque news sur Lisaac que j'ai vu il y avait du bon pour le libre surtout que là le compilateur et la lib en GPLv3, si ca a pas sa place sur DLFP, je vois pas où !
        
        Tu veux l'avouer, tu as une dent contre eux ?
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 25 septembre 2007 à 00:04. Évalué à 10.
      
      Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: Pertinence de cette dépeche ?
        
        Posté par BAud (site web personnel) le 25 septembre 2007 à 00:33. Évalué à 2.
        
        Fr comme Francophone aussi, pour LinuxFR, les initiatives extra-européennes de groupe d'utilisateurs de logiciels libres, telles que https://linuxfr.org/~khapin/25340.html sont les bienvenues aussi :D
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Khâpin (site web personnel) le 25 septembre 2007 à 01:17. Évalué à 4.
        
        Mouais, en l'occurrence, tous les participants à cette "rencontre extra-européenne" étaient français...
        Ceci dit, je suis d'accord avec toi pour souligner que linuxFR se résume souvent à linux France (+ parfois Belgique), et le regretter.
- [^] # Re: Pertinence de cette dépeche ?
  
  Posté par Hal9000 le 24 septembre 2007 à 20:52. Évalué à 1.
  
  Je viens de lire la page Wikipedia de Lissac, et je ne vois pas ou est le probleme. Peut-etre a-t-elle ete modifiee apres les remarques auxquelles tu fais reference.
- [^] # Re: Pertinence de cette dépeche ?
  
  Posté par Nicolas Boulay (site web personnel) le 24 septembre 2007 à 21:23. Évalué à 2.
  
  Qu'est-ce que cela peut te foutre que cela soit publié ?
  
  Tu as un compte à régler avec des personnes du projet ou quoi ?
  "La première sécurité est la liberté"
- [^] # Re: Pertinence de cette dépeche ?
  
  Posté par Pierre Jarillon (site web personnel) le 24 septembre 2007 à 22:48. Évalué à 4.
  
  J'ai rencontré "Ontologia" en 2005 ou 2006 lors d'un salon "Solutions Linux" à Paris. Il essayait alors de convaincre les responsables de l'INRIA de libérer le logiciel mais les commerciaux voulaient le vendre.
  
  Je suis convaincu qu'aucune technologie nouvelle ne peut plus percer si elle n'est pas libre. En effet, les frais de commercialisation sont énormes et la rentabilité n'est plus qu'une utopie. Il faut s'appeler Microsoft pour pouvoir lancer .NET en s'appuyant sur un parc de machines captives.
  
  Lisaac est une technologie particulièrement innovante et il est très heureux de la voir maintenant sous licence GPL.
  - [^] # Re: Pertinence de cette dépeche ?
    
    Posté par Anonyme le 25 septembre 2007 à 11:20. Évalué à 3.
    
    Je suis convaincu qu'aucune technologie nouvelle ne peut plus percer si elle n'est pas libre.
    
    Pas tout a fait vrai : dans tous les domaines très spécifiques, c'est même l'inverse, elle n'a aucune chance de survivre si elle n'est pas proprio : le libre a besoin d'un masse critique de développeur (libres) pour survivre, et dans certains domains ils sont très rares.
    
    Par contre dès que l'on parle de développement logiciel (les compilateurs est l'exemple type de ce qui n'a aucune chance d'avoir de succès en proprio) ou n'importe quelle technologie destinée a être déployée massivement (format de fichier genre codec image par ex) je suis d'accord, aujourd'hui le libre est indispensable.
    - [^] # Re: Pertinence de cette dépeche ?
      
      Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 11:55. Évalué à 3.
      
      Je dirais que ton premier cas est vrai, si très peu de client veulent bien mettre beaucoup d'argent. (par exemple le développement de puce, ou des soft pour fondeur, qui doivent être une dizaine dans le monde)
      "La première sécurité est la liberté"
  - [^] # Re: Pertinence de cette dépeche ?
    
    Posté par Rémi Pannequin le 02 octobre 2007 à 17:07. Évalué à 1.
    
    « Je suis convaincu qu'aucune technologie nouvelle ne peut plus percer si elle n'est pas libre. [...] Il faut s'appeler Microsoft pour pouvoir lancer .NET en s'appuyant sur un parc de machines captives.»
    
    Et tant bien même... cf faible succès de Vista !
    - [^] # Re: Pertinence de cette dépeche ?
      
      Posté par Matthieu Moy (site web personnel) le 04 octobre 2007 à 12:03. Évalué à 3.
      
      Faible succès ?
      
      En quelques mois, Vista est devant MacOS et Linux toutes versions confondues en parts de marché.
      
      Faut s'appeler Microsoft pour considérer ça comme un faible succès !
      - [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Antoine le 04 octobre 2007 à 17:05. Évalué à 5.
        
        En quelques mois, Vista est devant MacOS et Linux toutes versions confondues en parts de marché.
        
        Dans la mesure où cette progression peut s'expliquer par le chargement par défaut de Vista avec les nouveaux PCs, on ne peut pas en conclure un "succès" quelconque.
        
        La plupart des articles traitant de Vista sur Internet (hors journalisme-croupion type 01Net et autres) sont assez négatifs, et je ne vois personne s'extasier sur les nouveautés offertes par Vista (alors qu'avec XP ou 95, par exemple, il y avait de vraies avancées).
        
        Du point de vue technique comme de celui de la satisfaction de l'utilisateur, Vista est un échec.
        Croire que le succès se mesure au taux de pénétration, la réussite à l'argent, voilà la bêtise moderne.
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par darkleon (site web personnel) le 05 octobre 2007 à 19:03. Évalué à 2.
        
        Du point de vue technique comme de celui de la satisfaction de l'utilisateur, Vista est un échec.
        Croire que le succès se mesure au taux de pénétration, la réussite à l'argent, voilà la bêtise moderne.
        
        Peut-être, mais l'argent intéresse plus Microsoft que la qualité technique globale :-)
        
        Et c'est le seul truc qui intéresse une entreprise (personne morale avec un profil de psychopate faut il le rappeler), la qualité, la satisfaction utilisateur ne sont là que pour maximiser le profit.
        Et comment vendre de la maintenance si les applis et les OS étaient blindés et sans bugs ?
        C'est un équilibre entre "ne pas dégouter les clients" et les rendre captifs
        
        Le but ultime de notre société moderne étant de vendre une fortune un "truc" qui ne coute rien, voir pas de "truc" du tout :-)
        
        [^] # Re: Pertinence de cette dépeche ?
        
        Posté par Antoine le 06 octobre 2007 à 17:00. Évalué à 3.
        
        Peut-être, mais l'argent intéresse plus Microsoft que la qualité technique globale :-)
        
        Certes... mais à moyen terme je pense que la médiocrité de Vista peut avoir de grosses répercussions sur l'image de Microsoft (qui n'est déjà plus, aux yeux des gens, l'extraordinaire prodige économique qu'on nous décrivait à la fin des années 90). Une fois cette image devenue aussi banale que celle de Renault ou Peugeot, les produits MS sont beaucoup plus vulnérables à la concurrence.
# seul compilateur objet au monde à réaliser une analyse de flot ?

Posté par Antoine le 24 septembre 2007 à 19:09. Évalué à 4.

L'intérêt majeur pour le libre est la disponibilité du seul compilateur objet au monde à réaliser une analyse de flot profonde du code.

Je ne sais pas quels sont les critères pour toi d'un "compilateur objet", mais pypy fait aussi ce genre d'analyse.
http://codespeak.net/pypy/
- [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
  
  Posté par Anonyme le 25 septembre 2007 à 09:57. Évalué à 2.
  
  Est-ce qu'il y aurait des documents ou des papiers à propos de ces techniques d'analyse poussé du flot d'execution ? (liisac ou pypy peu importe)
  - [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
    
    Posté par Ontologia (site web personnel) le 25 septembre 2007 à 10:32. Évalué à 4.
    
    Pas à ma connaissance car ça n'a pas été publié (y compris pour Lisaac, mais ça va venir).
    Google m'a trouvé un petit doc écrit par Xavier Leroy (ocaml)
    ça explique en gros le principe.
    http://pauillac.inria.fr/~xleroy/dea/compil/flow
    
    L'analyse de flot en Lisaac a pour mission de déterminer le type vivant d'un objet en fonction des diverses possibilités d'exécution du code.
    Cela permet d'éviter les switch sur type dans le code.
    Le compilateur arrive à retomber, à 96 % sur du code monomorphique (un seul type possible), et utilise une table dichotomique pour le reste .
    
    Tu trouveras des explications dans les slides ici : http://isaacproject.u-strasbg.fr/download/workshop.pdf
    
    En ce qui concerne pypy, je ne sais pas, il va falloir que j'analyse la chose, mais ce doit être plus difficile de compiler un langage non typé, car le compilateur doit sérieusement mouliner pour typer son flot..
    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
    - [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
      
      Posté par Yusei (Mastodon) le 25 septembre 2007 à 10:41. Évalué à 3.
      
      Si jamais quelque chose de théorique (ie. compréhensible par quelqu'un qui n'a jamais codé de vrai compilateur mais qui aime bien les graphes) est publié sur le sujet par Benoit Sonntag ou quelqu'un d'autre, ça serait intéressant de faire un journal pour le signaler.
    - [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
      
      Posté par Antoine le 25 septembre 2007 à 13:39. Évalué à 3.
      
      mais ce doit être plus difficile de compiler un langage non typé
      
      Python est fortement typé, c'est juste qu'il est dynamique.
      Quant à compiler on peut très bien produire du bytecode :)
    - [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
      
      Posté par TImaniac (site web personnel) le 25 septembre 2007 à 18:06. Évalué à 6.
      
      Le compilateur arrive à retomber, à 96 % sur du code monomorphique
      Sachant que l'un des intérêts de la programmation objet est la réutilisation de composants et souplesse de déploiement/configuration associée, dans beaucoup de cas il est techniquement impossible de connaître à l'avance le type réellement instanciés (suffit de voir les patterns IoC par exemple) : ce 96% me paraît intuitivement largement sur-estimé.
      Je conçois que Lisaac ne soit pas destiné à faire des briques de composants logiciels comme on pourrait le faire en Java ou autre, mais quand même : chercher à résoudre statiquement les appels polymorphique revient à partir du principe que le code est pas vraiment modulaire et/ou réutilisable sous forme de composant, bref codé "ala C".
      Quand on voit le résultat au niveau perf, je me demande également où est l'intérêt, c'est quand même très relatif comme gain, surtout quand tu vois les contraintes sur les ressources nécessaire à la compilation.
      Vous comparez les perfs avec gcc, très bien, mais celui-ci n'est pas réputé pour produire du code ultra-performant, pourquoi ne pas plutôt comparer avec le compilo Intel ?
      
      Quelques remarques :
      "Le Garbage Collector de Lisaac est certainement un des ramasses-miettes les plus rapides à l'heure actuelle. Il est basé sur une architecture de type "Mark and Sweep" améliorée. En effet un "Mark and Sweep" classique parcourt tous les pointeurs, considérant n'importe quoi comme une référence possible. Le compilateur Lisaac génère un GC qui connait le type des objets qu'il gère, ce qui permet d'accélérer le marquage. Plus précisément, le marquage oublie volontairement les entiers, les caractères et les NATIVE_ARRAY "
      Les GC modernes font également cela. D'ailleur les types "primitifs" (entier, etc.) sont généralement alloués sur la pile et non le tas, et ne sont donc pas du tout manipulés par le GC.
      
      Sinon de manière beaucoup plus subjective : évite ce ton prétentieux dans tes journaux/dépêche, c'est vraiment lourd et ne donne pas spécialement une bonne image de Lisaac. Du style :
      "La spécification 0.2 apporte des innovations importantes"
      Des améliorations oui, des innovations faut pas exagérer, je vois pas ce qu'il y a d'innovant à "Le mot clé Expanded remplace *.".
      "certainement un des ramasses-miettes les plus rapides à l'heure actuelle." (sans chiffre ni rien)
      "Non content"[...]
      Et j'en passe.
      Un peu de modestie ne ferait pas de mal si vous voulez attirer un minimum d'attrait du milieu des logiciels libres. Là on a l'impression que tu fais un discours marketing pompeux.
      - [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par tarlack le 25 septembre 2007 à 18:36. Évalué à 4.
        
        "Sachant que l'un des intérêts de la programmation objet est la réutilisation de composants et souplesse de déploiement/configuration associée, dans beaucoup de cas il est techniquement impossible de connaître à l'avance le type réellement instanciés (suffit de voir les patterns IoC par exemple) : ce 96% me paraît intuitivement largement sur-estimé."
        
        Je dirais que ca depend du contexte. Dans le cadre d'une appli fortement orientée plugin, pour l'instant on ne peut rien dire, la compilation séparée n'est pas encore gérée. Mais dans le cadre d'applis avec une conception Objet mais dont le binaire est "monolithique" tu peux parfaitement le prevoir, le cas embetant étant les collections. Mais sinon, vu que tu as à ta disposition tout ce qui va être executé, et donc tous les chemins possibles, tu peux specialiser toutes les fonctions pour les types qu'elles vont pouvoir recevoir, et ainsi éviter le polymorphisme. Le chiffre de 96% sort des stats du compilo. Si je prends ce qu'il me sort pour le bootstrap du compilo lui meme, voila ce qu'il me met :
        
        Polymorphic call : 0.8% (1996/231824)
        
        "Vous comparez les perfs avec gcc, très bien, mais celui-ci n'est pas réputé pour produire du code ultra-performant, pourquoi ne pas plutôt comparer avec le compilo Intel ?"
        
        A priori c'est celui qui revient le plus dans les bench shootout[1], et en plus c'est celui qu'on trouve très largement sur toutes les distros Linux. À mes yeux c'est déjà pas mal comme justification, mais il y en a peut être d'autres ;)
        
        [1] http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Yusei (Mastodon) le 25 septembre 2007 à 19:16. Évalué à 3.
        
        Mais dans le cadre d'applis avec une conception Objet mais dont le binaire est "monolithique" tu peux parfaitement le prevoir, le cas embetant étant les collections.
        
        Pire que ça, le cas embêtant c'est à chaque fois que tu veux définir une vraie méthode virtuelle, dont l'implémentation dépend des sous-classes, et que tu ne sais pas toi même quel est le type de l'objet à un moment donné. Donc, dans tous les cas où l'héritage n'est pas juste une manière de coder proprement mais un besoin.
        
        Tu auras un problème avec les collections, mais tu auras aussi un problème dès que l'utilisateur peut entrer des données qui déterminent le type de tes objets. C'est déjà assez problématique.
        
        Le chiffre de 96% sort des stats du compilo.
        
        Là dessus, il marque un point: ça peut vouloir dire que le compilo est efficace, mais aussi qu'il est codé sans utiliser vraiment de concepts d'objets. S'il n'y a pas beaucoup d'héritage, forcément, ça marche mieux. Et un compilateur, c'est assez bas niveau en terme de modélisation.
        
        De toutes façons, difficile de débattre de points aussi techniques sans étudier le langage et les algos du compilateur, mais il est évident que l'analyse de flot atteint vite ses limites de par sa complexité. Il serait intéressant de voir des benchs portant sur ce point plutôt que sur la rapidité.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par tarlack le 25 septembre 2007 à 19:39. Évalué à 3.
        
        Pire que ça, le cas embêtant c'est à chaque fois que tu veux définir une vraie méthode virtuelle
        
        Lisaac simule des schemas d'executions et trace tous les types possibles. Meme si les types dépendent de données, il ne sont pas créés en fonction des données (il faudrait pouvoir definir des prototypes à la volée, en runtime). Tu as juste différent types prédefinis (ceux que tu as créés pour ton programme) qui sont utilisés en fonction de celles-ci, donc tu peux tracer.
        
        Il serait intéressant de voir des benchs portant sur ce point plutôt que sur la rapidité.
        
        Si tu parles de l'heritage (sinon j'ai mal compris et je m'en excuse ;) ), des benchs avait été fait par Xavier Oswald pour tester ces points là. En gros il y avait un bench sur l'heritage horizontal (une classe A et 500 classes filles directes par exemple) et vertical.
        Pour le vertical, il prenait un proto du bas de l'arbre et faisait 2.000.000 appels sur des methodes codées dans un des parents, quelconque (ca allait de 25 à 500 parents). Voilà les chiffres, tirés d'un log irc ^^ :
        
        xoswald: c++ croit rapidement 1.4s , 2.1s, 2.6s etc..
        xoswald: alors que lisaac reste pratiquement stationnaire
        xoswald: 0.7s a 1s
        xoswald: et java met deja 5.7s pour 25 parents
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par TImaniac (site web personnel) le 25 septembre 2007 à 19:48. Évalué à 1.
        
        Lisaac simule des schemas d'executions et trace tous les types possibles.
        Sauf qu'un des gros atouts de l'objet, c'est de bosser avec des contrats d'interface, sans connaître le type sous-jacent, souvent fourni par un composant tiers, soit mis à la disposition des programmeurs (framework).
        Rassures moi : Lisaac envisage bien la programmation modulaire quand même ? Non parcqu'il est soit disant génial et il faut abandonner C# et Java, alors je me pose des questions de programmation de tous les jours... (je ne fais pas référence à tes propos mais à ceux de Benoît).
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par tarlack le 25 septembre 2007 à 20:21. Évalué à 2.
        
        Il faut distinguer 2 types de modularité : modularité dans ton architecture logicielle et modularité binaire.
        
        La modularité de l'architecture logicielle est bien sûre possible. Un exemple typique, ce sont les collections dans Lisaac. Un type abstrait COLLECTION[E], et ensuite tu ne passes que par là. Donc si ton framework est constituée d'un ensemble de prototypes dont tu as le code source, tu peux utiliser ton framework de maniere normale, avec ses interfaces. Le compilo fera le boulot d'aller voir ce qu'il y a derriere, via son analyse de flot. Coté concepteur (vu que c'est ce coté là qui t'interesse visiblement), tu ne verras rien, tu coderas en boite noire comme d'habitude.
        
        La modularité binaire (ou compilation séparée) dans un contexte d'optimisation globale est bien plus dure que dans un contexte d'optimisation locale (comme en Java ou autres), mais là aussi il y a 2 niveaux : la modularité type plugin, et la modularité type bibliothèque partagée.
        La modularité type plugin parait plus simple. Avec Benoit on avait quelques idées qui, à la fin, permettraient de garder une optimisation globale même pour les plugins.
        La modularité type bibliothèque partagée est bien plus complexe, car la bibliothèque est compilée sans connaitre les contextes d'utilisation de ses fonctions, donc out l'optimisation globale.
        Ce sont clairement des domaines de recherche actuelle.
        
        Il faut bien voir que Lisaac a été construit avec en tête l'idée de ne jamais prendre la solution de facilité. Pour la compilation séparée, il y a une solution simple si on ne prend pas cet engagement : on pond une interface en C, sans aucune optimisation sur les contextes etc, et l'autre prog se lie dessus. Probleme : on perd enormement des benefices de l'optimisation globale, alors que c'est ca qui permet d'avoir des perfs proches du C, voir meilleures dans certains cas. Rien ne dis qu'au final c'est ce qui sera fait, mais ca sera pas avant une longue analyse de ce qui est faisable.
        
        Comme tous les projets de recherche, Lisaac cherche avant tout à être au top. Ca amène quelques contraintes, mais au final c'est parce que des gens prennent le temps de tout examiner que la JRE va un peu plus vite qu'un escargot et que Lisaac arrive à avoir une approche très haut niveau et de très bonnes perfs :-)
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 25 septembre 2007 à 22:33. Évalué à 2.
        
        Bibliotheque partagée, ca je vois bien, mais qu'appelez-vous "plugin" ?
        
        Sinon, ne le prennez pas mal, mais j'ai l'impression que vous vous focalisez un peu trop sur les performances par rapport au C. Ce n'est pas un mal en soit, mais il y a d'autres aspects a prendre en compte, comme la maintenance ou la facilité d'apprentissage.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par tarlack le 25 septembre 2007 à 22:50. Évalué à 1.
        
        Ce que j'appelle un plugin, c'est une bibliothèque respectant une certaine API afin d'etre utilisée par un programme donné (on code la bib specifiquement pour ce programme là) qui la chargera et l'utilisera. par exemple, on peut citer les modules apaches qui sont des plugins pour apache, les drivers linux le sont aussi d'une certaine manière pour le noyau. pour résumer, un plugin est fait specifiquement pour un programme, contrairement à la bibliothèque partagée. Certes les 2 donnent la meme chose en terme de structure (un .so classique sur les unix), mais en terme de compilation globale c'est très différent, car dans le cas de plugins on connait le programme qui utilisera le plugin, et donc on peut avoir les contextes. est-ce moins obscur ?
        
        Qu'appelez vous maintenabilité ? extensibilité du code ? facilité de compréhension pour le maintenir et corriger les bugs ? gestion d'un projet ? outils de debugging ?
        
        si c'est l'aspect maintenance du code, etant un langage de haut niveau gerant tout seul la mémoire, il aura une maintenabilité plus aisée qu'un langage de bas niveau.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 26 septembre 2007 à 13:58. Évalué à 3.
        
        Ok, merci pour les plugins.
        
        Pour la maintenance, je pensais, par exemple, au fait que dans un projet, les equipes se renouvellent au cours du temps. Un nouvel arrivant doit etre operationnel rapidement pour analyser le programme, le corriger et le faire evoluer. Sans vouloir lancer un troll, le langage Perl n'est pas réputé pour etre facilement maintenable, ceci etant certainement du a sa syntaxe tres consise et le fait qu'"il y a plusieurs facons de le faire".
        
        Un autre aspect est le fait d'apprendre un nouveau langage. Une des raisons pour laquelle Java a aussi bien reussi, c'est que la syntaxe de base est tres proche du C. Un programmeur C qui n'a jamais fait du Java de sa vie comprend rapidement un programme Java ; pas tout le programme bien sur, mais souvent suffisamment pour pouvoir analyser l'algorithme et effectuer une correction. Il y a evidemment d'autres facteurs (Sun poussait et pousse toujours le langage, la richesse de l'environnement) mais cet aspect la est tres important.
        
        Le langage D est vraiment tres bien sur le papier, mieux que C, C++, Java ou C# par exemple ; je precise que je ne lance pas de trolls. Pourquoi ne perce-t-il pas alors ? Peut etre parce qu'il soit sous copyright Digital Mars. Cet aspect "langage non-libre" a été soulevé par un autre intervenant.
        
        Puisque vous dites que vous ciblez l'embarqué, certains equipements necessitent une mise-a-jour logicielle. Il y a clairement un avantage a utiliser un langage produisant du ByteCode pour effectuer ces mises-a-jour (independance par rapport a la plateforme materielle). Je crois que dans Lisaac, il n'y a pas de notion de ByteCode.
        
        Bref, ce que je voulais dire c'est que la reussite ou non de votre projet depend d'un nombre important de facteurs et que la performance par rapport au C n'est pas forcement le plus important. Java s'est trainé une reputation d'escargot pendant des années. Ca s'est bien amélioré mais ca ne l'a pas empéché d'avoir percé.
        
        Vous avez fait un super boulot et semblez tres enthousiastes, mais c'est tres facile de garder la tete dans le guidon. Je voulais juste vous faire part de remarques exterieures qui, je l'espere, sont constructives.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 26 septembre 2007 à 14:05. Évalué à 4.
        
        Puisque vous dites que vous ciblez l'embarqué, certains equipements necessitent une mise-a-jour logicielle. Il y a clairement un avantage a utiliser un langage produisant du ByteCode pour effectuer ces mises-a-jour
        
        euh... HEIN. Il est fou. On se fait chier à produire du code rapide pour avoir la plateforme moins chère possible et il veut mettre une VM ?!
        
        Du bytecode pour l'embarqué, c'est la meilleur de l'année. Surtout pour des mises à jour, c'est encore pire. (ps:je ne vois pas bien le rapport)
        
        Ca s'est bien amélioré mais ca ne l'a pas empéché d'avoir percé.
        
        Java misait sur une autre approche que Lisaac : sa lib pour gagner du temps.
        
        Lisaac vise autre chose. Plus tangible en plus.
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 26 septembre 2007 à 14:26. Évalué à 4.
        
        Le monde de l'embarqué ce ne sont pas que des microcontrolleurs 8 bits.
        
        Un exemple : en TV num, depuis quelques années, il y a de plus en plus de JVM. En gros, l'OS, les drivers et la JVM sont en C et l'application est en Java. Tout ce petit monde peut etre mis-a-jour via la diffusion satellite.
        
        C'est beaucoup plus simple de mettre a jour l'application par ByteCode car la plateforme materielle est abstraite.
        
        La specification J2ME de Java est destinée au monde de l'embarqué. D'autres existent comme STIP.
        
        Il y a meme des specifications Temps-Reel pour Java ; la plus connue (car officielle) est RTSJ (Real-Time Specification Java).
        
        Je rappelle qu'a l'origine Java a été concu pour l'embarqué uniquement, et que la mise-a-jour par ByteCode était un élément important. Le ByteCode a aussi été concu pour etre plus compact qu'un programme deja compilé.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 26 septembre 2007 à 14:29. Évalué à 1.
        
        Le marché que tu décris ne représente rien en volume par rapport au reste.
        
        Il y a beaucoup de blabla autour de java pour l'embarqué mais très peu d'application réelle. Rien que la RAM nécessaire en plus est un frein.
        
        Sinon, je ne voix pas pourquoi le ByteCode serait plus compact, et de plus, jene voix pas l'interet surtout quand tu as une énorme JVM derrière.
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 26 septembre 2007 à 15:48. Évalué à 2.
        
        Le marché que je décris c'est telephonie mobile (ok il n'y a pas de JVM dans tous les telephones portables) + TV num. Ce ne sont pas des petits marchés. A l'heure actuelle, ce sont deja des millions de machines. Je ne parle pas non plus des autres marchés.
        
        Tous les equipements embarqués n'ont pas les memes contraintes, mais pour certains d'entre eux, le fait de pouvoir mettre a jour l'application sans se preoccuper de la plateforme materielle est clairement un avantage. Ceci est, a mon avis, quelque choses qui va continuer a se developper.
        
        La JVM JamVM (J2SE) annonce un executable (compresse) de 140KB. La JVM MicroJVM (J2ME) annonce une empreinte memoire inferieure a 30 KB.
        
        Le ByteCode est plus compact pour deux raisons:
        
        - la premiere vient de sa conception : en ByteCode Java, si tu mets '0' sur la pile, c'est un seul octet ; sur une machine 32 bits, rien que le nombre tient sur 4 octets ; tout n'est pas comme ca, mais globalement, c'est plus compact
        
        - la seconde raison est que les classes s'appuient beaucoup sur la bibliotheque et que tu peux eventuellement mettre a jour une seule classe ; c'est moins evident si tu veux faire ca avec un programme compilé, surtout sans bibliotheque partagée
        
        Un des interets que le ByteCode soit compact est le temps de telechargement de la mise-a-jour. Le programme tient aussi moins de place en memoire.
        
        Ceci dit, je ne vient pas ici pour dire que Java c'est genial pour l'embarque grace a son ByteCode, surtout que je suis plutot C. Je dis juste que c'est dans certains cas, cela a des avantages. Ceci est valable pour tous les langages generant du ByteCode.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 26 septembre 2007 à 16:42. Évalué à 1.
        
        Je ne connais plus les chiffres de vente des µp 16 bits et des petits 32 bits arm. Je crois que l'on est pas loin du milliards. C'est sans commune mesure avec un téléphone ou autre.
        
        Tu annonce 30 et 170KB, cela ne fait pas beaucoup sauf que les µP 16 bits on difficilement plus de 64KB de mémoire.
        
        pour le bytcode, certe pour mettre sur la pile, tu utilies un mot d'un octet, et minimum 2 octets pour du x86, mais si tu fais une addition entre 2 nombres ailleurs dans la pile, sur x86, cela prendra toujours 2 octets mais combien en byte code java pour manipuler la pile et mettre les valeurs au bon endroit ?
        
        Concernant la mise à jour de code, tu peux tout à fait patcher du binaire. Il n'y a pas vraiment de différence. La difficulté sera toujours la même : comment gérer les données des classes modifiés.
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 26 septembre 2007 à 17:05. Évalué à 2.
        
        Bon, je crois qu'on a dérivé.
        
        Le monde de l'embarqué est tres vaste, et l'echelle est plus importante que le monde du desktop.
        
        J'essayais juste de faire une critique que je pensais constructive, a savoir qu'il y a une part non-negligeable de l'embarqué ou l'utilisation de ByteCode avait un avantage. Je n'ai pas dis qu'il faut abandonner l'assembleur et le C, juste que le ByteCode est utilisé et que le marché potentiel est tres important, surtout en valeur. Je demandais juste si le fait de pouvoir generer du ByteCode etait une fonctionnalité prévue, car cela a certains avantages, comme le fait d'utiliser des bibliotheques partagées ; je n'ai pas dit non plus que c'etait absolument indispensable.
        
        Pour la manipulation des données et d'apres ce que j'ai vu, tout est serialisé sur disque ou en memoire flash, et on recharge la JVM en relisant ces données. Ce n'est certes pas tres eleguant mais ca a le merite d'etre simple ; en plus si la mise-a-jour a lieu durant la nuit ce n'est generalement pas tres genant pour l'utilisateur. C'est juste une histoire de compromis entre diverses choses, en premier le cout, et en dernier l'elegance technique. Triste réalité n'est-ce-pas ?
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Mildred (site web personnel) le 27 septembre 2007 à 13:05. Évalué à 1.
        
        Il serait possible éventuellement de faire d'autres backend pour Lisaac, c'est à dire qu'on pourrait cmpiler en C, mais on peut aussi très bien imaginer de compiler pour la JVM ou encore Parrot...
        
        Seulement à l'heure actuelle, les structures C sont un peu partout dans le code du compilateur. Si on veut ajouter un langage ca risque d'être difficile.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 27 septembre 2007 à 18:15. Évalué à 1.
        
        Au fait, j'ai fait un petit essai avec une petite fonction qui prend deux entiers et retourne leur somme:
        
        en C:
        int function (int a, int b) { return a + b; }
        
        en Java:
        public static int function (int a, int b) { return a + b; }
        
        sur x86, je compile avec optimisations (-O3 -fomit-frame-pointer) et j'obtiens:
        0: 8b 44 24 08 mov 0x8(%esp),%eax 4: 03 44 24 04 add 0x4(%esp),%eax 8: c3 ret
        soit 9 octets (11 octets avec -O2)
        
        Le ByteCode Java est:
        0: iload_0 1: iload_1 2: iadd 3: ireturn
        soit 4 octets (on mets les deux parametres sur la pile, on les additionne et on retourne le sommet de la pile).
        
        Ici, il y a un rapport environ de 2 en faveur du ByteCode. Bon ce n'est qu'un exemple, et je ne dis pas que c'est toujours comme ca hein.
        
        J'ai essayé avec la fonction factorielle codée recursivement et j'obtiens un rapport presque de 14 avec -O3 (gloups), plus que 3 avec -O0 et presque 2 avec -O2. Je n'ai pas cherché a faire un truc super-optimisé, mais juste un petit programe classique.
        
        Une fois translaté en langage machine, il n'est pas deraisonnable de penser que le ByteCode occupera au moins la taille occupée par un code equivalent écrit en C, donc le fait que ca soit plus compact n'a pas forcement toujours un interet.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 27 septembre 2007 à 18:35. Évalué à 2.
        
        essayes -Os pour gcc. Il faudrait voir sur des fonctions plus réaliste, ici, c'est trop court.
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 28 septembre 2007 à 01:19. Évalué à 1.
        
        Avec -Os, c'est mieux en effet, et effectivement, il faudrait regarder avec un "vrai" programme.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par imalip le 26 septembre 2007 à 17:00. Évalué à 4.
        
        Le marché que je décris c'est telephonie mobile + TV num. Ce ne sont pas des petits marchés.
        
        J'ai bossé dans 2 boites de téléphonie mobile en tant que dev. J'ai vu 0 ligne de java en 13 mois. Les applis java représentent une quantité négligeable par rapport a tout le reste de la plateforme (drivers, gestion protocoles, UI, ...). A l'arrivée, les seuls truc en java sur mon téléphone quand je l'ai acheté, c'etait 3 jeu de démonstration.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 26 septembre 2007 à 17:24. Évalué à 1.
        
        Je ne connais pas bien le monde de la telephonie mobile mais un autre intervenant semblait dire que ce n'etait pas rare.
        
        Chez le fabricant de STB ou j'ai travaillé, je n'ai pas vu une seule ligne de code en Java non plus, mais une JVM etait ajoutée par dessus la couche drivers.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par satan le 26 septembre 2007 à 15:31. Évalué à 2.
        
        Un exemple : en TV num, depuis quelques années, il y a de plus en plus de JVM. En gros, l'OS, les drivers et la JVM sont en C et l'application est en Java. Tout ce petit monde peut etre mis-a-jour via la diffusion satellite.
        
        Pour tous ceux qui passeront au Blu-ray, il faut Java pour afficher les menus et les sous-titres, ça fait partie du standard Blu-ray. James Gosling veut qu'on puisse télécharger de nouveaux sous-titres pour d'autres langues via internet aussi.
        
        Quant à J2ME c'est présent sur presque tous les téléphones portables modernes pour les jeux, mais peu de gens sont au courant qu'il existe aussi des logiciels tout ce qu'il y a de plus conventionels qui sont codés pour J2ME.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 26 septembre 2007 à 16:07. Évalué à 1.
        
        D'ailleurs la mise à jour par sattelite, cela existe depuis toujours pour le système de protection de canalsat. Et ce n'est pas une JVM.
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 26 septembre 2007 à 16:18. Évalué à 2.
        
        Cela fait un petit moment qu'il y a des JVM sur les Set-Top-Box Canal Sat.
        J'ai travaillé chez un des fabriquants fournisseurs de STB pour Canal Sat : je te promets qu'il y a une JVM dessus.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 26 septembre 2007 à 16:45. Évalué à 2.
        
        Ok. Je pensais à la carte à puce qui gère la sécurité. Y'a pas de jvm dessus, j'ai aussi bossé dessus :)
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 26 septembre 2007 à 17:11. Évalué à 1.
        
        Par contre dans un autre registre, il y a des JavaCards.
        
        Lisaac, c'est prevu pour tourner sur une JavaCard ?
        
        ;-)
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 26 septembre 2007 à 16:20. Évalué à 0.
        
        Cela fait un petit moment qu'il y a une JVM sur les Set-Top-Box de Canal Sat.
        J'ai travaillé chez un fabricant fournisseur de STB pour Canal Sat et je te promets qu'il y a une JVM.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 26 septembre 2007 à 16:22. Évalué à 0.
        
        Désolé pour le doublon.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par rewind (Mastodon) le 27 septembre 2007 à 11:26. Évalué à 2.
        
        Du bytecode pour l'embarqué, c'est la meilleur de l'année.
        
        Ouais, un peu comme un langage qui gère lui même la mémoire pour l'embarqué, j'en ris encore...
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 27 septembre 2007 à 11:35. Évalué à 1.
        
        Je ne vois pas trop le problème en fait ? Je sais que c'est une des raisons qui fait que Linus haie le c++ (de la gestion mémoire derrière son dos) mais je ne sais pas trop les détails.
        
        Fondamentalement qu'est-ce qui gène ? Le fait que d'habitude, on ne sais pas quand toute la mémoire sera pleine, ce qui empèche de bien tout utiliser ?
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par rewind (Mastodon) le 27 septembre 2007 à 12:33. Évalué à 1.
        
        Ben j'ai lu quelque part parmi ces commentaires que le compilateur faisait des optimisations pour garder tout dans une seule ligne de cache. Très bien. Maintenant, croire qu'on peut faire ça de manière générique pour toutes les architectures et tous les algorithmes, c'est être sérieusement optimiste (ou illuminé, c'est selon).
        
        Pour avoir déjà vu des gens qui ont ce genre de problématique quotidiennement dans l'embarqué, l'optimisation des structures de données et de leur emplacement en mémoire ainsi que de l'organisation du code pour provoquer le moins de défaut de cache possible, c'est quasi-spécifique à chaque couple (algo-archi) et ça demande énormément de temps. Et ça demande de pouvoir maitriser toute la gestion de la mémoire de A à Z.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Yusei (Mastodon) le 27 septembre 2007 à 12:37. Évalué à 3.
        
        Sauf erreur, ce n'est pas le langage qui gère la mémoire mais le compilateur. On peut donc imaginer une option "architecture" du compilateur qui permette de faire ce genre d'optimisations en fonction de l'architecture.
        
        Évidemment, ça limite sérieusement le nombre d'architectures qu'on peut gérer.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Ontologia (site web personnel) le 27 septembre 2007 à 13:54. Évalué à 4.
        
        C'est dans les cartons.
        En fait, on aura carrément un système qui permettra de définir certaines optims de manière extren au compilateur, des sortes de fichiers de configuration.
        Il faudra en écrire une par archi, ou on pourra mettre différentes choses :
        
        - Taille de ligne de cache code et donnée
        - Optimisation sur les entiers (mélange pipeline flottant et entier)
        - Taille max de la mémoire
        - etc...
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 27 septembre 2007 à 14:30. Évalué à 2.
        
        Lisaac n'arrivera jamais à ce niveau d'optim. Il fait simplement un meilleur boulot sur un code propre que gcc. Si tu commences à optimiser à mort un code C, c'est un peu comme si tu recodais en assembleur.
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 27 septembre 2007 à 12:48. Évalué à 1.
        
        Utiliser le mot "Garbage Collector" a cote du mot "Systeme Embarqué" fait herisser les cheveux de plus d'une personne, surtout si tu precises "Temps-Reel".
        
        Dans certains projets de systemes embarqués il n'y a aucune allocation dynamique ; avantage : pas de 'malloc' qui echoue ; inconvenient : tu sur-dimensionnes ta memoire pour le pire cas.
        
        Mais bon, encore une fois, les contraintes ne sont pas les memes pour tous les systemes embarqués, que ca soit en terme de taille, de fiabilite, etc. Un ABS et une Set-Top-Box sont des systemes embarqués, mais les contraintes ne sont pas du tout les memes.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par imalip le 27 septembre 2007 à 13:06. Évalué à 2.
        
        Dans certains projets de systemes embarqués il n'y a aucune allocation dynamique ; avantage : pas de 'malloc' qui echoue ; inconvenient : tu sur-dimensionnes ta memoire pour le pire cas.
        
        C'est a dire que quand on doit faire tenir l'intégralité du controle (code + data) d'un chassis de F1 dans 750ko, il faut sérrer... (La télémétrie étant a part).
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par crumpet le 27 septembre 2007 à 14:31. Évalué à 1.
        
        J'imagine que le nombre d'unités (les F1) est faible, et que ce n'est pas pour une question de cout qu'il y a juste 750 Ko. Est-ce-que le processeur ne peut addresser que 1 Mo ? Y-a-t'il une autre raison ?
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 27 septembre 2007 à 14:33. Évalué à 2.
        
        F1, 750 ko , serrer ?
        
        J'avais eu une conf d'un vague présentation du système par un ingénieur renaut qui se faisait brider en live sur ce qu'il pouvait dire.
        
        Mais en gros, j'en avais déduit qu'il devait avoir une dizaine de ppc. Donc 750ko me parait petit :)
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par imalip le 27 septembre 2007 à 16:33. Évalué à 2.
        
        Renault utilise du Marelli Step 11. Il y a effectivement pas loin d'une dizaine de ppc, plus 4 DSP. Bon, j'ai pas les specs sous la main, et si j'essaie d'ouvrir celui sur le bench on risque de me regarder bizarrement, mais ca nous fait tres peur. C'est énorme, et on n'a aucune idée d'a quoi tout ca sert, meme si ca fait chassis+moteur. Mais je confirme qu'en 2003/2004, on pouvait faire le controle chassis avec un seul DSP (et ses 750ko de RAM), 2 en 2005/2006, plus un qui fait télémétrie/IO. Je suis bien placé pour le savoir, il a fallu que je décide du numbre de secteurs pour stoquer l'image en flash...
        
        Apres, ca dépend des moyens/impératifs qu'on a. Si on a la possibilité d'avoir du fait-maison sur mesure, 3 DSP ou 2 PPC, ca marche tres bien. Si on n'a pas de contrainte commerciales, on peut prendre au choix Marelli, McLaren ou PI (typiquement http://www.piresearch.com/uploads/LightweightSystems.pdf , aussi utilisé en Camp Car). Dans ce cas-la le systeme est plus flexible et polyvalent, donc plus de code, etc...
        
        Si la direction impose qu'on prenne du XXX avec une poignée de consultants pour des interets purement commerciaux...
        
        M'enfin l'an prochain, plus de question a se poser, tout le monde utilisera la meme marque, Microsoft^W McLaren. A moins que...
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Ontologia (site web personnel) le 26 septembre 2007 à 14:10. Évalué à 2.
        
        Merci pour tes remarques coinstructives :-)
        
        Lisaac génère pour le moment du C. Il peut très bien, dans le futur, générer toutes sortes de chose : byteCode Java, ou code Java à compiler. ByteCode LLVM, etc...
        
        Le compilateur possède un petit langage interne avec quelques primitives qui donne lieu à génération du code. On pourrait imaginer d'avoir un jour différents back-end, c'est tout à fait envisageable.
        
        Java est arrivé je pense au bon moment, s'est servi de la niche de l'applet web pour conquérir l'espace et a bénéficié d'une grosse librairie et d'un bon framework n-tiers.
        Sans compter le marketing de SUN derrière.
        
        Notre marketing à nous, c'est le libre :-)
        
        La grosse lib... on va avoir celle d'Eiffel bientôt, ce qui amènera un minimum vital pour coder (regexp, opengl, xml, réseau) et surtout écrire des libs plus haut niveau.
        
        J'établi à l'heure actuelle une liste comparative (Java / Eiffel / Lisaac) afin de déterminer les priorités.
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Mildred (site web personnel) le 27 septembre 2007 à 13:08. Évalué à 3.
        
        Il y a GTK, QT ou WxWidgets dans la lib Eiffel ?
        Parce que pour le moment, je me demande comment coder une application graphique en Lisaac :( ... J'ai pensé porter GNUstep mais ça n'a pas l'air facile.
        
        Ce qui serait bien je pense, c'est faie un binding Gobjects <-> Lisaac
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Ontologia (site web personnel) le 27 septembre 2007 à 13:58. Évalué à 2.
        
        Il y a la lib conçu pour être multiplateforme dans lib/gui.
        Cette lib sera celle d'IsaacOS, elle ne se repose que sur putPixel.
        
        Mais on peut envisager des binding...
        
        Il y a un générateur de binding pour Eiffel, qu'on pourra ensuite traduire en lisaac, on pourrait peut être l'utiliser ?
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par reno le 27 septembre 2007 à 10:19. Évalué à 2.
        
        >>Le langage D est vraiment tres bien sur le papier, mieux que C, C++, Java ou C# par exemple ; je precise que je ne lance pas de trolls. Pourquoi ne perce-t-il pas alors ? Peut etre parce qu'il soit sous copyright Digital Mars. Cet aspect "langage non-libre" a été soulevé par un autre intervenant.<<
        
        Bof, il existe un compilateur libre de D: GDC.
        Il n'est pas au niveau du compilateur 'officiel' sur certains points, mais il a l'air utilisable d'après les posts que je vois.
        
        Le problème de D est plus au niveau des librairies (la lutte entre Phobos et Tango n'aide pas) et du langage: certes la v1 est sortie, mais quasiment aussitôt la v2 a vu le jour qui ajoute plein de truc, alors que dans la v1 il y a des parties non implémentée (je crois que les contrats ne sont pas implémentés).
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Gilles G. le 27 septembre 2007 à 12:30. Évalué à 2.
        
        Dans la v1, les contrats sont implémentés, et la v1 est fonctionnelle. Le langage et ses compilateur (gdc basé sur gcc et dmd de digital mars) sont très utilisables autant en terme de perfs que de stabilité (pour la version 1.0)
        La version 2 est une version de développement qui ne devrait pas être utilisée en production.
        
        Par contre, il y a clairement des problèmes de communication chez digital mars:
        * c'est dur de savoir quelle est la version stable du compilateur *et* du langage
        * la documentation du langage concerne la version instable. C'est pas très pratique quand on utilise la version stable.
        * le téléchargement du compilateur renvoie par défaut sur la version 2 qu'il ne faut pourtant pas utiliser en production...
        * etc.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 23:16. Évalué à 3.
        
        Sinon, ne le prennez pas mal, mais j'ai l'impression que vous vous focalisez un peu trop sur les performances par rapport au C. Ce n'est pas un mal en soit, mais il y a d'autres aspects a prendre en compte, comme la maintenance ou la facilité d'apprentissage.
        
        C'est évidement pris en compte mais pas encore fini. C'est plus un choix marketing de montrer ça en premier, car c'est le plus marquant et le plus évident. Comment veux-tu mesurer l'accroissement de productivité sur un nouveau langage ? (que tu dois apprendre donc...)
        
        Il y a des plans et des idées pour essayer de valider statiquement les contracts. La premier chose implémenté dans ce sens est la détection des appels sur NULL.
        
        Pour la facilité d'apprentissage, il y a la syntaxe dont tu fais le tour rapidement et la future lib censé être simple.
        
        Bref, c'est juste la 1er version majeur...
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Antoine le 25 septembre 2007 à 20:35. Évalué à 2.
        
        Non parcqu'il est soit disant génial et il faut abandonner C# et Java
        
        Ces deux propositions sont indépendantes.
        On peut prendre l'une et refuser l'autre :)
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Yusei (Mastodon) le 25 septembre 2007 à 21:45. Évalué à 3.
        
        Tout d'abord: pourquoi es-tu aussi agressif envers les créateurs de Lisaac ? Tu n'aimes pas que quelqu'un critique ton C# chéri ? C'est étonnant comme réaction.
        
        Ensuite, autant je comprenais tes arguments tout à l'heure, autant là j'ai décroché. En quoi le code n'est pas modulaire sous prétexte que la liaison avec la bibliothèque se fait à la compilation, et pas au runtime ? Ça a des avantages et des inconvénients, mais il est tout à fait possible de faire du code modulaire comme ça.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 10:12. Évalué à 7.
        
        Tout d'abord: pourquoi es-tu aussi agressif envers les créateurs de Lisaac ?
        Agressif ? Bof, pas plus que le commentaire noté +10 de Benoît Sonntag qui dit à 2 reprises que C# et Java sont des langages qui n'auraient jamais dû existé (sans aucune argumentation) quand Lisaac est "moderne". Du bon gros troll de base. Ajouté à cela le ton pompeux et auto-complimenté de la dépêche (même si contenant plein d'informations), ca donne vraiment une impression de "vous avez rien compris avec vos technos de merde, voilà Lisaac, et encore, c'est qu'un début, vous allez voir !",
        Alors voilà, je demande à voir, je me poses les questions du programmeur/concepteur de tous les jours, et je prends pour exemple la modularité.
        
        En quoi le code n'est pas modulaire sous prétexte que la liaison avec la bibliothèque se fait à la compilation, et pas au runtime ?
        Même si la modularité au sein d'un composant monolithique est une bonne pratique de programmation, la modularité perd une bonne partie de son intérêt si on ne peut pas remplacer un composant par un autre de manière plus "technique" (lib, module, framework, etc.). La modularité facilite le déploiement, la maintenance, le partage de code, la souplesse de configuration et de personnalisation, etc. D'après ce que je comprends, Les algos d'optimisation spécifiques à Lisaac ne sont pertinents que dans les cas ou on fait l'impasse sur ces atouts de la modularité, où l'on se contente de faire de l'héritage "pour faire joli" au sein d'un même module.
        Je vois que leur objectif est de faire un OS, comment feront-ils pour charger et décharger un module à chaud ? Accepter un éco-système de drivers externes ?
        
        Que ce soit uniquement une étape du style "on mettra les bibliothèques après", je peux comprendre (se focaliser sur les nouveautés d'optimisation), mais si le support de bibliothèques/plugins/modules/cquevousvoulez élimine en grosse partie l'intérêt de l'algo principal d'optimisation dont ils sont fier, je ne vois absolument pas l'intérêt. (il a sûrement d'autre qualité cependant)
        
        , mais il est tout à fait possible de faire du code modulaire comme ça.
        Faire du code modulaire n'est pas une fin en soit, ce qu'on recherche c'est les avantages que la modularité apporte. Lisaac semble limité son utilité.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Yusei (Mastodon) le 26 septembre 2007 à 10:38. Évalué à 3.
        
        Que ce soit uniquement une étape du style "on mettra les bibliothèques après"
        Ils ont dit au moins deux fois dans le thread ne pas gérer "encore" les bibliothèques partagées. En tout cas ce dont tu parles, ce n'est pas de programmation modulaire, c'est de la possibilité de charger le code pendant le runtime. La confusion vient surement du fait que tu pensais "programmation de modules chargeables au runtime".
        
        mais si le support de bibliothèques/plugins/modules/cquevousvoulez élimine en grosse partie l'intérêt de l'algo principal d'optimisation dont ils sont fier
        
        Il y a assez peu de chances, dans la mesure où c'est le genre d'optimisation qui n'a d'intérêt que dans les quelques pourcents de code les plus gourmands en calcul de toute application. Pour peu que tes plugins fassent des travaux plus ou moins indépendants les uns des autres, ce n'est pas là dessus qu'on pourrait gagner grand chose.
        
        Maintenant, il faut se rendre compte qu'il y a des choses qui ne sont pas optimisables. Si tu as un algo compliqué et que tu veux pouvoir changer ses structures de données au runtime (sans ré-optimiser au runtime), tu auras de grosses difficultés théoriques, qui n'ont rien à voir avec le langage choisi. Reprocher ça aux créateurs de Lisaac n'aurait aucun sens, donc je pense que ce n'est pas ce que tu voulais dire.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 26 septembre 2007 à 10:50. Évalué à 1.
        
        Agressif ? Bof, pas plus que le commentaire noté +10 de Benoît Sonntag qui dit à 2 reprises que C# et Java sont des langages qui n'auraient jamais dû existé (sans aucune argumentation) quand Lisaac est "moderne".
        
        On troll contre 2 langages et tu te sens tellement personnelement visé qu'il faut que tu attaques ?!
        
        "vous avez rien compris avec vos technos de merde, voilà Lisaac, et encore, c'est qu'un début, vous allez voir !",
        
        D'un point de vue purement langage (et non library), Effel ou OCaml sont bien supérieur à java ou c#.
        
        La modularité facilite le déploiement, la maintenance, le partage de code, la souplesse de configuration et de personnalisation, etc.
        
        Sauf que tu mélanges tout. Lisaac est purement objet (dans l'os même le pixel est un objet, et cela ne rame pas !). Tu as donc toutes la réutilisabilité du code, la personnalisation, et la configuration que tu veux. Pour l'instant, il n'y a pas encore de partage de _binaire_ possible. Mais, c'est juste la 1er version...
        
        les algos d'optimisation spécifiques à Lisaac ne sont pertinents que dans les cas ou on fait l'impasse sur ces atouts de la modularité
        
        J'aurais tendance à dire "t'es con ou tu le fais expres". Qu'est-ce qui empèche de faire une optimisation global d'une lib ? Une lib cela peut être aussi énorme ! Un compilo C ne fait des optims que fichiers C par fichier C, il ne va pas plus loin. Lisaac permet ici d'aller plus loin.
        
        où l'on se contente de faire de l'héritage "pour faire joli" au sein d'un même module.
        
        euh... comment dire .... On te dit que Lisaac gère meme l'héritage alimentaire... l'héritage d'implémentation quoi, pas de concept/type. Justement pour faire plus propre que d'habitude... A part ça on troll...
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Antoine le 28 septembre 2007 à 21:30. Évalué à 4.
        
        Lisaac est purement objet (dans l'os même le pixel est un objet, et cela ne rame pas !). Tu as donc toutes la réutilisabilité du code, la personnalisation, et la configuration que tu veux.
        
        Je ne savais pas qu'être "purement objet" entraînait automatiquement ces qualités miraculeuses. Vous aussi vous avez gobé le marketing Java ?
        
        Un contre-exemple est Javascript qui, bien qu'objet lui aussi (et orienté "prototype" comme Lisaac d'ailleurs...), souffre de l'absence d'un système de modules ou packages (comme ce que connaissent Python, Ruby, Java...).
        
        PS : moi aussi je vous trouve bien agressifs et péremptoires dans votre communication
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par tarlack le 28 septembre 2007 à 22:22. Évalué à 2.
        
        Personnellement je n'aime pas java, donc je risque pas de tomber dans leur marketing. j'ai appris la prog sur le tas, l'objet sur le tas (comme beaucoup de monde, il n'y a rien d'extra à ca) et ca m'a permis de me faire une idée sans intervention exterieure sur l'apport de cette approche...certes la POO ca fait pas encore le café, mais en tout cas pour les critères cités ca aide bien, enfin en tout cas pour moi ;-)
      - [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 20:09. Évalué à 2.
        
        Vous comparez les perfs avec gcc, très bien, mais celui-ci n'est pas réputé pour produire du code ultra-performant, pourquoi ne pas plutôt comparer avec le compilo Intel ?
        
        Simplement parce que ce n'est pas vrai. Par default, icc fait des optims uniquement mis en oeuvre par l'option --fast-math sous gcc.
        
        En gros, icc triche et peut donc produire du code faux.
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par mdlh le 25 septembre 2007 à 20:55. Évalué à 3.
        
        Generalement, quand on cherche a faire du code "ultra-performant" (pour reprendre le terme), on ne se contente pas du resultat produit par le compilateur avec les options "par defaut". Dire que icc n'est pas plus rapide que gcc en analysant le comportement d'icc par defaut... comment dire...
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 21:00. Évalué à 3.
        
        C'est pourtant ce qui a été fait.
        
        J'avais lu un article d'un scientifique bien après la sortie de icc, qui le descendait en flamme.
        
        Il faut dire aussi que gcc a fait des progres. Par exemple, lors des benchs pour Lisaac, on s'est rendu compte que gcc 4.2.1 produit du code environ 30% plus rapide que gcc 2.95 (pour le mpeg2).
        "La première sécurité est la liberté"
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par mdlh le 25 septembre 2007 à 21:24. Évalué à 1.
        
        nicO, je critiquais le raisonnement (ne parler que du comportement par defaut d'icc pour juger icc vs gcc dans le cadre d'optimisation poussee), pas le fait de dire qu'icc ne devrait pas inclure ces optimisations par defaut.
        
        Il me semble que maintenant gcc inclut le code des operations trigonometriques directement plutot que de faire appel aux fonctions de la libm. Ca doit aider un chouilla pour MPEG2. Sinon, oui il y a des progres dans Gcc. Mais va falloir surveiller car il y a des codeurs d'icc qui donne un coup de main de temps en temps...
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 21:54. Évalué à 2.
        
        Concernant ICC, je ne parlais que de l'origine de sa réputation, que je trouve usurpé.
        "La première sécurité est la liberté"
      - [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Philip Marlowe le 25 septembre 2007 à 21:59. Évalué à 8.
        
        Sinon de manière beaucoup plus subjective : évite ce ton prétentieux dans tes journaux/dépêche, c'est vraiment lourd et ne donne pas spécialement une bonne image de Lisaac. Du style :
        "La spécification 0.2 apporte des innovations importantes"
        Des améliorations oui, des innovations faut pas exagérer, je vois pas ce qu'il y a d'innovant à "Le mot clé Expanded remplace *.".
        "certainement un des ramasses-miettes les plus rapides à l'heure actuelle." (sans chiffre ni rien)
        "Non content"[...]
        Et j'en passe.
        Un peu de modestie ne ferait pas de mal si vous voulez attirer un minimum d'attrait du milieu des logiciels libres. Là on a l'impression que tu fais un discours marketing pompeux.
        Puisque l'on est dans la subjectivité, Ontologia réussit à m'intéresser à Lisaac, ne serait-ce que grâce à ce genre de news bien documentées, même si parfois un ton un peu publicitaire affleure. S'il n'avait que toi comme zélateur ça me ferait plutôt fuir Mono.
        
        Je me souviens encore de tes polémiques particulièrement bien argumentées, en tout cas par du subjectif, contre Boubou à propos des brevets que pourrait opposer le moment venu Microsoft à Mono. Tes logorrhées interminables d'une pauvreté affligeante quant à leur contenu, leur orthographe, leur logique, leur argumentation...
        
        Bref je pense que tu es mal placé pour faire ce genre de remarques vexantes à Ontologia, d'un ton condescendant et du haut d'on ne sait quelle science...
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 10:29. Évalué à 2.
        
        Ouahou !
        
        J'ai jamais prétendu que Mono allait révolutionner le monde ou quoique ce soit, d'ailleur je n'en parle même plus et y'a longtemps que j'ai arrêté de vous enmerdez avec ca.
        Sans vouloir faire mon prétentieux, j'ai pas l'impression d'avoir mis un style pompeux dans les depêches que j'ai proposé sur ce site concernant Mono, j'ai essayé d'un mettre un macimum d'objectivité, laissant le lecteur juger lui même de ce qui est "innovant" ou "génial".
        
        Je n'ai pas eu la prétention de faire un joli document LaTeX comme boubou pour en faire un "libre blanc" de la situation des brevets autour de Mono, alors que visiblement il était aussi connaisseur que moi en droit, avait les mêmes problèmes d'interprétation de texte anglais que moi, et évitait savamment les arguments qui puisse contredire la conclusion écrite à l'avance de son document, qui se résume à du bon gros FUD : "avec MS, on sait jamais", bref argumentation de la peur, du doute.
        
        Alors oué, je suis peut être pas doué sur la forme (orthographe, argumentation, ce que tu veux), mais moi j'avais juste l'impression de défendre un projet de logiciel libre. Je sortais pas des trucs "vos technos n'auraient même pas mérité d'existé" et autres conneries du genre.
        
        T'inquiète pas, je suis pas revenu troller longtemps, je vois que certains sont toujours autant admiratif de la forme, même lorsqu'elle s'apparente au plus gros troll, plutôt que de discuter du fond.
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par GuieA_7 (site web personnel) le 26 septembre 2007 à 12:52. Évalué à 1.
        
        Si ça peut te rassurer, des lecteurs (enfin au moins un) apprécient tes posts quand ils vont à contre courant de l'avis de la majorité....
        
        /me qui espère que Lisaac sera le langage/environnement qui dépote et venant de l'INRIA (parce que déçu par SmartEiffel et OCamL).
        
        [^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
        
        Posté par Bozo_le_clown le 26 septembre 2007 à 13:55. Évalué à 4.
        
        Moi aussi.
        
        Timaniac a autant sa place ici que d'autres, d'autant qu'en général ses remarques sont plutôt argumentées et les questions qu'ils posent sont plutôt pertinentes (selon moi en tout cas).
        
        Le but ici est d'évaluer les qualités d'un langage et de le promouvoir.
        Les mêmes qui s'emeuvent ne prennent pas tant de pincettes avec des remarques "condescendantes" à l'egard du monde Java et C#.
        
        On peut donc leur retourner le compliment quand à leur communication.
        
        Bref ! un peu moins de polémiques et un peu plus de simplicité dans le discours (d'autres auraient dit humilité) pour nous pauvres petits ingénieurs préoccupés par nos tâches quotidiennes avec nos vieux langages tous moisis. Car nous sommes vos futurs clients après tout.
# sonntag

Posté par sonntag le 25 septembre 2007 à 00:16. Évalué à 10.

J'interviens pour la première fois, car je suis un peu déçu des remarques que cet article occasionne et aussi parce que pour la première fois, je pense que mon produit a un petit intérêt.
(Après 6 ans de travail)
J'aimerai des critiques constructives après m'être battu pour que Lisaac soit Libre !

Premièrement : On arrive enfin à compiler des prototypes. Expressivité importante: une donnée peut devenir du code et inversement durant l'exécution. L'héritage peut être modifié durant l'exécution, modèle fomel avec les blocks...

Deuxièmement : Nous avons les meilleures performances dans le domaine de l'objet pur (Et cela ne se discute même pas!).

Et Troisièmement : Je n'interviendrai pas ultérieurement, donc je salue tous les programmeurs de SmallTalk, SmartEiffel, Self, IO, ...
Et je dénonce les langage c#, Java, ... comme étant des langages qui n'auraient jamais du faire partie de l'histoire de l'informatique ! Ils ont 30 ans de retard... (tout en restant cool)

Pour finir, je dirai que Lisaac est un petit langage moderne qui est dédié à des programmeurs qui aiment le bas niveau, le C ou ASM.
Je viens de cette catégorie, j'ai tout fait dans ce sens.
Si j'interviens ce soir, c'est parce que nous avons besoin de soutien!
Faites l'effort de découvrir ce langage, (comme je l'ai fait à l'époque pour SmartEiffel et Self) vous n'en serrez pas déçu. Et si vous avez des idées pour améliorer la bête, je suis tout prêt à vous répondre.
Travaillons ensemble vers autre chose que C# et Java...
- [^] # Re: sonntag
  
  Posté par Khâpin (site web personnel) le 25 septembre 2007 à 01:23. Évalué à 2.
  
  Rassure-toi, j'ai l'impression que tous les commentaires (sauf un) sont très encourageants et admiratifs quant à Lisaac.
  C'est comme ça sur DLFP : il y a plusieurs sons de cloches, mais sur beaucoup de sujets, le "collectif" parle d'une voix relativement claire (il n'y a qu'à regarder la note du commentaire de Lucas comparée à celles des autres pour s'en convaincre).
  
  Bravo pour Liisac, à toi et à tous les autres contributeurs (même si je ne saisis pas encore vraiment tous les intérêts de ce langage, n'étant pas programmeur).
- [^] # Re: sonntag
  
  Posté par Yusei (Mastodon) le 25 septembre 2007 à 06:34. Évalué à 3.
  
  Pour ma part, les quelques dépêches/journaux proposés par Ontologia m'avaient donné envie de regarder du côté de Lisaac, mais j'avoue qu'il y a tellement de "langages libres" que j'aimerais apprendre mieux (Eiffel, OCaml...) que je n'avais pas pris le temps d'essayer. C'est l'occasion de m'y mettre, pour voir.
  
  (J'avoue aussi que les exemples de codes ne me parlent pas du tout, mais c'est peut-être normal)
  - [^] # Re: sonntag
    
    Posté par Ontologia (site web personnel) le 25 septembre 2007 à 10:35. Évalué à 2.
    
    Quel genre d'exemple te parlerait mieux ?
    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
    - [^] # Re: sonntag
      
      Posté par Yusei (Mastodon) le 25 septembre 2007 à 11:32. Évalué à 4.
      
      En fait je comprend les exemples mais, comme beaucoup ici, je trouve ça assez laid. Les exemples sont simples, donc je comprend, mais ça m'inquiète quand j'imagine du code en plus grande quantité. Les exemples que je vois sur le site ne me montrent pas les qualités du langage.
      
      (à part la syntaxe condition.if que je trouve rigolote)
      - [^] # Re: sonntag
        
        Posté par Mildred (site web personnel) le 27 septembre 2007 à 17:36. Évalué à 1.
        
        En fait, du code Lisaac, ce n'est pas forcément moche ... C'est même joli si on a la bonne coloration syntaxique.
        
        Tu veux voir du code Lisaac ? http://codebrowse.launchpad.net/~mildred/liworld/trunk/files(...) (dans le répertoire src)
        
        Sinon, le code Lisaac ressemble fortement à du C, et est du même coup facile à apréhender. Il semblerait que Benoît l'ait étudiée pour. Par contre, le truc qui peut être déroutant, c'est que tu n'a ni mot clef break, ni continue. Du coup du dois te débrouiller autrement. C'est faisable facilement mais ça force a réfléchir souvent un peu plus.
        
        Une question: Lisaac optimise-t-il les boucles du genre :
        
        ( + bool :BOOLEAN; ... 1.to 20 do { i:INTEGER; bool.if { // Quelque chose } }; )
        
        Ça permet de remplacer les Break et Continues facilement je trouve.
        
        PS: à quand la possibilité de poster facilement du code sur DLFP ? Par exemple pouvoir utiliser la balise <p> ou <br/>
- [^] # Re: sonntag
  
  Posté par reno le 25 septembre 2007 à 08:08. Évalué à 6.
  
  Bon j'ai déjà fait la remarque, ne te sens pas visé, mais si on regarde SmallTalk, on voit qu'il n'a pas eu un grand succès, par contre Ruby lui, qui n'en est pas si loin que ça de Smalltalk, a bien décollé.
  
  Il a décollé pour plusieurs raisons:
  1- un langage très souple, mais ça Smalltalk l'avait déjà.
  2- une syntaxe *très* agréable: car parlant au programmeurs C, shell, Perl, mais en plus propre.
  3- une killer-app Ruby on Rails, qui a été réalisée car Ruby a 1 et 2.
  
  Isaac a (1) mais pas (2) *a mon avis*..
  Hors (3), le vrai déclic, ne vient que si suffisamment de programmeurs s'interesse au langage donc il faut d'abord avoir (1) (la c'est bon) *et* (2)..
  
  Après chacun a ses préférences pour la syntaxe, mes favoris actuels sont Ruby et Scala.
  
  Après je ne prétends pas avoir la recette ultime..
  - [^] # Re: sonntag
    
    Posté par BAud (site web personnel) le 25 septembre 2007 à 08:50. Évalué à 1.
    
    Isaac a (1) mais pas (2) *a mon avis*..
    c'est pas sympa pour Isaac_Newton, vu que tu t'es visiblement trompé, réessaie avec Lisaac cette fois-ci :-)
    - [^] # Re: sonntag
      
      Posté par Mildred (site web personnel) le 27 septembre 2007 à 17:39. Évalué à 1.
      
      En plus benoît m'a dit que la syntaxe de Lisaac a été étudiée pour être proche du C et être facilement compréhensible par n'importe qui.
      
      Après, le problème, c'est que sur les court exemples, on a le mot clef Section qui peut perturber, mais c'est comme le public: du C++. le vrai code Lisaac est très joli.
      - [^] # Re: sonntag
        
        Posté par freeze le 28 septembre 2007 à 20:26. Évalué à 5.
        
        Je dois être bigleux, mais plus je vois de code Lisaac, et moins je vois de rapport (lexical / grammatical) avec du C ....
        
        Honnêtement, je ne vois pas en quoi Lisaac est plus joli que du C.
      - [^] # Re: sonntag
        
        Posté par reno le 28 septembre 2007 à 23:50. Évalué à 3.
        
        >Lisaac a été étudiée pour être proche du C
        
        Pour une valeur très faible de proche: le ':=' a la place du =, ça ne fait pas très C!
        
        Bon plus sérieuseusement, moi je ne le trouve pas joli (des gouts et des couleurs je sais), pour être plus constructif, ce que je n'aime pas dans la syntaxe de Lissac:
        -Les types tout en majuscules, beh ça fait mal aux yeux, commencer par une majuscule est suffisant et bien plus lisible.
        
        -Le dernier élément évalué qui est la valeur de retour de la fonction: les gars d'EROS avait fait une étude et avait trouvé que c'était une mauvaise idée du point de vue de la sécurité car souvent des fonctions retournaient des trucs qu'elles n'auraient pas due.. Donc ils suggèrent d'utiliser plutôt un mot clef explicite, le ^ de Smalltalk me paraît tout indiquer ici.
        
        -Les +| -var : type := value; pour définir des variables, on s'y fait peut-être mais au départ c'est plutôt génant.
        Je prefere la syntaxe de Limbo:
        a: type; // declare a et l'initialise avec la valeur du type par defaut
        a : type = val; // declare a et l'initialise avec val
        a := val; // inférence de type: declare a avec le type de val et l'initialise avec val, c'est la variante la plus utile.
        a = val; // a doit être déjà déclaré.
        
        Après pour le scope (+ et -), je ne sais pas trop, juste que par défaut cela devrait être local.
  - [^] # Re: sonntag
    
    Posté par Lucas le 25 septembre 2007 à 08:53. Évalué à 2.
    
    En fait, je ne suis même pas sûr que la qualité intrinsèque du langage compte tant que ça.
    
    Regarde PHP, beaucoup de monde sait programmer en PHP, alors que c'est un langage qui a toujours été en retard sur beaucoup de concepts, et que presque personne de "cultivé" ne peut trouver "beau".
    
    Et pour Ruby, heureusement qu'il y a eu RoR: avant RoR, le langage était déjà aussi élégant, et pourtant presque personne ne l'utilisait.
    - [^] # Re: sonntag
      
      Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 11:05. Évalué à -1.
      
      Lisaac cherche des codeurs type C/C++ voir java/C# pas ceux qui touche à PHP ou VBA...
      "La première sécurité est la liberté"
    - [^] # Re: sonntag
      
      Posté par reno le 25 septembre 2007 à 11:31. Évalué à 2.
      
      Certes, mais je dirais que PHP et Perl se sont ouvert des niches car ils sont arrivés les premiers sur leur créneau.
      
      Après justement sur le créneau du Web et du scripting, Ruby gagne du terrain car justement il est plus élégant (avec beaucoup de difficulté car le poids de l'installé est énorme).
      
      >Et pour Ruby, heureusement qu'il y a eu RoR: avant RoR, le langage était déjà aussi élégant, et pourtant presque personne ne l'utilisait.
      
      Tout à fait exact.
  - [^] # Re: sonntag
    
    Posté par Miguel Moquillon (site web personnel) le 25 septembre 2007 à 15:33. Évalué à 2.
    
    mais si on regarde SmallTalk, on voit qu'il n'a pas eu un grand succès,
    
    Hum ... Il n'a pas eu, certes, le succès escomptée. Pourtant, aujourd'hui, il semble avoir le vent en poupe et permet même de construire des outils assez en avance : squeak, open croquet, seaside, pour ne citer qu'eux, sont assez détonnant, surtout en perspective des applications qu'ils ont permis de produire comme par exemple Dabble DB ou Qwaq. Ce qui est marrant, c'est qu'il semble que c'est via Ruby qu'un certain nombre de programmeurs s'oriente de plus en plus vers Smalltalk.
    
    Jusqu'à présent, par son essence même, Smalltalk semble être le seul qui permet de construire rapidement et proprement une application d'une certaine qualité, une application qui reste ... objet (et pas seulement dans la programmation). Aussi, si Lisaac me semble intéressant, il me laisse toutefois un sentiment de perplexité (je ne sais pourquoi) ; mais il faudrait que je l'essai à nouveau. Je pense qu'il prendra probablement toute sa force dans un environnement approprié (isaacOS ?).
- [^] # Re: sonntag
  
  Posté par yim yom (site web personnel) le 25 septembre 2007 à 10:52. Évalué à 2.
  
  arrete de te plaindre Benoit. Si tu veux communiquer sur ton langage, fait plutot passer la news sur freshmeat ou plnews. LinuxFr est ... comment dire.... une tribune ou les opinions sont bien tranchees ! :-)
  - [^] # Re: sonntag
    
    Posté par Ontologia (site web personnel) le 25 septembre 2007 à 11:13. Évalué à 3.
    
    Fresmeat c'est fait. Plnews, on peut pas poster.
    Slashdot, ça passe pas, évidemment.
    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
- [^] # Re: sonntag
  
  Posté par Philippe F (site web personnel) le 25 septembre 2007 à 11:17. Évalué à 7.
  
  Je suis admiratif du travail effectué sur ce langage qui a l'air bien sympathique. Par contre, côté syntaxe, je souffre.
  
  Je suppose qu'une partie de la syntaxe est héritée du SmallTalk ou de Eiffel, en tout cas d'un langage que je ne connais pas. J'ai vraiment du mal à comprendre la logique des exemples de code.
  
  La page sur la simplicité vante le faible nombre de mot-clé, mais j'ai l'impression que cela se paie en "caractère-clé", ce qui rend le code plutôt pénible à déchiffrer. Comme Perl quoi...
  - [^] # Re: sonntag
    
    Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 12:00. Évalué à 1.
    
    non en fait c'est le coté ultra minimaliste du code qui impose ça.
    
    Tout est objet même les clause logique du if, même les bloc de code des 2 branches du if...
    
    Une fois que tu as compris ça, tout devient plus claire :)
    "La première sécurité est la liberté"
    - [^] # Re: sonntag
      
      Posté par Mildred (site web personnel) le 27 septembre 2007 à 17:45. Évalué à 1.
      
      Comme le langage est très extensible, tu peux utiliser une syntaxe très proche du C.
      
      par exemple un test peut très bien s'écrire
      
      if (condition) then {...} else {...};
      
      Ou encore tu peux faire un appel de fonction (grâce aux paramètres multiples de la version 0.2) ainsi:
      
      mafonction(param, param);
      
      On dirait presque du C. Après bien sûr de base tu ne peux pas le faire car les fonctions de la lib sont écrites autrement (avec des mots-clefs) ... Mais Lisaac a cette possibilité.
      
      Enfin, s'approcher de cette syntaxe n'est pas le but de Lisaac. Mais c'est pour dire que Lisaac n'a pas une syntaxe si étrange que ça. Je me rappelle le jour ou j'ai commencé à programmer en Lisaac, avant je ne comprenant rien à la syntaxe, mais moins d'une heure après, j'avais tout compris.
- [^] # Re: sonntag
  
  Posté par judicael le 25 septembre 2007 à 11:21. Évalué à 3.
  
  Je connais peu les problèmes spécifiques de développement bas niveau, mais clairement, ce que tu as fait me semble avoir plus qu'un "petit intérêt" :
  
  - Quels autres langages savent à la fois travailler à un niveau proche de la machine, et être de haut niveau ? (Forth ?) Clairement, Lisaac me semble une innovation dans ce domaine et elle est la bienvenue.
  
  - De ce que j'en ai vu, l'interface Lisaac/C semble être extrêmement aisée puisqu'on peut écrire du code C dans une méthode Lisaac, ce qui me paraît également un très bon point pour travailler avec des systèmes existants.
  
  Un créneau qui me semblerait intéressant, c'est de convaincre des développeurs de modules du noyau Linux ou/et des développeurs de (modules) xorg d'utiliser Lisaac (attention qd même aux questions de licence), car cela donnerait une forte visibilité à Lisaac. Est-ce dans tes projets ?
  
  Linux est écrit en C, un langage qui n'aurait jamais dû exister. J'aimerais beaucoup que C puisse être mis à la poubelle et remplacé par un langage de plus niveau et *nix lui-même remplacé par des OS mieux conçus. On peut rêver d'un OS en Haskell (voir le boulot très intéressant d'Andrew Tolmach sur le sujet) et de machines Lisp mais C ne pourra sans doute être remplacé que progressivement, de manière évolutive. J'attends donc beaucoup de Lisaac...
  
  Judicaël.
  
  PS : Pour justifier mes remarques sur C : Les débordements de tampons, responsables de la majeure partie des failles de sécurité, étaient inexistants en 1974 sous le système le plus sécurisé de l'époque. Il faut dire qu'il était écrit en PL/I, un langage certes assez gros, mais dans lequel on pouvait manipuler des chaînes de caractères de façon décente. Plus d'infos : http://www.acsac.org/2002/papers/classic-multics.pdf
  
  Pour mémoire, 33 ans après, je viens de jeter un coup d'oeil au 60 premières vulnérabilités données sur CVE (http://www.cve.mitre.org/cve/) sur les 365 de ce mois (septembre 2007). Pour 9 d'entre elles (15%), on trouve "buffer overflow" ou "stack overflow" dans le résumé...
  - [^] # Re: sonntag
    
    Posté par reno le 25 septembre 2007 à 11:49. Évalué à 2.
    
    >Quels autres langages savent à la fois travailler à un niveau proche de la machine, et être de haut niveau ?
    
    Le C++ :-) ?
    Pas taper!
    
    Plus sérieusement: D qui a le gros avantage justement d'être proche du C++, tout en étant mieux fait (c'était pas dur ;-) ).
    
    Pour ta comparaison C/Haskell, bof: le C pour moi, a un gros avantage sur Haskell: je comprends ce que fait le compilateur, Haskell repose sur des concepts que je ne comprends pas (et oui j'ai lu plein de tutoriels sur les monad mais ça ne m'a pas éclairé).
    
    Ceci dit, je suis d'accord qu'il y a mieux que le C, mais pour moi ce n'est pas Haskell: je veux développer des programmes, pas faire des math.
    - [^] # Re: sonntag
      
      Posté par Yusei (Mastodon) le 25 septembre 2007 à 11:53. Évalué à 3.
      
      je veux développer des programmes, pas faire des math.
      
      C'est pas la même chose ?
      - [^] # Re: sonntag
        
        Posté par Antoine le 25 septembre 2007 à 13:43. Évalué à 2.
        
        Non, ce n'est pas la même chose.
        C'est d'ailleurs la raison pour laquelle la plupart des langages de recherche ne percent pas : parce que leurs concepteurs pensent qu'un langage de programmation doit s'apparenter à un langage formel décrivant des objets mathématiques.
        
        [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 25 septembre 2007 à 13:48. Évalué à 4.
        
        C'est d'ailleurs la raison pour laquelle la plupart des langages de recherche ne percent pas : parce que leurs concepteurs pensent qu'un langage de programmation doit s'apparenter à un langage formel décrivant des objets mathématiques.
        
        Ce qui n'est pas le cas pour Lisaac.
        Il est certes très minimaliste, mais pas à but mathématique.
        
        Benoit Sonntag l'a certes pensé en tant que chercheur, mais aussi en tant qu'auteur de logiciel généraliste : il a été demo-coder, il a écrit un logiciel de dessin vectoriel, etc...
        
        C'est vraiment un langage qui a été conçu pour faire de tout.
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
      - [^] # Re: sonntag
        
        Posté par lezardbreton le 26 septembre 2007 à 10:42. Évalué à 2.
        
        Heu, quel est le rapport ? (question sérieuse)
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 26 septembre 2007 à 11:04. Évalué à 2.
        
        Je trollais un peu, mais comme dans tout troll il y a une part de vérité.
        
        Un ordinateur et un programme sont des objets mathématiques. Il existe de nombreux modèles mathématiques équivalents qui les décrivent, dont les plus connus sont les machines de Turing et le lambda calcul.
        
        Toutes les questions concernant ce qu'on peut faire ou pas avec un ordinateur, la preuve de validité et sur la performance des algorithmes, ne trouvent leurs réponses que dans le cadre de ces modèles. Si on programme sans faire de maths, on ne peut résoudre que des problèmes très simples et rien de nouveau.
        
        Ceci dit comme les compilateurs et bibliothèques se chargent d'une partie des maths, on peut généralement s'en passer tant qu'on se limite à des interfaces pour manipuler des données (tri, affichage, enregistrement...).
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 26 septembre 2007 à 14:43. Évalué à 4.
        
        Il me semble que tu surestimes tres largement le role des maths (et de l'informatique theorique) dans la programmation. Contrairement a ce que tu dis, je pense que la quasi totalite des problemes qui se posent en programmation se resolvent sans faire de maths.
        
        Je parierais gros que parmis la population des programmeurs, y compris des meilleurs, seule un petite minorite a des connaissances approfondies en informatique theorique et estime que ca fait d'eux de meilleurs programmeurs.
        
        Bien sur il faut etre capable de comprendre des notions de base comme la complexite, mais ca reste totalement elementaire d'un point de vue mathematique, et ca ne necessite absolument pas de passer par de quelconques modeles mathematiques de programmes.
        
        Bon, je ne remet pas en cause l'interet de l'informatique theorique d'un point de vue intellectuel, mais force est de constater le decalage enorme entre les preoccupations des informaticiens (ceux qui font des programmes qui servent) et les preoccupations que les theoriciens imaginent chez les informaticiens.
        
        Cela dit, ce message n'avait pas forcement lieu d'etre dans un thread sur Lissac. Son contenu ne lui etait pas destine.
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 26 septembre 2007 à 15:19. Évalué à 1.
        
        Je parierais gros que parmis la population des programmeurs, y compris des meilleurs, seule un petite minorite a des connaissances approfondies en informatique theorique et estime que ca fait d'eux de meilleurs programmeurs.
        
        Peut-être que ça explique la légendaire fiabilité de l'informatique ;)
        
        Plus sérieusement, comme je le disais, si tout ce que tu fais c'est de la gestion de données, tu n'auras peut-être pas besoin de maths, encore que tu aies besoin de connaître quelques notions de complexité pour choisir tes structures de données.
        
        Mais si tu veux résoudre de nouveaux problèmes avec tes données, pas simplement les lire/modifier/enregistrer/trier, tu vas avoir besoin d'écrire des algorithmes, et là tu vas avoir besoin d'éléments pour:
        - écrire le code
        - prouver que ton code fait ce que tu veux
        - savoir si c'est efficace
        
        Je prend des exemples à la con, mais il est assez difficile par exemple de concevoir un algorithme de routage si on ne sait pas ce qu'est un graphe. Difficile d'écrire l'algorithme de routage si on n'est pas à l'aise avec la récursion. Difficile de prouver qu'il fait ce que l'on veut. Difficile de calculer sa complexité.
        
        L'informatique n'étant pas destinée uniquement à assembler des composants existants, dès qu'on veut créer du code on utilise des maths.
        
        Par contre je suis sûr que beaucoup de gens les utilisent sans savoir que c'en est.
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 26 septembre 2007 à 23:06. Évalué à 1.
        
        En fait, tout depend d'ou on place la limite entre math et informatique.
        
        Pour moi, la recursivite, c'est de l'info pure, rien a voir avec les maths. Et ca ne necessite aucune notion de math. Les preuves de programme, idem. La complexite ca necessite des notions de math niveau terminale (premier cycle universitaire au max), pour les considerations pratiques en tout cas. Pareil pour la theorie des graphes etc, etc...
        
        Mais on s'ecarte du sujet. Ce que je voulais dire, c'est que non, les programmes informatiques ne sont pas des objets mathematiques. Il peuvent effectivement etre formellement decris comme tel, mais fondamentalement, le travail d'un informaticien, meme de haut niveau, qui ecrit un programme n'a rien a voir avec celui d'un mathematicien.
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 27 septembre 2007 à 07:08. Évalué à 3.
        
        En fait, tout depend d'ou on place la limite entre math et informatique.
        
        Je ne place pas de limite entre maths et info, et c'est pour ça que je m'amusais à demander naïvement quelle était la différence. Je te rassure, je sais que tout le monde ne partage pas ce point de vue ;)
        
        Pour le défendre, je ne ferais que souligner que les gens les plus connus en informatique sont mathématiciens. À commencer par les créateurs de l'informatique comme on la connait (Turing, Church, Von Neumann) jusqu'au auteurs plus récents (Knuth, qui a créé TeX mais surtout écrit The Art of Computer Programming, qui est un livre de maths, Claude Berge qui a plus ou moins créé la théorie des graphes, ...).
        
        Pour moi, la recursivite, c'est de l'info pure, rien a voir avec les maths. Et ca ne necessite aucune notion de math. Les preuves de programme, idem. La complexite ca necessite des notions de math niveau terminale (premier cycle universitaire au max), pour les considerations pratiques en tout cas. Pareil pour la theorie des graphes etc, etc...
        
        Houla, ok... je ne veux pas te vexer en suggérant que tu n'as pas beaucoup étudié l'informatique théorique, mais bon... tout ça c'est des maths. Toutes ces choses ont toutes été créées par des mathématiciens, et ils ne seront sûrement pas d'accord pour les voir sortir de leur domaine ;)
        
        Pour prendre l'exemple le plus extrême, dire que la théorie des graphes n'est pas des maths, c'est euh... comment dire... ce n'est même pas un domaine de l'informatique qui s'apparente aux maths, c'est des maths, ça en a toujours été. Si on considère que les graphes sont un outil informatique parce qu'on s'en sert en informatique, on peut penser la même chose des transformées de Fourier, de la théorie de l'information, de la cryptographie...
        
        fondamentalement, le travail d'un informaticien, meme de haut niveau, qui ecrit un programme n'a rien a voir avec celui d'un mathematicien.
        
        Je suis d'accord pour le fait d'écrire un programme, mais c'est une petite partie du travail de l'informaticien, qui doit aussi concevoir le programme et le valider. Pour la conception et la validation, il s'agit de mathématiques.
        
        Pour ne prendre qu'un exemple, lorsque les informaticiens ont créé des réseaux, ils se sont demandés comment reproduire certains algorithmes qui avant étaient centralisés, de manière décentralisée. Par exemple, si tu connais la topologie (maths !) de ton réseau, tu peux facilement calculer les distances (minimales) entre deux noeuds. Mais si tu es un ordinateur sur le réseau, et que tu ne connais pas à priori sa topologie, c'est plus compliqué. Il a donc fallu concevoir des algorithmes distribués qui faisaient le même travail. C'est de l'informatique ? des maths ? Au point de vue du travail à effectuer, c'est des maths de bout en bout, mais le domaine d'application est indiscutablement l'informatique.
        
        Et là, comme on a effectivement bien dévié du sujet, je dirais quand même que je bosse (plus pour longtemps) pour un SSII, et quand je code des sites webs en Rails ou quand j'installe un serveur mails, je suis conscient de ne pas faire (beaucoup) de maths. Mais je ne crée rien de nouveau, je ne fais qu'assembler des briques qui servent à faire des traîtements classiques sur des données. Ce n'est malheureusement pas tous les jours que les informaticiens-programmeurs doivent résoudre de nouveaux problèmes.
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 27 septembre 2007 à 10:49. Évalué à 3.
        
        En fait, si, j'ai fait beaucoup d'informatique theorique. Mais je ne suis pas vexe, car je sais qu'il y a une petite part de mauvaise fois dans mes propos. J'ai bosse avec des logiciens, des types qui ecrivent des papiers de recherche incomprehensibles en voulant formaliser des concepts somme toute relativement simple de l'informatique, alors ca m'a traumatise.
        
        Mais sur le fond, je persiste. "The Art of Computer Programming" n'est en rien un livre de math, meme si Knuth a demarre dans les maths. Le fait d'utiliser des notions de math ne fait pas de quelqu'un un mathematicien, ni des concepts crees des concepts mathematiques.
        
        On pourrait appliquer le meme raisonnement a la physique. La physique ce n'est pas des maths. Ce n'est pas parcequ'on resoud une equa diff qu'on est un mathematicien.
        
        Quand a tes exemples, pareil, les maths ne sont qu'un outil, d'ailleurs en general utilise a un niveau elementaire, licence au maximum. OK, il y a de la crypto qui depote pas mal niveau math mais c'est plutot une exception.
        
        Enfin bon, la question de ce que sont les mathematique est complexe est tres interessante. J'imagine que des tas de gens mieux place que moi ont beaucoup ecris sur le sujet.
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 27 septembre 2007 à 11:06. Évalué à 1.
        
        C'est effectivement intéressant: The Art of Computer Programming (taocp) est-il un livre de maths ou non ? Les outils utilisés sont des outils mathématiques, et l'objet étudié est une machine de Turing (ou un algorithme, c'est pareil), qui est un objet mathématique.
        
        Quand Knuth prend un algorithme et prouve qu'il est correct, il effectue une preuve mathématique. Je ne vois pas de différence entre le cours de maths de terminale où je devais prouver la correction (c'est le bon mot ?) de l'algorithme d'Euclide pour factoriser des nombres, et les preuves d'algorithmes de taocp.
        
        Quand dans son quatrième tome il aborde les énumérations, on est en plein de la combinatoire, pour ceux qui en doutaient encore après la lecture des tomes précédents.
        
        Quand il calcule la complexité d'un algorithme, difficile de nier qu'il s'agit aussi d'une preuve mathématique en regardant les méthodes utilisées. Alors finalement la question porte vraiment sur la nature mathématique ou non de l'objet qu'on étudie (l'algorithme).
        
        Rappelons quand même que la machine de Turing est un formalisme qui a été créé pour répondre à la question: quels sont les objets mathématiques que l'on peut calculer ?
        
        [^] # Re: sonntag
        
        Posté par Sytoka Modon (site web personnel) le 27 septembre 2007 à 11:48. Évalué à 3.
        
        Les sciences pour l'ingénieur étant le plus possible cohérentes, elles ont besoin de preuve de type mathématiques pour justement démontrer cette cohérence.
        
        Si je prends la théorie des éléments finis très utilisée en calcul de structure, elle a été mise au point par des mécaniciens, puis des matheux ont formalisé tout cela avec la notion de formulation faible et d'espace de Sobolev. Cela ne veut d'ailleurs pas dire que tout calcul éléments finis est mathématiquement juste car seul un petit bout de ce qu'utilise les mécaniciens est 'prouvé' mathématiquement.
        
        Alors maintenant, on trouve des bouquins qui sont 'à cheval' entre les mthas et la mécanique et qui expose les éléments finis plutôt d'un point de vue ou plutôt de l'autre.
        
        C'est pas pour cela qu'un ingénieur fait des maths lorsqu'il calcule un pont ! Il utilise des maths pour faire des Sciences Pour l'Ingénieur (le fameux SPI qu'on voit un peu partout maintenant).
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 27 septembre 2007 à 12:01. Évalué à 2.
        
        Je ne connais pas les sciences pour l'ingénieur, donc je manque d'éléments pour comprendre l'analogie.
        
        En tout cas l'informatique n'a pas été formalisée après coup par des matheux, c'est eux qui l'ont créée pour répondre à une question bien précise (que peut-on calculer). Je n'ai pas l'impression que depuis elle soit devenue une science à part.
        
        [^] # Re: sonntag
        
        Posté par Sytoka Modon (site web personnel) le 27 septembre 2007 à 14:26. Évalué à 2.
        
        > Je n'ai pas l'impression que depuis elle soit devenue une science à
        > part.
        
        Justement, je me le demande parfois. Les maths se sont construites en même temps que les sciences pour l'ingénieur jusqu'en 1900 pour faire grossier. Depuis, c'est plus flou de savoir qui avance le premier les billes (par exemple, la notion de distribution était utilisé en SPI avant que Swartz ne formalise tout cela sous cette appellation).
        
        Aujourd'hui, je ne suis pas sur que ce soit toujours des matheux qui portent les nouveaux langages. En france, l'informatique est rattaché aux maths appliquées donc le lien est fort et la france est forte en math ! Je ne sais pas si aux USA le lien est aussi fort, surtout que la bas il n'y a pas cette distinction math appli - math pure.
        
        Donc, il y a l'effet INRIA en france donc on le voit sur les langages réalisés plus particulièrement en france.
        
        Mais si je prends perl6 par exemple, je suis loin d'être aussi sur de ton affirmation. Que les concepteurs essayent de faire le plus logique possible, je veux bien le croire (normal) mais j'ai vraiment l'impression que de plus en plus de langage vont se faire sans que cela soit un groupe de matheux qui en soit à l'origine.
        
        [^] # Re: sonntag
        
        Posté par fmaz fmaz le 28 septembre 2007 à 08:28. Évalué à 2.
        
        > En france, l'informatique est rattaché aux maths appliquées.
        
        Alors pourquoi y a-t-il des sections différentes au CNU pour les maths appliquées et l'informatique.
        
        Comment expliques-tu qu'après ma thèse, j'ai été qualifié en 25 (mathématiques) et en 27 (informatique) mais pas en 26 (maths appliquées) ?
        
        Pour ceux qui lisent encore ceci mais qui ne comprennent rien à ce que je raconte, je recommence en plus verbeux. Après une thèse, pour pouvoir se présenter à un concours pour être enseignant chercheur, il faut envoyer un dossier au CNU qui dit si on a le droit. Le CNU est divisé en section pour éviter qu'un historien ne se retrouve avec un dossier de chimiste. Dans mon cas, des matheux ont accepté de me qualifier en 25 (resp. 27) et ont donc reconnu que ce que je faisais, c'était suffisamment des maths (resp. de l'informatique) pour eux mais pas en 26. Je ne fais donc pas de maths appliquées.
        
        [^] # Re: sonntag
        
        Posté par Sytoka Modon (site web personnel) le 28 septembre 2007 à 09:13. Évalué à 2.
        
        Je suis d'accord avec toi. J'ai un peu trop globalisé ;-) En gros, je voulais dire que l'informatique en france est globalement dans la sphère des maths (et je dirais globalement plutôt du coté math appli) alors que petit à petit, il va se passer la même chose que dans les autres discipline du SPI et le génie logiciel aura (ou a déjà) avoir sa place propre comme le génie électrique.
        
        De ce que je vois, l'informatique à la fac ou dans les écoles d'ingenieurs est souvent proche soit des UFR de math, soit des écoles de math.
        
        [^] # Re: sonntag
        
        Posté par Thomas Douillard le 28 septembre 2007 à 11:45. Évalué à 4.
        
        Le truc de l'informatique c'est que c'est à la frontière de pleins de choses:
        
        L'info théorique pure, c'est des modèles mathématiques de la calculabilité, des machines, des programmes. C'est à la frontière des maths, de la logique, ...
        
        L'informatique sert à des humains, qui bossent potentiellement dans n'importe quelle discipline. Donc l'info s'applique, peut fournir des outils pour n'importe quelle discipline.
        
        Pour que ces outils soient utilisables par le plus grand nombre, on doit faire des interface intuitives, utilisables, efficaces. On fait de l'ergonomie.
        
        L'informatique peut servir à faire tourner un robot ou une chaine de production : on fait de la robotique, de l'automatique, voire de l'IA.
        
        L'informatique se sert de morceaux de siliciums et de puce, on utilise de l'électronique, qui elle est faite POUR exécuter des programmes (CPU), mais l'informatique peut s'intéresser à d'autres modes de calculs.
        
        L'informatique permet en général de résoudre des problèmes, on fait de l'algorithmique, qui utilise parfois des maths pures, des propriétés mathématiques pures complexes pour certains problème, on fait de l'algorithmique. Les problèmes qu'on attaque sont soit des problèmes assez théoriques, soit des problèmes très pratiques.
        
        On fait aussi du traitement de données au sens large, là tout dépend du domaine d'application, avec des algorithmes, des interfaces pour présenter les données, des analyses de données pour les présenter à l'utilisateur, en utilisant des outils statistiques, des algorithmes, ...
        
        Les utilisateurs, enfin, certains, croient que l'informatique se résument à ce qu'ils voient sur leur écran. C'est l'arbre qui cache la forêt.
        
        En conclusion, l'informatique, au sens large, c'est transversal, c'est à l'interface de pleins de domaine. Science des ordinateurs, du traitement de l'information, des calculs automatiques, de la communication avec des machines, ...
        
        Et encore j'ai du oublier des trucs.
        
        [^] # Re: sonntag
        
        Posté par Dr BG le 27 septembre 2007 à 08:33. Évalué à 4.
        
        La complexite ca necessite des notions de math niveau terminale (premier cycle universitaire au max)
        
        Là, j'imagine que tu ne sais pas vraiment ce qu'est la théorie de la complexité pour dire ça. Idem pour les preuves etc.
        
        Que bon nombre de programmeur fassent des programmes ne nécessitant que des notions ultra basiques d'informatique théorique ne signifie pas que ces notions théoriques se limites à ces connaissances basiques.
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 27 septembre 2007 à 10:28. Évalué à 2.
        
        Si, je sais vraiment ce qu'est la théorie de la complexité. Je sais que certaines parties de cette theorie volent tres haut, mais que pour les considerations pratiques, il suffit d'avoir _vraiment_ compris ce que sont un logarithme, une exponentielle, une limite. Le reste vient tout seul.
        
        Donc c'est bien un niveau terminale. Un excellent eleve de terminale pourrait obtenir facilement une comprehension de la theorie de la complexite suffisante pour n'importe quel besoin pratique de l'informatique.
        
        Si tu peux me decrire un contre exemple, ca m'interesse.
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 27 septembre 2007 à 10:49. Évalué à 2.
        
        Quel est le meilleur algorithme de tri à inclure dans une bibliothèque (et donc pas pour un besoin spécifique mais en général) ?
        
        Avec des notions de base en complexité, on peut calculer la complexité au pire de Quicksort, O(n^2) et celle de Mergesort O(n * log n), et en déduire que Mergesort est meilleur.
        
        Si on arrive à calculer la complexité en moyenne, on se rend compte que Quickstort, en moyenne, est en O(n * log n), et si on investigue un peu on se rendra compte qu'en pratique il est en général plus rapide.
        
        C'est un exemple classique qui explique pourquoi la complexité au pire n'est pas toujours suffisante pour choisir un algorithme. Et calculer la complexité en moyenne d'un algorithme, c'est souvent une autre paire de manches. J'ai eu à prouver celle de Mergesort en DEA...
        
        En fait, j'ai l'impression que pour toi un "besoin pratique de l'informatique", ça sera plutôt d'ouvrir un livre, regarder les différentes complexités et savoir reconnaitre laquelle est la meilleure. Effectivement dans ce cas, il suffit de savoir qu'un logarithme est meilleur qu'une exponentielle.
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 27 septembre 2007 à 11:09. Évalué à 1.
        
        Ton exemple fait appel a des notions de maths de terminale. Rien de plus. OK, la demo est peut-etre penible a ecrire, mais ca ne change pas l'aspect elementaire des maths qu'il y a derriere.
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 27 septembre 2007 à 11:17. Évalué à 4.
        
        Ton exemple fait appel a des notions de maths de terminale.
        
        Non. Ou alors en terminale tu as étudié les arbres aléatoires et les séries génératrices, ce qui conforterait la thèse selon laquelle le niveau de l'enseignement se dégrade.
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 27 septembre 2007 à 11:54. Évalué à 1.
        
        Ou alors j'ai fait une terminale avant toi.
        
        Plus serieusement je reconnais mon erreur. Mais il n'en reste pas moins que l'idee derriere cette distinction en general/pire des cas et n log n / n^2 est simple a comprendre pour ces algos de tri. Meme si effectivement la moyenne peut etre difficile a calculer de facon rigoureuse.
        
        Je pense que si les bons programmeurs "sentent" ces distinctions, peu d'entre eux ecrivent des series generatrices sur des coins de table.
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 27 septembre 2007 à 12:13. Évalué à 2.
        
        Je ne crois pas que les bons programmeurs puissent "sentir" la distinction entre deux bons algorithmes :) Facile de sentir que le tri à bulle est mauvais, mais pour choisir entre quicksort, mergesort et heapsort il faut un peu plus d'éléments. J'ai choisi cet exemple parce que justement on choisit souvent quicksort alors qu'il est moins bon "au pire".
        
        Le fond du problème reste que si l'on n'a pas besoin de connaitre grand chose pour choisir un algorithme parmis ceux déjà créés, quand il faut créer soi-même c'est plus compliqué.
        
        [^] # Re: sonntag
        
        Posté par Nicolas Boulay (site web personnel) le 27 septembre 2007 à 14:36. Évalué à 2.
        
        un trie à bulle est bon si les élements ne sont pas trop en désordre.
        "La première sécurité est la liberté"
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 27 septembre 2007 à 15:13. Évalué à 1.
        
        Je ne voudrais pas pinailler, surtout que j'ai admis avoir eu tort, mais c'est justement sur des considerations pratiques que tu choisis QuickSort, alors que la theorie t'indiquerait plutot de prendre MergeSort systematiquement, qui a une complexite egale en moyenne a QuickSort, et meilleure dans le pire des cas.
        
        Bref, de toute facon, il y a un malentendu dans cette conversation. Je suis d'accord, l'info a besoin d'outils mathematiques, generalement triviaux mais pas toujours (tiens je te file un bon contre-exemple: les SVM). Ce n'est pas ca que je remet en cause. Mais bon, on a eu une discussion la dessus un peu plus haut, je n'en rajoute pas.
        
        [^] # Re: sonntag
        
        Posté par Gniarf le 27 septembre 2007 à 21:26. Évalué à 2.
        
        SVM ? Sciences et Vie Micro ? oO
        
        [^] # Re: sonntag
        
        Posté par Sebastien le 28 septembre 2007 à 01:25. Évalué à 1.
        
        je suppose, vu le contexte, que c'est 'Support Vector Machine':
        
        http://en.wikipedia.org/wiki/Support_vector_machine
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 28 septembre 2007 à 09:14. Évalué à 2.
        
        Oui, desole pour l'acronyme esoterique. D'habitude c'est moi qui rale contre ca.
        
        [^] # Re: sonntag
        
        Posté par fmaz fmaz le 28 septembre 2007 à 08:35. Évalué à 3.
        
        Les gens utilisent quicksort car c'est un tri en place avec une faible constante.
        
        Heapsort est en place mais fait de gros déplacement dans la mémoire ce qui cause des problèmes dès qu'on veut trier de gros volumes de données.
        
        Merge-sort n'est, par défault, pas en place. Il utilise deux fois plus de mémoire et ça pose des problèmes. On peut en faire un tri en place mais c'est beaucoup plus compliqué.
        
        Dans la vraie vie, quicksort est effectivement plus rapide.
        
        Dans un autre genre. L'algo de multiplication de polynômes qui a la meilleur complexité passe pas de la FFT et tourne en n.log(n). En pratique, à part pour des polynômes vraiment grands (plusieurs milliers de coefs), les gens utilisent l'algorithme de Kartsuba (en n^{3/2}) et des généralisations.
        
        [^] # Re: sonntag
        
        Posté par Dr BG le 27 septembre 2007 à 10:55. Évalué à 3.
        
        Disons qu'il me semble là qu'on parle de la complexité d'un algorithme donné et pas de la complexité du problème. Alors effectivement, si on ne s'intéresse qu'a la complexité de l'algo, ça va.
        
        Si le programmeur se rend compte que la complexité de son algo est exponentielle il est tout de même très intéressant de savoir dans quelle classe se trouve le problème. S'il est dans P, alors faudra sans doute se creuser la tête pour trouver un algo polynomial. S'il est NP-complet soit on se dit "tant pis" soit faut se tourner vers une bonne approximation. Classer les problèmes ne me parait pas si évident. Bon, on ne lui demandera peut être pas d'en faire la preuve, mais même intuitivement ça nécessite bien souvent une bonne expérience des "réductions" (si on ne veut pas être à côté de la plaque, l'intuition est parfois trompeuse).
        
        Tous les programmeurs ne sont pas confrontés à ces problème et bon nombre d'informaticiens n'ont qu'une connaissance assez vague de ces notions (moi aussi). Je pense cependant que dans certains besoins pratique de l'informatique cela peut arriver. Et quand ça arrive, qu'est-ce qu'on fait ?
        
        [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 27 septembre 2007 à 11:11. Évalué à 5.
        
        Le fait que les professionnels de l'informatique ne connaissent rien au math, et plus généralement à la théorie est pour moi un gros problème.
        
        Je travaille avec des gens qui ne connaissaient même pas les expressions régulières ou les tables de hashage. On leur donne pourtant des responsabilités et des projets de plusieurs milliers d'euros et de ligne de code à gérer.
        
        Résultat, ils sont incapables de penser en terme de généricité, et passent leur temps à refaire, et à faire refaire (et c'est moi qui prend...) ce que l'on a déjà fait.
        Pire, ceux qui ont eu affaire avec des théoriciens, les méprisent parce qu'ils "se souciaient plus de l'élégance que de l'efficacité".
        Pour eux, théoricien = Type qui veut se faire plaisir avec des trucs qui coutent cher et qui ne marchent pas.
        Ils ne voient pas au delà et ne comprennent pas que leur budget pourraient diminuer d'un tiers (et leur gains augmenter de tout autant) s'il était capable de voir un tout petit peu plus loin.
        
        Le fait d'avoir un diplome d'ingénieur est mieux considéré que d'avoir fait une thèse en France est très symptomatique des oeillères des dirigeants dans le domaine...
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: sonntag
        
        Posté par Vivi (site web personnel) le 26 septembre 2007 à 19:58. Évalué à 6.
        
        Il me semble que tu sous-estimes tres largement le rôle des maths (et de l'informatique théorique) dans la programmation.
        
        Sérieusement, des affirmations comme « la quasi totalite des problemes qui se posent en programmation se resolvent sans faire de maths » ne veulent pas dire grand-chose: ça ne sert à rien de considérer la "totalité" des problèmes en programmation car personne n'est confronté à tous ces problèmes en même temps. Ça dépend énormément du domaine. Quand on bosse dans le domaine des compilateurs, outils d'analyse statique, moteurs de preuve, etc. c'est très utile.
        
        « le decalage enorme entre les preoccupations des informaticiens (ceux qui font des programmes qui servent) et les preoccupations que les theoriciens imaginent chez les informaticiens. »
        
        C'est rigolo cette tournure: pour toi les théoriciens ne sont pas des informaticiens. Moi j'aurai appelé "informaticiens" les théoriciens et "programmeurs" ceux qui font des programmes ...
        
        [^] # Re: sonntag
        
        Posté par lezardbreton le 26 septembre 2007 à 20:11. Évalué à 6.
        
        Sincèrement, je suis d'accord avec le fait que l'utilisation de mathématique est relativement marginale dans l'informatique. En fait, tout dépend du milieu dans lequel tu te retrouves. Je travaille par exemple en finance de marché. A part les pricers (calculateurs de prix de produits), les calculateurs de risques (VAR, CVAR, etc...), aucune mathématique à l'horison.
        
        Comme d'habitude, notre environnement influence notre vision globale de l'informatique, et donc personne n'aura le dernier mot.
        
        [^] # Re: sonntag
        
        Posté par TeXitoi (site web personnel) le 27 septembre 2007 à 09:52. Évalué à 2.
        
        Mouais... Et les requètes sur des bases de données, c'est pas de la théorie des ensembles ? Les conditions dans tes if, c'est pas de la logique ? et la théorie des ensemble et la logique, c'est pas des mathématiques ?
        
        Souvent, ce qui est considéré comme "informatique" n'est finalement que des mathématiques appliqués, notamment logique, théorie des ensembles et arithmétique.
        
        [^] # Re: sonntag
        
        Posté par el_mickey le 27 septembre 2007 à 10:14. Évalué à 2.
        
        Et les additions que l'épicier fait c'est pas des maths ?
        
        [^] # Re: sonntag
        
        Posté par reno le 27 septembre 2007 à 10:28. Évalué à 2.
        
        Bof, il n'y a pas besoin de connaître la théorie des ensembles pour faire une requête sur une base de donnée, il n'y a pas non besoin de connaître la théorie des ensemble pour faire un logiciel de base de donnée.
        
        Donc non une base de donnée ce n'est pas lié à la théorie des ensembles, après tu peux l'analyser en termes de théorie des ensemble si ça t'amuse mais bof.
        
        Par ton raisonnement, je peux dire que la cuisine c'est des math..
        
        [^] # Re: sonntag
        
        Posté par LeMagicien Garcimore le 28 septembre 2007 à 04:43. Évalué à 1.
        
        et l'algèbre relationnelle c'est pas des maths peut être ?
        
        [^] # Re: sonntag
        
        Posté par Sytoka Modon (site web personnel) le 28 septembre 2007 à 07:48. Évalué à 2.
        
        Et les espaces de Riemann, c'est pas des maths peut-être ? C'est pas pour cela qu'Einstein était un mathématicien !
        
        Je trouve que pas mal de post ici confondent math et génie logiciel.
        
        [^] # Re: sonntag
        
        Posté par Dr BG le 28 septembre 2007 à 09:06. Évalué à 4.
        
        A mon avis, la différence est là : si tu travailles sur les espaces de Riemann en soit, tu es mathématicien, sinon tu l'utilises juste comme outil et ça ne fait pas de toi un mathématicien.
        
        Il y a des informaticiens qui travaillent sur les graphes, la complexité etc. en soit. Il y en a d'autres qui ne font que l'appliquer. Parmis les informaticiens, il y en a des matheux et y'a les autres (sûrement pareil en physique d'ailleurs).
        
        Alors oui, selon moi quand on ne fait qu'appliquer des outils mathématiques (aussi complexe soit-ils), on ne fait pas des maths.
        
        Ayant posé cela, revenons au fil de la discussion.
        
        Il y avait deux débats mélangés : y'a-t-il des informaticiens qui font des maths ? et a-t-on besoin de connaître les maths pour faire de l'informatique ?
        
        A la première question, je réponds : "oui, mais pas tous"
        A la seconde : "même si on ne fait qu'appliquer des outils, il est souvent nécessaire de bien les comprendre, donc faut quand même comprendre un minimum les maths"
        
        Pour finir, je concluerais en disant que je prends plaisir à troller là-dessus, et que je sais très bien que certains boulot dans l'informatique ne nécessite quasiment aucune connaissance de maths. Personnellement, je ne suis ni un grand théoricien, ni un grand technicien :-) (les deux m'intéressent pourtant)
        
        [^] # Re: sonntag
        
        Posté par Sytoka Modon (site web personnel) le 28 septembre 2007 à 14:01. Évalué à 3.
        
        > A la seconde : "même si on ne fait qu'appliquer des outils, il est
        > souvent nécessaire de bien les comprendre, donc faut quand même
        > comprendre un minimum les maths"
        
        Je suis Administrateur Système et Réseau. je peux t'assurer que la plupart des copains qui le sont aussi ne sont pas des matheux pour un sous.
        
        Il n'y a pas besoin d'être bon en math pour régler un serveur samba ou postfix. Pour faire ces choses là, il faut savoir faire du génie logiciel donc connaitre les limites de ceux-ci et les conséquences de telle ou telle action.
        
        [^] # Re: sonntag
        
        Posté par Dr BG le 28 septembre 2007 à 14:18. Évalué à 2.
        
        C'est un peu ce que je voulais dire par "si on ne fait qu'appliquer des outils" [mathématiques]. Dans ce cas, tu n'appliques pas d'outils mathématiques (enfin il me semble, hein :-)). J'ai même rajouté à la fin de mon commentaire : "je sais très bien que certains boulot dans l'informatique ne nécessite quasiment aucune connaissance de maths."
        
        Et enfin, j'ai quand même dit que je "trollais".
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 28 septembre 2007 à 14:32. Évalué à 2.
        
        Pas besoin de math pour regler un serveur postfix ou samba, pas besoin de genie logiciel non plus. On s'est pas mal ecarte debat initial, mais on parlait des programmeurs, quand meme, sinon le debat n'a plus aucun sens.
        
        [^] # Re: sonntag
        
        Posté par Sytoka Modon (site web personnel) le 28 septembre 2007 à 15:05. Évalué à 2.
        
        Mais je suis aussi programmeur lorsque j'ai le temps. Et en admin système, tu programmes, certes du bash la plupart du temps...
        
        La ou je veux en venir est qu'on n'est pas tous des dieux de l'informatique et je vois bien que mes programmes sont à cent lieux des optimisations que font pas mal de gens sur dlfp. Mais enfin, je code et je n'y connais rien au concept mathématique qui sont derrière l'informatique. Cela ne m'a pas empêché de faire à une époque un tout petit peu d'assembleur.
        
        Je comprends que lorsqu'on fait un nouveau langage ou une nouvelle structure de données btree... On s'amuse à essayer de démontrer par A + B que ce que l'on fait est bien mais cela concerne combien d'informaticien en pratique. Très peu.
        
        En plus, je me souviens que certain algo de convergence en calcul numérique converge super bien alors que mathématiquement, on n'arrive pas à le démontrer et que l'inverse arrive aussi (un super algo qui converge d'après le théorème mais qui ne marche pas en pratique). Il faut voir que la machine fait pas mal d'erreur et ne suis donc pas toujours les maths elle aussi.
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 28 septembre 2007 à 15:53. Évalué à 2.
        
        Oui, c'est juste l'argument que je remettais en cause.
        
        En fait, je pense que la vrai question est de savoir dans quelle mesure les gens qui font avancer l'informatique, qui concoivent des trucs nouveaux, utilisent des concepts avances de mathematique (pas ce qu'on apprend en fac d'info). Mon point de vue c'est que globalement non, meme si il y a des tas d'exceptions. C'est tres discutable, je le reconnais.
        
        Mais qu'il y ai des millions de gens qui soient informaticiens, au sens large, et qui n'y connaissent rien en math, c'est evident, personne ne le conteste.
        
        [^] # Re: sonntag
        
        Posté par Sytoka Modon (site web personnel) le 28 septembre 2007 à 20:15. Évalué à 2.
        
        Je ne sais pas mais globalement, j'ai l'impression que si les premiers jets ont été fait par des matheux, les versions suivantes ont été faites par des experts de génie logiciel. Par exemple, pour Fortran, qui est dans les organismes de normalisation ?
        
        Si je prends l'exemple de Sather, l'équipe qui l'a conçu en partant d'Effeil à divergé sur un point de conception. Dans Effeil, Meyer essaye par tous les moyens d'unifier tous les concepts autour de sa notion d'objet alors que Sather est construit pour orthogonaliser un maximum les concepts afin que l'implémentation et la syntaxe de l'un n'intervienne que le moins possible sur l'autre. Je trouve que cette approche est du grand art de génie logiciel.
        
        Dernier exemple pris exprès à contre courant de << l'approche francaise >>, Perl est un grand langage (pour moi) qui est piloté par un linguiste. En cela, Perl ouvre peut être la voie. Ce n'est peut être pas le premier dans ce cas là mais cela doit être l'un des plus utilisé.
        
        Sur ce dernier langage, je ne suis pas d'accord avec Benoit et la manière dont il a critiqué les autres langages (même s'il ne cite pas Perl). Perl6 n'a pas la même ambition que Lisaac mais lorsque l'on connait la qualité des personnes qui travaillent dessus depuis pas mal d'année, la somme des concepts que ce langage va permettre d'utiliser, cela me donne un sentiment de profond respect.
        
        [^] # Re: sonntag
        
        Posté par lezardbreton le 27 septembre 2007 à 10:45. Évalué à 2.
        
        Tu as une notion des mathématiques vraiment étendue...
        La logique par exemple semble faire partie pour toi de la défintion commune des maths, autant dire que ce n'est pas mon point de vue.
        
        [^] # Re: sonntag
        
        Posté par rewind (Mastodon) le 27 septembre 2007 à 12:19. Évalué à 1.
        
        Je vais te filer un poly de logique d'une centaine de pages dans laquelle il n'y a pas la moindre petite ligne de code ou même une seule allusion à la programmation et on en reparle après...
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 27 septembre 2007 à 12:32. Évalué à 3.
        
        Attention à la convention de Genève...
        
        [^] # Re: sonntag
        
        Posté par lezardbreton le 27 septembre 2007 à 13:43. Évalué à 2.
        
        La logique n'a pas grand rapport avec le code non plus. C'est une discipline en soit, à côté de la discipline des mathématiques. Je ne comprends pas le sens de ta phrase...
        
        [^] # Re: sonntag
        
        Posté par TeXitoi (site web personnel) le 27 septembre 2007 à 14:09. Évalué à 1.
        
        http://fr.wikipedia.org/wiki/Logique_math%C3%A9matique
        
        La logique, c'est des mathématiques, d'après cet article, en tout cas...
        
        [^] # Re: sonntag
        
        Posté par lezardbreton le 27 septembre 2007 à 14:39. Évalué à 4.
        
        et d'après celui là : http://fr.wikipedia.org/wiki/Logique non.
        La logique (du grec λόγος (logos), ce qui veut dire, entre autres, raison ou discours) est dans une première approche l'étude des règles formelles que doit respecter toute déduction correcte.
        
        Elle est depuis l'antiquité l'une des grandes disciplines de la philosophie, avec l'éthique et la métaphysique. En outre, on a assisté durant le XXe siècle au développement fulgurant d'une approche mathématique et informatique de la logique. Elle trouve de nos jours de nombreuses applications en ingénierie, en linguistique, en psychologie cognitive, en philosophie analytique ou en communication.
        
        [^] # Re: sonntag
        
        Posté par Sytoka Modon (site web personnel) le 27 septembre 2007 à 11:41. Évalué à 4.
        
        C'est pas parce que que la théorie est cohérente mathématiquement que l'on fait des maths. Les sciences pour l'ingénieur, c'est quoi ?
        
        Exemple, je fais du calcul de structure par élément finis, c'est des maths ? Et bien non. Lorsque je démontre que les éléments finis converge dans des cas précis, oui, là, je fais des maths. Mais pas lors d'une utilisation sur des cas réels.
        
        [^] # Re: sonntag
        
        Posté par fmaz fmaz le 27 septembre 2007 à 10:38. Évalué à 3.
        
        Le problème avec tout ça, c'est qu'un informaticien, ça peut être l'administrateur système, l'analyste programmeur, ou le chercheur en théorie des graphes.
        
        Pour prendre une analogie mécanique, cela revient au même que dire qu'un mécanicien ou qu'un ingénieur de chez peugeot sont tous les deux de mécanos.
        
        Oui, l'utilisation des mathématiques est marginale chez ton concessionnaire automobile mais non l'utilisation des mathématiques n'est pas marginale dans les bureaux d'études automobile.
        
        La grande majorité des informaticiens sont des mécaniciens de l'informatique. Oui, ils n'utilisent pas beaucoup de maths. C'est aussi compatible avec le fait que les maths prennent une part importante en informatique.
        
        Bref.
        
        [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 27 septembre 2007 à 11:00. Évalué à 3.
        
        J'ai l'impression que c'est surtout un problème français.
        
        En France, les ingénieurs pensent que les chercheurs sont des professeurs Nimbus qui ne servent à rien, et les chercheurs pensent que les ingénieurs sont des gros nuls à peine capable d'écrire un intranet en Java.
        
        Résultat, t'as fait une thèse, ou même t'as un diplôme nul et t'as quelques papiers de recherches à ton actif, c'est mal vu quand tu cherches un boulot. C'est mon cas...
        
        L'aspect mathématique, voire même théorique, est ainsi rejeté par les professionnels de l'industrie.
        
        "Mathématique" c'est une notion, savoir ce qui rentre ou pas dans le champ d'une notion, n'est pas un débat sémantiquement profond, mais simplement un débat de sens, "que met-on dans telle ou ou telle catégorie ?"
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: sonntag
        
        Posté par Antoine le 28 septembre 2007 à 21:41. Évalué à 2.
        
        En France, les ingénieurs pensent que les chercheurs sont des professeurs Nimbus qui ne servent à rien, et les chercheurs pensent que les ingénieurs sont des gros nuls à peine capable d'écrire un intranet en Java.
        
        Résultat, t'as fait une thèse, ou même t'as un diplôme nul et t'as quelques papiers de recherches à ton actif, c'est mal vu quand tu cherches un boulot. C'est mon cas...
        
        Ca t'apprendra à penser que les ingénieurs sont des gros nuls à peine capable (sic) d'écrire un intranet en Java :-)
        
        [^] # Re: sonntag
        
        Posté par tarlack le 28 septembre 2007 à 22:11. Évalué à 2.
        
        et au milieu il y a les ingés qui veulent devenir chercheurs, qui savent à peu près à quoi s'en tenir des 2 cotés :-)
        
        Cela dit, j'ai rencontré des ingés qui pensent effectivement que la recherche ca sert à rien...mais par contre coté chercheur, bien que n'en ayant pas rencontrés beaucoup (la plupart étant mes profs), je n'ai pas vu le coté "les ingés c'est des nuls". Cela dit je ne doute pas que certains pensent comme cela. Mais bon, faudrait pas non plus prendre l'arbre pour la foret quoi...enfin, j'espere que les gens visés ne sont bien que l'arbre qui planque la foret, sinon c'est grave ^^
    - [^] # Re: sonntag
      
      Posté par GTof le 27 septembre 2007 à 13:09. Évalué à 1.
      
      je veux développer des programmes, pas faire des math.
      
      Et moi j'en ai marre de ceux qui croient que programmer c'est juste pisser du code. Si tu programmer intelligemment, tu as besoin de notions théoriques.
      
      Premièrement tout programmeurs devrait penser à la complexité algorithmique de ses programmes, oui c'est des maths mais si ton programme est exponentiel alors qu'ils pourrait être linéaire ca fait une différnece.
      
      Deuxièmement tout programmeur devait aussi de poser des questions sur les bases théoriques des langages qu'il utilise. Les langages reposent sur des notions qui peuvent paraître simple au premier abord mais sont souvent complexes. Comprendre la logique de son langage c'est produite du code mieux pensé, mieux adapté, éviter les pièges, etc ...
      
      Troisièmement, la tendance actuelle est clairment d'avoir des langages plus formels: plus de typage, un typage plus fort et plus souple, des notions théoriques puissantes, ... Tout ceci pour donner des langages puis sûrs et plus souples. Sans parler des langages où on peut donner la spécifications des programmes, ceux ou on prouve les programmes, etc ...
      
      Ok le C c'est simple mais le programmeur à tout à gérer à la main ce qui introduit forcément plus de bugs (segfault, bufferoverflow,etc...), la réutilisabilité du code est faible, etc ... Quand à la rapidité du C, qui dit que ce que le programmeur va faire à la main n'est pas mieux fait par un système automatique d'un langage évolué ? SI tous les programmeurs utilisaient toujours les meilleurs algorithmes connus ca se saurait.
      
      Un langage est un outil et plus un outil est puissant plus il demande d'apprentissage pour le manier mais plus le résultat en vaut le coup.
      
      D'ailleurs serait il possible d'avoir un comparatif sur les gains qu'apporte Lissac sur le développement de Isaac OS en comparaison avec les problèmes qu'apportent le C sur Linux ou *BSD par exemple ? Par exemple quelque chose que sur Issac est fait naturellement alors que chez les autres c'est compliqué a faire.
      
      Pour en remetrre une couche sur la programmation et les maths, j'ai découvert récemment Concoqtion ( http://www.metaocaml.org/concoqtion/ ), le niveau mathématique dedans est vraiment élevé (j'espère qu'un jour j'arriverai à comprendre ....) en revanche sa puissance à l'air tout simplement ahurissante !
      - [^] # Re: sonntag
        
        Posté par reno le 27 septembre 2007 à 22:10. Évalué à 4.
        
        >>«je veux développer des programmes, pas faire des math.»
        >Et moi j'en ai marre de ceux qui croient que programmer c'est juste pisser du code. Si tu programmer intelligemment, tu as besoin de notions théoriques.
        
        Très peu.. La principale qualité d'un bon développeur c'est d'être capable de comprendre le besoin et ensuite de sortir du code maintenable pour y répondre, point.
        
        >Premièrement tout programmeurs devrait penser à la complexité algorithmique de ses programmes
        
        Un niveau de math *très différent* de celui réclamé pour essayer de comprendre Haskell, ce qui était le sujet de cette phrase de mon post.
        
        >Deuxièmement tout programmeur devait aussi de poser des questions sur les bases théoriques des langages qu'il utilise.
        
        Ah? Les langages que j'utilise le plus sont le C, le shell (et le Perl quand je ne peux pas l'éviter) et je regarde attentivement D pour le futur, qu'est ce que tu entends par 'base théorique' dans leur cas?
        
        >Troisièmement, la tendance actuelle est clairment d'avoir des langages plus formels:: plus de typage, un typage plus fort et plus souple,
        
        La tendance en recherche oui. Ailleurs c'est loin d'être évident: Ruby, D les langages qui montent, sont très différent d'Haskell, Coq et consorts..
        
        Je ne vois pas pourquoi tu montes sur tes grand chevaux dans ton post: personne ne t'empeche de t'éclater avec de la preuve de programme, chacun son truc, je préfère écrire des programmes qu'essayer de comprendre des math comme celle utilisée pour Haskell ou Coq.
    - [^] # Re: sonntag
      
      Posté par Mildred (site web personnel) le 27 septembre 2007 à 17:50. Évalué à 1.
      
      Sauf qu'en D je ne pense pas que tu puisse directement inclure des instructions assembleur, si ? J'ai un peu programmé avec ce langage et ça ressemblait un peu à un Java sans machine virtuelle et plus proche du C.
      
      Lisaac, tu peux directement inclure du code C (via les backquotes ``), et tu maîtrise vraiment le résultat en C obtenu. Et si ton compilateur C permet d'écrire de l'assembleur, tu peux le faire directement depuis Lisaac
      - [^] # Re: sonntag
        
        Posté par Gilles G. le 27 septembre 2007 à 18:06. Évalué à 2.
        
        Sauf qu'en D je ne pense pas que tu puisse directement inclure des instructions assembleur, si ?
        Si.
        Le D est vraiment adapté à la programmation système puisque tu peux aussi choisir de ne pas utiliser le ramasse-miette.
        
        Sinon, le D a aussi un gros avantage: la compilation est _très_ rapide (c'est presque du pascal).
      - [^] # Re: sonntag
        
        Posté par reno le 27 septembre 2007 à 21:17. Évalué à 2.
        
        >Sauf qu'en D je ne pense pas que tu puisse directement inclure des instructions assembleur, si ?
        
        Si: http://www.digitalmars.com/d/iasm.html
        
        >Lisaac, tu peux directement inclure du code C
        
        D s'interface assez bien aussi avec le C, un peu comme le C++ appelle du C et la syntaxe de D est assez proche de celle du C..
        
        Pour le détail:
        http://www.digitalmars.com/d/interfaceToC.html
- [^] # license et divers points techniques
  
  Posté par Tramo Piere le 25 septembre 2007 à 11:29. Évalué à 1.
  
  Ne serait-il pas mieux d'ajouter une exception à la GPLv3 de la bibliothèque (ou changer pour la LGPLv3) afin de permettre le développement de logiciels en licence GPLv2, QPL, propriétaire, etc ?
  
  Concernant les fonctionnalités:
  * je n'aime vraiment pas du tout la syntaxe smalltalk, n'est-il pas possible d'avoir un préprocesseur intégré (à la camlp5 ou ocaml+twt) ? Avoir quelquechose de ressemblant à Python ou à D (ou même caml) serait un grand plus.
  * Concurrence : les performances sont-elles les mêmes en architecture multi-coeur, multi-processeur ?
  * Interaction avec les bibliothèques existantes : comment lier le code à du c ? Est-t-il possible d'écrire facilement des librairies partagées ?
  - [^] # Re: license et divers points techniques
    
    Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 12:03. Évalué à 2.
    
    1) Je pense que cela n'est qu'une question d'habitude.
    2) y'a pas encore de concurrence propre en Lisaac, c'est prévu pour la suite. pthread marche mais c'est pas top.
    3) C'est très facile de réutiliser du C. Par contre, il n'y a pas encore de notion de lib partagé.
    "La première sécurité est la liberté"
  - [^] # Re: license et divers points techniques
    
    Posté par tarlack le 25 septembre 2007 à 12:32. Évalué à 7.
    
    Pour les fonctionnalités :
    
    * la syntaxe, c'est clairement une question de goût. Je viens du C++, et quand je suis passé à Lisaac, clairement au début c'est dur. En développant le mod pour Kate, je me suis rendu compte qu'en fait cette syntaxe est geniale, pour plusieurs raisons à mes yeux :
    
    - très peu de règles de grammaire. En 10 minutes tu connais toute la syntaxe, même les finesses.
    
    - conceptuelle et stricte : certes c'est abstrait et tranché, mais une fois maitrisé tu obtiens une expressivité sans faille. L'aspect tranché est une force, car le langage ne part pas n'importe où, meme si ca peut deplaire.
    
    - La sémantique est nette car limitée à quelques trucs (pas besoin d'apprendre des centaines de notions), tout le reste est de la lib, donc il suffit de lire le code ou regarder la doc générée. Par exemple, le fait que les blocs soient à evaluation tardive t'assure que si tu as :
    (cond1) && {cond2}, en lisant le slot '&&' de BOOLEAN (et surtout de TRUE et FALSE), tu es certain que le bloc {cond2} ne sera evalué que si cond1 est vraie. Je ne fais reference à aucune spec, à aucune norme, mais à la lib.
    
    - tu n'es limité quasiment que par ton imagination. Tu veux avoir telle construction specifique à ton projet en cours ? en general tu peux la faire. C'est limite si tu ne crées pas un langage vraiment dédié à chaque projet, dans un formalisme qui est celui du Lisaac. En cela Lisaac se rapproche de meta-langages, mais cela n'engage que moi bien sûr.
    
    * concurrence : pour l'instant le modèle COP n'est pas encore implémenté, mais tu peux voir à quoi ca ressemble dans le manuel, il y est décrit. Donc tous les tests sont mono-proc, meme si executés sur du multi-coeur/proc.
    
    * interaction avec les bibliothèques : tu peux écrire directement du code C en lisaac, mais ca fout l'analyse de flot en l'air donc c'est pas genial. En plus il y a des restrictions si je me souviens bien, pour le typage. Après pour l'intégration de bibliothèques ayant leurs propres structures de données, tu peux le faire en ecrivant les prototypes associés à ces structures, avec la section Mapping pour les membres. Cela dit, il faudrait tester cela plus avant pour voir jusqu'où ca peut aller.
- [^] # Re: sonntag
  
  Posté par beagf (site web personnel) le 25 septembre 2007 à 13:23. Évalué à 9.
  
  Depuis le temps que je voyais des news sur Lisaac, je n'avais pas eu le temps d'éssayer. Et bien c'est chose faite. Enfin c'est en cours.
  Je ne vais pas parler du langage car je ne le connais pas encore suffisament, et je n'ai pas eu le temps de m'habituer à la syntaxe, mais je vais parler de l'environement.
  
  Je trouve que l'environnement de Lisaac est beaucoup trop intrusif. Je ne supporte pas qu'un programme pense savoir mieux que moi ce que je veux.
  Donc pour moi, il y a quelques choses essentielles à modifier dans le package fournit :
  - ne pas allez modifier le fichier .bashrc de l'utilisateur, ou en tout cas pas sans lui demander avant si il le desire.
  - dans le fichier d'indentation de vim, ne pas forcer l'utilisateur à utiliser les même tabulation que l'auteur.
  Peut-être que l'auteur adore les tabulations qui on une largeur de 2 espace et qui sont automatiquement converties en espace, mais ce n'est pas le cas de tout le monde.
  
  Et lors de l'instalation de la syntaxe pour vim, indiquer clairement que l'instalation du fichier de configuration par default est le fichier .vimrc et non pas une config du fichier de syntaxe. Il est douloureux de voir que l'installation d'un script de coloration syntaxique a virer toute la configuration de votre éditeur...
  
  Donc j'ai installé Lisaac et je dois dire que l'installation m'a fortement refroidit. Mais je ne me suis pas découragé, et je vais quand même faire quelques petites remarques.
  La syntaxe est particulière et pour le moment je ne la trouve pas très lisible, mais il va falloir voir à l'usage. En général il me faut un temps d'adaptation quand j'éssaye un nouveau langage. Par contre je n'aime pas que les langages qui forcent l'utilisation des majuscules et minuscules. Je trouve moche de devoir ecrire les noms des prototypes en majuscule, mais c'est une question de goûts. Y a-t'il une raison particulière qui force ceci ?
  Ensuite un point de détails, mais la doc ne semble pas à jours car elle parle de category dans la section Header, mais le compilateur le signale comme deprecated.
  
  Mais je dois avouer que si je n'ai pas accrocher au niveau de la syntaxe, le reste du langage me plait bien pour l'instant. Il est relativement puissant, et simple à apprendre si l'on connait déjà un peu les concept qui sont derrière.
  Pour faire quelques tests j'ai recoder en Lisaac quelques un des codes de calculs scientifique que j'avais code en C. Ça ce fait très bien et naturellement. Le code Lisaac me semble même dans quelques cas plus simple à comprendre.
  Et question perf, mon code en C est super optimisé, alors que le code Lisaac est loin de l'être puisque je ne connait encore aucune des subtilitées du langage, ni les manière de rendre le code rapide et facilement optimisable. Et pourtant les perfs sont plustot bonnes. J'obtiens en moyenne du code 40% plus lent, ce qui me laisse penser que l'on peut obtenir des perfs equivalentes quand on maîtrise le langage.
  
  Donc un bilan plustot encourageant. Mes principaux grief étant dirigés vers l'instalation et celle-ci ne se faisant qu'une seule fois...
  Pour l'instant il reste clair pour moi que mes codes critiques resterons en C, mais je vais surement ecrire quelques programmes non critique en Lisaac pour l'étudier plus en profondeur et voir si l'investissement en temps est valable.
  - [^] # Re: sonntag
    
    Posté par Ontologia (site web personnel) le 25 septembre 2007 à 13:44. Évalué à 3.
    
    Merci pour tes remarques concernant l'install, on va en prendre bonne note.
    
    Je me demandais : As-tu compilé le c produit par lisaac, avec les mêmes optimisation que ton source initial en C ?
    genre :
    -O3 -fomit-frame-pointer -ftree-vectorize -msse -march=pentium4 -mtune=pentium4
    
    Ensuite, il suffit d'optimiser l'algorithme pour avoir des performances, la gestion mémoire n'est pas à ta charge. Par contre utiliser des variables temporelles, des déroulement de boucles peuvent aider.
    
    Mais nicO saurait mieux répondre que moi sur le sujet :)
    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
    - [^] # Re: sonntag
      
      Posté par beagf (site web personnel) le 25 septembre 2007 à 17:28. Évalué à 4.
      
      Pour les premiers essais j'utilisait les binnaires fournits directement par Lisaac, mais justement, ne sachant pas quelles options il passait à gcc je me suis mits à les compiler avec exactement les mêmes options que pour mon code. Les comparaisons sont faites avec ces derniers binnaires.
      
      Pour ce qui est des algorithmes, ils sont déjà optimisés à mort, mais même avec les meilleurs algos, si tu les implémente comme un pieds tu obtiens un programme qui se trainne comme un bousin. Et même si tu fais gaffe de bien coder ton algo il peut toujours y avoir certains coûts cachés dans certaines constructions du langage.
      
      Pour ce qui est de la gestion de la mémoire, à mon avis, une bonne partie de la différence de prformance viens de la. Mes programmes travail sur des volumes de données assez énormes, l'un d'entre eux ayant des pics à 15 Go en C, le même dépassant les 21 Go en Lisaac. Et la machine sur laquelle il tourne dispose de 16 Go de ram, le deuxième doit donc swapper de temps en temps pendant l'éxecution.
      Le programme en C est beaucoup plus complèxe à ce niveau car toute la mémoire est gérée manuellement et le tout optimisé pour tenir en mémoire sur cette machine. Mais cela n'explique pas toute la différence de perfs.
      
      Pour ce qui est des déroulements de boucles, c'est plustôt au compilateur de le faire. (éventuellement via un -funroll-loop) La version en C n'a aucun déroulement manuel pas plus que la version en Lisaac. Le problème c'est que ce genre de manip rend vite le code illisible et impossible à maintenir pour un gain qui au final est minimime par rapport à ce que le compilateur produit.
      
      Pour ce qui est de l'inniling du message en dessous, il est déjà configurer mais je ne sais plus à combien, je n'ai pas le makefile sous les yeux mais je pourrais vérifié. La taille du code ayant peu d'importance ici, l'essentiel est de trouver le bon compromis avec la taille du cache. J'avais fait pas mal d'essais pour voir à quel point on pouvais inliner sans que les caches miss fassent perdre plus qu'on ne gagne. Le problème c'est que tout les petits reglages dans ce genre on été faits pour la version en C et ne sont surement pas adapters à la version en Lisaac.
      
      Par contre il reste un point ou la version en Lisaac est loin derrière la version en C, c'est le temps de compilation...
      - [^] # Re: sonntag
        
        Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 17:44. Évalué à 4.
        
        "-funroll-loop" est inclus dans -O3 souvent -funroll-all-loops fait encore mieux. Sinon, je pense que Ontologia pensait faciliter la vie du compilo avec les variables en question.
        
        Par contre il reste un point ou la version en Lisaac est loin derrière la version en C, c'est le temps de compilation...
        
        Forcément en C, c'est toi qui a fait les optims pas le compilo :)
        "La première sécurité est la liberté"
      - [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 25 septembre 2007 à 17:48. Évalué à 5.
        
        Pour ce qui est de la gestion de la mémoire, à mon avis, une bonne partie de la différence de prformance viens de la. Mes programmes travail sur des volumes de données assez énormes, l'un d'entre eux ayant des pics à 15 Go en C, le même dépassant les 21 Go en Lisaac. Et la machine sur laquelle il tourne dispose de 16 Go de ram, le deuxième doit donc swapper de temps en temps pendant l'éxecution.
        
        Pour le moment, Lisaac prend ses aises niveau mémoire, mais ça va s'améliorer, ya des idées en l'air comme la réutilisation de variables locales, en jouant sur les lignes de cache (oui parce que la gestion de la mémoire en lisaac essaye de jouer sur la gestion de ligne de cache)
        
        Comme on veut cibler l'embarqué, on va travailler sur la consommation mémoire, mais c'était pas la priorité pour cette version.
        
        Pour ce qui est des déroulements de boucles, c'est plustôt au compilateur de le faire. (éventuellement via un -funroll-loop) La version en C n'a aucun déroulement manuel pas plus que la version en Lisaac. Le problème c'est que ce genre de manip rend vite le code illisible et impossible à maintenir pour un gain qui au final est minimime par rapport à ce que le compilateur produit.
        
        C'est prévu.
        
        Pour ce qui est de l'inniling du message en dessous, il est déjà configurer mais je ne sais plus à combien, je n'ai pas le makefile sous les yeux mais je pourrais vérifié. La taille du code ayant peu d'importance ici, l'essentiel est de trouver le bon compromis avec la taille du cache. J'avais fait pas mal d'essais pour voir à quel point on pouvais inliner sans que les caches miss fassent perdre plus qu'on ne gagne. Le problème c'est que tout les petits reglages dans ce genre on été faits pour la version en C et ne sont surement pas adapters à la version en Lisaac.
        
        Tu parles du cache code ou du cache données ?
        En ce qui concerne le cache code, il faut effectivement faire attention à ne pas trop inliner.
        En ce qui concerne le cache données, Lisaac gère tant que possible la mémoire en se basant sur des lignes de cache à 64 octets, mais c'est encore très perfectible.
        
        Ya aussi une grosse optim qui est prévu et qui fera gagner beaucoup, c'est de sortir les variables.
        
        Dans le C généré par lisaac, tu as souvent :
        while( cond) {
        ((int *)struct1->struct2->struct3)[index ] = ...
        ...
        }
        Le pb c'est que gcc recalcul le pointeur à chaque fois ds la boucle, faut donc créer une variable locale (ou mieux utilser une existante) qui va le faire avant le début du while, et éviter ça.
        
        Benoit évalue cette optim à deux semaine de travail.
        J'ai fait cette optim à la main sur du code critique en calcul, j'ai gagné 15%
        
        Et je te parle pas de la futur autovectorisation de GCC, de mélanger flottant et entier, etc...
        
        Ya encore énormément de chose à faire en optim, on est qu'au tout début.
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
      - [^] # Re: sonntag
        
        Posté par crumpet le 25 septembre 2007 à 17:59. Évalué à 2.
        
        Jai fait aussi quelques essais avec Lisaac.
        
        Je rajouterais juste que la commande de compilation de gcc est ecrite en dur dans le fichier path.li. Si on veut ajouter on enlever une bibliotheque, on doit regenerer le generateur de code (lisaac). C'est bof bof.
        
        Peut-on utiliser un debogueur pas-a-pas sur le code source (le .li) ? Est-ce-que cette fonctionnalité est prévue dans le futur ?
        
        A propos du code généré, c'est bourré de variables globales. Tot ou tard il va y avoir des collisions.
        
        Je sais que ca fait un peu "je chipote" mais ce sont des problemes qui finiront par ressurgir, surtout si, comme je vous le souhaite, votre projet prend de l'ampleur.
        
        [^] # Re: sonntag
        
        Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 18:22. Évalué à 2.
        
        Je rajouterais juste que la commande de compilation de gcc est ecrite en dur dans le fichier path.li. Si on veut ajouter on enlever une bibliotheque, on doit regenerer le generateur de code (lisaac). C'est bof bof.
        
        C'est vrai que j'avais pris l'habitude d'écrire la phase de compilation de gcc à la main, en compilant directement le fichier généré.
        
        Peut-on utiliser un debogueur pas-a-pas sur le code source (le .li) ?
        
        pas encore.
        
        Est-ce-que cette fonctionnalité est prévue dans le futur ?
        
        oui.
        
        A propos du code généré, c'est bourré de variables globales. Tot ou tard il va y avoir des collisions.
        
        Vu qu'il n'y a pas encore de notion de lib, cela ne peut pas arriver.
        
        Je sais que ca fait un peu "je chipote" mais ce sont des problemes qui finiront par ressurgir, surtout si, comme je vous le souhaite, votre projet prend de l'ampleur.
        
        On est tout ouï. :)
        "La première sécurité est la liberté"
        
        [^] # Re: sonntag
        
        Posté par crumpet le 25 septembre 2007 à 18:51. Évalué à 2.
        
        Vu qu'il n'y a pas encore de notion de lib, cela ne peut pas arriver.
        
        Si je peux me permettre, au lieu de creer directement l'executable qui contient a la fois le code du programme et le code de la bibliotheque lissac (garbage collector, etc.), vous pourriez separer en deux parties: d'un coté la bibliotheque lisaac, d'un autre coté la bibliotheque du programme, avec des points d'entrées bien definis.
        
        Vous pourriez ainsi developper des bibliotheques entierement en Lisaac. Avec une petite interface (.h), ces bibliotheques pourraient etre utilisees a la place de bibliotheques existantes ecrites en C.
        
        [^] # Re: sonntag
        
        Posté par tarlack le 25 septembre 2007 à 18:56. Évalué à 2.
        
        le probleme ici c'est la compilation séparée. En effet, Lisaac fait de l'optimisation globale. En gros, la lib est recompilée et reoptimisée pour repondre aux besoins specifiques de chaque prog. Notamment, une methode dans un code lisaac peut en generer plusieurs, en fonction des types possibles qui peuvent arriver lors de l'appel par le programme principal par exemple. Il n'y a pas de correspondance 1:1 entre une methode lisaac et une methode correspondante dans le C généré. En plus avec l'inlining il n'est meme pas dit que tu aies une fonction C pour ta fonction de la lib lisaac.
        
        [^] # Re: sonntag
        
        Posté par Mildred (site web personnel) le 27 septembre 2007 à 18:20. Évalué à 1.
        
        C'est techniquement possible de créer une méthode Lisaac et de l'appeler en C (par contre tu n'aura pas de contexte Self). Mais ce n'est pas du tout intuitif. En gros il faut jouer avec la Section External et on y arrive.
        
        [^] # Re: sonntag
        
        Posté par Mildred (site web personnel) le 27 septembre 2007 à 18:20. Évalué à 1.
        
        Path.li contrairement a ce que son nom indique n'est pas un fichier source Lisaac. Il est interprété à chaque fois.
        Donc pas besoin de recompiler le compilateur :)
        
        Mais un nouveau système pour la compilation est en route...
  - [^] # Re: sonntag
    
    Posté par Ontologia (site web personnel) le 25 septembre 2007 à 15:41. Évalué à 2.
    
    Et j'oubliais aussi...
    
    Il faut que tu joue avec le switch i du compilateur. Il règle le niveau d'inlining. Par défaut, il est à 20 il me semble. 0 permet d'avoir un code assez petit, 30 ou 40 est en général ce qu'on trouve de mieux pour les perfs.
    
    Résumé, pour les perfs compile avec :
    lisaac monfichier.li -i30 -O
    
    Normalement, tu devrais grapiller quelques %
    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
- [^] # Re: sonntag
  
  Posté par TImaniac (site web personnel) le 25 septembre 2007 à 18:18. Évalué à 2.
  
  Pour finir, je dirai que Lisaac est un petit langage moderne qui est dédié à des programmeurs qui aiment le bas niveau, le C ou ASM.
  Travaillons ensemble vers autre chose que C# et Java...
  Tu proposes quoi pour replacer Java/C# ? Non parcque Lissac ne semble pas pour toi un bon candidat (remplace plutôt ce qui se faisait habituellement en C ou ASM).
  Que reproches-tu à C# ou Java dans leurs utilisations classiques (IHM/SI/SOA/Web etc.) et que proposes-tu à la place ?
  - [^] # Re: sonntag
    
    Posté par Tramo Piere le 26 septembre 2007 à 10:26. Évalué à 3.
    
    C'est sur que lorsque l'on ne connait que java ou c# on a du mal à voir les problèmes.
    
    Voici quelques exemples: absence de contrats, de closures, aspects dynamiques limités (ou bien il faut des extensions comme Groovy), complexité de la grammaire (et donc lenteur de la compilation), pas de curryfication, pas de tail recursion, ..
    
    Pour l'utilisation classique des SOA/IHM/Web, la quantité de design patterns et l'apparition de tant de différents languages (Groovy, Jython, ..), et de frameworks (Junit, Aspectj, Hibernate, ..) montrent tout à fait la faiblesse des briques de base qui sont incapables d'évoluer.
    
    Comme les architectes et programmeurs sont très paresseux, la tendance est d'ajouter des couches d'abstraction. Un exemple sur les Makefiles : au lieu d'améliorer Make (qui n'a pas évolué depuis le début), on fait des générateurs de makefiles, plutôt que de penser globalement on appelle Make récursivement (et pour les performances on n'a qu'à changer le hardware).
    - [^] # Re: sonntag
      
      Posté par el_mickey le 26 septembre 2007 à 11:02. Évalué à 3.
      
      Pour l'absence de closures si on suit la définition wikipédia (Ouai je l'ai vu aussi à la fac mais j'ai toujours fait un blocage sur ce concept :), ça donne : "Une fermeture est donc créée lorsqu'une fonction est définie dans le corps d'une autre fonction et fait référence à des variables locales ou des arguments de la fonction dans laquelle elle est définie."
      
      Bah pour moi, ça ressemble trés fortement à un delegate en C# quand même. Bon aprés ton argument est surement vrai pour java.
      - [^] # Re: sonntag
        
        Posté par Mildred (site web personnel) le 27 septembre 2007 à 18:25. Évalué à 1.
        
        Si je me souviens de ce que je faisai en java, on peut faire des closures. Mais par contre la syntaxe est lourde ...
        void main(){ int mavariable; toto.tata(new Runnable(){ void run(){ ... } }) }
        Bon, c'est pas une vraie closure, mais ca peut jouer le même rôle. Je crois que ça répond aussi un pau à la question d'Ontologia juste en dessous
    - [^] # Re: sonntag
      
      Posté par Ontologia (site web personnel) le 26 septembre 2007 à 11:02. Évalué à 2.
      
      J'ajouterai surtout l'absence de type BLOCK.
      
      Je souffre énormément en Java à cause de l'inexistance de BLOCK.
      
      En effet, avec ce type (qui est une fonction en fait), et la syntaxe à mot clé , on peut inventer les structures de controle qu'on veut.
      
      Ainsi dans la lib standard, j'ai rajouté différents foreach :
      
      foreach_while : Parcours tous les éléments et continu tant que la condition sur l'élément est vrai. ça évite de faire une construction hyper lourde à la java, avec un while, un tmp, un cast, et tout le toutim
      
      foreach_until : même idée, avec le until
      
      Ma préférée est le
      - to up: INTEGER do action:BLOCK items function:BLOCK <-
      Qui se trouvera dans numeric.
      
      Bref, les langages qui m'impose de subir les desiderata des concepteurs pour les structures de contrôle, ça m'emmerde.
      Il est vrai que parvenir à modifier la lib standard n'est pas anodin (il faut que l'idée soit bonne, la tester sous toutes les coutures, que Benoit Sonntag soit d'accord), mais au moins c'est possible de le faire.
      
      Dans cette étude http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf , il est expliqué que beaucoup de problèmes (bugs, etc...) proviennent de parcours d'index dans des tableaux et de compréhension d'ensemble.
      C'est une fonction dans laquelle tu défini une fonction de parcours d'ensemble.
      
      1. to n do { i : INTEGER;
      // code
      } items { j : INTEGER;
      2*j+1
      };
      
      je rajoute cela à ce qu'a pointé Tramo Piere, et effectivement, Java est un vieux langage dépassé. Et comme disais je ne sais plus qui, ici même
      "Java : une syntaxe bas niveau avec les inconvéniants du haut niveau"
      C# même combat.
      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
      - [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 11:59. Évalué à 1.
        
        foreach_while
        Bof, en C# 3 je peux faire ca :
        maliste.foreach_while(elem => elem.Foo() , elem => elem.truc == 0);
        qui applique la Foo à tous les éléments de ma liste tant que la propriété truc vaut 0.
        
        [^] # Re: sonntag
        
        Posté par tarlack le 26 septembre 2007 à 12:48. Évalué à 1.
        
        OUi, obligé de faire une fonction pour ca, c'est vachement lisible dis moi ! on voit vachement le coté prediqué de la chose...à la relecture je doute que tout le monde comprenne ce que ca fait, comparé à un :
        
        mon_arbre.for_all { i : ITEM;
        //code
        };
        
        il y en a une que je comprend tout de suite (parce que la notation ressemble à ce qu'on trouve dans beaucoup de langage), l'autre non (on me donne à froid ton code je ne sais pas ce que ca fait).
        
        Les 2 approches sont valables, mais une est definitivement limitée à un domaine, plus ou moins vaste certes, mais limité, contrairement à l'autre.
        
        [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 13:29. Évalué à 1.
        
        ?? C'est quoi la différence entre ta syntaxe et la mienne au niveau lisibilité, alors attend je résumes :
        
        Lisaac :
        
        mon_arbre.for_all { i : ITEM;
        //code
        };
        
        C# :
        
        mon_arbre.Foreach(delegate(ITEM i)
        {
        //code
        });
        
        ou (toujours C#) :
        mon_arbre.Foreach(i =>
        {
        //mon code
        });
        
        [^] # Re: sonntag
        
        Posté par tarlack le 26 septembre 2007 à 13:38. Évalué à 1.
        
        quand on résume on est pas sensé prendre les elements à dispo une fois que tout le monde a parlé ?
        donc si je resume, on avait une syntaxe du genre :
        
        C#
        maliste.foreach_while(elem => elem.Foo() , elem => elem.truc == 0);
        
        et
        
        Lisaac
        mon_arbre.for_all { i : ITEM;
        //code
        };
        
        je ne connais pas C#, mais rien que de voir que y a 15 manieres d'exprimer la meme chose prévues par la grammaire en elle-meme je me dis que niveau redondance c'est pas mal...ou alors y a de fines nuances sur le comportement...
        Et si on veut avoir des conditions (comme pour le foreach_while ou autre), qu'on veut 3 blocs en parametres, etc, on fait comment ? moi c'est résumé, il n'y a qu'une seule maniere, elle est claire et non ambigue.
        Dans ton exemple,
        
        mon_arbre.Foreach(i =>
        {
        //mon code
        });
        
        le i, tu le declares avant ? meme question pour le elem de ton 1er extrait de code que j'ai remis dans ce commentaire...Non parce que ne connaissant pas C# ca me laisse confus...
        
        [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 13:58. Évalué à 1.
        
        donc si je resume, on avait une syntaxe du genre :
        Oué mais nan, j'étais parti sur un foreach_while qui supposait qu'on avait 2 blocks d'instructions en paramètres. Tu es revenus à un foreach "classique", d'où mes nouveaux exemples.
        
        ou alors y a de fines nuances sur le comportement...
        Y'a juste des évolutions : C# 1 : pointeurs de méthodes, C# 2 : méthodes anonymes (plus besoin de déclarer une méthode séparée que l'on référence), C# 3 : expression lambda.
        Alors oui, dans C# 3 tu peux toujours faire comme en C# 2 ou C# 1.
        
        qu'on veut 3 blocs en parametres, etc, on fait comment ?
        Bah pareil ! C'est quoi le problème ? Mon premier exemple prenait 2 blocs, chacun était dans mon exemple une lambda expression séparé par une virgule (dur dur). Je te laisse deviner comment ajouter un 3ème paramètre ;)
        
        le i, tu le declares avant ?
        Bah nan, c'est une lambda expression, le i est justement ici sa déclaration. Son type est défini par inférence à partir du type de la méthode Foreach.
        C'est justement parcque tu ne comprends pas cette écritureque j'avais commencé par la syntaxe C# 2 ;) Mais certains trouvent plus joli, plus concis et plus propre la 3ème.
        
        Enfin tout ca pour dire que je ne vois absolument pas la différence, au final je peux déclarer une méthode qui prends plusieurs paramètres, chaque paramètre peut être un bloc de code, que tu l'écrives sous la forme d'une fonction anonyme ou sous la forme d'une lambda expression.
        
        [^] # Re: sonntag
        
        Posté par tarlack le 26 septembre 2007 à 16:06. Évalué à 1.
        
        certes, mais definir la semantique de chaque bloc tu ne peux pas. resultat, à la fin tu te demandes ce que vas faire chaque fonction...c'est un probleme plus general cela dit, et qui font que Lisaac, avec les mots clés, permet d'avoir ce genre de constructions complexes. un exemple bete qui fera que tu auras des problemes avec C# :
        
        1 : mon_arbre.foreach_while {...} do {...} finally {...};
        2 : mon_arbre.foreach_while {...} do {...} at_beginning {...};
        
        bon ce sont des exemples un peu à la con, mais ca montre bien le probleme.
        
        De plus, et là il y a une difference enorme, c'est que tu ne peux pas "manipuler" ton bloc. Comment fais-tu des structures du genre
        
        bloc.f1 {//code}.f {....} etc ?
        typiquement, le if ... elseif ...elseif est codé comme cela en lisaac, elseif etant une mthode codée dans BLOCK. Tu ne peux pas appeler de membres sur ta fonction lambda, donc les structures "à plusieurs étages" ne sont pas faisables. BLOCK est bien plus general que les declarations lambda.
        
        [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 16:30. Évalué à 1.
        
        mais definir la semantique de chaque bloc tu ne peux pas.
        Mouaich, ca peut très bien être explicite dans le nom de la méthode, dans la doc (et donc l'auto-complétion) :
        mon_arbre.foreach_while_do_finally(while, do, finally);
        Après effectivement c'est moins puissant que les block notamment dans les exemples que tu donnes.
        Tu peux toujours contourner le problème en prenant en paramètre une interface imposant de passer par exemple un objet contenant 3 "fonctions", chacune correspondant à un bloc.
        Ca serait un peu plus lourd syntaxiquement, mais tu gardes les mêmes possibilités.
        Après je te dirais franchement que je n'aime pas du tout les exemples sur lesquels on travail, j'ai peur que les développeur face trop mumuse avec pour avoir leur petites libs de boucles à eux, qu'eux seuls comprennent (avec tous les bugs qui vont avec).
        Un peu comme en C++ ou tu peux faire tout et n'importe quoi avec les templates et les macros (certains se sont amusés à reproduire la syntaxe de Lisp) : ca peut devenir imbitable pour un intérêt très limité.
        
        [^] # Re: sonntag
        
        Posté par tarlack le 26 septembre 2007 à 18:39. Évalué à 2.
        
        ouais mais après, comme tu le dis, c'est toujours la meme chose quelque soit le langage, à plus ou moins haut niveau. Mais bon, un developpeur c'est aussi faineant, et reinventer la roue c'est moyen niveau faineantise :-)
        Donc il faut voir ce qui va être fait, et surtout garder un oeil dessus, pour eviter ce genre d'écueils ;)
      - [^] # Re: sonntag
        
        Posté par Mildred (site web personnel) le 27 septembre 2007 à 18:26. Évalué à 1.
        
        Sans compter que tu peux hériter à la main d'un prototype qui définira tes structures de contrôle particulières ...
    - [^] # Re: sonntag
      
      Posté par TImaniac (site web personnel) le 26 septembre 2007 à 11:12. Évalué à 0.
      
      dynamiques limités
      Ca évolue, regarde le Dynamic Language Runtime que vient de sortir MS, il s'appui intégralement sur les briques de base existante.
      
      complexité de la grammaire (et donc lenteur de la compilation)
      Mouaich. Suffisament rapide pour être compilé en temps réel par les IDE. Je ne suis pas sûr que des langages comme Lisaac qui visent une grande quantité d'optimisations à la compilation améliore la chose. Enfin je ne vois pas en quoi Java & co ont 30 ans de retard là dessus.
      
      pas de curryfication, pas de tail recursion, ..
      Et ca fait de Java et C# des langages qui n'auraient jamais dû exister ?
      Faut aussi bien voir que ces langages évoluent : généricité, lambda expression, langages de requête, etc.
      
      montrent tout à fait la faiblesse des briques de base qui sont incapables d'évoluer.
      Ou sont suffisament générique et d'assez haut niveau pour supporter un vaste éco-système.
      Ces frameworks ne pourraient pas exister sans une base technique qui le permet (bytecode pour les tisseurs, introspection pour les tests U, etc.)
      
      Même si beaucoup de tes critiques sont pertinentes, il n'y a pas à l'heure actuelle d'alternative pour leurs segments d'utilisation. Tous les autres langages ont leurs défauts propres qui ne leur permet pas de remplacer Java ou C# pour de nombreuses utilisations.
      Alors dire que ces langages ne devraient pas exister, cela suppose qu'on est au moins le bon goût de proposer une alternative. Benoît Sonntag le dit lui même, Lissac n'en ai pas une.
      - [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 26 septembre 2007 à 11:39. Évalué à 3.
        
        Il y a des langages qui sont innovants, performants et bien plus satisfaisants du point de vue de l'informaticien, mais qui ne se sont pas imposés simplement parce qu'ils n'avaient pas le soutien d'une grosse boîte comme Sun ou MS. Le langage Java est encore en retard sur Eiffel, qui existait pourtant bien avant.
        
        Parler de remplacer Java ou C# implique bien plus que discuter les qualités du langage. Le langage Java n'a pas été conçu pour être un langage innovant, il a été conçu comme une sorte de C++ un peu plus propre adapté à la plateforme Java. Sa force n'a jamais été le langage, mais la plateforme et les bibliothèques. Pour n'importe quel projet je préfèrerais coder en Eiffel, mais pour n'importe quel projet je préfère le framework de Java.
        
        En fait le problème avec le langage Java, c'est que tous ses choix sont des compromis décevants. C'est un langage qui se veut de haut niveau mais il reprend la syntaxe lourde du C++. Il se veut un langage orienté objet mais n'en reprend que le minimum vital. Grace à sa VM il est assez dynamique mais ne propose rien dans sa syntaxe pour en profiter. Forcément si on le compare au C++ c'est un petit progrès, mais si on le compare à d'autres langages c'est frustrant. Si seulement Sun avait copié Eiffel au lieu de copier C++...
        
        [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 13:40. Évalué à 1.
        
        En fait le problème avec le langage Java, c'est que tous ses choix sont des compromis décevants.
        Décevant ? Je comprends ta frustration mais moi je vois les choses différement : en réutilisant la syntaxe du C++, elle facilite la vie de millions de développeurs, en limitant volontairement les aspects objets, elle simplifie la compréhension du code pour un développeur "moyen", etc.
        Ces langages sont une suite logique d'évolutions, et c'est cet "héritage" du passé qui font qu'ils sont utilisables et utilisés.
        A quoi sert un langage si personne ne le comprend ?
        A quoi sert un langage si seul les chercheurs sont capables d'en appréhender les concepts (soit de trop haut niveau, soit top différent des concepts existants) ?
        
        Bref, la beauté du langage ne fait toutes les qualités requises pour un langage "ready" pour un large public de développeur.
        
        [^] # Re: sonntag
        
        Posté par tarlack le 26 septembre 2007 à 13:50. Évalué à 1.
        
        je suis d'accord avec toi, sauf que ca ca s'applique aussi à la transition imperatif/Objet (ou Cobol/Java ca marche aussi)...pourtant le pas a été fait, c'est donc bien que ca fournissait un atout. Tout le problème c'est que pour voir les avantages que ca apporte il faut accepter d'y consacrer un peu de temps...(par exemple le passage à J2EE, qui dans le genre pas facile à prendre en main est pas mal, meme si ca amene ensuite pas mal de confort pour certains types d'applis)
        
        [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 14:07. Évalué à 0.
        
        sauf que ca ca s'applique aussi à la transition imperatif/Objet
        Pas convaincu. Il n'y a pas pour moi d'opposition entre impératif et objet. L'objet est plus une façon de programmer, de représenter les données : tu peux très bien appliquer le concept en C. Cette méthode (objet) est tellement naturelle (chercher à encapsuler, factoriser) qu'elle conduit à introduire dans la syntaxe des langages impératifs des constructions dédiées. Mais c'est une évolution, pas un "saut".
        Tu peux toujours faire de l'impératif en Java comme tu peux faire de l'objet en C. C'est pas forcement les bons outil pour la bonne utilisation, mais c'est tout à fait possible.
        
        Tout le problème c'est que pour voir les avantages que ca apporte il faut accepter d'y consacrer un peu de temps...
        Certes, mais pour cela faut voir la transition : pourrais-je toujours programmer comme avant ? Pourrais-je utiliser ma syntaxe favorite (argument .NET) ? Pourrai-je faire la même chose qu'avant ? (framework complet) Existe-t-il un IDE où je puisse être productif ? Est-ce compatible avec l'existant ? Existe-t-il un support (forum, doc, etc.) ?
        Beaucoup trop de langages "universitaires" se focalise sur le langage en lui même. J'ai envie de dire que le langage en soit est presque accessoire si on oublie le reste.
        
        [^] # Re: sonntag
        
        Posté par tarlack le 26 septembre 2007 à 16:09. Évalué à 2.
        
        certes, pour les IDE on y travaille, mais c'est un boulot enorme. J'ai fait un plugin pour KDevelop avec auto-completion intelligente etc, mais ca représente des mois de boulot (en tout cas quand on est accessoirement etudiant). Donc c'est bien de dire "oh y a rien je regarde pas, il vous manque ca ca et ca", mais c'est bien aussi de mettre la main à la patte. C'est là qu'interviennent les communautés non ? ;-)
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 26 septembre 2007 à 17:00. Évalué à 2.
        
        Beaucoup trop de langages "universitaires" se focalise sur le langage
        
        C'est pas très étonnant. Je ne serais pas non plus surpris d'apprendre que les frameworks universitaires (si ça existe) se focalisent sur les frameworks.
        
        Je suis d'accord qu'un langage sans framework n'est pas très utile en pratique, mais comment reprocher à des gens qui font de la recherche sur les langages de s'intéresser au langage en lui même ? Évidemment que quand ils comparent C# et le leur, ils parlent du langage et pas du framework.
        
        C'est d'autant plus vrai que le framework est assez indépendant du langage, et toi qui est fan de .NET tu ne diras pas le contraire. Si tout d'un coup Lisaac se mettait à cibler la plateforme .NET, ça ne le rendrait pas meilleur ou moins bon langage, mais ça résoudrait son problème de framework.
        
        J'ai envie de dire que le langage en soit est presque accessoire
        
        Tu risques d'être souvent déçu par les news sur des langages en cours d'élaboration alors, car tu n'y trouveras jamais un framework à la hauteur de celui de Java.
        
        [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 17:16. Évalué à 1.
        
        C'est d'autant plus vrai que le framework est assez indépendant du langage, et toi qui est fan de .NET tu ne diras pas le contraire.
        Le framework est indépendant du langage, certes, mais l'inverse n'est pas forcement vrai. Le langage peut s'appuyer sur les fonctionnalités du framework sous-jacent.
        Je m'auto-cite (plus bas) :
        "le langage peut supposer la présence d'un garbage collector avec un fonctionnement bien précis, le langage peut supposer la présence de certains types de base, le langage peut supposer la présence d'un framework de sécurité sous-jacent, de possibilité d'introspection, etc."
        
        mais ça résoudrait son problème de framework
        Il aurait du mal à s'adapter : le framework .NET suppose de respecter un certain nombre de paradigmes "conventionnels" : types de base, objet, sécurité, etc. Sans parler des problèmes liés à l'interopérabilité : impossibilité d'exporter un "BLOCK" et autres joyeusetés. Certains algos d'optimisations qui font la fierté de Lisaac (à raison) ne seraient probablement plus utilisables.
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 26 septembre 2007 à 13:52. Évalué à 5.
        
        Il n'y a pas de raison pour qu'un langage dont la syntaxe ne reprend pas celle du C++ soit incompréhensible. Ruby l'a largement prouvé.
      - [^] # Re: sonntag
        
        Posté par Tramo Piere le 26 septembre 2007 à 11:43. Évalué à 3.
        
        > Même si beaucoup de tes critiques sont pertinentes, il n'y a pas à l'heure actuelle d'alternative pour leurs segments d'utilisation. Tous les autres langages ont leurs défauts propres qui ne leur permet pas de remplacer Java ou C# pour de nombreuses utilisations.
        
        Bon, un exemple concret: Lisp:
        SQL est un dérivé de Lisp. Javascript est très similaire à Lisp. Les css peuvent se représenter efficacement en Lisp. Le modèle DOM (html, xhtml) peut se représenter très bien aussi en Lisp (remplacer les tags par des parenthèses, l'arbre reste le même). Et après tout ce temps (faisait déjà tout ça il y a 40 ans) ni java ni c# n'ont toutes les fonctionnalités de Lisp, ni les performances.
        
        Pourquoi Lisp n'a pas percé ? On peut lui reprocher sa syntaxe (Lissac partage ce problème), l'absence de grandes entreprises derrière (sans Sun, Java serait resté oak, sans Microsoft, pas de C# et sans miguel, à boire), et surtout l'ignorance des programmeurs qui restent dans leur caverne.
        
        [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 13:51. Évalué à 0.
        
        On peut lui reprocher sa syntaxe
        C'est un gros défaut, c'est vraiment illisible, on passe son temps à compter les parenthèses.
        Moi je vois surtout qu'il manque un framework. Un vrai bon gros framework uniformisé et qui reprend la plupart des outils nécessaire pour réaliser une grande variété d'application.
        C'est le gros point commun entre Java et C# : c'est le framework.
        
        surtout l'ignorance des programmeurs qui restent dans leur caverne.
        Pas convaincu, on est beaucoup à être passé à un moment par le Lisp et autre OCaml. C'est gentil mais sans framework ca sert à rien.
        Même dans le langage : des besoins "industriels" comme le versionning des types, l'introspection (plugins, automatisation, etc.), voir même la facilité d'inter-actions dans un IDE, tout ca nécessitent un langage qui a été un minimum pensé dans ce sens.
        Lisp c'est joli pour les mathématiciens, mais ca sert pas à grand chose pour un informaticien (qui ne fait pas des algos mathématiques la plupart du temps).
        
        [^] # Re: sonntag
        
        Posté par Tramo Piere le 26 septembre 2007 à 14:08. Évalué à 2.
        
        > Lisp c'est joli pour les mathématiciens, mais ca sert pas à grand chose pour un informaticien
        Ben justement si:
        * inférence des types
        * programmation par contrats (assert est insuffisant)
        * aide au déboggage (aop)
        Des concepts qui existent depuis bien longtemps.
        
        Il n'y a effectivement pas que les maths, il y a aussi l'histoire de l'informatique. Et c'est bien de connaître un outil, mais c'est beaucoup mieux d'en connaître les limites.
        
        Quand tu parles de framework, tu t'éloignes du language pour en venir aux bibliothèques. Mais on peut aussi en revenir au pourquoi du framework : le language ne permet pas d'encapsuler les requêtes sql correctement, ou de permettre une implémentation mvc simple et modulaire. Et comme il s'agit de languages bien statiques, on finit par se retrouver avec plus de fichiers xml (que pas mal critiquent pour la lisibilité) que de code (java, c#). Autant pour la lisibilité de Lisp.
        
        Enfin, J2EE, .Net réinventent la roue (Squeak, Delphi), en moins bien et surtout en beaucoup plus lent et volumineux.
        
        [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 14:31. Évalué à 1.
        
        Ben justement si:
        Toutafé, y'a pleins de choses bien, mais les inconvénients sont trop bloquant pour qu'ils soient utiles. C'est comme Lisaac aujourd'hui : pas de modularité binaire == utilisation anecdotique (pour moi).
        
        le language ne permet pas d'encapsuler les requêtes sql correctement,
        C# 3 :
        var res = from s in auteurs
        where s.Length == 5
        orderby s
        select s.ToUpper();
        
        Quand tu parles de framework, tu t'éloignes du language pour en venir aux bibliothèques.
        Pas totalement, quand je parle framework je parle aussi machine virtuelle (bytecode, JIT, GC, securité, etc.) : le langage expose plus ou moins de possibilité en fonction de la machine "cible". C'est fortement lié.
        
        Enfin, J2EE, .Net réinventent la roue (Squeak, Delphi), en moins bien et surtout en beaucoup plus lent et volumineux.
        Il est où le serveur d'application en Squeak ou Delphi ? Elle
        C'est le même type qui a fait C# et qui a fait Delphi dans le passé, je vois mal comment il aurait pu faire "moins bien". D'ailleur .NET est tellement moins bien que Delphi que Delphi cible maintenant .NET comme plateforme "cible" (entre autre), ce qui démontre au passage tout l'intérêt d'avoir une VM intermédiaire standardisée.
        
        [^] # Re: sonntag
        
        Posté par Tramo Piere le 26 septembre 2007 à 16:18. Évalué à 1.
        
        > C# 3 :
        
        C'est bien, ça s'améliore. Dommage que mono soit encore loin derrière :-)
        
        > le langage expose plus ou moins de possibilité en fonction de la machine "cible". C'est fortement lié.
        
        On peut compiler du caml ou du F# en .Net
        Implémentation != language
        
        > Il est où le serveur d'application en Squeak ou Delphi
        
        Nulle part, Delphi est mort (les devs sont partis), et Squeak est un framework orienté ihm (il est où le framework IHM en .Net ?).
        
        Mais pour ce qui est de la consommation de ressources et la fluidité .Net a encore du chemin avant de rattraper le vieux Delphi.
        
        [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 16:57. Évalué à 1.
        
        C'est bien, ça s'améliore. Dommage que mono soit encore loin derrière :-)
        Loin derrière ? Mono compile presque toutes les nouveautés, Mono devrait supporter intégralement C# 3 au moment de la sortie officielle de Visual Studio 2008 (le produit commercial rattaché au lancement officiel de C# 3) pour janvier, ils n'auront jamais été aussi synchro.
        
        On peut compiler du caml ou du F# en .Net. Implémentation != language
        Bien sûr, mais les exemples de langages que tu proposes sont des langages de "haut niveau" qui respect les paradigmes objets de base, ce qui est le point commun requis par la VM de .NET.
        Et il y a parfois des corrélations fortes : le langage peut supposer la présence d'un garbage collector avec un fonctionnement bien précis, le langage peut supposer la présence de certains types de base, le langage peut supposer la présence d'un framework de sécurité sous-jacent, de possibilité d'introspection, etc.
        
        il est où le framework IHM en .Net ?
        Il est là : http://www.microsoft.com/downloads/details.aspx?familyid=7B9(...)
        et là :
        http://www.microsoft.com/downloads/details.aspx?familyid=2B6(...)
        C'est pas en standard dans le framework, mais c'est sans doute pas plus mal, tout le monde n'est pas d'accord sur le pattern le plus adapté et encore moins sur la façon de l'implémenter.
        Pour les IHM web tu as par contre un framework complet et de nombreux frameworks annexes.
        
        Mais pour ce qui est de la consommation de ressources et la fluidité .Net a encore du chemin avant de rattraper le vieux Delphi.
        .NET ajoute une couche d'abstraction (VM) et des services associés qui ont effectivement un coût. Mais Delphi ne proposait pas tous ces services, c'est donc difficilement comparable.
        
        [^] # Re: sonntag
        
        Posté par Nicolas Boulay (site web personnel) le 26 septembre 2007 à 17:03. Évalué à 0.
        
        Mais Delphi ne proposait pas tous ces services, c'est donc difficilement comparable.
        
        Bah si. Quand tu veux un truc simple, c'est plus lent que le "vieux truc"', à cause de fonctionnalité dont tu n'as pas besoin.
        "La première sécurité est la liberté"
        
        [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 17:22. Évalué à 1.
        
        à cause de fonctionnalité dont tu n'as pas besoin.
        
        bah utilises les bons outils en fonction de tes besoins ;)
        
        [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 26 septembre 2007 à 14:27. Évalué à 2.
        
        Qu'est-ce qui te semble absolument indispensable comme Framework ?
        Car lorsque je regarde Java (std) je trouve
        
        (les question signifie que je ne sais pas, pas que je critique)
        
        - une lib pour faire des interfaces utilisateur (1)
        - de quoi gérer des fichiers, des flux, de la sérialisation d'objet par ce biais... (1)
        - Reflexivité (2)
        - threading (3)
        - réseau (4)
        - RMI (2)
        - Securité (5)
        - SQL (5) mais ça devrait pas être méchant. Surtout que ce sera surement intégré ds le langage.
        - text (5) ah oui c'est pas con, faudrai le faire ça. On a toutes les briques de base en +
        - Collection, on a
        - libZIP, à coder
        - accessibility ( c'est quoi ?)
        - activity ( c'est quoi ?)
        - imageio, ya un début avec BITMAP, etc...
        - javax.management (sert à quoi ?)
        - Xml (4) et je vais personnellement l'améliorer pour en faire une lib de rêve, car je connais très bien le sujet...
        
        (1) On l'a, elle est pas aussi complète, mais elle va grossir
        (2) C'est prévu (1 an ou 2)
        (3) Pas besoin on a le modèle COP
        (4) La lib Eiffel va nous l'apporter
        (5) là effectivement, on a rien
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: sonntag
        
        Posté par TImaniac (site web personnel) le 26 septembre 2007 à 14:42. Évalué à 3.
        
        C'est un tout petit sous-ensemble que tu as pris là.
        Java ou .NET inclu beaucoup plus que ca, ce que tu me décris là c'est Java il y a 5 ou 10 ans.
        
        Moi je veux un serveur d'application, je veux un framework web, je veux un framework web-services, je veux un framework d'IHM vectorisé, je veux un framework de workflow, je veux un framework 3D, je veux un framework audio/video, je veux un framework pour l'embarqué, je veux un framework pour client web, je veux des API de sécurité, je veux des API de gestion de plugins, je veux des API pour les schema W3C, pour XSLT, un framework pour composants transactionnels, des API de cryptographie, j'en oublie sûrement plein.
        Et je veux surtout que le tout soit unifié, pas un assemblage de trucs disparate qui vienne de différentes sources, chacune avec ses concepts pas toujours compatibles entre eux me forcant à m'adapter en permanence sans profiter de mon acquis.
        Enfin tout ce qui fait la force de Java ou .NET quoi.
        
        [^] # Re: sonntag
        
        Posté par TeXitoi (site web personnel) le 26 septembre 2007 à 14:57. Évalué à 7.
        
        Foutaises !
        
        [^] # Re: sonntag
        
        Posté par Bozo_le_clown le 26 septembre 2007 à 15:24. Évalué à 3.
        
        moi j'ai la case "curryfication", "closures", "objet à prototypes", "tail recursion", "block", "modularité de l'architecture logicielle" "optimisation globale" ...et toi ?
        
        [^] # Re: sonntag
        
        Posté par el_mickey le 26 septembre 2007 à 15:29. Évalué à 1.
        
        Ouai mais c'est pas pareil, les tiens c'est pour un "research loto", l'autre il joue au "business loto".
        
        [^] # Re: sonntag
        
        Posté par Bozo_le_clown le 26 septembre 2007 à 15:32. Évalué à 2.
        
        Ah on joue avec des grilles différentes.
        
        Faut pas s'etonner qu'on arrive jamais à s'échanger quoi ce soit.
        
        [^] # Re: sonntag
        
        Posté par TeXitoi (site web personnel) le 26 septembre 2007 à 15:46. Évalué à 2.
        
        En effet, moi, j'avais « framework web », « framework web-services », « framework d'IHM vectorisé » (sympa, celui-là), « framework de workflow » (le meilleur), et « un framework pour composants transactionnels ».
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 26 septembre 2007 à 15:50. Évalué à 3.
        
        Il ne manque qu'un framework pour fabriquer des frameworks et la boucle est bouclée
        
        [^] # Re: sonntag
        
        Posté par Mildred (site web personnel) le 27 septembre 2007 à 18:46. Évalué à 1.
        
        Pas pour critiquer, mais la bibliothèque pour faire une interface utilisateur en Lisaac, c'est ... pas encore ça (j'ai juste regardé les démos).
        
        Moi j'attend d'avoir un truc qui puisse s'intégrer a mon desktop sans trop de domages, du genre Gtk ou QT (même si je préfère Gtk qui n'est malhereusement pas encore compatible Mac OS X)
        
        [^] # Re: sonntag
        
        Posté par Gniarf le 27 septembre 2007 à 21:33. Évalué à 4.
        
        t'as pas bien saisi : Lisaac est parfait... pour Hurd.
        
        [^] # Re: sonntag
        
        Posté par Mildred (site web personnel) le 28 septembre 2007 à 12:22. Évalué à 3.
        
        En attendant, Lisaac fonctionne, et le Hurd a encore changé de noyau.
        Donc moi, je vote Lisaac.
        
        Après pour IsaacOS, je ne me prononce pas.
        
        [^] # Re: sonntag
        
        Posté par _flo_ le 28 septembre 2007 à 20:32. Évalué à 4.
        
        > et je vais personnellement l'améliorer pour en faire une lib de rêve, car je connais très bien le sujet...
        
        Mais dis moi, il a pas completement tort TIManiac...tu te la petes a fond!!
        
        C'est bien d'etre (sans doute) une brute en theorie et (sans doute) un bon codeur. Est-ce bien la peine de la ramener ainsi a la premiere occasion?
        
        Tenter une comparaison entre les framework de Java/.NET et la lib standard d'un langage de recherche, qui m'a l'air fort sympathique au demeurant, est pour le moins.....osé. Pour pas dire que tu flatules plutot haut.
        
        Pour memoire, ces frameworks ont qq années de developpement avec de grosses equipes derriere, sont ultra-documentés et debuggés. Et ont en outre bien plus de fonctionnalités que ce que tu decris. Donc meme si le Lisaac c'est le mega truc ultra puissant de la mort qui permet de coder ca en 4 jours ouvrés, savoir reconnaitre ses faiblesses c'est bien aussi!
        
        > (3) Pas besoin on a le modèle COP
        
        Ca m'interesse. J'ai lu la presentation du mec d'Epic que tu as mis en lien. Interessant (notamment sur les langages de shaders) mais je sais pas si ca a un rapport direct (COP = ??). En matiere de concurrence, il parle du modele d'Haskell, que j'avoue ne pas connaitre du tout mais les fonctionnalités qu'il decrit ont l'air sympa. Surtout, comment tu compiles ca en C (car si j'ai bien compris c'est le gros point fort de Lisaac, les perfs) sans passer par du threading et des appels systeme, justement? Auquel cas obtenir un compilo stable va sans doute pas etre aussi facile a faire qu'a dire...
        
        En tout cas bon courage pour l'evolution et le succes de votre projet! (surtout qu'apparemment en faire la pub n'a pas l'air de poser de difficultés... ;-)
        
        [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 29 septembre 2007 à 13:47. Évalué à 1.
        
        et je vais personnellement l'améliorer pour en faire une lib de rêve, car je connais très bien le sujet...
        
        Mais dis moi, il a pas completement tort TIManiac...tu te la petes a fond!!
        
        C'est bien d'etre (sans doute) une brute en theorie et (sans doute) un bon codeur. Est-ce bien la peine de la ramener ainsi a la premiere occasion?
        Je parlais de faire une librairie XML. Juste la lib qui te permet de manipuler un arbre.
        C'est franchement pas quelques chose qui prend des mois à faire.
        
        Si on commence à parler d'XSL,etc... là d'accord.
        
        Pour le reste, faut bien commencer un jour, et prendre des risques, sinon on fait jamais rien, non ?
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: sonntag
        
        Posté par _flo_ le 29 septembre 2007 à 18:34. Évalué à 2.
        
        Certes, c'etait un exemple parmi d'autres superlatifs encensant ton propre produit ("de reve", franchement.... ;-).
        
        Enfin peu importe hein, c'est pas moi qui bosse avec vous.
        
        Par contre vis a vis de mes questions sur le modele COP, peux tu eclairer ma lanterne?
        
        [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 29 septembre 2007 à 20:01. Évalué à 3.
        
        Certes, c'etait un exemple parmi d'autres superlatifs encensant ton propre produit ("de reve", franchement.... ;-).
        Bon c'est vrai que j'y crois beaucoup ;-) Ya mes rêves d'informaticien qui se réalise dedans ;-)
        Concernant l'Xml je disais que je m'y connaissais, parce que c'est mon métier, je fais ça toutes la journée :-)
        
        Par contre vis a vis de mes questions sur le modele COP, peux tu eclairer ma lanterne?
        
        En gros COP, c'est un modèle.
        
        Si tu déclare ton objet en '-' (- devant la section NAME), ton objet sera une sorte de thread.
        Si un autre objet appel une fonction (rendant un résultat)sur cette objet, l'appelant sera bloqué.
        Si c'est une méthode sans résultat, elle s'exécutera en parallèle.
        
        Le compilateur se débrouille tout seul avec les thread, les verrous, etc...
        
        C'est une amélioration de SCOOP que B. Meyer avait inventé pour Eiffel.
        
        Mais c'est bien mieux expliqué dans le manuel :-)
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: sonntag
        
        Posté par _flo_ le 29 septembre 2007 à 20:49. Évalué à 2.
        
        D'accord, je vois en gros ce que ca peut donner.
        
        C'est sympa, mais ca peut derouter ceux qui sont habitués a faire du multithreading toute la journée (chacun son truc a faire toute la journée, le xml pour toi, le multithreading pour moi... :-).
        
        En effet le programmeur n'a a ce moment pas forcement de visibilité sur le nombre de threads effectivement créés, le nombre de verrous manipulés etc... Ce qui peut etre important quand on en manipule beaucoup, et surtout qu'on fait du temps réel et qu'on veut pas s'amuser a créer un thread a la volée mais plutot le créer, le lancer et le lancer "effectivement" en debloquant un semaphore, ce genre de choses...
        
        Par contre pour du multithreading "basique" ca peut effectivement eviter bien des soucis d'inclure ca dans le langage, surtout quand on est pas habitués. Car c'est vrai que si on est pas rigoureux a donf (et meme si on l'est d'ailleurs), passer une semaine a chercher la cause d'un deadlock c'est plutot moyen en terme de productivité...
        
        M'enfin pour revenir a la comparaison trollistique avec Java/C# (sinon c'est pas drole), je n'ai personnellement jamais eu le moindre deadlock sur des programmes ecrits dans ces langages, avec leurs constructions 'synchronized' et 'lock' (je crois, ca fait longtemps que j'en ai pas fait). Pareil, implementer l'interface Runnable, c'est pas non plus...
        
        Enfin bref, du bon en perspective, meme si vous allez bien vous amuser au niveau compilo a gerer tout ca!!
        
        [^] # Re: sonntag
        
        Posté par LeMagicien Garcimore le 30 septembre 2007 à 19:46. Évalué à 1.
        
        Par rapport a un moniteur ca donne quoi ?
        
        http://en.wikipedia.org/wiki/Monitor_%28synchronization%29
        
        [^] # Re: sonntag
        
        Posté par Bozo_le_clown le 26 septembre 2007 à 14:42. Évalué à 2.
        
        Peut-être le fait que pour un humain résoudre un problème se fait en général en decoupant le pb en plus petit pb qu'il résoudra un par un et qu'il enchainera
        Le paradigme procédural est donc naturel.
        
        Peut-être le fait que pour un humain le paradigme objet lui rappelle son environnemnent et qu'il appréhende ces consepts d'autant mieux.
        
        Mais la programmation fonctionnelle,le commun des mortels a t'il les bagages mathématiques nécessaire pour comprendre la récursivité (suites reccurrentes), le lambda calcul, ...
        
        Surtout pourquoi vouloir réduire un langage à un seul concept aussi puissant soit-il. Personne n'a envie de faire l'effort intelllectuel de réécrire le if ou le for ou toute autre construction syntaxique à chaque instant. C'est sûr lorsqu'on maitrise ces idiomes, on est fier, on est un "vrai" programmeur" , on peut en remontrer aux autres , mais on s'en isole. Après il faut pas venir se plaindre et demander pourquoi les autres ne les affectionnent pas.
        
        C'est là justement que les langage comme Ruby, Python Groovy et consorts tirent leur épingles du jeu. Ils son multi-paradigme et ne focrent personne à programmer "contre nature".
        
        [^] # Re: sonntag
        
        Posté par fmaz fmaz le 27 septembre 2007 à 10:58. Évalué à 1.
        
        >Peut-être le fait que pour un humain résoudre un problème
        > se fait en général en decoupant le pb en plus petit pb qu'il
        > résoudra un par un et qu'il enchainera. Le paradigme
        > procédural est donc naturel.
        >
        >Mais la programmation fonctionnelle,le commun des mortels
        > a t'il les bagages mathématiques nécessaire pour
        > comprendre la récursivité (suites reccurrentes), le lambda calcul, ...
        
        C'est quoi pour toit le paradigme procédural ?
        Le principe de la réccurrence, c'est exactement ce que tu décris comme étant naturel.
        On pour résoudre pour n, on se rammène à un truc plus simple (n-1). Le tri fusion est un bon exemple.
    - [^] # Re: sonntag
      
      Posté par Joël SCHAAL le 26 septembre 2007 à 14:20. Évalué à 3.
      
      J'aimerais bien en savoir un peu plus sur ces prétendues tares que comporte Java.
      
      En effet je travaille avec ce langage tous les jours depuis 2 ans, et je ne me rends pas compte que c'est un langage arriéré avec lequel on peut faire moins de choses ou apparemment de manière moins esthétique / performante / rigoureuse. Je rentre bien dans ton premier cas ("on a du mal à voir les problèmes").
      
      Prenons donc la liste (non exhaustive apparement) des concepts qui manquent :
      
      - absence de contrats : je ne connais pas trop cette manière de travailler, mais d'après Wikipedia, ca revient à tester des domaines de valeurs. les mots clé assert (Java 1.5) sont là pour ca, et au pire on pourra toujours utiliser le mécanisme des Exceptions si ca ne suffit pas.
      
      - closures : effectivement pas de closures. on ne peut pas définir de fonctions dans une fonction. Mais est ce vraiment nécessaire ? Dans quel cas on ne ne peut faire quelque chose d'élégant et d'efficace uniquement avec les closures ?
      
      - aspects dynamiques limités : pourrais tu développer, s'il te plait ? Parce que la reflexion, les generics et la modification de code a chaud dans la VM, je trouve ça déjà pas mal.
      
      - compléxité de la grammaire : alors là forcément je ne m'en rends plus trop compte... Mais je ne suis pas sûr de trouver les points qui posent tant de problème. Et puis, en général, j'arrive souvent mieux à comprendre ce que fait un code Java qui utilise la plupart des mécanismes de la grammaire qu'un code Java qui appelle des méthodes de librairies que je ne connais pas. J'ai l'impression que de toutes facons il faudra passer par l'apprentissage de quelque chose.
      Que ce soit une syntaxe complexe + plein de librairies ou une syntaxe simple mais encore plus de librairies à apprendre à manipuler ne change que peu de chose selon moi.
      
      - lenteur de la compilation : en ce moment je travaille sur un produit qui contient environ une vingtaine d'archives jar. On estime travailler sur environ 800 000 lignes de code. Lorsqu'on compiile tout on en a pour environ 4 minutes (temps de récupération des données par SVN compris). Si on modifie seulement une partie du code, ca dépasse rarement la minute, on est plus de l'ordre de la dizaine de secondes.
      
      - concernant les frameworks et les briques qui s'ajoutent : si ces briques peuvent s'ajouter, c'est comme dit plus bas car le langage est assez souple pour le permettre. Plutot que de voir ca comme une preuve de l'incapacité d'évoluer, je verrais plutôt ca comme une preuve de l'organisation du code : la syntaxe pour faire les choses de bases comme les boucles, les tests, la manipulation d'objets et les opérations mathématiques de base, le SDK pour le reste. Les libs tierces pour ajouter des concepts pas dispo dans le SDK (rarement utiles, nouveaux,...). Ensuite dire que les briques de base sont incapables d'évoluer, c'est aussi dire que les évolutions qui marquent les versions 1.4, 5 et 6 ne servent a rien. Un peu fort tout de même, non ?
      
      Là où je trouve Java un peu embêtant, c'est pour la manipulation de fichiers (tous ces streams qui ne peuvent pas toujours communiquer entre eux, pfff...) [SDK] et pour la gestion de la concurrence [SDK + syntaxe].
      
      L'avantage de Lisaac ne m'apparait pas encore clairement, et je pense ne pas être le seul. Bon je n'ai jamais été fan de lambda calcul, de théorie des types et de coq, mais j'ai bien apprécié le Caml, même si je trouve que j'allais plus lentement a développer quelque chose qu'en C ou Java.
      
      Merci de votre patience.
      
      P.S.: je ne sais pas si ce genre de "débat" a déjà eu lieu, merci de m'indiquer le lien le cas échéant.
      - [^] # Re: sonntag
        
        Posté par reno le 27 septembre 2007 à 10:47. Évalué à 2.
        
        >>absence de contrats : je ne connais pas trop cette manière de travailler, mais d'après Wikipedia, ca revient à tester des domaines de valeurs. les mots clé assert (Java 1.5) sont là pour ca, et au pire on pourra toujours utiliser le mécanisme des Exceptions si ca ne suffit pas.<<
        
        On peut toujours faire tout dans chaque langage, le problème c'est la lourdeur du résultat.
        En Eiffel, les contrats d'une classes sont hérités par les classes qui en héritent, tu peux dupliquer les assert ou dans l'assert d'un héritier appeler les assert de la superclass, mais c'est lourd.
        
        Pour les closures, l'exemple type est pour les IHM, ou on a besoin de plein de petit bout de code a associer aux evenements, en Java c'est verbeux.
        
        Je suis d'accord avec toi pour la complexité de la grammaire de Java, certes c'est plus compliqué qu'un Smalltalk mais beaucoup moins qu'un C++ ou un Perl.
        
        Comme manque j'ajouterai:
        -les "properties": c'est lourd toutes ces fonctions set et get
        -le passage d'arguments par mots-clef.
        
        Et pour les generic, je prefere celle de Scala qui peuvent être covariante ou contravariante.
    - [^] # Re: sonntag
      
      Posté par Bozo_le_clown le 26 septembre 2007 à 14:24. Évalué à 2.
      
      Absence de contrats, de closures, aspects dynamiques limités (ou bien il faut des extensions comme Groovy), complexité de la grammaire (et donc lenteur de la compilation), pas de curryfication, pas de tail recursion, ..
      
      Forcément un langage type statiquement n'a pas les qualités d'un langage dynamiquement, il n'en a pas le défauts non plus (cf.. pyprotocols, pychecker, test sur les types d'arguments, ...)
      Et vu les innombrables trolls sur le sujet sur la toile on ne peut guère être categorique.
      
      En revanche ca m'aurait plus de savoir dans quelle catégorie se placait Lisaac en lisant la dépêche parce que perso, le fait qu'il optimise l'arbre de décision du programme ca m'apporte pas grand chose.
      Bref j'aurais aimé du concret, une vraie comparaison avec un langage comme Java et Ruby plûtôt qu'une liste complète de concepts que seul une minorité connait (enfin je crois).
      Par exemple la curryfication et la tail recursion, c'est quoi ? peut on vivre sans ?
      Pour les contrats , tu as à disposition des librairies qui s'en chargent et il n'y a guère de languages hormis Eiffel qui l'intègrents nativement. Est-ce le cas de Lisaac ?
      
      Pour l'utilisation classique des SOA/IHM/Web, la quantité de design patterns et l'apparition de tant de différents languages (Groovy, Jython, ..), et de frameworks (Junit, Aspectj, Hibernate, ..) montrent tout à fait la faiblesse des briques de base qui sont incapables d'évoluer.
      
      Ce que comble la programmation aspect c'est une des faiblesses du modèle objet (à proptotypes ou non). Elle prend en charge les problématiques transverses qui auparavant etaient disséminées et vise justement à alléger et rendre encore plus réutilsable ces briques de base.
      Elle se veut donc complémentaire. et on ne peut pas dire qu'elllees n'evoluent pas.
      Lisaac n'est donc pas objet ?
      
      Puis un petit détour sur les couches d'abstraction et ces pôvres makefiles pour accentuer la confusion des genres
      - [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 26 septembre 2007 à 14:52. Évalué à 2.
        
        Forcément un langage type statiquement n'a pas les qualités d'un langage dynamiquement, il n'en a pas le défauts non plus (cf.. pyprotocols, pychecker, test sur les types d'arguments, ...)
        Et vu les innombrables trolls sur le sujet sur la toile on ne peut guère être categorique.
        
        Lisaac est fortement typé, ce n'est pas un langage à typage dynamique, attention :-)
        
        En revanche ca m'aurait plus de savoir dans quelle catégorie se placait Lisaac en lisant la dépêche parce que perso, le fait qu'il optimise l'arbre de décision du programme ca m'apporte pas grand chose.
        Bref j'aurais aimé du concret, une vraie comparaison avec un langage comme Java et Ruby plûtôt qu'une liste complète de concepts que seul une minorité connait (enfin je crois).
        
        Par exemple la curryfication et la tail recursion, c'est quoi ? peut on vivre sans ?
        Pour les contrats , tu as à disposition des librairies qui s'en chargent et il n'y a guère de languages hormis Eiffel qui l'intègrents nativement. Est-ce le cas de Lisaac ?
        
        C'est vrai que j'ai été un peu trop conceptuel.
        
        La curryfication c'est le fait de transformer par exemple une fonction de 2 paramètre, en fonction de fonction, comme ça si tu as un paramètre tu le renvoi à la premiere et ça te renvoi une fonction.
        curryfication
        
        L'intérêt des contrats en Eiffel et lisaac (parce qu'il y en a vraiment en lisaac), c'est que tes contrats sont hérités : ils suivent l'arbre d'héritage, ce qui fait que tu peux les ajouter en comlpétant cet arbre.
        Ya des mots clé dans le langage, en Lisaac, le mot clé Old te permet de comparer l'ancienne valeur d'une variable en début de fonction et à la fin.
        
        Ce que comble la programmation aspect c'est une des faiblesses du modèle objet (à proptotypes ou non). Elle prend en charge les problématiques transverses qui auparavant etaient disséminées et vise justement à alléger et rendre encore plus réutilsable ces briques de base.
        Elle se veut donc complémentaire. et on ne peut pas dire qu'elllees n'evoluent pas.
        Lisaac n'est donc pas objet ?
        Perso, mais ce n'est que mon avis, je trouve ça bidouille, l'AOP..
        ça revient à quoi en fait ?
        ça revient à mettre des goto conditionnels dans ton code.
        Je faisais ça en Basic quand j'étais gosse...
        
        'fin cela dit tu pourras le faire sur des variables en lisaac : tu met un print dans le contrat de ta variable, ça va t'afficher le print à chaque fois qu'on accèdera à la variable (et testera le contrat, en passant)..
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: sonntag
        
        Posté par el_mickey le 26 septembre 2007 à 15:09. Évalué à 2.
        
        >>ça revient à mettre des goto conditionnels dans ton code.
        >>Je faisais ça en Basic quand j'étais gosse...
        
        Bah pareil que le foreach_while, je faisais ça a coup de goto quand j'etais jeune. Faut croire qu'il y en a qui lui ont trouvé une utilité.
        
        [^] # Re: sonntag
        
        Posté par Bozo_le_clown le 26 septembre 2007 à 15:17. Évalué à 2.
        
        Lisaac est fortement typé, ce n'est pas un langage à typage dynamique, attention :-)
        
        Merci de ta réponse mais ce qu'il m'interesse de comprendre
        c'est si le typage ets fort ou faible et s'il est statique ou dynamique
        Ces 2 concepts sont différents
        http://www.sitepoint.com/article/typing-versus-dynamic-typin(...)
        
        Par ex:
        C est fortement/statiquement typé
        Python est fortement/dynamiquement typé
        Perl est faiblement/dynamiquement typé
        
        Personnellement, je digère très mal le typage faible.
        
        Concernant ta remarque sur l'AOP je n'en ai pas une vision identique.
        Si l'on devait faire une analogie comme tu t'y exerces, il faudrait le comparer aux CSS.
        Les CSS s'occupent de la présentation et le XHTML du contenu.
        
        Avec l'AOP tu peux te permettre de sortir certaines problématiques transverses comme par exemple la persistence, le logging, ... de tes classes et de les traiter en un seul endroit: les aspects.
        Si tu fais évoluer ton approche de ces problématiques, tu n'interviens que sur les aspects au lieu d'intervenir sur toutes les le methodes de tes classes. Tu peux donc faire évoluer ton architecture beaucoup plus simplement et rapidement.
        Bref conjuguée avec l'objet, ca permet une approche orthogonale (comme pour la présentation/contenu)
        
        J'en conclus qu'il n'y a pas encore d'outils/framework AOP avec Lisaac mais ca n'est pas incompatible.
        Seulement après faut pas venir critiquer les "vieux" langages sur des arguments d'evolutivité (tu n'es pas visé)
        
        [^] # Re: sonntag
        
        Posté par Tramo Piere le 26 septembre 2007 à 15:50. Évalué à 1.
        
        Un petit mot sur l'aop:
        Lorsque l'on veut débugger sérieusement un algorithme ou du code complexe, on va ajouter des logs en entrée et en sortie, ce qui pollue rapidement le code.
        En remplaçant dynamiquement les fonctions ou les méthodes, on peut ajouter des logs sélectivement. On peut aussi utiliser ce mécanisme pour étendre l'outil avec de nouvelles fonctions, sans pour autant ajouter un arbre de classes supplémentaire.
        
        J'utilise ces techniques en javascript (affichage de pile des appels de fonctions lors d'une exception), mais on y trouve d'importants usages en java (aspectJ), et dans d'autres langages le mécanisme est immédiat (Python).
        Exemple de projet utilisant ce mécanisme: http://code.google.com/p/waf
        
        Le Y combinator en haskell/caml se rapproche de ce concept (déboggage/extension des fonctions récursives).
        
        [^] # Re: sonntag
        
        Posté par Yusei (Mastodon) le 26 septembre 2007 à 15:53. Évalué à 2.
        
        <Mr Jourdain>Grace à ce thread, j'ai enfin compris ce qu'était l'AOP, et réalisé que j'en faisais sans le savoir.
        
        [^] # Re: sonntag
        
        Posté par el_mickey le 26 septembre 2007 à 15:54. Évalué à 2.
        
        >>Lorsque l'on veut débugger sérieusement un algorithme ou du code complexe, on va ajouter des logs en entrée et en sortie, ce qui pollue rapidement le code.
        
        Ou alors tu utilises le debugger intégré à ton IDE.
        
        [^] # Re: sonntag
        
        Posté par Tramo Piere le 26 septembre 2007 à 16:20. Évalué à 2.
        
        > Ou alors tu utilises le debugger intégré à ton IDE.
        
        Sauf en production.
        
        [^] # Re: sonntag
        
        Posté par el_mickey le 26 septembre 2007 à 16:51. Évalué à 1.
        
        Et comment tu changes le comportement de ton aspect en production ?
        
        [^] # Re: sonntag
        
        Posté par Tramo Piere le 26 septembre 2007 à 17:11. Évalué à 2.
        
        En javascript on peut tout remplacer à chaud (de même en Python, on peut même déclarer de nouveaux modules et on dispose de métaclasses). Pour Java c'est plus difficile, mais avec Groovy on peut y arriver aussi.
        
        [^] # Re: sonntag
        
        Posté par Mildred (site web personnel) le 27 septembre 2007 à 19:55. Évalué à 1.
        
        Je pensait que tu parlais de java ... Je vois mal ce qu'il peut y avoir en production en Javascript.
      - [^] # Re: sonntag
        
        Posté par Mildred (site web personnel) le 27 septembre 2007 à 19:51. Évalué à 2.
        
        la tail recursion ou récursion terminale, c'est un truc dont tu ne peux pas te passer et qui existe dans tout bon langage (par exemple Lua, Lisaac ...)
        
        En gros ça te permet de faire de la récursivité sans exploser ta pile. Lorsque la dernère instruction de ta fonction est du style return appel_de_fonction(param ...), alors au lieu de rajouter un nouveau contexte sur la pile (et donc la faire grossir), le contexte de la fonction en cours est dépilé et le contexte de la fonction a appeler (appel_de_fonction) est empilé. Cela permet de ne pas faire grossir la pile pour rien. Après, la fonction appel_de_fonction retorunera directement à la fonction appelante sans passer par la fonction courante.
        
        Mais ça ne marche pas avec ta dernière instruction du genre return appel_de_fonction(...) + 1 car après l'appel de appel_de_fonction, la fonction en cours doit faire une addition, et doit donc reprendre la main avant de retourner.
        
        [^] # Re: sonntag
        
        Posté par fmaz fmaz le 28 septembre 2007 à 08:54. Évalué à 1.
        
        Pour donner un exemple d'école trop simple.
        
        Si tu codes la factorielle par
        
        fact(n)=
        si n=0 then 1
        else n*fact(n-1)
        
        On se rend vite compte qu'en fait, on peut la coder
        
        fact(n)=
        res=1
        for i=1 to n: res=res*i
        return(res)
        
        L'avantage de la première version, c'est que c'est plus proche de la définition mathématique. L'inconvéniant, c'est le nombre d'appel récursif qui peut exploser la pile. L'avantage de la second, c'est la pile. L'inconvéniant, c'est que c'est moins proche de la fonction mathématique.
        
        En fait, de façon générale, on peut toujours transformer un code recursif en un code impératif. Il suffit de manipuler une pile et de faire un while qui englobe le tout. Fait sous cette forme, ce n'est pas intéressant. En revanche, certain type de récursion (les récursion terminales) peuvent se coder avec une bête boucle for. De plus, cette procédure de dé-recursifier s'automatise. Certains langages le détectent et optimisent tout seuls.
        
        [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 28 septembre 2007 à 09:44. Évalué à 2.
        
        En fait, de façon générale, on peut toujours transformer un code recursif en un code impératif.
        
        Tu es vraiment sûr ? On m'a souvent dit que beaucoup de récursive non terminal était impossible à transformer en impératif.
        Si tu as la recette magique, tu nous intéresse ! :-)
        
        Tu le traduit comment impératif ça ?
        int tak(int x, int y, int z) { if (y < x) { return tak(tak(x - 1, y, z), tak(y - 1, z, x), tak(z - 1, x, y)); } return z; }
        
        Certains langages le détectent et optimisent tout seuls.
        Le compilateur Lisaac par exemple :)
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: sonntag
        
        Posté par tarlack le 28 septembre 2007 à 09:55. Évalué à 3.
        
        ben tu prends le code asm généré pour ca par exemple, ou les instructions proc executées... :)
        les approches recursives et imperatives sont turing-complet, donc tout ce que tu peux ecrire dans l'un est ecrivable dans l'autre.
        
        [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 28 septembre 2007 à 10:39. Évalué à 2.
        
        Je iens de regarder vite fait, et le code asm fait du récursif : il calcul, met en pile, fait un call sur lui même...
        
        tak__TJ: .LFB16: .loc 1 1134 0 .LVL9: pushl %ebp .LCFI7: movl %esp, %ebp .LCFI8: pushl %edi .LCFI9: movl %ecx, %edi pushl %esi .LCFI10: movl %eax, %esi pushl %ebx .LCFI11: movl %edx, %ebx subl $8, %esp .LCFI12: .LVL10: .L26: .loc 1 1137 0 cmpl %esi, %ebx jge .L27 .loc 1 1138 0 movl %ebx, %ecx movl %esi, %edx leal -1(%edi), %eax call tak__TJ movl %esi, %ecx movl %edi, %edx movl %eax, -16(%ebp) leal -1(%ebx), %eax call tak__TJ movl %edi, %ecx movl %ebx, %edx movl %eax, -20(%ebp) leal -1(%esi), %eax call tak__TJ movl -20(%ebp), %ebx movl -16(%ebp), %edi movl %eax, %esi jmp .L26 .LVL11: .L27: .loc 1 1143 0 popl %edx movl %edi, %eax popl %ecx popl %ebx .LVL12: popl %esi .LVL13: popl %edi .LVL14: popl %ebp ret
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: sonntag
        
        Posté par Dr BG le 28 septembre 2007 à 11:07. Évalué à 2.
        
        Passer par la pile, c'est justement la traduction itérative d'une fonction récursive... là ton code s'exécute bien itérativement pas à pas.
        
        [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 28 septembre 2007 à 11:34. Évalué à 2.
        
        Oui mais ça résoud pas le problème du récursif qui consomme une variable (ici dans la pile) à chaque passage dans la fonction...
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: sonntag
        
        Posté par Dr BG le 28 septembre 2007 à 11:45. Évalué à 2.
        
        Non, en effet, mais c'est ce que dit le commentaire de fmaz fmaz. Avec les fonctions récursives terminales on peut se passer de la pile, sinon non, ce qui ne change rien au fait qu'elle soit dé-récrursifiées (transformées en fonctions itératives).
        
        [^] # Re: sonntag
        
        Posté par Dr BG le 28 septembre 2007 à 09:55. Évalué à 3.
        
        La transformation n'est pas toujours évidente, mais il y a des méthodes pour le faire, qui quand on les suit pas à pas ne sont en fait pas si compliquées que ça. Je me souviens d'avoir vu ça en maîtrise (mais j'ai oublié la méthode :-)). Si c'est non-terminal, bah tu utilises une pile...
        
        De toutes façons, ton ordinateur exécute les tâches séquentiellement (et pas récursivement).
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 28 septembre 2007 à 11:49. Évalué à 2.
        
        Sequentiellement et recursivement, ca n'a rien de contradictoire.
        
        Tu empiles tout ce qu'il faut, tu resautes dans la procedure dans la quelle tu etais deja, et hop. Un code recursif reste recursif une fois compile (sauf recursion terminale).
        
        Sinon, tout ce qui est calculable peut effectivement l'etre sans recursivite. Mais c'est assez theorique. La transformation d'un programme recursif en programme non recursif, c'est hors de portee d'un compilo (d'ailleurs c'est surement pas calculable, mais la je ne suis pas sur). Il suffit d'essayer d'implementer un QuickSort sans recursivite pour s'en convaincre.
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 28 septembre 2007 à 11:57. Évalué à 2.
        
        Je me repond a moi-meme, je n'avais pas vu ton commentaire plus haut...
        
        Mais je ne suis pas d'accord, pour moi le code assembleur reste recursif. Simplement la pile est explicite au lieu d'etre implicite dans un autre langage.
        
        [^] # Re: sonntag
        
        Posté par Dr BG le 28 septembre 2007 à 13:57. Évalué à 3.
        
        Disons que le code assembleur représente toujours ta fonction récursive (normal, c'est ce qu'on voulait :-)) et qu'il le fait de manière impérative.
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 28 septembre 2007 à 14:54. Évalué à 3.
        
        Je me re-repond a moi-meme, l'arnaque, dans ce iteratif-qui-simule-le recursif, c'est au niveau de la place memoire. Il te faut une quantite de memoire dependant lineairement du nombre d'appel. C'est Vivi qui l'explique en dessous.
        
        Donc le vrai theoreme c'est: tout programme recursif peut se transformer en programme iteratif qui fonctionne sans exploser la memoire, mais c'est pas evident.
        
        Pas vraiment sur que le theoreme s'exprime vraiment comme ca, en fait.
        
        [^] # Re: sonntag
        
        Posté par Hal9000 le 28 septembre 2007 à 14:57. Évalué à 2.
        
        Oops, ca n'est vrai que pour les fonctions recursives primitives... Je ne me souvenais plus de ca.
        
        [^] # Re: sonntag
        
        Posté par Mildred (site web personnel) le 28 septembre 2007 à 12:26. Évalué à 1.
        
        Je crois qu'il y a eu des ébauches pour faire un ordinateur à base de dataflow, et qui exécute donc tout récursivement avec une approche fonctionnelle.
        Pour paralleliser, ça serait bien quand même.
        
        [^] # Re: sonntag
        
        Posté par fmaz fmaz le 28 septembre 2007 à 13:50. Évalué à 2.
        
        Tu écris un interpréteur pour ton langage (que tu écris de façon impérative) et tu lui passe en argument le code de ton truc.
        
        Je n'ai pas dis que c'était efficace, j'ai dit que c'était toujours possible.
        
        [^] # Re: sonntag
        
        Posté par Vivi (site web personnel) le 28 septembre 2007 à 14:07. Évalué à 2.
        
        En fait, de façon générale, on peut toujours transformer un code recursif en un code impératif.
        
        Tu es vraiment sûr ?
        
        Alors, le résultat intéressant si je me rappelle bien, c'est que les fonctions récursives dites récursives primitives peuvent être transformées en programme impératif utilisant un espace mémoire fixe (sinon ça n'a pas d'intérêt).
        
        Le cas d'exemple de fonction récursive non-primitive, c'est la fonction d'Ackermann qui ressemble un peu à celle que tu donnes en exemple.
        
        Sinon à propos de l'exemple de factorielle, on l'écrit de façon récursive terminale en ajoutant un argument "accumulateur":
        
        int fac(int acc, int n) { if (n < 1) return acc; else return fac(acc *n, n-1); }
        
        et on l'appelle fac(1, n).
        
        [^] # Re: sonntag
        
        Posté par reno le 28 septembre 2007 à 17:31. Évalué à 2.
        
        Et la, la "beauté" de la définition récursive de factorielle est bien entamée.
        
        C'est pour ça que je n'aimes pas trop les récursions: la plupart du temps soit c'est joli mais pas efficace, soit c'est efficace mais pas beau..
        
        [^] # Re: sonntag
        
        Posté par fmaz fmaz le 28 septembre 2007 à 18:04. Évalué à 2.
        
        Au début, on parlait du fait que certains langages détectaient les récursions terminales et les optimisaient.
        
        L'exemple de la factorielle est justement un exemple de récursion terminale et certains compilos optimisent automatiquement. C'est donc joli ET efficace.
        
        Maintenant, certains programmes récursifs ne sont pas récursifs terminal. Le compilo ne va pas optimiser mais de toute façon, ça serait dur de le faire.
        Un bon exemple de ça, c'est les tours de Hanoï.
        
        La procédure récursive, c'est
        
        déplacer la pile de taille n-1 du pilier 1 sur le pilier 2
        déplacer le cercle n du pilier 1 sur le pilier 3
        déplacer la pille de tailler n-1 du pilier 2 sur le pilier 3
        
        C'est pas récursif terminal mais c'est joli.
        
        Traduire ça en impératif, c'est pas beau et même si on peut le faire, on obtient un truc aussi lent que la version récursive.
        
        Oui, je sais, si on étudie le mouvement du cercle de taille 1, on peut ausi le faire impérativement mais là, on change complètement d'algorithme.
- [^] # Re: sonntag
  
  Posté par ciol le 25 septembre 2007 à 18:46. Évalué à -10.
  
  > J'interviens pour la première fois, car je suis un peu déçu des remarques que cet article occasionne et aussi parce que pour la première fois, je pense que mon produit a un petit intérêt.
  
  > Je n'interviendrai pas ultérieurement
  
  Pourquoi on est pas assez intelligent pour toi sale petit merdeux ? Tu te prends pour qui à débarquer comme ça et à lancer des choses du genre "moi je trolle pas, je fais." ?
  C'est toi le chef et tu envoies Ontologia rapporter ce que tu fais à ta place c'est ça, c'est pas assez bien pour toi ?
  Tu es chercheur, tu as créé un langage et un OS, cool; mais t'es pas obligé de te prendre pour un dieu aussi connard.
  
  Bon vent et va foutre ton spam flatteur d'égo ailleurs.
  - [^] # Re: sonntag
    
    Posté par ciol le 26 septembre 2007 à 17:06. Évalué à -7.
    
    désolé
- [^] # Re: sonntag
  
  Posté par darkleon (site web personnel) le 27 septembre 2007 à 11:53. Évalué à 3.
  
  Pour finir, je dirai que Lisaac est un petit langage moderne qui est dédié à des programmeurs qui aiment le bas niveau, le C ou ASM.
  
  C'est justement cet aspect combiné à une expressivité de haut niveau qui m'a attiré pour avoir plus d'informations sur ce langage.
  
  Enfin un langage où on exprime son problème de manière générique et synthétique, et c'est le compilo qui va faire toutes les optimisations.
  
  Evidemment, de l'ASM à la mimine pourra toujours être plus rapide, mais je me souviens d'un test d'un logiciel de génération de fugues, le testeur disait que la musique générée était à 90% du Bach, donc un humain est toujours plus performant qu'une machine, mais combien d'humains peuvent prétendre avoir le niveau de Bach. C'est la même polémique avec les programmes d'échecs.
  
  Comme je n'ai pas la prétention d'être un super hacker et que tapper du code me gonfle (surtout en java ou on fait 3/4 de glue code pour coller les morceaux de frameworks), un langage qui optimise certe, peut être moins bien que ce que je pourrais faire, mais de manière constante et globale sera surement plus efficace que moi.
  Rien n'empéche par la suite d'optimiser à la mimine les boucles critiques.
  
  Franchement, je pense que c'est un pas dans la bonne direction pour avoir du code plus robuste, moins on tappe de code "technique" (affectation, copie de champs, transtypage, vérification de domaines, de types), moins on a de risques de bugs, et si c'est le compilo qui est buggé dans la génération , on corrige à un endroit et on régénére l'application.
  
  ça ne remplacera pas JAVA, .NET, car l'interêt de ces langages est de pouvoir diviser pour régner sur un projet, mais je ne vois pas fondamentalement ce qui empécherait ce langage d'être à la base d'un nouvel OS, qui serait à priori plus robuste et plus fiable qu'un OS en C.
  
  Le seul problème, c'est la documentation, commence à partir des sources est un peu rude.
  - [^] # Re: sonntag
    
    Posté par Ontologia (site web personnel) le 27 septembre 2007 à 12:01. Évalué à 2.
    
    Tu as une doc ici :
    http://isaacproject.u-strasbg.fr/API/index.html
    
    Si tu l'as pas vu, c'est qu'on ne l'as pas assez mis en exergue :)
    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
    - [^] # Re: sonntag
      
      Posté par darkleon (site web personnel) le 27 septembre 2007 à 15:05. Évalué à 2.
      
      Si tu l'as pas vu, c'est qu'on ne l'as pas assez mis en exergue :)
      
      En fait je pensais plutôt a ce type de page
      
      http://isaacproject.u-strasbg.fr/li/li_docs.html
      
      La dernière fois que je suis allé sur le site, ça ne m'a pas sauté aux yeux.
      La documentation de l'API se résume à la description des méthodes et attributs. Certe on a la définition formelle, mais c'est un peu indigeste quand on a pas le cerveau qui a pris l'habitude de jongler avec la représentation du code Lisaac et les concepts derrière.
      
      Le langage a l'air génial, mais pour le moment, c'est quand même le jeu de piste pour l'essayer, mais ça va surement s'améliorer avec le temps.
      - [^] # Re: sonntag
        
        Posté par Ontologia (site web personnel) le 27 septembre 2007 à 15:11. Évalué à 2.
        
        J'ai une doc un peu moins concise, plus joli, mais moins complète, que je compte mettre sur le site, bientôt, quand j'aurai eu le temps de la reprendre. Je te l'envoi perso si tu veux :-)
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: sonntag
        
        Posté par darkleon (site web personnel) le 27 septembre 2007 à 15:58. Évalué à 1.
        
        Merci pour la proposition, mais je n'ai pas encore d'idée de projet perso (même tout petit, comme un solveur par exemple) pour mettre lisaac en application.
        Le temps de réunir toutes les conditions, je pense que la doc se sera améliorée ! :-)
        
        Si un des utilisateurs de Lisaac améliore les commentaires sur la doc existante, aura t'il un moyen de vous remonter ses modifications ?
        
        <hors propos>
        J'ai beau avoir étudié pleins de langage à la fac, pour la plupart, j'en suis resté au niveau de la "syntaxe".
        J'ai beau avoir fait du LISP, il y a un monde entre les exercices que j'ai du faire et les papiers vantant la puissance du LISP.
        Sans compter qu'entre les parenthéses et la notation préfixe (ou postfixe pour les calculatrices HP), je n'arrive vraiment pas à m'y faire, j'ai un rejet esthétique de cette syntaxe, même si les concepts sont élégants.
        Si la plupart des notations mathématiques "sur papier" sont infixe, c'est que c'est quand même plus agréable à lire.
        
        La notion d'esthétisme d'un code source est aussi un domaine intéressant, comment équilibrer les symboles pour que la lecture soit harmonieuse et le décodage par le cerveau facilité.
        </hors propos>
    - [^] # Re: sonntag
      
      Posté par Mildred (site web personnel) le 27 septembre 2007 à 19:58. Évalué à 1.
      
      En même temps, les sources ne sont pas si compliquées et bien souvent c'est plus pratique de regarder le code source de la lib que la documentation. Ca paraît difficile mais en fait c'est simple
  - [^] # Re: sonntag
    
    Posté par Nicolas Boulay (site web personnel) le 27 septembre 2007 à 14:43. Évalué à 2.
    
    tu as bien compris la philo de Lisaac :)
    "La première sécurité est la liberté"
    - [^] # Re: sonntag
      
      Posté par darkleon (site web personnel) le 27 septembre 2007 à 15:43. Évalué à 1.
      
      En fait, je suis à 0,1% jaloux :-)
      
      ça fait des années que je pense à ce genre de concept (comme surement beaucoup d'autres informaticiens paresseux), mais entre le manque de temps, et la somme de travail à fournir (et le travail préparatoire mathématique pour me remettre à niveau) ont fait que c'est toujours resté au stade du rêve.
      
      Mais comme vous vous êtes retroussés les manches (les 99,9% restants) et que vous avez quelque chose qui commence a être exploitable, je ne peux pas vous en vouloir et au contraire vous encourager à continuer.
      - [^] # Re: sonntag
        
        Posté par Nicolas Boulay (site web personnel) le 27 septembre 2007 à 16:00. Évalué à 2.
        
        Lisaac c'est à 99% Ben. Mais maintenant, il faut une infra de test et écrire la lib standard. C'est du boulot moins haut niveau donc plus abordable.
        "La première sécurité est la liberté"
- [^] # Re: sonntag
  
  Posté par GTof le 27 septembre 2007 à 12:19. Évalué à 1.
  
  C'est toujours les râleurs qu'on entend le mieux mais il est clair qu'ici beaucoup de gens sont intéressés par Lissac. Les gens qui s'intéressent au langage préfèrent l'apprendre et jouer avec que de faire des tartines ici, ce qui n'exclus pas un petit mot pour dire qu'on apprécie ce qui fut le cas.
  
  En tout cas merci pour ce travail, bien qu'en en connaissant très peu, ça m'a l'air très intéressant et merci aussi de le mettre en GPLv3.
# Vaccination

Posté par Yusei (Mastodon) le 25 septembre 2007 à 08:38. Évalué à 3.

Il me vient une petite interrogation concernant le fait que la bibliothèque vaccine/contamine les exécutables: existe-t-il des langages/compilateurs qui font ça et qui ont un jour eu du succès ?
- [^] # Re: Vaccination
  
  Posté par BAud (site web personnel) le 25 septembre 2007 à 08:52. Évalué à 2.
  
  GNU gettext ou readline par exemple ? Rien n'empêche de réécrire pour ceux qui ne veulent pas du vaccin, ce qui est contreproductif àmha.
  - [^] # Re: Vaccination
    
    Posté par Lucas le 25 septembre 2007 à 08:55. Évalué à 3.
    
    gettext et readline ne sont pas des compilateurs ;)
    - [^] # Re: Vaccination
      
      Posté par Yusei (Mastodon) le 25 septembre 2007 à 09:01. Évalué à 2.
      
      C'est ce que j'allais lui répondre, mais d'un autre côté la bibliothèque standard de Lisaac n'est pas non plus un compilateur. Juste un élément quasi-indispensable de la plateforme.
      
      J'ai beau utiliser une licence libre "vaccinante" pour tout ce que je code sur mon temps libre, j'ai tendance à penser que la bibliothèque standard fait partie du langage, et que par conséquent elle ne devrait pas "vacciner" les fichiers de sortie. C'est un peu comme si Inkscape rendait GPL les fichiers SVG qu'il génère.
      - [^] # Re: Vaccination
        
        Posté par Lucas le 25 septembre 2007 à 09:08. Évalué à 1.
        
        D'un autre côté, si j'ai bien compris, le compilo est sous GPLv3 également. Et pas sûr qu'il ait une exception sur ce qu'il génère (cf mon commentaire/question un peu plus haut).
        
        [^] # Re: Vaccination
        
        Posté par TeXitoi (site web personnel) le 25 septembre 2007 à 10:39. Évalué à 1.
        
        Ce qui est généré par des programmes en GPL n'est jamais GPL. Sinon, tes documents OpenOffice le sont, tes pages Web faites avec NVu également, ainsi que tes comptes fait avec Grisbi...
        
        Si bison a une tel exception, c'est parce que le fichier généré comprend du code fourni par le programme.
        
        [^] # Re: Vaccination
        
        Posté par Ontologia (site web personnel) le 25 septembre 2007 à 10:45. Évalué à 3.
        
        Oui mais la lib est GPLv3, Or, le code compilé embarque pas mal de code de la lib. Donc le code est GPLv3
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
        
        [^] # Re: Vaccination
        
        Posté par TeXitoi (site web personnel) le 25 septembre 2007 à 10:53. Évalué à 2.
        
        Oui, bien sûr, j'ai jamais dit le contraire.
        
        Mais si quelqu'un recode la lib standard en une licence plus permissive (BSD, CeCILL C ou LGPL avec exception de "linkage"), il serait alors possible de faire des programme non GPLv3.
        
        Cette lib me gène : elle empêche l'utilisation d'une autre licence que GPLv3 : pas de programmes en LISAAC sous GPLv2, CeCILL, BSD ou licence priorio. Est-ce pour se permettre un business model à la trolltech (vente de licence pour utilisation de la lib en non GPL) ?
        
        [^] # Re: Vaccination
        
        Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 11:07. Évalué à 2.
        
        Est-ce pour se permettre un business model à la trolltech (vente de licence pour utilisation de la lib en non GPL) ?
        
        C'est une idée.
        
        Mais pour que cela marche, il faut que les contributeurs à la lib donne leur copyright pour vendre le licence. C'est pas gagné du tout... Or lisaac a besoin de ces contributeurs. Mais lisaac a aussi besoin de moyen pour exister... bref, cela se mord la queue.
        "La première sécurité est la liberté"
- [^] # Re: Vaccination
  
  Posté par Hal9000 le 25 septembre 2007 à 14:32. Évalué à 1.
  
  C'est vrai que ca parait extremement handicapant, si effectivement ca revient en pratique a imposer la licence utilisee pour les logiciels produits.
  Un des responsables du projet pourrait-il nous expliquer ce choix?
  - [^] # Re: Vaccination
    
    Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 14:46. Évalué à 2.
    
    Il y a plusieurs raisons. Cela se mélange.
    
    Il y a l'idée de favoriser le libre, en le forçant. On considère Lisaac comme une "killer feature" du libre. C'est vrai aussi, que l'on aurait pu faire une double licence GPLv2/GPLv3 mais bon, on fait simple pour commencer.
    
    Il y a l'idée de refaire le coup de Trolltech ou de MySQL Labs. T'en qu'à avoir de bonnes idées, c'est encore mieux de pouvoir en vivre. Si une personne ne veut pas faire de libre, elle paye.
    
    Est-ce que le modèle de Trolltech est le bon ? Ou celui de Mozilla ? Ou encore celui de Perl, ou encore de PHP ?
    
    Bref, on est pas encore rentré dans ce genre de détails. C'est possible que cela puisse évolué.
    "La première sécurité est la liberté"
    - [^] # Re: Vaccination
      
      Posté par Yusei (Mastodon) le 25 septembre 2007 à 15:07. Évalué à 6.
      
      À mon avis, considérer Lisaac comme promoteur du libre plutôt que le contraire, c'est s'assurer qu'il n'aura jamais qu'une reconnaissance limitée.
      
      Tout simplement parce que l'industrie ne voudra pas s'en servir (ça ne sert à rien d'investir dans un langage qui limite ce qu'on a le droit de faire avec son produit), et que si l'industrie ne s'en sert pas, beaucoup de développeurs ne prendront même pas la peine de l'apprendre.
      
      Quand on voit le mal qu'ont à s'imposer de bons langages comme Eiffel ou OCaml, alors qu'ils n'imposent pas ces contraintes d'utilisation, on ne peut que se demander comment Lisaac pourrait attirer l'attention sans être utilisé dans l'industrie. Ce n'est pas un hasard si Java est plus utilisé qu'Eiffel alors que n'importe quel développeur raisonnable préfèrerait coder en Eiffel.
      
      Si je dis ça, ce n'est pas parce que j'ai envie de coder des softs propriétaires, c'est surtout parce que j'aimerais bien un jour avoir la possibilité de choisir autre chose que le C++ quand je dois coder quelque chose de rapide. J'attends avec impatience un bon langage qui arrive à sortir du milieu académique. Il est très bien, le milieu académique, mais pour avoir tout un framework de développement autour du langage, il faut une grosse communauté.
    - [^] # Re: Vaccination
      
      Posté par Hal9000 le 25 septembre 2007 à 15:12. Évalué à 4.
      
      OK, je comprend. Le modele TrollTech semble se tenir. Mais la, faut limiter les contributions... Mais peut-etre comptez vous sur la communaute pour developper des killer apps, pas pour participer au langage lui-meme ou a la librairie standard.
      
      En tout cas, je vous souhaite bonne chance. Pensez a developper un environement de developpement a la hauteur, et a mettre le paquet sur les bibliotheques disponibles. J'espere que l'INRIA vous donnera les ressources dont vous avez besoin pour ca. Si ils l'avaient fait pour l'OCaml, ca aurait peut-etre marche...
      - [^] # Re: Vaccination
        
        Posté par Ontologia (site web personnel) le 25 septembre 2007 à 15:25. Évalué à 3.
        
        C'est plus l'INRIA mantenant, c'est le CNRS...
        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
- [^] # Re: Vaccination
  
  Posté par Mildred (site web personnel) le 27 septembre 2007 à 20:08. Évalué à 1.
  
  On peut refaire la lib standard ... ce n'est pas si difficile. Pour avoir quelque chose de milimal, il faut implémenter des choses comme OBJECT, BOOLEAN, INTEGER, BLOCK et d'autres. Le reste comme les collections, c'est plus accessoire (cela ne veut pas dire qu'on en a pas besoin).
  
  Maintenant que je me rend compte que la lib est en GPLv3, ça me fait peur. Parce que j'ai déjà des programmes qui utilisent la licence MIT/X11 (par conviction) et que je préfèrerais garder cette licence. Mais j'espère que ça changera, sicon, c'est vrai que cela pourrait faire couler Lisaac.
  
  Mais pour le moment, on ne se pose pas trop de problèmes de licences ... Tout le monde est bienvenu.
# Benchmark

Posté par rewind (Mastodon) le 25 septembre 2007 à 17:26. Évalué à 7.

Dans la recherche, il parait qu'on doit pouvoir refaire les expérimentations pour valider les résultats. Or sur la page benchmark, il y a de jolis résultats mais rien qui permettent à M. Lambda (moi) de refaire ces expérimentations. Il manque le code du décodeur MPEG-2 ! Tous les autres détails genre la machine ou les options de compilation ne servent à rien sans ce code.

Serait-il possible de l'avoir ? Y a-t-il d'autres benchmarks disponibles ?
- [^] # Re: Benchmark
  
  Posté par Ontologia (site web personnel) le 25 septembre 2007 à 17:28. Évalué à 2.
  
  Tu vas sur le site, dans la section "Communauty" tu trouveras un lien vers une page de projet GNA.
  Tu y trouveras le SVN du projet.
  
  Il y est.
  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
  - [^] # Re: Benchmark
    
    Posté par M le 25 septembre 2007 à 21:57. Évalué à 4.
    
    Il serait bon de préciser qu'il s'agit d'un décodeur de référence, ie non optimisé et ou la clarté est souvent privilégié.
    
    De plus je m'interroge sur le copyright du code isaac :
    le code C est sous copyright MPEG (avec une licence dont on ne sait pas trop si elle est libre et si elle autorise le repompage pour faire des versions dérivées).
    Le code isaac est d'après le site une conversion "mot pour mot" de la version C, ça dérive donc du code original C, et le copyright devrait toujours s'appliquer. Il me parait douteux que le code isaac change le copyright et la licence.
    
    C'est un peu comme une traduction d'un bouquin, l'auteur de la version originale a toujours des droits sur les versions traduites.
    - [^] # Re: Benchmark
      
      Posté par Nicolas Boulay (site web personnel) le 25 septembre 2007 à 22:24. Évalué à 1.
      
      C'est just pour dire que la version Lisaac n'utilise pas d'algo différent qui lui donnerait un avantage.
      "La première sécurité est la liberté"
    - [^] # Re: Benchmark
      
      Posté par Ontologia (site web personnel) le 25 septembre 2007 à 22:29. Évalué à 1.
      
      Je suis d'accord avec ce que vient de dire nicO, mais c'est vrai qu'on est peut être allé un peu vite en le mettant dans le subversion : GNA impose que le logiciel soit libre, ce qui est effectivement illégal.
      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Packaging pour distributions ?

Posté par Xavier Maillard le 26 septembre 2007 à 06:00. Évalué à 1.

Salut,

Je sais que ça fait un peu tôt, mais est-il prévu à très court terme, de packager Lisaac pour les principales distributions GNU/linux existantes (slackware, Debian et compagnie) ? Le fait de le trouver dans sa distribution de préférence sans se galérer à l'installer soit-même (cf. un post un peu plus haut), c'est déjà un bon début.

Autre question non technique: j'ai vu qu'il y avait une paire de listes de diffusion consacrées au projet. POur la partie devel, j'arrive à accéder aux archives mais pas pour la partie user. Est-ce normal -i.e. il n'y a pas encore d'archives ? Sinon, pour suivre devel, combien de messages par jour sont échangés sur cette liste ?

Merci pour vos éléments de réponse
- [^] # Re: Packaging pour distributions ?
  
  Posté par Nicolas Boulay (site web personnel) le 26 septembre 2007 à 09:58. Évalué à 3.
  
  combien de messages par jour sont échangés sur cette liste ?
  
  Pas grand chose... surtout depuis que l'on a dis que tout devait se faire en anglais :)
  "La première sécurité est la liberté"
- [^] # Re: Packaging pour distributions ?
  
  Posté par Sylvain Sauvage le 26 septembre 2007 à 17:10. Évalué à 2.
  
  Euh, sur Debian, depuis plusieurs semaines (mois ?) :
  
  $ apt-cache search lisaac
  lisaac - Object-oriented language base on prototype
  lisaac-common - Arch-independent part for lisaac
  lisaac-doc - Documentation for lisaac
  lisaac-mode - Emacs mode for editing Lisaac programs
  
  $ apt-cache policy lisaac
  lisaac:
  Installé : (aucun)
  Candidat : 0.84-3
  Table de version :
  0.84-3 0
  500 http://ftp.fr.debian.org sid/main Packages
  500 http://ftp.fr.debian.org testing/main Packages
  
  Donc à la fois dans Sid et Testing.
  - [^] # Re: Packaging pour distributions ?
    
    Posté par imalip le 26 septembre 2007 à 17:42. Évalué à 3.
    
    Euh, sur Debian, depuis plusieurs semaines (mois ?) :
    
    http://packages.qa.debian.org/l/lisaac.html
    
    Un an le mois prochain, et c'est dans Etch (stable)
  - [^] # Re: Packaging pour distributions ?
    
    Posté par TeXitoi (site web personnel) le 26 septembre 2007 à 17:51. Évalué à 2.
    
    Mmm... 0.12 (version du compilo ?), 0.2 (version de la spec ?), 0.84 (heu... version "debian ?)... C'est pas un peu le bordel la numérotation des versions en lisaac?
    - [^] # Re: Packaging pour distributions ?
      
      Posté par Ontologia (site web personnel) le 26 septembre 2007 à 18:13. Évalué à 2.
      
      en réalité c'est 0.084, car elle tend vers la spécification 0.1
      Comme 0.12 qui tend vers la spécification 0.2
      
      Ya un schéma ici : http://isaacproject.u-strasbg.fr/li/li_download.html
      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
      - [^] # Re: Packaging pour distributions ?
        
        Posté par BAud (site web personnel) le 26 septembre 2007 à 22:24. Évalué à 3.
        
        vous ne pourriez pas multiplier par 10 ?
        
        quand vous aurez fini, ça vous permettra d'avoir une note de 12/10 (toujours dépasser les attentes ;-) ).
        parce que bon à ce train là il y aura toujours un 0. dans vos version, ce qui fait un peu pas fini ou pas utilisable...
        
        heureusement qu'il ne faut pas attendre le langage parfait pour s'exprimer :D
      - [^] # Re: Packaging pour distributions ?
        
        Posté par TeXitoi (site web personnel) le 27 septembre 2007 à 09:58. Évalué à 3.
        
        OK, c'est plus clair, mais ca casse tout les canons comme quoi 0.12 > 0.2...
        
        J'aurai rajouté un point dans votre notation pour éviter l'ambiguité : 0.0.84, 0.2, 0.1.2, ça aurait été plus consistant avec l'existant...
        
        Et au passage, vu que 1.0 n'existera jamais par définition, il est vrai que le 0. est peu utile ;-)
- [^] # Re: Packaging pour distributions ?
  
  Posté par Xavier Oswald le 27 septembre 2007 à 16:23. Évalué à 3.
  
  Je réponds à cette question comme je suis co-mainteneur du paquet debian ;)
  
  Lisaac existe dans Debian depuis 1an environ.
  Lisaac est disponible pour stable/testing/unstable.
  
  La version actuellement dans Debian est la 0.084 visant à avoir les spécifications de Lisaac 0.1, donc il sagit de l'ancienne syntaxe Lisaac.
  
  Je vais faire sous peu une nouvelle version du paquet Debian avec la 0.12 qui vise à contenir la spécification Lisaac 0.3.
  
  Je penses que fin du mois prochain on aura la nouvelle release de Lisaac dans Debian.
  
  Happy hacking ... ,
- [^] # Re: Packaging pour distributions ?
  
  Posté par Xavier Oswald le 27 septembre 2007 à 16:51. Évalué à 2.
  
  Salut,
  
  Au sujet des listes, il n'y a encore pas de mail sur isaac-user, donc c'est normal. Ah non, c'est plus le cas, il y a 2 mails maintenant ;)
  
  Au niveau mail sur isaac-devel, ca reste gérable, il a en gros 1mail tout les 3-4 jours mais ca reply bien d'habitude. Donc si tu postes un mail tu devrais avoir pas mal de réponses dans la journée.
  
  Pourquoi si peu de mail sur les listes?
  >> on vient de passer le projet sur GNA il y a quelques semaines donc c'est normal !
  
  @ toute ...
- [^] # Re: Packaging pour distributions ?
  
  Posté par Mildred (site web personnel) le 27 septembre 2007 à 20:13. Évalué à 1.
  
  Rieen sur les archives de la mailing liste, tout simplement parce que personne n'a envoyé de message, tu peux t'inscrire si tu veux :)

Suivre le flux des commentaires

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