Re: Ideas / implementation correlations.

Dear Mario,

This email is a perfect example of the kind of slop AI produces.

	Julf

On 06/09/2026 10:06 pm, Mario Marietto wrote:
> *They can be distinguished*, but they cannot always be completely 
> separated. The issue becomes particularly interesting in the case of an 
> operating system, because we need to distinguish at least three levels:
> 
>  1. *the idea or architectural principle*;
>  2. *its concrete specification*;
>  3. *its implementation in code*.
> 
> For example, imagine an operating system based on the idea:
> 
>     “The kernel must isolate drivers from the rest of the system, so
>     that a compromised driver cannot compromise the kernel.”
> 
> That is an *architectural idea*. It does not coincide with a particular 
> piece of code. You could implement it using a microkernel, isolated 
> processes, capabilities, sandboxing, hardware separation, 
> virtualization, and so on.
> 
> But if someone creates a concrete project in which this idea is 
> transformed into a *particular architecture*, with specific mechanisms, 
> interfaces, and data structures, then the distinction becomes less 
> clear-cut.
> 
> 
>       The fundamental point
> 
> Saying:
> 
>     “I reject the code, therefore I reject the idea”
> 
> is *not logically necessary*.
> 
> I can reject an implementation while simultaneously accepting the 
> principle that it is trying to realize.
> 
> For example:
> 
>     “The idea of isolating drivers is excellent, but this implementation
>     uses an IPC mechanism that is too slow.”
> 
> Here I am rejecting *the implementation*, not the idea.
> 
> But the opposite can also be true: if the code contains a particular 
> technical solution that *necessarily embodies a certain idea*, then 
> rejecting that solution may also mean rejecting that particular idea.
> 
> ------------------------------------------------------------------------
> 
> 
>       There is, however, a subtler distinction
> 
> A complex software project is not simply:
> 
> *ideas → code*
> 
> It is more like:
> 
> *ideas → architecture → specifications → algorithms → data structures → 
> code*
> 
> As you move down this hierarchy, the concrete content increases.
> 
> For example:
> 
> *Idea*
> 
>     Isolate drivers.
> 
> ↓
> 
> *Architecture*
> 
>     Every driver runs outside the kernel and communicates through IPC.
> 
> ↓
> 
> *Specification*
> 
>     The driver possesses a capability allowing it to access only
>     resources X, Y, and Z.
> 
> ↓
> 
> *Implementation*
> 
> |driver_process() ipc_send(...) capability_check(...)|
> 
> The final code is therefore a *particular realization of a conceptual 
> chain*.
> 
> If I remove the code, I do not necessarily eliminate the idea.
> 
> But if I remove *the entire architecture and all the mechanisms through 
> which the idea takes form*, then I may have eliminated the idea itself, 
> even if I verbally claim to have preserved it.
> 
> ------------------------------------------------------------------------
> 
> 
>       And this brings us to your second question
> 
>     Does someone who rejects the code through which the ideas are
>     expressed also reject the ideas underlying that code?
> 
> *No, not necessarily.*
> 
> But we need to ask *what exactly is being rejected*.
> 
> If someone says:
> 
>     “I do not want to use this code because it is written in C.”
> 
> they have not necessarily rejected the idea behind the algorithm.
> 
> If they say:
> 
>     “I do not want this architecture because it requires drivers to be
>     separated from the kernel.”
> 
> then yes: they are rejecting a *specific architectural idea*.
> 
> And there is a third, very interesting case:
> 
>     “I do not want that code, but I want to achieve exactly the same
>     behavior, using the same architectural principles and the same
>     constraints.”
> 
> Here they have not rejected the idea. They have rejected *that 
> particular expression of the idea*.
> 
> ------------------------------------------------------------------------
> 
> 
>       There is, however, a limit
> 
> Ideas in computer science are not always independent of their 
> implementation.
> 
> In a very complex system, some ideas are so deeply intertwined with the 
> concrete structure that saying:
> 
>     “I will keep the ideas but completely throw away the implementation”
> 
> can become almost meaningless.
> 
> Take a filesystem.
> 
> Saying:
> 
>     “I want a copy-on-write filesystem with efficient snapshots.”
> 
> is an idea.
> 
> But to implement it, you have to make decisions about:
> 
>   * tree structures;
>   * block management;
>   * metadata;
>   * allocation;
>   * journaling;
>   * reference counting;
>   * garbage collection;
>   * locking;
>   * transactions;
>   * crash consistency.
> 
> At that point, the collection of ideas becomes a *technology*, not just 
> a single abstract idea.
> 
> And a technology can remain recognizable even without its original code.
> 
> ------------------------------------------------------------------------
> 
> 
>       So I would formulate the distinction this way
> 
> *Code ≠ ideas.*
> 
> But also:
> 
> *Code ≠ merely a container for ideas.*
> 
> Code is a *materialization of a layered set of ideas, design choices, 
> and technical knowledge*.
> 
> Therefore:
> 
>     *Rejecting an implementation does not necessarily imply rejecting
>     the ideas implemented by it.*
> 
> But:
> 
>     *Systematically rejecting the architectural choices that make that
>     implementation possible may, in practice, amount to rejecting those
>     ideas.*
> 
> And in the case of an entire operating system, this becomes even more 
> evident: *you cannot arbitrarily separate “the ideas” from the concrete 
> project*, because part of the idea lies precisely in the relationships 
> between the components, in the interfaces, and in the mechanisms through 
> which they cooperate.
> 
> This distinction is particularly important if your question arises from 
> the problem of *porting an existing project/architecture to another 
> operating system without bringing over its code*: in that situation, you 
> need to determine which elements are /ideas/, which are / 
> specifications/, which are /technical know-how/, and which are simply 
> the /concrete expression of those things in code/.
> 
> 
> Mario.
> 
> Il Dom 6 Set 2026, 21:30 Paul Vixie <paul@redbarn.org 
> <mailto:paul@redbarn.org>> ha scritto:
> 
>     <<If you dont accept the code you also dont accept the ideas I had
>     when I have chosen what technologies put inside and how.>>
> 
>     This assertion is trivially and obviously and demonstrably false,
>     and now that you have repeated it several times without answering
>     any of the challenges or refutations which have been made in this
>     and prior threads, it discredits you as a thinker. I'll be ignoring
>     you  hence forth, to avoid useless waste of my time.
>