Both your examples (is my number prime, are my XML nodes unique) are easily expressed in a dependently-typed language.
Dependent type checkers may be hard to implement, but the typing rules are fairly simple, and people have been using this correct by construction philosophy using dependently-typed languages for a while now.
Now, are there really tools to make type systems with dependent types simple to prove? In reasonable time? How about the effort developers would have to put into just trying to express such types and into verifying that such an expression is indeed accomplishing its stated goals?
Just for a moment, imagine you filing a PR in a typical Web shop for the login form validation procedure, and sending a couple of screenfulls of Coq code or similar as a proof of your password validation procedure. How do you think your team will react to this?
Again, I didn't say it's impossible. Quite the opposite, I said that it is possible, but will be so bad in practice that nobody will want to use it, unless they are batshit crazy.
I love the idea, although it doesn't seem to perform very smoothly, even on simple examples. A related project is Penrose [^1], except the latter isn't interactive.
The problem is not solved by using unsigned ints though, because it stems from integer overflow. I'm afraid your implementations are, alas, also incorrect.
Their point was about having to pay to export your data. Afaik Bridge is still to this day only available to paying users. Still, their statement is no longer true since exporting in bulk is permitted for free with the Import-Export app.
I see it as a way of getting paid for the development of services. People willing to pay for an offering are more likely to provide quality feedback. Once it is stable there and dev time has been recouped, you can offer it to the free tier.
I actually don't have an issue with that. Once it is available to free tier users, it frees up the devs to go to the next item on the list once again only available to the paid users. Lather, rinse, repeat. Sounds like a fairly sound bizplan.
> I see it as a way of getting paid for the development of services.
The obvious reason is that a company has an incentive to make it easy to onboard and no incentive to help you migrate off or even an incentive to make it difficult or costly to leave. I don't see how making import/export something only a payed tier has is specifically or especially for funding development. It's not the deal breaker or the reason people choose Protonmail over others, even if it can be a consideration.
Do you not agree that the types of support requests or other feedback from the masses in the free tier tends to be of a much lower quality than you might get from a paid user? The expense of supporting those requests are not insignificant. By ensuring that the product is in a much more stable state before reaching the free tier can help keep those support costs lower.
>It's not the deal breaker or the reason people choose Protonmail over others, even if it can be a consideration.
Yet here we are on a dev centric forum talking about it being a "bad" decision. From a dev perspective, the decision of starting something in a paid tier then (if ever) releasing to the free tier is not offensive to me. A company offers a free thing that has fewer features than a paid tier, "news at 11" type of story it is not. Doing poor research into the limitations of the free tier and complaining publicly about not having access to the paid features on the free tier is also not news worthy. Again, yet, here we are.
Hey Dylan I saw your comment on USPS api. I am very much unguided on how to use it. Can you please email me? I don't know how to use it and I even called them, no luck! Please email me.
--impetus1 a t protonmail(dot)com.>
Good. If you want to pay with your personal data, use gmail. If you want to keep your personal data, then pay the people who run the service with actual money.
Briefly looking at the files and code it's hard to tell whether that is still the case, but it's fair to assume Import-Export would reuse most of the machinery behind Bridge.
bridge exposes imap making it easy to download all your data using Thunderbird or another client. I don't know about "export" because imap does what I want and is supported by most providers in the same format.
For those who care about OSS and moving to Protonmail from bigcorps email, this _might_ matter, although I think that for the majority of Protonmail users (which doesn't care much about open source), it doesn't matter.
Absolutely perplexed by the other answers that think CSS grid is a hammer for every nail. In your example without a table, you can just drop `display grid` and set `div {min-height: 33vh}`.
