6 ms·

>Tada! composeObjects cannot compose correctly. The nature of objects is to know the domain. Food is a composition of ingredients and cooking. However you can

>Tada! composeObjects cannot compose correctly. The nature of objects is to know the domain. Food is a composition of ingredients and cooking. However you can eat food and take it to go, because during composition, the context of what food is, is added. Your composition method cannot do this, it does not know about context. A tuple (cooking, ingredients) has no domain knowledge. Your composition is mashing random stuff together. It is not correct. It is the same as creating a tuple or list of two objects, with no concept of Food. >That depends on your domain. In this particular case, it could be the first chicken on the stack. It won't be a particularly tasty chicken, since it'll be entirely uncooked and probably frozen, but that's certainly within the realm of possibility. No it's not. Domain matters, otherwise programs are meaningless. Composition without domain proves nothing. >Well yeah, welcome to Turing-completeness :) Why are you welcoming me to something you don't understand. Everyone knows what turing completeness is, therefore everyone knows that you can imitate features of one primitive with features from another if the underlying system is turing complete. So what is the point of your whole expose? Let me answer for you: there is no point. When someone says that C++ supports types and python doesn't we have a guy here who says "well python does support types: look I wrote a whole C++ compiler with type checking in python...." You are that guy. Technically correct, but Literally going nowhere with all your points. >Indeed, and the rules in that example would be: >1. There are two things on the stack, and those things are addresses of procedures to JMP or CALL into. >That's really all there is to it. If the arguments aren't valid pointers to procedures, then you crash :) No dude. By rules I mean domain specific rules. Not arbitrary rules of the language. The composition of step1 and step6 is illegal because it doesn't make sense even though you can do it in forth. >You could do the same thing in Lisp, or in C/C++ (when linked to, say, LLVM, or when using a compiler that allows dropping down to assembly), or assembly, or in quite literally any other Turing-complete language with the ability to emit arbitrary code and JMP to it (and even then). Again you can do anything with any language therefore all languages are isomorphic and there's no differences among any languages. Dude. Come on. Objects and procedures do not compose, unless you bend them to imitate functions. You can do this in C++, lisp anything, including Forth. This is an obvious fact. Therefore nobody brings it up. Except you. >Again: not all bricks are Legos. Nothing wrong with needing mortar and rebar to build something. Buildings aren't programs built to be refactored and changed on a very dynamic basis. If you want your program to be scalable (which buildings aren't) modular (which buildings aren't) refactorable (which buildings aren't) then you need to build with legos. Mortar limits scalability which is a feature 90% of programs want but fail to have. If you want your program to be glued together like a giant monolith, be my guest, use the mortar.

yellowapple 7y ago
Context is not a requirement of the actual act of composition, though; that's what I'm trying to help you understand. Context might be why you might compose two things in a specific way, or why you might restrict composition between given things, but the act of composition itself is not tied to those specific requirements. In the functional realm: passing a function and list into a map function should work for any function and any list; map needn't care whether or not that function actually is applicable to that list (if it ain't, then that's the function's problem, not map's). Same deal for the "composeObject" function (if Foo and Bar shouldn't be composed, then don't try to compose Foo and Bar), and same deal for the compose procedure (if step1 and step6 shouldn't be composed, then don't try to compose step1 and step6). > The composition of step1 and step6 is illegal because it doesn't make sense It doesn't make sense to you. The computer doesn't care whether or not it makes sense to you. The computer only cares that it's able to pop two subroutine pointers and push one to a new subroutine that JMPs/CALLs to those popped pointers. The computer's gonna try to go to the store and eat a chicken, because that's what it's been told to do. To the computer, that makes perfect sense, because everything's subroutines and words, the chicken and the store and the going and the eating just being data to be pushed and popped. You're welcome to write subroutines that actually validate your ideas of sensibility before proceeding to actually compose the subroutines they're popping off the stack, and there are indeed languages that help you with that, but the computer is still fully capable of composing things regardless of whether or not you think they should be composed. ---- To humor your argument, though: composeFooAndBar(first: Class<Foo>, second: Class<Bar>) { third = new Class third._methods = first._methods.merge(second._methods) return third } FooBar = composeFooAndBar(Foo, Bar) foobar = new FooBar foobar.hi; foobar.bye # "howdy" then "adios" FooBaz = composeFooAndBar(Foo, Baz) # Yay! Our sensibilities are enforced!
- crimsonalucard 7y ago
  >Context is not a requirement of the actual act of composition, though; that's what I'm trying to help you understand. Context might be why you might compose two things in a specific way, or why you might restrict composition between given things, but the act of composition itself is not tied to those specific requirements. In the functional realm: passing a function and list into a map function should work for any function and any list; map needn't care whether or not that function actually is applicable to that list (if it ain't, then that's the function's problem, not map's). Same deal for the "composeObject" function (if Foo and Bar shouldn't be composed, then don't try to compose Foo and Bar), and same deal for the compose procedure (if step1 and step6 shouldn't be composed, then don't try to compose step1 and step6). Context matters. This is what the type system is for, the type system makes it so the computer will also know what can compose with what. You claimed the computer doesn't care, the type system proves you wrong. >but the computer is still fully capable of composing things regardless of whether or not you think they should be composed. Composition as a concept itself doesn't exist as a command on the instruction set level. It's a higher level concept. Another higher level concept is teaching the computer about the domain by feeding it into the type system. Why are you talking about the low level inability of a computer to comprehend the domain when on that same level the computer is unable to compose things as well. The topic of conversation is about a higher level of logic. Types and composition allow your computer to know about domain and compose. >To humor your argument, though: Remember way back when i defined composition as a universal function? Meaning that the compose function should be able to compose ANYTHING. Not just a Foo and Bar and your arbitrary composition rule. For example it should be able to compose a ONE and a TWO into a THREE as well. That's my arbitrary composition rule for addition. Your example fails to prove anything nor humor anyone.

