Vlákno názorů k článku Programovací jazyky z vývojářského pekla od balki - Najhorsie je suverenne C++, kazdy program v nom...

No potom je potřeba "uměle" zvyšovat čitelnost rozekáním (i svého programu) do malých funkcí, z nichž každá dělá svou práci a má dobře zdokumentované rozhraní (někdy stačí správné jméno). Potom při čtení progamu stačí zkontrolovat tu funkci, že na _všechny_ možné vstupy udělá to co tvrdí její dokumentace bez studia vlastního programu a naopak zkontrolovat, že program využívá tu funkci v souladu s dokumentací (neposílá do ní vstupy, pro které nemá funkce definované chování), bez ohledu na implementaci. Dřive zmíněné konstrukce mi umožňují tyto malé celky někdy nepsat jako samostatné funkce, protože nezvýší objem kontextu na danném místě programu.

jj, tomu rozsekání se říká atomizace. Jak velká respektive atomická, to už je na každém, spíš asi otázka na Coding style.
Jak už tu někdo psal. Kdo píše jak čuně, tak bude jak čuně psát v každém jazyku.

To každopádně souhlas. Jestli je to správně nevím a ani to řešit nehodlám. Mě se líbí rozmanitý svět. Jen bych ty ostatní jazyky pro ty, kteří to zvládají, nehaněl.

Proti PHP nic nemám. Asi to není zářný příklad nej nej skvělejšího jazyka, ale má širokou podporu ve všech směrech, v distribucích, serverech, standardech a na scriptování s podporou OOP je parádní. Má silné možnosti přístupu k souborům, k databázi, silně podporuje práci se stringy a má dobrou podporu pro přenosové protokoly. A to je na webu potřeba. Ano, je hodně benevolentní. takže si ho spousta lidí plete s jednoduchým jazykem. tak to ale není. PHP umožní velké přemety, o to ale lépe musí programátor vědět co dělá. Ale beru, je to taková klasika, nic exotického.

> třeba vlastní parser pro specifické XML. Nikde v FP není funkce naparsujMiZrov­naTohleMojeXML ...a tak tedy ať tak nebo tak, budu muset jít řádek po řádku

Ono záleží na tom, co člověk chce - ale já třeba nedávno potřeboval ani ne tak parsovat, jako spíš modifikovat existující XML. A najednou zjistíš, že existuje knihovna ve stylu "xpath", snadno rozšiřitelná o další "operátory", "filtry", a když to ještě zkombinuješ s nějakými knihovnami pro práci se stavy, tak najednou máš v podstatě něco, co má třeba funkcionalitu XSLT. Bez jakékoliv přímé podpory jazyka, je to jenom knihovna. A tohle jsou věci, které jsem nikdy pořádně v OOP neviděl a netuším, jestli vůbec něco takového je principiálně možné.

No, v OOP, to je spíš language specific. Třeba v PHP je několik takových rozšiřitelných parserů už přímo v jazyku, podle úrovně ve které pracují. Možná se pletu, ale v C nic takového přímo v jazyku není a musela by to být šílenost :-)

Ale já tím jen chtěl ukázat, že jakmile začne někdo dělat nějaké nestandardní operace a programy, tak ta výhoda FP že na všechno je funkce a vše je na jeden řádek, padá. Ale nezatracuji FP, je to jiný přístup na jiné úkoly ale proto bych ani ty poslední dobou "tradiční" jazyky nezatracoval.

V Clojure nevím přesně, nepotkal jsem, beru co píšete. Ale vím bezpečně, že v PHP je SImpleXML, která to taky celé načte a rozseká, ale zkuste to udělat pro XML s 50 miliony hodnot, to se ani nebavím o atributtech v elementech atd. Ano, takové jsem měl, byla to odpověď serveru. Nesmím napsat odkud to bylo. Bylo to tom, že se to nevlezlo do paměti na serveru, takže proto bylo potřeba napsat parser, který to načítá dávkově ze souboru a pamatuje si zanoření v elementech samozřejmě, protože jinak s ohledem na pamět: nashledanou, sek a pád Vtip jev tom, že to množství prostě paměť najednou nedá.
Stejně ani nevím, jak se liší list(Clojure) a array(PHP) nebo array(C/C++/Java) v při uložení v operační paměti. TIpuji že to bude velmi podobná řada bytes za sebou s nějakou adresací podle dat. typu.

