Kevered a dinamikus típusosságot a gyenge típusossággal. A két fogalom ortogonális egymásra, mind a négy lehetséges kombinációra tudok példát.
| Statikusa típusos | Dinamikusan típusos | |
|---|---|---|
| Erősen típusos | Java | Python |
| Gyengén típusos | C* | JavaScript |
* Erről megoszlanak a vélemények, az tény, hogy a C típusrendszere sokkal megengedőbb mint más statikusan típusos nyelveké, pl.: pointer artimetika, signed/unsigned közötti automatikus konverzió, boolean hiánya, stb.
Az, hogy egy referenciának nem ismered előre a típusát az a dinamikus típusossághoz köthető, a "type juggling" a gyengén típusossághoz.
Pont erről beszéltem, hogy le kell kezelni a type jugglingból eredő összes lehetséges állapotot, átfedést, fals pozitív konverziót (ld. a tábla) és ez fog a végén sokszoros munkaidőt és kódmennyiséget eredményezni. Nem értem mi nem érthető.
Privát kód esetén, amikor csak te hívod azt a kódot, akkor pontosan tudod hogy mivel hívod, felesleges lekezelni a nem létező eseteket. Ha 3rd party is hívhatja, akkor ledokumentálod mivel lehet hívni, ami abban nincs az nem definiált viselkedés. Ha te hívsz 3rd partyt, azon meg a rendes teszt lefedettség segít, de az nyelvfüggetlenül hozzátartozik a professzionális szoftverfejlesztéshez (értsd: akkor sem elfogadható ha egy Java kód nincs tesztekkel lefedve).
Tehát magad is elismered, hogy a JS típuskezelése annyira problémás, hogy megoldásnak azt javaslod, hogy inkább használjunk egy másik nyelvet, ami majd lefordul JS-re.
Ne forgasd ki a szavaimat, nem ezt állítottam. A TypeScript csak statikus típusosságot ad a JavaScripthez (lásd fenti táblázat, nem keverendő a type inference-szel), a típusrendszer a kettőben megegyezik. Mindkettőnek megvan a helye és előnyei-hátrányai. Vannak esetek, amikor a statikus típusosság segít, és vannak esetek, amikor csak hátráltat.