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

[Tuxik]

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.

[Reklama]

[zboj]

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.

[v]

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

[balki]

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.

[andy]

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

[Reklama]

[zboj]

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"

[zboj]

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.

[Tuxik]

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.

[zboj]

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

[andy]

Kód: [Vybrat]

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

[Tuxik]

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

[zboj]

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

[andy]

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?

[zboj]

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.

[Tuxik]

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?