Reprise du message précédent :
pour moi, un langage évolué comme le C# ou même la daube qu'est Java est tout à fait pertinant pour apprendre l'algorythmie.
 
bon, après, aucun langage n'arrive au petit orteil d'ADA en ce qui concerne l'apprentissage mais bon... au moins avec un langage évolué on arrive rapidement à faire un petit truc fun qui marche alors qu'en ADA, rien que pour afficher les 10 premiers éléments d'une factorielle tu pleures

Par contre, l'orthographe c'est pas encore ca...  

c'est de la faute d'IntelliSense

 
Quitte à prendre quelque chose de pertinent, autant prendre un langage comme Scheme plutôt que de s'emmerder avec les paradigmes imposés par Java (définir une classe pour faire un "hello, world", spécifier les types concrets des objets, se voir imposer un cycle de compilation rigide etc.)

VB, y'a que ça de vrai

 
Parce que y'a aucun paradigme imposé dans Scheme peut-être ?

 
Ai-je dit le contraire ? Je pointais simplement l'emmerdement que constituent les modèles imposés par Java. De mon point de vue, Scheme n'impose aucun modèle particulièrement déroutant quand il s'agit d'implémenter les algorithmes d'un cours de base sur l'algorithmique.

Lol

Bof, l'ADA fait chier pour des conneries, Haskell aussi a un type system furieux. Moins que les anciens ADA probablement, mais très contraignant néanmoins, cf la citation de sigfpe:

 
Et ce en étant largement moins chiant et moins verbeux qu'Ada

Ce ne sont pas des paradigmes

Citation qui repose sur du vent ?

Appelle ça comme il serait correct de l'appeler, tu m'as compris.

 
Pas compris la remarque

ADA j'ai dit que c'était bien pour apprendre "tout court". Pour l'algo, c'est pas loin d'être une horreur, parceque rien que pour compiler un prog qui fait la division entre deux nombre saisis en paramètre t'as 500 lignes de surcharges, d'exceptions et autres à taper pour que ça compile. Donc pour l'algo...
 
Par contre, quand t'arrives à écrire un prog ADA qui marche du premier coup, t'as toutes les bases nécessaires pour appréhender la plupart des langages sans sourciller.
Par rapport au C par exemple, où on peut faire tout et surtout n'importe quoi, c'est un gros avantage. L'ADA t'oblige à écrire des algos qui ne reposent pas sur des économies de bout de chandelle, ce qui est propre à un bon algo : c'est pas au niveau de sa transcription en langage qu'on doit s'occuper de l'améliorer, mais en amont, lors de sa conception.
 
Pour un algo complexe, c'est particulièrement intéressant de trouver à la conception la solution la moins coûteuse, plutôt que de prendre la première qui passe, et rendre le code illisile à coup d'optimisations "alakon".

PS : D'ailleurs, moi j'ai toujours appris l'algo avec une feuille et un crayon.
 
La transcription dans la langage, c'est ensuite "juste du pissage" de code pour moi. C'est deux métiers totalement différents qui reposent généralement sur les épaules de d'une même personne. Mais à la base, je suis loin d'être convaincu qu'un langage soit mieux qu'un autre pour ce qui est de l'algo.
Alors qui peut le plus peut le moins : transcrire un algo objet en C, c'est pas super évident. Avec un langage évolué, c'est limpide. D'où ma phrase à propos de C# ou Java.

 
Je vois pas l'intérêt d'affirmer une telle chose vu le flou que représentent les mots "likely" et "useful", ici.

Pas d'accord, certains uniquement, et impératifs uniquement. Avoir fait de l'Ada ne t'aidera pas à apprendre l'Erlang ou le Forth. À part dans le sens où, personne n'utilisant Ada, il y a des chances pour que les gens l'apprenant aient appris nombre d'autres langage et aient donc des facilités dans le domaine (ou soient intéressés par l'apprentissage de nouveaux langages en permanence)

Un langage "bon pour apprendre l'algo" c'est justement un langage dans lequel cette transcription n'existe pas, ou quasiment pas, un langage où la transcription est naturelle et le code aussi clair que l'algo/pseudocode "papier"

