kvalitní statická analýza - nástroj versus typy rubrika: Programování: Jiné

16 Taco
položil/-a 14.4. 12:40
 
upravil/-a 16.4. 12:00

V sousední otázce řekl @Tomáš Tintěra "kvalitní statická analýza. (Ne typová kontrola, ale samostatný nástroj)".

Zajímalo by mě, dokážete si představit některé oblasti statické analýzy, které by typový systém nedokázal ošetřit? Pusťte si prosím fantazii na špacír. Třeba ošetřit meze polí lze pomocí Dependenci Types.

Nebavíme se o tom, že to ten který jazyk neumí. Ale spíš tak nějak z principu.

Děkuji.

[Edit] Chytil jsem se toho opakovaně omílaného tvrzení, že: "Toto sebelepší typová kontrola neodhalí a je potřeba analyzator". Samozřejmě typy jsou na něco jiného, ale stejně mi to zní jako blbost.

Komentáře

  • harrison314 : Ja mam dve doplnujuce otazky: Ktory jazyk ma podla teba dostatocny typovy system? Ratas do typoveho systemu aj napriklad Haskelovske vynutenie velkosti zaciatocnych pismen (funkcie malym, typy velkym)? 14.4. 18:22
  • Taco : @harrison314: Žádný nebude dostatečný. Ale velice slušný má Scala, Haskell, Rust. To bych považoval za takové minimum, o čem se dá bavit. ••• Spíše asi ne, protože ta velikost písmen je IMHO spíše otázka syntaxe. 14.4. 21:01
  • harrison314 : Vsteky funkcionalne - je ti jasne, ze FP kladie ine poziadavky na typy ako OOP? 14.4. 21:57
  • Taco : @harrison314: to si nemyslím a to si nemyslím. 15.4. 11:40
  • Kit : @Taco: Uvědom si, že OOP typy (tím méně statické) prakticky nepotřebuje. 15.4. 14:04
  • Taco : @Kit: To si nemyslím. 15.4. 18:52
odkaz
8 v6ak
odpověděl/-a 19.4. 16:11

Jsou tu věci, které může odhalit statická analýza i kompilátor, ale přímo s typy nesouvisejí: unreachable code, dead code, výraz, který se vždy vyhodnotí na true nebo vždy na false, … Statické typy zde mohou napovědět (collection.size() < 0 je blbost od pohledu, ale pokud neznáte typ proměnné collection, těžko to strojově odhalíte), ale pouze posilují možnosti.

Jsou tu věci, které lze odhalit pomocí typů, ale z různých praktických důvodů se to dnes nedělá. Kdybychom chtěli kontrolovat způsob stavění SQL nebo HTML, jsou na to nástroje, ale ne s každou 3rd party knihovnou jsou použitelné. A v neposlední řadě i nasazení na vlastní kód by znamenalo přepsat vlastní kód. Oproti tomu přidání analyzátoru je neinvazivní a relativně snadné.

Rozdělení, co dělá kompilátor a co 3rd party analýza, je otázka praktičnosti. Stejně jako nemohu po autorech jazyka chtít standardní knihovnu na všechno, na co si vzpomenu (stejně se vždy najde něco dalšího), tak nemohu chtít ani statickou analýzu všeho, na co si vzpomenu – stejně se vždy najde chytrá hlava, kterou napadne i něco dalšího.

Může být otázkou, proč ty analyzátory nejsou pluginy do kompilátoru. Nevím, možná kvůli neochotě autorů kompilátorů nabízet dostatečně stabilní API.

Komentáře

  • Taco : S tímto se určitě mohu stotožnit. 19.4. 17:17
  • Taco : S těmi typy: Máš třeba velice košatou funkci, která se dá zdrcnout/inlinovat do jedné hodnoty. A to jen díky tomu, že vím o těch jednotlivých tokenech, že jsou imutable... etc, etc. To je věc, kterou sebelepším externím nástrojem neuděláš :-) - ne, kecám. Třeba google-closure-compiler to dokáže i na tak blbém jazyce, jako je javascript. 19.4. 17:46
  • harrison314 : "Může být otázkou, proč ty analyzátory nejsou pluginy do kompilátoru. Nevím, možná kvůli neochotě autorů kompilátorů nabízet dostatečně stabilní API." - praveze C# analyzery su pluginy do Roslinu, alebo vyuzivaju jeho API. Zavednie takehoto API prinieslo to, ze to na co dovtedy treba komercny softver a dlhe roky vyvoja, tak dnes zvladne napisat hocikto na kolene 19.4. 19:28
  • Honza Břešťan : Unreachable/dead code muzou odhalit linear types a jejich pribuzni: https://en.wikipedia.org/wiki/Substructural_type_system. Na prvni pohled to muze vypadat dost intruzivne a tezkopadne, ale uz dnesni Rust a jeho reference ownership jdou timhle smerem. V budoucnu se mozna dockame, ze to vyvojari budou vnimat jako dneska treba "nove" javascriptove let a const bindingy, akorat s extra kontrolama, a ze se to podobne jako immutabilita stane mainstreamem. Ve spouste pripadu a hlavne u existujicich jazyku ale urcite dava smysl nechat tohle na separatnim nastroji mimo language design. 19.4. 19:56
  • v6ak : @harrison314: A teprve čas ukáže, jestli to udělali dobře, nebo jestli se z toho stane koule na noze, která bude bránit dalšímu vývoji kompilátoru. A i pokud to vyjde u C#, pochopím opatrný přístup u jiných jazyků. Možná to API bude časem standardní věcí u zavedených jazyků (Java, C, C++, …), ale ne u relativně nových (dnes třeba asi Swift, možná ještě Rust). 19.4. 19:58
  • harrison314 : @v6ak: Uz su to 4 roky, to nie je ziadna novinka. Myslim, ze s aspon produktoveho hladiska sa im to vyrazne vyplatilo. Pretoze analyzeri a refaktoringy tym oddelili od Visual Studia, co ho zrichlilo a rozne tretostranne pluginy ho nezhadzuju. 19.4. 22:03
  • v6ak : @harrison314: Čtyři roky jsou asi dostatečně dlouhá doba na to, abychom viděli, že se to chytlo, ale příliš krátká doba na to, abychom viděli případné problémy, které jsem zmiňoval. Až dejme tomu za deset let budou chtít překopat kompilátor, uvidí se, jak moc je toto API koulí na noze. 19.4. 22:10
  • Tomáš Tintěra : Podobně ve světě C++. API nabízí několik kompilátorů. Aktuálně vede Clang. Externí nástroje přechází na model, kdy jejich jádrem je kompilátor Clang. (Už proto udržuji svůj kód přeložitelný Clang-em, i když finální kód je generován něčím jiným.) Clang je součástí platformy https://llvm.org/ kde, pokud vím, je kompilátor "jen" (zjednodušeně) tvoří abstraktní syntaktický strom. Generování kódu je společné pro řadu jazyků. Čili design jde spíše směrem, kde jako kompilátor chápeme jen část toho, co dělal třeba kompilátor Turbo Pascalu. 22.4. 20:23

Pro zobrazení všech 8 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.