Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 122 524 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
221
Salut

je me demande si de mémoire, le PLM n'est pas un bel hybride entre C et Assembleur...

Je me souviens avoir lu du PLM à l'aérospatial dans les années 1998 sur du
code embarqué pour l'A320 (véridique)

Par contre, meme si on ne peut pas écrire en C# (ou java) des VST, j'ai entendu
parler que sur Vista, M$ fournir WASAPI qui sera une interface de qualité
professionnel Audio. On peut gager qu'on pourra alors faire de l'audio en C#
comme on faisait de l'ASIO.. en C++ (cela dit, on peut déja faire de l'audio
en C#... ) mais de la à developper un VSTi en C#... je crois qu'il y a pour
le moment des problèmes de wrapper...

Quoique, personnellement, j'ai réussi à mettre du C# dans du code C++ (c'est
facile à faire)... mais surtout à appeler depuis une appli Non managé, via
une DLL, ce propre Code...

En clair, on doit pouvoir faire un VST en C# (sauf peut-etre pour l'IHM, et
encore, je pense que cela doit etre fastidieux mais réaliable)

THe Monz, Toulouse

PS : la page ou il parle de WASAPI :
http://msmvps.com/blogs/odewit/archive/2005/12/09/78606.aspx
222

Citation : Fortran et cobol, ca rentre dans la categorie antediluvien, non ?


Certes mais il y a encore énormément de code maintenu actuellement dans ces langages. En calcul scientifique le Fortran est toujours très répandu et le Cobol c'est en gestion (banques, assurances...)

Citation : Je parlais bien de langages "recents", cad qui sont encore utilises pour faire de nouveaux projets.


Toi oui, mais peut-être pas celui qui a posé la question ! Du reste, je ne serais pas surpris qu'il y ait encore régulièrement de nouveaux projets réalisés en Fortran, à cause des raisons :
- beaucoup de scientifique sont très familiers du Fortran et pas du tout des autres langages
- pas mal de super-calculateurs (genre Fujitsu) n'ont que le Fortran comme librairies voire compilateur optimisés pour leur architecture (processeurs, bus etc.)

Citation : Non serieusement, le C haut niveau, c'est pas tenable comme argument. Je veux dire, c'est quand meme bien la premiere fois que je vois le discours etre tenu.


C'est un problème de terminologie, il faudrait une échelle. Disons que de 0 à 10, l'assembleur serait à 0, le C à 2 ou 3, le C++ à 5, Perl/Python à 7, Prolog 8 ou 9...

Après il faut décider si "haut niveau" commence à 1 ou à 6... !

Citation : > Par contre, dans ces nouveaux langages, il n'y en a pas encore qui aident réellement à la programmation multi-thread (au sens détection d'accès concurrents à la mémoire dès la compilation).

C'est pas tout a fait vrai. Par exemple, les langages fonctionnels, permettent de paralleliser pas mal de trucs facilement (la encore, mapreduce sur google ). Ensuite, erlang est un langage qui gere explicitement la concurrence, et c'est pas un jouet (c'est utilise pour l'implementation de switch telephoniques, par exemple: ericsson, deutsch telekom, etc...)


Faudrait que je regarde, ça doit être intéressant. Cela dit, dans l'industrie il est rare que ces langages soient seulement évoqués, et en tout cas ils sont quasiment jamais envisagés sérieusement.

Citation : Putain, ca fait je ne sais combien de posts que je me tue a dire pourquoi c'est pas vrai, qu'il y a des choses a voir ailleurs.


Ca dépend du contexte ça coco. Par exemple si tu as prévu d'utiliser des librairies comme Ilog Views ou Ilog Rules, de réutiliser des librairies déjà développées en interne... c'est vite torché ! Sans parler des arguments "marketing", du niveau : "Ada c'est complètement démodé, C++ c'est sur le déclin, java c'est à la mode". Si un grand chef te sort ça, la discussion est difficile.
:mrg:

Citation : Un code écrit en C une fois qu'il est compilé, il tourne sur un type de machine (si tout va bien). Il ne sera jamais amélioré, il est figé à vie. Si des nouveaux jeux d'instruction ou un nouvel OS sortent, il faut tout recompiler, retrouver les librairies etc... Alors qu'en Java, il marche sur toutes les plateformes. Une nouvelle JRE sort, le programme marche encre, ça se trouve il a été optimisé, et en plus il tient compte des dernières nouveautés de processeurs etc.


