Poslední příspěvky

1

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od Jožka Niemand kdy Dnes v 17:24:36 »

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.

2

Sítě / Jak získat přípojku od Cetinu

« Poslední příspěvek od borekz kdy Dnes v 17:20:18 »

Jde se nějak domluvit přímo s Cetinem na placeném vytvoření přípojky tam kde podle webu Cetinu jde, ale podle koncových poskytovatelů nejde ?

3

Hardware / Re:Napájecí zdroj ke Gigabyte Brix

« Poslední příspěvek od xnd kdy Dnes v 17:07:16 »

Ja prevadzkujem svoj Gigabyte Brix miniPC (bezi non-stop ako NVR) na 12V zdroj. Original dodavany zdroj bol 19V plus minus. Pod 12V sa nezapne.
Treba davat pozor na pokles napatia pri nahlom zatazeni, niektore lacnejsie zdroje mozu mat vyssi pokles napatia (voltage drop) a to pri nizkych napatiach okolo 12V moze sposobit nestabilitu.

4

Hardware / Re:Rozdílné barvy na monitorech Dell a Mac

« Poslední příspěvek od Karmelos kdy Dnes v 16:59:43 »

Ale úvaha/závěr je? je správné mít monitor nastavený tak, aby?
1) zobrazil rozlišitelně všechny úrovně
2) aby to bylo přijemné na oči (snížit kontrast pomůže)
3) aby to odpovídalo realitě

Tak pokud neděláte do grafiky tak vám podání barev může být putna  a na příjemný na oči třeba zapnout noční režim.  Pokud vám za barvách záleží, pořiďte si kvalitní monitor a sondu. Všechno ostatní je kompromis, potřeba se s tim smířit a nemá smysl se tím zabývat.

5

Hardware / Re:Napájecí zdroj ke Gigabyte Brix

« Poslední příspěvek od 🇺🇦 GPU kdy Dnes v 16:10:19 »

Většina laptopových zdrojů je na 19/19.5/20V takže ono je to vcelku jedno. Takže bych použil nějaký originální značkový adaptér, co se třeba válí doma, než nějakou neznačkovou čínu. Správný konektor už máš na tom starém zdroji.

6

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od Jiří Havel kdy Dnes v 16:07:29 »

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ě.

7

Hardware / Re:Zkušenosti s monitory Dell U3325QE alebo BenQ RD320U

« Poslední příspěvek od ondrej _ kdy Dnes v 15:38:10 »

Ak vyuzijes vyssi jas, kontrast,vyssi refresh rate  a power delivery az 140W, tak Dell.
Ak toto nepotrebujes, tak by som rozmyslal nad Benq.

Tiez neviem ako Benq ale Dell U serie su tiez slusne skalibrovane Delta E pod 2.

8

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od Tomáš Crhonek kdy Dnes v 15:20:38 »

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.

9

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od Franta Kučera kdy Dnes v 15:11:11 »

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

10

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od Franta Kučera kdy Dnes v 14:59:46 »

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)