Ballerina Programing Language

Yes, the principle does actually mean that nonconforming inputs should be accepted. Well, only if someone has decided that their meaning is clear. But that is rarely so if you're outside of the spec. The intended meaning of a bunch of bits (syntax) can be anything, or nothing at all.

Sensible defaults can't be assumed; they have to be specified. My sensible may be your silly.

If a spec defines certain parameters, and neglects to say anything about their defaults, and an implemention assumes defaults, that will cause issues.

Firstly, the user will break if they go to another implementation which rejects their data. It's not that implementation's fault; it's just catching the error of missing values with unspecified defaults.

Worse, the user's data can silently be interpreted with some different defaults.

You have to be exactly as anal about case and white space variations as the spec says.

A C compiler or linker can't treat PrintF as printf just because the meaning seems clear enough, and PrintF has not been declared or defined.

> Whereas the eejits who invented HTML have a helluva lot to answer for.

In my original version of the comment I used HTML as an example, but decided to omit that.

The problem wasn't the invention of it (though that doesn't escape criticism) but rather the fact that during early Web history and during the first Browser War era, browsers tried to accept non-conforming HTML and render it anyway. Thus people writing bad HTML had no feedback. The pages looked good with whatever browser they tested with. So browsers had to scramble to reverse engineer and imitate each other's handling of bad HTML as good. The effects of that situation persist; it's not fully resolved.

That will happen with any interchange or storage format, if treated with Postel's principle.

Postel's principle is from the point of view of keeping the internet working, in a situation where messages pass through multiple hosts, which are inaccessible to either the sender or the receiver. If something is rejected due to violating a rule, there is no diagnosis; the symptom looks the same like a severed cable at the bottom of the ocean. It's understandable where that came from.

Postel's principle somewhat applies to intermediary data handlers.

If you're just routing messages, and see a message that you don't understand, then just pass it along.

The principle should be "have as little effect as possible; look at only the parts of data needed to do your job, and don't interpret and act on payloads that don't belong to you; try hard to route rather than drop."

I saw this at Kubecon 2018 and even got a sweater from the folks there. The idea of an all-in-one soup-to-nuts system is pretty unusual these days.

So, this is a fascinating project. I don't know how I'd introduce it at a company though. Maybe in a skunkworks group or something. Possibly if I was working as some sort of middleware-integrator group.

The JVM bits don't bother me, but it does make things heavierweight than I'd like.

Curious if anyone is using it, it seems to have tons of potential.

I saw their demo at Kube-Con Barcelona. Pretty cool stuff. They deployed the sample into kubernetes by generating YAML and docker via the compiler. An aspect that other languages should think of.