Le coin des développeurs

Hey les geeks! Vous développez quoi? en quel langage? besoin d'un coup de main pour votre code?

Histoire des langages:

http://en.wikipedia.org/wiki/History_of_programming_languages

Hé, le webmestre tu peux déplacer ce topic dans la section "Informatique": j'ai cliqué trop vite?

 J'ai un jquery quiz à tester pendant les vacances.  Je peux piquer ton .jpg pour montrer à mes élèves?

Longue vie à ce fil.  Je ne suis pas codeur donc c'est plutôt par intérêt intéressé

If_Then_Else a écrit:Hé, le webmestre tu peux déplacer ce topic dans la section "Informatique": j'ai cliqué trop vite?

Bonjour, s'il te plaît...  

La question n'a aucun sens. On ne programme pas dans un langage, on utilise un langage adapté à un besoin. Je sais bien que les développeurs Java sont capables d'écrire du Java dans n'importe quel langage, mais utiliser un langage que l'on connaît pour un besoin pour lequel il n'est pas conçu est une hérésie.

Pour ma part :
- C, C++ (fonctionnel, voire un peu objet s'il le faut vraiment), Fortran pour les gros programmes ;
- RPL/2 et RPL/C pour des besoins spécifiques (du style implantation d'algorithmes mathématiques massivement parallèles). Attention, ce sont des langages qui piquent (lien) ;
- Forth pour faire simple sur des systèmes sans OS.

Les mauvaises langues ajouteraient Sendmail, PostScript et TeX qui sont tous deux Turing-complets (la preuve, Basix est un interprète Basic entièrement écrit en TeX et disponible sur le CTAN (lien aussi)).

Et jamais, je dis bien jamais les horreurs que sont :
- C# et F# ;
- Java ;
- Perl ;
- Python.

Et pour certains étudiants, punis, j'ai déjà demandé des TP en
- Brainfuck (avec comme caractères de contrôle l'espace et la tabulation  :diable: )
- goto++ qui est rigolo aussi.

que vas-tu nous développer le grincheux?

merci Gryphe!   

Moi, je ne sais pas, mais certains s'amusent énormément : lien

On croirait le dernier discours de l'homme politique à la mode...

Ou une copie d'étudiant... Souvent, le bruit est supérieur au signal et cela ressemble assez à un bruit de télétransmission.

Le grincheux a écrit:Moi, je ne sais pas, mais certains s'amusent énormément : lien

...

source a écrit:<!-- Tables are the best thing in html ever and  :censure:  -->

The guy has a sense of humor I suppose.

https://github.com/jewlofthelotus/SlickQuiz

 Y en a t-il des meilleurs?  (Celui-ci va apparement me permettre d'inclure des images avec modifications...)

xphrog a écrit:

Le grincheux a écrit:Moi, je ne sais pas, mais certains s'amusent énormément : lien

...

source a écrit:<!-- Tables are the best thing in html ever and  :censure:  -->

The guy has a sense of humor I suppose.

https://github.com/jewlofthelotus/SlickQuiz

 Y en a t-il des meilleurs?  (Celui-ci  va apparement me permettre d'inclure des images avec modifications...)

La meilleure chose en HTML/XML est celle qui n'a jamais été écrite, voyons !

Je sens que la présence féminine va laisser à désirer sur ce topic...  

Il faut vraiment qu'on lie le grincheux à une chaise dans le coin là... :lol!:

comme ça ML serait obligée de venir le récupérer.   

xphrog a écrit:Il faut vraiment qu'on lie le grincheux à une chaise dans le coin là... :lol!:

Trop tard... Les hommes en blanc m'ont déjà passé la chemise avec les mains dans le dos...   

Ronin a écrit:Je sens que la présence féminine va laisser à désirer sur ce topic...  

Pour info, jewelofthelotus est une fille.

Personnellement je m'amuse en ce moment à coder un filtre anti-parasite (en C++, à l'aide du SDK d'Avisynth) pour traiter des enregistrements TNT. Rien de révolutionnaire (c'est du bon vieux produit de convolution avec une Gaussienne discrète), mais ça reste instructif sur la manipulation des classes.

Dedale a écrit:Personnellement je m'amuse en ce moment à coder un filtre anti-parasite (en C++, à l'aide du SDK d'Avisynth) pour traiter des enregistrements TNT. Rien de révolutionnaire (c'est du bon vieux produit de convolution avec une Gaussienne discrète), mais ça reste instructif sur la manipulation des classes.

Y a vraiment pas à dire... On ne trouve plus de technicien pour le combat à pied... Heureusement que la mémoire ne coûte plus rien  :lol: 

Le grincheux a écrit:Y a vraiment pas à dire... On ne trouve plus de technicien pour le combat à pied... Heureusement que la mémoire ne coûte plus rien  :lol: 

C'est que je suis feignant!

Dedale is in the house

Même si je n'ai rien compris de ce que tu racontes.  :lol:   

La mémoire ne coûte pas cher.  C'est un argument écologique important?  ou pas?

xProg s'inquiète  :| 

xphrog a écrit:Dedale is in the house

Même si je n'ai rien compris de ce que tu racontes.  :lol:   

La mémoire ne coûte pas cher.  C'est un argument écologique important?  ou pas?

xProg s'inquiète   :| 

Tu n'as, je pense, pas idée de l'impact écologique de choix informatiques. Aujourd'hui, 95% des mails qui transitent sur internet sont du spam et la gestion de ce spam consomme l'électricité de quelques tranches nucléaires rien qu'en Europe. On pourrait lutter contre ce spam en utilisant des serveurs de mail gérés correctement par des gens compétents.

C'est exactement la même chose pour les logiciels. Lorsqu'un logiciel est écrit correctement, il est plus compact, tourne plus vite, bref, c'est optimisé. Lorsqu'il est écrit à l'arrache avec un langage objet, il est beaucoup plus gourmand parce que le langage part du principe que les données procèdent du programme et non le contraire avec la conséquence immédiate que lorsqu'on a besoin d'appeler la variable "banane", il faut siffler une classe "singe" pour apporter cette banane et que la classe "singe" refuse de venir sans avoir avec elle tous ses copains de la jungle. Et c'est sans compter avec les garbage collectors (ou ramasse-miettes) parce que l'utilisateur ne doit pas gérer lui-même la mémoire...   

L'utilisation de tels langages demande ainsi des processeurs plus rapides (quitte à ce qu'ils passent leur temps à traiter des informations totalement inutiles dans des structures de données vides) et beaucoup plus de mémoire. C'est aussi ce qui explique que depuis une dizaine d'années au moins, la vitesse d'exécution des programmes ne s'est plus accrue malgré l'augmentation des performances des ordinateurs. Il y a donc un coût écologique (puisqu'on pourrait faire la même chose avec grosso-modo des machines 20 fois moins rapides et avec 20 fois moins de mémoire) provenant d'une surconsommation d'énergie et d'un surdimensionnement des capacités de calcul et de mémoire.

Ce qu'il faut aussi noter, c'est la vitesse de développement du code. En utilisant un langage impératif (typiquement Cobol, un ancêtre qui est toujours bien vivant puisque la majorité du nouveau code informatique est écrit en Cobol, Cobol étant le seul langage qui permette de travailler en virgule fixe, pour la comptabilité, c'est très important), procédural (Fortran, C...) ou fonctionnel (LISP et dérivés), il faut penser ses algorithmes et écrire des choses de façon propre. La programmation commence par une feuille de papier, la conception est correcte et il n'est pas rare de trouver en production du code dont les premières lignes ont été écrites il y a plus de 40 ans. En utilisant des langages abjects, pardon objet, on peut utiliser des méthodes "agiles" (un joli nom !) puisqu'on part des données pour écrire le code sans réellement avoir pris le temps d'écrire un cahier des charges. Le code est alors jetable et à chaque nouveau besoin, on réécrit tout. Typiquement, les logiciels écrits en Java sont entièrement réécrits entre la version n et la version n+1 parce qu'il est plus rapide de tout réécrire que de comprendre les interactions subtiles entre objets. Seul le concepteur pourrait à la rigueur s'y retrouver. Mais il est vrai qu'on trouve beaucoup plus de bidouilleurs sur des langages objets que sur les autres. On ne peut pas bidouiller avec un langage qui n'est pas objet.

Pour fixer les idées, juste un exemple. J'ai dû coder à l'arrache un algorithme A* pour un test sur un coin de table. Un A*, c'est un algorithme capable de trouver le plus court chemin dans un graphe. Mon graphe comportait plus de 15 millions de segments et un Dijkstra ne convenait pas car bien trop lent. Je n'avais pas le temps de coder un A* et j'ai cherché dans les bibliothèques existantes un A* que je pourrais utiliser 'out of the box'. J'en ai trouvé un, dans la bibliothèque Boost (C++). J'ai donc codé une interface C++ à mes routines et... et le calcul en question a mis à genou mes machines de calcul (8 Go de mémoire, 70 Go de swap et 32 processeurs). Pourtant, un tel graphe doit pouvoir tenir dans la mémoire du calculateur en question. Un coup de debugger et j'ai pu constater que les objets Boost::graph était dérivés de la libstd du C++ et qu'à chaque segment du graphe (dont les seules informations pertinentes étaient point source 32 bits, point destination 32 bits, pénalité du segment 32 bits) correspondait une structure de plus de 1 Ko ! J'ai donc passé quelques jours à réécrire un A* dans un langage procédural (je n'ai pas trouvé d'A* en C ou équivalent). Il tournait 20 fois plus vite en consommant en tout 25 fois moins de mémoire. Rien que la consommation électrique était divisé par plus de 20 !

Plutôt que de fermer Fessenheim, on devrait interdire l'exécution du code de merdre. Ça, ce serait écologique !

Le grincheux a écrit:

xphrog a écrit:Dedale is in the house

Même si je n'ai rien compris de ce que tu racontes.  :lol:   

La mémoire ne coûte pas cher.  C'est un argument écologique important?  ou pas?

xProg s'inquiète   :| 

Tu n'as, je pense, pas idée de l'impact écologique de choix informatiques. Aujourd'hui, 95% des mails qui transitent sur internet sont du spam et la gestion de ce spam consomme l'électricité de quelques tranches nucléaires rien qu'en Europe. On pourrait lutter contre ce spam en utilisant des serveurs de mail gérés correctement par des gens compétents.
(...)

C'est exactement la même chose pour les logiciels. Lorsqu'un logiciel est écrit correctement, il est plus compact, tourne plus vite, bref, c'est optimisé.
Plutôt que de fermer Fessenheim, on devrait interdire l'exécution du code de merdre. Ça, ce serait écologique !

  
J'aurais au moins appris, et retenu, ça !  

Le grincheux a écrit:C'est exactement la même chose pour les logiciels. Lorsqu'un logiciel est écrit correctement, il est plus compact, tourne plus vite, bref, c'est optimisé. Lorsqu'il est écrit à l'arrache avec un langage objet, il est beaucoup plus gourmand parce que le langage part du principe que les données procèdent du programme et non le contraire avec la conséquence immédiate que lorsqu'on a besoin d'appeler la variable "banane", il faut siffler une classe "singe" pour apporter cette banane et que la classe "singe" refuse de venir sans avoir avec elle tous ses copains de la jungle. Et c'est sans compter avec les garbage collectors (ou ramasse-miettes) parce que l'utilisateur ne doit pas gérer lui-même la mémoire...   

Encore faut-il savoir réaliser le logiciel en question dans son intégralité. Lorsque je souhaite réaliser un filtre de débruitage pour de la vidéo, je n'ai pas l'intention ni le temps pour apprendre à programmer un démultiplexeur, des codecs, un frameserver, etc ...
Certes le choix d'utiliser des classes dont on n'a pas nécessairement une connaissance poussée de leur fonctionnement peut être préjudiciable, mais toujours est-il que cela permet de réaliser quand même quelquechose.

Bonjour à tous, et surtout au webmestre qui est très à cheval sur les convenances et on le comprend!

Pour ma part je suis un "Delphi guy" (Delphi: Pascal Objet de Embarcadero www.embarcadero.com) Développement su PC, MC, Android et IOS .

Voici un topic de présentation (le gars est un peu endormi mais bon...):



Avant de lire dans le détail les posts ci-dessus, je voulais avoir votre avis concernant la transférabilité dans notre vie professionnelle des compétences/attitudes/connaissances acquises en tant que développeur...

C'est une question que je me pose après avoir lu ce blog(http://delphicodemonkey.blogspot.fr/2013/12/effectiveness-how-to-increase-it.html) et celui-ci

Dedale a écrit:

Le grincheux a écrit:C'est exactement la même chose pour les logiciels. Lorsqu'un logiciel est écrit correctement, il est plus compact, tourne plus vite, bref, c'est optimisé. Lorsqu'il est écrit à l'arrache avec un langage objet, il est beaucoup plus gourmand parce que le langage part du principe que les données procèdent du programme et non le contraire avec la conséquence immédiate que lorsqu'on a besoin d'appeler la variable "banane", il faut siffler une classe "singe" pour apporter cette banane et que la classe "singe" refuse de venir sans avoir avec elle tous ses copains de la jungle. Et c'est sans compter avec les garbage collectors (ou ramasse-miettes) parce que l'utilisateur ne doit pas gérer lui-même la mémoire...   

Encore faut-il savoir réaliser le logiciel en question dans son intégralité. Lorsque je souhaite réaliser un filtre de débruitage pour de la vidéo, je n'ai pas l'intention ni le temps pour apprendre à programmer un démultiplexeur, des codecs, un frameserver, etc ...

Il devrait être interdit d'utiliser une bibliothèque qu'on n'est pas capable d'écrire. À chaque fois que j'ai vu cela, ça s'est mal fini (dont une fois avec Ariane V par un feu d'artifice à plusieurs millions pour une erreur indigne d'un débutant !). Le pire dans cette histoire, ce sont les bibliothèques écrites en langage objet parce que c'est à la mode et qu'on développe plus vite. Lorsque les concepteurs des bibliothèques en question ne savent pas trop les conséquences de leurs actes et que les utilisateurs desdites bibliothèques n'en savent pas plus, le resultat marchotte lorsqu'on a de la chance.

Certes le choix d'utiliser des classes dont on n'a pas nécessairement une connaissance poussée de leur fonctionnement peut être préjudiciable, mais toujours est-il que cela permet de réaliser quand même quelquechose.

Pour passer derrière des gens qui raisonnent comme toi (à savoir on utilise des bibliothèques parce que ça permet d'aller vite), je peux t'affirmer qu'il vaut mieux ne rien réaliser que de réaliser un tel code. Le diable est dans les détails de la programmation informatique et ne pas maîtriser son outil parfaitement expose à de sévères déconvenues.

Le grincheux a écrit:

xphrog a écrit:Dedale is in the house

Même si je n'ai rien compris de ce que tu racontes.  :lol:   

La mémoire ne coûte pas cher.  C'est un argument écologique important?  ou pas?

xProg s'inquiète   :| 

Tu n'as, je pense, pas idée de l'impact écologique de choix informatiques. Aujourd'hui, 95% des mails qui transitent sur internet sont du spam et la gestion de ce spam consomme l'électricité de quelques tranches nucléaires rien qu'en Europe. On pourrait lutter contre ce spam en utilisant des serveurs de mail gérés correctement par des gens compétents.

C'est exactement la même chose pour les logiciels. Lorsqu'un logiciel est écrit correctement, il est plus compact, tourne plus vite, bref, c'est optimisé. Lorsqu'il est écrit à l'arrache avec un langage objet, il est beaucoup plus gourmand parce que le langage part du principe que les données procèdent du programme et non le contraire avec la conséquence immédiate que lorsqu'on a besoin d'appeler la variable "banane", il faut siffler une classe "singe" pour apporter cette banane et que la classe "singe" refuse de venir sans avoir avec elle tous ses copains de la jungle. Et c'est sans compter avec les garbage collectors (ou ramasse-miettes) parce que l'utilisateur ne doit pas gérer lui-même la mémoire...   

L'utilisation de tels langages demande ainsi des processeurs plus rapides (quitte à ce qu'ils passent leur temps à traiter des informations totalement inutiles dans des structures de données vides) et beaucoup plus de mémoire. C'est aussi ce qui explique que depuis une dizaine d'années au moins, la vitesse d'exécution des programmes ne s'est plus accrue malgré l'augmentation des performances des ordinateurs. Il y a donc un coût écologique (puisqu'on pourrait faire la même chose avec grosso-modo des machines 20 fois moins rapides et avec 20 fois moins de mémoire) provenant d'une surconsommation d'énergie et d'un surdimensionnement des capacités de calcul et de mémoire.

Ce qu'il faut aussi noter, c'est la vitesse de développement du code. En utilisant un langage impératif (typiquement Cobol, un ancêtre qui est toujours bien vivant puisque la majorité du nouveau code informatique est écrit en Cobol, Cobol étant le seul langage qui permette de travailler en virgule fixe, pour la comptabilité, c'est très important), procédural (Fortran, C...) ou fonctionnel (LISP et dérivés), il faut penser ses algorithmes et écrire des choses de façon propre. La programmation commence par une feuille de papier, la conception est correcte et il n'est pas rare de trouver en production du code dont les premières lignes ont été écrites il y a plus de 40 ans. En utilisant des langages abjects, pardon objet, on peut utiliser des méthodes "agiles" (un joli nom !) puisqu'on part des données pour écrire le code sans réellement avoir pris le temps d'écrire un cahier des charges. Le code est alors jetable et à chaque nouveau besoin, on réécrit tout. Typiquement, les logiciels écrits en Java sont entièrement réécrits entre la version n et la version n+1 parce qu'il est plus rapide de tout réécrire que de comprendre les interactions subtiles entre objets. Seul le concepteur pourrait à la rigueur s'y retrouver. Mais il est vrai qu'on trouve beaucoup plus de bidouilleurs sur des langages objets que sur les autres. On ne peut pas bidouiller avec un langage qui n'est pas objet.

Pour fixer les idées, juste un exemple. J'ai dû coder à l'arrache un algorithme A* pour un test sur un coin de table. Un A*, c'est un algorithme capable de trouver le plus court chemin dans un graphe. Mon graphe comportait plus de 15 millions de segments et un Dijkstra ne convenait pas car bien trop lent. Je n'avais pas le temps de coder un A* et j'ai cherché dans les bibliothèques existantes un A* que je pourrais utiliser 'out of the box'. J'en ai trouvé un, dans la bibliothèque Boost (C++). J'ai donc codé une interface C++ à mes routines et... et le calcul en question a mis à genou mes machines de calcul (8 Go de mémoire, 70 Go de swap et 32 processeurs). Pourtant, un tel graphe doit pouvoir tenir dans la mémoire du calculateur en question. Un coup de debugger et j'ai pu constater que les objets Boost::graph était dérivés de la libstd du C++ et qu'à chaque segment du graphe (dont les seules informations pertinentes étaient point source 32 bits, point destination 32 bits, pénalité du segment 32 bits) correspondait une structure de plus de 1 Ko ! J'ai donc passé quelques jours à réécrire un A* dans un langage procédural (je n'ai pas trouvé d'A* en C ou équivalent). Il tournait 20 fois plus vite en consommant en tout 25 fois moins de mémoire. Rien que la consommation électrique était divisé par plus de 20 !

Plutôt que de fermer Fessenheim, on devrait interdire l'exécution du code de merdre. Ça, ce serait écologique !

Le code "qui pue" doit être corrigé collectivement!
Java : code interprété avec la machine virtuelle. Pas adapté au développement d'un algo A*...

En Delphi, peut-on éviter Tobject en passant par les Interfaces... Pas évident
type
IBigNumber = interface
/*
interface methods
*/
end;

type
BigInteger = record
private
FNumber: IBigNumber;
public
/*
public methods and overloaded operators
*/
end;


The BigInteger type is an interface reference wrapped in the advanced record; SizeOf(BigInteger) = SizeOf(Pointer).

Let us generalize the above idea. Instead of


type
TMyObject = class
/*
..
*/
end;


we use the alternative:


type
IMyObject = interface
/*
..
*/
end;

TMyObject = record
private
FMyObject: IMyObject;
public
/*
..
*/
end;


You can see that the alternative requires more code typing. What we obtain for more work?
•IMyObject can be implemented in DLL and used with different programming languages;
•We obtain automatic memory management based on reference counting;
•Automatic memory management makes possible fluent coding;
•We can overload operators in TMyObject;
•We get rid of all TObject overhead.