Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
A jak souvisí Java/C# s OOP?Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní
Statické typování je pro OOP irelevantní.
Co se dovzdelat a zkusit se doucit trebas tu Scalu/F# nebo alespon Javu/C#?
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní
Statické typování je pro OOP irelevantní.
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
co je "rozhodování o typu"?součtové typy => dynamické typování?rozhodování o typu za běhu => dynamické typování
To znamená, není předem jasně dáno, že na vstupu je osmibajtový int a nic jiného. Jakmile připustím nějaký "noise", už dynamicky rozhoduji, jaký typ dat na tom vstupu je. Když chci přečíst 512 bajtů (sektor) z disku jako zařízení (ne přes FS), tak staticky říkám, že chci načíst přesně 512 bajtů a v bufferu očekávám 512 platných bajtů. Z FS může přijít i kratší záznam s uvedenou délkou, ale to už je dynamický typ.
Kite, Kite. Ty kdyby si tomu aspoň rozuměl, co?Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...To je triviální, prostě rozhraním.
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.Kód: [Vybrat]type RatioNum = RatioNum Num
| RatioNumFract Num Num
deriving show
sin :: RatioNum -> RatioNum
sin RatioNum num = ...
sin RatioNumFract num denom = ...
print $ sin (RatioNum 5)
print $ sin (RatioNumFract 5 2)
Bavíme se o objektových jazycích. Patří mezi ně i Haskell?
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.
Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...
Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne.
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Kód: [Vybrat]#!/usr/bin/env python
# -*- coding: utf-8 -*-
def vypis(kolekce):
print(type(kolekce))
for i in kolekce:
print(i)
print()
seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print(). Když nebudou splněny obě tyto podmínky, funkce havaruje. Pravděpodobně vyhodí nějakou výjimku, kterou buď očekávám a musím na ni nějak zareagovat, nebo výjimka shodí celý program. Kdybych se chtěl výjimce vyhnout, musel bych v kódu nějak ošetřit chování funkce pro všechny typy, které nejsou "iterable<printable>". Ovšem ze zadání může plynout, že nemá smysl volat vypis() na takové typy. Ve staticky typovaném jazyce bych jednoduše přidal parametru kolekce typ iterable<printable> a mohl bych se spolehnout, že případné chyby odhalí kompilátor při překladu. V dynamicky typovaném jazyce můžu tento požadavek tak akorát napsat do dokumentace a případně doufat, že na každé použití této funkce někdo napíše test, že se v tom kokrétním místě vždy volá se správným typem.
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.Jasne. Existuji situace, kdy je to jedno (a v nich ti nic nebrani pouzit neco jak Iterable). A (drz se!) jsou situace, kdy to jedno neni. Pokud je chces resit jako prase... tak je res jako prase.
Správně jsi poznal, že seznam i množina jsou Iterable, což je přesně to, o co mi šlo. Ukázal jsem příklad, kde je výhodné použití polymorfismu. Velmi dobře vím, že jsou situace, kdy to jedno není, ale o tom ten příklad není. Místo striktně defenzivního přístupu použiji takový, který je v daném případě výhodnější. Uvedeným postupem docílím mnohem volnějších závislostí mezi objekty, což je silně žádoucí. Mohu je tak poměrně jednoduše zaměňovat. Jestli je to styl na prase, tak programuji jako prase - ale objektově.
V Javě bych v deklaraci formálního parametru použil Iterable<Object>. Takže vlastně stejně, jen o pár zbytečných znaků navíc.
Pokud by byl problém s množinou, mohu ji klidně přetypovat na seznam při volání procedury nebo až uvnitř.Kód: [Vybrat]vypis(list(seznam))
vypis(list(mnozina))
# nebo uvnitř vypis()
seznam = list(kolekce)
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print(). Když nebudou splněny obě tyto podmínky, funkce havaruje. Pravděpodobně vyhodí nějakou výjimku, kterou buď očekávám a musím na ni nějak zareagovat, nebo výjimka shodí celý program. Kdybych se chtěl výjimce vyhnout, musel bych v kódu nějak ošetřit chování funkce pro všechny typy, které nejsou "iterable<printable>". Ovšem ze zadání může plynout, že nemá smysl volat vypis() na takové typy. Ve staticky typovaném jazyce bych jednoduše přidal parametru kolekce typ iterable<printable> a mohl bych se spolehnout, že případné chyby odhalí kompilátor při překladu. V dynamicky typovaném jazyce můžu tento požadavek tak akorát napsat do dokumentace a případně doufat, že na každé použití této funkce někdo napíše test, že se v tom kokrétním místě vždy volá se správným typem.
Jistě, uvedený příklad nemá ošetřen vstup, protože pro demonstrační účely je nepotřebuje. V reálu jsou před výkonnou částí procedury nejen typové kontroly, ale i další validace s případným vyhozením výjimky. Záleží na specifikaci požadavku, zda a v jaké míře je taková validace účelná. Pokud se připouští, že na vstupu bude třeba int nebo string, procedura s tím musí počítat. U staticky typovaných jazyků by přibyly další dvě přetížené metody. Pak do té metody někdo bude chtít strčit float...
Statické typy nepřipouští, že bych tu proceduru mohl chtít volat s hodnotou jiného typu, než jaký je uveden ve formálním parametru. Považuji to za chybu. V dynamicky typovaném jazyce mohu předat i hodnotu, která není iterable a procedura si s tím poradí. Je to její starost.
Pokud ti není jasný rozdíl mezi sémantikou listu a setu, tak je asi problém na tvém přijímači.Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
(Btw zrovna tady máš ještě o problém navíc, protože se rozlišuje první autor, korespondující autor...)Kód: [Vybrat]#!/usr/bin/env python
# -*- coding: utf-8 -*-
def vypis(kolekce):
print(type(kolekce))
for i in kolekce:
print(i)
print()
seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.
Nepoznate nahodou klavesnicu, ktorej by sa dalo podsvietenie vypnut/zapnut bud hardverovo alebo softverovo? Nezaujimaju ma klavesnice v notebookoch.
To bych nerekl. Zabyvam se tim pragmaticky. I kdyby haskell nebyl tak tezkopadny, jako v praxi pouzivane staticke jazyky, tak je to bezvyznamna zajimavost, protoze v praxi je to nepouzitelny jazyk. Zajimaji me a posuzuji vlastnosti praktickych jazyku.Aha. Takže houby víš, ale názor se ti už udělal.Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?4. genericke programovaniJako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.