Je viens de découvrir HB++ sur leur site...
Ca a l'air pas mal fait du tout et surtout : cela semble plus simple que d'attaquer directement le codage en instructions natives de Palm OS...
J'ai vu les nombreux différents tutoriels par-ci par-là, et les commentaires à son propos sur ce forum.
En plus, y'a une version trial fully fonctionnelle qui permet de tester l'IDE complètement, sans restriction.
Je vais donc tenter une approche par cette voie... Espérons qu'elle soit plus fructueuse pour moi que via PODS, qui m'a un peu découragé...
Version complète : Développement : C ou HB++ ?
Je pense que tu te décourrages vite. Au contraire je trouve l'API de PalmSource super bien faite, surtout pour de C. Tu peux faire ta première application en quelques lignes, alors que toutes les API graphique en C que j'ai connu, demandaient des 100aine de lignes (Ex: Xlib 
). Si tu veux voici un synoptique d'application en C PalmSource:
Voila pour le main le code est pratiquement toujours le même
Il manque le gestionnaire de la form en code
Et maintenant les resources, là si tu utilises PODS normalement il faut créer un fichier xrd avec l'outil fourni par PalmSource. Sinon si tu utilises PilRC comme tout bon linuxien il faut un fichier rcp comme celui-ci
Bon il y a beaucoup de chose à rajouter, il y beaucoup d'erreurs ici mais c'est juste un synoptique. Dès que j'aurais accès à mon ordi perso, je t'enverrais mes applis de base, celle avec laquelle je développe maintenant mes nouvelles applis. J'ai dit mes car j'ai une appli pour gérer une form sans database et une autre qui gère une database, avec une form listant les enregistrements, une form pour en visualisée un et une form pour en éditer un. En faite cette dernière est très proche de la toute première version de ExMail que tu peux avoir ici
). Si tu veux voici un synoptique d'application en C PalmSource:
CITATION(main.c)
CODE
PilotMain()
{
AppStart(); /* fonction a definir*/
AppEventLoop(); /* fonction a definir*/
AppStop(); /* fonction a definir*/
return 0;
}
void AppStart()
{
//ouvre ta database ici si tu as besoin
//fonctions de DataBase Manager (Ex: DmOpenDatabase)
//Sélectionne la première Form (Fenètre) à ouvrir
FrmGotoForm(RSC_FORMID_MAIN);
//Autres initialisations possibles: le DIA, les préférences, la comm, les librairies...)
}
void AppEventLoop()
{
// la boucle générale d'execution
do
{
// recherche un nouvel evenement du système
EvtGetEvent(&event);
// l'event est-il traité par le système?
if (!SysHandleEvent(&event))
//l'event est-il traité par le gestionnaire des menus
/*si c'est le cas ce gestionnaire enverra un autre event
qu'il laissera passé au gestionnaire de la form*/
if (!MenuHandleEvent(&event))
//l'event est-il traité par le gestionnaire spécifique de ton appli
if (AppHandleEvent(&event)) /* fonction a definir*/
//l'event devrat etre traité par le gestionnaire de la form en court, ce gestionnaire est chargé dynamiquement plus loin
DispatchHandleEvent(&event);
} while (event.eType != appStop)
}
Boolean AppHandleEvent(pEventP)
{
// l'event est-il le chargement d'une form
if (pEventP->eType == frmLoadEvent)
{
// chargement de la form
FrmSetActiveForm(pEventP->data.frmLoad.frmP);
if (pEventP->data.frmLoad.frmID == RSC_FORMID_MAIN)
{
// chargement du gestionnaire spécifique de la form
/* MainFormHandleEvent fonction a definir */
FrmSetHandleEvent(RSC_FORMID_MAIN, MainFormHandleEvent);
//l'event a été traité
return true;
}
}
//l'event N'a PAS été traité
return false;
}
void AppStop()
{
// envoi un event frmSave à tous les gestionnaires de form actif
FrmSaveAllForm();
// envoi un event frmClose à tous les gestionnaires de form actif
FrmCloseAllForm();
//fermeta database ici si tu as besoin
//fonctions de DataBase Manager (Ex: DmCloseDatabase)
//Autres fermeture possibles: le DIA, les préférences, la comm, les librairies...)
}
{
AppStart(); /* fonction a definir*/
AppEventLoop(); /* fonction a definir*/
AppStop(); /* fonction a definir*/
return 0;
}
void AppStart()
{
//ouvre ta database ici si tu as besoin
//fonctions de DataBase Manager (Ex: DmOpenDatabase)
//Sélectionne la première Form (Fenètre) à ouvrir
FrmGotoForm(RSC_FORMID_MAIN);
//Autres initialisations possibles: le DIA, les préférences, la comm, les librairies...)
}
void AppEventLoop()
{
// la boucle générale d'execution
do
{
// recherche un nouvel evenement du système
EvtGetEvent(&event);
// l'event est-il traité par le système?
if (!SysHandleEvent(&event))
//l'event est-il traité par le gestionnaire des menus
/*si c'est le cas ce gestionnaire enverra un autre event
qu'il laissera passé au gestionnaire de la form*/
if (!MenuHandleEvent(&event))
//l'event est-il traité par le gestionnaire spécifique de ton appli
if (AppHandleEvent(&event)) /* fonction a definir*/
//l'event devrat etre traité par le gestionnaire de la form en court, ce gestionnaire est chargé dynamiquement plus loin
DispatchHandleEvent(&event);
} while (event.eType != appStop)
}
Boolean AppHandleEvent(pEventP)
{
// l'event est-il le chargement d'une form
if (pEventP->eType == frmLoadEvent)
{
// chargement de la form
FrmSetActiveForm(pEventP->data.frmLoad.frmP);
if (pEventP->data.frmLoad.frmID == RSC_FORMID_MAIN)
{
// chargement du gestionnaire spécifique de la form
/* MainFormHandleEvent fonction a definir */
FrmSetHandleEvent(RSC_FORMID_MAIN, MainFormHandleEvent);
//l'event a été traité
return true;
}
}
//l'event N'a PAS été traité
return false;
}
void AppStop()
{
// envoi un event frmSave à tous les gestionnaires de form actif
FrmSaveAllForm();
// envoi un event frmClose à tous les gestionnaires de form actif
FrmCloseAllForm();
//fermeta database ici si tu as besoin
//fonctions de DataBase Manager (Ex: DmCloseDatabase)
//Autres fermeture possibles: le DIA, les préférences, la comm, les librairies...)
}
Voila pour le main le code est pratiquement toujours le même
Il manque le gestionnaire de la form en code
CITATION(mainform.c)
CODE
Boolean MainFormHandle(pEventP)
{
Boolean handled = false;
switch(pEvent->eType)
{
case frmOpenEvent:
FrmDrawForm(FrmGetActiveForm());
handled = true;
break;
case frmSaveEvent:
break;
case frmCloseEvent:
break;
}
return handled;
}
{
Boolean handled = false;
switch(pEvent->eType)
{
case frmOpenEvent:
FrmDrawForm(FrmGetActiveForm());
handled = true;
break;
case frmSaveEvent:
break;
case frmCloseEvent:
break;
}
return handled;
}
Et maintenant les resources, là si tu utilises PODS normalement il faut créer un fichier xrd avec l'outil fourni par PalmSource. Sinon si tu utilises PilRC comme tout bon linuxien il faut un fichier rcp comme celui-ci
CITATION(mainform.rcp)
CODE
FORM ID RSC_FORMID_MAIN
BEGIN
TITLE "Test"
LABEL "coucou" AUTOID
END
BEGIN
TITLE "Test"
LABEL "coucou" AUTOID
END
Bon il y a beaucoup de chose à rajouter, il y beaucoup d'erreurs ici mais c'est juste un synoptique. Dès que j'aurais accès à mon ordi perso, je t'enverrais mes applis de base, celle avec laquelle je développe maintenant mes nouvelles applis. J'ai dit mes car j'ai une appli pour gérer une form sans database et une autre qui gère une database, avec une form listant les enregistrements, une form pour en visualisée un et une form pour en éditer un. En faite cette dernière est très proche de la toute première version de ExMail que tu peux avoir ici
En fait, si je comprends bien, toi-même tu pars de "templates" que tu ré-utilises à chaque fois que tu commences une nouvelle application ?
Un "template" pour application avec D.B., un autre pour les applications sans D.B.
Je sais, je me décourage vite, Corto, mais je suis "très lent à la comprenure", comme on dit ici en Belgique.
Dans mes études actuelles en informatique, je dois travailler beaucoup plus que les autres pour comprendre des choses que mes collègues assimilent plus vite. C'est comme ça, on est comme on est.
Et, bien que comprenant l'anglais, je suis assez décu du manque d'explications et de tutoriels en général concernant PODS.
Peut-être que cela va venir...
Mon projet de Travail de Fin d'étude devrait comporter un lien avec un palm, c'est pas obligé, mais ce serait bien, mais au rythme où j'apprends, je crois que je ferais une impasse là-dessus.
Je suis occupé à apprendre GTK sous Linux, c'est dur aussi, mais là, je progresse au moins grâce à plein d'explications trouvées sur le net, et à deux bouquins...
Donc, oui, je trouve ça dur le palm, par manque de références et d'exemples clairs...
Donc, oui, pour te répondre, je suis interessé par tes templates...
Un "template" pour application avec D.B., un autre pour les applications sans D.B.
Je sais, je me décourage vite, Corto, mais je suis "très lent à la comprenure", comme on dit ici en Belgique.
Dans mes études actuelles en informatique, je dois travailler beaucoup plus que les autres pour comprendre des choses que mes collègues assimilent plus vite. C'est comme ça, on est comme on est.
Et, bien que comprenant l'anglais, je suis assez décu du manque d'explications et de tutoriels en général concernant PODS.
Peut-être que cela va venir...
Mon projet de Travail de Fin d'étude devrait comporter un lien avec un palm, c'est pas obligé, mais ce serait bien, mais au rythme où j'apprends, je crois que je ferais une impasse là-dessus.
Je suis occupé à apprendre GTK sous Linux, c'est dur aussi, mais là, je progresse au moins grâce à plein d'explications trouvées sur le net, et à deux bouquins...
Donc, oui, je trouve ça dur le palm, par manque de références et d'exemples clairs...
Donc, oui, pour te répondre, je suis interessé par tes templates...
Ne l'écoute pas, calogerogigante, et passe sur HB++. Tu verras, c'est simple et facile! 
[TROLL]
HB++, c'est quoi çà.
Ah ouai je me souviens un joujou à la Visual Basic.
Si tu es étudiant en info, c'est que tu veux être professionnel, il faut alors utiliser des outils de professionnel.
[/TROLL]
Avis perso et sans rigolade, si tu apprends l'informatique, alors travaille avec des langages que tu utiliseras quand tu travailleras, entre autre le C, le C++, le Java, pour le développement applicatif, le PHP, le Perl, le Basic pour le développement internet. Fait ton choix.
HB++, c'est quoi çà.
Ah ouai je me souviens un joujou à la Visual Basic.
Si tu es étudiant en info, c'est que tu veux être professionnel, il faut alors utiliser des outils de professionnel.
[/TROLL]
Avis perso et sans rigolade, si tu apprends l'informatique, alors travaille avec des langages que tu utiliseras quand tu travailleras, entre autre le C, le C++, le Java, pour le développement applicatif, le PHP, le Perl, le Basic pour le développement internet. Fait ton choix.
Et ne pas oublier le non moins excellent iziBasic : aldweb.com
Pour le trolling :P...
... Je vais plutôt répondre à ça :
1.
Je ne crois pas que l'approche "on n'apprend que ce que l'on va utiliser plus tard en travaillant" soit vraiment valable. Plus généralement, l'éducation/l'enseignement ne doit pas être la p*** du marché du travail. Par exemple, c'est à mon avis une erreur d'enseigner l'informatique aux débutants avec des langages comme C - d'expérience, les étudiants qui commencent passent leur temps à se poser des questions de forme comme "comment j'alloue mon tableau" ou "je fais comment pour libérer la mémoire de cette structure" ou "ça compile pas" au lieu de se concentrer sur l'essentiel et sur le principe d'un algorithme. Et il faut sans cesse mentir, simplifier, ne pas entrer dans les détails ou bien dire des "Dans un premier temps, on va écrire ceci, on comprendra plus tard pourquoi". Un peu comme les dizaines de lignes de C que tu as postées. Tu trouves ça normal que quand tu débutes, tu aies à faire autant de suppositions et avaler autant de trucs qui ne paraissent pas naturel ? Je ne dis pas qu'il faut cesser d'enseigner C, c'est juste que le prétexte "c'est ce qu'ils utiliseront plus tard" n'est pas suffisant pour en faire le langage de tout l'enseignement.
J'ai appris l'informatique avec Scheme que j'utilise très peu maintenant mais je ne pense pas que ça a été une perte de temps, tout au contraire. Ca ne m'a peut être pas appris à "programmer profesionnellement", mais ça m'a appris à penser. De la même façon, un débutant en programmation PalmOS utilisant C risque de se concentrer à fond sur l'effort de programmation, sans réfléchir aux problèmes de conception, d'ergonomie et de philosophie très différents du monde PC. En réduisant l'effort de programmation et en laissant l'esprit pour réfléchir à la conception / à l'ergonomie, les outils RAD (que ce soit HB++, NsBasic, MobileVB) ou les outils onboard (pocketC, iziBasic, pp) peuvent être très instructifs.
Avis perso à calogerogigante : si tu apprends l'informatique, n'hésite pas à te forger tes premières armes sur des outils simplifiés synthétisant la philosophie de ce que tu dois apprendre. Peut-être ne collent-ils pas à une réalité professionnelle, mais ils t'offrent un modèle avec lequel tu peux réfléchir, comprendre et apprendre.
2.
Il y a une différence entre "apprendre le C" et "apprendre le modèle de programmation et les API PalmOS". On peut très bien être professionnel sans avoir fait l'effort d'apprendre toutes les API C existantes.
Peut-être même que calogerogigante connaît déjà très bien le C ? Et qu'il galère juste avec le modèle de programmation PalmOS ?
"Etre programmeur professionnel utilisant C quotidiennement" et "Ne pas se casser la tête à apprendre des nouvelles API ou utiliser des API barbares alors qu'un outil RAD offre les mêmes résultats en quelques lignes de code" ne sont pas si incompatibles que tu ne le crois.
Avis perso à calogerogigante : si tu apprends l'informatique, dis toi que le domaine est vaste et que tes possibilités d'apprentissage sont limitées. Investis ton temps d'apprentissage pour le long terme (apprends des algorithmes, des théories, des modèles) et non le court terme (n'apprends des API complexes et spécifiques qu'en cas de nécessité).
3.
Visual Basic est le langage le plus utilisé dans le monde (en perte de vitesse devant java, je le concède). Et il y a des dizaines de milliers de PDA sur lesquelles tournent des versions en production d'applications professionnelles HB++ (dans le milieu médical en particulier).
L'informatique professionnelle ne se limite pas à l'écriture d'applications commerciales vendues ou distribuées au public - pour lequel C est le langage de choix. C'est (malheureusement diront certains) en très grande proportion des applications de saisie/stockage en DB/traitement/consultation/impression, applications pour le développement desquelles l'utilisation de C tourne au masochisme, et pour lesquelles les outils RAD ont été pensés.
4.
Enfin, il me semble un peu inapproprié de véhiculer l'image du professionnel qui "utilise un outil de professionnel". Si j'étais recruteur dans une boîte développant des logiciels professionnels, et que j'avais à choisir entre un ayatollah du C, aussi fort soit-il, ou quelqu'un moins doué mais avec un profil mixte, l'ayatollah resterait sur la touche.
Avis perso à calogerogigante : si tu apprends l'informatique, alors adopte une démarche la plus ouverte possible et ne dénigre aucun langage. Le professionnel est celui qui connaît le maximum d'outils et qui sait choisir celui qui est le plus adapté à la tâche qu'il doit réaliser.
CITATION
Avis perso et sans rigolade, si tu apprends l'informatique, alors travaille avec des langages que tu utiliseras quand tu travailleras, entre autre le C, le C++, le Java, pour le développement applicatif, le PHP, le Perl, le Basic pour le développement internet. Fait ton choix.
... Je vais plutôt répondre à ça :
1.
Je ne crois pas que l'approche "on n'apprend que ce que l'on va utiliser plus tard en travaillant" soit vraiment valable. Plus généralement, l'éducation/l'enseignement ne doit pas être la p*** du marché du travail. Par exemple, c'est à mon avis une erreur d'enseigner l'informatique aux débutants avec des langages comme C - d'expérience, les étudiants qui commencent passent leur temps à se poser des questions de forme comme "comment j'alloue mon tableau" ou "je fais comment pour libérer la mémoire de cette structure" ou "ça compile pas" au lieu de se concentrer sur l'essentiel et sur le principe d'un algorithme. Et il faut sans cesse mentir, simplifier, ne pas entrer dans les détails ou bien dire des "Dans un premier temps, on va écrire ceci, on comprendra plus tard pourquoi". Un peu comme les dizaines de lignes de C que tu as postées. Tu trouves ça normal que quand tu débutes, tu aies à faire autant de suppositions et avaler autant de trucs qui ne paraissent pas naturel ? Je ne dis pas qu'il faut cesser d'enseigner C, c'est juste que le prétexte "c'est ce qu'ils utiliseront plus tard" n'est pas suffisant pour en faire le langage de tout l'enseignement.
J'ai appris l'informatique avec Scheme que j'utilise très peu maintenant mais je ne pense pas que ça a été une perte de temps, tout au contraire. Ca ne m'a peut être pas appris à "programmer profesionnellement", mais ça m'a appris à penser. De la même façon, un débutant en programmation PalmOS utilisant C risque de se concentrer à fond sur l'effort de programmation, sans réfléchir aux problèmes de conception, d'ergonomie et de philosophie très différents du monde PC. En réduisant l'effort de programmation et en laissant l'esprit pour réfléchir à la conception / à l'ergonomie, les outils RAD (que ce soit HB++, NsBasic, MobileVB) ou les outils onboard (pocketC, iziBasic, pp) peuvent être très instructifs.
Avis perso à calogerogigante : si tu apprends l'informatique, n'hésite pas à te forger tes premières armes sur des outils simplifiés synthétisant la philosophie de ce que tu dois apprendre. Peut-être ne collent-ils pas à une réalité professionnelle, mais ils t'offrent un modèle avec lequel tu peux réfléchir, comprendre et apprendre.
2.
Il y a une différence entre "apprendre le C" et "apprendre le modèle de programmation et les API PalmOS". On peut très bien être professionnel sans avoir fait l'effort d'apprendre toutes les API C existantes.
Peut-être même que calogerogigante connaît déjà très bien le C ? Et qu'il galère juste avec le modèle de programmation PalmOS ?
"Etre programmeur professionnel utilisant C quotidiennement" et "Ne pas se casser la tête à apprendre des nouvelles API ou utiliser des API barbares alors qu'un outil RAD offre les mêmes résultats en quelques lignes de code" ne sont pas si incompatibles que tu ne le crois.
Avis perso à calogerogigante : si tu apprends l'informatique, dis toi que le domaine est vaste et que tes possibilités d'apprentissage sont limitées. Investis ton temps d'apprentissage pour le long terme (apprends des algorithmes, des théories, des modèles) et non le court terme (n'apprends des API complexes et spécifiques qu'en cas de nécessité).
3.
Visual Basic est le langage le plus utilisé dans le monde (en perte de vitesse devant java, je le concède). Et il y a des dizaines de milliers de PDA sur lesquelles tournent des versions en production d'applications professionnelles HB++ (dans le milieu médical en particulier).
L'informatique professionnelle ne se limite pas à l'écriture d'applications commerciales vendues ou distribuées au public - pour lequel C est le langage de choix. C'est (malheureusement diront certains) en très grande proportion des applications de saisie/stockage en DB/traitement/consultation/impression, applications pour le développement desquelles l'utilisation de C tourne au masochisme, et pour lesquelles les outils RAD ont été pensés.
4.
Enfin, il me semble un peu inapproprié de véhiculer l'image du professionnel qui "utilise un outil de professionnel". Si j'étais recruteur dans une boîte développant des logiciels professionnels, et que j'avais à choisir entre un ayatollah du C, aussi fort soit-il, ou quelqu'un moins doué mais avec un profil mixte, l'ayatollah resterait sur la touche.
Avis perso à calogerogigante : si tu apprends l'informatique, alors adopte une démarche la plus ouverte possible et ne dénigre aucun langage. Le professionnel est celui qui connaît le maximum d'outils et qui sait choisir celui qui est le plus adapté à la tâche qu'il doit réaliser.
Avec tout le respect que je te dois, Corto, j'avoue que j'adhère totalement à la façon de voir de poolpy.
C'est tout à fait ça !!
Mais que cela ne crée pas de clivage ou de fossé entre nous, Corto !!
Ce n'est qu'un partage d'opinion et de point de vue !!
Amicalement !!
CITATION
Peut-être même que calogerogigante connaît déjà très bien le C ? Et qu'il galère juste avec le modèle de programmation PalmOS ?
C'est tout à fait ça !!
Mais que cela ne crée pas de clivage ou de fossé entre nous, Corto !!
Ce n'est qu'un partage d'opinion et de point de vue !!
Amicalement !!
J'applaudis à 2 mains (voire plus) le commentaire de Poolpy 8) .
Ce qu'il manque aux étudiants c'est de savoir faire de l'architecture logiciel, en sortant d'école vous êtes des nouveau-nés dans ce domaine. Or je pense que les langages de très bas niveau sont très bon pour çà, car il oblige à architecturer vos idées. Il est impossible de faire du bon boulot sans avoir mis à plat le fonctionnement de votre application avant d'avoir pissé la moindre ligne de code, je parle pour de gros projet, mais il faut commencer petit pour devenir grand.
Les langages de haut niveau permettent de développer rapidement sans passer par les phases de conception et d'architecture des applications (plus ou moins simple), mais rapidement quand le nombre de fonctionnalités que l'on veut rajouter au fur et à mesure, devient important, on tombe dans le piège des usines à gaz et de la tuyauterie trouée. Je ne dis pas que l'on ne peut pas faire d'appli sans tomber dans l'usine à gaz, au contraire, pour des applis simples se seraient plutot le contraire, mais la compléxité d'une appli se trouve limité à un moment par le langage utilisé.
Que cela soit le basic, le perl, le shell et autres langages de haut niveau, je les ai appris sur le tas en peu de temps, et dans certains de ces langages je pense être allé très loin. Par contre cela fait 11 ans que je fais du C et j'en apprend encore. Je ne parle pas du C++ et du Java qui sont tellement riche en possibilité d'architecture, que je ne suis pas sûr que quelqu'un est allé jusqu'au bout de ces langages, même leurs créateurs.
Et puis c'est en forgeant que l'on devient forgeron.
Si vous vous contentez de faire des opinels, vous ne ferez jamais une épée.
Les langages de haut niveau permettent de développer rapidement sans passer par les phases de conception et d'architecture des applications (plus ou moins simple), mais rapidement quand le nombre de fonctionnalités que l'on veut rajouter au fur et à mesure, devient important, on tombe dans le piège des usines à gaz et de la tuyauterie trouée. Je ne dis pas que l'on ne peut pas faire d'appli sans tomber dans l'usine à gaz, au contraire, pour des applis simples se seraient plutot le contraire, mais la compléxité d'une appli se trouve limité à un moment par le langage utilisé.
Que cela soit le basic, le perl, le shell et autres langages de haut niveau, je les ai appris sur le tas en peu de temps, et dans certains de ces langages je pense être allé très loin. Par contre cela fait 11 ans que je fais du C et j'en apprend encore. Je ne parle pas du C++ et du Java qui sont tellement riche en possibilité d'architecture, que je ne suis pas sûr que quelqu'un est allé jusqu'au bout de ces langages, même leurs créateurs.
Et puis c'est en forgeant que l'on devient forgeron.
Si vous vous contentez de faire des opinels, vous ne ferez jamais une épée.
On peut discuter des heures sur les mérites comparés des langages mais je m'en tiendrais à un point : pourquoi apprendre la programmation avec du C et pas avec du basic...
Parce qu'apprendre l'algorithmique c'est très bien mais ce n'est pas de la programmation, c'est juste une branche des mathématiques. Et que la "vraie" programmation elle doit concilier les mathématiques avec le concret des machines qui sont à notre disposition. Les deux sont indispensables au développeur.
Et de ce point de vue "galérer" avec l'allocation mémoire (pour en rester à cet exemple) a une énorme vertu pédagogique car cela te montre comment fonctionne la gestion de la mémoire dans un programme. Si tu en restes à basic (voire à java, qui masque aussi beaucoup de choses), tu ne vas jamais comprendre comment fonctionne l'architecture mémoire d'une "vraie" bécane et tu vas écrire des programmes qui risquent de s'écrouler dans des conditions réelles. Apprendre la programmation, c'est aussi apprendre ça.
Et j'ai le regret de constater qu'aujourd'hui, je ne vois plus beaucoup de développeurs qui font le lien entre un programme et ce qui se passe au coeur de la machine. Ce qui aboutit à des programmes qui font ce qu'on leur demande de faire en conditions de tests mais qui ne tiennent pas la route en production (et j'en fais l'expérience assez régulièrement sur les projets que je pilote).
Evidemment tout ceci n'empêche pas de programmer en basic lorsque cela reste un hobby. Ou de choisir le langage le mieux adapté à un projet donné une fois que tu as appris à faire un choix en connaissance de cause.
Parce qu'apprendre l'algorithmique c'est très bien mais ce n'est pas de la programmation, c'est juste une branche des mathématiques. Et que la "vraie" programmation elle doit concilier les mathématiques avec le concret des machines qui sont à notre disposition. Les deux sont indispensables au développeur.
Et de ce point de vue "galérer" avec l'allocation mémoire (pour en rester à cet exemple) a une énorme vertu pédagogique car cela te montre comment fonctionne la gestion de la mémoire dans un programme. Si tu en restes à basic (voire à java, qui masque aussi beaucoup de choses), tu ne vas jamais comprendre comment fonctionne l'architecture mémoire d'une "vraie" bécane et tu vas écrire des programmes qui risquent de s'écrouler dans des conditions réelles. Apprendre la programmation, c'est aussi apprendre ça.
Et j'ai le regret de constater qu'aujourd'hui, je ne vois plus beaucoup de développeurs qui font le lien entre un programme et ce qui se passe au coeur de la machine. Ce qui aboutit à des programmes qui font ce qu'on leur demande de faire en conditions de tests mais qui ne tiennent pas la route en production (et j'en fais l'expérience assez régulièrement sur les projets que je pilote).
Evidemment tout ceci n'empêche pas de programmer en basic lorsque cela reste un hobby. Ou de choisir le langage le mieux adapté à un projet donné une fois que tu as appris à faire un choix en connaissance de cause.
Dans mon cas, pour mon TFE, c'est un rapport "vitesse de création / efficacité de ce qui est demandé" que je dois atteindre.
Je suis très conscient de ce que vous tentez d'expliquer, Patrice et Corto, sur la maitrise et la connaissance de ce qui se passe derrière un programme. Je suis d'accord avec vous.
Mais mon problème, c'est que je dois en très peu de temps maitriser GTK, l'api C MySQL, et LATEX pour mon Travail de Fin d'études....
Ces trois sujets sont essentiels à mon projet, et pour ça, trois mois, ça va déjà être short (je suis très lent !!) cf (***)
Alors, l'éventuel lien de mon application de gestion au palm est encore au stade de "possible si j'ai du temps pour y arriver"...
Si j'arrive à assimiler un mode de création de programme palm qui m'amène à une application rapide et fonctionnelle: oui, pour atteindre mon but scolaire, je choisirai celle-là.
En laissant pour plus tard la véritable prise en main de l'API palm natif.
(***) P.S.: je travaille à temps plein le jour, et mon graduat informatique a lieu en 3 années à raison de 3 soirs semaines de 17h30 à 21h30. Sans compter la vie de famille !
Je suis très conscient de ce que vous tentez d'expliquer, Patrice et Corto, sur la maitrise et la connaissance de ce qui se passe derrière un programme. Je suis d'accord avec vous.
Mais mon problème, c'est que je dois en très peu de temps maitriser GTK, l'api C MySQL, et LATEX pour mon Travail de Fin d'études....
Ces trois sujets sont essentiels à mon projet, et pour ça, trois mois, ça va déjà être short (je suis très lent !!) cf (***)
Alors, l'éventuel lien de mon application de gestion au palm est encore au stade de "possible si j'ai du temps pour y arriver"...
Si j'arrive à assimiler un mode de création de programme palm qui m'amène à une application rapide et fonctionnelle: oui, pour atteindre mon but scolaire, je choisirai celle-là.
En laissant pour plus tard la véritable prise en main de l'API palm natif.
(***) P.S.: je travaille à temps plein le jour, et mon graduat informatique a lieu en 3 années à raison de 3 soirs semaines de 17h30 à 21h30. Sans compter la vie de famille !
CITATION(poolpy)
3.
Visual Basic est le langage le plus utilisé dans le monde (en perte de vitesse devant java, je le concède). Et il y a des dizaines de milliers de PDA sur lesquelles tournent des versions en production d'applications professionnelles HB++ (dans le milieu médical en particulier).
Visual Basic est le langage le plus utilisé dans le monde (en perte de vitesse devant java, je le concède). Et il y a des dizaines de milliers de PDA sur lesquelles tournent des versions en production d'applications professionnelles HB++ (dans le milieu médical en particulier).
Vrai
CITATION(poolpy)
L'informatique professionnelle ne se limite pas à l'écriture d'applications commerciales vendues ou distribuées au public - pour lequel C est le langage de choix. C'est (malheureusement diront certains) en très grande proportion des applications de saisie/stockage en DB/traitement/consultation/impression, applications pour le développement desquelles l'utilisation de C tourne au masochisme, et pour lesquelles les outils RAD ont été pensés.
A moitié vrai : en C sous PalmOS, on peut utiliser Sqlite, un moteur de base de données opensource qui peut etre intégré dans une appli. On interroge ensuite la base en SQL pur et dur
Ensuite, certains IDE pour PalmOS proposent des bibliothèques de gestion de données évoluées et très bien faites : Falch.Net Developper Studio par exemple.
Pour avoir programmé en VB et en C à l'IUT, j'ai pu comparer les deux langages pour des applis un peu évoluées . Pour moi, il n'y a pas photo entre le C et le VB : vive le C !
Je programmais sous Windows. En VB, la gestion mémoire était hasardeuse, alors qu'un programme écrit en C correct avait une gestion mémoire beaucoup plus propre.
J'avais commencé la programmation avant d'entrer à l'IUT avec du turbo pascal. A l'IUT, on travaillait en Pascal IBM pendant les TD d'algo. Ce langage a l'avantage d'etre proche du langage algorithmique. Je le conseille pour l'enseignement d'ailleurs, car le passage au C n'est pas trop douloureux à faire ensuite.
J'ai essayé HB++ ... Ben euh :-?
Je préfère largement FNDS parce que j'ai une allergie au VB probablement
La rapidité de développement n'est qu'une facade. Pour des applications simples, je pense qu'elle est valable. Encore que, avec les squelettes d'applications, je produit un hello world en 2 minutes avec FNDS.
Pour des applications évoluées, je ne pense pas que HB++ ait l'avantage, mais je peux me tromper ...
Pour conclure, je dirais qu'il n'y a pas de mauvais outils, juste des mauvais ouvriers.
Sujet divisé car on commençait à s'éloigner singulièrement de "PODS 1.1"
CITATION(Patrice)
Et de ce point de vue "galérer" avec l'allocation mémoire (pour en rester à cet exemple) a une énorme vertu pédagogique car cela te montre comment fonctionne la gestion de la mémoire dans un programme. Si tu en restes à basic (voire à java, qui masque aussi beaucoup de choses), tu ne vas jamais comprendre comment fonctionne l'architecture mémoire d'une "vraie" bécane et tu vas écrire des programmes qui risquent de s'écrouler dans des conditions réelles. Apprendre la programmation, c'est aussi apprendre ça.
Entièrement vrai, et à titre d'exemple, je peux citer un problème que j'ai actuellement. Au boulot, je travaille avec un annuaire LDAP capable de supporter près de 1000 connexions/seconde lorsque que les requêtes sont bien écrites.
Ces derniers temps, la plate-forme passait dans le rouge car une seule requête mal écrite (parcourant toute la hiérarchie pour un objet non indexé) consommait énormément de CPU. Il suffit de seulement une vingtaine de requêtes de ce type pour faire 'tomber' des quadri-pro équipé de 4 Go de RAM 8O
Comprendre le fonctionnement des outils utilisés est donc primordial dans l'informatique professionnelle. Il est facile de dire qu'un micro n'est pas assez puissant et d'en imposer le changement aux particuliers. C'est bien plus délicat dans le cadre de projet d'entreprise !
CITATION(Patrice)
Et de ce point de vue "galérer" avec l'allocation mémoire (pour en rester à cet exemple) a une énorme vertu pédagogique car cela te montre comment fonctionne la gestion de la mémoire dans un programme. Si tu en restes à basic (voire à java, qui masque aussi beaucoup de choses), tu ne vas jamais comprendre comment fonctionne l'architecture mémoire d'une "vraie" bécane et tu vas écrire des programmes qui risquent de s'écrouler dans des conditions réelles. Apprendre la programmation, c'est aussi apprendre ça.
Dans ce cas la, l'interet se limite justement à l'apprentissage ! Le C permet de controler parfaitement ce qu'on fait, ce qui peu être très intéressant dans certains cas precis mais n'a que peut d'interet dans la majorité des programmes. Pire en C, la memoire est (peut être) légérement économisée et mieux controlée mais elle est source d'erreurs ( en conditions réelles comme tu le dis ). Beaucoup de programme en C fonctionne bien dans 95% des cas et plantent lamentablement lors d'une suite d'actions non prévues lors du développement et des tests ! Même en faisant attention et en ayant une grande expérience, le risque de plantage lié à la memoire est bien supérieur en C qu'en Basic.
Evidemment le C est indispensable dans des situations bien précise et je l'utilise d'ailleur beaucoup ...
Salut,
Le sujet est HB++ ou C?
Je commence serieusement a en avoir ras la casquette des a prioris genre, c'est du VB like, donc pas bien. HB++ est un compilateur, comme GCC ou CW, il genere donc du code compile, rapide et efficace.
Il n'y a que le resultat qui compte! Que vaut il mieux? galerer pendant des des semaines sur un projet (exemple , <Troll> fallait pas me chercher!</troll>), avoir des bugs a n'en plus finir, ne pas atteindre son but, mais c'est pas grave, on aura pondu des milliers de lignes de C, alors tout va bien.
Certes, plus on programme bas niveau, plus on devrait avoir des connaissances etendues sur les internals. Ce n'est pas souvent le cas, et on voit plein de programmeurs C sortir des applications qui offrent plus d'erreur fatales que de fonctionnalites. Comme le dit brillamment poolpy, il vaut mieux se concentrer sur la fonctionalite que sur le moyen. C'est pour cela que nous avons creer HB++. Nous, on s'occupe des moyens, le programmeur s'occupe de la fonctionnalite. Rien a f****e de savoir que MemhandleLock ou pas, je m'en tamponne, je veux afficher un texte!!! Rien a faire de savoir que tel ou tel truc a change entre PalmOS 3.5 et 4.1.2, je veux que ca marche!
En plus, HB++ permet d'appeler directement les API, ce qui permet de ne pas se limiter a notre class library, cependant est tres puissante.
Concernant le cote professionnel ou pas, une bonne partie de nos clients sont des professionnels. Ils ont choisi HB++ parce que cela leur permettait de travailler vite et bien. Ils produisent des applis pro, et ont des obligations de resultats, dans des delais fixés. Une autre partie est developpeur shareware/freeware et veulent aussi se concentrer sur le but plutot que sur les moyens.
JPA
The HB++ team
Le sujet est HB++ ou C?
Je commence serieusement a en avoir ras la casquette des a prioris genre, c'est du VB like, donc pas bien. HB++ est un compilateur, comme GCC ou CW, il genere donc du code compile, rapide et efficace.
Il n'y a que le resultat qui compte! Que vaut il mieux? galerer pendant des des semaines sur un projet (exemple , <Troll> fallait pas me chercher!</troll>), avoir des bugs a n'en plus finir, ne pas atteindre son but, mais c'est pas grave, on aura pondu des milliers de lignes de C, alors tout va bien.
Certes, plus on programme bas niveau, plus on devrait avoir des connaissances etendues sur les internals. Ce n'est pas souvent le cas, et on voit plein de programmeurs C sortir des applications qui offrent plus d'erreur fatales que de fonctionnalites. Comme le dit brillamment poolpy, il vaut mieux se concentrer sur la fonctionalite que sur le moyen. C'est pour cela que nous avons creer HB++. Nous, on s'occupe des moyens, le programmeur s'occupe de la fonctionnalite. Rien a f****e de savoir que MemhandleLock ou pas, je m'en tamponne, je veux afficher un texte!!! Rien a faire de savoir que tel ou tel truc a change entre PalmOS 3.5 et 4.1.2, je veux que ca marche!
En plus, HB++ permet d'appeler directement les API, ce qui permet de ne pas se limiter a notre class library, cependant est tres puissante.
Concernant le cote professionnel ou pas, une bonne partie de nos clients sont des professionnels. Ils ont choisi HB++ parce que cela leur permettait de travailler vite et bien. Ils produisent des applis pro, et ont des obligations de resultats, dans des delais fixés. Une autre partie est developpeur shareware/freeware et veulent aussi se concentrer sur le but plutot que sur les moyens.
JPA
The HB++ team
JPA, tu as l'air de te sentir agressé alors que je n'en vois pas la raison. Et du coup, tes propos perdent en objectivité... :?
A corto :
Je crois qu'on ne voit pas ça de la même façon : en apprenant à programmer avec un langage de bas niveau, on passe son temps à régler des problèmes de programmation et d'implémentation. En programmant avec des langages de haut-niveau, on se repose sur des classes, et on a l'esprit libre pour penser architecture 8).
Je n'ai jamais dit qu'un langage de haut niveau dispensait d'architecturer. Au contraire ! Encore une fois, mon propos (résumé) est le suivant :
"Un langage de haut-niveau débarasse le programmeur de tout un tas de tâches superflues qui peuvent l'induire en erreur, et lui permet de se concentrer sur l'architecture et sur la résolution des problèmes".
:!: Tu aurais pu mettre [TROLL] autour de ce commentaire, ça m'aurait évité d'y répondre...
[TROLL]
Parce qu'au fond, tu reproches au programmeur HB++ de se reposer sur une librairie de classes et d'ignorer ce qu'il y a en dessous ? Tu lui reproches de se la jouer facile avec un langage qui fait tout pour lui ? Tu lui reproches de fermer les yeux sur les mystérieux mystères de PalmOS et de tout ce qu'il peut nous apporter, et nous apprendre ?
Alors va au bout ! Ne te repose pas sur cette librairie de fonctions qu'est PalmOS ! Ne te la joue pas facile avec les commodités du C ! Ouvre les yeux sur les mystères de la machine ! Code en assembleur et adresse directement le hardware !
Si vous vous contentez de faire des épées, vous ne ferez jamais de sabres lasers !
[/TROLL]
A Patrice :
Alors ne crois-tu pas que les langages de programmation doivent se rapprocher au plus près des mathématiques et d'un modèle formel de la machine ? Entre un LISP ou un ML et C, lequel est le plus proche des mathématiques ?
Tu sembles souligner une dichotomie entre, d'une part, le concret de la machine, et les mathématiques - ce qui selon toi justifie l'enseignement de C par rapport aux langages de haut-niveau, puisqu'il ne faut pas délaisser le côté machine.
Il me semble que dès lors qu'un programme est écrit dans un langage pour lequel est diponsible un modèle d'exécution formel (Les familles de LISP ou ML en ont, la plupart des langages sans pointeurs peuvent en avoir, bien qu'ils sont complexes et rarement efficacement utilisables), le gap entre sa sémantique ("les mathématiques") et l'implémentation ("le concret de la machine") peut être facilement comblé. En témoignent les performances excellentes des compilateurs LISP ou ML.
Il est vrai que sur ce point deux approches sont possibles :
- Le programmeur écrit ce que l'ordinateur doit faire. Auquel cas, le langage de programmation doit permettre d'aller dans "le concret de la machine", et il est bon que le programmeur connaisse ce concret.
- Le programmeur décrit ce que l'ordinateur doit faire. Auquel cas, le langage de programmation doit permettre au programmeur de s'exprimer à un très haut niveau, en utilisant le plus d'abstractions possibles, de manière à ce que le compilateur puisse au mieux comprendre ce qu'il doit produire.
Je pense que ta conception de la programmation correspond à la première approche, et que la mienne correspond à la seconde.
Je pense également (mais c'est mon humble avis), que l'avenir de la programmation est dans la deuxième approche, et que dans un monde :P idéal :P, un programmeur ne doit pas avoir à se soucier de ce qui se passe dans la machine.
D'un point de vue purement pédagogique, crois-tu que devoir se soucier de tous les détails d'implémentation (par exemple, comment représenter un graphe, des ensembles) permet aux étudiants d'avoir une pensée "mathématique" ? J'en doute.
Quand un algorithme tient en dix lignes de Scheme (ou de Caml, ou de Haskell), en utilisant des fonctions de haut niveau, des ensembles, des vecteurs, et quand son équivalent en C en fait quatre-vingt et utilise à tout bout de champ des boucles, des structures et des champs de bits pour représenter les ensembles, lequel des deux est le meilleur support à la réflexion de l'étudiant ?
Je ne suis pas d'accord sur deux points.
- D'abord, nous parlons d'apprendre l'algorithmique, pas la programmation, et tu as toi même souligné la différence. Mon expérience m'a appris qu'il est souhaitable de dissocier les deux, de manière à ce que l'étudiant ne confonde pas l'un pour l'autre, et que l'un ne soit pas un obstacle à l'apprentissage de l'autre.
J'ai deux profils en tête.
* Profil 1 : l'étudiant excellent en mathématique, très fin lorsqu'il s'agit de raisonner sur des graphes, de démontrer des propriétés sur un algorithme, etc. mais nul en programmation, à qui on est malheureusement obligé de mettre des mauvaises notes parce qu'il n'arrive pas à formuler ses idées en C.
* Profil 2 : l'étudiant qui confond "améliorer un algorithme" avec "améliorer une implémentation". Ceux là sont les "gourous" qui optimisent comme des malades une implémentation C (parfois avec de l'assembleur) d'un algorithme pourri.
- Ensuite, ta volonté d'embrasser dans une seule pensée le fonctionnement entier de la machine, du microprocesseur à ton programme, est certes louable, mais selon moi dépassée. Un intellectuel de la renaissance pouvait prétendre tout saisir des mathématiques de son époque, un mathématicien d'aujourd'hui doit se spécialiser. De même, jusque dans les années 1990, le champs de l'informatique était suffisament restreint pour qu'une même personne puisse se faire une idée complète du fonctionnement de sa machine, depuis le programme écrit dans un langage de haut niveau jusqu'à l'architecture du micro-processeur. Désormais, le fonctionnement des processeurs est suffisament complexe (contraintes de cache, d'interlocking, de pipelining, de canaux d'exécution parallèles) pour qu'on accepte que seuls les concepteurs de compilateurs doivent s'en soucier. Je pense que nous sommes entrés dans une époque où il n'est plus raisonnable pour un programmeur non système de se soucier des détails d'implémentation. Tous les programmes seront bientôt écrits dans des langages aux librairies de fonctions extrêmement riches et évoluées, et l'implémentation de ces librairies sera affaire de spécialistes.
Je vais prendre un autre exemple "pédagogie"... Les étudiants apprennent la gestion des fichiers, les structures de données, l'implémentation des algorithmes de tri, de recherche, etc. Ensuite, on leur dit : "C'est toute cette théorie qui a fait naître les moteurs de bases de données - qui bien entendu ont bénéficiés de milliers d'amélioration et de recherche très spécialisée". Et avec notre bénédiciton, l'étudiant peut par la suite utiliser les libs mySQL dans ses projets.
Je ne vois pas pourquoi il serait interdit d'apprendre à un étudiant le fonctionnement de l'allocation mémoire, de lui expliquer comment fonctionne un garbage collector, et de lui dire avec notre bénédiction, "Tu peux maintenant utiliser Boehm ou un langage avec garbage-collection et allocation automatique".
A moins que tu ne vois une différence fondamentale entre les deux ?
A SteC:
Tu le dis toi même : le problème ne vient pas du langage de programmation utilisé mais d'une mauvaise implémentation / d'un mauvais choix de structures de données.
Un mauvais programmeur C ou un mauvais programmeur d'un langage de haut niveau aurait pu faire la même erreur. Cela ne plaide pas en la faveur du C, mais soutient juste qu'il est nécessaire de renforcer l'enseignement de l'algorithmique par rapport à celui de la programmation.
Je ne vais pas m'y risquer, mais on pourrait même aller jusqu'à dire que C est coupable, puisqu'il détourne les étudiants de la compréhension des algorithmes.
Ce qui est assez amusant, c'est qu'il est maintenant parfaitement bien accepté de ne plus laisser au programmeur le choix des instructions machines pour son programme, et de déléguer ce choix au logiciel (le compilateur). Par contre, la communauté est très divisée sur la question de la l'allocation mémoire : beaucoup pensent qu'elle doit être encore laissée au programmeur, et que la déléguer au logiciel (le garbage collector) est une abberration. Alors que la perte de performances n'est pas significative, et que les gains en fiabilité sont importants.
Quelqu'un a-t-il une explication à cela ?
Oui, C fait abstraction des différences de CPU entre machines, mais pas des différences d'OS - c'est un autre avantage des langages de haut-niveau, puisqu'ils encapsulent dans leurs librairies de classes les différences entre OS ou versions de l'OS.
CITATION
Les langages de haut niveau permettent de développer rapidement sans passer par les phases de conception et d'architecture des applications (plus ou moins simple)
Je crois qu'on ne voit pas ça de la même façon
: en apprenant à programmer avec un langage de bas niveau, on passe son temps à régler des problèmes de programmation et d'implémentation. En programmant avec des langages de haut-niveau, on se repose sur des classes, et on a l'esprit libre pour penser architecture 8).
CITATION
car il oblige à architecturer vos idées
Je n'ai jamais dit qu'un langage de haut niveau dispensait d'architecturer. Au contraire !
Encore une fois, mon propos (résumé) est le suivant :
"Un langage de haut-niveau débarasse le programmeur de tout un tas de tâches superflues qui peuvent l'induire en erreur, et lui permet de se concentrer sur l'architecture et sur la résolution des problèmes".
CITATION
Et puis c'est en forgeant que l'on devient forgeron.
Si vous vous contentez de faire des opinels, vous ne ferez jamais une épée.
Si vous vous contentez de faire des opinels, vous ne ferez jamais une épée.
:!: Tu aurais pu mettre [TROLL] autour de ce commentaire, ça m'aurait évité d'y répondre...
[TROLL]
Parce qu'au fond, tu reproches au programmeur HB++ de se reposer sur une librairie de classes et d'ignorer ce qu'il y a en dessous ? Tu lui reproches de se la jouer facile avec un langage qui fait tout pour lui ? Tu lui reproches de fermer les yeux sur les mystérieux mystères de PalmOS et de tout ce qu'il peut nous apporter, et nous apprendre ?
Alors va au bout ! Ne te repose pas sur cette librairie de fonctions qu'est PalmOS ! Ne te la joue pas facile avec les commodités du C ! Ouvre les yeux sur les mystères de la machine ! Code en assembleur et adresse directement le hardware !
Si vous vous contentez de faire des épées, vous ne ferez jamais de sabres lasers !
[/TROLL]
A Patrice :
CITATION
Parce qu'apprendre l'algorithmique c'est très bien mais ce n'est pas de la programmation, c'est juste une branche des mathématiques. Et que la "vraie" programmation elle doit concilier les mathématiques avec le concret des machines qui sont à notre disposition. Les deux sont indispensables au développeur.
Alors ne crois-tu pas que les langages de programmation doivent se rapprocher au plus près des mathématiques et d'un modèle formel de la machine ? Entre un LISP ou un ML et C, lequel est le plus proche des mathématiques ?
Tu sembles souligner une dichotomie entre, d'une part, le concret de la machine, et les mathématiques - ce qui selon toi justifie l'enseignement de C par rapport aux langages de haut-niveau, puisqu'il ne faut pas délaisser le côté machine.
Il me semble que dès lors qu'un programme est écrit dans un langage pour lequel est diponsible un modèle d'exécution formel (Les familles de LISP ou ML en ont, la plupart des langages sans pointeurs peuvent en avoir, bien qu'ils sont complexes et rarement efficacement utilisables), le gap entre sa sémantique ("les mathématiques") et l'implémentation ("le concret de la machine") peut être facilement comblé. En témoignent les performances excellentes des compilateurs LISP ou ML.
Il est vrai que sur ce point deux approches sont possibles :
- Le programmeur écrit ce que l'ordinateur doit faire. Auquel cas, le langage de programmation doit permettre d'aller dans "le concret de la machine", et il est bon que le programmeur connaisse ce concret.
- Le programmeur décrit ce que l'ordinateur doit faire. Auquel cas, le langage de programmation doit permettre au programmeur de s'exprimer à un très haut niveau, en utilisant le plus d'abstractions possibles, de manière à ce que le compilateur puisse au mieux comprendre ce qu'il doit produire.
Je pense que ta conception de la programmation correspond à la première approche, et que la mienne correspond à la seconde.
Je pense également (mais c'est mon humble avis), que l'avenir de la programmation est dans la deuxième approche, et que dans un monde :P idéal :P, un programmeur ne doit pas avoir à se soucier de ce qui se passe dans la machine.
D'un point de vue purement pédagogique, crois-tu que devoir se soucier de tous les détails d'implémentation (par exemple, comment représenter un graphe, des ensembles) permet aux étudiants d'avoir une pensée "mathématique" ? J'en doute.
Quand un algorithme tient en dix lignes de Scheme (ou de Caml, ou de Haskell), en utilisant des fonctions de haut niveau, des ensembles, des vecteurs, et quand son équivalent en C en fait quatre-vingt et utilise à tout bout de champ des boucles, des structures et des champs de bits pour représenter les ensembles, lequel des deux est le meilleur support à la réflexion de l'étudiant ?
CITATION
Apprendre la programmation, c'est aussi apprendre ça.
Je ne suis pas d'accord sur deux points.
- D'abord, nous parlons d'apprendre l'algorithmique, pas la programmation, et tu as toi même souligné la différence. Mon expérience m'a appris qu'il est souhaitable de dissocier les deux, de manière à ce que l'étudiant ne confonde pas l'un pour l'autre, et que l'un ne soit pas un obstacle à l'apprentissage de l'autre.
J'ai deux profils en tête.
* Profil 1 : l'étudiant excellent en mathématique, très fin lorsqu'il s'agit de raisonner sur des graphes, de démontrer des propriétés sur un algorithme, etc. mais nul en programmation, à qui on est malheureusement obligé de mettre des mauvaises notes parce qu'il n'arrive pas à formuler ses idées en C.
* Profil 2 : l'étudiant qui confond "améliorer un algorithme" avec "améliorer une implémentation". Ceux là sont les "gourous" qui optimisent comme des malades une implémentation C (parfois avec de l'assembleur) d'un algorithme pourri.
- Ensuite, ta volonté d'embrasser dans une seule pensée le fonctionnement entier de la machine, du microprocesseur à ton programme, est certes louable, mais selon moi dépassée. Un intellectuel de la renaissance pouvait prétendre tout saisir des mathématiques de son époque, un mathématicien d'aujourd'hui doit se spécialiser. De même, jusque dans les années 1990, le champs de l'informatique était suffisament restreint pour qu'une même personne puisse se faire une idée complète du fonctionnement de sa machine, depuis le programme écrit dans un langage de haut niveau jusqu'à l'architecture du micro-processeur. Désormais, le fonctionnement des processeurs est suffisament complexe (contraintes de cache, d'interlocking, de pipelining, de canaux d'exécution parallèles) pour qu'on accepte que seuls les concepteurs de compilateurs doivent s'en soucier. Je pense que nous sommes entrés dans une époque où il n'est plus raisonnable pour un programmeur non système de se soucier des détails d'implémentation. Tous les programmes seront bientôt écrits dans des langages aux librairies de fonctions extrêmement riches et évoluées, et l'implémentation de ces librairies sera affaire de spécialistes.
Je vais prendre un autre exemple "pédagogie"... Les étudiants apprennent la gestion des fichiers, les structures de données, l'implémentation des algorithmes de tri, de recherche, etc. Ensuite, on leur dit : "C'est toute cette théorie qui a fait naître les moteurs de bases de données - qui bien entendu ont bénéficiés de milliers d'amélioration et de recherche très spécialisée". Et avec notre bénédiciton, l'étudiant peut par la suite utiliser les libs mySQL dans ses projets.
Je ne vois pas pourquoi il serait interdit d'apprendre à un étudiant le fonctionnement de l'allocation mémoire, de lui expliquer comment fonctionne un garbage collector, et de lui dire avec notre bénédiction, "Tu peux maintenant utiliser Boehm ou un langage avec garbage-collection et allocation automatique".
A moins que tu ne vois une différence fondamentale entre les deux ?
A SteC:
CITATION
Ces derniers temps, la plate-forme passait dans le rouge car une seule requête mal écrite (parcourant toute la hiérarchie pour un objet non indexé) consommait énormément de CPU. Il suffit de seulement une vingtaine de requêtes de ce type pour faire 'tomber' des quadri-pro équipé de 4 Go de RAM Choqué
Tu le dis toi même : le problème ne vient pas du langage de programmation utilisé mais d'une mauvaise implémentation / d'un mauvais choix de structures de données.
Un mauvais programmeur C ou un mauvais programmeur d'un langage de haut niveau aurait pu faire la même erreur. Cela ne plaide pas en la faveur du C, mais soutient juste qu'il est nécessaire de renforcer l'enseignement de l'algorithmique par rapport à celui de la programmation.
Je ne vais pas m'y risquer, mais on pourrait même aller jusqu'à dire que C est coupable, puisqu'il détourne les étudiants de la compréhension des algorithmes.
CITATION
Beaucoup de programme en C fonctionne bien dans 95% des cas et plantent lamentablement lors d'une suite d'actions non prévues lors du développement et des tests ! Même en faisant attention et en ayant une grande expérience, le risque de plantage lié à la memoire est bien supérieur en C qu'en Basic.
Ce qui est assez amusant, c'est qu'il est maintenant parfaitement bien accepté de ne plus laisser au programmeur le choix des instructions machines pour son programme, et de déléguer ce choix au logiciel (le compilateur). Par contre, la communauté est très divisée sur la question de la l'allocation mémoire : beaucoup pensent qu'elle doit être encore laissée au programmeur, et que la déléguer au logiciel (le garbage collector) est une abberration. Alors que la perte de performances n'est pas significative, et que les gains en fiabilité sont importants.
Quelqu'un a-t-il une explication à cela ?
CITATION
Rien a faire de savoir que tel ou tel truc a change entre PalmOS 3.5 et 4.1.2, je veux que ca marche!
Oui, C fait abstraction des différences de CPU entre machines, mais pas des différences d'OS - c'est un autre avantage des langages de haut-niveau, puisqu'ils encapsulent dans leurs librairies de classes les différences entre OS ou versions de l'OS.
Poolpy, désolé je n'ai pas le courage de tout lire. Mais sur ce que j'ai lu, j'ai 2 remarques :
1) Ce que j'ai dit et que tu n'as pas l'air d'avoir compris, c'est que l'algorithmique c'est de la théorie et qu'il faut retomber sur terre à un moment donné et faire avec le matériel que tu as sous la main. Et là il est plus qu'important de savoir comment fonctionne une machine pour ne pas faire n'importe quoi.
2) Je suis de la vieille école et pour moi l'analyste n'est pas le programmeur (ni l'inverse) : il y en a un qui décrit ce qu'il attend et l'autre le réalise avec les moyens qu'il a à sa dispostion.
Si j'ai arrêté de lire ta prose, c'est qu'en mélangeant tout il est facile de prouver n'importe quoi.
Maintenant j'en reste là, car je me moque bien de savoir qui développe en basic ou en C...
1) Ce que j'ai dit et que tu n'as pas l'air d'avoir compris, c'est que l'algorithmique c'est de la théorie et qu'il faut retomber sur terre à un moment donné et faire avec le matériel que tu as sous la main. Et là il est plus qu'important de savoir comment fonctionne une machine pour ne pas faire n'importe quoi.
2) Je suis de la vieille école et pour moi l'analyste n'est pas le programmeur (ni l'inverse) : il y en a un qui décrit ce qu'il attend et l'autre le réalise avec les moyens qu'il a à sa dispostion.
Si j'ai arrêté de lire ta prose, c'est qu'en mélangeant tout il est facile de prouver n'importe quoi.
Maintenant j'en reste là, car je me moque bien de savoir qui développe en basic ou en C...
Alors pour résumer ma réponse à la lumière de tes deux points, et sans les réfuter :
1) La dichotomie que tu avances entre le côté "théorique" d'un algorithme et son implémentation machine est vouée à disparaître, et cette disparition est souhaitable. En particulier, certains langages permettent d'écrire des programmes sous forme de description exacte de ce qu'ils doivent produire (le quoi) et non sous forme d'instructions de ce qu'ils doivent faire (le comment) ; et il est possible de compiler très efficacement ces langages.
Accessoirement, les interférences entre "le quoi" et "le comment", notament celles induites par les langages de bas niveau, sont un obstacle à l'enseignement de l'informatique.
2) J'avance que ce qui est aujourd'hui la tâche du programmeur non-analyste sera effectuée par le logiciel, et que le programmeur travaillera désormais à un plus haut niveau. C'est la conséquence de la complexité croissante des systèmes, et des progrès effectués dans la conception des langages.
Accessoirement, je comprends tout à fait qu'un programmeur non-anlyste puisse ne pas se réjouir de cette évolution, puisque qu'elle le rend inutile et menace de lui faire perdre son travail s'il ne se spécialise pas.
Ce n'est pas en enlevant la liberté d'expression de l'autre qu'on le fait taire, c'est en lui faisant saisir qu'aussi argumentés que puissent être ses propos, il ne sera plus écouté :!: Et qu'accessoirement il mélange tout et qu'il prouve n'importe quoi :p :p :p
:p Merci Patrice pour cette belle leçon d'humanisme ! :p
1) La dichotomie que tu avances entre le côté "théorique" d'un algorithme et son implémentation machine est vouée à disparaître, et cette disparition est souhaitable. En particulier, certains langages permettent d'écrire des programmes sous forme de description exacte de ce qu'ils doivent produire (le quoi) et non sous forme d'instructions de ce qu'ils doivent faire (le comment) ; et il est possible de compiler très efficacement ces langages.
Accessoirement, les interférences entre "le quoi" et "le comment", notament celles induites par les langages de bas niveau, sont un obstacle à l'enseignement de l'informatique.
2) J'avance que ce qui est aujourd'hui la tâche du programmeur non-analyste sera effectuée par le logiciel, et que le programmeur travaillera désormais à un plus haut niveau. C'est la conséquence de la complexité croissante des systèmes, et des progrès effectués dans la conception des langages.
Accessoirement, je comprends tout à fait qu'un programmeur non-anlyste puisse ne pas se réjouir de cette évolution, puisque qu'elle le rend inutile et menace de lui faire perdre son travail s'il ne se spécialise pas.
CITATION
Poolpy, désolé je n'ai pas le courage de tout lire. [...] Si j'ai arrêté de lire ta prose, c'est qu'en mélangeant tout il est facile de prouver n'importe quoi.
Ce n'est pas en enlevant la liberté d'expression de l'autre qu'on le fait taire, c'est en lui faisant saisir qu'aussi argumentés que puissent être ses propos, il ne sera plus écouté :!: Et qu'accessoirement il mélange tout et qu'il prouve n'importe quoi :p :p :p
:p Merci Patrice pour cette belle leçon d'humanisme ! :p
Très intéressant ce thread ! 
Intéressant, mais je ne comprends pas tout, pour ne pas dire rien, si ce n'est que parfois je me rends compte de l'aggressivité ambiante qui y règne... et je trouve cela bien dommage.
Cool tout le monde! Merci.
Cool tout le monde! Merci.
CITATION
JPA, tu as l'air de te sentir agressé alors que je n'en vois pas la raison. Et du coup, tes propos perdent en objectivité...
Ca c'est ton avis. Mais non, Patrice. C'est juste une petite clarification, histoire de remettre les points sur les i - et comme tu l'as sans doute remarque, j'ai pris la precaution d'inserer mes commentaires sarcastiques (et ils le sont) avec des flags <troll>.
Si demain une personne qui n'a utilisé Metro que 3,5 secondes te dit: c'est de la m***e, tu reagiras sans doute plus mal. Ensuite s'il te dit que c'est plus sympa de trimbaler tous le plans papiers de tous les metros du monde dans sa sacoche, que c'est plus malin ainsi que d'utiliser ton soft, que le papier c'est vraimment tres agreable au touche, que l'on peut s'en servir pour faire des cocottes, que ca peut servir quand on a une envie pressante, que le papier a fait c'est preuve depuis des milliers d'années alors que l'info...blahblahblah.... tu te poseras des questions sur ce que le quidam en question veut vraimment faire: s'orienter dans le metro ou faire un effet de style avec sa tonne de plans papiers. (ca c'est pas bien, on tue la foret! utilisez plutot Metro). Et puis si tu vois ensuite le quidam se perdre dans les couloirs d'un metro, tu auras peut etre un commentaire sarcastique
Ben voila, avec HB++, on developpe vite et bien, et il y aura des dizaines de milliers de personnes qui te le confirmeront. Alors, quand un autre quidam, qui ne connait pas ou peu le produit, porte un jugement erroné, je pense qu'il est sain de rectifier. Je connais bien le C/C++ (HB++ est developpe en C/C++) mais si je dois ecrire un soft pour Palm, je le ferai en HB++, car je vise le resultat, pas les moyens pour l'atteindre. Dans le meme style, peu m'importe la marque, la couleur, la complexite de mon vehicule- le tout est que je puisse me deplacer rapidement et confortablement en toute securite...tu vois ce que je veux dire?
Ok, VB avait de gros defauts en termes de performances et de fonctionnalites. Mais aussi plein d'avantages qui ont fait sont succes malgre tout. Maintenant, quand quelqu'un entend 'basic', il pense 'c'est un interprete limite qui rame'. C'est un jugement hatif qu'il est pret a colporter sur les forums, sans avoir meme pris la peine de verifier. Dommage, c'est comme repondre sans avoir lu/entendu, c'est souvent a cote de la plaque. Ou voter (Oui/Non) a la constitution Europeenne sans avoir lu et compris les implications, etc....
Tu aurais du quand meme lire les commentaires de poolpy, c'est tout simplement brillant.
JPA
The HB++ team
Moi j'aime bien HB++ ! 
Me too...
StepH
StepH
Poolpy, tes arguments (les 2) je les entend depuis 20 ans. Et pourtant depuis 20 ans, on est toujours obligé de faire avec les contraintes du matériel et on a toujours besoin de développeurs de bas niveau (au sens des couches basses, pas de leur niveau à eux). C'est d'ailleurs là tout ce que je dis : on est encore loin de l'idéal...
Quant à ta liberté d'expression, je ne vois pas en quoi je l'égratigne.
JPA, je pense très honnêtement que personne n'a mis en cause HB++ jusqu'ici, mais je comprend que tu puisses prendre certains commentaires à coeur (d'ailleurs j'aurais du nommer le sujet Basic vs C). Cependant cela ne justifie pas de perdre ton objectivité (oui, j'insiste) :
Quant à ta liberté d'expression, je ne vois pas en quoi je l'égratigne.
JPA, je pense très honnêtement que personne n'a mis en cause HB++ jusqu'ici, mais je comprend que tu puisses prendre certains commentaires à coeur (d'ailleurs j'aurais du nommer le sujet Basic vs C). Cependant cela ne justifie pas de perdre ton objectivité (oui, j'insiste) :
CITATION(jpa)
Maintenant, quand quelqu'un entend 'basic', il pense 'c'est un interprete limite qui rame'. C'est un jugement hatif qu'il est pret a colporter sur les forums, sans avoir meme pris la peine de verifier.
Ce type de remarque est un procès d'intention
CITATION(poolpy)
Oui, C fait abstraction des différences de CPU entre machines, mais pas des différences d'OS - c'est un autre avantage des langages de haut-niveau, puisqu'ils encapsulent dans leurs librairies de classes les différences entre OS ou versions de l'OS.
On peut aussi faire la même chose en C (et heureusement).
Le code écrit en C est réutilisable sans trop de modifications pour d'autres OS . Qu'en est-il du code écrit en HB++ ?
Admettons que comme Corto, j'écrive un logiciel de gestion de courrier électronique. J'écrit (et je teste) le code réseau sur mon PC (ou mon Mac :-p ) et je le teste comme cela dessus, avec le confort des debbugeurs existant sous Windows ou sous Unix. Une fois le code stable et fiable, l'adaptation du code réseau sur PalmOS prend quelques minutes.
Avec HB++, je peux écrire mon code réseaux (ou autre) en VB et le porter facilement sous HB++ ?
Cet argument est aussi valable pour la gestion des données. Un programme qui gère beaucoup de données peut les stocker en utilisant sqlite. Le code peut là aussi etre porté facilement vers un autre OS, puisque l'API existe aussi pour PPC, Windows, Unix, MacOS .....
Et l'interface d'accès aux données de HB++, c'est la même qu'en VB ?
Alors quel est le langage qui s'adapte le plus facilement entre les OS ?
L'inconvénient des langages de haut niveau comme HB++ est qu'on est limité par les fonctionnalités des classes fournies avec le langage. Quel est le niveau de compatibilité des classes de gestion du courrier électronique avec le protocole IMAP ? Et le support SSL dans les classes POP et IMAP ? Si les fonctions dont on a besoin ne sont pas disponibles, on peut facilement les ajouter ?
Peut-on facilement étendre les fonctionnalités des classes ? Ou doit-on redevelopper une classe quand les fonctionnalités dont on a besoin ne sont pas implémentées ?
Hello oupsman,
Ben tes minutes vont se transformer en heures ou en jour, car tu verras que l'implementation des sockets dans le SDK palm a quelques specificites. Et puis ensuite il faudra que tu implementes ton code differemment en fonctions des versions de PalmOS, voire des differentes machines. hehe...pas gagne tout de suite.
Alors que ce que permet HB++, c'est d'ecrire ton code dans son IDE, de profiter du confort du debugger en liaison avec POSE/PalmSim pour le mettre au point (bien sur, il te faut activer l'option Redirect Netlib call to host TCP/IP). Le gros plus etant que ton code sera independant de la version de l'OS ou de la machine...Donc plus simple
Oui, tu trouveras sur nos forums des posts d'utilisateurs qui font cela. Les fonctions ont les memes param et donne les memes resultats, les types commun ont le meme nom, la plupart des evenements sont identiques, etc, etc...Donc oui, on ne gene pas pour reutiliser du code VB
Bien sur, certaines choses different ou ne peuvent etre en commun entre le monde PC et Palm. Faire clignoter la LED du palm ne se retrouvera pas sur le PC, etc...
Aha! tu veux dire qu'il faut utliser des soft haut niveau comme SQL lite? Mais bien sur, je suis d'accord! Rien ne t'empeches d'ailleurs de le faire depuis HB++.
Autrement, si tu dois utiliser le SDK Palm pour acceder a tes donnees, en C, il te faudra faire attention aux legeres differences que l'on retrouve d'une version de l'OS a l'autre. Pas en HB++, puis que c'est gerer en interne dans la librairie.
En VB, ton interface avec les donnees changent en fonction de la base de donnee que tu utilises. Des composants comme ADO harmonisent un peu cela, mais si tu veux attaquer du SQLServer en natif, ce ne sera pas du tout la meme chose que de gerer une base Postgress, par exemple.
Comme la plupart des developpeurs VB ont deja utilise DAO/ADO, nous avons repris la meme syntaxe (.Edit, .Update, MoveNext, MovePrevious,..., .EOF, BOF, etc, etc...). Les differences sont mineures et le code VB pour la gestions des bases est donc aussi grandement reutilisable. Bien sur il existe des differences: les bases PC n'ont pas de CreatorID ou de Type...
Hmmm...HB++ ne compile que pour PalmOS, donc pas de debat la dessus. Par contre, et je trouve ca important, il permet de s'afrranchir des differences de comportement (et il y en a un paquet) entre les differentes version de PalmOS et les specificites des differentes machines. La gestion de la DIA est un exemple avec les specifs sony, PalmSource, PalmOne...Avec HB++, cela est gere par la librairie, donc tu ecris un code qui n'a pas en tenir compte. Ce n'est pas negligeable, et cela reduit grandement le travail du developpeur.
Quand tu fais un soft pour PalmOS en C (avec le SDK palm), c'est vraimment penible de devoir gerer toutes ces differences- tout ce que l'on veut c'est que cela marche. Il existe peut etre un framework C pour PalmOS qui permet de faire la meme chose, je ne sais pas...
Attention, ne crois pas que je crache sur le C, ou sur le SDK palm! Pas du tout. Je connais bien les deux et m'en sers souvent (viens de passer la nuit sur un petit parser des familles en VC++, c'etait cool). Mais quand je fais un projet pour Palm, il n'y a pas photo, je le fait en HB++...
Enfin, ma reponse initiale etait une reaction par rapport a ca:
HB++, c'est quoi çà.
Ah ouai je me souviens un joujou à la Visual Basic.
Si tu es étudiant en info, c'est que tu veux être professionnel, il faut alors utiliser des outils de professionnel.
Cela a provoque comme une sorte de 'fatal exception' ou debordement de pile, et je n'ai pu m'empecher de recadrer, en gardant le meme ton de plaisanterie que Corto d'ailleurs. Je ne peux malheusement pas citer mes clients en reference, mais je peux t'assurer qu'il y a de tout dont pas mal de 'Pro' comme certains fabricants de Palm, des grandes ecoles, des corps d'armees, des gens qui envoient des trucs dans l'espace, des institutions gouvernementales, des compagnies aeriennes et des aeroports...etc..Notre compilo n'est pas un joujou et il est utilise par des pros qui ont des obligations de resultats et des delais a tenir.
Que cela n'empeche pas de se boire une biere ensemble un de ces quatres, en parler dev/Palm. On a fait l'experience avec aldweb (createur d'iziBasic) et Philippe Guillot (createur de PP) il n'y a pas si longtemps, et meme si chacun a son langage de predilection (celui qu'il a cree), c'est quand meme sympa. A renouveler!
A+
JPA
The HB++ team
CITATION
Admettons que comme Corto, j'écrive un logiciel de gestion de courrier électronique. J'écrit (et je teste) le code réseau sur mon PC (ou mon Mac :Razz ) et je le teste comme cela dessus, avec le confort des debbugeurs existant sous Windows ou sous Unix. Une fois le code stable et fiable, l'adaptation du code réseau sur PalmOS prend quelques minutes.
Ben tes minutes vont se transformer en heures ou en jour, car tu verras que l'implementation des sockets dans le SDK palm a quelques specificites. Et puis ensuite il faudra que tu implementes ton code differemment en fonctions des versions de PalmOS, voire des differentes machines. hehe...pas gagne tout de suite.
Alors que ce que permet HB++, c'est d'ecrire ton code dans son IDE, de profiter du confort du debugger en liaison avec POSE/PalmSim pour le mettre au point (bien sur, il te faut activer l'option Redirect Netlib call to host TCP/IP). Le gros plus etant que ton code sera independant de la version de l'OS ou de la machine...Donc plus simple
CITATION
en VB et le porter facilement sous HB++ ?
Oui, tu trouveras sur nos forums des posts d'utilisateurs qui font cela. Les fonctions ont les memes param et donne les memes resultats, les types commun ont le meme nom, la plupart des evenements sont identiques, etc, etc...Donc oui, on ne gene pas pour reutiliser du code VB
Bien sur, certaines choses different ou ne peuvent etre en commun entre le monde PC et Palm. Faire clignoter la LED du palm ne se retrouvera pas sur le PC, etc...
CITATION
Cet argument est aussi valable pour la gestion des données. Un programme qui gère beaucoup de données peut les stocker en utilisant sqlite. Le code peut là aussi etre porté facilement vers un autre OS, puisque l'API existe aussi pour PPC, Windows, Unix, MacOS .....
Aha! tu veux dire qu'il faut utliser des soft haut niveau comme SQL lite? Mais bien sur, je suis d'accord! Rien ne t'empeches d'ailleurs de le faire depuis HB++.
Autrement, si tu dois utiliser le SDK Palm pour acceder a tes donnees, en C, il te faudra faire attention aux legeres differences que l'on retrouve d'une version de l'OS a l'autre. Pas en HB++, puis que c'est gerer en interne dans la librairie.
CITATION
Et l'interface d'accès aux données de HB++, c'est la même qu'en VB ?
En VB, ton interface avec les donnees changent en fonction de la base de donnee que tu utilises. Des composants comme ADO harmonisent un peu cela, mais si tu veux attaquer du SQLServer en natif, ce ne sera pas du tout la meme chose que de gerer une base Postgress, par exemple.
Comme la plupart des developpeurs VB ont deja utilise DAO/ADO, nous avons repris la meme syntaxe (.Edit, .Update, MoveNext, MovePrevious,..., .EOF, BOF, etc, etc...). Les differences sont mineures et le code VB pour la gestions des bases est donc aussi grandement reutilisable. Bien sur il existe des differences: les bases PC n'ont pas de CreatorID ou de Type...
CITATION
Alors quel est le langage qui s'adapte le plus facilement entre les OS ?
Hmmm...HB++ ne compile que pour PalmOS, donc pas de debat la dessus. Par contre, et je trouve ca important, il permet de s'afrranchir des differences de comportement (et il y en a un paquet) entre les differentes version de PalmOS et les specificites des differentes machines. La gestion de la DIA est un exemple avec les specifs sony, PalmSource, PalmOne...Avec HB++, cela est gere par la librairie, donc tu ecris un code qui n'a pas en tenir compte. Ce n'est pas negligeable, et cela reduit grandement le travail du developpeur.
Quand tu fais un soft pour PalmOS en C (avec le SDK palm), c'est vraimment penible de devoir gerer toutes ces differences- tout ce que l'on veut c'est que cela marche. Il existe peut etre un framework C pour PalmOS qui permet de faire la meme chose, je ne sais pas...
Attention, ne crois pas que je crache sur le C, ou sur le SDK palm! Pas du tout. Je connais bien les deux et m'en sers souvent (viens de passer la nuit sur un petit parser des familles en VC++, c'etait cool). Mais quand je fais un projet pour Palm, il n'y a pas photo, je le fait en HB++...
Enfin, ma reponse initiale etait une reaction par rapport a ca:
HB++, c'est quoi çà.
Ah ouai je me souviens un joujou à la Visual Basic.
Si tu es étudiant en info, c'est que tu veux être professionnel, il faut alors utiliser des outils de professionnel.
Cela a provoque comme une sorte de 'fatal exception' ou debordement de pile, et je n'ai pu m'empecher de recadrer, en gardant le meme ton de plaisanterie que Corto d'ailleurs. Je ne peux malheusement pas citer mes clients en reference, mais je peux t'assurer qu'il y a de tout dont pas mal de 'Pro' comme certains fabricants de Palm, des grandes ecoles, des corps d'armees, des gens qui envoient des trucs dans l'espace, des institutions gouvernementales, des compagnies aeriennes et des aeroports...etc..Notre compilo n'est pas un joujou et il est utilise par des pros qui ont des obligations de resultats et des delais a tenir.
Que cela n'empeche pas de se boire une biere ensemble un de ces quatres, en parler dev/Palm. On a fait l'experience avec aldweb (createur d'iziBasic) et Philippe Guillot (createur de PP) il n'y a pas si longtemps, et meme si chacun a son langage de predilection (celui qu'il a cree), c'est quand meme sympa. A renouveler!
A+
JPA
The HB++ team
CITATION(jpa)
Cela a provoque comme une sorte de 'fatal exception' ou debordement de pile, et je n'ai pu m'empecher de recadrer, en gardant le meme ton de plaisanterie que Corto d'ailleurs. Je ne peux malheusement pas citer mes clients en reference, mais je peux t'assurer qu'il y a de tout dont pas mal de 'Pro' comme certains fabricants de Palm, des grandes ecoles, des corps d'armees, des gens qui envoient des trucs dans l'espace, des institutions gouvernementales, des compagnies aeriennes et des aeroports...etc..Notre compilo n'est pas un joujou et il est utilise par des pros qui ont des obligations de resultats et des delais a tenir.
Je n'ai jamais dit que HB++ était un jouet. Loin de là (ca fait cher le jouet quand même
) Mais disons qu'il n'ést pas adapté à tous les projets, ni à tous les programmeurs (surtout ...). J'ai une allergie chronique au basic (ben oui, j'en ai trop fait dans ma jeunesse). J'ai essayé HB++ et j'ai été imprésionne par le travail qu'il y a derrière. Il est vrai que la vitesse d'exécution est excellente. On sent le compilo, contrairement au VB. Là je suis d'accord.
Par contre, tu n'as pas répondu à mes questions sur les composants IMAP de HB++ et les possibilités d'extensions
L'inconvénient d'un langage comme HB++, c'est qu'on est limité par les classes fournies. Certes elles permettent de développer rapidement une appli. Mais quand on a besoin de plus de fonctionnalités, ben faut redévelopper la classe en entier. On est donc dans la logique d'une bibliothèque externe en C : une boite noire et une API. Point barre !
On est donc loin de la souplesse de réutilisation du code qui existe en C.
CITATION(jpa)
Que cela n'empeche pas de se boire une biere ensemble un de ces quatres, en parler dev/Palm. On a fait l'experience avec aldweb (createur d'iziBasic) et Philippe Guillot (createur de PP) il n'y a pas si longtemps, et meme si chacun a son langage de predilection (celui qu'il a cree), c'est quand meme sympa. A renouveler!
Avec plaisir.
Y'a une réunion PA le 2 avril. Tu viens ?
CITATION
L'inconvénient d'un langage comme HB++, c'est qu'on est limité par les classes fournies. Certes elles permettent de développer rapidement une appli. Mais quand on a besoin de plus de fonctionnalités, ben faut redévelopper la classe en entier. On est donc dans la logique d'une bibliothèque externe en C : une boite noire et une API. Point barre !
Il faut distinguer deux choses :
- La bibliothèque de classes natives HB++ (qui est un wrapper autour des API principales de PalmOS prenant en charge tout le côté fastidieux - allocation mémoire, bugs de PalmOS, incompatibilités entre versions). Celles là ne peuvent pas être réimplémentées, c'est un point (puisque cette bibliothèque est écrite en C). La classe StreamSocket gérant de façon pratique les sockets se situe à ce niveau. Mais puisque ce sont des "primitives", il n'y a pas de raisons d'avoir à les modifier.
- La bibliothèque de classes ou de user controls livrés avec HB++, implémentés en HB++. Ceux là sont donnés avec leur code source et peuvent être modifiés, étendus, réimplémentés. Une classe gérant la messagerie ou un protocole réseau se situera évidemment à ce niveau.
CITATION
On est donc loin de la souplesse de réutilisation du code qui existe en C.
Peux-tu expliquer ?
Parce que dans le pire des cas, on peut redéclarer toutes les API de PalmOS et avoir strictement la même flexibilité qu'en C.
CITATION(oupsman)
(ca fait cher le jouet quand même )
)8O 149 euros dans sa version standard, je n'appelle pas du tout ça cher, comparé à ce que peuvent coûter certains autres hobbies. Et la version Pro est à 490 €, ce qui est toujours OK pour un soft professionnel, avec support (ma boîte a voulu acheter InstallAnywhere il y a quelques semaines, ils ont abandonné quand ils ont vu le prix: 3000$).
Rappelons qu'il est possible d'utiliser HB++ gratuitement, avec l'affichage d'une nagscreen au démarrage des applications générées (ce qui semble gêner certains, on en a déjà parlé en long et en large ailleurs
).
J'ajouterai que le support de jpa et Poolpy dans les forums de HB++ est tout simplement extraordinaire: réponses dans la journée (souvent beaucoup plus vite), week-end compris; solutions complètes avec exemples (morceaux de code), APIs traduites en HB++, applications complètes, ... Franchement, ils mettent la barre très très haut en matière de support, chez Peter Holmes Consulting.
Moi, un ayatollah HB++? Oui, tout à fait, et fier de l'être!
CITATION(snark)
CITATION(oupsman)
(ca fait cher le jouet quand même )
)8O 149 euros dans sa version standard
C'est ce que je dis : cher le jouet. GCC est gratos, et Falch.net developper studio est à 49$ dans la version pro.
CW est hors jeu, lui il chiffre à 381$ environ.
Bon OK je suis de mauvaise foi, ma suite de logiciels de 3D m'a couté beaucoup plus cher que cela
Mon but n'est pas de faire un procès à HB++.
Ceci dit, tous les arguments que jpa sort sur l'encapsulation sont aussi valables en C. On peut tout à fait faire des wrappers autour des librairies PalmONE, Sony et handera pour la gestion de la ZGV.
Et je suis certain que les développeurs C professionnels l'ont tous fait.
Désolé oups, mais de ton post, je n'en ai retenu que ceci:
CITATION(oupsman)
Bon OK je suis de mauvaise foi
CITATION(snark)
Désolé oups, mais de ton post, je n'en ai retenu que ceci:
CITATION(oupsman)
Bon OK je suis de mauvaise foi
(WW)
CITATION(oupsman)
C'est ce que je dis : cher le jouet. GCC est gratos, et Falch.net developper studio est à 49$ dans la version pro.
Je sens que JPA va venir expliquer ici avec plein d'exemples concrets que le coût d'un outil de développement ne s'évalue pas en ne prenant en compte que le prix du compilateur en lui-même, mais aussi :
- Le coût de formation des développeurs de l'entreprise à l'outil (on se place dans le contexte d'une boîte qui n'est pas spécialisée dans le PDA, et qui voit débarquer un projet PDA).
- La facilité de recrutement (éventuellement) d'un développeur supplémentaire sur le projet.
- Le temps de développement total du projet.
- Plus généralement, l'agilité de l'outil de développement lorsqu'il s'agit de restructurer le code, rajouter des fonctions non prévues, etc.
- La facilité avec laquelle le programme peut être maintenu, éventuellement par un non-spécialiste du PDA.
- La réactivité du support technique de l'outil en question (le temps qu'un développeur va pouvoir passer bloqué sur un problème).
J'étais en train de préparer un post dans ce sens.
Mais trop tard, grillé par Poolpy.
Effectivement, il ne faut pas oublier qu'une entreprise développe rarement dans un but de perdre de l'argent. Elle répond à un modèle economique dans un environement concurrentiel. Cela m'enerve un peu de voir que les développeurs puissent oublier ce pan de réalité.
Mais trop tard, grillé par Poolpy.
Effectivement, il ne faut pas oublier qu'une entreprise développe rarement dans un but de perdre de l'argent. Elle répond à un modèle economique dans un environement concurrentiel. Cela m'enerve un peu de voir que les développeurs puissent oublier ce pan de réalité.
les rares fois où je sors de mon 12ème (pour Patrice ) et que je vais débugger des applis en usines, je tombe en général sur 3 cas :
1) le programme n'est pas stable. En général, écrit en C (ouC++) avec des complexiries pointeusales qui font planter. Garbage collecteur ou langage sans pointeur souhaitable...
2) le problème de performance : la plateforme n'est pas adpaté (VB, pas de multithread, goulot, ...) et là effectivement, le choix d'un langage plus bas niveau aurait été bienvenu. Des fois on s'aperçoit qu'en utilisant des langages de haut niveau ils masquent de véritables usines à gaz lors de traitement simples (tri, recherche, ...) ce qui pénalise les perfs sans que le developpeur ne puisse y faire qqchose !
3) problème de performance lié aux algos. Independant du langage. Le developpeur à sécher les cours d'algorithmie avancé !
En conclusion, je vois un peu de tout. Des systèmes VB pilotent des ateliers, des applis en C aussi. Si une plateforme était universelle et formidable ça se saurait. Chaque langage a ses défauts/qualités comme montré dans les 3 cas de figures ...
) et que je vais débugger des applis en usines, je tombe en général sur 3 cas :
1) le programme n'est pas stable. En général, écrit en C (ouC++) avec des complexiries pointeusales qui font planter. Garbage collecteur ou langage sans pointeur souhaitable...
2) le problème de performance : la plateforme n'est pas adpaté (VB, pas de multithread, goulot, ...) et là effectivement, le choix d'un langage plus bas niveau aurait été bienvenu. Des fois on s'aperçoit qu'en utilisant des langages de haut niveau ils masquent de véritables usines à gaz lors de traitement simples (tri, recherche, ...) ce qui pénalise les perfs sans que le developpeur ne puisse y faire qqchose !
3) problème de performance lié aux algos. Independant du langage. Le developpeur à sécher les cours d'algorithmie avancé !
En conclusion, je vois un peu de tout. Des systèmes VB pilotent des ateliers, des applis en C aussi. Si une plateforme était universelle et formidable ça se saurait. Chaque langage a ses défauts/qualités comme montré dans les 3 cas de figures ...
Hello oupsman,
Je te reponds. Tu as a ta disposition une librairie de haut de haut niveau qui implemente toute une palette de fonctionnalites. Si tu veut faire de l'IMAP, du POP,SMTP...tu utilises la classe StreamSocket de la librairie et tu la code dans ta propre classe. Ne te fatigue pas trop la dessus, on va fournir un sample 'Client email' tres bientot, avec les classes idoines pour gerer POP/SMTP, les pieces attachees, etc...une fois ces classes integrees dans ton projet, tu n'a qu'a les instancier, et t'en servir. Envoyer, recevoir des mails, voir la liste des mails sur ton serveur, obtenir leur taille et ID, etc..se fait en quelques lignes.
Ben non, tu as du loupe un truc quand tu as essaye HB++. Comme dit plus haut, tu as a ta disposition une librairie haut niveau, et ce que tu n'as pas, tu peux le faire en HB++ directement-sans appler une shared lib, meme si cela est possible. Par exemple, refaire du code pour remplacer Zlib ou JPEGlib est un peu bebete, autant utiliser la sharedlib existante.
Mais rien ne t'empeche de creer tes propres 'nouvelles classes' en HB++ directement, en te servant des primitives de la librairie HB++ ou meme en appelant les API PalmOS (ou PalmOne, TapWave,etc..) directement depuis HB++. Tu n'est pas plus limite qu'en C, tu peux meme definir des callback en HB++, etc...
Ben non. Il m'arrive de faire copier/coller de code C dans HB++ et de le traduire en deux minutes. Je vire ce qui est gere automatiquement par HB++, je garde juste l'algo et les appels API. Generalement, ca diminue la taille du code de beaucoup. Concernant ta remarque sur le fait que beaucoup de developpeurs C doivent integrer du code pour gerer la DIA, oui, tu as raison, ils le font....Ce que je disait, c'est que tout ce code en C correspond a 0 (zero) ligne de code en HB++ car c'est deja gerer par la librairie.
Et puis il y a des modules (packages) additionnels qui etendent tes possibliltes: il te suffit juste de les integrer (Charts, Calendar, DateBook DB class, Todo DB class, Agenda DB class, Note DB class, Shape control, Treo's gadgets, controles de dessins divers, Classes pour acceder des bases SatForms, PDAT, AppForge,...., des controles personalises gauges et sliders, des Tab, classe Treeview (exactement la meme syntaxe qu'en VB) , Barcode, SDIO socket scan, Datec printers, PPrint, PrintBoy, IrPrint, Acceeca....et la liste est longue). C'est un framework tout fait, que tu n'as plus qu'a utiliser. S'il te manque un truc, tu peux le coder directement en HB++...sans parler du generateur de conduit qui te permet de generer un conduit (un vrai, la dll qui va bien) en deux minutes....le conduit installer qui est livre avec....
Oui, tu peux etendre les fonctionalites des classes existantes, tu auras peux etre vu que HB++ permet la derivation et l'heritage....Quand une fonctionalite n'existe pas, en C comme en HB++, il est vrai que l'on doit la developper...ou alors il faut allumer un cierge, faire des incantations, boire une biere....Arg, je derape encore!
AHHHH...on se la fait cette biere? Oui! C'est prive? Sais pas ou cela se passe...Vais me renseigner offLine/offForum...
A+
JPA
The HB++ team
CITATION
Par contre, tu n'as pas répondu à mes questions sur les composants IMAP de HB++ et les possibilités d'extensions
Je te reponds. Tu as a ta disposition une librairie de haut de haut niveau qui implemente toute une palette de fonctionnalites. Si tu veut faire de l'IMAP, du POP,SMTP...tu utilises la classe StreamSocket de la librairie et tu la code dans ta propre classe. Ne te fatigue pas trop la dessus, on va fournir un sample 'Client email' tres bientot, avec les classes idoines pour gerer POP/SMTP, les pieces attachees, etc...une fois ces classes integrees dans ton projet, tu n'a qu'a les instancier, et t'en servir. Envoyer, recevoir des mails, voir la liste des mails sur ton serveur, obtenir leur taille et ID, etc..se fait en quelques lignes.
CITATION
L'inconvénient d'un langage comme HB++, c'est qu'on est limité par les classes fournies. Certes elles permettent de développer rapidement une appli. Mais quand on a besoin de plus de fonctionnalités, ben faut redévelopper la classe en entier. On est donc dans la logique d'une bibliothèque externe en C : une boite noire et une API. Point barre !
Ben non, tu as du loupe un truc quand tu as essaye HB++. Comme dit plus haut, tu as a ta disposition une librairie haut niveau, et ce que tu n'as pas, tu peux le faire en HB++ directement-sans appler une shared lib, meme si cela est possible. Par exemple, refaire du code pour remplacer Zlib ou JPEGlib est un peu bebete, autant utiliser la sharedlib existante.
Mais rien ne t'empeche de creer tes propres 'nouvelles classes' en HB++ directement, en te servant des primitives de la librairie HB++ ou meme en appelant les API PalmOS (ou PalmOne, TapWave,etc..) directement depuis HB++. Tu n'est pas plus limite qu'en C, tu peux meme definir des callback en HB++, etc...
CITATION
On est donc loin de la souplesse de réutilisation du code qui existe en C.
Ben non. Il m'arrive de faire copier/coller de code C dans HB++ et de le traduire en deux minutes. Je vire ce qui est gere automatiquement par HB++, je garde juste l'algo et les appels API. Generalement, ca diminue la taille du code de beaucoup. Concernant ta remarque sur le fait que beaucoup de developpeurs C doivent integrer du code pour gerer la DIA, oui, tu as raison, ils le font....Ce que je disait, c'est que tout ce code en C correspond a 0 (zero) ligne de code en HB++ car c'est deja gerer par la librairie.
Et puis il y a des modules (packages) additionnels qui etendent tes possibliltes: il te suffit juste de les integrer (Charts, Calendar, DateBook DB class, Todo DB class, Agenda DB class, Note DB class, Shape control, Treo's gadgets, controles de dessins divers, Classes pour acceder des bases SatForms, PDAT, AppForge,...., des controles personalises gauges et sliders, des Tab, classe Treeview (exactement la meme syntaxe qu'en VB) , Barcode, SDIO socket scan, Datec printers, PPrint, PrintBoy, IrPrint, Acceeca....et la liste est longue). C'est un framework tout fait, que tu n'as plus qu'a utiliser. S'il te manque un truc, tu peux le coder directement en HB++...sans parler du generateur de conduit qui te permet de generer un conduit (un vrai, la dll qui va bien) en deux minutes....le conduit installer qui est livre avec....
CITATION
Peut-on facilement étendre les fonctionnalités des classes ? Ou doit-on redevelopper une classe quand les fonctionnalités dont on a besoin ne sont pas implémentées ?
Oui, tu peux etendre les fonctionalites des classes existantes, tu auras peux etre vu que HB++ permet la derivation et l'heritage....Quand une fonctionalite n'existe pas, en C comme en HB++, il est vrai que l'on doit la developper...ou alors il faut allumer un cierge, faire des incantations, boire une biere....Arg, je derape encore!
CITATION
Avec plaisir.
Y'a une réunion PA le 2 avril. Tu viens ?
Y'a une réunion PA le 2 avril. Tu viens ?
AHHHH...on se la fait cette biere? Oui! C'est prive? Sais pas ou cela se passe...Vais me renseigner offLine/offForum...
A+
JPA
The HB++ team
CITATION(jpa)
CITATION(oupsman)
Y'a une réunion PA le 2 avril. Tu viens ?
AHHHH...on se la fait cette biere? Oui! C'est prive? Sais pas ou cela se passe...Vais me renseigner offLine/offForum...
C'est ici que ça se passe
et c'est ouvert à tous bien sûr !
CITATION(poolpy)
CITATION(oupsman)
C'est ce que je dis : cher le jouet. GCC est gratos, et Falch.net developper studio est à 49$ dans la version pro.
Je sens que JPA va venir expliquer ici avec plein d'exemples concrets que le coût d'un outil de développement ne s'évalue pas en ne prenant en compte que le prix du compilateur en lui-même, mais aussi :
Je me place dans le contexte d'un développeur de Freeware/shareware.
Même si la plupart des développeurs travaillent dans le monde de l'entreprise, y'a quand même des hobbysts qui développent pour leur plaisir.
Et moi je me vois pas trop mettre 149$ dans un IDE. Tu m'offres la license jpa
Bon OK je sors.
CITATION(oupsman)
CITATION(poolpy)
CITATION(oupsman)
C'est ce que je dis : cher le jouet. GCC est gratos, et Falch.net developper studio est à 49$ dans la version pro.
Je sens que JPA va venir expliquer ici avec plein d'exemples concrets que le coût d'un outil de développement ne s'évalue pas en ne prenant en compte que le prix du compilateur en lui-même, mais aussi :
Je me place dans le contexte d'un développeur de Freeware/shareware.
Même si la plupart des développeurs travaillent dans le monde de l'entreprise, y'a quand même des hobbysts qui développent pour leur plaisir.
C'est mon cas et je me suis acheté la licence.
Quand je compare à mon activité musicale, HB++ coute moins cher qu'un instrument de musique : Une flute à bec ... 300 euros pour le bout d'olivier. Et ca reviens à peut près tout les 5 ans.
Et puis pour revenir à HB++, comme je développe à la maison entre deux activités, la rapidité de création de programme me permet d'aller à l'essentiel : réaliser le programme pas passer des heures à décortiquer les API de chaque constructeur. (même si je le fais un peu pour ne pas perdre de vu les contraintes de ces petites machines)
CITATION(oupsman)
Je me place dans le contexte d'un développeur de Freeware/shareware.
Et moi je me vois pas trop mettre 149$ dans un IDE. Tu m'offres la license jpa
Et moi je me vois pas trop mettre 149$ dans un IDE. Tu m'offres la license jpa
Dans un contexte freeware, HB++ est gratuit (avec un nag screen relativement discret) et dans un contexte shareware (donc où c'est pour gagner de l'argent), payer 149$ ne me choque pas...
CITATION(jpa)
Dans le meme style, peu m'importe la marque, la couleur, la complexite de mon vehicule- le tout est que je puisse me deplacer rapidement et confortablement en toute securite...tu vois ce que je veux dire?
oui je vois
Tiens, je vais aussi donner mon opinion de vieux briscart sur le sujet.
Qui se souvient de l'assembleur ? Trop complexe pour être utlisé par le commun des mortels, réservé à une élite de programmeur ayant aujourd'hui presque disparue. C'est pourtant le langage le plus rapide en exécution mais le plus long à mettre en oeuvre. Plusieurs langages ont donc vu le jour pour simplifier la programmation. Avantage, on développe plus rapidement, inconvénient, on s'éloigne du langage machine, on ajoute des couches, on perd en performance brute.
Il n'y a pas de langage meilleur qu'un autre, ca dépend de ce que l'on veut faire. Pour le système, on choisit le C, pour les mathématiques, le fortran, etc ...
Mais une chose est certaine, plus la programmation est simplifiée et moins le code produit sera performant.
Il y a peu, on a abordé sur PA un sujet du même genre sur les éditeurs de texte, chacun a vanté l'éditeur qu'il utilisait sous Unix. Certains simplifient la rédaction d'un programme, mais c'est plus long à tapper au clavier, d'autres comme VI sont très complexes à utiliser mais aucun n'est plus rapide pour pisser du code ...
C'est une histoire de compromis : Faciliter de développement ou privilégier la performance ? à chacun de voir selon ses besoins.
[edit] Ceci dit, je suis plus près de Corto ou Patrice dans leur réflexion, parce que le C est pour moi un langage avec lequel j'ai eu beaucoup d'aventures et d'affinité C'est un langage d'afficionados [/edit]
Qui se souvient de l'assembleur ? Trop complexe pour être utlisé par le commun des mortels, réservé à une élite de programmeur ayant aujourd'hui presque disparue. C'est pourtant le langage le plus rapide en exécution mais le plus long à mettre en oeuvre. Plusieurs langages ont donc vu le jour pour simplifier la programmation. Avantage, on développe plus rapidement, inconvénient, on s'éloigne du langage machine, on ajoute des couches, on perd en performance brute.
Il n'y a pas de langage meilleur qu'un autre, ca dépend de ce que l'on veut faire. Pour le système, on choisit le C, pour les mathématiques, le fortran, etc ...
Mais une chose est certaine, plus la programmation est simplifiée et moins le code produit sera performant.
Il y a peu, on a abordé sur PA un sujet du même genre sur les éditeurs de texte, chacun a vanté l'éditeur qu'il utilisait sous Unix. Certains simplifient la rédaction d'un programme, mais c'est plus long à tapper au clavier, d'autres comme VI sont très complexes à utiliser mais aucun n'est plus rapide pour pisser du code ...
C'est une histoire de compromis : Faciliter de développement ou privilégier la performance ? à chacun de voir selon ses besoins.
[edit] Ceci dit, je suis plus près de Corto ou Patrice dans leur réflexion, parce que le C est pour moi un langage avec lequel j'ai eu beaucoup d'aventures et d'affinité
C'est un langage d'afficionados [/edit]
CITATION(Schtunks)
Moi j'aime bien HB++ ! :D
moi aussi et c'est une découverte
Salut CyrilP,
Elite!! comme tu y vas :!: Non, c'est cool l'assembleur,mais pour des taches bien specifiques. Ecrire en assembleur la gestion d'une form n'a aucun interet...par contre ecrire un assembleur une routine de tri ou de comparaison qui est appelee des milliers de fois par sec, ca c'est vraimment utile!
B-D D'ailleurs, on a laisse la possibilite de code directement en assembleur dans HB++ (on peut voir que le mot cle asm est reserve). Le plus gros probleme pour nous reste la documentation autour de cette possibilite, ce qui n'est pas simple du tout. D'ailleurs, la documentation en generale n'est pas une tache simple (l'enfer!). P:-)
Ben quoi? c'est vrai non Ne cafte pas stp!
Si mes hobbies/plaisirs ne pouvait me couter que ca
Ce serait le bonheur!
Yes!
A+
JPA
The HB++ team
CITATION
Qui se souvient de l'assembleur ? Trop complexe pour être utlisé par le commun des mortels, réservé à une élite de programmeur ayant aujourd'hui presque disparue.
Elite!! comme tu y vas :!: Non, c'est cool l'assembleur,mais pour des taches bien specifiques. Ecrire en assembleur la gestion d'une form n'a aucun interet...par contre ecrire un assembleur une routine de tri ou de comparaison qui est appelee des milliers de fois par sec, ca c'est vraimment utile!
B-D D'ailleurs, on a laisse la possibilite de code directement en assembleur dans HB++ (on peut voir que le mot cle asm est reserve). Le plus gros probleme pour nous reste la documentation autour de cette possibilite, ce qui n'est pas simple du tout. D'ailleurs, la documentation en generale n'est pas une tache simple (l'enfer!). P:-)
CITATION
CITATION
Dans le meme style, peu m'importe la marque, la couleur, la complexite de mon vehicule- le tout est que je puisse me deplacer rapidement et confortablement en toute securite...tu vois ce que je veux dire?
oui je vois Ben quoi? c'est vrai non
Ne cafte pas stp!
CITATION
Même si la plupart des développeurs travaillent dans le monde de l'entreprise, y'a quand même des hobbysts qui développent pour leur plaisir.
Si mes hobbies/plaisirs ne pouvait me couter que ca
Ce serait le bonheur!
CITATION
Y'a une réunion PA le 2 avril. Tu viens ?
Yes!
A+
JPA
The HB++ team
CITATION
Trop complexe pour être utlisé par le commun des mortels, réservé à une élite de programmeur ayant aujourd'hui presque disparue. C'est pourtant le langage le plus rapide en exécution mais le plus long à mettre en oeuvre.
La plupart des processeurs sont maintenant suffisament complexes pour qu'il soit quasiment impossible à un humain d'écrire du code efficace en langage machine, ne serait-ce parce qu'il faut apprendre les milliers de règles ou contraintes pour permettre du parallélisme/pipeling efficace. Il faut l'accepter : s'ils sont bien %#!§@çus, les compilateurs font un meilleur boulot.
CITATION
Mais une chose est certaine, plus la programmation est simplifiée et moins le code produit sera performant.
Si l'on suppose que simplifier la programmation ne peut se faire qu'en utilisant des couches d'abstraction figées qui s'appellent les unes les autres, tu as tout à fait raison, simplifier ne peut que ralentir. Mais tu oublies qu'un compilateur peut aussi très bien choisir la meilleure implémentation possible d'un concept de haut-niveau, ou raisonner sur le code de haut-niveau pour identifier des optimisations, et donc arriver à des performances meilleures ou identiques à celle d'un langage de bas-niveau. OCaml, Haskell, Scheme ou même Clean se classent souvent très bien dans des benchmarks (et souvent mieux que certains compilateurs C/C++) alors qu'ils offrent une programmation d'un très haut-niveau. Etonnant non ?
CITATION
Ceci dit, je suis plus près de Corto ou Patrice dans leur réflexion, parce que le C est pour moi un langage avec lequel j'ai eu beaucoup d'aventures et d'affinité Clin d'oeil C'est un langage d'afficionados
En une dizaine d'années, j'ai écrit beaucoup de C, et ce sur différentes plateformes (PC, Amiga, BeOS, Unix). Même si je ne suis sans doute pas expert, je pense connaître assez bien le langage. Peut-être trouveras-tu ça traître, mais maintenant, je suis très content de ne presque plus avoir à en écrire !
Comme beaucoup de gamins de ma génération, j'ai également eu ma période "intromaker" dans laquelle je codais des effets graphiques ou sonores optimisés en assembleur sur des 386/486 (sur ce dernier, il fallait déjà prendre en compte des contraintes de pipelining, d'ordonnancement du code pour ne pas bloquer le pipelining), etc. Je suis maintenant très content également de savoir que cette pratique a disparu, et que les compilateurs s'en sortent comme des chefs.
C ou HB++ ? tel est l'étrange titre de ce fil de discussion bien animé !
Je crois que le titre exact devrait être :
C, HB++, iziBasic, PP ET tous les autres :p
En effet, je suis toujours étonné de voir chacun défendre les avantages de tel ou tel outil de développement. Alors, qu'à mon avis, tous ont une raison d'exister, des gens qui aiment programmer de préférence avec tel ou tel d'entre eux.
Et même mon "petit" iziBasic est utilisé par des professionnels au quotidien, ces professionnels seraient-ils moins respectables que ceux qui développent en C ou HB++ ?
Il y en a donc pour tous les goûts, c'est celà qui est le plus chouette.
Et nous avons bien de la chance d'avoir 3 outils de dev/palm français (HB++, PP et iziBasic). Cocorico !
Enfin, c'est un fil de discussion du même genre initié voici quelques temps sur ce même forum PalmAttitude qui a été à l'origine de cette rencontre bien cordiale entre jpa, Philippe Guillot et moi-même.
Je crois que le titre exact devrait être :
C, HB++, iziBasic, PP ET tous les autres :p
En effet, je suis toujours étonné de voir chacun défendre les avantages de tel ou tel outil de développement. Alors, qu'à mon avis, tous ont une raison d'exister, des gens qui aiment programmer de préférence avec tel ou tel d'entre eux.
Et même mon "petit" iziBasic est utilisé par des professionnels au quotidien, ces professionnels seraient-ils moins respectables que ceux qui développent en C ou HB++ ?
Il y en a donc pour tous les goûts, c'est celà qui est le plus chouette.
Et nous avons bien de la chance d'avoir 3 outils de dev/palm français (HB++, PP et iziBasic). Cocorico !
Enfin, c'est un fil de discussion du même genre initié voici quelques temps sur ce même forum PalmAttitude qui a été à l'origine de cette rencontre bien cordiale entre jpa, Philippe Guillot et moi-même.
Salut Laurent,
True! Ils sont fort ces frenchies!!! Et dire qu'en plus, PalmOS est developpé a Montpellier.... :-J
JPA
The HB++ team
CITATION
Et nous avons bien de la chance d'avoir 3 outils de dev/palm français (HB++, PP et iziBasic). Cocorico !
True! Ils sont fort ces frenchies!!!
Et dire qu'en plus, PalmOS est developpé a Montpellier.... :-J
JPA
The HB++ team
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'information, la mise en page et les images, veuillez cliquer ici.