Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Tomáš Crhonek kdy Dnes v 17:43:26 »
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.
2
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Radek Miček kdy Dnes v 17:39:04 »
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?
3
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.
4
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 ?
5
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.
6
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.
7
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.
8
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ě.
9
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.
10
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.
Stran: [1] 2 3 ... 10