1. C'est une plaisanterie avec un fond de vérité (comme beaucoup de citations dans ma collection, la taille du fond variant mais étant souvent grande), pas un axiome...
2. C'est un sentiment qu'ont énormément d'utilisateurs d'Haskell et qui découle de son système de types extrèmement strict et fin, ceci étant l'une des caractéristique principales d'Ada (avec une gestion d'erreur là aussi extrèmement stricte puisque toute erreur possible se doit d'être gérée). J'avais une citation sur le sujet mais je ne la retrouve pas là tout de suite, mais en substance elle disait qu'en Ada si on réussit à compiler un programme il n'aura pas de bugs.

Bien sûr d'autres sont plus critiques sur le sujet (d'Ada), d'où cette citation de Bruce Powel Douglass

3. Je ne vois pas en quoi les mots "likely" et "useful" sont flous...

 
c'est de moi ça ?

Je serais incapable de te le dire

c'est en tout cas ce que j'ai appris lorsque j'ai fais mes études.
 
après quelques croûtages en règles avec pourtant une compilation correcte, le prof a dû revenir sur cette affirmation.
cependant, ADA est un des rares langages où dès l'écriture, à tout moment, on sait comment il va se comporter, et sans surprise. donc même si le compilo a laissé passer des bugs potentiels, on est sûr à chaque instruction de ce qu'elle va faire.
 
inversement, en C par exemple, on peut parfaitement caster un uint en int, et se retrouver avec un superbe dépassement de capacité, sans que ce soit visible au premier coup d'oeil : c'est à dire que là où ADA va lever une exception à l'exécution, le programme C va continuer comme si de rien n'était, et commencer à faire du grand total n'importe quoi (et peut-être planter 1000 lignes de code plus loin).

Je suis au courant, j'ai un peu regardé Ada

Mais justement, c'est pareil pour Haskell, pire même puisque pour chaque fonction on sait si elle contient des effets de bord (IO, modification d'état, ...) parce que ça fera partie de son type

Et comme le langage est fonctionnel pur (pas d'effets de bords, pas de variables locales, les variables sont en fait des constantes [bind-once]) il y a des classes complètes de bugs qui ne peuvent tout simplement pas exister

Ou trasher ses pointeurs avec des pointer arithmetics foireux, ou flinguer sa pile, ou utiliser une zone mémoire non initialisée, ou écraser des zones mémoires allouées à d'autres structures, ou plein d'autres trucs très marrant mais assez gênants quand on voudrait une application avec peu de bugs, je sais

Pour apprendre les bases de l'algo, le mieux reste le QBasic

Tu te fais pas chier avec les types, les machins les trucs, t'as juste ce qu'il faut, tu va direct au but, t'as pas un langage à la con en-dessous avec 20 000 trucs à faire.

Genre faire de l'algo avec du Java ou du C# c'est n'importe quoi, le moindre truc que tu veux faire, tu te tapes cash une classe avec fonction main et tout, ce qui fait déjà trop d'information pour débuter.

Pour se concentrer sur un truc, mieux vaut ne pas avoir de bruit autout. Alors tu fais ça en QBasic, t'as ton code devant toi, rien autour, t'as juste l'essentiel

Marrant, on dirait une description de Python mais au sujet d'un langage moche

Et pour les types, le problème de Java et C# n'est pas d'en avoir mais de devoir les préciser en permanence y compris (et surtout) quand ça n'a strictement aucun intérêt et que ça fait perdre un maximum de temps

Parce qu'avoir des types, c'est le bien, quand on a pas de types on se retrouve avec PHP alors bon voila quoi

en meme temps le java c'est quend meme un peut compliqué, le C++ je crois que ça permet de commencer en douceur, avec des additions, des boucles et tt le tralala et de migrer doucement vers de la prog GUI.

C'est une blague?
 
Non parce que Java à la base c'est une simplification du C++, tout ce qui était complexe et (de l'avis de Sun) générateur d'erreur a été dégagé (gestion manuelle de la mémoire, pointeurs, operator overloading, templates, MI, séparation .h/.cpp, ...).
 
