Příspěvky

496

Vývoj / Re:C# nebo Python?

« kdy: 26. 01. 2014, 13:38:14 »

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ší.

497

Vývoj / Re:C# nebo Python?

« kdy: 26. 01. 2014, 11:12:50 »

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.
 

498

Vývoj / Re:C# nebo Python?

« kdy: 25. 01. 2014, 22:53:10 »

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.

499

Vývoj / Re:C# nebo Python?

« kdy: 25. 01. 2014, 19:20:15 »

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??)

500

Vývoj / Re:C# nebo Python?

« kdy: 25. 01. 2014, 17:59:57 »

Jaký je problém v tom, že pro určení typů některých výrazů je třeba znát kontext?

501

Vývoj / Re:C# nebo Python?

« kdy: 25. 01. 2014, 16:53:17 »

Jedna kniha s prominutím nedělá odbornou veřejnost. A ta kniha si prostě evidetně dělá vlastní definice, které jsou v rozporu s obecnou terminologií: 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.

Kde dělám nějaké dva významy slova typ fakt nechápu.

A kde je problém s Listem nechápu také. Buďto mám list, do kterého mohu nacpat cokoli, nebo List, do kterého chci nacpat pouze řetězce. Ty mají dva různé typy a C# to od verze 2.0 umí svým typovým systémem zachytit. Pokud se budem bavit o verzi 1.0, kde generika nebyla, pak to je prostě nedokonalost typového systému C# a nikoli nedokonalostí pojmu typ.
Právě to, že i když List<Int> vypadá stejně jako List<String>, tak stejný typ nemají, je to, čím se typové jazyky liší od duck-typing languages.

502

Vývoj / Re:C# nebo Python?

« kdy: 25. 01. 2014, 15:08:57 »

Ano, můžete používat slovo "typ" pro pojem, pro který ho používal Russell. Pokud ale odborná veřejnost v oboru informatika toto slovo už používá pro pojem jiný, pak je dobrým zvykem se přizpůsobit. Jinak totiž diskuse nemá smysl, protože jeden o koze a druhý o voze. Pokud už se přizpůsobit nechcete, tak je dobré diskusi uvést tím, že vlastně mluvíte o něčem jiném než ostatní. Ale pak je zas otázka, proč o tom vůbec mluvíte, že? :-)
(Když si vyjasníme mapování slovo - pojem, tak defakto na příspěvek Python má vlastnost A jste odpověděl: nikoli, Python nemá vlastnost B).

PS: Mimochodem dosti pochybuji, že pojem typ vymyslel Russel. Nejsem odborník na Russela, ale dovolil bych si tvrdit, že filosofové už mnohem dříve operovali s tímto pojmem, byť třeba pro jeho označení použili slovo jiné (např. čím se to liší od Platónových ideí?), Russell tento pojem pouze uvedl do vztahu s formální logikou a označil ho jiným slovem.

503

Vývoj / Re:C# nebo Python?

« kdy: 25. 01. 2014, 14:24:42 »

...
Za běhu Python nerozlišuje typy, ale tagy.
....

Směšuješ informaci s implementací. To, že má nějaký objekt uloženou informaci o svém typu pomocí tagů je sice hezké, ale nic to nemění na tom, zdali ten objekt má nebo nemá typ a zdali ten typ je nebo není odlišný od typu jiného objektu.
V této oblasti je terminologie poměrně dost dobře ustálená a dá se říci:

Python je typový jazyk, neboť objekty si s sebou nesou informaci o svém typu a můžeš se na jejich typ zeptat (např. fce isinstance, __class__ vlastnost objektu atd...).
To, že python nevyžaduje deklaraci typu proměné (někdy se mluví o slabé typovosti) a že nemá type-checking (ani statický, ani dynamický) na věci nic nemění.

Beztypový jazyk je např. lisp (all is list), asi by se za něj dal považovat i javascript (pokud se budeme bavit o objektech a pomyneme to, že kromě nich tam existuje pár primitivních typů jako číslo atd...)

