Audiofanzine a 25 ans !
Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
FR
EN
Notifications
  • Refonte graphique octobre 2025
    Refonte graphique octobre 2025
    Une refonte graphique vient d'être mise en ligne. Nous espérons qu'elle vous plaira. Merci de nous signaler tout bug ou perte de fonctionnalité ici →
  • Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Un cadeau d'UVI pour les 25 ans d'Audiofanzine
    Pour célébrer notre quart de siècle, UVI se joint à nous et vous offre le Digital Synsations Vol.1. Pour en profiter c'est par ici 👉
  • Nouveauté : Bookmark article, news ou tuto
    Nouveauté : Bookmark article, news ou tuto
    Bookmarkez un article, une news ou un tuto et retrouvez-le dans votre section "Mes signets" du menu membre.
  • 6 nouveaux annuaires
    6 nouveaux annuaires
    Luthiers, Réparateurs, Cours de musique, Studios d’enregistrement, de mastering et de répétition... Suggérez l’ajout d’une entreprise, inscrivez la vôtre ou déposez un avis.
  • Alertes disponibilité et baisse de prix
    Alertes disponibilité et baisse de prix
    Ces nouvelles fonctionnalités vous permettent d'être informé·e dès qu'un produit est disponible ou que son prix a baissé.
  • Tentatives d'arnaque dans les petites annonces
    Nous faisons face depuis quelques mois à une recrudescence de tentatives d'arnaques dans les petites annonces. Suivez nos recommandations >
Bidouille & Développement Informatique
News
Articles
Médias
Forums
Tutoriels

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 131 677 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
1426
non :-D
1427
Citation de Djardin :
ça a un intérête d'après vous quand on a 25ans en 2013 d'apprendre Cobol, Pascal ou Fortran ? j'ai une idée de la réponse, mais bon.

Je me suis abstenu de tout commentaire jusqu'à présent car je considère comme d'autres qu'un bon outil de développement est celui qui est maîtrisé et adapté au besoin. Mais je bosse encore aujourd'hui avec le langage pascal (Delphi pour Win32/64 et MikroPascal pour PIC)...
Dois-je comprendre (avec stupeur) que ce langage est lui aussi obsolète ? :8O:

Certes, je n'ai plus 25 ans, c'était peut-être ce que j'aurais du lire en premier :bravo:

Formateur en techniques sonores ; électronicien ; auteur @ sonelec-musique.com

[ Dernière édition du message le 14/02/2013 à 14:59:26 ]

1428
il n'y a pas de langage obsolète en soi
le tout est de savoir le but qu'on poursuit
il me semble que notre ami se posait la question de l'apprentissage d'un langage dans le cadre d'une utilisation en entreprise, pour le boulot quoi
sinon, pour des projets perso, tout est bon du moment que ça marche!
1429

D'un côté, Fortran permettrait de revenir vers des trucs plus scientifique-mathématique, plus métier, et moins info (si j'ai tout compris).

en plus, on peut imaginer que d'ici 10-15ans, une bonne partie des développeurs Fortran vont "disparaitre" (retraite, changement d'activité). donc ça permettrait d'être sur une niche.

 

D'un autre côté, ça à l'air très moche, c'est risqué de ne bosser que sur des applications très vieille, donc uniquement de la maintenance, et rien de nouveau.

Référence en matière de bon gout capillaire et vestimentaire.
homme à tête de zizi.

http://soundcloud.com/djardin

1430
Pour le Fortran, c'est ce que je croyais aussi, mais un pote qui bosse sur des supercalculateurs m'a dit que c'est très utilisé dans le domaine (et pas par "inertie", mais parce qu'apparemment c'est bien adapté aux calculs parallèles).

Le Cobol c'est bien si tu veux bosser pour des banques ou autres boîtes avec de l'info critique, "qui marche depuis des dizaines d'années donc on n'y touche pas", et que t'aime bien la rétro-informatique. Sorti de là...

Le Pascal "standard" est pour ainsi dire mort (à part dans l'éducation, et seulement pour l'initiation) ; le Delphi a la tête hors de l'eau pour le moment, mais il n'en restera probablement pas grand-chose le jour où Embarcadero jettera l'éponge.

La prononciation, c'est important !

[ Dernière édition du message le 14/02/2013 à 15:16:11 ]

1431
Citation :
Ça dépend si t'as suffisamment réfléchi avant de coder. :-D


