4 ms·

You can't just compose two functions because they're both written in a functional programming language. The programmer has to have the foresight to make their t

You can't just compose two functions because they're both written in a functional programming language. The programmer has to have the foresight to make their types compatible. I think the novelty of the Unix pipe for interoperability is that they (typically) work on one agreed-upon kind of data: human readable, white-space separated. So a lot of tools "just work" with each other. There's no reason you can't do this with functional programming, but obviously you can do it with non-functional programming too, and you could certainly fail to do this with functional programming.

crimsonalucard5 6y ago
>You can't just compose two functions because they're both written in a functional programming language. Obviously not, the types have to be compatible just like how a lego piece must be compatible. >The programmer has to have the foresight to make their types compatible. Just like a lego builder needs to have the foresight to see whether two lego components are compatible. The analogy still fits. > I think the novelty of the Unix pipe for interoperability is that they (typically) work on one agreed-upon kind of data: human readable, white-space separated. So a lot of tools "just work" with each other. The agreed upon data is just a type. Unix pipes compose functions that take in strings as input and deliver strings as output. The spaces is just an oversight, the whole thing would have been more clean if the type was designed to represent multiple pieces of data like a tuple of words rather than a single string with words divided by spaces. >you could certainly fail to do this with functional programming. Just like how two lego pieces can't compose if they're not compatible pieces facing the right direction. Sockets and plugs must be compatible. A functional program still fits the analogy of legos perfectly. Take a look at lego pieces here: https://brickarchitect.com/2019/2019-most-common-lego-parts/ https://brickarchitect.com/2019/2019-most-common-lego-parts/ There exists lego parts that can never compose with certain other parts. Just like functions and function composition. What you're not seeing is how other styles of programming such as OOP or procedural programming fail to fit the analogy and literally become like organ transplantation. Let's take a look at object composition. How does that work in the context of legos? It's like a lego block with a mutating hole in it and once you can put different things in that hole and that changes the overall lego block. Also with OOP and procedural programming you get lego blocks that can mutate. Lego blocks can transform themselves and other lego blocks. They form an interconnected network of entities that are constantly mutating. To fit the analogy of a lego block you need unchanging blocks. The entire field of Procedural programming and OOP is basically the art of building systems with mutating primitives that constantly change. Imagine constructing buildings using bricks that change shape. Now imagine refactoring code that does this.... Organ transplantation. Also you really just need to try it. Doing the type of grafting and refactoring that's an intrinsic part of programming literally becomes lego-like once you program using the functional style. To really see the big picture I suggest you exclusively try the point free style using Haskell. That being said. There are still massive tradeoffs to doing functional programming. But if your goal is to program like you're using lego blocks, functional programming is the path.
- DougWebb 6y ago
  Also with OOP and procedural programming you get lego blocks that can mutate. Lego blocks can transform themselves and other lego blocks. They form an interconnected network of entities that are constantly mutating. That kind of sounds like a structure of living cells. They're more complex than a structure of lego blocks, but they can do a lot more too. Don't take that as an argument in favor of OOP though. Building with legos is a lot easier to get right than building with cells would be.
  - crimsonalucard5 6y ago
    You can create building blocks of unlimited complexity or pure simplicity. The key lies in your choice of primitives. Do you start off with a set primitives that are extremely complex or a set primitives that are simple but complete in the sense that you can build entities of unlimited complexity by composing simpler primitives? I would say the latter method is easier. But there's no reason why the former method won't work. Biological evolution has built many examples of working machines with primitives of unimaginable complexity.
    - ElFitz 6y ago
      Yes, it did. But it also had a couple billion years of trial and error to do so. Basically, it's the infinite monkey theorem.
      - crimsonalucard5 6y ago
        Yeah, I'm just saying it can work and it can work remarkably well and efficiently. It's just probably too complex for our limited intelligence to handle.