:-D No jo no. V tom mém případě šly všechny záznamy poptat jedině pře API najednou. Takže v podstatě to samé.
Díky za náhled do ukládání v Clojure.

Tak ony existují i streaming parsery a vůbec nemusí jenom o "SAX" parsery... a právě v těch FP jazycích mohou mít ty streaming parsery hodně zajímavou funkcionalitu. Třeba konkrétně není problém parsovat velký JSON soubor a pokud je možné tu operaci provést "jednoprůchodově" (nebo aspoň načíst podmnožinu dat, se kterou se bude pracovat), tak je to velmi triviální záležitost. Práce se streaming parsery v Javě pro složitější struktury není úplně příjemná...

> Ale já tím jen chtěl ukázat, že jakmile začne někdo dělat nějaké nestandardní operace a programy, tak ta výhoda FP že na všechno je funkce a vše je na jeden řádek, padá. Ale nezatracuji FP, je to jiný přístup na jiné úkoly ale proto bych ani ty poslední dobou "tradiční" jazyky nezatracoval.

Ale tak to není - vůbec nejde o "nestandardní" programy. V mnoha FP jazycích jsou možné abstrakce, které v imperativních jazycích v drtivé většině nejdou. Takže je vysoce pravděpodobné, že pokud ten problém není ve stylu "veškerá abstrakce nemožná", tak se to v FP podaří namodelovat mnohem jednodušeji.

Já vím, že tohle je zase debata ve stylu "a můj jazyk je lepší", ale zrovna teď jsem dělal "jednořádkovou" změnu v kódu a prostě v OOP by tohle snad vůbec nebylo možné - využívám polymorfismus v návratové hodnotě, typeclassy, monady... takže ve výsledku je to operace skutečně prakticky "na 1 řádku", akorát překladač se docela nadře. Ne, že by to v OOP úplně nešlo - šlo, ale člověk se docela nadře a fakt to nebude na 1 řádku...

Nech být, když jsem se prvně setkal s knihovnou setjmp, tak jsem na to koukal jak puk :D A to prý v C nejsou výjimky...

A i na tom Cčku bych nemusel nechat chlup suchý, třeba je krása, když potřebuju tabulku s několika paramery, indexovanou nějakým číslem:
- Indexování enumem. To je OK.
- Když v enumu nepřiřadím hodnoty, tak na konce dám další položku a mám počet. To je OK.
- Řádek z té tabulky se dá narvat do struktury. To je OK.
- Řádky se dají hodit do pole s velikostí z enumu. To je OK.
Ale když to chci náhodou všechno spojit, musím si hlídat pořadí a počty řádků na dvou místech, aby to korespondovalo, enum v .h, data musí být v .c a vytažený pomocí inline funkcí nebo zhovadilost typu external...

Áno, s tým sa dá samozrejme iba súhlasiť. Extrémne povedané, kód sa píše pre ľudí, nie pre počítače. Aspoň za predpokladu, že človek nie je osamelý vlk.

Potom je ale väčšina tejto diskusie zbytočná, pretože ak píše človek kód pre ľudí, vyhne sa neprehľadným technikám. :) Aj keď samozrejme platí, že s narastajúcimi znalosťami rastie schopnosť čítať cudzí kód. Takže treba nájsť sadu výrazových prostriedkov jazyka, ktorá je dostatočne výkonná a zároveň dostatočne pochopiteľná celému spektru ľudí, ktorí s kódom na danom projekte prídu do kontaktu.