Et ça reste beaucoup moins complexe que le clusterfuck qu'est le C++

 
Heuuu je ne suis pas un excellent programmeur ADA mais je peux te dire que je vois plus souvent des "constraint error" (erreur a l'execution) que des erreurs de compilation. J'ai pu observer une promo réaliser un compilo en ADA, ce qui changeait par rapport a l'epoque ou ca se faisait en C, c'est que sur les ecrans a la place de "Segmentation Fault" on avait "Constraint Error" et ca n'etait pas forcement plus utile pour déboguer ...
 

 
apres certaine notion connue, je dit pas que le java c'est pas super simple a utiliser, mais faut deja connaitre les pointeurs, les types, les classes.
 
perso je connaissait C++ avant java, et le java, evidement, ça m'a parus facile, mais les gars a coté de moi qui connaissait pas le C++, ont eu du mal a comprendre les etiquettes, et pk ça marchait pas sur les int, et les void, les contructeurs, c'est quoi un garbage, ou elle est la memoire  ect...

elle est passée où la blonde aux gros seins du topic ?

pour moi, la meilleur façon d'apprendre la prog c'est :
- commencer par ADA pour apprendre à coder proprement / expérimenter l'aglorythmie qui se traduit bien du pseudo-code en ADA
- faire du C en même temps ou juste après pour comprendre les mécanismes bas niveau et s'habituer à cette syntaxe largement utilisée (java, C++, C#, javascript )
- passer à un langage moderne : C++, Java, C# dans le cadre de projets conséquents pour s'habituer à la manpulation d'un IDE, apprendre à utiliser un vrai environnement de dev (avec repository, bugtracker, etc.), s'habituer à la recherche/réutilisation de libs externes
 

C'est ce que j'ai suivi à peu près :

• QBasic pour apprendre les bases (if-while-for-input-print)
• C pour le bas-niveau, piger comment tout fonctionne à la base
• Un tout p'tit peu d'assembleur pour voir vraiment comment ça se passe tout en dessous
• Haut-niveau avec Java et .NET

 
Manque de fonctionnel tout ça

stop les gars, il veut juste se faire plaisir en aprenant a prog, a ce rythme là, il va devenir flic ou fonctionnaire des impôt

Pas vraiment, même le NPE -- qui est le seul endroit en Java où j'ai pu rencontrer une notion de "pointeur" -- ne parle en fait pas de pointeurs.

Bof, pas besoin de connaître quoi que ce soit en théorie des types pour faire du Java. Pas nécessairement du "bon" java, mais du java quand même

Oui, à la limite, et encore. Mais si on ne connait pas les classes on ne fait pas non plus du C++, on fait un espèce de trucs immonde entre le C et le C++...

Et alors, c'est censé montrer que le C++ est plus simple que le Java? Où penses tu qu'ils en seraient si on leur faisait apprendre le C++?

Pour moi la meilleure façon de commencer ce serait plutôt:

* Un langage clair et très haut niveau dans lequel "ça fonctionne", mais qui ne file pas des habitudes horribles. De cette manière l'élève peut être intéressé sans être complètement dégouté, et peut faire des choses utiles. Python est très bien pour ça, Ruby est également acceptable, Scheme peut probablement être une bonne idée mais il force l'apprentissage de concepts complexes très rapidement (récursion omniprésente)  et possède une syntaxe complètement en dehors du chemin classique. Introduire le concept d'environnement de devs immédiatement: versioning obligatoire dès cette étape. Introduire également la notion de qualité et de tests (unitaires et fonctionels)
* Introduire des contraintes (perfs) et complexités qui forcent tout d'abord l'introduction de la recherche algorithmique et structurelle (toujours les meilleurs gains), puis de la micro optimisation. Introduction du C à la fois en tant que langage et en tant qu'outil de gain de performances. Introduction et utilisation d'un langage très fortement typé (ADA) avec explication du pourquoi. Ajouter l'importance de la recherche de libs 3rd party (qui aura normalement commencé en première étape)
* Passer à un langage pour boulet (C++/Java/C#) pour montrer aux élèves ce sur quoi ils vont passer leur vie, au bout de 2 semaines introduire les IDEs pour éviter les suicides.
* Finir en introduisant les paradigmes de programmation hors impératifs/OO: fonctionnel (Haskell, Caml ou SML), distributed/parallel (Erlang?), logique (Prolog), DBC (Eiffel puisqu'il est l'un des rares langages basés sur le concept)
* Optionnellement, ajouter une descente vers l'ASM si la chose est encore possible à ce stade (pas sûr)

Et là tu finis avec des gens qui connaissent leur domaine et son capable de choisir en connaissance de cause.

Mais qui, au monde, à part Masklinn fait du fonctionnel ?

 
alors 1)
 
les pointeur en java ça existe, il n'y a même pratiquement que ça, c'est pour ça que l'on utilise des new, sauf pour les types simples comme les int, ou l'on utilise uniquement le contenus de la variable, et pour expliquer pourquoi un "void fonction(int i, Integer I) va modifier le contenu du parametre passé en operande de l'integer mais pas de l'int a quelqu'un qui ne connais pas le principe des pointeurs, une solution; lui aprendre ce qu'est qu'un pointeur.
 
2) quand je dit classe, c'est de la prog objet dont je veut parler, en C++ on peut passer doucement d'un printf jesait pas quoi, a la creation d'un classe qui implemente le printf, et en faire apres des heritages, et des polymorphisme et tt le reste, alors qu'en java, tu n,e fait rien tabt que tu ne sait pas faire un constructeur.
 
