## brian kernighan ### link
strong typing is telling the truth about data
there is also additional literature: link
-> strong typing is good because it prevents errors
the size of an array is part of its type (so it prevents from applying the same procedure to multiple arrays, from having common, general-pupose sub-routines). size shouldn’t be a part of the type. that’s obvious but WHY
no static attributes to variables means its forcing global scoping and cognitive overload (partly because it is far removed from the place where it is actually used). the locality is important
procedures must be declared before they are used (which is the opposite of how they are used: separation of similar/related things). this is mitigated by #include statements. this is for the convenience of the compiler rather than the convenience of the writer
no separate compilation, aka no standard for specifying that compilation
having to declare type names is useful for types that are used often (aka vector3 = arr[0..2]) but is a distraction for things used only once.
no casting (tihis seems to be a problem rather in terms of use than in terms of comprehension)
cannot guarantee the evaluation of a statement before the other (problem with i < max index && arr[i]> 0).
no break statements to exit loops
case statements do not have a default.
; is a separator, and not a terminator. he doesn’t like that because that means that “one hsould have a sophisticated understanding of what a statement it”. this implies that syntax should relieve us from cognitive load (cf. python indents)
no way to separate a function call from a variable: they both look like names (e.g. without the ())
it’s fine for non-efficient programs (i.e. non-real programs)
enum data types are nice
clumsiness