C# nebo Python?

[Logik]

Radek: Furt nechápu kam míříš. Jestli myslíš rozdíl mezi deklarovaným typem a typem hodnoty nebo co (což jsou sice dva pojmy, ale naprosto jasně odlišený a navíc je mezi nima vztah). Co kdybys to "hloupejch otázek" :-) prostě napsal?

--

Galgonek: Jo, Javu zrovna detailně neznam, tak sem si to našel, tam máš pravdu že null jako takové má typ null type + speciální pravidla pro konverzi. Tam to contextově závislé není. V C# tam nic takového není, takže když člověk napíše null, tak není jasné, jakého typu null myslíš, než ho někam přiřadíš.
..
Teď jsem si přečet co píe Radek a je možný, že někde na to "vybudujou formalismus", aby šlo nějak formálně zachytit a tak určit přesný typ každého výrazu, ale zrovna v tomdle je vidět, že C# nepíšou teoretici a místo vymejšlení blbin se prostě spokojili s tim, že tomu samo o sobě typ určit nejde (taky k čemu by to bylo??)

[Reklama]

[atarist]

fakt si nemyslite, ze debata je uplne mimo konktext povodnej otazky? Vsimnite si to, obcas..

Obavam se, ze puvodni otazka uz byla zodpovezena nekym mimo toto forum: "pouzivej VB" :-(
takze good luck a my ostatni muzeme pokracovat ve flame

[Radek Miček]

Furt nechápu kam míříš. Jestli myslíš rozdíl mezi deklarovaným typem a typem hodnoty nebo co (což jsou sice dva pojmy, ale naprosto jasně odlišený a navíc je mezi nima vztah). Co kdybys to "hloupejch otázek" :-) prostě napsal?

Ve většině typových systémů, které nejsou substrukturální, platí vlastnost zvaná zachování typu (type preservation nebo subject reduction), tudíž deklarovaný typ výrazu je stejný jako typ hodnoty.

Začneme s typy:

Například výraz "ahoj" v C# má typ string a všechny jeho nadtypy. Výraz "ahoj" as object má typ object. V Haskellu má výraz Nothing typy Maybe String, Maybe Int, Maybe (Maybe Int), Maybe z a nekonečně mnoho dalších. Podobně prázdný neměnný jednosměrný spojový seznam reprezentovaný hodnotou Nil má ve Scale nekonečně mnoho typů.

Dále existují tagy:

Některé jazyky - třeba C#, Java, Scala, Python - vybaví hodnoty za běhu tzv. tagy. Tagy mají různou přesnost a občas existuje souvislost s typem původního výrazu. Například u kolekce řetězců bude v C# tag List<string>, což možná přesně odpovídá typu výrazu, jehož vyhodnocením kolekce vznikla, a možná také neodpovídá - typ výrazu mohl být třeba object.

Funkcionální jazyky s algebraickými datovými typy používají tagy za běhu při pattern matchingu. Lze například deklarovat typ jednosměrný spojový seznam čísel data IntList = Nil | Cons Int IntList a tagem za běhu se pak rozlišuje, zda je seznam prázdný nebo ne.

Závěr

Z tohoto pohledu Python nemá typy, ale pouze tagy. A proč oboje nepojmenovávat stejným slovem? Protože to způsobuje zmatky - viz třeba Type Checking: typeof, GetType, or is?. Jak třeba budete formulovat výroky, že výraz měl typ object, vyhodnotil se na hodnotu typu object s tagem string.

A co když bude jazyk za běhu používat typy i tagy zároveň - jak to pak budete pojmenovávat?

už jen z anotace knihy: "A type system is a syntactic method" když mezi běžné termíny z oblasti teorie programovacích jazyků
patří např. dynamic type-checking, které se syntaxí nemá společného nic.

To je v pořádku - říká to, že se nejedná o sémantickou metodu. Jinak řečeno je to teorie důkazů a nikoliv teorie modelů.

[JS]

Z tohoto pohledu Python nemá typy, ale pouze tagy. A proč oboje nepojmenovávat stejným slovem? Protože to způsobuje zmatky - viz třeba Type Checking: typeof, GetType, or is?. Jak třeba budete formulovat výroky, že výraz měl typ object, vyhodnotil se na hodnotu typu object s tagem string.

