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 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) . Évalué à 3.
Merci.
[^] # Re: Sather
Posté par ciol . Évalué à -9.
(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) . Évalué à 3.
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) . Évalué à 6.
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) . Évalué à 4.
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) . Évalué à 2.
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) . Évalué à 6.
a:ARRAY{INT} := |1,2,3|; loop #OUT + ",".separate!(a.elt!.str); end;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;# Pertinence de cette dépeche ?
Posté par Lucas . Évalué à -6.
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) . Évalué à 9.
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 . Évalué à 0.
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) . Évalué à 10.
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 . Évalué à 6.
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) . Évalué à 1.
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 . Évalué à 2.
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) . Évalué à 1.
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 . Évalué à 2.
[^] # Re: Pertinence de cette dépeche ?
Posté par TeXitoi (site web personnel) . Évalué à 2.
[^] # Re: Pertinence de cette dépeche ?
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: Pertinence de cette dépeche ?
Posté par benoar . Évalué à 3.
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) . Évalué à 0.
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 . Évalué à 0.
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) . Évalué à 4.
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 . Évalué à 1.
[^] # Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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) . Évalué à 3.
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 . Évalué à 2.
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) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pertinence de cette dépeche ?
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
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) . Évalué à 1.
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 . Évalué à 3.
[^] # Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Pertinence de cette dépeche ?
Posté par benoar . Évalué à 2.
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 . Évalué à 2.
[^] # Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pertinence de cette dépeche ?
Posté par benoar . Évalué à 2.
[^] # Re: Pertinence de cette dépeche ?
Posté par benoar . Évalué à 2.
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 :
D'où l'exception de la libstd++.
[^] # Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pertinence de cette dépeche ?
Posté par benoar . Évalué à 2.
[^] # Re: Pertinence de cette dépeche ?
Posté par Yusei (Mastodon) . Évalué à 7.
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 . Évalué à 2.
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 . Évalué à 1.
[^] # Re: Pertinence de cette dépeche ?
Posté par GTof . Évalué à 2.
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 . É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) . Évalué à 2.
[^] # Re: Pertinence de cette dépeche ?
Posté par Khâpin (site web personnel) . Évalué à 4.
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 . Évalué à 1.
[^] # Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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) . Évalué à 4.
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 . Évalué à 3.
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) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Pertinence de cette dépeche ?
Posté par Rémi Pannequin . Évalué à 1.
Et tant bien même... cf faible succès de Vista !
[^] # Re: Pertinence de cette dépeche ?
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
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 . Évalué à 5.
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) . Évalué à 2.
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 . Évalué à 3.
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 . Évalué à 4.
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 . Évalué à 2.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Ontologia (site web personnel) . Évalué à 4.
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) . Évalué à 3.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Antoine . Évalué à 3.
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) . Évalué à 6.
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 . Évalué à 4.
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) . Évalué à 3.
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.
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 . Évalué à 3.
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.
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 ^^ :
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par TImaniac (site web personnel) . Évalué à 1.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 3.
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) . Évalué à 4.
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 . Évalué à 4.
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) . Évalué à 1.
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 . Évalué à 2.
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) . Évalué à 1.
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 . Évalué à 2.
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) . Évalué à 1.
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 . Évalué à 1.
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) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet . Évalué à 1.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par imalip . Évalué à 4.
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 . Évalué à 1.
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 . É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) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet . Évalué à 2.
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) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet . Évalué à 1.
Lisaac, c'est prevu pour tourner sur une JavaCard ?
;-)
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet . Évalué à 0.
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 . Évalué à 0.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par rewind (Mastodon) . Évalué à 2.
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) . Évalué à 1.
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) . Évalué à 1.
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) . Évalué à 3.
É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) . Évalué à 4.
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) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet . Évalué à 1.
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 . Évalué à 2.
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 . Évalué à 1.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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) . Évalué à 2.
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) . Évalué à 3.
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) . Évalué à 2.
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 . Évalué à 2.
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. . Évalué à 2.
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) . É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 . Évalué à 2.
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) . Évalué à 3.
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) . Évalué à 7.
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) . Évalué à 3.
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".
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) . Évalué à 1.
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 . Évalué à 4.
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 . Évalué à 2.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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 . Évalué à 3.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
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 . Évalué à 1.
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) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Philip Marlowe . Évalué à 8.
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) . Évalué à 2.
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) . Évalué à 1.
/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 . Évalué à 4.
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 . Évalué à 10.
(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) . Évalué à 2.
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) . Évalué à 3.
(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) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Yusei (Mastodon) . Évalué à 4.
(à part la syntaxe condition.if que je trouve rigolote)
[^] # Re: sonntag
Posté par Mildred (site web personnel) . É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 . Évalué à 6.
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) . Évalué à 1.
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) . Évalué à 1.
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 . Évalué à 5.
Honnêtement, je ne vois pas en quoi Lisaac est plus joli que du C.
[^] # Re: sonntag
Posté par reno . Évalué à 3.
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 . Évalué à 2.
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) . Évalué à -1.
"La première sécurité est la liberté"
[^] # Re: sonntag
Posté par reno . Évalué à 2.
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) . Évalué à 2.
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) . Évalué à 2.
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . Évalué à 3.
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) . Évalué à 7.
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) . Évalué à 1.
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) . Évalué à 1.
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 . Évalué à 3.
- 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 . Évalué à 2.
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) . Évalué à 3.
C'est pas la même chose ?
[^] # Re: sonntag
Posté par Antoine . Évalué à 2.
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) . Évalué à 4.
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 . Évalué à 2.
[^] # Re: sonntag
Posté par Yusei (Mastodon) . Évalué à 2.
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 . Évalué à 4.
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) . Évalué à 1.
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 . Évalué à 1.
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) . Évalué à 3.
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, ...).
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...
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 . Évalué à 3.
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) . Évalué à 1.
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) . Évalué à 3.
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) . Évalué à 2.
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) . Évalué à 2.
> 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 . Évalué à 2.
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) . Évalué à 2.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 2.
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) . Évalué à 2.
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 . Évalué à 1.
[^] # Re: sonntag
Posté par Yusei (Mastodon) . Évalué à 4.
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 . Évalué à 1.
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) . Évalué à 2.
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) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: sonntag
Posté par Hal9000 . Évalué à 1.
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 . Évalué à 2.
[^] # Re: sonntag
Posté par Sebastien Binet . Évalué à 1.
http://en.wikipedia.org/wiki/Support_vector_machine
[^] # Re: sonntag
Posté par Hal9000 . Évalué à 2.
[^] # Re: sonntag
Posté par fmaz fmaz . Évalué à 3.
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 (site web personnel) . Évalué à 3.
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) . Évalué à 5.
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) . Évalué à 6.
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 . Évalué à 6.
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) . Évalué à 2.
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 . Évalué à 2.
[^] # Re: sonntag
Posté par reno . Évalué à 2.
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 . Évalué à 1.
[^] # Re: sonntag
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je trouve que pas mal de post ici confondent math et génie logiciel.
[^] # Re: sonntag
Posté par Dr BG (site web personnel) . Évalué à 4.
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) . Évalué à 3.
> 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 (site web personnel) . Évalué à 2.
Et enfin, j'ai quand même dit que je "trollais".
[^] # Re: sonntag
Posté par Hal9000 . Évalué à 2.
[^] # Re: sonntag
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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) . Évalué à 2.
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 . Évalué à 2.
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) . Évalué à 1.
[^] # Re: sonntag
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: sonntag
Posté par lezardbreton . Évalué à 2.
[^] # Re: sonntag
Posté par TeXitoi (site web personnel) . Évalué à 1.
La logique, c'est des mathématiques, d'après cet article, en tout cas...
[^] # Re: sonntag
Posté par lezardbreton . Évalué à 4.
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) . Évalué à 4.
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 . Évalué à 3.
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) . Évalué à 3.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 4.
>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) . Évalué à 1.
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. . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 1.
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) . Évalué à 2.
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 . Évalué à 7.
* 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) . Évalué à 9.
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) . Évalué à 3.
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) . Évalué à 4.
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) . Évalué à 4.
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) . Évalué à 5.
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 . É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.
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) . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 2.
[^] # Re: sonntag
Posté par Mildred (site web personnel) . Évalué à 1.
[^] # Re: sonntag
Posté par Mildred (site web personnel) . Évalué à 1.
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) . Évalué à 2.
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) . Évalué à 2.
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 . Évalué à 3.
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 . Évalué à 3.
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) . Évalué à 1.
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) . Évalué à 2.
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) . Évalué à 1.
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 . Évalué à 1.
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) . Évalué à 1.
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 . Évalué à 1.
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) . Évalué à 1.
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 . Évalué à 1.
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) . Évalué à 1.
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 . Évalué à 2.
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) . Évalué à 1.
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . Évalué à 0.
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) . Évalué à 3.
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) . Évalué à 1.
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 . Évalué à 1.
[^] # Re: sonntag
Posté par TImaniac (site web personnel) . Évalué à 0.
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 . Évalué à 2.
[^] # Re: sonntag
Posté par Yusei (Mastodon) . Évalué à 2.
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.
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) . Évalué à 1.
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) . Évalué à 5.
[^] # Re: sonntag
Posté par Tramo Piere . Évalué à 3.
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) . Évalué à 0.
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 . Évalué à 2.
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) . Évalué à 1.
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 . Évalué à 1.
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) . Évalué à 1.
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) . Évalué à 0.
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) . Évalué à 1.
bah utilises les bons outils en fonction de tes besoins ;)
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . Évalué à 2.
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) . Évalué à 3.
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) . Évalué à 7.
[^] # Re: sonntag
Posté par Bozo_le_clown . Évalué à 3.
[^] # Re: sonntag
Posté par el_mickey . Évalué à 1.
[^] # Re: sonntag
Posté par Bozo_le_clown . Évalué à 2.
Faut pas s'etonner qu'on arrive jamais à s'échanger quoi ce soit.
[^] # Re: sonntag
Posté par TeXitoi (site web personnel) . Évalué à 2.
[^] # Re: sonntag
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: sonntag
Posté par Mildred (site web personnel) . Évalué à 1.
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 . Évalué à 4.
[^] # Re: sonntag
Posté par Mildred (site web personnel) . Évalué à 3.
Donc moi, je vote Lisaac.
Après pour IsaacOS, je ne me prononce pas.
[^] # Re: sonntag
Posté par _flo_ . Évalué à 4.
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) . Évalué à 1.
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_ . Évalué à 2.
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) . Évalué à 3.
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_ . Évalué à 2.
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 . Évalué à 1.
http://en.wikipedia.org/wiki/Monitor_%28synchronization%29
[^] # Re: sonntag
Posté par Bozo_le_clown . Évalué à 2.
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 . Évalué à 1.
> 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 . Évalué à 3.
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 . Évalué à 2.
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 . É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.
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 ?
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) . Évalué à 2.
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 . Évalué à 2.
>>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 . Évalué à 2.
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 . Évalué à 1.
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) . Évalué à 2.
[^] # Re: sonntag
Posté par el_mickey . Évalué à 2.
Ou alors tu utilises le debugger intégré à ton IDE.
[^] # Re: sonntag
Posté par Tramo Piere . Évalué à 2.
Sauf en production.
[^] # Re: sonntag
Posté par el_mickey . Évalué à 1.
[^] # Re: sonntag
Posté par Tramo Piere . Évalué à 2.
[^] # Re: sonntag
Posté par Mildred (site web personnel) . Évalué à 1.
[^] # Re: sonntag
Posté par Mildred (site web personnel) . Évalué à 2.
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 . Évalué à 1.
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) . Évalué à 2.
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 . Évalué à 3.
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) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Dr BG (site web personnel) . Évalué à 2.
[^] # Re: sonntag
Posté par Dr BG (site web personnel) . Évalué à 3.
De toutes façons, ton ordinateur exécute les tâches séquentiellement (et pas récursivement).
[^] # Re: sonntag
Posté par Hal9000 . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 3.
[^] # Re: sonntag
Posté par Hal9000 . Évalué à 3.
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 . Évalué à 2.
[^] # Re: sonntag
Posté par Mildred (site web personnel) . Évalué à 1.
Pour paralleliser, ça serait bien quand même.
[^] # Re: sonntag
Posté par fmaz fmaz . Évalué à 2.
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) . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à -10.
> 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 . Évalué à -7.
[^] # Re: sonntag
Posté par darkleon (site web personnel) . Évalué à 3.
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) . Évalué à 2.
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) . Évalué à 2.
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) . Évalué à 2.
« 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) . Évalué à 1.
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) . Évalué à 1.
[^] # Re: sonntag
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: sonntag
Posté par darkleon (site web personnel) . Évalué à 1.
ç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) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: sonntag
Posté par GTof . Évalué à 1.
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) . Évalué à 3.
[^] # Re: Vaccination
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Vaccination
Posté par Lucas . Évalué à 3.
[^] # Re: Vaccination
Posté par Yusei (Mastodon) . Évalué à 2.
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 . Évalué à 1.
[^] # Re: Vaccination
Posté par TeXitoi (site web personnel) . Évalué à 1.
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) . Évalué à 3.
« 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) . Évalué à 2.
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) . Évalué à 2.
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 . Évalué à 1.
Un des responsables du projet pourrait-il nous expliquer ce choix?
[^] # Re: Vaccination
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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) . Évalué à 6.
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 . Évalué à 4.
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) . Évalué à 3.
« 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) . Évalué à 1.
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) . Évalué à 7.
Serait-il possible de l'avoir ? Y a-t-il d'autres benchmarks disponibles ?
[^] # Re: Benchmark
Posté par Ontologia (site web personnel) . Évalué à 2.
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 . Évalué à 4.
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) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Benchmark
Posté par Ontologia (site web personnel) . Évalué à 1.
« 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 . Évalué à 1.
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) . Évalué à 3.
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 . Évalué à 2.
$ 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 . Évalué à 3.
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) . Évalué à 2.
[^] # Re: Packaging pour distributions ?
Posté par Ontologia (site web personnel) . Évalué à 2.
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) . Évalué à 3.
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) . Évalué à 3.
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 . Évalué à 3.
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 . Évalué à 2.
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) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.