Discussion :

[souviron34]

N'y a-t-il personne pour casser du sucre sur le dos de Fortran?

pourquoi vouloir casser du sucre sur Fortran ?

Langage parfaitement adapté à ce pourquoi il est utilisé, toujours largement répandu, et surtout stable (une révision tous les 10 ans).


J'attend en rigolant qu'est-ce que vous ferez dans 20 ans de vos programmes ayant demandé je ne sais combien de ressources et d ebudget aujourdhui, et que vous voudrez continuer à maintenir...

[Lyche]

Pour ma part, c'est PHP, ce "langage" est un ersatz de langage. Aucune structure, une gestion des objets très critiquable. C'est un langage de bidouille par excellence qui ne rentre pas dans ma conception du développement.
Et puis ce mélange html/code je trouve ça grotesque et particulièrement malsain. On nous apprend à structurer nos procédures, nos dossiers, nos syntaxes mais avec php, si on souhaite le faire ça devient très vite un gros bronx avec des fichiers de partout, des codes en dur à droite à gauche qui me font horreur. Bref, pour moi c'est tout sauf un langage que j'aime utiliser

[Tommy31]

pourquoi vouloir casser du sucre sur Fortran ?

Parce que c'est le jeu de ce fil. On a tous un langage préféré qu'on ne peut défendre qu'en dénigrant les autres. Donc, comment on rabaisse Fortran ?

[souviron34]

Parce que c'est le jeu de ce fil. On a tous un langage préféré qu'on ne peut défendre qu'en dénigrant les autres. Donc, comment on rabaisse Fortran ?

ok, mais si Oompa avait des arguments à donner, qu'il les donne...

Là il intervient en posant une question, ce qui n'est pas le sujet du fil...

[jabbounet]

Parce que c'est le jeu de ce fil. On a tous un langage préféré qu'on ne peut défendre qu'en dénigrant les autres. Donc, comment on rabaisse Fortran ?

Fortran est capable de se défendre tout seul, il est mature, stable.

J'attend en rigolant qu'est-ce que vous ferez dans 20 ans de vos programmes ayant demandé je ne sais combien de ressources et d ebudget aujourdhui, et que vous voudrez continuer à maintenir...

pour ce que j'en ai vu, je crois qu'ils sont dans une optique de faire du jetable, ça répond au besoin a l'instant "t" à t+1 on casse tout et on recommence.

[Mac LAK]

pour ce que j'en ai vu, je crois qu'ils sont dans une optique de faire du jetable, ça répond au besoin a l'instant "t" à t+1 on casse tout et on recommence.

C'est hélas quelque chose d'un peu trop récurrent en ce moment, avec la variante "ce n'est pas la dernière techno à la mode, donc ça ne vaut rien, donc on casse"...

[Lyche]

Il n'y a pas que le problème de mode, il y a un problème de choix de technologie au début de la conception du projet.. influencé par le choix de technologies imposées par les contraintes de l'entreprise dans laquelle on travail.
Je travail régulièrement avec des personnes qui ne jurent que par Excel pour gérer des DWH, alors forcément tout le temps on est obligé de casser ce qui a été fait et de refaire sinon les utilisateurs gueulent parce que ça fonctionne pas, sans jamais se dire "ha ouai on a pas demandé la bonne chose au départ".

Après, il est vrai que c'est devenu une mode de faire du "dev poubelle". Comme dans les jeux vidéo, tu fais un truc qui va être temporaire pour en faire plus souvent.

[Oompa]

Quelques posts plus haut j'ai, à mon sens, suffisamment exposé ma position: Java&co sont des langages poubelles, car voulu ainsi par leurs concepteurs (question de rentabilité).
Des langages comme Fortran et C ont une révision tout les 10 à 15 ans, sont standardisés et stables, et leurs bibliothèques standards sont correctement codés. La sollicitation "qui veux casser du sucre sur Fortran et Erlang" repose sur 2 choses: J'aimerai bien voir quelqu'un qui utilise Fortran et qui s'en plaint.
J'aimerai bien voir quelqu'un qui utilise Erlang tout court.
Devinette: sous quel langage le serveur le plus rapide au monde fonctionne-t-il? (pardonnez le raccourci de la question)

réponse: http://trustleap.com

[deltree]

Je conçois que vous n'aimiez pas le Java, et ce qu'on n'aime pas ça ne se discute pas puisque c'est le sujet du Thread
Ceci-dit, c'est devenu mon language de prédilection, et d'entendre dire que "c'est le denier langage à la mode" alors que je le pratique depuis 11 ans et qu'il existe depuis 14 ans....

Bref ,je vais peut-être vous étonner, mais mon langage détesté du jour, c'est le JSP2/ taglib JSTL et NETUI et expression EL (c'est en gros de la programmation java J2EE)

ça ne parle peut-être pas à tout le monde, mais on a jeté aux orties les "vieux" scriptlets java des JSP1 qui certes n'étaient pas robuste, pour les remplacer par les dernière nouveautés à la mode (justement) qui ne sont pas plus robustes, mais qui sont en plus illisibles (programmation en XML et j'en passe)

Ce que je jetterais aux orties si j'avais le choix: c'est tout ce qui est programmation XML: Ant, taglib JSTL et XSLT: XML est un format de données, pas un language de prog!!!

et pour appuyer mes dire, je vous fournit la programmation d'un if-then else en JSTL, dont je vous laisse apprécier la lisibilité:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<c:choose>
          <c:when test="${fmt}">
	         <fmt:message key="${avalue.value}" bundle="${bundle}"/>
          </c:when>
          <c:otherwise>
          	<c:out value="${avalue.value}"/>
	  </c:otherwise>
</c:choose>

et en scriptlet, c'était peut-etre pas très beau, mais un chouille plus concis:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 <%=(fmt)?getTranslation(avalue.getValue(),bundle):avalue.getValue()%>

et après on me demande pourquoi les sources ont augmenté de taille

[Ecva233]

Il paraît qu'à l'époque de Cobol (que je n'ai pas connu), l'estimation du prix d'un écran de saisie pouvait plus ou moins se faire en comptant le nombre de lignes de code qui seraient nécessaire à son fonctionnement. Style un champ c'est X lignes de codes pour l'affichage, X pour la lecture. Un total de Y lignes multiplié par un facteur de son choix...

Euh tu peux enlever l'imparfait, s'il te plait. Cobol existe toujours et encore pour un petit moment, du moins jusqu'à ce que j'arrive à la retraite j'espère .

C'est vrai que le cobol n'est plus utilisé du moins sur mainframe, pour développer des interfaces graphiques (là ça se comprend), sauf sauf, sur les environnements comptables des grosses entreprises. Là surprise, beaucoup d'utilisateurs comptent uniquement sur le mainframe, car il tombe pas, parce qu'un serice est tombé, ou qu'une bibliothèque n'est pas disponible, parce que les changements sont maitrisés ... Enfin là n'est point le sujet.

Ensuite l'estimation de charge de construction d'un interface était souvent caler sur un ensemble de paramètres :
- si c'était un interface simple type menu
- le type de base de données ou de fichiers accédés
- interface de consultation ou de mise à jour
- complexité des règles de gestion à implanter

Donc rien à voir avec le nombre de ligne de code qu'il fallait pour développer,
sachant que certains interface de consultation pouvait être plus lourd en terme de code que pour certains interfaces de mise à jour.

[_skip]

Donc rien à voir avec le nombre de ligne de code qu'il fallait pour développer,
sachant que certains interface de consultation pouvait être plus lourd en terme de code que pour certains interfaces de mise à jour.

Ah? J'ai lu ça dans un bouquin qui traitait de l'évaluation des charges en gestion de projet mais peut être n'était-ce pas Cobol qui était cité, en tout cas une de ces vieilles technos où il était question d'interface en mode caractère...

Je regarderai, sinon je n'ai pas personnellement l'impression que Cobol est le langage de choix aujourd'hui pour les applications de gestion, sans considérer que ça marche bien ou non.

[Ecva233]

Je regarderai, sinon je n'ai pas personnellement l'impression que Cobol est le langage de choix aujourd'hui pour les applications de gestion, sans considérer que ça marche bien ou non.

Les grosses entreprises type Banque ou Assurances ne sont pas près à le lacher. Il est clair que l'on assiste, depuis un moment d'ailleurs, à un partage des tâches. Les nouvelles technos sont dévouées aux interfaces de saisie, consultation, mais elles s'appuient sur des sous prog cocol, pacbase, ou tout autre langage de gestion mainframe pour aller rechercher les données sur des bases de données énormes, ou pour effectuer des calculs de masse. Les gros traitements de données en masse sont toujours fait en cobol/mainframe car il est simple, fiable et fait pour cela.

Et détrompe toi sur le coté qui marche bien ou pas. Pour l'avoir vu en entreprise, suite à un gros problème sur leur mainframe, j'ai vu un ensemble de responsable, sautés ou rétrogradés, alors que des problèmes de connexion, de blocage de services sont monnaie courante sur les serveurs. Et là ya pas de suite aussi drastique. J'ai demandé la raison de ce limogeage en cascade. Il m'a été répondu, "le Mainframe, c'est notre vitrine, la stabilité, la rapidité".
Comme quoi la notion de problème/serveur est rentré dans le commun de l'informatique ...

Là ou je bosse actuellement, on a un compte rendu des incidents de nuit. Régulièrement il remonte des incidents sur serveurs, entrainant des blocages à répétition et des indisponibilités pour les utilisateurs clients. A titre de comparison pour 1 incident sur mainframe on à 9 incidents serveurs (unix/windows).

Un semblant de gros projet à démarrer ya quelques années pour remplacer le mainframe par une architecture web avec Oracle en support. Ce sont les utilisateurs qui ont fait barrage ... Amusant non. Car il ne faut pas oublier, on ne choisit pas une techno pour se faire plaisir en tant qu'informaticien, mais pour rendre un service à un client. Et là la musique n'est plus la même. L'utilisateur attend surtout d'un système la fiabilité, la rapidité de la réponse, et la convivialité des interfaces.

En tout état de cause, je ne cherche pas absoluement à défendre le couple cobol/mainframe, mais ce qu'il fait il le fait bien, et c'est pourquoi il a encore une place de choix dans les entreprises qui en ont un.

[el_slapper]

(.../...)
Là ou je bosse actuellement, on a un compte rendu des incidents de nuit. Régulièrement il remonte des incidents sur serveurs, entrainant des blocages à répétition et des indisponibilités pour les utilisateurs clients. A titre de comparison pour 1 incident sur mainframe on à 9 incidents serveurs (unix/windows).
(.../...)

J'ai moi, vu du 1 pour 49(alors qu'on avait 55% de Cobol).....

