Přechod z Javy na Rust. Ano či ne?

[Franta Kučera]

Kód: [Vybrat]

vaha.zvazit(osoba)
osoba.zvazitSe(vaha)
Oboji je spatne. Melo by to byt akce::zvazit(osoba, vaha) - a je to. Osoba nemusi znat nic o vaze, a vaha muze umet vazit treba i zvirata nebo mouku.

Cele OOP je do jiste miry divne, nuti nas vazat akce na konkretni objekty, ktere by klidne mohly byt naprosto nezavisle.

Jenže pak zjistíš, že těch postupů nebo metod vážení je víc, není to jen jedna univerzální akce zvážit(). Takže můžeš mít např. rozhraní PostupVážení s metodou zvážit(Osoba, Váha) a několik alternativních implementací tohoto rozhraní. Ta PostupVážení může mít ještě nějakou parametrizaci (její součástí může být i ta Váha – a pak voláš jen zvážit(Object)).

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde. Statická metoda, která vrací hodnotu je funkce. Statická metoda, která má jen (vstupní/výstupní) parametry, je procedura. A např. návrhový vzor továrna je funkce, obvykle používaná jako funkce vyššího řádu. Typicky ji někam předáváš jako parametr nebo ti ji někdo vrací jako návratovou hodnotu. A oproti jiným paradigmatům umožňuje OOP spojit více funkcí/metod, které k sobě logicky patří, plus související data, do jednoho objektu.

(samozřejmě to má svoje úskalí, viz ten můj odkazovaný článek, a není dobré se do toho vrhat bezhlavě, trochu krotit prvotní nadšení a držet kreativitu na uzdě, ale to platí všude)

[Reklama]

[Franta Kučera]

Tohle ale záleží na konkrétním programu. Kevlin Henney (https://en.wikipedia.org/wiki/Kevlin_Henney) doporučuje každý program dělat maximálně konkrétní, tedy pro tiskárnu je normální mít datové typy jako ink, paper, book apod. Je nevhodné vytvářet abstraktní metody, které umí vážit slona, když potřebuju jen znát hmotnost inkoustu. Tiskárna ví, kolik ho potřebuje a datový objekt typu ink může mít metodu GetVolume(). Nebo ještě lépe, mít kontejner pro inkousty a o každém ví, kolik jaké barvy tam je.

Jak kde. Postupem času jsem došel k tomu, že 1) implementaci, která je skrytá uvnitř, je většinou dobré dělat co nejjednodušší, nedělat overengineering, nevyrábět tam za každou cenu X objetků nebo abstraktních rozhraní, když stačí pár obyčejných metod, pár bloků kódu. Protože tyhle implementační detaily můžeš kdykoli přepsat a udělat je složitější nebo „pořádně objektově“. Ale u 2) veřejného rozhraní bys měl ten návrh udělat robustní už na začátku a myslet (v nějakém rozumném horizontu) i na budoucí vývoj a obecnost, univerzálnost. Protože veřejné API bys měl měnit co nejméně a hlavně zpětně kompatibilně (pokud nechceš naštvat všechny kolem sebe).

Více jsem to rozepsal v Rozlišování veřejného API a interních rozhraní.

[Tomáš Crhonek]

Jak kde. Postupem času jsem došel k tomu, že 1) implementaci, která je skrytá uvnitř, je většinou dobré dělat co nejjednodušší, nedělat overengineering, nevyrábět tam za každou cenu X objetků nebo abstraktních rozhraní, když stačí pár obyčejných metod, pár bloků kódu. Protože tyhle implementační detaily můžeš kdykoli přepsat a udělat je složitější nebo „pořádně objektově“. Ale u 2) veřejného rozhraní bys měl ten návrh udělat robustní už na začátku a myslet (v nějakém rozumném horizontu) i na budoucí vývoj a obecnost, univerzálnost. Protože veřejné API bys měl měnit co nejméně a hlavně zpětně kompatibilně (pokud nechceš naštvat všechny kolem sebe).

Více jsem to rozepsal v Rozlišování veřejného API a interních rozhraní.

