DEV Community: Laurent Franceschetti

Is Mathematics Invented or Discovered? This Answer Might Surprise You

Laurent Franceschetti — Tue, 14 Apr 2026 08:47:55 +0000

Is mathematics invented or discovered? I will share an insight about one of the oldest philosophical riddles of mathematics. And the answer might surprise you.

Whichever side you were on, it's good news and bad news at the same time:

"Invented" is the winner.
"Invented" is probably not what you thought it was.

As a matter of fact, it is nothing new. It is simply a rephrasing of principles you might already have known, either consciously or unconsciously.

The answer to the riddle is simply that the question contains a hidden ambiguity. And as you probably know, if your definition of a symbol is ambiguous (i.e. you use one symbol with two meanings, or one symbol as the alias of another), you might get two results: either a stop in error (contradiction), or an infinite loop (undecidability).

With ambiguous definitions, you cannot process that proposition "Is mathematics invented or discovered", because it would be mathematically undecidable.

Of course, someone will object, that's a a philosophical question, outside of mathematics, so it's a lost cause...

And yet, we might find a somewhat sensible way to reason mathematically about this philosophical question about mathematics.

To solve this issue we need to disambiguate: we need to split a few things in our mind. Here is a rough avenue.

First (and this is implicit in the statement of the question), we must posit a duality between the mind and reality. Let's consider them as two universes, or two sets: the Subjective (internal universe), and Objective (external universe). The Subjective universe contains ideas, the Objective universe contains things. In physics the elements of the Objective universe are called bodies, and we agree (more or less) that they are composed of particles.

In the Objective universe, discovery is the fact of getting to know, consciously, that something is objectively there. It could be an object, or a law. To discover means "to remove the veil from something"

In the Subjective universe, you can generate any idea you want, and this is the act of creation. The Objective (physical) universe does not afford such freedom; it seems to operate under certain stable laws, that cannot changed on a whim. The Law of Gravity is to be obeyed, and Mother Nature makes a better job at exerting general surveillance and ruthlessly enforcing it, than the best secret police force in a totalitarian state. What you can do in defiance, is only two things: to perceive what is there, and to act in an effort to make things go your way, within the Law.

Mathematics is symbol processing, so where does it belong to? To the Subjective universe. Of course the paper, the pen, the computer, the blackboard, printed page or monitor to visualize results are real: they belong to the (Objective set). They are three-dimensional, you can feel them. But the concepts of Mathematics? You cannot touch them, you cannot feel them, you cannot perceive them. The only way you can perceive them, is by creating them first. In your mind. It is both odd and interesting that you can communicate about them to another person; but only to a person who has created them first. In their mind. You use reality to communicate about Mathematics (voice, paper, etc.).

Mathematics uses symbols as its raw material: they are ideas, elements of the Subjective universe, but with a very special, interesting property. Indeed, what is a symbol, such as the letter A, the digit 1, or an emoji, etc.? It is common knowledge that it has both form and meaning. We can state this in the following way: it is a pair of elements, one in the Objective universe (a form), and one in the Subjective universe (an idea). The technical term that embodies this duality is ideogram: literally, an idea (ideo-) materialized as a mark (-gram). It's quite simple: think of these pairs (idea, object) as stitches between two surfaces (the Objective and the Subjective). The idea part of the symbol has a "ghost" in the objective universe, and the physical part of the symbol has a "ghost" in the objective universe. You can conceive the symbol is a stitch between the two parts; or say that the idea and the thing are a stable reflection of each other.

What is reasoning, in a mathematical sense? It is clearly an operation of the Subjective universe. If you look carefully at it, it is transformation of symbols, thanks to general rules that are stable, as well as constraints you chose to apply to your specific problem. It is the rules and constraints that allow reasoning. Reasoning in the mathematical sense, should run somewhat parallel to the evolution of the Objective universe, to be useful. By being useful, we mean solving problems.

Everybody knows, that mathematics is about solving problems. A problem is reflected in the subjective universe; but ultimately is in the objective universe, otherwise it wouldn't be a problem.

If you you use arithmetics to count units of sheep or quantities of grain, it has some use, only to the degree that it allows you to predict, or decide about, the physical (objective) universe. Perhaps, the detour might be very circuitous; but in the end, it will have to have a reflection in the physical universe. Even the most abstract theory, such as topology (the study of relation between objects) is useful to the degree that it solves problems in the objective universe. And solving problems is necessary for survival, in plants, animals and human beings.

