5 ms·

>Well for example this insight explains Memoization I don't think it does. In fact I don't see (edit: the logcial progression from one idea to the other) at a

>Well for example this insight explains Memoization I don't think it does. In fact I don't see (edit: the logcial progression from one idea to the other) at all. Memorization is the natural conclusion of the thought process that begins with the disk/CPU trade off and the idea that "some things are expensive to compute but cheap to store", aka caching.

KK7NIL 8mo ago
Both arrays and (pure) functions are just mappings of inputs to outputs, this is why memoization is possible without any loss of functionality. Whether storing (arrays) or computing (functions) is faster is a quirk of your hardware and use case.
- Dylan16807 8mo ago
  Memoization is a different way around though. You're turning part of a function into an array and a traditional function is still in charge. It doesn't depend on arrays being functions. I would also reject the idea that "Arrays are Functions" is equivalent to "Functions are Arrays". They're both true in a sense, but they're not the same statement.
  - KK7NIL 8mo ago
    We're talking past each other because we're using different definitions. If you actually read the article you'll see that the type of arrays and functions they're talking about are not necessarily the types you'll find in your typical programming language (with some exceptions, as others noted) but more in the area of pure math. The insights one can gain from this pure math definition are still very much useful for real world programming tough (e.g. memoization), you just have to be careful about the slightly different definitions/implementations.
    - Dylan16807 8mo ago
      > If you actually read the article Needless. > The insights one can gain from this pure math definition are still very much useful for real world programming tough (e.g. memoization), you just have to be careful about the slightly different definitions/implementations. I agree completely here. But I think that undermines some of the earlier claims. The math definition only serves as inspiration, we're not using the math definition when we memoize. And the important part you need for that inspiration is a lot narrower than full equivalence.
      - KK7NIL 8mo ago
        > And the important part you need for that inspiration is a lot narrower than full equivalence. The blogpost is discussing exactly what you gain (and lose) when arrays and functions fit this strict definition, allowing a unification of the syntax and possible compiler optimizations. I think the point they're making is exactly that having only a loose equivalence between arrays and functions might be a programming status quo that could be holding us back from a higher level abstraction.
        Dylan16807 8mo ago
        > I think the point they're making is exactly that having only a loose equivalence between arrays and functions might be a programming status quo that could be holding us back from a higher level abstraction. Maybe. I'll sit here ready for those insightful uses of stricter connections. But the memoization example is very loose, and memoization is what I was replying to.

KK7NIL 8mo ago

Both arrays and (pure) functions are just mappings of inputs to outputs, this is why memoization is possible without any loss of functionality. Whether storing (arrays) or computing (functions) is faster is a quirk of your hardware and use case.

Dylan16807 8mo ago
Memoization is a different way around though. You're turning part of a function into an array and a traditional function is still in charge. It doesn't depend on arrays being functions. I would also reject the idea that "Arrays are Functions" is equivalent to "Functions are Arrays". They're both true in a sense, but they're not the same statement.
- KK7NIL 8mo ago
  We're talking past each other because we're using different definitions. If you actually read the article you'll see that the type of arrays and functions they're talking about are not necessarily the types you'll find in your typical programming language (with some exceptions, as others noted) but more in the area of pure math. The insights one can gain from this pure math definition are still very much useful for real world programming tough (e.g. memoization), you just have to be careful about the slightly different definitions/implementations.
  - Dylan16807 8mo ago
    > If you actually read the article Needless. > The insights one can gain from this pure math definition are still very much useful for real world programming tough (e.g. memoization), you just have to be careful about the slightly different definitions/implementations. I agree completely here. But I think that undermines some of the earlier claims. The math definition only serves as inspiration, we're not using the math definition when we memoize. And the important part you need for that inspiration is a lot narrower than full equivalence.
    - KK7NIL 8mo ago
      > And the important part you need for that inspiration is a lot narrower than full equivalence. The blogpost is discussing exactly what you gain (and lose) when arrays and functions fit this strict definition, allowing a unification of the syntax and possible compiler optimizations. I think the point they're making is exactly that having only a loose equivalence between arrays and functions might be a programming status quo that could be holding us back from a higher level abstraction.
      - Dylan16807 8mo ago
        > I think the point they're making is exactly that having only a loose equivalence between arrays and functions might be a programming status quo that could be holding us back from a higher level abstraction. Maybe. I'll sit here ready for those insightful uses of stricter connections. But the memoization example is very loose, and memoization is what I was replying to.