Quels sont les meilleurs languages de programmation [...]

Sur OS X, dans des langage a peu pres connus, tu as plusieurs types :

Les langages interpretes, souvent plus lents :
- Java, tres bon, mais ca prend un peu de temps pour s'y mettre, l'interet, c'est que ca fonctionne "a peu pres" partout.
- Les clones d'HyperCard : super intuitif, vraiment sympa pour decouvrir la programmation, mais c'est limite. Il y en a plusieurs je crois. Un pile de ce type necessite un player. Les players existent sur beaucoup de plateformes differentes.
- Le Lingo de Director : Facile sympa, marche sous Windows et MacOS 9 (pas MacOS X!). C'est tres graphique, on peut creer des jeux assez facilement avec Director, mais bon, ca restera des petits jeux.
- Les langages fonctionnels pour faire des maths ou du prototypage : LISP, PROLOG, c'est pas top l'eclate quand meme.

Les langages compiles :
-RealBasic, pas un foudre de guerre mais il a l'avantage d'etre tres tres simple a apprendre et de permettre de developper de tres bonnes applications. En plus, c'est compatible MacOS 9/MacOS X/Windows. Tres bons produit malgre quelques bugs. L'interet, c'est que s'il te manque une fonctionnalite, tu peux aller fouiner dans tous les plug-in existants ou ecrire ton propre plug. Il est tres facile de realiser un plug RealBasic si tu connais un peu le langage C.
- ObjectiveC Cocoa, ca met un peu de temps a s'apprendre et il faut avoir des bases en C. Mais ca devient quand meme tres rapide pour developper des interfaces. Beaucoup mieux que Carbon pour cette tache.
- C++, tu peux utiliser du C++ dans tes projets Cocoa ou Carbon, ou meme PowerPlant. PowerPlant fournit des classes C++ permettant de faciliter la creation d'interfaces.
- Le langage C, mon prefere, car on peut tout faire avec, et les instructions de base sont tres simples. Bon, ok, ca prend du temps d'apprendre le C, mais c'est indispensable pour etre un vrai programmeur, et puis, ca aide pour le C++ ou ObjectiveC ensuite. Tu peux faire un projet Cocoa et utiliser du C pour faire des libraries multiplateformes.
- Le Pascal... Heu, ben chai meme plus si ca existe encore sous OS X. Si, ca doit exister, mais bon, tant qu'a faire, le C est mieux.
- L'assembleur : si tu as envie d'apprendre un langage tres complique, tres fastidieux pour faire presque rien, si tu as envie d'apprendre un langage qui est maintenant inutile, apprend celui-la. A part si tu veux craquer des programmes, aujourd'hui, ca sert plus a grand chose d'apprendre l'assembleur.

 
Bonjour,

Bon, je suis d'accord a 99,99% avec toi Superced. Comme toi, je préfère developper en C. Comme il est très simple (simpliste dirait certains, non sans raison) on le maîtrise assez vite.

Par contre, je pense qu'il est impératif d'avoir des bases d'assembleur. Tous les langages compilés, genèrent de l'assembleur, et aucun langage n'est exempt d'erreur de compilation surtout lors de l'optimisation (Codewarrior par exemple...).
Il est donc parfois nécessaire de se dire, bon, "qu'a compris le compilateur de ce que j'ai écrit ?", et là il faut savoir lire l'assembleur.

Cordialement
 
Le C n'est franchement pas un langage simple. C'est plutôt un langage de "bas niveau", ce qui le rend très difficile à maîtrisé pour un non-informaticien. Mon plus grand reproche aussi, c'est que ce langage n'est pas du tout assez strict. Il laisse le programmeur beaucoup trop libre (avec les types notamment), ce qui bien sûr peut être un avantage pour des programmeurs avancés, mais qui ne l'est absolument pas pour un amateur.

Je pense donc qu'il est bien mieux de commencer la programmation avec un langage fortement typé et avec une syntaxe assez stricte. Et de ce point de vue là, le C est tout à l'opposé !
 
