Introduction décente à l'orienté objet ?

[pankkake]

Bah j'ai bien vu une perte de performance après une multiplication par 6 du coût matériel.

Tout ça parce qu'une boîte préfère acheter du matos plutôt que de dépenser un peu de temps humain pour comprendre ce qui se passe (on peut remercier la fiscalité en partie).

La dauberie de Java c'est parce que sur ma machine à moi, pour faire un Hello World, c'est lent.

Je n'ai absolument rien à foutre des benchmarks, des traitements de milliers de données, la moindre application Java a une sorte de retard intégré par rapport à toute autre application. D'ailleurs je suis très fier de ne plus avoir Java sur aucune de mes machines (et faire tourner LibreOffice sans).

[Noob]

En intégration, sur des Xeon E5, j’ai déjà du faire du taf de relativement bas niveau pour rendre le transformateur lock-free, ça scale quasi-linéairement jusqu’à 16 threads en exploitant l’hyperthreading, au delà ça chie un peu à cause de la bande passante mémoire…

 

En production, sur une machine neuve hors de prix, avec des Xeon E7 tous neufs, paf, c’est plus lent qu’en dev par thread (pas surprenant), mais c’est également moins scalable (arghh), résultat, la machine de dev a 6k€ va plus vite que la machine de prod a 40k€, youpy.

 

1. Combien de thread sur le xeon E5 ? Parce que la première limite à laquelle je pense c'est surtout le nombre de thread par proc.

Par contre pour le E7 versus E5 ou machine de dev je veux bien que tu dises ce qui allait pas, par mp s'il faut...

[Poil à gratter]

Ils peuvent au contraire être fiers. PHP est un moteur de template devenu géant du Web. L'épisode de Facebook a au contraire prouvé que PHP tient la charge même sur des projets démesurés. La contribution de Facebook n'est pas une gifle.

Mouais, ils ont du écrire un pré processeur pour transformer leur code PHP en C/C++, tellement les performances de PHP sont bonnes. Maintenant ils sont en train d'écrire une VM pour PHP (le HHVM dont a parle neuneu2k), je leur souhaite bien du courage... Mon avis c'est que Facebook serait bien plus performant (re)écrit en Java, mais comme ils ont des tonnes de code en PHP, et une batterie de développeurs seniors PHP difficile a recycler, ils continuent avec leur PHP.

 

Mais e problème de scalabilite de PHP/Python/Ruby/Perl/JavaScript - et de tous les langages faiblement types en général - c'est pas vraiment sur les performances mais plutôt sur le nombre de gens qu'on peut faire travailler en parallèle sur une application complexe sans que ca deviennent un cauchemar. Pareil pour le refactoring ou le tooling, c'est pas franchement le point fort de ces langages.

[pankkake]

C/C++

Terme qui n'a aucun sens.

Mais e problème de scalabilite de PHP/Python/Ruby/Perl/JavaScript - et de tous les langages faiblement types en général - c'est pas vraiment sur les performances mais plutôt sur le nombre de gens qu'on peut faire travailler en parallèle sur une application complexe sans que ca deviennent un cauchemar. Pareil pour le refactoring ou le tooling, c'est pas franchement le point fort de ces langages.

lol le marketing bidon de Sun/Oracle

Sinon bravo a Java pour arriver, en tant que langage compilé qui a 5% des fonctionnalités d'un langage interprété (mais au moins destiné aux adultes), à des performances décentes dans un benchmark.

[Poil à gratter]

Terme qui n'a aucun sens.

 

 

 

lol le marketing bidon de Sun/Oracle

Sinon bravo a Java pour arriver, en tant que langage compilé qui a 5% des fonctionnalités d'un langage interprété (mais au moins destiné aux adultes), à des performances décentes dans un benchmark.

Bof, je sais pas si ca génère du C++ pur, ou un mélange de C/C++

 

Mais ca n'a rien de marketing bidon de dire que coordonner des développements en utilisant des langages dynamiques et faiblement types est beaucoup plus dur qu'avec des langages compiles et fortement types. Il y a plein de raisons objectives derrière, et je suis toujours surpris de voir des gens affirmer sans ambages qu'il est aussi facile de réaliser des développements d'envergure et de qualité industrielle avec des langages comme Ruby ou Python que Java ou C#.

 

 

