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.
Tak to považuješ chybně.Logicke chyby povazuji za podmnozinu semantickychA hlavne, i kdyz pada, tak jen na semanticke chybyNikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.
Ze to vyplazne semanticky spatnej vysledek mam asi podobnlu duveru jako kdyz to napisu v pythonu.Nikdy jsem netvrdil opak.
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resitVětšinou jsem se bez cyklické struktury obešel.
data Node = Node {pk: Int, val: String, links: [Node]}(Node 42 "text") == (Node 42 "text")A hlavne, i kdyz pada, tak jen na semanticke chyby
řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?Záleží náročnější na co.
Dependency injection znamena 'posli mi objekt jako parametr, at si ho nemusim vytvaret sam'.
Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)No a to je prave ten problem. Staticky typ je staticky typ v kazdem z techto jazyku. A pokud to neni upresneno, nelze ignorovat mainstramove jazyky se statickymi typy, tedy C, C++, Java a C#.
To neni straw man, to je reakce na tvrzeni, kdyz se to podari zkompilovat, je to v podstate hotovo.A proc je to blbost na entou? Protoze je to straw man.Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou. Viz C, ktere lehce umozni prekladat padajic programy a naopak jsou ty typy zdrojem mnohych chyb. Pak tu jsou jazyky s pokrocilejsim typovym systemem. Pokrocilejsi = slozitejsi. Tyto sice umozni eliminovat nektere chyby typické pro C, ale a) ty se v dynamickem jazyce nevyskytuji b) je tu kardinalni otazka, kdo odladi chyby v pouziti typoveho systemu? A na to mame univerzalni odpoved, testy. Staticke typy vec zbytecne komplikuji a ve vysledku nic neresi. S vyjimkou vykonu.Tak to určitě.
Objektový přístup spočívá v tom, že data kontroluješ co možná nejpozději.
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Dnes jsou kvalitní fw na co? Na dělání eshopů, možná redakčních systémů. Kolik máš kvalitních frameworků pro php na kreslení technologických schémat, které by si jednoduše rozuměly s opc serverem a vůbec obecně pro průmyslové nasazení? Který php framework si dobře rozumí alespoň s nejběžnějšími ERP systémy? Framework je dobrý na dělání tuctových webů, které potřebuješ sázet jako baťa cvičky, nikoliv na systémy přizpůsobené na míru, kde fw stejně z půlky musíš překopat a pak složitě udržovat funkční.Ta, co mě zaměstnává, to oceňuje už přes 15 let. Vývoj začal v roce 2002, nasazeno to bylo v roce 2003. Kde v té době bylo symfony?Jenže to je něco jiného. Dnes kvalitní FW jsou.A za svuj kratší život má symfony už čtvrtou major verzi (kdy přestala být podporovaná ta první) a visí na spoustě dalších projektů, takže otázka zní, kde bude za dalsich 15 let? Jak jsem napsal, myslím si, že z hlediska dlouhodobého udržování aplikace je to lepší řešení a vyplatí se to.Nevyplatí. Proč by mělo? Uveďte konkrétní výhody.
Jako dobře, pokud budete tvrdit, že žádný FW nemá požadované funkčnosti, protože vy máte tento a tento skvělej nápad, který žádné FW nemá, a naroubovat se na to nedají, tak fajn, takto by se dalo bavit. Ale vytvářet si vlastní řešení jen proto, aby bylo vlastní?! Ne, zcela určitě ne.
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!
Asi nerozumíš více věcem, ale to je normální.Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.Však to v Pythonu odchytí testy, ne?
Mohl bys mi prosím odpovědět na položenou otázku?CitaceProč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?
Pokud neznáš odpověď, tak samozřejmě nemusíš a ani se nemusíš zbytečně vykrucovat.
Ta, co mě zaměstnává, to oceňuje už přes 15 let. Vývoj začal v roce 2002, nasazeno to bylo v roce 2003. Kde v té době bylo symfony?Jenže to je něco jiného. Dnes kvalitní FW jsou.
A za svuj kratší život má symfony už čtvrtou major verzi (kdy přestala být podporovaná ta první) a visí na spoustě dalších projektů, takže otázka zní, kde bude za dalsich 15 let? Jak jsem napsal, myslím si, že z hlediska dlouhodobého udržování aplikace je to lepší řešení a vyplatí se to.Nevyplatí. Proč by mělo? Uveďte konkrétní výhody.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.