Příspěvky

1186

Studium a uplatnění / Re:Trénink SQL

« kdy: 16. 01. 2016, 23:03:52 »

http://sqlzoo.net/wiki/SQL_Tutorial (jakmile zvladnete z hlavy ty pokrocile priklady uvedene dole, tak si muzete bez ostychu zacit rikat SQL guru; ja osobne jsem nejeden z nich nedal a musel jsem se nechat inspirovat jejich resenim ).

Off topic: Na tech pokrocilych prikladech je krasne videt, ze SQL standard je velice nepodareny (a implementace od implementace se vyrazne lisi, takze jiz i pro stredne komplexni programy nelze psat ciste SQL a musi se "ifdefit") a samotne SQL je dost spatne navrzeny koncept (ma hrozne moc der a ani zdaleka nesplnuje dnesni pozadavky). Ani plne relacni databaze (napr. http://shark.armchair.mb.ca/~erwin/) nejsou vselek (v cem vsem je SQL slabe/nepouzitelne a jako to pripadne resit vcetne diskuze o plne relacnich jazycich lze nalezt v diskuzich pod ruzne zanorenymi odkazy na http://c2.com/cgi/wiki?StructuredQueryLanguage), a tak osobne sazim na Datalog-based databaze (napr. http://docs.datomic.com/query.html nebo FLOSS in-memory varianta https://github.com/tonsky/datascript), ktere resi snad vsechny stavajici technicke problemy databazi a zadne nove problemy mi nejsou zname.

Datalog je mnohem snazší na pochopení, ale SQL je na některé úlohy lepší.

1187

Odkladiště / Re:Programátorův pohled na svět

« kdy: 16. 01. 2016, 22:58:04 »

Aerable je stejným nesmyslem jako IArea.

jak je to teda správně?

HasArea

To je blbě, to není příčestí.

1188

Odkladiště / Re:mysleni pana Programatora

« kdy: 15. 01. 2016, 21:45:08 »

Každému, kdo programuje, doporučuju knížky Peregrina.

Jo. Taky jsem ho tady už několikrát doporučoval. Asi nejzajímavější a širšímu okruhu nejsrozumitelnější český filosof jakého jsem zatím potkal.

Jako člověka ho neznám, takže nemůžu soudit.

Až bych řekl, že jediný srozumitelný.

1189

Odkladiště / Re:Programátorův pohled na svět

« kdy: 15. 01. 2016, 21:04:53 »

Aerable je stejným nesmyslem jako IArea.

Areable jsi tehdy použil ty...

No a?

Ukázals zásadní neznalost angličtiny a diskvalifikoval ses pro další diskuzi. Jinak nic.

1190

Odkladiště / Re:Programátorův pohled na svět

« kdy: 15. 01. 2016, 17:14:19 »

Aerable je stejným nesmyslem jako IArea.
...
tak to rozhraní pojmenuji Printable

Logicky z toho vyplývá že Printable je stejným nesmyslem jako IPrint.

Nikde není v požadavcích napsáno, co má ten obdélník umět. Tak jsem si vymyslel metodu print(), protože mě v tu chvíli nic lepšího nenapadlo. Pokud nepotřebuje umět nic, není ani nutné žádné rozhraní - to je občas také užitečné, pokud si vystačíš se standardními metodami, které umí každý objekt.

píše se tam o objektu, který "má plochu", např. obdélník, takže jaký je správný název metody a rozhraní?

Správně je computed property area a v jazyce, který to neumožňuje, metoda area() v rozhraní HavingArea (případně WithArea, což je PP)

1191

Odkladiště / Re:Programátorův pohled na svět

« kdy: 15. 01. 2016, 17:11:03 »

Aerable je stejným nesmyslem jako IArea.

jak je to teda správně?

Příčestí - HavingArea

1192

Odkladiště / Re:Programátorův pohled na svět

« kdy: 15. 01. 2016, 17:09:57 »

Obvykle stačí jedno slovo, slepence nebývají potřebné. Název proměnné - podstatné jméno, název metody - sloveso, název rozhraní - přídavné jméno. Dodržování těchto pravidel krásně zpřehlední aplikaci, čte se to jak pohádka.

Ty krásně přehledné jednoslovné názvy bych chtěl vidět. Možná se to čte jako pohádka, akorát ji pochopí jenom autor, prvních pár dnů... Ale co, zaplaceno se dostane a po nás přece potopa...

Ono jde spíše o konvenci, například jen debil pojmenuje immutable metodu slovesem.

Pokud dodržuješ pravidlo Tell, don't ask, tak ti moc prostoru pro immutable metody nezbývá. Ale i tak: Máš snad něco proti názvům metod seek(), find() nebo search(), které používám u kolekcí?

Se správným používáním konvencí také souvisí alespoň elementární znalost angličtiny, aby se nestalo, že si někdo někde přečte, že jména rozhraní mají být adjektiva, a rozhraní pro vše, co má plochu (obdélník apod.), nazve Areable, čili verbální příponu dá na substantivum (jak jsme si zde na fóru mohli nedávno přečíst, takový dement by neměl dělat ani v PHP).

FUD.

Aerable je stejným nesmyslem jako IArea. Základem pro tvorbu názvů rozhraní nemá být substantivum, ale verbum. Stačí se podívat na to, co rozhraní obsahuje: Seznam hlaviček metod - tedy schopností, které má daný objekt splňovat. Z toho se dá odvodit název rozhraní. Pokud je tam třeba metoda print(), tak to rozhraní pojmenuji Printable a implementuji ho ve třídě Rectangle apod.

Areable jsi tehdy použil ty...

1193

Vývoj / Re:Generická matice

« kdy: 15. 01. 2016, 00:24:42 »

Jde ve staticky typovaném jazyce implementovat matice s generickými prvky? Pokud ano, jak?
Např. v C++ bych mohl mít Matrix<double> nebo Matrix<Vector>, ale mně jde o to, aby v jedné matici mohly být prvky různých typů při zachování statické kontroly. Příkladem budiž třeba výpočet vektorového součinu pomocí determinantu (matice obsahuje vektory i skaláry a výsledkem je vektor).

Let's take any language, say, Swift (pun intended)

Kód: [Vybrat]

protocol MatrixElementType {
    func +(x:MatrixElementType, y:MatrixElementType) -> MatrixElementType
    func *(x:MatrixElementType, y:MatrixElementType) -> MatrixElementType
}

extension Double : MatrixElementType {}

struct Vector : MatrixElementType {
    let data:[Double]
    var dimension:Int { return data.count }
}

struct Matrix {
    let data:[MatrixElementType]
    let dimension:Int
    init(data:[MatrixElementType]) { self.data = data; dimension = Math.sqrt(data.count) }
    subscript(index:(row:Int,column:Int)) -> MatrixElementType {
        get { return data[index.row * dimension + index.column] }
    }
    func firstMinor(row row:Int, column:Int) -> MatrixElementType {
        ...
    }
    var determinant:MatrixElementType {
        if dimension == 1 { return data[0] }
        else {
            ...
        }
    }
}

let m = Matrix(data: [ Vector(data: [ 1, 0, 0 ]), Vector(data: [ 0, 1, 0 ]), Vector(data: [ 0, 0, 1 ]), 2, 0, 0, 0, 2, 0 ])
print(m)
print(m.determinant)

Po přepsání tento kód funguje v každém jazyce s šablonami a přetěžováním operátorů, jen vypadá hnusněji. To zadání by bylo hezký příklad ke zkoušce

1194

Odkladiště / Re:Programátorův pohled na svět

« kdy: 14. 01. 2016, 23:23:24 »

Obvykle stačí jedno slovo, slepence nebývají potřebné. Název proměnné - podstatné jméno, název metody - sloveso, název rozhraní - přídavné jméno. Dodržování těchto pravidel krásně zpřehlední aplikaci, čte se to jak pohádka.

Ty krásně přehledné jednoslovné názvy bych chtěl vidět. Možná se to čte jako pohádka, akorát ji pochopí jenom autor, prvních pár dnů... Ale co, zaplaceno se dostane a po nás přece potopa...

Ono jde spíše o konvenci, například jen debil pojmenuje immutable metodu slovesem. Se správným používáním konvencí také souvisí alespoň elementární znalost angličtiny, aby se nestalo, že si někdo někde přečte, že jména rozhraní mají být adjektiva, a rozhraní pro vše, co má plochu (obdélník apod.), nazve Areable, čili verbální příponu dá na substantivum (jak jsme si zde na fóru mohli nedávno přečíst, takový dement by neměl dělat ani v PHP).

1195

Odkladiště / Re:Programátorův pohled na svět

« kdy: 14. 01. 2016, 23:14:41 »

slo by nejak (asi na zaklade analogie s necim z bezneho zivota co kazdy zna ?) priblizit cloveku, co nikdy neprogramoval ani nebude, cim a jak se lisi "pohled na svet"tech opravdu nejlepsich programatoru od bezneho smrtelnika jako ja ? nejde mi ani tak o vysvetlovani jednotlivych paradigmat, natoz syntaxe, spis o nejake "kulhajici"zobecneni neprenosnych ? zkusenosti za roky co se venujete programovani ? asi to nejde co ? ja vim ze nikdy umet programovat nebudu tak bych chtel jen zazit ten pohled na svet Vasima ocima ...

Dobrý programátor myslí abstraktně (matematicky). Není náhoda, že nejlepší vědci, již přispěli (akademicky) ke "computer science", se rekrutovali z oborů jako matematika (příkladů je přehršel), fyzika (Feynman), ale i (analytická) filozofie (Robinson).

1196

Odkladiště / Re:mysleni pana Programatora

« kdy: 14. 01. 2016, 22:53:43 »

filozof a programator jsou docela protihlehle pristupy,

Nejsou. Vyšší levely programování se např. skrze logiku a vytváření modelů parádně potkávají nejenom s moderní analytickou filosofií, ale třeba i s některými partiemi dávné filosofie. Dobře zhuštěné seznámení s Aristotelem by pro žádného programátora nebylo na škodu. Každý programátor pořád dokola řeší problémy typu obecné vs. konkrétní, dokonce i substance vs. akcident, akorátže neví, že se tomu tak říká a že se jeho problémy (v trochu jiné podobě samozřejmě) řešily už před dvěma tisíci lety. Jestliže mu někdo na střední nezáživně a nevýstižně vykládal o sporu o univerzálie, zbytečně je odsouzen část z omylů opakovat, jako třeba když si myslí, že nutně musí existovat něco jako třída (~ substance), jinak se svět propadne v chaos

Spíš než v tom, o čem píšeš, je problém s lidma, kteří o filosofii nic neví a představují si, že filosofie = bezbřehé nekontrolovatelné a neověřitelné plkání o πčovinách. To není pravda, aspoň ne obecně.

Speciální případ přesahu mezi programováním, filosofií a (matematickou) logikou jsou pak věci jako teorie typů, kategorií, sémantika apod. kde je to úplně zřejmé.

Každému, kdo programuje, doporučuju knížky Peregrina. Sice mi ten člověk nesedí lidsky (znám ho osobně z univerzity), ale píše o filozofii dost zajímavě a pro "normální lidi".

1197

Vývoj / Re:Generická matice

« kdy: 12. 01. 2016, 21:33:41 »

Jde ve staticky typovaném jazyce implementovat matice s generickými prvky? Pokud ano, jak?
Např. v C++ bych mohl mít Matrix<double> nebo Matrix<Vector>, ale mně jde o to, aby v jedné matici mohly být prvky různých typů při zachování statické kontroly. Příkladem budiž třeba výpočet vektorového součinu pomocí determinantu (matice obsahuje vektory i skaláry a výsledkem je vektor).

Ono to je "abuse of notation", ale samozřejmě to jde, stačí mít protokol MatrixElementType a k němu potřebné operace. Potom v čase překladu lze generovat specializovaný kód.

1198

Vývoj / Re:Generická matice

« kdy: 12. 01. 2016, 21:31:20 »

Pokud jde o vektorový součin, řešil bych to čistěji - Matrix zobecnit na Tenzor, zavést Levi-Civitův pseudotenzor (permutační symbol) a dále pak počítat dle pravidel tenzorového počtu. Patrně podobně by šly řešit i jiné problémy.

Na to se nikdo neptal.

1199

Vývoj / Re:Generická matice

« kdy: 12. 01. 2016, 21:29:45 »

Matrix<std::pair<double, std::vector<double>*> matrix; // nebo nejakej auto pointer, nebo custom pair

if (matrix.get(x, y).second == NULL) //scalar
else //vector

Tak tohle je hodně blbej nápad.

1200

Vývoj / Re:Generická matice

« kdy: 12. 01. 2016, 15:54:26 »

Jde ve staticky typovaném jazyce implementovat matice s generickými prvky? Pokud ano, jak?
Např. v C++ bych mohl mít Matrix<double> nebo Matrix<Vector>, ale mně jde o to, aby v jedné matici mohly být prvky různých typů při zachování statické kontroly. Příkladem budiž třeba výpočet vektorového součinu pomocí determinantu (matice obsahuje vektory i skaláry a výsledkem je vektor).

Tak napada me jedine nejakej typ co by to zabalil, neco jako Variant v Decku:

http://dlang.org/phobos/std_variant.html

Pripadne vyuzit union, to by taky mohlo jit nejak slepit

To by ale už nebylo staticky typované.