Chapu, jak to myslis, ale prijde mi to trochu zbytecne to rozlisovat mimo matematiku (a i v matematice bych o tom pochyboval, prijde mi, ze pripadna teorie tagu neexistuje proto, ze je ekvivalentni teorii typu). Prijde mi, ze je to snaha dotahnout trochu umele rozdeleni (mezi typy a objekty), ktere vytvari teorie typu proto, aby vubec mohla existovat. Takze to vnimam jako dost uzky pohled na ten problem - skrz tyto teorie.

Co skutecne chceme podchytit v praxi typem, IMHO, je trida operaci, ktere muzeme nad danym objektem provadet. Problem je, ze tady existuje diskrepance mezi matematikou, kde neni mozne aplikovat funkci "mimo" definicni obor, a realnym svetem pocitacu, kdy to celkem dobre mozne je, a tak dostaneme nedefinovany vysledek. Abychom ale mohli tu druhou situaci matematicky modelovat (k cemuz slouzi teorie typu), musime nekde tu hranici postavit; ale bude vzdycky trochu umela, a nikde neni napsano, ze musi stat prave tam, kde se program kompiluje (nebo alternativne tam, kde jsou konstantni data a nekonstantni vstupy).

Ta hranice totiz neni ostra. Treba Haskell nema typ "cisla s kterymi lze delit". Ale fakticky to tak je, protoze pokud budes v programu delit nulou, dostanes undefined, coz je uplne stejne "undefined", jako dostanes, pokud program vubec nezkompilujes.

Takze, z toho vyplyva, ze otazka, kolik typu existuje a ktere, zavisi na tom, kde se stanovi ta hranice. Ale jelikoz ji muzeme posunout (v momente, kdy mapujeme realny svet na matematickou realitu), jsou ty clanky zcela zbytecnou argumentaci, byt formalne teoreticky spravnou.

fakt si nemyslite, ze debata je uplne mimo konktext povodnej otazky? Vsimnite si to, obcas..

Mozna je mimo kontext, ale ma stejny typ..

[Logik]

Začnu od konce:

To je v pořádku - říká to, že se nejedná o sémantickou metodu. Jinak řečeno je to teorie důkazů a nikoliv teorie modelů.

Pokud type-system je syntaktická metoda, tak by ji nějaká sémantika právě neměla zajímat. Takže to rozhodně v pořádku není.
Fór je v tom, že dynamic type- checking by mělo bejt v Tvym názvosloví vlasně (dynamic) tag-checking. A to je přesně to, co chci ukázat, že termín dynamic tag-checking se nepoužívá: když to hodíš do googlu, tak Ti vypadne sto odkazů (a jeden z prvních odkazuje zas pouze na Harpera) - zatímco na dynamic type-checking má asi půl milionu odkazů.

Jak třeba budete formulovat výroky, že výraz měl typ object, vyhodnotil se na hodnotu typu object s tagem string.

Typ výrazu je object a hodnota výsledku je typu String? (Mimochodem IMHO ses sám do toho zapletl, protože jestli zastáváš názor, že typ je čistě syntaktická záležitost, takže se nemá na něco vyhodnocovat, ne?)

Už snad chápu, o jaké dvojakosti mluvíš, ale ta ničemu nevadí, protože zde je striktně oddělená doména: v případě statického typování se pohybujem v oblasti výrazů, zatímco v dynamickém typování se pohybujem v oboru hodnot. Nedochází tedy k žádnému přetížení významů, pouze ten termín znamená něco trochu jiného v syntaxi a něco jiného v sémantice, které ale operují s jinou množinou popisovaných objektů. Pokud je to i tak třeba výslovně odlišit, pak k tomu jsou určeny slova statický a dynamický. Tak furt nerozumím, kde je potřeba měnit evidetně zavedenou terminilogii.

Co až budou programovací jazyky, které používají obojí? A copak nejsou? Ve spoustě scénářů člověk se staticky typovanym jazykem v určitejch scénářích kontroluje typ (podle Tebe tag) za běhu, protože mu z nějakého důvodu (ať už kvůli špatnému návrhu programu, nebo třeba v důsledku absence generik viz starší java) statická kontrola nestačí. Zvládnout tuto distinkci patří k základním dovednostem programátora. Jak jsem pochopil, ta skupina používající slovo tag pochází spíše z oblasti formální logiky a dedukce. Pro klasifikaci jazyků pro účely vybrání vhodného pro praxi je, i kdybych Tvoji terminologie byla standardní v oblasti dedukce, normální užít terminologii z oblasti programování.

