4 ms·

>Functions run to completion and return their result. Filters tend to run concurrently and, importantly, do not return their results, they pass them on to the n

>Functions run to completion and return their result. Filters tend to run concurrently and, importantly, do not return their results, they pass them on to the next filter in the pipeline. Let me address this point so it is more clear. Functions by definition do not need to "run" at all. The underlying implementation of a programming language may "run" a function lazily, eagerly or concurrently but that is not what the Definition of a function is describing. A function is simply a relation between two sets, one set called a codomain, another set called a domain is deterministic. That is all. So within unix piping the domain is stdin, the codomain is stdout, the function is the unix program. This paradigm fits the definition of a function and as long as that "function" remains deterministic and compose-able it fits within the paradigm of functional programming BY definition. there is no need to discuss "similarities" here, because it fits the definition therefore it is functional programming. Of course we can get pedantic about certain non-functional use cases but in basically you are fully aware of the generality I'm describing. No point in getting pedantic. Also keep in mind when you "execute" these functions it does not matter HOW these functions are executing whether concurrently, lazily or eagerly. The only important thing is the relation between the domain and codomain. That is all. >The single type is also a restriction relative to the functional model, and crucial to (syntactic) composability. Every unix program must internally deserialize this string type and serialize it again for output. The typing must be handled regardless. It seems like you don't need to deal with it but it's dealt with regardless. You also get inevitable deserialization problems of incorrect types. You do not escape typing in the unix world. >But they are not actually equal (never mind the same), at least not in typed FP, and most FP is typed. A relation that takes a string from a domain and returns a string that is from a codomain is a function that is part of functional programming. This is EXACTLY what a unix program does when relating stdin to stdout and therefore it IS a function and it is FP By definition. You can look at it from another direction. A function that returns an Array does not fit the definition of what a unix program should output to stdout therefore a function IS NOT a unix program. BUT a unix program IS a function. Formally unix programs are just the set of all functions where the domain and codomains are strings. >>Both f' and f are equivalent in theory. >But they are not actually equal (never mind the same), at least not in typed FP, and most FP is typed. The mathematical term is "isomorphic" meaning you get the EXACT same properties going one way vs. the other way. It's the syntactic sugar that prevents composition. Using multi-arity functions and single arity functions with tuples only involves two additional parenthesis: f(a, b) f'((a, b)) It's just syntactic sugar that causes a difference to occur. Arity and tuple types are well described to be isomorphic in category theory. I'm not making this up. One way to think about an isomorphism is that if two things are isomorphic then they are just different perspectives of the exact same thing. Any differences are superficial or illusory. >Exactly. It is hidden in Unix and not in FP. That's a difference. Exactly what? If you're not dealing with the type conversions someone else has too. Just because it's hidden from you doesn't mean it doesn't need to be dealt with. Someone has to serialize things and deserialize it. Even from the command line level you cannot escape types. Let's say you have a unix program that can only take numerical strings from stdin. Let's say you pipe english letters to it... if you do then you will have still triggered a sort of type error despite everything being typed as strings in unix. It's just not handled explicitly as a system error. You cannot escape typing even in the unix world because it is in the end just FP. >So: it is good to recognize that 'X is similar to Y', but that doesn't imply that 'X is just Y'. Except we're not talking about similarity. Like I said above X is just Y BY definition.

