>Tada!

Looks like you defined a new object. Then placed two objects into the the new object as dependencies. Sure You can call it composition. But that's not the composition that I'm talking about. I specifically defined what I'm talking about in the first post so that it could be referred to rather than everyone needlessly going in circles talking about different definitions of composition. Here let me copy and paste it here for you as an example:

"The solution to incremental changes is to develop your app in a way where every unit of computation is compose-able under a strict rule. Meaning I can write a universal function compose(A,B) = C and that function can compose any primitive. Then you build complicated logic just like how you build a wall from a set of bricks... form complicated logic as a composition of more primitive logic all the way down."

Tada!

> Those aren't primitives, though. Primitives are the lowest possible level; that's what makes them primitives. If something can be decomposed further (or is in turn composed of other things which are visible to the language without e.g. dropping down to assembly), then it is definitionally not a primitive.

The lowest level primitive, you would think is a bit. But we hardly go to that level do we? We actually have higher level things that we refer to as primitives (for example ints). You know what's even lower than a bit? An electrical voltage... I can go to even lower levels of abstraction as well. Atoms. Yet here we are still calling a bit a primitive even though it is not the lowest level.

When you program you design systems. And in those systems you define primitives that function in YOUR universe. Sure you design the system on top of another system which in itself has lower level primitives but we don't have refer to those outside primitives within our own universe. So what I mean is primitives not in the sense of the system I am working in, but in the system I am creating.

That being said. PRIMITIVE is 100% the appropriate word. You never defined what you mean by component but I'm sure it's some super specific thing that comes from some design pattern, but that's besides the point.

>That's a circular definition, and does not in any way clarify what you mean by "procedures".

You're referring to a typo. Replace "of" with "or" the point was to illustrate a potential refactoring. Ex: A list of procedures is the same as a list of instructions.

You get what I mean by procedures so no need to act confused about my typo or a slightly confusingly worded sentence.

>In pseudo-Forth (with punctuation turned into something more reasonable, and a couple imaginary procedures for creating (anonProcedure) and executing (execute) function pointers):

We can get really technical here. Due to Curry howard isomorphism a turing machine can technically do anything and simulate composition as well. But like your example shows, it is awkward. It's adding a char to an int in C++. Yeah you can do it.

Additionally you are arbitrarily naming your procedures. Step 6 should be something that is very distant in meaning from step 1. For example:

Step 1 should be go to store.
Step 2 should be buy chicken.
Steps 3-5 should be all the steps to prepare the chicken.
Step 6 is eat chicken

Compose step 1 with step 6. It does not make semantic sense.

Go to store, eat chicken.

What chicken?

Sure you can "compose" but like I said, you've basically gave an example where you can do anything. You need rules on what can compose with what. Usually these rules are implemented by something called a type system. Type systems are typically ineffective at enforcing composition of procedures. There would really be no way for a type system in your example to make sure step 1 can only compose with step 2 to form stepOneAndTwo and such a composition is not universally defined. You define how your steps compose on every program you write. No legos, no modularity.

>Maybe you'd do a better job conveying your point if you just said the "primitive" you mean instead of being needlessly coy about it.

I'm not being coy. What's going on here is an inability to understand. Or maybe you do understand. In that case I don't know what's going on.

>And regarding this brick-which-cannot-be-named-for-some-reason: yes, they happen to snap together remarkably well like Lego bricks, but people don't (typically) build their houses with Lego bricks, nor do people normally write their business logic in Haskell.

What does haskell have to do with this? I'm not talking about haskell. I am talking about something 100% of all programmers already use all the time.

I'm not naming the brick because if you know what I'm talking about, then there's really no point in arguing about it is there? You get it, because the logic led inescapably to one place. You arrived at the same conclusion and therefore we are in agreement.

If you don't get it, well that's not my problem, I'm not here to dive into a rabbit hole about the merits of a certain topic, only the flaws of the current paradigm. You want to talk about it? be my guest, I'm not starting it myself.

Who writes business logic in Forth nowadays? Less people than haskell that's 100% fact, but that's besides the point because, again, I never was talking about haskell.