Malbolge, je connaissais pas du tout mais oui c'est assez spécial... XD

L'assembleur en même temps, tout est plus ou moins ramener vers lui, vu que c'est le langage dont la logique est une des plus proches (je ne sais pas si il y a d'autres langages le ressemblant ou du même niveau) de celle du microprocesseur. Je ne parle pas vraiment technique parce que je ne suis que développeur web mais plutôt de mon ressenti.

Par contre perso y a des trucs où je ne suis parfois pas vraiment d'accord comme on dit souvent que le langage C est un langage de bas niveau, j'aurais plutôt tendance à dire l'inverse (enfin je parle de manière générale et de la logique de base, certes on peut très bien faire du bas niveau avec du C ça c'est clair et net, et encore heureux !). De manière globale, que ça soit en C, PHP (2 langages que je connais, je ne vais pas m'aventurer dans ceux que j'ignore même si je sais que pour certains PHP est loin d'être un must etc) j'utiliserais sensiblement la même logique, pas en assembleur.

Et même au sein d'un langage, la logique peut différer complètement, exemple le procédural et l'objet, c'est 2 façons de réfléchir différentes. C'est dur de classifier la "difficulté" d'un langage, après certes la notion de haut niveau et bas niveau indique déjà pas mal de choses, mais autant un langage va paraître simple pour un et compliqué pour l'autre, et vice versa.

Par définition, un langage assembleur c'est l'ensemble des instrutions que ton (micro)processeur sait exécuter. Après, tu en as des dizaines (en fait, rien que chez intel tu en as déjà des dizaines).

"on dit souvent que le langage C est un langage de bas niveau" C'est simple :
Les listes sont elles des objets de langage ? non.
Les fonctions sont-elles des objets du premier ordre (= manipulable comme des entiers) ? pas vraiment.
Gère-t-on la mémoire pour toi avec un garbage collector ? Assurément pas.
Donc c'est un langage très bas niveau.

"exemple le procédural et l'objet" pour moi ce n'est pas comparable. Qu'entends-tu par "procédural" ? Tu veux parler de programmation modulaire ?

"C'est dur de classifier la "difficulté" d'un langage" oui. Mais quand tu as une grosse dose de théorie derrière la machinerie (genre la couche objet de C++ et les monadess de Haskell), tu peux te dire que tu as affaire à un langage dur.

Je ne suis globalement pas d'accord avec tout ce qui a été dit Je dirai qu'un langage compliqué est un langage dont les programmes sont dur à lire par une tiers personne (ou meme par la personne qui l'a écrite quelque temps plus tot) lorsqu'il a été écrit en respectant les bonnes pratiques du langage.

Je rajouterai donc Perl en tete de liste

Ensuite le Java, car même si le langage lui même est simple, les frameworks (web, client lourd & co) ou archi logiciel qui lui sont associés nécessites bcp plus de boulot pour comprendre le code.

Ensuite le C++, même si on est avisé et qu'ont fait les choses correctement il arrive toujours un moment ou on se laisse aller et la... c'est le drame

Je mettrais l'assembleur en milieu de liste, car la, ca dépend vraiment du codeur et il n'y a pas de concepte bizzare ou complexe mais il est looooonnng a lire.

En fin de liste, pour les langage les plus simples, je metterai le C, car il évite les concepts complexes et est lisible.

Globalement, comme dit au début, le langage le plus compliqué est celui qu'on connais le moins, car même si un langage de haut niveau (C++, Java) propose des concepts complexe il n'est pas obliger de les utiliser.

KouicKouic: dans une première passe, je m'en fiche qu'un code soit dur à lire… mais alors complètement. Ce qui compte avant tout, c'est que le code fasse ce que j'attends de lui. Ensuite seulement, je veux qu'il fasse ça de façon performante (vite et sans bouffer une quantité éxagérée de RAM). La lisibilité, ça n'arrive qu'en troisième chez moi.

« il n'y a pas de concepte bizzare ou complexe » va lire le 3ème manuel du x86 et on en reparle. Sans aller si loin, fais-moi une fonction de tri fusion en x86 et on en reparle.
Et je ne parle pas des règles des contraintes liées aux règles d'ordonnancement mystiques sur un pentium 4.

Sinon, je suis assez d'accord sur le fait que le C est plutôt simple. Une fois le concept de pointeur assimilé, le reste n'est presque que de l'algorithmique basique et de la syntaxe.

Je suis d'accord avec toi, Chris_27, sur ce qui compte c'est bien qu'un programme fasse ce pour quoi il a été ecrit. Mais je n'ai pas les mêmes critere que toi pour la suite. <troll> Codant essentiellement en C et C++ mes programmes sont toujours rapides et legers. </troll> Pour moi la lisibilité est primordial ("déformation" professionnelle), car lors d'un pépin ou d'une évolution nécessaire, un programme dure a lire est au mieux une perde de temps au pire une galere avec le client.

J'ai tendence a associe la complexité du code avec la complexité du langage car en général les problèmes de compréhention de programmes arrivent avec les langage que j'ai classer en haut de ma liste des langages complexe.

"va lire le 3ème manuel du x86 et on en reparle. Sans aller si loin, fais-moi une fonction de tri fusion en x86 et on en reparle. Et je ne parle pas des règles des contraintes liées aux règles d'ordonnancement [...]

La tu confond la complexité de ce que tu veux obtenir avec la complexite du langage lui meme. C'est comme demander de faire une IA parlant Klingon en quatrain avec du Java.

En assembleur, tu as des contraintes sur les instructions directement reliées aux contraintes architecturales. Sans une certaine maîtrise de l'architecture, tu n'arriveras pas à produire du code correct.

Et pour le tri fusion, c'est très faisable. C'est même un des cas d'école pour vérifier si on sait gérer correctement la pile avant/après un appel de fonction.

Il est clair qu'en assembleur, il y a des contrainte architecturales a prendre en compte. Néanmoins, tu peux produire du code correct. Je ne parlerai pas du codage en ASM sur processeur x86/x64 & co car la complexité ne viens pas du langage lui même mais de la cible. Sur micro-processeurs de base tu n'auras pas a te soucier de concept complexe, objet ou autre (mis a par les pointeurs comme tu l'as spécifié plus tot).

Bon, apres on peut chipoter sur la définition de ce qui est dur ou pas. Forcement, je me base sur mon parcours. A 16 ans, l'ASM ne me posait pas de problème et j'étais tout fière de prog en ASM grace auquel j'utilisai le FPU pour calculer les coords de mon cube en 3D fil de fer ...

Bah, du code "correct" c'est vite dit. Un exemple typique auquel on finit par être confronté:

int 80

C'est une instrubtion tout ce qu'il y a de plus correcte … sauf que tu ne peux pas la placer n'importe où (et de fait, si tu es user sur un système un minimum sécurisé, tu ne peux pas la placer du tout).

Ba, c'est comme vouloir ouvrir un fichier en Java, sur un systeme un minimum sécurisé tu ne peux pas tout ouvrir.
Cela ne viens pas du langage.

Si, a effet équivalent, on compare les codes suivants :

public class Bonjour {
public static void main(String[] args) {
System.out.println("Bonjour");
System.exit(0);
}
}

et

1. include <stdio.h>
2. include <stdlib.h>

void main(void) {
const char* BONJ = "Bonjour\n";
fprintf(stdout, BONJ);
exit(0);
}

et

.globl _start
BONJ: .ascii "Bonjour\n"
_start: mov $4 , %eax ; 4 : appel Write
mov $1 , %ebx ; 1 : fichier STDOUT
mov $BONJ , %ecx ; chaine a afficher
mov $8 , %edx ; taille de la chaine
int $0x80 ; Int 0x80, appel

mov $1 , %eax ; 1 : Exit
mov $0 , %ebx ; 0 valeur de retour
int $0x80 ; Int 0x80, appel

Perso, je vois plus de concepts compliqués en Java qu'en ASM. Le C me semble le plus simple des 2.

Vous nous refaites la difference entre "tedious" et "complex". Pendant longtemps, le C a ete considere comme un "macro assembler". Ce qui est complique en assembleur, c'est le volume d'operation et les registres qui ne sont pas interchangeable.

Gérer sa pile correctement, c'est pas juste tedious amha. Et faire un peu de système en assembleur non plus. Après, je suis bien d'accord pour dire que la difficulté est plutôt d'ordre technique que d'ordre conceptuel.

Tout a fait d'accord.