Příspěvky

1561

Vývoj / Re:Funkcionální programování a mainstream

« kdy: 22. 07. 2017, 19:36:09 »

IMHO:

Protože OOP nefunguje tak, jak evangelisti slibovali = nepomáhá tolik, jak mělo, je extrémně náročné do toho proniknout, vyžaduje to velkou míru disciplíny, ...

Zatímco FP vypadá, že by mohlo fungovat líp = dá se v něm snadněji psát čitelný kód, hůře se v něm prasí, většinou to sklouzává na to, že to buď napíšeš relativně čitelně, nebo to nenapíšeš vůbec, větší míra znovupoužitelnosti oproti OOP, plus to má další více či méně teoretické výhody.

A nejdůležitější důvod vůbec: je po tom poptávka.

1562

Software / Re:ShepherD (dmd) versus SystemD

« kdy: 17. 07. 2017, 23:10:52 »

A protože tohle vlákno si přímo říká o flame, bylo by pěkné, kdybyste se ty nenáviděné kousky software naučili psát správně. Je to systemd, nikde žádné velké písmeno, leda by to slovo stálo na začátku věty.

Beru na vědomí.

1563

Software / ShepherD (dmd) versus SystemD

« kdy: 17. 07. 2017, 13:03:53 »

Zdravím.

Mohl by mi někdo znalej pomoct udělat si obrázek, o těchto dvou řešeních?

O SystemD něco málo vím. Je kolem toho větší humbuk, je masivně nasazován. Takže se tomu nedá moc vyhnout.

ShepherD, co je mi známo, nasazen na GuixSD, je kompatabilkní s SysV initem... Prakticky jen to, co jsem si nastudoval z jejich stránek.

Věnoval se tomu někdo víc? Může mi říct, co je na ShepherD zajímavé; i třeba v porovnání k SystemD.

Díky.

1564

Vývoj / Re:Výpočetní složitost v deklarativním programování

« kdy: 28. 06. 2017, 15:51:34 »

Ano, ta optimalizace samozrejme sama nenastane, nekdo to musi implementovat.

Tak teoreticky stačí vytvořit fitness fci, a naimplementuje se sama (jedinej případ, kdy evoluce cca funguje). A samozřejmě na takovou funkci je třeba právě dobře definovaný stavový prostor. A ten se deklarativně definuje lépe, než imperativně.

1565

Vývoj / Re:OOP a servisní třídy

« kdy: 27. 06. 2017, 21:53:56 »

Pri servise nejde o bezstavovost - zakladnym charakterom servisu je vytiahnutie concernu (v zmysle odizolovat starost) do nejakej ciastkovej, samostatne uchopitelnej, pochopitelnej a manazovatelnej (zlyhatelnej) jednotky, co samo sebou nejaky ten stav implikuje. Viete, ako ked si firma najme upratovaci servis alebo si spustite nginx na serveri. Ak je nieco bezstavove a nezlyhatelne, tak by som to nazval funkcia a nech je trebars aj v tom vasom namespace.

Celkem pěkná definice.

1566

Vývoj / Re:OOP a servisní třídy

« kdy: 25. 06. 2017, 12:58:41 »

A to jsme se ještě nedostali k flame, jak si někteří lide poradí s rozlišování co je otázka OOP a co je otázka Typování.

OOP bych nechal, to není přesně definované (čímž se možná právě hodí na flame). Těm pár konceptům jako typování, polymorfismus, dědičnost apod. se dá věnovat zvlášť, jsou navzájem ortogonální.

Dá. Ale málokomu je to jasné. Mnoho programátorů chápe OOP jako dědičnost + třídy + interface. Tři věci z toho nejsou součástí OOP.

1567

Vývoj / Re:OOP a servisní třídy

« kdy: 25. 06. 2017, 00:34:49 »

Co se týče OOP, tak bych to moc neprožíval. Žádné mainstreamové OOP jazyky OOP nejsou. [...] a na Kaye si nikdo nevzpomene.

