z3 VS returns

Code correctness is a lost art. I requirement to think in abstractions is what scares a lot of devs to avoid it. The higher abstraction language (formal specs) focus on a dedicated language to describe code, whereas lower abstractions (code contracts) basically replace validation logic with a better model.

C# once had Code Contracts[1]; a simple yet powerful way to make formal specifications. The contracts was checked at compile time using the Z3 SMT solver[2]. It was unfortunately deprecated after a few years[3] and once removed from the .NET Runtime it was declared dead.

The closest thing C# now have is probably Dafny[4] while the C# dev guys still try to figure out how to implement it directly in the language[5].

[1] https://www.microsoft.com/en-us/research/project/code-contra...

[2] https://github.com/Z3Prover/z3

[3] https://github.com/microsoft/CodeContracts

[4] https://github.com/dafny-lang/dafny

[5] https://github.com/dotnet/csharplang/issues/105

I believe, Nim also has this functionality, although, it uses the [0]Z3Prover tool with a nim frontend [1]"DrNim" for proving.

[0]https://github.com/Z3Prover/z3

Don't get me wrong, there are times when Microsoft got it right the first time that was technically far superior to their competitors. Windows IOCP was theoretically capable of doing C10K as far back in 1994-95 when there wasn't any hardware support yet and UNIX world was bickering over how to do asynchronous I/O. Years later POSIX came up with select which was a shoddy little shit in comparison. Linux caved in finally only as recently as 2019 and implemented io_uring. Microsoft research has contributed some very interesting things to computer science like Z3 SAT solver and in collaboration with INRIA made languages like F* and Low* for formal specification and verification. But all this dwarfs in comparison to all the harm they did.

Other than that, you should look at Z3 which is pretty damn good at these sort of theorems/constraints.

In the end I used Z3 Julia bindings instead. The hardest part was to get the result back from it, because I kept running into assertion violations from inside Z3

> And you propose me instead to go and reverse engineer library Js code which I am not that proficient in, and rewrite all code in Java instead?..

Yes, rather than demand others cater to your whims, frankly.

Do you realise how hypocritical it sounds to complain that you are not proficient in Javascript, when others might not be proficient in ?

Go use Z3 if you need a prover in C++ (or Java), its far more robust (provided its the type you're after) than someones 700 LoC JavaScript implementation.

https://github.com/Z3Prover/z3

My open-source project https://github.com/obijywk/grilops (excuse the shameless plug) can help when creating Nikoli-style grid logic puzzles, and we used it during the development of Ents, Resolution, and Missing Pieces (and to check uniqueness of Digital Gaming solutions). The constraint solver library it depends on, https://github.com/Z3Prover/z3 from Microsoft Research, is also very useful on its own, and we used it to help with the creation of Art Gallery and Global Shipping Crisis. Dennis Yurichev's SAT/SMT By Example is an extensive resource for learning how to use these kinds of tools to solve all sorts of problems, including puzzle solving.

returns – Make your functions return something meaningful, typed, and safe

returns from the DRY python group appears to offer similar functionality.

Not to diminish this at all, but https://github.com/dry-python/returns also exists. The scope is wider, but the look and feel of the types feels very similar.

https://github.com/dry-python/returns#maybe-container

You can decide for yourself what is more readable: all these lambdas or the `None and f()` code.

One of the repos that I found interesting recently is https://github.com/dry-python/returns

Functional semantics are available in Python, but IMO not that great. List, dict, and generator comprehensions allow you to perform most operations that you would use in a functional first programming language and there are third party libraries like toolz and funcy that implement some of the more advanced operations. The main issue I've found with using Python as a functional language is it doesn't support fluent syntax. With Scala you can do a relatively complex map/filter/reduce operation with syntactic ease list_of_ints.map(x => x*x).filter(x => x%2 ==0).reduce(x,y => x+y) With Python it's just clunky and less readable b/c of support of list comprehension syntax over fluent syntax. sum([x**2 for x in list_of_ints if x % 2 == 0]) A codebase with 5000 lines of the Scala style code will be much readable and maintainable than with the Python style code.

dry-python/returns is a library with primitives that make typed functional programming in Python easier.