Pourquoi la programmation fonctionnelle n’est-elle pas la norme?

Le genre de talk que j’adore, car il mĂȘle programmation et histoire et offre un recul dont on manque souvent cruellement.

Il semble que ce soit dĂ», comme bien souvent, Ă  un mĂ©lange de successions d’Ă©vĂšnements invĂ©tables mĂȘlĂ©s Ă  des coups du hasard. L’appellation "orientĂ© objet" elle-mĂȘme n’est pas anodine…​

Richard Feldman liste, comme causes principales de la dominations des langages orientés objets (O.O.) :

  1. Les killer apps (Ruby on Rails pour Ruby)

  2. L'exclusivité de la plateforme (Objective C, Swift, JavaScript)

  3. La possibilité de transitioner facilement depuis un langage populaire (C++, Kotlin, TypeScript)

L’auteur retrace ce qui a menĂ© au paysage actuel fait de JS/typescript, ObjectiveC/Swift, C/C++, C# et Java principalement. Mais il omet peut-ĂȘtre aussi de noter :

  • La plupart des langages sont des blue collar languages, acceptant une hybridation plus ou moins forte entre les paradigmes, et ne se soucient pas trop d’un forme de "puretĂ©" souvent plus marquĂ©e dans les langages fonctionnels;

  • Les GUI des annĂ©es 1980-1990. Le mĂ©canisme d’hĂ©ritage O.O. pour des composants techniques type widgets est vachement pratique (Delphi, PowerBuilder), mĂȘme s’il est Ă  dĂ©conseiller en gĂ©nĂ©ral (Effective Java, item 16, et il existe un concensus dans d’autres langages).

Et de conclure que peut-ĂȘtre, l’heure des langages fonctionnels n’est-elle tout simplement pas encore venue.

 Elon Musk - interview par Lex Fridman

RĂ©sumĂ© d’une longue et passionante interview d’Elon Musk par Lex Fridman au sujet de Tesla, de la conduite autonome et de l’IA.

La conduite autonome se nourrit de donnĂ©es. GrĂące Ă  ses vĂ©hicules en circulation avec la fonction AutoPilot d’aide Ă  la conduite, Testla collecte la quasi totalitĂ© des donnĂ©es disponibles. Le matĂ©riel installĂ© sur les voitures est dĂ©jĂ  apte Ă  la conduite autonome. Le logiciel doit par contre encore progresser. Le coĂ»t des mises Ă  jour est marginal - les propriĂ©taires de Tesla bĂ©nĂ©ficient dĂ©jĂ  d’amĂ©liorations rĂ©guliĂšres de l’AutoPilot. Chaque fois que l’AutoPilot ne parvient pas Ă  gĂ©rer la situation et rend la main au conducteur est une occasion de l’amĂ©liorer.

La supervision de la conduite par un humain sera rapidement sans pertinence Ă  partir du moment oĂč la machine conduira mieux qu’un humain. "Mieux" s’entend par rapport aux nombre d’accidents, de blessĂ©s et de dĂ©cĂšs. La question reste ouverte mais Elon cite un seuil de 200% d’amĂ©lioration Ă  partir duquel il vaut mieux laisser la voiture conduire elle-mĂȘme, et oĂč laisser un humain intervenir devient mĂȘme contre-productif.

Elon compare cela Ă  la fonction d’opĂ©rateur d’ascenseur. Aujourd’hui, personne ne songerait confier cette tĂąche Ă  un opĂ©rateur humain qui actionnerait un levier pour commander l’ascenseur comme c’Ă©tait le cas autrefois. Confier cette tĂąche Ă  une machine est moins dangereux.

Un jour, on trouvera incongru de laisser tout un chacun se déplacer dans un engin de 2 tonnes comme bon lui semble.

Les recherches actuelles nous mĂšneront-elles vers une "intelligence gĂ©nĂ©rale"? La question reste ouverte. CrĂ©era-t-on une IA capable de sentiments? Cela pose la question des sentiments : sont-ils distinct d’un processus physique?

Enfin, quand on lui demande quelle question il poserait si le monde dans lequel nous vivons Ă©tait une simulation, il rĂ©pond : "Qu’y a-t-il en dehors de la simulation?".

 Freelance vs employee

"We think an employee would be more engaged in the company and in the project than a freelance". And also: "would you consider an employee position?"

These are sentences I hear nowadays, as I am looking for a new gig in the software development field. Probably a nice long-term project will catch my eye. In some cases, my freelance status will become the number one hindrance. Not my skills. Not my attitude. Not my way of working. My administrative status.

How odd is this, in a market where experienced software developers are in very short supplies?

The situation may be specific to Belgium. For some reason, the vast majority of my fellow senior colleagues are freelancers rather than employees. In my experience, it is not the case in the financial sector for instance, where there is also a strong shortage of available (wo)manpower. But that’s a reality.


A colleague will be a good fit if they have the right mindset and skills, and if your company is true to its values. They will be dedicated if they are motivated individuals and if the project is honest and worth it.

This has nothing to do with a freelance or an employee status.

Some good reasons

  1. We get subvention for an employee, not for a freelance

  2. Employees are taken into account to value the company, not freelancers (important for investors)

I hate it when it is the case, but these are valid reasons for startup at an early stage. Investors are wrong but I’m not arguing with you.

Some less good reasons