monetus 6y ago
The message passing protocol in pure data is white space delimited with semicolons ending commands. FUDI is underappreciated, and enabled 'dynamic' programming of PD despite the available code having been built almost entirely with a mind towards instantiating all memory use ahead of time. Good interfaces enable unexpected things. https://en.m.wikipedia.org/wiki/FUDI https://en.m.wikipedia.org/wiki/FUDI
hencq 6y ago
Nicely put. That aligns very nicely with the philosophy behind Clojure and for instance less so with Haskell. In Clojure you usually use only a few data types, often (immutable) hashmaps. A program then simply becomes a series of functions that transform data.
- platz 6y ago
  Anytime someone mentions a nice thing about Haskell, you can be sure a Clojure programmer will appear shortly, without being previously referenced, to try and disparage them.
  - crimsonalucard5 6y ago
    I mean what he describes is literally the same thing as haskell. Just untyped.
  - adamkl 6y ago
    Not sure where the hostility is coming from. I didn’t read anything disparaging about Haskell in hencq’s comment. He/she just made a factual statement about Clojure’s approach to data types being analogous to Unix/strings when it comes to composition. It comes with the same drawbacks (the lack of static typing is similar to strings with Unix; you have to be aware of the details of the data coming in and out because there is no type system to save you - unlike Haskell), but the benefit is easier composition.
    - hencq 6y ago
      Yeah, I didn't mean anything disparaging about Haskell at all. I only mentioned Haskell as an example of a functional programming language. I tried to make a point (apparently poorly) about the easy composition that using a limited number of (dynamic) types enables. Of course all the usual dynamic vs static tradeoffs apply. Thanks for doing a better job explaining that :-)
      - crimsonalucard5 6y ago
vicda 6y ago
Yes, but you write a short function/lambda for connecting them. Just like how you have sed/awk, or the many required flags to make any non-trivial operation "just work". You're not free from the need to specify how to parse the strings just because your whole human readable system is stringly typed.
willtim 6y ago
If languages adopted structural typing, rather than nominal as the default, then it would be much easier to align the types (e.g. projection/renaming of columns). Most FP languages have a limited form of structural typing with tuples.
- orbifold 6y ago
  Objects in OCaml are structurally typed as well.
  - deleted 6y ago
    [deleted]

crimsonalucard5 6y ago

>You can't just compose two functions because they're both written in a functional programming language. Obviously not, the types have to be compatible just like how a lego piece must be compatible. >The programmer has to have the foresight to make their types compatible. Just like a lego builder needs to have the foresight to see whether two lego components are compatible. The analogy still fits. > I think the novelty of the Unix pipe for interoperability is that they (typically) work on one agreed-upon kind of data: human readable, white-space separated. So a lot of tools "just work" with each other. The agreed upon data is just a type. Unix pipes compose functions that take in strings as input and deliver strings as output. The spaces is just an oversight, the whole thing would have been more clean if the type was designed to represent multiple pieces of data like a tuple of words rather than a single string with words divided by spaces. >you could certainly fail to do this with functional programming. Just like how two lego pieces can't compose if they're not compatible pieces facing the right direction. Sockets and plugs must be compatible. A functional program still fits the analogy of legos perfectly. Take a look at lego pieces here: https://brickarchitect.com/2019/2019-most-common-lego-parts/ https://brickarchitect.com/2019/2019-most-common-lego-parts/ There exists lego parts that can never compose with certain other parts. Just like functions and function composition. What you're not seeing is how other styles of programming such as OOP or procedural programming fail to fit the analogy and literally become like organ transplantation. Let's take a look at object composition. How does that work in the context of legos? It's like a lego block with a mutating hole in it and once you can put different things in that hole and that changes the overall lego block. Also with OOP and procedural programming you get lego blocks that can mutate. Lego blocks can transform themselves and other lego blocks. They form an interconnected network of entities that are constantly mutating. To fit the analogy of a lego block you need unchanging blocks. The entire field of Procedural programming and OOP is basically the art of building systems with mutating primitives that constantly change. Imagine constructing buildings using bricks that change shape. Now imagine refactoring code that does this.... Organ transplantation. Also you really just need to try it. Doing the type of grafting and refactoring that's an intrinsic part of programming literally becomes lego-like once you program using the functional style. To really see the big picture I suggest you exclusively try the point free style using Haskell. That being said. There are still massive tradeoffs to doing functional programming. But if your goal is to program like you're using lego blocks, functional programming is the path.

