Le topic de la programmation: Et envoyez des sioux!

[Teocali]

Java avait aussi une approche très stricte de la programmation objet qui a fortement influencé le langage, notamment sur certaines construction assez rigides.

J'mettrais un bémol : ce n'est pas le language qui a poussé ces constructions rigides. De manière objective, tu peux faire des trucs super souple en java. Le problème, c'est qu'il y'avait un coté "empêchons au max les dev de faire des conneries" chez les concepteurs. Ca a donné un compilateur qui vérifiait plein de chose pour l'époque, et qui était limite magique à l'époque (je me souviens encore de ma découverte du C++ après mes premieres cours de Java, et l'horreur qui m'a saisie quand je me suis rendu compte que tu n'étais pas obligé de gérer tes exceptions déclarées), mais d'un autre coté ça a donné une bibliothèque standard (et des framework) extrêmement verbeuse, a coup de builder de factory et tutti quanti. Et c'est généralement ce dernier point qu'on reproche à Java

[Taro]

Et je ne comprends pas ce que tu reproches au C++ sur ce point.

Je l'ai pourtant couché noir sur blanc :

Un typage encore plus fort. Pareil, l'Ada va plus loin en proposant de créer des types dont on définit explicitement les dimensions et les range.

Pour illustrer avec un exemple :

subtype Temperature is Integer range -273 .. 1200;
type Sondes is array(4 .. 8) of Temperature;

Encore une fois on peut bricoler pour arriver au même résultat, mais ça ne fait pas partie du langage, ce n'est pas prévu dans sa syntaxe, et j'aurais aimé que ça y soit.

[Cwningen]

Je l'ai pourtant couché noir sur blanc :



Pour illustrer avec un exemple :

subtype Temperature is Integer range -273 .. 1200;
type Sondes is array(4 .. 8) of Temperature;

J'ai dit que je ne connaissais pas l'ada. Il n'y a rien de clair dans ta phrase. La répéter n'aide pas. Au moins avec la syntaxe, j'ai pu chercher par moi-même. Donc si je comprends bien, c'est la possibilité de changer l'intervalle utilisé pour indexer les éléments du tableau (pour ne pas forcément commencer à 0 ou 1). Avant ça, j'en été encore à l'interprétation de ducon, mais la taille du tableau fait déjà partie du type en C++.

[vectra]

Les questions de choix techno et leur justification je pense que c'est les meilleures aspects pour connaître la maturité d'une équipe.

Je me souviens encore d'une entreprise où un de nos anciens stagiaire avait fini et il me disait "ah ils ont du C++/C# là bas mais ils passent progressivement sur C++ pour les perfs", du coup je lui dit "Ah vous avez une super équipe alors. Car vous utilisez A* et c'est multi-threadable et c'est compliqué le multi-threading en C++".

Et lui qui regarde ses chaussures et qui me réponds "baaah en fait justement, comme c'est compliqué en fait non, on multi-thread pas".



Les gus sont parti de C# car "C++ c'est plus performant" pour fini avec une app pas performante car ils multi-thread pas (et le multi-threading sur C# et des lib comme le TPL même un stagiaire peut faire), je vous jure...

C'est pas la faute du langage s'ils sont cons, surtout depuis C++17.
S'il fallait prendre ce genre d'exemples pour accréditer/discréditer un langage, ceux prisés par les débutants seraient disqualifiés d'office.

[Captain_Cowkill]

