I've been thinking about #programming languages and types this morning.

Especially about the fallacy of trusting languages like #typescript on the actual shape of the data. I mean all your type annotations and etc still leave you very vulnerable to malformed data / errors during runtime and you end up having to add runtime validation anyways. My current conclusion is that #DesignByContract might be a better avenue for adding input / output verification to a dynamic language like #python or js.

I wonder where we'd be if all the money and time that has gone into typescript had gone into making contracts a viable tool in #javascript

Wikipedia has more info on design-by-contract: https://en.wikipedia.org/wiki/Design_by_contract

Including links to some projects that aim to add contracts to javascript.

@dekkzz76 @AmenZwa It's important to note that the majority of the problem is due to profit incentive and little else.

A low-regulation engineering field where for-profit actors have incentives to cut costs at every single corner they can. It's hard to imagine it ending any other way.

Also you can use unit tests to exercise a full #DesignByContract implementation too. #StaticVerification is not the only way to ensure a system is behaving correctly (and physical interference suggests it can't).

If you're serious about #objectOriented programming, try to use #DesignByContract to the fullest extent your language supports it. Your future debugging self will thank you. At the very least, liberally use #assertions throughout your code to state what should be true at any given point in your code.

https://en.wikipedia.org/wiki/Design_by_contract

#dbc #SoftwareEngineering

@xphentom Well, for one, you're missing regression tests. But more importantly, all of these, especially integration and unit tests will be greatly enhanced using #DesignByContract

https://en.wikipedia.org/wiki/Design_by_contract

#SoftwareEngineering #DesignByContract