Donc, tu veux un objet sprite, donc la possibilité de gérer des collections de sprites, avec quelques méthodes comme HitTest, changement de gamma ou des choses de ce genre.
Attention, lisaac n'est pas un langage objet à classe : tu n'instancie pas un objet, tu le clone. Donc pas besoin de définir un héritage, etc...
Tu le clone, tu lui met ses octets de bitmap dedans et terminé.
Quand au pointeur, tu fait ma_liste_de_sprite : LINKED_LIST[SPRITE];
et ensuite tu y accède avec des opérations du style
1) Chacun pourra se contenter de se servir des briques de bases et de manipuler des bits si ça lui chante
2) Lisaac est un langage haut niveau conçu pour le système, il est très à l'aise avec ça
3) Le compilateur est le compilo objet le plus optimisé à l'heure actuel : il produit du code dont les performances atteignent celles du C.
4) Le haut niveau d'abstraction n'est là que pour simplifier la vie à ceux qui ne veulent pas rentrer dans les détails.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
>Ton projet me semble énorme, déjà. Combien d'années te seront nécessaires pour arriver à un niveau de fonctionnalités voisin de Directx ou SDL+ OpenGL+OpenAL ?
Je parle de spécification. Pour le code, on verra. De toutes façons, on code 15 fois plus vite en lisaac qu'en C++
Ensuite, je me concentrerais sur les fonctionnalités de base au début, reprenant des remarques intéressantes du style de celle d' Adrien Bustany là haut. Pour concurrencer SDL, on verra plus tard.
> Et partir sur un langage peu utilisé voir inconnu ne risque pas de t'amener beaucoup de développeurs tiers...
Ce langage est inconnu pour l'instant, mais ça va changer.
> Sans compter les bindings supplémentaires à faire pour que ta lib soit utilisable par d'autres langages plus populaires...
Ils se débrouilleront avec les sources C que le compilateur cracheras.
Cela dit, on pourra trouver d'autres solutions. Je ne cherche qu'à spécifier une librairie pour ce langage.
De toutes façon, importer une librairie construite dans un logique d'objet à prototype dans un langage à classe risque de poser quelques problème à la marge.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est codé à l'arache, c'est la première fois que je fais du java...
Merci :)
Petit problème, il me dit que this ne connait pas addKeyListener( ds la doc, il est dit que AddKeyListener est une méthode de JComponent), donc j'ai fait descendre Main de JPanel
import testuih2.IMovableDrawable;
import testuih2.FormDrawable;
/**
*
* @author montaigne
*/
public class Main extends JPanel implements KeyListener {
//private EcouteurClavier machin = new EcouteurClavier();
/** Creates a new instance of Main */
private JCanvas jc;
private FormDrawable rect,rect2;
//EcouteurClavier clav = new EcouteurClavier(jc);
public Main () {
//String[] truc = new String[2];
//m.main(truc);
jc = new JCanvas();
System.out.print ("Test Sortie out");
jc.setBackground(Color.WHITE);
jc.setPreferredSize(new Dimension(400,200));
Dimension dim =new Dimension(40,60);
rect = new RectangleDrawable(Color.RED,new Point(10,10),dim);
/** Handle the key released event from the text field. */
public void keyReleased(KeyEvent e) {
System.out.print ("KEY RELEASED: ");
System.out.print (e.getKeyChar ());
}
}
Qui ne marche pas :(
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
/** Handle the key released event from the text field. */
public void keyReleased(KeyEvent e) {
System.out.print ("KEY RELEASED: ");
System.out.print (e.getKeyChar ());
}
}
Je l'ai ensuite déclaré dans main
EcouteurClavier clav = new EcouteurClavier();
et mis jc.addKeyListener(clav);
Bam, même erreur :
Compiling 1 source file to
/home/montaigne/Developpement/Java/TestUIH2/src/testuih2/Main.java:52: non-static variable clav cannot be referenced from a static context
jc.addKeyListener(clav);
1 error
je remet donc static devant
static EcouteurClavier clav = new EcouteurClavier();
Ca compile mais ça donne rien.
Et moi qui doit présenter àça à un oral dans deux jours...
Merci pour tout quand même :) !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
/home/montaigne/Developpement/Java/TestUIH2/src/testuih2/Main.java:47: non-static variable this cannot be referenced from a static context
jc.addKeyListener(this);
1 error
Là je vois pas, faut que je fasse une classe à part ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je pense que Hurd est un OS conceptuellement très interessant sur plein de points, notamment la fin du noyau monolithique qui permet de modulariser a peu près tout et n'importe quoi.
La gestion des droits d'utilisateurs par exemple est très interessante, en ce qu'elle permet de se dépatouiller de n'importe quel situation en permettant de changer n'importes quels droits d'un processus.
Je ne liste pas les avancées conceptuels de Hurd, vous les connaissez mieux que moi.
Néanmoins, et pour rejoindre le titre provoquant que j'ai choisi, je pense AMHA que le Hurd a pour gros défaut d'être écrit en C.
Le C était un langage vraiment génial pour l'époque et l'est encore aujourd'hui. Mais son approche trop bas niveau, la nécessité de gérer les pointeurs, bref de tout faire à la main, implique que tous projet d'une certaine envergure atteint très vite ses limites et que l'on tombe très vite sur des bugs classique, stupide de surcroit.
Windows en est un bon exemple, et l'étude de ses sources (celle de Windows 2000 qui circulèrent sur le net) achève la preuve (ie. On se trouve devant un code très bien écrit, très bien commenté, où l'on se rend compte que c'est la complexité intrinsèque du projet qui est le problème majeur)
et surtout http://fr.wikipedia.org/wiki/Lisaac(...) (qui intègre des fonctionnalités étendues de programmation système) permettent maintenant de concevoir des systèmes d'exploitation objet écrit dans un langage de haut niveau, avec de très bonne performances.
L'absence de pointeurs dans ces langages, leurs librairies évoluées (collections, tables de hashages, types chaîne évolué, etc...), le multi héritage, etc... permettent de faciliter le développement et la maintenance.
Bref, Hurd bien que très intéressant et plus moderne que les OS installés est déjà dépassé.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est ce que les adultes autour d'eux ont pensés, et pour ceux qui faisaient partis de l'encadrement, leur ont expliqué.
Mais que veux-tu, à 20 ans maintenant certains ont un age mentale de 15...
Tu as beaucoup de développeurs comme ça. Ils font leur 35 h, ils se satisfassent de VB ou Windev, et ils ne veulent pas aller plus loin.
Le pire c'est que par leur nombre, ils sont une force économique de poids, on doit s'adapter à eux. Bien que je pense que fasse à la concurrence cette espèce devra disparaître..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je suis déjà tombé sur du code en Caml de 3 lignes en passant 10 minutes à comprendre.
Une fois compris, j'ai effectivement réalisé que cela prendreait 10 fois plus de code en langage impératif classique. Mais je pense que j'aurai compris avant.
Après c'est jutse une question d'habitudes
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Voilà, tu vis avec gens qui savent ce qu'est un compilateur. Mes camarades ne savaient pas ce que c'est (à part quelques uns heureusement).
Tout ce qu'il veulent savoir, c'est sur quel bouton cliquer....
Je pense que 50 % des devs sont à ce niveau, et sachant que les jeunes de 20 ans qu'on forme maintenant sont des "enfants de win95" ils n'ont jamais été confronté à un pc bien frustre, où il fallait tapper en basic, ou en ligne de commande.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Cependant, je doute qu'il soit vraiment plus facile d'apprendre les pointeurs en C.
C'est marrant tu met exactement le doigt sur un autre problème ;-)
Nous avons eu un projet C à rendre, le prof nous a demandé, en 3 semaines, d'écrire un mini interpréteur basic.
Sur 15 élèves de la promo (bts en alternance), seul 4 l'ont rendus. Les autres ont protestés, arguant que c'était "trop difficile, on ne comprend rien".
Je pense qu'un Caml habillé d'un bon environnement de développement avec la possibilité de le coupler avec pas mal de technos existante serait interessant. Il serait interessant que cet environnement de dev soit multi-langage de sorte à utilser caml sur des choses vraiment interessantes (traitement de données) et de laisser la tuyauterie technique (iUH) pour des langages plus conventionnels.
Après c'est une question de goût.
Un visual caml, j'acheterais.
Mais j'utilise caml quand je peux. En fait j'attend de récupérer le bouquin de Weiss et Leroy dont une nouvelle édition va peut être sortir afin de m'y mettre une seconde et dernière fois pour toute :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est vrai...
... Mais on peut difficilement remplacer un développeur chef de projet qui, au contact de l'entreprise cliente, peut analyser complètement et avec compétence les besoins, l'organisation, le métier de l'entreprise.
Pour moi un Indien fera surtout de l'écriture de composants.
Qui serviront aux troufions pour écrire leur logiciels.
Ou alors ils nous feront le codage de la fonction toto...
Ya donc des chance que ça se complémente à peu près
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je crois que tu vie dans un monde d'universitaires et/ou d'ingénieurs.
Je suis en train de terminer un BTS (honte à moi, oui), et j'ai eu autour de moi des élèves de niveau BTS pendant deux ans. Je peux te dire qu'ils ne seront jamais capable, à moins d'un miracle, de comprendre Ocaml. Enfin si, ils seraient "cérébralement "capables, mais ils sont incapable de faire l'effort, ça les interessera jamais.
Ce sont des gens qui ont du mal à maîtriser le concept de fonction, au niveau théorique. Ils ont beaucoup de mal à appréhender la programmation objet.
Ils ont déjà beaucoup de mal en algorithmique. C'est le seul point que leur expérience professionnelle améliorera.
La récursivité, c'est beaucoup trop difficile pour eux, ça les décourage.
Je n'ai pas cotoyé des gens stupide, loin de là, mais ils ne sont absolument pas curieux du tout.
Donc il feront du VB.net et des trucs de ce genre, ils vont mettre des années à comprendre l'objet.
Un bon langage pour eux, c'est VB6 et windev, voire Delphi pour l'élite (ya des pointeurs en delphi attention, et puis c'est objet Delphi !!)
Evidemment, Linux ils ne veulent pas en entendre parler. La ligne de commande leur fait peur et ça les obligerai à comprendre le système.
Mais déjà leur faire un avaler un truc du genre
let rec fact = function n -> if n=0 then 1 else n*fact(n-1);;
désolé, mais j'y crois pas.
Pour te donner une idée du niveau, ils ont mis deux jours à comprendre comment programmer une pile avec des pointeurs, dans un langage algorithmique style Pascal en français.
Deux jours plein, deux jours à 7 heures de cours par jour (!!!).
En deuxième année qui plus est, donc avec 1 ans de programmation derrière eux...
Des gens comme ça, il y en a plein, je ne suis pas certain que le développement soit leur point fort, ils sont surement plus compétent dans d'autres domaines.
Mais je répète ma conviction : Ocaml est réservé à un élite.
Pour le reste, je suis totalement d'accord avec toi : Des gens ouvert et capable d'appréhender l'embryon de théorie absolument nécessaire et motivé pour s'y mettre peuvent très bien le faire.
Mais quand tu sais qu'il y a plein d'entreprises qui choississent de ne pas utiliser J2EE parce que leur dev ne maîtrisent pas l'objet, tu te demande qui il reste poua apprendre un tel langage.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Comme je l'ai dit plus haut, les indéniables avantages de Ocaml sont ce qu'ils sont, mais moins 10 % des développeurs sont capable de le maitriser, alors que des langages comme Lisaac ou Eiffel, tu en as 30 % peut être.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je voudrai redescendre sur terre en rappellant que sur le marché du travail, au moins la moitié des développeurs ont un niveau BTS (et que le niveau BTS, je sais de quoi je parle, a un niveau très bas, ou tout élément théorique est absolument absent) et que beaucoup de ces pros ne sont même pas capable de programmer, conceptualiser en objet.
Caml, langage que je vénère, est à des années lumière du monde de ces gens là qui est fait de VB, Vb.net, et autre Windev.
Je ne suis même pas sûr qu'ils soient tous capables de développer en C#
Vous faites tous partis d'une élite, vous êtes curieux, mais des développeurs comme vous, il y en a peu.
Les gens auxquels je pense, ne comprendront jamais rien aux concepts qu'il y a derrière Caml, c''est beaucoup trop théorique pour eux.
Caml est génial mais restera cantonné dans le milieu de ceux qui peuvent comprendre.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Les performances de Smart Eiffel sont dus à la suppression de la liaison dynamique.
Dans tous les langages objets, l'accès à une méthode spécialisé sur plusieurs classes dans l'arbre d'héritage se fait par une liaison dynamique, plus exactement une VFT (Virtual Function Table).
En gros, on a une structure avec un pointeur sur fonction que l'on peut parfois mettre dans un tableau.
En assembleur ça donne des trucs du genre "call dword ptr [_adresse_de_la_fonction]", ce qui implique :
- Que l'inlining est très limité
- Que le processeur est obligé de vider son cache mais aussi de laisser tomber toutes ses prédictions de branchements.
Donc une chute des performances.
A ma connaissance, tous les langages objets sauf (Smart) Eiffel et Lisaac fonctionnent comme ça.
Avec l'algorithme du produit cartésien de Ole Agesen et Craig Chambers (à peu près innaplicable), l'algorithme de Dominique Colnet est le premier à réussir à supprimer la liaison dynamique.
Un algorithme de prédiction de type détermine les types possibles pour le receveur et les paramètres, ce qui donne lieu à un switch afin de traiter chaque cas.
En plus, on peut enfin faire de l'inlining et de la spécialisation de code.
Le problème de Smart Eiffel, c'est qu'il traite tous les cas de résolution de type, même ceux, qui, dans le code tel qu'on le possède ne pourront jamais survenir.
Lisaac est le premier compilateur à analyser tout son code et de déterminer les types possibles et de ne traiter qu'eux seuls.
Ca permet d'éviter plus de 84 % de switch.
L'inlining est encore facilité, ainsi que la spécialisation de code.
Résultat, un décodeur Mpeg1/2 algorithmiquement identique à un décodeur C, est plus lent de 1,9 % (pour 30 % de code en moins, langage objet de haut niveau oblige).
L'avenir est à mon avis aux langages objets dont le compilateur est doté d'un algorithme de suppression de la liaison dynamique.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
DSK est le réformiste typique qui est passé par l'extrême gauche, et qui au lieu de devenir un néolibérale d'extrême droite comme son copain Kessler, s'est dit que poursuivre une utopie se faisait petit à petit.
Ce type de réformisme est à court terme terne et peu paraître peu ambitieux, mais à long terme, le but est d'aller très loin.
Au vu de tes préoccupations, je te conseille vivement de lire "La voie humaine" de Jacques Attali qui propose une utopie vraiment interessante et absolument pas dans la lignée révolutionnaire sanguinaire qui est celle - vieille antienne - du marxisme.
Attali est typique de l'utopiste réaliste : avec Rocard il a monté une banque de micro-crédit consistant à prêter à bas taux des petites sommes d'argent (200 ¤) dans les pays pauvres afin d'aider les locaux à créer un commerce. C'est de l'humanitaire responsabilisant.
---
Tiens je tombe là dessus :
"C'est la Java ?
Le livre de Jacques Attali "Lignes d'horizon" a fait naître l'idée du langage Java (sorte d'esperanto du langage informatique) au cofondateur américain de Sun Microsystem, Bill Joy.
"
Marrant non ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: En tout cas merci
Posté par Ontologia (site web personnel) . En réponse au journal Spécifier une nouvelle librairie graphique. Évalué à 1.
Il ya plein de choses à faires, du code, faire avancer l'OS, le compilo, les nouveaux concepts, tout ça... ;o)
Donc n'hésite pas :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ma petite experience
Posté par Ontologia (site web personnel) . En réponse au journal Spécifier une nouvelle librairie graphique. Évalué à 3.
Attention, lisaac n'est pas un langage objet à classe : tu n'instancie pas un objet, tu le clone. Donc pas besoin de définir un héritage, etc...
Tu le clone, tu lui met ses octets de bitmap dedans et terminé.
Quand au pointeur, tu fait ma_liste_de_sprite : LINKED_LIST[SPRITE];
et ensuite tu y accède avec des opérations du style
(ma_liste_de_sprite.item i.hitTest).if {"Touché\n".print;};
Pour la problématique du niveau d'abstraction,
1) Chacun pourra se contenter de se servir des briques de bases et de manipuler des bits si ça lui chante
2) Lisaac est un langage haut niveau conçu pour le système, il est très à l'aise avec ça
3) Le compilateur est le compilo objet le plus optimisé à l'heure actuel : il produit du code dont les performances atteignent celles du C.
4) Le haut niveau d'abstraction n'est là que pour simplifier la vie à ceux qui ne veulent pas rentrer dans les détails.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Bindings
Posté par Ontologia (site web personnel) . En réponse au journal Spécifier une nouvelle librairie graphique. Évalué à 2.
L'objectif est de concevoir une nouvelle bibliothèque, conceptuellement.
Si tel était mon intention, je n'aurai pas posté ce journal :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Encore
Posté par Ontologia (site web personnel) . En réponse au journal Spécifier une nouvelle librairie graphique. Évalué à 2.
Je parle de spécification. Pour le code, on verra. De toutes façons, on code 15 fois plus vite en lisaac qu'en C++
Ensuite, je me concentrerais sur les fonctionnalités de base au début, reprenant des remarques intéressantes du style de celle d' Adrien Bustany là haut. Pour concurrencer SDL, on verra plus tard.
> Et partir sur un langage peu utilisé voir inconnu ne risque pas de t'amener beaucoup de développeurs tiers...
Ce langage est inconnu pour l'instant, mais ça va changer.
> Sans compter les bindings supplémentaires à faire pour que ta lib soit utilisable par d'autres langages plus populaires...
Ils se débrouilleront avec les sources C que le compilateur cracheras.
Cela dit, on pourra trouver d'autres solutions. Je ne cherche qu'à spécifier une librairie pour ce langage.
De toutes façon, importer une librairie construite dans un logique d'objet à prototype dans un langage à classe risque de poser quelques problème à la marge.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: J'aurai une source à te proposer
Posté par Ontologia (site web personnel) . En réponse au journal Pour un OUI ou pour un NON de transformation sociale pragmatique. Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un joli lapsus
Posté par Ontologia (site web personnel) . En réponse à la dépêche Discours de Renaud Dutreil aux Trophées du Libre. Évalué à 1.
ok je -> [ ]
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: modifie completement ton code
Posté par Ontologia (site web personnel) . En réponse au message J'arrive pas à récupérer un évenement clavier dans une fenêtre. Évalué à 1.
Merci :)
Petit problème, il me dit que this ne connait pas addKeyListener( ds la doc, il est dit que AddKeyListener est une méthode de JComponent), donc j'ai fait descendre Main de JPanel
Ce qui me donne le code suivant :
package testuih2;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.Point;
import java.awt.event.KeyListener;
import java.awt.event.KeyEvent;
import javax.swing.JPanel;
import testuih2.GUIHelper;
import testuih2.IDrawable;
import testuih2.JCanvas;
import testuih2.RectangleDrawable;
import testuih2.IMovableDrawable;
import testuih2.FormDrawable;
/**
*
* @author montaigne
*/
public class Main extends JPanel implements KeyListener {
//private EcouteurClavier machin = new EcouteurClavier();
/** Creates a new instance of Main */
private JCanvas jc;
private FormDrawable rect,rect2;
//EcouteurClavier clav = new EcouteurClavier(jc);
public Main () {
//String[] truc = new String[2];
//m.main(truc);
jc = new JCanvas();
System.out.print ("Test Sortie out");
jc.setBackground(Color.WHITE);
jc.setPreferredSize(new Dimension(400,200));
Dimension dim =new Dimension(40,60);
rect = new RectangleDrawable(Color.RED,new Point(10,10),dim);
//jc.addKeyListener(clav);
jc.addDrawable(rect);
this.addKeyListener(this);
GUIHelper.showOnFrame(jc,"test JCanvas");
for (int i = 1 ; i<35 ; i += 5)
{
int b;
rect.setPosition (new Point(rect.getPosition ().x+i,rect.getPosition ().y+i));
jc.repaint ();
}
}
/**
* @param args the command line arguments
*/
public static void main (String[] args) {
// TODO code application logic here
Main main = new Main();
}//main
public void keyTyped(KeyEvent e) {
System.out.print ("Event clavier trouvé");
System.out.print (e.getKeyChar ());
}
public void keyPressed(KeyEvent e) {
System.out.print ("KEY PRESSED: ");
System.out.print (e.getKeyChar ());
}
/** Handle the key released event from the text field. */
public void keyReleased(KeyEvent e) {
System.out.print ("KEY RELEASED: ");
System.out.print (e.getKeyChar ());
}
}
Qui ne marche pas :(
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Manque le addKeyListener ?
Posté par Ontologia (site web personnel) . En réponse au message J'arrive pas à récupérer un évenement clavier dans une fenêtre. Évalué à 1.
public EcouteurClavier () {
}
en
public EcouteurClavier (JCanvas j) {
j.addKeyListener (this);
}
Ca compile mais ça donne rien.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Manque le addKeyListener ?
Posté par Ontologia (site web personnel) . En réponse au message J'arrive pas à récupérer un évenement clavier dans une fenêtre. Évalué à 1.
Je suis allé voir la doc sur le addKeyListener, et je me suis rendu compte qu'il prenait un KeyListener l en argument.
J'ai donc repris mon objet ecouteurclavier
Je l'ai ensuite déclaré dans main
EcouteurClavier clav = new EcouteurClavier();
et mis jc.addKeyListener(clav);
Bam, même erreur :
Compiling 1 source file to
/home/montaigne/Developpement/Java/TestUIH2/src/testuih2/Main.java:52: non-static variable clav cannot be referenced from a static context
jc.addKeyListener(clav);
1 error
je remet donc static devant
static EcouteurClavier clav = new EcouteurClavier();
Ca compile mais ça donne rien.
Et moi qui doit présenter àça à un oral dans deux jours...
Merci pour tout quand même :) !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Manque le addKeyListener ?
Posté par Ontologia (site web personnel) . En réponse au message J'arrive pas à récupérer un évenement clavier dans une fenêtre. Évalué à 1.
/home/montaigne/Developpement/Java/TestUIH2/src/testuih2/Main.java:47: non-static variable this cannot be referenced from a static context
jc.addKeyListener(this);
1 error
Là je vois pas, faut que je fasse une classe à part ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Hurd a un gros défaut congénital
Posté par Ontologia (site web personnel) . En réponse à la dépêche Nouvelle avancée du port du Hurd sur L4. Évalué à 0.
Je pense que Hurd est un OS conceptuellement très interessant sur plein de points, notamment la fin du noyau monolithique qui permet de modulariser a peu près tout et n'importe quoi.
La gestion des droits d'utilisateurs par exemple est très interessante, en ce qu'elle permet de se dépatouiller de n'importe quel situation en permettant de changer n'importes quels droits d'un processus.
Je ne liste pas les avancées conceptuels de Hurd, vous les connaissez mieux que moi.
Néanmoins, et pour rejoindre le titre provoquant que j'ai choisi, je pense AMHA que le Hurd a pour gros défaut d'être écrit en C.
Le C était un langage vraiment génial pour l'époque et l'est encore aujourd'hui. Mais son approche trop bas niveau, la nécessité de gérer les pointeurs, bref de tout faire à la main, implique que tous projet d'une certaine envergure atteint très vite ses limites et que l'on tombe très vite sur des bugs classique, stupide de surcroit.
Windows en est un bon exemple, et l'étude de ses sources (celle de Windows 2000 qui circulèrent sur le net) achève la preuve (ie. On se trouve devant un code très bien écrit, très bien commenté, où l'on se rend compte que c'est la complexité intrinsèque du projet qui est le problème majeur)
Je crois que les recherches récentes sur les compilateurs, et en particulier
http://smarteiffel.loria.fr/(...)
http://www.loria.fr/~zendra/publications/oopsla97.ps(...)
et surtout http://fr.wikipedia.org/wiki/Lisaac(...) (qui intègre des fonctionnalités étendues de programmation système) permettent maintenant de concevoir des systèmes d'exploitation objet écrit dans un langage de haut niveau, avec de très bonne performances.
L'absence de pointeurs dans ces langages, leurs librairies évoluées (collections, tables de hashages, types chaîne évolué, etc...), le multi héritage, etc... permettent de faciliter le développement et la maintenance.
Bref, Hurd bien que très intéressant et plus moderne que les OS installés est déjà dépassé.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: OCaml (difficulté d'apprentissage)
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 1.
Mais que veux-tu, à 20 ans maintenant certains ont un age mentale de 15...
Tu as beaucoup de développeurs comme ça. Ils font leur 35 h, ils se satisfassent de VB ou Windev, et ils ne veulent pas aller plus loin.
Le pire c'est que par leur nombre, ils sont une force économique de poids, on doit s'adapter à eux. Bien que je pense que fasse à la concurrence cette espèce devra disparaître..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un petit test custom
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 1.
Une fois compris, j'ai effectivement réalisé que cela prendreait 10 fois plus de code en langage impératif classique. Mais je pense que j'aurai compris avant.
Après c'est jutse une question d'habitudes
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: OCaml (difficulté d'apprentissage)
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Tout ce qu'il veulent savoir, c'est sur quel bouton cliquer....
Je pense que 50 % des devs sont à ce niveau, et sachant que les jeunes de 20 ans qu'on forme maintenant sont des "enfants de win95" ils n'ont jamais été confronté à un pc bien frustre, où il fallait tapper en basic, ou en ligne de commande.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: OCaml (difficulté d'apprentissage)
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
C'est marrant tu met exactement le doigt sur un autre problème ;-)
Nous avons eu un projet C à rendre, le prof nous a demandé, en 3 semaines, d'écrire un mini interpréteur basic.
Sur 15 élèves de la promo (bts en alternance), seul 4 l'ont rendus. Les autres ont protestés, arguant que c'était "trop difficile, on ne comprend rien".
Je pense qu'un Caml habillé d'un bon environnement de développement avec la possibilité de le coupler avec pas mal de technos existante serait interessant. Il serait interessant que cet environnement de dev soit multi-langage de sorte à utilser caml sur des choses vraiment interessantes (traitement de données) et de laisser la tuyauterie technique (iUH) pour des langages plus conventionnels.
Après c'est une question de goût.
Un visual caml, j'acheterais.
Mais j'utilise caml quand je peux. En fait j'attend de récupérer le bouquin de Weiss et Leroy dont une nouvelle édition va peut être sortir afin de m'y mettre une seconde et dernière fois pour toute :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: OCaml, oui mais...
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 0.
... Mais on peut difficilement remplacer un développeur chef de projet qui, au contact de l'entreprise cliente, peut analyser complètement et avec compétence les besoins, l'organisation, le métier de l'entreprise.
Pour moi un Indien fera surtout de l'écriture de composants.
Qui serviront aux troufions pour écrire leur logiciels.
Ou alors ils nous feront le codage de la fonction toto...
Ya donc des chance que ça se complémente à peu près
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: OCaml (difficulté d'apprentissage)
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Je suis en train de terminer un BTS (honte à moi, oui), et j'ai eu autour de moi des élèves de niveau BTS pendant deux ans. Je peux te dire qu'ils ne seront jamais capable, à moins d'un miracle, de comprendre Ocaml. Enfin si, ils seraient "cérébralement "capables, mais ils sont incapable de faire l'effort, ça les interessera jamais.
Ce sont des gens qui ont du mal à maîtriser le concept de fonction, au niveau théorique. Ils ont beaucoup de mal à appréhender la programmation objet.
Ils ont déjà beaucoup de mal en algorithmique. C'est le seul point que leur expérience professionnelle améliorera.
La récursivité, c'est beaucoup trop difficile pour eux, ça les décourage.
Je n'ai pas cotoyé des gens stupide, loin de là, mais ils ne sont absolument pas curieux du tout.
Donc il feront du VB.net et des trucs de ce genre, ils vont mettre des années à comprendre l'objet.
Un bon langage pour eux, c'est VB6 et windev, voire Delphi pour l'élite (ya des pointeurs en delphi attention, et puis c'est objet Delphi !!)
Evidemment, Linux ils ne veulent pas en entendre parler. La ligne de commande leur fait peur et ça les obligerai à comprendre le système.
Mais déjà leur faire un avaler un truc du genre
désolé, mais j'y crois pas.
Pour te donner une idée du niveau, ils ont mis deux jours à comprendre comment programmer une pile avec des pointeurs, dans un langage algorithmique style Pascal en français.
Deux jours plein, deux jours à 7 heures de cours par jour (!!!).
En deuxième année qui plus est, donc avec 1 ans de programmation derrière eux...
Des gens comme ça, il y en a plein, je ne suis pas certain que le développement soit leur point fort, ils sont surement plus compétent dans d'autres domaines.
Mais je répète ma conviction : Ocaml est réservé à un élite.
Pour le reste, je suis totalement d'accord avec toi : Des gens ouvert et capable d'appréhender l'embryon de théorie absolument nécessaire et motivé pour s'y mettre peuvent très bien le faire.
Mais quand tu sais qu'il y a plein d'entreprises qui choississent de ne pas utiliser J2EE parce que leur dev ne maîtrisent pas l'objet, tu te demande qui il reste poua apprendre un tel langage.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: SmartEiffel
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: SmartEiffel
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Mais la publi qui répond à oopsla97 est en préparation.
Oui ça date, et personne dans l'industrie, ne semble l'utiliser
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: SmartEiffel
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 1.
Eiffel et Lisaac donc
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: OCaml, oui mais...
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 3.
Caml, langage que je vénère, est à des années lumière du monde de ces gens là qui est fait de VB, Vb.net, et autre Windev.
Je ne suis même pas sûr qu'ils soient tous capables de développer en C#
Vous faites tous partis d'une élite, vous êtes curieux, mais des développeurs comme vous, il y en a peu.
Les gens auxquels je pense, ne comprendront jamais rien aux concepts qu'il y a derrière Caml, c''est beaucoup trop théorique pour eux.
Caml est génial mais restera cantonné dans le milieu de ceux qui peuvent comprendre.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# SmartEiffel
Posté par Ontologia (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 7.
Dans tous les langages objets, l'accès à une méthode spécialisé sur plusieurs classes dans l'arbre d'héritage se fait par une liaison dynamique, plus exactement une VFT (Virtual Function Table).
En gros, on a une structure avec un pointeur sur fonction que l'on peut parfois mettre dans un tableau.
En assembleur ça donne des trucs du genre "call dword ptr [_adresse_de_la_fonction]", ce qui implique :
- Que l'inlining est très limité
- Que le processeur est obligé de vider son cache mais aussi de laisser tomber toutes ses prédictions de branchements.
Donc une chute des performances.
A ma connaissance, tous les langages objets sauf (Smart) Eiffel et Lisaac fonctionnent comme ça.
Avec l'algorithme du produit cartésien de Ole Agesen et Craig Chambers (à peu près innaplicable), l'algorithme de Dominique Colnet est le premier à réussir à supprimer la liaison dynamique.
Un algorithme de prédiction de type détermine les types possibles pour le receveur et les paramètres, ce qui donne lieu à un switch afin de traiter chaque cas.
En plus, on peut enfin faire de l'inlining et de la spécialisation de code.
Le problème de Smart Eiffel, c'est qu'il traite tous les cas de résolution de type, même ceux, qui, dans le code tel qu'on le possède ne pourront jamais survenir.
Lisaac est le premier compilateur à analyser tout son code et de déterminer les types possibles et de ne traiter qu'eux seuls.
Ca permet d'éviter plus de 84 % de switch.
L'inlining est encore facilité, ainsi que la spécialisation de code.
Résultat, un décodeur Mpeg1/2 algorithmiquement identique à un décodeur C, est plus lent de 1,9 % (pour 30 % de code en moins, langage objet de haut niveau oblige).
L'avenir est à mon avis aux langages objets dont le compilateur est doté d'un algorithme de suppression de la liaison dynamique.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Version argumentée
Posté par Ontologia (site web personnel) . En réponse au journal Pour un OUI ou pour un NON de transformation sociale pragmatique. Évalué à 2.
En 2002, entre les deux tours de la présidentielle, sur un site satelite du PS, il y avait deux entêtes de forums :
Le premier : "Si on analysait les raisons de notre échec ?"
0 commentaires
Le second " Je ne veux pas voter pour chirac !!!!!!!!!!"
500 commentaires.
Sur linuxfr, j'ai la joie de voir débâttre des gens ayant une formation scientifique et pour certain assez objectif et non fanatisés, comme Séverin.
Donc, j'aime bien discutter politique ici. Je défenderai toujours ce point de vue.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: J'aurai une source à te proposer
Posté par Ontologia (site web personnel) . En réponse au journal Pour un OUI ou pour un NON de transformation sociale pragmatique. Évalué à 2.
Ce type de réformisme est à court terme terne et peu paraître peu ambitieux, mais à long terme, le but est d'aller très loin.
Au vu de tes préoccupations, je te conseille vivement de lire "La voie humaine" de Jacques Attali qui propose une utopie vraiment interessante et absolument pas dans la lignée révolutionnaire sanguinaire qui est celle - vieille antienne - du marxisme.
Une présentation :
http://www.evene.fr/livres/fiche.php?id_livre=10761&topic=La_vo(...)
Attali est typique de l'utopiste réaliste : avec Rocard il a monté une banque de micro-crédit consistant à prêter à bas taux des petites sommes d'argent (200 ¤) dans les pays pauvres afin d'aider les locaux à créer un commerce. C'est de l'humanitaire responsabilisant.
---
Tiens je tombe là dessus :
"C'est la Java ?
Le livre de Jacques Attali "Lignes d'horizon" a fait naître l'idée du langage Java (sorte d'esperanto du langage informatique) au cofondateur américain de Sun Microsystem, Bill Joy.
"
Marrant non ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# J'aurai une source à te proposer
Posté par Ontologia (site web personnel) . En réponse au journal Pour un OUI ou pour un NON de transformation sociale pragmatique. Évalué à 0.
Pour continuer avec le même
tu trouveras un commentaire interessant où il répond à ses détracetrus sur son blog
http://www.blogdsk.net/dsk/2005/05/visionnez_le_dv.html#comments(...)
tu fait ctrl+f sur ton firefox favori en cherchant : Rédigé par: dsk
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker