pied gauche

 

Bavardage & Divers

Forum > Bavardage & Divers > A propos de mémoire

1 | 2 | 3 | 4

Sondage : Je me rappelle du bug de l'an deux-mille, et du "krack" de la "bulle" Internet (1 choix possible)
18 (62%)
3 (10%)
8 (28%)
(vous devez être identifié pour pouvoir voter)

Sylvius de Napline

13/05 (11:41)

avatar

nombre messages : 4554

Membre

Nerdos[*n]Valkyry a écrit :

> Le MS-DOS a changé, tout comme le Bash.

Tu parles de l'interprète de commande, pas de DOS on est d'accord ? La console windows n'est pas un sous-système DOS. Heureusement que ça a évolué. Mais on est toujours très loin de bash, qui, me semble t-il, a évolué beaucoup plus vite.

Gâterie

14/05 (09:28)

avatar

nombre messages : 11497

Membre

Nerdos[*n]Valkyry a écrit :

> Cobol en 2019 !?! [3)]
>
> C'était déjà considéré comme 'dépassé' quand j'ai fait mes études ...
> Mais, si certains langages durent autant, je pense que c'est parce qu'ils remplissent leur
> fonction, et ont été mis à jour.

Absolument pas ! Le cobol ne remplit pas sa fonction, c'est juste que certaines applications critiques en banque ont été programmées en cobol - et que lesdites banque n'ont pas toute eu la motivation de le ré-écrire en mieux.

Par contre, je crois effectivement avoir entendu dire qu'il y a eu une évolution. Si je me souviens bien du détail, la nouvelle version est toute aussi mal foutue que l'ancienne et personne ne sait pourquoi elle existe - soit tu maintiens ton application en cobol, soit tu la ré-écris dans un vrai langage, mais tu va pas la reprogrammer dans un langage daubé...


edit : pour comprendre les problèmes du cobol, il faut savoir qu'il a été fondé sur de mauvaises idées - des idées qui semblaient bonnes à l'époque, les gens qui l'ont conçu n'étaient pas stupide, mais qui se sont avérées mauvaises à l'usage. En gros, l'idée que comme il devait concerner des applications critiques en finance, il devait pouvoir être lu par tous - un programmeur programme le truc, il file le code à un banquier, le banquier regarde et comprend tout et constate que le code fait bien ce qu'il veut. Et au final, ça donne un code lisible par personne - là où les langages objets, par exemple, sont difficilement compréhensibles par un non-programmeur mais assez facilement lisibles par un programmeur. Jean-Jacques pourra sans doute donner des exemples de trucs ultra-mal conçus en cobol. Seulement voilà, de gros programmes ont été fait en cobol, ils font ce qu'on leur demande, on peut comprendre que certaines entreprises préfèrent les maintenir que de tout changer.


Le fortran de son côté a été basé sur les même idées que le C (avec un côté vaguement plus scientifique - ie, deux-trois fonctionnalité plus pratiques pour un usage scientifique), et sa survie est sans doute issue de la (bonne) idée de rétro-compatibilité : un compilateur Fortran 95 est capable de reconnaître et de compiler du Fortran 77. Le fortran 95 n'est pas aussi performant que le C++ en terme de programmation objet, mais il est, disons, "suffisant", et la possibilité d'y intégrer des routines très rapide en F77 sans avoir à rien faire (plus les quelques trucs un peu plus pratiques pour un code scientifique) a suffit à assurer sa pérennité (peut-être à tort).

Fun fact : en F77, on doit laisser 6 caractères libre au début de chaque ligne. Ces 6 caractères correspondent au numéro de ligne sur une carte perforée - on a donc un reste direct du fait que c'était un langage pour cartes perforées.


Pour l'Ada, je ne sais pas - mais je ne suis pas convaincu que, comme le Cobol, il ait été basé sur de mauvaises idées qui semblaient bonne à l'époque. Je suppose qu'il est basé sur des idées qui sont bonne dans le contexte où on l'utilise.

Fun fact : l'Ada tient son nom de Ada Lovelace, première programmeuse de l'histoire - un genre de hipster de la programmation qui programmait avant que ça soit cool, en fait avant même que les ordinateurs existent.

___

PROTOPLASME

[ce message a été édité par Gâterie le 14/05 à 10:00]

Sylvius de Napline

14/05 (17:09)

avatar

nombre messages : 4554

Membre

Gâterie a écrit :

> Pour l'Ada, je ne sais pas - mais je ne suis pas convaincu que, comme le Cobol, il ait été
> basé sur de mauvaises idées qui semblaient bonne à l'époque. Je suppose qu'il est basé sur
> des idées qui sont bonne dans le contexte où on l'utilise.

En effet, il y a encore des nouveaux projets qui débutent en choisissant Ada. Certes, il s'agit d'habitudes des gens du métier, mais il reste considéré pour ses qualités dans le domaine de la sûreté. Et il y a des trucs très cools fait avec Spark chez Adacore.

Alizée [=)] Seldonovitch

15/05 (04:19)

avatar

nombre messages : 1212

Ministre du Travail

Kraland

Domicile : Quartier Suprême

Ah bah : si ça tourne encore avec des langages du XXème siècle, je comprends mieux pourquoi ma banque est toujours à la bourre quand j'attends un virement.


Heureusement, il y a des gens qui innovent, et qui n'hésitent pas à utiliser les méthodes «agiles» pour livrer des stabilisateurs de vols de gros porteurs, en temps et en heure.



Un troll ? Où ça ?

[ce message a été édité par Alizée [=)] Seldonovitch le 15/05 à 04:21]

Nerdos[*n]Valkyry

16/05 (19:37)

avatar

nombre messages : 17773

Citoyen

Confédération Libre

Domicile : Triangle d'Or

Gâterie a écrit :
Seulement voilà, de gros programmes ont été fait en cobol, ils font ce qu'on leur demande

C'est ce que je voulais dire, quand un programme fait ce qu'on lui demande, on n'a pas vraiment de raison de changer.
Je ne connais pas du tout le Cobol, juste de nom.

L'Ada, j'ai pratiqué le 83 et le 95 (pas le 2005, mais il a l'air encore mieux), c'est mon langage préféré.
C'est très rigide, car très fortement typé, mais si le code passe la compilation, à part erreur de conception, on est sûr que le programme va tourner, vite et sans erreur !


Sylvius de Napline,

L'émulateur MS-DOS, si tu préfères. (Que ce n'est même plus une vraie console sur les derniers Windows)

Et bien sûr, ça ne peut pas égaler le Bash. Je ne sais pas si tu connais, mais rien que pouvoir 'tuber' des commandes, c.a.d enfiler les résultats de l'une à l'autre, et sauvegarder le résultat, en une ligne. Plus Grep, qui est vraiment un bijoux. J'allais presque oublier Nmap, avec ces deux logiciels et une console Bash, il y a vraiment de quoi s'amuser.


Le site du WCG | Les recherches en cours | Le topic de la Team | FAQ en français | Vous aussi aidez la recherche avec la Team Kraland
Les petits ruisseaux font les grandes rivières, les "petits" ordinateurs font de méga calculateurs pour la recherche.


[ce message a été édité par Nerdos[*n]Valkyry le 16/05 à 19:55]

Sylvius de Napline

17/05 (11:27)

avatar

nombre messages : 4554

Membre

Nerdos[*n]Valkyry a écrit :

> L'émulateur MS-DOS, si tu préfères. (Que ce n'est même plus une vraie console sur les
> derniers Windows)


Tu peux utiliser l’interpréteur de commande sans utiliser d'émulateur MS-DOS. C'est ce que donne le raccourcis "Invite de commande", ou directement "cmd.exe". Cet interpréteur utilise une console windows pour ses entrées sorties.

> Je ne sais pas si tu connais, mais rien que pouvoir 'tuber' des commandes

C'est possible aussi bien avec bash qu'avec l'interpréteur de commandes windows.

> Plus Grep, qui est vraiment un bijoux.

J'utilise grep distribué avec MinGW sur windows également.

Forum > Bavardage & Divers > A propos de mémoire

1 | 2 | 3 | 4