Discussion :

[Logan Mauzaize]

Quii existaient en Fortran IV

Oui c'est bien ce qu'on dit un langage "bas niveau".

Et c'est bien là que je vois le problème.. Cette classification a été effectuée par les défenseurs du OO comme étant le nec-plus-ultra de la programmation...

Encore une fois je ne vois pas en quoi le fait d'être un langage objet ou non augmente l'abstraction...

C'est la conception qui doit être objet...

Je sais (je vois) qu'il est bien difficile pour des gens élevés dans cette pensée ("OO is god") de s'en extraire, mais c'est bien la base de cette classification..

OO is not god SQL et Prolog en sont de bons exemples.

Mais qui se prend la tête avec ça à part les débutants ????

Les gens qui font des pointeurs de pointeurs de pointeurs de ... ^^ Ceci dit je fais pas de C/C++ donc j'en sais trop rien. Pour moi le plus compliqué c'est surtout la gestion du cycle de vie. De ce que j'ai pu sentir en discutant avec des développeurs C/C++, ils utilisent énormément d'objet jetable et le constructeur par recopie.

Merci, mais c'est tout simplement faux. Il faudra revoir tes cours..

Java a été développé au départ par SUN comme langage graphique portable, pour faire le pont entre M$ et les autres constructeurs.

La plupart des autres constructeurs (DEC, IBM, Sun, SGI, etc) avaient un standard graphique commun : X11.

En 1994 M$ a sorti des PC pour lesquels le boitier était soudé (ne permettant donc pas de regarder les cartes). Linus Torwald a réussi à "bypasser" ça et a sorti Linux (qui par définition pouvait être X11-compatible). Mais les fabricants officiels ne pouvaient pas indiquer qu'ils avaient "bypassés" les soudures. Sun a alors dévelopé quelque chose qui pouvait ET marcher sur les PC avec l'API Win32 ET marcher sur les autres ordi avec l'API X11 ...

En 1994, c'était pas plutôt des PCs HP/Compaq ? Et il me semble que la cible première de Java c'était les lave linges et les micro-ondes ?

[souviron34]

Les gens qui font des pointeurs de pointeurs de pointeurs de ... ^^

J'en fait tous les jours et ça ne me pose aucun problème

Ceci dit je fais pas de C/C++ donc j'en sais trop rien. Pour moi le plus compliqué c'est surtout la gestion du cycle de vie. De ce que j'ai pu sentir en discutant avec des développeurs C/C++, ils utilisent énormément d'objet jetable et le constructeur par recopie.

C'est bien là le problème : C/C++ n'existe pas...

C'est soit l'un, soit l'autre...

Et en C justement si tu fais de l'OO tu n'auras pas de constructeur par recopie...

En 1994, c'était pas plutôt des PCs HP/Compaq ?

Il y en avait, mais - je n'étais pas en France à l'époque - HP/Compaq n'étaient pas la majorité...

Et il me semble que la cible première de Java c'était les lave linges et les micro-ondes ?

légende urbaine...

https://fr.wikipedia.org/wiki/Java_%28langage%29

Certaines personnes prétendent également que le nom de Java vient du fait que le programme était destiné à pouvoir tourner sur des systèmes embarqués, comme des cafetière

Mais surtout, par rapport au sujet :

De juin à juillet 1994, après trois jours de remue-méninges avec John Gage, James Gosling, Joy, Naughton, Wayne Rosing et Eric Schmidt, l’équipe recentra la plate-forme sur le web. Ils pensaient qu’avec l’avènement du navigateur Mosaic, Internet était le lieu où allait se développer le même genre d’outil interactif que celui qu’ils avaient envisagé pour l’industrie du câble. Naughton développa comme prototype un petit navigateur web, WebRunner qui deviendra par la suite HotJava.
.....
En octobre 1994, HotJava et la plate-forme Java furent présentés pour Sun Executives. Java 1.0a fut disponible en téléchargement en 1994 mais la première version publique du navigateur HotJava arriva le 23 mai 1995 à la conférence SunWorld2.

