Příspěvky

46

O serveru Root.cz / Diskuze

« kdy: 18. 06. 2019, 06:14:30 »

Proc z diskuze zmizela moznost davat palce dolu? Co je to zase za genialni featura? To se i z roota stava politicky korektni hnojiste? Hlavne aby nekdo nemel deprese, ze s nim ostatni nesouhlasi?
Bohuzel musim rict, ze z rootu se stava tezky odpad. Zacalo to zariznutim přihlášených prispevku. Od te doby forum skomira. Pri vsech tech hadkach a urazkach se clovek obcas dozvedel i zajimave informace. Ted se clovek na foru dozvi kulove. A ted dalsi zmena k "lepsimu". Tohle fakt musi vymyslet nejaky inteligent.

47

Hardware / Re:Intel nebo AMD?

« kdy: 11. 06. 2019, 07:17:34 »

Je ale pravda, ze na dmaci pouziti tyto patche nejsou potreba.

Jen pokud tím domácím použitím myslíte počítač, ze kterého nepřistupujete na web.

Vlastne mate pravdu. Dneska uz se vi i jak zneuzit diry v Intelu pres JS. Uznavam. No, ovsem v pripade nainstalovani vsech patchu uz intel i v single core zaostava.

48

Hardware / Re:Intel nebo AMD?

« kdy: 11. 06. 2019, 06:15:22 »

V posledni dobe se docela dobre dari AMD, dokonce udajne predbehla Intel tim, ze ma prejit u svych procesoru na 7nm technologii vyroby CPU.

Presto vsak Intel stale valcuje AMD co se tyce single core vykonu procesoru, takze co se mych potreb tyce, AMD bych si nikdy v dohledne dobe nekoupil.

Dalsi vec ktera mi prijde docela vyhodna je ten fakt, ze Intel ma zabudovanou grafickou kartu - coz asi ne uplne kazdemu muze prijit zajimave, ale ja na PC moc hry nehraju a tak mi to vyhovuje.

Nicmene chtel bych tady nadhodit diskuzi o tom, jak si myslite ze dopadne souboj AMD vs Intel v dohledne dobe - myslite ze ma AMD sanci prevalcovat a Intel muze zbankrotovat, podobne jako se to stalo Nokii?

Ocekavate nejake paktovani Intelu a NVidie do budoucna? Jak znamo, NVvidia ma konkurenci spise v AMD nez v Intelu, kteryzto nevyrabi externi graficke karty. Mohli by proto mozna spojit sily dohromady?

Bohuzel nemuzu souhlasit ani s jednim tvrzenim, nebo predpokladem.
Intel uz urcite v single-core nevalcuje amd, spis je to plichta(trochu naklonena pro intel). Za predpokladu ze nebudete instalovat patche, na stale mnozici se inteli problemy. Pak bude intel daleko v prachu vzadu. Je ale pravda, ze na dmaci pouziti tyto patche nejsou potreba. Navic s novym amd, ktere by melo vyjit nekdy ted v cervenci to vypada, ze naopak se ipc vice prikloni na stranu amd.
Co se tyka multithreadoveho vykonu, tam intel absolutne nestiha.
Pro hrani her je to tedy otazka. Pro praci, kde se multithreadovost vyuzije, zejmena vyvoj software, je amd jednoznacna volba. Bez diskuze.
I AMD ma procesory s GPU, docela prodavane a GPU samotne je podstatne vykonnejsi, nez Intel GPU.
Paktovani Intel s NVidii se mi moc nezda, z pravdepodobneho zasahu antimonopolniho uradu.
Urcite si nemyslim, ze Intel dopadne jako Nokie. Spis doufam, ze se trochu vyrovna trh, AMD si ukroji trochu vic servroveho kolace a konecne bude zas nejaka konkurence.

49

Software / Re:Aký software od Microsoftu používate?

« kdy: 29. 05. 2019, 20:05:13 »

QBASIC.EXE + GORILLA.BAS

A ještě tu mám Win3.11, na ukázku, že Widle byly v minulosti použitelnější než dnes.

Ale jako vazne. Kdyby ve windows 7 bylo wsl, tak je to ultimatni...
Myslim, ze 7cky byly fakt zdaleka nejlepsi OS pro napric uzivatelskym spektrem vubec. Jak jsem rikal, pokud by tam bylo wsl, tak...  nebo aspon docker for windows. To by mozna stacilo...

