Příspěvky

496

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 17:10:49 »

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

497

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 16:35:36 »

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

498

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 16:30:11 »

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.

499

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 16:29:01 »

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"

500

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 16:16:06 »

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.

501

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 16:09:34 »

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.

502

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 16:07:21 »

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.

503

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 15:51:49 »

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.

504

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 15:45:02 »

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:

Kód: [Vybrat]

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

505

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 15:42:01 »

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:

Kód: [Vybrat]

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.

506

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 15:33:10 »

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

Kód: [Vybrat]

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

Kód: [Vybrat]

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

507

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 15:30:53 »

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

Kód: [Vybrat]

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

Kód: [Vybrat]

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

508

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 15:13:46 »

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

Kód: [Vybrat]

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

Kód: [Vybrat]

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.

509

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 15:00:20 »

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?

510

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 14:58:36 »

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

Kód: [Vybrat]

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.