Tři lidi se shodnou na tom, co je OOP, jen když dva z nich jsou mrtví (ne že bych teď nabádal k vraždám). Jenže z pragmatického pohledu jediná důležitá věc je polymorfismus, jehož lze dosáhnout prostými protokoly (rozhraními), zbytek tzv. "OOP" je víceméně k ničemu. Pak jsou ještě technikality jako nějaký automatický způsob správy paměti nebo rozumná podpora paralelismu, ale to už jsme někde jinde. Jakmile se přidají i jen blbá generika, tak už se klouže k FP s tím, že to bude jen polovičatá zkriplená implementace.
P.S. Chudák Kay musí dost trpět, když vidí, kdo dnes píše programy a v čem.

A to jsme se ještě nedostali k flame, jak si někteří lide poradí s rozlišování co je otázka OOP a co je otázka Typování.

1568

Vývoj / Re:OOP a servisní třídy

« kdy: 24. 06. 2017, 21:42:51 »

Myslím takové ty NěcoService. Jako je třeba servisní vrstva plná podobných tříd. Možná jsem to jen špatně pochopila.

Servisní třídy (nebo tedy pokud jsem tě dobře pochopil tak Servisy) používám a používám je rád. Dost to zpřehledňuje kód, protože určitá logika je na jednom omezeném a kontrolovatelném místě. Dobře se definuje, co to má dělat. Pohodlně se to testuje. A při inteligentním návrhu se to dá i dobře komponovat. Snadno se s nimi pracuje ve smyslu snadné nahraditelnosti, změnitelnosti, protože zbytečně nerozšiřuje rozhraní aplikace.

Co se týče OOP, tak bych to moc neprožíval. Žádné mainstreamové OOP jazyky OOP nejsou. A co se týče definice OOP, tak si pod tím každý představuje ledacos.

Takže jako odpověď na tvou otázku: V praxi Servisy ano. V teorii (zkouška ve škole) OOP je bordel, a každej jazyk si to dělá po svém. Co člověk, to názor a na Kaye si nikdo nevzpomene.

1569

Vývoj / Re:Proč pořád používáme TTY, konzole a terminál?

« kdy: 23. 06. 2017, 03:44:52 »

Nejblíž tomu, o čem se tady mluví, je asi Rio z Plan 9*. Taky (bohužel) slepá větev, která se neujala. Později se Plan 9 přerodil v Inferno a opět umřel. Nikdy se to neuchytilo, ...

LinuxSTEP byl na GNUStepu postavený, ale chybělo mu to POSIXové pozadí a celý ten "klasický" userland. Prostě jen jádro, libc a framework. Mělo to i jakýsi balíkovací systém napsaný v ObjectiveC. Samo to taky zdechlo.
Jeho primární autor vymyslel i jakousi cmdline 2.0 a tomu taky nikdo nechtěl věnovat čas.

Možná by stálo za to vytáhnout nějakou teorii proč se to neujalo.

1570

Vývoj / Re:Přepsání serveru v Javě

« kdy: 22. 06. 2017, 02:11:57 »

A co třeba tohle?

Kód: [Vybrat]

val foo = (cond) ? new Foo() : new Bar();
foo.method();

Jak v takovém případě zafunguje inference? Bude hledat společná rozhraní obou tříd?

A co bys tak rekl? Jaky typ ma tenhle vyraz (cond) ? new Foo() : new Bar();? Nehledej slozitost, kde neni. Nebo se to alespon douc.

Tak já bych řekl, že buď vezme největší společný rozhraní, nebo spíš chcípne, protože je to otevřené. (Ale čerpám na základě zkušeností z Haskellu, Java tu interferenci nemá.)

Typicky se bere prostě supremum, pokud typový systém tvoří úplný svaz. Nebo to je prostě chyba, když se výsledný typ neuvede explicitně, záleží na jazyku. Haskell je v tomto trochu specifický, když má de facto jen rozhraní.

Stačilo říct: "jo" :-)