Jinak za mne. W10 na hry. Co se tyka programovani, tak visual studio je opravdu nejlepsi IDE(i kdyz potrebuje par pluginu, pro doladeni) pro c++. A to rikam jako clovek, co pouziva vim 20 let. Z uzivatelskeho softwaru za mne excel(i kdyz pravda, v poslednich letech jsem zadne nahrady nezkousel, ale pred lety, kdy jsem behem studia v ramci brigady excel musel pouzivat, jsem zjistil, ze jakekoli open/libre office tomu opravdu nesahaji ani po paty).

50

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 16:42:32 »

If the value p being boxed is an integer literal of type int between -128 and 127 inclusive (§3.10.1), or the boolean literal true or false (§3.10.3), or a character literal between '\u0000' and '\u007f' inclusive (§3.10.4), then let a and b be the results of any two boxing conversions of p. It is always the case that a == b.

To je uz skoro jak == v JS )

Presne A v dalsim zduvodneni vyslovene pisou ze zamer je aby sly boxovane hodnoty co nejvic porovnavat operatorem ==. Akorat se jim to zdalo moc narocne, tak dle normy staci jen cast oboru hodnot takhle porovnat.. .. mi to prijde jako docela komedie teda...

51

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 16:22:12 »

Nemá vliv na návratové hodnoty operátoru. Operátor == v Javě při použití na objekty porovnává reference. Integer ani String nejsou definovány jako singletony, takže v běžící aplikaci může existovat víc instancí, které shodou okolností obsahují stejnou hodnotu. Pokud tedy operátorem == porovnávám reference ukazující na stejnou hodnotu, je věcí náhody, zda dostanu true nebo false. Pool opakovaně používaných instancí akorát zvyšuje pravděpodobnost, že se pro stejnou hodnotu použijí stejné instance, ale nikdo nemůže zaručit, že nevznikne jiná instance se stejnou hodnotou.

Ne, tohle neni nemusi byt zadna hruba chyba a doufam, ze tyhle nesmysly nevykladate juniorum. Je presne definovano, kdy se to rovnat musi a je to i zduvodnene. Naopak idealne by se chtelo, aby se to rovnalo, ale z performance duvodu to neni vyzadovane v celem oboru platnosti danych typu. Rikate to presne opacne nez to je.

If the value p being boxed is an integer literal of type int between -128 and 127 inclusive (§3.10.1), or the boolean literal true or false (§3.10.3), or a character literal between '\u0000' and '\u007f' inclusive (§3.10.4), then let a and b be the results of any two boxing conversions of p. It is always the case that a == b.

Ideally, boxing a primitive value would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rule above is a pragmatic compromise, requiring that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly. For other values, the rule disallows any assumptions about the identity of the boxed values on the programmer's part. This allows (but does not require) sharing of some or all of these references. Notice that integer literals of type long are allowed, but not required, to be shared.

This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all char and short values, as well as int and long values in the range of -32K to +32K.

https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7

A to je pekny priklad neintuitivnosti jazyka.

52

Vývoj / Re:Ideálny programovací jazyk

« kdy: 16. 05. 2019, 16:11:34 »

každý operátor rovnosti, který podporuje i něco jiného, než primitivní typy, je kontraintuitivní, protože u složitějších typů vždy narazíme na to, že prostě není jasné, co je to rovnost.

Nemohu souhlasit. Stačí se na to dívat tak, že porovnáváte hodnotu versus identitu, a není problém.

Co naopak problém je, jsou technické/výkonnostní potíže. Ostatně proto, se soukromě domnívám, ty objekty jsou řešené jako reference.

No a problem je, ze v jave operator == neporovnava ani identitu ani hodnotu. On teda se snazi porovnavat identitu, ale z navrhu jinych casti jazyka (napr cachovani hodnot Integeru) zpusobuje, ze neresi ani identitu, takze ten operator ma v podstate nedeterministicke chovani(protoze specka rika jen minimalni pocet cachovanych hodnot).

53

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 17:47:42 »

Naopak, to je nejvetsi pain GC a to je proc pri serioznim pouziti jsou s Javou obrovske problemy. Nikdy nevis kdy zacne GC uvolnovat a jak velkou kupu pameti. Vede to casto k tomu, ze jakekoli vetsi aplikace se v jave ladi daleko pracneji nez i ve starem C.