DougWebb 6y ago
Also with OOP and procedural programming you get lego blocks that can mutate. Lego blocks can transform themselves and other lego blocks. They form an interconnected network of entities that are constantly mutating. That kind of sounds like a structure of living cells. They're more complex than a structure of lego blocks, but they can do a lot more too. Don't take that as an argument in favor of OOP though. Building with legos is a lot easier to get right than building with cells would be.
- crimsonalucard5 6y ago
  You can create building blocks of unlimited complexity or pure simplicity. The key lies in your choice of primitives. Do you start off with a set primitives that are extremely complex or a set primitives that are simple but complete in the sense that you can build entities of unlimited complexity by composing simpler primitives? I would say the latter method is easier. But there's no reason why the former method won't work. Biological evolution has built many examples of working machines with primitives of unimaginable complexity.
  - ElFitz 6y ago
    Yes, it did. But it also had a couple billion years of trial and error to do so. Basically, it's the infinite monkey theorem.
    - crimsonalucard5 6y ago
      Yeah, I'm just saying it can work and it can work remarkably well and efficiently. It's just probably too complex for our limited intelligence to handle.

monetus 6y ago

The message passing protocol in pure data is white space delimited with semicolons ending commands. FUDI is underappreciated, and enabled 'dynamic' programming of PD despite the available code having been built almost entirely with a mind towards instantiating all memory use ahead of time. Good interfaces enable unexpected things. https://en.m.wikipedia.org/wiki/FUDI https://en.m.wikipedia.org/wiki/FUDI

hencq 6y ago

Nicely put. That aligns very nicely with the philosophy behind Clojure and for instance less so with Haskell. In Clojure you usually use only a few data types, often (immutable) hashmaps. A program then simply becomes a series of functions that transform data.

platz 6y ago
Anytime someone mentions a nice thing about Haskell, you can be sure a Clojure programmer will appear shortly, without being previously referenced, to try and disparage them.
- crimsonalucard5 6y ago
  I mean what he describes is literally the same thing as haskell. Just untyped.
- adamkl 6y ago
  Not sure where the hostility is coming from. I didn’t read anything disparaging about Haskell in hencq’s comment. He/she just made a factual statement about Clojure’s approach to data types being analogous to Unix/strings when it comes to composition. It comes with the same drawbacks (the lack of static typing is similar to strings with Unix; you have to be aware of the details of the data coming in and out because there is no type system to save you - unlike Haskell), but the benefit is easier composition.
  - hencq 6y ago
    Yeah, I didn't mean anything disparaging about Haskell at all. I only mentioned Haskell as an example of a functional programming language. I tried to make a point (apparently poorly) about the easy composition that using a limited number of (dynamic) types enables. Of course all the usual dynamic vs static tradeoffs apply. Thanks for doing a better job explaining that :-)
    - crimsonalucard5 6y ago

vicda 6y ago

Yes, but you write a short function/lambda for connecting them. Just like how you have sed/awk, or the many required flags to make any non-trivial operation "just work". You're not free from the need to specify how to parse the strings just because your whole human readable system is stringly typed.

willtim 6y ago

If languages adopted structural typing, rather than nominal as the default, then it would be much easier to align the types (e.g. projection/renaming of columns). Most FP languages have a limited form of structural typing with tuples.

orbifold 6y ago
Objects in OCaml are structurally typed as well.
- deleted 6y ago
  [deleted]