> I don’t know why the network would be any way special.
The network isn't special. This applies locally too. But the article we are commenting on (at least, _I_ was commenting on) is about the network, and it uses the phrase "type safety over the network" in particular.
> You parse/validate unstructured binary blobs into structured data, and what’s left _is type safety_.
That is in fact exactly what I said. The point is that at some point you started with unstructured binary blobs. As soon as data leaves the application, it is no longer "safe", and it is unsafe until it is ingested and (re)validated. So my point can be freely generalised to "type safety beyond the application boundary is a fiction". And the application boundary will always exist, whether you are working with a strongly or weakly, statically or dynamically typed language.
In many statically-typed languages, types do not exist at runtime - they are erased once the program is known to be internally consistent. What is left is not type safety, it is parsing and validation of unstructured binary blobs (or arbitrary strings, depending on the protocol) into structured data. Structure and types are not the same thing, and in many languages they barely even overlap.
My point was more that the layers below the application will also have to parse the data into a particular format - in the case of networked applications, into TCP/IP packets, then anything particular to the message protocol, before hitting the application. And then the application will, at runtime (regardless of whether you are using a type safe language or not) have to parse and validate the shape of the data before it can be used.
The idea of "type safety over the network" is a fiction.
When it comes down to it, what is being sent over the network is 1s and 0s. At some point, some layer (probably multiple layers) are going to have to interpret that sequence of 1s and 0s into a particular shape. There are two main ways of doing that:
- Know what format the data is in, but not the content (self-describing formats) - in which case the data you end up with might be of an arbitrary shape, and casting/interpreting the data is left to the application
- Know what format the data is in, AND know the content (non-self-describing formats) - in which case the runtime will parse out the data for you from the raw bits and you get to use it in its structured form.
The fact that this conversion happens doesn't depend on the language; JS is no more unsafe than any other language in this regard, and JSON is no better or worse of a data serialisation format for it. The boundary already exists, and someone has to handle what happens when the data is the wrong shape. Where that boundary ends up influences the shape of the application but what is preferable will depend on the application and developer.
Turing completeness and P completeness are completely different things. There is no sense in which P-completeness is a "more specific" version of Turing-completeness.
> The $ operator is nothing but syntactic sugar that allows you to write bar $ foo data instead of having to write bar (foo data). That’s it.
Actually, it's even simpler than that: the $ operator is nothing but a function that applies its left argument to its right one! The full definition is
f $ x = f x
(plus a directive that sets its precedence and association)
It wasn't easier, but it was simpler. Fewer moving parts.
The reason we moved away from it was that after a point, the amount of legwork to implement relatively simple behaviours became astronomical. Whether or not the current state of matters is "better", who's to say. But things are certainly much easier now.
Besides, you still can use those old modes if you want to :)
> Understanding the map signature in Haskell is more difficult than any C construct.
This is obviously false. The map type signature is significantly easier to understand than pointers, referencing and dereferencing.
I am an educator in computer science - the former takes about 30-60 seconds to grok (even in Haskell, though it translates to most languages, and even the fully generalised fmap), but it is a rare student that fully understands the latter within a full term of teaching.
> Just imagine Vampire Survivors without sound or effects.
I can't help but feel that this completely undermines your point - Vampire Survivors is bashed together using rudimentary knockoffs of sprites from games from the 1990s, in an engine which barely supports the idea of particles let alone proper visual effects.* It is the gameplay that carries Vampire Survivors, not the aesthetic.
Game feel is of course essential to producing a good game all-round, but a competent game designer can and will tell the difference between a good game design and a bad one, way before polish and juice are layered on top.
*I don't say this as a criticism - Vampire Survivors is fantastic - but the idea that it's propped up by its look is just daft.
> Here are some monoids: string-append over strings, addition over integers, state transition over machine states, compose over unary functions.
Correction: function composition is not a monoid over unary functions, only over families of endofunctions (functions of type `a -> a` for some `a`). You can't compose a function of type `a -> b` with a function of type `a -> b` for example, when `a` /= `b`, because one gives back a value of type `b` which cannot be passed into a function expecting a value of type `a`.
The network isn't special. This applies locally too. But the article we are commenting on (at least, _I_ was commenting on) is about the network, and it uses the phrase "type safety over the network" in particular.
> You parse/validate unstructured binary blobs into structured data, and what’s left _is type safety_.
That is in fact exactly what I said. The point is that at some point you started with unstructured binary blobs. As soon as data leaves the application, it is no longer "safe", and it is unsafe until it is ingested and (re)validated. So my point can be freely generalised to "type safety beyond the application boundary is a fiction". And the application boundary will always exist, whether you are working with a strongly or weakly, statically or dynamically typed language.