No, a poza tym... statyczna analiza to nie wszystko, można też dokonywać dynamicznej analizy i śledzić uruchomiony program, a potem zbierać o nim dane z runtime'a i używać tych danych np. do autocomplete. W ten sposób można by uzyskać masę danych (podobno Visual Studio tak robi dla JSa, ale nie wiem jak to w praktyce wygląda, bo nie mam Windowsa nawet, to nie przetestuję. Póki co sam sobie eksperymentuję i tworzę bibliotekę do tego typu analizy).
Brzmi jak zakładanie majtek przez głowę. Jeśli to nie jest wystarczająco wygodne to dalej nie łagodzi problemu.
W każdym razie - statyczna analiza języka, który nie jest statycznie typowany to wyzwanie, ale jednak nie takie wielkie jak próbuje się wmówić ludziom. Po prostu ktoś musi usiąść i zastanowić się "jak zrobić statyczną analizę" a potem to zaimplementować np. jako wtyczkę do swojego ulubionego edytora (sam się bawię w tego typu rzeczy).
JetBrains zarabia kupę kasy na IDE, w szczególności na Webie - obsługa HTML, CSS i JS to elementy za które trzeba u nich płacić. Dziwne byłoby więc, gdyby celowo olewali JS i szli na łatwiznę. Z TSa przecież nie wyciągną takiej kasy jak z JSa.
na to są rozwiązania (najlepiej wszystkie cztery).
Po pierwsze trzeba założyć, że dyscyplina się nie skaluje. W dużych wieloletnich projektach jest tak, że programiści się zmieniają (rotacja), mają różny poziom zaawansowania i różne style kodowania. Nawet jeśli w danym momencie coś się ustali to i tak z czasem sprawy się pozmieniają, a kod będzie rozwijany w dziesiątkach różnych styli.
testy, żeby sprawdzić czy się nic nie zepsuło
To jest standard w każdym dużym projekcie i założyłem, że każdy to robi, także wtedy gdy pisałem o problemach z językami kaczo typowanymi.
dyscyplina zespołu, ustalone standardy kodowania
Jeszcze raz - dyscyplina się nie skaluje. Często jest tak, że czas goni i trzeba robić rozwiązania na szybko, a potem zbijać dług techniczny. W językach dynamicznych można iść na dużo większe skróty by osiągnąć cel i tym samym dużo więcej nabroić w takim samym czasie.
lintery do sprawdzania, czy standardy są zachowane
W językach statycznie typowanych lintery też są i z racji typowania języka mają obszerniejsze zestawy funkcjonalności. Jeśli projekt jest monolitem to łatwo dojść do takiego momentu kiedy ostrzeżeń wypluwanych przez kompilator czy innego sprawdzacza stylu jest na tyle dużo że łapie się na to znieczulicę. W Sabre tak miałem - moduł core przy kompilacji rzucał taką litanią ostrzeżeń, że mało kto próbował się w to wczytywać. Tutaj więc moim zdaniem dużo zależy od skali pojedynczej aplikacji.
Poza tym.... w startupie coś takiego własnie będzie zaletą a nie wadą i według mnie z punktu widzenia biznesu ma to sens by zrobić coś tanio i cool przy pomocy np. PHP.
A jak pomysł chwyci to przepisać np. na coś z JVM. Całe mnóstwo jest takich historii.
Są też sytuacje gdzie ugrzęźnie się w takim śmierdzącym PHP. Sztandarowy przykład - Facebook. Utknęli w PHP tak mocno, że stwierdzili że zrobią własną VMkę dla własnego dialektu PHP (HHVM dla języka Hack). Skala problemu musiała być ogromna by coś takiego im się opłacało.