A good metaphor of the two-universe idea is: *Mathematics is a superb map-maker (Subjective), but it never walks the terrain (Objective) *. A map gives you the places of trees, houses, streets. But they are symbols for trees, houses, streets. The map has no idea of what they are; it cannot experience them, feel them, know them. Yes, one might argue, but what if you enriched the map? Add pictures, temperatures, humidity, etc. You would have just enriched your symbols, and it's still symbols. You could go to infinity, it would just be symbols, reducible to 0s and 1s. Symbols. Always symbols. That's all it is and will be. Always and forever.

The map makes sense only thanks to the little stitches. The coordinates must point to an actual location in the Objective universe. The temperature measurements must corresponds to particles in motion, the humidity to the presence of water molecules, etc.

You could say that the map is a physical object actually since it needs to be on paper or a screen to be perceived. Or, is it? No it's just little blobs of color (call them dots, or pixels, if you wish). It is you, thanks to your symbolic processing engine of the mind, who are (consciously or unconsciously) parsing those patterns of dots, isolating them into symbols, and arranging them in a data structure. You can delegate that process, partly, to a machine, but that's still the same process.

All right, then what about reasoning? It is the act of observing and, with symbolic reasoning, arriving a new, useful conclusion about reality, to solve problems in order to survive. The subtle thing about reasoning is that it required a mathematical process, i.e. in involved the manipulation of these stitched ideas called "symbols". So in order to arrive at a useful, problem-solving conclusion, you had to make sure that the stitches of your symbols were still attached to their counterparts in the physical universe.

In mathematical terms, you had achieved a first transform from the Objective universe to the Subjective Universe, and then a second transform from the Subjective univers to the Objective one. In the simple example, you had four sheep in one place, and three in another. You did not have to put them all together physically in one place and count them. You could transform the problem in 4 + 3 = 7, then do a transform and no realize that you have seven sheep in the physical universe.

Perhaps you might have understood my point just with the above, but let's add one more concept: convergent evolution, a process that evidently applies to all living beings, including human beings. What is it? Convergent evolution, is the rule that two living beings (tree, animals) even completely unrelated genetically, culturally, etc., attempting to solve a similar problem will eventually tend to similar, optimal solutions.

A clear example is that completely unrelated animals, separated by millions of years (or possibly galaxies) will arrive at similar forms, in they find themselves in similar conditions. An example is carcinogenesis where "crab-like" creatures repeatedly evolve in shallow coastal waters. That's because that body-plan is fairly optimal for those conditions. Another example is the striking similarity of shape between sharks and dolphins; the reason has to do with hydrodynamics (the forces involved in an aquatic environment) and ultimately the geometry of the objective, tridimensional universe.

And geometry is the hint here. Mathematics will converge toward laws of the physical universe (or accurately it will be able to project them on laws of the physical universe), because of the fundamental axiom that it must solve problems of the physical universe. That's convergent evolution, which is simply that the space of optimal solutions is finite, within a stated set of constraints.

Mathematics is a subjective space of possible problem‑solving structures,with problems originating in the objective universe.

That means that mathematics is undoubtedly created; that much is obvious. But is constrained by the stitches of its symboles with the objective universe, which must continue to hold. Hence the rules and constraints that it evolves are led to go into a certain direction, toward certain optimal decisions, which have some relation with the laws of the physical universe.

That explains why mathematics can support experimental sciences by confirming measurements and predicting them. That's why mathematical creations sometimes lead to actual discoveries in the objective universe.

The answer is extremely simple:

Mathematics is created and always created; but not in any way because it carries with it symbols of the object universe. That's why it leads to discoveries in the objective universe.

And that is the process that is defined invention. Invention is not pure creation, and it is not pure discovery.

It comes from Latin in- "toward", and -venire "to come". That's not pure, imaginative creation. That's following a map, to arrive at the destination. And all journeys in Mathematics eventually lead to the objective universe.

The answer is: Mathematics is _both: creation and discovery; and connecting the two with mathematical reasoning is called invention.

Solving the venv headache with a small utility?