Je partage l'avis de Molgow. Je ne programme plus beaucoup, ou alors en dilettante, donc je ne suis peut-être pas le mieux placé pour parler. Mais j'enseigne un peu d'algorithmique-programmation, simple, au CNAM et j'ai l'impression, qu'à ce niveau, C ralentit plutôt les choses.

Je préférais, surtout pur débuter : pascal (c'est vrai qu'aujourd'hui, c'est un peu difficile à faire joujou avec sur mac) ou Ocaml, pour faire dans l'exotisme, ou java (malgré la syntaxe C qui conviendra au contraire mieux à certains), ou Ada. Je fais un blocage sur C : les raccourcis vite incompréhensibles, les pointeurs dans tous les coins et pas toujours pour de bonnes raisons.

Je comprends très bien qu'un programmeur à 100% en tire satisfaction mais pour le programmeur intermittent, c'est moins évident et pour la formation, c'est galère : il faut beaucoup plus de temps pour donner le bagage minimum pour être capable d'écrire ou de lire un programme élémentaire.

Passer par l'intermédiaire d'un langage plus "propre" au départ me semble une option raisonnable, même si après on passe au C pour des raisons pratiques. Le langage n'est pas l'essentiel mais ça peut être plus facile de commencer par l'italien que par le japonais pour un individu lambda. Et le fait d'avoir vu des langages différents ne peut pas, à mon avis, être un défaut.

 
Bonjour,

C'est vrai, le C peut devenir rapidement illisible.
Mais c'est également vrai pour tous les langages.
N'oubliant pas qu'un programme c'est des commentaires avec du code dedans...
J'ai vu des sources en assembleur merveilleusement clair, et des sources de langage orientés objet completement incompréhensibles...

Cordialement
 
</font><blockquote><font class="small">Citer:</font><hr />
- Les clones d'HyperCard : super intuitif, vraiment sympa pour decouvrir la programmation, mais c'est limite. Il y en a plusieurs je crois. Un pile de ce type necessite un player. Les players existent sur beaucoup de plateformes differentes.
<hr /></blockquote>

Hello

Revolution est un clone d'HyperCard, mais il sait créer des application independante. (comme HyperCard).

Donc pas besoin de player.
Et il tourne sur mac (9/X), PC, unix, linux, ...

Perso je le trouve nikel.
 
<blockquote><font class="small">Post&eacute; &agrave; l'origine par Didier Guillion:</font><hr /> Bonjour,

C'est vrai, le C peut devenir rapidement illisible.
Mais c'est également vrai pour tous les langages.
<hr /></blockquote>

C'est vrai qu'on peut toujours écrire un programme illisible quel que soit le langage (ça peut même donner des exercices intéressants : dites-moi ce que fait ce truc ?
laugh.gif
)

Avec C, le problème est :

1) que tu es tout de suite confronté à des écritures pas tout à fait évidentes pour un petit nouveau (c'est un peu mieux souvent avec C++). Quelques exemples :

- le passage de paramètres (adresse/valeur). Le mot-clef VAR du Pascal est bien plus pédagogique.
- les écritures formatées, commencer sans format du tout, ça serait quand même plus simple (C et Fortran, même combat
laugh.gif
)

Même si au final, ça ne change pas grand chose, le démarrage est retardé et sans qu'on y gagne, à mon avis, quoi que ce soit du point de vue de l'apprentissage.

2) Que les programmes trouvés dans la nature utilisent assez systématiquement (il y a d'heureuses exceptions dans les bouquins d'algorithmique comme ceux de Sedgewick par exemple) de nombreuses "astuces" du C parfaitement claires pour un habitué mais souvent inabordables pour un débutant, ce qui était beaucoup plus rare en Pascal (ou le serait même en Ada).

C'est assez rébarbatif pour les élèves.
 
<blockquote><font class="small">Post&eacute; &agrave; l'origine par Krynn:</font><hr />Revolution est un clone d'HyperCard, mais il sait créer des application independante. (comme HyperCard).

