it-swarm-eu.dev

Stojí statické psaní za kompromisy?

Začal jsem kódovat v Python primárně tam, kde není bezpečnost typu, pak jsem se přesunul do C # a Java tam, kde je.) Zjistil jsem, že bych mohl trochu pracovat rychleji a s menšími bolestmi hlavy v Pythonu, ale znovu, moje C # a Java aplikace jsou na mnohem vyšší úrovni složitosti, takže jsem nikdy nedala Python a pravý zátěžový test.

Díky táborům Java a C # to znělo, jako by bez toho, aby byla na místě typová bezpečnost, většina lidí narazila na nejrůznější hrozné chyby, což by znamenalo více problémů, než by stálo za to.

Nejedná se o jazykové srovnání, proto se prosím nezabývejte otázkami, jako je kompilované nebo interpretované. Stojí bezpečnost typu hitem rychlosti vývoje a flexibility? PROČ?

lidem, kteří chtěli příklad názoru, že dynamické psaní je rychlejší:

"Během vývoje používejte dynamicky psaný jazyk. Poskytuje vám rychlejší zpětnou vazbu, čas obratu a rychlost vývoje." - http://blog.jayway.com/2010/04/14/static-typing-is-the-root-of-all-evil/

110
Morgan Herlocker

Je to trochu mýtus, že si programátoři nemusí dělat starosti s typy v dynamicky psaných jazycích.

V dynamicky zadaných jazycích:

  • Stále musíte vědět, zda pracujete s polem, celým číslem, řetězcem, hashovou tabulkou, odkazem na funkci, slovníkem, objektem nebo podobně.

  • Pokud se jedná o objekt, musíte vědět, do které třídy patří.

  • Přiřazení jednoho z těchto typů proměnnému nebo funkčnímu parametru, u kterého se očekává, že bude jiným typem, je téměř vždy chyba.

  • Na nižší úrovni je třeba započítat například počet bitů nebo podepsané versus nepodepsané, pokud například vyplňujete paket TCP).

  • Můžete narazit na problémy, kde dostanete nulu, kde jste opravdu chtěli prázdný řetězec. Jinými slovy, stále ladíte chyby typu mismatch. Jediným skutečným rozdílem je, že kompilátor chyby nezachytává.

  • Řekl bych, že ani příliš nezaznamenáváte psaní -, protože máte tendenci chtít v komentářích dokumentovat, jaké jsou vaše funkční parametry místo toho, aby je dokumentovaly v kódu. Z tohoto důvodu jsou bloky komentářů ve stylu doxygenů v praxi mnohem populárnější v rámci dynamicky zadaného kódu, kde ve staticky psaných jazycích je většinou vidíte pouze pro knihovny.

To neznamená, že programování v dynamicky psaných jazycích není cítit příjemnější, protože kompilátor není vždy na zádech, a zkušení programátoři Nemá potíže s hledáním a opravou druhu chyb, které by statické psaní přesto zachytilo, ale je to zcela oddělený problém od údajného zvýšení účinnosti nebo snížení rychlosti chyb, pro které je dynamické psaní v nejlepším případě dokonce i se statickým typováním.

164
Karl Bielefeldt

Jak typy zesílí, mohou vám pomoci více - pokud, používáte je správně místo toho, abyste s nimi bojovali. Navrhněte své typy tak, aby odrážely váš problémový prostor, a logické chyby se pravděpodobně stanou neshodami typu kompilace namísto runtime crashů nebo nesmyslných výsledků.

124
geekosaur

Zřeknutí se odpovědnosti: Jsem milenec typu;)

Na vaši otázku je těžké odpovědět: Co jsou to kompromisy ?

Udělám extrémní příklad: Haskell , je to staticky napsané. Ve skutečnosti je to jeden z nejpoužívanějších jazyků.

Haskell však podporuje obecné programování v tom smyslu, že píšete metody, které pracují s jakýmkoli typem vyhovujícím určitému konceptu (nebo rozhraní).

Haskell dále používá odvození typu , takže nikdy nemusíte deklarovat typ vašich proměnných. Při kompilaci jsou staticky počítány, stejně jako a Python interpret by je spočítal při spuštění programu).

Zjistil jsem, že většina lidí, kteří jsou drsní na statickém psaní, si vlastně stěžují na něco jiného (výřečnost, bolest při přepínání jednoho typu ve prospěch jiného), ale Haskell nevykazuje žádné z těchto problémů, zatímco je staticky psán ...


