Sujet Le pub des programmeurs
- 1 925 réponses
- 117 participants
- 123 065 vues
- 130 followers
Afficher le sujet de la discussion
C'est vachement revelateur, le dechiffre, n'empeche !
Fortran et cobol, ca rentre dans la categorie antediluvien, non ? Je parlais bien de langages "recents", cad qui sont encore utilises pour faire de nouveaux projets.
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. J'ai rien contre le C, c'est un langage que j'utilise beaucoup, mais je le fais pour des trucs bas niveau (implementation d'algo difficilement implementables en python, ce qui est assez rare maintenant quand meme).
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...)
Ada, je connais tres peu, et c'est vrai que ca avait l'air interessant. Mais par contre, contrairement a ce que tu dis, j'ai l'impression que peu de programmeurs aiment. C'est vachement contraignant, et c'est considere par beaucoup comme un langage ayant echoue.
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
A quel niveau tu veux savoir ? L'algo dsp, le tuyautage autour ? Un equalizer de base (ie un filtre shelve), c'est relativement facile. Tu peux trouver les equations de base (il y a d'autres trucs plus sophistiques) la:
http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt
Je suis d'accord sur le fond, a savoir que c'est un domaine (recompilation dynamique de code) qui va voir beaucoup de progres, et qui va engendrer des trucs de plus en plus utiliser. Par contre, pour java, je suis pas tout a fait d'accord parce qu'en pratique, le coup du write once, run everywhere, c'est pas verifie. T'as toujours des problemes de plateformes, de version java, etc... Ensuite, absolument rien t'empeche d'appliquer les memes techniques a du code compile machine plutot que du bytecode java: rosetta, par exemple, sous mac os X, utilise exactement cette technique. qemu, emulateur d'OS, utilise aussi cette technique (dans un but different)
Un exemple:
https://pdos.csail.mit.edu/~baford/vm/
C'est pas limite, je l'utilise toujours quand je fais du C. Ca facilite beaucoup les choses quand tu as des librairies avec pas mal de parametres. FFTW, par exemple, est implementee comme ca. Ce qui est lourd en C, c'est tout ce qui concerne l'heritage, et la, clairement, j'utiliserai pas le C. (je fais C++ + QT pour du graphique avec python pour le proto); a part si le C est intermediaire, et sorti par un programme par un programme de plus haut niveau.
Ton truc d'automate, j'avoue ne pas voir de quoi tu parles; tu as un lien qui en dit plus ?
y a des programeurs sur AF si oui vous bossez sous quoi ?Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 22 ans
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 22 ans
Citation :
le C est plus facile à déchiffrer
C'est vachement revelateur, le dechiffre, n'empeche !
zieQ
466
Posteur·euse AFfamé·e
Membre depuis 21 ans
Anonyme
521410
Je parlais d'automate et/ou de graphes, car je me suis laissé dire (de source sur lol) que c'était l'implémentation d'algo qui les manipulent (par exemple RPNI pour l'apprentissage de langage, notamanet la fusion d'etat etc) était très importante (évidement) dans le temps d'execution. Bref en gros l'algo implenter naivement en java ou perl ou camL était en fait très très lent par rapport à ce qu'une version C (ou C++) pouvait faire.
le C est de plus haut niveau que l'assembleur, aucun doute, sinon il n'existerai pas, mais je connais pas d'autre langage plus proche? (de l'assemleur)
et pour en rajouter une couche, on peut faire de l'objet en C
(bon ok c'est limite mais possible)
le C est de plus haut niveau que l'assembleur, aucun doute, sinon il n'existerai pas, mais je connais pas d'autre langage plus proche? (de l'assemleur)
et pour en rajouter une couche, on peut faire de l'objet en C
(bon ok c'est limite mais possible)gerfaut
575
Posteur·euse AFfolé·e
Membre depuis 20 ans
Dr Pouet
52037
Membre d’honneur
Membre depuis 20 ans
thie91
87
Posteur·euse AFfranchi·e
Membre depuis 19 ans
jujupauty
1150
AFicionado·a
Membre depuis 21 ans
Dr Pouet
52037
Membre d’honneur
Membre depuis 20 ans
Le C a effectivement été créé par Kernigan et Ritchie pour écrire des systèmes d'exploitation (leurs prototypes d'Unix en fait). Ils en avaient marre de repartir presque de zéro à chaque changement de calculateur.
Livre d'histoire :
Un compilateur C était ensuite généralement fourni avec chaque Unix de manière à pouvoir porter les outils de base. Le but n'était pas de faire un langage de très haut niveau. Mais par la suite, à partir du moment où tu as déjà un compilateur qui marche sur ton système, tu es tenté de l'utiliser (notamment de faire des économies en n'achetant rien de plus). J'imagine que c'est pour ça que le C s'est aussi largement imposé.
Pourtant quand on comparait C + vi de base, par rapport à Turbo Pascal 7, le confort de développement n'avait un peu rien à voir. Et puis la vitesse de compilation... 80.000 lignes par minute en Pascal sur un 386 !!
Livre d'histoire :
Un compilateur C était ensuite généralement fourni avec chaque Unix de manière à pouvoir porter les outils de base. Le but n'était pas de faire un langage de très haut niveau. Mais par la suite, à partir du moment où tu as déjà un compilateur qui marche sur ton système, tu es tenté de l'utiliser (notamment de faire des économies en n'achetant rien de plus). J'imagine que c'est pour ça que le C s'est aussi largement imposé.
Pourtant quand on comparait C + vi de base, par rapport à Turbo Pascal 7, le confort de développement n'avait un peu rien à voir. Et puis la vitesse de compilation... 80.000 lignes par minute en Pascal sur un 386 !!
Pov Gabou
19553
Drogué·e à l’AFéine
Membre depuis 22 ans
Citation :
En termes de productivité et lisibilité (ou maintenabilité), le Fortran et le Cobol doivent être entre le C et l'assembleur.
Fortran et cobol, ca rentre dans la categorie antediluvien, non ? Je parlais bien de langages "recents", cad qui sont encore utilises pour faire de nouveaux projets.
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. J'ai rien contre le C, c'est un langage que j'utilise beaucoup, mais je le fais pour des trucs bas niveau (implementation d'algo difficilement implementables en python, ce qui est assez rare maintenant quand meme).
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...)Ada, je connais tres peu, et c'est vrai que ca avait l'air interessant. Mais par contre, contrairement a ce que tu dis, j'ai l'impression que peu de programmeurs aiment. C'est vachement contraignant, et c'est considere par beaucoup comme un langage ayant echoue.
Citation :
C++ si ça doit aller vite, et java sinon
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
Citation : comment vous faite un equalizer avec un PC ?
enfin, je veut dire, au niveau de la programmation...
A quel niveau tu veux savoir ? L'algo dsp, le tuyautage autour ? Un equalizer de base (ie un filtre shelve), c'est relativement facile. Tu peux trouver les equations de base (il y a d'autres trucs plus sophistiques) la:
http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt
Citation :
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.
Je suis d'accord sur le fond, a savoir que c'est un domaine (recompilation dynamique de code) qui va voir beaucoup de progres, et qui va engendrer des trucs de plus en plus utiliser. Par contre, pour java, je suis pas tout a fait d'accord parce qu'en pratique, le coup du write once, run everywhere, c'est pas verifie. T'as toujours des problemes de plateformes, de version java, etc... Ensuite, absolument rien t'empeche d'appliquer les memes techniques a du code compile machine plutot que du bytecode java: rosetta, par exemple, sous mac os X, utilise exactement cette technique. qemu, emulateur d'OS, utilise aussi cette technique (dans un but different)
Un exemple:
https://pdos.csail.mit.edu/~baford/vm/
Citation :
et pour en rajouter une couche, on peut faire de l'objet en C (bon ok c'est limite mais possible)
C'est pas limite, je l'utilise toujours quand je fais du C. Ca facilite beaucoup les choses quand tu as des librairies avec pas mal de parametres. FFTW, par exemple, est implementee comme ca. Ce qui est lourd en C, c'est tout ce qui concerne l'heritage, et la, clairement, j'utiliserai pas le C. (je fais C++ + QT pour du graphique avec python pour le proto); a part si le C est intermediaire, et sorti par un programme par un programme de plus haut niveau.
Ton truc d'automate, j'avoue ne pas voir de quoi tu parles; tu as un lien qui en dit plus ?
- < Liste des sujets
- Charte