Donc pas besoin de player.
Et il tourne sur mac (9/X), PC, unix, linux, ...

Perso je le trouve nikel.
<hr /></blockquote>


Oui, j'ai regardé un peu et il m'intéresse mais :
1) il coût combien aujourd'hui ?
2) Quelle pérennité espérer ?
 
1) il coût combien aujourd'hui ?

- gratuit pour 10 lignes de script par objet
(facilement contournable en faisant des appelle a d'autre objet)
tu peux le downloader gratuitement sur http://www.runrev.com pour te faire une idée
- des 99$ pour etudiants
- apres les prix varient de 299$ à beaucoup (pour une entreprise avec multilicences)
- Plus de detail sur Store Runrev

La version gratuite est deja largement utilisable.


2) Quelle pérennité espérer ?

- comme tous les langagues qui ne sont pas supporter par des mastodonte. (c'est variable). A part le Java et le C++, je ne sais pas si il y a bcp de programme qui ont un avenir assuré.


Mais que souhates-tu faire comme prog? Ca peux aussi bcp aider pour le programme, le plus adapté.
 
<blockquote><font class="small">Post&eacute; &agrave; l'origine par Krynn:</font><hr /> 1) il coût combien aujourd'hui ?

- gratuit pour 10 lignes de script par objet
(facilement contournable en faisant des appelle a d'autre objet)
- apres les prix varient de 299$ à beaucoup (pour une entreprise avec multilicences)
La version gratuite est deja largement utilisable.

<hr /></blockquote>

Oui, donc apparemment les prix n'ont pas changé depuis la dernière fois que j'ai regardé.

- 10 lignes par script, pour moi, c'est vraiment inutilisable : j'utilise hypercard intensivement depuis ses origines et la limite de script à 32 ko me gênait déjà souvent même si les "stacks in use" me permettaient de m'en sortir souvent assez proprement (pour ce que je fais, je ne dis pas que c'est pareil pour tout le monde). Les bricolages d'un objet à un autre, je connais : un peu ça va, beaucoup, c'est ingérable
J'aurais préféré avoir une vraie version de démo utilisable un mois, je pourrais tester réellement.

- 300 $ soit 400 euros : je ne suis pas encore prêt à payer ça pour faire des freewares, compte tenu de la pérennité hypothétique du produit. J'ai déjà vu passer pas mal de clones intéressants en shareware ou pas et à part metacard aux prix stratosphériques (le moteur de révolution) et supercard qui semble resortir le nez du bois après une histoire plutôt cahotique, je ne vois pas grand-monde.

Entendons-nous bien, je pense que le produit a de réelles qualités (l'engagement de Rinaldi en est la meilleure preuve) et à 150 euros pour une version complète, je signe demain même sans réelle démo mais là, on reste pour les happy few, le contraire de ce qu'était hypercard, même quand il est devenu payant.

Alors, j'attends toujours : un révolution ou un supercard ou un autre correct à prix correct pour moi (ou un hypercard 3, bien improbable)

Pourtant, entre l'éducation, le traitement de mesures, etc. je pense qu'il y a une niche intéressante pour Apple.

Ce que je programmerai, pour le plaisir, ce serait :
- des programmes liés à la conception d'installations solaires
- des programmes sur les unités de mesure
- à titre privé, des outils de traitement de mesures (au boulot, je bricole beaucoup ça avec hypercard)
-
 
SuperCed a dit:
Java EST un langage interprete, il necessite un runtime appele "Machine virtuelle java".

Je coupe la poire en deux : Java est un langage intermédiaire entre le compilable et l'interprêté : tu écris ton code, tu le compiles et tu obtiens du pseudo-code, qui sera interprété par la machine virtuelle de ta plate-forme. Voilà, on se dispute plus, maintenant
smile.gif


Quand à savoir quel est le meilleur langage ? C'est un peu vain comme débat. chaque langage a ses points forts et ses faiblesses. Par exemple le Java est élégant, idéal pour l'apprentissage, mais tu feras pas le quart de ce que tu peux faire en C/C++, et de toute façon, là n'est pas son but.

Cependant, on ne peut pas contester que le couple C/C++ est le langage le plus universel. Il est supporté par toute les plate-formes et utilisable à tout les niveaux de programmation (de l'assembleur à la base de donnée). Mais faut se le cogner quand-même, surtout en objet où le C++ est quand-même lourdingue (pourra-t-on un jour oublier les fichiers d'en-tête ? pourra-t-on un jour faire des affectations dynamique d'objet sans "cast" ?) Pas le meilleur pour apprendre, bien qu'il soit indispensable à un pro.

En revanche, je supporte pas le Basic. Idéal pour apprendre ? Idéal pour apprendre les mauvaises manières de programmation, oui !
 
En ce qui concerne le Java, meme s'il est ecrit "compiler" dans les environnements de developpement, il ne s'agit pas d'une compilation au sens mathematique du terme, il s'agit d'une precompilation et d'une transformation.

La compilation consste a transformer un code en langage machine. Pour Java, ce n'est pas vrai.

De plus, on considere un langage comme "interprete" des qu'il fait appel a un runtime pour executer son code.

Enfin, si tu n'es pas d'accord, tu peux chercher quelque part dans l'ISO ou l'IEE pour verifier.
 
Sûr que le débat compilateur/interpréteur n'est pas simple
laugh.gif
.

De mon point de vue, java ou plus précisément les mises en oeuvre classiques de java * utilisent (comme le faisait déjà Pascal UCSD sur apple II et ailleurs) le principe d'un compilateur pour une machine virtuelle (on traduit bien en langage machine) mais comme la machine est virtuelle, il faut ensuite :
- soit un interpréteur émulant la machine virtuelle
- soit un processeur doté des instructions de la machine java (vaporware ?
laugh.gif
).

* on peut avoir un compilo dédié à une machine mais ça complique l'évolution de java. et sa logique

On peut même trouver plus vicieux comme mise en oeuvre, genre OCaml avec son compilateur interactif : ça a tout d'un interpréteur type vieux basic : tu tapes une ligne, il traduit mais c'est de la compilation et pas de l'interprétation (ce sont les concepteurs et metteurs en oeuvre de Caml qui le disent
zen.gif
et ils tatouillent quand même un peu en informatique théorique
laugh.gif
)

Maintenant, la définition des mots est une chose, le ressenti en pratique en est une autre. Et là, ben, quand c'est lent, on dit que c'est interprété (c'est plus simple comme ça, non
laugh.gif
).
 
<blockquote><font class="small">Post&eacute; &agrave; l'origine par lupus yonderboy:</font><hr />

En revanche, je supporte pas le Basic. Idéal pour apprendre ? Idéal pour apprendre les mauvaises manières de programmation, oui !
<hr /></blockquote>

Absolument. En fait, l'intérêt des Basic (qui ne sont pas un ni même des langages aujourd'hui mais plutôt des environnements de développement), c'est de faciliter l'accés aux API des systèmes.

Or, à mon avis, c'est pas par ça qu'il faut commencer pour apprendre à programmer
laugh.gif

 
<blockquote><font class="small">Post&eacute; &agrave; l'origine par Luc G:</font><hr /> Sûr que le débat compilateur/interpréteur n'est pas simple
laugh.gif
.

De mon point de vue, java ou plus précisément les mises en oeuvre classiques de java * utilisent (comme le faisait déjà Pascal UCSD sur apple II et ailleurs) le principe d'un compilateur pour une machine virtuelle (on traduit bien en langage machine)
<hr /></blockquote>

Non non non, le lava est traduit en fichier binaire, incomprehensible par le processeur, donc ce n'est pas du langage machine.

<blockquote><font class="small">Post&eacute; &agrave; l'origine par Luc G:</font><hr />
mais comme la machine est virtuelle, il faut ensuite :
- soit un interpréteur émulant la machine virtuelle
- soit un processeur doté des instructions de la machine java (vaporware ?
laugh.gif
).

<hr /></blockquote>

Cette machine existe bel et bien chez Sun Microsystem. C'est une machine qui n'a pas besoin de machine virtuelle pour fonctionner. Mais bon, dans ce cas la, c'est l'electronique qui est ada^pte au langage et non l'inverse, c'est encore un autre probleme.

<blockquote><font class="small">Post&eacute; &agrave; l'origine par Luc G:</font><hr />

Maintenant, la définition des mots est une chose, le ressenti en pratique en est une autre. Et là, ben, quand c'est lent, on dit que c'est interprété (c'est plus simple comme ça, non
laugh.gif
).

<hr /></blockquote>

Desole, ca ne marche pas ton truc. RealBasic est lent et pourtant, ca compile...

Un truc beaucoup plus simple pour savoir si c'est compile ou non :
On fait tourner le meme programme sur un pece et sur un Mac. Si ca fonctionne (a peu pres) de la meme maniere, alors, c'est interprete, sinon c'est compile.

Java a de moins en moins d'interet car les standard imposes par Sun sont de moins en moins respectes. Les machines virtuelles sont parfois tres differentes d'un OS a l'autre.

Bref, Java, ca ne tient pas ses promesses, et en plus, c'est lent.

 
La phrase sur lent = interpréteur, c'était de l'humour, pas grand chose d'autre : les gens ont tendance à associer lenteur et interprétation, ce qui est assez logique dans l'esprit "ancien" des interpréteurs :

1) la même instruction rencontrée x fois est traduite x fois, ce qui ralentit effectivement les choes.
2) l'interprétation se faisant pendant l'utilisation, le temps d'interprétation est perceptible par l'utilisateur (pour la compilation, c'est pour le développeur que c'est perceptible.
laugh.gif


Même dans l'état actuel de l'art (où les choses sont plus complexes : mix compil/interprétation, je n'ai pas la même conception d'un compilateur que toi, mais ça fait bien 20 ans que je vois des débats là-dessus
laugh.gif


Par exemple ici .

Perso, je suis dans la ligne de ce que dit Eric Marsden. Et il rappelle que le choix compilo/interprété ne relève pas du langage (j'ai vu du fortran interprété) même si la logique d'un langage peut faciliter une voie ou l'autre.

Enfin, compte tenu de la complexité des processeurs modernes, même à ce niveau, il y a fréquemment des phases d'interprétation (émulation des instructions d'anciens processeurs, optimisation, etc.)

Le binaire produit par le compilateur java n'est pas compréhensible par le processeur hôte, mais c'est aussi le cas pour du bon gros code X86 sur un PowerPC : virtualPC remplit dans ce cas le rôle que joue la machine java dans l'autre (entre autres choses évidemment). C'est pas pour ça que le compilateur Microsoft visual C devient un interpréteur
laugh.gif
.

Mais c'est vrai que, sauf en conception de langages et d'outils de devpt, ce sont des conversations de chez le coiffeur
laugh.gif
 
<blockquote><font class="small">Post&eacute; &agrave; l'origine par Luc G:</font><hr />
Le binaire produit par le compilateur java n'est pas compréhensible par le processeur hôte, mais c'est aussi le cas pour du bon gros code X86 sur un PowerPC : virtualPC remplit dans ce cas le rôle que joue la machine java dans l'autre (entre autres choses évidemment). C'est pas pour ça que le compilateur Microsoft visual C devient un interpréteur
laugh.gif
.

<hr /></blockquote>

Attention, tu commets ici une erreur de logique; "Un code interprete n'est pas lisible par tous les processeurs" n'implique pas "qu'un code compile est lisible sur tous les processeurs"!
Il s'agit ici d'une implication et non d'une equivalence. La reciproque est fausse.
Ton raisonnement est faux.

Par contre, je suis un peu d'accord avec toi sur le fait que la compilation ou interpretation ne tient pas du langage. En effet, il existe de vrais compilateurs Java. Mais dans ce topic, je parlais du Java que l'on rencontre dans 99 pour cent des cas.