Julien a écrit 27 commentaires

A quand un support de SQLAlchemy .. ?

L'intégrité des données c'est quand même un des points les plus importants dans un RDBMS, utiliser un RDBMS sans utiliser de contraintes ça me parait vraiment anormal (quoique ... j'ai découvert récemment le script postgresql de drupal et je suis tombé 4 fois).

mmh j'avais pas compris ça comme ça ..

apparement si.

"Elle me semble être particulièrement bien adapté pour le développement web (enfin, si vous visez à devenir le prochain twitter, Cassandra est probablement un meilleur choix). Certains prédisent même qu'elle pourrait prendre la place de MySQL dans ce domaine."

oui, je voulais bien entendu parler des bases de données relationnelles .. merci pr la rectification

Par pitié, qu'on arrête de comparer MongoDB, Cassandra, Redis, etc à une base de données. Comparer MongoDB avec une "vrai" base de données comme PostgreSQL c'est tout simplement un non sens.

100 % d'accord

"Personnellement, au risque de me faire arracher la tête par certains, je ne trouve pas Java plus lourd que Python"

-> tu plaisantes j'espère .. ?

OK Java est quasi aussi rapide que du C/C++, OK Java a de très bonnes specs (cf JDBC, etc) ... mais franchement au niveau de la consommation mémoire c'est parfois n'importe quoi (parfois je me demande même s'il y a un GC..). Par exemple la j'ai un Tomcat avec _une_ appli qui utilise Spring, Hibernate, Lucene ... paf 600 mo de RAM. Geoserver avec Jetty ? -> des pointes à 800 mo de RAM.

J'ai tendance à trouver que tout en Java est lourd et uber compliqué. Prends les EJB, Hibernate vs SQLAlchemy en Python, Spring vs Pylons, etc

C'est bien une mentalité de développeur Java ça ...
Franchement tu trouves ça normal une consommation mémoire de 500 mo par application ? Moi pas.

Encore une raison d'utiliser PostgreSQL au lieu de ce brol ...

Franchement, quel est encore l'intérêt du PHP aujourd'hui ? La syntaxe est immonde, les namespaces inexistants (pratique avec 1000+ functions), c'est lent, c'est pas threadsafe, ça supporte pas l'Unicode, les horribles cast implicite à la $foo = "1" + 1 .. excellent pour les effets de bords ...... je passe sur la syntaxe qui change à chaque nouvelle version majeure du langage, les innombrables fonctions qui font la même chose (les fonctions pour trier les tableaux par exemple, qui peuvent être remplacées par une seule fonction en Python), l'absence totale de standard, les jolis trous de sécu qui fleurissent toutes les semaines, etc etc

Je ne parle pas de la maintenabilité de la plupart des sites PHP .. avec du bon gros code imbriqué dans de l'HTML, un pur plaisir.

OK c'était pratique dans le temps pour faire des petits sites pour des neuneus qui n'y connaissent rien en programmation ... mais bon.

déjà pour comparer PHP au reste ...

Petite erreur de typo, je voulais parler des variables spéciales ($@, $_, ...) et non pas du @ ..

Grand amateur de Python également (j'en fais tous les jours au boulot), j'ai également fait un peu de Ruby.

Quelques critiques à propos de Ruby (je n'ai pas testé la version 1.9):
- C'est très lent (mais cette critique semble tomber à l'eau avec la version 1.9). Il est vrai que la vitesse d'exécution n'est pas primordiale dans ce genre de langage (Perl, Python, Ruby, ...) ... mais il y a des limites.
- Pas de support de l'Unicode, qui est pour moi _le_ plus gros problème de Ruby.
- J'ai retrouvé beaucoup de truc que j'aimais pas en Perl (notamment les variables @, ...), le langage est un peu "fouilli".
- Pas de multihéritage (mais on dirait que c'est le truc du moment à proscrire..)

Quelques avantages de Python:
- La librairie de base est bien plus fournie que celle de Ruby.
- Langage clair, propre et simple, et surtout qui ne change pas à chaque version (à l'exception de Python 3000), comme en Perl ou PHP. Je suis presque sur qu'un programme écrit il y a 10 ans tourne sans modifications sur les WM actuelles.
- La "communauté" Python met en place des petits "standard" (les PEP) légers comme DBAPI, WSGI, ...
- "There is only one way to do it"

Et puis on trouve vraiment d'excellentes libraires comme Pylons, SQLAlchemy, Genshi, ... on a vraiment plus de choix qu'en Ruby.

Les principales critiques que j'entends toujours à propos de Python:
- L'indentation: on aime ou on aime pas..
- Il faut mettre "self" partout: oui, "explicit is better than implicit". Je trouve ça plus lisible d'accéder à une variable (ou méthode) de l'objet via "self.x" plutot que betement "x"
- Il n'y a pas de support des variables privées: oui et non. On peut créer des variables à peu près privée avec __foo, mais la philosophie de Python est plutot "si vous ne voulez pas accéder à une variable privée, n'y accéder pas et puis c'est tout". De plus ce n'est, pour moi, pas le plus important en POO. Quand on regarde la majorité des programmes Java, on a en général un setVariable() et un getVariable() qui contiennent en général une ligne avec une assignation pour le premier et un return pour le 2ème .. De plus Python a un concept de "properties" (ala C#) qui permet de faire ça de manière élégante.

Pour finir, je me demande aussi si Ruby aurait autant de succès aujourd'hui si Ruby on Rails n'avait pas existé (... d'ailleurs je me demande toujours comment ce framework a autant de succès tant il est inintéressant et mal foutu ...)

C'est une des nombreuses raisons pour lesquelles j'aime Python. A l'exception de Python 3000 qui sera vraiment la première version qui sera backward incompatible, un script écrit il y a 10 ans tournera toujours sans problèmes (ou alors avec des corrections vraiment mineures) sur les versions d'aujourd'hui.
Sans vouloir troller, je pense que PHP occupera de moins en moins de part de marché dans le futur, quand on voit tout les problèmes et les incohérences de ce "langage" ...

> Bash, sed , awk ?

-> Python !

rm -rf / en root, c'est radical !

N'oublions pas non plus le non support de l'Unicode qui est vraiment un vrai problème et que de nombreuses librairies sont encore au stade de l'alpha / beta (je pense notamment au driver de PostgreSQL).
Concernant le langage en lui même, c'est mieux que du Perl, mais ça ne reste pas aussi lisible que du Python, et je trouve aussi dommage qu'ils aient repris certains trucs "sales" de Perl (notamment les variables "spéciales" $...) ...

omg LOL @#çLAWLAWL @l#!ç

l'important avec la drogue c'est d'arrêter tot

iptables ça s'installe ...

sauf que Zope + Postgresql c'était pas très au point qd j'avais testé (Zope 2.7 + Psycopg + Postgresql 7.4 à l'époque).

Le pb de toutes ces solutions c'est les performances par rapport à un SGBRD classique tel quel Postgresql (de loin le meilleur serveur SQL à mes yeux). Quand on voit les performances de ZODB (Zope) ...

"Il suffit de quelques minutes d'utilisation pour constater qu'une application sous Zope va vite, vraiment vite..."

Tu rigoles la j'espère ... ?

>Du coup, je continuais à utiliser le duo PHP/MYSQL pour les >développements web

Personnellement je préfère de loin le couple Postgresql / Python / Mod_Python / Clearsilver ... (évidemment il faut écrire des handlers ce qui est peut-être un peu plus compliqué...)

>Et je tombe sur ZPT. Je pousse un peu plus loin ma lecture et je >comprends que ce langage de template est vraiment intéressant.

Je suis désolé, mais quand je vois des choses comme :

<div metal:fill-slot="main" id="content-news"
tal:define="results python:container.portal_catalog(portal_type='News Item',sort_on='Date',sort_order='reverse',review_state='published');
results python:[r for r in results if r.getObject()];
Batch python:modules['Products.CMFPlone'].Batch;
b_start python:request.get('b_start',0);
portal_discussion nocall:here/portal_discussion;
isDiscussionAllowedFor nocall:portal_discussion/isDiscussionAllowedFor;
getDiscussionFor nocall:portal_discussion/getDiscussionFor;
home_url python: mtool.getHomeUrl;
localized_time python: modules['Products.CMFPlone.PloneUtilities'].localized_time;">


<form name="searchresults" action="" method="post" tal:condition="results"
tal:define="batch python:Batch(results, 15, int(b_start), orphan=1)">

(...)

c'est incompréhensible et ça n'a rien a faire dans un template ... (et je n'ai pas pris le pire exemple niveau illisibilité).
Alors peut-être que ça a été amélioré dans Plone 2.1, peut-être que les developpeurs de Plone n'utilise pas ZPT comme il faut, ... ?

>j'avais souvent l'impression de recoder plus ou moins les mêmes >choses

mouais ... pourquoi ne pas te faire une petite API personnelle, bien organisée en classes .. ?
J'avais aussi ce problème au début, mais par après je me suis fait des classes pour l'authentification des utilisateurs, des classes pour les menus, etc

>il m'était (peut être par incompétence) difficile d'organiser >correctement mon projet au niveau de la stucture du code >source...

ça ça vient avec la pratique :) Personnellement j'essaie d'implémenter un espèce de modèle MVC avec mod_python: un handler qui intercèpte les actions, qui dispatche vers un modules (souvent une classe par page), ces modules appellent mes classes de bases, et enfin me génère une structure HDF qui j'affiche avec Clearsilver. Ainsi tout est bien séparé (partie structure et logique), et j'ai des templates propres.

>Maintenant, une question reste à élucider : pourquoi il est aussi >difficile "d'entrer" dans la technologie Zope ? manque de >communication ? mauvaise documentation ? sujet trop abstrait ?

- Améliorer la ZMI serait déjà pas mal
- Réorganiser l'API qui est un vrai bordel
- Faire quelque chose pour améliorer la rapidité (apparement ya des progrès la dessus)

La première impression que j'ai eu avec Zope c'est que "c'est une grosse usine à gaz où il y règne un bordel assez conséquent"

voila ... ceci dit je n'ai _pas_ testé Zope > 2.6 ni Plone 2.1, donc ça c'est peut-être amélioré ça je ne dis pas :)