Nouveautés

Moi ça m’intéresse aussi

D'ailleurs, vous pourriez nous dire ou on en est en termes de langages de programmation aujourd'hui (rapido hein...  )

JeanBaptiste a écrit:

Moi ça m’intéresse aussi

D'ailleurs, vous pourriez nous dire ou on en est en termes de langages de programmation aujourd'hui

  Oui peut-être ...

JeanBaptiste a écrit:

(rapido hein...  )

 Mais non

  Quels langages ? (compilés, script, machine virtuelle) pour quels environnements ?(Windows et C# ou Mac et objectiveC) pour quoi faire ? : base de données, acquisition et embarqué, client-serveur, multiplateforme, programmation scientifique et quel paradigme ? : structuré, POO, fonctionnel, etc.

  La question est vaste, donc    Quand j'ai fait ma formation en prog c'était dans le cadre d'une maîtrise de linguistique appliquée dont une des options était : traitement du langage naturel par l'informatique. C'était en ... 1984 (    ) et j'ai appris le BASIC ( ) et l'assembleur. Rien à voir avec ce qui se fait maintenant. Heureusement j'ai croisé un compilo Pascal assez rapidement après.

moi basic sur ZX81 Sinclair à la même époque, puis basta j'ai utilisé du clef en main.

A night in tunisia en langage oud... parce que pour le reste de vos discussionsvous m'avez scotché... 
Y'a un truc que vous ne maitrisez pas ici? je suis sûr qu'en couture vous valez pas un pli!! (pareil que non ils collectionnent toutes les machines à coudre depuis 1920 et ont trouvé de nouvelles façon de tricoter des tenues en laine étanche grâce à des aiguilles de leurs inventions qu'ils avaient imaginées sous linux 9.8 à roulettes.....)
http://oudside.bandcamp.com/track/a-night-in-tunisia

Karmatotal a écrit:

...   j'ai l'impression que notre petite conversation va lasser nos amis mais je voudrais quand même ajouter à ton "euh ?" un autre "euh ?" si tu le permets  :
  D'un point de vue strictement informatique peux-tu me dire ce que c'est qu'un type "vide" (ou void) ? Parce qu'un type, nous sommes bien d'accord que c'est un gabarit de donnée, un modèle général de donnée. Donc en C nous avons un gabarit général de donnée... inexistante. C'est quand même ça cela signifie du point de vue de la sémantique du langage. Ca ne veut pas dire que cela ne fonctionne pas, cela veut dire qe cela pose des problèmes d'effets de bord.

Tant qu'à lasser nos amis (au passages : qu'ils nous excusent  ) :

void est sans doute mal choisi du point de vue sémantique nous sommes d'accord, il aurait été plus judicieux de dire nothing ou autre chose ...

En C exactement comme en C++ void n'est pas un gabarit de donné, c'est simplement l'indication :
- qu'une fonction ne retourne rien (donc on pourrait par exemple dire procedure foo(int x) au lieu de void foo(int x)),
- qu'une fonction n'a pas d'arguments : int foo(void) ce qu'on peut abréger en C++ en int foo() (de nombreux compilateurs C savent le faire),
- qu'on réserve un pointeur générique : void* toto que l'on pourra par la suite "caster".

Karmatotal a écrit:

  Quant à scanf, on peut certes l'utiliser avec beaucoup de précautions mais les problèmes de débordements de la pile sont légion et très connus, cf http://stackoverflow.com/questions/3456106/problem-using-scanf
Tiens voici un petit code avec boucle infinie liée à l'utilisation de scanf si l'utilisateur tape une lettre par exemple.

Code:

#include <stdio.h>
 
int main(void)
{
    int n = 0;
 
   while (n != 1)
    {
        printf("Tapez 1 pour quitter.\n");
        scanf("%d", &n);
    }
 
   return 0;
}

 

Si tu veux absolument récupérer un chiffre utilise :
- scanf("%[0-9]",&n) ...

- ou pour tester le 1 :
#include <string.h>

char tb[100] ;
...
scanf("%s",tb);
if(strchcr(tb,"1") != NULL)
break;

on peut faire plus simple :

char c;
...

scanf("%c",&c) ;
n = (int) c ;


Le problème que tu évoques de traitement de l'utilisateur "non coopératif", n'est pas propre à C : on le retrouve quasiment dans tous dans tous les langages ...

Karmatotal a écrit:

Pour finir, je pense que C est un langage intéressant (sinon il n'aurait pas eu le succès qu'il a connu même si c'est aussi pour des raisons conjoncturelles de passage de l'assembleur à un langage qui ressemblait suffisamment à de l'assembleur pour qu'on ne soit pas dérouté). Simplement il a des défauts (comme tout langage par ailleurs) qui le rendent un peu dangereux et surtout complexe à utiliser : il faut tout vérifier. C'est l'anti ADA en fait (que je n'aime pas trop non plus). Pour de l'embarqué, c'est souvent le seul langage possible, pour le reste, quand j'ai le choix, je choisis autre chose, si je n'ai pas le choix je fais du C. Je comprends qu'en acquisition cela reste le langage de choix si on ne veut pas faire d'assembleur, c'est un domaine que je ne connaît pas en plus (j'avoue donc mon ignorance).

C'est surtout le langage de choix parce que les processeurs modernes (i.e. à partir du Pentium 4) ont une pipeline d'instruction et un ordonnanceur qui font que toute tentative d'optimisation à la main (i.e. au niveau assembleur) peut être réduite à néant (tu a beau spécifier un LOAD XX,AX, l’ordonnanceur peut te le transformer au vol en LOAD XX,BX ... Sans parler des problèmes de branchements prédictifs et autres ...). On a testé dans mon boulot : le compilo Intel crée un code plus rapide que les autres, sans doute parce qu'il "connaît" une partie du fonctionnement de l'ordonnanceur.

Karmatotal a écrit:

 Bref pour un programme d'une centaine de lignes ou deux, ça va, on peut [edit : je peux] vérifier tout. Quand ça dépasse j'ai du mal, sans compter que pour moi le C n'est pas particulièrement lisible comparé aux langages dérivés d'Algol.

La lisibilité d'un programme c'est à mon avis 20% la familiarité avec le langage et 80% la façon dont il est écrit et commenté ... (exemple : je pense bien connaître C, j'ai téléchargé le source du noyau Linux c'est carrément illisible).

Karmatotal a écrit:

Mais voilà, c'est juste une opinion perso, je comprends qu'on puisse aimer. Cela dit les effets de bords, c'est pas perso, c'est dans n'importe quel cours structuré sur le C, il n'y a guère que ce langage qui confonde procédure et fonction et qui soit donc obligé d'inventer le concept de type vide.

Non, non il y en a des tas d'autres, je n'en mets que quelques uns : Matlab, Forth, Smalltalk, Lisp (avec en plus des lambda-fonctions) ...

Bon on va (re)-baptiser le Forum : guitarandjazandcomputer  

paddypat a écrit:

A night in tunisia en langage oud... parce que pour le reste de vos discussions vous m'avez scotché... 
Y'a un truc que vous ne maitrisez pas ici? je suis sûr qu'en couture vous valez pas un pli!! (pareil que non ils collectionnent toutes les machines à coudre depuis 1920 et ont trouvé de nouvelles façon de tricoter des tenues en laine étanche grâce à des aiguilles de leurs inventions qu'ils avaient imaginées  sous linux 9.8 à roulettes.....)
http://oudside.bandcamp.com/track/a-night-in-tunisia

Tout de suite, tu le veux en oud ou en oud++ ?  


Il y a des tas de trucs que je ne maîtrise pas et même auxquelles je ne connais absolument rien ; heureusement car apprendre est une des raisons de l'existence ... (c'est profond ça, je vais le noter dans mon cahier de maximes).

Je suis sur qu'on va être d'accord avec Karma sur la phrase précédente ...

stan_fr a écrit:

Je suis sur qu'on va être d'accord avec Karma sur la phrase précédente ...

 Tout à fait  

 Pour le reste, à peu près OK sauf pour la boucle infinie parce que une interruption de programme et une endless loop c'est pas pareil en exécution. Pour en sortir il faut ou tuer le processus pour les systèmes qui le permettent vraiment  (je ne vise personne   ) ou rebooter et les conséquences ne sont pas les mêmes.
    De +, C ne possède pas la compilation séparée (les fichiers .h sont des header, pas des unit au sens de Pascal ou Modula) et ça me manque.

  Pour la lisibilité, je suis d'accord jusqu'à un certain point quand même, je dirai plutôt 40 / 60 mais bon, je pinaille.

Pour les autres langages que tu cites, comme je ne les connais pas je te fais confiance.

Syndesmo Jean a écrit:

lasser non, le forum est là pour échanger,à deux ou a dix  
...

Surtout pas, continuez, c'est passionnant! ... enfin, ça doit sûrement être passionnant! ... et puis pendant ce temps-là, vous n'attaquez pas les petites vieilles!  

Karmatotal a écrit:

...
Pour le reste, à peu près OK sauf pour la boucle infinie parce que une interruption de programme et une endless loop c'est pas pareil en exécution. Pour en sortir il faut ou tuer le processus pour les systèmes qui le permettent vraiment  (je ne vise personne   ) ou rebooter et les conséquences ne sont pas les mêmes.
    De +, C ne possède pas la compilation séparée (les fichiers .h sont des header, pas des unit au sens de Pascal ou Modula) et ça me manque.

  Pour la lisibilité, je suis d'accord jusqu'à un certain point quand même, je dirai plutôt 40 / 60 mais bon, je pinaille.

Pour les autres langages que tu cites, comme je ne les connais pas je te fais confiance.

Allez une petite dernière et on y revient plus ...

- Les solutions que j'indique n'impliquent pas une terminaison de programme mais une sortie de boucle : break = continuer à la fin du bloc en cours ...

- Windows permet sans problème de tuer des process sans avoir à rebooter : tu tapes CTR-Alt-Suppr et tu te retrouves sous le gestionnaires de tâches qui te permet de tuer à tout va ...

- C permet la compilation séparé (heureusement) cc -o de mémoire sous Linux, après il faut indiquer à l'éditeur de liens comment faire mais c'est vrai pour tous les langages compilés ...
Les headers (#include ...) ne sont effectivement que du texte, on pourrait sans doute s'en passer mais à l’époque ou C a été dérivé de B la mémoire était très couteuse et éviter de charger du texte paraissait justifié (ça a aussi un avantage en ce sens que tu peux te faire ton propre header qui n'inclue que les fonctions dont tu as besoin).
- Dans les langages j'en avais oublié un, pourtant très utilisé, FORTRAN avec au menu : procédures, fonctions et subroutines ...

Le principal c'est qu'on soit d'accord sur cette fabuleuse chose qu'est apprentissage  

igor a écrit:

Syndesmo Jean a écrit:

lasser non, le forum est là pour échanger,à deux ou a dix  
...

Surtout pas, continuez, c'est passionnant! ... enfin, ça doit sûrement être passionnant! ... et puis pendant ce temps-là, vous n'attaquez pas les petites vieilles!  

T'inquiètes pas Igor on t'en laissera, de toute façon on ne chasse qu'en France ...  

stan_fr a écrit:

Allez une petite dernière et on y revient plus ...

   développement quand tu nous tiens ...

stan_fr a écrit:

- Les solutions que j'indique n'impliquent pas une terminaison de programme mais une sortie de boucle : break = continuer à la fin du bloc en cours ...

  Néanmoins l'instruction <Write> en Pascal n'a pas besoin de tout ce mic-mac, pas de boucle infinie possible.  

stan_fr a écrit:

- Windows permet sans problème de tuer des process sans avoir à rebooter : tu tapes CTR-Alt-Suppr et tu te retrouves sous le gestionnaires de tâches qui te permet de tuer à tout va ...

      C'est vrai mais pour l'utiliser environ une fois par semaine sous XP  ( ) : tu trouves que ce gestionnaire est efficace et rapide pour tuer un processus ?   Sans doute que ça a dû s'améliorer avec 7 (je l'espère)

stan_fr a écrit:

- C permet la compilation séparé (heureusement) cc -o de mémoire sous Linux, après il faut indiquer à l'éditeur de liens comment faire mais c'est vrai pour tous les langages compilés ...

   Excuse-moi encore une fois de pinailler, mais dans ton exemple ce n'est pas le langage C qui permet la compilation séparée, c'est l'OS. Tu peux aussi le faire via des bibliothèques statiques (.obj sous win) ou dynamiques (.dll ou .so sous *nux) y compris avec du BASIC ou quoi que ce soit.
 Mais en Pascal ça a toujours été (et depuis TurboPascal 4 ! ) en natif sans passer par le système d'exploitation et l'éditeur de lien. C'est le compilateur qui gère tout seul les tables de correspondances et l'édition de lien entre les différentes unités (mot clé <UNIT> en Pascal et <MODULE> en Modula) c'est donc indépendant de l'OS. Pascal permet donc la compilation séparée en tant que langage indépendant de l'OS. La dernière partie de ta phrase que j'ai mise en italiques ne s'applique ni à Pascal, ni à Modula ni à ADA qui sont tous trois des langages compilés.

stan_fr a écrit:

Le principal c'est qu'on soit d'accord sur cette fabuleuse chose qu'est apprentissage  

   Et nous le sommes !

Donc la on est dans la rubrique nouveauté , ok bon    

"C'est curieux chez les marins ce besoin de faire des phrases…"   

Je viens de découvrir Brian Bromberg  " compared to that ", c'est de la contrebasse et du jazz ...désolé ....   

j'aime bien   je trouvais le son de la guitare pas mal en fait il semble que ce soit une picolo basse


Personnel: Brian Bromberg: acoustic bass, hollow body piccolo bass, steel string acoustic piccolo bass; Carvin B24 4 string bass, Carvin B24 4 string fretless bass; Alex Acuna: percussion; Gannin Arnold: rhythm guitar; Charlie Bishart: violin; Randy Brecker: trumpet, flugelhorn; Vinnie Colaiuta: drums; George Duke: piano; Bela Fleck: banjo; Mitch Forman: piano; Larry Goldings: hammond b3 organ; Jeff Lorber: piano, electric piano; Gary Meek: tenor sax; Tom Zink: piano.

Horn Section: Tony Guerrero; Willie Murillo; Jason Thor; Vince Trombetta; Mark Visher

marcel a écrit:

Je viens de découvrir Brian Bromberg  " compared to that ", c'est de la contrebasse et du jazz ...désolé ....   

T'a pas l'impression d'être gravement HS, là ? ...   

  

Ce forum est quand même génial!   

 

Karmatotal a écrit:

...

stan_fr a écrit:

- Les solutions que j'indique n'impliquent pas une terminaison de programme mais une sortie de boucle : break = continuer à la fin du bloc en cours ...

  Néanmoins l'instruction <Write> en Pascal n'a pas besoin de tout ce mic-mac, pas de boucle infinie possible.  

Là j'ai un peu de mal à suivre : on parlait des effets de scanf** (l'équivalent de read en Pascal si je ne me trompe pas) quand c'est mal programmé, l'équivalent de write en C (printf) ne pose aucun problème ...

**Sinon je t'aurais proposé l'écriture usuelle (pour un programmeur en C) :
...
printf("Tapez 1 pour quitter\n")
while( getchar() != 0x31 ) // getchar retourne un int et le code ASCII correspondant à 1 est en héxa 0x31 (49 en décimal)
 ;
...

Karmatotal a écrit:

stan_fr a écrit:

- Windows permet sans problème de tuer des process sans avoir à rebooter : tu tapes CTR-Alt-Suppr et tu te retrouves sous le gestionnaires de tâches qui te permet de tuer à tout va ...

     
C'est vrai mais pour l'utiliser environ une fois par semaine sous XP  ( ) : tu trouves que ce gestionnaire est efficace et rapide pour tuer un processus ?   Sans doute que ça a dû s'améliorer avec 7 (je l'espère)

J'entends ou je lis souvent ça, mais nous utilisons mon épouse et moi XP (Pro SP3) environ 5 h/j sans aucun plantage, ni besoin de tuer un process ... On est des martiens ou on devrait jouer au loto ?
Et si ça m'arrive (pour certains jeux sous DosBox ou prévus pour Win98) oui c'est efficace : la liste des applications s'affiche en clair (pas besoin de pidof toto comme sous Unix ou Linux), je clique sur l'appli à tuer (pas tellement plus compliqué que kill 3345 à mon avis).

Karmatotal a écrit:

stan_fr a écrit:

- C permet la compilation séparé (heureusement) cc -o de mémoire sous Linux, après il faut indiquer à l'éditeur de liens comment faire mais c'est vrai pour tous les langages compilés ...

   
Excuse-moi encore une fois de pinailler, mais dans ton exemple ce n'est pas le langage C qui permet la compilation séparée, c'est l'OS. Tu peux aussi le faire via des bibliothèques statiques (.obj sous win) ou dynamiques (.dll ou .so sous *nux) y compris avec du BASIC ou quoi que ce soit.
 Mais en Pascal ça a toujours été (et depuis TurboPascal 4 ! ) en natif sans passer par le système d'exploitation et l'éditeur de lien. C'est le compilateur qui gère tout seul les tables de correspondances et l'édition de lien entre les différentes unités (mot clé <UNIT> en Pascal et <MODULE> en Modula) c'est donc indépendant de l'OS. Pascal permet donc la compilation séparée en tant que langage indépendant de l'OS. La dernière partie de ta phrase que j'ai mise en italiques ne s'applique ni à Pascal, ni à Modula ni à ADA qui sont tous trois des langages compilés.

Je pinaille aussi mais ce que tu décris de Turbo Pascal est valable pour Turbo C qui masque aussi la phase d'édition de liens (mais ce sont deux produits Borland sous Windows ...). Et ce n'est pas l'OS qui fait le travail tout seul comme un grand, sinon on utiliserait pas de fichiers make nous sommes bien d'accord, mais ce n'est pas Pascal (ni C d'ailleurs) mais l'environnement de développement (Turbo Pascal et son successeur Delphi, Visual Studio, Eclipse ...) qui fait le sale boulot.

