Słaby argument. Można go sprowadzić do całkiem sensownego wniosku, stwierdzając, że skoro są unit testy to statyczne typowanie jest niepotrzebne.
Poprawiłem kilka słów w wypowiedzi (FTFY). ;)
Statyczne (w przeciwieństwie do dynamicznego) typowanie nie jest i nie powinno być celem samym w sobie.
Statyczne typowanie ma sens przy kompilacji AOT (ahead of time) - gdy błąd może zostać wychwycony, nim program zostanie wykonany.
W kompilacji JIT w konfiguracji per funkcja lub interpretacji kodu statyczne typowanie byłoby tylko upierdliwe.
W dodatku silne typowanie w wykonaniu C++ skutecznie utrudnia tworzenie heterogenicznych lub drzewiastych kontenerów, których struktura znana jest dopiero w runtime.
I to jest IMHO jeden z
głównych powodów, dla którego w większości zastosowań C++ jest naprawdę nieefektywne.
A więc co jest celem? Ja bym powiedział, że to, żeby program działał [w określonym stopniu]
niezawodnie i
zgodnie z oczekiwaniami.
I jeśli chodzi o spełnienie tego celu - testy (niekoniecznie unit testy!*) IMHO mogą z powodzeniem zastąpić statyczne typowanie.
Natomiast samo statyczne typowanie bez testów niestety niewiele pomaga.
Bugi w programach pisanych w C/C++ widuję chyba częściej, na pewno są one o wiele gorsze do diagnozowania (segfault i coredump vs. stacktrace, gdb vs. pdb).
* Sformułowanie "testy
jednostkowe" zaczyna mi wyglądać na kolejne magiczne słowo (buzzword), powtarzane bez głębszego zrozumienia. Może zostańmy przy samym "testy" albo "zautomatyzowane testy"?
Co innego silne (w przeciwieństwie do słabego) typowanie - to, że 2 stringi nie zostana przy porównywaniu przekonwertowane na liczby to dość elementarne oczekiwanie użytkownika.
Jak już znajdziesz ten artykuł to powiedz Xion-owi gdzie go ma żeby mógł go wykasować ;)
Bo jak by na to nie spojrzeć statyczne typowanie a Unit Test-y to zupełnie inne bajki.
Wykasuj lepiej tego posta. :P (ups, chyba go uwieczniłem w cytacie)