Un langage sans "if" - Page 1

Que serait un langage (impératif) sans "if" ?

Le langage obligerait à cacher les tests dans le polymorphisme. Au lieu de

void accident(Vehicule v){
	if (v.nbPneus == 2)
		accidentVelo();
	if (v.nbPneus > 2)
		accidentGrave();
	
}

on serait obligé de:

void maFonction(Vehicule v){
	v.accident();
}


class Vehicule{
	// ...
	virtual void accident();
}


class Velo: Vehicule {
	void accident(){
		accidentVelo();
	}
}

class Voiture: Vehicule {
	void accident(){
		accidentGrave();
	}
}

que voyez-vous d'autre comme impact dans la façon de programmer sans if? Peut-on s'en sortir sans "if" ?

Bah ouai
La seule structure nécessaire pour coder un algorithme est le while. Avec ça, on peut se débrouiller pour recréer le comportement de toutes les autres structures (if,else, for, switch).
Un langange de programmation muni uniquement de while est complet.

Je suis déçu par cette réponse.

Dans ce cas, il faut aussi interdire les while, for, switch. Mais peut-être pas le foreach.
Je voudrais savoir comment ça impacte la façon de penser pour programmer. La différence entre les deux codes dans ./1 est que dans le premier c'est accident qui sait ce qu'il faut faire et dans le deuxième, c'est les objets qui savent comment se comporter parce qu'ils savent qui ils sont.

non mais foreach c'est for...

if(condition) {
A;
} else {
B;
}


-->

euh...

je sais pas
vu qu'un while est un if+goto...

tu pourrais expliquer plus thibaut?

Prolog, y'a pas de if

squalyl (./4) :
if(condition) {
A;
} else {
B;
}


-->

euh...

je sais pas
vu qu'un while est un if+goto...

ben...

while ( cond ) {
   A
   break
}
while ( !cond ) {
   B
   break
}

non ?

oui c'était trop con en fait, j'avais pas pensé au break

Enfin de toutes façons, on peut très bien se débrouiller avec if+goto aussi, je ne vois pas ce que le while a de si spécifique


PS : sans le break on peut faire ça je suppose (enfin bon, ça revient à un break )

bool continue= true ;
while ( continue && cond ) {
   A
   continue= false
}
test= true ;
while ( continue && !cond ) {
   B
   continue= false
}

./1 Ton exemple est de mauvaise fois et induit en erreur. Tu as pris un exemple où la prog OO s'applique parfaitement, et tu l'as traduit en non OO. De cette manière, on a l'impression que se passer de "if" est mieux, et qu'il faudrait effectivement un language sans OO.

Bon et sinon, une tel language (de la façon dont je me l'imagine, càd avec une classe incluse dans le language qui d'une manière ou d'une autre fait un if) serait excessivement lourd à utiliser. Je ne pense pas qu'on puisse se passer de "if", sinon ça ne serait qu'un language de description.

De toute façon, les sauts apportent beaucoup dans un programme, ce serait bête de s'en priver.
Mais finalement, je ne suis pas sûr de bien cerner ta question.
Quel que soit le sucre syntaxique permettant de réaliser un saut (while, for, if, fonction(), break, return), le résultat est le même : le pointeur d'instruction du µprocesseur (pc) effectue un saut...

(v.nbPneus <= 2) ? accidentVelo() : accidentGrave();

ah oui carrément en fait

(cond)?cond_a():cond_b();

int cond_a() {
A;
return 0;
}

int cond_b() {
B;
return 0;
}

ca revient à ./2 et ./3, on interdit toute expression booléenne si vous voulez. Je réponds aux autres dans peu de temps.

non mais tu veux faire quoi sans instruction conditionnelle!

je peux bien te sortir un

#ifdef __m68k__
asm("tst cond \n beq A \n bra B");
#elif defined(__i386__)
...
#elif...
#else
#error vtff
#endif

mais tu vas dire pas d'asm inline...
spas très drôle. Si t'as une idée ponds la; sinon je vois pas trop!

il ne veut pas une astuce pour contourner la contrainte du "sans if", il veut juste explorer ce que signifierait un language "sans if" et la manière de raisonner qu'il faudrait employer pour programmer (si c'est possible).

sur les GPU y'avait pas d'instruction conditionnelle ce qui rendait les shaders programmés plus rapides qu'un prog asm standard vu qu'on cassait pas le pipeline.

Mais même la je crois qu'on en a ajouté, des branch. cf le langage CUDA de Nvidia.