Navíc, když stejný termín v oblasti syntaxe a sémantiky má svůj smysl, protože ukazuje na velmi přímý vztah mezi těmito dvěma pojmy:
1) v každém rozumném programu platí, že výraz typu A je vyhodnocen na hodnotu typu A či potomek A
2) velmi často při čtení programu Ti stačí informace, že daný objekt je typu (tagu) A, což může vyplývat jak ze syntaxe, tak u "např. pythonu" sémantiky. A to, že ve skutečnosti tam je objekt tagu potomek A je šumák.

A navíc sám jsi ještě navíc demonstroval to, že i termín tag je přetíženej, protože pokud chceš slovem tag označovat dynamický typ, pak jím nemůžeš postihnout např. (ne)prázdnost seznam při pattern matchingu, jaks psal. Anebo musíš rozvolnit vztah tagu a typu, čímž opět Ti vyvstane potřeba pro termín "tagu zachycujícího typ" a jsme zpátky.

[Reklama]

[Radek Miček]

Pokud type-system je syntaktická metoda, tak by ji nějaká sémantika právě neměla zajímat.

Tak to je. Zadefinujete co jsou typy, co jsou výrazy a následně pravidla pro typový systém, která výrazům přiřazují typy.

Pak samozřejmě chcete ukázat nějaký vztah typového systému vůči sémantice jazyka - třeba korektnost. Typový systém je deduktivní systém, ale na rozdíl od důkazových systémů není tolik kladen důraz na bezespornost.

Fór je v tom, že dynamic type- checking by mělo bejt v Tvym názvosloví vlasně (dynamic) tag-checking. A to je přesně to, co chci ukázat, že termín dynamic tag-checking se nepoužívá: když to hodíš do googlu, tak Ti vypadne sto odkazů (a jeden z prvních odkazuje zas pouze na Harpera) - zatímco na dynamic type-checking má asi půl milionu odkazů.

Ano, bohužel, taková je situace. Opravil jsem vás proto, aby se to do budoucna zlepšilo.

Lidé, co se zabývají teorií typů, se IMO příliš nezajímají o tzv. dynamicky typované jazyky, neboť to je z hlediska teorie typů trivialita (žádné typy / jeden typ). Proto se termín tag-checking nevyskytuje příliš často. Viz komiks.

Typ výrazu je object a hodnota výsledku je typu String? (Mimochodem IMHO ses sám do toho zapletl, protože jestli zastáváš názor, že typ je čistě syntaktická záležitost, takže se nemá na něco vyhodnocovat, ne?)

Ano, pojmy jako hodnota a vyhodnocení jsou už věcí sémantiky. To však nebrání tomu, aby se mezi typy a relací vyhodnocení vybudoval vztah. To je přeci stejné jako v logice, kde dokazuji úplnost a korektnost. A následně, když pak něco dokáži, tak říkám, že je to pravdivé.

A mj. psal jsem, že hodnota je rovněž typu object - právě proto, že většinou platí zachování typů. Naopak tag může být něco jiného.

v případě statického typování se pohybujem v oblasti výrazů, zatímco v dynamickém typování se pohybujem v oboru hodnot.

Hodnoty jsou speciálním případem výrazů, takže ne. Při definici sémantiky se určí, jaké výrazy budou hodnoty.

Anebo musíš rozvolnit vztah tagu a typu, čímž opět Ti vyvstane potřeba pro termín "tagu zachycujícího typ" a jsme zpátky.

Já na žádném vztahu netrvám viz moje věta: "Tagy mají různou přesnost a občas existuje souvislost s typem původního výrazu".

Co až budou programovací jazyky, které používají obojí? A copak nejsou?

Psal jsem obojí za běhu. Žádný známý mě nenapadá - typy většinou použije kompilátor/JIT (třeba pro vyřešení overloadingu), a pak se už nepoužívají. Viz příklad "ahoj" as object, jenž má typ object, tj. nemůžete ho dát funkci, která chce string. Nicméně za běhu se už k typu nedostanete - kompilátor nikam neuloží, že zde odvodil typ object, k dispozici však máte tag string.

Jazyk, který mám na mysli, by sémantiku definoval např. pomocí typových derivací (tj. odvození typů, která vzniknou při typové kontrole). To se občas dělá u jazyků s průnikovými typy.

[maze]

