daniel:// stenberg://

#curl decomplexification continued

https://daniel.haxx.se/blog/2026/02/24/decomplexification-continued/

decomplexification continued

Last spring I wrote a blog post about our ongoing work in the background to gradually simplify the curl source code over time. This is a follow-up: a status update of what we have done since then and what comes next. In May 2025 I had just managed to get the worst function in curl … Continue reading decomplexification continued →

daniel.haxx.se
Feb 24 at 12:09pmWeb
Show threadOliverUvFeb 24

@bagder nice work!

I think yeah, probably will take a few years of bug fixing and feature impl to get a feel for the difference in working with the new code base.

Have high doubts about any methodology that attempts to quantify this type of information. So much will depend on having chosen useful abstractions and APIs for current and future needs

Show threadDaniel GerberFeb 24
@bagder Regarding „does it matter?”: is it not absolutely necessary to be as simple as possible in order to find new maintainers or get contributions from others?
Show threaddaniel:// stenberg://Feb 24
@Gerbsen I bet it helps for that, yes!
Show threadDaniel GerberFeb 24
@bagder since you asked in your original post, it would be something that you could easily measure by asking your contributors, I guess
Show threaddaniel:// stenberg://Feb 24

@Gerbsen I think most contributors show up now (their now) because of a need and desire for something now. They don't necessarily know or can compare code complexity now vs in the past. and I bet all contributors will say that they prefer less complex code...

So I think it's hard to ask.

Show threadWouter HindriksFeb 24
@bagder Nice, now do OpenSSL! ;)
Show threadPaul Wouters 🇪🇺🇨🇦Feb 24
@bagder did you end up finding refactored function duplicates ? As in, did this create (and did you then remove) duplicate functionality ?
Show threaddaniel:// stenberg://Feb 24
@letoams not to any particular extent, no...
Show threadCausticHarmonyFeb 24
@bagder Typo: "but I it is probably "
Show threaddaniel:// stenberg://Feb 24
@CausticHarmony thanks!
Show threadechopapaFeb 24

@bagder

that reminds me to an old FORTH wisdom:

Use several short word definitions rather than one long word definition. Break your problem up.​ ​Don’t ever create a Forth word that is hundreds of lines of code long. The beauty of Forth is its ability to build upon itself, allowing you to test as you go. To this end, keep your Forth words to three or four lines of code where possible. That might sound strange if you’re used to other languages, but once you get into the swing of Forth, you’ll understand that this is a logical approach to coding.

https://udamonic.com/creating-words.html

Creating Words

​A new word is created by using a colon definition . This simple example program squares the value on top of the stack:

udamonic.com
Show threadziggyFeb 25
@bagder From my experience: improving the worst cases matters a lot. Devs don’t dare to touch too complex code, and when they are forced to do so they will make the change, usually, in a non-optimal way since they cannot really understand what’s happening. Simplifying these might end in a “ah, _this_ is what is happening here” moment