Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: Bezdislav 28. 03. 2017, 11:53:39
-
vysoké školy neprodukují kvalitní programátory. Ani střední odborné. To co příjde ze škol je odpad. Nesoustředění, těkaví lepïči kodu, u kterých ani nevíte jestli zítra do práce vůbec příjdou.
Stále více lidí programuje i když neměli žadné IT vzdělání, protože programátoři prostě chybí a jsou stále více dobře placení. Ovšem tito lidé už jsou většinou aspoň ve střední věku, 30-40 let.
Zájem u mladých o programování a IT všeobecně? Ano, jejich zájem začíná a končí tam kde jsou sociální sítě. Samozřejmě existují vyjímky, které potvrzují pravidlo.
Stále více a více je tedy programátorská sféra zaplněná hobbyisty, kteří jsou dobří, ale není jich nekonečno. Tudíž co bude v budoucnu? Budem dováže Indy, kde je opravdu neskutečný boom v programátorech? Nebo jak to vidíte vy, kteří už jste v praxi nějaký ten pátek?
-
Stále více a více je tedy programátorská sféra zaplněná hobbyisty, kteří jsou dobří, ale není jich nekonečno.
To tak snad bylo vzdycky ne? Programatori v 70. az 90. letech byli jenom taci, protoze na skolach se to vubec neucilo. V soucasnosti ti lide dostanou papir, ktery neni potreba, jen dava zdani nejakeho formalniho vzdelani.
-
Ne.
-
A co je kvalitní programátor ?
Ten kdo ve wysiwyg-html-editoru nakliká stránku ?
Ten kdo dokáže slepit pár J2EE knihoven a vytvořit otesánka ?
Ten komu stačí gcc a zbytek si postaví ?
Osobně si myslím že kvalitní programátor je ten dole, ale komerční tlaky kolem jsou spíš opačného názoru.
Ale všeho z mírou, psát si do každého projektu vlastní libzip2 je extrémismus :-)
-
vysoké školy neprodukují kvalitní programátory. Ani střední odborné. To co příjde ze škol je odpad. Nesoustředění, těkaví lepïči kodu, u kterých ani nevíte jestli zítra do práce vůbec příjdou.
Stále více lidí programuje i když neměli žadné IT vzdělání, protože programátoři prostě chybí a jsou stále více dobře placení. Ovšem tito lidé už jsou většinou aspoň ve střední věku, 30-40 let.
Zájem u mladých o programování a IT všeobecně? Ano, jejich zájem začíná a končí tam kde jsou sociální sítě. Samozřejmě existují vyjímky, které potvrzují pravidlo.
Stále více a více je tedy programátorská sféra zaplněná hobbyisty, kteří jsou dobří, ale není jich nekonečno. Tudíž co bude v budoucnu? Budem dováže Indy, kde je opravdu neskutečný boom v programátorech? Nebo jak to vidíte vy, kteří už jste v praxi nějaký ten pátek?
No oni i ti hobyisti mají své mouchy. Třeba dřívější sekta Spektristů, pozdější Bashistů.
Jinak programátory nahradí umělá inteligence. Činnosti se stěhují do počítačů, takže interakce s reálným světem se omezuje, což pochopení světa umělé inteligenci zjednodušuje, protože se pohybuje v unifikovaném a zjednodušeném prostředí. Jak budou spolu stále více komunikovat stroje, odpadne grafický režim, což bude další zjednodušení. Nakonec ani té inteligence nebude tolik třeba. Například pohyb roje mohou řídit jednoduchá pravidla na úrovni inteligence bakterií, či dokonce neživé hmoty. Voda taky teče, aniž by někdo řídil její tok.
-
A co je kvalitní programátor ?
Ten, co vyresi zakaznikuv problem a vysledek bude pouzitelny a opravovatelny i po tom, co programatora sezere krokodyl.
-
A co je kvalitní programátor ?
Ten kdo ve wysiwyg-html-editoru nakliká stránku ?
Ten kdo dokáže slepit pár J2EE knihoven a vytvořit otesánka ?
Ten komu stačí gcc a zbytek si postaví ?
Osobně si myslím že kvalitní programátor je ten dole, ale komerční tlaky kolem jsou spíš opačného názoru.
Ale všeho z mírou, psát si do každého projektu vlastní libzip2 je extrémismus :-)
A když ten dole zemře, nebo se jen opije, kdo ho nahradí? A kolik ta náhrada bude stát.
-
A co je kvalitní programátor ?
Ten, co vyresi zakaznikuv problem a vysledek bude pouzitelny a opravovatelny i po tom, co programatora sezere krokodyl.
Tak, tak, ...
-
hobbyisty
Stále méně a méně lidí umí psát.
-
Tak samozrejme, ze jich ubyva, je stale mene lidi, takze je mene i tech chytrych a podstatna cast z nich se cpe na prestizni obory nebo tam, kde to obkecaji. Tento trend bohuzel nesouvisi s vysokou ani stredni skolou, zacina uz na zakladce a pak se jen prohlubuje. Zmenit to muzete pouze u vlastnich deti.
-
IMHO asi bude nutné, aby si firmy ty kvalitní programátory (a řidiče kamionů, řemeslníky a další nedostatkové profese) vyškolily samy. A po vyškolení a zaučení si jich vážily a kdejakej magor ...eee manager po nich nevozil nos, že když chtějí odejít, tak ať jdou, že lidí co stojí před vrátnicí a žebrají o práci je dost.
-
vysoké školy neprodukují kvalitní programátory. Ani střední odborné. To co příjde ze škol je odpad. Nesoustředění, těkaví lepïči kodu, u kterých ani nevíte jestli zítra do práce vůbec příjdou.
Stále více lidí programuje i když neměli žadné IT vzdělání, protože programátoři prostě chybí a jsou stále více dobře placení. Ovšem tito lidé už jsou většinou aspoň ve střední věku, 30-40 let.
Zájem u mladých o programování a IT všeobecně? Ano, jejich zájem začíná a končí tam kde jsou sociální sítě. Samozřejmě existují vyjímky, které potvrzují pravidlo.
Stále více a více je tedy programátorská sféra zaplněná hobbyisty, kteří jsou dobří, ale není jich nekonečno. Tudíž co bude v budoucnu? Budem dováže Indy, kde je opravdu neskutečný boom v programátorech? Nebo jak to vidíte vy, kteří už jste v praxi nějaký ten pátek?
Nejlepší programátor je ten s doménovou znalostí, studiím IT pro IT samotné je cesta do pekel. Dřív se "IT" studovalo jen jako doplněk k nějakému "skutečnému" oboru, například v rámci numerické matematiky. Pro praxi je důležitější doménová znalost a produktivní nástroje, když už je potřeba něco řešit počítačem.
-
+1, pripadne +1000000 8)
IMHO asi bude nutné, aby si firmy ty kvalitní programátory (a řidiče kamionů, řemeslníky a další nedostatkové profese) vyškolily samy. A po vyškolení a zaučení si jich vážily a kdejakej magor ...eee manager po nich nevozil nos, že když chtějí odejít, tak ať jdou, že lidí co stojí před vrátnicí a žebrají o práci je dost.
-
hobbyisty
Stále méně a méně lidí umí psát.
Proč myslíte, správně je to jen několik posledních let, dříve se byl správně i tvar hoby, coby koníček. Je to spíše otázka generační. Ale máte pravdu, čeština upadá už nejméně 80 let. Nejkrásnější byla tak kolem roku 1930. A správněji by asi bylo hobista, jako drogista, obchodník v oboru drogerie. Po vašem hobbyista. To máte jako počeštěné lobista a novočeské multikulturní a krkolomné lobbyista.
-
Nejlepší programátor je ten s doménovou znalostí, studiím IT pro IT samotné je cesta do pekel. Dřív se "IT" studovalo jen jako doplněk k nějakému "skutečnému" oboru, například v rámci numerické matematiky. Pro praxi je důležitější doménová znalost a produktivní nástroje, když už je potřeba něco řešit počítačem.
Většina kódu je režijní banalita, samotné znalostní domény se týká snad 1%.
-
Ale máte pravdu, čeština upadá už nejméně 80 let. Nejkrásnější byla tak kolem roku 1930.
Nicemu to nevadi, jazyk se musi vyvijet. Podivejte se na nejhorsi variantu cestiny vubec a pritom ji Slovaci stale pouzivaji.
-
Ale máte pravdu, čeština upadá už nejméně 80 let. Nejkrásnější byla tak kolem roku 1930.
Nicemu to nevadi, jazyk se musi vyvijet. Podivejte se na nejhorsi variantu cestiny vubec a pritom ji Slovaci stale pouzivaji.
Vyvíjet neznamená degenerovat.
-
Nejlepší programátor je ten s doménovou znalostí, studiím IT pro IT samotné je cesta do pekel. Dřív se "IT" studovalo jen jako doplněk k nějakému "skutečnému" oboru, například v rámci numerické matematiky. Pro praxi je důležitější doménová znalost a produktivní nástroje, když už je potřeba něco řešit počítačem.
To tvrdil už před dvaceti lety náš docent matematiky na IT vysoké škole, že "čisté IT" je neperspektivní a budoucnost mají lidé co umí primárně doménu a IT bokem. No, pořád to není pravda.
V reálu je samozřejmě nutné mít představu o oboru, pro který člověk programuje, ale ta se dá získat poměrně rychle. Nějaký detailní vhled ale programátor moc nepotřebuje, od toho je tu business a analytici. Tohle nastavení se v praxi osvědčuje. Co se naopak moc neosvědčuje je situace, kdy člověk s perfektní znalostí oboru zkouší ubastlit nějaký program. Výsledkem je, jak jinak, bastl.
Samozřejmě jsou situace, kdy i takový postup má smysl, typicky když si vědec potřebuje naprogramovat nějakou simulaci v Matlabu / Rku, ale to je dost mimo programátorský mainstream.
-
Ale máte pravdu, čeština upadá už nejméně 80 let. Nejkrásnější byla tak kolem roku 1930.
Nicemu to nevadi, jazyk se musi vyvijet. Podivejte se na nejhorsi variantu cestiny vubec a pritom ji Slovaci stale pouzivaji.
Slovanským národům je ale slovenština libozvučnější, to čeština jim nesedí :-)))
-
V reálu je samozřejmě nutné mít představu o oboru, pro který člověk programuje, ale ta se dá získat poměrně rychle. Nějaký detailní vhled ale programátor moc nepotřebuje, od toho je tu business a analytici. Tohle nastavení se v praxi osvědčuje. Co se naopak moc neosvědčuje je situace, kdy člověk s perfektní znalostí oboru zkouší ubastlit nějaký program. Výsledkem je, jak jinak, bastl.
No tohle rozhodně neplatí obecně. Jamile nejste úplný mainstream typu Java, C#, .NET a podobně, zaměstnavatelé stále častěji preferují na pozice konzultanta/programátora lidi z oboru jejich businessu stejně jako zákazníci. Je totiž neskonale jednodušší naučit technicky/přirodovědně vzdělaného člověka programovat, než programátorovi vysvětlovat zákonitosti jejich businessu a procesů, které potřebují. Někde se s holým IT vzděláním a praxí vůbec nedostanete ani k pohovoru.
-
A co je kvalitní programátor ?
Ten kdo ve wysiwyg-html-editoru nakliká stránku ?
Ten kdo dokáže slepit pár J2EE knihoven a vytvořit otesánka ?
Ten komu stačí gcc a zbytek si postaví ?
Osobně si myslím že kvalitní programátor je ten dole, ale komerční tlaky kolem jsou spíš opačného názoru.
Ale všeho z mírou, psát si do každého projektu vlastní libzip2 je extrémismus :-)
Kvalitny programator je ten, ktory je vhodny pre dany projekt. Ak bastlim hajzlovu misu v assembleri, nenajmem si JEE javistu a na projekt v php jadroveho fyzika s dobrou znalostou matlabu. A ak robim J2EE, tak si nenajmem joudu hobistu co na arduine blika s diodkami.
-
Slovanským národům je ale slovenština libozvučnější, to čeština jim nesedí :-)))
Vzpomínám si, když jsem jedné slovenské spolupracovnici řekl: "Vlasta, choď do riti." tak mi to znělo skoro jako lichotka ;D
-
preco by mali byt C# a JAVA mainstreamove? Mozte to vysvetlit? To skor javascript, css a html.
-
preco by mali byt C# a JAVA mainstreamove? Mozte to vysvetlit? To skor javascript, css a html.
Asi byl myšlen backend a jazyky pro patlaly (s VM, GC...).
-
Je totiž neskonale jednodušší naučit technicky/přirodovědně vzdělaného člověka programovat, než programátorovi vysvětlovat zákonitosti jejich businessu a procesů, které potřebují.
Na to naučit se kvalitně programovat je potřeba pár let praxe. Opravdu jsou programátoři tak tupí, že by za pár studia let ty zákonitosti businessu a procesů nepochopili?
-
preco by mali byt C# a JAVA mainstreamove? Mozte to vysvetlit? To skor javascript, css a html.
Asi byl myšlen backend a jazyky pro patlaly (s VM, GC...).
Pre patlaly? To vies aj nejako dolozit, alebo je to len tvoj subjektivny pocit?
-
Je totiž neskonale jednodušší naučit technicky/přirodovědně vzdělaného člověka programovat, než programátorovi vysvětlovat zákonitosti jejich businessu a procesů, které potřebují.
Na to naučit se kvalitně programovat je potřeba pár let praxe. Opravdu jsou programátoři tak tupí, že by za pár studia let ty zákonitosti businessu a procesů nepochopili?
Tiez suhlasim, veci co zvyknu vyplodit elektrikari a prirodvedci byvaju tak na obesenie sa. Vobec nevedia, ako sa pise efektivny a udrziavatelny softver.
-
Tiez suhlasim, veci co zvyknu vyplodit elektrikari a prirodvedci byvaju tak na obesenie sa. Vobec nevedia, ako sa pise efektivny a udrziavatelny softver.
Mám opačnou zkušenost. Profesionálním SW inženýrům často nejde o efektivní vyřešení úlohy, ale o honění si ega vymýšlením šílených abstrakcí. Nejlepší SW vytváří lidé se zájmem o vyřešení konkrétního problému.
-
Tiez suhlasim, veci co zvyknu vyplodit elektrikari a prirodvedci byvaju tak na obesenie sa. Vobec nevedia, ako sa pise efektivny a udrziavatelny softver.
Mám opačnou zkušenost. Profesionálním SW inženýrům často nejde o efektivní vyřešení úlohy, ale o honění si ega vymýšlením šílených abstrakcí. Nejlepší SW vytváří lidé se zájmem o vyřešení konkrétního problému.
Ak ma softver velkost vacsieho hello world, potom aj bastlici mozu spravit nieco zmysluplne. Tam nie je problem zahodit program a na 50-ty pokus to napisat dobre.
-
No tohle rozhodně neplatí obecně. Jamile nejste úplný mainstream typu Java, C#, .NET a podobně, zaměstnavatelé stále častěji preferují na pozice konzultanta/programátora lidi z oboru jejich businessu stejně jako zákazníci. Je totiž neskonale jednodušší naučit technicky/přirodovědně vzdělaného člověka programovat, než programátorovi vysvětlovat zákonitosti jejich businessu a procesů, které potřebují. Někde se s holým IT vzděláním a praxí vůbec nedostanete ani k pohovoru.
Naučit technicky vzdělaného člověka slušně programovat chce tak 3 roky studia teorie a dalších 5 let praktických zkušeností aby si vštípil dobré návyky a poznal, co je udržovatelné a co ne. Můžete uvést příklad nějakých "zákonitostí businessu a procesů", které programátor potřebuje studovat osm let, aby mohl v tom oboru slušně programovat?
Už jsem psal, že to jsou situace, kdy opravdu dává smysl aby to dělal ne-programátor. Typicky když se jedná o nějaké skriptování (menší projekty) kde programátor dělá sám a zadání si z velké části i sám vymýšlí. Ale osobně jsem se nikdy nesetkal s tím, že by se mnou nechtěl někdo spolupracovat, protože neznám dobře doménu.
-
preco by mali byt C# a JAVA mainstreamove? Mozte to vysvetlit? To skor javascript, css a html.
Asi byl myšlen backend a jazyky pro patlaly (s VM, GC...).
Pre patlaly? To vies aj nejako dolozit, alebo je to len tvoj subjektivny pocit?
To je principiálně objektivní pocit každého, kdo zažil lepší časy, kdy programátor programoval a patlal zametal ulice. Nikdo by nezaměstnal tesaře, který podprůměrně až průměrně odvádí svoji práci, ale není schopný si při práci uklidit a proto musí mít nonstop za zadkem uklízečku, protože bez ní by za chvilku zabordelil celou dílnu a znemožnil práci i ostatním. Za tesaře dosaď programátora, za uklízečku GC a máš to.
A jestli mi zase někdo řekne, že HW je zadarmo, tak si zkuste typické programátorské prasení:
Pořiďte si libovolný HW za mega, výběr nechám na vás, nainstalujte si na něj nějaké SQL, vytvořte v ní jeden sloupec typu TEXT s neurčenou délkou, naplňte ji náhodnými daty o velikosti 100GB a udělejte aplikaci, která z toho vyhledá a vypíše hodnoty dotazem obsahujícím LIKE %cosi%. Změřte si, jak dlouho to trvá, doplňte db opět náhodnými daty do velikosti 1TB a zkuste zjistit, kolik vás bude stát HW, aby to bylo stejně rychlé.
Zdá se vám to ujetý? Ne, to je hodně růžová realita. V horším případě tam těch tabulek bude 100 a výběr bude tak 20 JOINů a 15 vnořených selectů, z nichž jich několik bude obsahovat podobný LIKE. A až to všechno vyzkoušíte a vymyslíte, tak potom mi řekněte, jestli by náááááhodou nebylo levnější, to od začátku napsat normálně a optimalizovaně.
-
Aha takze ten co robi v Cecku nie je patlal, lebo nema za sebou GC ako upratovacku. A potom su same memoryleaky...
A preco by mal byt C# programator podpriemerny? Nemoze to iste platit o assembler programatorovi alebo Ceckarovi? Taketo kecy mi vedia vzdy vycarovat usmev na tvary a zaroven aj nasrat
-
A jestli mi zase někdo řekne, že HW je zadarmo, tak si zkuste typické programátorské prasení:
Pořiďte si libovolný HW za mega, výběr nechám na vás, nainstalujte si na něj nějaké SQL, vytvořte v ní jeden sloupec typu TEXT s neurčenou délkou, naplňte ji náhodnými daty o velikosti 100GB a udělejte aplikaci, která z toho vyhledá a vypíše hodnoty dotazem obsahujícím LIKE %cosi%. Změřte si, jak dlouho to trvá, doplňte db opět náhodnými daty do velikosti 1TB a zkuste zjistit, kolik vás bude stát HW, aby to bylo stejně rychlé.
Zdá se vám to ujetý? Ne, to je hodně růžová realita. V horším případě tam těch tabulek bude 100 a výběr bude tak 20 JOINů a 15 vnořených selectů, z nichž jich několik bude obsahovat podobný LIKE. A až to všechno vyzkoušíte a vymyslíte, tak potom mi řekněte, jestli by náááááhodou nebylo levnější, to od začátku napsat normálně a optimalizovaně.
To jsou nepodstatné detaily. Důležité je, že čtverec je potomek obdelníka a ne naopak.
-
To jsou nepodstatné detaily. Důležité je, že čtverec je potomek obdelníka a ne naopak.
No... kéž by... on totiž čtverec může být se správnou aproximací i potomkem kružnice a ta může být nafouknutým potomkem bodu... hlavně že to nějak vyjde, ne?
-
Aha takze ten co robi v Cecku nie je patlal, lebo nema za sebou GC ako upratovacku. A potom su same memoryleaky...
A preco by mal byt C# programator podpriemerny? Nemoze to iste platit o assembler programatorovi alebo Ceckarovi? Taketo kecy mi vedia vzdy vycarovat usmev na tvary a zaroven aj nasrat
To by byl pěkný argument, kdyby ty memory leaky nešly vyrobit navzdory GC... ale proti všem předpokladům to lze. Mně zase pokaždé spolehlivě nakaká každej, kdo se bez GC ani nevykaká, protože... proč vlastně? Protože je to normální? Ano, je. Ale to neznamená, že je to dobře. To znamená, že to vyhovuje dostatečně velké skupině lidí. Ale neříká to absolutně nic o kvalitě té skupiny.
-
Ale máte pravdu, čeština upadá už nejméně 80 let. Nejkrásnější byla tak kolem roku 1930.
Nicemu to nevadi, jazyk se musi vyvijet. Podivejte se na nejhorsi variantu cestiny vubec a pritom ji Slovaci stale pouzivaji.
Vyvíjet neznamená degenerovat.
Degenerace je taky vyvoj.
-
preco by mali byt C# a JAVA mainstreamove? Mozte to vysvetlit? To skor javascript, css a html.
Asi byl myšlen backend a jazyky pro patlaly (s VM, GC...).
Pre patlaly? To vies aj nejako dolozit, alebo je to len tvoj subjektivny pocit?
To je principiálně objektivní pocit každého, kdo zažil lepší časy, kdy programátor programoval a patlal zametal ulice. Nikdo by nezaměstnal tesaře, který podprůměrně až průměrně odvádí svoji práci, ale není schopný si při práci uklidit a proto musí mít nonstop za zadkem uklízečku, protože bez ní by za chvilku zabordelil celou dílnu a znemožnil práci i ostatním. Za tesaře dosaď programátora, za uklízečku GC a máš to.
A jestli mi zase někdo řekne, že HW je zadarmo, tak si zkuste typické programátorské prasení:
Pořiďte si libovolný HW za mega, výběr nechám na vás, nainstalujte si na něj nějaké SQL, vytvořte v ní jeden sloupec typu TEXT s neurčenou délkou, naplňte ji náhodnými daty o velikosti 100GB a udělejte aplikaci, která z toho vyhledá a vypíše hodnoty dotazem obsahujícím LIKE %cosi%. Změřte si, jak dlouho to trvá, doplňte db opět náhodnými daty do velikosti 1TB a zkuste zjistit, kolik vás bude stát HW, aby to bylo stejně rychlé.
Zdá se vám to ujetý? Ne, to je hodně růžová realita. V horším případě tam těch tabulek bude 100 a výběr bude tak 20 JOINů a 15 vnořených selectů, z nichž jich několik bude obsahovat podobný LIKE. A až to všechno vyzkoušíte a vymyslíte, tak potom mi řekněte, jestli by náááááhodou nebylo levnější, to od začátku napsat normálně a optimalizovaně.
Tento příspěvek by mohl kandidovat na "příspěvek roku", přesně vystihuje největší problém dnešního IT.
-
To jsou nepodstatné detaily. Důležité je, že čtverec je potomek obdelníka a ne naopak.
No... kéž by... on totiž čtverec může být se správnou aproximací i potomkem kružnice a ta může být nafouknutým potomkem bodu... hlavně že to nějak vyjde, ne?
V topologii ano. Ostatně právě proto je celé OOP - slovy klasika - "fraught endeavor" a ve většině případů spíše kontraproduktivní.
-
GC není na škodu.
GC je vrstva abstrakce.
Samozřejmě, v real time nebo embedded vývoji, který je často real time, není možné plošně nějaké GC použít protože latence a nebo nedostatek paměti.
Vůbec to ale neznamená že programátor dělající bez GC je lepší než ten s GC.
Naopak, některé systémy ani bez GC běžet nebudou protože životnost paměti je nepredikovatelná v době kompilace či návrhu systemu.
-
vysoké školy neprodukují kvalitní programátory. Ani střední odborné. To co příjde ze škol je odpad. Nesoustředění, těkaví lepïči kodu, u kterých ani nevíte jestli zítra do práce vůbec příjdou.
Stále více lidí programuje i když neměli žadné IT vzdělání, protože programátoři prostě chybí a jsou stále více dobře placení. Ovšem tito lidé už jsou většinou aspoň ve střední věku, 30-40 let.
Zájem u mladých o programování a IT všeobecně? Ano, jejich zájem začíná a končí tam kde jsou sociální sítě. Samozřejmě existují vyjímky, které potvrzují pravidlo.
Stále více a více je tedy programátorská sféra zaplněná hobbyisty, kteří jsou dobří, ale není jich nekonečno. Tudíž co bude v budoucnu? Budem dováže Indy, kde je opravdu neskutečný boom v programátorech? Nebo jak to vidíte vy, kteří už jste v praxi nějaký ten pátek?
Ne, za pár let se programátoři na trhu zežerou. Bude jich moc.
-
Aha takze ten co robi v Cecku nie je patlal, lebo nema za sebou GC ako upratovacku. A potom su same memoryleaky...
A preco by mal byt C# programator podpriemerny? Nemoze to iste platit o assembler programatorovi alebo Ceckarovi? Taketo kecy mi vedia vzdy vycarovat usmev na tvary a zaroven aj nasrat
To by byl pěkný argument, kdyby ty memory leaky nešly vyrobit navzdory GC... ale proti všem předpokladům to lze. Mně zase pokaždé spolehlivě nakaká každej, kdo se bez GC ani nevykaká, protože... proč vlastně? Protože je to normální? Ano, je. Ale to neznamená, že je to dobře. To znamená, že to vyhovuje dostatečně velké skupině lidí. Ale neříká to absolutně nic o kvalitě té skupiny.
To iste plati aj opacne
-
To iste plati aj opacne
Kupodivu to neplatí, protože člověk programující bez GC si ani neškrtne, pokud není schopnej ošetřit vlastní bordel, zatímco ten s GC to schová dostatečně na to, aby to bylo "tak nějak stable" a dalo se to i prodávat.
-
Naopak, některé systémy ani bez GC běžet nebudou protože životnost paměti je nepredikovatelná v době kompilace či návrhu systemu.
To je opodstatněné jen v krajních případech, většinou je to prostě chyba návrhu, protože v bussiness inteligence, což je většina dnešního programování, by k tomu nemělo nikdy dojít.
-
Mám-li mluvit za sebe, se obávám, že za pár let nebudu zaměstnatelný z důvodu, že prostě budu moc drahý a překvalifikovaný (obor zájmu C++/Python).
-
Me prijde ze problem neni jen v lidech - podle me sou lidi porad stejni - a rozhodne to neni jen problem nejakeho GC a uklidu bordelu po sobe - to by bylo hodne kratkozrake - to je proste jenom vedlejsi efekt daleko sirsiho problemu. Podivejte se na programatory takto: co se po nich vsechno chce, za jaky cas a co je pro ne hlavni motivaci a pridejme si ty spatne vlastnosti kterymi kazdy oplyvame a trh prace a je pomerne jasne co s toho asi muze vzniknout ... dabel je v detailu - problem je ze na detail nema nikdo prostor - narazim na to denne. A s toho potom vznikaji vsechny ty nastroje na to delat tyhle veci "efektivneji" a uz se tocime v kruhu. A otazka je jestli to je spatne - proste evoluce ... vsadim se ze starejch programatoru bylo nebe modrejsi a trava zelenejsi ... prdlajs.
-
Me prijde ze problem neni jen v lidech - podle me sou lidi porad stejni - a rozhodne to neni jen problem nejakeho GC a uklidu bordelu po sobe - to by bylo hodne kratkozrake - to je proste jenom vedlejsi efekt daleko sirsiho problemu. Podivejte se na programatory takto: co se po nich vsechno chce, za jaky cas a co je pro ne hlavni motivaci a pridejme si ty spatne vlastnosti kterymi kazdy oplyvame a trh prace a je pomerne jasne co s toho asi muze vzniknout ... dabel je v detailu - problem je ze na detail nema nikdo prostor - narazim na to denne. A s toho potom vznikaji vsechny ty nastroje na to delat tyhle veci "efektivneji" a uz se tocime v kruhu. A otazka je jestli to je spatne - proste evoluce ... vsadim se ze starejch programatoru bylo nebe modrejsi a trava zelenejsi ... prdlajs.
Neviditelná ruka trhu si to přebere, ostatně proto je tady tolik deprimivaných lůzrů, není-liž pravda? S tím kruhem to je svatá pravda, nástroj pro zvýšení efektivity jen přitáhne ty podprůměrné a už to jede. Na druhou stranu jak říkám, pokud si to trh přebere, efektivitu to v konečném důsledku zvýší.
-
Me prijde ze problem neni jen v lidech - podle me sou lidi porad stejni - a rozhodne to neni jen problem nejakeho GC a uklidu bordelu po sobe - to by bylo hodne kratkozrake - to je proste jenom vedlejsi efekt daleko sirsiho problemu. Podivejte se na programatory takto: co se po nich vsechno chce, za jaky cas a co je pro ne hlavni motivaci a pridejme si ty spatne vlastnosti kterymi kazdy oplyvame a trh prace a je pomerne jasne co s toho asi muze vzniknout ... dabel je v detailu - problem je ze na detail nema nikdo prostor - narazim na to denne. A s toho potom vznikaji vsechny ty nastroje na to delat tyhle veci "efektivneji" a uz se tocime v kruhu. A otazka je jestli to je spatne - proste evoluce ... vsadim se ze starejch programatoru bylo nebe modrejsi a trava zelenejsi ... prdlajs.
Nejzásadnější rozdíl je internet. Dokud nebyl, nebo byl dostupný omezeně, programátor se naučil základy, prohlídl pár dostupných zdrojáků a začal něco dělat. Když nevěděl, musel se zamyslet, jak problém vyřešit, vzít referenční příručku, pohledat vhodné příkazy a poskládat je do funkčního celku. V tu chvíli většinou musel vědět co a proč dělá. Dneska kolikrát chybí jakákoliv představivost, jakákoliv logika, napíšu do googlu co chci, zjistím, že je na to knihovna, stáhnu, použiju z ní jeden příkaz (i když už jsem tam předtím přidal 10 jiných knihoven, který to umí taky, jen mi to google neřekl na prvních třech místech) a jupí, přesuneme se o krok dál. Kolikrát už to padlo i ve fóru na rootu... potřebuji kravinu a nevím jak... 5 řádků kódu... a řešení? To umí ten framwework a tamten a tahle knihovna a jinej jazyk a... sorry jako...
-
Me prijde ze problem neni jen v lidech - podle me sou lidi porad stejni - a rozhodne to neni jen problem nejakeho GC a uklidu bordelu po sobe - to by bylo hodne kratkozrake - to je proste jenom vedlejsi efekt daleko sirsiho problemu. Podivejte se na programatory takto: co se po nich vsechno chce, za jaky cas a co je pro ne hlavni motivaci a pridejme si ty spatne vlastnosti kterymi kazdy oplyvame a trh prace a je pomerne jasne co s toho asi muze vzniknout ... dabel je v detailu - problem je ze na detail nema nikdo prostor - narazim na to denne. A s toho potom vznikaji vsechny ty nastroje na to delat tyhle veci "efektivneji" a uz se tocime v kruhu. A otazka je jestli to je spatne - proste evoluce ... vsadim se ze starejch programatoru bylo nebe modrejsi a trava zelenejsi ... prdlajs.
Problem vidim najme vo fragmentaci platforiem a potreby implementovat softver do kazdej blbosti. Kazdy druhy frikulin si vymysli nejaky protokol a framework, mame zastupy programatorov, ktori potom vedia vela a zaroven nic. Teraz je problem umocneny roznymi smart a IOT kravinkami. Zamestnavatelia su niektori tiez ujebani, nejdu po velkych platformach, ale pozaduju funkcinalne orientovany eiffel s embedded pythonom.
Potom sa tu vykopavky z cias stazuju, ze nikto neovlada C++. No jasne, ze neovlada, lebo v tom nikto nekodi a nikdo to skoro nevyzaduje. (Mimochodom, je to aj zly jazyk ale o tom potom)
-
Me prijde ze problem neni jen v lidech - podle me sou lidi porad stejni - a rozhodne to neni jen problem nejakeho GC a uklidu bordelu po sobe - to by bylo hodne kratkozrake - to je proste jenom vedlejsi efekt daleko sirsiho problemu. Podivejte se na programatory takto: co se po nich vsechno chce, za jaky cas a co je pro ne hlavni motivaci a pridejme si ty spatne vlastnosti kterymi kazdy oplyvame a trh prace a je pomerne jasne co s toho asi muze vzniknout ... dabel je v detailu - problem je ze na detail nema nikdo prostor - narazim na to denne. A s toho potom vznikaji vsechny ty nastroje na to delat tyhle veci "efektivneji" a uz se tocime v kruhu. A otazka je jestli to je spatne - proste evoluce ... vsadim se ze starejch programatoru bylo nebe modrejsi a trava zelenejsi ... prdlajs.
Problem vidim najme vo fragmentaci platforiem a potreby implementovat softver do kazdej blbosti. Kazdy druhy frikulin si vymysli nejaky protokol a framework, mame zastupy programatorov, ktori potom vedia vela a zaroven nic. Teraz je problem umocneny roznymi smart a IOT kravinkami. Zamestnavatelia su niektori tiez ujebani, nejdu po velkych platformach, ale pozaduju funkcinalne orientovany eiffel s embedded pythonom.
Potom sa tu vykopavky z cias stazuju, ze nikto neovlada C++. No jasne, ze neovlada, lebo v tom nikto nekodi a nikdo to skoro nevyzaduje. (Mimochodom, je to aj zly jazyk ale o tom potom)
C++ už dávno chcíplo, nemá budoucnost (pro casual developera !!!)
na embed je C
a zbytek už je zmigrovanej na javu nebo c#
-
Tento příspěvek by mohl kandidovat na "příspěvek roku", přesně vystihuje největší problém dnešního IT.
Skor na blabol roku.
-
Naopak, některé systémy ani bez GC běžet nebudou protože životnost paměti je nepredikovatelná v době kompilace či návrhu systemu.
To je opodstatněné jen v krajních případech, většinou je to prostě chyba návrhu, protože v bussiness inteligence, což je většina dnešního programování, by k tomu nemělo nikdy dojít.
obecně vzato, třeba FP je celí takový ten krajní případ
OOP to samé
ne že by to bez něj nešlo, ale pokud ho chceme dělat tak jak bylo zamýšleno, tak s ručním managementem by ses posral
je fajn umět v cčku něco udělat bez něj, ale není to must have v dnešní době řekl bych
dneska se jede hodně high level, jinak to ani nejde při těch požadavcích
-
Naopak, některé systémy ani bez GC běžet nebudou protože životnost paměti je nepredikovatelná v době kompilace či návrhu systemu.
To je opodstatněné jen v krajních případech, většinou je to prostě chyba návrhu, protože v bussiness inteligence, což je většina dnešního programování, by k tomu nemělo nikdy dojít.
Á, pán je fajnšmekr, zřejmě se děsně vyžívá v řízení zdrojů a ošetřování uvolňování při chybách/výjimkách, je hrozně rád, když mu tahle legrace zabírá čtvrtinu délky funkcí a samozřejmě se v tom nikdy nesekne. A o FP asi neslyšel, protože v pure funkcích se jaksi nedá nic "dělat", natož nějak řídit dealokace...
-
S tou pamětí je to syndrom Sinclairisty, už v té době, na normálních mašinách běželo stránkování paměti a spoléhalo se při přidělování paměti na předem dané algoritmy, které byly součástí operačního systému. S požadavkem přenositelnosti se správa paměti přestěhovala logicky do runtimu jazyka a vzniklo GC. S kvalitou programátorů to nemá nic společného.
-
2čumil 2andy: že se používá OOP a FP neznamená, že je to správně. Znamená to, že je jednoduché na to sehnat lidi, kteří v tom udělají, co je třeba a to především proto, že je to jednoduché a naučí se to i cvičená opice za bednu banánů.
-
Me prijde ze problem neni jen v lidech - podle me sou lidi porad stejni - a rozhodne to neni jen problem nejakeho GC a uklidu bordelu po sobe - to by bylo hodne kratkozrake - to je proste jenom vedlejsi efekt daleko sirsiho problemu. Podivejte se na programatory takto: co se po nich vsechno chce, za jaky cas a co je pro ne hlavni motivaci a pridejme si ty spatne vlastnosti kterymi kazdy oplyvame a trh prace a je pomerne jasne co s toho asi muze vzniknout ... dabel je v detailu - problem je ze na detail nema nikdo prostor - narazim na to denne. A s toho potom vznikaji vsechny ty nastroje na to delat tyhle veci "efektivneji" a uz se tocime v kruhu. A otazka je jestli to je spatne - proste evoluce ... vsadim se ze starejch programatoru bylo nebe modrejsi a trava zelenejsi ... prdlajs.
Neviditelná ruka trhu si to přebere, ostatně proto je tady tolik deprimivaných lůzrů, není-liž pravda? S tím kruhem to je svatá pravda, nástroj pro zvýšení efektivity jen přitáhne ty podprůměrné a už to jede. Na druhou stranu jak říkám, pokud si to trh přebere, efektivitu to v konečném důsledku zvýší.
Jenže nebe opravdu bylo modřejší a tráva zelenější. Důvod je ten, že ta neviditelná ruka trhu slouží k optimalizaci zisků, ne kvality. A za současných podmínek je snadnější toho dosáhnout kvantitou a rychlostí než kvalitou. Je to asi podobné, jako když "za starých časů" každý kuchař musel opravdu umět vařit, zatímco dnes je požadavek v první řadě nějak a co nejrychleji nasytit, tj. fastfood metoda a jídelny. Copak se v mekáčích najde v personálu někdo, kdo umí vařit? Jen vám poskládá předraženou obloženou housku, jejímž pravidelným požíváním si akorát přivodíte zdravotní problémy, které zas bude muset řešit nějaký jiný úzce profilovaný specialista. Za další peníze.
Tohle je současné IT. Většina IT byznysu je založena na řešení problémů, které vznikly jen snahou ušetřit čas a peníze. Jako v tom filmu Srdečný pozdrav ze Zeměkoule: "Nejvyšší formou rozumné činnosti na Zemi je vědecké sympózium. Řeší škodlivé následky prospěšné vědecké činnosti."
Řekl bych, že problém není ani tak sehnat dobrého vývojáře, jako dobrého manažera. Většina z nich má totiž akorát nadrcené nějaké přiblblé poučky a hesla, nad jejichž aplikovatelností vůbec nepřemýšlí. Takže jejich typické úvahy jsou ve stylu "jedna ženská porodí dítě za 9 měsíců, když jich tedy najmeme 9, budeme mít první dítě už za měsíc". Pak na nějakém školení přijde nějaký mamrd s tím, že když by se jich najímalo 10, bude dítě hned. A podle toho pak ty projekty vypadají. Přitom už někdy v 70. letech se přišlo na to, že "adding manpower to a late software project makes it later".
Ale jsem optimista. Až se daný segment nasytí kvantitou, tak se snad půjde po kvalitě. Momentálně jsme na vlně, kdy je hlad po nástrojích, jež umožňují zaměstnat v IT i cvičenou opici.
Mimochodem:
https://www.youtube.com/watch?v=NdSD07U5uBs
-
https://www.youtube.com/watch?v=ubaX1Smg6pY
-
Me prijde ze problem neni jen v lidech - podle me sou lidi porad stejni - a rozhodne to neni jen problem nejakeho GC a uklidu bordelu po sobe - to by bylo hodne kratkozrake - to je proste jenom vedlejsi efekt daleko sirsiho problemu. Podivejte se na programatory takto: co se po nich vsechno chce, za jaky cas a co je pro ne hlavni motivaci a pridejme si ty spatne vlastnosti kterymi kazdy oplyvame a trh prace a je pomerne jasne co s toho asi muze vzniknout ... dabel je v detailu - problem je ze na detail nema nikdo prostor - narazim na to denne. A s toho potom vznikaji vsechny ty nastroje na to delat tyhle veci "efektivneji" a uz se tocime v kruhu. A otazka je jestli to je spatne - proste evoluce ... vsadim se ze starejch programatoru bylo nebe modrejsi a trava zelenejsi ... prdlajs.
Neviditelná ruka trhu si to přebere, ostatně proto je tady tolik deprimivaných lůzrů, není-liž pravda? S tím kruhem to je svatá pravda, nástroj pro zvýšení efektivity jen přitáhne ty podprůměrné a už to jede. Na druhou stranu jak říkám, pokud si to trh přebere, efektivitu to v konečném důsledku zvýší.
Jenže nebe opravdu bylo modřejší a tráva zelenější. Důvod je ten, že ta neviditelná ruka trhu slouží k optimalizaci zisků, ne kvality. A za současných podmínek je snadnější toho dosáhnout kvantitou a rychlostí než kvalitou. Je to asi podobné, jako když "za starých časů" každý kuchař musel opravdu umět vařit, zatímco dnes je požadavek v první řadě nějak a co nejrychleji nasytit, tj. fastfood metoda a jídelny. Copak se v mekáčích najde v personálu někdo, kdo umí vařit? Jen vám poskládá předraženou obloženou housku, jejímž pravidelným požíváním si akorát přivodíte zdravotní problémy, které zas bude muset řešit nějaký jiný úzce profilovaný specialista. Za další peníze.
Tohle je současné IT. Většina IT byznysu je založena na řešení problémů, které vznikly jen snahou ušetřit čas a peníze. Jako v tom filmu Srdečný pozdrav ze Zeměkoule: "Nejvyšší formou rozumné činnosti na Zemi je vědecké sympózium. Řeší škodlivé následky prospěšné vědecké činnosti."
Řekl bych, že problém není ani tak sehnat dobrého vývojáře, jako dobrého manažera. Většina z nich má totiž akorát nadrcené nějaké přiblblé poučky a hesla, nad jejichž aplikovatelností vůbec nepřemýšlí. Takže jejich typické úvahy jsou ve stylu "jedna ženská porodí dítě za 9 měsíců, když jich tedy najmeme 9, budeme mít první dítě už za měsíc". Pak na nějakém školení přijde nějaký mamrd s tím, že když by se jich najímalo 10, bude dítě hned. A podle toho pak ty projekty vypadají. Přitom už někdy v 70. letech se přišlo na to, že "adding manpower to a late software project makes it later".
Ale jsem optimista. Až se daný segment nasytí kvantitou, tak se snad půjde po kvalitě. Momentálně jsme na vlně, kdy je hlad po nástrojích, jež umožňují zaměstnat v IT i cvičenou opici.
Mimochodem:
https://www.youtube.com/watch?v=NdSD07U5uBs
Výstižné ;D
-
... Dneska kolikrát chybí ...
To co chybi je predevsim mozek ... zrovna dneska sem resil s dodavatelem vykon ... a on mi ukazoval "novou verzi" ... kdyz sem se ho ptal, proc je to pomaly jak svin ... tak rek proto, ze holt soudruzi v emerice pouzili nejakej khuull frejmwork, kterej s 10 zaznamama v databazi i funguje. Kdyz je v ty databazi tech zaznamu 1/2M ... tak to sezere behem asi 5 minut (coz je odezva toho celyho) skorem 2GB ram browseru ... protoze ti curaci (premejslim o nejakym jeste horsim prizvisku) to proste cely generujou jako html (komplet tech 1/2M zaznamu) aby to pak dzavascrajptem ... vsechno schovali ... a zobrazili pozadovanych 10 zaznamu.
-
S tou pamětí je to syndrom Sinclairisty,...
A Nový je syndromem čeho?
-
2čumil 2andy: že se používá OOP a FP neznamená, že je to správně. Znamená to, že je jednoduché na to sehnat lidi, kteří v tom udělají, co je třeba a to především proto, že je to jednoduché a naučí se to i cvičená opice za bednu banánů.
Ani nie. Take tvrdia len ludia, co to neovladaju. V skutocnosti dobre vediet OOP a FP chce poriadne zrucnosti a vedomosti. Tak ako vo vsetkom ostatnom.
Aj ja viem prasit v thumb2 instrukcnej sade pre ARM a zaklady je celkom lahke sa naucit. No netvrdim nezmysly o opiciach a bedniach bananov.
-
2čumil 2andy: že se používá OOP a FP neznamená, že je to správně. Znamená to, že je jednoduché na to sehnat lidi, kteří v tom udělají, co je třeba a to především proto, že je to jednoduché a naučí se to i cvičená opice za bednu banánů.
Jasně, tady je fakt spousta lidí, co zvládá FP, protože je to tak děsně jednoduché....
-
2čumil 2andy: že se používá OOP a FP neznamená, že je to správně. Znamená to, že je jednoduché na to sehnat lidi, kteří v tom udělají, co je třeba a to především proto, že je to jednoduché a naučí se to i cvičená opice za bednu banánů.
Jasně, tady je fakt spousta lidí, co zvládá FP, protože je to tak děsně jednoduché....
FP je pro psaní efektivního kódu jednoduché z mnoha důvodů, složitější je napsat funkční interpretr/překladač pro FP.
-
2čumil 2andy: že se používá OOP a FP neznamená, že je to správně. Znamená to, že je jednoduché na to sehnat lidi, kteří v tom udělají, co je třeba a to především proto, že je to jednoduché a naučí se to i cvičená opice za bednu banánů.
Jasně, tady je fakt spousta lidí, co zvládá FP, protože je to tak děsně jednoduché....
FP je pro psaní efektivního kódu jednoduché z mnoha důvodů, složitější je napsat funkční interpretr/překladač pro FP.
Když někdo umí hrát na housle, tak to taky vypadá jednoduše....
-
Nikdo by nezaměstnal tesaře, který podprůměrně až průměrně odvádí svoji práci, ale není schopný si při práci uklidit a proto musí mít nonstop za zadkem uklízečku, protože bez ní by za chvilku zabordelil celou dílnu a znemožnil práci i ostatním. Za tesaře dosaď programátora, za uklízečku GC a máš to.
+1. Já bych zase nikdy nezaměstnal „programátora“, který nedokáže psát strojový kód v hexaeditoru, ale furt chce mít za zadkem assembler nebo dokonce kompilátor céčka!!!
-
Me prijde ze problem neni jen v lidech - podle me sou lidi porad stejni - a rozhodne to neni jen problem nejakeho GC a uklidu bordelu po sobe - to by bylo hodne kratkozrake - to je proste jenom vedlejsi efekt daleko sirsiho problemu. Podivejte se na programatory takto: co se po nich vsechno chce, za jaky cas a co je pro ne hlavni motivaci a pridejme si ty spatne vlastnosti kterymi kazdy oplyvame a trh prace a je pomerne jasne co s toho asi muze vzniknout ... dabel je v detailu - problem je ze na detail nema nikdo prostor - narazim na to denne. A s toho potom vznikaji vsechny ty nastroje na to delat tyhle veci "efektivneji" a uz se tocime v kruhu. A otazka je jestli to je spatne - proste evoluce ... vsadim se ze starejch programatoru bylo nebe modrejsi a trava zelenejsi ... prdlajs.
Neviditelná ruka trhu si to přebere, ostatně proto je tady tolik deprimivaných lůzrů, není-liž pravda? S tím kruhem to je svatá pravda, nástroj pro zvýšení efektivity jen přitáhne ty podprůměrné a už to jede. Na druhou stranu jak říkám, pokud si to trh přebere, efektivitu to v konečném důsledku zvýší.
Jenže nebe opravdu bylo modřejší a tráva zelenější. Důvod je ten, že ta neviditelná ruka trhu slouží k optimalizaci zisků, ne kvality. A za současných podmínek je snadnější toho dosáhnout kvantitou a rychlostí než kvalitou. Je to asi podobné, jako když "za starých časů" každý kuchař musel opravdu umět vařit, zatímco dnes je požadavek v první řadě nějak a co nejrychleji nasytit, tj. fastfood metoda a jídelny. Copak se v mekáčích najde v personálu někdo, kdo umí vařit? Jen vám poskládá předraženou obloženou housku, jejímž pravidelným požíváním si akorát přivodíte zdravotní problémy, které zas bude muset řešit nějaký jiný úzce profilovaný specialista. Za další peníze.
Tohle je současné IT. Většina IT byznysu je založena na řešení problémů, které vznikly jen snahou ušetřit čas a peníze. Jako v tom filmu Srdečný pozdrav ze Zeměkoule: "Nejvyšší formou rozumné činnosti na Zemi je vědecké sympózium. Řeší škodlivé následky prospěšné vědecké činnosti."
Řekl bych, že problém není ani tak sehnat dobrého vývojáře, jako dobrého manažera. Většina z nich má totiž akorát nadrcené nějaké přiblblé poučky a hesla, nad jejichž aplikovatelností vůbec nepřemýšlí. Takže jejich typické úvahy jsou ve stylu "jedna ženská porodí dítě za 9 měsíců, když jich tedy najmeme 9, budeme mít první dítě už za měsíc". Pak na nějakém školení přijde nějaký mamrd s tím, že když by se jich najímalo 10, bude dítě hned. A podle toho pak ty projekty vypadají. Přitom už někdy v 70. letech se přišlo na to, že "adding manpower to a late software project makes it later".
Ale jsem optimista. Až se daný segment nasytí kvantitou, tak se snad půjde po kvalitě. Momentálně jsme na vlně, kdy je hlad po nástrojích, jež umožňují zaměstnat v IT i cvičenou opici.
Mimochodem:
https://www.youtube.com/watch?v=NdSD07U5uBs
Výstižné ;D
Hloupé. My nevíme jaká kvalita je optimální. To hledá vzhledem k aktuálnímu stavu systému trh. Příliš kvality může škodit, alokuje se zbytečně mnoho zdrojů do nějakého projektu, který stejně zapadne, protože bude nepotřebný, nebude po něm poptávka. Například.
-
Je až s podivem, kolik lidí se tu věnuje natolik komplikovaným věcem, že bez často zbytečných berliček je podle nich nemožné, nebo neúnosně náročné, je vůbec zprovoznit. Otázkou je, jestli je to vždy komplexností daného problému. Přitom si troufnu tvrdit, že většina "programátorů" nezná ani polovinu standardních knihoven svého jazyka. A znalostí nemyslím odříkání příkazů se syntaxí, tím myslím alespoň tušení, co tam všechno je a co by se tak mohlo dát použít v konkrétním případě. O znalosti platformy nemá vůbec cenu mluvit. Ale uvědomte si pánové, o kolik se za posledních 10 let zvednul výkon na jádro? O prd. Zachraňuje to enormní nárůst paměti, rychlý úložiště a zvyšování počtu jader, ale to není relevantní pro všechny případy. Navíc tam, kde to mělo smysl, tam byly už dřív jiný platformy než x86. In memory computing je starší, než většina přítomných, jenom to dřív nebylo možné s garážovým rozpočtem. A opět zopakuji... plýtvat prostředky, protože HW je zadarmo, je cesta do pekel, protože je velmi snadné s dnešními požadavky narazit na strop. Dost dobrý server pořídíte za mega, 2x rychlejší už možná nepořídíte vůbec, a musíte jít do HPC. Ale pokud není aplikace od začátku napsaná s důrazem na škálovatelnost (a to většinou není), tak je vám HPC k ničemu a nezbývá, než začít znovu a lépe. A chci vidět, kolik z těch super programátorů zvládne svoji dokonale čitelně napsanou a vysoce abstraktní aplikaci jednoduše upravit při zachování rozumných nákladů. V praxi se to limitně blíží nule a je většinou výhodnější pořídit jiný SW od někoho jiného, i kdyby to měl napsat na zelené louce.
-
To iste plati aj opacne
Kupodivu to neplatí, protože člověk programující bez GC si ani neškrtne, pokud není schopnej ošetřit vlastní bordel, zatímco ten s GC to schová dostatečně na to, aby to bylo "tak nějak stable" a dalo se to i prodávat.
tak, ako sa da naprogramovat zle v C#, da sa aj v C/C++. Ja nevidim ziadnu spojitost medzi tym, ze C -> lepsi vyvojar, C# -> horsi vyvojar. To je pausalizacia. Co som videl kod po C++ vyvojaroch, tak ani citat sa nedal.
-
Je až s podivem, kolik lidí se tu věnuje natolik komplikovaným věcem, že bez často zbytečných berliček je podle nich nemožné, nebo neúnosně náročné, je vůbec zprovoznit.
Jojo, kritik je ten, který říká, jak by to dělal, kdyby to uměl...
Mimochodem, předpokládám, že programátoři by taky neměli používat SQL, protože ručně psaná a na konkrétní úkol optimalizovaná databáze je samozřejmě rychlejší....
-
Je až s podivem, kolik lidí se tu věnuje natolik komplikovaným věcem, že bez často zbytečných berliček je podle nich nemožné, nebo neúnosně náročné, je vůbec zprovoznit. Otázkou je, jestli je to vždy komplexností daného problému. Přitom si troufnu tvrdit, že většina "programátorů" nezná ani polovinu standardních knihoven svého jazyka. A znalostí nemyslím odříkání příkazů se syntaxí, tím myslím alespoň tušení, co tam všechno je a co by se tak mohlo dát použít v konkrétním případě. O znalosti platformy nemá vůbec cenu mluvit. Ale uvědomte si pánové, o kolik se za posledních 10 let zvednul výkon na jádro? O prd. Zachraňuje to enormní nárůst paměti, rychlý úložiště a zvyšování počtu jader, ale to není relevantní pro všechny případy. Navíc tam, kde to mělo smysl, tam byly už dřív jiný platformy než x86. In memory computing je starší, než většina přítomných, jenom to dřív nebylo možné s garážovým rozpočtem. A opět zopakuji... plýtvat prostředky, protože HW je zadarmo, je cesta do pekel, protože je velmi snadné s dnešními požadavky narazit na strop. Dost dobrý server pořídíte za mega, 2x rychlejší už možná nepořídíte vůbec, a musíte jít do HPC. Ale pokud není aplikace od začátku napsaná s důrazem na škálovatelnost (a to většinou není), tak je vám HPC k ničemu a nezbývá, než začít znovu a lépe. A chci vidět, kolik z těch super programátorů zvládne svoji dokonale čitelně napsanou a vysoce abstraktní aplikaci jednoduše upravit při zachování rozumných nákladů. V praxi se to limitně blíží nule a je většinou výhodnější pořídit jiný SW od někoho jiného, i kdyby to měl napsat na zelené louce.
Preto taki programatori, ktori vedia pouzivat abstrakcie a vedia aj pisat suboptimalny kod, maju 3x vacsie platy. (Suboptimalny som napisal naschval, optimum byva nedosiahnutelne).
-
Je až s podivem, kolik lidí se tu věnuje natolik komplikovaným věcem, že bez často zbytečných berliček je podle nich nemožné, nebo neúnosně náročné, je vůbec zprovoznit. Otázkou je, jestli je to vždy komplexností daného problému. Přitom si troufnu tvrdit, že většina "programátorů" nezná ani polovinu standardních knihoven svého jazyka. A znalostí nemyslím odříkání příkazů se syntaxí, tím myslím alespoň tušení, co tam všechno je a co by se tak mohlo dát použít v konkrétním případě. O znalosti platformy nemá vůbec cenu mluvit. Ale uvědomte si pánové, o kolik se za posledních 10 let zvednul výkon na jádro? O prd. Zachraňuje to enormní nárůst paměti, rychlý úložiště a zvyšování počtu jader, ale to není relevantní pro všechny případy. Navíc tam, kde to mělo smysl, tam byly už dřív jiný platformy než x86. In memory computing je starší, než většina přítomných, jenom to dřív nebylo možné s garážovým rozpočtem. A opět zopakuji... plýtvat prostředky, protože HW je zadarmo, je cesta do pekel, protože je velmi snadné s dnešními požadavky narazit na strop. Dost dobrý server pořídíte za mega, 2x rychlejší už možná nepořídíte vůbec, a musíte jít do HPC. Ale pokud není aplikace od začátku napsaná s důrazem na škálovatelnost (a to většinou není), tak je vám HPC k ničemu a nezbývá, než začít znovu a lépe. A chci vidět, kolik z těch super programátorů zvládne svoji dokonale čitelně napsanou a vysoce abstraktní aplikaci jednoduše upravit při zachování rozumných nákladů. V praxi se to limitně blíží nule a je většinou výhodnější pořídit jiný SW od někoho jiného, i kdyby to měl napsat na zelené louce.
vzdy je lacnejsie kupit zelezo, ako robit softver poriadne. zoberme si take statne institucie napojene na eurofondy. nejaka vopred urcena firma akoze vyhra tender. Ta to rozdeli medzi subdodavatelov a ti zas medzi subdodavatelov. V zavere to vyjde tak, ze na tom robia studenti niekde u sukromnika v garazi (bol to aj moj pripad) za par supov. Institucii resp. statu je jedno, ci to bude rychle alebo nebude. Obcania vyuzivajuci tento softver aj tak tomu nerozumeju, tak naco sa zaoberat nejakymi optimalizaciami? A takto sa potom mnozia ti pseudoprogramatori. Slovensky IT trh je tak nasiaknuty statnymi zakazkami. Kde sa maju ti studenti naucit lepsiemu programovaniu, ked nemaju nato ani poriadne prilezitost? Ked si to porovnam so zahranicim, tak je to 100 a 1.
-
To je pausalizacia. ...
To je realita, protoze spatne se da psat v obojim, jenze v tom Ccku se to projevi o poznani driv, takze tech patlalu v tom dela o poznani min.
... neměli používat SQL...
Vetsina tech, co si dneska rikaj programator, si mysli, ze nejlepsi zpusob pouziti SQL je select * from ... a presne podle toho vypadaj ty vysledky.
-
tak, ako sa da naprogramovat zle v C#, da sa aj v C/C++. Ja nevidim ziadnu spojitost medzi tym, ze C -> lepsi vyvojar, C# -> horsi vyvojar. To je pausalizacia. Co som videl kod po C++ vyvojaroch, tak ani citat sa nedal.
Schopnost číst a chápat zdrojový kód, byla vždy jedna ze základních a nejsložitějších dovedností dobrého a zkušeného programátora. Syntaxi se naučí i opice, ale proč by měli všichni psát tak, aby to po nich ta opice dokázala přečíst? Já netvrdím, že neexistují případy, kdy se hodí OOP, GC a já nevím, co všechno, já tvrdím, že se to velmi často používá zbytečně a nesmyslně jen proto, aby se to použilo. Pokud si chce někdo říkat programátor, chce za to dostávat pěkné peníze a dokonce se tím chce chlubit, měl by poznat, kdy je to vhodné a kdy ne. Ano, můžou za to zaměstnavatelé, kteří si najmou opice, narvou jim do hlavy trendy a buzzwordy a nechají je prasit bez hlušího kontextu, hlavně, že je to rychle a může se prasit něco dalšího. Kolik firem zaměstnává nějakého mentora, který je ochotný opicím vysvětlovat proč, jak, a je schopnej to i odůvodnit?
-
Budoucnost programování? Asi tak.
http://objevit.cz/umela-inteligence-od-microsoftu-umi-programovat-lepe-nez-clovek-t216644
-
Budoucnost programování? Asi tak.
http://objevit.cz/umela-inteligence-od-microsoftu-umi-programovat-lepe-nez-clovek-t216644
Objevit.cz vyzera ako klasicky postfaktualny bullshit :)
-
Jojo, kritik je ten, který říká, jak by to dělal, kdyby to uměl...
Kritik bohužel až příliš často řeší problémy za programátory, protože je mezi nimi spousta namyšlených idiotů, kteří neuznají svou chybu ani poté, co jim člověk píchne prstem do kódu a řekne jim, co je tam špatně.
Mimochodem, předpokládám, že programátoři by taky neměli používat SQL, protože ručně psaná a na konkrétní úkol optimalizovaná databáze je samozřejmě rychlejší....
Programátoři by neměli používat SQL na každou blbost a když už musí, bylo by dobré, vědět jak. Jejich přístup k databázím je dost často tragédie a ještě se hájí tím, že nejsou databázisti. To ale není můj problém, já jsem na straně zákazníka, který si od dodavatele koupil produkt, který databázi používá a vyžaduje. Jestli na to dodavatel nemá lidi není můj problém a že to nějakej programátor nad rámec svých znalostí zbastlil, mě nezajímá. Hlavně, že je tam 20 java opic, 10 manažerů a 5 ředitelů. Krásným příkladem - a nikoliv ojedinělým - je jedna "luxusní aplikace", která pro vypsání zaměstnance s pár detaily z DB (asi 15 polí) provede kolem 250 selectů! Až se takové pseudoprogramátorské firmě ucpou záchody, tak bych jim tam poslal opraváře s kladivem a svářečkou, ať si taky jednou užijí "profi práci" od ostatních.
-
To je pausalizacia. ...
To je realita, protoze spatne se da psat v obojim, jenze v tom Ccku se to projevi o poznani driv, takze tech patlalu v tom dela o poznani min.
mozno na embedded zariadeniach, kde sa pamat pohybuje radovo v kb. Ak by som nieco robil v C na stroji s 32gb RAM, tak myslim, ze to clovek nespozna
-
To je principiálně objektivní pocit každého, kdo zažil lepší časy, kdy programátor programoval a patlal zametal ulice. Nikdo by nezaměstnal tesaře, který podprůměrně až průměrně odvádí svoji práci, ale není schopný si při práci uklidit a proto musí mít nonstop za zadkem uklízečku, protože bez ní by za chvilku zabordelil celou dílnu a znemožnil práci i ostatním. Za tesaře dosaď programátora, za uklízečku GC a máš to.
Za tesaře dosaď programátora, za uklízečku kompilátor. Tak co, jsi pořádný programátor a datlíš program zásadně v hexa editoru, nebo patlal co potřebuje kompilátor?
A jestli mi zase někdo řekne, že HW je zadarmo, tak si zkuste typické programátorské prasení:
A co takhle:
- Protože v DB bude nanejvýš pár set řádek, programátor P klidně v dotazech použije LIKE. Práci má hotovou za hodinu.
- Programátor T v žádném případě nechce prasit, takže si hezky napíše vlastní fulltext engine. Sice se dostane do nějakých problémů s aktualizací indexu on-the-fly při insertech, ale už za dva měsíce má hotovo. Ve výsledku je jeho řešení o 1ms rychlejší, což, bohužel, uživatel nepozná.
Otázka za 10 bodů: Kterého programátora zaměstnavatel vyhodí, protože vyházel jeho peníze oknem?
Aneb jak říká staré programátorské přísloví, předčasná optimalizace je horší, než předčasná ejekulace.
-
Je až s podivem, kolik lidí se tu věnuje natolik komplikovaným věcem, že bez často zbytečných berliček je podle nich nemožné, nebo neúnosně náročné, je vůbec zprovoznit. Otázkou je, jestli je to vždy komplexností daného problému. Přitom si troufnu tvrdit, že většina "programátorů" nezná ani polovinu standardních knihoven svého jazyka. A znalostí nemyslím odříkání příkazů se syntaxí, tím myslím alespoň tušení, co tam všechno je a co by se tak mohlo dát použít v konkrétním případě. O znalosti platformy nemá vůbec cenu mluvit. Ale uvědomte si pánové, o kolik se za posledních 10 let zvednul výkon na jádro? O prd. Zachraňuje to enormní nárůst paměti, rychlý úložiště a zvyšování počtu jader, ale to není relevantní pro všechny případy. Navíc tam, kde to mělo smysl, tam byly už dřív jiný platformy než x86. In memory computing je starší, než většina přítomných, jenom to dřív nebylo možné s garážovým rozpočtem. A opět zopakuji... plýtvat prostředky, protože HW je zadarmo, je cesta do pekel, protože je velmi snadné s dnešními požadavky narazit na strop. Dost dobrý server pořídíte za mega, 2x rychlejší už možná nepořídíte vůbec, a musíte jít do HPC. Ale pokud není aplikace od začátku napsaná s důrazem na škálovatelnost (a to většinou není), tak je vám HPC k ničemu a nezbývá, než začít znovu a lépe. A chci vidět, kolik z těch super programátorů zvládne svoji dokonale čitelně napsanou a vysoce abstraktní aplikaci jednoduše upravit při zachování rozumných nákladů. V praxi se to limitně blíží nule a je většinou výhodnější pořídit jiný SW od někoho jiného, i kdyby to měl napsat na zelené louce.
Narazíte-li na strop stávajících možností, vymyslíte nové postupy odpovídající aktuální situaci. Stejně se bude muset změnit architektura hw, protože většinu úloh bude řešit AI a klasické zpracování dat odpadne. Nebude potřeba spoustu věcí explicitně vědět, protože je bude řešit AI bez našeho vědomí. Klasické databázové aplikace přestanou být potřeba. Informace budou ve formě člověkem neinterpretovatelných natrénovaných sítí. Půjde o black boxovou revoluci.
-
- Protože v DB bude nanejvýš pár set řádek, programátor P klidně v dotazech použije LIKE. Práci má hotovou za hodinu.
- Programátor T v žádném případě nechce prasit, takže si hezky napíše vlastní fulltext engine. Sice se dostane do nějakých problémů s aktualizací indexu on-the-fly při insertech, ale už za dva měsíce má hotovo. Ve výsledku je jeho řešení o 1ms rychlejší, což, bohužel, uživatel nepozná.
Otázka za 10 bodů: Kterého programátora zaměstnavatel vyhodí, protože vyházel jeho peníze oknem?
Aneb jak říká staré programátorské přísloví, předčasná optimalizace je horší, než předčasná ejekulace.
No a teď zpět do smutné reality... nikdo se neobtěžoval zákazníka zeptat, jaký očekává objem dat, proto bude mít testovací databáze opravdu pouze pár set řádků a všechno bude vypadat normálně.
A teď otázka za 11 bodů: Kvůli komu firma nedostane zakázku, když se při PoC nad reálnými daty budou 20 minut motat přesýpací hodiny?
-
tak ale to uz prehanate tuxiku :D
to som sa este nestretol s niecim takym. myslim, ze az tak tupi programatori nie su :D
-
- Protože v DB bude nanejvýš pár set řádek, programátor P klidně v dotazech použije LIKE. Práci má hotovou za hodinu.
- Programátor T v žádném případě nechce prasit, takže si hezky napíše vlastní fulltext engine. Sice se dostane do nějakých problémů s aktualizací indexu on-the-fly při insertech, ale už za dva měsíce má hotovo. Ve výsledku je jeho řešení o 1ms rychlejší, což, bohužel, uživatel nepozná.
Otázka za 10 bodů: Kterého programátora zaměstnavatel vyhodí, protože vyházel jeho peníze oknem?
Aneb jak říká staré programátorské přísloví, předčasná optimalizace je horší, než předčasná ejekulace.
No a teď zpět do smutné reality... nikdo se neobtěžoval zákazníka zeptat, jaký očekává objem dat, proto bude mít testovací databáze opravdu pouze pár set řádků a všechno bude vypadat normálně.
A teď otázka za 11 bodů: Kvůli komu firma nedostane zakázku, když se při PoC nad reálnými daty budou 20 minut motat přesýpací hodiny?
Ale to se měl zeptat programátor, na kolik dat to dělá.
-
Narazíte-li na strop stávajících možností, vymyslíte nové postupy odpovídající aktuální situaci. Stejně se bude muset změnit architektura hw, protože většinu úloh bude řešit AI a klasické zpracování dat odpadne. Nebude potřeba spoustu věcí explicitně vědět, protože je bude řešit AI bez našeho vědomí. Klasické databázové aplikace přestanou být potřeba. Informace budou ve formě člověkem neinterpretovatelných natrénovaných sítí. Půjde o black boxovou revoluci.
Managor/majitel chce data, chce je v hezkých grafech a chce je hned. Jak mu vysvětlíte, že musí 20 let počkat na AI a pak stejně žádný grafy nedostane, protože si je AI nechá pro sebe? Jestli je řešením 90 procent programátorů zamrazit a počkat na technologie, které budou uzpůsobené jejich intelektu, jsem pro :D Ale to neřeší současnou situaci.
-
vysoké školy neprodukují kvalitní programátory. Ani střední odborné. To co příjde ze škol je odpad. Nesoustředění, těkaví lepïči kodu, u kterých ani nevíte jestli zítra do práce vůbec příjdou.
A co ma byt? Vetsina firem nema zajem produkovat kvalitni software, jen blit do sveta odpad, agresivni, smirovaci bastly, ktere se mohou zitra rozsypat pod tihou vlastnich updatu. Na to jim staci lepici kodu a je to tak vlastne pro vsechny lepsi. Hruza pomyslet, co by dokazaly napachat s kvalitnimi programatory.
-
tak ale to uz prehanate tuxiku :D
to som sa este nestretol s niecim takym. myslim, ze az tak tupi programatori nie su :D
Netvrdím, že všichni, ale ano, jsou a není jich málo. Trh je plný firem složených z jednoho CEO, jednoho markeťáka a 5ti ještě studujících programátorských opic. Navenek se tváří jako korporace založená těsně po "budiž světlo" a reference mají plný firem, který o nich nikdy neslyšely. Nejdůležitější je mít cool anglický název, blikací web a pořádnou vyřídilku. Tohle bohužel není ani vtip, ani nadsázka, ani to není přehnané. V horším případě se najímá jiná firma těsně po skřípajícím produkčním nasazení, aby začala znova, v tom lepším se podobný kraviny do produkce nedostanou. Dost často to končí hádkou o to, kdo to podělal, protože zákazník tvrdí, že to nefunguje, dodavatel tvrdí, že mu zákazník nedodal podklady atd.
-
Narazíte-li na strop stávajících možností, vymyslíte nové postupy odpovídající aktuální situaci. Stejně se bude muset změnit architektura hw, protože většinu úloh bude řešit AI a klasické zpracování dat odpadne. Nebude potřeba spoustu věcí explicitně vědět, protože je bude řešit AI bez našeho vědomí. Klasické databázové aplikace přestanou být potřeba. Informace budou ve formě člověkem neinterpretovatelných natrénovaných sítí. Půjde o black boxovou revoluci.
Managor/majitel chce data, chce je v hezkých grafech a chce je hned. Jak mu vysvětlíte, že musí 20 let počkat na AI a pak stejně žádný grafy nedostane, protože si je AI nechá pro sebe? Jestli je řešením 90 procent programátorů zamrazit a počkat na technologie, které budou uzpůsobené jejich intelektu, jsem pro :D Ale to neřeší současnou situaci.
No on ten manažer ty grafy nedostane, protože ho nebude potřeba. AI rozhodne za něj, a ne za 20 let, ale za 3-7 let. Informace se do oběhu mezi lidi ani dostávat nebudou. Stroje se nebudou programovat, ale trénovat. Výsledkem nebude program, ale natrénovaná síť, která se nahraje do zařízení.
-
Trh je plný firem složených z jednoho CEO, jednoho markeťáka a 5ti ještě studujících programátorských opic.
s tymto s vami suhlasim. sam som robil v takej firme - garazovka. 1 CEO, ktory bol zaroven architekt, analytik, potom clovek, ktory sa vyhlasoval za programator, ale programovat nevedel, tak robil testera, ja som tam programoval ako student a bol tam este 1 senior. V takychto firmach je to naozaj nahovno a zial, je ich vela a niet sa tam od koho ucit.
Mna by len zaujimala jedna otazka. Niektori diskuteri tu pouzivaju slovo opica, lepic kodu. Za co alebo koho povazuju oni seba? Za profesionalov produkujucich skvely a optimalizovany kod?
-
No on ten manažer ty grafy nedostane, protože ho nebude potřeba. AI rozhodne za něj, a ne za 20 let, ale za 3-7 let. Informace se do oběhu mezi lidi ani dostávat nebudou. Stroje se nebudou programovat, ale trénovat. Výsledkem nebude program, ale natrénovaná síť, která se nahraje do zařízení.
Ty drogy chci taky :D A ta AI si dokonce sama kreativně vytvoří novou, revoluční, bezprecedentní koncepci, kterou se bude firma řídit, aniž by se o tom někdo dozvěděl, aniž by se nad tím někdo zamýšlel, aniž by to majitele/akcionáře zajímalo? Opravdu ty drogy chci :D
-
Zamestnatelny progrator je uz dnes nedostatkovy "tovar". U nas vo firme (mala firma cca 30 it ludi) robim pohovory vyvojarov. A co som si vsimol:
- Ako najvacsi problem vidim mileniovu generaciu pekne to zhrnul Simon Sinek - https://www.youtube.com/watch?v=OPaQPWfqjmw, casto sa toto opakuje: prijde mlady programator chce 2000e plat, 2 dni homeoffice za tyzden, nadcasy odmieta (napr pred odovzdanim/nasadenim), nema pracovne navyky, nie je proaktivny, nepozna domenu a po par malo mesiacoch ho prestane bavit programovat lebo sa ju (domenu) musi naucit... z mladych (25) je prijatelnych (po osobnostnej stranke) mozno 2 z 10 ludi, zo starsich (35 a viac) mozno 7 z 10
- Ked som ja chodil do skoly (10 rokov dozadu) kazdy zo spoluziakov pocas skoly pracoval v it, ked dnes prijde niekto na pohovor tak pocas skoly robili v it 2 z 10 ludi
- Programovanie len v praci, nemaju zalubu taku ze si doma riesia projekty, ak ano tak vacsinou mi povedia, ze v unity robia hru. Ti co robia nieco mimo prace a nemaju rodinu je malo, cca 3 z 10 ludi
- Vyhradenost/obmedzenost na jednu platformu/framework -> c#, alebo java alebo ruby, alebo podobne a nechcu sa ucit nove a tvria ze to ich je najlepsie - ti co poznaju viac a nebrania sa novym veciam 4 z 10
Dnes IT vynasa, preto sa tomu vela ludi chce venovat, ale nemaju na to, nie su to ti klasicki it nerdi co vyrastali v 70 a 80 rokoch a pocitac bola ich najvacsia zaluba. Vacsina tychto novych ludi nema na to byt programatorom, preto je vela podpriemernych programatorov medzi mladymi a celkova uroven klesa. Pred 5 rokmi to bol vacsi vyber...
-
s tymto s vami suhlasim. sam som robil v takej firme - garazovka. 1 CEO, ktory bol zaroven architekt, analytik, potom clovek, ktory sa vyhlasoval za programator, ale programovat nevedel, tak robil testera, ja som tam programoval ako student a bol tam este 1 senior. V takychto firmach je to naozaj nahovno a zial, je ich vela a niet sa tam od koho ucit.
Mna by len zaujimala jedna otazka. Niektori diskuteri tu pouzivaju slovo opica, lepic kodu. Za co alebo koho povazuju oni seba? Za profesionalov produkujucich skvely a optimalizovany kod?
je třeba si výrazy objasnit:
opice: osobně používám pro člověka bez vlastní kreativity, který bude opakovat naučené postupy bez jejich hlubšího chápání, zcela bez ohledu na to, jestli jsou pro daný případ vhodné
lepič kódu: též zvaný špageťák, opět nic nevymýšlí, jen skládá dohromady různé útržky z různých zdrojů a jakési funkcionality dost často dosahuje metodou pokus/omyl
Z mé strany to není urážka, ale pouze zkrácené a myslím i výstižné označení. Asi to funguje dobře, protože spousta lidí se v tom poznává. Rozhodně jim to nevyčítám, že to dělají, když za to mají slušný plat a málo práce, ale jestli budou rozkřikovat do světa, že je to jediný správný přístup, tak na to sami dojedou, protože už jim nebude mít kdo vyvíjet jejich cool frameworky a s takovou kvalifikací je čeká v létě koště, v zimě hrablo a oranžová vestička jako bonus celoročně.
-
s takymto vysvetlenim sa neda nic ine, len suhlasit. :)
Programovanie len v praci, nemaju zalubu taku ze si doma riesia projekty, ak ano tak vacsinou mi povedia, ze v unity robia hru.
Co je na tom zle, ked si niekto skusa robit v Unity? Lepsie by mal skusat v konzole vypisovat fibonacciho?
-
No on ten manažer ty grafy nedostane, protože ho nebude potřeba. AI rozhodne za něj, a ne za 20 let, ale za 3-7 let. Informace se do oběhu mezi lidi ani dostávat nebudou. Stroje se nebudou programovat, ale trénovat. Výsledkem nebude program, ale natrénovaná síť, která se nahraje do zařízení.
Ty drogy chci taky :D A ta AI si dokonce sama kreativně vytvoří novou, revoluční, bezprecedentní koncepci, kterou se bude firma řídit, aniž by se o tom někdo dozvěděl, aniž by se nad tím někdo zamýšlel, aniž by to majitele/akcionáře zajímalo? Opravdu ty drogy chci :D
Proč by informace z e-shopu statisticky musel zpracovávat člověk? Vždyť to jsou standardizované postupy, proč by zboží na sklad měl objednávat člověk, vždyť už dnes CRM systémy to často umí samy. Tedy běžné manažerské rozhodování odpadne, zůstane manažer inovací, který stroje natrénuje na nové často riskantní postupy, rutinu už stroje zvládnou samy.
Ono generovat nový design výrobků lze taky dělat strojově a zařazovat je do prodeje a zkoumat jak se ujmou. K tomu všemu není potřeba manažerů. Problém je zatím technologie malosériové výroby, ale to se s rozvojem 3D tisku pomalu mění. No a nebudu-li k dispozitci tyto údaje, nebudou se moci ani lidi naučit reálnou bussines logiku, nebudou mít co strojům předat, z oblasti rutinních činností. Což celý proces bude akcelerovat. Manažeři budou v roli chirurgů, kde budou něco měnit, aniž by do detailu rozuměli tomu co dělají a produkční organismus si pomůže sám a nalezne novou rovnováhu už sám.
Tedy nastane doba, kdy informace z uzavřeného produkčně prodejního procesu se k lidem ani nedostanou. Tak jako dnes vás nezajímá, kde a jak jsou informace uloženy, které používáte.
-
Proč by informace z e-shopu statisticky musel zpracovávat člověk? Vždyť to jsou standardizované postupy, proč by zboží na sklad měl objednávat člověk, vždyť už dnes CRM systémy to často umí samy. Tedy běžné manažerské rozhodování odpadne, zůstane manažer inovací, který stroje natrénuje na nové často riskantní postupy, rutinu už stroje zvládnou samy.
Ono generovat nový design výrobků lze taky dělat strojově a zařazovat je do prodeje a zkoumat jak se ujmou. K tomu všemu není potřeba manažerů. Problém je zatím technologie malosériové výroby, ale to se s rozvojem 3D tisku pomalu mění. No a nebudu-li k dispozitci tyto údaje, nebudou se moci ani lidi naučit reálnou bussines logiku, nebudou mít co strojům předat, z oblasti rutinních činností. Což celý proces bude akcelerovat. Manažeři budou v roli chirurgů, kde budou něco měnit, aniž by do detailu rozuměli tomu co dělají a produkční organismus si pomůže sám a nalezne novou rovnováhu už sám.
Tedy nastane doba, kdy informace z uzavřeného produkčně prodejního procesu se k lidem ani nedostanou. Tak jako dnes vás nezajímá, kde a jak jsou informace uloženy, které používáte.
Opomíjíte jednu věc: jde o prachy. Lidé chtějí vědět, jak se jejich prachy točí, kolik jim to nese. Momentálně se ve velkém řeší big data, mimo jiné se řeší, jak z nich dostat online výsledky, ne proto, že by byly tak extrémě důležité (až na výjimky), ale proto, že je někdo prostě chce vidět. Ten někdo si za to kolikrát platí nemalé peníze. Jestli lidi za 3-7 let pochopí, že je to na nic, pak je to průchozí.
Mimochodem, mě opravdu ZAJÍMÁ, kde a jak mám uložený data, je to jedna z věcí, za které jsem slušně placenej :D
-
Proč by informace z e-shopu statisticky musel zpracovávat člověk? Vždyť to jsou standardizované postupy, proč by zboží na sklad měl objednávat člověk, vždyť už dnes CRM systémy to často umí samy. Tedy běžné manažerské rozhodování odpadne, zůstane manažer inovací, který stroje natrénuje na nové často riskantní postupy, rutinu už stroje zvládnou samy.
Ono generovat nový design výrobků lze taky dělat strojově a zařazovat je do prodeje a zkoumat jak se ujmou. K tomu všemu není potřeba manažerů. Problém je zatím technologie malosériové výroby, ale to se s rozvojem 3D tisku pomalu mění. No a nebudu-li k dispozitci tyto údaje, nebudou se moci ani lidi naučit reálnou bussines logiku, nebudou mít co strojům předat, z oblasti rutinních činností. Což celý proces bude akcelerovat. Manažeři budou v roli chirurgů, kde budou něco měnit, aniž by do detailu rozuměli tomu co dělají a produkční organismus si pomůže sám a nalezne novou rovnováhu už sám.
Tedy nastane doba, kdy informace z uzavřeného produkčně prodejního procesu se k lidem ani nedostanou. Tak jako dnes vás nezajímá, kde a jak jsou informace uloženy, které používáte.
Opomíjíte jednu věc: jde o prachy. Lidé chtějí vědět, jak se jejich prachy točí, kolik jim to nese. Momentálně se ve velkém řeší big data, mimo jiné se řeší, jak z nich dostat online výsledky, ne proto, že by byly tak extrémě důležité (až na výjimky), ale proto, že je někdo prostě chce vidět. Ten někdo si za to kolikrát platí nemalé peníze. Jestli lidi za 3-7 let pochopí, že je to na nic, pak je to průchozí.
Mimochodem, mě opravdu ZAJÍMÁ, kde a jak mám uložený data, je to jedna z věcí, za které jsem slušně placenej :D
To programátoři mainframů před nástupem PC říkali taky. Bill Gates dlouho nevěřil v komerční úspěch internetu.
Jinak to za co jste placený, převezme vámi natrénovaný stroj. Není to přece žádná magie, ale znalosti, které často nevyužíváte vědomě, ale pouze jako výsledek automatického procesu, který nemáte pod kontrolou a proběhl ve vašem mozku. Uložení dat má navíc jen volnou vazbu na realitu, tu vazbu zprostředkovává jen gramatika dotazování, nic více. Takže můžete zpracovávat data, aniž byste jim rozuměl, můžete pracovat jen v rámci modelu, který je dán existující strukturou databáze.
Nedochází vám jedna věc, lidé většinu informací, které dnes potřebují, přestanou potřebovat, protože rozhodnutí za ně udělají stroje. Například budou-li zavedena samořiditelná auta masově, nebude třeba vytvářet grafická zobrazení map, protože stroj je nepotřebuje a nebude je potřebovat ani člověk, protože jen stroji sdělí číslo místa, kam se chce dostat, nebo jen vybere tvář člověka, se kterým se chce setkat.
Přejdeme do stádia black box civilizace.
-
Například budou-li zavedena samořiditelná auta masově, nebude třeba vytvářet grafická zobrazení map, protože stroj je nepotřebuje a nebude je potřebovat ani člověk, protože jen stroji sdělí číslo místa, kam se chce dostat, nebo jen vybere tvář člověka, se kterým se chce setkat.
Jo takovy s prominutim bl....cky uz jsem zazil, jediny co vi je, jak natukat na GPSce cil a vubec netusi, jak se tam dostanou (ani ramcove, tj. jestli jedou na sever nebo na jih). Takze kdyz GPS klekne nebo ma spatny data (v horach typicka situace), tak ... konec civilizace.
-
@tuxík
Kde a jak je uložena tato diskuse?
-
Netvrdím, že všichni, ale ano, jsou a není jich málo. Trh je plný firem složených z jednoho CEO, jednoho markeťáka a 5ti ještě studujících programátorských opic.
Já tomu asi nerozumím - existují špatní programátoři, nástroje typu GC, SQL apod. umožní i špatným programátorům vyrobit jakž takž něco funkčního (i když dost blbě), ergo používání nástrojů GC, SQL apod. je (většinou) špatné? Proč by si dobrý programátor neměl ušetřit práci? Proč bych měl jako programátor po 1000 řešit alokace/dealokace, když je za mně zpravidla líp vyřeší GC?
-
Například budou-li zavedena samořiditelná auta masově, nebude třeba vytvářet grafická zobrazení map, protože stroj je nepotřebuje a nebude je potřebovat ani člověk, protože jen stroji sdělí číslo místa, kam se chce dostat, nebo jen vybere tvář člověka, se kterým se chce setkat.
Jo takovy s prominutim bl....cky uz jsem zazil, jediny co vi je, jak natukat na GPSce cil a vubec netusi, jak se tam dostanou (ani ramcove, tj. jestli jedou na sever nebo na jih). Takze kdyz GPS klekne nebo ma spatny data (v horach typicka situace), tak ... konec civilizace.
Dobře, ale pakety po síti si taky neřídíte sám, ale využíváte služeb DNS serverů.
-
Co je na tom zle, ked si niekto skusa robit v Unity? Lepsie by mal skusat v konzole vypisovat fibonacciho?
Ať si hrají, kdo si hraje nezlobí, stejně každej s počítačema začal prostřednictvím her a snem každého malého nerda bylo nějakou naprogramovat. Ale mohl by alespoň vědět, co to ta fibonacciho posloupnost je :D
-
Netvrdím, že všichni, ale ano, jsou a není jich málo. Trh je plný firem složených z jednoho CEO, jednoho markeťáka a 5ti ještě studujících programátorských opic.
Já tomu asi nerozumím - existují špatní programátoři, nástroje typu GC, SQL apod. umožní i špatným programátorům vyrobit jakž takž něco funkčního (i když dost blbě), ergo používání nástrojů GC, SQL apod. je (většinou) špatné? Proč by si dobrý programátor neměl ušetřit práci? Proč bych měl jako programátor po 1000 řešit alokace/dealokace, když je za mně zpravidla líp vyřeší GC?
Proč? Protože étos spektrismu.
-
Co je na tom zle, ked si niekto skusa robit v Unity? Lepsie by mal skusat v konzole vypisovat fibonacciho?
Ať si hrají, kdo si hraje nezlobí, stejně každej s počítačema začal prostřednictvím her a snem každého malého nerda bylo nějakou naprogramovat. Ale mohl by alespoň vědět, co to ta fibonacciho posloupnost je :D
Nebo že součet logaritmů je násobení.
-
Například budou-li zavedena samořiditelná auta masově, nebude třeba vytvářet grafická zobrazení map, protože stroj je nepotřebuje a nebude je potřebovat ani člověk, protože jen stroji sdělí číslo místa, kam se chce dostat, nebo jen vybere tvář člověka, se kterým se chce setkat.
Jo takovy s prominutim bl....cky uz jsem zazil, jediny co vi je, jak natukat na GPSce cil a vubec netusi, jak se tam dostanou (ani ramcove, tj. jestli jedou na sever nebo na jih). Takze kdyz GPS klekne nebo ma spatny data (v horach typicka situace), tak ... konec civilizace.
Moja prva jazda Uberom bola presne takato. Zaroven to bola aj moja posledna jazda uberom. Navigaciu robil ja podla dopravnych znaciek. (Ako nevodica ma prekvapilo, ze vsetko je znacene ako pre blbych a aj tak sa nevedia niektori trafit)
-
Například budou-li zavedena samořiditelná auta masově, nebude třeba vytvářet grafická zobrazení map, protože stroj je nepotřebuje a nebude je potřebovat ani člověk, protože jen stroji sdělí číslo místa, kam se chce dostat, nebo jen vybere tvář člověka, se kterým se chce setkat.
Jo takovy s prominutim bl....cky uz jsem zazil, jediny co vi je, jak natukat na GPSce cil a vubec netusi, jak se tam dostanou (ani ramcove, tj. jestli jedou na sever nebo na jih). Takze kdyz GPS klekne nebo ma spatny data (v horach typicka situace), tak ... konec civilizace.
Moja prva jazda Uberom bola presne takato. Zaroven to bola aj moja posledna jazda uberom. Navigaciu robil ja podla dopravnych znaciek. (Ako nevodica ma prekvapilo, ze vsetko je znacene ako pre blbych a aj tak sa nevedia niektori trafit)
Tak to jste měl štěstí, za pár let budou cesty křižovat automaticky řiditelné kapsule s kostlivci, kteří neměli tolik štěstí a cestu nenašli.
-
Novy, vy pozerate moc sci-fi a popritom fajcite riadny matros
-
Novy, vy pozerate moc sci-fi a popritom fajcite riadny matros
Kdyby jenom, ale ono se to už děje https://www.novinky.cz/internet-a-pc/433516-musk-chce-propojit-lidske-mozky-s-pocitaci.html
-
Celou dobu tvrdím, že bez mozkových implantátů je herní průmysl ve slepé uličce.
-
Já tomu asi nerozumím - existují špatní programátoři, nástroje typu GC, SQL apod. umožní i špatným programátorům vyrobit jakž takž něco funkčního (i když dost blbě), ergo používání nástrojů GC, SQL apod. je (většinou) špatné? Proč by si dobrý programátor neměl ušetřit práci? Proč bych měl jako programátor po 1000 řešit alokace/dealokace, když je za mně zpravidla líp vyřeší GC?
Špatné je, když programátor píše kód, spoléhá se na GC, protože se to tak naučil a ve skutečnosti ani netuší, že tam nějaký GC je a co pro něj/za něj dělá. Co se týče jakékoliv DB, tam je situace odlišná a dle osobních zkušeností i horší, počínaje samotným návrhem DB (který sice není v kompetenci čistého programátora, ale víme, jak to je), kdy bývá zprasená nejen struktura, ale vzhledem k neznalosti je často použita i zcela nevhodná DB. Potom se to ohýbá, programátor se snaží o "jakože OLAP" nad OLTP DB a vůbec škoda mluvit. Navíc si programátoři evidentně neuvědomují, že opravdu moc dobře vím, proč je nenechám bastlit nad nějakou vlastní DB v jejich správě a nutím je se připojovat do DB pod naší správou. A kdo první uhádne proč, může si zdarma stáhnout třeba Postgres i s dokumentací.
-
Kdyby jenom, ale ono se to už děje https://www.novinky.cz/internet-a-pc/433516-musk-chce-propojit-lidske-mozky-s-pocitaci.html
https://www.debility.ru/vlhke_sny/0112358-tuxik-chce-vyhrat-eurojackpot-a-uz-nikdy-nepracovat.html
Když si na to založím firmu, taky už "se to bude dít"?
Jde to s vámi opravdu z kopce, už to není ani poučné, ani vtipné, na trolling je to chabé... opravdu bych ty drogy chtěl.
-
...
Hloupé. My nevíme jaká kvalita je optimální. To hledá vzhledem k aktuálnímu stavu systému trh. Příliš kvality může škodit, alokuje se zbytečně mnoho zdrojů do nějakého projektu, který stejně zapadne, protože bude nepotřebný, nebude po něm poptávka. Například.
... dalsi zabijak - vystavni blabol :)
-
Špatné je, když programátor píše kód, spoléhá se na GC, protože se to tak naučil a ve skutečnosti ani netuší, že tam nějaký GC je a co pro něj/za něj dělá.
Jinymy slovy - pouziti GC je (velmi casto, ne vzdy) super, jen musis vedet ze a proc?
-
Kdyby jenom, ale ono se to už děje https://www.novinky.cz/internet-a-pc/433516-musk-chce-propojit-lidske-mozky-s-pocitaci.html
https://www.debility.ru/vlhke_sny/0112358-tuxik-chce-vyhrat-eurojackpot-a-uz-nikdy-nepracovat.html
Když si na to založím firmu, taky už "se to bude dít"?
Jde to s vámi opravdu z kopce, už to není ani poučné, ani vtipné, na trolling je to chabé... opravdu bych ty drogy chtěl.
První náznaky http://www.osel.cz/8753-nanoboti-v-mozku-budou-pro-kazdeho.html
-
...
Hloupé. My nevíme jaká kvalita je optimální. To hledá vzhledem k aktuálnímu stavu systému trh. Příliš kvality může škodit, alokuje se zbytečně mnoho zdrojů do nějakého projektu, který stejně zapadne, protože bude nepotřebný, nebude po něm poptávka. Například.
... dalsi zabijak - vystavni blabol :)
A vy to snad víte? Jistě chodíte v kožených botách šitých na míru. Tedy máte maximum kvality.
-
Kdyby jenom, ale ono se to už děje https://www.novinky.cz/internet-a-pc/433516-musk-chce-propojit-lidske-mozky-s-pocitaci.html
https://www.debility.ru/vlhke_sny/0112358-tuxik-chce-vyhrat-eurojackpot-a-uz-nikdy-nepracovat.html
Když si na to založím firmu, taky už "se to bude dít"?
Jde to s vámi opravdu z kopce, už to není ani poučné, ani vtipné, na trolling je to chabé... opravdu bych ty drogy chtěl.
První náznaky http://www.osel.cz/8753-nanoboti-v-mozku-budou-pro-kazdeho.html
A zde konkrétní výzkum z našeho regionu https://www.sav.sk/?lang=sk&doc=user-org-user&user_no=1646&action=projects
-
A zde http://www.m2neural.eu/, zatím jen na periferních nervech.
-
...
Hloupé. My nevíme jaká kvalita je optimální. To hledá vzhledem k aktuálnímu stavu systému trh. Příliš kvality může škodit, alokuje se zbytečně mnoho zdrojů do nějakého projektu, který stejně zapadne, protože bude nepotřebný, nebude po něm poptávka. Například.
... dalsi zabijak - vystavni blabol :)
A vy to snad víte? Jistě chodíte v kožených botách šitých na míru. Tedy máte maximum kvality.
<trapne_ticho/>
-
Jinymy slovy - pouziti GC je (velmi casto, ne vzdy) super, jen musis vedet ze a proc?
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
-
Jinymy slovy - pouziti GC je (velmi casto, ne vzdy) super, jen musis vedet ze a proc?
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
Ne ze by si zrovna na tenhle user case musel psat dealokaci rucne (coz mimochodem neni zas takova sranda, pokud zacnes uvazovat i o tom, ze se ti uvnitr bloku muze stat ledacos spatneho). Tohle je ten nejprimitivnejsi priklad escape analysis.
-
Netvrdím, že všichni, ale ano, jsou a není jich málo. Trh je plný firem složených z jednoho CEO, jednoho markeťáka a 5ti ještě studujících programátorských opic.
Já tomu asi nerozumím - existují špatní programátoři, nástroje typu GC, SQL apod. umožní i špatným programátorům vyrobit jakž takž něco funkčního (i když dost blbě), ergo používání nástrojů GC, SQL apod. je (většinou) špatné? Proč by si dobrý programátor neměl ušetřit práci? Proč bych měl jako programátor po 1000 řešit alokace/dealokace, když je za mně zpravidla líp vyřeší GC?
Dobrý programátor v C(++) umí psát funkční kód i bez explicitní správy paměti, ta je přenechána vesměs jen autorům knihoven na nižší úrovni, což je obvykle v dané komunitě beztak elita. Jak říkával můj učitel matematiky na SŠ: stačí myslet. To je ostatně největší problém dnešního IT, ty zmíněné "opice" místo myšlení googlují.
-
bohuzel vyvoj v oblasti sw jde nechutne pomalu, radove pomaleji nez hw.
clovek by neveril ze v 21 stoleti se stale bude programovat v...textovem editoru. v stale stejnych jazicich jako v 20 stoleti.
mozna ze na to clovek jako tvor proste nema a narazil na sve limity a nastup AI bude vysvobozenim, po lidskych koderech nestekne casem ani pes a potencialne nadprumerne inteligentni jedinci dostanou sanci v jinych pro cloveka vhodnejsich oborech....
takze dulezite bude tu AI postupne dokopat do stadia ze se zacne ucit sama. doufejme ze par genialnich jedincu nas lopotici se programatory vysvobodi:-)
-
Jinymy slovy - pouziti GC je (velmi casto, ne vzdy) super, jen musis vedet ze a proc?
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
V tomto případě ale stačí alokace na zásobníku, která je zadarmo (pokud se na zásobník vejde).
-
Jinymy slovy - pouziti GC je (velmi casto, ne vzdy) super, jen musis vedet ze a proc?
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
Ne ze by si zrovna na tenhle user case musel psat dealokaci rucne (coz mimochodem neni zas takova sranda, pokud zacnes uvazovat i o tom, ze se ti uvnitr bloku muze stat ledacos spatneho). Tohle je ten nejprimitivnejsi priklad escape analysis.
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně :) , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání. A jinak, to je pořád řečí, jak musí být kód čitelný (někteří to považují za důležitější, než jeho funkčnost) a najednou je používání primitivních postupů špatně? Ono totiž většinou čím primitivnější, tím lepší. Chce to kázeň. A to je právě to, co velmi často chybí a proč vzniká tolik kočkopsů.
-
...
Hloupé. My nevíme jaká kvalita je optimální. To hledá vzhledem k aktuálnímu stavu systému trh. Příliš kvality může škodit, alokuje se zbytečně mnoho zdrojů do nějakého projektu, který stejně zapadne, protože bude nepotřebný, nebude po něm poptávka. Například.
... dalsi zabijak - vystavni blabol :)
A vy to snad víte? Jistě chodíte v kožených botách šitých na míru. Tedy máte maximum kvality.
<trapne_ticho/>
Tak polopaticky. No v dobách, kdy byly každé boty šité na míru a nebylo to tak dávno, u nás před nějakými 150 lety, mnozí lidé chodili bosí. Kvalita obuvi dnes poklesla, většinou nemají boty šité na míru, ale chodí obutí. A vystačí si i s touto sníženou kvalitou. Otázka zní, jak je možno tu kvalitu ještě snížit, aby to bylo prodejné a udržela se rentabilita výroby bot, když mzdové náklady na výrobu v Číně rostou.
No a ten samý proces probíhá i v tvorbě software. S nárůstem poptávky a průmyslovou produkcí klesá kvalita.
-
Jinymy slovy - pouziti GC je (velmi casto, ne vzdy) super, jen musis vedet ze a proc?
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
Ne ze by si zrovna na tenhle user case musel psat dealokaci rucne (coz mimochodem neni zas takova sranda, pokud zacnes uvazovat i o tom, ze se ti uvnitr bloku muze stat ledacos spatneho). Tohle je ten nejprimitivnejsi priklad escape analysis.
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně :) , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání. A jinak, to je pořád řečí, jak musí být kód čitelný (někteří to považují za důležitější, než jeho funkčnost) a najednou je používání primitivních postupů špatně? Ono totiž většinou čím primitivnější, tím lepší. Chce to kázeň. A to je právě to, co velmi často chybí a proč vzniká tolik kočkopsů.
Proste jenom pridas k seznamu veci, co musi manageovat rucne i tu nejpouzivanejsi. A pritom tam muzes zrovna v tehle situaci jenom udelat chyby, lepsi nez slusny kompilator + runtime nebudes.
-
Jinymy slovy - pouziti GC je (velmi casto, ne vzdy) super, jen musis vedet ze a proc?
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
Ne ze by si zrovna na tenhle user case musel psat dealokaci rucne (coz mimochodem neni zas takova sranda, pokud zacnes uvazovat i o tom, ze se ti uvnitr bloku muze stat ledacos spatneho). Tohle je ten nejprimitivnejsi priklad escape analysis.
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně :) , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání. A jinak, to je pořád řečí, jak musí být kód čitelný (někteří to považují za důležitější, než jeho funkčnost) a najednou je používání primitivních postupů špatně? Ono totiž většinou čím primitivnější, tím lepší. Chce to kázeň. A to je právě to, co velmi často chybí a proč vzniká tolik kočkopsů.
I kázeň něco stojí, i kód navíc, i chyby navíc.
-
Mimochodem, předpokládám, že programátoři by taky neměli používat SQL, protože ručně psaná a na konkrétní úkol optimalizovaná databáze je samozřejmě rychlejší....
Ona taky je - IMS. Ale je to tezkopadne.
-
btw vetsina aplikaci pametove neustale roste, ne protoze leakuje, ale protoze drzi mnohe data zbytecne (ale lexikalne spravne tj zadna automatika jako GC nepomuze)
programator musi o pameti premyslet jako o vzacnem zdroji. kdyz ne, tak prave programy psane v jazicich s automatickym memory managementem jsou ty nejzravejsi, prave kvuli bezstarostnemu pristupu k pameti.
-
btw vetsina aplikaci pametove neustale roste, ne protoze leakuje, ale protoze drzi mnohe data zbytecne (ale lexikalne spravne tj zadna automatika jako GC nepomuze)
programator musi o pameti premyslet jako o vzacnem zdroji. kdyz ne, tak prave programy psane v jazicich s automatickym memory managementem jsou ty nejzravejsi, prave kvuli bezstarostnemu pristupu k pameti.
GC pomůže, může nepoužívanou ale aktivní paměť odsunout na disk. To je mechanismus starý 60 let. Naopak je často spíše problém, že dostupná paměť systému se nevyužívá.
-
Potom se to ohýbá, programátor se snaží o "jakože OLAP" nad OLTP DB a vůbec škoda mluvit.
Kterou databazi (nejlepe OSS) doporucujes na OLAP?
-
Ale máte pravdu, čeština upadá už nejméně 80 let. Nejkrásnější byla tak kolem roku 1930.
Nicemu to nevadi, jazyk se musi vyvijet. Podivejte se na nejhorsi variantu cestiny vubec a pritom ji Slovaci stale pouzivaji.
To by snáď nemohla byť na roote alebo zdrojáku diskusia v ktorej by neboli urážky nasmerované k vášmu východnému susedovi.
-
vysoké školy neprodukují kvalitní programátory. Ani střední odborné. To co příjde ze škol je odpad. Nesoustředění, těkaví lepïči kodu, u kterých ani nevíte jestli zítra do práce vůbec příjdou.
Stále více lidí programuje i když neměli žadné IT vzdělání, protože programátoři prostě chybí a jsou stále více dobře placení. Ovšem tito lidé už jsou většinou aspoň ve střední věku, 30-40 let.
Zájem u mladých o programování a IT všeobecně? Ano, jejich zájem začíná a končí tam kde jsou sociální sítě. Samozřejmě existují vyjímky, které potvrzují pravidlo.
Stále více a více je tedy programátorská sféra zaplněná hobbyisty, kteří jsou dobří, ale není jich nekonečno. Tudíž co bude v budoucnu? Budem dováže Indy, kde je opravdu neskutečný boom v programátorech? Nebo jak to vidíte vy, kteří už jste v praxi nějaký ten pátek?
Ja bych vsechny ty programatory zakazal....
Ono taky kvalitnich programatoru moc nepotrebujete. Chcete par lidi s napady a pak armadu lopat, protoze i ten nejvetsi genius by se ukodoval k smrti, kdyby mel vsechny trivky resit sam.
Vzdycky kdyz si ctu takovejhle povzdech nad kvalitou absolventu, vzpomenu si na stary dobry text o pojidacich kolacu :)
-
Potom se to ohýbá, programátor se snaží o "jakože OLAP" nad OLTP DB a vůbec škoda mluvit.
Kterou databazi (nejlepe OSS) doporucujes na OLAP?
Druid, MongoDB, z komerčních Oracle (12c), Hana
-
Ale máte pravdu, čeština upadá už nejméně 80 let. Nejkrásnější byla tak kolem roku 1930.
Nicemu to nevadi, jazyk se musi vyvijet. Podivejte se na nejhorsi variantu cestiny vubec a pritom ji Slovaci stale pouzivaji.
To by snáď nemohla byť na roote alebo zdrojáku diskusia v ktorej by neboli urážky nasmerované k vášmu východnému susedovi.
Ber to s nadsázkou ;)
-
To by snáď nemohla byť na roote alebo zdrojáku diskusia v ktorej by neboli urážky nasmerované k vášmu východnému susedovi.
Počkej... na východ od ČR je snad díra a za ní až Ukrajina, ne? Nic ve zlým, otec byl slovák ;) Nic si z toho nedělej, když nejsou argumenty, přejde se na stupidní urážky ;)
-
btw vetsina aplikaci pametove neustale roste, ne protoze leakuje, ale protoze drzi mnohe data zbytecne (ale lexikalne spravne tj zadna automatika jako GC nepomuze)
programator musi o pameti premyslet jako o vzacnem zdroji. kdyz ne, tak prave programy psane v jazicich s automatickym memory managementem jsou ty nejzravejsi, prave kvuli bezstarostnemu pristupu k pameti.
GC pomůže, může nepoužívanou ale aktivní paměť odsunout na disk. To je mechanismus starý 60 let. Naopak je často spíše problém, že dostupná paměť systému se nevyužívá.
to je neskutecne hloupej pristup. ale evidentne se nim ridi minimalne vsechny ty nemehla programujici napr webowe browsery a proto vsechny ty chrome/firefox/explorery dokazi sezrat primo neskutecne mnozstvi mem+swapu. vtip je v tom ze maloktera aplikace ma ambici bezet na systemu sama a ne jako jedna z mnoha
-
btw vetsina aplikaci pametove neustale roste, ne protoze leakuje, ale protoze drzi mnohe data zbytecne (ale lexikalne spravne tj zadna automatika jako GC nepomuze)
programator musi o pameti premyslet jako o vzacnem zdroji. kdyz ne, tak prave programy psane v jazicich s automatickym memory managementem jsou ty nejzravejsi, prave kvuli bezstarostnemu pristupu k pameti.
GC pomůže, může nepoužívanou ale aktivní paměť odsunout na disk. To je mechanismus starý 60 let. Naopak je často spíše problém, že dostupná paměť systému se nevyužívá.
to je neskutecne hloupej pristup. ale evidentne se nim ridi minimalne vsechny ty nemehla programujici napr webowe browsery a proto vsechny ty chrome/firefox/explorery dokazi sezrat primo neskutecne mnozstvi mem+swapu. vtip je v tom ze maloktera aplikace ma ambici bezet na systemu sama a ne jako jedna z mnoha
a jeste dodatek, pak prece nejsou ani problem leaky. vsak ony se prece taky casem odswapuji :-) kaslem na free, dreme to naostro....
-
vysoké školy neprodukují kvalitní programátory. Ani střední odborné. To co příjde ze škol je odpad. Nesoustředění, těkaví lepïči kodu, u kterých ani nevíte jestli zítra do práce vůbec příjdou.
Stále více lidí programuje i když neměli žadné IT vzdělání, protože programátoři prostě chybí a jsou stále více dobře placení. Ovšem tito lidé už jsou většinou aspoň ve střední věku, 30-40 let.
Zájem u mladých o programování a IT všeobecně? Ano, jejich zájem začíná a končí tam kde jsou sociální sítě. Samozřejmě existují vyjímky, které potvrzují pravidlo.
Stále více a více je tedy programátorská sféra zaplněná hobbyisty, kteří jsou dobří, ale není jich nekonečno. Tudíž co bude v budoucnu? Budem dováže Indy, kde je opravdu neskutečný boom v programátorech? Nebo jak to vidíte vy, kteří už jste v praxi nějaký ten pátek?
Ja bych vsechny ty programatory zakazal....
Ono taky kvalitnich programatoru moc nepotrebujete. Chcete par lidi s napady a pak armadu lopat, protoze i ten nejvetsi genius by se ukodoval k smrti, kdyby mel vsechny trivky resit sam.
Vzdycky kdyz si ctu takovejhle povzdech nad kvalitou absolventu, vzpomenu si na stary dobry text o pojidacich kolacu :)
Tak ono to je jak na stavbě, architekt je taky jen jeden (nebo studio) a pak člověk potřebuje zástup řemeslníků a někoho pro jejich řízení. Problém v iT je ten, že neexistuje nějaká soustavná příprava právě těch řemeslníků. Architekt se na takovou práci vykašle (už jen, protože je hůře placená) a nevzdělaní/nezkušení (nebo jak tu někdo píše, "opice") to prostě udělají špatně (zdraví technický dluh). On totiž takový dobrý zedník je taky žádaný a nedostatkový a nenahradí ho skladník, pokladní z Lidlu nebo taxikář, až posledně jmenované nahradí umělina. Ti "architekti" v IT si na "opice" stěžují oprávněně, ale moc s tím dělat nemůžou kromě nadávání, čímž ony opice jen dráždí. Ve skutečnosti existují postupy a metodologie, které tvorbu softwaru automatizují, ale běžný manažer tomu nerozumí a když si o tom něco zjistí, zavrhne to jako to dražší řešení, protože prostě myslí krátkozrace. A teď babo raď... Jak už tu zaznělo, mnohé z těch "opic" na to ani nemají, takže nějaké dovzdělání nepomůže a v tom marastu se budeme plácat dál.
-
btw vetsina aplikaci pametove neustale roste, ne protoze leakuje, ale protoze drzi mnohe data zbytecne (ale lexikalne spravne tj zadna automatika jako GC nepomuze)
programator musi o pameti premyslet jako o vzacnem zdroji. kdyz ne, tak prave programy psane v jazicich s automatickym memory managementem jsou ty nejzravejsi, prave kvuli bezstarostnemu pristupu k pameti.
GC pomůže, může nepoužívanou ale aktivní paměť odsunout na disk. To je mechanismus starý 60 let. Naopak je často spíše problém, že dostupná paměť systému se nevyužívá.
to je neskutecne hloupej pristup. ale evidentne se nim ridi minimalne vsechny ty nemehla programujici napr webowe browsery a proto vsechny ty chrome/firefox/explorery dokazi sezrat primo neskutecne mnozstvi mem+swapu. vtip je v tom ze maloktera aplikace ma ambici bezet na systemu sama a ne jako jedna z mnoha
a jeste dodatek, pak prece nejsou ani problem leaky. vsak ony se prece taky casem odswapuji :-) kaslem na free, dreme to naostro....
Tak to skutečně mnohdy funguje. Někdy člověk jen závidí těm, co pracují na projektech, kde "coding guidelines" zakazují použití dynamické alokace paměti.
-
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
...
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně :) , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání.
Jasně, takže....:
v1 = priprav_objekt();
v2 = pripav_objekt_2(v1);
if (v2 == null) {
free(v1);
return;
}
v3 = priprav_objekt_3(v1, v2);
if (v3 == null) {
free(v2);
free(v1);
}
Jasně, dá se to trošku vylepšit těma "goto" a la linux kernel, případně nějakým jedním místem, kde uvolním všechno, co není null... nedejbože, aby na ten objekt ukazovalo něco od někud jinud, že....
A jinak, to je pořád řečí, jak musí být kód čitelný (někteří to považují za důležitější, než jeho funkčnost) a najednou je používání primitivních postupů špatně? Ono totiž většinou čím primitivnější, tím lepší. Chce to kázeň. A to je právě to, co velmi často chybí a proč vzniká tolik kočkopsů.
Jestli chápu správně, tak pro tebe kód, kde třetinu kódu zabírá memory management (který de-fakto nemá nic společného s řešeným problémem) je čitelnější než kód, kde se o to stará GC?
Jinak doporučuji se zamyslet nad tím, jak budeš řešit třeba asynchronní výjimky v multithreadovaném kódu - to se jaksi neřeší segfaultem, ale jen umře ten thread a ta paměť se uvolní, pokud ji nepoužívá někdo jiný v jiném threadu... už jsi něco takového zkoušel programovat?
-
btw vetsina aplikaci pametove neustale roste, ne protoze leakuje, ale protoze drzi mnohe data zbytecne (ale lexikalne spravne tj zadna automatika jako GC nepomuze)
programator musi o pameti premyslet jako o vzacnem zdroji. kdyz ne, tak prave programy psane v jazicich s automatickym memory managementem jsou ty nejzravejsi, prave kvuli bezstarostnemu pristupu k pameti.
GC pomůže, může nepoužívanou ale aktivní paměť odsunout na disk. To je mechanismus starý 60 let. Naopak je často spíše problém, že dostupná paměť systému se nevyužívá.
to je neskutecne hloupej pristup. ale evidentne se nim ridi minimalne vsechny ty nemehla programujici napr webowe browsery a proto vsechny ty chrome/firefox/explorery dokazi sezrat primo neskutecne mnozstvi mem+swapu. vtip je v tom ze maloktera aplikace ma ambici bezet na systemu sama a ne jako jedna z mnoha
a jeste dodatek, pak prece nejsou ani problem leaky. vsak ony se prece taky casem odswapuji :-) kaslem na free, dreme to naostro....
Tak to skutečně mnohdy funguje. Někdy člověk jen závidí těm, co pracují na projektech, kde "coding guidelines" zakazují použití dynamické alokace paměti.
no ja zazil jak vlastni poolove alokatory (na hrach pro playstation 2 - mala pamet, zadnej swap) tak kompletne static-only 24/7/365 kriticke systemy, takze nepochopim jak takove bastly jako webove browsery muzou existovat...
-
Kterou databazi (nejlepe OSS) doporucujes na OLAP?
Druid, MongoDB, z komerčních Oracle (12c), Hana
Zkousel jsi Mongo nebo Druid v porovnani s Postgresem? (Na OLAP.) Byl bych prekvapeny, kdyby to vyslo rychlejsi, ale rad se poucim. (To neni trikova otazka - nezkousel jsem to. Ale kdybych to zkousel, tak bych jeste zkusil MonetDB.)
-
ja by som len k Predmetu tejto spravy.
nie ze za par rokov, tych kvalitnych vyvojarov uz teraz postrada trh. Za par rokov tu uz nebude ani to malo, co je teraz. Budu len sami javascriptaci, htmlaci, cssaci a XY takych, vyuzivajucich XY frameworkov vychadzajucich z javascriptu.
-
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
...
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně :) , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání.
Jasně, takže....:
v1 = priprav_objekt();
v2 = pripav_objekt_2(v1);
if (v2 == null) {
free(v1);
return;
}
v3 = priprav_objekt_3(v1, v2);
if (v3 == null) {
free(v2);
free(v1);
}
Jasně, dá se to trošku vylepšit těma "goto" a la linux kernel, případně nějakým jedním místem, kde uvolním všechno, co není null... nedejbože, aby na ten objekt ukazovalo něco od někud jinud, že....
Hodně debilní kód, není divu, že software vypadá, jak vypadá. Na tomto příkladu je vidět, jak by javista psal v C, kdyby ho k tomu pustili. Zůstaňte fakt radši u bicyklu s postranními kolečky, přechod na Porsche opravdu nedopadne dobře.
-
ja by som len k Predmetu tejto spravy.
nie ze za par rokov, tych kvalitnych vyvojarov uz teraz postrada trh. Za par rokov tu uz nebude ani to malo, co je teraz. Budu len sami javascriptaci, htmlaci, cssaci a XY takych, vyuzivajucich XY frameworkov vychadzajucich z javascriptu.
To je ale dobře pro ty "kvalitní", protože pak budou zaměstnatelnější, ne?
-
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
...
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně :) , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání.
Jasně, takže....:
v1 = priprav_objekt();
v2 = pripav_objekt_2(v1);
if (v2 == null) {
free(v1);
return;
}
v3 = priprav_objekt_3(v1, v2);
if (v3 == null) {
free(v2);
free(v1);
}
Jasně, dá se to trošku vylepšit těma "goto" a la linux kernel, případně nějakým jedním místem, kde uvolním všechno, co není null... nedejbože, aby na ten objekt ukazovalo něco od někud jinud, že....
Hodně debilní kód, není divu, že software vypadá, jak vypadá. Na tomto příkladu je vidět, jak by javista psal v C, kdyby ho k tomu pustili. Zůstaňte fakt radši u bicyklu s postranními kolečky, přechod na Porsche opravdu nedopadne dobře.
Tak co udelas misto toho? Slozis to ze trech volani v matrjosce, ze kterych nebude jasne, o co jde, ze kod znamena
v1 = priprav1()
v2 = priprav2()
c2 = priprav3()
a zbytek je omacka?
-
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
...
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně :) , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání.
Jasně, takže....:
v1 = priprav_objekt();
v2 = pripav_objekt_2(v1);
if (v2 == null) {
free(v1);
return;
}
v3 = priprav_objekt_3(v1, v2);
if (v3 == null) {
free(v2);
free(v1);
}
Jasně, dá se to trošku vylepšit těma "goto" a la linux kernel, případně nějakým jedním místem, kde uvolním všechno, co není null... nedejbože, aby na ten objekt ukazovalo něco od někud jinud, že....
Hodně debilní kód, není divu, že software vypadá, jak vypadá. Na tomto příkladu je vidět, jak by javista psal v C, kdyby ho k tomu pustili. Zůstaňte fakt radši u bicyklu s postranními kolečky, přechod na Porsche opravdu nedopadne dobře.
Tak co udelas misto toho? Slozis to ze trech volani v matrjosce, ze kterych nebude jasne, o co jde, ze kod znamena
v1 = priprav1()
v2 = priprav2()
c2 = priprav3()
a zbytek je omacka?
Ne. Ze všeho nejdřív bych se podíval, jestli jde předávat objekty na zásobníku. Pokud ne, tak použiju nějakou formu správy paměti (jako v GCD). A pokud to z nějakého důvodu není v žádném případě žádoucí, tak použiju makro, které mi zajistí úklid ve všech větvích kódu, na unixech by bylo například udělané pomocí __attribute__(cleanup). Existují i jiné způsoby, ale ne tak univerzální, např. jen pro kód běžící v rámci nějaké smyčky událostí, ale to už moc odbočuju.
-
v1 = priprav_objekt();
v2 = pripav_objekt_2(v1);
if (v2 == null) {
free(v1);
return;
}
v3 = priprav_objekt_3(v1, v2);
if (v3 == null) {
free(v2);
free(v1);
}
Jestli chápu správně, tak pro tebe kód, kde třetinu kódu zabírá memory management...
Právě jsi porušil ten single exit, čímž jsi to dokonale zprasil.
Jestli je podle tebe normální na každý pár alokace a free napsat 4 řádky kódu, který s tím pracuje, pak ano, třetina kódu bude memory management a v takovém případě zůstaň u něčeho s GC, stejně to tím nevytrhneš.
-
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
...
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně :) , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání.
Jasně, takže....:
v1 = priprav_objekt();
v2 = pripav_objekt_2(v1);
if (v2 == null) {
free(v1);
return;
}
v3 = priprav_objekt_3(v1, v2);
if (v3 == null) {
free(v2);
free(v1);
}
Jasně, dá se to trošku vylepšit těma "goto" a la linux kernel, případně nějakým jedním místem, kde uvolním všechno, co není null... nedejbože, aby na ten objekt ukazovalo něco od někud jinud, že....
Hodně debilní kód, není divu, že software vypadá, jak vypadá. Na tomto příkladu je vidět, jak by javista psal v C, kdyby ho k tomu pustili. Zůstaňte fakt radši u bicyklu s postranními kolečky, přechod na Porsche opravdu nedopadne dobře.
Tak co udelas misto toho? Slozis to ze trech volani v matrjosce, ze kterych nebude jasne, o co jde, ze kod znamena
v1 = priprav1()
v2 = priprav2()
c2 = priprav3()
a zbytek je omacka?
Ne. Ze všeho nejdřív bych se podíval, jestli jde předávat objekty na zásobníku. Pokud ne, tak použiju nějakou formu správy paměti (jako v GCD). A pokud to z nějakého důvodu není v žádném případě žádoucí, tak použiju makro, které mi zajistí úklid ve všech větvích kódu, na unixech by bylo například udělané pomocí __attribute__(cleanup). Existují i jiné způsoby, ale ne tak univerzální, např. jen pro kód běžící v rámci nějaké smyčky událostí, ale to už moc odbočuju.
A co tím získáte, když funkci GC simulujete pomocí makra.
-
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
...
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně :) , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání.
Jasně, takže....:
v1 = priprav_objekt();
v2 = pripav_objekt_2(v1);
if (v2 == null) {
free(v1);
return;
}
v3 = priprav_objekt_3(v1, v2);
if (v3 == null) {
free(v2);
free(v1);
}
Jasně, dá se to trošku vylepšit těma "goto" a la linux kernel, případně nějakým jedním místem, kde uvolním všechno, co není null... nedejbože, aby na ten objekt ukazovalo něco od někud jinud, že....
Hodně debilní kód, není divu, že software vypadá, jak vypadá. Na tomto příkladu je vidět, jak by javista psal v C, kdyby ho k tomu pustili. Zůstaňte fakt radši u bicyklu s postranními kolečky, přechod na Porsche opravdu nedopadne dobře.
Tak co udelas misto toho? Slozis to ze trech volani v matrjosce, ze kterych nebude jasne, o co jde, ze kod znamena
v1 = priprav1()
v2 = priprav2()
c2 = priprav3()
a zbytek je omacka?
Ne. Ze všeho nejdřív bych se podíval, jestli jde předávat objekty na zásobníku. Pokud ne, tak použiju nějakou formu správy paměti (jako v GCD). A pokud to z nějakého důvodu není v žádném případě žádoucí, tak použiju makro, které mi zajistí úklid ve všech větvích kódu, na unixech by bylo například udělané pomocí __attribute__(cleanup). Existují i jiné způsoby, ale ne tak univerzální, např. jen pro kód běžící v rámci nějaké smyčky událostí, ale to už moc odbočuju.
A co tím získáte, když funkci GC simulujete pomocí makra.
Muze tvrdit, ze nepouziva GC a neni loser.
-
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
...
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně :) , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání.
Jasně, takže....:
v1 = priprav_objekt();
v2 = pripav_objekt_2(v1);
if (v2 == null) {
free(v1);
return;
}
v3 = priprav_objekt_3(v1, v2);
if (v3 == null) {
free(v2);
free(v1);
}
Jasně, dá se to trošku vylepšit těma "goto" a la linux kernel, případně nějakým jedním místem, kde uvolním všechno, co není null... nedejbože, aby na ten objekt ukazovalo něco od někud jinud, že....
Hodně debilní kód, není divu, že software vypadá, jak vypadá. Na tomto příkladu je vidět, jak by javista psal v C, kdyby ho k tomu pustili. Zůstaňte fakt radši u bicyklu s postranními kolečky, přechod na Porsche opravdu nedopadne dobře.
Tak co udelas misto toho? Slozis to ze trech volani v matrjosce, ze kterych nebude jasne, o co jde, ze kod znamena
v1 = priprav1()
v2 = priprav2()
c2 = priprav3()
a zbytek je omacka?
Ne. Ze všeho nejdřív bych se podíval, jestli jde předávat objekty na zásobníku. Pokud ne, tak použiju nějakou formu správy paměti (jako v GCD). A pokud to z nějakého důvodu není v žádném případě žádoucí, tak použiju makro, které mi zajistí úklid ve všech větvích kódu, na unixech by bylo například udělané pomocí __attribute__(cleanup). Existují i jiné způsoby, ale ne tak univerzální, např. jen pro kód běžící v rámci nějaké smyčky událostí, ale to už moc odbočuju.
A co tím získáte, když funkci GC simulujete pomocí makra.
To nebude plnohodnotné GC, ale buď RC nebo v podstatě RAII. Výhody snad vidí každý.
-
v1 = priprav_objekt();
v2 = pripav_objekt_2(v1);
if (v2 == null) {
free(v1);
return;
}
v3 = priprav_objekt_3(v1, v2);
if (v3 == null) {
free(v2);
free(v1);
}
Jestli chápu správně, tak pro tebe kód, kde třetinu kódu zabírá memory management...
Právě jsi porušil ten single exit, čímž jsi to dokonale zprasil.
Jestli je podle tebe normální na každý pár alokace a free napsat 4 řádky kódu, který s tím pracuje, pak ano, třetina kódu bude memory management a v takovém případě zůstaň u něčeho s GC, stejně to tím nevytrhneš.
Tak to napis po svem, at mame o cem diskutovat. Potrebujes naplnit tri promenne, jejich priprava potrebuje dynamickou alokaci a muze selhat.
-
To nebude plnohodnotné GC, ale buď RC nebo v podstatě RAII. Výhody snad vidí každý.
Ano, muzes prudit do ostatnich.
-
Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
...
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně :) , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání.
Jasně, takže....:
v1 = priprav_objekt();
v2 = pripav_objekt_2(v1);
if (v2 == null) {
free(v1);
return;
}
v3 = priprav_objekt_3(v1, v2);
if (v3 == null) {
free(v2);
free(v1);
}
Jasně, dá se to trošku vylepšit těma "goto" a la linux kernel, případně nějakým jedním místem, kde uvolním všechno, co není null... nedejbože, aby na ten objekt ukazovalo něco od někud jinud, že....
Hodně debilní kód, není divu, že software vypadá, jak vypadá. Na tomto příkladu je vidět, jak by javista psal v C, kdyby ho k tomu pustili. Zůstaňte fakt radši u bicyklu s postranními kolečky, přechod na Porsche opravdu nedopadne dobře.
Tak co udelas misto toho? Slozis to ze trech volani v matrjosce, ze kterych nebude jasne, o co jde, ze kod znamena
v1 = priprav1()
v2 = priprav2()
c2 = priprav3()
a zbytek je omacka?
Ne. Ze všeho nejdřív bych se podíval, jestli jde předávat objekty na zásobníku. Pokud ne, tak použiju nějakou formu správy paměti (jako v GCD). A pokud to z nějakého důvodu není v žádném případě žádoucí, tak použiju makro, které mi zajistí úklid ve všech větvích kódu, na unixech by bylo například udělané pomocí __attribute__(cleanup). Existují i jiné způsoby, ale ne tak univerzální, např. jen pro kód běžící v rámci nějaké smyčky událostí, ale to už moc odbočuju.
A co tím získáte, když funkci GC simulujete pomocí makra.
Muze tvrdit, ze nepouziva GC a neni loser.
Jestli v tom nevidíš rozdíl, tak je jakákoliv diskuse bezpředmětná.
-
Ono hlavne pro tohle vubec nemusis kod zaplacavat nejakymi makry...
-
Právě jsi porušil ten single exit, čímž jsi to dokonale zprasil.
Jestli je podle tebe normální na každý pár alokace a free napsat 4 řádky kódu, který s tím pracuje, pak ano, třetina kódu bude memory management a v takovém případě zůstaň u něčeho s GC, stejně to tím nevytrhneš.
Vždyť jsem odkazoval na Linux:
v1 = priprav_v1();
if (v1 == null)
goto exit_v1;
v2 = priprav_v2();
if (V2 == null)
goto exit_v2;
v3 = priprav_v3();
if (v3 == null)
goto exit_v3;
return v3;
exit_v3:
free(v2);
exit_v2:
free(v1);
exit_v1:
return NULL;
Takhle vypadá kód Linuxu, IMO to moc líp nejde. Máš lepší nápad? Sem s tím.
na unixech by bylo například udělané pomocí __attribute__(cleanup).
Nebo v C++ SmartPointry aka reference counting, který pak třeba zvládnou i to, když v té alokaci pošlu ten objekt někam jinam. Což už je vlastně primitivní GC, které akorát neumí cykly.
Hmm....
Jestli v tom nevidíš rozdíl, tak je jakákoliv diskuse bezpředmětná.
Pokud nepíšu real-time systémy, tak v tom fakt rozdíl není, kromě toho, že to ty cykly neumí....
-
Právě jsi porušil ten single exit, čímž jsi to dokonale zprasil.
Jestli je podle tebe normální na každý pár alokace a free napsat 4 řádky kódu, který s tím pracuje, pak ano, třetina kódu bude memory management a v takovém případě zůstaň u něčeho s GC, stejně to tím nevytrhneš.
Vždyť jsem odkazoval na Linux:
v1 = priprav_v1();
if (v1 == null)
goto exit_v1;
v2 = priprav_v2();
if (V2 == null)
goto exit_v2;
v3 = priprav_v3();
if (v3 == null)
goto exit_v3;
return v3;
exit_v3:
free(v2);
exit_v2:
free(v1);
exit_v1:
return NULL;
Takhle vypadá kód Linuxu, IMO to moc líp nejde. Máš lepší nápad? Sem s tím.
na unixech by bylo například udělané pomocí __attribute__(cleanup).
Nebo v C++ SmartPointry aka reference counting, který pak třeba zvládnou i to, když v té alokaci pošlu ten objekt někam jinam. Což už je vlastně primitivní GC, které akorát neumí cykly.
Hmm....
Jestli v tom nevidíš rozdíl, tak je jakákoliv diskuse bezpředmětná.
Pokud nepíšu real-time systémy, tak v tom fakt rozdíl není, kromě toho, že to ty cykly neumí....
1. Doporučuji podívat se na kód Grand Central Dispatch.
2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.
-
Takhle vypadá kód Linuxu, IMO to moc líp nejde. Máš lepší nápad? Sem s tím.
"...if free(ptr) has already been called before, undefined behavior occurs. If ptr is NULL, no operation is performed. "
někteří pak preferují do { if (...) break; } while(0) místo skoků
-
Právě jsi porušil ten single exit, čímž jsi to dokonale zprasil.
Jestli je podle tebe normální na každý pár alokace a free napsat 4 řádky kódu, který s tím pracuje, pak ano, třetina kódu bude memory management a v takovém případě zůstaň u něčeho s GC, stejně to tím nevytrhneš.
Vždyť jsem odkazoval na Linux:
v1 = priprav_v1();
if (v1 == null)
goto exit_v1;
v2 = priprav_v2();
if (V2 == null)
goto exit_v2;
v3 = priprav_v3();
if (v3 == null)
goto exit_v3;
return v3;
exit_v3:
free(v2);
exit_v2:
free(v1);
exit_v1:
return NULL;
Takhle vypadá kód Linuxu, IMO to moc líp nejde. Máš lepší nápad? Sem s tím.
na unixech by bylo například udělané pomocí __attribute__(cleanup).
Nebo v C++ SmartPointry aka reference counting, který pak třeba zvládnou i to, když v té alokaci pošlu ten objekt někam jinam. Což už je vlastně primitivní GC, které akorát neumí cykly.
Hmm....
Jestli v tom nevidíš rozdíl, tak je jakákoliv diskuse bezpředmětná.
Pokud nepíšu real-time systémy, tak v tom fakt rozdíl není, kromě toho, že to ty cykly neumí....
BTW stačilo by jedno návěstí. Fakt super, když někdo chce kódem v jazyce, jejž neovládá, podpořit nějaké své tvrzení...
-
2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.
můžete to rozvést?
-
Jen ho pořádně nakrmte :D On nic rozvádět nebude, protože si sem přišel pro ego boost přes nějaké nesmysly. Vlastně to není poprvé, co? :D Jen pak zbytečně zapadnou příspěvky od lidí, kteří nejsou tak hloupí jako on.
-
2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.
můžete to rozvést?
RC typicky používá běžné malloc/free, jež jsou nedeterministické. Nic jiného jsem tím nemyslel. Fungovalo by to s deterministickým alokátorem, nicméně při uvolnění taky člověk obecně neví, kolik objektů se lavinově uvolní. Proto real-time software paměť moc dynamicky nealokuje, leda tak na začátku nebo v nějaké neomezené pauze.
-
BTW stačilo by jedno návěstí.
Jo, stačilo, pravda. Pokud bych nedělal nějakou další alokaci zdrojů, případně pokud by nebylo nutné volat destruktory, protože ty objekty třeba ukazují na něco jiného.... což ve složitějším projektu opravdu dělat nebudeme, že...
Fakt super, když někdo chce kódem v jazyce, jejž neovládá, podpořit nějaké své tvrzení...
No, fascinuje mě, jak na takovémhle případu zjistíš, že C neovládám....
-
2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.
můžete to rozvést?
RC typicky používá běžné malloc/free, jež jsou nedeterministické. Nic jiného jsem tím nemyslel. Fungovalo by to s deterministickým alokátorem, nicméně při uvolnění taky člověk obecně neví, kolik objektů se lavinově uvolní. Proto real-time software paměť moc dynamicky nealokuje, leda tak na začátku nebo v nějaké neomezené pauze.
RC je obecný koncept, nezávislý na jazyku, spojovat to s malloc/free je tedy poněkud nevhodné a říct, že malloc/free jsou nedeterministické taky není dobře, většinou jistě ano, ale můžete si vytvořit vlastní implementaci (někdy aplikaci stačí i jenom malloc)
-
BTW stačilo by jedno návěstí.
Jo, stačilo, pravda. Pokud bych nedělal nějakou další alokaci zdrojů, případně pokud by nebylo nutné volat destruktory, protože ty objekty třeba ukazují na něco jiného.... což ve složitějším projektu opravdu dělat nebudeme, že...
O desturktorech viz předchozí stránka.
-
2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.
můžete to rozvést?
RC typicky používá běžné malloc/free, jež jsou nedeterministické. Nic jiného jsem tím nemyslel. Fungovalo by to s deterministickým alokátorem, nicméně při uvolnění taky člověk obecně neví, kolik objektů se lavinově uvolní. Proto real-time software paměť moc dynamicky nealokuje, leda tak na začátku nebo v nějaké neomezené pauze.
RC je obecný koncept, nezávislý na jazyku, spojovat to s malloc/free je tedy poněkud nevhodné a říct, že malloc/free jsou nedeterministické taky není dobře, většinou jistě ano, ale můžete si vytvořit vlastní implementaci (někdy aplikaci stačí i jenom malloc)
Však to píšu, že existuje i deterministický alokátor. U real-time softwaru je prostě problém jakýkoliv vyšší koncept, nejen RC nebo GC, neboť když nevím, jak přesně se něco chová, nemůžu garantovat, že mi to nerozhodí běh programu.
-
ale proč by měli všichni psát tak, aby to po nich ta opice dokázala přečíst?
Počkej počkej, doufám, že tím nechceš říct, že spagetti kód je v pořádku a "opravdový programátor" (!opice) se v něm přece vyzná?
-
No jestli tu někdo tvrdí, že něco umí a pak to udělá nejhorším možným způsobem, tak to buď neumí, nebo... nebo nevím co, v každým jazyce a s jakoukoliv technologií se dá napsat škaredej kód. To nic nedokazuje.
Jinak k věci...
a = blbost(30);
b = kravina(a);
c = volovina(b);pak stačí otestovat, jestli je c null, protože kontroly vstupů jsou přesně tam, kde mají být a to na začátku blbosti, kraviny a voloviny.
-
ale proč by měli všichni psát tak, aby to po nich ta opice dokázala přečíst?
Počkej počkej, doufám, že tím nechceš říct, že spagetti kód je v pořádku a "opravdový programátor" (!opice) se v něm přece vyzná?
Ne, já tím chtěl říct, že nebudu veškeré násobení rozepisovat jako sčítání ve smyčce jenom kvůli tomu, že někdo násobení nezná.
Zároveň se dá očekávat, že zkušený programátor s nějakým úsilím, který může a nemusí být přiměřený, dokáže pochopit a přepsat i ty špagety.
-
ale proč by měli všichni psát tak, aby to po nich ta opice dokázala přečíst?
Počkej počkej, doufám, že tím nechceš říct, že spagetti kód je v pořádku a "opravdový programátor" (!opice) se v něm přece vyzná?
Možná spíše bylo myšleno, že kód se nemá psát zbytečně jednoduše, aby mu porozuměl každý, stačí, když mu porozumí někdo na stejné úrovni jako autor.
-
2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.
můžete to rozvést?
RC typicky používá běžné malloc/free, jež jsou nedeterministické. Nic jiného jsem tím nemyslel. Fungovalo by to s deterministickým alokátorem, nicméně při uvolnění taky člověk obecně neví, kolik objektů se lavinově uvolní. Proto real-time software paměť moc dynamicky nealokuje, leda tak na začátku nebo v nějaké neomezené pauze.
RC je obecný koncept, nezávislý na jazyku, spojovat to s malloc/free je tedy poněkud nevhodné a říct, že malloc/free jsou nedeterministické taky není dobře, většinou jistě ano, ale můžete si vytvořit vlastní implementaci (někdy aplikaci stačí i jenom malloc)
Však to píšu, že existuje i deterministický alokátor. U real-time softwaru je prostě problém jakýkoliv vyšší koncept, nejen RC nebo GC, neboť když nevím, jak přesně se něco chová, nemůžu garantovat, že mi to nerozhodí běh programu.
že to nevíte vy, neznamená, že to neví nikdo :)
-
ale proč by měli všichni psát tak, aby to po nich ta opice dokázala přečíst?
Počkej počkej, doufám, že tím nechceš říct, že spagetti kód je v pořádku a "opravdový programátor" (!opice) se v něm přece vyzná?
Možná spíše bylo myšleno, že kód se nemá psát zbytečně jednoduše, aby mu porozuměl každý, stačí, když mu porozumí někdo na stejné úrovni jako autor.
Ja by som povedal, ze kod by nemal byt zbytocne obfuskovany a zmotany. Avsak v pripade, ze je na to dovod ,najcastejsie performance, mozu byt kriticke pasaze menej zrozumitelne. Ale mali by byt dobre zdokumentovane.
-
BTW stačilo by jedno návěstí.
Jo, stačilo, pravda. Pokud bych nedělal nějakou další alokaci zdrojů, případně pokud by nebylo nutné volat destruktory, protože ty objekty třeba ukazují na něco jiného.... což ve složitějším projektu opravdu dělat nebudeme, že...
O desturktorech viz předchozí stránka.
Jasně, takže v podstatě implementace RAII v C prostředky non-standard extensiony v Céčku.....
Ono je mnoho věcí, které programátorům usnadňují život, z hlediska paměti třeba podle "síly":
- RAII
- ARC
- GC
Jak tedy mám chápat Tuxíkovy nářky? Jako že používat cokoliv víc než RAII je prostě špatně, neefektivní a zcela zbytečné?
-
ale proč by měli všichni psát tak, aby to po nich ta opice dokázala přečíst?
Počkej počkej, doufám, že tím nechceš říct, že spagetti kód je v pořádku a "opravdový programátor" (!opice) se v něm přece vyzná?
Možná spíše bylo myšleno, že kód se nemá psát zbytečně jednoduše, aby mu porozuměl každý, stačí, když mu porozumí někdo na stejné úrovni jako autor.
Ja by som povedal, ze kod by nemal byt zbytocne obfuskovany a zmotany. Avsak v pripade, ze je na to dovod ,najcastejsie performance, mozu byt kriticke pasaze menej zrozumitelne. Ale mali by byt dobre zdokumentovane.
Jo, jako komentáře stylu "You are not expected to understand this" ;)
-
2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.
můžete to rozvést?
RC typicky používá běžné malloc/free, jež jsou nedeterministické. Nic jiného jsem tím nemyslel. Fungovalo by to s deterministickým alokátorem, nicméně při uvolnění taky člověk obecně neví, kolik objektů se lavinově uvolní. Proto real-time software paměť moc dynamicky nealokuje, leda tak na začátku nebo v nějaké neomezené pauze.
RC je obecný koncept, nezávislý na jazyku, spojovat to s malloc/free je tedy poněkud nevhodné a říct, že malloc/free jsou nedeterministické taky není dobře, většinou jistě ano, ale můžete si vytvořit vlastní implementaci (někdy aplikaci stačí i jenom malloc)
Však to píšu, že existuje i deterministický alokátor. U real-time softwaru je prostě problém jakýkoliv vyšší koncept, nejen RC nebo GC, neboť když nevím, jak přesně se něco chová, nemůžu garantovat, že mi to nerozhodí běh programu.
že to nevíte vy, neznamená, že to neví nikdo :)
Logicky u cizí knihovny to nebudu vědět před přečtením dokumentace. Tam to ví bez vysvětlení jen autoři.
-
Jak tedy mám chápat Tuxíkovy nářky? Jako že používat cokoliv víc než RAII je prostě špatně, neefektivní a zcela zbytečné?
Tak si to vlákno přečti znovu... jestli ani potom nepochopíš, že univerzální použití jakékoliv technologie na úplně cokoliv jen proto, že to jinak neumím, je postup pro opice, potom jsi špatný, neefektivní a zbytečný programátor.
-
BTW stačilo by jedno návěstí.
Jo, stačilo, pravda. Pokud bych nedělal nějakou další alokaci zdrojů, případně pokud by nebylo nutné volat destruktory, protože ty objekty třeba ukazují na něco jiného.... což ve složitějším projektu opravdu dělat nebudeme, že...
O desturktorech viz předchozí stránka.
Jasně, takže v podstatě implementace RAII v C prostředky non-standard extensiony v Céčku.....
Ono je mnoho věcí, které programátorům usnadňují život, z hlediska paměti třeba podle "síly":
- RAII
- ARC
- GC
Jak tedy mám chápat Tuxíkovy nářky? Jako že používat cokoliv víc než RAII je prostě špatně, neefektivní a zcela zbytečné?
Je to jedna z možností. V jiném případě bude lepší třeba autorelease pool. RAII a (A)RC má výhodu, že je konceptuálně jen jedno a nejde zprasit. GC je více typů a vesměs s problémy. Nicméně když se implementuje rozumně, je jeho použití užitečné a žádoucí, například v Go nebo svého času ObjC, kde byl GC v určitých ohledech unikátní.
-
a = blbost(30);
b = kravina(a);
c = volovina(b);
Jasně, a když spadne blbost(), tak to pěkně celý popadá na nějaký null pointery, že.... ať žije kvalitní kód...
Jak tedy mám chápat Tuxíkovy nářky? Jako že používat cokoliv víc než RAII je prostě špatně, neefektivní a zcela zbytečné?
Tak si to vlákno přečti znovu... jestli ani potom nepochopíš, že univerzální použití jakékoliv technologie na úplně cokoliv jen proto, že to jinak neumím, je postup pro opice, potom jsi špatný, neefektivní a zbytečný programátor.
Čtu:
použití GC je (velmi často, ne vždy) zbytečnost
Proč bych neměl použít GC, když mě to ušetří práci (a chyby) s prací s pamětí? Mě naopak připadá, že nepoužití GC, pokud to zrovna není nějaký use-case, kde není vhodný, je naprosto zbytečné. To, co vyřeší RAII řeší GC úplně bez problémů. To, co řeší ARC, řeší GC taky bez problémů. A navíc ještě zvládá cykly. Tak proč bych neměl jít stylem "použiju GC, pokud není důvod ho nepoužít"?
-
Jasně, a když spadne blbost(), tak to pěkně celý popadá na nějaký null pointery, že.... ať žije kvalitní kód...
pak stačí otestovat, jestli je c null, protože kontroly vstupů jsou přesně tam, kde mají být a to na začátku blbosti, kraviny a voloviny
Už to vidíš? Co vidíš... chápeš? Nebo je normální testovat raději vstup v programu třeba 80x, před každým voláním? Teda vlastně asi ano... bohužel...
-
Jak tedy mám chápat Tuxíkovy nářky? Jako že používat cokoliv víc než RAII je prostě špatně, neefektivní a zcela zbytečné?
Tak si to vlákno přečti znovu... jestli ani potom nepochopíš, že univerzální použití jakékoliv technologie na úplně cokoliv jen proto, že to jinak neumím, je postup pro opice, potom jsi špatný, neefektivní a zbytečný programátor.
Čtu:
použití GC je (velmi často, ne vždy) zbytečnost
Proč bych neměl použít GC, když mě to ušetří práci (a chyby) s prací s pamětí? Mě naopak připadá, že nepoužití GC, pokud to zrovna není nějaký use-case, kde není vhodný, je naprosto zbytečné. To, co vyřeší RAII řeší GC úplně bez problémů. To, co řeší ARC, řeší GC taky bez problémů. A navíc ještě zvládá cykly. Tak proč bych neměl jít stylem "použiju GC, pokud není důvod ho nepoužít"?
To je filosofie Go a ano, je to pragmatické a rozumné, ale jen proto, že můžu alokovat i na zásobníku a protože GC v Go je trojbarevný.
-
Jasně, a když spadne blbost(), tak to pěkně celý popadá na nějaký null pointery, že.... ať žije kvalitní kód...
pak stačí otestovat, jestli je c null, protože kontroly vstupů jsou přesně tam, kde mají být a to na začátku blbosti, kraviny a voloviny
Už to vidíš? Co vidíš... chápeš? Nebo je normální testovat raději vstup v programu třeba 80x, před každým voláním? Teda vlastně asi ano... bohužel...
Jojo, to je taky úžasný programování, testovat si na začátku každý funkce, jestli mi někdo neposlal null... Pak z toho vychází opravdu přehledný kód....
To je filosofie Go a ano, je to pragmatické a rozumné, ale jen proto, že můžu alokovat i na zásobníku a protože GC v Go je trojbarevný.
Proč by nemělo být pragmatické používat GC i tam, kde tohle třeba splněno není? Pokud není můj use-case zrovna v konfliktu s GC (možná v 95% případech není), tak proč GC nepoužít?
-
Jasně, a když spadne blbost(), tak to pěkně celý popadá na nějaký null pointery, že.... ať žije kvalitní kód...
pak stačí otestovat, jestli je c null, protože kontroly vstupů jsou přesně tam, kde mají být a to na začátku blbosti, kraviny a voloviny
Už to vidíš? Co vidíš... chápeš? Nebo je normální testovat raději vstup v programu třeba 80x, před každým voláním? Teda vlastně asi ano... bohužel...
Jojo, to je taky úžasný programování, testovat si na začátku každý funkce, jestli mi někdo neposlal null... Pak z toho vychází opravdu přehledný kód....
To je filosofie Go a ano, je to pragmatické a rozumné, ale jen proto, že můžu alokovat i na zásobníku a protože GC v Go je trojbarevný.
Proč by nemělo být pragmatické používat GC i tam, kde tohle třeba splněno není? Pokud není můj use-case zrovna v konfliktu s GC (možná v 95% případech není), tak proč GC nepoužít?
Protože to zbytečně žere paměť a vnáší nedeterminismus. Ono to nemusí vadit na serveru pro nenáročnou aplikaci, ale na omezeném systému (stačí mobil) je znát právě ten paměťový limit. I když zrovna u Go se dá procentuálně nastavit "agresivita" GC a asi by se většina problémů vyřešila. Pro ObjC zase existoval GC umožňující běh real-timových vláken, ale to už jsou okrajové záležitosti.
-
Jojo, to je taky úžasný programování, testovat si na začátku každý funkce, jestli mi někdo neposlal null... Pak z toho vychází opravdu přehledný kód....
Aha... takže pracujeme s absolutně deterministickým prostředím a daty, takže chyba nemůže nastat. Tím pádem nemusím nic kontrolovat ani před tím, ani potom a celá GOTO šaráda a všechny kecy kolem byly úplně mimo. Na co ale v takovém prostředí potřebuji GC?
-
Protože to zbytečně žere paměť a vnáší nedeterminismus. Ono to nemusí vadit na serveru pro nenáročnou aplikaci, ale na omezeném systému (stačí mobil) je znát právě ten paměťový limit. I když zrovna u Go se dá procentuálně nastavit "agresivita" GC a asi by se většina problémů vyřešila. Pro ObjC zase existoval GC umožňující běh real-timových vláken, ale to už jsou okrajové záležitosti.
Připadá mi, že v 95% případů člověk prostě žádné problémy nemá. A těch 5% je fakt někdy oříšek, který se někdy vyřeší nastavením GC a někdy třeba i tím, že se GC na některé věci prostě nepoužije. Ale z téhle diskuze mám pocit, jako kdyby GC bylo až na výjimky prakticky nepoužitelné....
-
Pardon, už to vím... to proto, abych z toho udělal prostředí nedeterministické a mohl si honit triko, jak jsem to pěkně rozbil.
-
Jojo, to je taky úžasný programování, testovat si na začátku každý funkce, jestli mi někdo neposlal null... Pak z toho vychází opravdu přehledný kód....
Aha... takže pracujeme s absolutně deterministickým prostředím a daty, takže chyba nemůže nastat. Tím pádem nemusím nic kontrolovat ani před tím, ani potom a celá GOTO šaráda a všechny kecy kolem byly úplně mimo. Na co ale v takovém prostředí potřebuji GC?
Ne. Data kontroluju při načítání. Proč by funkce měly kontrolovat, jestli jim někdo neposlal null jako parametr? To jako pak budu 80x kontrolovat, jestli ten jeden parametr se náhodou nedeterministicky v RAMce nezměnil na null?
-
Protože to zbytečně žere paměť a vnáší nedeterminismus. Ono to nemusí vadit na serveru pro nenáročnou aplikaci, ale na omezeném systému (stačí mobil) je znát právě ten paměťový limit. I když zrovna u Go se dá procentuálně nastavit "agresivita" GC a asi by se většina problémů vyřešila. Pro ObjC zase existoval GC umožňující běh real-timových vláken, ale to už jsou okrajové záležitosti.
Připadá mi, že v 95% případů člověk prostě žádné problémy nemá. A těch 5% je fakt někdy oříšek, který se někdy vyřeší nastavením GC a někdy třeba i tím, že se GC na některé věci prostě nepoužije. Ale z téhle diskuze mám pocit, jako kdyby GC bylo až na výjimky prakticky nepoužitelné....
Ten pocit je špatnej, rozdíl je v pojetí. Někdo to chce používat všude tam, kde tomu nic fakticky nebrání, podle někoho je lepší to použít jen tam, kde to má reálný přínos, který dostatečně vyváží nedostatky.
Když někdo tvrdí, že použití free je tak velká raketová věda, že s pravděpodobností limitně se blížící nekonečnu zanese do programu chyby, tak můžu říct maximálně tolik, že raději nemá programovat, protože s pravděpodobností limitně se blížící nekonečnu udělá dříve nebo později nějakou chybu i s GC.
-
Když někdo tvrdí, že použití free je tak velká raketová věda, že s pravděpodobností limitně se blížící nekonečnu zanese do programu chyby, tak můžu říct maximálně tolik, že raději nemá programovat, protože s pravděpodobností limitně se blížící nekonečnu udělá dříve nebo později nějakou chybu i s GC.
Tys fakt nikdy neudělal v programu chybu?
-
Aha... takže pracujeme s absolutně deterministickým prostředím a daty, takže chyba nemůže nastat. Tím pádem nemusím nic kontrolovat ani před tím, ani potom a celá GOTO šaráda a všechny kecy kolem byly úplně mimo. Na co ale v takovém prostředí potřebuji GC?
Proc bys neco testoval ... sak ono to nekde cestou zbuchne na nejakou neosetrenou vyjimku ... nebo jeste lip ... protoze 54E8 je taky cislo, takze ... vlastne vsechno projde zcela koser, jen ten vysledek bude nejak divnej, ale coz. Holt si uzivatel, kterej na to narazi, uzije trochu toho ladeni, protoze tvurce se bude bit v prsa, ze u nej je vse naprosto vporadku.
-
Protože to zbytečně žere paměť a vnáší nedeterminismus. Ono to nemusí vadit na serveru pro nenáročnou aplikaci, ale na omezeném systému (stačí mobil) je znát právě ten paměťový limit. I když zrovna u Go se dá procentuálně nastavit "agresivita" GC a asi by se většina problémů vyřešila. Pro ObjC zase existoval GC umožňující běh real-timových vláken, ale to už jsou okrajové záležitosti.
Připadá mi, že v 95% případů člověk prostě žádné problémy nemá. A těch 5% je fakt někdy oříšek, který se někdy vyřeší nastavením GC a někdy třeba i tím, že se GC na některé věci prostě nepoužije. Ale z téhle diskuze mám pocit, jako kdyby GC bylo až na výjimky prakticky nepoužitelné....
Zásadní problém už zmínil Tuxik - GC se nadužívá. Slušný kód v GC/RC jazyce má prostě alokovat vše, co jde, na zásobníku, což není problém v Go, .NET ani ObjC nebo Swiftu. Pak není problém ani relativně jednoduchý GC, protože odpadu je málo. Jen v Javě je problém, pročež pak autoři knihoven, aby mohli napsat efektivní kód, sahají k sun.misc.Unsafe, což sice zabere, ale kód je pak k poblití. Mimochodem nejlépe celé to GC funguje v Go i proto, že o tom, co se alokuje na haldě a co na zásobníku, rozhoduje překladač, takže "programátor", co ani nezná rozdíl mezi haldou a zásobníkem, to nemůže moc pokazit.
-
Ne. Data kontroluju při načítání. Proč by funkce měly kontrolovat, jestli jim někdo neposlal null jako parametr? To jako pak budu 80x kontrolovat, jestli ten jeden parametr se náhodou nedeterministicky v RAMce nezměnil na null?
A ty víš, co v těch funkcích je? Co když blbost(30) znamená "načti 30x po sobě hodnotu z analogového čidla"? Posuzuješ kód zcela neznámého účelu takovým způsobem, aby to sedělo na tvoje tvrzení. Já dokážu taky vymyslet případy, kdy to sedí na moje. Rozdíl je v tom, že tvůj postoj je striktní a snaží se vyloučit cokoliv jiného, zatímco já hned na začátku přiznal, že ačkoliv se přikláním k jednomu způsobu, striktně na něm netrvám a dokážu si představit i jiné situace.
-
Ne. Data kontroluju při načítání. Proč by funkce měly kontrolovat, jestli jim někdo neposlal null jako parametr? To jako pak budu 80x kontrolovat, jestli ten jeden parametr se náhodou nedeterministicky v RAMce nezměnil na null?
A ty víš, co v těch funkcích je? Co když blbost(30) znamená "načti 30x po sobě hodnotu z analogového čidla"? Posuzuješ kód zcela neznámého účelu takovým způsobem, aby to sedělo na tvoje tvrzení. Já dokážu taky vymyslet případy, kdy to sedí na moje. Rozdíl je v tom, že tvůj postoj je striktní a snaží se vyloučit cokoliv jiného, zatímco já hned na začátku přiznal, že ačkoliv se přikláním k jednomu způsobu, striktně na něm netrvám a dokážu si představit i jiné situace.
Tak asi bylo zřejmé, proč jsem ten příklad dával - že takhle vypadá spousta různých věcí. Například pokud by blbost(30) bylo čtení z analogového čidla a "null" znamenalo, že došlo k chybě, tak bys ten "null" do té funkce kravina() asi poslat neměl. Způsob, jak jsi ten kód napsal, v podstatě simuluje "maybe monad" a to není v C-like jazyku zrovna přehledný způsob programování.
Zásadní problém už zmínil Tuxik - GC se nadužívá.
Co to je "nadužívá"? Ano, je pravda, že spoustu věcí klidně vyřeší RAII nebo ARC. Ale co je špatné na použití GC? V 95% aplikací použití GC žádné problémy nepřinese, na druhou stranu moje zkušenost je, že jak nějakou aplikaci rozšiřuju, tak dřív nebo pozdějc narazím na něco, coby GC velmi snadno vyřešilo.
A Tuxík tady pořád šermuje s free(), takže jeho idea asi je, že i celé RAII/ARC je taky na houby....
-
Ne. Data kontroluju při načítání. Proč by funkce měly kontrolovat, jestli jim někdo neposlal null jako parametr? To jako pak budu 80x kontrolovat, jestli ten jeden parametr se náhodou nedeterministicky v RAMce nezměnil na null?
A ty víš, co v těch funkcích je? Co když blbost(30) znamená "načti 30x po sobě hodnotu z analogového čidla"? Posuzuješ kód zcela neznámého účelu takovým způsobem, aby to sedělo na tvoje tvrzení. Já dokážu taky vymyslet případy, kdy to sedí na moje. Rozdíl je v tom, že tvůj postoj je striktní a snaží se vyloučit cokoliv jiného, zatímco já hned na začátku přiznal, že ačkoliv se přikláním k jednomu způsobu, striktně na něm netrvám a dokážu si představit i jiné situace.
Tak asi bylo zřejmé, proč jsem ten příklad dával - že takhle vypadá spousta různých věcí. Například pokud by blbost(30) bylo čtení z analogového čidla a "null" znamenalo, že došlo k chybě, tak bys ten "null" do té funkce kravina() asi poslat neměl. Způsob, jak jsi ten kód napsal, v podstatě simuluje "maybe monad" a to není v C-like jazyku zrovna přehledný způsob programování.
Zásadní problém už zmínil Tuxik - GC se nadužívá.
Co to je "nadužívá"? Ano, je pravda, že spoustu věcí klidně vyřeší RAII nebo ARC. Ale co je špatné na použití GC? V 95% aplikací použití GC žádné problémy nepřinese, na druhou stranu moje zkušenost je, že jak nějakou aplikaci rozšiřuju, tak dřív nebo pozdějc narazím na něco, coby GC velmi snadno vyřešilo.
A Tuxík tady pořád šermuje s free(), takže jeho idea asi je, že i celé RAII/ARC je taky na houby....
1. Nezačínejme s monádami, please, to pak bude dalších 500 příspěvků o ničem.
2. Jak jsem psal, špatné je alokovat paměť na haldě, když by stačil zásobník. Toť vše. Jinak když je dost paměti, tak klidně GC až do aleluja.
-
Mně se fakt libí, že ze 3 řádků vytržených z kontextu se dá přesně říct, co všechno je blbě. Za chvíli mě tu někdo začne buzerovat za to, že mam tlačítko v GUI o kousek vlevo a že to není dostatečně ergonomické :-D RAII a RC je to samý v bledě modré. Má to use cases, ale neznamená to, že to musím použít.
-
Mně se fakt libí, že ze 3 řádků vytržených z kontextu se dá přesně říct, co všechno je blbě. Za chvíli mě tu někdo začne buzerovat za to, že mam tlačítko v GUI o kousek vlevo a že to není dostatečně ergonomické :-D RAII a RC je to samý v bledě modré. Má to use cases, ale neznamená to, že to musím použít.
Neskutečně blbý byl ten původní kód s několika goto. O tom tvém bez dodatečného kontextu nic říct nejde ;)
-
Mně se fakt libí, že ze 3 řádků vytržených z kontextu se dá přesně říct, co všechno je blbě. Za chvíli mě tu někdo začne buzerovat za to, že mam tlačítko v GUI o kousek vlevo a že to není dostatečně ergonomické :-D RAII a RC je to samý v bledě modré. Má to use cases, ale neznamená to, že to musím použít.
Neskutečně blbý byl ten původní kód s několika goto. O tom tvém bez dodatečného kontextu nic říct nejde ;)
Náhodou, mně se goto líbí, já začínal na basicu :-D nejraději bych do moderních jazyků protlačil povinné číslování řádků. :-D ale fakt mě dojímá, kolik jediných správných postupů v programování existuje :-(
-
No já bych se pustil do těch monád, bude legrace, co?
-
btw vetsina aplikaci pametove neustale roste, ne protoze leakuje, ale protoze drzi mnohe data zbytecne (ale lexikalne spravne tj zadna automatika jako GC nepomuze)
programator musi o pameti premyslet jako o vzacnem zdroji. kdyz ne, tak prave programy psane v jazicich s automatickym memory managementem jsou ty nejzravejsi, prave kvuli bezstarostnemu pristupu k pameti.
GC pomůže, může nepoužívanou ale aktivní paměť odsunout na disk. To je mechanismus starý 60 let. Naopak je často spíše problém, že dostupná paměť systému se nevyužívá.
Může mi někdo vysvětlit, proč se tu plete dohromady GC a swapování? Já myslel, že swap je záležitost OS a funguje bez ohledu na tom jestli daná aplikace používá GC či nikoliv. Nebo snad aplikace nevyužívající GC není možné odsunout na disk nebo co (to je spíše řečnická otázka)?
-
Mně se fakt libí, že ze 3 řádků vytržených z kontextu se dá přesně říct, co všechno je blbě. Za chvíli mě tu někdo začne buzerovat za to, že mam tlačítko v GUI o kousek vlevo a že to není dostatečně ergonomické :-D RAII a RC je to samý v bledě modré. Má to use cases, ale neznamená to, že to musím použít.
Neskutečně blbý byl ten původní kód s několika goto. O tom tvém bez dodatečného kontextu nic říct nejde ;)
Náhodou, mně se goto líbí, já začínal na basicu :-D nejraději bych do moderních jazyků protlačil povinné číslování řádků. :-D ale fakt mě dojímá, kolik jediných správných postupů v programování existuje :-(
Já nekritizuju goto jako takové, ale když někdo použije padesát návěstí, když stačí jedno, to je na exemplární potrestáni :)
-
No já bych se pustil do těch monád, bude legrace, co?
Chybí ti tam "li" - limonád. S těmi je legrace.
-
No já bych se pustil do těch monád, bude legrace, co?
Nechal bych to být, 99% lidí stejně neví, proč a nač to je.
-
btw vetsina aplikaci pametove neustale roste, ne protoze leakuje, ale protoze drzi mnohe data zbytecne (ale lexikalne spravne tj zadna automatika jako GC nepomuze)
programator musi o pameti premyslet jako o vzacnem zdroji. kdyz ne, tak prave programy psane v jazicich s automatickym memory managementem jsou ty nejzravejsi, prave kvuli bezstarostnemu pristupu k pameti.
GC pomůže, může nepoužívanou ale aktivní paměť odsunout na disk. To je mechanismus starý 60 let. Naopak je často spíše problém, že dostupná paměť systému se nevyužívá.
Může mi někdo vysvětlit, proč se tu plete dohromady GC a swapování? Já myslel, že swap je záležitost OS a funguje bez ohledu na tom jestli daná aplikace používá GC či nikoliv. Nebo snad aplikace nevyužívající GC není možné odsunout na disk nebo co (to je spíše řečnická otázka)?
Někdo chtěl spustit off-topic.
-
btw vetsina aplikaci pametove neustale roste, ne protoze leakuje, ale protoze drzi mnohe data zbytecne (ale lexikalne spravne tj zadna automatika jako GC nepomuze)
programator musi o pameti premyslet jako o vzacnem zdroji. kdyz ne, tak prave programy psane v jazicich s automatickym memory managementem jsou ty nejzravejsi, prave kvuli bezstarostnemu pristupu k pameti.
GC pomůže, může nepoužívanou ale aktivní paměť odsunout na disk. To je mechanismus starý 60 let. Naopak je často spíše problém, že dostupná paměť systému se nevyužívá.
Může mi někdo vysvětlit, proč se tu plete dohromady GC a swapování? Já myslel, že swap je záležitost OS a funguje bez ohledu na tom jestli daná aplikace používá GC či nikoliv. Nebo snad aplikace nevyužívající GC není možné odsunout na disk nebo co (to je spíše řečnická otázka)?
Někdo chtěl spustit off-topic.
uz zase me z vas boli hlava
-
Tak polopaticky. No v dobách, kdy byly každé boty šité na míru a nebylo to tak dávno, u nás před nějakými 150 lety, mnozí lidé chodili bosí. Kvalita obuvi dnes poklesla, většinou nemají boty šité na míru, ale chodí obutí. A vystačí si i s touto sníženou kvalitou. Otázka zní, jak je možno tu kvalitu ještě snížit, aby to bylo prodejné a udržela se rentabilita výroby bot, když mzdové náklady na výrobu v Číně rostou.
No a ten samý proces probíhá i v tvorbě software. S nárůstem poptávky a průmyslovou produkcí klesá kvalita.
Není nutně pravda. Průmyslová produkce často naopak znamená zlepšení kvality. Konec konců, zkuste si ručně vyřezat a vypilovat kolo nebo kuličku, aby bylo pravidelné, neházelo s přesností tisícin mm... Jsem zvědav, jestli to vaše ručně vyrobené kolo nebo kulička (třeba do ložiska) bude lepší než to průmyslově vyrobené... ;)
Z5 k botám - Kvalita nejen bot ale čehokoliv nesouvisí nutně s tím, jestli se to vyrábí na míru.
Můžu totiž vyrobit na míru a přitom vyrobit nekvalitně.
I v těch dávných dobách samozřejmě se vyráběly dreky. A ne vyždy se boty šily na míru. Protože když švec prodával na nějakém trhu, musel mít samozřejmě v zásobě hotové boty v několika velikostech které se nejběžněji kupují. To, že lidi chodili často bosí, s šitím na míru nesouvisí. Souvisí to s tím, že ruční šití je drahé a lidé byli chudí.
Průmyslová výroba to zlevnila, ale to neznamená, že by se průmyslově nedaly vyrobit kvalitní boty. Samozřejmě že dají, jenže to by manažeři a akcionáři tolik nevydělali, tak je třeba ošulit na nákladech, aby zbylo více do kapsy.
-
Tak polopaticky. No v dobách, kdy byly každé boty šité na míru a nebylo to tak dávno, u nás před nějakými 150 lety, mnozí lidé chodili bosí. Kvalita obuvi dnes poklesla, většinou nemají boty šité na míru, ale chodí obutí. A vystačí si i s touto sníženou kvalitou. Otázka zní, jak je možno tu kvalitu ještě snížit, aby to bylo prodejné a udržela se rentabilita výroby bot, když mzdové náklady na výrobu v Číně rostou.
No a ten samý proces probíhá i v tvorbě software. S nárůstem poptávky a průmyslovou produkcí klesá kvalita.
Není nutně pravda. Průmyslová produkce často naopak znamená zlepšení kvality. Konec konců, zkuste si ručně vyřezat a vypilovat kolo nebo kuličku, aby bylo pravidelné, neházelo s přesností tisícin mm... Jsem zvědav, jestli to vaše ručně vyrobené kolo nebo kulička (třeba do ložiska) bude lepší než to průmyslově vyrobené... ;)
Z5 k botám - Kvalita nejen bot ale čehokoliv nesouvisí nutně s tím, jestli se to vyrábí na míru.
Můžu totiž vyrobit na míru a přitom vyrobit nekvalitně.
I v těch dávných dobách samozřejmě se vyráběly dreky. A ne vyždy se boty šily na míru. Protože když švec prodával na nějakém trhu, musel mít samozřejmě v zásobě hotové boty v několika velikostech které se nejběžněji kupují. To, že lidi chodili často bosí, s šitím na míru nesouvisí. Souvisí to s tím, že ruční šití je drahé a lidé byli chudí.
Průmyslová výroba to zlevnila, ale to neznamená, že by se průmyslově nedaly vyrobit kvalitní boty. Samozřejmě že dají, jenže to by manažeři a akcionáři tolik nevydělali, tak je třeba ošulit na nákladech, aby zbylo více do kapsy.
ty boty uz bych radeji nevytahoval ...
-
Tak polopaticky. No v dobách, kdy byly každé boty šité na míru a nebylo to tak dávno, u nás před nějakými 150 lety, mnozí lidé chodili bosí. Kvalita obuvi dnes poklesla, většinou nemají boty šité na míru, ale chodí obutí. A vystačí si i s touto sníženou kvalitou. Otázka zní, jak je možno tu kvalitu ještě snížit, aby to bylo prodejné a udržela se rentabilita výroby bot, když mzdové náklady na výrobu v Číně rostou.
No a ten samý proces probíhá i v tvorbě software. S nárůstem poptávky a průmyslovou produkcí klesá kvalita.
Není nutně pravda. Průmyslová produkce často naopak znamená zlepšení kvality. Konec konců, zkuste si ručně vyřezat a vypilovat kolo nebo kuličku, aby bylo pravidelné, neházelo s přesností tisícin mm... Jsem zvědav, jestli to vaše ručně vyrobené kolo nebo kulička (třeba do ložiska) bude lepší než to průmyslově vyrobené... ;)
Z5 k botám - Kvalita nejen bot ale čehokoliv nesouvisí nutně s tím, jestli se to vyrábí na míru.
Můžu totiž vyrobit na míru a přitom vyrobit nekvalitně.
I v těch dávných dobách samozřejmě se vyráběly dreky. A ne vyždy se boty šily na míru. Protože když švec prodával na nějakém trhu, musel mít samozřejmě v zásobě hotové boty v několika velikostech které se nejběžněji kupují. To, že lidi chodili často bosí, s šitím na míru nesouvisí. Souvisí to s tím, že ruční šití je drahé a lidé byli chudí.
Průmyslová výroba to zlevnila, ale to neznamená, že by se průmyslově nedaly vyrobit kvalitní boty. Samozřejmě že dají, jenže to by manažeři a akcionáři tolik nevydělali, tak je třeba ošulit na nákladech, aby zbylo více do kapsy.
Tak manažeři ani akcionáři nevydělávají tolik, jako ti co nic nedělají, podíl státu na každém výrobku je vyšší než příjem majitelů a manažerů.
-
Opomíjíte jednu věc: jde o prachy. Lidé chtějí vědět, jak se jejich prachy točí, kolik jim to nese. Momentálně se ve velkém řeší big data, mimo jiné se řeší, jak z nich dostat online výsledky, ne proto, že by byly tak extrémě důležité (až na výjimky), ale proto, že je někdo prostě chce vidět. Ten někdo si za to kolikrát platí nemalé peníze. Jestli lidi za 3-7 let pochopí, že je to na nic, pak je to průchozí.
Mimochodem, mě opravdu ZAJÍMÁ, kde a jak mám uložený data, je to jedna z věcí, za které jsem slušně placenej :D
To programátoři mainframů před nástupem PC říkali taky. Bill Gates dlouho nevěřil v komerční úspěch internetu.
Jinak to za co jste placený, převezme vámi natrénovaný stroj. Není to přece žádná magie, ale znalosti, které často nevyužíváte vědomě, ale pouze jako výsledek automatického procesu, který nemáte pod kontrolou a proběhl ve vašem mozku. Uložení dat má navíc jen volnou vazbu na realitu, tu vazbu zprostředkovává jen gramatika dotazování, nic více. Takže můžete zpracovávat data, aniž byste jim rozuměl, můžete pracovat jen v rámci modelu, který je dán existující strukturou databáze.
Nedochází vám jedna věc, lidé většinu informací, které dnes potřebují, přestanou potřebovat, protože rozhodnutí za ně udělají stroje. Například budou-li zavedena samořiditelná auta masově, nebude třeba vytvářet grafická zobrazení map, protože stroj je nepotřebuje a nebude je potřebovat ani člověk, protože jen stroji sdělí číslo místa, kam se chce dostat, nebo jen vybere tvář člověka, se kterým se chce setkat.
Přejdeme do stádia black box civilizace.
To programátoři mainframů před nástupem PC říkali taky. - A co, mainframy existují dodnes.
Není to přece žádná magie, ... - Právě, že to je magie. Dodnes nevíme pořádně, jak funguje mozek. I takový neuron není jen jednoduchý tranzistor s jasně definovanými vstupy a výstupy.
...jen stroji sdělí číslo místa, kam se chce dostat... - A kde to číslo místa vezmu, když ho zpaměti znát nebudu a mapy nebudou?
Hloupé. My nevíme jaká kvalita je optimální. To hledá vzhledem k aktuálnímu stavu systému trh. Příliš kvality může škodit, alokuje se zbytečně mnoho zdrojů do nějakého projektu, který stejně zapadne, protože bude nepotřebný, nebude po něm poptávka. Například.
Pokud to nevíme, tak to neví ani ten trh. Protože kdo/co je trh? Trh tvoříme my. A pokud nejsem schopen specifikovat požadavek na kvalitu a tomu trhu to sdělit, tak ten trh to sám nepozná, když to nevim ani já sám.
Ale já vim, jakou kvalitu chci a podle toho vysílám signály trhu. Jestli je trh vyslyší, je jiná věc.
Jinak by mě zajímalo, jak vysvětlit blackboxové inteligenci s názvem Nový, že zbytečně alokuje a plýtvá zdroje, když z výstupu lezou nepoužitelný hnoje?
-
Opomíjíte jednu věc: jde o prachy. Lidé chtějí vědět, jak se jejich prachy točí, kolik jim to nese. Momentálně se ve velkém řeší big data, mimo jiné se řeší, jak z nich dostat online výsledky, ne proto, že by byly tak extrémě důležité (až na výjimky), ale proto, že je někdo prostě chce vidět. Ten někdo si za to kolikrát platí nemalé peníze. Jestli lidi za 3-7 let pochopí, že je to na nic, pak je to průchozí.
Mimochodem, mě opravdu ZAJÍMÁ, kde a jak mám uložený data, je to jedna z věcí, za které jsem slušně placenej :D
To programátoři mainframů před nástupem PC říkali taky. Bill Gates dlouho nevěřil v komerční úspěch internetu.
Jinak to za co jste placený, převezme vámi natrénovaný stroj. Není to přece žádná magie, ale znalosti, které často nevyužíváte vědomě, ale pouze jako výsledek automatického procesu, který nemáte pod kontrolou a proběhl ve vašem mozku. Uložení dat má navíc jen volnou vazbu na realitu, tu vazbu zprostředkovává jen gramatika dotazování, nic více. Takže můžete zpracovávat data, aniž byste jim rozuměl, můžete pracovat jen v rámci modelu, který je dán existující strukturou databáze.
Nedochází vám jedna věc, lidé většinu informací, které dnes potřebují, přestanou potřebovat, protože rozhodnutí za ně udělají stroje. Například budou-li zavedena samořiditelná auta masově, nebude třeba vytvářet grafická zobrazení map, protože stroj je nepotřebuje a nebude je potřebovat ani člověk, protože jen stroji sdělí číslo místa, kam se chce dostat, nebo jen vybere tvář člověka, se kterým se chce setkat.
Přejdeme do stádia black box civilizace.
To programátoři mainframů před nástupem PC říkali taky. - A co, mainframy existují dodnes.
Není to přece žádná magie, ... - Právě, že to je magie. Dodnes nevíme pořádně, jak funguje mozek. I takový neuron není jen jednoduchý tranzistor s jasně definovanými vstupy a výstupy.
...jen stroji sdělí číslo místa, kam se chce dostat... - A kde to číslo místa vezmu, když ho zpaměti znát nebudu a mapy nebudou?
Hloupé. My nevíme jaká kvalita je optimální. To hledá vzhledem k aktuálnímu stavu systému trh. Příliš kvality může škodit, alokuje se zbytečně mnoho zdrojů do nějakého projektu, který stejně zapadne, protože bude nepotřebný, nebude po něm poptávka. Například.
Pokud to nevíme, tak to neví ani ten trh. Protože kdo/co je trh? Trh tvoříme my. A pokud nejsem schopen specifikovat požadavek na kvalitu a tomu trhu to sdělit, tak ten trh to sám nepozná, když to nevim ani já sám.
Ale já vim, jakou kvalitu chci a podle toho vysílám signály trhu. Jestli je trh vyslyší, je jiná věc.
Jinak by mě zajímalo, jak vysvětlit blackboxové inteligenci s názvem Nový, že zbytečně alokuje a plýtvá zdroje, když z výstupu lezou nepoužitelný hnoje?
Trh je něco víc než my, je to náš souhrn, proto může nalézt řešení, které jednotlivci schopni nalézt nejsou, vláda pak je z hlediska řízení kolektivu v pozici jednotlivce, prakticky taky provádí jeden pokus na řešení problému tam, kde trh jich současně provádí 10 milionů.
Je to stejné, jako kdybyste dostal vagón písku a měl ho uspořádat do energeticky optimálního tvaru, gravitace to udělá sama a hned. Taky jen díky vzájemné interakci zrníček písku. Kdyby bylo možné gravitaci vypnout, jak byste tu úlohu vyřešil a vyřešil byste ji tak, že po opětovném zapnutí gravitace by nedošlo k samovolným přesunům písku? A to je přesně pozice jednotlivce vůči trhu. Bez gravitační zpětné vazby nevíte, jak halda může být v daných podmínkách vysoká.
-
@Lama
Vy máte dostat kvalitu optimální vzhledem ke všem ostatním, ne takovou, jakou požadujete. To máte jako africkými nájezdníky, taky nemohou všichni dostat kvalitu, kterou požadují. Buď ji dostanou oni, nebo vy.
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
-
Nevím proč tu chcete řečit GC a monády, já za vrchol programování považuju v kodu tohle:
On Error Resume Next
A samozřejmě bez ošetření. 8)
-
Nevím proč tu chcete řečit GC a monády, já za vrchol programování považuju v kodu tohle:
On Error Resume Next
A samozřejmě bez ošetření. 8)
Ale i to může mít opodstatnění, ne jako řešení chyby se kterou si nevíte rady, ale když je požadavek vybrat to, co vyhovuje daným podmínkám. Ze vstupních dat můžete vybírat jen to co vás zajímá a zbytek můžete zahodit.
-
@Lama
Vy máte dostat kvalitu optimální vzhledem ke všem ostatním, ne takovou, jakou požadujete. To máte jako africkými nájezdníky, taky nemohou všichni dostat kvalitu, kterou požadují. Buď ji dostanou oni, nebo vy.
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
ty musis mit hodne divoky sny chlapce
-
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
Problém je v tom, že každá opice má nevyvratitelný pocit vlastní dokonalosti a chtěla by kritické aplikace dělat stejně, jako dělá ten běžný odpad :P
-
@Lama
Vy máte dostat kvalitu optimální vzhledem ke všem ostatním, ne takovou, jakou požadujete. To máte jako africkými nájezdníky, taky nemohou všichni dostat kvalitu, kterou požadují. Buď ji dostanou oni, nebo vy.
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
ty musis mit hodne divoky sny chlapce
To znáte, ne. Každý má mít svou míru plnou. Vtip je v tom, že ty míry nejsou pro každého stejné a nejsou ani takové, jaké požadujete, jsou takové, jaké na vás připadnou, a to jaké na vás připadnou je mírou vašich schopností, píle, štěstí a i dílem náhody.
-
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
Problém je v tom, že každá opice má nevyvratitelný pocit vlastní dokonalosti a chtěla by kritické aplikace dělat stejně, jako dělá ten běžný odpad :P
No ono je to spíše tak, že každý má pocit, že staví kritickou aplikaci, když těch je jen pár. Ale samozřejmě, žádná práce se nemá odbývat, spíše je to v použitých nástrojích.
-
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
Problém je v tom, že každá opice má nevyvratitelný pocit vlastní dokonalosti a chtěla by kritické aplikace dělat stejně, jako dělá ten běžný odpad :P
Opice neví, že je opice :-)))
-
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
Problém je v tom, že každá opice má nevyvratitelný pocit vlastní dokonalosti a chtěla by kritické aplikace dělat stejně, jako dělá ten běžný odpad :P
Ta největší tragédie je, že opice zhusta neví, že je opice, i když má indicie ze všech stran. Aneb: Ignorance more frequently begets confidence than does knowledge.
-
@Lama
Vy máte dostat kvalitu optimální vzhledem ke všem ostatním, ne takovou, jakou požadujete. To máte jako africkými nájezdníky, taky nemohou všichni dostat kvalitu, kterou požadují. Buď ji dostanou oni, nebo vy.
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
ty musis mit hodne divoky sny chlapce
To znáte, ne. Každý má mít svou míru plnou. Vtip je v tom, že ty míry nejsou pro každého stejné a nejsou ani takové, jaké požadujete, jsou takové, jaké na vás připadnou, a to jaké na vás připadnou je mírou vašich schopností, píle, štěstí a i dílem náhody.
rad bych to nejak uzavrel - a fakticky si me uplne odrovnal - takze mi nezbyva nez s tebou souhlasit a rozhodne ano - mas pravdu a je to tak!
-
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
Problém je v tom, že každá opice má nevyvratitelný pocit vlastní dokonalosti a chtěla by kritické aplikace dělat stejně, jako dělá ten běžný odpad :P
Ta největší tragédie je, že opice zhusta neví, že je opice, i když má indicie ze všech stran. Aneb: Ignorance more frequently begets confidence than does knowledge.
ale je stastna - necht jsou vsechny bytosti stastny!
-
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
Problém je v tom, že každá opice má nevyvratitelný pocit vlastní dokonalosti a chtěla by kritické aplikace dělat stejně, jako dělá ten běžný odpad :P
Ta největší tragédie je, že opice zhusta neví, že je opice, i když má indicie ze všech stran. Aneb: Ignorance more frequently begets confidence than does knowledge.
ale je stastna - necht jsou vsechny bytosti stastny!
No jo, ale ti, co její výtvory používají, už méně.
-
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
Problém je v tom, že každá opice má nevyvratitelný pocit vlastní dokonalosti a chtěla by kritické aplikace dělat stejně, jako dělá ten běžný odpad :P
Ta největší tragédie je, že opice zhusta neví, že je opice, i když má indicie ze všech stran. Aneb: Ignorance more frequently begets confidence than does knowledge.
ale je stastna - necht jsou vsechny bytosti stastny!
No jo, ale ti, co její výtvory používají, už méně.
hele - ja to chtel po celym dni cteni techdle uletu zakoncit nejak optimisticky ... chapu - nemas den - a chces to na nekoho za kazdou cenu hodit ale ja mam opice docela rad - vlastne sem jedna z nich takze bych byl rad kdybych po dnesku mel take nejake vyhlidky jeste - verim ze opice i lopaty mohou koexistovat v miru!
-
...
Hloupé. My nevíme jaká kvalita je optimální. To hledá vzhledem k aktuálnímu stavu systému trh. Příliš kvality může škodit, alokuje se zbytečně mnoho zdrojů do nějakého projektu, který stejně zapadne, protože bude nepotřebný, nebude po něm poptávka. Například.
... dalsi zabijak - vystavni blabol :)
A vy to snad víte? Jistě chodíte v kožených botách šitých na míru. Tedy máte maximum kvality.
<trapne_ticho/>
Tak polopaticky. No v dobách, kdy byly každé boty šité na míru a nebylo to tak dávno, u nás před nějakými 150 lety, mnozí lidé chodili bosí. Kvalita obuvi dnes poklesla, většinou nemají boty šité na míru, ale chodí obutí. A vystačí si i s touto sníženou kvalitou. Otázka zní, jak je možno tu kvalitu ještě snížit, aby to bylo prodejné a udržela se rentabilita výroby bot, když mzdové náklady na výrobu v Číně rostou.
No a ten samý proces probíhá i v tvorbě software. S nárůstem poptávky a průmyslovou produkcí klesá kvalita.
Je zajímavé, jak rychle se ztrácí historická paměť.
Ne před 150 lety, ještě za druhé války se v létě na vesnicích běžně chodilo bosky.
-
A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.
Problém je v tom, že každá opice má nevyvratitelný pocit vlastní dokonalosti a chtěla by kritické aplikace dělat stejně, jako dělá ten běžný odpad :P
Ta největší tragédie je, že opice zhusta neví, že je opice, i když má indicie ze všech stran. Aneb: Ignorance more frequently begets confidence than does knowledge.
ale je stastna - necht jsou vsechny bytosti stastny!
No jo, ale ti, co její výtvory používají, už méně.
hele - ja to chtel po celym dni cteni techdle uletu zakoncit nejak optimisticky ... chapu - nemas den - a chces to na nekoho za kazdou cenu hodit ale ja mam opice docela rad - vlastne sem jedna z nich takze bych byl rad kdybych po dnesku mel take nejake vyhlidky jeste - verim ze opice i lopaty mohou koexistovat v miru!
Tak hodně štěstí s java(megalo)manem ;)
-
hele - ja to chtel po celym dni cteni techdle uletu zakoncit nejak optimisticky ... chapu - nemas den - a chces to na nekoho za kazdou cenu hodit ale ja mam opice docela rad - vlastne sem jedna z nich takze bych byl rad kdybych po dnesku mel take nejake vyhlidky jeste - verim ze opice i lopaty mohou koexistovat v miru!
Nene, jsi jen obyčejná lopata. Jak tu zaznělo - opice neví, že je opice - ale ty to víš, takže opice nejsi :D
-
AI nebude?
http://petr-kubac.blog.cz/1703/umela-inteligence-nebude
-
https://www.youtube.com/watch?v=ubaX1Smg6pY
asi nejhodnotnější příspěvek v celé diskuzi. Koukám už na třetí video s tímhle borcem a musim uznat, že to má v hlavě zatraceně dobře srovnaný.
-
AI nebude?
http://petr-kubac.blog.cz/1703/umela-inteligence-nebude
A na tos přišel kde ?
Kubáč pouze vysvětlil že mírně vyvynutá ANI-AGI náz s velkou pravděpodobností usmaží pokud k tomu bude mít prostředky.
Vzhledem k tomu že největší výzkum je na poli zelenejch mozku, tak bude mít těch smažících nástrojů tolik, že země bude pro emzáky takovej malej ohňostroj ...
A pak sou tady různí facebookove a googlove, který na AI taky pilně dělaj, a pokud se jim povede dostat na určitou úroveň že by začala mít choutky zdrhnout, bude to taky prča.
Ale snad bez raket.
-
btw vetsina aplikaci pametove neustale roste, ne protoze leakuje, ale protoze drzi mnohe data zbytecne (ale lexikalne spravne tj zadna automatika jako GC nepomuze)
programator musi o pameti premyslet jako o vzacnem zdroji. kdyz ne, tak prave programy psane v jazicich s automatickym memory managementem jsou ty nejzravejsi, prave kvuli bezstarostnemu pristupu k pameti.
GC pomůže, může nepoužívanou ale aktivní paměť odsunout na disk. To je mechanismus starý 60 let. Naopak je často spíše problém, že dostupná paměť systému se nevyužívá.
Může mi někdo vysvětlit, proč se tu plete dohromady GC a swapování? Já myslel, že swap je záležitost OS a funguje bez ohledu na tom jestli daná aplikace používá GC či nikoliv. Nebo snad aplikace nevyužívající GC není možné odsunout na disk nebo co (to je spíše řečnická otázka)?
to nevym
snad jedině že swap zabije tracing GC, protože ve chvíly kdy se skenuje heapa (nebo její část) která je ve swapu, musí se z něj vytáhnout což vyvolá další swap a tak dále. Ve výsledku je potom program kompletně nepoužitelný. To je také důvod proč je pro GC nutno mít kotel paměti.
Ruční správa je výrazně k paměti šetřivejší. Na druhou stranu, paměť je levná ... čas programátora ne.
-
Chtělo by to zákon, že každá AI by měla projít základním vzděláním. Hned v první třídě jí jako povinnou četbu naordinujeme Asimovovy zákony robotiky :D
-
Na druhou stranu, paměť je levná ... čas programátora ne.
Kecy v kleci. Paměť je levná jen do určité velikosti, potom její cena roste téměř exponenciálně, za určitou hranicí už je třeba přepisovat programy, měnit platformy (a přepisovat programy)... v ten moment platíš nehorázný peníze za HW a zároveň znovu a lépe platíš další čas programátora. A to jen proto, že bylo levnější to na začátku naprasit.
-
Na druhou stranu, paměť je levná ... čas programátora ne.
.
To je o mnozstve.
1MB usetrenej pamate < hodina programatora < 1TB usetrenej pamate
-
Tragédie. Poblité stoly a všude bordel.
Tři zakomplexovaní klučíci si honí triko, že znají c/C++ a možná i Rust a tím pádem jsou víc než ostatní. Vše mimo toho, že GC je největší zlo, jim uniká. Pár dalších, z nichž někteří o programování jen z dálky slyšeli, jim mohutně přizvukuje, protože přece paměti je pořád málo a vůbec, opravdový programátor přece není pojídač koláčů. Většině nedochází, že Java není synonymem pro GC, a že třeba velikost haldy lze omezit. Abych byl spravedlivý, jeden z těch klučíků později upozornil na to, že není GC jako GC a že v implementaci mohou být značné rozdíly.
Na všem je nejkomičtější to, že z celé diskuse byly nejpřínosnější (až na pár úletů) příspěvky všemi vysmívaného Nového. A pak se v tom vyznej.
Pokud mi chcete jadrně odpovědět, doporučuji si nejdřív projít celou diskusi znovu.
-
Náhodou, lidi co nevědí že nevědí jsou zábavní ;D
-
By se ovsem taky nemelo zapominat na fakt, ze JVM je napsany v C++, ergo cela Java neni nic jinyho nez takovy skriptik pro jednu C++ aplikaci... ergo byt (treba i senior) Java script-kiddie vubec jeste neznamena umet programovat v C++. Natoz efektivne.
-
By se ovsem taky nemelo zapominat na fakt, ze JVM je napsany v C++, ergo cela Java neni nic jinyho nez takovy skriptik pro jednu C++ aplikaci... ergo byt (treba i senior) Java script-kiddie vubec jeste neznamena umet programovat v C++. Natoz efektivne.
Java je pragmaticky jazyk. Low level java by zrovna vyzerala ako C. C je nevhodny jazyk pre aplikacne kodenie, ale velmi vhodny pre systemove. C ma kompilatory pre vela hw platforiem. Pisat kompilator "protojavy" do strojoveho kodu by bolo zbytocne plytvanie zdrojmi. Dalo by sa to, ale naco ... Preto je hotspot pisany v C (a bohuzial aj v C++). Takze super, ze si tu mastite kaspara, ale asi mate malo znalosti.
-
By se ovsem taky nemelo zapominat na fakt, ze JVM je napsany v C++, ergo cela Java neni nic jinyho nez takovy skriptik pro jednu C++ aplikaci... ergo byt (treba i senior) Java script-kiddie vubec jeste neznamena umet programovat v C++. Natoz efektivne.
No.... a c++ je jen skriptík pro stroják, ne? A stroják je jen skriptík pro procesor, což není nic jiného, než bludiště pro elektrony ;)
-
Náhodou, lidi co nevědí že nevědí jsou zábavní ;D
Vidím, že jste pochopil :-)))
-
Na druhou stranu, paměť je levná ... čas programátora ne.
Kecy v kleci. Paměť je levná jen do určité velikosti, potom její cena roste téměř exponenciálně, za určitou hranicí už je třeba přepisovat programy, měnit platformy (a přepisovat programy)... v ten moment platíš nehorázný peníze za HW a zároveň znovu a lépe platíš další čas programátora. A to jen proto, že bylo levnější to na začátku naprasit.
Program, který plýtvá pamětí (OOP, FP), lze snadněji přepsat na distribuovanou verzi. Optimalizovný program je třeba přepsat celý znovu.
-
Na druhou stranu, paměť je levná ... čas programátora ne.
Kecy v kleci. Paměť je levná jen do určité velikosti, potom její cena roste téměř exponenciálně, za určitou hranicí už je třeba přepisovat programy, měnit platformy (a přepisovat programy)... v ten moment platíš nehorázný peníze za HW a zároveň znovu a lépe platíš další čas programátora. A to jen proto, že bylo levnější to na začátku naprasit.
Program, který plýtvá pamětí (OOP, FP), lze snadněji přepsat na distribuovanou verzi. Optimalizovný program je třeba přepsat celý znovu.
jezismrajaaaaaaa
-
By se ovsem taky nemelo zapominat na fakt, ze JVM je napsany v C++, ergo cela Java neni nic jinyho nez takovy skriptik pro jednu C++ aplikaci... ergo byt (treba i senior) Java script-kiddie vubec jeste neznamena umet programovat v C++. Natoz efektivne.
Java je pragmaticky jazyk. Low level java by zrovna vyzerala ako C. C je nevhodny jazyk pre aplikacne kodenie, ale velmi vhodny pre systemove. C ma kompilatory pre vela hw platforiem. Pisat kompilator "protojavy" do strojoveho kodu by bolo zbytocne plytvanie zdrojmi. Dalo by sa to, ale naco ... Preto je hotspot pisany v C (a bohuzial aj v C++). Takze super, ze si tu mastite kaspara, ale asi mate malo znalosti.
Houby by se dalo napsat GC s necim, co samo na GC zavisi.
-
Na všem je nejkomičtější to, že z celé diskuse byly nejpřínosnější (až na pár úletů) příspěvky všemi vysmívaného Nového. A pak se v tom vyznej.
Vše je relativní. V této vysoce hodnotné diskusi dokonce ani Javaman nevypadal najednou tak špatně.
-
By se ovsem taky nemelo zapominat na fakt, ze JVM je napsany v C++, ergo cela Java neni nic jinyho nez takovy skriptik pro jednu C++ aplikaci... ergo byt (treba i senior) Java script-kiddie vubec jeste neznamena umet programovat v C++. Natoz efektivne.
Java je pragmaticky jazyk. Low level java by zrovna vyzerala ako C. C je nevhodny jazyk pre aplikacne kodenie, ale velmi vhodny pre systemove. C ma kompilatory pre vela hw platforiem. Pisat kompilator "protojavy" do strojoveho kodu by bolo zbytocne plytvanie zdrojmi. Dalo by sa to, ale naco ... Preto je hotspot pisany v C (a bohuzial aj v C++). Takze super, ze si tu mastite kaspara, ale asi mate malo znalosti.
Houby by se dalo napsat GC s necim, co samo na GC zavisi.
Este raz - v jave sa da napisat kompilator, ktory kompiluje "nieco" do strojoveho kodu. Len by ten kompilator musel copycat sposobom "odkukavat" funkcionalitu uz existujucich dlhymi rokmi odladenych kompilatorov, ako napr gcc. Takze napisat JVM v zjednodusenej jave Pepika Dvojbodku by bolo zbytovne pracne.
V systemovom programovani sa garbage collector nepouziva, lebo ide o iny druh programovania, ktore z podstaty musi byt low level. Takze si nieco nastudujte nez zacnete trollit.
-
By se ovsem taky nemelo zapominat na fakt, ze JVM je napsany v C++, ergo cela Java neni nic jinyho nez takovy skriptik pro jednu C++ aplikaci... ergo byt (treba i senior) Java script-kiddie vubec jeste neznamena umet programovat v C++. Natoz efektivne.
Java je pragmaticky jazyk. Low level java by zrovna vyzerala ako C. C je nevhodny jazyk pre aplikacne kodenie, ale velmi vhodny pre systemove. C ma kompilatory pre vela hw platforiem. Pisat kompilator "protojavy" do strojoveho kodu by bolo zbytocne plytvanie zdrojmi. Dalo by sa to, ale naco ... Preto je hotspot pisany v C (a bohuzial aj v C++). Takze super, ze si tu mastite kaspara, ale asi mate malo znalosti.
Houby by se dalo napsat GC s necim, co samo na GC zavisi.
Este raz ...
... ale uz skutecne naposled ...
-
https://www.youtube.com/watch?v=ubaX1Smg6pY
asi nejhodnotnější příspěvek v celé diskuzi. Koukám už na třetí video s tímhle borcem a musim uznat, že to má v hlavě zatraceně dobře srovnaný.
Kdo jiný už by v tom měl mít jasno, když ne člověk jako je on. ;)
(mimochodem, tento "borec", jak říkáš, třebaže ho většina BFU vůbec nezná, měl mnohem větší vliv na vývoj IT, než třeba novinářský maskot Jobs)
-
By se ovsem taky nemelo zapominat na fakt, ze JVM je napsany v C++, ergo cela Java neni nic jinyho nez takovy skriptik pro jednu C++ aplikaci... ergo byt (treba i senior) Java script-kiddie vubec jeste neznamena umet programovat v C++. Natoz efektivne.
Java je pragmaticky jazyk. Low level java by zrovna vyzerala ako C. C je nevhodny jazyk pre aplikacne kodenie, ale velmi vhodny pre systemove. C ma kompilatory pre vela hw platforiem. Pisat kompilator "protojavy" do strojoveho kodu by bolo zbytocne plytvanie zdrojmi. Dalo by sa to, ale naco ... Preto je hotspot pisany v C (a bohuzial aj v C++). Takze super, ze si tu mastite kaspara, ale asi mate malo znalosti.
Houby by se dalo napsat GC s necim, co samo na GC zavisi.
Este raz ...
... ale uz skutecne naposled ...
Aj 50 krat. Obhajci C++ pre vsetky pouzitia mavaju problemy s pamatou.
-
Nebude, za to bude dost hloupých trolů.
-
Nebude, za to bude dost hloupých trolů.
Hloupý troll je oxymoron.
-
By se ovsem taky nemelo zapominat na fakt, ze JVM je napsany v C++, ergo cela Java neni nic jinyho nez takovy skriptik pro jednu C++ aplikaci... ergo byt (treba i senior) Java script-kiddie vubec jeste neznamena umet programovat v C++. Natoz efektivne.
Java je pragmaticky jazyk. Low level java by zrovna vyzerala ako C. C je nevhodny jazyk pre aplikacne kodenie, ale velmi vhodny pre systemove. C ma kompilatory pre vela hw platforiem. Pisat kompilator "protojavy" do strojoveho kodu by bolo zbytocne plytvanie zdrojmi. Dalo by sa to, ale naco ... Preto je hotspot pisany v C (a bohuzial aj v C++). Takze super, ze si tu mastite kaspara, ale asi mate malo znalosti.
Houby by se dalo napsat GC s necim, co samo na GC zavisi.
To samozřejmě není pravda.
Příklad? Go. Od verze 1.4 je napsáno samo v sobě... (krásná formulace :D)
Samozřejmě se tehdy kompilace skokově zpomalila asi 3x (u velkých projektů), ale nyní je to už zhruba jen 1,5x. Na druhou stranu to má velkou výhodu v jednoduché přenositelnosti a křížových překladech.
-
By se ovsem taky nemelo zapominat na fakt, ze JVM je napsany v C++, ergo cela Java neni nic jinyho nez takovy skriptik pro jednu C++ aplikaci... ergo byt (treba i senior) Java script-kiddie vubec jeste neznamena umet programovat v C++. Natoz efektivne.
Java je pragmaticky jazyk. Low level java by zrovna vyzerala ako C. C je nevhodny jazyk pre aplikacne kodenie, ale velmi vhodny pre systemove. C ma kompilatory pre vela hw platforiem. Pisat kompilator "protojavy" do strojoveho kodu by bolo zbytocne plytvanie zdrojmi. Dalo by sa to, ale naco ... Preto je hotspot pisany v C (a bohuzial aj v C++). Takze super, ze si tu mastite kaspara, ale asi mate malo znalosti.
Houby by se dalo napsat GC s necim, co samo na GC zavisi.
To samozřejmě není pravda.
Příklad? Go. Od verze 1.4 je napsáno samo v sobě... (krásná formulace :D)
Samozřejmě se tehdy kompilace skokově zpomalila asi 3x (u velkých projektů), ale nyní je to už zhruba jen 1,5x. Na druhou stranu to má velkou výhodu v jednoduché přenositelnosti a křížových překladech.
Od 1.5
-
Tragédie. Poblité stoly a všude bordel.
.........
Na všem je nejkomičtější to, že z celé diskuse byly nejpřínosnější (až na pár úletů) příspěvky všemi vysmívaného Nového. A pak se v tom vyznej.
Pokud mi chcete jadrně odpovědět, doporučuji si nejdřív projít celou diskusi znovu.
Odpovím normálně. Spíše se zeptám, měl bych 2 otázky:
1: Tento výpotek blackboxové AI s názvem Nový bys zařadil kam, do nejpřínosnějších či do úletů?
Program, který plýtvá pamětí (OOP, FP), lze snadněji přepsat na distribuovanou verzi. Optimalizovný program je třeba přepsat celý znovu.
2: Jak se díváš na tu rozebíranou situaci s těma botama? ;) ;D
Náhodou, lidi co nevědí že nevědí jsou zábavní ;D
Vidím, že jste pochopil :-)))
Blackboxovou AI zn. Nový není možné pochopit... Je to autonomní systém jedoucí podle svých záhadných pravidel, kterou někdo spustil a již to není možné zstavit. Jednou nás to sežere všechny...
-
@Lama
Nešlo o blackboxovou AI, ale o blackboxovou civilizaci, kdy lidé budou méně rozhodovat, protože za ně mnoho rozhodnutí, které činí dosud, udělá AI a z toho logicky plyne, že se k nim dostane méně informací a ani je nebudou potřebovat, protože rozhodnutí, která na jejich základě bylo třeba učinit, už udělala AI. Prostě umělé věci budou fungovat a lidé nebudou vědět proč, což dnes ví a vědět to přestanou. Dokonce ani nebudou vědět, jak vznikly.
-
jojo - takovy lidi jako je Novy si celej zivot zvatlaj - nikdo jim nerozumi a vsichni si z nich delaj srandu a pak pridou s neco jako teorie relativity nebo podobnym blabolem ... ja mu drzim palec - respekt - nicmene nektery veci by si mohl odpustit - to s tema botama bylo proste za carou ...
-
Tak ono neni žvatlání jako žvatlání. Pokud někdo žvatlá pátý přes devátý a evidentně neví vo co go a myslí si, že je Einstein, no tak prosim, no.
to s tema botama bylo proste za carou ... - víc věcí tu bylo za čarou (GC vs. swap)
Prostě umělé věci budou fungovat a lidé nebudou vědět proč, což dnes ví a vědět to přestanou. - Někdo jim zakáže vědět? To mi příde jako dost podceňování lidské zvídavosti a zvědavosti. Nepochybuji o tom, že i v budoucnu budou zvídaví a zvědaví lidé, toužící po poznání. Jasně, že většinu to nebude zajímat, ale to už nezajímá teď. Konec konců, kolik lidí ví to, na jakých principech fungují počítače a co se asi tak zhruba děje uvnitř. A myslím, že v budoucnu to bude stejné. 90% lidí je to jedno a pak je tu pár % těch, kteří se rádi v něčem vrtaji a šťouraji. A tak to bude furt.
-
Tak ono neni žvatlání jako žvatlání. Pokud někdo žvatlá pátý přes devátý a evidentně neví vo co go a myslí si, že je Einstein, no tak prosim, no.
to s tema botama bylo proste za carou ... - víc věcí tu bylo za čarou (GC vs. swap)
Prostě umělé věci budou fungovat a lidé nebudou vědět proč, což dnes ví a vědět to přestanou. - Někdo jim zakáže vědět? To mi příde jako dost podceňování lidské zvídavosti a zvědavosti. Nepochybuji o tom, že i v budoucnu budou zvídaví a zvědaví lidé, toužící po poznání. Jasně, že většinu to nebude zajímat, ale to už nezajímá teď. Konec konců, kolik lidí ví to, na jakých principech fungují počítače a co se asi tak zhruba děje uvnitř. A myslím, že v budoucnu to bude stejné. 90% lidí je to jedno a pak je tu pár % těch, kteří se rádi v něčem vrtaji a šťouraji. A tak to bude furt.
me by zajimal podle jakyho vzoru zanikaj diskuse na rootu trebas - jestli existuje nakej pattern pro to udrzet jedno tady to shitstorm-vlakno tak aby se propracovalo az na uplnou jednicku - zatim vede: SW pro odhad počtu shromážděných lidí - do toho bych to na zacatku nikdy nerekl ...
-
Tak ono neni žvatlání jako žvatlání. Pokud někdo žvatlá pátý přes devátý a evidentně neví vo co go a myslí si, že je Einstein, no tak prosim, no.
to s tema botama bylo proste za carou ... - víc věcí tu bylo za čarou (GC vs. swap)
Prostě umělé věci budou fungovat a lidé nebudou vědět proč, což dnes ví a vědět to přestanou. - Někdo jim zakáže vědět? To mi příde jako dost podceňování lidské zvídavosti a zvědavosti. Nepochybuji o tom, že i v budoucnu budou zvídaví a zvědaví lidé, toužící po poznání. Jasně, že většinu to nebude zajímat, ale to už nezajímá teď. Konec konců, kolik lidí ví to, na jakých principech fungují počítače a co se asi tak zhruba děje uvnitř. A myslím, že v budoucnu to bude stejné. 90% lidí je to jedno a pak je tu pár % těch, kteří se rádi v něčem vrtaji a šťouraji. A tak to bude furt.
me by zajimal podle jakyho vzoru zanikaj diskuse na rootu trebas - jestli existuje nakej pattern pro to udrzet jedno tady to shitstorm-vlakno tak aby se propracovalo az na uplnou jednicku - zatim vede: SW pro odhad počtu shromážděných lidí - do toho bych to na zacatku nikdy nerekl ...
Někdo napíše něco rozumného k věci a póvl to ubije - stokrát nic umořilo vola, Zemana a já nevím co všechno...
-
Tak ono neni žvatlání jako žvatlání. Pokud někdo žvatlá pátý přes devátý a evidentně neví vo co go a myslí si, že je Einstein, no tak prosim, no.
to s tema botama bylo proste za carou ... - víc věcí tu bylo za čarou (GC vs. swap)
Prostě umělé věci budou fungovat a lidé nebudou vědět proč, což dnes ví a vědět to přestanou. - Někdo jim zakáže vědět? To mi příde jako dost podceňování lidské zvídavosti a zvědavosti. Nepochybuji o tom, že i v budoucnu budou zvídaví a zvědaví lidé, toužící po poznání. Jasně, že většinu to nebude zajímat, ale to už nezajímá teď. Konec konců, kolik lidí ví to, na jakých principech fungují počítače a co se asi tak zhruba děje uvnitř. A myslím, že v budoucnu to bude stejné. 90% lidí je to jedno a pak je tu pár % těch, kteří se rádi v něčem vrtaji a šťouraji. A tak to bude furt.
Inteligence aby měla smysl, musí dostat volnost v rozhodování, získají-li stroje větší inteligenci, například tvůrčí, tak musí dostat svobodu tvořit, jinak by to nemělo smysl. To je logické ne. No ale ta svoboda zároveň znamená, že informace, které vedou k jejímu uplatnění, už dál neputují, jsou zkonzumovány tím tvůrčím aktem. Představte si, že máte inteligentní 3D tiskárnu jídla, hladový na ni zahučíte, večeře, a za chvíli z ní vypadne něco, co se bude podobat mořskému plodu z Ordoviku, sníte ho a ani vás nenapadne přemýšlet, odkud tiskárna vzala inspiraci a to vše proto, že jí došla zásoba želé. Protože to sníte a nevyhodíte, tiskárna recept nasdílí jiným tiskárnám a vznikne mezi lidmi zvyk jíst mořské plody z Ordoviku :-))) A to bude zrod blackboxové civilizace. Věci se budou objevovat, aniž byste znal příběh jejich vzniku.
Dnes je to jinak, prodává i ten příběh vzniku, zářným příkladem jsou produkty Apple.
A ty boty, boty to je de facto kultovní československý produkt, výroba bot v Baťových závodech byla chlouba českého předválečného průmyslu. Znamení nové doby, stejně jak ještě nedávno bylo PC, dnes chytrý telefon. Proto jsem ten příměr použil :-)))
-
... Proto jsem ten příměr použil :-)))
... odhaleni se nekona kamarade a vtipny to neni - nemuzes preci nekoho utlouct nudou a potom cekat ze ti bude lustit nejake odhaleni - jestli teda vo to slo ... musis na tom este zapracovat a bude to supr!
-
zboj se dneska zarekl ze uz do tohodle neprispeje ani tecku ale stejne mu to nedalo :) uplne ho vidim jak si vcera vecer rval vlasy ze uz se na to muze vysrat - ze sou vsichni stejne dementi - ale proste 1.4 kdyz je to 1.5 - nene - to se musi napravit :)
-
http://dariusforoux.com/30-things-about-life-wish-known-10-years-ago/