A noter

*** message déplacé ***

il y a certes des bonnes idées dans cette simplification (mais une complication car le caractère ← n'existe pas au clavier)
et des mauvaises : croire que la notion même d'entrées (ce que l'on fournit à "la fonction") et de sorties (ce que fournit "la fonction" comme résultats) ne font pas partie de l'algorithmique !

c'est surement pour que l'usage du lire/ecrire disparaisse.

et quand ils voudront programmer ça sur machine ils seront bien emm..és

casio a deja commercialise une calculatrice avec programmation fonctionnelle

@moderateurs
desole pour le double post.
Fil à rapatrier dans le forum Espace Profs ?

raison de plus pour supprimer tout apprentissage de quoi que ce soit vu que c'est les machines qui feront tout ...
"le peuple" n'a absolument pas besoin de savoir comment ça se passe.

le but au lycee c'est d'ecrire des algorithmes pas de programmer.
Le prof fera comme il veut mais on se doit de preparer les eleves à l'xamen.
Donc de suivre la nouvelle syntaxe.

je pense qu'à terme (eu egard au programme de seconde) on leur demandera
d'ecrire des fonctions et on ne parlera pas d'entree ou de sortie.
Il y a un enorme lobby python qui est hegemonique et qui impose sa norme au lycee et en prepa.

je suis pret à parier que dans le sujet de bac de 2020, on aura:
ecrire une fonction XYZ prenant en arguments blabla et renvoyant  blabla

qu'on appelle "argument" ou "entrées" c'est exactement pareil
et qu'on appelle "renvoyant" ou "sortie" aussi.
et entretenir ainsi la confusion entre la programmation (en Python, ou pas) et l'algorithmique est néfaste.
on peut, mais à condition d'en être conscient.

bien sûr !
ce qui est important c'est que les eleves comprennent qu'un programme est un mur compose
d'une multitude de briques qui sont des fonctions et pas des programmes qui commencent par "lire" et finissent par "ecrire".

ne pas confondre les entrées et sorties d'un algorithme qui sont des notions fonctionnelles et ce qu'il "lit" et "écrit" qui sont des entrées sorties "physiques" sur un clavier ou un écran !!!

et puis des programmes avec des "écrire" multiples en plein milieu ça existe (encore heureux !!)

ma vision des choses.

On considere l'algorithme suivant (conforme bac 2018)
Question: Quelle est la valeur de la variable n à la fin de l'execution de l'algorithme ?

n <- 0
C <- 3.4
tant que C>=1
  n <- n+1
  C <- 0.8*C
fin tant que

def MaFonction():
  n=0
  C=3.4
  while C>=1:
    n=n+1
    C=0.8*C
  return n

fonction TaFonction()
  var n,C;
  n:=0;C:=3.4;
  tantque C>=1 faire
    n:=n+1;
    C:=0.8*C;
  ftantque
  retourne n
ffonction:;

un peu de lecture lobbying ?

une couche de plus

Bonsoir.

Je viens de tomber sur ce topic intéressant...

Sans vouloir (re)lancer une polémique, je voudrais faire quelques remarques :

1/ S'il n'y a pas de signe sur nos claviers actuels, on peut utiliser l'association de < et de - pour former <-.

Pour les affectations d'une valeur à une variable, voir . Tout le monde y a mis du sien pour symboliser une affectation.

Sur les claviers dédiés au langage APL, on trouve le symbole .

2/ Pour Python, s'il y a une hégémonie, il semble qu'elle soit limitée. Python ne semble pas être le langage dominant dans le monde "réel".

Voir les deux liens suivant :

Pour illustrer l'interet des fonctions en programmation,
on peut commenter le programme ci-dessous en classe,
y compris avec des eleves de seconde.
On ne parlera evidemment pas de recursivite,
cette notion etant au programme de deuxieme annee de prepa.
Il faut copier ce code dans une fenetre de programmation de Xcas
pour beneficier de la coloration syntaxique et ainsi distinguer
les fonctions de Xcas de celles de l'utilisateur.

anemone(a,n,c):={
  local L;
  L:=NULL;
  L:=L,cercle(a+i*n,n);
  L:=L,cercle(a-i*n,n);
  L:=L,cercle(a+n,n);
  L:=L,cercle(a-n,n);
  retourne affichage(L,c+rempli),cercle(a,n/2,affichage=rempli+0);
  }:;

tulipe(a,n,c):={
  local L;
  L:=NULL;
  L:=L,cercle(a+i*n,n,3.15,6.4);
  L:=L,cercle(a+i*n-n,n,-0.1,1.58);
  L:=L,cercle(a+i*n+n,n,1.58,3.15);
  L:=L,segment(a+i*n-n,a+2*i*n-n);
  retourne affichage(L,c+rempli);
}:;

fleurs1(x,y):={
  local L,c;
  L:=NULL;
  c:=alea(10)+85;
  si abs(x-y)<0.5 alors 
    retourne L,arc(x,y,-5*pi/12,
    affichage=epaisseur_ligne_3),anemone(y,(y-x)*0.3,c);
  fsi
  L:=arc(x,y,-5*pi/12,affichage=epaisseur_ligne_3),
  anemone(y,(y-x)*0.2,c);
  L:=L,fleurs1(x,x+(y-x)*0.5*exp(i*0.5));
  L:=L,fleurs1(x,x+(y-x)*0.5*exp(-i*0.5));
  retourne L;
}:;

fleurs2(x,y):={
  local L,c;
  L:=NULL;
  c:=alea(10)+85;
  si abs(x-y)<0.5 alors 
    retourne L,arc(x,y,-5*pi/12,
    affichage=epaisseur_ligne_3),
    tulipe(y,(-i)*(y-x)*(0.5)*exp(-i*5*pi/24),c);
  fsi
  L:=arc(x,y,-5*pi/12,affichage=epaisseur_ligne_3),
  tulipe(y,-i*(y-x)*(0.4)*exp(-i*5*pi/24),c);
  L:=L,fleurs2(x,x+(y-x)*0.5*exp(i*0.5));
  L:=L,fleurs2(x,x+(y-x)*0.5*exp(-i*0.5));
  retourne L;
}:;

fleurs1(14,14+6*i),fleurs1(14,19+6*i),fleurs2(0,5*i),fleurs2(0,3+4*i),
legende(4+9.0*i,"JOYEUX NOEL 2017 ET BONNE ANNEE 2018")

@alp12, bonsoir.

Je dirais que l'intérêt des fonctions en programmation dépend du contexte, matériel ou logiciel.

C'est sûr que développer une application sur un calculateur type PC doté d'une mémoire morte ou vive quasi-infinie (disque dur, barrette RAM 2 Go, ...) facilite l'usage d'appel de fonctions.

En 40 ans de développement en informatique embarquée, j'ai connu des processeurs avec une pile (Data Stack) réduite voire inexistante (pas d'instructions CALL et RET) limitant de facto les appels à des fonctions.