Oula je ne voulais pas lancer un débat "réfléchir avant de coder" VS "débugguer", dans tous les cas ce n'est pas taper des lignes de caractères qui consomme le temps du développeur!


Pour le fortran je confirme : j'ai un pote thésard en physique et ce n'est pas pour le fun qu'il code en fortran mais pour lancer des calculs parallèles de malade. En pratique je ne sais pas quel est l'avantage, mais j'ai cru comprendre qu'effectivement c'était plus lié aux capacités intrinsèques du langage qu'à l'utilisation de vieilles bibliothèques.

Pour info il me semble que le soft Sensomusic Usine est codé en Delphi.

[ Dernière édition du message le 14/02/2013 à 17:54:23 ]

1432
Citation de Zerosquare :
Le Cobol c'est bien si tu veux bosser pour des banques [...]. Sorti de là...

Finance, assurance, administrations, bref : en informatique de gestion, qui est à l'informatique ce que l'expert-comptable est au bureaucrate.

J'ai la faiblesse de croire que papy-boom aidant, les compétences COBOL doivent sérieusement se faire rares, a fortiori si le langage n'est plus enseigné. Et donc il y a peut-être encore des places à prendre dans les boutiques qui n'ont pas migré ou webisé leurs applications historiques pour les raisons que tu cites (ça fonctionne toujours). C'est une corde facile à rajouter à son arc de compétences, si on a pas peur de l'austérité des outils sur certaines plate-formes (encore que ça a dû évoluer), et des idiosyncrasies du langage (doux euphémisme).

« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)

[ Dernière édition du message le 15/02/2013 à 00:04:04 ]

1433
Citation :
C'est une corde facile à rajouter à son arc de compétences, si on a pas peur de l'austérité des outils sur certaines plate-formes (encore que ça a dû évoluer), et des idiosyncrasies du langage (doux euphémisme).
Le problème, c'est qu'en France on te colle vite une étiquette, même si tu as plusieurs cordes à ton arc. Donc à moins d'être motivé pour faire ça pour un bout de temps (et je doute que ce soit le cas de la majorité des jeunes informaticiens), ça peut être à double tranchant.

La prononciation, c'est important !

1434
Faut sans doute pas s'y enfermer, ou être un raté dans les autres technologies, l'objet, Java, le web, tout ça. :oops2:

Le tout est de comprendre les specs, s'il en existe encore.

Citation :
Additionally, traditional COBOL is a simple language with a limited scope of function (with no pointers, no user-defined types, and no user-defined functions), encouraging a straightforward coding style. This has made it well-suited to its primary domain of business computing—where the program complexity lies in the business rules that need to be encoded rather than sophisticated algorithms or data structures.

Aaah, les délices de la maintenance d'applications historiques sur mainframe... :bave:

« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)

1435
Bonjour,
Pardon d'être plus ou moins HS. Je suis tombé il y a 3-4 ans sur le site d'un programmeur de Grenoble sauf erreur qui proposait toute sorte de devices virtuels pour la MAO tels que interfaces audio et MIDI, samplers, etc. la plupart en versions 8, 12, 16 et 24 pistes. J'ai mis tout ce qui me passait par la tête dans Google, impossible de le retrouver. Est-ce que quelqu'un le connaît ?
Merci d'avance pour toute piste :D:
Cordialement
Pierre
1436
Citation de Zerosquare :
Pour le Fortran, c'est ce que je croyais aussi, mais un pote qui bosse sur des supercalculateurs m'a dit que c'est très utilisé dans le domaine (et pas par "inertie", mais parce qu'apparemment c'est bien adapté aux calculs parallèles).