Proč myslíte, že je Python nahraní? Tím to nechci obhajovat, zajímá mě názor proč v současnosti nejpoužívanější skriptovací jazyk je pouze na "hraní"?

Protože je tzv. dynamicky typovaný - přesněji jeho typový systém má pouze jeden typ.

1. To ze typy staticky nekontroluje neznamena ze tam nejsou.

2. Staticky typovani ma smysl tam kde potrebujes maximalni vykon, protoze tim pomuzes optimalizatoru. Ocekavat od toho cokoli jinyho je hloupost, pripadne sebemrskacstvi...

[maze]

Jestli vám jde o pochopení OPRAVDOVÉHO objektového modelování a programování, tak Smalltalk, který je minimalistický a přitom mocný, nekompromisně objektový a bez balastu. V praxi se moc nepoužívá, ale na pochopení asi nic lepšího nenajdete. Pak můžete klidně to C# a uvidíte, co je to za nakynutý bastl a co všechno to neumí. (Python neznám, tak o něm mluvit nebudu, ale co si pamatuju, tak mi přišel jako takový splácaný eintopf).

No nevim jestli bych jazyk bez multiple-dispatch nazval "opravdovy oop". Spis bych doporucil se podivat na CLOS (common lisp object system)

[overboss]

2. Staticky typovani ma smysl tam kde potrebujes maximalni vykon, protoze tim pomuzes optimalizatoru. Ocekavat od toho cokoli jinyho je hloupost, pripadne sebemrskacstvi...

Otazka je naco potom vznikaju silne staticky typovane jazyky s pokrocilou type inference, ked sa da pouzit rovno dynamicky jazyk? C# ma aj dynamicke typovanie a late binding ale malokedy sa tato moznost vyuziva. Preco?

[Radek Miček]

2. Staticky typovani ma smysl tam kde potrebujes maximalni vykon, protoze tim pomuzes optimalizatoru. Ocekavat od toho cokoli jinyho je hloupost, pripadne sebemrskacstvi...

Bohatý typový systém má rovněž smysl, když chcete dokázat určité vlastnosti programu (viz třeba CompCert) nebo když chcete prostě jen něco dokázat (ani to nemusí mít nic společného s programem).

[Logik]

Radek:

No z tvojí odpovědi mi v podstatě vyplývá todle: Existovali lidi co pragramujou, ty z potřeby nedostatečnosti statickýho typování vyvinuli dynamicky typovaný jazyky. No, jenže to nesedělo některejm lidem vyvíjejícím své typové teorie a tak se ty jazyky do tý teorie snažili nacpat. Ale ono jim to nešlo.

A tak co udělali? Místo aby typovou teorii nějak rozšířili či pozměnili tak, aby pokrývala i dynamicky typované jazyky, vymysleli jinou abstrakci - tagy - a dynamicky typované jazyky se do ní snažej nacpat. A snažej se lidi co používaj dynamický jazyky přesvědčit, ať jejich novou teorii používaj.
Protože ale vymysleli teorii něčeho jinýho, neboť (dynamický) typ narozdíl od tagu JE SVÁZANEJ se statickým typem a tato vlastnost JE CHTĚNÁ a UŽITEČNÁ a hlavně je to KLÍČOVÁ vlastnost dynamickýho typu, a protože vlastně evidentně vůbec nepochopili praktičnost dynamických jazyků, (např. že platit časem běhu za rychlý vývoj je rozumné - viz Harper), tak kupodivu svoji terminologii do širší praxe neprosadili. A tak si zhrzení aspoň z majority dělaj srandu komixama. Budiž jim to přáno... :-)

Jinak:
"Typový systém je deduktivní systém." - Nikoli. Typový systém v oboru dekdukce je deduktivní systém. Co to je v programovacích jazycích nevím, protože to není natolik složité, abych se o to hlouběji zajímal, ale je to popsáno ve specifikaci každého jazyka. Deduktivní typový systém (alespoň takový jak jsi nastínil) ale evidentně nepopisuje typové systémy programovacích jazyků dobře (když neumí popsat správně co je to dynamický typ a jeho vztah k statickému typu) a protože pro praxi nepřináší zatím nic natolik užitečného, aby ospravedlnil tuto redefinici, není zatím důvod proč se užitečných vlastností programovacího typového systému zbavovat ve prospěch deduktivního.

