REDGUY: myslím se dostáváme k otázce, co to znamená v dnešní době "programátor". (a o tom byl i ten vtip s operátory a dynamickým typováním v javascriptu...)

WILD_A: Kolik procent programatoru pravidelne programuje TSP o 10000 bodech a o rad vejs a pridava k tomu dalsi podminky? Nebo i kolik programatoru vi (bez googlovani) jak to efektivne resit? Heh, kolik programatoru vubec hned z hlavy vi co ta zkratka znamena?

Samozrejme ze najdes specialni pripady kdy ten vykon potrebujes, o tom zadna. Ale pro naprostou vetsinu situaci a naprostou vetsinu programatoru je hrubej vykon sekundarni, primarni je jak snadno se pisou a udrzujou slozite programy. A pokud se bavime o uceni se, jak spravne programovat, tak je lepsi si TSP implementovat v jazyce, kterej ti umozni soustredit se na algoritmus i za cenu o neco nizsiho vykonu. Ostatne, viz [ FLEGMA @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] .

WILD_A: S tim algoritmem pro grafy jsi mi pripomel, jak jsem cetl knizku Struktury dat od Berztisse, docela obsolete - rok 1979 a u algoritmu pro hledani cyklu v orientovanem grafu bylo doporuceni, at se nepousti pro graf s prilis velkym poctem uzlu kvuli vypocetni narocnosti a to cislo bylo uplne smesne - ted si nepamatuju jestli 20 nebo 50 :-) V praci jsem tentyz problem resil lepsim algoritmem (vytuneny Tarjan) a na modernim hw, grafy do 1000 uzlu a vysledky v radu milisekund. Kolega prede mnou resil ulohu bruteforcem a u mensich grafu se cekalo na vysledek minuty, u vetsich padalo na pamet, tam by nepomohl ani lepsi hw :-)

REDGUY: Nepotrebujeme vetsi vykon? Jak rychle vyresis TSP o 10000 bodech a jak rychkle kdyz to bude o rad vejs? A kdyz tomu pridam dalsi podminky? Jasne je svet aplikaci pro vice nebo mene BFU a tam s vykonem uz moc neziskavame, ale NLP, computer vision a podobny veci by z lepsiho vykonu taky dokazali tezit i pro beznyho uzivatele. Ale hlavne i nadale existuje velkej balik NP problemu, kde lepsi vykon dost pomaha. Kdyz jsem uz zacal s TSP tak pred nedavnem bylo TSP o par tisicich bodech velka vec, dneska to zvladnu na svym laptopu do minuty a neni toho dosazeno paralelizaci ani lepsim algoritmem, ten se od 90tych let nezlepsil.

Takze ja bych s tebou nesouhlasil, dost zalezi v jakym svete se pohybujes.

XCHAOS: Promin, ale kdyz se ti bez chyby prelozi C program, tak nemas jistotu vubec zadnou. Nevim na co presne narazis zminkou o "skriptech", ale jestli ti jde o typovou kontrolu, tak prekvapive existuji jine jazyky nez C ktere ji maji, v rade pripadu i mnohem lepsi.

REDGUY: já nejsem nijak striktní. poslední zásahy do nějakého kódu, co jsem udělal, se týkaly drobných oprav skriptů v shellu nebo php ... pár řádek jsem spáchal i v Pythonu... V C bych dělal rád, ale jaksi ... bez nějakého toolkitu a vůbec základní odvahy k tomu není motivace.

ale když už jsem pochochopil, co je potřeba k napsání robustního a stabilního C kódu (tedy, nesnažit se přistupovat k NULL pointerům, což se člověk na druhou stranu naučí po čase téměř automaticky a dává to i do každé podmínky a tak), tak je mu to líto zahodit. je to jako by si už jednou zvládl salta na snowboardu (tam je teda nezvládám, ale umím si představit, jaký by to byl pocit), ale nebylo by pro to uplatnění a všichni by ti vysvětlovali, že jezdit na sáňkách je daleko lepší, protože to můžou dělat všichni.

