Je suis d'accord avec toi sur le fait que pas mal de technologies se sont imposées grace à la montée en puissance des ordis et qu'on est un peu sorti de l'époque où on codait plein de trucs à la main (encore qu'à mon avis, il reste des domaines ou l'assembleur est roi, même si ça reste cher à développer). Il n'empèche que (toujours à mon avis), avec un peu de rigueur et avec les technos actuelles, on peu diminuer par 10 la taille des programmes et les accellérer énormément.
A mon avis, il est des choses qu'on ne devrait pas considérer comme normales (telle la prog objet), mais normales dans certains cas (dans le cas de l'objet, c'est parfois un choix pas très intéressant par rapport à du procédural). Il me semble qu'une approche composants / légo comme OLE ou tu conçois en ajoutant tes briques venant de gauche et de droite ne convient pas à tous les cas (loin de là).
Tiens c'est pareil pour les RAD qui ne servent à faire que la partie 'chiante' de ton soft: dès que tu dois un peu personnaliser l'aspect RAD/composants ne sert plus mais en plus gène. Du coup: soit tu trouves un composant qui colle (bon courage, et surcoût), soit tu fais du porc (ex de base: tu rajoutes une boucle derrière celle que fait ton composant sur le même ensemble de données), soit tu refais tout à la main. Ok, je ne connais que des RAD proprios avec des composants fermés (et généralement buggués), dans du open source ça devrait être moins galère mais c'est ce que je vois tous les jours. Au final, tu te retrouves avec une appli comme le gestionnaire de fichier de gnome, avec 150000 appels à la même ressource.
Je n'ai pas vraiment voulu dire que ces trucs là c'est mal, je dis juste que ce n'est pas à mettre à toutes les sauces comme on a tendance à le faire actuellement, que ça à des inconvéniants même au niveau utilisateur final et que la lourdeur et la compléxité engendrée par ces mécanismes n'est pas justifiée. De plus, je continue à penser que ce n'est toujours pas au point à l'heure acutelle.
[^] # Re: Un peu comme MS-Windows 1
Posté par Toufou (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 2.
A mon avis, il est des choses qu'on ne devrait pas considérer comme normales (telle la prog objet), mais normales dans certains cas (dans le cas de l'objet, c'est parfois un choix pas très intéressant par rapport à du procédural). Il me semble qu'une approche composants / légo comme OLE ou tu conçois en ajoutant tes briques venant de gauche et de droite ne convient pas à tous les cas (loin de là).
Tiens c'est pareil pour les RAD qui ne servent à faire que la partie 'chiante' de ton soft: dès que tu dois un peu personnaliser l'aspect RAD/composants ne sert plus mais en plus gène. Du coup: soit tu trouves un composant qui colle (bon courage, et surcoût), soit tu fais du porc (ex de base: tu rajoutes une boucle derrière celle que fait ton composant sur le même ensemble de données), soit tu refais tout à la main. Ok, je ne connais que des RAD proprios avec des composants fermés (et généralement buggués), dans du open source ça devrait être moins galère mais c'est ce que je vois tous les jours. Au final, tu te retrouves avec une appli comme le gestionnaire de fichier de gnome, avec 150000 appels à la même ressource.
Je n'ai pas vraiment voulu dire que ces trucs là c'est mal, je dis juste que ce n'est pas à mettre à toutes les sauces comme on a tendance à le faire actuellement, que ça à des inconvéniants même au niveau utilisateur final et que la lourdeur et la compléxité engendrée par ces mécanismes n'est pas justifiée. De plus, je continue à penser que ce n'est toujours pas au point à l'heure acutelle.