squalyl (./4) :
non mais foreach c'est for...

non foreach c'est pas for. Dans for, on est obligé de mettre une expression booléenne.

./11 ( et ./15 ./17 )> Oui, tu penses comme un programmeur asm. Evidemment au final ça va faire un saut. Le but, c'est d'interdire certaines choses au niveau du langage, pour forcer le programmeur à tenter de faire autrement et voir l'impact que ça peut avoir: est-ce chiant? est-ce plus maintenable? est-ce inutilisable?.. etc.. Ce qui me fait répondre à ./10:

./10 > Oui le premier exemple est particulièrement attirante, mais comme tu l'as présenti, ca devient plus compliqué quand il faut faire l'équivalent de:

if (dayDatas.ferie || dayDatas.chomematin && dayDatas.chomeaprem)
{
faisCa();
}

à vu de nez, il faut faire 5~6 héritages pour arriver à ça. Mais est-ce que le fait d'obliger le programmeur à faire ces héritages ne le pousseront pas à ne pas créer des variables membres inutiles et, au moment de surcharger la fonction qui va gérer faisCa spécifiquement, ca ne l'oblige pas à avoir toujours en tête le sens de chaque classe enfant?

"Un langage sans if", n'existe pas. Pourquoi ?
- Parce que pour compater deux valeurs on fait une soustraction.
- Parce que l'opérateur EQV(A, B) ( NOT(XOR(A, B)) ) est facile à obtenir.
- Parce qu'on peut mathématiquement créer la fonction IF.
- Parce que dans un microprocesseur il n'y a pas de conditions, pourtant on en a en programmation.
b) c = a; else c = b; afficher(c);En bref le concept est simple, au lieu d'avoirif (a == afficher(c);

ben tu aurasr = ifeq(a, b); // retourne 0 ou 1
c = r * a + (1 - r) * b;

En gros tu augmentes le nombre d'opérations par un facteur potentiellement infini. Tu gagnes... rien.

Je passe sur les vertu de la programmation structurées et ses semblables parce que je veux pas m'éterniser, mais bon un langage sans if ça n'apporte pas de concepts, donc ça ne sert a rien.

J'ai pas compris grand chose à ton post, mais c'est surtout ça qui me trouble:

GoldenCrystal (./19) :
- Parce que dans un microprocesseur il n'y a pas de conditions, pourtant on en a en programmation.

Ben oui dans un microprocesseur tu as de la logique combinatoire. De la logique et rien d'autre.
Pourtant quand tu programmes ben tu utlise des conditions...
Si tu veux que je sois encore plus clair... Il suffit de "coder le microprocesseur" dans ton programme...

GoldenCrystal (./19) :
ben tu auras

r = ifeq(a, b); // retourne 0 ou 1  
c = c * a + (1 - c) * b;
afficher(c);

- 2*c + 2*r

Heu oui merci je corrige

ok merci pour tes remarques.

comment tu ferais void accident(Vehicule v) de l'exemple 1, sans if, en appelant accidentVelo et accidentGrave dans son corps?

Bah tu es obligé de passer les conditions de bout en bout, c'est pour ça que j'ai parlé de potentiellement infini
ça se fait, mais ça sert a rien ^^
Tant que "l'interdiction" se contourne mathématiquement ça ne sert a rien d'interdire
Autre chose encore, la méthode des objets, elle marche pas parce que... à un moment tu dois bien créer tes objets. Si tu as pas de conditions tu créera toujours le même (type d') objet

Attend je ne comprends pas là.

Tu veux dire que tu ferais les hacks mathématiques que tu as écrit pour nbPneus == 3, nbPneus == 4, nbPneus == 5 etc.. ?

Sinon pour le type d'objet... Le handler du bouton1 crée un objet Velo, celui du bouton 2 crée un objet Voiture et l'ajoute au jeu par exemple. Où est le problème?

Pen^2 (./9) :
Enfin de toutes façons, on peut très bien se débrouiller avec if+goto aussi, je ne vois pas ce que le while a de si spécifique

C'est un chercheur en informatique théorique qui nous a dit ça, l'année dernière, en cours de C. Ce serait prétentieux de le contredire, mais on peut débattre oui.
Peut-être qu'il évince le if+goto parceque ça fait 2 instructions. Avec un while, une seule instruction suffit, comme tu l'as montré au post ./9.

Hmm quand je dis passer les conditions de bout en bout.
C'est pour (nbPneus > 2) tu passe le résultat de la condition (0 ou 1, que tu t'es démerdé pour calculer, ça se fait ^^) à ta fonction.
En gros tu aurais des fonctions avec toutes un paramètre "bool executer" que tu appliques récursivement a chaque endroit nécéssaire dans la fonction, c'est crade mais à moins de vraiment faire une émulation processeur complète on ne peut pas simuler l'instruction goto