mpweiher 6y ago
You keep claiming things are the same and then describing differences. Not sure what else I can do to make you understand this. As such, I am bowing out as I can only repeat what I’ve written.
- crimsonalucard5 6y ago
  No I did not do what you wrote. Here's what I did: I defined what a function is, then I described how a unix program fits the definition of what a function is... In short a unix program with stdin as domain and stdout as a codomain is a function but a function is not necessarily a unix program. I think what's actually going on is you didn't read what I wrote very carefully. You sort of just skimmed over it. I can't blame you, it is rather long and detailed... But if you want to have a meaningful discussion you need to read it and ask questions about things you don't understand.
  - mpweiher 6y ago
    As I wrote before: > > Unix piping is basically functional programming. > Only in the same sense that all computing is Turing Machines or NAND gates. Yes, you can map and analogize long enough until you reach a point where you find what you perceive to be equivalences. However, what you've done at that point is rediscover that all these mechanisms are computational and thus at some level equivalent and transformable into each other, just like yoo can implement all of this with just NAND gates. You have not shown what you claim. ¯\_(ツ)_/¯
    - crimsonalucard5 6y ago
      >you can map and analogize This is a common thing for people to do during debates and it's not an effective form of proving anything. If you read my post carefully you will see that, again I did NOT do this. What I did is defined what a function is, and defined How a unix program fits that definition. This is not a "illustrate my point by 10 million examples while establishing nothing" It's a logical proof. Read it more carefully. >However, what you've done at that point is rediscover that all these mechanisms are computational and thus at some level equivalent and transformable into each other, just like yoo can implement all of this with just NAND gates. Transformational is not the right term. The term you're seeking is "isomorphic." First off you're not being clear about what you're saying so I'm going to make an assumption. Here's what I'm assuming: Your statement implies that because all things are "isomorphic" with NAND Gates and Computation in general therefore all things are "functions" including unix programs. If what you imply is True (which it is not by the way) then you're basically saying that I'm right but the statement I'm making is Pointless because everything can be a "function." From another perspective what your statement implies is that any statement that anyone makes about whether or not a language is functional or not is pointless because it's all Turing Machines and NAND gates so everything is functional so who cares? This is obviously not the case. C++ is clearly not a functional language even though it can be coded to functionally behave as if it were and vice versa, but the language itself does not FIT the definition of a functional language, only a small subset of C++ may fit, but the language itself does not fit. But let's get back to the part where you're wrong. NAND gates are functions, but not all Composition of Nand Gates Fit the definition of a function. Additionally the definition of a Turing Machine does not fit the definition of a function either. Examine the JK FlipFlop: http://hyperphysics.phy-astr.gsu.edu/hbase/Electronic/jkflipflop.html http://hyperphysics.phy-astr.gsu.edu/hbase/Electronic/jkflip... You will see this basic computing component is constructed from nand gates but it's truth table is anything but deterministic. A JK flip flop does not represent a deterministic mapping between a codomain and a domain and is therefore NOT a function. JK flip flops form the backbone of registers which are in turn a fundamental concept of computing machines. Computing machines themselves hold state via registers and thus computations are not deterministic as the computations rely on state stored in the registers. Thus for computing as a whole, for programming languages as a whole, MOST of computing IS NOT Functional Programming because most computations rely on state and are not deterministic. The greater majority of programs designed on top of a computation machine rely on stateful deterministic methods of computing: Java, C++, python almost every computing technology out there is NOT functional. Only a small subset of languages can fit the definition of a function or functional program. This INCLUDES "unix programs and Piping" in general, but most things DO NOT fit this paradigm. You can configure these machines (and languages) to BEHAVE as if they were stateless just like you can configure functional machines to BEHAVE as if they were stateful via the "curry-howard correspondance" but this doesn't mean that "everything" is a function, the definition of a function itself actually refers to superficial differences outside of the isomorphism. >You have not shown what you claim. ¯\_(ツ)_/¯ I have shown that your statements are not only an admission that I'm right, but that your statement is indeed wrong. I didn't use any analogies here. I went straight into situations that disprove your statements derived directly from your wording. If I used an analogy you will find the Use of the word "like" somewhere which did NOT occur. Also I'm not the one being pedantic here. You're the one who initially took the statement into computing theory. Literally unix piping is a highly functional paradigm. It is obvious from an intuitive and lay-mans perspective. My initial post stating this has roughly 40 upvotes so you will find that most people agree with me.

mpweiher 6y ago

You keep claiming things are the same and then describing differences. Not sure what else I can do to make you understand this. As such, I am bowing out as I can only repeat what I’ve written.