prostě jistotu, kterou mám, když se mi bez chyby přeloží nějaký C program (a vím, že jsem v něm nedělal zásah do modulů, které už jsou prověřené jako stabilní), tu mi žádný skript prostě nedá.

JANFROG: No prave. Proto mi XChaosovo striktni trvani na C prijde smesny. Navic pokud (aspon jak to chapu) mu jde o to ucit se.

REDGUY: C

JANFROG: jenže to je je přesně to: mě třeba memory management zajímá. nějaké nápady ohledně toho mám, ale zkušenosti jsou v podstatě z 16bit DOSu (kde se řešily fakt psí kusy) a v Linux jsem se na to vykašlal, protože paměti bylo dost, a já psal spíš "skripty", než rozsáhlejší aplikace (prostě jsem neřešil dealokaci paměti, protože se jí zabralo trochu a program pak stejně brzo skončil)

možností v C je několik, jsou tu různé náhrady za malloc/free, je tu Glib, jsou tu různé hračky... ale ne, místo toho se tady budeme bavit s trolem, který nám vysvětlí, že C je celé špatně a nemá cenu tyhle věci studovat (kromě toho, že tu tuším právě REDGUY, pokud si ho s někým nepletu, před časem navrhoval např. alloca(), které když jsem si pořádně nastudoval, tak jsem zjistil, že je pro věci, které mi zajímají naprosto nevhodné - paměť alkovanou na stacku nejde vrátit pomocí return, například... takže mi ta rétorika čím dál tím víc připadá jako "já jsem nepřišel na to, jak některé věci udělat v C, takže C je tím pádem celé špatně!")

JANFROG: Nejdriv jedna otazka: ted ty interpretry a generatory kodu pises v C nebo C++?

REDGUY: protože když nějakej jazyk znám 20 let, tak řeším, k čemu dalšímu ty znalosti použít - místo toho, abych se učil od nuly něco dalšího a seznamoval s neočekávaným chováním apod.

prostě z nějakého důvodu ti stojí za to úsilí bojkotovat klub, určený pro lidi, který baví/zajímá spíš C než C++. Nebo pro lidí, které baví/zajímá kromě C++ i C. prostě nechápu proč: pod Linuxem je v tom pořád napsaná většina knihoven (když ne aplikací), je to obrovská resource base, nad kterou lze s minimem úsilí udělat něco vlastního. mě zajímá, jaký má kdo názor na to, jak to "něco vlastního" udělat správně. A C++, navzdory názvu, nemá v některých ohledech s C společného o moc víc, než ten JavaScript (tzn. složené závorky :-) a teda konkrétně navíc je taky kompilované, ale tím to fakt končí.

na většině jiných míst na NYXu by tě s přístupem "tenhle klub je celý špatně" už dávno zabanovali...

XCHAOS: A ja se prave snazim naznacit, primarne tedy tobe, ze je fakt dobrej napad zamyslet se nad tim, jestli "necitim potrebu resit proc C" je dobry pristup a jestli, kdyby ses otevrel jinym jazykum, by to z tebe treba neudelalo lepsiho programatora.

REDGUY: tenhle klub je pro lidi, kteří mají nějaký důvod programovat v C a necítí potřebu ho řešit. uznávám, že v záhlaví to mám formulované trochu divočeji :-)

XCHAOS: Samozrejme, zalezi ceho chces dosahnout. Pokud si svuj cil natvrdo nadefinujes jako "jak tohle dobre programovat v C", tak ano, nema smysl se bavit o jinych jazycich. Ale podle me, mnohem zajimavejsi otazka je "proc bych to vubec mel chtit programovat v C".

