I have been intrigued by the idea of visual coding tools for many years, but these kind of tools have always disappointed me. They remind me of the system used to teach small children to program in the programming language Scratch, see [Scratch].

I prefer to "visualize" my code as manipulating a set of logical assertions that characterize the state of the computation, ultimately reaching the point where the state of the computation's properties satisfy the requirements. Somewhat like that explained in [Gries1987] and [Dijkstra1976]. Visual tools are just too coarse to capture the details necessary to ensure correctness or real-life requirements.

While UML diagrams sometimes help to make sense of a complex set of OO Class relationships, this is far from how I normally work with the meaning of code in my head while programming.

[Scratch] https://en.wikipedia.org/wiki/Scratch_(programming_language)

[Gries1987] https://www.amazon.com/Science-Programming-Monographs-Comput...

[Dijkstra1976] https://www.amazon.com/Discipline-Programming-Edsger-W-Dijks...

Also, slightly less advanced:

A Discipline of Programming

https://www.amazon.com/Discipline-Programming-Edsger-W-Dijks...

For more practical fun, consider Frama-C, SPARK, and Dafny.

Heck, the basic methods of writing provably correct programs have been explained in plain English since at least the 70s:

https://www.amazon.com/Discipline-Programming-Edsger-W-Dijks...

https://www.amazon.com/Science-Programming-Monographs-Comput...

This is not some rocket science type verification with a dependently typed theorem prover language, it's fairly simple paper and pencil logic. It should not be hard to adapt it to Solidity specific concepts like running out of gas.

The reason these techniques are mostly ignored is that the techniques don't scale at all to large programs calling APIs with imprecise semantics (e.g. filesystem, network), and most people would rather publish imperfect software and iterate rather than spec everything up front. Well, unlike most software, contracts are not large, their semantics are meant to be 100% precise, and most people would rather take the time to make sure a contract does what it claims to do rather than discover a bug afterwards. I would hope.

Also see - "A Discipline of Programming" by Edsger W. Dijkstra

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkst...

His hand-written notes are here http://www.cs.utexas.edu/~EWD/. One biting example is http://www.smaldone.com.ar/documentos/ewd/EWD707_pretty.pdf.

His Discipline of Programming http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkst...

There are some here http://cs-exhibitions.uni-klu.ac.at/index.php?id=31 that might overlap with the texas ones. One famous one is about the cruelty of teaching computer programming: http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF.

His wikipedia page has links to a number of his seminal ideas.

Anything by EWDijkstra or CAR Hoare or David Gries.

The Science of Programming by David Gries was very good, it covered some maths needed for programming such as set theory and then it used its own programming language (based on Dijkstra's) to discuss programming language concepts that may come up. It had a great little section about deriving conditions based on loop invariants. Also there's a section on Predicates. Basically it covers all the stuff you'll need to know when using any programming language and that programming language tutorials fail to discuss.

You can see a preview at Google Books: http://books.google.ca/books?id=vv5pot-ySsEC&lpg=PP1&...

There's also A Discipline of Programming by Dijkstra and I love that one too. He has examples of great algorithms and the way he develops them is awesome: http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkst...

The reason books like that aren't written is because they're too academic for some peoples' tastes. Unfortunately, books like Head First or whatever else, sell like hot cakes because they appeal to the lowest common denominator of programmer, the one whose eyes glaze over whenever there's math involved (that's usually the North American programmer, Europeans (at least the French and Dutch) don't mind the math).

I also think a lot of people dislike books with several exercises because they add way more pages. You don't need 3-5 pages of exercises, older math books only had 0.5-2 pages of exercises. Older math books are also not cluttered like the modern textbooks.

You could also do what Dijkstra did, which was write. Think and write about your experience, think and write about how you will approach a problem and explore alternative solutions, etc. Make up your own little notation for programming so you can free yourself from worrying about some obscure syntax or library call in a language.

A hefty value, despite the need for much clicking as you paginate

reviews and such: http://www.amazon.com/Discipline-Programming-Prentice-Hall-A...