[Lyche]

le langage ne fait pas tout hein, si c'est mal codé, ça plantera, quelque soit le support derrière

[bleuerouge]

Le SQL

[souviron34]

Ah? J'ai lu ça dans un bouquin qui traitait de l'évaluation des charges en gestion de projet mais peut être n'était-ce pas Cobol qui était cité, en tout cas une de ces vieilles technos où il était question d'interface en mode caractère...

non seulement ça n'est pas lié au Cobol, mais c'est même une "méthode" d'évaluation toujouts en cours (même si à mon avis elle n'a aucun sens) en gestion de projet : nombre de lignes, points de fonctions, COCOMO, etc etc..

[jabbounet]

non seulement ça n'est pas lié au Cobol, mais c'est même une "méthode" d'évaluation toujouts en cours (même si à mon avis elle n'a aucun sens) en gestion de projet : nombre de lignes, points de fonctions, COCOMO, etc etc..

effectivement elle n'a pas beaucoup de sens si utilisé tel quel, il faut l'adapter au contexte, complexité du projet, type d'équipe, .....

et même là c'est pas certains que les évaluations soit juste.

[SuperDidom]

Quelques posts plus haut j'ai, à mon sens, suffisamment exposé ma position: Java&co sont des langages poubelles, car voulu ainsi par leurs concepteurs (question de rentabilité).
Des langages comme Fortran et C ont une révision tout les 10 à 15 ans, sont standardisés et stables, et leurs bibliothèques standards sont correctement codés. La sollicitation "qui veux casser du sucre sur Fortran et Erlang" repose sur 2 choses: J'aimerai bien voir quelqu'un qui utilise Fortran et qui s'en plaint.
J'aimerai bien voir quelqu'un qui utilise Erlang tout court.


réponse: http://trustleap.com

Hello, moi j'utilise Erlang depuis quelques mois... Et je dois dire que c'est assez sympa comme langage! Bon le coup de variables dont tu ne peux assigner la valeur qu'une seule fois ca fait un peu bizarre au debut, la syntaxe est un peu degueu... mais on finit par s'y faire! Ce qui est relou c'est que la communaute est minus alors tu dois bouquiner, fouiller sur le net, et fouiller encore alors qu'un probleme du meme ordre en C aurait ete resolu en une fine requete google.. :/
Sinon sur cette histoire de java = langage poubelle j'avoue de pas trop comprendre... Vu tout ce qu'on peut faire, tous les frameworks qui existent, tout ce que l'oriente objet ouvre comme possibilites, les divers interfacages avec d'autres technos et l'apprentissage (des bases) hyper simple pour un newbie je la trouve plutot riche la poubelle!

Have fun +++

[Neuromancien2]

-le PL SQL: on a beau me dire que c'est efficace, on a tellement de framework pour travailler en SQL dans tous les langages, que je ne vois pas l'intérêt de se promener dans ce langage archaique.

C'est notamment en pensant au PL/SQL que j'ai ouvert ce fil.
Je déteste également VB, VBA et ASP... Eh oui, il y a encore peu de temps, j'ai été obligé de travailler sur une application en ASP 4.0 !

[jabbounet]

Sinon sur cette histoire de java = langage poubelle j'avoue de pas trop comprendre... Vu tout ce qu'on peut faire, tous les frameworks qui existent, tout ce que l'oriente objet ouvre comme possibilites, les divers interfacages avec d'autres technos et l'apprentissage (des bases) hyper simple pour un newbie je la trouve plutot riche la poubelle!

Have fun +++

C'est surtout dans le sens ou je vois plein de projet java remplacer ou se faisant remplacer tous les deux ou trois ans par d'autre projet java a peine sorti du four et répondant aux même besoins.