L’annonce fut effectuée par John Gage, le directeur scientifique de Sun Microsystems. Son annonce fut accompagnée de l’annonce surprise de Marc Andressen, vice-président de l’exécutif de Netscape que Netscape allait inclure le support de Java dans ses navigateurs. Le 9 janvier 1996, le groupe Javasoft fut constitué par Sun Microsystems pour développer cette technologie3. Deux semaines plus tard la première version de Java était disponible.

Disons que comme, en graphique, tu avais X11 sur tous les constructeurs SAUF M$, et que M$ avait Win32, déjà pour un navigateur, Mosaic se basait sur X11, puis Netscape avait 2 versions.

C'est donc l'aspect portabilité du graphisme qui a valu l'intérêt porté à Java entre 96 et 2000...

[GrandFather]

Et c'est bien là que je vois le problème.. Cette classification a été effectuée par les défenseurs du OO comme étant le nec-plus-ultra de la programmation...

Ca y est, tu as encore enfourché ton vieux cheval de bataille, hein ?

Déjà, tu fais une erreur d'interprétation, l'appelation « haut niveau » n'induit pas comme tu l'insinues une échelle qualitative, il s'agit simplement de définir des langages qui s'éloignent des primitives de la machine sur laquelle ils s'exécutent pour mettre en oeuvre des paradigmes tels que l'objet, le lambda calcul, le langage naturel, la logique du premier ordre, etc.

D'autre part, il s'agit d'une notion relative et évolutive. Par exemple, à son apparition, le C était considéré comme un langage de haut niveau par rapport à ceux en vigueur. Autre exemple, BeOS était un OS, le seul à ma connaissance, à avoir été intégralement conçu en C++ (et en assembleur), et donc à présenter une API intégralement objet. Le C++ ne pouvait donc pas être considéré comme un langage à haut niveau d'abstraction pour cette plateforme particulière.

[souviron34]

Ca y est, tu as encore enfourché ton vieux cheval de bataille, hein ?
..
D'autre part, il s'agit d'une notion relative et évolutive.

Ce n'est pas un cheval de bataille, c'est juste que la denière partie citée n'a pas l'air très partagée, et que ça sent beaucoup plus absolu que relatif..

Mais c'est aussi lié - mon exaspération - au fait de la religion OO, et des codes/modélisations extrêmement complexes qu'on voit, qui me selblent être tout le contraire d'un "haut niveau d'abstraction"

[jouana]

Ca n'a rien a voir avec l'OO j'en fait pas la défense loin de la et bas ou haut niveau n'a rien a voir avec l'OO.

Ni même de la complexité de la solution qui en sort du à des contraintes de type techno, fonctionnel ou autres.

Ce que je souligné plus haut c'est qu'un langage de bas niveau nécessite un peu plus de notion de base qu'un langage de haut niveau.

Tu prend du php par exemple, tu n'utilise pas la partie objet ça reste un langage de haut niveau, pas de gestion de la mémoire, typage auto ....

Les langages de haut niveau surcouche plus de chose afin de simplifié sont utilisation c'est un fait, après il n'est pas dit que la conception est plus simple.

Les gens qui dev en C et C++ pense beaucoup plus à la stack que ce qui dev en java.

[Logan Mauzaize]

J'en fait tous les jours et ça ne me pose aucun problème

C'est bien là le problème : C/C++ n'existe pas...

C'est soit l'un, soit l'autre...

Et en C justement si tu fais de l'OO tu n'auras pas de constructeur par recopie...

D'un point de vue gestion de la mémoire, C et C++ se valent. Je suis certes pas un expert mais à part le malloc devenu new, il me semble qu'il n'y a pas de grosses différences entre les deux langages.

Il y en avait, mais - je n'étais pas en France à l'époque - HP/Compaq n'étaient pas la majorité...

En tout cas je jouais sur HP et Compaq à l'époque. Vive DOOM et Diablo ^^

légende urbaine...
https://fr.wikipedia.org/wiki/Java_%28langage%29