Laurent Franceschetti — Mon, 30 Mar 2026 14:41:33 +0000

Python’s virtual environments (venvs) are great — until you actually try to use them.

Every project has its own .venv, but the moment you move around your filesystem, you’re stuck manually running:

source .venv/bin/activate

…over and over, in every project, forever.

You have to activate the venv in every shell where you are.

WHY? The flaw is structural: using environment variables for activating the venv was a design error. The reason is that it's impossible for a program to modify the shell environment it was launched from. There is no way around that...

Many tools, like git had already solved this problem decades ago, without environment variables: they automatically discover the nearest repository by walking upward through parent directories.

So why not do the same for Python?

🔍 `venv`: Find the nearest `.venv` automatically and activate it

Drop this into your .zshrc or .bashrc:

# -------------------------------------------------
# Activate the Python virtual environment
# -------------------------------------------------
# venv: search upward for the nearest .venv directory and activate it
venv() {
    # Start from the current working directory
    local dir="$PWD"

    # Walk upward until we reach the filesystem root
    while [ "$dir" != "/" ]; do

        # If this directory contains a .venv folder, we found the environment
        if [ -d "$dir/.venv" ]; then

            # If this venv is already active, do nothing
            if [ "$VIRTUAL_ENV" = "$dir/.venv" ]; then
                return 0
            fi

            echo "Activating venv at $dir/.venv"

            # Use 'source' so activation happens in the *current* shell
            # (a script cannot do this — only a function can)
            source "$dir/.venv/bin/activate"

            return 0
        fi

        # Move one directory up and continue searching
        dir="$(dirname "$dir")"
    done

    # If we reached the root without finding a .venv, deactivate if one is active
    if [ -n "$VIRTUAL_ENV" ]; then
        echo "Deactivating venv at $VIRTUAL_ENV"
        deactivate
    else
        echo "(No .venv found in this directory or any parent.)"
    fi

    return 1
}

Why this works

It’s structural: it walks up the directory tree, just like Git does.
It's a shell function so it runs in the current shell so it can modify the current process' environment; and for that it can use source as an escape hatch.
It’s predictable: it only activates when you ask it to.

This gives you a clean, deterministic workflow. Just type:

venv

No matter where you are inside the project, the right environment activates.

🧹 Optional: Add a `devenv` to deactivate

If you want symmetry:

devenv() {
    deactivate 2>/dev/null || echo "No active venv."
}

🎯 Final thoughts

Python’s tooling ecosystem is full of “activation rituals” that hide what’s really happening. This tiny function cuts through all of that and gives you a simple, structural rule:

Activate the nearest .venv — nothing more, nothing less.

It’s small, sharp, and honest. Exactly the kind of tool the shell excels at.

YAMLpp is renamed to Protein

Laurent Franceschetti — Mon, 12 Jan 2026 14:33:08 +0000

The YAMLpp language (introduced in that article) evolved a lot, particularly with the introduction of imported modules, and it deserved a better name to describe what it could do for project developers or people involved in system administration or deployment.

Nowadays, a lot of tools ara data-driven. You describe the result you want, and the system figures out how to produce it.

The original name YAMLpp was a reference to its basic syntax (it is YAML-compliant) and it initially produced YAML.

But Protein is so much more than that. It is a data composer and a templating tool.

A data composer can be seen as similar to a typographical composer: you start from a small set of data, and you use that too to compose your data (arrange them in space) in the same way as you would lay out a small set of a letters on a page, to form a text. You can output formally correct data structures (typically in YAML or JSON), or store them in files, for later use.
A templating tool: you can also use the embedded templating engine (Jinja), to produce output files, typically in HTML format; or produce Javascript snippets.

Protein is simply regular YAML, with commands called constructs (which are simply keys starting with a dot, such as .do, .foreach, etc.). Protein is essentially a tree builder and transformer.