Jo, v tomto se shodujeme. Já jsem reagoval na tu univerzální váhu akce::zvazit(osoba, vaha) - tohle je kravina, proč by metoda zvážit měla dostat ještě další obecnou metodu váha? (A prosím, programujme pouze anglicky.)

To, že se veřejné API nemění se nemusíme ani bavit, ale tady je přece diskuse o implementaci. Všechny jazyky mají něco jako interface, golang má bohaté datové typy z možností si jich udělat kolik potřebuju, k tomu definovat metody rozhraní a potom si to každý může naimplementovat jak potřebuje. Stačí dodržet signaturu rozhraní a typy (ty jsou definované v předávaných parametrech rozhraní). Možná mám moc rád golang, ale tohle je přesně to, proč mám rád i PostgreSQL a jeho bohatství datových typů a jejich omezení (referenční integrita, constraints apod.). Prostě teplota v Kelvinech je vždy větší než nula apod.

[Jiří Havel]

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde...

Tohle ale platí pro úplně všechny výpočetně úplné jazyky. Rozdíl je jen v tom, jak je ta jiná syntaxe ukecaná, (ne)pohodlná nebo náchylná k chybám a podobně.

[Jožka Niemand]

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde.

Nejflexibilnější jsou jazyky s otevřenou minimalistickou syntaxí, v nichž si mohu dotvořit, co potřebuji - jako LISP, FORTH, TCL... Ani jeden z nich nebyl vytvořen jako objektový, v žádném z nich ale není problém objektový systém dotvořit, když bez něj někdo nemůže žít (což se i stalo; obzvláště CLOS je podle mě nejméně o level lepší objektový systém, než jaký nabízí C++, C# nebo Java). Ale jazyky tohoto typu IMHO objektové nadstavby nepotřebují, protože samy o sobě umožňují vytváření tak silných výrazových prostředků, jaké si jen autor programu přeje a potřebuje k řešení svého problému, takže proč se omezovat na objekty.

[Reklama]

[Radek Miček]

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde.

Nejflexibilnější jsou jazyky s otevřenou minimalistickou syntaxí, v nichž si mohu dotvořit, co potřebuji - jako LISP, FORTH, TCL... Ani jeden z nich nebyl vytvořen jako objektový, v žádném z nich ale není problém objektový systém dotvořit, když bez něj někdo nemůže žít (což se i stalo; obzvláště CLOS je podle mě nejméně o level lepší objektový systém, než jaký nabízí C++, C# nebo Java). Ale jazyky tohoto typu IMHO objektové nadstavby nepotřebují, protože samy o sobě umožňují vytváření tak silných výrazových prostředků, jaké si jen autor programu přeje a potřebuje k řešení svého problému, takže proč se omezovat na objekty.

Mám pocit, že pro jazyky s multimetodami nikdy nevznikla efektivní implementace. Nebo ano?

[Tomáš Crhonek]

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde.

Nejflexibilnější jsou jazyky s otevřenou minimalistickou syntaxí, v nichž si mohu dotvořit, co potřebuji - jako LISP, FORTH, TCL... Ani jeden z nich nebyl vytvořen jako objektový, v žádném z nich ale není problém objektový systém dotvořit, když bez něj někdo nemůže žít (což se i stalo; obzvláště CLOS je podle mě nejméně o level lepší objektový systém, než jaký nabízí C++, C# nebo Java). Ale jazyky tohoto typu IMHO objektové nadstavby nepotřebují, protože samy o sobě umožňují vytváření tak silných výrazových prostředků, jaké si jen autor programu přeje a potřebuje k řešení svého problému, takže proč se omezovat na objekty.

Mám pocit, že pro jazyky s multimetodami nikdy nevznikla efektivní implementace. Nebo ano?

Nevím přesně co tím myslíš. Psal o tom pan Tišnovský v roce 2016 a jazyku Clojure. Podle popisu to vypadá na podobnou věc, jako je v golangu tzv. func receiver. Tedy možnost si připsat metodu do objektu syntaxí

(object)Method(args)

Takto se do object dostane další metoda v rámci aktuální package. Každý package si může definovat jinou vlastní metodu pro sdílený objekt.

[Radek Miček]

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde.

Nejflexibilnější jsou jazyky s otevřenou minimalistickou syntaxí, v nichž si mohu dotvořit, co potřebuji - jako LISP, FORTH, TCL... Ani jeden z nich nebyl vytvořen jako objektový, v žádném z nich ale není problém objektový systém dotvořit, když bez něj někdo nemůže žít (což se i stalo; obzvláště CLOS je podle mě nejméně o level lepší objektový systém, než jaký nabízí C++, C# nebo Java). Ale jazyky tohoto typu IMHO objektové nadstavby nepotřebují, protože samy o sobě umožňují vytváření tak silných výrazových prostředků, jaké si jen autor programu přeje a potřebuje k řešení svého problému, takže proč se omezovat na objekty.

Mám pocit, že pro jazyky s multimetodami nikdy nevznikla efektivní implementace. Nebo ano?

Nevím přesně co tím myslíš. Psal o tom pan Tišnovský v roce 2016 a jazyku Clojure. Podle popisu to vypadá na podobnou věc, jako je v golangu tzv. func receiver. Tedy možnost si připsat metodu do objektu syntaxí

(object)Method(args)

Takto se do object dostane další metoda v rámci aktuální package. Každý package si může definovat jinou vlastní metodu pro sdílený objekt.

Měl jsem na mysli rychlostí. Že volání multimetod v CLOS není (myslím si) tak rychlé jako v C++ (kde je dispatch jen podle jednoho argumentu).

[anonacct]

Já jen použil příklad co tu byl, kdybych měl vytvořit vlastní tak by zněl takto:

```
struct Point {
  double x, y;
};
```

Chci vůbec mít member funkce? Já třeba preferuju `distance(p1, p2)` než `p1.distance(p2)`. To samé když vidím třeba `a.dot(b)`, atd... přijde mi to až přehnané API navrhovat takto.

[BoneFlute]

Já jen použil příklad co tu byl, kdybych měl vytvořit vlastní tak by zněl takto:

```
struct Point {
  double x, y;
};
```

Chci vůbec mít member funkce? Já třeba preferuju `distance(p1, p2)` než `p1.distance(p2)`. To samé když vidím třeba `a.dot(b)`, atd... přijde mi to až přehnané API navrhovat takto.

Objekt je o tom, že schovává vnitřní stav a nějakou svou logiku. Distance mezi dvěma body není stav ani logika toho bodu, IMHO.

Ještě lépe to vynikne, ale to už tu někdo zmiňoval, když začneš řešit více variant distance. Například s tolerancí. A pak to musíš nějak přidat do toho objektu.

[BoneFlute]

Já jen použil příklad co tu byl, kdybych měl vytvořit vlastní tak by zněl takto:

```
struct Point {
  double x, y;
};
```

Chci vůbec mít member funkce? Já třeba preferuju `distance(p1, p2)` než `p1.distance(p2)`. To samé když vidím třeba `a.dot(b)`, atd... přijde mi to až přehnané API navrhovat takto.

A naopak. Mám-li nějaký systém, který se například stará o persistenci objektů, tak mohu chtít, aby ten objekt byl persistovatelnej. Dám tomu nějaký

Kód: [Vybrat]

interface Persistable {
    fn serialize() -> dict
    fn unserialize(dict) -> self
}
a zde je to skutečně starostí toho objektu.

(sorry, lepší příklad mě nenapadl)

Nebudu ho učit serializovat se do Jsonu, nebo do Databáze, ale obecný serializování musí umět on.

[Radek Miček]

Nebudu ho učit serializovat se do Jsonu, nebo do Databáze, ale obecný serializování musí umět on.

Ale i obecných serializačních formátů existuje mnoho. Jeden například povolí 64-bitová celá čísla a druhý povolí celá čísla bez omezení velikosti. Jiný povolí čas na mikrosekundy, další na pikosekundy. Některé mohou řešit, jak jsou data uložena v paměti, jiné se od toho snaží abstrahovat.

[Jiří Havel]

Nebudu ho učit serializovat se do Jsonu, nebo do Databáze, ale obecný serializování musí umět on.

Ale i obecných serializačních formátů existuje mnoho. Jeden například povolí 64-bitová celá čísla a druhý povolí celá čísla bez omezení velikosti. Jiný povolí čas na mikrosekundy, další na pikosekundy. Některé mohou řešit, jak jsou data uložena v paměti, jiné se od toho snaží abstrahovat.

Tak tenhle přístup má samozřejmě nějaké předpoklady. Objekt vysype obecný slovník obsahující nějaké základní typy a pak to chce zpátky v původní podobě beze změn. Prakticky to znamená, že ten dict bude podporovat akorát tak osekané doubly a obecné stringy.
Ve chvíli, kdy je třeba řešit nějaké ztrátové ukládání, tak to takhle obecně nejde. A je otázka, jestli se tomu ještě dá říkat serializace.

[novomente]

Diskuse se nám krásně rozběhla. Ani jsem ji celou nestačil sledovat. Ale mám dotaz.

Když vývojář dostane zadání, musí ho napřed analyzovat a vybrat pro něj vhodný jazyk, ve kterém ho je nejlépe zakódovat. Každý programovací jazyk má svá specifika (výhody i nevýhody), která se musí při oné volbě brát v úvahu. Přitom v jednom jazyku lze programovat různými způsoby, skoro bych řekl, že co vývojář to jiný způsob programování. Jistě, každý jazyk má svá pravidla a doporučení (nikoliv zákony), která lze buď dodržovat, anebo porušovat, když je porušení lepší řešení.

Uvažuji zatím správně?

Sám jsem nedávno dělal (jen tak pro sebe) jednu počítačovou hru pro Commodore 64 (to je takový starý 8-bitový stroj). Programoval jsem v assebleru (mimochodem poprvé v životě). Dělal jsem se s tím celý rok. Celkem jsem to musel čtyřikrát přepisovat prakticky od nuly, neboť jsem narazil na okamžik, kdy už jsem se v kódu sám nevyznal. Četl jsem, že dobrou věcí v programování je určit si nějaký svůj "styl" a toho se pak držet. Ty první tři pokusy nepracovali tak dobře (dlouhý kód, chyby, různý přístup). Napočtvrté jsem měl už dost zkušeností s assemblerem a problematikou kódování hry, že jsem se již mohl rozhodnout pro jeden způsob, který jsem pak dodržoval až do finále. Tato zkušenost mi o programování řekla docela hodně, neboť v assembleru se dá programovat opravdu hodně způsoby.

Když jsem psal nějakou rutinu, napsal jsem několik verzí, než jsem se rozhodl pro tu nejvhodnější. Někdy jsem jí ale musel přepracovat, neboť s jiným kódem nepracovala dost dobře. Musel jsem opravdu hodně a vynalézavě přemýšlet. Neříkám, že jsem to napsal jako nějaký špičkový přeborník. Závěrečné vydání (release) mělo jednu logickou chybu, kterou jsem nemohl najít. Ale ta chyba se náramně hodila k té hře, a dávala jí takový zvláštní a zajímavý průběh. Tak jsem se rozhodl ji tam záměrně nechat, jinak totiž program šlapal dobře.

Závěrem tedy dotaz...

Co vývojář, to originální osobnost. Co zadání + vývojář, to originální výsledek zpracování toho zadání. Nikdy jsem nepracoval ve vývojářském týmu. A dotaz zní: Máte také podobnou zkušenost s originalitou každého vývojáře? Mohu veřejně říci, že zpracování zadání (vývoj, programování atd.) je velice osobní záležitost?

[Jiří Havel]

Zásadní (ne)výhoda každého jazyka je jestli ho umím, resp. jestli na něho seženu dost lidí.

Takže třeba ta nejzásadnější výhoda Javascriptu při použití na backendu je ta, že už je použitý na frontendu.

A v týmu je záhodné originalitu krotit. Sice každý programátor píše trochu jinak, ale v mezích toho aby se v tom vyznali i ostatní. Větší týmy mají obvykle více či méně detailní konvence od kterých se upouští jen v opravdu výjimečných případech.