Příklad stručnosti:

-- type
factorial :: Integer -> Integer

-- using recursion
factorial 0 = 1
factorial n = n * factorial (n - 1)

Kromě vestavěné podpory je obtížnější se zkrátit.

Příklad obecného programování:

> reverse "hell­o" -- Strings are list of Char in Haskell
=> "olleh"
> reverse [1, 2, 3, 4, 5]
=> [5,4,3,2,1]

Příklad odvození typu:

> :t rever­se "hell­o"
:: [Char]

které lze jednoduše spočítat:

  • "hello" je seznam Char (vyjádřený jako [Char])
  • reverse aplikováno na typ [A] vrátí typ [A]

Vyzkoušejte v prohlížeči

78
Matthieu M.

Líbí se mi jak staticky, tak dynamicky napsané jazyky. Dvě největší výhody typové bezpečnosti pro mě jsou:

1) Často můžete do značné míry odvodit, co funkce dělá čistě z typového podpisu (to platí zejména ve funkčních jazycích, jako je Haskell).

2) Když uděláte významný refaktor, kompilátor vám automaticky řekne vše, co musíte udělat, aby všechno fungovalo. Když v C++ něco refaktoruji, můj postup je často jednoduše a) změnit část, kterou vím, kterou chci změnit, a b) opravit každou chybu kompilace.

37
dfan

Osobně zjišťuji, že bezpečnost typu mi pomáhá rychleji se rozvíjet v mé současné práci. Kompilátor pro mě hodně kontroluje zdravý rozum téměř při psaní, což mi umožňuje více se zaměřit na obchodní logiku, kterou implementuji.

Sečteno a podtrženo, je to, že ačkoliv ztratím určitou flexibilitu, získávám nějaký čas, který by jinak strávil sledováním typů problémů.

29
Michael K

V debatě je spousta silných názorů, ale zjevně nejde o názor, jde o fakta . Takže bychom se měli podívat na empirický výzkum . A důkazy z toho jsou jasné:

Ano , statické psaní stojí za kompromisy - a to nejen o kousek, ale ve skutečnosti podstatně . Ve skutečnosti spolehlivé důkazy ukazují, že statické psaní může snížit počet chyb v kódu alespoň o 15% (a to je nízký odhad, skutečný procento je téměř jistě větší). To je šokující vysoké číslo: Myslím, že ani většina zastánců statického psaní by si nemyslela, že by to udělalo tak drastický rozdíl.

Zvažte toto: pokud vám někdo řekl, že existuje jednoduchý způsob, jak snížit chyby ve vašem projektu o 15% přes noc, mělo by to být naprosto nemyslitelné.1  Je to téměř příslovečná stříbrná kulka.

Důkazy jsou prezentovány v příspěvku Jak psát nebo psát: Kvantifikace detekovatelných chyb v JavaScriptu od Zheng Gao, Christian Bird a hraběte T. Barra. Povzbuzuji každého, aby si ho přečetl, je to dobře napsaný dokument, který představuje příkladný výzkum.

Je těžké stručně shrnout, jak pečlivě autoři provedli svou analýzu, ale zde je (velmi hrubý) obrys:

TypeScript a Flow jsou dva programovací jazyky založené na JavaScriptu, které, i když zůstávají jinak kompatibilní, přidávají typové rady a kontrolu statického typu. To umožňuje rozšířit existující kód podle typů a poté jej zkontrolovat.

Vědci shromáždili Open Source projekty napsané v JavaScriptu od GitHub, podívali se na vyřešené zprávy o chybách a pokusili se redukovat každou z nahlášených chyb na kus kódu, který by byl zachycen statickou kontrolou typu TypeScript nebo Flow. To jim umožnilo odhadnout spodní hranici procenta chyb, které by bylo možné opravit pomocí statického psaní.

Vědci přijali přísná opatření, aby zajistili, že jejich analýza nebude považovat chybu netýkající se typu za chybu související s typy.2

