Discussion :

[jabbounet]

Ca me fait pensez à un article que j'avais lue sur l'influence de java dans les ecoles sur le niveau
http://www.developpez.net/forums/d59...ecoles-niveau/

très intéressant ces articles, je met en liens les références que l'on peux trouver dans le fofo que tu a mis ce sera plus rapide.

http://java.developpez.com
http://www.stsc.hill.af.mil/CrossTal...Schonberg.html


maintenant trouver des produit sur étagère pour t'aider a faire ton soft ça peux aider mais il faut le faire avec parcimonie .
Parfois ça coute moins cher de re developper une lib (adapté au besoin) que de se prendre la tête a savoir si tel produit (proche du besoin) conviens et comment gérer sa license si on veux l'intégrer, comment vont se répartir les royalties, le support, ....

[nicorama]

En pédagogue (en théorie ), je suis parfaitement d'accord pour dire qu'il ne faut pas commencer par java !

Java utilise les pointeurs et nettoie la mémoire. Un programmeur Java comme les autres doit le savoir, et utilise sa compréhension au moment de debugger.

Mais si on n'a jamais appris à utiliser un pointeur et allonger les octets en mémoire, on ne peut passer à un autre langage, et en plus on debuggera par bidouillage !

Pas moyen de me remettre au C, mais je suis bien content d'y être passé !

[yan]

