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

[andy]

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

[Reklama]

[zboj]

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.

[andy]

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

[Jenda]

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

[Ivan Nový]

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é 

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.

[Reklama]

[Tuxik]

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.

[jpu]

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.

[andy]

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

[balki]

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

[jpu]

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.

[j]

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.

[Tuxik]

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?

[mervin]

Budoucnost programování? Asi tak.
http://objevit.cz/umela-inteligence-od-microsoftu-umi-programovat-lepe-nez-clovek-t216644

[balki]

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

[Tuxik]

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.