Disons que comme, en graphique, tu avais X11 sur tous les constructeurs SAUF M$, et que M$ avait Win32, déjà pour un navigateur, Mosaic se basait sur X11, puis Netscape avait 2 versions.

C'est donc l'aspect portabilité du graphisme qui a valu l'intérêt porté à Java entre 96 et 2000...

On est déjà dans l'air du Web, le projet Oak est apparu bien avant. De toutes facons c'est sans importance.

[Logan Mauzaize]

Les gens qui dev en C et C++ pense beaucoup plus à la stack que ce qui dev en java.

Bah disons qu'en Java, on ne peut pas créer d'objet sur la stack, ca limite déjà pas mal. En gros il n'y a que les références et les types primitifs.
Bien qu'il me semble que l'optimiseur peut faire de l'allocation sur la stack désormais mais ce n'est pas un concept que tu peux manipuler.


D'ailleurs merci d'apporter ce sujet, ca montre bien que dans un langage comme le C tu dois/peux faire attention à comment fonctionne la machine alors que c'est moins vrai pour d'autres langages plus "haut niveau".

[souviron34]

D'ailleurs merci d'apporter ce sujet, ca montre bien que dans un langage comme le C tu dois/peux faire attention à comment fonctionne la machine alors que c'est moins vrai pour d'autres langages plus "haut niveau".

Ah bon ????

Bizarre... Je n'ai même jamais su - et a fortiori préoccupé de - ce qu'était un stack, et pourtant je progamme depuis maintenant 24 ans en C...


C'est exactement là-dessus que ça m'irrite... C'est vous qui avez eu des cours théoriques, mais vous jugez sans avoir pratiqué, ou tout au moins sans avoir pratiqué SANS les cours théoriques...

[rimram31]

légende urbaine...

https://fr.wikipedia.org/wiki/Java_%28langage%29

Oui et non ... http://en.wikipedia.org/wiki/Java_%2...orm%29#History Oak a bien été créé dans le cadre d'un projet Sun dédié aux "smart appliances", soit des appareils "intelligents". J'ai commencé a faire "mumuse" avec Java (pas que, je l'avais évalué dans le cadre d'un projet bien concret!), ce devait être encore la 1.0 et si j'en crois l'histoire, ce devait être en 97 car j'ai souvenir avoir vu arriver la 1.1 a peine la 1.0 téléchargée

A l'époque, je me souviens de lecture d'articles (que je ne retrouve plus ...) expliquant que la techno avait été conçue afin de permettre a un contrôleur de piloter différents équipements en leur envoyant directement le programme a exécuter, même programme devant s'exécuter sur différents hardware, d’où l'approche VM.

Là où tu as raison c'est qu'ensuite Java lui est né en réutilisant ces travaux dans un tout autre cadre, celui des navigateurs web.

Sinon votre débat est amusant, plutôt d'accord avec souviron34 sur la complexité que l'on a ajouté alors qu'elle ne s'imposait pas. Les langages se valent, quand on en a exploré quelques uns, la prise en main d'un nouveau ne doit pas excéder la demi journée, je ne compte plus le nombre de langage "classiques" et ou ésotériques (spécifique a certains outils/équipements) que j'ai eu a prendre en main, la vraie difficulté sera de savoir comment traiter un problème particulier: environnement, librairies dispos ...

Je pense que naturellement on fait l'association entre un langage et l'ensemble des technologies qui l'accompagne qui fait que les langages "modernes" sont perçus comme plus complexes que les anciens.

Sur la complexité, ce qui me désole c'est que tous les langages disons "populaires" suivent la même route stupide, ils se complexifient et du coup perdent ce qui en a fait leur succès: leur simplicité. C/C++, Java/ Java 1.5, PHP "objet" ...

Ne pas s'étonner du succès de javascript aujourd'hui mais probable qu'il fera les mêmes erreurs ..

[el_slapper]

ça mélange un peu tout, là...