Évidemment on va trouver quelques exceptions, par exemple Eve Online, écrit - partiellement - en Python, cote performances. Cote taille et nombre de contributeurs élevés, on a Puppet ecrit en Ruby: 300K LOC et 244 contributeurs. M'enfin ca reste l'exception, et en entreprise c'est encore plus rare. Et on attend toujours l'équivalent d'un Excel ou d'un Firefox écrit dans un langage dynamique.

 

PS: je sais pas pourquoi le forum décide de fusionner les quotes...

[Nirvana]

Pour avoir utilisé temporairement OKCupid, j'ai toujours trouvé leur site rapide et performant, mais je ne sais pas si leur choix de langages en est la cause

 

 

At OkCupid, we don't do all our programming in C++. We also use:
 

• Python - we love Python and use it for offline reporting and maintenance scripts
• PHP - for a few handful of simple admin pages
• OkPub - a templating language our front-end coders use. It looks a lot like django's, but with some big improvements.

Still, C++ is our language of choice for programming our web services.  There are a few reasons for this:

1. we like type safety when programming large applications
2. we prefer async over multi-threaded programming, and we have a C++ rewriter tool called TAME which makes high performance async programming very easy.
3. we never really considered .NET languages because we don't have experience with administering MS software
4. ...and most important, performance.

To illustrate point #4 with an example: when a user performs a match search on OkCupid, we have to do the following:

• retrieve (from somewhere not the DB) their question answers, their ideal match's answers, and their question importances. On average, each user on OkCupid has 250 questions answered in 3 parts.
• figure out who qualifies for their search, typically a very complicated query across a few million users. On average, tens of thousands of people qualify, and we need to figure out who they are without hitting the DB.
• calculate a match percentage between the searcher and each candidate, which involves thousands of arithmetic operations on the intersections of their questions. Even with a massive distributed cache, the hit rate is well under 50%. Therefore, every single match request on OkCupid involves many millions of computations.
• sort all the results on a variety of metrics mashed together (last login, match percentage, distance, etc.)
• publish a page into our templates and return that to the user

This match request, as I describe above, doesn't just happen when someone explicitly visits www.okcupid.com/match, it also happens every few pages of a session in the background, so we can recommend new users in the left margin of the site. It also happens during newsletter generation, quiver (daily match) generation, etc. All said, we handle a couple hundred of those match requests every second, and each one, despite being a distributed problem involving many machines, low cache-hit rate, and serious CPU work, typically takes around 30 milliseconds.

Match is just one example of this kind of problem. We do a lot of analysis on every page we don't talk about publicly, and C++ combined with OkPub = a very pleasant combination of speedy development, easy site changes, and extremely high performing services.

From a sysadmin standpoint: we're currently running 6 cheap webservers and they each comfortably handle over 500 non-image HTTP requests per second during peak time, including the fact that they're highly dynamic and doing all that templating work for each reply.

While I stand by everything I said above, I wouldn't recommend using C++ for most websites for a variety of reasons. A common and valid complaint about C++ is that C-style pointers and manual memory management result in dangling pointers, wild writes, and memory leaks.  So C++ is only an option if paired with extensive use of a good automatic memory management library, such as Boost's referenced-counted shared pointers. In practice, cycles induced by reference-counting are extremely rare. (On the contary, memory leaks induced by caches that grow out of control, that would never be garbage collected in even a sophisticated reclamation scheme, are common!).

Some other issues with C++:

• fewer good libraries for web work
• basically no community, unlike PHP, RoR, and Python
• fewer available devs
• waiting for compiles...and waiting...

Typically when building a website you should postpone performance concerns until later and just get it built as fast as possible while keeping it easy to change.  We felt OkCupid was special because of its complexity from the beginning, so we took this unusual route.

 