Ve srovnání s předchozími studiemi má tato nová studie zvláštní přednosti:

  • Existuje přímé porovnání statického vs. dynamického psaní, s několika (pokud vůbec) matoucími faktory, protože jediný rozdíl mezi JavaScriptem a TypeScript/Flow je psaní.
  • Provádějí replikaci napříč různými dimenzemi kontrolou jak TypeScript, tak Flow (tj. Různých typů systémů) a tím, že různí lidé reprodukují anotaci (manuální) typu, aby opravili chyby. A provádějí to na velkém počtu kódových základen z různých projektů.
  • Příspěvek měří přímý dopad statického psaní na opravitelné chyby (spíše než na nejasnější kvalitu).
  • Autoři definují přísný model toho, co měřit a jak, dopředu. Jejich popis je navíc neuvěřitelně jasný a usnadňuje analýzu chyb (je to vždy dobré, když se výzkumná práce otevře útokům: pokud žádné útoky nedokážou protrhnout své argumenty, vyjde to ještě silněji).3
  • Provádějí řádnou výkonovou analýz , takže jejich velikost vzorku je dostatečná a jejich následná statistická analýza je vzduchotěsná.
  • Jsou příliš konzervativní, aby vyloučili matoucí vysvětlení a měřili pouze jednu pohyblivou část. Dále omezují svou analýzu na chyby, které jsou okamžitě opravitelné zahrnutím typů, a vylučují vše, co by pro přizpůsobení psaní vyžadovalo pokročilejší refaktoring. Takže ve skutečnosti je efekt pravděpodobně mnohem větší, ale rozhodně není menší, než to, co uváděli.
  • A konečně nenajdou mírný efekt, ale ohromující rozdíl. Přes jejich příliš konzervativní postup, dokonce na spodním konci 95% intervalu spolehlivosti zjistí, že existuje alespoň 10% chyb, které by jednoduše zmizely s minimálními kontrolami přidaného typu.

Pokud v dokumentu není zásadní chyba, kterou nikdo dosud neobjevil, ukazuje papír přesvědčivě velkou výhodu statického psaní, a to téměř bez nákladů.4


Podle historické poznámky měl výzkum psaní oborů v programování skalnatý začátek, protože po dlouhou dobu nebyly důkazy jasné vůbec jasné. Důvodem je to, že provádění systematických experimentů za účelem zkoumání účinku statického vs. dynamického psaní není snadné: systematický experiment musí izolovat účinek, který zkoumáme. A bohužel nemůžeme izolovat účinek psaní disciplíny, protože je vázán na programovací jazyky.

Ve skutečnosti existovaly programovací jazyky, které umožňovaly statické i dynamické psaní v různých dialektech (např. VB s Option StrictOn nebo Off nebo staticky zadaný LISP). Nebyly však vhodné pro přímé srovnání, zejména proto, že neexistovaly žádné dostatečně velké kódové základny, které by umožňovaly přímé srovnání. V nejlepším případě bychom je mohli porovnat v „laboratorním nastavení“, kde testované subjekty náhodně řeší úkol ve staticky nebo dynamicky zadané variantě jazyka.

Tato umělá přiřazení programování bohužel nemodelují použití v reálném světě. Zejména mnoho z nich má malý rozsah a řeší dobře definovaný problém, který lze shrnout na půl stránky textu.

Naštěstí to je v minulosti, protože TypeScript, Flow a JavaScript jsou ve skutečnosti stejné jazyky, s výjimkou statického psaní, a protože existuje rozsáhlá datová sada kódu a chyb v reálném světě, ze kterých se dá vzorovat.


1 Inspirován citací z původního papíru.

2 Nejsem s tím úplně spokojen: jednou z hlavních sil staticky typizovaných jazyků je to, že problémy, které se zdánlivě nesouvisejí s typem, mohou být formulovány způsoby, které lze staticky zkontrolovat typem. To transformuje mnoho logických chyb na typové chyby, které drasticky zvyšují míru chyb, které mohou být zachyceny statickým typem. Ve skutečnosti papír zhruba klasifikuje chyby, které se netýkají typu, a tvrdím, že velké procento z nich by ve skutečnosti mohlo být zachyceno statickým typováním.

3 Vyzývám kohokoli, zejména zastánce dynamického psaní, aby se pokusil najít v analýze neadresované nedostatky. Nemyslím si, že je jich mnoho (pokud existují) a jsem přesvědčen, že žádná potenciální chyba by výsledek podstatně nezměnila.

4 Mám podezření, že skutečné náklady na statické psaní v reálných rozsáhlých projektech neexistují, protože se pak stanou přirozenou součástí architektury a mohou dokonce zjednodušit plánování. Oprava chyb statického typu vyžaduje čas, ale mnohem méně než chyby objevené později. Toto bylo rozsáhle empiricky studováno a bylo známo po celá desetiletí (viz např. Kód dokončen ).

14
Konrad Rudolph

Stojí bezpečnost typu hitem rychlosti vývoje a flexibility?