yellowapple 7y ago

Context is not a requirement of the actual act of composition, though; that's what I'm trying to help you understand. Context might be why you might compose two things in a specific way, or why you might restrict composition between given things, but the act of composition itself is not tied to those specific requirements. In the functional realm: passing a function and list into a map function should work for any function and any list; map needn't care whether or not that function actually is applicable to that list (if it ain't, then that's the function's problem, not map's). Same deal for the "composeObject" function (if Foo and Bar shouldn't be composed, then don't try to compose Foo and Bar), and same deal for the compose procedure (if step1 and step6 shouldn't be composed, then don't try to compose step1 and step6). > The composition of step1 and step6 is illegal because it doesn't make sense It doesn't make sense to you. The computer doesn't care whether or not it makes sense to you. The computer only cares that it's able to pop two subroutine pointers and push one to a new subroutine that JMPs/CALLs to those popped pointers. The computer's gonna try to go to the store and eat a chicken, because that's what it's been told to do. To the computer, that makes perfect sense, because everything's subroutines and words, the chicken and the store and the going and the eating just being data to be pushed and popped. You're welcome to write subroutines that actually validate your ideas of sensibility before proceeding to actually compose the subroutines they're popping off the stack, and there are indeed languages that help you with that, but the computer is still fully capable of composing things regardless of whether or not you think they should be composed. ---- To humor your argument, though: composeFooAndBar(first: Class<Foo>, second: Class<Bar>) { third = new Class third._methods = first._methods.merge(second._methods) return third } FooBar = composeFooAndBar(Foo, Bar) foobar = new FooBar foobar.hi; foobar.bye # "howdy" then "adios" FooBaz = composeFooAndBar(Foo, Baz) # Yay! Our sensibilities are enforced!

crimsonalucard 7y ago
>Context is not a requirement of the actual act of composition, though; that's what I'm trying to help you understand. Context might be why you might compose two things in a specific way, or why you might restrict composition between given things, but the act of composition itself is not tied to those specific requirements. In the functional realm: passing a function and list into a map function should work for any function and any list; map needn't care whether or not that function actually is applicable to that list (if it ain't, then that's the function's problem, not map's). Same deal for the "composeObject" function (if Foo and Bar shouldn't be composed, then don't try to compose Foo and Bar), and same deal for the compose procedure (if step1 and step6 shouldn't be composed, then don't try to compose step1 and step6). Context matters. This is what the type system is for, the type system makes it so the computer will also know what can compose with what. You claimed the computer doesn't care, the type system proves you wrong. >but the computer is still fully capable of composing things regardless of whether or not you think they should be composed. Composition as a concept itself doesn't exist as a command on the instruction set level. It's a higher level concept. Another higher level concept is teaching the computer about the domain by feeding it into the type system. Why are you talking about the low level inability of a computer to comprehend the domain when on that same level the computer is unable to compose things as well. The topic of conversation is about a higher level of logic. Types and composition allow your computer to know about domain and compose. >To humor your argument, though: Remember way back when i defined composition as a universal function? Meaning that the compose function should be able to compose ANYTHING. Not just a Foo and Bar and your arbitrary composition rule. For example it should be able to compose a ONE and a TWO into a THREE as well. That's my arbitrary composition rule for addition. Your example fails to prove anything nor humor anyone.