Popravdě jsem nikdy nedělal v Javě nic tak velkého. Zatím mi vždy stačil přístup napsat to jednoduše, hlavně pustit z hlavy poučky o mikro optimalizacích z C++ a v případě problému to zprofilovat.
Docela mě zajímá, jaké charakteristiky má taková větší aplikace u které dělá problém spuštění GC.

Vetsi databaze, aplikace citlive na latenci.

Odkdy má velikost databáze vliv na latenci GC?

Co to meles? Ja rikam neco jineho, ja rikam, ze velke db v jave s tim maji problem s gc, s world stopem, napr HBase, asi nejrozsirenejsi free big data databaze. A totez i aplikace citlive na latenci.  Jakekoli spusteni GC znamena nedeterministicke lagy.

54

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 15:35:55 »

Naopak, to je nejvetsi pain GC a to je proc pri serioznim pouziti jsou s Javou obrovske problemy. Nikdy nevis kdy zacne GC uvolnovat a jak velkou kupu pameti. Vede to casto k tomu, ze jakekoli vetsi aplikace se v jave ladi daleko pracneji nez i ve starem C.

Popravdě jsem nikdy nedělal v Javě nic tak velkého. Zatím mi vždy stačil přístup napsat to jednoduše, hlavně pustit z hlavy poučky o mikro optimalizacích z C++ a v případě problému to zprofilovat.
Docela mě zajímá, jaké charakteristiky má taková větší aplikace u které dělá problém spuštění GC.

Vetsi databaze, aplikace citlive na latenci.

55

Vývoj / Re:Ideálny programovací jazyk

« kdy: 10. 05. 2019, 21:41:07 »

Naopak od C++11 se o to neni potreba starat a funguje to. Narozdil od GC jazyku jako java navic i deterministicky

Ještě k té deterministické dealokaci - dobře že to zmiňuješ, protože to názorně ukazuje posunuté myšlení C++ programátorů. Deterministická dealokace je sama o sobě zbytečná, řešený problém si ji sám o sobě nežádá. Ovšem v C++  je to způsob, jak uvolnit zdroje, takže se tak používá na vše. Jenže už se nemyslí na to, že to má neblahý vliv na výkon dealokace. Ta kdyby se nedělala pro každý objekt zvlášť, ale pro větší bloky, tak je to mnohem výhodnější a právě to je moment, ve kterém získává GC navrch - uklízí až když je to nutné, což je v běžných scénářích mnohem výhodnější než se starat o každý mazaný objekt.

Naopak, to je nejvetsi pain GC a to je proc pri serioznim pouziti jsou s Javou obrovske problemy. Nikdy nevis kdy zacne GC uvolnovat a jak velkou kupu pameti. Vede to casto k tomu, ze jakekoli vetsi aplikace se v jave ladi daleko pracneji nez i ve starem C.

56

Vývoj / Re:Ideálny programovací jazyk

« kdy: 10. 05. 2019, 18:35:15 »

V první řadě je otázka, co to znamená ideální, nejspíš nejde udělat jazyk, který by se hodil na všechno. Ale když vezmu mainstream, tak je rozhodně nejdůležitější, aby byl jednoduchý, asi tak na úrovni javy (i ta má věci navíc, jako je třeba vestavěná synchronizace).

Syntaxe by se měla držet osvědčených zvyků ohledně operátorů, závorek atd., některé nové jazyky to zbytečně prohazují. Dál základní OOP, funkcionální prvky, aby stačilo říct "co" místo "jak". Takže streamy (ale jednodušší než v javě), lambdy, konstantní objekty...

Rozhodně musí mít GC, ruční správa paměti je ve většině případů špatná věc. Stejně tak by se programátor neměl starat o to, zda budou data na stacku nebo heapu, tohle zvládne překladač či runtime dost dobře sám. C++11 jasně ukazuje, že je špatný nápad tím prasit jazyk a že z toho cesta nevede. Smart pointery, move semantika atd. to ve výsledku ještě zhorší.

A bylo by hezké, kdyby měl nějak snadno zvládnuto ORM, JSON, HTTP, prostě napojení na běžné okolní prostředí.

No lol... tak to urcite.. to je pekna snuska...
Naopak od C++11 se o to neni potreba starat a funguje to. Narozdil od GC jazyku jako java navic i deterministicky, takze neni potreba jakekoli komplikovanejsi veci ojebavat pres manualni spravu pameti. Jak je videt na vetsich komplikovanejsich java projektech.

Jn, problemy, na ktere lze pouzivat ORM.. na to c++ potreba neni, to je pravda.. tam bohate staci python.

57

