46
Vývoj / Re:Python attribute error 'str' object has no attribute 'get'
« kdy: 20. 01. 2019, 08:45:07 »
zkus vymazat .get('nodes'). Ale podle mě nevíš co děláš.
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
47
Vývoj / Re:Co si myslíte o OOP?
« kdy: 19. 01. 2019, 10:59:58 »Vůbec nevíš, která bije. Jestli s tím “pracuješ” v bakalářce, tak ji neobhájíš ani ne VŠE.Kontinuace je 'zbytek vypoctu'.Je to přesně naopak, kontinuace je funkce reprezentující nějaký výpočet, které se předá “zbytek výpočtu” ve formě funkce. Z Wikipedie bys mohl pochopit aspoň převod konstanty na příslušnou kontinuaci.
Synku, ja s timhle pracuju, tak snad vim, o cem mluvim.
Ty zrejme mluvis o funkci callcc, neboli call-with-current-continuation, ktera dostane parametr K, coz je kontinuace, neboli zbytek vypoctu.
P.S. Call/cc je něco zcela jiného.
Mas neco cim bys prispel do diskuse nebo tady chces jen dal trollovat?
Jestli chces pokracovat tak predstav svuj argument k vyvraceni a neschovavej se za nejaky hadanky.
k čemu tedy call/cc používáš?
48
Vývoj / Re:Co si myslíte o OOP?
« kdy: 19. 01. 2019, 10:58:11 »Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?
v Crystalu se používají makra jako náhrada za runtime metaprogramování a introspekci. V dynamických jazycích jako python a ruby nejsou makra moc potřeba.
https://crystal-lang.org/
Crystal se snaží být statcké Ruby.
49
Vývoj / Re:Co si myslíte o OOP?
« kdy: 17. 01. 2019, 09:11:32 ».....
ten článek The Perils of JavaSchools mimo jiné pojednává i o neschopnosti uvažovat na vyšší úrovni abstrakce.
50
Vývoj / Re:Co si myslíte o OOP?
« kdy: 16. 01. 2019, 22:04:24 »A proto mam rad komplexni python s jeho multiparadigmatickym pristupem, dekoratory, generatory, comprehension a dalsimi featurami, protoze programovat v nem je poteseni a radost.A to jsi ještě nezmínil konkurentnost. Programovat něco konkurentního v Pythonu, to není potěšení a radost, to už je přímo orgastická extáze. Obzvlášť ve dvojce.
ve dvojce jsem používal gevent a radost to byla.
51
Vývoj / Re:Co si myslíte o OOP?
« kdy: 16. 01. 2019, 18:36:48 »ndarray je implementováno tadyVůbec nerozumím, co se snažíš říct.
https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/arrayobject.c
všechny vestavěné typy jsou implementovány v C, není rozdíl mezi rozšiřujícím typem a vestavěným typem.
https://docs.python.org/3/extending/newtypes_tutorial.html
co jsi chtěl říct ty tím odkazem?
52
Vývoj / Re:Co si myslíte o OOP?
« kdy: 16. 01. 2019, 17:52:36 »je to implementováno stejně jako všechny vestavěné typy cpythonu.Ani mi to moc nepřijde: https://github.com/numpy/numpy/blob/master/numpy/core/src/common/array_assign.c
to jsou jen pomocné funkce, které přímo z pythonu volat nelze.
ndarray je implementováno tady
https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/arrayobject.c
všechny vestavěné typy jsou implementovány v C, není rozdíl mezi rozšiřujícím typem a vestavěným typem.
https://docs.python.org/3/extending/newtypes_tutorial.html
53
Vývoj / Re:Co si myslíte o OOP?
« kdy: 16. 01. 2019, 17:22:44 »Ani ne. Typová informace je součástí toho objektu. Typová kontrola probíhá za běhu.Nemluvil jsem o tom, kde je typová kontrola, ale o tom, v čem je to implementováno.
je to implementováno stejně jako všechny vestavěné typy cpythonu.
54
Vývoj / Re:Co si myslíte o OOP?
« kdy: 16. 01. 2019, 17:17:31 »Ono to krasne dokazuje omezenost mysleni 'statickych' programatoruMno... Zaznelo tady "muzes pouzit numpy.array". Neni to nahodou implementovano staticky v cythonu nebo rovnou v C?
Ani ne. Typová informace je součástí toho objektu. Typová kontrola probíhá za běhu.
55
Vývoj / Re:co si myslite o oop?
« kdy: 16. 01. 2019, 15:22:20 »Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.
V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).
Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.
Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.
List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.
Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?
Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:
- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...
Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic...
Něco si k tomu vygooglete. Začněte tutoriálem. Tady vám to nikdo do podrobna nevysvětlí, zbytečně o bychom přepisovali dokumentaci.
pro úspornou reprezentaci pole čísel můžete použít třeba array.array nebo numpy.array
https://docs.python.org/3/library/array.html
56
Vývoj / Re:Jednoduchý framework PHP
« kdy: 16. 01. 2019, 14:19:47 »Nepotřebuješ žádný framework. jQuery sloužilo k vyřešení nekompatibilit mezi browsery a pro jednodušší manipulaci s DOMem, v PHP ale žádná taková potřeba není, protože v PHP žádný DOM není. Dneska už není třeba ani jQuery, moderní javascript má vše co je potřeba.
PHP je vlastně samo o sobě templatovací framework, a je otázka jestli vzhledem k rozšířenosti moderního javascriptu má cenu ho takto vůbec používat, protože GUI může být celé v javascriptu (SPA, ale lze i bez) a v PHP můžeš mít implementováno REST(ish...) API pouze pro tahání a ukládání dat, případně ještě SSE (server sent events) či jiné podobné věci. Webovky pak mohou být ne-php soubory a v nich pak javascriptem tahat a ukládat data do databáze. Na implementaci REST API pravděpodobně nepotřebuješ žádný framework, ale určitě se nějaké najdou.
PHP má smysl jako platforma pro provozování historických hotovek (Wordpress, Joomla, Drupal...). Jinak hlavní důvod proč ho používat je kvůli jeho rozšířenosti a nízké ceně za hosting. Další výhodou PHP je že můžeš mít nějakou logiku i když nepoužíváš javascript a udělat tak stránku klasicky postaru...
REST API bez frameworku je z 90% znovuvynalézání kola.
57
Vývoj / Re:Co si myslíte o OOP?
« kdy: 16. 01. 2019, 10:30:11 »Proto davam prednost pythonu se silnymi typy, dnes i moznosti typehintingu.
to právě funguje jen s podmnožinou pythonu. Když nějaká knihovna používá metaclassy, nebo jinak dynamicky generuje typy, tak se to musí řešit mypy pluginem. Většina pluginů pouze potlačí chybové hlášky.
58
Vývoj / Re: Jednoduchý framework PHP
« kdy: 16. 01. 2019, 09:13:06 »Pokud mastíš jednoduché weby, doporučuji DSL framework (Pro Ruby Sinatra, pro PHP zkus Slim/Limonade). Na cokoliv složitějšího ber Nette (PHP), Padrino (Ruby).
budoucnost v Ruby světě je Amber.
59
Vývoj / Re:Co si myslíte o OOP?
« kdy: 15. 01. 2019, 17:55:24 »Netvrdil jsem, že jsou nesmyslné, ale v praxi nepraktické a že se pragmaticky radši zabývám věcmi praktickými.Co je to funkcionální si každý zkusil ve škole na lispu.Takže tě přece jenom někdo donutil si ty "nesmyslné" jazyky vyzkoušet. To je dobře
V praxi je nepraktická i přílišná volnost.
60
Vývoj / Re:Jaký editor pro psaní zdrojáků v jazyce C?
« kdy: 15. 01. 2019, 14:02:13 »To jsou zase kydy.
VIM pouzivam denne, je to muj primarni editor na mem windows notebooku, ale s IDE se to fakt porovnavat neda.
Treba eclipse pri psani java kodu neustale kompiluje na pozadi a cervene podtrhava chyby, skrta deprecated metody, zlute podtrhava warningy (napr usused variables) a primo navrhuje opravy.
Naseptavac nabizi autocomplete nabidku s procentualni pravdepodobnosti na zaklade realne cetnosti v kodu.
Kdyz napisu Set<String> x = new H - a zmacknu CTRL+space - eclipse mi rekne, ze s pravdepodobnosti 95% budu chtit HashSet<>(); s nizsi pravdepodobnosti zavolat metodu se stejny navratovym typem, s este nizsi pravdepodobnosti chci zalozit inner class...
Validuje XML dokumenty, luxusni podpora automaticke refaktorizace, generovani boilerplate kodu typu gettery/settery, copy constructory jednim klikem
Vyvoj v IDE se s vimem neda ani omylem srovnat.
ale tazatel se neptal na IDE pro Javu.
Pro C/C++ je CLION
https://www.youtube.com/watch?v=Srnw1dI1iAA
stojí to za peníze? Umí to něco navíc oproti zmiňovanému VS Code s pluginem?
