Discussion :

[Garulfo]

http://en.wikipedia.org/wiki/Anders_Hejlsberg

-> Delphi -> Object Pascal -> Borland -> 1990

On ne peut pas dire qu'il n'y ait aucun lien ... http://fr.wikipedia.org/wiki/Anders_Hejlsberg
Après je n'aurais certainement pas tourné la phrase ainsi -- on pourrait croire que C# était là avant...

Luc a raison la phrase est mal tournée, bien que je pensais que cela été de notoriété public, sinon c'est dans le livre mastering delphi que j'ai pêché cela.

Les liens Wiki il faut s'en méfier
http://en.wikipedia.org/wiki/Delphi_...mming_language)
fait le lien avec Niklaus Wirth plus qu'avec Hejlsberg.
Mais c'est vrai que je confondais avec Object Pascal (qui vient de Apple Computer).

Merci pour la correction donc

[Garulfo]

Oh si ça existe, à commencer par VB !

Mais oui. Et la marmotte…
Petit troll va

[Keihilin]

Finalement, j'aimerais voir un langage qui ne nécessite pas de comprendre ce que l'on fait Ça serait génial… mais ça n'existe pas.

Non mais sérieusement, ça dépend du sens que l'on donne à "savoir ce que l'on fait".

Plus un langage est de haut niveau, plus il te mâche le travail et te cache le fonctionnement de la machine, moins tu as besoin de savoir ce que tu fais.

Un exemple pourrait être un langage à GC; disons C# puisque c'est mon pain quotidien.
Liberé du problème parfois épineux de la gestion de la mémoire, le développeur n'a souvent pas la moindre idée de ce qui se passe vraiment sous le capot, et dans l'absolu, il n'a pas besoin de le savoir...

...jusqu'au jour où, à force de design cradingue, son application va atteindre les limites du GC et se mettre à bouffer toute la RAM. Là il devra peut être essayer de comprendre ce qui se passe.
Encore que pour certain, la réaction face à cette situation consiste à maudir .Net et sa gourmandise en mémoire et à acheter une ou deux barettes supplémentaires.

[souviron34]

J'ai surtout remarqué un mouvement pour appeler script des choses que j'appellerais programme. J'ai même vu des gens parler de scripts C... et ils ne pensaient pas à l'utilisation d'un interpréteur C.

juste pour terminer sur les scripts, quelque chose qui m'est venu en prenant mon café ce matin () :

les scripts dépendent des OS à cause des commandes, et le changer d'OS implique de tout réécrire, contrairement à un langage de programmation où il suffit d'avoir le bon compilo... Un .bat ne tournera jamais sous un unixoide, un .sh jamais sous DOS. Et si jamais on avait un "compilateur" qui transforme le format d'un .sh en .bat, les commandes seraient incomprises..