Dites les canards, est-ce que l'un de vous aurait suivi une formation JavaScript en ligne qu'il aurait trouvé intéressante ? Jusque là je suivais les "cours" de MDN, mais avec JavaScript je vois bien les limites des leçons gratuites (trop d'enrobage pour rien, pas assez d'exos, explications parfois trop succinctes, manque d'exemples clairs, pas mal de coquilles...).

[Lazyjoe]

c'est compliqué le multi-threading en C++

A l'ancienne avec un peu d'OpenMP tu introduit facilement des threads. Mais sinon les threads sont dans la STL depuis C++11, et on peut même écrire des boucles "parallel_for" directement dans le langage maintenant.

[Nilsou]

Ouais très bonne remarque, le langage on s'en tape un peu la majorité du temps, surtout durant le prototypage. C'est dur de se forcer mais faut vraiment appliquer "Early optimization is the root of all evil".

D'abord tu fais le design sur le papier, ensuite tu implémentes un premier truc, et seulement après tu commences à optimiser.

C'est faux pour pleins de trucs. L'exemple avec A* dans le post juste au dessus du tient est typique : coder un A* pour que ce soit facile à paralléliser ensuite : faut le faire dés le début. C'est pas à la fin que tu prends un programme mono-coeur et que tu le parallélise.

[ducon]

Avant ça, j'en été encore à l'interprétation de ducon, mais la taille du tableau fait déjà partie du type en C++.

Je ne connais rien à l’Ada moi non plus mais ça me semble clair :
Temperature contient des entiers compris entre −217 et 1200 (ou 1199 si on utilise la variante Pythada). C’est bien un intervalle mais d'entiers (noté souvent avec des crochets doubles en maths).
Sondes est un tableau de Temperatures indexé de 4 à 8 (ou 7…)

[Nilsou]

Bon après, c'est bien que ce soit dans le langage en lui même, mais ça se fait un peu en deux coups de cuillère à pot en C++ ...

[Orhin]

Sondes est un tableau de Temperatures indexé de 4 à 8 (ou 7…)

C'est pas ce je comprend avec la syntaxe, pour moi Sondes est un tableau contenant 4 à 8 éléments.

[Lazyjoe]

C'est pas ce je comprend avec la syntaxe, pour moi Sondes est un tableau contenant 4 à 8 éléments.

Pour le coup c'est similaire à la syntaxe Fortran où on écrirait la même chose avec Sondes(4:8) (par contre pas moyen de faire des types avec un intervalle limité que je sache).

[ducon]

C'est pas ce je comprend avec la syntaxe, pour moi Sondes est un tableau contenant 4 à 8 éléments.

Ha oui, pas con.

Pour le coup c'est similaire à la syntaxe Fortran où on écrirait la même chose avec Sondes(4:8) (par contre pas moyen de faire des types avec un intervalle limité que je sache).

En Python, si.

[gros_bidule]

Question con : avec un type à intervalle limité, vous n'avez pas peur de revenir sur le code 6 mois plus tard et vous demander comment fonctionne ce truc ?
Ca me fait penser à certaines fonctions Kotlin, qui font des trucs cheloux mais qui ont un nom pas du tout explicite. J'ai ça en horreur. l'objectif premier du code c'est d'être lisible, pas d'avoir le moins de caractères possibles.

[Cwningen]

Justement, dans l'exemple de Taro, c'est pour définir un nouveau type. Donc on n'écrit pas "cette fonction prend en entrée un entier entre -273 et 1200" mais "cette fonction prend en entrée une température", ce qui me parait assez clair.

[William Vaurien]

Petite parenthèse, j'ai un voisin au chômage depuis le confinement: il bosse dans l'événementiel... L'autre jour en discutant j'ai appris qu'il voulait changer d'orientation pour devenir dev mais que popol emploi l'a envoyé chier car il est trop "diplomé" alors qu'il a 'juste' une Licence.
Je ne sais pas trop quoi lui conseiller pour un vrai changement de carrière, pas apprendre à faire 'hello world' en Python. Vous avez des idées pour relancer ce genre de profil (35 ans / diplôme qui n'a rien à voir) vers du dev employable ?

[ducon]

Ben merde, si lui avec une licence est trop diplômé, que dire de mézigue ?

[FB74]

Petite parenthèse, j'ai un voisin au chômage depuis le confinement: il bosse dans l'événementiel... L'autre jour en discutant j'ai appris qu'il voulait changer d'orientation pour devenir dev mais que popol emploi l'a envoyé chier car il est trop "diplomé" alors qu'il a 'juste' une Licence.
Je ne sais pas trop quoi lui conseiller pour un vrai changement de carrière, pas apprendre à faire 'hello world' en Python. Vous avez des idées pour relancer ce genre de profil (35 ans / diplôme qui n'a rien à voir) vers du dev employable ?

Déjà, il faudrait voir le type de formation.
Moi, je pense qu'il faudrait regarder du côté de tout ce qui est en relation directe (DURANT la formation) avec l'entreprise.

Donc contrat pro ou truc dans le genre.

L'avantage c'est que tu es payé, et que si l'entreprise te forme pendant 1 an, c'est pas juste pour un petit tour...

Il faut vraiment avoir un pied dans le monde de l'entreprise, sinon la personne va tomber sur une formation "plus ou moins académique" et sera en compétition avec des tas de gens sans expérience professionnelle.

[Taro]

Haha, c'est marrant de voir vos différentes interprétations, ça montre bien ce que je disais : la syntaxe de l'Ada est vraiment naze.
On écrit un roman pour faire deux pauvres instructions, et en plus ça n'est pas suffisamment intuitif pour ne laisser aucune place à l'interprétation.


C'est la "version ducon" qui est correcte.

Définir l'intervalle (-2 .. 2) pour un subtype Integer, ça spécifie les limites des valeurs possibles, ce qui donne ainsi un type entier pouvant prendre les valeurs -2, -1, 0, 1 ou 2.
Le but étant effectivement que les fonctions/méthodes reçoivent en paramètre un type "Temprature", par exemple, partout où ça a du sens.
Impossible de faire un cast implicite par erreur, il faut faire un cast explicite si on veut convertir une valeur depuis un autre type. On détecte ainsi encore un peu plus d'erreurs possibles, au compile-time si un cast est manquant et au runtime si l'intervalle prévu est dépassé.

Définir l'intervalle (3 .. 5) pour un type array, ça spécifie directement les indices possibles, et donc indirectement les dimensions dudit tableau, ce qui donne ainsi un tableau de 3 éléments auxquels on accède via les indices 3, 4 et 5.
Donc on peut définir des tableaux auxquels on accède depuis l'index 0, depuis l'index 1, ou encore depuis n'importe quel index. J'ai pas trop d'exemple concret qui me revient en tête pour un tableau qu'on n'indexerait ni à 0 ni à 1 mais bon, c'est possible.


Et sinon @Cwningen : j'ai donné un exemple, ok ça ne t'a pas parlé ; mais je ne suis pas censé connaître tes connaissances et je n'allais peut-être pas non plus écrire un roman pour introduire ce langage. Langage dont, encore une fois, je n'aime d'ailleurs pas la syntaxe. J'ai énuméré deux-trois points qui me manquent dans le C++, c'est tout.
Je suis pas venu me battre, alors ne sois pas si cassant dans tes messages.

[Orhin]

Définir l'intervalle (3 .. 5) pour un type array, ça spécifie directement les indices possibles, et donc indirectement les dimensions dudit tableau, ce qui donne ainsi un tableau de 3 éléments auxquels on accède via les indices 3, 4 et 5.
Donc on peut définir des tableaux auxquels on accède depuis l'index 0, depuis l'index 1, ou encore depuis n'importe quel index. J'ai pas trop d'exemple concret qui me revient en tête pour un tableau qu'on n'indexerait ni à 0 ni à 1 mais bon, c'est possible.

Mais c'est quoi l'intérêt ?

Car autant définir le nombre min/max d'éléments je vois très bien les cas d'utilisation (idem pour les ranges de nombre), autant redéfinir l'index de départ ça me parait totalement contre intuitif.

[vectra]

Petite parenthèse, j'ai un voisin au chômage depuis le confinement: il bosse dans l'événementiel... L'autre jour en discutant j'ai appris qu'il voulait changer d'orientation pour devenir dev mais que popol emploi l'a envoyé chier car il est trop "diplomé" alors qu'il a 'juste' une Licence.
Je ne sais pas trop quoi lui conseiller pour un vrai changement de carrière, pas apprendre à faire 'hello world' en Python. Vous avez des idées pour relancer ce genre de profil (35 ans / diplôme qui n'a rien à voir) vers du dev employable ?

Y'a des formations en 10 semaines cofinancées par Popol et une SSII, mais 1) c'est pas sûr que ça envoie du bois cette année et 2) c'est niveau master en général, avec une sélection sur dossier.
A voir, car c'est une voie intéressante pour quelqu'un qui n'a jamais fait d'info.
Après, à l'époque où ça embauchait, ça servait aussi à caser les emplois les moins payés et intéressants, en tous cas jusqu'à ce que les élèves prennent de l'XP.

[gros_bidule]

Petite parenthèse, j'ai un voisin au chômage depuis le confinement: il bosse dans l'événementiel... L'autre jour en discutant j'ai appris qu'il voulait changer d'orientation pour devenir dev mais que popol emploi l'a envoyé chier car il est trop "diplomé" alors qu'il a 'juste' une Licence.
Je ne sais pas trop quoi lui conseiller pour un vrai changement de carrière, pas apprendre à faire 'hello world' en Python. Vous avez des idées pour relancer ce genre de profil (35 ans / diplôme qui n'a rien à voir) vers du dev employable ?

Y'a des coincoins qui ont fait ou sont en reconversion. ils sauront aider je pense. -> Topic des carrières
edit : http://forum.canardpc.com/threads/98...ans-la-popoche

[FB74]

Y'a un bundle d'ebooks Python sur Humble Bundle:
https://www.humblebundle.com/books/u...lf-packt-books

Vous pensez que ça peut valoir le coup/ coût ou qu'il vaut mieux en rester à des trucs sur le net ?

[vectra]

La plupart des bouquins Packt que j'ai testés, franchement ils sont limites pas bons.
J'ai l'impression que Packt est aux éditeurs classiques ce que TedX est à Ted. On est parfois pas loin de l'auto-édition je trouve...

[Taro]

Mais c'est quoi l'intérêt ?

Car autant définir le nombre min/max d'éléments je vois très bien les cas d'utilisation (idem pour les ranges de nombre), autant redéfinir l'index de départ ça me parait totalement contre intuitif.

J'avoue, l'intérêt de définir l'indexation d'un tableau par des entiers de 5 à 8 par exemple, on peut parfois le chercher... ça paraît inutile et contre-intuitif.
Ce qu'il faut y voir, par contre, c'est que ça marche sur des types plus variés que les "simples" entiers de base.

Et donc, par exemple, tu pourrais très bien définir un tableau contenant des entiers, indexé via le type Temperature, et qui te servirait à stocker pour chaque valeur la conversion en degrés Fahrenheit.
Ou avoir un type enum Color qui peut prendre les valeurs Red/Green/Blue et t'en servir pour indexer un type array Pixel.
Tout en ayant les contraintes du typage fort (nécessité de passer par des casts explicites en cas de conversion, détection au runtime des valeurs non autorisées).

[Anonyme20240202]

faut le faire dés le début. C'est pas à la fin que tu prends un programme mono-coeur et que tu le parallélise.

Bah faut déjà que y'ait un besoin de parallélisation en premier lieu, et pourquoi paralléliser au niveau de l'algorithme? Si c'est des agents qui consomme l'algorithme avec de petits sets de données tu peux facilement imaginer un thread par client.

On rappelle que paralléliser rajoute un overhead potentiel, donc moins rapide que tu séquentiel si c'est pas des problèmes adaptés.

Et donc si tu détermines qu'en premier lieu tu veux paralléliser l'algo', bah ça fait partie de la phase de design que je décris. Donc on est d'accord et tu dis mot pour mot ce que je dis dans mon post, design d'abord.

Sachant que c'est tout de même extrêmement simple de déterminer si tu vas vouloir paralléliser ou non selon ce que tu fais. Volume de données/pattern des données vs. restriction hardware/réseau, contraintes de temps. Et paf tu sais si tu dois paralléliser ou non.

Et justement le "à la fin", si c'est après un succès monstre de ton produit, reprendre le design est parfaitement normal pour supporter ta nouvelle popularité. Tu as un time to market court avec un prototypage rapide qui te semblait bon, un succès inattendu arrive, potentiellement des changements à faire, hyper courant dans l'industrie.

Et je suis pas en train de dire qu'il faut prototyper à la zeub' c'est juste un exemple potentiel au pif.

[Orhin]

J'avoue, l'intérêt de définir l'indexation d'un tableau par des entiers de 5 à 8 par exemple, on peut parfois le chercher... ça paraît inutile et contre-intuitif.
Ce qu'il faut y voir, par contre, c'est que ça marche sur des types plus variés que les "simples" entiers de base.

Et donc, par exemple, tu pourrais très bien définir un tableau contenant des entiers, indexé via le type Temperature, et qui te servirait à stocker pour chaque valeur la conversion en degrés Fahrenheit.
Ou avoir un type enum Color qui peut prendre les valeurs Red/Green/Blue et t'en servir pour indexer un type array Pixel.
Tout en ayant les contraintes du typage fort (nécessité de passer par des casts explicites en cas de conversion, détection au runtime des valeurs non autorisées).

Ah oui effectivement ça peut être très utile dans ces cas.

Y'a un truc similaire en Typescript avec les types mappés où tu peux définir les propriétés acceptées/obligatoires pour un objet.
Si je reprend ton exemple du pixel tu peux faire :

// Pas obligé d'assigner des valeurs explicites à l'enum mais plus pratique pour déclarer les objets et accéder à leurs propriétés
enum Colors {
  Red = 'red',
  Green = 'green',
  Blue = 'blue'
}

// Pas de range en TS malheureusement pour l'instant, donc déclarer les valeurs de 0 à 255 est plutôt moche
type ColorValue = 0 | 1 | 2 | 4

// Record<K, V> est un type générique de base qui accepte les types de propriétés (K) et des valeurs (V) de l'objet
type Pixel = Record<Colors, ColorValue>

const a: Pixel = {
  [Colors.Red]: 0,
  [Colors.Green]: 0,
  [Colors.Blue]: 0,
} // OK

const b: Pixel = {
  red: 0,
  green: 0,
  blue: 0,
} // OK

const c: Pixel = {
  red: 5,
  green: 0,
  blue: 0,
} // Error

const d: Pixel = {
  red: 0,
  blue: 0,
} // Error

const e: Pixel = {
  red: '0',
  green: '0',
  blue: '0',
} // Error


const f: Partial<Pixel> = {
  red: 0,
} // OK

const test1 = 5
const test2: number = 4
const test3 = 4
const test4: ColorValue = 4

a.red = test1 // Error
a.red = test2 // Error
a.red = test3 // OK
a.red = test4 // OK
a[Colors.red] = test4 // OK
a['red'] = test4 // OK

Bien sur ça reste du check à la compilation pas au runtime (JS interprété oblige), mais c'est très utile.

[Taro]

Y'a un truc similaire en Typescript avec les types mappés où tu peux définir les propriétés acceptées/obligatoires pour un objet.
[...]
Bien sur ça reste du check à la compilation pas au runtime (JS interprété oblige), mais c'est très utile.

Effectivement c'est pas mal !
Et justement, je préfère ce qui est détecté à la compilation. L'Ada est justement très fort pour ça. Tout ce qui est détecté avant le runtime est bon à prendre.


(et le Python m'insupporte sur ce point)

[XWolverine]

Je ne sais plus comment ça marche, l'ADA, j'ai juste souvenir quand je l'ai vu à l'école que c'était effectivement bien rigide, notamment les casts obligatoirement explicites.

[Nilsou]

En même temps, même en C c'est considéré comme une mauvaise pratique de faire des cast implicites. Donc ça me parait pas déconnant de l'interdire carrément.

[rOut]

C'est ce que fait Rust d'ailleurs, tout est explicite, y compris les conversions entières dès que les types ne sont pas identiques.