Takže to vlastně jde o to, co děláte. Pokud programujete, záložní systémy pro letadla, typ bezpečnosti je pravděpodobně způsob, jak jít.

Dynamický jazyk vs Statické jazykové programování jsou opravdu dvě různá zvířata. Oba vyžadují od sebe zásadně odlišný přístup. Většinou můžete přenést metodu přístupu mezi statickou a dynamickou, ale ztratíte výhody ostatních.

Je to opravdu myšlení. Je jeden lepší než ten druhý? To opravdu záleží na tom, kdo jste a jak si myslíte. Většina lidí, se kterými pracuji, by se nikdy nedotkla dynamického jazyka, pokud by to nemuselo, protože mají pocit, že existuje příliš mnoho místa pro chyby. Mýlí se to myslet? Ne, samozřejmě, že ne, ale to znamená, že si uvědomili, že jejich přístup k aplikaci jejich stylu kódování nebude fungovat v dynamickém prostředí. Ostatní lidé, se kterými chodím do skupin uživatelů, jsou pravý opak. Považují statické psaní za příliš těžkopádné, protože to omezuje jejich přístup k řešení určitých typů problémů.

Mohu upřímně říct, že hodně přecházím mezi JavaScriptem a C #. Znalost a práce v obou jazycích teď do jisté míry ovlivňují ostatní, ale ve skutečnosti je kód, který píšu, v každém pohledu úplně odlišný od druhého. Vyžadují odlišný přístup, protože se zásadně liší. Zjistil jsem, že pokud zjistíte, že přemýšlíte: „Člověče, je to mnohem těžší udělat v jazyce X,“ váš přístup je asi trochu mimo. Zde je příklad, že lidé mluví o „pythonickém“ způsobu práce. Znamená to, že existuje způsob, jak jazyk Python jazyk funguje, aby se problém usnadnil. Dělat to jiným způsobem je obecně těžší a těžkopádnější. jak jazyk funguje, aby to skutečně fungovalo pro vás. Je to totéž s dynamickými vs. statickými jazyky.

12
kemiller2002

Nedávno byla položena podobná otázka: Dynamické vs. Staticky napsané jazyky pro webové stránky

Abych zopakoval jádro mé odpovědi:

Jak se systémy zvětšují, staticky psané jazyky zajišťují robustnost na úrovni komponent, a tedy flexibilitu na úrovni systému.

Ano, Java je striktně napsáno a ano, Java saje (bez urážky. Je to hrozné. Je to hrozné) skvělá platforma a ekosystém, ale jeden z nejhorších jazyků vůbec (ve skutečnosti používán)).
Z toho však lze odvodit, že přísné psaní na hovno je jen klam. Je to jako ukazovat na PHP a odvodit dynamické psaní na hovno (znovu, bez urážky. Pomalu se to zlepšuje, dávám ti to).

Osobně dělám většinu svého vývoje v haXe , který má systém statického typu. Nejen, že je výrazně výraznější, než u Java a vyžaduje to mnohem méně úsilí v důsledku odvozování typu), ale je to také volitelné. Pokud se vám to někdy dostane do cesty, stačí jej obejít .

Bezpečnost typu je funkce (to je něco, co mnoho údajně vysoce kvalitních jazyků nemá pravdu) , které vám pomohou zabraňte střelbě do nohy .
A o jakémkoli úspěšném dynamicky napsaném jazyce by bylo prostě lepší, kdybyste měli možnost nechat si typ kódu zkontrolovat podle libosti.
Například se mi určitě líbilo experimentování s Ruby, ale to bylo hlavně proto, že Ruby je plně objektově orientováno, což je zcela ortogonální k přítomnosti kompilačního systému typu času).

Myslím si, že tvrzení, že systémy statického typu jsou rušivé, je založeno pouze na nedostatku znalostí dobrých systémů statického typu. Existuje řada jazyků, které to dělají správně, protože je jedním z nich a v tomto ohledu pravděpodobně není ani nejlepší.

Příklad haXe kódu:

class Car {
    public function new();
    public function wroom() trace('wroooooooom!')
}
class Duck {
    public function new();
    public function quack(at) trace('quackquack, ' + at + '!')
}

function letQuack(o) o.quack();
letQuack(new Car());
letQuack(new Duck());

To způsobí chybu kompilace času:

Car should be { quack : Void -> Unknown<0> }
Car has no field quack
For function argument 'o'
Duck should be { quack : Void -> Unknown<0> }
Invalid type for field quack :
to : String -> Void should be Void -> Unknown<0>
For function argument 'o'

