For many languages there are mature parsers out there that can be reused (e.g. Google's Closure compiler or babel for JavaScript, or the Soot framework for Java that also simplifies more advanced code analysis). In the worst case, it's sometimes possible to interface with the standard compiler for the language directly (for example, the TypeScript compiler provides TypeScript APIs for its parser/type checker/etc.). I believe for C++ for example, a Clang plugin (https://clang.llvm.org/docs/ClangPlugins.html) would have been a plausible way to implement something like this.
One example that comes to mind is type state [0]. I'm not aware of any other language (including those with support for dependent types, like Agda) where these properties can be checked without external static analysis tools and the problems they bring.
> If only Jolla devs had kept their promises of open-sourcing more of their code.
I think that's a big part of the answer to why it hasn't caught among techies. When I tried using it (shortly after release), there were numerous issues in their default apps that nobody could fix because they are proprietary and Jolla didn't seem to have the resources to handle all the bugs.
I'd wager that if it had been open source, the early adopters would have put some time in to fix a lot of the bugs.
In retrospect I'm pretty pissed at them for not being honest and upholding their promises. In my book they're basically con artists that just tried to get the Linux community's money by saying "open source" without actually meaning it.
This, along with Jolla's bankruptcy, is why I stopped using Sailfish as a former user. I didn't feel that I could depend on the platform sticking around.
I later switched to Ubuntu Touch because, despite Canonical picking up the project, the community had continued maintaining it. They could do that because it was freely licensed; nobody could do that for Sailfish.
A OnePlus One, though I have both a PinePhone and Librem 5 preordered, and I'm looking forward to giving both of those a try. The OPO is nice, though I've had issues with the battery life.
You can provide this implementation yourself easily enough though. I agree it's maybe not ideal that this needs to be done for every Trait you want this behavior for.
At least now we are checking that two pieces of saying what we want a program to do match up. It's less likely to get both the implementation and specification (in the form of types) wrong. Whenever the program fails to type-check, it will make you think about both bugs in the type and bugs in the code, even if the latter is more likely.
Types can’t encode the specification fully, or require a lot of work to encode a specification (so most people will skip this work).
The simplest example is very common banking and e-commerce logic which is basically a series of checks in the form:
if <some piece of data retrieved at runtime at that particular moment> is consistent with <multiple other pieces whose number and relevance depends on that data retrieved at runtime from potentially multiple sources>.
> At the same time we finally got a phone that is built with some security in mind (Librem).
If it ever materializes. It's already more than half a year behind schedule and after preordering it close to when it was announced, I'm very skeptical I'll ever receive it.