Pour les objets ce que je veux dire c'est que ton programme à l'état le plus basique, reçoit des chiffres. Que ce soit des caractères entrés au clavier, lu d'un fichier texte, des codes de couleur, ou la position de la souris. Pour passer a des objets tu dois forcément transformer ces chiffres en informations. Ton objet "fenetre" devant etre défini dans ce même langage (sinon c'est de la triche, tu inderdis le if aux autres mais toi tu l'utilise, prouvant par la même que ton langage est inutilisable ^^), et bien tu ne peut te passer de ifs pour déterminer quel bouton a été cliqué, quelle touche enfoncée, etc...

EDIT: Quoique tout bien réfléchi tu couples ma méthode avec la tienne ça contourne entièrement le if
Les méthodes virtuelles remplacent les goto, et hop

L'idée de départ c'est de "cacher" les if dans le polymorphisme, comme j'ai dit dans ./1. Je veux savoir si c'est suffisant pour obliger les gens à l'utiliser à fond le polymorphisme. D'après ce que tu montres, il faudrait interdir les opérations bit à bit aussi. C'est pour ca que je trouve ça intéressant (je m'attendais à ce que quelqu'un arrive à cette remarque, suite à une discussion avec un pote qu'on a eu sur le sujet). D'ailleurs, il faut aussi interdire les trucs du genre pointeur de fonctions...

Par contre, quand tu fais une infinité de ligne de code pour contourner une interdiction, c'est que l'interdiciton ne sert pas à rien. Non?

D'ailleurs, même si tes hacks étaient permis par le langage, càd si on permettait les opérations bit à bit, le but ici n'est pas dire si un tel langage sert à quelque chose, mais de voir l'impact que ça a dans la façon de construire/concevoir le programme.

Concernant les "if" dissimulés dans les handles, au risque de me répeter c'est toujours la même chose. Evidemment que le processeur fait un saut un jour ou l'autre.
Pour être honnete, y a une question à laquelle j'arrive pas à répondre. Comment faire un programme qui prend un entier écrit au clavier et qui dit si le nombre est supérieur à 10 ?

Tu fais une récurrence sur les caractères... (pour contourner les boucles conditionnelles... enfin ça ne rime vraiment à rien)
Si le caractère initial est -, il est inférieur. Fini.
Si le caractère est 0 on regarde le suivant jusqu'à != 0 ou la fin. A la fin on sait que le nombre est <= 10
Si le caractère est != 0 on regarde juste si le suivant est aussi, dans ce cas le nombre est > 10.

A chaque fois tu dois faire une comparaison sur les caractères ">= '0'", "<= '9'" aussi mais bon... Logique combinatoire... ça se fait.

Et quand tu propose de supprimer carrément touts les opérateurs logiques... ça se contourne également, mais ça devient vraiment lourd... Tu veux aussi interdire les additions du coup non ?
Sinon pointeurs de fonction = fonctions virtuelles. Soit il dit en passant c'est super lent en réalité (a plus forte raison si tu en as beaucoup, et dans ton cas c'est inévaitable, car à ce moment la la taille de ton éxécutable augmente énormément pour contenir chacune des mini fonctions qui en apelle d'autres etc..., donc tu utilises presque jamais le cache du cpu), et ça s'optimise très peu pour ne pas dire "pas du tout".

Et les "if" dissimulés dans les handles . Y'a pas de handle pas de machin. A un moment en implémentant TON language, dans TES librairies codées avec TON langage tus eras OBLIGE de faire un if, que ce soit pour tester un HANDLE, un pointeur de classe externe, un ID de controle, ou des coordonnées de souris.

Normalement tu peux résumer la grande majorité des programmes non systèmes (donc pas besoin vital de manipuler des champ de bits) à 3 opérations: addition, comparaison, branchement. Toi tu propose de supprimer "comparaison".
L'utilisateur de donne deux entiers a et b, te demande lequel est le plus grand. Tu as interdit opérations logiques, tests conditionnels et compagnie... Tu fais quoi ?

C'est pas viable