PS: Ad ten blog (Dynamic languages are static languages) - tak autor toho blogu nerespektuje vžitou terminologii (co je typ, třída atd...) a to, že se ohání Widgensteinem na tom nic nemění. Vymyslel si vlastní definici pojmu typ a pak dokazuje, jak jsou dynamicky typované jazyky omezené, protože v té jeho definici mají pouze jeden typ.
To pak prohlašuje jako nevýhodu, přitom tam má pouze dva argumenty, proč tomu tak je. Z toho jeden z nich je špatně (i v dynamicky typovaném jazyku lze zajistit invariant, že do dané metody vstoupí jen argument daného typu, jen je zpravidla (ale ne nutně!) kontrola vykonávána v runtime, což má své nevýhody ale i výhody, např. v preciznější kontrole) a jeden z nich je napůl nepravda a napůl půpravda (že dynamic typing stojí více procesorového času: zaprve, s JIT kompilerem to nemusí platit, zadruhé, static typing zas zabere víc času při překladu a čas programátora je dnes dost často dražší než čas počítače....)

504

Vývoj / Re:C# nebo Python?

« kdy: 25. 01. 2014, 13:31:02 »

Prave nutnost pisat zatvorky pri bezparametrickej funkcii je specialita jazyka C (a jazykov z neho vychadzajucich). Ostatne jazykove rodiny (Pascal, Modula, ML, Lisp, Basic, Ruby, ADA, Eiffel) nic take nevyzaduju. Vo funkcionalnych jazykoch zvykne byt ()  specialny typ.

- Závorky u funkce bez argumentů je naprosto logická věc, která umožňuje distinkci mezi funkcí a voláním té funkce.

- Existuje spousta jazyků, co to vyžaduje a není pascal - like, např. Python, Fortran, Go...

- Lisp závorky pro evaluaci funkce bez argumentů vyžaduje (jen u něj je operátor zavolej funkci jiný, nikoli závorky za názvem funkce, ale kolem funkce (jsem si vědom částečného významového rozdílu)).

- Na jedné straně mluvíš o rodině C like jazyků, kde házíš vše do jednoho pytle (i když např. takové C a Javascript jsou naprosto odlišné jazyky), a na druhé straně děláš výčet s Pascalem, Modulou a ADou, přitom druzí dva jsou přímí potomci pascalu.

- Co se týče např. Basicu, tak sám microsoft v dokumentaci tvrdí, že se sice závorky mohou "omitnout", ale že to nedoporučuje dělat kvůli čitelnosti...

- V Ruby zas díky tomu, když chci udělat operátor map, tak místo čistého pole.map(f) musím vytvářet lambda funkci pole.map(|e| f(e)) - vopičárna

- Většina z Tebou uvedených jazyků se v praxi moc nepoužívá.

Když to shrnu - tak ano, existují jazyky, které umožňují závorky nepsat, ale není pravda, že je to jen jedna rodina jazyků, je to naopak většina dnes v praxi používaných jazyků a asi i rodin jazyků, je to většina jazyků vzniklých v poslední době -  za good habit se to považuje i v imperativních jazycích které to striktně nepožadují a ty jazyky, které to nepožadují, za to platí nutností speciální konstrukce pro zápis "funkcionálních" operací.

505

Vývoj / Re:Jazyk podobný C#

« kdy: 18. 01. 2014, 23:00:28 »

Že se s tim Bla ještě máte náladu bavit....

nicméně, Bla, proč teda např. Sun i IBM vyhazují za realtime javu peníze, když je to taková blbina?
http://en.wikipedia.org/wiki/Real_time_Java

A taky si nastuduj např.
https://www.google.cz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CFoQFjAE&url=https%3A%2F%2Fwww.cs.tcd.ie%2FDavid.Gregg%2Fpapers%2Ftoplas05.pdf&ei=H_naUrn1BZK1hAfbzoHICg&usg=AFQjCNEAJEBOIHwvi-zhjE23edLWHJ9U_A&sig2=dH2ZDVJYkyo9lgp8TM8E_g&bvm=bv.59568121,d.ZG4&cad=rja

506

Vývoj / Re:Šifrovací algoritmus pro hesla

« kdy: 13. 11. 2013, 13:33:56 »

Tak nevím, jestli jsi to pochopil dobře. Např. rozhodně nemá smysl hašovat sůl zvlášť, myslím, že směšuješ sůl (sloužící k rozrůznění v db uložených haší stejných hesel a prevenci slovníkového útoku) a výzvu (sloužící k tomu, aby nešlo odchytit pomocí MIM heslo a později znovu použít).