[L'affreux]

Mouais, ils ont du écrire un pré processeur pour transformer leur code PHP en C/C++, tellement les performances de PHP sont bonnes.

Donc c'est un moteur de templates devenu langage de programmation, conçu au départ pour des projets modestes, et qui montre ses limites dans le cas d'un site géant dans lequel le monde entier a un compte. Si ce n'est pas une réussite, il faut m'expliquer. Certes ça ne fait pas de PHP la meilleure techno pour les projets géants, mais le cas de Facebook ajoute à la crédibilité de PHP. Les projets plus légers que Facebook sont finalement assez nombreux.

[neuneu2k]

Donc c'est un moteur de templates devenu langage de programmation, conçu au départ pour des projets modestes, et qui montre ses limites dans le cas d'un site géant dans lequel le monde entier a un compte. Si ce n'est pas une réussite, il faut m'expliquer. Certes ça ne fait pas de PHP la meilleure techno pour les projets géants, mais le cas de Facebook ajoute à la crédibilité de PHP. Les projets plus modestes que Facebook sont finalement assez nombreux.

 

Comme je le disais, on ne peu pas juger une techno selon un seul critère de toute façon, l'outillage, la plateforme, l’écosystème  la communauté de développeurs, sont des facteurs au moins aussi importants que le langage.

[Poil à gratter]

Donc c'est un moteur de templates devenu langage de programmation, conçu au départ pour des projets modestes, et qui montre ses limites dans le cas d'un site géant dans lequel le monde entier a un compte. Si ce n'est pas une réussite, il faut m'expliquer. Certes ça ne fait pas de PHP la meilleure techno pour les projets géants, mais le cas de Facebook ajoute à la crédibilité de PHP. Les projets plus légers que Facebook sont finalement assez nombreux.

 

Pas vraiment non, le precompiler ne rend pas PHP meilleur, c'est toujours le même langage avec les même défauts. Ça permet juste d'atteindre des performances acceptables en production. C'est sur que le succès de Facebook a apporte de la crédibilité a PHP, m'enfin on partait de très loin quand même. Et puis attention: Facebook n'est évidemment pas écrit 100% en PHP. Je ne suis pas dans le secret des dieux mais a mon avis hormis l'interface utilisateur, on doit rapidement retomber sur du C++ et du Java pour tout ce qui est backend (et Erlang pour le chat).

 

Le problème de PHP c'est qu'il n'y a eu aucune réflexion sur le langage en lui-même, et en gros pour résumer c'est un thin wrapper pour des bibliothèques écrites en C. C'est assez flagrant quand on regarde le nom des fonctions des différentes extensions, qui sont en gros les mêmes que ceux des librairies en C. Exemple avec MySQL:

 

https://github.com/php/php-src/blob/master/ext/mysql/php_mysql.c

 

Du coup ca donne une API hétéroclite, faite de bric et de broc, avec des extensions d'un niveau de qualité très variable, et des performances de merde parce que c'est une implémentation très naïve et qu'il n'y a aucun moyen d'ajouter des niveaux d'indirections dans ce merdier. Enfin bref, je vais pas m'étendre plus que ca sur le sujet, c'est de l'histoire ancienne pour moi PHP  

 

Même si j'aurais rien contre le fait de développer des trucs très cibles en PHP, j'ai bien une ou deux idées en tête, en particulier avec Quercus:

http://quercus.caucho.com/

[pankkake]

Le PHP est un langage de nihiliste, le Java un langage de bureaucrate.

[L'affreux]

Du coup ca donne une API hétéroclite, faite de bric et de broc, avec des extensions d'un niveau de qualité très variable, et des performances de merde parce que c'est une implémentation très naïve et qu'il n'y a aucun moyen d'ajouter des niveaux d'indirections dans ce merdier. Enfin bref, je vais pas m'étendre plus que ca sur le sujet, c'est de l'histoire ancienne pour moi PHP

Pour moi c'est Java l'histoire ancienne. J'ai quitté Java il y a trois ans avec soulagement. Avec Java et ses frameworks le programmeur est tellement cadré qu'il sera bientôt lui-même un robot. J'ai choisi PHP pour l'unique raison qu'il est massivement déployé sur les hébergements à bas cout, mais j'aime bien la naïveté de PHP justement, c'est une garantie que l'écosystème restera léger.

Je suis convaincu que les frameworks PHP copiant Java (Symfony…) font fausse route en cumulant les inconvénients des deux mondes.

[neuneu2k]

Pour moi c'est Java l'histoire ancienne. J'ai quitté Java il y a trois ans avec soulagement. Avec Java et ses frameworks le programmeur est tellement cadré qu'il sera bientôt lui-même un robot. J'ai choisi PHP pour l'unique raison qu'il est massivement déployé sur les hébergements à bas cout, mais j'aime bien la naïveté de PHP justement, c'est une garantie que l'écosystème restera léger.

 

 

La vision fordiste de beaucoup de managers IT fait que Java et C# sont utilisés dans un cadre hyperstructurant, ça à un sens pour les développeurs "business" pour des raisons de lisibilité et de maintenabilité, mais c'est hyper chiant de se retrouver dans le rôle du développeur business en question quand le business est pensé par un tiers et qu'on n'est qu’un traducteur qui devrait en effet être remplacé par un robot (quand on traite les développeurs comme des robots, c’est de la perte pure de payer 400+€ par jour pour du travail de robot…), c'est indépendant du langage et dû à l'organisation, mais le résultat est que oui, la majorité des développements en java sont cadrés.

 

Je suis convaincu que les frameworks PHP copiant Java (Symfony…) font fausse route en cumulant les inconvénients des deux mondes.

 

+1

[h16]

La vision fordiste de beaucoup de managers IT fait que Java et C# sont utilisés dans un cadre hyperstructurant, ça à un sens pour les développeurs "business" pour des raisons de lisibilité et de maintenabilité, mais c'est hyper chiant de se retrouver dans le rôle du développeur business en question quand le business est pensé par un tiers et qu'on n'est qu’un traducteur qui devrait en effet être remplacé par un robot (quand on traite les développeurs comme des robots, c’est de la perte pure de payer 400+€ par jour pour du travail de robot…), c'est indépendant du langage et dû à l'organisation, mais le résultat est que oui, la majorité des développements en java sont cadrés.

 

Et ils le sont tellement qu'ils sont devenus trop coûteux. Sans compter que plus on s'éloigne du métal, plus on voit apparaître de "do it yourself" pour compenser, et de bricolages pour contourner la mise en place de projets lourdingues.

[neuneu2k]

Et ils le sont tellement qu'ils sont devenus trop coûteux. Sans compter que plus on s'éloigne du métal, plus on voit apparaître de "do it yourself" pour compenser, et de bricolages pour contourner la mise en place de projets lourdingues.

Oui, mais ce n'est pas une fatalité, on ne peut juste pas se passer d'avoir des gens qui maîtrisent la full stack.

Avoir une armée de développeurs business qui ne voient que les couches hautes n'est pas un problème en soi, s'en contenter l'est déjà plus, payer pour des gens qui n'ont ni la connaissance/découverte du besoin, ni de valeur ajoutée technique, elle est la l'aberration qui mène a la lourdeur.

Mais ce n'est fondamentalement pas un problème technique, c'est un problème de management.

[L'affreux]

c'est indépendant du langage et dû à l'organisation, mais le résultat est que oui, la majorité des développements en java sont cadrés.

Ce n'est pas indépendant. Il me semble que les bonnes pratiques de Java, c-à-d. toujours factoriser, toujours abstraire un niveau plus haut, mènent aux frameworks Java et à un cadrage toujours plus strict du métier de programmeur. C'est de l'industrialisation. D'artisan créateur dans un atelier, le programmeur devient ouvrier spécialisé dans une usine. Je comprends bien l'évolution, je mesure sa valeur, sauf que le nouveau métier ne me plait pas. Et je reste sur l'ancien, même s'il faut pour cela revenir à des technologies elles-mêmes plus artisanales.

[L'affreux]

maîtrisent

Au fait, est-ce volontairement que vous restez sur l'ancienne orthographe ? Je dis "vous" parce que h16 dans ses billets c'est pareil.

[pankkake]

Je suis convaincu que les frameworks PHP copiant Java (Symfony…) font fausse route en cumulant les inconvénients des deux mondes.

Ah complètement, Symfony 2 pour moi a perdu tout intérêt.

[Yozz]

C'est sympa de voir un fil que j'ai lancé il y a plus de trois ans continuer à vivre. Je suis toujours aussi limité en OOP, mais ça ne m'a pas empêché de livrer mon PC-Banking

[Nirvana]

Me revoilà à devoir faire un nouveau projet (Java + XML) pour dans 5 jours. Je vous demanderai éventuellement de l'aide si je bloque : http://pagesperso-systeme.lip6.fr/Jean-Francois.Perrot/inalco/XML/IM12/Projet/ProjetXML12.html

[Nirvana]

Bon, j'ai réussi la première étape, qui consiste à prendre un fichier texte en entrée et à cracher du XML en sortie, seulement le résultat s'affiche dans la console. Comme l'énoncé est ambigü, je me demande s'il ne faut pas aussi écrire la sortie dans un fichier XML. Evidemment, on n'a pas vu comment manipuler des fichiers à part dans des bouts de code donnés tels quels par les profs, donc je ne sais pas s'il y a une méthode (dans tous les sens du terme) simple pour faire ça.

 

Donc voilà mon code (à 90% déjà fourni par le prof) et désolé pour tous les commentaires :

 

package fr.crim.a2012.tt2xml0;

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.Writer;

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.transform.OutputKeys;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;

import org.w3c.dom.DOMImplementation;
import org.w3c.dom.Document;
import org.w3c.dom.DocumentType;
import org.w3c.dom.Element;

public class TT2XML0 {

    /*
     * Méthode de service - Ici, méthode de classe - Ecrit le texte de sortie
     */
    public static void sortir(Document doc, Writer out) throws Exception {

        /*
         * Acts as a holder for a transformation Source tree in the form of a
         * Document Object Model (DOM) tree.
         */
        DOMSource src = new DOMSource(doc);

        /*
         * Acts as an holder for a transformation result, which may be XML,
         * plain Text, HTML, or some other form of markup.
         */
        StreamResult res = new StreamResult(out);

        /*
         * An instance of this abstract class can transform a source tree into a
         * result tree.
         */
        Transformer trans = TransformerFactory.newInstance().newTransformer();

        trans.setOutputProperty(
                OutputKeys.DOCTYPE_SYSTEM,
                "http://pagesperso-systeme.lip6.fr/Jean-Francois.Perrot/inalco/XML/IM12/Projet/tags.dtd");

        // Transforme la source XML en objet Result
        trans.transform(src, res);

    }

    /*
     * Méthode principale (méthode de classe) Crée un objet Document à partir
     * d'un fichier lu en entrée
     */

    public static Document lireText(BufferedReader entree) throws Exception {

        // DocumentBuilder est un parseur permettant l'analyse d'un fichier XML
        DocumentBuilder parseur = DocumentBuilderFactory.newInstance()
                .newDocumentBuilder();

        DOMImplementation domi = parseur.getDOMImplementation();

        // DTD
        DocumentType dtd = domi
                .createDocumentType(
                        "liste",
                        null,
                        "http://pagesperso-systeme.lip6.fr/Jean-Francois.Perrot/inalco/XML/IM12/Projet/tags.dtd");

        // L'interface Document représente un document XML entier
        Document listeTokens = domi.createDocument("http://crim.fr/ns/graph",
                "tags", dtd);

        // L'interface Element représente un élément dans un document XML
        Element liste = listeTokens.getDocumentElement();

        String ligne = entree.readLine();

        do { // Pour chaque ligne du fichier d'entrée

            // Capture des tokens dans un tableau de chaînes
            String[] tab = ligne.split("[ \t]+");

            String mot = tab[0]; // Mot
            String etiquette = tab[1].trim(); // Etiquette morphosyntaxique
            String lemme = tab[2].trim(); // Lemme

            // Crée un élément XML de type "token"
            Element el = listeTokens.createElement("token");

            // Ajoute l'élément "token" après la racine de l'arbre XML
            liste.appendChild(el);

            // Ajoute les trois attributs à l'élément "token" créé et ajouté
            el.setAttribute("mot", mot);
            el.setAttribute("etiquette", etiquette);
            el.setAttribute("lemme", lemme);

            // Passe à la ligne suivante
            ligne = entree.readLine();
        } while (ligne != null);

        return listeTokens; // Retourne l'arbre XML créé
    }

    // ------------------------------------------------------------------------

    public static void main(String[] args) {

        // Message d'erreur si trop ou pas assez d'arguments
        if (args.length != 1) {
            System.out.println("Il me faut un nom de fichier !");
        } else {

            try { // Exécution du programme

                // Lecture du fichier passé en argument
                BufferedReader entree = new BufferedReader(
                        new InputStreamReader(new FileInputStream(args[0]),
                                "ISO-8859-1"));

                // Création du fichier XML de sortie
                Document doc = lireText(entree);

                // OutputStreamWriter = Encodage des caractères de sortie
                Writer sortie = new OutputStreamWriter(System.out, "UTF-8");

                // Ecriture du flux de sortie
                sortir(doc, sortie);

            } catch (Exception e) {
                System.out.println("Erreur " + e.getMessage());
            }
        }
    }
}

Voilà le texte en entrée (format .txt, iso 8859-1) : http://pastebin.com/Uyp8rUSL ou en lien direct

 

Et la sortie que j'ai en console : http://pastebin.com/wSFGUbKJ

 

A la rigueur, je pourrais rediriger le flux de sortie en Bash sans problème, mais j'imagine que c'est "mieux" de le faire directement en Java...

[pankkake]

A la rigueur, je pourrais rediriger le flux de sortie en Bash sans problème, mais j'imagine que c'est "mieux" de le faire directement en Java...

Bah tu dois pas être loin, tu as réussi à ouvrir un fichier en lecture, fait l'équivalent en écriture.

Sinon là tu sors à la fois le résultat et les messages sur stdout, c'est mal ; il faudrait que les messages qui ne sont pas la sortie XML soient sur stderr (System.err en Java je suppose).

[neuneu2k]

StreamResult res = new StreamResult(new File("toto.xml"));

 

Désolé, j'ai fauté, j'aurai du le faire en 10 lignes avec une abstractfactory, mais il est tard

[Nirvana]

Bah tu dois pas être loin, tu as réussi à ouvrir un fichier en lecture, fait l'équivalent en écriture.

Sinon là tu sors à la fois le résultat et les messages sur stdout, c'est mal ; il faudrait que les messages qui ne sont pas la sortie XML soient sur stderr (System.err en Java je suppose).

 

Merci. Donc, à la place de

 

catch (Exception e) {
				System.out.println("Erreur " + e.getMessage());

je mets tout bêtement

 

catch (Exception e) {
				System.err.println("Erreur " + e.getMessage());

?

 

Edit : en tout cas ça compile.

[Nirvana]

 

StreamResult res = new StreamResult(new File("toto.xml"));

 

Désolé, j'ai fauté, j'aurai du le faire en 10 lignes avec une abstractfactory, mais il est tard

 

 

Nickel. Merci beaucoup !

[Rincevent]

 

StreamResult res = new StreamResult(new File("toto.xml"));

 

Désolé, j'ai fauté, j'aurai du le faire en 10 lignes avec une abstractfactory, mais il est tard

 

Et pour un n00b, c'est quoi la différence entre une UsineAbstraite et ça ?

[Sloonz]

Et pour un n00b, c'est quoi la différence entre une UsineAbstraite et ça ?

Elle se chiffre en euros quand tu es payé à la ligne.

[Noob]

 

StreamResult res = new StreamResult(new File("toto.xml"));

 

Désolé, j'ai fauté, j'aurai du le faire en 10 lignes avec une abstractfactory, mais il est tard

 

 

Tient c'est amusant comme il est plus simple d'écrire dans un fichier xml qu'autre chose.

Java et les I/O sur fichier c'est quand même la plaie.

[L'affreux]

Et pour un n00b, c'est quoi la différence entre une UsineAbstraite et ça ?

L'usine est abstraite alors tu l'implémentes toi-même en faisant appel à d'autres usines déjà implémentées qui font ce qu'il y a à faire.

[Rincevent]

Voilà qui ne m'avance guère, pour tout t'avouer.

[Noob]

http://en.wikipedia.org/wiki/Abstract_factory_pattern