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

[zboj]

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.

[Reklama]

[andy]

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

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?

[ferren]

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

[JS]

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

[jpu]

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.

[Reklama]

[zboj]

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.

[zboj]

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?

[Ondra Satai Nekola]

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?

[zboj]

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.

[Tuxik]

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);
}
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š.

[Ivan Nový]

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.

[Ondra Satai Nekola]

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.

[zboj]

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

[Ondra Satai Nekola]

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);
}
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.

[Ondra Satai Nekola]

To nebude plnohodnotné GC, ale buď RC nebo v podstatě RAII. Výhody snad vidí každý.

Ano, muzes prudit do ostatnich.