Nemůžete opravdu tvrdit, že jsem musel věnovat velkou pozornost bezpečnosti typu.

Říkat, že nepotřebujete bezpečnost typu, protože testy máte ještě idiotičtější. Písemné testy jsou nudné a opakující se. A já opravdu nechci psát test, jen abych zjistil, že případ Cara nebude šarlatán a Duck potřebuje někoho, kdo by šokoval.

Na konci dne zjistíte, bez ohledu na to, kolik vás stála bezpečnost režijního typu, nakonec je amortizován (dokonce i v Java - i když možná ne tak brzy).

7
back2dos

Záleží.

Režimy selhání člověka jsou často statistické. Silná kontrola typu snižuje pravděpodobnost několika určitých typů lidských selhání (způsobujících kód buggy). Ale to, že můžete selhat, neznamená vždy, že budete (Murphy neodolá).

Zda toto snížení pravděpodobnosti selhání stojí za cenu, záleží.

Pokud píšete kód pro jadernou elektrárnu nebo systém ATC, může být jakékoli snížení režimu selhání člověka extrémně důležité. Pokud rychle prototypujete nějaký nápad na webu, který nemá žádnou specifikaci a má důsledky téměř nulového selhání, pak vám může nebo nemusí dojít ke snížení poruchových režimů nebo pravděpodobností, ale může vás stát v době vývoje (více úhozů atd.), a v mozkových buňkách rozptýlených zapamatováním aktuálního požadovaného typu (typů).

5
hotpaw2

Z jakéhokoli důvodu nedělám chyby související s typem objektu, který často už ne. V jazycích, jako je C #, s větší pravděpodobností dělám chyby související s runtime obsazeními, než s největší pravděpodobností udělám kompilátorem detekovatelnou typovou bezpečnostní chybu, která, jak uděluji, je obvykle způsobena občasnou potřebou obejít statičnost staticky psaný jazyk. Když píšu Ruby, kód má sklon spíše naznačovat typ objektu a dostupnost a REPL znamená, že už jsem experimentálně ověřil, že požadovaná metoda/atributy existují, nebo Budu mít jednotkový test, který v zásadě dělá to samé, a tak jsem také zřídka narazil na bezpečnostní problémy typu Ruby.

Ale to neznamená, že staticky napsané systémy nemohou být lepší, než jsou.

Ve staticky psaných jazycích je důležitý také typ systém. Jako příklad, s něčím jako Nějaký monad ve funkčních jazycích (typ <Some>: = yes x | no), získáte kontroly kompilace, které v zásadě zabraňují obávané NullReferenceException běžné ve většině typů systémů; při spuštění kódu odpovídající vzor dostanete chyby kompilace času, které vám sdělí, že se vám nepodařilo zpracovat nulovou podmínku (pokud tento mechanismus použijete k deklarování typu). Podobné typy chyb také omezíte, když používáte například F potrubní operátor |>.

V tradici statického psaní typu Hindley-Milner můžete vytvářet věci, které vám dávají mnohem více než záruku, že typ požaduje podporu rozhraní X, a jakmile tyto věci máte, řekl bych, že staticky zadaný systém se stává hodně cennější.

Pokud to není možnost, rozšíření Design by Contract for C # mohou přidat další sadu mechanismů, které zvyšují hodnotu systému statického typu, ale stále vyžadují více disciplíny než některá z těchto funkčních paradigmat.

5
JasonTrue