1) Princip VÝZVY je ten, že klient zahašuje heslo s něčím, co mu pošle server (to něco může být pokaždé jiné).
Server provede stejnou hash a porovná.

2) Pokud není záhodno, aby server znal heslo uživatele, tak může server znát pouze hash uživatele. Pak je postup stejný, akorát klient před algoritmem 1) heslo zahašuje. Pak server potřebuje znát pouze hash toho hesla.

3) Pokud není záhodno, aby šla hesla na serveru prolomit pomocí slovníku, je třeba hesla hašovat se solí. Tuto sůl buď klient zná (pak je postup stejný jako v 2, akorát se při hašování přidá sůl), nebo nezná (např. proto, že je pro každého uživatele jiná, což je bezpečnější). V tom případě musí klient o sůl požádat server. Komunikace je tedy takováto

K: Ahoj, tady uzivatel UZIVATEL, chci se prihlásit
S: Ok, sůl uzivatele UZIVATEL je SUL, náhodná vyzva je VYZVA
K: Ok, autentizuji se pomoci hash(VYZVA+hash(SUL+HESLO))
S: Zkontroluje hash(VYZVA + HASHOVANE_OSOLENE_HESLO)

To, že komunikace probíhá v jedné session, tzn. server musí vědět, že přihlašovanému poslal tu a tu výzvu a on se chce přihlásit jako ten a ten uživatel je doufám jasné.

All clear?

PS: ?ožnost, jak zjednodušit solení a zachovat unikátní sůl je nastavit sůl jako USERNAME+nějakáblbostprovšechnystejná.

507

Odkladiště / Re:oksystem

« kdy: 11. 07. 2013, 11:26:26 »

Na školení od nich jsem nebyl, ale znám dost lidí, co v té firmě pracuje a kdybych hledal zaměstnání, tak by to byla jedna z firem, která by byla v hledáčku...

508

Hardware / Re:Podpora 8 jader ve hrách

« kdy: 21. 04. 2013, 00:23:53 »

Prolez si nějaký testy a kup nejlevnějšího 4x4 (:-)) intela. FX je sice v některejch úlohách rychlejší - např. na kompilace či tuším encoding videa je to dobrej procesor - a zároveň je levnější, ale dosti her není pořádně paralelizovaná, a tam má výkon na jedno jádro tragickej.
http://extrahardware.cnews.cz/recenze/core-i5-3350p-nejlevnejsi-ctyrjadro-intelu-zn-neplatite-grafiku/strana/0/10

Nevím, kde si vzal ty čísla s výkonem na jedno jádro, ale IMHO jsou poněkud mimo, tendle poměr výkonů platí, dokud CPU nepotřebuje SSE nebo FPU výpočty, nebo (tuším že je to tím) víc přístupů do L2 cache, pak výkonnost FX prudce klesá (protože má sdílený jednotky) - je teda vzatej jen z testů, který jsou pro AMD procík příznivý.

509

Vývoj / Re:Extrakce z archivu (statické knihovny)

« kdy: 15. 04. 2013, 12:56:31 »

Jenže on je problém, že ten soubor utils.o je dvakrát v JEDNÉ knihovně. Takže já ten první vůbec neumím vyextrahovat, protože na příkaz
ar x libmetis.a utils.o
(nebo jak to je přesně, píšu z hlavy) se vždy vyextrahuje pouze ten druhý utils.o

Šahat do makefilů, kde se dělat ty původní soubory můžu, ale vzhledem k tomu, že to jsou third party knihovny a já stavim něco nad tim, tak to nechci. Už proto, že ty cizí knihovny pravděpodobně nemůžu distribuovat atd....

Zatím, co jsem vymyslel, je udělat z těch dvou statickejch knihoven sdílenou knihovnu, ale to taky není ideální řešení...

510

Vývoj / Re:Extrakce z archivu (statické knihovny)

« kdy: 13. 04. 2013, 15:58:57 »

Nikdo nic? :-) To sem to napsal tak nepochopitelně, nebo je to fakt neřešitelný?