
Static Analysis - ibobev
https://nim-lang.org/blog/2020/06/08/static-analysis.html
======
Animats
The real benefit of static analysis is non-local. It's automatically catching
that A, which has some entry condition, is being called correctly by B, way
over in another file maintained by someone else. This is why the borrow
checker in Rust, which is a form of static analysis, is so valuable. It keeps
you from global ambiguity over who owns what.

Compare linters and style checkers, which merely enforce local no-nos. The
value in the more elaborate tools is automatically catching errors where each
piece of code looks fine in isolation. Proof of correctness work tends to
focus on local issues, because that's the academic history. But that's not
where it is really valuable.

~~~
nimmer
> the borrow checker in Rust, which is a form of static analysis, is so
> valuable

> Compare linters and style checkers

Odd comparison: static analysis is way more powerful than these two examples.

It can spot plenty of subtle bugs due to incorrect reasoning around a problem.

~~~
Cyph0n
Genuinely curious: is static analysis really more powerful than the Rust type
system + borrow checker?

A more concrete example: is Coverity + C more powerful than Rust?

~~~
thechao
There’s _no_ model more powerful than static analysis if, by static analysis,
they mean abstract interpretation: the Galois connection guarantees this.

~~~
a1369209993
> abstract interpretation

That's not what static analysis (which includes things like type-checking)
means _and_ that's not something you can do with general-purpose code, for
reasons related to Rice's theorem.

~~~
thechao
Type-checking is one of the classical examples of abstract interpretation —
it's mentioned in the original Cousot & Cousot paper (1977). Maybe you're
thinking of something else?

------
themodelplumber
I have no good reason to know about "full formal chains," and yet attempting
to read the article still managed to grind my programmer ego into the dirt. :)
Major respect to people who operate in that world.

Related to Nim in general: I'm excited to use Nim more. Prior to finding Nim,
I had this list of languages to explore in more depth: Python, Ruby, Lisp,
Pascal (though I still plan to explore those). Oh, and find a good scripting
language, in addition to one from the compiled language group. Oh, and avoid
anything too "enterprise". So if you know anything about Nim, you know why
this feels pretty amazing.

~~~
saghm
> Python, Ruby, Lisp, Pascal (though I still plan to explore those). Oh, and
> find a good scripting language, in addition to one from the compiled
> language group

It's interesting that you want to explore Python and Ruby more but seem to
consider finding a good scripting language as a separate goal. They're both
definitely scripting languages, so if you don't expect either to be good, why
do you want to explore them more?

~~~
themodelplumber
Could you clarify? I couldn't relate these back to my comment:

* but seem to consider ... separate goal

* if you don't expect either to be good

~~~
saghm
Sorry for the confusion; the part of the comment I was responding to was this:

> I had this list of languages to explore in more depth: Python, Ruby, Lisp,
> Pascal (though I still plan to explore those). Oh, and find a good scripting
> language, in addition to one from the compiled language group.

The phrasing of "oh, and find a good scripting language" makes it sound like
that's a completely separate goal than exploring Python, Ruby, etc. in depth.
It reads to me like you plan to explore those four languages, then afterwards
go find a good scripting language. This doesn't seem like it would be
necessary if you find either Python or Ruby to be a good scripting language
when you explore them, which implies that you don't expect to have found
either of them to be good. Given that, I was curious about your motivation to
explore those languages if you didn't expect them to be good.

Based on your confusion, it seems like you weren't intending these to be read
as separate goals. I'm still not sure why you'd explicitly call out "finding a
good scripting language" after mentioning you wanted to explore Python and
Ruby, but my initial question appears not to be relevant.

------
pietroppeter
Not yet released but the DrNim documentation is available online [1]. DrNim is
the tool that will provide Static Analysis to Nim (based on z3). This will be
probably presented in the upcoming Nim Online conference in June 20 [2].

[1] [https://nim-lang.org/docs/drnim.html](https://nim-
lang.org/docs/drnim.html) [2] [https://forum.nim-
lang.org/t/6418#39615](https://forum.nim-lang.org/t/6418#39615)

------
mkchoi212
I can't understand how people use languages without static analysis. The only
edge case I can think is using any scripting language to write a script that
is less than 1k lines. Are there any pros for languages that don't have static
analysis other than the fact that it allows "rapid development/prototyping"?

~~~
beders
So you don't know any successful projects in JavaScript, Clojure, Erlang,
Elixir, Groovy, Julia, R, etc. etc. etc.? ;)

There are well-known advantages and repeating them here will incite another
flame-war.

I can only speak from my 35 years of coding experience, spending most of that
time in the confines of static typing:

Most problems I solve today are not good fits for static types. They cause
major headaches along the road as your customer's needs change and as I get a
better understanding of the problem domain.

~~~
zozbot234
> Most problems I solve today are not good fits for static types.

This would seem to involve a widespread misconception about what static types
are really about. Languages that "don't have static types" are _not_
inherently more flexible than languages that do expose them; one can always
translate a "dynamic" program structure to a statically-typed language in a
way that preserves arbitrary flexibility in refactoring, prototyping and the
like. Many languages even provide a standard `Dynamic` type for this very
purpose.

~~~
beders
Yeah, which makes them so generic they become meaningless, like generic_map,
generic_attribute...no thanks.

If you want to define, transform and reason about your domain model at
runtime, dynamic languages are the way to go.

I know, I've been using static typing for most of my career. They become a
burden, refactoring or not. Now go back to your Haskell corner ;)

------
compressedgas
Looks like Dafny [https://www.microsoft.com/en-us/research/project/dafny-a-
lan...](https://www.microsoft.com/en-us/research/project/dafny-a-language-and-
program-verifier-for-functional-correctness/)

------
whitten
How common in the industry is the use of 'invar' to signal an invariant,
'ensure' to signal a postcondition, and 'require' to signal a pre-condition ?

~~~
rhencke
Eiffel uses 'ensure' and 'require' for these meanings.

.NET Code Contracts (may it rest in peace) uses 'Ensures' and 'Requires' for
these meanings as well.

~~~
whitten
what about for invariants ?

~~~
skrebbel
assert() is pretty much the industry standard for invariants, right? they're
usually evaluated at runtime but it should be perfectly possible for a static
analysis tool to "evaluate" them statically.

~~~
judofyr
assert() by itself is typically not the same as "defining an invariant". An
invariant is an expression which should be true for the whole life-time of the
block/function/program/anything, but assert() only defines an assertion at a
specific point.

~~~
nimmer
Plus, assert() is commonly used for runtime checks, not static analysis.

~~~
rurban
You can use static_assert but compilers observe assert already. assume is
another commonly used invariant.

