hrefna,
@hrefna@hachyderm.io avatar

My instinct, looking at conversations around and AS2, is that there there's a disconnect when people talk about trying to ensure compile-time type safety with those that prefer systems that lean more toward dynamic, runtime typing.

Because I've seen a few cases now where people in the latter group seem to not understand why the first group views the translation into this as such a problem.

But this isn't about the preferred tool, this is about where the complexity lives.

1/

hrefna,
@hrefna@hachyderm.io avatar

By solving these problems with compile-time type safety you move the complexity to a different part o the development process.

This isn't "better" or "worse," but it does have some extremely strong advantages.

When solving these things in a language like python or JS you aren't not solving this complexity. You still end up dealing with it.

You just deal with it at a different place in the code and the process.

2/

hrefna,
@hrefna@hachyderm.io avatar

The people who are trying to do this are generally of the mind that they want the advantages of moving this complexity up in the chain, and are getting frustrated when the protocol seems to find new and inventive ways to foil them from doing this. It also has a variety of pieces in it that make using tools that make this easy much more difficult.

"So why not just use…"

Because we aren't actually changing the amount of complexity. In python or whatever I'd still be needing to do this!

3/

hrefna,
@hrefna@hachyderm.io avatar

But I'd do it at a different place in the pipeline and it is in some ways easier to do an incomplete implementation without knowing ahead of time what that incomplete implementation needs to look like.

This has some strong advantages too! But it isn't—and shouldn't be—considered the One True Way™. Especially because we all end up making many of the same compromises to the protocol.

The difference is where it lives in the code and when you have to deal with it in your process.

4/

hrefna, (edited )
@hrefna@hachyderm.io avatar

You hear about it more from people who like compile-time type checking because for us we encounter that complexity as one of our very first steps, and we generally—with the way that is structured—encounter it more-or-less all at once.

But the complexity is still there in other tools. But it seems to get solved a little more piecemeal and later in the cycle.

Neither good nor bad, but different tradeoffs.

5/5

FenTiger,
@FenTiger@mastodon.social avatar

@hrefna Or you could just "make it all really simple", pretend there's no complexity anywhere, and hope for the best.

hrefna,
@hrefna@hachyderm.io avatar

@FenTiger Ah yes, that's a time honored tradition in software development. "If I just focus on my part right here and completely ignore everyone downstream I can pretend that everything is pure and uncomplicated!"

"Well if it is 'cold outside' you should stop opening the doors into winter and only open the ones into summer!"

FenTiger,
@FenTiger@mastodon.social avatar

@hrefna Have you seen what happens when C-levels take this mindset?

hrefna,
@hrefna@hachyderm.io avatar

@FenTiger Why yes, yes I have x_x

huitema,
@huitema@social.secret-wg.org avatar

@hrefna @FenTiger A lot of that early checking can also be done by developing an extensive set of unit tests.

hrefna,
@hrefna@hachyderm.io avatar

@huitema

You really, really can't in this application. Or rather, building the tools and the set of tests around that, along with the expected outputs, would be at least as much work as putting everything in a type system

I was not entirely joking when I said that I was pretty sure that there were uncountably infinite nontrivial variations

You might be able to do it with fuzz testing, but it's a nontrivial problem

Also not an idle point that I have yet to see anyone do that here

@FenTiger

FenTiger,
@FenTiger@mastodon.social avatar

@hrefna Uncountably? That's surprising. I wouldn't have expected the infinity of nontrivial variations to be any more than merely countable. ;)

@huitema

hrefna,
@hrefna@hachyderm.io avatar

@FenTiger Same, but I can basically demonstrate that there are countably infinite variations from JSON-LD (depending on what we mean by trivial) and at least countably infinite variations from AS2 itself. That doesn't automatically mean uncountably infinite (and I am NOT going to attempt to run a diagonalization proof to determine this for a fact), but it meets several of the criteria I'd normally see in uncountable sets.

Could be wrong here, but that's my instinct.

@huitema

hrefna,
@hrefna@hachyderm.io avatar

@FenTiger

My real questions which I would like, in a non-shitpost sense, to see someone (who is not me) prove are something along the lines of:

  1. Whether generic parsing (or more precisely comparing two arbitrary objects) is NPC, EXPTIME-hard, or what exactly. Similarly memory complexity.

  2. Where it falls more generally in a formal grammar sense, though I'll freely admit I'm unlikely to understand the answer here (it's way outside of my area), but I'd still like to know it

@huitema

benpate,
@benpate@mastodon.social avatar

@hrefna I love my statically typed languages, but... Given that we’re parsing messages received at run-time, I don’t know how it’s possible to enforce type checking 100% at compile-time.

I’m experimenting with a “normalizer” filter that strips out anything in an AS/AP message that doesn’t fit what I want to see. I’ll let you know how it goes.

hrefna,
@hrefna@hachyderm.io avatar

@benpate I mean that also applies to a bunch of different things where we use protobuf: parsing messages received at run-time, but we can deserialize them into POJOs and whatever else. Most RPC systems have their quirks here, but work well enough.

Really I can also do it with most (typical) protocols.

But AS2 almost goes out of its way to make things difficult.

Interested to hear your results! So far my two most successful approaches are 1) Dynamic proxies 2) parsing it in multiple passes.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • fediverse
  • tacticalgear
  • thenastyranch
  • ethstaker
  • everett
  • Durango
  • rosin
  • InstantRegret
  • DreamBathrooms
  • magazineikmin
  • Youngstown
  • mdbf
  • slotface
  • GTA5RPClips
  • kavyap
  • JUstTest
  • tester
  • cubers
  • cisconetworking
  • ngwrru68w68
  • khanakhh
  • normalnudes
  • provamag3
  • Leos
  • modclub
  • osvaldo12
  • megavids
  • anitta
  • lostlight
  • All magazines