3) si l'on connais le C++, je passage a java est quasi imediat, pour le contraire, ben bon courage, donc connaitre le C++ apporte bc.
 

référence

je vais pas t'envoyer mon cour non plus hein , mais je vais t'apprendre google
 
http://www.google.fr/search?client [...] che+Google

et en C++, tu fais un pointeur comme une référence ?    

 
et bien va expliquer la difference a qq qui a appris a prog uniquement avec java !

Faut arrêter de fréquenter des arriérés aussi, c'est pas non plus de la magie noire un pointeur.

le topic a été créé par un noob de la prog, donc pour moi C++ c'est bon pour lui, et les pointeur ça peut qd meme donner mal a la tête qd on a pas bien l'habitude
 

Les gens qui bossent dans les télécoms quand ils veulent du 9 nines

Pas au sens des pointeurs C, non. Il n'y a pas d'arithmétique de pointeurs, pas de manipulation complexes de ceux-ci, pas de déréférencement explicite, pas d'allocation explicite du pointee, les pointeurs sont cachés derrière la notion de référence, comme dans la très grande majorité des langages avec GC.

Heuu je ne sais pas dans quel univers parallèle tu résides, mais en l'occurence dans le mien il ne le fait pas
 

import java.lang.Integer;
public class Test {
    public static void function(int foo, Integer bar) {
        foo = 3;
        bar = new Integer(5);
    }
    public static void main(String args[]) {
        int foo = 0;
        Integer bar = new Integer(0);
        System.out.println("Pre function, foo = " + foo + ", bar = " + bar.intValue());
        function(foo, bar);
        System.out.println("Post function, foo = " + foo + ", bar = " + bar.intValue());
    }
}

Output:

Ce genre de trucs n'est faisable qu'en C# avec les outparameters et les références "à la C++", qui doivent être déclarées explicitement et ne font pas partie du comportement par défaut du langage.

Printf c'est du C, pas du C++, ça revient à ce que je disais: faire du C++ sans POO, c'est pas du C++.

Pas besoin d'un constructeur pour bricoler de l'impératif dans un `main`, non

C'est pas un argument ça, c'est du grand n'importe quoi
 
Pour la dernière fois, le Java a été fait pour être plus simple que le C++, il n'y a rien d'anormal à ce que le passage C++ -> Java soit relativement facile, c'est exactement dans cette optique que le Java a été créé, le contraire serait plus qu'étonnant

import java.lang.Integer;
public class Test {
    public static void function(int foo, Integer bar) {
        foo = 3;
        bar = new Integer(5);
    }
    public static void main(String args[]) {
        int foo = 0;
        Integer bar = new Integer(0);
        System.out.println("Pre function, foo = " + foo + ", bar = " + bar.intValue());
        function(foo, bar);
        System.out.println("Post function, foo = " + foo + ", bar = " + bar.intValue());
    }
}

 
suis pas d'accord sur grand chose ;
 
si l'on modifie ton code de la maniere suivante;
 

import java.lang.Integer;
public class Test {
    public static void function(int foo, Integer bar) {
        foo = 3;
        bar = 5;
    }
    public static void main(String args[]) {
        int foo = 0;
        Integer bar = new Integer(0);
        System.out.println("Pre function, foo = " + foo + ", bar = " + bar.intValue());
        function(foo, bar);
        System.out.println("Post function, foo = " + foo + ", bar = " + bar.intValue());
    }
}

le nouvel Output:

 
avec une notion de surcharge au passage.
 
 
printf ça marche en c et en c++, c'est une fonction certe ecrite en C mais qui fonctionne parfaitement en C++.