C'est sur que lorsque l'on ne connait que java ou c# on a du mal à voir les problèmes.
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 Tramo Piere . En réponse à la dépêche Lisaac 0.12 en GPL v3. É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).