
Esverify: LiquidHaskell inspired verification for JavaScript - indolering
https://esverify.org
======
idle_zealot
I had the pleasure of taking a functional programming course taught by one of
Liquid Haskell's core contributors. Since then even relatively robust type
systems have always felt a bit lacking. Strict/static typing allows a compiler
to provide certain guarantees that dynamically typed languages rely on
manually written unit/integration tests for, and liquid types take this a step
further by allowing inline narrowing of types and specification of invariants.

The emergence of technologies like this and Rust's borrow checker have me
dreaming of a future where the writing tests is increasingly unnecessary, as
your language requires that you specify your invariants etc up front. That
combined with something like QuickCheck may make manually writing test cases a
thing of the past.

~~~
im_down_w_otp
There will invariably be some need for a kind of testing. Though we very
rarely utilize traditional unit tests. Property-based tests are our common
testing entry point.

"Model conformance" issues can go both directions. The model can diverge from
the implementation. The designer's intent can also be incorrectly expressed in
the model.

Some forms of testing can be useful in describing the problem domain and
expectations in a more approachable/transparent way, and those tests can be
used as part of an ensemble of methods to attempt to ensure the model
represents the designer's intent, and that the implementation conforms to the
model.

It's also extremely unlikely that even if you're able to verify your software,
that every other part of the stack/system will have the same assurances, and
in those cases some forms of testing can also be useful for building trust in
components that you have no proof for.

Disclaimer: this set of problems is what my company works on for life-critical
systems.

------
z3t4
About 15 years ago it was good practice in JavaScript to check the function
parameters to make sure the caller didn't do anything wrong, which would throw
a friendly error message to the developer. But this seem to be thrown upon by
new developers, they argue that it's "code clutter". This "code clutter"
however solves almost all problems with the dynamic nature of JavaScript. Also
type annotations and static typing do not substitute good documentation, nor
does it substitute testing.

------
jononor
This combined with TypeScript (which seems to be on their roadmap), and
property-based testing ala QuickCheck would be a serious toolkit for writing
more correct JavaScript.

------
roywiggins
This is tangential but this is the second post recently using fancy ligature
fonts in code examples and it's... jarring.

~~~
afranchuk
Yeah, they can definitely be jarring at first. But if you use them for a
little while in a terminal that supports them (I use kitty[1]), the non
ligature font will look jarring instead. I'm not so sure about using them for
online code samples, though...

[1]: [https://sw.kovidgoyal.net/kitty/](https://sw.kovidgoyal.net/kitty/)

~~~
roywiggins
Right- I did look at them when they first came to my attention and I do like
the look. If I were more of a fan of terminal customization I would probably
give them a go. But it's weird to see them in code samples online.

I remember when I first was looking at them, I realised that they aren't even
all consistent. I think it was the the "<=" ligature. <= can either be glossed
as a left arrow or a less-than-or-equal, and at least one font decided
somewhat inexplicably that it was an arrow. These fonts have no idea what the
semantics are of what you're actually coding (since they're just ligatures) so
insofar <= always means less-than-or-equal then you're fine, but if you find
some language where it means assignment you'll need a different font!

------
enturn
This seems similar to .Net Code Contracts. Although I've never used either so
couldn't say for sure.

------
indolering
Can I blame HN for the first letter being capitalized ? Could someone change
it to be all lowercase?