Typy jsou omezení na rozhraních, takže jsou podmnožinou toho, co byste mohli chtít vyzkoušet pomocí jednotkových testů, a proto je řada kompromisů podobná:

  • Statické typy dávají dřívější zpětnou vazbu o tom, zda kód splňuje požadavky, které může typový systém vyjádřit, výměnou za zpoždění zpětné vazby od vytváření něčeho minimálně funkčního (jako je zpětná vazba od zákazníka nebo testy vyšší úrovně).
  • Znalost, že kód splňuje určité požadavky, může usnadnit refaktoring a ladění, ale také zvyšuje režii měnícím se rozhraním a měnícím se požadavkům.
  • Obzvláště pokud staticky napsaný jazyk postrádá nátlak, poskytuje dodatečnou bezpečnost před používáním kódu na datech, která by způsobovala chyby (snižuje potřebu podmíněnosti a tvrzení), ale příliš omezující omezení vyžadují, aby uživatel napsal více kódu pro masírování svých dat do přijatelná forma (například explicitní typ casting).
  • Explicitní anotace typu mohou pomoci pochopit při čtení kódu, nebo to může nepořádek kód s nadbytečnými nebo zbytečnými informacemi.
  • V závislosti na implementaci se může odvrátit od napjatosti. To záleží na věcech, jako jsou povinné nebo odvozené anotace typu, jak dobře může typový systém vyjádřit obecné typy/rozhraní, syntaxi a zda jste zamýšleli otestovat omezení, která mohou být vyjádřena typovým systémem (tj. stejný test je pravděpodobně přísnější než jazykový prvek než jako jednotkový test, ale pravděpodobně jste to nechtěli testovat).
  • Kromě toho (ale nesouvisející s TDD) mohou statické typy pomáhat při kompilaci optimalizace času na úkor požadavku kontroly typů (a získání času na jejich kontrolu a provedení optimalizací) a lepší optimalizace může být provedena, pokud jsou data omezena na typy které dobře mapují hardware. To usnadňuje vývoj kódu s požadavky na výkon, ale může to způsobovat potíže kódu, který se těmto omezením dobře nehodí (podle bodu 3).

Abych to shrnul, tvrdil bych, že dynamické jazyky jsou zvláště užitečné pro prototypování, zatímco pokud si musíte být jisti, že váš kód je správný, měli byste upřednostnit silný typ systému.

4
T.R.

Ano, určitě. Jedna věc, kterou najdete, jak používáte jak silně psané jazyky, tak Python (Python je silně psaný) je to, že většina dobře napsaného kódu v dynamických jazycích má tendenci řídit se stejnými konvencemi jako silně psaný kód. Dynamické psaní je velmi užitečné pro serializaci a deserializaci, ale pro většinu ostatních věcí opravdu nepřispívá k žádné výhodě. A pokud většina vašeho kódu nesouvisí se serializací, proč vynechat bezplatnou kontrolu chyb?

3
Mason Wheeler

Morgane, mám pro tebe zajímavý nápad: statické + dynamické psaní. Zmínili jste Python, C # a Java. Věděli jste, že existují nějaké docela dobré porty Python k .NET a Java?) V obou případech vám tyto porty umožňují používat knihovny těchto platforem a/nebo spolupracovat s existujícím kódem. To vám dává několik možností:

  1. Zachovejte starý kód ve statickém, nepružném jazyce. Pro nové věci použijte Python).
  2. Pomocí Python) prototypujte nové věci na vyspělých platformách. Překódujte komponenty, které chcete zachovat, ve vyspělejším jazyce.
  3. Pro části, které se často měníte, použijte dynamický jazyk.
  4. Případně použijte dynamický jazyk pro hraní s nápady, jako je úprava spuštěného kódu.
  5. Udělejte vše v dynamickém jazyce, s výjimkou kritických částí, kde používáte silně psaný jazyk.

Tyto přístupy jsem použil již v 90. letech, abych se zbavil bolesti vyvíjené v C/C++. Potřeboval jsem nativní knihovny a někdy i výkon. Přesto jsem chtěl lepší syntaxi, flexibilitu, bezpečnost atd. Trik je proto pečlivě kombinoval, aby získal správný kompromis. V praxi to bylo často lepší než vyhodit celý jazyk a starší kód pro jiný jazyk/platformu.