Dans beaucoup de contextes on considère que Java c'est tellement récent qu'on a pas encore réellement éprouvé ces avantages dont tu parles. En revanche, avoir du code développé en C pour PDP 11, porté ensuite sur Solaris, puis sur Linux, ça on sait qu'on y arrive à peu près. Ou encore du LTR (Langage Temps Réel) développé sur Mitra, porté sur Data General, puis sur AIX en développant un compilateur LTR->C et un environnement qui simule le scheduling du DG...

Certes il ne s'agit pas de jeux en 3D...
:bravo:

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

223

Citation : C'est un problème de terminologie, il faudrait une échelle. Disons que de 0 à 10, l'assembleur serait à 0, le C à 2 ou 3, le C++ à 5, Perl/Python à 7, Prolog 8 ou 9...

Après il faut décider si "haut niveau" commence à 1 ou à 6... !



Et encore, même cette échelle est subjective. Dans le fond, je suis d'accord avec Dr Pouet, ça dépend de tes besoins et donc du point de vue. Pour ma part, je n'ai pas besoin de garbage collector, d'autant plus si ça fait baisser les performances. Les langages sans typage fort, même si je n'en ai qu'une maigre expérience, je ne suis pas fan, on ne sait jamais ce qu'on manipule. Ce genre de fonctionnalités a donc moins d'importance que certaines autres à mes yeux et donc ne rentrent que peu dans mon critère "langage haut-niveau".
224

Citation : Certes il ne s'agit pas de jeux en 3D...


j'osais pas en parler, mais bon, les console de jeux (sony) c'est archaique, ca rentre pas dans le débat lol

Citation : Ton truc d'automate, j'avoue ne pas voir de quoi tu parles; tu as un lien qui en dit plus ?


https://www.google.fr/search?hs=s0X&hl=fr&client=firefox-a&rls=org.mozilla:en-US:official&q=RPNI%2Boncina&btnG=Rechercher&meta=
en gros ca sert à inférer un automate à partir d'exemple positif et negatif. Il y a bcp d'algo dans le meme genre (notament toutes les déclinaison possibe pour les automates probabiliste, automates d'arbres...). L'algo est très simple, mais repose sur la fusion d'état jusqu'a soit arriver à quelque chose de correct, soit de pas bon, et la faut revenir en arrière. Avec des automates géant, ca devient lourd à gérer. Enfin ce que je voulais dire par la, c'est que les pointeurs c'est pratique pour manipuler certaine structure de données, en est-il de meme (au point de vue éfficacité) si l'on ne dispose pas de pointeur? (et l'allocation mémoire).
225

Citation :
Faudrait que je regarde, ça doit être intéressant. Cela dit, dans l'industrie il est rare que ces langages soient seulement évoqués, et en tout cas ils sont quasiment jamais envisagés sérieusement.



Ben erlang, regarde les boites qui l'utilisent. Et si on a une discussion technique, je vois pas pourquoi on prendrait l'argument industriel: je veux dire qu'a ce compte la, les langages les plus utilises, c'est visual basic et excel.

Citation :
Certes mais il y a encore énormément de code maintenu actuellement dans ces langages. En calcul scientifique le Fortran est toujours très répandu et le Cobol c'est en gestion (banques, assurances...)



Non mais je sais tout ca. Mais je ne parle pas de ca. Ce que je raconte, c'est avec les outils dispo aujourd'hui, pour les nouveaux projets, le C est un langage de bas niveau. Compatibilite, bla bla, je connais tout ca, mais ca m'interesse pas dans le sens ou c'est pas une problematique technique. Parce qu'a ce compte la, on peut aussi parler des problematiques economiques et 'philosophiques' (cout des implementations, caractere open source, etc...). Si aujourd'hui, j'implemente un projet de logiciel scientifique, sur lequel j'ai le choix du langage, est-ce que le C ou le C++ est le langage le plus interessant, je pense que non. Un tel langage doit evidemment pouvoir reutiliser le code existant (entre autre fortran), mais c'est tout.

Le coup des scientifiques tres familiers avec Fortran et rien d'autre, je crois qu'ils ont presque tous les cheveux blancs, quand meme ;)

Citation :
C'est un problème de terminologie, il faudrait une échelle. Disons que de 0 à 10, l'assembleur serait à 0, le C à 2 ou 3, le C++ à 5, Perl/Python à 7, Prolog 8 ou 9...



Sur une echelle de 1 a 10, tu dis pas en general que 2 est en haut de la liste ;)

Citation :
On peut gager qu'on pourra alors faire de l'audio en C#
comme on faisait de l'ASIO.. en C++ (cela dit, on peut déja faire de l'audio
en C#... ) mais de la à developper un VSTi en C#... je crois qu'il y a pour
le moment des problèmes de wrapper...