JeanBaptiste a écrit:

Moi ça m’intéresse aussi

D'ailleurs, vous pourriez nous dire ou on en est en termes de langages de programmation aujourd'hui (rapido hein...  )

En très rapide :

- Programmation générale gros programmes : C++ (C pour les sytèmes d'exploitation),
- Programmation gros calculs exigeant du parallélisme massif : CUDA (un mix C, C++ pour les cartes Nvidia uniquement : on peut "facilement" utiliser des milliers de coeurs ou plus),
- Intelligence artificielle ou assimilable (reconnaissance du langage, etc ...) : souvent LISP
- Programmation plus légère et (théoriquement) sans risuqe de virus : Java,
- Programmation Web coté client : HTML et Javascript (ou ses dérivés genre JQuery),
- Programmation Web coté serveur : PHP, Java.

Excuse, c'était bien <read> pas <write>, erreur idiote.
 
    Pour XP franchement, j'ai énormément de pbs sans doute liés à un antivirus et un firewall (pourtant bien configuré je pense) et pourtant je trouve que XP est très stable par rapport à Vista. Et pourtant je ne joue pas. Maintenant, ça dépend aussi de la bécane qui est vieille. Pour autant j'ai eu un Linux sur un PC qui était aussi vieux et avec un peu moins de mémoire, pas de plantage. Ce n'est pas des ragots, c'est du vécu. Mes processus sous Win XP se tuent très difficilement et lentement par rapport à Linux.

   Pour le langage, c'est dans la norme même du langage que c'est décidé. Et, je le redis, ce n'est pas l'OS qui fait le travail, ni l'EDI comme tu le dis, c'est le compilateur qui met en pratique une propriété du langage. Ce n'est donc pas plus dépendant du compilateur (s'il suit la norme) que de l'OS. Turbo C a implanté ça parce que TP l'avait, là c'est autre chose, cela ne fait pas partie du langage C. C'est sur ce point que nous différons. Quand je déclare une UNIT dans mon programme ou un MODULE en MODULA, je n'ai rien d'autre à faire, c'est le langage qui s'occupe de tout (via le compilo évidemment mais qui ne fait que mettre en pratique la norme et non rajouter d'autres choses comme tu le dis). UNIT est un mot réservé du langage lui-même pour la compilation séparée ce qui prouve qu'elle fait partie de la norme du langage.
Dans la norme de l'ADA, du MODULA et du PASCAL ISO il y a l'obligation de définir des tables de liens internes au langage lui-même pour faire de la compil séparée quelque soit l'OS.

 Pour les gros programmes j'ajoute au C++, le Pascal Object avec l'EDI Delphi.
 Et pour les langages web et sript : Python. Simple et puissant , basé sur une machine virtuelle comme Java.

Désolé mais puisque tu travailles souvent sous Linux, tu peux aussi le faire en C/C++ :

void* sdl_library = dlopen("ma_librairie.so", RTLD_LAZY);
if (sdl_library == NULL) {
// signaler l'erreur ...
} else {
// utiliser le résultat avec la table des symboles
}

C'est vrai que c'est plus lourd que les units Pascaliens, mais ça existe ... (avec des syntaxes variant un peu suivant l'OS, donc ce n'est pas portable en soi, mais c'est un détail qu'on peut automatiser avec des ifdef).

Oui Python c'est bien (comme Ruby, Perl et d'autres), mais JB voulait du court et je n'ai cité que les plus utilisés ...

