GC > En fait, je trouve que la réflexion de Folco est très juste. Mais avec un bémol : la conversion de Ruby|PHP|Python vers SQL est un problème beaucoup plus simple que la conversion du C vers de l'ASM : pas de soucis d'allocations de registre, de détection de code mort, d'optimisations qui vont déplacer ou modifier des pans entiers de code. Ça reste essentiellement de la réécriture, presque mot à mot.

Ensuite, tu ne parles que de choses compliquées en SQL. Certes, les choses compliquées existent mais ce n'est pas le plus courant. Même avec des modèles assez simples, on peut faire plein, plein de choses… Faire ses choix en utilisant uniquement les cas rares n'est pas forcément la meilleure idée. Je ne connais pas Ruby/RoR ou PHP/Doctrine, mais en Python/Django, tu peux faire l'équivalent de l'ASM inline en C : au lieu de définir la table depuis le Python, tu utilises une table SQL existante et tu associes toi-même chaque colonne à un champ Python. Pour les requêtes, il y a la même chose : faire la requête en SQL pur et récupérer soit des résultats bruts, soit des objets Python correctement peuplés (si tu débrouilles pour que la requête renvoie des résultats au bon format).
Je trouve vraiment dommage de se passer d'un outil qui peut faciliter la vie 99% du temps à cause du 1% de cas compliqués (alors qu'on peut utiliser les deux en même temps : l'ORM pour les cas simples, le SQL brut pour les cas compliqués), surtout que le temps humain est souvent la ressource critique qu'il faut optimiser.

Pour finir, oui, le SQL est assez simple… sauf qu'il y a autant de SQL que de bases de données, ce qui complique lourdement la tâche quand tu veux faire un code indépendant de la base.