Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

[andy]

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é....

[Reklama]

[Tuxik]

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.

[andy]

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?

[Tuxik]

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.

[andy]

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?

[Reklama]

[j]

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.

[zboj]

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.

[Tuxik]

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.

[andy]

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....

[zboj]

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.

[Tuxik]

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.

[zboj]

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

[Tuxik]

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 :-(

[Tuxik]

No já bych se pustil do těch monád, bude legrace, co?

[Lama]

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)?