proč? protože v minulosti se to právě nezřídka dělo! - LOL! Zase: pokud to myslis podobne jako ti, pro ktere studium vojenstvi znamena reenaktovani bitev obcanske valky, tak ano. Psat interpreter/generator kodu v C proto, ze driv to tak lidi delali a chci si to vyzkouset stejne jako experimentali archeologove zkousi zivot v hlinenych chatrcich, dava smysl. Ale pokud to delam proto, ze se chci naucit jak dobre psat interpretr/generator kodu, tak C je jedna z nejhorsich moznosti.

Btw, prijde mi, ze uz zase prubezne posouvas branku jak se ti zrovna hodi. Myslis ze bys mohl nejak explicitne specifikovat, PROC vlastne chces C? Je to proto, ze chces iluzi kontroly? Proto, ze driv se v nem psali veci a chces byt neco jako experimentalni historik? Nebo proto, ze si myslis, ze tak "vymacknes" z pocitace co to da?

REDGUY: mno, nevím, jestli se má člověk "stát dobrým programátorem" (má někdo vůbec takový cíl?) pomocí pochopení jazyka C. ale podle mě lze debatovat o tom, jak tu či onu věc v C dobře naprogramovat. A některé praktiky, ačkoliv samy o sobě jsou validní, můžou znemožnit např. údržbu kódu více lidmi (protože původní vývojář zahrnul nějaké předpoklady, o kterých autor patche nic netušil).

nevím, mj. je i velká šance, že třeba lidi, kteří by si chtěli navrhnout vlastní interpreter (nebo třeba i generátor kódu) sáhnou právě po C (proč? protože v minulosti se to právě nezřídka dělo!).

XCHAOS: jediný nástroj nebude nikdy vhodný pro všechny - ano.

C je celkem dobrý nástroj k pochopení, jak některé věci fungují - to je tak obecny vyrok, ze je to v podstate tautologie.

někteří lidi se prostě chtějí naučit dobře zatloukat hřebíky a nepraštit se u toho přes prsty - jenomze tady se tvoje podobenstvi rozpada. Jestli je tvym cilem naucit se C, no, tak asi ano, na to je C fakt dobry nastroj. Ale jestli je tvym cilem stat se dobrym programatorem, C je spatna volba. A to je i odpoved na tvoji predposledni otazku 8))

REDGUY: já popravdě nevím, k čemu programátory vedeš ty. především se mi zdá, že je odrazuješ od spolupráce se mnou...

REDGUY: jinak jak psát "udrzovatelny a kvalitni kod" mi samozřejmě zajímá taky. to asi zajímá každého. na druhou stranu - poslepovat kód z ready-made komponent, kterým nerozumím, nemusí být nutně odpověď na tuto otázku. lidi, který zajímá, "jak něco funguje uvnitř", budou v určité míře potřeba i v budoucnosti. ne pro každého je jazyk C správná odpověď, ale já se chci bavit s těmi, kteří hledají, jestli to třeba správná odpověď zrovna pro ně není - a ne s těmi, kdo jsou si jistí, že ne.

REDGUY: tak s tím paralelismem vyjímečně souhlasím - že je - nejen v C - potřeba udělat něco, aby thready šlo používat jednodušej (co takhle třeba jen "iterace bez udání pořadí" - tu je možné paralelizovat podle počtu jader, kdyby na to byla jedna instrukce, usnadnilo by to spoustu práce)

jinak co potřebujem a co ne, to je trochu tvůj "plural majesticus". zaměstnanec korporace má asi jinou představu, co potřebuje, než vývojář na volné noze nebo dokonce amatér. jediný nástroj nebude nikdy vhodný pro všechny. aby mohl někdo používat hotovou abstrakci, musí jí někdo jiný naprogramovat. proč je interpreter Pythonu pořád napsaný v C a ne v C++? apod...