Le probleme majeur que je vois avec le C# est le suivant: l'architecture de base d'un plug VST, c'est une dll avec un thread qui fait le process, qui lui doit etre temps reel, et les autres pour tout ce qui a autour (GUI, etc... Je simplifie, si tu fais un sampler, ca devient nettement plus complique par exemple, mais bon, restons simple). Faire tout ce qui est autour en C# ou n'importe quel autre langage, ca doit etre possible.

Le thread dsp, lui, ne doit comporter aucun appel systeme en general. Je passe sous linux la parce que je connais pas windows: le process dsp doit pouvoir tourner des qu'il a des donnees dispo en entree. Il ne doit jamais bloquer, et il ne doit donc jamais faire d'appel systeme: pas de malloc, pas de fopen, etc... Idealement, les seules fonctions qu'il appelle sont les tiennes, et ne font que du calcul. On peut imaginer se faire son propre allocateur memoire temps reel (a partir de pool, par exemple), mais dans le cas simples, c'est pas tres utile. Encore mieux, il faut eviter d'avoir des defaults de page dans ce thread, donc souvent, on va bloquer tous les buffers utilises par ce thread en memoire vive (il parait que c'est chaud a faire sous windows, voire impossible; je sais pas a quel point c'est vrai mais je me souviens d'un email de R. Kuper, developpeur en chef chez cakewalk, qui attendait avec impatience vista pour permettre ce genre de trucs)

Ensuite, ce thread a une priorite speciale, avec un scheduling particulier appelee SCHED_FIFO:

Citation : SCHED_FIFO can only be used with static priorities higher than 0, which means that when a SCHED_FIFO processes becomes runnable, it will always preempt immediately any currently running normal SCHED_OTHER process. SCHED_FIFO is a simple scheduling algorithm without time slicing. For processes scheduled under the SCHED_FIFO policy, the following rules are applied: A SCHED_FIFO process that has been preempted by another process of higher priority will stay at the head of the list for its priority and will resume execution as soon as all processes of higher priority are blocked again. When a SCHED_FIFO process becomes runnable, it will be inserted at the end of the list for its priority. A call to sched_setscheduler() or sched_setparam() will put the SCHED_FIFO (or SCHED_RR) process identified by pid at the start of the list if it was runnable. As a consequence, it may preempt the currently running process if it has the same priority. (POSIX 1003.1 specifies that the process should go to the end of the list.) A process calling sched_yield() will be put at the end of the list. No other events will move a process scheduled under the SCHED_FIFO policy in the wait list of runnable processes with equal static priority. A SCHED_FIFO process runs until either it is blocked by an I/O request, it is preempted by a higher priority process, or it calls sched_yield().



En gros, ca veut dire qu'un thread FIFO (si tu en as un seul sur le systeme, pour simplifier) va tourner autant qu'il veut, jusqu'a ce qu'il ait fini de faire son boulot: il ne sera pas interrompu par un autre thread (par exemple GUI).

pour resumer:
- un plug a un thread "temps reel"
- ce thread ne doit jamais bloquer: pas d'appel systeme, ie pas de malloc, pas de fopen, meme pas de primites de synchronisation (cf les efforts pour avoir des structures de donnes "lock free" : ); return false;" rel="nofollow" target="_blank">https://en.wikipedia.org/wiki/Lock-free_and_wait-free_algorithms, http://www.audiomulch.com/~rossb/code/lockfree/)
- tu ne veux pas avoir de defaut de page: tu fais en sorte de bloquer toute la memoire utilisee par ce thread dans la memoire vive.
-

Bref, tu peux pas faire ca avec du C# (tout ce qui concerne la memoire, a moins que tu puisses definir des policy speciales pour le GC selon les threads, ce qui serait assez impressionant).

Citation :
Enfin ce que je voulais dire par la, c'est que les pointeurs c'est pratique pour manipuler certaine structure de données, en est-il de meme (au point de vue éfficacité) si l'on ne dispose pas de pointeur? (et l'allocation mémoire).



Je connais rien au sujet dont tu parles (automates et cie), donc je peux pas trop m'avancer. Par contre, je vois pas le rapport entre structure de donnees et pointeurs. Je vois pas une seule structure qui ne soit pas utilisable dans un langage sans pointeur et qui soit implementable qu'en C. En tout cas, tous les trucs basiques (listes, queues, hash, arbres, etc...) sont presents d'office dans quasiment tous les langages modernes.

