Tchat programmation

Bonjour,

pour ma part :

turbo PASCAL
F77
un peu de C
PYTHON
VBA

jlr

Cool merci pour vos retours. J'ai fait un peu de VB, Python et C aussi (systèmes embarqués).

Merci Tartempion pour ton exemple. C'est élégant je trouve, en effet. En Java 8, qui introduit une touche de programmation fonctionnelle, tu peux écrire les factorielles comme ça :

Code : #

IntStream.rangeClosed(1, 3).reduce(1, (x, y) -> x * y);

Cet exemple calcule la factorielle de 3.

Flo. On n'est pas des extra-terrestres non plus. C'est sûr il faut avoir programmé un peu pour s'y retrouver. Mais c'est comme si tu parles à un non-initié de "rebond sur PP" ou "rsi qui sort de la zone de surachat", il va te regarder d'un air perplexe.

C'est ça bear, quand je suis arrivée sur Andlil, je ne comprenais pas les 3/4 de ce qu'il se disait sur les files

pareil.

"Stack Overflow boiled it down to one main reason: the rise of Python can be connected to the rise of interest in data science.

One major factor is Python’s versatility. There are over 125,000 third-party Python libraries.

It’s ideal for novice software engineers, marketers, business analysts, bankers, and anyone else who wants to do more with data."
http://news.codecademy.com/why-learn-python/

Perso, je pense que Python c'est bien pour les petits projets ou les prototypes. Pas sûr que ça soit approprié pour un gros projet. Bon c'est sûr je ne suis pas objectif, mon gagne-pain c'est Java / Javascript.

https://danluu.com/empirical-pl/
The evidence behind strong claims about static vs. dynamic languages

"it’s rare to see people cite actual evidence.

Let’s take a look at the empirical evidence that backs up these claims..."

Sujet intéressant pour moi, le soucis c'est que l'auteur rejette toutes les analyses étudiées dans son post, parce qu'elles posent des problèmes de cohérence statistique principalement.

Perso, encore une fois un peu biaisé, je suis convaincu que les languages typés rendent plus productifs. Ce n'est pas pour rien qu'on voit décoller TypeScript (qui, entre autres évolutions, apporte le typage à javascript).

J'espère en discuter avec vous

Intéressante cette file.

L'élégance d'une solution, selon moi, vient de sa simplicité pour résoudre un problème à priori complexe. L'orienté objet et les possibilités d’abstractions permettent cela.

John pretty much hit it right on the money by knowing linked lists, binary trees, k-ary trees, tries, lists, heaps, queues, stacks, multidimensional ar s, hash tables and hashing. Also space, time, and complexity tradeoffs of algorithms. [...] (J'ai quelques révisions à faire perso... pas seulement des révisions du reste)

C'est indispensable de connaitre les conteneurs (ou collections) et leurs différences, complexité algorithmique (notation O) pour l'insertion d'élément, l'accès, la suppression, etc. De leur choix découle les performances de l'application, la maintenance et l'évolutivité.

Typiquement des questions d'entretiens : Différence entre une liste et un vecteur (ou ar ) ?
C'est une question ouverte qui permet de jauger du niveau du candidat.

Salut Mister Hyde. Je connaissais pas la notation O. Je vais jeter un coup d'oeil.

Il y a des articles sympa sur le net pour les questions d'interview. Pour le Java en particulier, il faut faire un max de Mock Exams, pour se remémorer (ou apprendre :p) les subtilités.

https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions

BearIsDead, tu passes des entretiens en ce moment ?

Thks Mister. Non je suis en congés sabbatiques. D'ailleurs je perds un peu la main côté programmation, il faut que je me dérouille. J'ai un projet de site Web avec un, voire plusieurs potes, je pense faire ça en Java / Spring + Angular. Ou peut-être NodeJS + Angular. Qui sait.

Je programme comme un bourrin débutant, je n'ai appris en java que le minimum qui me soit utile pour l'exercice.
J'imagine que le code ferait sourire un pro mais il fait le job. Pour l'instant cela me suffit à peu près pour transcrire les idées.
A contrario avec peu de ressources de développement cela me contraint à imaginer des algos avec une mise en oeuvre simple. Ou alors je dois passer des jours à découvrir comment coder une fonction, une idée.
Par nécessité je suis donc adepte du lean programming

Salut Euraed. Même si ça prend du temps à maîtriser, pour la lisibilité du code (entre autres) je ne peux que te conseiller d'utiliser Spring / Spring Boot, surtout si tu utilises une base de données. Ceci dit on peut écrire du joli code sans framework aussi, mais bon c'est dommage de réinventer la roue.

Enfin, je comprends bien que tu travailles sur un projet perso, donc tu n'as pas le besoin de partager ton code, ce qui rend la lisibilité du code moins importante (tant que c'est lisible pour toi :p).

Tout à fait d'accord Swing. Il faut faire simple. C'est justement le but des frameworks, qui sont issus des années d'expérience de différents programmeurs, pour rendre ton code lisible / simple.

Aussi essayer de rendre un maximummum les choses génériques, d'où la pertinence de l'abstraction.

Pour commencer en codage quel est le meilleur langage ?
Oula je sens que... Non.. Arrêtez.....

Qu'est ce que du code pro ?

C'est celui qui répond aux besoins fonctionnelles du client, en étant sans bugs, robuste, évolutif, le tout à coût raisonnable.

Pour cela, le code doit être simple, c'est à dire factorisé, utiliser judicieusement les ressources du langage (algorithmes, conteneurs, ...) pour ne pas réinventer la roue. Utiliser les possibilités d'abstraction pour faire des traitements génériques, avoir des composants réutilisables. Il doit également être lisible, testable, et éviter toutes les pratiques à risque.

Ce sont toutes ces qualités intrinsèques qui permettent de dire si le code est "pro", qui permet de maîtriser les coûts et les délais, de pouvoir donner un chiffrage réaliste pour l'implémentation d'une fonctionnalité ou d'une évolution.

C'est ce qu'on attend d'un développeur, comprendre ces enjeux, plutôt que des pisser des kilomètres de code, en abusant des subtilités du langage, et qui finiront immanquablement à la poubelle.

Mister Hyde. Attention à la "surfactorisation" quand même. A mon avis il vaut mieux, avant de généraliser le code (refactoring), attendre d'avoir bien cerné le problème, plutôt que d'écrire un code qui finit par faire tout et n'importe quoi.

Toujours se focaliser sur une définition claire du cahier des charges et du besoin client avant de vouloir se faire plaisir avec les subtilités d'un langage quelconque.

D'accord avec toi Swing. On parle d' "overengineering". Qui va à l'encontre du https://en.wikipedia.org/wiki/KISS_principle

De la "surfactorisation" je n'en ai jamais vu.

En revanche, attendre pour factoriser, c'est un grand classique sur les projets. Ça ajoute de la dette technique, pour laquelle il faut dépenser du temps et de l'argent pour la résorber mais que le client refuse, car ça ne crée aucune valeur, ce qui est vrai de son point de vue. C'est là que ton projet commence à dériver.

La difficulté pour cerner problème ou le besoin client, c'est que le client ne sait pas toujours ce qu'il veut, ne sait pas l'exprimer, est changeant. De l'autre côté, l'équipe en charge de la réalisation, aura mal compris, mal interprété, n'aura pas saisi les contraintes, les spécificités du métiers du client.

De fait, le projet va évoluer constamment jusqu'à atteindre un état qui sera accepté par le client. Pour que cela se passe bien, il faut maintenir une certaine rigueur sur le projet. (cf mon poste précédent)