C je celkem dobrý nástroj k pochopení, jak některé věci fungují - je to kladivo, a lze na něm okoukat, jak zatloukat hřebík. není to parního buchar uvnitř nějaké ochranné klece, do které dáš věc do které chceš zatlouct hřebík, a ona ti z toho vypadne ve většině případů se zatlučeným hřebíkem a v jednom případě ze sta s ohnutým nezatlučeným hřebíkem, takže musíš zavést výstupního kontrolora kvality a zohlednit to v kalkulaci nákladů a vůbec dělat všechny ty věci, které korporace milují, protože je to to, v čem jsou vážně dobré: celý blackbox parního bucharu můžeš spolehlivě používat celá desetiletí, aniž by si chápal, jak funguje, a můžeš vykřikovat, že potřebuješ víc podavačů hřebíků co to rovnají na běžící pás a víc kontrolorů kvality a víc lidí, co umí prodat zatlučený hřebík - a přitom nikdo v celém tom cyklu nemusí mít ponětí, jak se zatloukají hřebíky, protože parní buchar dodává jiná korporace (teda pokud nestihne zkrachovat dřív, než se buchar rozbije)

to je všechno pěkné, ale někteří lidi se prostě chtějí naučit dobře zatloukat hřebíky a nepraštit se u toho přes prsty. pro tyhle je tenhle klub, a ty sám přiznáváš, že pro tebe ní, tak proč sakra celá ta debata s tebou? (já třeba dostal v konferenci Marxismus na NYXu ban hned, když jsem tam napsal, že mám celkem rád Karla Poppera... proč ty nedostaneš ban tady?)

REDGUY: jasně, všechno je "strawman fallacy"... (aspoň v posledních 10 příspěvcích od tebe). faktem je, že ty se účastníš debatního klubu o C s tím, že chceš dokázat, že to je okrajová záležitost. moderátor klubu se domnívá, že to až tak okrajová záležitost není (min. objem legacy free/open source software napsaný v C je jedním slovem obrovský)... a že např. pokud by se C učili středně pokročilí programátoři, kdyby přitom byli seznámeni s nějakou sadou "best practices" jak se nestřelit do nohy (která se jim neztratí mimochodem ani u těch embded minisystémů), tak by to nemuselo mít špatné výsledky.

naproti tomu, snažit se programátory vést k C++ znamená podle mě vést je směrem, kdy se smíří s používáním abstrakcí, které nechápou, jak fungují uvnitř. a navzdory rozšířené propagandě, objektový model není obrazem fungování světa, ale obrazem fungování hierarchických struktur uvnitř lidské společnosti (což diskutabilně... může být užitečné k tomu najít si dobře placené zaměstnaní, uznávám). Stůl nedědí vlastnosti objektu "noha od nábytku" a stůl a židli není vhodné navrhnout jako extenzi objektu noha, aby mohly stát na podlaze - fakticky, objekty v reálném světě jsou smontované ze součástí, mezi kterými není hierarchický vztah. Tzn. i softwarové objekty nakonec budou smontované či poslepované z objektů, které budou zahrnovat vlastnosti jiných objektů, ale ne děděním. To určitě neznamená, že se vše bude psát v čistém C, ale min. to znamená, že má smysl zajímat se i o jiné abstrakce, než nabízí dnešní OOP.

XCHAOS: takže poslední aplikace, kterou podle tebe má smysl napsat v C, je databázový engine, a když nevím, kolik toho přesně bude, tak to mám rovnou vždycky naskriptovat s použitím databáze - ne, to je samozrejme strawman fallacy. C ma svoje misto (kolikrat to budu opakovat?), ale je velmi male: jadro OS. Malinke embedded systemy. Situace s extremnimi naroky na vykon. A tak dale. Ale treba uz ten db engine to byt nemusi. Pro vsechno ostatni muzu pouzit jine nastroje a budu na tom lip nez s Ceckem.