Je confirme. Enfin presque. Ce n'est pas plus adapte au calcul parallele que les autres langages, c'est juste plus adapte au calcul en general. Fortran est prevu pour faire des calcul sur des tableaux multidimensionnels, il a un avantage sur la gestion des pointeurs par rapport au reste des langages (aliasing interdit) donc potentiellement plus performant. Et comme tous les vieux utilisent Fortran 77, tous les jeunes doivent s'y mettre, sauf qu'eux decident de prendre Fortran 2003 (il existe un 2008, mais aucun compilateur n'existe pour le moment) et ca va etre la grosse merde par la suite.
Aussi, les gars qui font du Fortran sont des mathematiciens formes a Matlab. Ils ne comprennent rien a l'informatique, donc ils prennent avec joie le truc pourri qui date des annees 70 et qui n'est pas trop loin de leur zone de confort.
Le cocktail ideal...


Oui, je suis aigri :p

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1437
Citation de LéoMoldo :
Pour le fortran je confirme : j'ai un pote thésard en physique et ce n'est pas pour le fun qu'il code en fortran mais pour lancer des calculs parallèles de malade. En pratique je ne sais pas quel est l'avantage, mais j'ai cru comprendre qu'effectivement c'était plus lié aux capacités intrinsèques du langage qu'à l'utilisation de vieilles bibliothèques.

Si, bibliotheques qui marchent (mais avec des interfaces pourries), c'est important. Mais c'est surtout qu'il arrive mieux a exprimer son algo que parce que Fortran est vraiment meilleur. Le coup de l'aliasing interdit est plus ou moins bypasse par le mot cle restrict en C/C++, donc cet avantage n'existe en realite plus.
Pas pour rien que les codes industriels reecrits de 0 s'eloignent au max du Fortran, mais on y retourne parfois, vers le Fortran 77, parce que ceux qui codent ne connaissent rien d'autre et ne veulent rien apprendre d'autre. A la fin, tu te retrouve avec des codes dont les fonctions font plus de 1000 lignes et qui ont fait perdre tout avantage au Fortran (l'aliasing interdit n'a servi a rien car le compilo ne peut rien inferer, et les tableaux multi-dimensionnels sont aussi peu utilises, et c'est non maintenable).


x
Hors sujet :
En forme aujourd'hui...

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1438

Le cobol, c'est pas fait pour les indiens quoi....
Bon je sort....

 

http://www.pierredon.free.fr

1439
Salut !

J'ai une petite question
Je souhaite mettre un soft dans un microcontrôleur ARM (EM357 de silicon labs), pour cela j'ai une sonde jtag olimex, ARM-USB-TINY-H, et le logiciel OpenOCD. Le soucis c'est que je n'y arrive pas, et c'est la première fois que j'utilise ces outils. Si j'ai bien compris, il me faut deux fichiers de configuration pour openOCD, l'un qui décris mon microcontrôleur et ma sonde jtag, et l'autre ma carte électronique (d'ailleurs je ne comprends pas bien non plus pourquoi il a besoin de ça).
Du coup je me demande :
Est ce que je peux utiliser openOCD seul ou alors il faut autre chose à côté ? (j'ai vu dans une doc qu'il utilisent ça avec eclipse et IAR)
Que dois-je mettre dans mes fichiers de configuration ?

Merci :)

1440
Pour info : http://matt.eifelle.com/2014/06/10/announcement-audio-tk-0-2-0/
Je compte faire un plugin AU/VST simulant une pédale SD1 bientôt, le temps de tester le pipeline et de vérifier les spectres (repliement, tout ça)

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1441
miles, tu as déjà testé les VSTs de Simulanalog?

Ils ont un pack (gratos!) avec une simu de SD1, de tubescreamer, de fender twin, de marshall JCM et de quelques autres pédales, et çà marche très bien!

http://www.simulanalog.org/guitarsuite.htm

Je crois qu'à la base c'est un projet universitaire en traitement du signal, ils ont fait un sacré boulot! J'ai comparé avec les plugins "LePou" que plein de gens considèrent comme les meilleures simulation d'ampli gratos, et ben je préfère largement Simulanalog.

Mais si je comprends bien tu as développé tout un toolkit en Python pour le dev audio?
1442
En fait, c'est basé sur les papiers de simulanalog, mais réécrit depuis 0. Dans leur papier, il n'y a pas qu'une distortion un peu plus simple et pas de discussion sur l'oversampling, même si l'algo d'origine est le même (un Newton Raphson). Je n'ai jamais vu leur code source, donc je ne sais pas quel est l'oversampling qu'ils utilisent. Pour la meilleure qualité, je constate que x32 est ce qu'il y a de meilleur en terme d'alisaing. Il me semble que les LePou utilisent moins, donc sont moins gourmands.

Il faut juste que je finalise mes tests et ma pseudo-skin et ce sera uploadé. Question de jours, j'espère !
Mon toolkit est écrit en C++, mais il y a des wrappers en Python pour mes tests (et pour les graphiques).

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1443
Citation de miles1981 :
Citation de Zerosquare :
Pour le Fortran, c'est ce que je croyais aussi, mais un pote qui bosse sur des supercalculateurs m'a dit que c'est très utilisé dans le domaine (et pas par "inertie", mais parce qu'apparemment c'est bien adapté aux calculs parallèles).