Nestačilo, protože to chtělo opravit a upřesnit.

Tak to udělej. Vždyť jsi řekl tu samou větu co já, jen jsi použil cizí termity :-D

1571

Vývoj / Re:Přepsání serveru v Javě

« kdy: 21. 06. 2017, 23:47:24 »

A co třeba tohle?

Kód: [Vybrat]

val foo = (cond) ? new Foo() : new Bar();
foo.method();

Jak v takovém případě zafunguje inference? Bude hledat společná rozhraní obou tříd?

A co bys tak rekl? Jaky typ ma tenhle vyraz (cond) ? new Foo() : new Bar();? Nehledej slozitost, kde neni. Nebo se to alespon douc.

Tak já bych řekl, že buď vezme největší společný rozhraní, nebo spíš chcípne, protože je to otevřené. (Ale čerpám na základě zkušeností z Haskellu, Java tu interferenci nemá.)

Typicky se bere prostě supremum, pokud typový systém tvoří úplný svaz. Nebo to je prostě chyba, když se výsledný typ neuvede explicitně, záleží na jazyku. Haskell je v tomto trochu specifický, když má de facto jen rozhraní.

Stačilo říct: "jo" :-)

1572

Vývoj / Re:Proč pořád používáme TTY, konzole a terminál?

« kdy: 21. 06. 2017, 20:01:47 »

Tak něco z toho předveď a jenom o tom nemluv. Když to bude fungovat a dávat smysl, pak to/tě možná ostatní vezmou vážně. Zatím to spíš vypadá, že si jenom rád povídáš.

Tak třeba já jsem něco takového zkoušel. Samozřejmě to nijak nedopadlo, páč čas, ale hrál jsem si hezky a dlouho. Měl jsem, nebo možná ještě mám podobnou vizi.

Možná jste na něj zbytečně agresivní, nezdá se vám? To, že to chce probrat na fóru, tak od čeho to fórum je, kruci, než aby si povídal?

1573

Vývoj / Re:Přepsání serveru v Javě

« kdy: 21. 06. 2017, 19:56:31 »

A co třeba tohle?

Kód: [Vybrat]

val foo = (cond) ? new Foo() : new Bar();
foo.method();

Jak v takovém případě zafunguje inference? Bude hledat společná rozhraní obou tříd?

A co bys tak rekl? Jaky typ ma tenhle vyraz (cond) ? new Foo() : new Bar();? Nehledej slozitost, kde neni. Nebo se to alespon douc.

Tak já bych řekl, že buď vezme největší společný rozhraní, nebo spíš chcípne, protože je to otevřené. (Ale čerpám na základě zkušeností z Haskellu, Java tu interferenci nemá.)

Ale když by se to napsalo takhle:

Kód: [Vybrat]

void foo(Bool cond) {
  val foo = (cond) ? new Foo() : new Bar();
  foo.method();
}

Tak má všechny potřebné informace co potřebuje, a mohlo by to projít. (Když by to uměla.)

1574

Vývoj / Re:Přepsání serveru v Javě

« kdy: 21. 06. 2017, 19:43:50 »

[V pohodě. Inference je v PHP běžná, jen jsem nevěděl, že se dostala už i do Javy.

Type inference v PHP? O tom bych rád slyšel detaily...

Já si zase počkám, zda bude Kit taky takovej frajer jako Nekola, a uzná chybu.

1575

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 13. 06. 2017, 00:48:45 »

decode "9007199254741091" -> error "příliš velké číslo" -- páč rozsah je IMHO definicí určen

Ne, ani ten rozsah není specifikací určen. Takže si opět můžeš zvolit čistě libovolně. Třeba 3

tak specifikace předepisuje notaci, ale neomezuje rozsah, neřekl bych, že to je špatně

Tak já tam vidím něco o devíti cifrách. http://www.json.org. (Ale nějak zvláštně jsem to nezkoumal.)

Eh, sorry, špatně jsem to pochopil, ty cifry.