(Poznámka: Odpověď již řekla, ale také chci znovu zdůraznit, že dynamické psaní! = Žádné/slabé psaní. Mnoho systémů dynamického typu používá silné psaní uvnitř. Způsob, jakým přemýšlím o tom, co způsobuje dynamiku typu, je, že typ proměnné je určen za běhu, nevyžaduje anotaci typu a/nebo se může měnit za běhu.

3
Nick P

V LISP bylo napsáno mnoho velmi komplikovaných systémů a neslyšel jsem žádný Lisper, který by si stěžoval, že chtěli statické psaní. Když jsem s tím pracoval, nevzpomínám si na žádné problémy, které by mě hodně zpomalily, než by to zachytil statický typový systém (a ty můžete určit staticky v Common LISP).

Navíc se zdá, že mainstreamové staticky psané jazyky nejsou pro zachycení chyb dobře vhodné. Při navrhování rozvržení je důležité, že určité číslo je svislé měření na stránce, ne zda je to int, unsigned, float nebo double. Na druhé straně kompilátor často označí převody typu, které považuje za nebezpečné, a naštěstí mi dovolím přidat svislé měření a počet znaků v řetězci. Tato slabost systému statického typu byla původní myšlenkou Simonyiho maďarské notace, než byla zničena v ošklivou zbytečnost.

3
David Thornley

Vidím, že se tato otázka objevuje hodně, a myslím si, že kvalita vašeho softwaru (a nedostatek chyb) má více co do činění s vývojovým procesem, způsobem, jakým je váš systém architekturován, a závazkem vás a vašich vrstevníků ke kvalitě kódu.

Moje poslední práce byla většinou python vývoj. Pracoval jsem pro velkou mezinárodní webhostingovou společnost a měli jsme dev týmy v USA, Kanadě a Jižní Koreji. Vlastní python webový rámec pro klientskou aplikaci front-end, který uživatelům umožnil spravovat jejich doménová jména a účty webhostingu. Backend: all python too. Python webová služba pro rozhovory s jednotlivými servery, jako je poskytování nového webhostingového serveru, vytvoření nového blogu, vytváření dns záznamů v našem systému názvových služeb; atd. atd. V mé současné práci klientské aplikace naše vše v Javě; Naším hlavním produktem je směs Java a flash. Vlastní Java webový rámec pro naše starší aplikace, branka pro naše novější interní nástroje.

Poté, co jsem pracoval v obou, musím říci, že tato otázka mě opravuje pokaždé, když to vidím. Pokud používáte dynamicky psaný jazyk a skutečně testujete svůj kód, budete v pořádku. Pokud je systém navržen dobře a dodržujete standardy, budete v pořádku. Kvůli nedostatku typů kompilátorů nikdy nevzniklo mnoho chyb. Většina chyb byla logickými chybami, stejně jako moje dnešní Java práce.

2
LGriffel

Stojí bezpečnost typu hitem rychlosti vývoje a flexibility? PROČ?

Statické psaní je síť zvýšení v rychlosti a flexibilitě vývoje v průběhu životního cyklu softwaru. Snižuje celkovou námahu a nepohodlí, ale hodně úsilí a nepohodlí posouvá dopředu, kde je to patrnější. Bariéra vstupu do pracovního kódu je vyšší, ale jakmile tuto bariéru překonáte (splněním kontroly typu), rozšíření a údržba tohoto kódu zabere mnohem méně práce.

Při vývoji softwaru bude vždy existovat bolest hlavy kvůli:

  • Vlastní složitost toho, čeho se snažíte dosáhnout

  • Inherentní omylnost člověka, zejména s ohledem na to, že při pokusu o něco složitější děláme více chyb

Dříve nebo později budete muset věnovat nějaký čas řešení těchto problémů. Nedá se to obejít. Statické psaní jednoduše řeší tyto výzvy dříve než později. Dříve je lepší než později, protože čím později odhalíte chybu (ne otázku pokud, ale kdy), tím více je oprava této chyby dražší.

Oprava chyby hlášené typovým kontrolorem je mnohem nižší než náklady na ladění výjimky související s typem vyvolané za běhu. Odložení kontroly typu za běhu je pouze zametání problému pod koberec.

2
Jordan

Na to nedostanete skutečně objektivní odpověď, ale moje zkušenost je taková, že bezpečnost typu je neocenitelná dokud, kterou ovládáte TDD. Jakmile máte silné pokrytí jednotkovým testem, kde byly testy napsány před kódem, kontrola kompilátoru se stane bolestí a ve skutečnosti se vám začne bránit.

2
pdr

ANO.

Pracoval jsem v PHP aplikacích, kde typy nejsou tak „silné“ jako v Java nebo C #.) Obvykle jsem dokončil „simulaci typů“, protože v aby se zabránilo špatným automatickým převodům nebo ověřování údajů.

Jazyky dynamického typu jsou dobré pro O.S. skripty a rychlé malé aplikace., ne složité aplikace.

Shrnutí: Pokud si musím vybrat mezi "slabým typem" nebo "dynamickým typem" programovacím jazykem, nebo "silným typem" programovacím jazykem pro komplexní obchodní aplikaci, zvolím "silný" Zadejte „Programovací jazyk .

0
umlcat

Myslím, že se vyplatí udělat krok zpět a zvážit, kdy dynamické psaní způsobuje problémy.

Jedním případem je případ, kdy větev kódu není vůbec testována, ale upřímně řečeno, kód, který není nikdy testován, bude pravděpodobně buggy, ať už se dynamické psaní používá nebo ne.

Dalším jemnějším problémem je však nedokonalá zastupitelnost.

Pokud je typ prostě úplně špatný, pak pokud není nikdy použita konkrétní cesta kódu, je pravděpodobné, že bude rychle detekována.

Na druhou stranu, pokud je typ nedokonalá náhrada, pak kód může většinou fungovat, ale rozbije se jemnými způsoby, které nebudou detekovány až mnohem později.

Dva z nejčastějších typů v programování jsou čísla a řetězce. V mnoha dynamických jazycích jsou pro sebe nedokonalými náhradníky. Řekněme například javascript nebo php, pokud zadáte číslo, kde se očekává řetězec, nebo naopak, váš program se spustí, aniž by došlo k chybě, ale může se chovat poněkud jemněji.

Python se vyhnul tomu, že konkrétní problém, čísla a řetězce nejsou v žádném případě navzájem substituenty a pokus o použití jednoho tam, kde se očekává druhý, povede obvykle k rychlému selhání.

Nedokonalému problému susbstituibility se však nevyhnul úplně. Různé typy čísel mohou být navzájem nedokonalými náhradami, stejně tak různé typy sekvencí.


Přicházím sem, nemyslím si, že je možné porovnat výhody a náklady statického a dynamického psaní obecným způsobem, protože si myslím, že výhody i náklady závisí na konkrétní variantě statického nebo dynamického psaní jazyka použití.

0
Peter Green

To je jen můj vlastní názor, ale ne, nemyslím si, že bezpečnost typu stojí za to. Ani na vteřinu.

Dlouho jsem vývojářem. Počínaje c ++, c #, poté se přesunul do javascriptu (frontend a backend přes node.js). Od doby, co jsem se vyvíjel v javascriptu, se moje produktivita prudce zvýšila, a to až do té míry, že se ve skutečnosti ztížím pomocí jazyků založených na typu. Jsem také proti kompilaci, chci, aby teď bylo vše v běhu. Interpretované jazyky jsou opravdu místem, kde jsem našel lásku k programování.

Pokud jde o typy, prostě nevidím žádné výhody. Vidím typy nyní stejným způsobem, jako vidím správu paměti. Zcela zbytečné. Jazyky zítřka by měly vývojáře zcela chránit před věděním něco o typech. Počítač by měl rozumět typům a nechat vývojáře mimo něj.

Zde je příklad. Jen jsem používal Swift (Appleův nový jazyk) v naději, že to vlastně bude žít až před svým jménem a zkusil jsem to: var n = 1/2 nefungoval. Byl jsem jako to, co se tady děje a pak si bohužel uvědomil, že musím udělat var n: Float = 1/2. To mi připomnělo, jak moc nenávidím systémy typu a kolik zbytečného přitěžení jsou.

Já bych dokonce jít další kilometr říct, že nechci ani uživatelem definované typy (jako jsou třídy). Nechci typy vůbec. Chci jen var a objekty. Kde lze jakýkoli objekt použít jako jakýkoli objekt. A objekty se dynamicky mění a neustále se mění. Kde se stane problémem runtime, co funguje a co ne.

Vývojáři rádi říkají, jak volně psané jazyky nejsou dobré pro velké projekty. Ale řekl bych, že je to naopak. Silně napsané jazyky jsou hrozné pro velké projekty. A pokud říkáte, že javascript nefunguje pro velké projekty, zeptejte se společnosti Uber 40 miliardář + +, která provozuje veškerý svůj backend na node.js/javascript nebo Facebooku, který začal s PHP.

Pokud jde o staticky psané jazyky, není to dobré pro dnešní rychlé iterace. Zde je jednoduchý příklad, máte 10 vývojářů pracujících na projektu .net s kontinuálním integračním serverem, jeden vývojář odešle chybu a celá sestavení je přerušeno, přestože 10 vývojářů pracuje na různých věcech, nyní jsou všichni zastaveni a čekají pro urážlivého vývojáře, aby napravil svou chybu. Mluvte o efektivním co? Typ systémové/statické jazyky jsou vzájemně závislé a způsobí, že váš kód bude vzájemně závislý. Soubory skriptu však nikdy nejsou vzájemně závislé. Pokud se vyskytne problém s jedním ze skriptů, který nezastaví produkci, všechny problémy, které vidíte, zůstanou na běhovém modulu. A runtime se nikdy nezastaví. Nikdy se to nerozbije. Mohlo by to vést k nesprávnému výstupu, ale nejen to zastaví celý proces, jakým fungují systémy typu.

0
user19718