De même, un fichier PostScript aura beaucoup de mal (et c'est un euphémisme) à être compris par une imprimante HPIB.

De même, tcl/tk (c'était le cas, je ne sais pas si ça l'est toujours) est (était ?) basé sur X11/Motif.. Dur dur de faire tourner ça sous Windows (quelle que soit la version)...

C'est ce qui m'apparaît (ce matin) comme la différence la plus frappante... Transférer d'un OS à un autre nécessiterait la ré-écriture de tout le "code" contenu..

...jusqu'au jour où, à force de design cradingue, son application va atteindre les limites du GC et se mettre à bouffer toute la RAM. Là il devra peut être essayer de comprendre ce qui se passe.
Encore que pour certain, la réaction fasse à cette situation consiste à maudir .Net et sa gourmandise en mémoire et à acheter une ou deux barettes supplémentaires.

et c'est malheureusement le cas général

[Matthieu Brucher]

les scripts dépendent des OS à cause des commandes, et le changer d'OS implique de tout réécrire, contrairement à un langage de programmation où il suffit d'avoir le bon compilo... Un .bat ne tournera jamais sous un unixoide, un .sh jamais sous DOS. Et si jamais on avait un "compilateur" qui transforme le format d'un .sh en .bat, les commandes seraient incomprises..

Pourtant, on arrive à exécuter les .sh sous Windows, avec MSYS ou Cygwin.
C'est comme Python. Si tu veux l'exécuter sur une plateforme non supportée, tu es mal. Tu as la solution de traduire dans un autre langage, ou tu programmes ton interpréteur.
Et par rapport aux commandes, de nombreux programmes font des appels "shell" ou système, et donc sont bien tributaires de la plateforme sur laquelle ils sont exécutés. Pour autant, ils sont bien écrits dans un "langage de programmation".

[souviron34]

Pourtant, on arrive à exécuter les .sh sous Windows, avec MSYS ou Cygwin.

Désolé, mais cygwin est un émulateur (mini) d'un OS...

arriver à exécuter un .sh sur Windows, bon courage ... Déjà que les devices sont des fichiers sous unixoides, faire un "mount" ou un "ls" sous Windows .. Je te mets au défi...

Et par rapport aux commandes, de nombreux programmes font des appels "shell" ou système, et donc sont bien tributaires de la plateforme sur laquelle ils sont exécutés. Pour autant, ils sont bien écrits dans un "langage de programmation".

Ceux qui utilisent la fonction system() oui.. (et encore, un programme "portable" ira lire la chaîne ou l'utilitaire à appeler dans un fichier de ressources, pour ne pas avoir à changer le code).

Mais l'écrasante majorité du code des programmes ne le font pas...

Et heureusement, sinon à quoi servirait-il d'avoir des langages de programmation ???

Ils ont justement été inventés pour faire une chose, et ne plus se préoccuper (à part trouver le bon compilateur) d'avoir à les ré-écrire..

[Luc Hermitte]

Un .bat ne tournera jamais sous un unixoide, un .sh jamais sous DOS. Et si jamais on avait un "compilateur" qui transforme le format d'un .sh en .bat, les commandes seraient incomprises..

Et un .py ne tournera jamais sous perl, (et vice-versa), de même qu'un programme vb.net ne passera jamais sous *nix.

Déjà que les devices sont des fichiers sous unixoides, faire un "mount" ou un "ls" sous Windows .. Je te mets au défi...

mount, je n'ai jamais essayé (faute d'y avoir pensé, mais je vais m'en occuper sérieusement dans les jours à venir). En revanche, régulièrement je fais des ls sous le $COMSPEC courant, et cela passe très bien ... vu que ls.exe est dans mon $PATH.

[Jean-Marc.Bourguet]

les scripts dépendent des OS à cause des
commandes, et le changer d'OS implique de tout réécrire,
contrairement à un langage de programmation où il suffit d'avoir le
bon compilo...

Et les bonnes libs... si je fais un appel a clone(2), j'aurais du mal a
utiliser le programme sur autre chose qu'un Linux. Les programmes
soi-disant en C qui sont ecrits par les eleves d'une certaine ecole auront
beaucoup de mal a tourner sur qqch qui ne propose pas une couche posix.
D'autres debutants nous sortent du "conio.h" a tout va qui limite tout
autant -- ou meme plus -- le choix de la cible.

Je n'ai pas reellement l'impression qu'il y a une difference de nature
entre les deux dependances, juste une difference d'intensite. Et ce n'est
pas suffisant a mon avis pour refuser la qualification de "programme" ou de
"langage de programmation".

[souviron34]

mount, je n'ai jamais essayé (faute d'y avoir pensé, mais je vais m'en occuper sérieusement dans les jours à venir). En revanche, régulièrement je fais des ls sous le $COMSPEC courant, et cela passe très bien ... vu que ls.exe est dans mon $PATH.

et top ? et ps ? et chmod ? et chown ? et pid ? et sed ? et awk ? et '&' , et "> /dev/NULL" ? et " > toto.err 2>&1" ?

C'est une évidence...



@Jean-Marc : je ne parle pas des débutants ni d'une certaine école. Je parlais de manière générale, face à des Principes.

Encore une fois, à mon avis, il y a une différence de fond..

Mais c'est que je suis un vieux croûton..

[Keihilin]

de même qu'un programme vb.net ne passera jamais sous *nix.

Ben si, à la condition qu'une machine virtuelle soit disponible.

[Jean-Marc.Bourguet]

Encore une fois, à mon avis, il y a une différence de fond.

C'est quoi la difference de fond entre un script en sh qui depend de mount(8) et un programme en C qui depend de mount(2)?

[Luc Hermitte]

et top ? et ps ? et chmod ? et chown ? et pid ? et sed ? et awk ? et '&' , et "> /dev/NULL" ? et " > toto.err 2>&1" ?

ps, chmod, chown sed et awk sont des exécutables, tout va bien.
Les syntaxes de pipes sont propres aux interpréteurs de commandes utilisés. Et nous sommes exactement dans la même situation que celle des scripts perl qui ne sont pas interprétables sans l'interpréteur perl.

Mais c'est que je suis un vieux croûton..

Non, tout dépend de comment on s'en sert.
Tant qu'il s'agit d'agencer des commandes pour écrire des nouveaux filtres, c'est sûr qu'il ne s'agit pas de programmation de haut vol.
Quand on commence à avoir des fonctions, à donner une structuration forte au script, il est difficile de dire que l'on ne programme pas. C'est globalement la conclusion du débat sur lambda-the-ultimate dont j'avais donné le lien.

Ben si, à la condition qu'une machine virtuelle soit disponible.

Oui, exactement!
NB: je répondais à souviron qui avait écarté les scripts shell qui tournent sous cygwin parce qu'on utilise un émulateur (ce qui n'est guère différent d'une machine virtuelle dans notre cas). Hors VB.NET a son langage de programmation, et il est fortement non portable.
La portabilité n'est pas un critère qui décide langage de programmation ou pas langage de programmation.

[souviron34]

Et nous sommes exactement dans la même situation que celle des scripts perl qui ne sont pas interprétables sans l'interpréteur perl.

C'est exactement ce que je dis...

Non, tout dépend de comment on s'en sert.
Tant qu'il s'agit d'agencer des commandes pour écrire des nouveaux filtres, c'est sûr qu'il ne s'agit pas de programmation de haut vol.
Quand on commence à avoir des fonctions, à donner une structuration forte au script, il est difficile de dire que l'on ne programme pas. C'est globalement la conclusion du débat sur lambda-the-ultimate dont j'avais donné le lien.

Admettons.. Mais à mon avis il y a quand même une différence..

(au moins, à mon avis, elle vaut la peine d'être enseignée et connue, pour ne pas tomber dans les excès cités plus hauts)...

NB: je répondais à souviron qui avait écarté les scripts shell qui tournent sous cygwin parce qu'on utilise un émulateur (ce qui n'est guère différent d'une machine virtuelle dans notre cas). Hors VB.NET a son langage de programmation, et il est fortement non portable.
La portabilité n'est pas un critère qui décide langage de programmation ou pas langage de programmation.

je ne me battrais plus là-dessus, mais voir plus haut...

(comme l'a dit Jean-Marc, le nombre de débutants parlant de "scripts" à la place de "programmes" (c'est foison en début d"'année scolaire sur le forum C) justifie en soi d'établir les distinctions au départ.. C'est tout ce que je dit.. Qu'après des gens expérimentés trouvent des équivalences théoriques, pas de problèmes. Mais je pense que c'est induire les jeunes en erreur que d'assimiler les 2 notions, et cela amène soit à des enormités (faire des scipts pour faire du calcul par exemple), des incompréhensions d'usages (entre bibliothèques et binaires), des problèmes de maintenance futures (faire reposer le produit d'une boîte sur un script, qui justement à cause de sa non-portabilité va entraîner des problèmes gigantesques de réécriture plus tard), etc etc..).

[chaplin]

Une précision pour les origines de Delphi.

Le 2 mai 1983, il[Phillipe Kahn] fonde Borland International. ... Quelques mois plus tard ... , le Turbo Pascal ..., il met au point un nouveau langage de programmation ... Pressé de s'imposer sur un marché déjà très encombré, le Français tente un coup de poker. Au lieu de proposer son logiciel à 600 dollars, comme tout le monde, il casse le marché en le vendant par correspondance à 49,95 dollars
Et ça marche ! «Quand j'ai tout plaqué pour rejoindre Borland, mes copains m'ont dit : "Tu es fou. Tu ne réussiras qu'à placer 300 logiciels !", se souvient un des pionniers. En fait, la première année on en a vendu 20 000 !» Après ce coup de force, le Français passera longtemps pour un «barbare» auprès des concurrents. Qu'importe ! Les programmeurs, eux, trouvent ses produits pas chers et performants. Lui-même accumule les bénéfices et ne tarde pas à s'acheter le jouet de ses rêves, une Porsche blanche, immatriculée «Turbo-Pascal». En fait, ce logiciel fut d'abord développé par un Danois, Anders Heilsberg, présenté à Philippe Kahn par trois autres Scandinaves, Niels Jensen, Ole Rasmussen et Mogens Glad, propriétaires d'une petite société d'informatique installée en Irlande et baptisée Borland !

J'ai vu une vidéo de 1994 où il présente le monde des objets, c'est franchement amusant .

[Jean-Marc.Bourguet]

Et nous sommes exactement dans la même situation que celle des scripts perl
qui ne sont pas interprétables sans l'interpréteur perl.

C'est exactement ce que je dis...

Attend... Tu dis que des scripts perl ne sont pas des programmes?

Où est-ce que tu places la limite?

Non, tout dépend de comment on s'en sert.

Tant qu'il s'agit d'agencer des commandes pour écrire des nouveaux filtres,
c'est sûr qu'il ne s'agit pas de programmation de haut vol. Quand on
commence à avoir des fonctions, à donner une structuration forte au script,
il est difficile de dire que l'on ne programme pas. C'est globalement la
conclusion du débat sur lambda-the-ultimate dont j'avais donné le lien.

Admettons.. Mais à mon avis il y a quand même une différence..

(au moins, à mon avis, elle vaut la peine d'être enseignée et connue, pour
ne pas tomber dans les excès cités plus hauts)...

La difference entre quoi et quoi?

Un langage qui permet simplement d'enchainer des commandes sans faire de
choix, de boucles ou de routines n'est pas un langage de programmation. Un
langage qui permet de faire des choix, des boucles et des routines en est
un. Entre les deux, je comprends qu'il y ait une zone de flou.

(comme l'a dit Jean-Marc, le nombre de débutants parlant de "scripts" à la
place de "programmes" (c'est foison en début d"'année scolaire sur le forum
C) justifie en soi d'établir les distinctions au départ.

J'ai surtout constate un glissement de sens qui s'accentue et qui a
commence pour moi avec l'utilisation de "script" par perl qui n'a pas de
mode interactif. Une fois ce pas fait, la suite etait quasiment
inevitable.

C'est tout ce que je dit.. Qu'après des gens expérimentés trouvent
des équivalences théoriques, pas de problèmes.

Tu aimes bien ecarter les arguments en les qualifiant de theorique. Je
suis tres pratique quand je ne vois pas de difference fondamentale entre
l'activite d'ecrire un script pour sh qui parse une ligne de commande et 3
fichiers pour lancer des commandes et analyser leur resultat et ecrire
en programme en C qui fait la meme chose. Mon activite est principalement
la meme; c'est simplement plus facile dans le premier cas car j'ai les
primitives adequates et pas dans le second.

Mais je pense que c'est induire les jeunes en erreur que d'assimiler
les 2 notions, et cela amène soit à des enormités (faire des scipts pour
faire du calcul par exemple),

J'ai deja fait des stats avec awk et je ne vois pas en quoi c'est une
enormite. J'avais les resultats que je n'aurais pas fini d'ecrire le
programme en C.

des incompréhensions d'usages (entre bibliothèques et
binaires),

Je ne vois pas le rapport.

[doc]

Java

- Pourquoi ce choix

Après une ancienne expérience de la programmation avec l'assembleur et le basic, j'ai découvert la programmation objet avec java.

- Les plus/avantages

La communauté et les ressources sur internet sont très nombreuses.
La javadoc qui fait partie intégrante du langage est incroyablement bien pensée, et très pratique, beaucoup plus que celle de C# par exemple.
La multitude de librairies open source.
Ses EDI open source.

- Les moins/inconvénients

Par rapport aux langages 'concurrents' et pour l'utilisation qui est la mienne : je n'en voie pas.

- Quels projets réalisez-vous avec et pourquoi

Des applets au départ, puis principelement des applications avec base de données et des utilitaires.

- Vers quels autres langages pensez-vous évoluer dans le futur

Python ? ou un langage fonctionnel ?

- Comment vous êtes-vous formé, ou avez-vous été formé sur ce langage

autodidacte avec au départ le livre 'java2' de la collection 'Les nouveaux poches micro', qui m'avait semblé très théorique, j'ai alors complété avec les 2 'au coeur de Java2' beaucoup plus détaillés. Sans oublier par la suite les tutoriels dvp et toutes les ressources du net.

- Est-ce une utilisation amateur ou professionnelle

utilisation amateur, mais dans le cadre de ma profession qui n'est pas l'informatique.

- Quels outils vous utilisez (Editeur, EDI, etc.)

J'ai commencé avec JBuilder qui était un excellent IDE accessible dans sa version personnelle. Puis j'ai dérivé vers Eclipse qui l'a peu à peu supplanté, et de temps en temps netbeans

- Autres langages utilisés, pourquoi ? dans quel cadre ? et comparaisons ?

Delphi qui m'a permit de programmer rapidement des IHM, mais je le trouve beaucoup moins agréable à utiliser (à cause des types de données, de sa documentation, de sa syntaxe...)

C# dont la prise en main est très rapide quand on vient du java, mais qui ne m'apporte rien de plus (pour l'utilisation que j'en ait du moins).

C que suis en train d'apprendre pour ma culture personnelle, mais dont je ne voie pas l'utilisation que j'en aurai. (peut être pour utiliser la jni si le besoin s'en fait sentir).

- Sur quels systèmes ou plateformes vous travaillez (Windows, DotNET, Linux, etc.)

Window, Linux

- Conclusion

En choississant java pour répondre à la question de ce fil, je ne veux pas signifier que c'est le meilleur de tous les langages, mais c'est en tous cas celui que je préfère. On peut aussi considérer que Java a ouvert une ère de programmation, avec son GC et sa jvm.

[el muchacho]

Sérieux, on pourrait pas virer Fortran du sondage et mettre D à la place ?
Je vois pas qui peut mettre Fortran comme langage préféré en 2009 à moins d'être sérieusement masochiste ou dérangé.

Pour ma part, si j'avais le choix, je programmerais en D pour un langage compilé en natif (impératif, objet, statiquement typé, linkable avec C, templates façon C++ avec une syntaxe plus simple, garbage collecté, performant) et en Scala pour un langage basé sur une machine virtuelle (fonctionnel, objet, statiquement typé, totalement compatible avec Java).

[Matthieu Brucher]

Sérieux, on pourrait pas virer Fortran du sondage et mettre D à la place ?
Je vois pas qui peut mettre Fortran comme langage préféré en 2009 à moins d'être sérieusement masochiste ou dérangé.

Je connais plusieurs développeurs qui ont, je pense, Fortran comme langage préféré dans le HPC.

[el muchacho]

Je connais plusieurs développeurs qui ont, je pense, Fortran comme langage préféré dans le HPC.

M'ouai, se taper du code spaghetti comme dans les années 70 pour gratter 5% de perfs par rapport au même code C sur des machines obsolètes l'année suivante, j'ai pas bien compris l'intérêt.

Le Fortran 77 est quand même un langage qui n'a aucune autre structure de données que les tableaux statiques, et pas d'allocation dynamique. Autrement dit, toutes les données sont rangées soit dans tableaux statiques, soit dans des variables globales (sur 7 caractères maxi) ou bien sur la pile. Et c'est tout. C'était concevable quand les plus grosses machines avaient 32 Ko de mémoire centrale, mais imaginer qu'on puisse au 21e siècle écrire des milliers de lignes de code avec ça, c'est vraiment une curiosité de l'Histoire.

Pour l'anecdote, j'ai eu une fois à traduire 3000 de lignes de Fortran en C++. Quand j'en ai eu fini avec ça (en comparant les sorties des deux programmes sur une suite de tests), entre les GOTO dans tous les sens et les noms de variables cryptiques, je ne savais tjrs pas ce que faisait le code Fortran ! Quand je pense qu'il y a encore aujourd'hui des étudiants qui sont (dé)formés au F77 comme premier langage, je me dis que le code spaghetti "write only" a encore de beaux jours devant lui.

Après on me dira que le langage a évolué avec F90, HPF et cie. Je ne sais pas dans quelle mesure ces évolutions sont utilisées et si elles ont gardé les performances du langage d'origine.

[Matthieu Brucher]

M'oui, se taper du code spaghetti et des noms de variables sur 6 caractères comme dans les années 70 pour gratter 5% de perfs par rapport au même code C sur des machines obsolètes l'année suivante, j'ai pas bien compris l'intérêt.

On ne parle pas de 5%, mais plutôt de 100%...
Ensuite, le Fortran 95 et le 2003 sont là pour ôter ces dernières limitations (mais je ne dis pas non plus que j'aime programmer dans ce langage, je dis juste que pour certains, c'est leur langage préféré).