juste une remarque par rapport au GC (de C#, mais je pense que c'est la même chose en java).
J'ai préparé une démo sur une appli style google map sur un mobile et C#.
Venant du C++, je me suis confronté à des problèmes mémoire :
comme j'utilise des tuiles d'images, je devais régulièrement charger/télécharger de nouvelles images. De plus, j'avais une image 1024*1024 comme buffer intermédiaire pour accélérer l'affichage (j'ai utilisé Graphics au lieu de directdraw, c'est sûrement pas le bon choix) et j'en allouais une autre à chaque mise à jour du buffer intermediaire.
Au début, je ne faisait aucun dispose car je me suis dit GC fait tous alors m'en fou. Et je me suis retrouvé très vite avec une exception car plus assez de mémoire....
Du coup j'ai créé mes deux images 1024*1024 une fois pour toute et j'ai fait mes disposes à la main des qu'une image n'est plus utiliser. Donc j'ai fait à l'ancienne, sans GC. Et ça marche nickel.
Même problème sur l'ouverture/téléchargement des tuiles. Obliger d'utiliser des using pour que le dispose soit automatique et ne pas avoir des erreurs d'ouvertures ou le téléchargement qui se bloque

Donc je ne trouve pas non plus que le GC est le must !!! C'est un outil pratique mais faut être sensibilisé aux limites.

[jabbounet]

juste une remarque par rapport au GC (de C#, mais je pense que c'est la même chose en java).
J'ai préparé une démo sur une appli style google map sur un mobile et C#.
Venant du C++, je me suis confronté à des problèmes mémoire :
comme j'utilise des tuiles d'images, je devais régulièrement charger/télécharger de nouvelles images. De plus, j'avais une image 1024*1024 comme buffer intermédiaire pour accélérer l'affichage (j'ai utilisé Graphics au lieu de directdraw, c'est sûrement pas le bon choix) et j'en allouais une autre à chaque mise à jour du buffer intermediaire.
Au début, je ne faisait aucun dispose car je me suis dit GC fait tous alors m'en fou. Et je me suis retrouvé très vite avec une exception car plus assez de mémoire....
Du coup j'ai créé mes deux images 1024*1024 une fois pour toute et j'ai fait mes disposes à la main des qu'une image n'est plus utiliser. Donc j'ai fait à l'ancienne, sans GC. Et ça marche nickel.
Même problème sur l'ouverture/téléchargement des tuiles. Obliger d'utiliser des using pour que le dispose soit automatique et ne pas avoir des erreurs d'ouvertures ou le téléchargement qui se bloque

Donc je ne trouve pas non plus que le GC est le must !!! C'est un outil pratique mais faut être sensibilisé aux limites.

je ne suis pas trop dans ces problématiques la (je pas fait beaucoup de java/C#) , mais je suppose que même si ton appli est stable en mémoire le fait de ne pas savoir quand ça sera nettoyé fait que tu vas entasser tout un tas d'objets inutilisé et si ton système est limité en mémoire tu risque d'allouer plus vite que ce que ton gc peux nettoyé et avoir ce genre de phénomène même si ton applis est globalement stable.

Ou alors je dit des bêtises et il y'a un mécanisme qui fait ça ne peux pas se produire ce genre de choses?


Autrement utilisé plusieurs buffers (fixe) en affichant un pendant que tu calcule ce qu'il y'aura dans les autres avant de les afficher me rappelle quelque choses de déjà vu quand j'étais étudiant et que l'on devais prendre en compte un affichage entrelacé des écran (tubes cathodiques) pour faire nos tp de programmation avec la lib X11 (un an ou deux avant la naissance de qt)

En recherchant un peu j'ai trouvé ça
http://en.wikipedia.org/wiki/Double_buffering

[yan]

je ne suis pas trop dans ces problématiques la (je pas fait beaucoup de java/C#) , mais je suppose que même si ton appli est stable en mémoire le fait de ne pas savoir quand ça sera nettoyé fait que tu vas entasser tout un tas d'objets inutilisé et si ton système est limité en mémoire tu risque d'allouer plus vite que ce que ton gc peux nettoyé et avoir ce genre de phénomène même si ton applis est globalement stable.

Oui je pense aussi que c'était le problème. Le GC n'avez pas encore libéré la mémoire et il n'y en avais plus assez. Le dipose m'as permis de contrôlé cette désallocation pour les images et ne plus avoir ce problème. Par contre, je pense que si l'appli aurais été desktop, y aurais peut de chance que j'ai ce problème de mémoire.

En recherchant un peu j'ai trouvé ça
http://en.wikipedia.org/wiki/Double_buffering

C'est bien le principe, mais j'avais zappé le nom quand j'ai écrit

[hegros]

yan j'ai eu le même problème avec un langage compilé soit sans gc, le problème venait plus de la plateforme mobile qui est limité en mémoire et en ressource de manière général, c'est des problèmes de performance à résoudre avec de meilleurs algorithmes et conception.

Et effectivement sur une autre plateforme tu n'aurais pas eu ce problème de mémoire puisque sur desktop en général les pc ont plus de mémoire que les mobiles

[yan]

le problème venait plus de la plateforme mobile qui est limité en mémoire et en ressource de manière général, c'est des problèmes de performance à résoudre avec de meilleurs algorithmes et conception.

Ce n'est pas tout à fait le même problème.
Je n'avais pas changé la quantité de mémoire utilisé, où le GC ne change rien, mais la façon dont est fait l'allocation/désalocation des images.
Si tu préfère à un instant t, j'avais toujours la même mémoire "théorique" utilisé pour les images. Seulement, très rapidement je me retrouvais sans mémoire car apparemment le GC n'avais pas encore fait ses désallocation. Juste en ajoutant un dispose au bon endroit, plus de problème.

[hegros]

Ah je comprends mieux en fait c'est une micro-fuite au niveau du GC qui ne ramasse pas ses propres miettes donc au bout d'un moment tu saturais la mémoire et le fait d'appeler explicitement le dispose à amener le GC à ramasser les miettes de ton application et de elle-même.

j'imagine aussi que ton système était mis à jour et qu'il n'y avait pas de problème connu pour le matériel concerné découvert après.

[jabbounet]

ceci dit avec une methode double buffering ét dérivée tu n'as normalement pas besoin de desalloue/reéllouer tes buffer, tu fait pointer (les adepter du java n'aime pas ce mot) index sur le buffer que tu veux afficher pendant que tu recalcule le contenu des autres

[yan]

ceci dit avec une methode double buffering ét dérivée tu n'as normalement pas besoin de desalloue/reéllouer tes buffer, tu fait pointer (les adepter du java n'aime pas ce mot) index sur le buffer que tu veux afficher pendant que tu recalcule le contenu des autres

C'était la première version et c'était pas du tout optimisé sur ce point là. C'etait une démo et la première fois que je faisai du C#.
Pour les deux images qui servent de buffer tu as raison, mais pour les tuiles, c'est impossibles surtout que l'on ne peut réutilisser un Bitmap pour charger une autre image(du moins je n'ai rien vue qui le permet).

La on part sur du HS, c'était pour illustrer que le GC n'est pas magique et qu'il peut poser des problèmes.

[jabbounet]

en les mettan dans un pool peu etre?

[Jedai]

Mon langage préféré est Haskell.

C'est un langage de programmation peu connu qui diffère radicalement des langages mainstream :

• purement fonctionnel : les effets de bord (IO, affectation à une variable, ...) y sont prohibés, ce qui fait que les fonctions respectent la transparence référentielle, une application de f à un argument donné renvoie toujours le même résultat, quel que soit le contexte. Les structures de données sont permanentes, elles ne peuvent pas être modifiées.
• évaluation paresseuse : les arguments d'une fonction ne sont évalués que si c'est nécessaire pour évaluer la fonction, et seulement autant qu'il est nécessaire. En conséquence de quoi, les structures de données infinies sont un idiome courant en Haskell, et les fonctions comme (||) (le OR à court-circuit des langages traditionnels) sont des fonctions comme les autres.
  

  Code Haskell :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  (||) :: Bool -> Bool -> Bool
  True || _ = True
  False || b = b

• typage statique fort : le système de type d'Haskell est très expressif, bien au-delà des systèmes de types de Java, C++ ou autres langages impératifs. Classes de types, types algébriques, polymorphisme paramétrique (de rang N), types existentiels, GADT, types fantômes.... Tous ces concepts (n'ayez pas peur, on n'a pas besoin de tous les connaître pour débuter en Haskell) permettent d'exprimer dans les types des contraintes de sécurité bien plus poussées que dans les langages mainstream.
• inférence de type : de plus il n'est pas souvent nécessaire d'être explicite dans les annotations de type (bien qu'il soit recommandé d'annoter les fonctions exportées à titre de documentation).

En conséquence de ces avantages théoriques, on a des avantages pratiques, comme une très grande facilité et sûreté de parallélisation et un compilateur optimiseur de grande qualité (GHC) qui produit du code parfois aussi rapide que du C.

Haskell a gagné une audience plus large dans les dernières années et en conséquence on trouve de plus en plus de librairies (Hackage) et d'outils (Haddock, HLint, Catch, ...). Aujourd'hui, Haskell est un langage de très grande qualité théorique et pratique, extrêmement expressif (un programme en Haskell est souvent aussi long, sinon même plus court que son équivalent dans les langages de scripts réputés pour leur expressivité), performant (nettement plus que les langages de scripts) et orienté sûreté.

--
Jedaï

[jabbounet]

haskell, cela me fait penser de très loin a prolog.

[Jedai]

haskell, cela me fait penser de très loin a prolog.

A peu près rien à voir : Haskell est purement fonctionnel statiquement typé, Prolog est logique dynamiquement typé. Le seul point commun qu'on pourrait leur trouver ce serait qu'ils appartiennent tous deux à la très vague catégorie des langages déclaratifs. Un méta point commun c'est que ce sont des langages plutôt académiques d'origine.

Quelque chose qui ressemble nettement plus à Haskell dans le secteur des langages logiques, c'est Curry.

Un exemple d'Haskell idiomatique pour créer une liste infinie "a", "b", .... "z", "aa", "ab", ... , "zz", "aaa" ... :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alphas = concat . tail . iterate (liftM2 (:) ['a'..'z']) $ [[]]

Comme vous le voyez c'est très compact pour décrire une opération relativement complexe et pour un programmeur Haskell de niveau correct, c'est également très lisible.

--
Jedaï

[xtra.creativity]

Les deux personnes qui ont vote le fortran c'est juste une blague ?
Je l'espere...

[Matthieu Brucher]

Les deux personnes qui ont vote le fortran c'est juste une blague ?
Je l'espere...

Ben non, pourquoi ? Si ces personnes font souvent du calcul scientifique, Fortran est une alternative tout à fait valable !

[FR119492]

Salut!

Les deux personnes qui ont vote le fortran c'est juste une blague ?
Je l'espere...

Non, ça n'est pas une blague, mais ça va devenir un défi: Dans le langage de ton choix, tu écris un programme pour résoudre un système linéaire de 10'000 équations à 10'000 inconnues, et ensuite, on chronomètre et on compare le temps d'exécution avec celui de mon programme écrit en Fortran.
Jean-Marc Blanc

[jabbounet]

Les deux personnes qui ont vote le fortran c'est juste une blague ?
Je l'espere...

et de plus c'est un langage avec un syntaxe plus lisible que le C à la base.

[Tommy31]

Non, ça n'est pas une blague, mais ça va devenir un défi: Dans le langage de ton choix, tu écris un programme pour résoudre un système linéaire de 10'000 équations à 10'000 inconnues, et ensuite, on chronomètre et on compare le temps d'exécution avec celui de mon programme écrit en Fortran.
Jean-Marc Blanc

Quelle version de fortran ?

[FR119492]

Salut!

Quelle version de fortran ?

Je travaille avec un Compaq Fortran dont le manuel de référence date de septembre 1999 et qui semble avoir intégré les possibilités F90 et F95. En fait, je programme en format fixe, parce que je n'ai pas encore vu de raison valable de changer et je n'utilise que peu des nouveautés, si ce n'est le format EN qui est très pratique pour l'impression des résultats. C'est peut-être un peu "retro", mais très efficace.
Jean-Marc Blanc