Navigation

#Presentation

I do research and development in applied mathematics for digital art matters, mostly photography, typically involving some physics and computer programming. With the maths models I built, I design end-user software and applications. For the applications I built, I design websites, write documentations and shoot educational videos. For the (scattered) documentations I wrote, I designed an (unified) AI-driven search engine.

I’m one of the very few open-source developers who write down the maths before opening their IDE to code anything silly. I have lost too much time because someone (sometimes me) tried hack something quickly and validated it on a non-significant sample where “it worked”. From cursory reading of such code, I can nowadays typically predict in which cases the hacks will fail, but without being able to propose a fix, because you can’t fix something that doesn’t state its goal in maths terms (especially since it gets buried into contextual technicalities as soon as computers are involved). Theory and abstraction win over inductivism  and should be used from the inception of the project if you want to make good use of your time.

Engineering is the art of designing solutions supported by scientific knowledge and optimized by numerical simulation.

Designing is deciding, deciding is choosing priorities, and no amount of science will ever tell what you should rather choose: it is a discussion between you and your values. What science tells engineers is how to achieve a goal, not which goal to pick. What engineers sometimes forget is they are only fooling themselves when they hide behind numbers to make their choices look more objective. What non-engineers don’t know is design is not just bending technology to deliver something ASAP: technology is only one mean to an end, not the only one, not always the best one. What both — engineers or not — often overlook is it’s often better, and usually simpler, to fix workflows rather than to fix tools, which involves understanding the needs (past the requests), educating, communicating and changing habits but little to no design.1 Nevertheless, since those are typically not the forte of the guys enjoying science, technology and technics, everyone stays in their silo of expertise, looks for solutions under the lamp post , and when you have a hammer, everything looks like a nail.

Design stems from a definite goal, clearly understood, expressed in technical terms, and objectively measurable. From there, means are unrolled and tuned until we reach optimality of the solution under the given set of constraints. Hacks are thoughtless happy accidents guaranteed to backfire because they start and end with “doing”. You can’t improve on hacks, at best you can add alternative hacks. Since open-source is made of saturday-afternoon pet projects, that’s all you will get for your money though.

This is where I publish those maths, to serve as addendum to my code, and other research or reflections on design and software.


Trained in applied physics, then metrology and finally mechanical engineering, I’m only interested in scientific computation and numerical simulation of physical processes. I had to step on software engineer’s feet because it seems they can’t be entrusted neither with end-user applications nor with vector algebra2. In the process, I have grown an acquired taste for end-user interfaces design.

I only use computers to solve real-world problems that require math processing, don’t mistake me for a technophile. My super-power is I hate programming, which makes me favour lean and simple solutions requiring the least amount of code, libs, deps, tech stacks and therefore the least amount of maintenance.

In a typical day, I write C, OpenCL and Python. I had to become proficient in PHP, Javascript, LaTeX and CSS for my websites and documentations. Since I moved all my websites to Hugo and had to build a custom template from scratch, I started writing a bit of Go as well.

I am very concerned by the inflationary spiral that is software and IT : there is no concept of “enough” software, we always need another layer and it’s often to work around the problems created by the previous layer. It also turns out that the next layer will often be more CPU-hungry than the previous.

That only leads to more energy consumption, device obsolescence, and yet fails to make workers more efficient (or people happier): they have to battle against more ever-changing tools and fix more post-upgrade messes. “One-size-fits-all” ACME  frameworks are to blame here, along with the don’t reinvent the wheel dogma : people will install sprawling toolkits and bloated plugins, only to use a few features that could be replaced by 5-15 lines of custom code, just to avoid writing code themselves (or paying someone to do it). I find that people overestimate the burden that is maintaining their own simple code and underestimate the burden of debugging their whole third-party software stack through possibly-incompatible upgrades.


  1. Of course, in an economy based on selling products and in a world where people hate change, it’s more lucrative to fix tools and sell upgrades. Loop over that for 10 years and that’s how you get madness-triggering software, only good for feature fatigue ↩︎

  2. Brains shutdown when equations show up – maybe one day I will understand why –, but it’s a shame because to avoid a couple of equations, coding monkeys get dozens of PDF pages explaining what they should implement mindlessly, which give them no chance to understand when it would be good to move away from the specifications they are reading. ↩︎

 ◉ 

Latest posts

Optimize a van shelf

13 min.
A few weeks ago, I discovered the tiny world of tiny houses and camping-vans and found that quite amazing. However, the current commercial camping vans look pretty sub-optimal to me, because they are equipped with kitchen-style furniture, meaning heavy, stand-alone stuff made of chipwood/OSB panels 1.5 cm thick. See for yourself : I spent 3 years working at Polytechnique Montreal on a 280 kg solar car made of carbon fiber, fiberglass and epoxy, and embedding 6 m² of solar panels on the top shell, so, seeing such a daddy’s design add around 750 kg of equipement on top of a 6 m² cargo van blew my mind in a bad way.
Lire la suite →

Help

2 min.
This website was designed halfway between a digital book and a blog, emphasizing content structure. It is accessible in hierarchical, transversal, topical, chronological and opportunistic ways, which demands some explanations for it is uncommon. #Structure #Hierarchical access Pages are layered into sections and subsections, appearing linearly in the breadcrumbs (under the page title), and as a treeview in the left-most column on desktop. This global hierarchy is similar to chapters in books.
Lire la suite →

Pages :
 ◉ 
 ◉ 

Author

Profile picture

Patrons Income Goal

I use computers to solve real-world problems that require physical simulation and math processing with some user interface on top. My super-power is I hate programming, meaning my programs are simple, lean and to-the-point. I code mostly open-source but my days of free-software advocate ended when I started contributing to said software and realized the average open-source developer is a clueless amateur. I'm done with FLOSS "communities", birthing 5-legged sheeps nobody else wants to use, failing to see the difference between democracy and design by commitee. There is no collective intelligence where there is no structure to organize it between individually-skilled persons, and that's a strong assumption on people's invidual intelligence in a development model where having freetime is the foremost skill.

Credits

This website uses neither cookies, nor personal data tracking system, nor advertising service. Multimedia players embedded on pages can use their own cookies and trackers.