Je confirme. Enfin presque. Ce n'est pas plus adapte au calcul parallele que les autres langages, c'est juste plus adapte au calcul en general. Fortran est prevu pour faire des calcul sur des tableaux multidimensionnels, il a un avantage sur la gestion des pointeurs par rapport au reste des langages (aliasing interdit) donc potentiellement plus performant. Et comme tous les vieux utilisent Fortran 77, tous les jeunes doivent s'y mettre, sauf qu'eux decident de prendre Fortran 2003 (il existe un 2008, mais aucun compilateur n'existe pour le moment) et ca va etre la grosse merde par la suite.
Aussi, les gars qui font du Fortran sont des mathematiciens formes a Matlab. Ils ne comprennent rien a l'informatique, donc ils prennent avec joie le truc pourri qui date des annees 70 et qui n'est pas trop loin de leur zone de confort.
Le cocktail ideal...


Oui, je suis aigri :p

À ma connaissance ce n'est pas uniquement ça (je connais des gens qui font des calculs de mécanique des fluides sur ordi, et sur différents supercalculateurs). Par exemple sur le supercalculateur Fujitsu de Météo-France, le compilateur livré avec, est optimisé pour utiliser au mieux l'architecture matérielle des CPUs, de l'allocation de la RAM, des bus entre unités de calculs etc... Certains microprocesseurs peuvent faire une multiplication de 2 matrices de nombres réels en 1 cycle, autrement dit : des centaines de multiplications et additions. Mais pour ça il faut :
- que le compilateur soit spécialement conçu pour ce hardware
- qu'il sache identifier des "formes de bloc de programme" qui peuvent s'optimiser à mort
- que le programmeur sache utiliser ces formes, plutôt que d'autres qui semblent équivalentes mais qui sont en réalité infiniment moins efficaces. (je dis peut-être n'importe quoi, mais en exemple pour fixer les idées, si à un moment on utilise un tableau à double entrée T(i,j), il faut d'abord faire la boucle sur i, puis j, sinon même si le résultat du calcul est le même, sa durée explose).

Sur ce supercalculateur et au moment où on en parlait (il y a 10 ans ?), seul le compilateur fortran utilisait à fond la puissance du hardware, le compilateur C l'exploitait à peine, et servait surtout pour "dépanner" et compiler des outils qui ne sont pas très consommateurs en CPU.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

1444
Effectivement, les compilateurs Fortran ont un avantage, leur âge combiné avec l'absence d'aliasing qui fait que le code intermédiaire est mieux décrit et potentiellement mieux compilé.
En revanche, que ce soit Fortran, C ou C++, le back-end est maintenant commun, donc les routines d'optimisation sont indépendantes. Il faut juste que le compilateur C ou C++ sache annoter correctement, ce qu'il sait faire de mieux en mieux.
+1 sur le fait que le programmeur sache dans quel sens faire ses boucles. Mais c'est pire que cela, il y a pas mal de choses à faire soi-même maintenant, comme le cache blocking... Il y a des bibliothèques C++ qui sont capables de faire ça de manière transparente pour l'utilisateur, donc avantage au langage moderne.
Ensuite, ça marche bien pour les algos qui font des appels à la mémoire de manière contigüe. Quand on passe aux accès aléatoires (plus ou moins tous les algos modernes), cette différence disparaît.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1445
Citation de miles1981 :
En revanche, que ce soit Fortran, C ou C++, le back-end est maintenant commun, donc les routines d'optimisation sont indépendantes.

De ce que j'avais compris et sur le Fujitsu en question (ou sur des SGI), le back-end n'était pas commun. Seul le back-end spécifiquement développé par Fujitsu pour cette machine (et uniquement en Fortran) permettait de l'exploiter à fond. Fujitsu aurait pu faire de même pour le C, mais il y avait manifestement tellement peu de clients à faire du calcul scientifique autrement qu'en Fortran, que ça ne valait pas le coup.

Je me souviens aussi de tests à la sortie de processeurs intel, où gcc malgré toutes ses qualités, ne pouvait pas donner d'aussi bonnes performances que le compilateur C intel, et qu'il a fallu pas mal de temps (entre 6 mois et un an), pour rattraper ça.

Donc j'imagine que ce que tu veux dire c'est que les back-end sont les mêmes pour les compilos gnu (et peut-être d'autres aussi), mais de ce que j'ai retenu, il y a d'autres cas, et parfois pour exploiter au maximum un hardware ces compilos ou back-ends ne sont pas égaux.


Par ailleurs, chez Météo-France comme dans beaucoup d'autres sociétés de calcul scientifique (mécanique des fluides...), quand un logiciel est énorme (disons 100 hommes x an) et fait l'essentiel de ce dont on a besoin, ben on continue à développer dans le même langage les petits ajouts de l'année... C'est la life !
(et c'est probablement pareil dans plein d'autres sociétés et pays, sinon Fujitsu aurait aussi développé la version C).

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

[ Dernière édition du message le 12/06/2014 à 00:23:59 ]

1446
Citation de miles1981 :
Il faut juste que je finalise mes tests et ma pseudo-skin et ce sera uploadé. Question de jours, j'espère !


Si t'as besoin d'un coup de main pour ça, c'est peut être possible que je fasse un peu de coloriage:

https://www.gearslutz.com/board/music-computers/733123-sknote-presets-skins.html

http://www.mediafactory.org.au/natalie-herbstreit/files/2014/10/the-end-2gt1jas.jpg

1447
Quelques uns que j'ai fait que je trouve sympa :

329897d1360342694-sknote-presets-skins-funny-test.jpg


313995d1350524238-sknote-presets-skins-captrndcountry.jpg

http://www.mediafactory.org.au/natalie-herbstreit/files/2014/10/the-end-2gt1jas.jpg

[ Dernière édition du message le 12/06/2014 à 00:34:59 ]

1448
Citation de Dr :
De ce que j'avais compris et sur le Fujitsu en question (ou sur des SGI), le back-end n'était pas commun. Seul le back-end spécifiquement développé par Fujitsu pour cette machine (et uniquement en Fortran) permettait de l'exploiter à fond. Fujitsu aurait pu faire de même pour le C, mais il y avait manifestement tellement peu de clients à faire du calcul scientifique autrement qu'en Fortran, que ça ne valait pas le coup.

Je me souviens aussi de tests à la sortie de processeurs intel, où gcc malgré toutes ses qualités, ne pouvait pas donner d'aussi bonnes performances que le compilateur C intel, et qu'il a fallu pas mal de temps (entre 6 mois et un an), pour rattraper ça.

Donc j'imagine que ce que tu veux dire c'est que les back-end sont les mêmes pour les compilos gnu (et peut-être d'autres aussi), mais de ce que j'ai retenu, il y a d'autres cas, et parfois pour exploiter au maximum un hardware ces compilos ou back-ends ne sont pas égaux.


Par ailleurs, chez Météo-France comme dans beaucoup d'autres sociétés de calcul scientifique (mécanique des fluides...), quand un logiciel est énorme (disons 100 hommes x an) et fait l'essentiel de ce dont on a besoin, ben on continue à développer dans le même langage les petits ajouts de l'année... C'est la life !
(et c'est probablement pareil dans plein d'autres sociétés et pays, sinon Fujitsu aurait aussi développé la version C).

Tout à fait. Jusqu'au jour où on se dit que le legacy code, c'est bien mais c'est limite en terme de maintenance et on recommence de 0 en C++ ;)

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1449
Citation de Hohman :
Si t'as besoin d'un coup de main pour ça, c'est peut être possible que je fasse un peu de coloriage:

https://www.gearslutz.com/board/music-computers/733123-sknote-presets-skins.html

Joli, je prends note et je veux bien, oui ! Pour l'instant la branche est juste sur mon Mac, le temps de savoir pourquoi le plugin semble fonctionner avec auval mais pas avec AULab !

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

1450
Par contre il faut que tu saches que je ne connais presque rien en programmation. Je peux juste fournir l'image de fond, les potentiomètres, typo, lumière et ombrage en pseudo 3D pour chaque position d'images et au format/dimensions voulu. Pour le reste je nage, j'ai quelques petites notions 3DS mais c'est beaucoup trop de boulot, c'est cher et je ne sais pas tout faire seul (essentiellement au niveau du code, et je n'ai pas envie de tuer quelqu'un :mdr:...)...
Les images que tu as pu voir représentes environ une demi journée de loisir en remplaçant des images existantes, dans ce cas aucun problème et on peut facilement faire mieux... Si/quand tu penses que c'est bon pour toi, aucun problème pour revenir vers moi.

http://www.mediafactory.org.au/natalie-herbstreit/files/2014/10/the-end-2gt1jas.jpg

[ Dernière édition du message le 12/06/2014 à 01:16:05 ]