Jazyk, který by používal dynamický i statický typy za běhu? A prosím proč?? Když je k dispozici dynamickej typ, tak statickej typ není potřeba. A pokud by byl jazyk, kterej by kromě (libovolnýho) typu navíc podporoval tagy (tj. anotaci bez vazby na typ). Klidně ať takovej je, pak tam tomu budu tagy klidně říkat - protože to bude něco jinýho než dynamickej typ.

 Navíc Vaše teorie vede přesně k tomu, (jak už psal Maze) - že co se nevejde do Vaší teorie, tak není. Je to perfektně vidět např. na Cythonu (což je defakto dialekt Pythonu), kde najednou ty neexistující pythonovské typy jdou explicitně napsat a syntakticky kontrolovat. Ano, přesně ty typy, které v tom pythonovském  zdrojáku podle Vás nejsou ;-). Z toho je vidět, že ta deduktivní teorie (díky tomu, jak je odstřižená od sémantiky) nezachycuje vhodně ani to, co je statický typ. Či že spíše vede k tvorbě modelů, které to nezachycují dobře.
 

[mikrom]

Zvrhlo sa to tu na OT takze k povodnej otazke.
 

Se C# jsem došel jen k objektovému programování, ale tam jsem celkem tvrdě narazil. A o Pythonu se říká, že je to jazyk vhodný pro začátečníky, tak mě napadlo, že bych se tím mohl zlepšit.

Ještě dodám, že hodlám C# v budoucnosti používat, teď jde jen o to, zda s tím "začít" už teď nebo až po Pythonu.

Ked ti ide primarne o C# bola by blbost zacinat kvoli tomu s Pythonom (alebo inym jazykom). Hlavne ak sa jedna o OOP tak v oboch jazykoch je to dost rozdielne, napr. Python zrejme (este som to nepouzil) podporuje viacnasobnu dedicnost a preto nema nieco take ako nterface (aspon ja som to este nevidel). V C# (zrejme ako v Jave) je mozne dedit iba z jednej triedy a preto sa tam (takisto ako v Jave) interface asi hodne pouziva. Doporucujem, ak nieco s C# nechapes najdi si k tomu tutorial, alebo sa spytaj na diskusnom fore, ale miesat do toho dalsi jazyk ti asi nepomoze.

Na druhej strane Python sa ti moze vyborne hodit na beznu pracu, ked potrebujes nieco rychlo urobit. Podla mojho nazoru sa v nom vyvija rychlejsie ako v C#. Ale moj nazor ber s rezervou, pretoze ja som C# musel pouzit len raz a myslim si ze je to okopirovana Java kde namiesto main() treba pisat Main() 

[Radek Miček]

a protože vlastně evidentně vůbec nepochopili praktičnost dynamických jazyků, (např. že platit časem běhu za rychlý vývoj je rozumné - viz Harper)

IMO jazyky s bohatšími typovými systémy a dobrou typovou inferencí mi právě umožňují rychlý vývoj a usnadňují úpravy již napsaných programů - viz Haskell, F#, OCaml (, Scala). V tzv. dynamicky typovaných jazycích je problém i obyčejné přejmenování. Navíc se slabým nebo žádným typovým systémem jste omezen pouze na primitivní abstrakce, protože složitější abstrakce je těžké napsat bez dopomoci správně.

pro praxi nepřináší zatím nic natolik užitečného, aby ospravedlnil tuto redefinici, není zatím důvod proč se užitečných vlastností programovacího typového systému zbavovat ve prospěch deduktivního

Můžete garantovat určité vlastnosti programu a programovacího jazyka (třeba onu korektnost), což je užitečné. Používá se to při návrhu programovacích jazyků (podívejte se třeba na programovací jazyk Mezzo nebo Ur/Web).

BTW jak při návrhu programovacího jazyka poznáte, že typový systém je správně?

Jazyk, který by používal dynamický i statický typy za běhu? A prosím proč??

Jak jsem psal, můžete pomocí nich definovat sémantiku. Konkrétně třeba viz Elaborating Intersection and Union Types. Stručně řečeno v jazyce povolí smíchat 2 termy do jednoho. Tento jeden term se pak může vyhodnotit na libovolný z oněch dvou termů. To, jak se bude vyhodnocovat může být určeno typovou derivací.

[andy]