Vývoj / Re:Ideálny programovací jazyk

« kdy: 09. 05. 2019, 10:21:49 »

Ruční volání destruktorů nebo třeba zavírání souborů by mě už nebavilo. Proč bych to měl hlídat?

V cpp zadne rucni volani destruktoru neni potreba. Akorat lze presne zjistit kouknutim do kodu, kdy se tak stane.

Takže se zánikem posledního deskriptoru na objekt se automaticky zavolá jeho destruktor? Java se má co učit, neboť tohle neumí.

Ano, pokud se pouziva moderni cpp(od 11ky, i kdyz i drive byly smart pointry ale s problemama.) Samozrejme je to zpetne kompatibilni, takze kdyz se vylozene chces strilet do nohy a ignorujes guideliny, ktere radi nepouzivat stare konstrukce nutne z duvodu zpetne kompatibility, tak si tu nohu ustrelit porad muzes.

58

Vývoj / Re:Ideálny programovací jazyk

« kdy: 09. 05. 2019, 10:18:19 »

A dalsi vec co nechapu proc to C++ dela je, ze kdyz chci vyuzivat jen stacku, tak pokud vracim z nejake funkce objekt na stacku, tak C++ ten objekt veme a cely ho prekopiruje jinam - nechapu proc, dyt je to neefektivni.

Pokud vracis objekt vytvoreny na stacku, tak se to nedeje, vetsina objektu se vytvari tam kde je potreba. Takze ze stacku se nic nekopiruje.

Dale me na C++ dost vytaci hlavickove soubory, to je proste z hlediska OOP paradigmatu totalni kockopsovina.

To je bohuzel z historickych duvodu a z duvodu kompatibility s C. Snad to moduly ted zmeni. Ted se to muselo ruzne obchazet.

A uplne nejvic me stve, ze to neni ani poradne zaplacene, tak proc se s tim stvat.

Zaplacene je to velmi dobre, pokud neco umis, pokud jsi standardni noob, tak ti samozrejme nikdo sypat zlato nebude.

59

Vývoj / Re:Ideálny programovací jazyk

« kdy: 08. 05. 2019, 21:31:18 »

Pokud jsem si všiml, tak destruktory fungují korektně jen v PHP. Spouští se ihned po uvolnění objektu. V ostatních jazycích je to slepeno dohromady s GC - destruktory neplní řádně svou funkci a proto je s nimi tolik potíží.

No nevím, ale v cpp jsem divné chování destruktorů nikdy nezaznamenal, zatím se mi vždy spustil bezprostředně po zavolání delete nebo když daný objekt má zmizet ze stacku. Pravdou je, že u jazyků používajících garbage collector tomu může být jinak, nicméně to bude asi jeden z důvodů, proč v Pythonu destruktory nejsou (měl by se spustit s během GC, což je nedefinovaný okamžik).

Ruční volání destruktorů nebo třeba zavírání souborů by mě už nebavilo. Proč bych to měl hlídat?

V cpp zadne rucni volani destruktoru neni potreba. Akorat lze presne zjistit kouknutim do kodu, kdy se tak stane.

60

Vývoj / Re:Python bytearray to string

« kdy: 26. 04. 2019, 10:37:36 »

kde je to technická nutnost, je to důsledek omezení těchto nižších jazyků, které nemají žádný přínos.

Technická nutnost fakt ne. Asi to usnadňuje psaní kompileru (nemám zkušenost), ale jinak je to fakt jen na libovůli tvůrce jazyka, se statickou typovostí to nemá nic moc společného. Viz třeba výše zmíněný Rust, tvrdit že je to dynamicky typovaný jazyk by bylo slušné šílenství ;-)

To jste si domyslela něco, co jsem nepsal. Já o statických typech nenapsal ani slovo. Co by mě šlo vytknout je tvrzení, že ta omezení nemají přínos. Přínos mají v jednoduchosti implementace jazyka a pravděpodíbně i ve výkonu.

Naopak, nepřehledné je mít milion různých proměnných v kterých jsou stejná data a která nepotřebujeme současně. Jedná se pořád o jedny a ty samá data, je správné mít pro ně stále stejný název. Potřeba měnit proměnné je zlozvyk ze staticky typovaných jazyků, kde je to technická nutnost, je to důsledek omezení těchto nižších jazyků, které nemají žádný přínos.

Nelzi. Jasne jsi psal, ze je to technicka nutnost. Coz ti kate vyvratila na priklade.