1. 5

  2. 4

    Javascript objects probably achieve (1) and (3). Maybe (2) if you wave your arms a bit. JSON achieves absolutely none of them.

    Yes, because JSON is a Notation, not an Object.

    1. 2

      Ultimately that’s my whole point. The post is about the differences between objects and notations—between codata and data—and was merely inspired by fact that LCON grabbed the “-ON” bit as a unit.

      Given the responses I’ve been getting to this post it’s become quite clear that iterative deepening is not a great choice of blog writing rhetoric.

      1. 2

        After rereading your post I think I understand what you’re saying.

        1. 1

          I really could have written it better.

          1. 0

            I remember when you kids would try to prove badassery in C++, now when you write blog posts steeped in category theory and 10 dollar words we get stuff like “coalgebraic interface.” Which, when searched with quotes comes up with zero hits, so you are not yet the authoritative source on it yet, ;)

            It is is a blog post, not a thesis. Maybe fancy down a little bit?

            Although I would love to send this through a Markov generator.

            1. 1

              What are you trying to say? I can explain more about it if you like. F-coalgebra is on Wikipedia if you like.


              My goal is not to use CT terms to make things more obtuse, but instead to leave links toward ideas which really are the center of what I’m writing about. I’m sorry such terminology turns you off.

              The paper you found is really interesting. One of the challenges of coalgebraic things (and so, we can more or less replace “colgebraic thing” with “object” if you like) is that it’s really difficult to generalize notions of value equality between them. That’s why usually you do one of two things in OO languages—either have “entity equality” via memory location or “state equality” by somehow extracting a non-object internal state (which is initial, data-not-codata, algebraic not co-algebraic).

              However, there is a good notion of object/coalgebraic/coinductive equality called a “bisimulation”. A bisimulation occurs when “you can’t tell two things apart from the outside”. Or, each thing “properly” simulates the other. If you take bisimulation as equality you can show that it has all of the properties you’d like.

              It’s just really a pain to work with still, so lots of people are seeking out better ways to apply bisimulations to the kinds of coalgebras computer scientists deal with all the time. Getting better at that would give much better formal tools for talking about when two algorithms are “the same”.

              1. 1

                I am not trying to dissuade you from blogging, just giving some feedback that might turn less people off. I believe there are some important insights in there. Wikipedia has a mal-attractor when it comes to mathematics articles, they can start with a clear explanation, but they quickly get edited to the point where only someone highly skilled in mathematics can understand it. The f-coalgebra link doesn’t help me.

                If I only I could include an inline venn diagram about the set of people that will understand your jargon and the set of people that need to understand what you are saying, I am pretty sure they disjoint. ;)

                Sameness from a certain projection is definitely a powerful idea (exactly how duck-typing became a thing). Also is representing state in a clean externalized view, a semantically consistent struct, dump the CT stuff or make it an aside.

                If your goal is to communicate about JSON and LCON how many of those people are going to know about codata and coalgebras. Think about your audience and put it terms that they can relate to, opaque, transparent, callables and structures.

                Also for JSON the O is object == struct, not object in the OO sense.

                Keep Blogging!

                1. 2

                  I certainly agree with your Venn diagram idea. I’m still feeling out for how I want to write.

                  I think there are important reasons for using CT terminology and I wish it were less scary. I could just make up new words but then I’d want to leave a key so that interested readers could find connections.

                  Honestly, struct-v-object is almost exactly right, but calling structs “objects” is an abuse of the term (though certainly a common one).

                  The whole idea is to begin to see objects (coalgebras, final encodings, codata) as a different species from structs (algebras, initial encodings, data) and talk about how their behavior differs.

                  JSON was just interesting to me because finite presentability is certainly a property of algebras. I’d like to find a better way to talk about it.

                  Eventually I’m going to write this stuff all out formally as a “Type of Recursive Data” follow-up post… Just not ready yet.