crimsonalucard5 6y ago
No I did not do what you wrote. Here's what I did: I defined what a function is, then I described how a unix program fits the definition of what a function is... In short a unix program with stdin as domain and stdout as a codomain is a function but a function is not necessarily a unix program. I think what's actually going on is you didn't read what I wrote very carefully. You sort of just skimmed over it. I can't blame you, it is rather long and detailed... But if you want to have a meaningful discussion you need to read it and ask questions about things you don't understand.
- mpweiher 6y ago
  As I wrote before: > > Unix piping is basically functional programming. > Only in the same sense that all computing is Turing Machines or NAND gates. Yes, you can map and analogize long enough until you reach a point where you find what you perceive to be equivalences. However, what you've done at that point is rediscover that all these mechanisms are computational and thus at some level equivalent and transformable into each other, just like yoo can implement all of this with just NAND gates. You have not shown what you claim. ¯\_(ツ)_/¯
  - crimsonalucard5 6y ago
    >you can map and analogize This is a common thing for people to do during debates and it's not an effective form of proving anything. If you read my post carefully you will see that, again I did NOT do this. What I did is defined what a function is, and defined How a unix program fits that definition. This is not a "illustrate my point by 10 million examples while establishing nothing" It's a logical proof. Read it more carefully. >However, what you've done at that point is rediscover that all these mechanisms are computational and thus at some level equivalent and transformable into each other, just like yoo can implement all of this with just NAND gates. Transformational is not the right term. The term you're seeking is "isomorphic." First off you're not being clear about what you're saying so I'm going to make an assumption. Here's what I'm assuming: Your statement implies that because all things are "isomorphic" with NAND Gates and Computation in general therefore all things are "functions" including unix programs. If what you imply is True (which it is not by the way) then you're basically saying that I'm right but the statement I'm making is Pointless because everything can be a "function." From another perspective what your statement implies is that any statement that anyone makes about whether or not a language is functional or not is pointless because it's all Turing Machines and NAND gates so everything is functional so who cares? This is obviously not the case. C++ is clearly not a functional language even though it can be coded to functionally behave as if it were and vice versa, but the language itself does not FIT the definition of a functional language, only a small subset of C++ may fit, but the language itself does not fit. But let's get back to the part where you're wrong. NAND gates are functions, but not all Composition of Nand Gates Fit the definition of a function. Additionally the definition of a Turing Machine does not fit the definition of a function either. Examine the JK FlipFlop: http://hyperphysics.phy-astr.gsu.edu/hbase/Electronic/jkflipflop.html http://hyperphysics.phy-astr.gsu.edu/hbase/Electronic/jkflip... You will see this basic computing component is constructed from nand gates but it's truth table is anything but deterministic. A JK flip flop does not represent a deterministic mapping between a codomain and a domain and is therefore NOT a function. JK flip flops form the backbone of registers which are in turn a fundamental concept of computing machines. Computing machines themselves hold state via registers and thus computations are not deterministic as the computations rely on state stored in the registers. Thus for computing as a whole, for programming languages as a whole, MOST of computing IS NOT Functional Programming because most computations rely on state and are not deterministic. The greater majority of programs designed on top of a computation machine rely on stateful deterministic methods of computing: Java, C++, python almost every computing technology out there is NOT functional. Only a small subset of languages can fit the definition of a function or functional program. This INCLUDES "unix programs and Piping" in general, but most things DO NOT fit this paradigm. You can configure these machines (and languages) to BEHAVE as if they were stateless just like you can configure functional machines to BEHAVE as if they were stateful via the "curry-howard correspondance" but this doesn't mean that "everything" is a function, the definition of a function itself actually refers to superficial differences outside of the isomorphism. >You have not shown what you claim. ¯\_(ツ)_/¯ I have shown that your statements are not only an admission that I'm right, but that your statement is indeed wrong. I didn't use any analogies here. I went straight into situations that disprove your statements derived directly from your wording. If I used an analogy you will find the Use of the word "like" somewhere which did NOT occur. Also I'm not the one being pedantic here. You're the one who initially took the statement into computing theory. Literally unix piping is a highly functional paradigm. It is obvious from an intuitive and lay-mans perspective. My initial post stating this has roughly 40 upvotes so you will find that most people agree with me.