Haut niveau : qui évite de se salir les mains avec les octets. Pas forcément une bonne idée, mais parfois oui. De toutes façons, tous les langages couvrent un certain spectre entre le bas niveau et le haut niveau. Juste certains permettent d'aller très bas, et d'autres très haut. SQL ne permet pas d'aller très bas, l'assembleur ne permet pas d'aller très haut.

Et je crois que votre afforntement sur le C++ vient de ce que c'est sans doute le langage à spectre le plus large. On peut faire du très abstrait, mais aussi du typo assembleur, avec. Haut niveau? Oui, mon général. Bas niveau? Tout autant, mon général.

Pour ce qui est de l'objet, beeeen, l'OO, c'est de l'impératif. La seule différence, c'est que le code affectant une donnée est collé à la définition de la donnée(donc dans la classe, qui est une structure de données à laquelle on ajoute le code s'appliquant dessus). Bon, ça a quelques impacts complémentaires, positifs(genre polymorphisme, surcharge simplifiés) ou négatifs(les modifications sur un composant utilisé partout ont tendance à rendre sa relivraison, euh, pas simple. Pire qu'en impératif).

Mais ça n'est pas la grande révolution, ni le grand carnage. C'est juste une manière un peu différente de ranger son code. Parfois adaptée, parfois non.

[jouana]

Ah bon ????

Bizarre... Je n'ai même jamais su - et a fortiori préoccupé de - ce qu'était un stack, et pourtant je progamme depuis maintenant 24 ans en C...


C'est exactement là-dessus que ça m'irrite... C'est vous qui avez eu des cours théoriques, mais vous jugez sans avoir pratiqué, ou tout au moins sans avoir pratiqué SANS les cours théoriques...

Le coup du sort de tes cahiers est un peu facile, perso j'ai fait une formation basée sur l'auto formation et la pratique intensive voir excessive.

Je ne me permet pas de dire tu as appris sur le tas c'est normal que tu es des lacune en culture informatique qui est totalement du même niveau que cette remarque.

Je ne connais ton parcours, ta façons de travailler et sur quoi tu travail je trouve donc que dans ce contexte ce type de remarque et plus que déplacé.

Soit pendant plus de 2 ans développement en C sur une moyenne de 10 à 15h/j 7/7 et ou je pouvais prendre des jours de repos en fonction de mon avancement sur les projets que je devais accomplir.

On voit un peu de théorie pour l'application mais c'est bien la pratique qui était mise en avant.

Wikipedia:Langage de haut niveau
Wikipedia:Langage de bas niveau

Je pense que ces 2 liens pourront clore ce débat.

Qui ressemble plus à une troll qu'autre chose, je ne dénigre le travail de personne je mettais juste une réalité en avant dans notre monde.

[gangsoleil]

Bizarre... Je n'ai même jamais su - et a fortiori préoccupé de - ce qu'était un stack, et pourtant je progamme depuis maintenant 24 ans en C...

Eh bien on va dire dans ce cas que le type de developpement que tu fais ne necessite pas de savoir cela, mais que ce n'est pas forcement le cas de tous les developpements.
Par exemple lorsqu'il y a des contraintes exterieures qui limitent les ressources utilisables, il semble necessaire de savoir quelles sont ces ressources, et comment en tirer partie.

Ou bien lorsque tu manipules des quantites de donnees pharaoniques, la encore l'utilisation de certaines choses sera plus adaptee que d'autres, et lorsque le fait de gagner/perdre une milliseconde sur un calcul te fait gagner/perdre 3h40 de calcul par jour, il est important de bien connaitre les tenants et les aboutisssants de ce qu'on utilise -- et mieux encore de comprendre pourquoi et comment les utiliser.

[souviron34]

Eh bien on va dire dans ce cas que le type de developpement que tu fais ne necessite pas de savoir cela, mais que ce n'est pas forcement le cas de tous les developpements.
Par exemple lorsqu'il y a des contraintes exterieures qui limitent les ressources utilisables, il semble necessaire de savoir quelles sont ces ressources, et comment en tirer partie.

Ou bien lorsque tu manipules des quantites de donnees pharaoniques, la encore l'utilisation de certaines choses sera plus adaptee que d'autres, et lorsque le fait de gagner/perdre une milliseconde sur un calcul te fait gagner/perdre 3h40 de calcul par jour, il est important de bien connaitre les tenants et les aboutisssants de ce qu'on utilise -- et mieux encore de comprendre pourquoi et comment les utiliser.

C'est bien vrai, mais c'est vrai de tous les langages...

Et a fortiori des langages "plus évolués", qui ont plus de couches (par exemple le "new" en langage objet fait beaucoup plus qu'un simple alloc, et du coup exécute tout un tas d'instructions dont on n'a pas besoin dans le cas d'optimisation)

Ce que je veux dire, c'est que votre conception "Grande abstraction" est bizarre, pare que justement vous me sortez des arguments de machine...

Pour moi justement "grande abstraction" signifie ne pas s'en occuper, et, j'ai pourtant programmé des millions de lignes, sur des applis prenant beaucoup de données (et de débit de données)..

Mon travail a principalement été sur les maths et des algos de géométrie ou de traitement d'images, mais aussi des clients/serveurs et du graphisme.


Et je n'ai absolument JAMAIS ni pensé ni été limité au "stack".... C'est vraiment étrange.. Vous me sortez des trucs qui me semblent tellement ésotériques que je ne vois pas bien le rapport.... Ou alors au contraire j'ai peur de comprendre...

[el_slapper]

Wikipedia:Langage de haut niveau
Wikipedia:Langage de bas niveau

Extraits :

La définition reste malgré tout assez floue, et il n'existe pas de méthode particulière qui permettrait de déterminer objectivement si un langage peut être considéré de bas niveau.

D'autres langages, comme le C voire le C++, sont considérés par certains comme étant des langages de bas niveau. D'autres pensent au contraire que le C et le C++ sont des langages de haut niveau car ils ne permettent pas de gérer suffisamment finement le matériel dans certaines situations.

ça correspond à ma notion de spectre.

En 2010, il existe plus de 200 langages de programmation de haut niveau. Les plus populaires sont Pascal, Java, Fortran, COBOL, OCaml et Python.

Bon, ça me rassure, je n'ai pas dit trop de clowneries.

[gl]

Je rejoins complètement el_slapper sur la notion de bas/haut niveau :

• Déjà il n'y a pas de définition universellement accepté : pour certains le haut niveau est caractérisé par l'éloignement du matériel, pour d'autres par les abstractions fournis (et on peut abstraire autre chose que le matériel, typiquement les DSL qui laissent de côté l'aspect "programmation" pour se rapprocher des notations et langages du domaine qu'ils modélisent) et enfin un nombre malheureusement très important de personne pour qui haut niveau == garbage collector[1] + typage dynamique[2] faible [3].[4]
• Ce n'est pas un simple point sur un axe mais bel et bien un plage complète. Plus ou moins large en fonction des outils proposés par les langages.
• Ce n'est même pas un axe unique mais un ensemble de critères. Comment classer des choses aussi différentes que l'introspection, le polymorphisme paramétrique, la surcharge d'opérateur, les slices, les listes en compréhension, etc. sur un même axe ? Et pourtant chaque langage en supporte certains et non d'autres, à partir de là comment être capable de classer les langages de manière absolue ?

[1] Je suis tout à fait d'accord que le garbage collector est un outil intéressant avec ses qualités et défauts propres qui le rende utile dans certaines situations. J'apprécierais en avoir un à disposition en standard en C++ en complément des mécanismes existants (et surtout pas à la place, ils ne correspondent pas aux mêmes points de compromis et sont complémentaires).
Par contre je ne vois pas franchement où se situe le niveau plus élevé que disons les smart pointers : on troque un mécanisme gérant uniquement la mémoire (pour les autres ressources, il faut les gérer "à la main") de manière non déterministe (le GC) contre un mécanisme qui gère toutes les ressources (bien que de manière un peu plus fastidieuse et un poil moins abstraite en ce qui concerne la mémoire) de manière déterministe. Des outils différents, mais pas fondamentalement plus abstrait ou plus loin du matériel.
[2] Dynamique vs. statique : un compromis différents, des qualités et limitations différentes mais pas fondamentalement plus haut niveau l'un que l'autre [5]. Et définitivement complémentaires.
[3] Typage faible vs. fort : y a-t-il vraiment besoin de détailler ? Peut-on sérieusement considérer un mécanisme nuisant à la robustesse, à la capacité à évoluer, à la maintenabilité, etc. comme une meilleure abstraction ?
[4] Cette dernière population me semble plus représenté un ensemble de personne à la compétence douteuse développant à la "vas-y comme je te pousse" sans se soucier de robustesse, de maintenabilité, de performance, de qualité dont l'objectif est d'obtenir un truc qui tombe en marche (enfin tant qu'on ne le titille pas trop) qu'autre chose.
[5] Par contre, dans le cadre du typage dynamique, je veux bien reconnaitre une abstraction un poil plus élevée du typage inféré sur le typage déclaré.

Pour ce qui est de l'objet, beeeen, l'OO, c'est de l'impératif.

Pas nécessairement, par exemple CLOS, qui est un système objet basé sur Common Lisp, est fonctionnel et non impératif.
En fait les notions d'OO et d'impératif sont relativement orthogonal même si les langages OO mainstream sont plutôt impératifs.

[souviron34]

Et je crois que votre afforntement sur le C++

Justement, ça n'était pas sur le C++ mais sur le C


En dehors de ça, tout à fait d'accord avec toi, et je trouve ta conclusion excellente :

Mais ça n'est pas la grande révolution, ni le grand carnage. C'est juste une manière un peu différente de ranger son code. Parfois adaptée, parfois non.

C'est un peu pour ça que ça m'énerve "ben raide", ces histoires-là...



@jouana : on va pas jouer à qui a la plus grosse, mais tu serais surpris, et ce que tu dis de ton expérience ne m'étonne pas du tout - et même confirme ce que je pensais - par rapport à tes conclusions

[jouana]

Non effectivement le but n'est pas de jouer à la plus grosse mais bien d'avoir un échange constructif afin que chacun puisse avancer dans le bon sens.

Bonne journée à tous

[deadalnix]

ou ils pensent faire de bon choix en diversifiant leur environnement de dévelopemment.

Personellement, j'ai toujours imposé dans notre entreprise un environnement unique (Turbo-pascal de 1983 à 1995, Delphi de 1995 à 2005, Visual studio C# depuis 2006) en créant à titre exceptionnel des "wrappers" dans d'autre langages pour interfacer nos développements.

L'inconvénient de cette strategie est qu'on est parfois amené à refuser des affaires. L'avantage est qu'on sait mieux évaluer les temps/coûts de développement dans des environnements bien maitrisés et qu'on peut capitaliser sur l'expérience acquise. Résultat : cela fait plus de 20 ans que personne chez nous n'a travaillé le week-end.

Si j'avais un marteau . . .

[deadalnix]

Bah disons qu'en Java, on ne peut pas créer d'objet sur la stack, ca limite déjà pas mal. En gros il n'y a que les références et les types primitifs.

Si tu crois que java ne met aucun object dans la stack, tu te mets le doigt dans l'œil jusqu'au fond du slip. Tu ne peux pas le spécifier explicitement, mais c'est un autre sujet.

[Logan Mauzaize]

Si tu crois que java ne met aucun object dans la stack, tu te mets le doigt dans l'œil jusqu'au fond du slip. Tu ne peux pas le spécifier explicitement, mais c'est un autre sujet.

Tu aurais au moins pu prendre la peine de lire la phrase suivante Et c'est tout à fait le sujet puisqu'on parle d'abstraction au même titre que tu ne peux pas spécifier l'allocation (et sa suppression) de la mémoire.