Pour ce qui est de la memoire dynamique, je pense vraiment qu'en general, tu ne devrais pas a t'en soucier. D'ailleurs, si tu utilises les techniques "modernes" du C++ (smart pointer, container), tu ne controles plus ces aspects la, et la, le C++ n'a plus vraiment d'avantage par rapport a d'autres langages vis a vis de l'efficacite. Par exemple, utiliser un truc a base de listes et hash, je suis pas sur que le C++ soit beaucoup plus rapide que du java ou du OCAML, par exemple.

Pour ce qui est des jeux video, je pense pas qu'il faille prendre ca comme de s jouets. J'ai plutot l'impression au contraire que c'est ce qu'il y a de plus sophistique comme logiciel avec un OS, au niveau de l'architecture.
226

Citation : Pour ce qui est des jeux video, je pense pas qu'il faille prendre ca comme de s jouets. J'ai plutot l'impression au contraire que c'est ce qu'il y a de plus sophistique comme logiciel avec un OS, au niveau de l'architecture.



Mouais, enfin, des logiciels audios, des simulateurs (ou tu dois etre
capable de "rejouer" ou de reprendre dans un état ne sont pas des logiciels
simples...

Certains jeux, c compliqué, mais tu prends un jeu comme quake, je suis
pas sur et certains que l'architecture soit tres complexe.. Apres, que le
faire en terme de code ne soit pas simple pour etre beau et performant, ok...
mais d'un point de vue architecture, un jeu.. c'est dans la plupart des
cas quelque chose d'assez compréhensible...(et finalement, certains jeux,
on dirait presque des logiciels de simulation ( en dehors de l'aspect
rejeu (ou tu ne revois pas seulement le rejeu de la vidéo, mais aussi les
changements d'états des entrées, etc...)

Bref, je pense qu'on peut trouver des architectures compliqués dans bcp de domaines, donc pour moi... pas de sectarisme...

THe Monz, Toulouse
227

Citation : Sur une echelle de 1 a 10, tu dis pas en general que 2 est en haut de la liste


C'est vrai :mrg: Il faudrait dire "moins bas niveau que l'assembleur", mais ça fait plus de mots...

Citation : Ben erlang, regarde les boites qui l'utilisent. Et si on a une discussion technique, je vois pas pourquoi on prendrait l'argument industriel: je veux dire qu'a ce compte la, les langages les plus utilises, c'est visual basic et excel.


Ca dépend des industries. Là où je bosse, si je regarde Erlang, ça sera que pour ma culture personnelle, ça n'a aucune chance (malheureusement) d'être jamais utilisé pour autre chose qu'un proto ou une moulinette de dépannage. Ici c'est Unix (autrefois HP-UX, Digital Unix/Tru64, AIX, Solaris et maintenant Linux) et autrefois Ada, C, maintenant C++ et un peu de java. On a aussi du Ilog, de l'Oracle, du SQLforms, des librairies SNMP, autrefois du réseau OSI et bientôt du Corba (TAO, donc ACE, CCM...)

Par exemple des fois on se dit que du OCAML ce serait quand même cool ; mais c'est tellement exotique que c'est pas trop la peine de se battre pour essayer de le suggérer...

Citation : Le coup des scientifiques tres familiers avec Fortran et rien d'autre, je crois qu'ils ont presque tous les cheveux blancs, quand meme


Pas sûr du tout. Je crois que la météo de tous les pays du monde est calculée en Fortran sur des super-calculateurs, et que pour la mécaflu / résistance des matériaux / acoustique c'est pareil, encore qu'ils migrent de + en + de super calculo vers PC linux, mais toujours en Fortran. Généralement ils estiment que le coût du changement n'est pas contrebalancé par le gain à espérer. Ce coût c'est un peu la formation, beaucoup la ré-utilisation de l'existant (dénormes bibliothèques de librairies et outils propres à l'entreprise).

Citation : Non mais je sais tout ca. Mais je ne parle pas de ca. Ce que je raconte, c'est avec les outils dispo aujourd'hui, pour les nouveaux projets, le C est un langage de bas niveau. Compatibilite, bla bla, je connais tout ca, mais ca m'interesse pas dans le sens ou c'est pas une problematique technique.


Ben le sujet initial du thread était :

Citation : Salut y a des programeurs sur AF si oui vous bossez sous quoi ?


Donc on peut parler un peu de ce qu'on veut non ?

Je sais bien qu'au niveau recherche ou "petits" développements les contraintes et les critères de choix sont complètement différents. Je pense que c'est intéressant d'entendre parler des domaines que l'on connait peu ou pas du tout, pour savoir comment ça se passe "ailleurs".

"petit développement" au sens : moins de 100.000 lignes, mais surtout : le contraire d'un soft qui va être développé en 2 à 4 ans et maintenu pendant 10 à 20 ans, par des équipes régulièrement renouvelées (pas toujours ultra-compétentes). Avec des contraintes opérationnelles : disponibilité, staisfaction utilisateur... etc.

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

228

Citation :
Certains jeux, c compliqué, mais tu prends un jeu comme quake, je suis
pas sur et certains que l'architecture soit tres complexe..



C'est simple, le code de quake 1, 2 et 3 est GPL, tu peux regarder ;) Les jeux video, je connais franchement rien, j'en ai jamais code, je connais pas du tout les technologies. Juste assez pour voir que c'est sacrement balaise (ceux qui font des trucs revolutionaire a la carmack, hein, pas les nieme implementation de je ne sais quel principe bidon). Je me souviens avoir vu des commentaires de developpeurs sur Linux Audio Developers qui disaient que les problemes de programmes audio sont triviaux par rapport a ceux des gros jeux video (et un truc comme ardour, c'est deja loin 'etre trivial, je pense).

Citation :
petit développement" au sens : moins de 100.000 lignes, mais surtout : le contraire d'un soft qui va être développé en 2 à 4 ans et maintenu pendant 10 à 20 ans, par des équipes régulièrement renouvelées (pas toujours ultra-compétentes).



C'est un argument d'un des classiques de Graham: le java est parfait pour les pointy hairy managers, parce que tu peux ecrire beaucoup de code bien commente qui sert a rien :)

Je pense que l'open source peut regler certains problemes lies a ces inerties (pas tout non plus). Par exemple, c'est ce mouvement qui a permis l'eclosion de beaucoup de langages de maniere viable, ou meme en a relance (lisp, python, perl, ruby, php, ocaml). Typiquement, aujourd'hui, je peux coder sous linux en a peu pres n'importe quel langage, parce qu'il existe de bons compilos pour pas mal de langages, du C a l'ada en passant par ocaml, fortran, sans parler des langages dont l'implementation de ref a toujours ete open source: ruby, perl, python.

Je vais prendre une analogie qui va te plaire :diable: ce qui m'interesse, c'est pas de voir les arguments pourquoi windows a 95% de part de marche sur le desktop, mais de voir pourquoi d'autres alternatives, par exemple a nature vegetale, peuvent tout a fait convenir.

Citation :
Je crois que la météo de tous les pays du monde est calculée en Fortran sur des super-calculateurs



Meteo, je confirme. Maintenant, attention: il y a beaucoup de code numerique en fortran, personne ne te contredira la dessus. Mais rien n'empeche aujourd'hui d'utiliser ces librairies en C ou avec un autre langage (tout langage digne de ce nom etant capable de s'interface avec le C, c'est une des puissances de ce dernier). Perso, j'utilise du code fortran de temps en temps, sans en etre conscient.

Citation :
Donc on peut parler un peu de ce qu'on veut non ?



Oui oui, bien sur, je voulais certainement pas imposer un sujet, juste dire dans quel cadre je me placais dans mes arguments. Evidemment, dire que python c'est pratique pour pas mal d'applis, ca veut pas dire recode demain tes applis d'intranet VB en python, ou ton truc de gestion de portefeuils en boo. Juste dire qu'il y a des choses sacrement interessantes, et qui seront de toute facon ce avec quoi les programmeurs feront leur boulot dans 20 ans (lorsque cobol aura enfin vraiment disparu :) ).
229

Citation : Mouais, enfin, des logiciels audios, des simulateurs (ou tu dois etre
capable de "rejouer" ou de reprendre dans un état ne sont pas des logiciels
simples...


je mettais ca hors course vis a vis du materiel (pas de driver, bug hardware, mal documenter et performances floues).
D'un point de vue complexité, pour ma propre expérience, c'est assez complexe à mettre au point, meme si les algos semble simple, meme si les sources sont dispo (les sources de quake sont libre, mais absolument attroce, et inabordable au premier venus), c'est a s'arracher les cheveux... Tou ca caser dans 32mo de RAM :) (la on compte chaque octets, d'ou la nécéssité de gérer la mémoire). Ca tombe bien qu'on en parle, c'est bien le developpement de simulateur?
230

Citation :
Tou ca caser dans 32mo de RAM (la on compte chaque octets, d'ou la nécéssité de gérer la mémoire). Ca tombe bien qu'on en parle, c'est bien le developpement de simulateur?



Imagine le gars lit ca 20 ans en arriere :)