Or at least reasons for which I want to offer a rebuttal. Reasons to avoid a freelance worker usually fall in one of the following categories:

  1. A freelance will be less "engaged", "involved" or "committed"

  2. A freelance is way more expensive

  3. A freelance will have a hard time integrating with the team and accept the company culture

  4. Freelance contracts are for short-term missions only

But they hold after analysis.

Dedication  Like any serious IT professional, I value my reputation. I would not be in a good position if I had not been truely dedicated to my previous jobs, or if I had left customers hanging because I was busy working on something else. The Belgian IT world is a small world. Only a fool would ruin their street cred for a few bucks. To a freelance, reputation is everything. And you cannot keep it by being distracted, inconsistent or not caring about your customer.

Cost  A freelance seems more expensive at first sight. Beware not to compare apples and pears though. If you account for eveything, you’ll find out that the apparent cost is not all. On top of the gross salary for an employee, you have paid holidays, training (you pay for the conference and for the salary at the same time), extra legal pension plan, hospitalisation insurance, social charges, meal vouchers, laptop and screen (plus the IT support for it, including system restore and repairs when needed), payroll processing costs, company car (including contract management and the overhead when it sits idle in the carpool). You support the risks in case of sickness (up to one month), have asymetrical notice period in favour of the worker, and a rigid legal framework to dismiss the employee. And plenty of other things I’m sure I have overlooked.

These are all good things, don’t get me wrong! I’d ask you every single one of them in writing signed in blood if I were to become your employee. The point is that you don’t have to cover those costs with a freelance. All in all, the remaining difference is small and accounts for the increased flexibility and the drastic reduction of the risks.

Culture  A freelance has typically seen many places and can bring you new expertize and ideas. By nature, I enjoy discovering new ways of thinking and different work cultures. I’d be a very unhappy freelancer if I was not open and ready to embrace something different and something new each time I started a new contract - as long as it suits me, of course, and this is regardless of my status. The only reason I would feel like an outsider is if you treat me like one.

Short-term Freelance contracts were maybe intended for short-term missions at some point, and they still fill that niche very nicely. But that is simply not the case anymore.

Check the candidate’s background. Find out how they work and how they think. Don’t dismiss her or him based on assumptions.

Advantages are overlooked

There are obvious advantages for a company to hire a freelance.

Flexibility  I push the freelance game to the max. You want zero notice period, as opposed to a legal several months for employees? Fine (but it will go both ways). You might need to reduce my workload for some period? I can live with that. Granted, not all freelances accept to go that far. But the engagement is typically Ă  la carte.

Batteries included  As a freelance, I come equiped with full metal jacket. There is no need to discuss all the expected advantages listed earlier and to enter somewhat painful negociations. There is no risk that the one-size-fits-all compensation package will get in the way, as I’ve made my own already. No need to discuss or negociate anything other than a rate and payment terms. What a refreshing feeling. If need be, I’ll take on my personal time to get up to speed with some technology.

Cost of opportunity

Considering that most (or at least many) experienced developers are freelancers, you deprive your company from perfectly valid candidates by simply discarding them. In a market where there is a huge shortage, ask yourself if this is a sound business practice.

Just like a slow or clumsy recruitement process puts you at a disadvantage in a fast-moving market, there is an enormous cost of opportunity for ignoring future collaborators solely based on their administrative status.

Blurred lines and convergence

Employment contract finds its root in a distant past, where the company or the boss was a provider and a caretaker for its workers. People would stay for a extended period of time at the same place. If was not uncommon for some persons to work their whole careers for the same company. Often a factory shaped the social landscape. Hiearachies were strong. There was a strong sense of deference to the boss. Even before WWII, history is filled with social progress gained from social fights as workers were trying to shift the balance towards greater respect of their condition.

The strict legal framework we find nowadays comes in straight line from that era.

Freelancing on the other hand is derived from free enterprise.

How both types of workers managed to eventually perform similar tasks in a similar team configurations remains an open question (really, feel free to shed some light). Both contracts seem to have converged a lot in practice, while remaining so opposite in their nature and design.

It is a sign that we have not collectivelly figured out a modern, unified framework for work relationships yet.

In practice, mature and modern companies allow for flexible schedules. Working remotely once a week is not unusual anymore. There is still the essential element of "control and surveillance" imbued in the employement contract. But it certainly does not mean much for senior staff that should benefit from a large autonomy in their work organization. And on the other hand, the freelancer is subject to justify its work. If not legally, at least in practice. The lines are blurred.

If your company is keen on enforcing the "command and control" aspect, then indeed a freelance contract is not for you. Whether this approach is healthy is a question left to the reader.

On the other hand, if you don’t, is the freelance vs employee status relevant?

Care for an employee contract?

It will not come as a surprise that, for me, today, the answer to this question is "no". I have organized my "legal" life in a certain way, and my company is a key part of it. Changing for the sake of it would be a huge hassle - specially if I were to restart it at a later stage.

On the other hand, hiring me as a freelance would not be that hard for you so I’ll ask instead…​ Would you consider hiring a skilled and dedicated freelancer for the job?

Avoid recruitement agencies

Oh yes, one last thing. As much as possible, avoid recruitment agencies. They bring limited added value. Most of them turn out to be an impediment for both parties. Seriously, I’ve stopped counting how many times the recruiter had little to no clue about the actual job. This should concern you way more than the freelance status itself. Hiring is the most important thing your company can do and outsourcing it may not be the best way to do it.

Looking for passionate developers? Check us out.

Older posts are available in the archive.