Veľa častí boostu je takých aké sú nie preto, lebo C++ podporuje šablóny, ale preto, lebo C++ šablóny nepodporovalo dostatočne, teda napríklad neboli variadické šablóny a nie je ešte schválená podpora konceptov, takže tieto veci bolo nutné rozpísať v existujúcom šablónovom jazyku a navyše z toho vychádzajú komplikované chybové hlásenia. Je možné, že boost po schválení C++17 bude vyzerať oveľa jednoduchšie, dáva to celkom zmysel, kto by chcel udržiavať komplikovaný kód, keď ho môže zjednodušiť.

Keď sa ale odvolávame na to, čo je v boost-e, treba si uvedomiť, že boost je knižnica nie aplikácia, teda sa predpokladá, že ho píšu (a čítajú) "trochu pokročilejší" programátori. Koľko z nás tu do boost-u prispieva? Ja teda nie..

Suhlasim skoro zo vsetkym co pisete. Len som tym chcel prave ukazat, ze prave C++ v rukach "pokrocileho" programatora moze byt vdaka moznostiam C++ celkom tazko citatelne. Da sa namietnut (a aj s tym sihlasim), ze dokonala znalost C++ by pomohla ale realne by ma zaujimalo kolko ludi prestudovalo napr cely popis templatov a vsetky specialitky tam. Proste niekedy je tazke sa zorientovat v tom co sa deje nehovoriac o dementnom popise chyby v kompilatoroch, niekedy najst v tom popise co je zle je uloha hodna detektiva.

Možno to bude tým, že aj v reálnom živote je niečo za niečo. Ak chcem široké spektrum možností, musím mať široké spektrum znalostí, neviem, či to môže byť inak, aj keď by som si to naozaj veľmi prial.

Už som ale písal vyššie, že ak sa programuje v tíme, je potrebné vybrať podskupinu jazyka, ktorá má dostatočné vlastnosti a ktorej rozumie čo najviac členov tímu.

Podľa mojich skúseností väčšina chýb je šablónového charakteru a nastáva vtedy, keď niekam dám niečo, čo tam nepatrí. Kontrola konceptov to rieši a chybové hlásenia sa stanú zrozumiteľnými, pretože jednoducho hlásením bude, že niečo nezodpovedá očakávanému konceptu a nie tak ako je to teraz, že chyba je hlásená v tisícej vnorenej funkcii naoko vôbec nesúvisiacej s používateľským kódom.

A potom dojdeme k situacii, ked vykopnu z pohovoru skoro kazdeho uchadzaca o poziciu C++ programatora, lebo neovlada milion piate rozsirenie z milon siedmych. Toto rozsirenie ovsem ovlada iba ten, co zadava test.

1. to je predsa blbosť toho, kto takýto pohovor vedie, nie chyba jazyka

2. odvolávanie sa na rozšírenia mi pripomína odvolávanie sa na goto, čo je v roku 2016 v C++ naozaj nezmysel, zvlášť keď sa všade odporúča písať kód kompatibilný so štandardom.

Heheh, odporuca sa pisat ... :)))

Potom clovek otvori cudzi kod a vsetky "odporucania sa" su v cudu :)

Prečo? Nemáte pravidlá pre používanie cudzieho kódu?? Alebo snáď vo vašom tímovom kóde preberáte pravidlá z cudzieho kódu a nemáte vlastný štandard? Takže koľko dodávateľov toľko importovaných pravidiel? Alebo čo konkrétne si tým chcel povedať?

Aby som to upresnil, existujú snahy o harmonizáciu znalostí, jedným z pokusov je kniha C++ Common Knowledge: Essential Intermediate Programming, Stephen C. Dewhurst, bola vydaná určite pred viac ako 10 rokmi, pretože osobne ju mám už minimálne 10 rokov, existuje veľa iných kníh, ktoré popisujú, čo je dobrá technika a čo nie je, takže kto chce, má možnosť nájsť si svoju cestu.

Aj to je odpoveď.. :)

Skor konstatovanie.