Logiku, umíš dobře Haskell? Já jen, že jsem měl podobný názor do té doby, než mě napadlo z dlouhé chvíle v tom napsat dvě ne úplně malé aplikace. Od té doby navzdory tomu, že programuju v pythonu a coffeescriptu, musím říct, že mi haskellový typový systém v těchhle jazycích strašně moc chybí - a to z toho důvodu, že by mi velmi urychlila vývoj. Ono to totiž odchytá neuvěřitelně velké množství chyb, navíc to docela podporuje code reuse a je to velmi přehledné.
Nicméně čistě z praktického pohledu, pokud dneska člověk píše třeba webové aplikace, pak de-fakto každý vstup, ale především každý SQL dotaz je vlastní typ - a bohužel s tím je prakticky trochu problém, protože když pak má člověk 100 typů kvůli 50 funkcím, s SQL dotazem, tak je to docela otrava. Nicméně věřím, že i na tom se pomalu pracuje

[Logik]

Radek: Možná že pro Tebe silně typové jazyky vhodnější jsou. Ale obecně praxe ukazuje, že jazyky s bohatým typovým systémem - a obzvlášt ty, které jsi vyjmenoval - jsou na vývoj drahé. Jestli je to způsobeno jejich "ukecaností", tím, že je je těžké zvládnout, kvalitě knihoven (což zas ale mluví o praktičnosti navrhovatelů jazyka) nebo prostě postavení hvězd se můžeme dohadovat. Ale přijde mi poněkud (rozuměj dost hodně :-)) namyšlené tvrdit, že ty zástupy programátorů co používá "netypové" jazyky jsou blbci, protože zbytečně programují v křápech, když tady existuje úžasný jazyk, který vyřeší všechny jejich potřeby a budou v něm psát pětkrát rychlejc. Asi to bude trochu jinak.

..pro praxi.... Ano, když budu potřebovat garantovat korektnost jazyka, tak sáhnu po teorii, která mi to umožní verifikovat. Já netvrdím, že Ta deduktivní teorie je nanic. Tvrdím, že se hodí k něčemu, ale k něčemu zas ne a tak není důvod ji cpát tam, kam se nehodí. Tzn. klidně udělám jazyk s programovacím typovým systémem, pak vezmu jí nejbližší deduktivní teorii a jí to ověřím a popř. návrh jazyka upravím... nebo můžu i postupovat opačně, vyjít z deduktivní teorie: ukazuje se ale, že PJ vzniklé "z praxe" jsou v praxi úspěšnější a tedy se dá s velkou jistotou říci, že užitečnější, než ty, které vzejdou z teorie...

...můžeme definovat sémantiku ... intersection and unions... A je to potřeba? Používá to nějaký jazyk, který je masivněji používán v praxi? Proč nahrazovat definici, která nám umožňuje zachycovat a klasifikovat to, co zachytit a klasifikovat potřebujeme, definicí, která nám nezachycuje to, co potřebujeme,  ale zato umožní věc, kterou nepotřebujeme?

V pythonu máme typy. V C máme typy. Ty typy se něčím liší a něco mají společné. Úkol teoretika není přijít s teorií, která řekne: v Pythonu typy nejsou. Úkol teoretika je přijít a vymyslet teorii, která nejenže vystihne rozdíly, mezi těmi typy (to se té teorii povedlo dokonale :-)), ale také vystihne to, co mají tyto typy společného. Až přijdete s touto teorií, určitě ji bez problémů prosadíte...


Andy: Haskell umím natolik, že sem měl kdysi z jednosemestrový přednášky jedničku ;-) a od tý doby jsem ho asi neviděl. Takže moc ne :-) Ale jinak souhlasím, typový systém je dobrá věc a čím silnější, tím lepší - taky programuji spíš v "netypových" jazycích a dělám chyby, které by mě silně typový systém odchytil, jen co bych je napsal. Jenže - přesně jak píšeš - se za to něco platí. Někdy je to cena malá (pro velké aplikace se spíše hodí typově silné jazyky), někdy je ta cena příliš velká. A ta dělící čára nejde jen malé/velké aplikace. Ona jde i naskrz programovacíma metodikama: na agilní vývoj se hodí spíše "netypové" jazyky, zatímco silně typové jazyky se hodí spíš na tradiční vývojový cyklus atd... A i každému sedí něco jiného: někdo je roztržitý a tak ocení typovou kontrolu hodně, někdo je schopen psát "z první" a pak je s míň ukecaným jazykem (to jde většinou ruku v ruce) rychlejší.