The result is surprisingly effective, typically for web development: in a few lines of code (it's YAML) you describe what YAML or JSON you want to produce, as well as HTML, Javascript, etc.

You don't have to worry about boiler plate any more, or about repeating the same data across different files; Protein helps you producing them from one single source (or a set of source files).

Protein has functions with their own scope as well as modules. The "magic" is done through the Jinja templating engine, which can produce new YAML structures.

Furthermore, you can define your own functions to be used in Jinja (developed in Python). Hence you can use Protein for what it does best (composing and templating), and delegate complicated and delicate calculations to Python. You get the best of both worlds.

Protein is installable as a Python package:

pip install protein-lang

Protein:

🚀 YAMLpp: An DevOps Project is Making a Big Leap Forward

Laurent Franceschetti — Fri, 19 Dec 2025 14:28:14 +0000

If you’ve ever worked with YAML at scale, you’ve probably hit the same wall: YAML is great for configuration, but it’s static. Too static. Real‑world systems need dynamic behavior — templating, reuse, conditional logic, environment‑dependent values, and the ability to generate multiple YAML outputs from a single source of truth.

A few weeks ago, YAMLpp was introduced as a macro language for dynamic, self‑generating YAML. It extended YAML with variables, conditionals, loops, imports, and even Python integration. It was a promising idea… but the implementation was early, experimental, and not yet ready for broader adoption.

That has changed.

Today, YAMLpp has quietly taken a major step forward, toward being a fully feature language.
Here’s what’s new.

✅ A more robust execution model

YAMLpp’s macro engine manipulates the YAML tree itself, not just text. This is powerful, but it also means the interpreter must be extremely disciplined.

Recent improvements include:

Better separation between parsing, evaluation, and emission
More explicit handling of Jinja expressions
Cleaner error messages
More deterministic behavior across Python versions
Extensive testing

This is the kind of progress that makes YAMLpp feel less like a prototype and more like a language you want to trust in production.

✅ Documentation that reflects reality

The ReadTheDocs site has been updated to match the current state of the project. The original DEV.to article introduced the vision; the docs now show how to actually use YAMLpp today.

This includes:

Clear examples
Updated syntax
A more accurate description of the macro language
A better explanation of how YAMLpp transforms YAML trees

✅ Ability to read databases

You can know load values no only from JSON, YAML or TOML files, but also from relational databases.

This can be done with the .def_sql, .exec_sql, and .load_sql constructs.

See explanation on documentation page.

✅ Exporting files

You can now instruct your script to export files (not only in YAML, but also JSON or TOML), with the .export construct.

See explanation on documentation page.

🎯 Why this matters

YAML is everywhere — Kubernetes, Docker, CI pipelines, IaC, cloud deployments, microservices, ML workflows. But YAML itself hasn’t evolved.

YAMLpp is one of the few projects trying to push YAML forward without breaking compatibility. It respects YAML’s strengths while giving it the dynamic capabilities modern systems need.

If you’ve ever wished YAML could:

reuse values
generate multiple files
adapt to environments
include logic
import other YAML files
integrate with Python

…YAMLpp is worth watching again.

✅ Want to explore?

GitHub: https://github.com/fralau/yamlpp
Docs: https://yamlpp.readthedocs.io
Pypi: https://pypi.org/project/yamlpp-lang/
Original DEV.to intro: https://dev.to/fralau/yamlpp-is-dynamicself-generating-yaml-2cb8

The project is still small, but the ideas are big — and the recent progress shows that YAMLpp is entering a new, more mature phase.

If you’re interested in dynamic configuration, DSLs, or YAML tooling, now is a great time to take another look.

Are Blockchains Behaving Like Beehives?

Laurent Franceschetti — Wed, 10 Dec 2025 10:58:45 +0000

I would like to submit a thought that people interested in blockchain and crypto would understand better than others.

Did you know 🐝 𝗧𝗵𝗲 𝗕𝗲𝗲𝗵𝗶𝘃𝗲 𝗣𝗮𝗿𝗮𝗱𝗼𝘅 𝗼𝗳 𝗕𝗹𝗼𝗰𝗸𝗰𝗵𝗮𝗶𝗻 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝘁𝗶𝗲𝘀? All large blockchain communities, despite being born with decentralized rules, will always result in centralization.

𝗕𝗹𝗼𝗰𝗸𝗰𝗵𝗮𝗶𝗻 𝗰𝗼𝗺𝗺𝘂𝗻𝗶𝘁𝗶𝗲𝘀 𝗮𝗿𝗲 𝗹𝗶𝗸𝗲 𝗯𝗲𝗲𝗵𝗶𝘃𝗲𝘀: decentralized by design, yet centralization emerges as they scale.

That's a property embedded in the rules of nature.

In nature, thousands of bees coordinate in a decentralized way, through elementary self-contained algorithms and simple communication protocols — foraging, cleaning, defending. But one queen becomes the reproductive center. If she dies, the hive looks alive for a while, yet the survival chain is broken and collapse is inevitable.

Blockchain mirrors the structure of a beehive:

𝗪𝗼𝗿𝗸𝗲𝗿𝘀 = everyday participants transacting on‑chain.
𝗦𝗼𝗹𝗱𝗶𝗲𝗿𝘀 = validators and consensus enforcers.
𝗗𝗿𝗼𝗻𝗲𝘀 = miners and liquidity providers.
𝗤𝘂𝗲𝗲𝗻𝘀 = custodians, issuers, foundations reproducing credibility and continuity.

Unlike in nature, blockchain hives often tolerate 𝗺𝘂𝗹𝘁𝗶𝗽𝗹𝗲 𝗾𝘂𝗲𝗲𝗻𝘀 — exchanges, stablecoin issuers, foundations — fragmenting the swarm into overlapping sub-colonies. This poly‑queen structure is both the 𝗶𝗻𝘁𝗿𝗶𝗻𝘀𝗶𝗰 𝘀𝘁𝗿𝗲𝗻𝗴𝘁𝗵 𝗮𝗻𝗱 𝘄𝗲𝗮𝗸𝗻𝗲𝘀𝘀 of the ecosystem.

The 𝗦𝘁𝗿𝗲𝗻𝗴𝘁𝗵: decentralization at the core of the system creates resilience.
The 𝗪𝗲𝗮𝗸𝗻𝗲𝘀𝘀: continuity depends on central “queens.” If a 𝗾𝘂𝗲𝗲𝗻 𝗱𝗶𝗲𝘀 — for example, an 𝗲𝘅𝗰𝗵𝗮𝗻𝗴𝗲 𝗴𝗼𝗲𝘀 𝗯𝗮𝗻𝗸𝗿𝘂𝗽𝘁 — its part of the ecosystem dies.

In fact, the death (bankruptcy) of a queen could destabilize others, in a domino effect and lead to the 𝗰𝗼𝗹𝗹𝗮𝗽𝘀𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗯𝗲𝗲𝗵𝗶𝘃𝗲, propagated by panic; in finance this is called the 𝗛𝗲𝗿𝘀𝘁𝗮𝘁𝘁 𝗥𝗶𝘀𝗸 -- from the name of a German bank, in 1970s, whose bankruptcy nearly collapsed the national banking system, because of the late settlement of transactions.

In the Bitcoin ecosystem in particular, the Herstatt Risk should be seriously considered, because it is an existential risk -- admittedly, it would not kill the blockchain itself, but it could seriously hurt the market value of Bitcoin... making the currency less desirable; and in the extreme, it could make that currency pointless.

Exchanges can take measures to protect themselves against the Herstatt Risk, using the blockchain to settle their mutual debts. However, it can be shown that there will always be a residual risk. And it requires, also, that the community becomes aware of the Herstatt Risk.

👉 The 𝗕𝗲𝗲𝗵𝗶𝘃𝗲 𝗣𝗮𝗿𝗮𝗱𝗼𝘅: decentralized by design, but centralization inevitably emerges with scale. And with centralization comes the concept of 𝗱𝗲𝗮𝘁𝗵, which is a mechanism rooted in nature, which is necessary to any ecosystem. So part of the game for any blockchain community, is to find strategies avoiding the risk of death for the whole colony.

What do you think? Do you see how exchanges could be affected by the Herstatt risk?

(Article adapted from a post on Linkedin).

YAMLpp is dynamic,self-generating YAML

Laurent Franceschetti — Tue, 02 Dec 2025 11:15:36 +0000

YAML is a great file format, used for writing configuration files; and more and more, as a foundation for Domain Specific Languages (DSLs), such as script files for Github workflows, Docker or Kubernetes.

How to make YAML dynamic?

We have all, however, suffered from a frustration: YAML is fundamentally a static file format. How can we make it dynamic?

It starts with the fact that some string, like http://dev.company.local appears several times across the files.

server:
  url: http://dev.company.local
  ...

documentation:
  url: http://dev.company.local/docs
  ...

And the day that address changes, what do we do?

Do a search/replace in the config files? Nah... this is brittle and things will get worse before they get better.
Define constant values with anchors (&), and then use aliases (*) to refer to them in the rest of the YAML file. This is a really neat feature, which gives YAML an advantage over formats: now you can put your constants on the top of the file. Anchors don't need to be strings or numbers (foo, or 5), but can also be maps or sequences ({foo: 5, bar: 6}, or [foo, bar, baz]). However it doesn't solve many cases where it's more complicated than a simple change of code snippet. A "small" change of parameter (from dev to test and from test to live) leads to significant changes in the YAML tree.
All right, then solve it with a little bit of templating, using Jinja (Python) or the Go native engine. Solved! ...Really? Everything is fine for a while, and then the workflow crashes because some corner case broke the YAML syntax. And we start fiddling-fiddling with spaces and escaping and newlines... and after 5 or 10 abort-debug-rerun cycles, the delivery is running late.
OK, what we can do now? Use a preprocessing language guaranteed to produce valid syntax, like Jsonnet for json? That wil work, for sure. However, you have now a friction problem: it's new language with its own syntax and file format, which requires implementing its own toolchain (Jsonnet is not json, so editor add-ons, parsers, interpreters, libraries, etc.) and you will need to drive the team through the learning curve of that language with its own syntax and semantic. Will you implement a serious project... or will you have a coffee break at that point, and keep doing things the same old way?

Enter YAMLpp

Faced with that problem, I decided that it needed a straightforward solution, which required basically only one utility (a pre-processor) to convert files into static YAML, and would change nothing else anywhere.

Enter YAMLpp (YAML Pre-Processor). It is a language that makes YAML dynamic, but it is itself YAML. So you can use your current editor which does your color highlighting, syntax checking, and so on.

Let's start with a Hello World example:

.context:
  name: "World"

message: "Hello {{ name }}!"

I don't think there is a lot to explain here. .context is called a construct, because it 'constructs' (builds) a YAML sub-tree or does something useful; in this case it defines a variable name and leaves no trace.

All constructs start with a . (a dot). In YAMLpp, .context is known as a keyword.

Then message contains a string that will be interpolated using the name variable.

Here is the result:

message: "Hello World"

As you see, the node .context disappeared. That's a rule for all YAMLpp constructs: they disappear and never make it to the target file.

YAMLpp is a metaprogramming tool

It goes much further than that.

It is a macro language written in YAML, the same language as the target language YAML.

.context:
  platform: dev

server:
  .if:
    .cond: "(platform, {{ prod }})"
    .then:
      url: prod.machine.local
      ...
    .else:
      ...
      url: dev.machine.local

The result is thus:

server:
   url: dev.machine.local
   ...

The .if construct is expanded: .if, .cond, .then and .else keywords will disappear, and only the intended final YAML nodes will remain.

For anyone who had anything to do with LISP or one its offspring languages, you know that a language that generates itself through macros, is a huge deal, because it opens the doors to meta-programming. In essence, are able to create your own Domain-Specific Language (DSL), for configuration or scripting.

For the others for whom this might sound a little too abstract: what you write in YAMLpp is still YAML, but allows you to manipulate your target YAML tree in any way you please. You are now able to express high-level concepts in your config file or script in a way that is meaningful to you and your team (expressive, shorter, non-repetitive), which will be expanded into a form (YAML) that the machine will be able to test/interpret correctly and that everyone else will understand -- because its part of the standard specification.
So now, YAML can be either dynamic (when it contains YAMLpp keywords) or static (without them). But regardless, it is still valid YAML.

Where do I go from there?

A working prototype was developed in Python and it already has its test suite (with pytest).

To install it:

pip install yamlpp-lang

You just need one command:

yamlpp input.yaml -o output.yaml

For more information see the Github repo and the documentation on ReadTheDocs.

You can also look at a webpage containing two realistic use cases, one for Kubernetes and one for Docker.

Anyone had personal experience learning Go from a previous experience with Python? Apart from the obvious differences (compilation, static typing, composition instead of inheritance,etc.), what was most significant?

Laurent Franceschetti — Tue, 02 Dec 2025 07:16:17 +0000