Vista n'est pas stable c'est vrai (surtout en mode Aero), comme Millenium ou 98 et Windows demande plus de place que Linux pas de doute là dessus, en terme de performance dans la vie courante je ne vois pas trop de différence et même aucune mais j'ai une "config de la mort qui tue" (Core I7 et 16 Giga sous Seven Pro 64 bits).

Ils nous font suer avec leurs musiciens de Jazz ...  

stan_fr a écrit:

Désolé mais puisque tu travailles souvent sous Linux, tu peux aussi le faire en C/C++ :

void* sdl_library = dlopen("ma_librairie.so", RTLD_LAZY);
if (sdl_library == NULL) {
  // signaler l'erreur ...
} else {
  // utiliser le résultat avec la table des symboles
}

C'est vrai que c'est plus lourd que les units Pascaliens, mais ça existe ... (avec des syntaxes variant un peu suivant l'OS, donc ce n'est pas portable en soi, mais c'est un détail qu'on peut automatiser avec des ifdef).

  En fait je pense qu'on est d'accord : on peut le faire (avec une bibliothèque en .so ou en .dll sous win) mais ce n'est qu'une émulation (et on peut émuler plein de choses y compris la POO avec C en utilisant les pointeurs et les <struct>). On peut aussi émuler l'héritage multiple avec Pascal Object alors qu'il ne permet pas, C++ le permet en natif. Je comprends que ceux qui veulent de l'héritage multiple préfèrent C++ que Pascal Object même si je peux  leur leur montrer comment émuler cette propriété.

  Comme tu l'as dit,  "c'est plus lourd" et  "ce n'est pas portable en soi". Cela dit C et C++ sont d'excellents langages, si je dois m'y mettre vraiment un jour, je le ferai sans pb.

  Pour WinXP il est clair que ma config (PC desktop qui a plus de 9 ans certes upgradé et boosté mais quand même l'âge est là) rame. Je trouve Linux (un peu) moins gourmand.

stan_fr a écrit:

Ils nous font suer avec leurs musiciens de Jazz ...  

 Alors ça c'est bien vrai !  (Bon je vais à ma répèt...)

vous voulez du HS ?

http://medias.tuxboard.com/flash/strip-tease-controle-parental.swf

        

Band In A Box 2014 est sorti !

what's new ?