XCHAOS: lidem dělá dobře představa, že vesmír je deterministický [...] programování prostě nejde vytrhnout z historického kontextu - WHAT. THE. FUCK? Takze protoze (podle tebe) lidem dela dobre "predstava determinismu", je dobre mit iluzi o tom, ze v C mam vsechno pod plnou kontrolou? Je dobre ignorovat vsechny ty veci, o kterejch jsem mluvil, diky kterejm nad low-level vecma vlastne zadnou kontrolu nemam? Opravdu rikas, ze mit technicky spatnou predstavu o tom, jak pocitace fungujou, je vlastne dobre, protoze nejaky filosoficky kecy?

jak příznačné, že dokument:
Recommended C Style and Coding Standards
https://www.doc.ic.ac.uk/lab/cplus/cstyle.html
neobsahuje ani slovo o tom, jak by se mělo v C optimálně zacházet se stringy :-) (BTW, ani netuším, jestli libc v současné verzi obsahuje třeba funkci, která by textový soubor načetla do pole stringů, které alokuje on-fly.. a zase když jsou tam regexpy, tak proč by tam nemělo být tohle? :-)

spíš mi jde o teoretickou úvahu, jak by mohlo C bývalo vypadat, kdyby nikoho v první řadě nenapadlo, že funkce strcpy()/strcat() jsou dobrý nápad :)

REDGUY: viz výše: lidem dělá dobře představa, že vesmír je deterministický. protože opakovaně zjišťují, že ten skutečný není, tak aspoň vymysleli počítače. vem to tak, že pokud se ukázalo, že vědecký pozitivismus 19.století byl slepá ulička a 20.století se vydalo úplně jiným směrem (viz Feynmanovy antičástice cestující v čase opačným směrem než částice apod.), tak se programování počítačů stalo jakousi náhražkovou aktivitou. je to asi podobný posun, jako že ve středověku by správný křesťan vyrazil s plechovým kýblem na hlavě dobývat Svatou zemi, zatímco v baroku by tak maximálně chodil poslouchat od kostela varhany a jen sem tam by někoho upálil (nebo daleko spíš už jen oběsil) kvůli obvinění z čarodějnictví (a stejně by to nedělal už ani moc s přesvědčení, ale spíš jen kvůli vyvlastnění majetku)

programování prostě nejde vytrhnout z historického kontextu.

a teď bychom se mohli vrátit k těm stringům - snažím se celý léta pochopit, co vlastně svým trollováním chceš říct - takže poslední aplikace, kterou podle tebe má smysl napsat v C, je databázový engine, a když nevím, kolik toho přesně bude, tak to mám rovnou vždycky naskriptovat s použitím databáze?

můj pocit z programování od jistého okamžiku je, že kdybychom měli dobré low-level algoritmy na nevím, kolik toho přesně bude, ale jinak celkem primitivní datové struktury, tak bychom ze stávajících technologií vymáčkli daleko víc. ale protože primitivní algoritmy se nejlépe staví nad vím, kolik toho přesně bude datovými typy, tak existují už několik desetiletí značné snahy připodobnit civilizaci počítačové hře, kde panáček chodí po jasně vymezené hrací ploše 80x25 znaků (nebo u ZX Spectra 32x24, dobře :-), aby se to dobře programovalo :-)

Co nelze upřít C++ je, že na rozdíl od různých akademických a experimentálních jazyků má business model: když se smíříš s tím, že stringy (nebo cokoliv jiného) jsou abstrakce a může ti být jedno, jak jsou naprogramované, tak máš větší šanci se někde zaměstnat a být placený od hodiny za vývoj nějaké aplikace podle nějakých specifikací. to je super.. ale vždycky existuje určitý typ lidí, kteří se v tom prostě budou vrtat (ať už půjde o to sami si opravovat auto nebo sletovat zesilovač.. vrtat se uvnitř nějaké ready-made abstrakce, kterou ostatní berou jako hotové spotřební zboží, je prostě jiný typ podobné úchylky... a souhlasím, že to může být nebezpečné, stejně jako když si člověk u auta sám zkusí opravit brzdy :-)